Modules

The modules listed below handle the VTAM® LU6.2 support in CICS®.

DFHZRVL

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:

  1. RECEIVE_WAIT, where CICS waits until input is received from VTAM before returning control to the caller. This applies to all RECEIVE response and command requests, and to data requests where the minimum length to be received is greater than zero.
  2. RECEIVE_IMMEDIATE, where CICS immediately returns control to the caller without waiting for VTAM to complete the request unless the data is already in the VTAM buffer, in which case it processes the data in the same way as for RECEIVE_WAIT before returning to the caller. This is requested via a minimum length of zero. It is used by the RECEIVE_IMMEDIATE call for the SAA communications interface, by a LOOK_AHEAD call, and in support of timely receipt of responses, ensuring earlier detection of an ISSUE_ERROR response from the partner LU.

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.

DFHZRLP

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:

  1. The RPL_B state machine (TCTERPBS) is set to indicate that the RECEIVE has been completed by VTAM; then the exit is taken from DFHZRLP.
  2. This phase corresponds to the single phase used for processing RECEIVE_WAIT requests, that is, the requests are checked for successful completion, examined to determine whether data, a command, or a response has been received, and parameters indicating what has been received are then returned to the caller.

Data received

When data is received, DFHZRLP:

  1. Sets the bracket and chain state machines, and returns indicators to DFHZARL according to the DFC flags received with the data:
  2. If more data is required, DFHZRLP recalls DFHZRVL via the activate scan routine (DFHZACT) to reissue the RECEIVE, for example when:
  3. Returns control to DFHZARL when:

If the data was received with RQD1, a response is sent synchronously by DFHZRLP using the receive RPL.

Command received

When a command is received, the actions of DFHZRLP depend on the command:

All other commands are incorrect.

Response received

When a response is received, DFHZRLP:

  1. Carries out checks:
  2. Sets the state machines.
  3. Passes back the return code to the caller.

DFHZSDL

This module issues the SEND request to VTAM to transmit data, commands, and responses on LU6.2 sessions.

DFHZSDL transmits:

Data transmission

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:

LMPEO
Large message performance enhancement outbound. VTAM slices large messages into RUs.
BUFFLST
Buffer list. VTAM accepts data from non-contiguous buffers.
USERRH
User request header. The request header is passed in BUFFLST.

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.

Command transmission

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.

Response transmission

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.

DFHZSLX

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.

DFHZRLX

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.

DFHCLS3

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:

SIGNOFF
Sign off a user on the other LU
TIMEOUT
Time out users.

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:

  1. Calls DFHZCUT to find a userid that needs to be timed out
  2. Makes a sign-off call to the other LU
  3. Calls DFHZCUT to remove the userid from the LUIT.

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

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:-

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

DFHZGCN is an AP domain subroutine. It handles the four architected CNOS functions, as described below.

INITIALIZE_SESSION_LIMIT

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:

  1. Does a ‘privileged’ allocate (for a SNASVCMG session).
  2. Builds an attach header.
  3. Completes the building of the CNOS command, using MAXIMUM values in the TCTME.
  4. Issues a SEND INVITE WAIT.
  5. Issues a RECEIVE LLID.
  6. Analyzes the responses to the command; SNA decrees that the CNOS source must accept the values returned.
  7. Calls DFHZGCA to action the new values.
  8. Sends messages DFHZC4900 and DFHZC4901 as appropriate.
  9. Frees the session.

The above steps are repeated for each user modegroup in the connection.

RESET_SESSION_LIMIT

A connection release request is passed via DFHZLS1 to DFHZGCN.

DFHZGCN performs the following actions:

  1. Does a ‘privileged’ allocate.
  2. Builds an attach header.
  3. Completes the building of one CNOS command, setting MAX, WIN, and LOS values to zero, and mode names affected to ALL.
  4. Issues SEND INVITE WAIT.
  5. Issues RECEIVE LLID.
  6. Analyzes the response to the command; the CNOS target must accept zero sessions (DRAIN can be changed from ALL to NONE).
  7. Calls DFHZGCA to action the new values.
  8. Sends message DFHZC4900.
  9. Frees the session.

CHANGE_SESSION_LIMIT

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:

  1. Does a ‘privileged’ allocate.
  2. Builds an attach header.
  3. Completes the building of one CNOS command, setting MAX and WIN values.
  4. Issues SEND INVITE WAIT.
  5. Issues RECEIVE LLID.
  6. Analyzes the responses to the command; SNA decrees that the CNOS source must accept the values returned.
  7. Calls DFHZGCA to action the new values.
  8. Sends messages DFHZC4900 and DFHZC4901 as appropriate.
  9. Frees the session.

PROCESS_SESSION_LIMIT

DFHZLS1 is attached, and calls DFHZGCN.

DFHZGCN performs the following actions:

  1. Addresses the CNOS command that DFHZLS1 passed.
  2. For each mode group specified, determines whether the values for session limit, source contention winners and source contention losers are acceptable. If not, the values are adjusted (negotiated) according to rules laid down by SNA.
  3. If this system is currently performing shutdown, negotiates down to session limit zero.
  4. Calls DFHZGCA to action the new values.
  5. Sends the CNOS reply containing the negotiated values.
  6. Sends messages DFHZC4900 and DFHZC4901 as appropriate.

DFHZGCA

DFHZGCA is an AP domain subroutine. It has three separate functions, as described below.

ACTION_CNOS_AND_CONNECT

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.

  1. Put sessions in/out of service for session limit increase/decrease.
  2. Set sessions to winner/loser in line with negotiated values.
  3. Bind/unbind sessions for session limit decrease, autoconnect processing or contention polarity switch.

SET_NEGOTIATED_VALUES

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.

ENSURE_SESSIONS_BOUND

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 ]]