gtps4m1k | System Generation |
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.)
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:
- 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:
- Permanently logged, as described previously.
- A terminal may be allowed to log on to all applications.
- 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.
- 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.
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:
- The origin of the data is the application itself.
- The destination of the data is application CLGx (where x
is the processor ID of the TPF host in direct control of the terminal).
If the application sending the notification resides in a non-TPF host, the
processor ID would have been passed to it as part of the origin of the data in
the processor-to-processor message format header (data macro PP0SG). If
the application sending the notification resides in a TPF system, the
processor ID would have been part of the origin in the RCPL.
- The text of the data is the address (LNIATA CPUID) of the originating
terminal.
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.
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):
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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:
- 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.
- 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:
- Allocate the required number of fixed file records via SIP for the chosen
configuration, application, and design for the following record types, if
used:
- Routing Control Block
- Agent Assembly Area
- AAA Initialization Table (UAT)
- Scratchpad Area
- Operator Authorization Table
- Node Control Block
- Terminal Application Authorization Table
- Subsystem Ordinal Record.
- Create the pilot records, using the system test compiler, for initializing
the following records, if used:
- AAA Initialization Table (UAT)
- Operator Authorization Table
- Terminal Application Authorization Table.
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:
- Message translation and character deletion
- Message assembly and integrity
- The origin/destination connection, including user determination for MDBF
- Activation of the message router package or direct activation of an
application if it is locally (this TPF host) resident.
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:
- Prime CRAS (of the BSS in an MDBF system)
- RO CRAS (of the BSS in an MDBF system)
- A separate tape functional console
- A separate DASD support functional console
- A separate communications support functional console
- An audit trail console
- Real-time database services (RDBS), which is used by the TPF Application
Requester (TPFAR) feature and the recoup utility.
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:
- 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.
- 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.