Browse Prior Art Database

Reducing Complexity of Terminal Network Application Support Programming

IP.com Disclosure Number: IPCOM000087237D
Original Publication Date: 1976-Nov-01
Included in the Prior Art Database: 2005-Mar-03
Document File: 4 page(s) / 61K

Publishing Venue

IBM

Related People

King, NJ: AUTHOR [+3]

Abstract

Summary. In order to reduce the complexity of the customer-written application programs in host-connected programmable controllers that support networks with large numbers of terminals, a subsystem management facility is designed to run in the system as application code.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 4

Reducing Complexity of Terminal Network Application Support Programming

Summary.

In order to reduce the complexity of the customer-written application programs in host-connected programmable controllers that support networks with large numbers of terminals, a subsystem management facility is designed to run in the system as application code.

The subsystem 11 (Fig. 2) is the interface between the actual customer task application program 13 and the control program 15 in the controller. The resultant terminal network that the customer will support with his task application program is reduced in complexity from the actual network of multiple terminals with concurrent transactions, shown in Fig. 1, to a virtual network of a single terminal to be supported in a single-thread fashion, shown in Fig. 2. This architecture allows the application programmer to address only that portion of his task application design that is concerned with the actual processing of the transaction data. His design is coded to deal with only a single terminal when in fact his program is supporting many terminals in a multithread fashion.

The subsystem management program has the responsibility for managing the host connections, the I/O to and from the terminals, the necessary subsystem buffers, the required message routing among the controller tasks, and the interface to the task application program.

Fig. 3 shows the primary routines that make up the subsystem and the interconnection paths between these routines. The main routine is the activity scan routine which acts as the activity scheduler for the virtual tasks. This routine has the responsibility for monitoring for activity pending in the form of I/O at the task, terminal or host level (paths 1, 2 and 3) or previous 1/0 that has completed (path 4). It also has the responsibility for causing a retry of an unsuccessful I/O attempt by periodically dequeuing requests that were queued (path 10). When the activity scan routine detects that the I/0 in progress has completed, the virtual task is given control (path 6). Control is returned to the subsystem from the virtual task when an I/O operation is requested (path 7) or the processing of the transaction is completed (path 14). The I/O Interface routine will direct the request to the terminal read/write routine or host read/write routine if a valid connection (path 8 or 11) exists. In the event that message routing is required, the request will be sent to the Station routine (path 12). If these routines are unable to complete the required processing, they will enqueue the request for a future retry (paths 9 and 13).

The buffer management routine is entered from the terminal routine to obtain a buffer for an initial read of the terminal (path 5). The buffer is freed at the completion of transaction processing (path 14).

Host Connections and Intertask Message Routing: The controller interface with the host is established by defining multiple logical connection path...