gtps2m0v | ACF/SNA Data Communications Reference |
TPFs' host node support allows TPF applications to communicate with IMS and CICS applications. One of the uses of this support is to enable SNA or non-SNA (EP) terminals to access IMS or CICS databases. This is performed by writing a TPF application that forwards terminal requests to, IMS for example. When IMS subsequently replies, the TPF application will forward the reply to the originating terminal. Normally, the TPF application reformats the data stream from the terminal to one acceptable to IMS and conversely reformats the IBM reply to a form appropriate to the terminal.
Because TPFs host node support requires the message recovery package, a key consideration for writing TPF host node applications is the operation of the system recovery table (SRT). The SRT is used to track each message from its receipt by TPF until the corresponding reply is successfully returned. For example, assume a TPF application that will forward all terminal input to IMS and subsequently return all IMS replies to the terminal.
In this example, an SRT entry will be made to record the receipt of each input message from the terminal. In addition, if the terminal and TPF application were defined as recoverable, a safe store copy of the input will be created in pool records on DASD. The SRT entry is active until the TPF application signals a Release Input to indicate that the entry was successfully processed. To signal a Release Input, the TPF application must issue a ROUTC macro with the RCPL2REL bit set in the RCPLCTL2 field of the routing control parameter list (RCPL). If the TPF application fails to signal Release Input in a user-defined time limit, TPF will consider the original input lost and resubmit a copy of the message to the application.
Therefore, a TPF application relaying messages between a terminal and IMS has several choices of when to signal Release Input. For example, the application can do any of the following:
The reader should understand that the decision to either unlock or leave locked the terminals keyboard is left to the application. Leaving the keyboard locked until the IMS reply is delivered prevents the terminal from sending another message, but requires the application to unlock the terminal if the IMS reply is not returned. Conversely, unlocking the keyboard before sending the IMS reply can make the correlation of the IMS reply to the original input difficult.
When the reply is received from IMS, the TPF application must indicate receipt of the message by sending a null RU via a ROUTC to IMS. This will cause the system to delete the SRT slot for the message from IMS (which is recoverable) and send a definite response to IMS. The TPF application must also send a message to the originating terminal. Because the TPF application will EXIT after sending the initial message to IMS and then be reactivated on the receipt of the reply message from IMS, it must remember the originating terminal. This can be done upon agreement of the interface between TPF and the IMS application that the RCPL be passed as part of the data stream and returned intact.
The null RU can also be used when an input message is resubmitted to the application because of a time-out when no reply is received to a recoverable input message. The application, if it decides that no more processing is required, can simply cause the SRT slot to be released and a response sent to the terminal by sending a null RU. The null RU in this case and the response to IMS described previously consists of an RCPL with the Release Input present and Function Management Header set, and the first byte of the message (AM0TXT) set to a X'00'.
The previous discussion assumes that both the TPF application and IMS have been defined to TPF as recoverable LUs so that message transmission between TPF and IMS is to be guaranteed. If either IMS or the TPF application were defined as non-recoverable, TPF will bypass the system overhead of ensuring messages are either successfully delivered or returned to the sender. Message recovery considerations (such as null RUs and SRT slots) still apply. The only difference is that TPF will not safe store messages on disk and will not request definite response for output messages.
RCPL control byte 2 (RCPLCTL2) also allows the application programmer to control transmission protocol on the Host Node LU session. If both session partners are defined as being recoverable, a half duplex flip-flop protocol is used by indicating Change Direction in the RCPL (RCPL2CD). If the SLU threads that are to be used for the Host Node LU session are defined as non-recoverable, a contention mode protocol may be used by indicating End Brackets in the RCPL (RCPL2EBK). Defining the SLU threads as non-recoverable allows the SLU to send End Brackets, which is necessary for full contention mode support. Change Direction and End Bracket are mutually exclusive and if both are indicated, End Bracket will be assumed. If End Bracket is indicated and the SLU threads are defined as being recoverable, half-duplex protocols are enforced.
In the previous examples, IMS was used, but the discussion is also applicable to CICS.
TPF's support of IMS uses the type P SLU support present in IMS.
The TPF application appears to IMS as a type P SLU. As such, all IMS conventions for this session type must be adhered to by TPF.
One such convention used by IMS is sending an unsolicited IMS error message (DFSxxxx) immediately following an IMS exception DR1/DR2 to input (-RSP). For example0: IMS will send a -RSP to input with system/user sense code 08260041 if the IMS transaction is stopped. IMS expects to remain in send state regardless of the current bracket state. IMS will then send the complete error message: DFS0065 TRAN/LTERM STOPPED (the hex '41' becomes the decimal 65 of the error message). TPF system code will stop output message transmission (OMT) on receiving the -RSP and pass both the -RSP and the following IMS error message to the TPF application. The TPF application must ROUTC a null RU to notify TPF to restart OMT. The null RU for this case is defined as:
TPF will function in this manner for system sense codes 0800, 0819, and 0826.
TPF support of CICS uses the 3790 Full Function LU support in CICS. The TPF application appears to CICS as a 3790. As such, all CICS conventions for this session type must be adhered to by TPF.