The LOGAPPL, QINIT, FIRSTONLY, and DEFONLY options can be coded on DEFAULTAPPL, PRTDEFAULTAPPL, LINEMODEAPPL, LUMAP-DEFAPPL, or PRTMAP-DEFAPPL. For the remainder of this topic, DEFAULTAPPL represents all the default application statements.
- LOGAPPL, QINIT
The LOGAPPL or QINIT functions keep the Telnet LU active if a Request Session fails due to the host VTAM® application not being active. In addition, VTAM remembers the attempted Request Session and will initiate a session request to the Telnet LU on behalf of the application when the application becomes active. When the Request Session fails, Telnet sends the client a solicitor screen or USSMSG07 screen. The user then has the option of logging on to a different host VTAM application (if DEFONLY is not coded). When this different session is started, VTAM drops the queued Request Session for the original session.
What happens at session logoff depends on whether or not LUSESSIONPEND and FIRSTONLY are coded and whether LOGAPPL or QINIT is coded. If LUSESSIONPEND is coded, the connection remains; otherwise, it is dropped. If FIRSTONLY is coded, Telnet sends a USSMSG10 screen or solicitor screen to the client. If FIRSTONLY is not coded, Telnet will initiate another session with the default application defined by the DEFAULTAPPL statement. LOGAPPL and QINIT have different results when logging off the original application. When LOGAPPL is specified, a USSMSG10 or solicitor screen is sent to the client. When QINIT is specified, Telnet requests a session with the default application.
- FIRSTONLY, DEFONLY
Sometimes a default application is used for the initial connection, but after LOGOFF a USSMSG10 or solicitor screen is more appropriate than redriving the default. In this case, code the FIRSTONLY parameter. This indicates the default should be used on the first session only. After a session has been established, any subsequent lookups ignore the default and send the USSMSG10 screen or solicitor screen.
If MSG07, LUMAP-DEFAPPL, or PRTMAP-DEFAPPL is coded and the default application is inactive, an error screen will be sent to the client. The DEFONLY parameter will block a user-entered application choice if it is different than the default. This parameter prevents application choice while giving the user error information.
- ReqSess OK - A Request Session to the default application succeeded or a Request Session to a second application from the USSMSG07 screen succeeded.
- ReqSess Fail - A Request Session to the default application failed.
- 2nd Appl Fail - A Request Session to a second application from the USSMSG07 screen failed.
FIRSTONLY is not a consideration because the first session has not been established.
- In session.
- Send USSMSG07 or solicitor screen to client. Close the ACB.
- Send USSMSG07 or solicitor screen to client. Keep ACB open, queue original session request in VTAM.
- Send USSMSG07 or solicitor screen to client. Keep ACB open, keep the original queued session request in VTAM.
- Drop connection.
The following table summarizes several possible session ending scenarios. The session is ending due to normal LOGOFF or session breakage (possibly caused by loss of the application).
- Original Application - User is in session with the original default application.
- CLSDST from Original Appl - User is in session with a second (or later) application after issuing a CLSDST-PASS from the original application.
In all cases, if LUSESSIONPEND is not coded the connection is dropped.
- Request a session with the default application.
- Send USSMSG10 or solicitor screen to client. Close the ACB.