Initiating a Session

A session between a terminal and a VTAM application is initiated by logging on to the application and specifying the name (as defined to VTAM) of the requested VTAM application. KOA command LOGON performs exactly the same function. In addition, for each session that is initiated, KOA selects a terminal name (which is used during communication with the VTAM application). This terminal name is dynamically selected from a predefined pool of terminal names as defined in member CTOPARM.

The TERMINAL parameter of command LOGON can be used to force a specific terminal name for the session. This may be useful when the VTAM application performs security checks based on terminal name.

As part of the logon process, the LU can pass information (messages) to the VTAM application. For example, the user ID can be passed to TSO. The DATA parameter of command LOGON performs this function.

Note: When a session is initiated, the VTAM application usually sends the first message (for example, a welcome message or a sign-on screen). Therefore, after a session is initiated, KOA expects to receive a message from the application. However, there are applications that expect the first message to come from the terminal (LU) instead. For these cases, the command SCREENMODE NORECEIVE should be specified before command LOGON, and KOA should be the first to send a message after the logon process is completed. As part of session initiation, the VTAM application and the LU may exchange certain information before the first screen is sent. For example, the application may require the specification of physical terminal characteristics (for example, screen size or screen display data type) before sending the first screen. Although this has no effect on a user working with a standard terminal (because this message switching is very quick), the KOA script must provide for these situations.

Most cases are handled automatically, and KOA receives the first screen immediately following command LOGON. However, in certain situations the user receives an "empty" screen (or several "empty" screens) before the expected first screen. Scripts must be designed to handle these situations.

Example

The following sample script logs on to CICS. This script is designed to handle the receipt of empty screens.

Table 18 KOA Sample Script to Log on to CICS