For UNIX platforms, AcuLaunch software is shipped on the Acucorp product CD-ROM. The files contained on the release media are described in the file "READ_ME.rcl."
1. Create a directory on the server to hold the AcuLaunch software. We recommend that you install AcuLaunch directly into the ACUCOBOL-GT home directory.
2. Mount the product CD-ROM on your UNIX system. Change directory ("cd") into the directory where your product CD-ROM is mounted and execute the install script as described on the Getting Started card that came with your product.
Follow the instructions on the card, entering your product code and product key when prompted.
In the target directory you should now find the files listed in "READ_ME.rcl". If you want to use the server configuration file in its default location, move "acurcl.cfg" into the "/etc" directory. This may require root or superuser privileges. The "acurcl.cfg" file may remain in the current directory, or be copied or moved to some other directory. If "acurcl.cfg" is not located in the default directory ("/etc"), the name and location of the configuration file must be specified with the "-c" option each time acurcl is started. See Appendix A, The "acurcl" Command.
AcuLaunch is now fully installed and ready for configuration on the UNIX server. See section 3.3.4 Modifying the Server Access File for important information about security. See section 3.3.2 Assigning Values to Server Configuration Variables for the settings that can be configured for the server.
Note that acushare is installed automatically as part of AcuLaunch installation.
Running AcuLaunch on HP MPE/iX Systems
A limitation in the MPE/iX operating environment requires that sites planning to use AcuLaunch 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.
AcuLaunch uses the same basic methods as AcuServer and AcuConnect to start the service, validate a service request, and fulfill a request. AcuLaunch runs as an independent resident program (daemon) called acurcl. The running acurcl 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, acurcl 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, acurcl 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, acurcl) to change its user ID. Therefore, the service always uses the ID of the account that started acurcl. Any action acurcl 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 AcuLaunch.
Because acurcl 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 acurcl 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 acurcl 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 acurcl is not executing a request, it waits on a socket in an efficient loop, consuming few resources.