CICS® uses ACF/VTAM to establish, or bind, logical-unit-to-logical-unit (LU-LU) sessions with remote systems. Being a logical connection, an LU-LU session is independent of the actual physical route between the two systems. A single logical connection can carry multiple independent sessions. Such sessions are called parallel sessions.
CICS supports two types of sessions, both of which are defined by IBM® Systems Network Architecture:
The characteristics of LUTYPE6 sessions are described in the Systems Network Architecture book Sessions Between Logical Units.
Note that you must not have more than one APPC connection installed at the same time between an LU-LU pair. Nor should you have an APPC and an LUTYPE6.1 connection installed at the same time between an LU-LU pair.
LUTYPE6.1 is the forerunner of LUTYPE6.2 (APPC).
LUTYPE6.1 sessions are supported by both CICS and IMS™, so can be used for CICS-to-IMS communication. (For CICS-to-CICS communication, LUTYPE6.2 is the preferred protocol.)
The general term used for the LUTYPE6.2 protocol is Advanced Program-to-Program Communication (APPC).
In addition to enabling data communication between transaction-processing systems, the APPC architecture defines subsets that enable device-level products (APPC terminals) to communicate with host-level products and also with each other. APPC sessions can therefore be used for CICS-to-CICS communication, and for communication between CICS and other APPC systems or terminals.
The following paragraphs provide an overview of some of the principal characteristics of the APPC architecture.
The APPC protocol boundary is a generic interface between transactions and the SNA network. It is defined by formatted functions, called verbs, and protocols for using the verbs. Details of this SNA protocol boundary are given in the Systems Network Architecture publication Transaction Programmer’s Reference Manual for LU Type 6.2.
CICS provides a command-level language that maps to the protocol boundary and enables you to write application programs that hold APPC conversations. Alternatively, you may use the Common Programming Interface Communications (CPI Communications) of the Systems Application Architecture® (SAA) environment.
Two types of APPC conversation are defined:
The APPC architecture provides three levels of synchronization. In CICS, these levels are known as Levels 0, 1, and 2. In SNA terms, these correspond to NONE, CONFIRM, and SYNCPOINT, as follows:
All three levels are supported by both EXEC CICS commands and CPI Communications.
When a transaction initiates a remote transaction connected by an APPC session, it can send data to be received by the attached transaction. This data, called program initialization parameters (PIP), is formatted into one or more variable-length subfields according to the SNA architected rules. CPI Communications does not support PIP.
Multisession APPC connections use the LU services manager. This is the software component responsible for negotiating session binds, session activation and deactivation, resynchronization, and error handling. It requires two special sessions with the remote LU; these are called the SNASVCMG sessions. When these are bound, the two sides of the LU-LU connection can communicate with each other, even if the connection is ‘not available for allocation’ for users.
A single-session APPC connection has no SNASVCMG sessions. For this reason, its function is limited. It cannot, for example, support level-2 synchronization.
The CICS implementation of APPC includes support for "class of service" selection.
Class of service (COS) is an ACF/VTAM facility that allows sessions between a pair of logical units to have different characteristics. This provides a user with the following:
In particular, sessions can take different virtual routes, and thus use different physical links; or the sessions can be of high or low priority to suit the traffic carried on them.
In CICS, APPC sessions are specified in groups called modesets, each of which is assigned a modename. The modename must be the name of a VTAM® LOGMODE entry (also called a modegroup), which can specify the class of service required for the session group. (See ACF/VTAM LOGMODE table entries for CICS.)
For efficient use of some network resources (for example, switched lines), SNA allows for such resources to be defined in the network as limited resources. Whenever a session is bound, VTAM indicates to CICS whether the bind is over a limited resource. When a task using a session across a limited resource frees the session, CICS unbinds that session if no other task wants to use it.
Both single- and multi-session connections may use limited resources. For a multi-session connection, CICS does not unbind LU service-manager sessions until all modegroups in the connection have performed initial "change number of sessions" (CNOS) exchange. When CICS unbinds a session, CICS tries to balance the contention winners and losers. This may result in CICS resetting an unbound session to be neither a winner nor a loser.