gtps2m11 | ACF/SNA Data Communications Reference |
Using TPF multiple host extension support, NEF_supported terminals can directly communicate with one or more TPF hosts via cross_domain support. AX.25's use of Permanent Virtual Circuits (PVCs) requires direct attachment to a specific host in the PU_5 environment. This is not required for PU 2.1. XALCI's use of GATE/FTPI allows the use of switched virtual circuits (SVCs) as well as PVCs. Because all 3 protocols are SNA-supported, either a block or byte multiplexer channel may be used.
Combining SNA and ALC support requires generation of both SNA and ALC data records. Further, it is necessary to cross-reference the basic SNA record (the resource vector table (RVT)) with the definition of each ALC supported terminal. The terminal address table (WGTA) is used for this purpose.
SNA (TPF) maintains the real network addresses of all logical units (LUs) in the NCP after they were discovered from the VTAM Communications Management Configuration (CMC) when the LU-LU session was set up. However, SNA (TPF) is not aware of the attached ALC terminals, lines, or interchanges. Each LU has a resource identifier (RID), network address, and node name. To maintain the ALC device address format, each terminal is given a 3-byte address known as Logical End-Point Identifier (LEID). The LEID is used to create the AAA initialization table (UAT) entries for the ALC terminals. Each NEF/AX.25/XALCI terminal address table (WGTA) entry contains the RID of the associated LU. Each NEF terminal on a 37x5 references to the same LU; each NEF LU references to all of the NEF terminals on the 37x5. The same is not true for AX.25 LUs. There may be several AX.25 LUs in the 37x5, each represent 1 or many terminal controllers. GATE/FTPIs' use of virtual circuit concentration allows a single LU type 1 to support multiple X.25 virtual circuits. Each of these virtual circuits can, in turn, support multiple terminals. At least 1 FTPI LU is required per TPF host. Multiple GATE/FTPI sessions to a single TPF host are supported.
VTAM Communications Management Configuration (CMC) must own NEF, AX.25, and XALCI resources. For NEF, the terminal interchange (TI) is identified to VTAM as a physical unit (PU). One LU per NCP with NEF and one or more LUs per NCP with NPSI/AX.25 or NPSI GATE/FTPI needs to be defined to a VTAM CMC. All terminals attached to the 37x5 through links and terminal interchanges communicate through the NEF, AX.25, and FTPI LUs. These LUs are also defined to TPF as cross_domain resources (CDRSCs). This implies that TPF is not aware of the ALC lines or terminal interchanges. All terminals accessed using NEF/AX.25/XALCI LUs are identified to TPF as LEIDs through an entry in the terminal address table (WGTA). The LEID need not have any correlation with the physical address of the terminal. However, the first (most significant) byte of the LEID must be above the range of valid symbolic line numbers.
Input or output data messages pass through 4 message formats when sent over the network. An input/output message is received or sent from the terminal interchange in ALC format. This format includes the real interchange address (IA), the synchronization check characters, the cyclic check characters, and the data. NCP (NEF/NPSI) converts this to or from a path information unit (PIU). The request unit (RU) is in the PIU. The RU contains terminal address information that is used to obtain the LEID followed by the data. TPF converts the input message to TPF application message format. On input, the communications source program activates the application in the same format (AM0SG) or in the input message format (MI0MI). The user specifies the format during system initialization. Output message processing is based on the output message format AM0SG or UI0OM.
The VTAM SSCP views NEF communication lines as SNA lines, and ALC terminal interchange units as physical units (PU). A pseudo_NEF application logical unit is created in the TPF host. The NCP NEF logical unit is then bound in a session with the NEF application logical unit. The NEF application logical unit is known as NEFx where x is the CPU ID of the host. All NCP NEF logical units that communicate with the host must be bound to NEFx This is not an application that a terminal operator can log into. Further, it does not appear in the routing control application table (RCAT). In the RVT, the NEF logical unit is defined as permanently logged. For AX.25, the TPF CCP code performs, on behalf of the application, the functions provided by the host NEF LU. FTPI LUs that are defined to TPF as using the XALCI protocol can be logged into any application. This dummy application is simply used for session startup and takedown. The XALCI data streams are used, in a manner similar to NEF, to allow access to the Log Processor. Terminals supported by XALCI are independent of the application that the FTPI LU is logged into.
The VTAM CMC system operator controls the NEF/AX.25/XALCI network using SNA commands. One exception exists: the operator does not control or communicate with ALC terminals. The TPF operator addresses the terminals via its LEID. The terminals can receive unsolicited messages sent through the ZSNDU command. The TPF operator can perform terminal diagnostics functions and terminal display functions via the ZTERM command. The ZTERM command displays the RCB file address, WGTA entry address, the application name, and the logical unit with which the terminal is associated.
When a terminal operator enters a data message, it is sent from the terminal to TPF. Before being transmitted to the host, if required by the user, NEF provides the ability to translate the data from ALC to EBCDIC. TPF XALCI support assumes that the data has already been converted to EBCDIC. The RU portion of the PIU received by TPF contains terminal address information and input data, including the end-of-message character. The terminal address information is as follows:
On receipt of the PIU, TPF determines the origin and the content, data, or response. If it is a data message, segment CNE1 is activated for all three classes of traffic. Otherwise, SNA OPZERO processes it like any other response.
The ALCI Comm Source program, CNE1, reformats input messages from a PIU to the TPF application message format. This includes setting up the LEID in the ECB from the input PIU. The message is also converted from an SNA format to a high speed message format. When the message is reformatted, an interface is provided to real-time trace (RTT) to allow agent trace as well as nodename trace. See TPF Program Development Support Reference for more information on these trace facilities.
The resource identifier (RID) field in the WGTA entry is updated to reflect the current association of the terminal with the NEF, AX.25, or FTPI/XALCI logical unit.
When CNE1 has completed successfully, the input message is processed as any other high-speed input message. Messages can be passed to either of the following:
Therefore, on exiting the input interface program, the input takes a parallel processing path to that of other high-speed ALC input messages.
When an application program, including the system message processor, sends an output message to a NEF/AX.25/XALCI terminal (in response to an input message), it uses either ROUT- or SEND-type macros. The ROUT or SEND macro service routines, or both, view this terminal as a high-speed ALC device. One exception exists: the first byte of the LEID is above the range of valid symbolic line numbers. Real symbolic line numbers are calculated during system generation with input supplied by the user. This data is stored in the system communication configuration table (CK6KE).
Support is included in the communication control program (CCP) to avoid accessing the system communication keypoint records. This logic intercepts the CCP when the symbolic line number is out of the valid range where a CCP error condition would have occurred without NEF, AX.25, or XALCI support. The LEID is then used to locate the terminals entry in the terminal address table (WGTA). The WGTA contains the RID that points to the resource vector table (RVT) entry. If the RVT entry cannot be used, CCP error logic is followed. Otherwise, the RVT entry is used to locate the device.
The technique described is used in the common CCP macro routine (segment CLXC) to determine when it is necessary to reformat the output message to a PIU format. In addition, only the SENDA, SENDC, SENDL, and SLMTC macros are supported. The ROUTC macro is only supported if it generates a SENDA, SENDC, or SENDL macro. In other words, ROUTC starts the appropriate macro for the appropriate device.
If an error occurs when locating the WGTA entry, a system error is issued.
The ALCI using the CLXV SNA output routine performs the reverse of the ALCI Comm Source interface program. When the message is reformatted, the SNA SOUTC macro service routine is activated. This routine performs the scheduling and transmission of the message to the 37x5. For XALCI, SOUTC also performs blocking of output messages according to the GATE/FTPI interface before transmission. The SOUTC routine also ensures that an SNA session is established with the receiving logical unit if the request was made via SLMTC. If required, it then translates the message. Lastly, the SOUTC routine informs the LU if the message is multisegmented and if a response is expected from the receiving terminal. For NEF, AX.25, and XALCI messages, pacing is not performed.