CICS to IMS using the START/RETRIEVE EXEC commands
CICS® uses START/RETRIEVE commands to process IMS nonresponse mode and nonconversational transactions, message switches, and the /DISPLAY, /RDISPLAY, and /FORMAT commands.
The general CICS application program flow for an asynchronous message from CICS to IMS is shown in the following figure.
After the input message is received from the terminal, the transaction is assembled using the START command. The values to be contained in the ATTACH and SCHEDULER function management header DPN, PRN, RDPN, and RPRN fields are specified as parameters on the START command. The DPN and PRN are used by IMS to determine the editing process to be initiated and the destination of the incoming message. The RDPN and RPRN are used to identify the CICS terminal and transaction to which the reply is to be returned. The START command must also specify NOCHECK if this is an IMS nonrecoverable transaction, and NOCHECK PROTECT if this is an IMS recoverable transaction. (PROTECT can optionally be used for nonrecoverable transactions.)
NOCHECK is a mandatory parameter for an ISC session with IMS. In a CICS-CICS ISC session, the use of START causes a return code reply to be sent to the initiating CICS from the receiving CICS. This return code indicates that the receiving CICS has scheduled the transaction to be executed as a result of the message it has received. This return code does not occur on an IMS-CICS session. NOCHECK informs the sending CICS that no such response is to be expected. START NOCHECK creates a message carrying BB/EB RQE1.
PROTECT, specified for recoverable transactions, delays the sending of the transaction on the session until CICS successfully takes a SYNCPOINT. Specifying START causes begin- and end-bracket (BB/EB) and the ATTACH and SCHEDULER function management headers to be appended to the outbound message. NOCHECK PROTECT requests a definite response (RQD2).
A SYNCPOINT command is now issued to append the appropriate sync point protocols and to send the message on the session. If this transaction elects to wait for a reply, it issues a RETRIEVE command. If this transaction does not choose to wait for a reply, it can terminate by issuing RETURN following either the START command or the SYNCPOINT command. The CICS mirror transaction schedules a new instance of this transaction when a reply is received.
If the transaction chooses to wait for the reply, it can issue RETRIEVE with
or without the WAIT parameter. Issuing RETRIEVE without
the WAIT parameter causes CICS to check for any queued asynchronous input
for this transaction and terminal. If such input is immediately available,
it satisfies the RETRIEVE command. If no such input
is immediately available, an appropriate indication is returned to
the RETRIEVE command, and the application can then
perform other processing or issue RETURN to terminate.
If RETRIEVE WAIT is issued, CICS does not return control to the application program until an asynchronous message is sent from IMS destined for this transaction and this terminal. Using WAIT causes the terminal be held until an IMS reply is received for it.
In both cases (RETRIEVE with or without WAIT), when a message is sent from CICS to IMS requesting asynchronous processing, no assumptions can be made by the originating application as to the timing of the output reply or the availability of any other output. That is, if unsolicited asynchronous output is pending for CICS, this output can be sent to CICS before the reply to this asynchronous transaction is returned. Therefore, requests and replies are not correlated within CICS in an asynchronous environment. Issuing RETRIEVE obtains any reply from IMS on any session that has the indicated transaction and terminal identification.