Use the parameters of the job description you entered in the LANSA Communication Extensions definitions to determine the subsystem in which the session jobs will run. This subsystem must allow for as many active jobs as you expect. Otherwise session jobs submitted by the Listener will be queued and unable to receive connection requests.
The session job starts running with the same user profile as the listener job. When a connection request is received, the session job performs a "sign-on" of the user requesting the remote session. After the new user is signed on, the job will run under the new user profile. (The library list is changed to the initial library list of the new user.)
Note that although the session job runs under the signed-on user profile, the initial job name doesn't change. You must not rely on the user component of the job name to identify the user who is running the session job. Instead, you should retrieve the current user attribute of the session job. This is handled by LANSA but you should be aware of it when using non LANSA programs.
Library List Considerations
To make it easier for users to connect to different LANSA systems, when the user signs on, the session job checks if the LANSA program library and the LANSA communications library are in the library list. If not present, they are added at the top of the library list. Therefore, the user profile doesn't need to have the LANSA libraries in his/her library list.
The automatic addition of LANSA libraries only works when the LANSA communications programs and service programs are installed in their standard libraries.