Modules

DFHEGL

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.

DFHETC and DFHETL

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:

  1. Maps an application request into a form suitable for the DFHZCP and DFHZCC application request modules. This includes mapping application data into GDS records.
  2. Detects errors and returns error codes to the application.
  3. Unmaps data from GDS records.
  4. Maintains state indicators.

For ISSUE CONFIRMATION, CONNECT PROCESS, EXTRACT PROCESS, ISSUE ERROR, ISSUE ABEND, and ISSUE SIGNAL commands, DFHETL:

  1. Maps application requests into DFHLUC macro calls.
  2. Updates state indicators in the TCTTE (for example, the TCTTE indicator that shows that a CONNECT PROCESS command has been issued).

For SEND and CONVERSE commands, DFHETL:

  1. Obtains storage for the processing of outbound application data.
  2. Creates attach FMHs, if appropriate.
  3. Calls DFHZARL to transmit data.

For RECEIVE commands, DFHETL:

  1. Obtains storage for the processing of inbound data.
  2. Calls DFHZARL to receive inbound data.
  3. Extracts inbound FMHs, as appropriate.
  4. Unmaps inbound data.
  5. Validates LLs and rejects them if not valid.
  6. Manages the passing of data back to the application.
  7. If the application issues a RECEIVE NOTRUNCATE request in order to receive only part of the chain, retains the residual data for subsequent RECEIVE requests. DFHETL receives one complete chain of data at a time from DFHZARL.

For WAIT commands, DFHETL calls DFHZARL.

For FREE commands, DFHETL:

  1. Checks that the terminal is in the correct state to be freed.
  2. Frees the storage used to hold RECEIVE data and the ETCB.
  3. Calls DFHZISP to free the session.

DFHZARL

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.

INITIAL_CALL function

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.

ALLOCATE function

DFHZARL performs the following actions:

  1. If the request passed the address of a profile entry, puts this address in the TCA. If the request passed the name of a profile, calls transaction manager to locate the entry and then puts the address of the entry in the TCA.
  2. If the request passed a netname rather than a specific sysid, calls DFHZLOC to locate the TCTTE for the netname and then puts the sysid into the DFHLUC parameter list (as if the caller had the specified sysid).
  3. Copies the DFHLUC parameter list to LIFO storage.
  4. Calls DFHZISP to allocate a TCTTE.
  5. Addresses the TCTTE allocated.
  6. Acquires LU6.2 send and receive buffers.
  7. Sets the user state machine (DFHZUSRM), request = ALLOCATE_RESOURCE.
  8. Returns results to the caller.

SEND function

DFHZARL performs the following actions:

  1. Checks the user state machine (DFHZUSRM).
  2. Checks the LL count and maintains a record of the outstanding LL count.
  3. If the command is SEND LAST, INVITE, or CONFIRM, and the outstanding LL count is nonzero, issues an error message.
  4. Sets the user state machine (DFHZUSRM).
  5. Issues RECEIVE IMMEDIATE requests, as required, to pick up any negative responses sent by the partner program.

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:

  1. Sets the user state machine (DFHZUSRM), request=WAIT.
  2. Invokes DFHZSDL for transmission of the data in application area or send buffer.

For a SEND request without WAIT, DFHZARL then:

  1. If there is sufficient space in the send buffer for all the data, transfers the data from the application area to the send buffer, and returns control to the caller.
  2. Saves the INVITE and LAST indicators.
  3. If the send buffer cannot hold all the data, invokes DFHZSDL for an implicit SEND.

If data or a CONFIRM command was sent (or both), DFHZARL then:

  1. Checks for a signal received.
  2. Checks for exception (negative) response received. If found, calls DFHZERH to handle the error. On return, sets the state machine.
  3. Returns results to the caller.

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.

RECEIVE function

DFHZARL passes the DFHLUC parameter list, specifying the type of receive required, to DFHZARR for processing (see DFHZARR).

ISSUE ERROR or ABEND function

DFHZARL is called as a result of an ISSUE ERROR or ISSUE ABEND command, and performs the following actions:

  1. Sets the user state machine
  2. Calls DFHZERH.

