Queueing sessions

Logon manager applications are very popular. Typically they are set up as a default application which sends a selection screen to the user. After the user specifies the destination application choice, the logon manager typically issues a CLSDST macro with OPTCD=PASS to the destination application. A new session is started with the destination application. The logon manager session is closed with a special UNBIND sent to Telnet indicating that a new session BIND is forthcoming. Telnet receives that special UNBIND and then waits for the next BIND instead of cleaning up as it would when receiving a normal UNBIND. When the user logs off the destination application, Telnet either goes through the initial database lookup process again (which will result in a session with the logon manager) or drops the connection, depending on whether LUSESSIONPEND is coded. Logoff of the original application will cause Telnet to perform normal close function instead of leaving the LU ACB open.

Many logon managers were written to support real terminals, not Telnet, and issue a SIMLOGON OPTCD=Q immediately after issuing the CLSDST-PASS. When SIMLOGON Q is coded, the logon request is added to a VTAM® queue. The first application queued is the first application off the VTAM queue. Immediately after user logoff from the destination application, VTAM (on behalf of the logon manager) will request a session with the terminal LU (or Telnet LU representing the client). This works very well for real terminals, but causes timing problems for Telnet when the logon manager is a default application. In this case, Telnet and VTAM both end up requesting a session.

The QSESSION option on ALLOWAPPL or RESTRICTAPPL can be used to correct this timing problem. When coded for the logon manager, Telnet will not do normal close processing when the UNBIND from the destination application arrives. Telnet will leave the LU ACB open and wait for the BIND from the logon manager that is generated because of the Queued SIMLOGON. When the BIND does arrive, Telnet will verify that the application name is the original logon manager and finish session setup.

If QSESSION is specified for an application that does not queue a SIMLOGON, or the SIMLOGON is removed from the queue because the original application was recycled, Telnet will be waiting for a BIND that is never coming. The connection will appear to be hung. To safeguard against this hang condition, a timer can be started when the destination application UNBIND is received. Telnet will wait for the specified period of time for a BIND from the QSESSION application. If the timer expires and there is no session, Telnet will clean up the connection as if the QSESSION parameter had not been specified.

As an example of the QSESSION parameter, assume that APPL1, APPL2, and APPL3 are each defined in VTAM. APPL1 will issue a SIMLOGON-Q after CLSDST-PASS. The following Telnet statements allow connections to access the applications and define which is a QSESSION application.

ALLOWAPPL APPL1 QSESSION,3
ALLOWAPPL APPL*

The client first logs on to APPL1. APPL1 issues a CLSDST-PASS to APPL2 and a SIMLOGON-Q. Finally, APPL2 issues a CLSDST-PASS to APPL3. When the APPL3 session is ended, VTAM sends an APPL1 BIND to Telnet. If the queued SIMLOGON had been removed, Telnet would have continued cleanup 3 seconds after receiving the UNBIND from APPL3. When the APPL1 session is ended, the ACB is closed and Telnet either goes through the initial database lookup again or closes the connection, depending on whether LUSESSIONPEND is coded.

As a second example, assume that APPL2 also issues a SIMLOGON-Q after it issues a CLSDST-PASS to APPL3. As in the previous example, when the APPL3 session is ended, VTAM sends an APPL1 BIND to Telnet. If the queued SIMLOGON had been removed, Telnet would have continued cleanup 3 seconds after receiving the UNBIND from APPL3. When the APPL1 session is ended, VTAM sends an APPL2 BIND to Telnet. The APPL2 SIMLOGON-Q was queued behind the APPL1 SIMLOGON-Q in VTAM.