gtpd2m24Data Communications Services Reference

Processing Description

In terms of sheer logic, the purpose of the Message Router is to deliver a train of information to a destination, as specified by control information (destination address) in message headers. The origins of this data are other CPUs connected to the TPF system through SDLC lines, and applications or system programs requesting transmission services through the ROUTC macro.

The following information introduces some of the system records and tables used by the message router. This is necessary to understand the message processing description that follows. A more detailed structural description of this data is provided later in this chapter.

CI0CO
Routing Control Block

The RCB is a record permanently assigned to every terminal in the system which is referenced by a symbolic line number, interchange address, and terminal address. It contains a system area for use by TPF programs and a work area for the user. The system area contains information such as terminal description, routing information, etc.

SN0CT
BSC Station Name Conversion Table

This table contains routing information for BSC stations which are treated as terminals rather than processors.

RC0PL
Routing Control Parameter List

The RCPL is associated with each TPF input or output message. It provides information about the origin, destination and characteristics of the message. It is created by a component of the Message Router and used by system and application programs.

RC0AT
Routing Control Application Table

The RCAT is used to control the routing of messages in the computer network. It is used by the Message Router to determine the destination of a message, as specified in the RCPL.

WG0TA
Terminal Address Table

This table is used to find the ordinal number for the Routing Control Block associated with a given terminal. In addition, the WGTA contains the terminal status, terminal type, Application Name Table (ANT) index and indicators.

AN0NT
Application Name Table

This table is an array of the names of all active and inactive applications defined as existing in the system. A reference to the RCAT is maintained for each application.

RV1VT RV2VT
Resource Vector Table

This table contains the definition, status, and ANT index for every SNA Network Addressable Unit (NAU) defined in the network. The Application Name Table (ANT) index is a reference to the application name for which the Network Addressable Unit is logged in. The RVT is used by TPF system programs to control the status and flow of messages through the system.

Within TPF books, an SNA Network Addressable Unit (NAU) is frequently misnamed a node. SNA NAUs have three attributes, that is, a name, a 16-bit network address and a type. The NAU type is used to identify network function and is either System Services Control Point (SSCP), Logical Unit (LU), Physical Unit (PU), or Line. SNA nodes are of four types, that is, CPU, communications controller, cluster controller or Terminal. The name of a node, using SNA formalities, is the name of the NAU of type PU assigned to an SNA node. The substitution of Node for NAU, although unfortunate, is usually clear in context. For example, the Node Name Conversion Routine should be called NAU Name Conversion since it converts the name of an NAU of any type to a 16-bit network address and vice-versa.

Message Routing Example for Non-SNA Terminals

Multiple applications are active (capable of accepting and processing data) in the CPUs.

Since there is no activity in the system (no one is using the terminal), the system is idle and the communication control programs (CCP) is monitoring the lines for input.

System activity begins when a system user enters a message at a terminal. Since terminals can be used to access any application in the system, logically the first data input by the user would be a request to be connected to a specific application. Such a request is in the form of a log-in message specifying the desired application (for example, the application identified as APPL). As this message is received by the CCP in CPU A, the processing flows as summarized in Figure 7.

Figure 7. Flow of a Non-SNA Message Through the TPF System


  1. The Operational Program Zero (OPZERO) creates an ECB, formats the data in an input message block, and attaches it to the ECB.
  2. OPZERO gives control to the Communication Source Processor.
  3. The communication source processor determines if the terminal is logged into an application by interrogating the WGTA slot associated with the inputting device.
  4. Since the terminal was previously idle (not connected to any application), the destination of the data will be the Log Processor for path connection. The routing control block (RCB) is retrieved and a routing control parameter list (RCPL) is created showing the origin of the data as the terminal address and the destination as the Log Processor.
  5. The Log Processor is given control. After validating the message, the WGTA is updated with the application name table (ANT) index of APPL, a response is generated, the origin and destination fields are reversed in the RCPL (response to the originator), and the Router program is given control.
  6. The Router, after determining the terminal type to which the message is to be transmitted, invokes the appropriate TPF SEND processing routine for further data transmission processing.
  7. A message stating a successful log-in to the requested application is received at the terminal.
  8. Up to this point, we have emphasized the connection of a terminal to a specific application. All the processing has been confined to some components of the MR in CPU A. The terminal operator is now in a position to converse with the requested application, and he will do so by entering a message.
  9. All the steps leading to the WGTA slot referencing by the Communication Source Processor are executed (Steps 1, 2, and 3).
  10. The destination of this input message is determined by referencing the ANT index in the WGTA slot. This ANT index is actually a pointer to the application name (APPL) in the Application Name Table. The Communication Source Program references the Routing Control Application Table (RCAT) entry for APPL (pointed to by the ANT) to determine the location of the destination application APPL. An RCPL is created showing the origin of the data as the terminal address and the destination as APPL. The Routing Control Block (RCB) associated with the inputting terminal is retrieved also, if required.

    (The possibility of APPL being inactive is not taken into consideration here because if that were the case, the Log Processor would have rejected the previous request for terminal connection.)

  11. The RCAT table would then provide the ENTER to the APPL Input Message Editor. (The Input Message Editor for an application is the program which understands the format and the significance of all the messages directed to the application.)
  12. Ultimately, the APPL Input Message Editor calls (through an ENTER macro) an application program to accomplish the unique interpretation of the textual content of the message.
  13. The application program, after generating an output message as a response to the terminal (possibly using the system formatting services) uses a ROUTC macro to transmit the output message. Normally, an application will avail itself of the system formatting services as specified in the Mapping Support Package. This package constructs, formats and transmits data streams on behalf of an application, thus rendering the application independent from physical device characteristics.
  14. A parameter of the ROUTC macro is a pointer to the RCPL which would have been set up by the application showing the origin as APPL and the destination as the terminal address. The application would have used the simple technique of primarily reversing the origin and destination fields in the original RCPL created by the Communication Source Program and transferred to APPL.
  15. As a result of the ROUTC macro being executed, a component of the Router is invoked which, after determining the type of the terminal specified as the destination in the RCPL, transfers control to the appropriate TPF SEND processing routine for data transmission.

    The above described process continues message after message, transaction after transaction, until the terminal operator enters a log message indicating a request for:

    1. Disconnection from APPL, in which case the Log Processor would update the terminal's WGTA entry to indicate an idle condition.
    2. Connection to another application (for example, ABCD). This would be interpreted as request (l) plus a request for connection to application ABCD, which would be processed as in Steps 4 through 7.

