gtps2m14 | ACF/SNA Data Communications Reference |
XALCI support allows ALC-type terminals attached to a packet switched data
network (PSDN) to communicate with existing TPF applications. XALCI is
similar to TPF NEF/ALCI and AX.25 support of the AX001 and AX002
protocols, but differs in the following ways:
- NPSI with the FTPI option is used in place of NPSI with the GATE option or
the ALCI feature of NCP. This effect of this change is limited to the
handling of the NPSI header.
- Terminal registration, XALCI header management, and correlation of
terminals to an LEID are not performed by NPSI. These
functions are implemented in a remote intelligent workstation (IWS) or gateway
and are not supplied by NCP, NPSI, or TPF.
- XALCI supports switched virtual circuits (SVCs). The effect of
using SVCs is that the correlation between LEID value and virtual circuit must
be delayed until the virtual circuit has been established and the registration
report has been received. With AX001/AX002, the correlation between
virtual circuit and LEID is made at network definition time. TPF
provides a user-replaceable module to process virtual circuit setup
requests. The replaceable module is implemented as a process selection
vector (PSV) routine. Users can either use the sample PSV routine or
substitute their own.
The sample PSV routine bases its processing on the NPSI/FTPI command
type. The valid command types are:
- Clear - User Data
- Qualified Data - DCE Reset Confirmation
- Diagnostic - Error Information
- Incoming Call - Interrupt
- Interrupt Confirm - Reset Confirm
The sample PSV routine classifies the input based on the FTPI
header. The general processing is:
- CALL REQUEST commands are accepted by issuing a ROUTC to return a CALL
ACCEPTED command and the ECB EXITCed. When the virtual circuit is
established, the next message received should be an ALCI registration
report.
- Data is passed through to the ALCI logic. The ALCI processing is
described in "Airlines Line Control (ALC) Support through SNA".
- All other types of NPSI commands are discarded by EXITCing the ECB.
TPF's XALCI support code uses the WGTA as its control
structure. Based on the LEID in the data stream, the WGTA slot is used
to store the MCH_ID, VC_ID, and the correlation number of the input message
for recall and insertion into the corresponding output message. The
WGTA is expanded by 4 bytes to hold this additional information.
The only network definition requirement for XALCI support is the need
to:
- Define the NPSI LUs that connect TPF to the packet switch data network
(PSDN).
- Note:
- Use the XALCI resource type for all FTPI LUs that use the XALCI
interface.
- Include the process selection vector routine to handle X.25 message
traffic that complies with the ALCI standards.
Define to the TPF system the NPSI or NPSI FTPI LU that connects the TPF
system to the network and non-SNA terminals using ALCI support. The
format and parameters used to define the NPSI or NPSI FTPI LU are shown in Figure 23.
Figure 23. RSC Statement Definition Statement for an FTPI LU
lu_name RSC LUTYPE=XALCI
,PSV=XALCI
[,PACING=0]
[,AWARE=NO]
[,LEID=FFFFFF]
|
The description of the XALCI values are:
- lu_name
- Specifies the name of the NPSI LU.
- LUTYPE=XALCI
- Specifies if the LU uses the GATE/FTPI interface of NPSI and uses XALCI
data streams to perform the FTPI header management.
- PACING=0
- Specifies the pacing value to use for message traffic sent by TPF.
- Note:
- A value of zero (0) must be specified and means that pacing is not
used.
- AWARE=NO
- Specifies whether the session awareness exit should be started whenever a
session with the LU has been established or terminated. NO must be
specified.
- LEID=FFFFFF
- Specifies from 1 to 3 bytes of data to be passed to the PSV routine when
an input message is received from the LU. This parameter is optional
and is neither required or used by the sample PSV routine supplied with
TPF.
An example of the coding of the RSC statement for XALCI support is shown in
Figure 24.
Figure 24. RSC Coding Example Statement for an XALCI LU
CPLU1 RSC LUTYPE=XALCI,
PACING=0,
AWARE=NO,
PSV=XALCI
|
For more information about defining SNA resources to the TPF system, see Defining SNA Resources to the TPF System.
TPF provides XALCI support by bridging its support of the NPSI FTPI option
with the support for ALCI. The bridge between FTPI and ALCI support is
implemented as a user-replaceable PSV routine. To include the PSV
routine in the TPF system, you must:
- Assemble program segment COBU. COBU is the PSV table and includes
and entry for XALCI. COBU must be allocated as a file resident
program.
- Allocate CNEA as either main storage of file resident, but not defined as
corefast. The PSV routine itself is a program segment named
CNEA.
The source code for the PSV table, COBU, includes the default PSV routine
for XALCI. Figure 25 shows the coded to be added to segment COBU.
Figure 25. XALCI PSV Entry Shipped with TPF
IPSVE NAME=XALCI,
PGM=CNEA,
RESERVE=NO,
DFC=NO
|
The macro to define a PSV table is shown in Figure 26.
Figure 26. Create PSV Table Macro
The macro to define a PSV entry is shown in Figure 27.
Figure 27. Create PSV Entry Macro
IPSVE NAME=XALCI
,PGM=CNEA
[,RESERVE=NO]
[,DFC=NO]
|
- NAME=XALCI,
- Specifies the 1 to 6 character PSV name. The character set is
restricted to the letters A through Z and the numbers 0 through 9. The
name XALCI was chosen for this example, but any valid name is
acceptable.
- PGM=CNEA,
- Specifies the user-replaceable program that bridges FTPI messages to the
ALCI interface. The program can be file or main storage resident but
cannot be corefast.
This program segment must reside in the BSS, but may also be resident in
other subsystems in an MDBF environment.
- RESERVE=NO,
- Specifies whether the entry is reserved for future use. If
reserved, a SERRC is generated in place of the ENTNC. The default is
NO.
- DFC=NO
- Specifies whether the user PSV provides the SNA-architected DFC
layer. The default is NO.
Figure 28 shows a sample of PSV definition for XALCI support.
Figure 28. Sample XALCI PSV Definition Statements
IPSVT BEGIN
IPSVE NAME=XALCI,PGM=CNEA
IPSVT END
|
For more information about the IPSVT and IPSVE macros, see TPF General Macros.
TPF's XALCI support is based on a coordinated effort between TPF base
code and a remote intelligent workstation (IWS) or gateway. The TPF
code performs the blocking and deblocking of data to and from GATE/FTPI, as
well as the FTPI header management and ALCI functions. For additional
information, see Airlines Line Control (ALC) Support through SNA. The FTPI header management is performed using WGTA
and is based on architected XALCI headers discussed in XALCI Header Formats. The gateway is responsible for:
- Managing the virtual circuit to NPSI and TPF. This involves, for
example, handling the various X.25 commands and error handling.
- Building and sending a registration report that lists the LEID of all
terminals supported by the gateway. This should be done when the
virtual circuit to TPF is first established, as well as when supported
terminals are powered on after the gateway has established the virtual circuit
to TPF.
- Inserting of the proper XALCI header information. This consists of
3 bytes (the X.25 Q byte and 2 bytes that are similar to NEF/ALCI
headers that describe the data in XALCI Header Formats), as well as a 3-byte LEID or, in the case of a registration
report, a list of LEIDs.
- Ensuring that the data that is sent to TPF is in EBCDIC. TPF XALCI
code assumes that all headers and data are in EBCDIC.
- Removing of XALCI header information from responses received from TPF and
routing to the correct destination based on the LEID in the XALCI
header.
- Ensuring that the data received from TPF is translated to the correct
character set. Headers and data transmitted from TPF are in
EBCDIC.
Figure 29 shows an example of the various XALCI headers.
Figure 29. XALCI Header Formats