gtps4m1kSystem Generation

Operator, Terminal, and LU Identification and Control

The purpose of this function is to identify and control operators, terminals, or SNA logical units. This may be accomplished at two levels. At the gross level, the terminal is simply assigned to an application and the operator authorized to input data to it. This level is handled by the log processor. Some applications will require more precise control for which a group of records and support programming is available to facilitate user tailoring. (Application sign-on is level 2.)

Log Processor

The log processor component of the message router package performs the connection or disconnection of a terminal/logical unit to or from an application. This connection establishes a data path between the terminal and the application so that, independent of the physical location of the application in the network, all the data entered at the respective terminal/logical unit is delivered to the logged application for the duration of the connection.

Normally the connection is established by a login message (or logon for ACF/SNA), and ended by a logoff message. However, SNA logical units, except for NEF terminals, may be permanently logged to a specific application. Non-SNA terminals may be associated with 1 or more applications through the use of a log authorization table. This indication is recorded in the AAA/RCB initialization table (UAT), which is generated as part of the pilot tape (see Communication Pilot Record Generation).

All valid application names must be recorded in the routing control initialization table (RCIT), which also contains for each application: status information and the maximum number of logs allowed. Before a terminal/logical unit can log on, the application must be made active via a command. Once the log is successfully completed, the index to the application name table (ANT) is stored in the WGTA entry for the terminal. For SNA support, the index to the ANT is stored in the resource vector table (RVT). The application name table is a single main storage resident record containing up to 255 application names along with the respective addresses of the RCAT application names and the addresses of the RCAT entries.

Two levels of security may be implemented via the log processor. The security level will be indicated in the RCAT entry for each application. The two levels are as follows:

  1. At the first level, the application may be used only by authorized terminals. This is controlled by authorization indicators in the WGTA, for all terminals. There are three types of terminal authorization security:
    1. Permanently logged, as described previously.
    2. A terminal may be allowed to log on to all applications.
    3. A terminal may be allowed to log on to a specified list of applications. This list is contained in the terminal application authorization table (TAPP). There is one set of TAPP records for the system. Users must create the TAPP records either offline, on a pilot tape using the system test compiler, or online using the ZAUTH command.
  2. The second level of security, one designed uniquely for and by the application itself, may be required. This may be needed for accounting purposes, or for applications performing multiple functions, each of which require unique security codes, or for a variety of reasons known only to the application. This is not a system function but an application one; it must be designed by the user, and it is termed the application sign-on/sign-out procedure.

Sign-In/Sign-Out Procedures

When the RCAT entry for the application indicates sign in or sign out is required, an entry point is provided so that the application can notify the log processor of successful sign in. Once the log processor is so notified it no longer monitors messages from that terminal, but they are passed directly to the application until such time as the operator signs out and the log processor is so notified. The interface to the log processor is in the form of an application-to-application data transmission where:

For more details about the log processor, see TPF Data Communications Services Reference. For the SNA log processor see the TPF ACF/SNA Data Communications Reference.

Operator/Terminal Control

Over and above logging or sign-on/sign-out, TPF provides facilities for more precise terminal or operator control related to the input/output message stream and application work areas. These facilities are different in the SNA and non-SNA support packages.

Non-SNA support (including NEF):

  1. For ALC terminals, an agent assembly area (AAA) (or for 3270 local terminals a routing control block RCB) is permanently assigned (in the fixed file area) to each terminal attached to these lines. In addition, an RCB is assigned to each symbolic line (SLN) used in a BSC link for 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). The TPF host processor ID renders the RCBs unique in the communications network.
  2. Therefore, each RCB is identified by an address (LNIATA or SLN) and a processor ID. 3270 SNA logical units (SDLC terminals) with pseudo LNIATAs have RCBs assigned in the same manner as real LNIATAs. In order to retrieve a RCB, the communication source program invokes the read AAA/RCB program, which uses the WGTA to retrieve the address of the AAA or RCB.
  3. For MDBF users, each subsystem will have its own unique set of AAA/RCB records. It is probable that each subsystem will also have its own unique set of ordinal numbers for these records. In other words, a terminal that has access to multiple subsystems will most likely have a different record ordinal number in each subsystem. The subsystem ordinal table (SSOR) will be used by WGR to cross-reference a terminal to a subsystem ordinal number.
  4. If the source of data is a BSC link, the RCB is retrieved only if a multiple block transmission is received and, in that case, the RCB is used for message assembly and is not passed to the application program.
  5. The RCB contains a system area and an application work area. The system area contains a message assembly area and control fields for proper routing of messages to and from that terminal. For BSC the RCB serves solely as a message assembly area.
  6. Each RCB is initialized, when its terminal or link becomes active in the system, by the RCB initialization program (RCBI) from information contained in the RCB/AAA initialization table (UAT). Users must create the UAT using the system test compiler.
  7. The agent assembly area (AAA) uses the same concept, organization, and accessing method as the RCB. The same UAT and WGTA tables are used for the AAA and for the RCB, simply with a different record type. Non-LNIATA systems do not require AAAs or RCBs.

