gtpc3m29 | Concepts and Structures |
The TPF system supports a variety of network protocols with most being supported through the systems network architecture (SNA). These include SDLC, CTC, X.25, ALC, and Token Ring. The non-SNA protocols are BSC, SLC, and 3270 local.
The primary SNA interface is through channel-connected communication controllers running NCPs, although a CTC interface is also supported. The TPF system recognizes a wide variety of SNA LU types (LU0, LU1, LU2, LU3, LU 6.2) with a wide variety of terminal types (such as 3600/4700, 327x, 328x, PS/2, AS/400, RISC System/6000).
In a loosely coupled complex, emulator program (EP) protocols (that is BSC and SLC) must be connected to a single CPC, known as the EP processor.
As a participant in a full function network, the TPF system supports two different interfaces to the SNA network:
The function of the TPF system within an SNA network is to act as a data host where network information and management are assumed to be handled by a VTAM communications management configuration (CMC). The TPF system manages the applications within its complex, the channel interfaces to locally attached communication controllers, and the range of terminals and LU types connected to the TPF system.
In keeping with the TPF philosophy to recover quickly when a system error occurs, there are several design points in communications control for this purpose:
A network restart requires a considerable amount of time if the SNA network is large.
The TPF system checkpoints network and session status periodically. This means that the system tables held in main storage are written to file storage. Therefore, in the event of a TPF system failure, the system tables can be recovered as of the last checkpoint time.
Practice has shown that most of the time, the network is not aware of gaps in the operation of the TPF system.
In addition, during a system restart, the TPF system queries the network to find out current network and session status. The system tables are updated with this information and checkpointed (that is, written to file storage). Thus the TPF system dynamically attempts to maintain the latest information about the network and its sessions.
Network status and timers are used to detect deadlocks that can occur because of the unpredictable rate of message traffic.
Functional management message router (FMMR) is a TPF routing mechanism that permits an application in a TPF system to send a message (data) to an application in another TPF system. That is, the destination TPF system is remote and out of complex to the origin TPF system. Therefore, if the origin TPF system is a uniprocessor, all other CPCs running the TPF system are remote. If the origin TPF system is loosely coupled, then the destination TPF system is a CPC that is external to the origin loosely coupled complex.
Only the SNA link protocol is supported for sending a message to a remote TPF application.
Interprocessor communication is the mechanism that is used for communication between the CPCs in a loosely coupled (LC) complex; that is, remote and in complex.
Conceptually, IPC can be viewed as a communication facility that is internal to the TPF system and uses the MPIF channel-to-channel protocol.
The TPF system provides a variety of user exits to allow a user installation to tailor system processing to address unique requirements. There are user exits within communications control, such as message recovery, transaction routing for input messages, ROUTC for output messages, COMM SOURCE, and processing selection vectors, which are activated based on the LU name of the input source.