gtpn1m0j | Non-SNA Data Communications Reference |
The purpose of the CCP is to provide an access method where by the application programs are relatively independent of the communications hardware operation.
The CCP handles all polling (telling the Terminal Interchange (TI) to send in any messages it has in its buffer) on a time basis. Further, if the amount of available main storage is low, polling is postponed until enough main storage is again available. The CCP also handles the circuit assurance on all communications lines. This is to ensure that the lines are in an operable condition.
The CCP executes all communication I/O operations for the application programs. The CCP sets up the CCWs, starts the I/O and handles the interrupts from the operation.
The CCP obtains main storage on input operations and releases the output block.
The CCP translates all input messages except 3270 Local into an appropriate internal character code. On output, it translates the internal code to the appropriate line code for transmission except for 3270 Local. Both input and output for the 3270 Local are in EBCDIC, except for control characters, which are in hexadecimal.
This includes the assembly of HS input messages into a single main storage block, if needed, and checking for invalid characters.
CCP performs backspace editing, if required, and then activates the Router. The Router will activate the appropriate application program which will route the message to the proper application segment for processing.
The CCP performs all hardware error detection at interrupt time and attempts correction of the error condition. If error correction fails, notification is sent to operations and the line turned down.
The CCP detects all software errors associated with the communications lines and processes them by issuing an appropriate system error.
The loosely coupled feature allows multiple processors running the same applications to concurrently access a common database. The balancing of the processing load across all processors in a complex is achieved by distributing the input message traffic across the complex. It is irrelevant which processor handles a terminal user's input, since each processor in a complex provides identical service. To a terminal user, say, a reservation agent, a loosely coupled complex has the appearance of a single TPF system. To the system operator, however, the system has the appearance of separate but connected processors. The system operators of a loosely coupled complex has the ability to run the complex from any or all loosely coupled processors.
There are three (3) considerations relative to communications support for the loosely coupled feature.
In order to balance the work load across the processors comprising a loosely coupled complex, the user must distribute the message traffic across those processors. The message traffic distribution technique available depends on the types of terminals in the loosely coupled network. The following describes the message distribution technique used relative to method or connection.
3705 Emulator program (EP) - All terminals which access TPF through a 3705-EP must submit their input to a specific loosely coupled processor, called the EP Processor. Therefore, message traffic distribution techniques are not available for terminals in this group.
3725 Network Extension Facility (NEF) -
TPF Network Extension Facility (NEF) support depends on either:
All subsequent occurrences of NEF in the text of this publication are superseded by the previous information.
All NEF terminals access the TPF loosely coupled complex through the 3725 NEF. Each 3725 with NEF is represented to each processor by one logical unit (LU). Message traffic from NEF terminals can be distributed across the complex by a user-written NEF exit routine. This routine resides in the 3725 and is link-edited with the NCP.
SDLC NCP Terminals - Message traffic from these terminals can be distributed across the loosely coupled complex by two methods. The first method is conceptually identical to the NEF approach where multiple LUs are assigned to each cluster controller. Each LU represents a port into the loosely coupled complex which can be used to route messages to a specific processor. The user must write code in the programmable controller to distribute message traffic. The algorithm for selecting the specific processor is left to the user to develop. Some valid algorithms are:
Send the first input to the first available processor, the second input to the second available processor, etc.
Define to each cluster controller a list of preferred CPU-IDs. The user's algorithm would then send each input message to the most preferred active processor.
In both algorithms, it is assumed that when processors are added or deleted from the loosely coupled complex, the algorithm automatically redistributes the input message traffic across the complex. Automatic redistribution of input message traffic based on the processor composition of the complex may not be desirable. For example, assume an unplanned shutdown causes the loosely coupled complex to lose a processor and the algorithm automatically directs traffic to the remaining processor(s). In this case, the CPU utilization on the remaining processors may reach 100%, seriously affecting response time. Therefore, algorithms with the ability to automatically redistribute message traffic when a loosely coupled processor shuts down are viable only if the remaining loosely coupled processors can assume the full network message traffic load.
The second method for distributing message traffic from SDLC terminals is to assign, at network definition, the ownership of each cluster controller to a specific loosely coupled processor. With this procedure, the user must attempt to balance the message traffic across the loosely coupled complex through the assignment of cluster controller ownership. This is the only method available for devices that are not user-programmable, such as 3274/3276 cluster controllers.
In a loosely coupled complex, there are two classes of messages which are routed between processors. These classes are:
The mechanism for exporting ROUTC requests to other processors within a loosely coupled complex is called System Inter-Processor communication (SIPC). The medium used for inter-processor communication is either a shared or dedicated file storage control unit.
Terminals in the CRAS table logged to the System Message Processor can direct an input message to a specific application, or the 'Z' command processor in a Subsystem or Subsystem User. This method can also be used to direct an input message to another system. To accomplish this, the operator enters a message in the following format:
aaaa/text
'aaaa' specifies a one- to four-character name (it may be an application name, a subsystem name or a subsystem user name) or ALL to indicate routing to SMP in all processors.
'text' is the data to be sent to the application and is forwarded without inspection.
For example, the following input from processor B would result in a display of main storage location 10 in Processor A.
SMPA/ZDCOR 000010
This function could also be used to invoke a user application in any processor. For example:
SMPB/RES0/OAA
input from processor A would result in OAA being sent to processor B for execution by application RES0.
The CCP provides the I/O programming required to support four distinct types of communications media:
Consequently, this package consists of four major main storage resident line control programs, and a collection of commonly used main storage resident subroutines. In addition, there are a vast number of file-resident support programs, each of which is associated with one or more of the above line control programs.
This program performs all the major functions for the 1052 or 3215 and is composed of the following parts:
This program controls I/O operations between the CPU and 1052/3215 operator's console if the 1052 option is selected.
FRACTIONAL CHANNEL CONTROL PROGRAM
This area of the CCPNUC contains the routines which provide the overall control of the I/O operations on the multiplexor channel. Examples of routines in the FCCP are the General SIO and MPX interrupt analysis routines. The General Start I/O routine initiates all I/O operations for the main storage resident I/O initiation routines of the various line control programs (i.e., bi-synch). The MPX Interrupt Analysis Routine examines the Multiplexor I/O interrupt and directs the interrupt to the appropriate interrupt processing routine.
COMMUNICATIONS MACRO ROUTING PACKAGE
This area of the CCPNUC is responsible for directing macro requests to the proper macro routine based upon control unit type (i.e., 2703, 3270 Local, etc.). It also performs validity checks to insure proper macro inputs.
COMMUNICATIONS KEYPOINT UPDATE MODULE
This area of the CCPNUC contains the main storage resident code which is activated by the PKEY macro to initiate the update of a SLSTL entry or PKST entry.
COMMUNICATIONS MULTIPLE USED ROUTINES
This area of the CCPNUC contains routines and tables which are common to one or more of the line control programs.
1052/3215 I/O PROGRAM
This portion of the CCPNUC provides the support for the 1052 or 3215 console as an operator control station.
Of additional interest, the communications multiple used routines of the CCPNUC contains the macros (CRAS and SEND) which interface with the long message transmitter program and which output messages to the 1052/3215 I/O program.
This program performs most of the major functions listed above (see "FUNCTIONS") for the Synchronous Link lines and is composed of the following parts:
This program controls input and output on the Synchronous Link line. It also provides, by means of macro support, an interface between application programs and the Synchronous Link Control Output Message Handler (03-CMS).
See "1052 or 3215 Console" for description.
This program controls the sending and receiving of data on the BSC lines.
See "1052 or 3215 Console" for description.
This program controls the sending and receiving of data on the 3270 Local Lines.
This program also controls the I/O operations between the CPU and the 3270 Local or natively attached 3270 operator's console.
See "1052 or 3215 Console" for description.
Synchronous Link Lines (SLC), Binary Synchronous Communication (BSC), 1052/2315 Console, 3270 Local (LC) I/O Programs, and 3270 Native Console Support (NSC).
The programs comprising Communications Source receive complete or partial message or data segments from the OPZERO functions of the relevant line discipline programs. Translation, editing and message assembly is performed as required. The message or data having been prepared for further transmission in the network or for a system or application editor is directed there by the construction of a Routing Control Parameter List (RC0PL) and the activation of the Message Router (03-ROUT).
The following file-resident support program is associated with the 1052 line control program.
When the prime CRAS device, 1052, 3215, or 3270 local CRT is inoperable, this program attempts to find a substitute. First, it will look for an alternate 1052/3215 in the first slot (line 00) of the Line Status Table. If an alternate 1052/3215 is not available, it will next look for a locally attached 3270 CRT device and its cross-referenced printer. If this fails, it will finally look for a valid 1977, or a valid CRT (2915, 4505, or 3270) with a cross-referenced RO printer, in the CRAS Status Table (CR0AT).
The following file resident support programs are associated with the Synchronous Link lines:
This is a set of routines that controls the automatic handling of the link. It processes and generates LCB's as and when necessary.
This program handles data blocks received on a link. It performs validity checks on each block, and causes an ACK or NAK to be sent in reply. When a complete message has been accepted, the program reformats it translates the text into EBCDIC, and passes the message to the appropriate message processing program.
This program builds and queues output message blocks for transmission via synchronous link lines. These blocks may contain whole messages being transmitted for the first time, or whole or parts of messages that are being retransmitted due to reception of a NAK LCB.
This program sets up pointers to link and channel keypoints, and initializes queue control fields.
This program restarts the synchronous link lines.
This program allows the selective starting of synchronous link lines.
This program allows the selective stopping of synchronous link lines.
This program displays synchronous link line status information.
This program invalidates a synchronous link line on which a non-correctable error has occurred. It then restores the tables and controls associated with the line to their initial settings.
The following file resident support programs are associated with BSC lines:
This program is used to retrieve file segments of long messages on the BSC line queues. It also performs other functions requiring an ECB driven program such as releasing file pool records.
This program conditions the transmission control unit and initializes tables so that a BSC line may be started.
This program starts the sending and receiving of data on the BSC lines.
This program stops the sending and receiving of data on a BSC line.
This program allows the system operator to determine the status of a BSC line.
This program allows the system operator to balance the load between the two CPU's on a BSC line.
This program initiates and responds to request-for-test messages on a BSC line.
This document describes the routines that will invalidate, display status, start, stop and restart the 3270 local lines. They also are activated in the event of either correctable or uncorrectable I/O error correction procedures.
The following file-resident support programs are associated with two or more line control programs.
This program allows the computer room operator to display and modify the contents of the CRAS Status Table.
This program zeroes the CCP's error counts on file.
This program analyzes 3270 Local line, SLC, BSC control commands and routes the messages to appropriate line control routines.
This program will display, for computer room personnel, the status of the terminal interchanges on a given BSC line.
This program displays the current communications control unit configuration upon request from the operator.
This program periodically updates the CCP error counts on file from the error counts in main storage.
This program displays the CCP control unit or line error counts from file upon request from the operator.
The CCP has the ability to discontinue polling the 3270 Local lines based on the size of the input list. This program will display or alter these polling controls. For 3270 Local devices which are attention driven versus polled, the concept applies to whether or not to service the Attention interrupt. It is not applicable for a 3270 Local logged to "System Message Processor" (03-CSMP).
This program sends to the prime CRAS an error message identifying a failing control unit by symbolic control unit number when excessive control unit errors have been detected by the main storage resident CCP error routines.
This program turns down (invalidates) a line, or pair of lines, on which an non-correctable error has occurred. It also restores all tables and controls associated with the line.
This program restarts all the communications lines in the system. Appropriate programs are activated sequentially by this program to restart the BSC, SLC, and 3270 Local lines.
This program formats an error message, from information passed by the CCP, qualifying an error type that occurred on a communication line and sends it to the prime or RO CRAS.
This program initializes the communication table in the restart schedule.
The tables initialized are:
The program uses keypoint information in: