2.1 Getting Started on UNIX

There are three basic steps to using AcuServer in a UNIX environment.

1. Install AcuServer. If you have not already installed AcuServer on your UNIX server, please refer to sections 2.2 and 2.3 of this chapter for a list of installation requirements and procedures. If AcuServer is already installed, then proceed to the next step. There is nothing on the AcuServer distribution media to install on the client machine. However, you should ensure that every client system that will use AcuServer has a licensed copy of an ACUCOBOL-GT runtime, Version 5.1 or later, and you may need to set up client passwords, user names and host names. This is described in section 2.5 Installing the Client.

2. Configure the AcuServer system. AcuServer system configuration consists of:

• Assigning values to the runtime configuration variables. With the exception of the FILE_PREFIX and possibly CODE_PREFIX variables (discussed later in this chapter), none of the runtime configuration variables requires modification. For information about runtime configuration variables, see section 4.2.1 Runtime Configuration Variables.
• Assigning values to the AcuServer configuration variables. None of the server configuration variables requires modification; however, you may want to modify them to gain control over or initiate certain functions like file locking, multi-record mode, error trace flushing, and more. For information about server configuration variables, see section 4.2.2 Server Configuration Variables.
• Creating the server access file. AcuServer file access security is managed by a site configured access file called the server access file. You must create a server access file (default name "/etc/AcuAccess") before AcuServer will start or establish connections with clients. AcuServer includes a command line option, "-access", for creating and maintaining the server access file. Step by step instructions are included in section 6.4.2 Creating or Opening an Access File. General information about the file is included in section 6.2 The Server Access File.
• Assigning and verifying UNIX ownerships and permissions on AcuServer's executable, access, and configuration files as well as existing data files and directories. AcuServer will not run on a UNIX server unless proper ownerships and permissions are set. Setting ownerships and permissions requires root privileges. Use the UNIX utilities "chown" and "chmod" to set ownerships and permissions as described in section 2.4 Ownerships and Permissions.
• Modifying your runtime configuration file or application code to use remote name notation. To use AcuServer, your applications must use remote name notation to reference files located on the server. The ACUCOBOL-GT runtime looks for remote name notation to identify requests to AcuServer. Remote name notation has the format "@server-name:path-name". You may add a remote path to the FILE_PREFIX or CODE_PREFIX configuration variables. Alternatively, you can define file name aliases in the runtime configuration file. A file name alias is a string that will replace the literal name in the ASSIGN TO clause of a SELECT statement. For more information on remote name notation, please refer to section 7.2 Accessing Remote Files.

3. Issue AcuServer commands. AcuServer services are handled by the acuserve daemon running on the server. The acuserve command can be invoked from the command line to start and stop AcuServer (the acuserve daemon), retrieve AcuServer operation status, unlock stranded files, and create and maintain the server access file. For complete details, read Chapter 5.

Please be aware that configuration of AcuServer system security is very important to safeguarding your data files and network computers. We urge you to read Chapter 6 before placing AcuServer into open service.

Running AcuServer on HP MPE/iX Systems

A limitation in the MPE/iX operating environment requires that sites planning to use AcuServer on an MPE/iX host carefully consider how they will deploy the service. The remainder of this section describes the situation and offers two management approaches for deploying on MPE/iX.

AcuServer uses the same basic methods as AcuLaunch and AcuConnect to start the service, validate a service request, and fulfill a request. AcuServer runs as an independent resident program (daemon) called acuserve. The running acuserve process takes the user ID of the account that starts the program. The service normally runs in the background, waiting for requests. When a service request is received, acuserve determines the user ID of the requester, checks an authorization file ("AcuAccess") to determine if the requester is allowed to use the service, and determines the proxy user ID to be used for the requester (the requester user ID can be mapped to another ID; the mapped ID may be unique or may be shared by a number of users). If authorization is successful, acuserve temporarily assumes the proxy user ID to fulfill the request. On most UNIX systems, the SETUID system function is used to assume the correct user ID. A similar function is used in the Windows operating environment.

In the MPE/iX environment, the operating system does not provide a way for a program (in this case acuserve) to change its user ID. Therefore, the service always uses the ID of the account that started acuserve. Any action acuserve takes is performed with that ID. This inability to change IDs imposes some limitations and requires that MPE/iX sites carefully consider how they will deploy AcuServer.

Because acuserve takes the user ID of the account that starts it, and because it uses that ID to access files and fulfill requests, it's very important that that account be able to service all anticipated requesters. There are two approaches to managing this issue. The approaches can be combined.

One approach is to start acuserve from an account that is accessible to all requesters (a "group" account). Of course, such an account must have all of the necessary access permissions to satisfy every requester. The limitation of this approach is that all requesters have the same proxy user ID on the server and there is no way to identify a unique requester.

The second approach is to start a separate instance of acuserve for each unique requester, or group of requesters (multiple group accounts). This approach will work so long as the number of separate instances does not over tax system resources (process space, processor capacity, and dynamic memory). The number of instances that each system can handle will vary depending on the resources of that machine. Some experimentation may be necessary to determine the limits of a given machine. Note that when acuserve is not executing a request, it waits on a socket in an efficient loop, consuming few resources.