DFHZARM

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.

SEND function

DFHZARM performs the following actions:

  1. Maps the data into GDS record format. The IDs used are:
  2. Examines bits set in the TCTTE by DFHZARL to determine which DFC to apply.
  3. Invokes DFHZARL (using a DFHLUC TYPE=SEND,LIST=... macro call) to pass the GDS records and DFC indicators.
  4. Updates the state bits in TCTTE as necessary.
  5. Interrogates the LU6.2 ATTACH_FMH_BUILT bit in the TCTTE, which was set by DFHZSUP or DFHETL. This bit indicates whether this is first SEND. If an LU6.2 attach header has not already been built as a result of a CONNECT PROCESS command, DFHZARM issues CONNECT_PROCESS to DFHZARL, assuming synclevel 2, before sending the data.

RECEIVE function

DFHZARM performs the following actions:

  1. Calls DFHZARL using TYPE=BUFFER. Two calls are made. On the first call, the first 4 bytes (LLID) are retrieved into LIFO. These are examined and the LL is used to determine the TIOA size and to specify the length required in the second call.
  2. On the second call, retrieves the remainder of the data directly into the TIOA. If the LL indicates concatenated data, a series of calls is made to retrieve all the data.

FREE function

The FREE function is used, for example, by DFHZISP to ensure that I/O has completed and CEB sent, using null data if necessary.

INVALID_ID function

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.

LU6.1 chains

An LU6.1 chain corresponds to one SEND command. LU6.2 chains are bigger, so:

DFHZARQ

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

DFHZARR is called by DFHZARL to handle receive requests. Details of the processing follow.

RECEIVE function

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.

Figure 38. Distributed transaction processing of LU6.2 receive requests
 This figure illustrates the modules in distributed transaction processing for LU6.2 receive requests, which are described in the text.

DFHZARL passes the DFHLUC parameter list, specifying the type of receive required, to DFHZARR.

DFHZARR then performs the following actions:

  1. Checks that request is valid; if not, returns error codes.
  2. Initializes the application and LU6.2 receive buffers (by calls to DFHZARRA and the DFHZARR0 subroutine of DFHZARR respectively).
  3. Calls DFHZARRC to determine what to process next.
  4. Depending on DFHZARRC’s response, calls the relevant subroutine.
  5. If "enough" (or all that can be) has not been received, loops back to step 3; otherwise step 6.
  6. Tests for (and returns) signal when it has been received.

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:

RECEIVE_WAIT
Request was a receive and wait.
RECEIVE_IMMEDIATE
Request was a receive immediate.
LOOK_AHEAD
All the allowed user data has been received, but only one receive immediate call to the DFHZARR1 subroutine of DFHZARR is permitted to attempt to pick up indicators such as CD, CEB, or a PS_header.
NO_MORE_RECEIVES
No more calls to DFHZARR1 are permitted, but processing may continue with what has already been received.
NO_RECEIVE_LOOK_AHEAD
All the allowed user data has been received. An attempt must be made to pick up indicators such as CD, CEB, or a PS_header without a call to DFHZARR1. This value is only required for a receive immediate request.
RECEIVE_COMPLETE
Receive processing is finished.

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:

DATA_RECORD
Application data
FMH_RECORD
FMH7 in the buffer
PS_HEADER_RECORD
Prepare or Request_commit
PARTIAL_LL
First byte of a logical record only, therefore cannot tell whether it is a DATA_RECORD or PS_HEADER_RECORD
CD
Change Direction
CEB
Conditional End Bracket
RQD2
RQD2 without CD or CEB
RQD2_CD
RQD2 with CD
RQD2_CEB
RQD2 with CEB
ER1
Negative response
EMPTY_BUFFER
Nothing available to receive.

DFHZERH

DFHZERH is called by DFHZARL or DFHZARRF, when it is required to transmit error information or when error information has been received.

Outbound errors

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:

  1. Sends a negative response
  2. Purges the remaining data to end of chain.

In all cases, DFHZERH then:

  1. Checks that the session is still in bracket
  2. Clears the send buffers
  3. Calls DFHZARL to send the FMH7.

Inbound errors

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

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

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