gtps2m4hACF/SNA Data Communications Reference

TPF X.25 Command Message Flows

In this section, the handling of the NPSI protocols involved in the establishment, acceptance, and discontinuance of switched virtual circuits using NPSI/GATE with the Fast Connect (FC) feature is discussed in the context of a CTCP written by you.

The TPF X.25 support provides a means of establishing switched (dial-up) connections between TPF applications and resources accessed via a PSDN. TPF's SNA support, augmented by the SNA Session Awareness routines provided by you (see "TPF SNA Session Awareness" in this section, and "Session Status Awareness Services"), handles the SNA interfaces, both to the VTAM SSCP and the NPSI LUs, necessary to setup and takedown LU-LU sessions required for the connections.

While the SNA connection is transparent to the TPF application, you are required to supply code to manage the underlying NPSI interface protocols required to setup and takedown switched calls.

The following examples are covered:

Before your CTCP can respond to NPSI/GATE in these examples, you must take such actions as reflecting in your control blocks the changing status of the Virtual Circuits underlying the call.

In the following sections, the CTCP is assumed to be defined via a MSGRTA statement as a TPF application named CTCP. TPF creates an associated RVT definition of a TPF Primary LU resource named CTCP. The CTCP functions are handled by a PSV routine (one or more ECB controlled programs) named GATE1. GATE1 is specified as the PSV on the OSTG RSC statement for each NPSI LU (both MCH_LU and VC_LU) defined to TPF that are in session with the CTCP PLU. It is further assumed that the sessions between the CTCP and the NPSI LU resources (both MCH_LU and necessary VC_LU resources) have been established before any NPSI command flows.

Note:
For the discussed X.25 command flows, the command data received is never presented to a TPF application, but all processing for the command occurs within the GATE1 PSV.

PSV Processing of NPSI/GATE Commands

When the CTCP to NPSI/GATE LU-LU session has been established for a VC_LU, all data transmitted across the session is intercepted and given to the PSV routine associated with the VC_LU; in this case the PSV routine is named GATE1. Whether processing inbound or outbound traffic, the GATE1 PSV routine must perform the CTCP functions associated with the message type (NPSI/GATE command versus data). Examples of the CTCP functions performed by the GATE1 PSV routine are:

(See Queue Manager for additional information.)

Figure 108 shows a generic flow of X.25 commands received from the network processed by the GATE1 PSV on behalf of the CTCP. Figure 111 shows a generic flow of X.25 commands initiated by a TPF application/CTCP handled by the GATE1 PSV on behalf of the CTCP destined for the network.

Figure 107. Control Block Relationship for Inbound CALL_REQUEST Command




CALL_REQUEST Command received from NPSI/GATE

See Figure 107 and Figure 108 for this scenario.

As shown in the first 3 flow items of Figure 108, upon receipt of a PIU from the NPSI/GATE VC_LU, TPF presents this to the GATE1 PSV using the standard TPF API (RCPL and message block). The first character in each message identifies it as a NPSI/GATE command or a data message. Upon finding a command indication, GATE1 further examines the text of the command to determine that it has just received a CALL_REQUEST. This is the dial-in situation and the CTCP (GATE1 PSV) must validate the caller and connect the required control block structure in TPF to allow data messages to flow to the application.

Using the RID in the RCPL associated with the CALL_REQUEST, the PSV routine GATE1 indexes to the associated Virtual Circuit Control Block (VCCB). From the VCCB, the X.25 network ID is obtained and the X.25 Network Control Block (XNCB) for the network is accessed. The ordinal number of the first fixed file record for the X.25 Network Contact List (XNCL) is obtained for the list of valid callers to be searched to insure that this caller is authorized. When a match is found and the caller has been validated, the contact information <ci> for this caller is obtained from the CPCB on file. This information identifies the terminal controller and is appended to the Virtual Circuit Control Block (VCCB), thus making the connection between the NPSI/GATE virtual circuit and the terminals available through the contact point for this call.

Finally, GATE1 (refer to Figure 108 flow items number 4 and 5):

Figure 108. Generic TPF Inbound X.25 CTCP Command/Reply Flow




CLEAR Command Received from NPSI/GATE

The remote contact point (terminal controller) can send an X.25 clear request when the connection to the host is to be broken. NPSI/GATE sends a CLEAR command to the CTCP when it has completed its handling of the clear request from the X.25 interface. Again assuming GATE/FC, the NPSI/GATE CLEAR command arrives over the same virtual circuit as normal data messages.

See Figure 108 and Figure 109 for this scenario.

Figure 109. Control Block Relationship for Inbound CLEAR Command




As shown in first 3 flow items of Figure 108, upon receipt of a PIU from the VC_LU destined for the CTCP, TPF presents this to the GATE1 PSV using the standard TPF API (RCPL and message block). The inbound GATE1 PSV routine recognizes that this is a NPSI/GATE CLEAR command and the process shown in Figure 109 begins. The RID of the NPSI/GATE VC_LU, passed by TPF in the RCPL, is used to find the Virtual Circuit Control Block (VCCB). The contact information <ci> appended to the Virtual Circuit Control Block (VCCB<ci>) is saved before resetting (clearing) the <ci> to break the relationship with the VCCB that was established during call in processing. The VCCB is then marked as available to the chain of virtual circuits in the X.25 Link Control Block (XLCB) for this X.25 link.

