A limitation in the MPE/iX operating environment requires that sites planning to use AcuConnect on an MPE/iX host carefully consider how they will deploy the service.
AcuConnect uses the same basic methods as AcuServer® to start the service, validate a service request, and fulfill a request. AcuConnect 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 doesn't 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 AcuConnect.
Because acurcl takes the user ID of the account that starts it, and because it uses that ID to access files and fulfill requests, that account must 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 as long as the number of separate instances doesn't overtax 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.