The modules listed below handle the VTAM® LU6.2 support in CICS®.
Session management state machines
Send and Receive processing
CNOS
Persistent Verification
XLN and Resynchronization
DFHZRVL is invoked to issue an LU6.2 receive specific request to receive:
Two broad categories of RECEIVE data are recognized by CICS; both are processed as RECEIVE_WAIT requests to VTAM:
The receive buffer is set up to receive the data, and the address of the receive exit DFHZRLX (driven on completion of the request) is stored into the receive RPL (RPL_B) before the RECEIVE macro is issued to VTAM. DFHZRVL is used by DFHZERH to determine the state of the session.
This module completes the LU6.2 receive specific processing for LU6.2 requests.
RECEIVE_IMMEDIATE requests are processed in two phases, that is, on two passes through DFHZRLP:
When data is received, DFHZRLP:
If the data was received with RQD1, a response is sent synchronously by DFHZRLP using the receive RPL.
When a command is received, the actions of DFHZRLP depend on the command:
All other commands are incorrect.
When a response is received, DFHZRLP:
This module issues the SEND request to VTAM to transmit data, commands, and responses on LU6.2 sessions.
DFHZSDL transmits:
If a SEND LAST command is issued, any outstanding completed receive RPL is first processed by queuing the TCTTE for RECEIVE processing by DFHZRLP, and any incomplete receive RPL is canceled via RESETSR.
For data transmission, DFHZSDL uses:
A maximum of two buffer list entries are used. The first buffer list entry addresses the data in the send buffer, and the second the data in the application area.
The request header is built in the first buffer list entry using parameters passed from DFHZARL. If an implicit send was requested, then CD, RQD2, and CEB are not checked. The first-in-chain (FIC) indicator is set after checking the chain state machine, and last-in-chain (LIC) is set whenever CD, RQD2, or CEB is included. Null data sent only-in-chain (OIC) is converted to an LUSTAT6 command. The address of the send exit DFHZSLX is stored in the send RPL, and the VTAM SEND macro is issued. On completion of the SEND request, the bracket and chain state machines are set according to the DFC indicators. These state machines are used extensively by DFHZERH to determine the state of the session before executing an error request.
The LUSTAT6 command is sent with:
The RTR command requests BB after a BID request is rejected with sense code X'0814'.
The BIS command shows bracket termination before CLSDST.
On completion of the SEND request, the exit DFHZSLX is invoked. LUSTAT causes the bracket and chain state machines to be set as for normal data flow.
DFHZSDL transmits ER1 and DR2 responses. The sequence number associated with the response is that of the path information unit (PIU) that initiated the current bracket. DFHZSDL uses the receive RPL (RPL_B) to send responses thus ensuring that the RU is returned with the response, unless the response is an ISSUE_ERROR request, in which case the send RPL is used. The response is sent synchronously, and POST=SCHED is included in the VTAM command, so that an exit routine is not involved. On return from VTAM, DFHZSDL sets the bracket and chain state machines accordingly.
The DFHZSLX module is the VTAM exit that is driven on completion of a SEND request. 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.
The DFHZRLX module is the VTAM exit that 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.
In the local CICS system, DFHCLS3 is invoked using the DFHLUS macro, which issues a DFHIC TYPE=PUT macro to start the appropriate transaction (CLS3) with data recorded on temporary storage indicating the requested operation.
The DFHLUS operations can be:
The SIGNOFF and TIMEOUT operations apply to persistent verification signons only.
DFHCLS3 retrieves the temporary-storage record.
The SIGNOFF and TIMEOUT operations are performed directly by DFHCLS3. These operations are supported outbound only.
For SIGNOFF, DFHCLS3 is started by DFHZCUT when a user on the other LU must be signed off.
For TIMEOUT, DFHCLS3 is started by DFHZCUT during time-out processing of a persistent verification signed-on-from list, also known to CICS as a local userid table (LUIT).
DFHCLS3 performs the following actions:
This sequence is repeated until there are no more userids to be timed out.
If DFHCLS3 abends during time-out processing, control passes to a SETXIT routine in DFHCLS3, which calls DFHZCUT to tidy up the relevant LUIT.
DFHZLS1 is the main program for the CICS implementation of the CNOS SNA service transaction. When acting as the initiator of a CNOS request (the CNOS source), it is invoked by the DFHZLS1M macro issuing a DFHIC TYPE=PUT for transaction id CLS1. The possible commands on the CNOS source system are:-
Acquire the specified connection, using the MAXIMUM values from the RDO SESSIONS definitions (for the required session limit and number of winner sessions) on the CNOS command for each modegroup.
Negotiate a change of the current session limit for a specified modegroup.
Release the connection, negotiating all modegroups to a session limit of zero.
When acting as the receiver of a CNOS request (the CNOS target), DFHZLS1 is invoked by an attach FMH for TPN X'06F1' sent from the CNOS source system, which is not necessarily CICS. The CNOS command sent with the attach FMH requests changes to the sessions in specified modegroups. In SNA terms, DFHZLS1 is handling a PROCESS_SESSION_LIMIT command. It issues a DFHLUC RECEIVE for the CNOS GDS that contains the details of the required command.
DFHZLS1 passes the parameters for each of the above commands through to DFHZGCN, where the detailed processing takes place.
DFHZGCN is an AP domain subroutine. It handles the four architected CNOS functions, as described below.
This is a two pass function in CICS. First time through, DFHZGCN initiates the bind of the SNASVCMG winner session and returns. The bind processing eventually causes the "session started" routine in DFHZNAC to run. This re-issues the DFHZLS1M INITIALIZE_SESSION_LIMIT request, and the CNOS negotiation can then take place.
DFHZGCN performs the following actions:
The above steps are repeated for each user modegroup in the connection.
A connection release request is passed via DFHZLS1 to DFHZGCN.
DFHZGCN performs the following actions:
DFHZLS1 is started from the EXEC API or CEMT via DFHEIQSM to change the session limit for a specific modegroup.
DFHZGCN performs the following actions:
DFHZLS1 is attached, and calls DFHZGCN.
DFHZGCN performs the following actions:
DFHZGCA is an AP domain subroutine. It has three separate functions, as described below.
After a CNOS negotiation DFHZGCA is responsible for changing the state of a specified modegroup to reflect the new values. There are three types of action required.
This function is used by DFHZGPC during persistent sessions restart to set the saved CNOS values in the modegroup without any binding/unbinding of sessions.
DFHZXRE0 invokes this function during persistent sessions restart because recovery processing can lead to LU6.2 sessions becoming unbound. It is important to ensure that they are re-bound in accordance with the autoconnect setting.
[[ Contents Previous Page | Next Page Index ]]