gtpa2m0oApplication Programming

Activating the Application

This section discusses the log processor and conditions at activation.

Log Processor

When a terminal operator enters a message intended, for example, for a credit verification application, it is not practical for TPF to analyze the text of the message to determine its intended destination. Large TPF systems may host thousands of terminals and dozens of applications, each of which might have scores of unique message types. The TPF log processor resolves this problem and allows any terminal to be connected to any application in the network at a given time. This is not a hardware connection; by the use of the system tables and programs all data entered at the terminal for the duration of the connection is delivered to the application requested.

The connection is established and terminated by log messages from the originating terminal. A terminal operator gets access to an application with a login message and terminates the connection with a logout message.

The system tables that are used to maintain terminal to application logging are mostly transparent to the application, so we will discuss them only briefly.

Application Name Table (ANT)

This table contains an item for every application in the system to which a terminal may log. Each item has the 4-character application name that would be used in the login message and status information about that application. Each item contains a pointer to that application's entry in the routing control application table (RCAT).

Routing Control Application Table (RCAT)

The RCAT has more detailed information about each application and pointers that enable efficient routing of messages. Included in each item are:

Operator Security

The RCAT also indicates that the sign-in or sign-out function is supported by the application.

This level of security is designed uniquely by the application. This security may be needed for accounting purposes, for applications performing multiple functions each of which require unique security codes or for a variety of reasons known only to the application.

Although sign-in or sign-out is not a TPF operation, the log processor includes an interface for it via a sign-in or sign-out procedure. If the RCAT entry for the application indicates sign-in/sign-out is required, this interface allows the application to notify the log processor of successful sign-in. Once the log processor is so notified, it no longer monitors messages from that terminal. They are passed directly to the application, until such time as the operator signs out and the log processor is notified.

The interface to the log processor is in the form of an application to application data transmission where:

Resource Vector Table (RVT)

The RVT is used for SNA terminal definition and control. There is an item in the record for each network resource in the network. When an SNA terminal logs in to an application, the RVT item is updated with an index value that serves two purposes. It indicates that the terminal is logged to an application, and it points indirectly to the RCAT item that gives the routing data for that application. When the application being logged on to is a non-SNA application, the WGTA table will also be updated.

WGTA Table (WGTA)

This table serves a purpose for non-SNA terminals similar to that of the resource vector table for SNA. When a terminal logs in to an application, the WGTA item for that terminal is updated with the index value pointing to the routing control information. WGTA contains either the RCB or AAA addresses. (See Routing Control Block and Agent Assembly Area).

Conditions at Activation

To recap, once a terminal is logged to an application, subsequent messages from that terminal are routed directly to the application. The application message editor for the application is pointed to by the RCAT. When COMM SOURCE completes its processing of the input message, it passes control to that program. Figure 1 shows the conditions at that point.

In summary:

Input Data

Input messages are presented to the application in a standard format described in the AM0SG DSECT or c$am0sg.h header. TPF performs the following processing before presenting a message to an application:

By including the AM0SG DSECT or c$am0sg.h header, the application program can address the fields in the message with the symbolic names in the header.

If the application requires you to use the older input message format (the MI0MI DSECT or the c$mi0mi.h header), it is the responsibility of the application input message editor to reformat the input message to that older format.

Table 3. Input Application Message Format: The c$am0sg.h Header

Data Type Displacement (Bytes) Symbolic Name Description
char 0-1 am0rid Record identification: MI for input
unsigned char 2 am0rcc Record code check (not used)
unsigned char 3 am0ctl Control byte
char 4-7 am0pgm Filing program (for TPF use)
unsigned long int 8-11 am0fch Forward chain - Must contain address of next file record (must be zero if no chain)
unsigned long int 12-15 am0bch Last record in chain - must contain address of last record in chain (zero if no chain); used in prime record only, must be zero in all chain records
short int 16-17 am0cct Character count from byte 18 to end of text (text + 5)
unsigned char 18-20 am0lit Origin address; sequence number, record identification, or LNIATA
char 21 am0np1 Control byte
char 22 am0np2 Control byte
char 23-N am0txt Text of message, including any function management header or terminal control characters

Note that am0bch, which you might expect to be a back chain, is not used as such by the TPF message router.