gtps2m2k | ACF/SNA Data Communications Reference |
To activate an LU-LU session, the TPF system needs to know the SNA command to send and across which session to send that command. The decision is based on the following factors:
This section discusses how the TPF system activates LU-LU sessions, meaning that the TPF system sends the first command in the session activation sequence. In this context, activating an LU-LU session does not mean which side is the primary LU (PLU) and, therefore, sends the BIND request to start the actual LU-LU session.
The discussion is broken into two parts, LU 6.2 and other LU types, because of the different triggers that activate these sessions and the different connectivity capabilities.
The ZNETW ACT command activates LU-LU sessions for LU types other than LU 6.2. The CDRM parameter, which is optional and only applicable to the TPF system connected as a PU 5 node, specifies the owning cross-domain resource manager (CDRM) of the remote LU that is being activated. The owning CDRM is not necessarily the CDRM that owns the remote LU but the CDRM through which the TPF system can access the remote LU.
Processing of the ZNETW ACT request depends on whether the CDRM parameter is specified and, if so, is that CDRM-CDRM session active.
An application program that issues the ALLOCATE verb causes an LU 6.2 session to be activated (if there are no active and available sessions already). Before the ALLOCATE verb is issued, a change number of sessions (CNOS) operation must have been done to initialize the mode name and session limits for the remote LU. This process can be done by an operator who enters the ZNCNS INITIALIZE command or an application program that issues the CNOSC INITIALIZE macro. Both of these have a pair of optional parameters, CDRM and CP. The CDRM parameter is identical in function to the CDRM parameter on the ZNETW ACT command.
The CP parameter can only be used when the remote LU 6.2 resource resides in an Advanced Peer-to-Peer Networking (APPN) node that is adjacent to the TPF system. The CP parameter specifies the control point (CP) name of the adjacent APPN node. In this case, the TPF system bypasses the normal APPN search, meaning the TPF system does not send a LOCATE request on the CP-CP sessions and, instead, sends a BIND request directly to the adjacent APPN node. User exit UALS selects the adjacent link station (ALS) over which the TPF system will send the BIND request.
Processing of a CNOS INITIALIZE request depends on whether the CDRM or CP parameter is specified and if that resource is active.
When the TPF system is connected to the network as a PU 5 node only, a CDINIT request is the first command sent to start the LU-LU session. Because the TPF system can be connected to many hosts, each with a CDRM-CDRM session, the owning CDRM must be known for the CDINIT request to be sent across the correct CDRM-CDRM session.
When a session is activated with the remote LU for the first time, the owning CDRM must be specified (the CDRM parameter must be specified). On subsequent session activation requests for the remote LU, the owning CDRM does not need to be specified, in which case the TPF system will use the same owning CDRM that was used the first time.
When the TPF system is connected to the network as a PU 2.1 node only and is running in LEN mode, the only LU-LU sessions that can be started by the TPF system are LU 6.2 sessions and the PLU must reside in the TPF system. Do not code the CDRM parameter on CNOS INITIALIZE requests. Each time that a session is started, the TPF system will select a CLU-CLU session over which to send a REQTAIL request to the VTAM logon manager.
When the TPF system is connected to the network as a PU 2.1 node only and is running in APPN mode, sessions other than LU 6.2 can be started by the TPF system and the PLU is not required to reside in the TPF system. Unlike PU 5 where there can be many CDRM-CDRM sessions, there is only one pair of CP-CP sessions because the TPF system is an APPN end node (EN).
Do not code the CDRM parameter on the ZNETW ACT command. Each time that a session is started, the TPF system will send a LOCATE request on the CP-CP sessions.
Do not code the CDRM parameter on the CNOS INITIALIZE request. If the remote LU does not reside in an adjacent APPN node, do not code the CP parameter either. Each time that a session is started, the TPF system will send a LOCATE request on the CP-CP sessions.
If the remote LU resides in an adjacent APPN node and the PLU resides in the TPF system, code the CP parameter on the first CNOS INITIALIZE request with the remote LU. On subsequent CNOS INITIALIZE requests, the CP parameter does not need to be specified. If the CP parameter is not specified, the TPF system uses the same owning CP that was used previously if there is a path to it; otherwise, a LOCATE request is sent on the CP-CP sessions.
Notes:
When the TPF system is connected to the network as both a PU 5 node and PU 2.1 node, the question becomes: What type of network search do you use to find the remote LU? In this context a mixed PU 5 and PU 2.1 environment means that the TPF system has both PU 5 and PU 2.1 links active; it does not mean that part of the LU-LU session path is in the PU 5 network and the other part of the path is in the PU 2.1 network.
The question of whether to search the PU 5 or PU 2.1 network is only relevant if the CDRM parameter (and CP parameter if LU 6.2) was not specified. There are two key considerations:
When migrating 3745s from PU 5 to APPN, the following rules are in place:
If you did not specify the CDRM parameter on the ZNETW ACT command, the order of preference is as follows:
If you did not specify the CDRM parameter or CP parameter on the CNOS INITIALIZE request, the order of preference is as follows: