z/OS Communications Server: SNA Programmer's LU 6.2 Guide
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


How session limits are used

z/OS Communications Server: SNA Programmer's LU 6.2 Guide
SC27-3669-00

The dialogue between transaction programs is called a conversation. The dialogue between logical units (LUs) is called a session. The conversation uses the session as its transmission medium. The session is a serially reusable resource of the conversation. While the session is in use for one conversation, it cannot be used for any other conversation. More than one session can be active between the same pair of LUs, which is called parallel sessions. The sessions between two LUs are grouped together by mode name. One of the application programs, acting on behalf of the transaction program, initiates the action.

To help with the allocation of storage at the LU, limits are placed on the number of sessions that an LU can have for a given logon mode name.

Before two LUs can start any conversations between them, they must negotiate the type and number of sessions, referred to as session limits. These session limits restrict the number of concurrent conversations an application program manages. Each conversation must be allocated to an active session.

Session limits do not affect the number of conversation requests that the application program can issue. VTAM® manages the conversation workload for the application program by controlling when a session is assigned to a conversation request.

A session is associated with a mode, which represents a specific set of session characteristics or capabilities. LUs negotiate session limits on a per-mode basis before any conversations can be allocated on a mode. An LU can use several modes, giving it greater capability, and more than one LU can use the same mode. Each set of characteristics, or mode, is stored in the logon mode table and identified by a logon mode name.

As an example of how session limits function, suppose two LUs negotiate a limit of 10 sessions between them on a logon mode, but they need 100 conversations on that logon mode to service transaction programs. The application programs can issue macroinstructions requesting the 100 conversations. However, because a limit of 10 sessions has been negotiated, only 10 sessions can be active between the two LUs on that logon mode. Therefore, no more than 10 conversations can be active at any given time. When all 10 sessions are assigned to conversations, the remaining conversation requests can be queued until the currently active conversations end and sessions become free. As sessions are freed, they are assigned to queued conversation requests.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014