Next, each end point on this contact point must be handled. For each End Point Control Block (EPCB) in the <ci> chain, the EPCB field containing the VC_LU RID is cleared, thus breaking the application/end point connection across the X.25 network.

GATE1 PSV then terminates the CLEAR command ECB (EXITC).

TPF Initiated Call Out Using CALL_REQUEST Command to NPSI/GATE

Your CTCP can initiate a call out process when there is a need to communicate with a disconnected remote terminal controller. This might occur when there is:

These events trigger sending a CALL_REQUEST command to NPSI/GATE. Figure 110 and Figure 111 are references for this scenario.

Figure 110. Control Block Relationship for CALL_OUT Request




An application sends a message to a terminal via a ROUTC. Your ROUTC EXIT processing code determines that the LEID specified in the RCPL requires GATE1 PSV processing. See the TPF System Installation Support Reference for additional information about user exits. Your code returns to the TPF ROUTC processing, indicating that the message must be given to GATE1 for processing. TPF ROUTC removes the outbound message from the application's ECB and attaches it to a newly created ECB to be presented to the GATE1 PSV.

For this activation, your CTCP, implemented in the 'GATE1' PSV routine, uses the terminal's LEID specified in the RCPL to access the EPCB and determines that no call is currently active with the terminal. You activate the Queue Manager facility which places the message on the terminal's message queue and start your CTCP call out processing. (See Queue Manager for detailed information.)

Your CTCP call out processing uses the pointer in the EPCB to access the CPCB on DASD. From the CPCB, the call user ID of the controller (contact point) for this terminal is obtained and a NPSI/GATE CALL_REQUEST command can be constructed.

After the call user ID is obtained, the CTCP finds an idle X.25 virtual circuit using the X.25 Link Control Block chain for the network identified in the CPCB.

The contact information <ci> for this terminal controller is copied from the CPCB into the VCCB for the selected, available virtual circuit, and the VCCB is flagged as having a call out pending. All tables are set appropriately and the necessary information is extracted to build a NPSI/GATE CALL_REQUEST command. An outbound RCPL specifies the CTCP as origin and the RID of the VCCB is selected, as the destination is then constructed.

Finally, the GATE routine sets the BYPASS SEND INTERCEPT (CE1CPA X'40') indicator to bypass ROUTC EXIT activation for the ensuing ROUTC. GATE issues the ROUTC macro with the modified RCPL and message block to forward the CALL_REQUEST to the network.

Figure 111. Generic TPF Outbound X.25 CTCP Command Processing Flow




CALL_CONFIRM Command Received from NPSI/GATE

An inbound CALL_CONFIRM command is the normal response to an outbound CALL_REQUEST command. The CALL_CONFIRM shows that the remote controller has accepted the call and is now ready to receive data.

With GATE/Fast Connect, the CALL_CONFIRM comes in on the same VC_LU-to-CTCP session on which the CALL_REQUEST was sent. Figure 112 and Figure 108 are references for this scenario.

Figure 112. Control Block Relationship for Inbound CALL_CONFIRM Command




As shown in the first 3 flow items of Figure 108, upon receipt of a PIU from the VC_LU, TPF presents this message to the GATE1 PSV using the standard TPF API (RCPL and message block).

Upon determining that this is a CALL_CONFIRM command from NPSI/GATE, the following major actions are performed:

When the CALL_CONFIRM command from NPSI/GATE is passed to GATE1, the VCCB is located by using the RID provided by TPF in the RCPL. The virtual circuit (VCCB) is marked active and each terminal or end point activated. This process involves storing the RID for the virtual circuit in each EPCB associated with the contact point. As each end point EPCB is handled, its output pending indicator is interrogated and if on, GATE1 interacts with the Queue Manager facility to initiate sending queued output to each terminal via ROUTC. For more information, see Queue Manager.

Upon completion of initiating the output for each terminal, the GATE1 terminates the ECB (EXITC).

TPF Initiated CLEAR Command Sent to NPSI/GATE

The CTCP should end a call that it initiated when the virtual circuit is no longer needed. This might occur under the following circumstances:

These events trigger sending a CLEAR command to NPSI/GATE.

The linkage between the EPCBs and the VCCB should be deactivated in order that no further attempt to send messages on this call will be made. The VCCB is marked to show the VC_LU as CLEAR pending CLEAR CONFIRM. The VC_LU should not be reused until the CLEAR_CONFIRM is received from NPSI/GATE. Otherwise, the processing is the same as for receiving a CLEAR command from NPSI. See CLEAR Command Received from NPSI/GATE.

CLEAR_CONFIRM Command Received from NPSI/GATE

After a CLEAR command is sent from the CTCP to NPSI/GATE, NPSI must notify the CTCP when the switched virtual circuit connection has been cleared by returning a CLEAR_CONFIRM command.

The action to be taken is to change the status of the VC_LU from CLEAR pending CLEAR_CONFIRM to CLEAR.