z/OS MVS Planning: APPC/MVS Management
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Network Terms

z/OS MVS Planning: APPC/MVS Management
SA23-1388-00

Logical Units (LUs) and LU 6.2
A logical unit is an SNA addressable unit that manages the exchange of data and acts as an intermediary between an end user and the network. There are different types of logical units. Some LU types support communication between application programs and different kinds of workstations. Other LU types support communication between two programs. LU type 6.2 specifically supports program-to-program communication. The actual implementation of LU 6.2 on a given system is APPC.
Local LU/Partner LU
Whether an LU is a local LU or a partner LU depends on point of view. From the point of view of an z/OS system, LUs defined to the z/OS system are local LUs and LUs defined to remote systems are partner LUs. However, from the point of view of the remote system, the names are reversed: the LUs that are defined to its system are local LUs and the ones on z/OS are the partner LUs.

A partner LU might or might not be on the same system as the local LU. When both LUs are on the same system, the LU through which communication is initiated is the local LU, and the LU through which communication is received is the partner LU.

LUs are defined to VTAM on z/OS by APPL statements in SYS1.VTAMLST. LUs managed by APPC/MVS must also be defined by LUADD statements in APPCPMxx parmlib members.

Physical units (PUs)
An SNA network consists of physical nodes, called physical units (PUs), which are connected by physical data links. Typically in an APPC/MVS network, there is at least one host node (PU 5), one communication controller node (PU 4), and any number of peripheral nodes (PU 2.0 and PU 2.1). A PU 2.0 can be either a programmable workstation or a non-programmable workstation that is configured as a dependent LU. A dependent LU can support a single session. Because only one conversation can flow over a session, the dependent LU can be used by only one transaction program at a time. A PU 2.1 is a physical node, such as a programmable workstation, an AS/400, or other compatible hardware, that can be configured as an independent LU. An independent LU can support multiple sessions concurrently. With a conversation flowing over each session, the LU can be used by many transaction programs at the same time.
Sessions
A session is a logical connection that is established or bound between two LUs of the same type. A session acts as a conduit through which data moves between the pair of LUs.

The following figure shows how a session spans two LUs that are defined on two different systems.

Figure 1. A Session between Two LUs
A Session between Two LUs

A session can support only one conversation at a time, but one session can support many conversations in sequence. Because sessions are reused by multiple conversations, a session is a long-lived connection compared to a conversation.

If no session exists when a TP issues an Allocate call to start a conversation, VTAM binds a session between the local LU and the partner LU. After a session is bound, TPs can communicate with each other over the session in a conversation. This sending of data between a local TP and its partner occurs until one TP ends the conversation with a Deallocate call.

The following figure shows a single conversation between TP1 and TP2 that is occurring over a session.

Figure 2. A Conversation between Two TPs
A Conversation between Two TPs

If the hardware permits and the two LUs are configured as independent LUs, they can have multiple, concurrent sessions called parallel sessions. When a TP from either LU issues an allocate call and sessions exist but are being used by other conversations, an LU can request a new session unless the defined session limit is reached.

Default session limits are defined for an LU in a VTAM APPL statement. Session-limit values can be changed by entering the VTAM MODIFY CNOS and MODIFY DEFINE operator commands, or by modifying the VTAM APPL definition statement and then restarting APPC/MVS. For more information about these commands, see z/OS Communications Server: SNA Operation.

The following figure shows three parallel sessions, each of which is carrying a conversation.

Figure 3. Parallel Sessions between LUs
Parallel Sessions between LUs

An installation can define different types of sessions, but sessions are ultimately defined by the LUs they span and by the session characteristics contained in the VTAM logon mode table that is associated with the session.

Sessions can span LUs on the same system, LUs on two like systems, and LUs on two unlike systems that are LU 6.2 compatible. The following figure shows three sessions bound from a single LU on SYS2. Session 1 spans LUs on two different systems. Session 2 spans the same two systems but is bound from a different LU on SYS1. Session 3 is bound between two LUs on the same system.

Figure 4. Different Types of Sessions between Two LUs
Different Types of Sessions between Two LUs
Logon Modes
A logon mode contains the parameters and protocols that determine a session's characteristics. Logon modes are defined in a VTAM logon mode table, a compiled version of which exists in SYS1.VTAMLIB. Session characteristics, such as pacing levels and class of service, are controlled by entries in logon mode tables. A VTAM system programmer can use these characteristics to define sessions for specific types of transactions, such as for ASCII data, satellite communication, high-speed transactions, batch, and interactive data.
Contention
When a TP from each LU in a session simultaneously attempts to start a conversation, the situation that results is called contention. To control which TP can allocate the conversation, a system programmer can define for each LU the number of sessions in which it is the contention winner and the number of sessions in which the LU is the contention loser.

Generally, a system programmer divides the contention winner role between the two LUs. For example, if two LUs can have ten parallel sessions and if the sessions will be equally started by both LUs, each LU is designated the contention winner for five sessions and the contention loser for five sessions. A contention winner can use the session without informing the contention loser. A contention loser can request use of the session from the contention winner.

Default contention winners and losers are defined for an LU in a VTAM APPL statement.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014