SNA support:

  1. For messages arriving via SDLC lines, logical unit control, logging information, and message assembly are handled by system records not used by the application; the resource vector table (RVT) and the node control block (NCB). These records must not be used by application programs and are not passed to the application input message editor program when the application is activated.
  2. An application may require a record for work space and for control of message input/output related to the logical unit. When the logical unit consists of multiple work stations, this will usually be essential. The scratch pad area (SPA) is designed for this purpose. There is one for each SNA resource in the network. It may be either a 381-or a 1055-byte record and is undefined except for a standard header and 13 bytes of control data defining the node. All SPAs are initialized via command (ZNSPA) by the SPA initializer program that (1) writes the header (2) copies the 13-byte data item from the resource resolution table (RRT) and (3) zeros the remainder of the block. User responsibility is to allocate the required space on the fixed file storage for the record size that fits the user requirements. The definition of the body of the record and any required initialization is also a user responsibility and normally should take place in the application input message editor.

In summary, user requirements for implementing operator or terminal control records are:

Communications Source Message Router and System Message Processor

The communications source package receives input messages from the various line discipline programs and from application programs for entry into the system. As appropriate it provides for:

If the user needs to modify the routing of input messages, there is a capability to write a user-specified exit routine to the communications source package which gets control upon each input message processed by the package. Use of this option is specified by using either the COMEXIT=YES keyword of the MSGRT macro or by using the ZSYSG command. In addition, the user must code the required logic into message router segment COBC. This segment is released with only a BACKC macro in it.

The router facility can be used with TPF tightly coupled (TC) support. TC support allows applications to run on more than a single CPU on processors with multiple CPUs. COBC, in addition to changing the destination application or the content of the input message, can direct the input message to a particular CPU (also known as I-stream) in the processor. Specific details for directing a message to an I-stream are given in the COBC commentary. When the default for the I-stream (0) is used, the I-stream scheduler selects an I-stream to balance the load between active I-streams.

For example, a user could write an exit routine to change the application input message editor program that is to get control, based on a unique primary action code in the input message itself. Therefore, a terminal logged to a particular application would not have to log off of that application and log on to another one simply to enter a single input message if the user exit routine could detect this condition based on the unique text in the input message. This facility is especially useful to MDBF users where the applications may be in different subsystems.

The system message processor (SMP) is a unique system-generated message router application that provides input and output processing of system control commands. It receives such input messages and activates the appropriate handling program (CVAA). All responses to commands and all unsolicited system messages are also transmitted by SMP.

The system operator console (prime CRAS) is permanently logged to the SMP application of the TPF host to which it is connected. All terminals logged to SMP, including the prime CRAS, have the capability to enter input messages to any non-SNA application by specifying the application name at the start of the message. This function is known as message prefixing.

In addition, each CRAS terminal can be designated via the ZACRS command to handle input or output for particular system functions. This is done via tables in the SMP command editor that specify a function code as well as the name of the segment that will service the message. The released SMP supports 7 unique functions:

These designations are done via assembler EQUATE statements in the RTCEQ macro and then entered as a 2-byte field for each unique command. The user may add additional functional areas by making use of the spare RTCDFCSx equates in the RTCEQ macro and updating the SMP command editor table (CVAB) to designate which commands will be sent to the new functional console. Specific information on how to implement additional functions as part of functional console support (FCS) may be found in TPF Data Communications Services Reference.

HPO feature users of either the loosely coupled facility (LC) or the multiple database function (MDBF) have unique requirements for SMP as follows:

  1. Each processor in the LC complex contains the exact same message router applications except for the system-generated applications, including SMP. In each processor there is an SMP application named SMPx, where x is the TPF processor ID that has been specified on the SYSID keyword of the CONFIG macro.
  2. MDBF users, in addition to the SMPx application that is automatically generated for the basic subsystem, must include an SMP application in each subsystem. This is done via a combination of the USER and SMP keywords on the MSGRTA macro. This is necessary to provide each subsystem with an input command capability. This also means that SMP itself (segment CVAA, and others) has to be allocated or loaded in each subsystem in addition to the BSS.