gtps2m15 | ACF/SNA Data Communications Reference |
Figure 30. XALCI Configuration
Figure 30 shows a typical XALCI configuration. GATE/FTPI multiplexed sessions are used to connect each host in the TPF loosely coupled complex to NPSI in the 3745. The 3745 is owned and loaded by the VTAM CMC. On the remote side of the X.25 network is an intelligent workstation (IWS) that supports multiple workstations attached via token ring. The IWS, or X.25 gateway, manages the addition to and removal of XALCI header information for all traffic originating from or destined for its supported workstations. The correlation of data to workstation is performed using a unique LEID that is associated with each workstation on the token ring.
On initial activation, the X.25 gateway is responsible for establishing a virtual circuit with the TPF complex. This is achieved by issuing a call to NPSI. Through the use of call user data or subaddressing, the gateway can specify a particular processor in the complex. Also, depending on NPSI generation options, the GATE/FTPI function can perform alternate routing of the CALL if the primary target host is unavailable. NPSI then forwards the call to the specified TPF CTCP.
The CTCP may analyze the call and either accept the call with a CALL ACCEPTED or reject it with a CLEAR. If CALL ACCEPTED is sent, this is then forwarded by NPSI across the newly established virtual circuit to the originating gateway. When the gateway receives the CALL ACCEPTED, the XALCI registration report is then built and transmitted on the virtual circuit. The registration report specifies the LEID of every workstation that the gateway supports. This report is primarily used by TPF to activate the LMT queues of hardcopy devices. The CTCP also uses the registration report to store routing information, such as the device's multichannel ID, virtual circuit ID, and current correlation number that are all required for GATE/FTPI support. When the registration report has been transmitted to TPF, terminal traffic may begin to flow between the gateway and the TPF complex.
To trace the flow of a message in an XALCI configuration, assume that LOGI RES0 is entered by one of the workstations on the token ring. The input message is transmitted on the ring to the gateway. The gateway then inserts the XALCI header information that describes this as user data, as well as the LEID that identifies the terminal. This data is then forwarded across the X.25 network on the virtual circuit. NPSI receives the input message and blocks it with other traffic that is destined for the same TPF CTCP. The data is accumulated until either a user-definable timer expires or the user-definable number of messages has been blocked into the PIU. In either case, the PIU is then forwarded across the multiplexed session to the specified TPF host.
OPZERO manages the deblocking of the deblocking of the messages from the GATE/FTPI blocked PIU based upon header information that was appended by NPSI on each message. Messages are copied by OPZERO to a core block and attached to an ECB. Upon inspection of the origin SNA resource type, SNA COMMSOURCE passes control to ALCI COMMSOURCE. ALCI COMMSOURCE uses the LEID in the data stream to access the WGTA slot for the device, and stores the multi-channel ID, virtual circuit ID and correlation number for this input message in the WGTA. The FTPI and XALCI headers are stripped out, and the message is put in AMSG format.
Because this is a LOGI message, control is passed to the log processor. The log processor logs the terminal into RES0 and responds with a LOGI COMPLETE data stream that it routs to the originating terminal. The message router determines that the LOGI COMPLETE message is destined for an XALCI resource and passes control to ALCI output transformation code in CCCCP1. Routines access the WGTA slot for the device based on the LEID and retrieve the FTPI header information that was saved on input. FTPI and XALCI headers are inserted into the output message and control is passed to SOUTC. SOUTC determines that this PIU is destined for an FTPI LU, and control is passed to the FTPI message blocking process. The FTPI message blocking process accumulate PIUs in a 4K core block until either the block is full or a timer expires. (See the TPF ACF/SNA Network Generation for detailed information on LUBLKT in SNAKEY/CTK2.) In either case, the blocked PIU is then transmitted to NPSI across the multiplexed session.
The GATE/FTPI process in NPSI then deblocks the messages from the blocked PIU, removes the FTPI header from the message, and transmits the message on the virtual circuit that was specified in the FTPI header. When the gateway receives the message, it removes the XALCI header information and LEID and sends the message on the token ring destined for the terminal that corresponds with the LEID. LOGI COMPLETE is displayed on the originating terminal.
For more information regarding coding of a GATE/FTPI CTCP as well as more detailed information regarding NPSI and its command flows, see the NPSI Host Programming and the NPSI Planning and Installation.