Do What I Mean, Not What I Say
by Mark Gambino, IBM TPF Development
"Why won't this work? The definitions on my system look fine. That's not what's supposed to happen. This used to work. I need a vacation.
Does any of this sound familiar? In an attempt to clear up some of the confusion regarding the interaction of different network components, we will explore how some network control program (NCP) and VTAM definitions can affect your TPF system. The examples chosen for this article were selected not only because they recently surfaced at one or more TPF customers sites, but also because each solution required a definition change in a network component other than TPF. The network definitions in the TPF system were correct but, as you will see, some events are completely controlled by the definitions in the NCP and VTAM system.
SNA Spelled Backwards is ANS
When migrating your TPF system from PU 5 to PU 2.1 support, coding the ANS parameter on the PU statement in the NCP generation deck (NCP gen) that defines the link between the 37x5 device and the TPF system becomes important. ANS means automatic network shutdown, and the ANS parameter in the NCP gen determines what happens to the link if there is a failure on the link between the 37x5 device and VTAM system that owns the NCP. In a large network with thousands of terminals in session with the TPF system, it is highly desirable that the network be able to survive a failure of the VTAM system to avoid having to restart all of the LU-LU sessions. Coding ANS=CONTINUE on the PU statement in the NCP gen that defines the link to the TPF system enables the sessions between the terminals and TPF to remain active even if the NCP is in shutdown mode with respect to the access method, meaning the link between the 37x5 and the owning VTAM system fails. Coding ANS=STOP causes the link and all sessions across that link to fail if the NCP loses its connection to its owning VTAM system.
When the TPF system is connected as a PU 5 node (PUTYPE=5 coded on the PU statement in the NCP gen), the only allowable value (and, therefore, the default value) for the ANS parameter is CONTINUE; therefore, many customers do not bother to code the ANS parameter in this case. However, when the TPF system is connected as a PU 2.1 node (PUTYPE=2 coded on the PU statement), ANS=CONTINUE and ANS=STOP are both valid options but the default is ANS=STOP. For this reason, you must specifically code ANS=CONT when defining a PU 2.1 link to the NCP. Whether you are defining a parallel channel adapter or ESCON channel adapter does not affect the default value of the ANS parameter or change how the ANS parameter should be coded.
It's ELEMENTary, Watson
If your TPF system is connected as a PU 5 node through a 3745 NCP to a VTAM system, how to correctly define the TPF cross-domain resource manager (CDRM) to VTAM changed 6 years ago; but not all customers are aware of this fact. Why? Because the old CDRM definition still works most of the time (the key word being most). Depending on the order in which major nodes are activated in VTAM, what resources are predefined to the NCP, and the status of the NCP when it is activated or acquired by VTAM, the activation of the CDRM-CDRM session between VTAM and TPF can fail if the CDRM definition in VTAM is incorrect. In the worst case scenario, the incorrect CDRM definition causes VTAM to abend. To better understand the problem, we need to examine the information in the Systems Network Architecture (SNA) archives.
Each resource in a PU 5 network (like a CDRM) is uniquely identified by its network address (NA), which contains a subarea number and an element address. When SNA support was first added to the TPF system back when dinosaurs roamed the earth, all resources that resided in the TPF system were assigned an NA at system generation time. The TPF systems services control point (SSCP), which to VTAM is the TPF CDRM, was assigned element address 0 (zero). Element address 1 was reserved and logical units (LUs) or applications were assigned NAs with element addresses of 2 and above. In VTAM, the definition for the TPF CDRM had to be coded with ADJNETEL=0 on the gateway path (GWPATH) statements. The ADJNETEL parameter specifies what the element address of the CDRM is in the adjacent network (which is the TPF network in this case).
When NCP Version 5 Release 3 (V5R3) came along in 1990, the link activation sequence between VTAM and NCP changed causing element addresses 0 and 1 to take on special meanings for PU 5 nodes. The PU in a PU 5 node is supposed to use element address 0 and the SSCP/CDRM is supposed to use element address 1. TPF 3.1 APAR WP12070 enabled the TPF system to connect to NCP V5R3 by allowing the use of element address 1 for the TPF CDRM. TPF determines the element address to use for its CDRM (0 or 1) based on the value that is sent by VTAM in the ACTCDRM request, which comes from the value of the ADJNETEL parameter on the CDRM definition statement. When using NCP V5R3 or higher, code ADJNETEL=1 on the CDRM statement in VTAM (or do not code the ADJNETEL parameter because its default value is 1). Do not code ADJNETEL=0 anymore because it can cause problems for the VTAM system.
While how to define the TPF CDRM to VTAM did change because of NCP V5R3, how to define the VTAM CDRM to TPF did not change. Just like TPF now determines what element address to use for its CDRM from the ACTCDRM request, TPF continues to use information in the ACTCDRM request to determine the NA for the VTAM CDRM. The NA for the VTAM CDRM is dynamically assigned by the SNA network interconnect (SNI) NCP and is, therefore, not predefined to the TPF system.
Pie a la MODEENT
Dynamic LU support (APAR PJ21044 on PUT 4) removed the requirement that a remote LU must be defined to the TPF system via the offline SNA table generation (OSTG) process before that LU can log on to the TPF system. For remote LUs that are discovered dynamically by the TPF system (not predefined in OSTG), particularly dependent LUs, it is crucial that the information in the VTAM logon mode table entry match the information in the corresponding BIND image table entry in the TPF system. A dynamically discovered LU is treated like an LU that was defined as LUTYPE=ANY in OSTG, meaning that during the session activation process the TPF system relies on the suggested BIND image to identify the characteristics of the remote LU. Remote LU 6.2 and functional management message router (FMMR) resources (LUs) can easily be identified because of the TPF application with which they are starting a session. For example, if a remote LU is starting a session with a TPF application that is type LU 6.2, the remote LU must also be type LU 6.2. However, there are several flavors of 3270, 3600, and X.25 resources, which makes them more difficult to identify because many different types of remote LUs can be in session with the same TPF application.
A VTAM logon mode table (MODETAB) contains mode table entry (MODEENT) statements that define the various mode names used in the network. When an LU owned by VTAM wants to go into session with a TPF application, VTAM uses the information in the MODEENT associated with this LU to build the suggested BIND image. In PU 5, the suggested BIND image is passed to the TPF system in the CDCINIT request across the CDRM-CDRM session. In Advanced Peer-to-Peer Networking (APPN), the suggested BIND image is passed in the LOCATE request across the CP-CP sessions. If the TPF system receives a logon request for a remote LU that was predefined (using OSTG) and is not LUTYPE=ANY, most of the information in the suggested BIND image is ignored (except for the RU sizes and pacing window values).
For dynamic LUs (and those predefined as LUTYPE=ANY), information in the suggested BIND image is used to search the BIND image table in the TPF system. If a matching entry is found, it is used to set up the LU type and device characteristics. The values in the suggested BIND image that are used as the search arguments are the transmission services (TS) profile, the primary LU protocol, the secondary LU protocol, and the common LU protocols, which correspond to the TSPROF, PRIPROT, SECPROT, and COMPROT parameters on the MODEENT statement. If the LU is identified as a 3270 LU, information in the presentation services (PS) profile of the suggested BIND image is used to find a matching entry in the PS profile table in the TPF system to further clarify the type of 3270 device. The PSERVIC parameter of the MODEENT statement defines the PS profile that will be included in the suggested BIND image.
The most common external symptom that there is a definition mismatch between the TPF system and VTAM system is a session activation failure with sense code X'0821'. If no matching BIND image table entry exists, the TPF system rejects the session activation request with that sense code. The same is true if no matching PS profile table entry exists for 3270 LUs.