Message Routing from SNA Terminals

A log in message from an SNA terminal reaches a software package within the VTAM CMC called Unformatted System Services (USS). Through the facility of the Systems Initialization Package (SIP) and the Offline SNA Table Generation (OSTG) program, a remote TPF application, to be reached by an SNA terminal over an inter-processor link is identified as a local SNA resource of CPU A. Upon receiving a session initiation command, the TPF system binds the terminal to the LU within CPU A. For data (FM) messages that follow the session initiation commands, the Communications Source Program invokes the same logic described in the steps following 8 in the previous example. (This logic represents the LU with which the terminal is in session.)

The RVT, rather than WGTA, is used when the input is received from an SNA terminal. The router logic uses SOUTC macros for SDLC transmissions. Furthermore, address conversion (RID to pseudo LNIATA) is performed if the application indicates that it depends upon the use of an RCB.

Figure 8. Flow of a SNA Message Through TPF


Message Format

The basic type of message format used by the Message Router is AM0SG, which is the Application Message Format.

The AM0SG format is used when the TPF system passes a message to an application's Input Message Editor program for processing, and when an application program (or the System Formatting Services Mapping Support Package, on behalf of an application) passes a message to the TPF system for routing to its destination (either a terminal or another application).

The Communication Control Program (CCP) components that are processing data for various line disciplines handle message blocks in different formats depending on the line protocol and the technique used to process I/O operations on the communications lines.

As a result, various message block formats and definitions are used by the CCP components interfacing with the MR facilities. Figure 9 describes the message format interfaces as they apply to the MR components overviewed prior to this section.

Application Message Format (AM0SG)

The Application Message Format, together with the Routing Control Parameter List format (RC0PL), constitute the Application Program Data Interface to the TPF system.

When an application program receives a data message from the MR, the input message as described in AM0SG is attached to the ECB at data level zero and the RC0PL, which may be of variable length, is in the ECB work area as described in RC0PL.

When an application routes a message to a terminal or an application program, the AM0SG format is used as input to the ROUTC macro. The program interface is found in TPF General Macros, describing the ROUTC macro. The AM0SG format is also used by the System Formatting Services (Mapping Support Package), which formats and controls the output data for an application program.

Figure 9. MR Message Format Interfaces


Notes:

  1. There is no document describing the format of message blocks for the directly attached terminal operations (i.e. 3215/1052). Information relative to I/O programs can be found in 03-CCPNUC. The DSECT used is CM0MSG defined within the macro LINEQ.

  2. The DSECT used is CM5MSG, defined within the macro LINEQ.

  3. The DSECT used is CM0MSG, defined within the macro LINEQ.

  4. The DSECT used is CM8CM. Each message begins with a header.

  5. The DSECT used is CM5MSG, defined within the macro LINEQ. Each message begins with a header.

Communications Source Program

