How the ACUCOBOL-GT Thin Client connects to AcuLaunch depends on the client application that is attempting to connect. However, some common steps are involved with any attempt, regardless of the client application. These are described here to clarify the use of the server access file and the DEFAULT_USER configuration variable, as well as the NT_SECURITY configuration variable.
Once the Thin Client has been invoked, the client process makes a request to AcuLaunch. To validate the requester's access privileges, AcuLaunch does the following:
1. opens the server access file
2. searches for a record that matches both the client machine name and the client user name
3. (if no match is found) searches for a record that matches the client machine name and a "match all" (blank) client user name
4. (if no match is found) searches for a record that has the "match all" ("*") client machine name and the client user name
5. (if no match is found) searches for a record that has the "match all" ("*") client machine name and the "match all" (blank) client user name
6. (if no match is found) refuses the connection.
When a match is found:
1. If the Local Username is valid, it is used.
2. If the Local Username is not valid, DEFAULT_USER is used.
3. If the Local Username is not valid and DEFAULT_USER is not valid, the connection is refused.
If the Local Username is valid and the password field is defined, a message is sent back to the requester asking for a password. For more about password handling, see section 5.2.2 Passwords.
When a connection is established, AcuLaunch invokes the runtime based on the information given by the client making the request. AcuLaunch connects that child runtime with the client, and then removes itself from the communication loop between the two processes.
The ACUCOBOL-GT runtime on the server runs the specified ACUCOBOL-GT program, which performs the requested task.
The ACUCOBOL-GT runtime returns screen information to the Thin Client, which displays it on client.