z/OS Communications Server LU6.2

This section describes the layer of CICS® that manages the interface to the z/OS® Communications Server for LU6.2 communication. The z/OS Communications Server LU6.2 provides advanced program-to-program communication (APPC) between transaction-processing systems, and enables device-level products (APPC terminals) to communicate with host-level products and with each other. APPC sessions can therefore be used for CICS-to-CICS communication, and for communication between CICS and other APPC systems (for example, AS/400) or terminals.

For information about the CICS functions that you can use to exploit LU6.2 communication, see Distributed program link, Distributed transaction processing, Function shipping, Intersystem communication (ISC), Transaction routing.

Detailed information about z/OS Communications Server LU6.2 commands and macros is given in the relevant z/OS Communications Server manuals.

Design overview

The main feature that distinguishes LU6.2 from other LU types is the support for parallel sessions i.e. many sessions (and conversations) between the two LUs at the same time. These sessions are further grouped by use of the class of service facility in z/OS Communications Server. The TCT structure for LU6.2 reflects this. Under the system entry (TCTSE) are a series of mode group entries (TCTMEs). Within a mode group there are a number of sessions represented by terminal entries (TCTTEs).

All the sessions within a mode group have the same transmission characteristics, that is, the same class of service. When a request to ALLOCATE a session is made, a MODENAME can be specified, indicating which class of service is required.

When a session has been allocated and a conversation started, data can be received and sent between the connected LUs. This is more or less directly under the control of the CICS application in the case of DTP, or indirectly under the control of the user for the other ISC facilities.

CICS also supports LU6.2 single session connections. These are represented by a TCTSE, a single TCTME and a single TCTTE. They support the same functions as parallel session connections.

The LU6.2 states for each session are stored in the TCTTE for that session. The modules and associated TCTTE field are usually referred to as state machines. When a module, such as DFHZARL, wants to check that the session is in a suitable state to perform a given operation, it uses the appropriate state machine to perform the check by invoking the CHECK function of the relevant macro. If the operation subsequently causes a change in the state of the session, the SET function of the relevant macro is invoked to record the new state. For more information, see Table 1.

See the following topics for additional details:

Modules

These modules handle the z/OS Communications Server LU6.2 support in CICS.

Table 1 lists the CICS modules that maintain specific states of LU6.2 sessions. These modules are invoked via the macros shown in the last column. Any query or change to the states is performed using these macros.

Table 1. LU6.2 session management state machines
Module State Macro
DFHZBKT SNA bracket state DFHZBSM
DFHZCNT Contention state DFHZCNM
DFHZCHS Chain state DFHZCHM
DFHZCRT RPL_B state DFHZCRM
Table 2. Send and receive processing modules
Module Description
DFHZRLP DFHZRLP handles the completion of LU6.2 RECEIVE requests.
DFHZRLX DFHZRLX is a z/OS Communications Server exit routine that queues the completed RPL for (post-z/OS Communications Server) processing by DFHZRLP.

It is scheduled on completion of an LU6.2 RECEIVE_SPECIFIC request. DFHZRLX queues the completed RPL to a chain anchored from TCTVRLPQ in the TCT prefix. DFHZDSP dequeues the RPLs for further processing by DFHZRLP.
DFHZRVL DFHZRVL processes RECEIVE commands for LU6.2 sessions.
DFHZSDL DFHZSDL processes SEND commands for LU6.2 sessions.
DFHZSLX DFHZSLX is a z/OS Communications Server exit routine that handles the completion of LU6.2 SEND requests. If the request completed successfully, the bracket and chain state machines are set to show the new state of the session. If the SEND request was data DR1, DFHZRVL is invoked via DFHZACT to receive the response.
Table 3. CNOS modules
Module Description
DFHZLS1 The main program for the CICS implementation of the CNOS SNA service transaction.
DFHZGCN DFHZGCN is an AP domain subroutine. It handles four architected CNOS functions that manage the session limit.
DFHZGCA DFHZGCA is an AP domain subroutine that has three separate functions.
Table 4. Others
Module Description
DFHCLS3 Persistent verification module
DFHCRRSY XLN and resynchronization module

Exits

No global user exit points are provided for this function.

Trace

The following listed modules have entry and exit trace points. Several of them also have exception and level 2 trace points. All of these trace points are from the AP domain and have IDs in the range FB00-FCFF.

  • DFHZRVL
  • DFHZRLP
  • DFHZSDL
  • DFHZSLX
  • DFHZRLX
  • DFHCLS3
  • DFHZLS1
  • DFHZLS1
  • DFHZGCN
  • DFHZGCN
  • DFHZGCA