All communication with the various sources of input to the TPF system is controlled by the Communication Control Program (CCP). The sources of input come from either a communication link to another CPU or from lines attached to remote concentrators. Various line disciplines are used (that is, NEF, SLC, BSC, SDLC) which imply unique differences in channel programs and procedures used by the CCP. For the purpose of focusing on the objective of this chapter, the CCP structure used in the execution of the many communication I/O requests will not be described here. All the details are given in the referenced TPF books. The component of the CCP which introduces all messages into the system and interfaces with the MR is the Operational Program Zero (OPZERO). The point of interface is the Communication Source Program. OPZERO is a collection of programs which are used to perform primarily the following functions:

  1. Create and initialize an Entry Control Block (ECB).

    The initialization includes the CPU identification field from information contained in a system keypoint. The CPU ID is used to give uniqueness to system entries within the domain of one CPU. For example, RCBs are uniquely identified by terminal address and CPU ID since different terminals in the computer network may have identical addresses when controlled by different CPU's.

  2. Link the message block to the ECB.
  3. Execute an ENTER macro to invoke the Communications Source Program.

    The exception to this is the OPZERO program processing input from SLC lines which initially directs the data to either the SLC Input Message Handler or the SLC Link Controller. This is necessary to perform functions which are directly related to the line protocol. (The same logic is not needed for BSC lines since all the necessary control can be performed at interrupt time).

    Different entrances to the Communications Source Program are selected by different OPZERO programs depending on the source of input. The main objective of the Communications Source Program is to place input data messages into common system format and create an RCPL. The RCPL contains all the information needed to select an application editor for further processing or to have the Message Router facility select a network path for further message routing. The Routing Control Parameter List (RCPL) is placed in the work area of the ECB. While different entrances to the Communications Source Program make use of different paths within the program itself, the primary logic and associated functions can be described commonly. Figure 10 represents an overview of the Communications Source Program.

Figure 10. Communications Source Program Overview




Processing Description of the Communications Source Program

Step 1a:
Locate the WGTA (Non-SNA Non-BSC) or the RVT (SNA) Slot.

Upon initial entry, the inputting terminal's WGTA slot is located through 03-WGR for non-SNA, non-BSC input. The WGTA contains pertinent information necessary to properly process and route the input request, such as terminal type, ANT index of the application to which the terminal is logged, and status indicators. SNA input will cause the RVT slot to be used, and like the WGTA, contains information required to process the input request.

Step 1b:
Retrieve The Routing Control Block (BSC)

As previously mentioned, an RCB is permanently assigned (in the fixed file area) to each NEF terminal in the system (computer network system). In addition, an RCB is assigned to each Symbolic Line (SLN) used in a BSC link for the purpose of maintaining common data relative to multiple transmissions such as message header information and data chaining fields. No RCBs are assigned to SLC links, BSC Stations or SNA Logical Units (SDLC terminals) with the single exception of 3270 SDLC terminals. The CPU ID renders the RCBs unique within the domain of one CPU. Therefore each RCB is identified by an address (LNIATA or SLN) and a CPU ID. In order to retrieve a RCB, the Communications Source Program invokes the Read RCB program (03- WGR). Using the address and CPUID of the given input source, the RCB ordinal number is obtained. 03-WGR obtains a file address from FACE (03-FACE) and retrieves the requested RCB. If the source of data is a BSC link, the link RCB may ultimately be substituted with a terminal RCB if, as described later, the origin is a NEF terminal and the destination is an application active in this CPU. The RCB for a BSC link is retrieved only if a multiple block transmission is received and is not passed to the application program.

Step 2:
Translate Message

The input data is translated to EBCDIC based upon the source of input. If the message comes from lines attached to remote concentrators (NEF or SLC lines) the WGTA provides information relative to the type of terminal and the translate tables needed to reduce the data to EBCDIC code.

Messages originating at 2915/4505/1977 terminals may contain backspace/erase characters in the data sequence. During translation these characters are identified and ultimately the Block Check Indicator (BCI) byte following End of Message is set to reflect this condition.

Messages originating from an SLC link are translated according to the technique used for SLC lines (see 18-SLC). At this point, SLC type B traffic (message switching) is assembled and ENTER macro executed which will give control to the message switching input message assembler (03-XIMA) for further processing.

Messages originating from a BSC link are translated if the BSC transmission code used is USASCII.

Step 3:
Build The Routing Control Parameter List (RCPL)

The RCPL is built in the work area of the Entry Control Block. If the source of input is a line attached to remote concentrators, information from both the ECB (Terminal address, CPU Identification) and the WGTA and ANT (Application ID, Terminal Type) is used to create the RCPL. If the source of input is a link connection (SLC, BSC) used for remote routing, the PPMSG header is used as a RCPL. In order to maintain continuity for functions supported in previous models of the TPF system, SLC lines may be used to link with systems not conforming to the MR standards such as SITA/HLN systems. If the source of data is this type of link, the RCPL is created using canned data generated by the user at system generation time). If the input source is a BSC line used for locally attached stations, the Station Name Conversion Table (SNCT) is used to build the RCPL. If the input came from an SDLC line, the Resource Vector Table is used to build the RCPL.

Step 4:
Determine Method Of Message Assembly

