z/OS Communications Server: SNA Programming
Previous topic | Next topic | Contents | Contact z/OS | Library | PDF


Logic of the 3600 finance communication system I/O routine

z/OS Communications Server: SNA Programming
SC27-3674-00

This routine is entered directly or indirectly (perhaps from a common I/O branching routine in the mainline program) as the result of a request for input from a specific terminal with which a processor is currently engaged in a transaction.

Figure 1. Logic of the 3600 I/O routine
The diagram shows the logic of the 3600 finance communication system I/O routine with numbers referring to additional notes that explain the details.
Figure 1 shows the logic of the 3600 I/O routines. The following notes are keyed to this figure.
1
If the processor's request is for input, the information that must be passed to VTAM® is set up and a RECEIVE is issued. The address of the session's RPL is put in a register and the address of the input area associated with the session and the length of the area are put in other registers. Because data is to be read, RTYPE=DFSYN is specified. The operation is to be asynchronous and input is to be read only from the specific session (whose CID is located in the RPL's ARG field). The ECB associated with the session is specified for posting by VTAM when the operation is completed. After issuing the RECEIVE request, register 15 contains 0 if the request is accepted, or some other return code if it is not. If the request is accepted, the wait routine is returned to, after setting the next sequential instruction in this routine as the address to be branched to when the ECB is posted.
Note: For simplicity, most checks of register 15 are not shown in sample program 2.
2
When data is received from the LU, VTAM posts the ECB associated with the RECEIVE RPL. When the wait routine discovers the posted ECB, it branches to the indicated location in the 3600 I/O routine. The RESPOND field of the RPL can be tested to determine whether the LU wants a definite response returned to verify that the input was received. If so, a SEND is issued, indicating that a response is to be sent to the LU (STYPE=RESP).

The SEND that sends the response, if requested, is scheduled synchronously. VTAM assumes POST=SCHED. Because no response can be returned to a response, once the request to send the response is accepted, the VTAM application program considers the sending of the response as complete.

If input arrives unsuccessfully or out of sequence (indicating that some input was lost), VTAM completes the VTAM application program's input request with an indication that a negative response must be returned; no input is forwarded to the program. The application program sends the negative response. The input request can be reissued.

Although not shown, the VTAM application program can also return a negative response to input that is successfully received. This might be done when initial processing indicates an error in the format of the received input. Such a response is understood by both the application program and the LU. The SSENSEO, SSENSMO, and USENSEO fields of the RPL can be used to convey exception information.

3
If the input contains a request to log off, the session is ended by issuing a CLSDST macroinstruction, and the control blocks associated with the session are returned to the system or to a pool. Optionally, a request can be sent to the LU, confirming logoff, prior to issuing CLSDST.

The preceding description of the 3600 input routine assumes that a CHECK macroinstruction is issued in the wait routine upon completion of each requested input operation; if an error occurs, CHECK causes entry to the LERAD or SYNAD exit routine which takes appropriate action. This can include sending the negative response for step 2. The input routine can issue a request to receive any kind of input: a normal-flow data request or data-flow-control request (DFSYN), an expedited-flow data-flow-control request (DFASY), or a response (RESP). In this sample program, DFASY and RESP-type input are handled by VTAM-scheduled DFASY and RESP exit routines, but the logic in these routines could have been branched to after determining in the wait routine or 3600 input routine that DFASY or RESP information had been received. DFSYN means that either data or normal-flow data-flow-control requests can be received; although not shown in this example, normal-flow data-flow-control requests such as Quiesce Complete (QC) might be receivable in some applications, in which case such requests have to be responded to.

4
When an output request from a processor is received by the 3600 output routine, the routine does not process the request if the logical unit has quiesced the VTAM application program; instead, the I/O routine branches to the wait routine. The processor must wait until the quiesce is released at which time the ECB for the session is posted, a pending send request detected, and the routine is reentered. This logic is discussed in Logic of the DFASY exit routine of Sample Program 2.
5
If the output request is chained to other output requests, a branch is made to a chaining output routine (see Figure 1).
6
If output is not being chained, a SEND is issued that includes the operand CHAIN=ONLY. If the output completes a transaction, the session is returned to continue-any mode; its next input satisfies the RECEIVE OPTCD=ANY request issued in RPL1. The request can specify scheduling of the operation (POST=SCHED) with completion to be determined as the result of a positive or negative response (RESPOND=NEX) that causes scheduling of the RESP exit routine. (The RESP exit routine posts the ECB associated with the session, notifying the VTAM application program and the processor that the output request was completed.) The output routine then branches to the wait routine.

Go to the previous page Go to the next page




Copyright IBM Corporation 1990, 2014