Use the parameters of the job description you entered in the LANSAto determine the subsystem in which the session jobs will run. The subsystem where the session jobs will run 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).
To perform the user sign-on, the session job uses APIs QSYGETPH, QWTSETP, and QSYRLSPH which are supplied by IBM. The user profile which owns program LCOTP must have authority to use these APIs.
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.