This section describes how to get a conversation started. The first two subsections explain how the front-end transaction and the back-end transaction initiate the conversation, and the final subsection discusses conversation initiation failure.
The front-end transaction is responsible for acquiring a session, specifying the conversation characteristics, and requesting the startup of the back-end transaction in the partner system.
Initially, there is no conversation, and therefore no conversation state. The front-end transaction acquires a session to start a new conversation by issuing an ALLOCATE command.
The RESP value should be checked to ensure that a session has been allocated. If successful, the RESP value is DFHRESP(NORMAL), the conversation is in allocated state (state 1) and the session identifier (convid) from EIBRSRCE must be saved immediately. The convid must be used in subsequent commands for this conversation.
If the front-end transaction is started by ATI in the local system, and is required to hold a conversation with an LUTYPE6.1 session as its principal facility, the session has already been allocated when the transaction starts. You can omit the SESSION option from commands relating to the principal facility. If, however, you want to name the session explicitly in these commands, you should obtain its name from EIBTRMID.
When a session has been acquired, the next step is to cause the partner transaction to be initiated. The state table shows that, in allocated state (state 1), one of the commands available is SEND. Using this command, the back-end transaction identifiers can be specified in the first four bytes of the data which, when transferred to the partner system, will attach the required back-end transaction. The send buffer containing the transaction name together with any other data, will be flushed immediately and the front-end transaction will wait until a response is received from the back-end transaction.
Alternatively, when a session has been acquired, the front-end transaction can build and send an attach header with the first transmission of data. The attach header can be built using the BUILD ATTACH command.
When using the BUILD ATTACH command, you must give a name to the built attach header which can then be used in the ATTACHID option of the first SEND (or converse) command. The back-end transaction name should also be specified.
The back-end transaction is initiated either by an attach header received from the partner system or by a transaction name 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 improves program readability and problem determination.
A CICS® transaction can be the back-end transaction in CICS-to-IMS™ communication only in the special case of SEND/RECEIVE asynchronous processing. The transaction is initiated by an LUTYPE6.1 attach FMH received from the remote IMS system, and is allowed to issue a single RECEIVE command only, possibly followed by an EXTRACT ATTACH command.
It is possible that the back-end transaction may fail to start up. This will result in the front-end transaction abending.
[[ Contents Previous Page | Next Page Index ]]