If message assembly is required, in order to eliminate excessive formatting of a message when its destination is not yet known, the Communications Source Program uses the Router Message Assembly Look-Ahead (03- RSAL) program to determine how an input message should be assembled. That is, what size main storage blocks and file records to use and what ID to use. The determination is based upon the message destination and the message type. For this purpose the RCPL previously created and the Routing Control Application Table (RCAT) are used to create a data assembly parameter list as defined by CDAP. This parameter list is used by the Communications Source Program to indicate to the General Purpose Data Assembly Program (03-CDAP) how to assemble a message (for example, chain in main storage or file, release input file addresses or not, block sizes to be used etc.).

Step 5:
Assemble Message

As previously mentioned, the General Purpose Data Assembly Program (03-CDAP) is used by the Communications Source Program to format and assemble input data before further processing is allowed to continue. This is done in order to place the message in a common system format (that is, AMSG) and to perform assembly for the segments of a multiple segment message. Data in the process of being assembled is filed to secondary storage and the address of the filed block is recorded in the RCB, which is retrieved prior to activating CDAP. Input message processing terminates at this point (an EXIT macro is issued) if a complete message is not available to the Communications Source Program. Otherwise, the result of CDAP processing is an edited input message in AMSG format.

Step 6:
Edit Message

Messages from 2915/4505/1977 terminals may require text editing when so indicated by the check character. Editing consists of:

  1. Removing NOP characters from messages originated at the RDI (Remote Display Interface) in the IBM 2946 Terminal Interchange.
  2. Removing backspace/erase characters if present in the text.

As the editing is performed the message is restructured to account for the deletion of data.

Step 7:
Determine If SNA LU Has Process Selection Vector (PSV) Defined

If a Process Selection Vector (PSV) is defined for the originating SNA LU, the appropriate exit is activated. PSVs are used to convert from the various X.25 protocols to the TPF protocol and visa versa. PSVs may also be used for conversion to and from 3270 and 3600 protocols. For detailed information on PSVs, see TPF ACF/SNA Data Communications Reference.

Step 8:
Determine Routing Of Assembled Message

At this point a decision is made to invoke (through an ENTER macro) the next component of the MR facilities to further process the data. The next component is either the Log Processor, the destination application or the Message Router program. If the source of input is a BSC link connection, and the destination is not a locally resident application, Message Router program is invoked. If however, the destination is a locally resident application and requires a terminal control record (RCB), the BSC link. RCB is replaced by the terminal RCB, as described in step 1b. The application is then activated by executing a direct ENTER (defined in the RCAT).

If the source of input is a SLC link the same logic as for the BSC input is followed. However, when the SLC link is used to control indirect terminals (that is, SLC/HLN connection) the determination for routing the message follows the logic used for input originating at directly controlled terminals (lines attached to remote concentrators). Therefore, with the exception of indirect terminal support, input from BSC or SLC links is never processed by the Log Processor.

If the source of input is a line attached to remote concentrators (terminal input) then the decision to invoke the next component of the Message Routing facilities is based upon the following.

The Log Processor is invoked when:

All of the above conditions are recorded in the terminal's WGTA entry.

The message router program is invoked when the destination is not a local application (that is, remote application, local or remote terminal, or logical unit).

The destination application is invoked when the application is locally resident.

Log Processor

The connection and disconnection of a non-SNA terminal to an application is performed by the Log Processor program. The terms connection and disconnection are loosely used to indicate the establishment of a data path from a terminal to and from an application. This is performed independently from the physical location of the application in the computer network. All data entered at the terminal for the duration of the connection is delivered to the application for processing.

Therefore, in order to converse with an application a terminal operator must first enter a log-in message. A log-out message is required to disconnect a terminal from an application.

There are two exceptions to the operator controlled process described above: 1) permanently logged terminals and 2) prime CRAS terminals.

Permanently logged terminals are terminals which are described to the system as having access to a specific application. LOGI/LOGO functions are restricted for these terminals. The Log Processor automatically logs these terminals in at restart time.

PRIME CRAS terminals are also permanently logged terminals. They are permanently logged into the SMP of their CPU. Unlike other permanently logged terminals, PRIME CRAS terminals have the ability to access other applications through the use of message prefixing. This function is activated by prefixing messages with the desired application name. For more details on this function see the System Message Processor (03-CSMP).

Note:
SNA terminals requesting Session Initiation/Termination through log in (LOGON APPLID) and log out (LOGOFF) commands are handled on the SSCP session by the Unformatted System Services component of the VTAM CMC.

Classification Of Non-SNA Applications

Applications in the TPF computer network are classified in one or more of the following categories:

  1. Unrestricted

    This class of applications can be used by any terminal operator without restrictions.

  2. Requiring Sign In/Out Procedure

    This class of applications require the user to follow specific sign procedures which are unique to the application itself. Therefore, a terminal operator must successfully sign-in to the requested application before the connection is completed and must successfully sign-out from the requested application before a disconnection becomes effective. Application sign processing is not part of the Log Processor. An entry point is provided so that the application can notify the Log Processor of successful sign procedures. The notification is in the form of an application to application message transmission. Before a sign-in can be accepted, the terminal must be logged-in to the application.

