DFHEGL processes GDS commands. It is an EXEC interface processor module, and receives control directly from DFHEIP. The TCTTE for the session is located and checked for validity. All GDS conversation-related commands are mapped into a DFHLUC macro call and routed directly to DFHZARL. There is no mapping or unmapping of data, state indicators are not maintained, and there are no FMHs to process.
DFHEIP routes all terminal control requests to DFHETC (the EXEC interface processor for terminal control). DFHETC handles BUILD_ATTACH, EXTRACT, and POINT_TC requests itself. It routes all other requests relating to an MRO or LU6.1 session to DFHZARQ except for FREE_TC and ALLOCATE_TC requests, which are routed to DFHZISP. It routes all other requests relating to an LU6.2 session to DFHETL except for ALLOCATE_TC, which is routed to DFHZISP.
DFHETL performs the following actions:
For ISSUE CONFIRMATION, CONNECT PROCESS, EXTRACT PROCESS, ISSUE ERROR, ISSUE ABEND, and ISSUE SIGNAL commands, DFHETL:
For SEND and CONVERSE commands, DFHETL:
For RECEIVE commands, DFHETL:
For WAIT commands, DFHETL calls DFHZARL.
For FREE commands, DFHETL:
DFHZARL is always invoked via the DFHLUC macro. The DFHLUCDS DSECT maps a parameter list that is set up to pass information to and return information from DFHZARL. DFHZARL manages data in buffers, not in TIOAs. SEND commands cause data to be assembled by DFHZARL into a buffer until a WAIT, or other event, causes the data in the buffer to be transmitted.
DFHZARL invokes DFHZSDL to send data to VTAM®, by placing requests on the activate chain. However, for optimization, DFHZARL can invoke DFHZSDL directly. Receive requests are handled by DFHZARR.
DFHZARL invokes DFHZUSR to manage the conversation state. The LU6.2 states for each session are stored in the TCTTE for that session.
If the request needs to be transaction routed, DFHZARL calls DFHZXRL to route the request to the terminal-owning region (see Transaction routing).
Details of DFHZARL’s processing for the principal functions of the DFHLUC macro that is used to invoke DFHZARL are given below.
This function is requested by DFHZSUP. DFHZARL acquires LU6.2 send and receive buffers. If the transaction is being started as a result of an ATTACH request received from a remote system, DFHZARL transfers any data received with the attach header from the TIOA into the receive buffer.
DFHZARL performs the following actions:
DFHZARL performs the following actions:
The caller must specify WAIT in the request to force the data to be sent immediately. SEND CONFIRM has an implicit WAIT, and control is not returned until a response has been received, when the state machine is set.
For a SEND request with WAIT, DFHZARL then:
For a SEND request without WAIT, DFHZARL then:
If data or a CONFIRM command was sent (or both), DFHZARL then:
When an implicit send is required, DFHZARL passes the data to DFHZSDL for transmission, passing the address of the data in the send buffer and in the application buffer. The total length of data passed to DFHZSDL is a multiple of the request unit size. On return to DFHZARL, the remaining data is transferred to the send buffer. The parameters passed to DFHZARL, such as INVITE and LAST, are not transmitted by DFHZSDL.
DFHZARL passes the DFHLUC parameter list, specifying the type of receive required, to DFHZARR for processing (see DFHZARR).
DFHZARL is called as a result of an ISSUE ERROR or ISSUE ABEND command, and performs the following actions:
DFHETL may invoke DFHZARM to provide service functions. DFHZARQ passes control to DFHZARM instead of initiating DFHZSDS, DFHZRVS, and so on, if DFHZARQ finds that it is an LU6.2 session. This applies to the SEND, WAIT, RECEIVE, and SIGNAL commands. The same applies to DFHZISP for the FREE command.
DFHZARM translates the data stream to and from a format suitable for invoking DFHZARL. In particular:
DFHZARM is invoked via the DFHLUCM macro, which has seven executable options:
DFHLUCM TYPE=STORAGE defines the storage in LIFO for passing primary input and output. The DSECT name is DFHLUMDS. TCTTE contains the secondary input and output. The principal functions are described in the following topics.
DFHZARM performs the following actions:
DFHZARM performs the following actions:
The FREE function is used, for example, by DFHZISP to ensure that I/O has completed and CEB sent, using null data if necessary.
The INVALID_ID function is used by DFHETL and DFHZARM itself. It handles the receipt of unrecognized or unsupported IDs. DFHZARM calls DFHZARL with ISSUE_ERROR (X'0889010x'), and sends a record with ID X'12F4' followed by the unrecognized ID. If the remote system responds, DFHZARM turns the flows around so that the local system can try again.
An LU6.1 chain corresponds to one SEND command. LU6.2 chains are bigger, so:
DFHETC routes SEND, WAIT, CONVERSE, and some RECEIVE commands to DFHZARQ. RECEIVE commands are passed to DFHZARQ if input journaling is in effect. Otherwise, the call is routed to DFHZARL directly.
DFHZARQ passes control to DFHZARM instead of initiating DFHZSDS, DFHZRVS, and so on, if DFHZARQ finds that it is an LU6.2 session. This applies to the SEND, WAIT, RECEIVE, and SIGNAL commands.
Reasons for calling DFHZARQ are:
DFHZARR is called by DFHZARL to handle receive requests. Details of the processing follow.
This function must be able to handle receipt of the following:
Figure 38 gives an overview of the modules involved with the processing of receive requests. These modules are described in CICS executable modules.
DFHZARL passes the DFHLUC parameter list, specifying the type of receive required, to DFHZARR.
DFHZARR then performs the following actions:
The results of the receive are passed back to the caller in the DFHLUC parameter list.
To control this processing, DFHZARR uses the variables receive_type and what_next, as follows.
receive_type can have the following values:
The first two values are possible initial values of receive_type, and the other four are used as the receive progresses.
what_next is an output of DFHZARRC, and represents what is next to be processed. It can have the following values:
DFHZERH is called by DFHZARL or DFHZARRF, when it is required to transmit error information or when error information has been received.
For outbound errors, DFHZERH is invoked by DFHZARL following an ISSUE_ERROR, ISSUE_ABEND, or SYNC_ROLLBACK request.
An FMH7 must be transmitted, but can only be transmitted if the session is in the send state.
If the session is in the receive state, DFHZERH:
In all cases, DFHZERH then:
For inbound errors, DFHZERH is invoked by DFHZARL or DFHZARRF when a process-level exception response or an FMH7 has been received.
If an exception response is received while in the send state, DFHZERH purges the present output buffer and sends ‘LIC,CD,RQE1’ to put the conversation into receive state--so that the following FMH7 can be received.
If an FMH7 is received, DFHZERH examines the associated sense code and any GDS error log data, then returns to its caller.
DFHZISP is called by DFHETC to perform ALLOCATE_TC requests. (ALLOCATE commands are passed to DFHZISP because DFHETC cannot check the session type until the session is allocated.)
DFHZISP is also called to perform FREE_TC requests.
DFHZSTAP provides a means of determining the conversation state of an MRO or LU6.2 session from the application side. This function is required if the application issues an EXEC CICS® EXTRACT ATTRIBUTES command with the STATE option, or a conversation-based command with the STATE option.
For MRO, modules that invoke MVS™ services via the DFHTC macro also update the conversation state information with a DFHZCNVM TYPE=PUT macro call. When an application requires the conversation state of a session, DFHETC calls DFHZSTAP using a DFHZSTAM TYPE=GETCURRSTATE macro, which returns a value representing the conversation state of the session.
For LU6.2, DFHZUSR is called to maintain the user conversation state machine. (See VTAM LU6.2 for further details.) When an application requires the conversation state of a session, DFHETL (mapped) or DFHEGL (unmapped) calls DFHZSTAP using a DFHZSTAM TYPE=GETCURRSTATE macro. DFHZSTAP examines the DFHZUSR state machine and maps the information into a value representing the conversation state of the session.
[[ Contents Previous Page | Next Page Index ]]