Back-end transaction initiation

The back-end transaction is initiated either by an attach header received from the partner system or by a transaction identifier included in the incoming data, and is started with the session as its principal facility.

Initially, the back-end transaction should determine the convid from EIBTRMID. This is not strictly necessary because the session is the back-end transaction’s principal facility making the CONVID parameter optional for DTP commands on this conversation. However, the convid is very useful for audit trails. Also, if the back-end transaction is involved in more than one conversation, then always specifying the convid will improve program readability and problem determination. Figure 1 shows a back-end transaction that does obtain the convid.

When the back-end transaction receives data, the presence of an attach header is indicated by either EIBATT or RESP(INBFMH). One of these is normally set after the back-end transaction issues its first RECEIVE command. The EXTRACT ATTACH command can be used to access session-related information from the attach header (for example, the back-end transaction identifier) if required, but it is not mandatory.

Figure 1. Startup of a back-end MRO transaction

 * ...
DATA DIVISION.
WORKING-STORAGE SECTION.
* ...
01 FILLER.
02 WS-CONVID PIC X(4).
02 WS-STATE PIC S9(7) COMP.
* ...
01 FILLER.
02 WS-RECORD PIC X(100).
02 WS-MAX-LEN PIC S9(5) COMP VALUE +100.
02 WS-RCVD-LEN PIC S9(5) COMP VALUE +0.
* ...
PROCEDURE DIVISION.
* ...
EXEC CICS ASSIGN FACILITY(WS-CONVID) END-EXEC.
* ...
* Receive data from the front-end transaction.
*
EXEC CICS RECEIVE CONVID(WS-CONVID) STATE(WS-STATE)
INTO(WS-RECORD) MAXLENGTH(WS-MAX-LEN)
NOTRUNCATE LENGTH(WS-RCVD-LEN)
END-EXEC.
*
* ... Check outcome of RECEIVE.
* ...

It is possible that the back-end transaction may fail to start. This will result in the front-end transaction abending. When this happens, message DFHIR3783 contains the reason for the error.