Classification Of Non-SNA Terminals

Non-SNA terminals can be classified by the type of authorization processing they require. Classification is defined in the AAA/RCB Initialization Table (UA1UA) and kept in the WGTA, and will correspond to one of the following categories:

  1. Permanently Logged - The terminal is logged in to an application at system restart time. The terminal operator is restricted from entering Log-in/out requests.
  2. Application Authorization List- The terminal is allowed to Log-in/out to a specified list of applications. This list resides in the Terminal Application Authorization List (TAPP) and can be maintained through the use of the ZAUTH command.
  3. Unrestricted - The terminal is allowed to Log-in/out of any application.

Log Messages for Non-SNA terminals

The following are valid log messages.

LOG IN: a. LOGI xxxx

Where:

xxxx
A 4 character application name (the name of the application to which the terminal operator wants to be connected).

Explanation: None.

Error Response: None.

System Action: None.

LOG OUT: b. LOGO

Explanation: Used to Log out of the application currently logged to and set the terminal to IDLE state.

Note:
A LOGI message can be used as a combination message to log out of the application the terminal is currently logged in to and log in to another application.

Error Response: None.

System Action: None.

DISPLAY c. LOGU xxxx UNSOLICITED MESSAGE/S:

Where:

xxxx
A 4 character application name (the name of the application to which the terminal operator wants to be connected).

Explanation: This message is used to display an unsolicited message originated by the application referenced in the message and directed to this terminal. More details on this type of message will be given in the section describing system usage.

Error Response: None.

System Action: None.

PURGE d. LOGP xxxx UNSOLICITED MESSAGE/S:

Where:

xxxx
A 4 character application name (the name of the application to which the terminal operator wants to be connected).

Explanation: This message is used to purge unsolicited messages originated by the application referenced in the message and directed to this terminal. More details on the use of this type of message will be given in the section describing system usage.

Error Response: None.

System Action: None.

Processing Description of the Log Processor

The Log Processor is activated by the Communications Source program when one of the following conditions exists as specified by indicators in the WGTA entry associated with the terminal inputting the data:

The following information introduces the concepts of screen formatting as it relates to the 3270-type terminals.

Display data, print data, or control data that is sent from the CPU to a 3270-type terminal is received and formatted at a control unit buffer and is then transferred to the device buffer. Conversely, display or print data that originates at a device is first sent to the control unit buffer, prepared for transmission, and then sent to the CPU.

A 3270 terminal can operate in one of two basic modes:

  1. With an unformatted display in which no attribute character (and, therefore, no display field) has been defined. The terminal is used in a free-form manner similar to the IBM 4505.
  2. With a formatted display in which a display field (or fields) has been defined as a result of storing at least one attribute character in the display buffer. The attribute characters define data fields with such characteristics as: protected (fixed format), unprotected (variable input data), alphameric input, selector pen detectable, and so on.

As a result of operating in one of the above modes, the input data sequence assumes different aspects. The presence of a set buffer address code (SBA) following the cursor address in the input data identifies the data sequence as being formatted. This knowledge is necessary to the Log Processor to be able to perform textual interpretation on the incoming data. (All the details relative to the 3270 terminal characteristics, functions and programming will be found in the referenced literature.)

