gtps2m1j | ACF/SNA Data Communications Reference |
For sessions between a remote LU and a TPF/APPC LU (not an SLU thread), there is a restriction that forces all sessions with a particular remote LU 6.2 to be established with only 1 processor in the loosely coupled complex. It does not matter which processor is chosen, but once the first session is established, all sessions with this remote LU 6.2 must go to the same processor as the first session.
To overcome this restriction, TPF provides unique TPF/APPC service LUs for each processor and a TPF service transaction program to allow TPF/APPC transaction programs in all processors of a loosely coupled complex to have LU 6.2 conversations with a particular remote LU 6.2.
To fully utilize TPF/APPC in a loosely coupled environment, there are some installation tasks that you need to perform. These tasks are described in Loosely Coupled Complex Example; however, before setting up your system to run TPF/APPC in a loosely coupled environment, you must determine the kind of sessions that your applications require.
A remote LU can view the complex in 1 of 2 ways:
If a remote LU needs sessions with multiple TPF hosts (separate image view), the LU can do 1 of the following:
If a remote LU only requires sessions with 1 TPF host (single image view), the LU can specify a local TPF/APPC LU name to establish a session with 1 TPF host.
1 factor to consider when determining whether an application needs sessions with multiple hosts or only 1 host is the number of messages it generates. Some applications may generate such a high volume of messages that funneling all the requests to a single TPF processor in the complex would create a problem with performance.
From the point of view of the TPF system, if all the TPF hosts need to communicate with the same remote, they can also establish sessions using the TPF/APPC service LUs in each host.
Figure 59 the many possible types of TPF/APPC sessions. In this example, there are 2 TPF loosely coupled complexes, each containing 2 hosts (LC1 contains TPFA and TPFB, and LC2 contains TPFC and TPFD), and several remote LU 6.2 nodes.
The local TPF/APPC LUs for the LC1 complex are APPC, TOUR, and DEAD. The local TPF/APPC LUs for the LC2 complex are LU62 and LVNV. (The local TPF/APPC LUs could be the same for both complexes in this example.) The TPF/APPC service LU for: (1) TPFA is SVCA, (2) TPFB is SVCB, (3) TPFC is SVCC, and (4) TPFD is SVCD.
In each host, the diagram shows the local TPF/APPC LUs and the unique TPF/APPC service LU, the RVTs for the remote LUs, and any SCBs associated with the particular remote RVT. Each SCB represents 1 session. The LU name in the SCB box indicates the local partner LU with which the remote is in session.
In the example, remote LU DB2 needs to communicate with multiple TPF hosts, so it is set up to view each TPF host in the complex as a separate image. Sessions are established using the service LU in each host; DB2 currently has 2 sessions with each host.
Remote LU PS2Y also views LC1 as separate TPF images and has a session established with each service LU in the complex. If necessary, PS2Y could also establish sessions with 1 of the TPF/APPC LUs in TPFC or TPFD, or it could establish sessions with 1 or both service LUs in TPFC and TPFD.
Remote LU PS2X views the LC1 complex as a single TPF image. It currently has 3 sessions established with LU APPC in TPFA. Because TPFB is in the same loosely coupled complex as TPFA, no sessions between PS2X and TPFB can be established at this time. However, because TPFC and TPFD are in a different complex, PS2X can establish sessions with either host in the LC2 complex.
Remote LUs PS2K and PS2Q both view LC2 as a single TPF image. PS2K has sessions with LU62 in TPFC and cannot establish sessions with TPFD, but can establish sessions with the hosts in LC1. PS2Q has a session with LVNV in TPFD and cannot establish sessions with TPFC.
PS2N has a session with the service LU in TPFC, which allows PS2N to establish sessions with the service LU of TPFD if needed.
Although not shown with lines in this diagram, there are also sessions between the service LUs of the hosts in different loosely coupled complexes as well as in the same complex. For example, SVCA in TPFA has 2 sessions with SVCC in TPFC and 1 session with SVCD in TPFD. SVCA also has a session with SVCB.
Figure 59. Loosely Coupled Complex Example for TPF/APPC Sessions
This section describes the tasks you must perform to use the TPF/APPC support in a loosely coupled environment.
The last 3 tasks are not required if all remote LU 6.2s are to view the complex as a single TPF image and the TPF system does not initiate any conversations with these remote LUs (that is, the remote LUs start all conversations).
These tasks are as follows:
See TPF/APPC Installation Checklist for information about how to define the local TPF/APPC LUs.
Define 1 TPF/APPC service LU for every processor in the TPF loosely coupled
complex with a MSGRTA statement as follows:
MSGRTA APLIC=SVCx,EDIT=CHDD,APROC=x,ASNA=APPC
where x is the processor ID.
For example, if there are 4 processors in the loosely coupled complex
(TPFA, TPFB, TPFC, TPFD), code the following:
MSGRTA APLIC=SVCA,EDIT=CHDD,APROC=A,ASNA=APPC
MSGRTA APLIC=SVCB,EDIT=CHDD,APROC=B,ASNA=APPC
MSGRTA APLIC=SVCC,EDIT=CHDD,APROC=C,ASNA=APPC
MSGRTA APLIC=SVCD,EDIT=CHDD,APROC=D,ASNA=APPC
If any remote LUs view the complex as a single TPF image and TPF is to
initiate conversations with these remotes, define the service transaction
program in the transaction program name table with the ITPNT macro as
follows:
ITPNT TYPE=ATTACH,PGM=CHRP,TPN=TPF_SERVICE_TP
ITPNT TYPE=AOR,PGM=CHRM,TPN=CHRM
When initialize the network, use the ZNCNS command to initialize the session limits for the mode name used by the TPF/APPC service LUs. (As with the ITPNT definitions, this is necessary only if any remote LUs view the complex as a single TPF image and TPF is to initiate conversations with these remotes.)
You must issue a ZNCNS INITIALIZE for each processor pair. For example, if there are 4 processors (TPFA, TPFB, TPFC, TPFD) and you decide that each processor needs 10 sessions with each of the remaining processors, issue the following commands:
Notes: