gtps2m33 | ACF/SNA Data Communications Reference |
For SNA CTC, the IODEV macro is used in the System Initialization Process to define the addresses of the CTC connections. In SNAKEY, this IODEV macro produces the symbolic device address table (SDAT), which defines the size of the physical network, including the number of CTC connections. After you define the addresses of the CTC connections using the IODEV macro, define the NCP and CTC links to the TPF system using the OSTG program or the ZNDYN command. See Defining SNA Resources to the TPF System for more information about defining these resources to the TPF system.
When you create a network definition for NCP or CTC resources, you must define the VR window size for VR pacing using the WINSIZE parameter. This number is saved in the MAXDT field in the RRT/RVT and passed to the adjacent node on the ACTVR. The recommended value is 100 to minimize the overhead of pacing but can be specified as high as 255. You are expected to tune this parameter to suit his network. Be aware that picking too high a number will impact NCP performance as NCP allocates 3 times this number of buffers for the virtual route.
The Subarea Address Table includes the ER and VR information.
TPF shares 1 network address for the SSCP and the CDRM (element address 0). With FID4 support (TPF as a data host), the SSCP is replaced by the PU Manager. TPF uses the same RVT entry for both the PU Manager and the CDRM, since no information on the PU5-PU4 session is kept in the RVT. ER and VR control information is kept in the Subarea Address Table.
When operating as a PU 5 type node (SSCP), with TPF's support of the SNA network interconnection (SNI) facility of NCP and VTAM, there are some special considerations relative to network definition. A VTAM CMC must own all resources attached to a gateway (SNI) NCP. For more information on PU 5 nodes, see "Cross-Domain Resource Manager (CDRM)".
A gateway NCP is defined from the viewpoint of the gateway SSCP that owns it. Therefore, to represent the TPF view of the network from within TPFs' own network, you must specify a subarea for the CDRM when the CDRM is defined to the TPF system. See Defining SNA Resources to the TPF System for more information about defining CDRM resources to the TPF system.
The name of the TPF systems' network ID stored in the TPF systems' SNA keypoint (CTK2) is the name as it is known by the owning VTAM system.
Because the design of SNI requires the VTAM CDRM that owns the gateway resources to appear in the subarea of the gateway NCP as an element in the NCPs subarea, some restrictions exist regarding TPF's attachment to an SNI network. TPF's table structure assumes that NCPs and VTAM hosts are each a unique subarea. Therefore, the subarea address table (SAT) has 1 entry for each subarea node. The VTAM SSCP and its associated CDRM are assumed to reside in the same subarea. With SNI, this is not true. To circumvent this problem, define a virtual or pseudo-subarea for the VTAM CDRM. The TPF system will create an SAT entry for this subarea and point it to the resource vector table entry for the VTAM CDRM. The RVT will contain the real network address for the CDRM. The actual network address of the VTAM CDRM is discovered dynamically when the CDRM-CDRM session is established. This virtual subarea will be used by TPF internally as the owning subarea for all resources that request sessions with TPF through this CDRM.
A CTC connection to VTAM requires TPF to appear as a node in the VTAM network and use a CDRM-CDRM session or Control LU (CLU) - Logon Manager session to establish LU-LU sessions between the VTAM and TPF hosts.
SNA CTC support requires the channel-attached major node to reside in the same network (for example, VTAMNET) as VTAM. Because the TPF system must be connected to the NCP network through SNI, the TPF CDRM resides in a different network (for example, TPFNET). In order to establish a session across CTC, TPF must appear to VTAM as a CDRM in the VTAM network so an additional TPF CDRM must be defined. See the TPF ACF/SNA Network Generation for examples of SNA CTC configurations.
Therefore, if both a CTC connection and an SNI connection exist, VTAM must have 4 separate definitions for the TPF CDRM:
When the TPF system is connected to a VTAM system using both PU 5 NCP links across SNI and APPN links, an alias name for the CDRM to the VTAM system must be defined to the TPF system. In this environment, the VTAM system is defined as an interchange node, allowing it to act as a PU 5 node and an APPN network node. VTAM requires that its SSCP name and CP name must be identical. The problem is that this name cannot be defined to the TPF system as both a CDRM and a CP. The CP must be defined to the TPF system using its real name and the CDRM must be defined using an alias name.
As an example, the SSCP and CP name for a VTAM system is VTM2. The alias name for the CDRM will be VTM2CDRM. The subarea of the VTAM system across the SNI boundary is 5. The following are the OSTG definitions needed to define this CP and CDRM:
VTM2 RSC LUTYPE=REMCP VTM2CDRM CDRM SUBAREA=5,ELEMENT=1,REALNAME=VTM2
In the previous example, the real name of the VTAM system, VTM2, is defined to the TPF system as a remote APPN control point using the OSTG RSC statement. You can also use dynamic LU support to define VTM2 to the TPF system.
You must define the alias name, VTM2CDRM, to the TPF system as a CDRM using the OSTG CDRM statement. The REALNAME parameter on the CDRM statement must be the real name of the VTAM system. To display or deactivate the CDRM from the TPF operator console, you must use the alias name.
See Defining SNA Resources to the TPF System for more information about defining SNA resources to the TPF system.