In summary, the Log Processor has to be able to interpret data sequences input at non 3270-type terminals, and formatted or unformatted 3270-type terminals. Different components of the Log Processor analyze input data depending on the type and status of the terminal (these characteristics are reflected in the terminal's WGTA entry). This logic is schematically represented in Figure 11.

Figure 11. Log Processor Overview (LOGI/LOGO Message Processing)


Information about Figure 11

Step 1:
The format of the message is identified by analyzing the type of terminal and, if a 3270-type, the mode of operation (4505 simulation or native mode). Invalid Log messages are discarded and the inputting terminal notified. All messages sent by the Log Processor are transmitted by activating a component of the System Message Processor (03-CSMP).

Step 2:
The application name specified in the Log message is located in the RCAT table and its validity is verified. This is done by checking the application status.

Step 3:
For terminals requiring authorization through the application list, the Terminal Application Authorization Record (TAPP) is retrieved and scanned. The application requested is verified by locating the supplied name in the terminal's Authorization List.

Step 4:
The WGTA entry is updated to record the connection of the inputting terminal to the requested application.

Step 5:
A response notifying the inputting terminal of a successful log is then generated and transmitted to the terminal.

LOGU and LOGP messages are processed as in Steps 1, 2, and 3 above before activating the Unsolicited Message Processor which will execute the requested function.

Some applications are classified as requiring sign in/out procedures. This requirement is recorded in the RCAT table at the entry relative to the specific application.

In summary, the most important function of the Log Processor is to store the requested application reference in the WGTA. This is key to the entire TPF-MR structure since this application name is used by the Communications Source Program to build the Routing Control Parameter List, which is in turn used by the Router program to find a path for the data from the terminal to the application.

Message Router Program

The function of the Message Router program is to deliver data sequences to a destination as specified to it by control information (that is, the destination address). The origin of this data can be an external source (outside the logical boundary of the CPU) or an internal source (inside the logical boundary of the CPU). External sources are either lines attached to remote concentrators or communication links to other CPUs. Internal sources are either application or system programs requesting transmission services through the ROUTC macro.

The Message Router Program interface with external sources is either the Communication Source Program or the Log Processor. The Message Router Program interface with internal sources is the ROUTC macro interpretation routine as it will be explained below. Figure 12 is a representation of these interfaces.

Figure 12. Message Router Program Interfaces


The ROUTC Macro

The ROUTC macro is used by application and system programs to transmit a data sequence to a terminal or to an application. When the ROUTC macro is issued, the data to be transmitted is pointed to by a Core Block Reference Word in the ECB and the destination is included in a Routing Control Parameter List (RCPL) pointed to by a specified register. The data is in the format specified in AMSG, the Routing Control Parameter List is described in RCPL. Normally the RCPL would have been associated with the data input to the application's input message editor and passed to it by the Communications Source Program as we shall see. In this case the application program responding to the input would normally reverse the origin and destination fields in the RCPL before issuing the ROUTC macro. If a ROUTC is issued by a Subsystem to an application residing in a different subsystem of the same processor, the message is copied from the originator's file pool to that of the destination.

If a ROUTC is issued by a non-BSS Subsystem to a destination outside of the processor, it is first copied to the file pool of the BSS.

The macro interpretation routine will then either:

  1. Invoke one of the TPF routines which interpret the SEND macros.
  2. Issue a Control Transfer macro (CFXR) so that when the supplied ENTER expansion is executed at post interrupt time, a component of either the Message Router Program or the SNA Output Message Transmission Program is invoked for further processing. The RCPL would have been passed in the work area of the ECB and the data would have been attached to level 0 of the ECB.

Path (1) is chosen when the following conditions exist:

  1. The destination, as specified in the RCPL, is a terminal, and
  2. The terminal is not a 3284/3286-3, and
  3. The CPUID of the destination is this CPU or a CPU within the same loosely coupled complex, and
  4. The line address in the destination field of the RCPL is not an SLC pseudo line (indirectly controlled terminals) and
  5. The line number is not 00 or 01, and
  6. The data is a single segment message, and
  7. The RCPL does not identify the data as an unsolicited or recoverable (SNA only) transmission.

When all of the above conditions are met, a SEND macro interpretation routine (SENDA, SENDB, SENDC, SENDL or SOUTC) is invoked depending on the terminal type.

The ROUTC macro, as previously described, can be used by an application program to transmit data sequences to another application. As shown in Figure 12, the ROUTC macro interfaces directly with the message router program. Consequently, an application program is not required to log in to another application before it can transmit data to it. This is an important system wide general rule.

Processing Description

As mentioned before, when the message router program is invoked (through processing of an ENTER macro) a standard interface is supplied. This interface is in the form of the data to be routed (in AMSG format) attached to level 0 of the ECB and the RCPL in the ECB's work area (beginning in the first byte).

For the purpose of simplifying the processing description, the message router program can be subdivided into two main components:

  1. Local routing

    This component handles all routing requests when the CPU ID, as specified in the destination field of the RCPL, is part of the loosely coupled complex in which the Message Router Program is running.

  2. Remote routing

    This component handles all routing requests when the destination CPU does not reside in the same loosely coupled complex as the CPU in which the Message Router Program is running.

The determination of which component to use is initially made by the Communications Source Program based solely upon the CPU ID of the destination.

Local Routing
In a loosely coupled complex, it is occasionally necessary to route messages between processors in the complex. These special cases require an additional step for local routing, the exporting of the ROUTC. That is, the ROUTC macro will be sent to the destination processor through the System Interprocessor Communication (SIPC) facility for processing. The processing logic then proceeds as represented in Figure 13 and described below.

The type of destination, as specified in the RCPL, is analyzed and two different paths are taken depending on whether it is a terminal or an application.

If the destination is an application and the RCAT table indicates its availability, the application input message editor whose name appears in the RCAT entry relative to the specified application is invoked. The RCAT entry would contain the ENTER expansion for that editor.

If the destination is a terminal and the data being routed is an unsolicited transmission, as indicated in the RCPL, the unsolicited message processor is invoked for further processing unless the destination terminal is a receive only device.

If the destination terminal is a SNA logical unit and the message cannot be sent immediately (as in the case of a long message or recoverable message), the SNA output transmission program is invoked to send the message. For messages that can be sent immediately, the message is formatted and sent through the SOUTC macro.

If the destination terminal is attached through an SLC pseudo line (indirectly controlled terminal), the data is prepared for transmission through SENDK macro. This requires the use of additional control information (such as the High Level Network exit address (HEX), the remote link/system ID and the symbolic link number) needed by the SLC facility to perform and control data transmission. The message is then sent (through a SENDK macro) as an SLC high integrity message (a copy of the entire message is created on file).

For destination terminals attached through a NEF line the data is transmitted by issuing a SEND macro. The type of SEND (SENDA, SENDC, SENDL) used depends upon the destination terminal type as indicated in the RCPL. Multisegment messages destined for a video terminal are transmitted by retrieving the message blocks from file and issuing multiple SENDCs.

Note:
Message blocks are forward chained in the TPF file pool area.

If the destination terminal is a BSC station, its address may appear in the RCPL in one of two ways: as a symbolic address or as a symbolic name. If a four character symbolic name is used, it must be converted to a symbolic address before the SENDB macro can be issued. This is done by using the name to search the BSC Station Name Conversion Table (SNCT). If the name refers to more than one line (multiple BSC lines to the station), the line with the smallest queue is chosen and the SENDB macro is issued.

If the TPF system is unable to deliver a message to a BSC station, line fallbackis invoked. This consists of using the destination in the RCPL to search the SNCT and determine if there is another line to the BSC station. The fallback process is automatic if a symbolic name was used in the RCPL. If a symbolic address was given instead, line fallback will be done only if so indicated by the terminal type field in the RCPL. If another line is found, SENDB is issued for that line. When all valid lines have been tried without success, the message is returned to the originator with the returned message indicator set in the RCPL.

The issuing of an ENTER (to an application) or a SEND (to a terminal) concludes the logical process of the local router component.

Figure 13. Message Router Program Local Routing Overview


Remote routing
When remote routing is required from a loosely coupled complex, all non-SNA traffic must pass through the EP processor. If the LC processor involved in the routing is a non-EP processor, the ROUTC is exported to the EP processor through the SIPC facility. Remote routing then proceeds as described below.

The SDLC path will be used when both of the following conditions are true:

  1. Both the local and remote domains are the TPF system.
  2. The Functional Management Message Router (FMMR) logical unit is defined and available in the remote domain.

If the SDLC path is not available, then the message will be returned to the originator.

Remote Routing Through an SDLC Link

Processing of a message to be transmitted over an SDLC link to a remote domain involves the following steps:

  1. Locate the Resource Vector Table entry for the remote Functional Management Message Router (FMMR) logical unit. Processing differs based on the type of destination:
    1. Destination is an application.

      The name of the application is given to the NAU Name Conversion program, which returns the Resource Identifier of the application. From here on, processing is the same as step (a).

    2. Destination is a terminal.

      The CPU-ID field of the RCPL is used to locate the FMMR entry for the CPU-ID.

  2. Perform validity checks. The following checks are made:
    1. System must be in NORM state.
    2. The local and remote FMMRs must be in session.

      If any of these checks fails, the message will be returned to the originator.

  3. Reformat the message. If the original message is in OMSG format, it is changed to AMSG format. If either the destination or the origin field of the RCPL indicates an SNA logical unit, the name of the logical unit is obtained.
  4. Send the message. Messages transmitted over the SDLC link are always sent in the following manner:

It should be noted that if the destination processor is a TPF system, ultimately the Local Router component in that processor will ENTER the requested application input message editor (see Figure 13); that local router component may in fact be the Communications Source Program. The data in AMSG format and the RCPL are the standard input interface to the application.

Undeliverable Messages:

This component of the Message Router Program processes data that cannot be delivered to its destination by other components. Some of the reasons for not being able to deliver the data are:

The processing performed depends on the:

Application-To-Application Messages:

The returned message indicator in the RCPL is set. The origin and destination fields in the RCPL are reversed and the message is routed back to the originator. If the returned message indicator is already on, indicating that this message had already been returned and is on its way back to the originator, then no further attempt is made to route the message and the data is discarded.

Application-To-Terminal Messages:

If the error is encountered by the local router component (for example in the attempt to retrieve message segments from file) then a message is generated and sent to the destination terminal to inform the user of the lost message. If the error is encountered by the remote router component, Application to Application messages procedure is followed.

Terminal-To-Application Messages:

The terminal input message is discarded and a message is sent to the originating terminal informing the user of the inability to reach the application program. If the terminal is a BSC station, this is treated as a system error since the application must be active if the station is active.

The returned message indicator is a very important aspect of the Message Routing Facility because it influences the way application programs are designed. In fact the application input message editor has to distinguish between original data and returned messages and take appropriate action. More information is provided later in the chapter.

System Services

Up to this point the emphasis has been on the architectural structure of the MR facilities, which is the main objective of this chapter. We have also introduced additional system facilities that are used to perform specific functions, such as the System Formatting Services, the System Message Processor (03-CSMP), and the Unsolicited Message Processor. While we will not indulge in any more detailed description of the System Formatting Services (also called Mapping Support Package), it is necessary to give additional consideration to the System Message Processor and the Unsolicited Message Processor because they interface directly with the MR facilities and have an impact on the system interface with the end user (terminal operators).

System Message Processor

The System Message Processor Program (SMP) is viewed by the system and the system's users (terminal operators) as an application. The name of this application is SMPx where x is the CPU ID of the processor in which the program resides. This distinction is made to allow flexibility in the control of the computer network system as will be mentioned below. The implication of SMP being considered an application is that:

An exception to point (2) is made for the terminal designated as the Primary CRAS (PRC) for processor x. Whenever PRC requires access to SMPx, it is permanently logged into SMPx. A second exception to point (2) is made for applications inputting messages to SMP. This, as already explained, is a system wide general rule that applies to all application to application transmissions.

The primary function of SMP is to process operator commands ('Z' primary action code). Due to the nature of these messages, which are usually system control messages, only a selected group of terminals, identified in the CRAS table (CRAT), are allowed to input Z type messages. An exception to this general rule is made for a few messages. In TPF processor x, SMPx processes commands input to it and acts on system resources which are in the domain of processor x. In a computer network system, these commands may be received through a link from another processor. Consequently, a TPF processor y can be controlled by a terminal attached to a communication line controlled by processor x. This is possible if:

  1. The RCAT in processor x has an entry relative to SMPy.
  2. The terminal attached to processor x is authorized to use application SMPy. (Authorization verified through the log-in procedure.)
  3. The CRAT table in processor y contains an entry for that terminal.

Another discrete function of SMP is to process system output messages.

In this role, SMP is regarded as the output message editor for all system programs. Eighteen (18) user entry points are the interface for message formatting and transmission. For example, the Log Processor uses SMP to output most of its messages.

Unsolicited Message Processor

The unsolicited message processor (UMP) processes all the unsolicited messages addressed to a terminal. A message is classified as unsolicited when it is not generated as a response to an input message. The distinction between solicited and unsolicited messages is not made when the destination is an application rather than a terminal. Unsolicited messages originate at a terminal, in a TPF processor or in an SCP processor. They are identified as unsolicited by the textual contents of the input message if the origin is a terminal or by the information in the RCPL in addition to content if the origin is a program in a TPF or SCP processor.

The destination of an unsolicited message may be a specific terminal (single message) or a group of terminals (broadcast message).

For information about the unsolicited message processor, see Unsolicited Message Processor. The following describes how the unsolicited message processor interacts with the message router. Two major components of the unsolicited message processor process unsolicited messages in different stages:

  1. Initial processing required to queue messages and send notification to the destination terminal.
  2. Disposition request processing required to comply with the terminal user's request to either display or purge the unsolicited messages.

The initial processing component of UMP is invoked by the Message Router Program for processing unsolicited messages addressed to non-receive-only terminals directly controlled by this CPU. It is also invoked by SMP when an unsolicited message request is entered at a terminal. Since the request is in the form of a command, it would have been entered by a CRAS terminal logged in to SMP as previously described.

The Unsolicited Message Processor uses Unsolicited Message Directories (CODR) to maintain references to unsolicited messages until they are successfully transmitted or are purged as a result of a disposition request.

When processing an unsolicited message, a reference item is created and inserted in a directory record. The directory record is retrieved using the address of the destination terminal to compute the needed ordinal number within the directory's record type. A reference item contains information such as:

Broadcast messages require the creation of reference items for the addressed terminals through the use of the WGTA table (WG0TA). Once the unsolicited message directory has been updated, a notification message is sent to the destination terminal to inform the operator of the existence of the unsolicited message. This notification (whose form depends on the terminal characteristics) is immediately sent for all broadcast messages. In order to schedule delivery of these messages, an Unsolicited Notification List (CONL) is created containing the addresses of each relevant receiving terminal. This list is processed by a component of UMP.

For non-broadcast messages (single messages) the destination terminal is immediately notified of the existence of the unsolicited message. After receiving notification, the terminal operator may either temporarily disregard the notice or immediately request a display of the message by following one of the procedures described in System Usage Terminal Operations. The appropriate input activates UMP which retrieves and searches the unsolicited message directory for the proper item based upon an originating application and the operator's terminal address. The unsolicited message is formatted appropriately and sent to the requesting terminal through the ROUTC macro, the Output Edit CRT Driver (03-UIO) or the Output Message Transmission Program.

A third functional component of UMP will, on a time initiated basis, police the Unsolicited Message Directory (CODR) to again advise terminal users of unsolicited messages queued for the terminal. This policing function will also purge, out of the system, any messages not displayed after several attempts at notifying the terminal user. The purge function may also be initiated by a direct request from the terminal user. It is described in System Usage Terminal Operations.