Mainline program

The request input area, AREA1, is initialized to asterisks to aid in debugging. The request length as well as the contents are evident if asterisks (rather than blanks) are printed when the request is presented to the terminal operator who is driving the program. (Other printable non-alphabetic characters could have been used as well.)

After the RECEIVE is completed, a CHECK is issued. If an error or special condition has occurred, the LERAD or SYNAD exit routine is entered. If the exit routine is able to recover successfully, it sets register 15 to 0; the mainline program is unaware that the exit routine was entered. If the exit routine is not able to recover successfully, it terminates the session with the LU or performs a SESSIONC CONTROL=CLEAR and a SESSIONC CONTROL=SDT, and sets register 15 to nonzero. The mainline program continues with other input, looping back to reissue the RECEIVE.

The RECEIVE can be completed by receipt of an expedited-flow (DFASY) or normal-flow (DFSYN) request. For example, receipt of Request Shutdown (or any other DFASY request) causes SAMP1 to issue CLSDST for that LU before reissuing the RECEIVE.

A check is made to see whether a simulated exception request has arrived; if so, a deliberate negative response must be returned. If a real exception request were to be received (requiring a negative response), the SYNAD exit routine would be scheduled as a result of the CHECK. In this case, the SYNAD exit routine would send a negative response and possibly use the SESSIONC macroinstruction to clear data traffic, reset the session to CA mode, and set an unsuccessful recovery indication in register 15 to allow the mainline program to reissue its RECEIVE.

Responses: SAMP1 is intended to handle all the valid combinations of no responses, exception response only, and definite responses. When instructed to echo the data (B'xxxx x1xx' in the first byte of the data header), it leaves the response types (RESPOND=values) unchanged, making it possible to force SAMP1 to send a request to the LU asking for no response or exception response only. In such a case, SAMP1 makes sure that the LU's session is in continue-any mode on completion of SEND rather than on receipt of a response by the RESP exit routine. When SAMP1 asks for a definite response, it leaves the LU's session in continue-specific mode until that response is processed by the exit routine. The next request (or requests) might be queued in VTAM's pageable buffers, but is ignored until the response has been handled.

Function management and data-flow-control protocols: SAMP1 does not modify the settings related to FM protocols in the RPLs, except when requested to send an exception response. This means that fields like FMHDR, CHAIN, BRACKET, CODESEL, and CHNGDIR are echoed back to the LU, ignoring the fact that this can be a protocol violation. In addition, SAMP1 processes (for example, by echoing) each chain request separately.

Ending the program: Two ways exist to end the program. Either a request can be sent from the LU that says, “CLOSE ACB,” or the VTAM® operator can halt VTAM, causing the TPEND exit routine to be driven. In the first case, a TPEND flag is set; in the second, a TPEND ECB is posted. The mainline program checks both of these during each of its loops, branching to close the ACB if a close indication is found. Prior to closing the ACB, the TPEND flag is set to X'FF' to prevent any undesired activity while the CLOSE macroinstruction is being executed by VTAM. The TPEND flag is checked by the LOGON, RESP, and LOSTERM exit routines when each is entered to make sure the exit routine has not been scheduled while closing the ACB is in progress. If the flag is set, the exit routine returns immediately to VTAM.