Programming with TIO

13 Asynchronous Devices

Programming with TIO

Programming Overview

TIO application programs can control remote terminals which are dedicated to the application. Since the terminal is not a remote console, the user is not confused by system messages or error codes. The application program can be tailored to the terminal user. Passwords and security features embedded in the programs can control access to sensitive information.

The ON-condition statements overlap I/O and processing. For example, instead of waiting for a terminal to respond to a prompt, the program does other processing until a carriage return is received from the terminal. If the input is not received before processing is finished, the program uses the WAIT statement to explicitly wait for the input.

Overlapping I/O and processing of other tasks is particularly useful in applications where several terminals are serviced by a single program. For example:

Programming Tips

The action and consequences of the CALL branching statement as well as not specifying a branching statement should be understood.

CALL

Program execution in the current environment is suspended when the interrupt condition is satisfied. A new environment is created and remains in effect until a SUBEXIT or SUBEND is encountered or another CALL statement is executed.

The CALL statement is recognized in all successive environments including the one containing the statement.

This program is a good example of how not to program with ON-condition statements. When subprogram X is called, the ON INPUT # statement is executed. The interrupt is defined in subprogram X and in subprogram Z. When both X and Z are exited, however, the interrupt is no longer defined.

No Branching Statement

Not specifying a branching statement informs the system of the programmer's intent to re-establish an interrupt condition in a previous environment. This serves to turn on the input or output interrupt. It is useful when switching environments or when changing a port's input/output state.

10     REQUEST 12
20     ON INPUT #12 CALL  X
30     WAIT

100    SUB X
110    A$=AREAD$(12)

170    ON INPUT #12
180    SUBEXIT

Using OFF INPUT # clears the branching statement of the ON INPUT # statement which was executed in the same environment. Therefore, an ON INPUT # with no branching statement will subsequently be ineffective.

10     REQUEST 12
20     ON INPUT # 12 CALL X
30     CALL Y

100    SUB X
110    OFF INPUT #12
120    PRINTER IS 12        The OFF INPUT #12 and ON INPUT #12
130    PRINT "..."          statements are executed in a different
                            environment than the initial
180    ON INPUT #12         ON INPUT #12 statement.
190    SUBEXIT

Programming Approaches

Once TIO statements and the concepts are understood, you are ready to begin programming. The most useful program approaches are introduced next.

Straight Line Approach

The following program communicates with one terminal. It demonstrates the ease of programming for one remote device. Later, the same program will be expanded for multiple terminals.

5      OPTION BASE 1
10     DIM A$[254] ,B$[254]
20     Port=11
30     REQUEST Port
40     PRINTER IS Port ,WIDTH(-1)
50     PRINT "Please enter your name:";
60     ON INPUT #Port GOTO Ini
70     WAIT
80   Ini:  A$=AREAD$(Port)                  *  Input data from the
90     PRINT "What's your street address"&A$&"?"* remote terminal;
100    ON INPUT #Port GOTO In2              *  equivalent to LINPUT
110    WAIT                                 *  A$ directed to the
120   In2: B$=AREAD$(Port)                  *  main console.
 .
 .
 .

Modular Approach

The modular approach to programming is useful when input from the terminal will determine which task is to be done.

In the following example, the program accepts a command from the terminal and the FNInterp function determines the task (X1, X2, and so on) to be done.

5      OPTION BASE 1
10     DIM Commd$[254]
20     Port=11
30     REQUEST Port
40     PRINTER IS Port ,WIDTH(-1)   ! This is the default width
for all TIO devices.
50     PRINT "Please enter a command";LIN(1);":";
60     ON INPUT #Port GOSUB Service
70     WAIT
80     END
100  Service: Commd$=AREAD$(Port)
110    ON FNInterp(Commd$)+1 GOTO Cmd_err;Call_x1;Call_x2
120  Cmd_err: PRINT "ERROR: COMMAND NOT RECOGNIZED."
130    GOTO Print_lbl
140  Call_x1: CALL X1(Commd$)
150    GOTO Print_lbl
160  Call_x2: CALL X2(Commd$)
170    GOTO Print_lbl
 .
 .
200  Print_lbl: PRINT ";";
210    ON INPUT #Port
220    RETURN

Array Addressing Mode

Expanding a program from accepting input from one terminal to accepting input from several terminals can be accomplished with little difficulty if the initial program was designed properly.

In the following example, the initial program is shown in the straight line approach example:

10     OPTION BASE 1
20     DIM A$(5)[254], B$(5)[254]
30     DISABLE
40     FOR Port=11 TO 14
50        REQUEST Port
60        PRINTER IS Port ,WIDTH(-1)
70        PRINT "Please enter your name:";
80        ON INPUT #Port GOTO Ini
90     NEXT Port
100    ENABLE
110    WAIT
200  Ini:  DISABLE
210    Port=(CURKEY-25)/3+11   !CALCULATE PORT NUMBER
220    A$(Port-10)=AREAD$(Port)
230    PRINTER IS Port,WIDTH(-1)
240    PRINT "What's your street address "&A$"?"
250    ON INPUT #Port GOTO In2
260    ENABLE
270    WAIT
300  In2: DISABLE
310    Port=(CURKEY-25)/3+11
320    B$(Port-10)=AREAD$(Port)

The DISABLE and ENABLE statements are used to protect critical sections of code from GOTO interrupts.

This program can communicate with four terminals because Eloquence always knows where to go when it gets an input line from terminal. Having the system keep track of program state flow in this manner is called an Implicit State Machine. This is further discussed later in this chapter.

Executive Mode

In the following example the Service subroutine is used as an input/output traffic manager. It is referred to as an Executive Routine.

5      OPTION BASE 1
10     DIM A$[254], B$[254], Input$[254]
20     DIM Buff$(5)[750]
25     State=1
30        DISABLE
40        FOR Port=11 TO 14
50          PACK USING P1;Buff$(Port-10)
60          REQUEST Port
70          PRINTER IS Port
75          PRINT "Please enter your name:";
80          ON INPUT #Port GOSUB Service
90        NEXT Port
100       ENABLE
110       WAIT
120  P1:    PACKFMT State, A$,B$
130   !
200  Service:DISABLE
205       Port=(CURKEY-25)/3+11
210       Input$=AREAD$(Port)
220       UNPACK USING P1 ;Buff$(Port-10)
230       PRINTER IS Port
240       GOSUB X
250       PACK USING P1;Buff$(Port-10)
260       ON INPUT #Port
265       ENABLE
270       RETURN
280   !
300  X:    ON State GOTO S1,S2,S3
310  S1:    A$=Input$
320         PRINT "What's your street address "&A$&"?"
330         State=2
340         RETURN
350   !
360  S2:    B$=Input$

This program demonstrates how PACK and UNPACK can be used to swap variables into and out of a common area. This program also illustrates how to use the Explicit State Machine approach.

Structured Programming

When the application program addresses one remote device with one task, you may only need to add a few statements to the current non-TIO program to drive that device. For example, assume a report is written at the end of the working day. Instead of outputting the report to the local (default) printer, the report is now to go to a remote printer. If this is the only remote I/O function the program performs, the only modifications needed are changing the device address in the PRINTER IS statements in the appropriate places.

The creation of a more complex TIO application program, however, usually consists of many tasks which may be executing concurrently. In the TIO environment, each remote device may be associated with a task which controls the processing and input/output associated with the others. If interaction is desired among tasks, however, you must ensure that it happens efficiently.

The multi-tasking environment is more complex than that of sequential programming for one task. The problems demand a highly organized and structured approach. Without such an approach, you may have a program containing persistent (but unrepeatable, under debugging conditions) interference problems among the tasks.

Structured programming is concerned with improving the programming process through better program organization. Structured programming techniques, such as constructive use of subroutines and subprograms, ensure that a program is understandable, easily modified and documented, and easier to debug.

Basic Structural Flow

The following diagram can be used for many TIO applications.

In regard to the above diagram, the following remarks should be made:

Initialize: The logic flow begins with the devices being initialized.
Wait: Once the initialization is complete, the program waits for input from one or more of the devices.
Input Traffic Manager: Input goes to the Input Traffic Manager routine which initiates a task.
Tasks: Each task is processed according to its priority.
Output Traffic Manager: If output is required, the Output Traffic Manager initiates and completes it to the appropriate device.
Terminals, Printers, Computer: The program waits in an idle state until the next input from the devices or until one of the traffic managers begins the next task.

Example Program

The program used to demonstrate the Executive Mode of programming was designed according to the preceding structural flow diagram.

5     OPTION BASE 1
10    DIM A$[254], B$[254], Input$[254]
20    DIM Buff$(5)[750]
25    State=1
30       DISABLE
40       FOR Port=11 TO 14
50         PACK USING P1;Buff$(Port-10)
60         REQUEST Port
70         PRINTER IS Port
75         PRINT "Please enter your name:";
80         ON INPUT #Port GOSUB Service
90       NEXT Port
100      ENABLE
110      WAIT
120  P1:    PACKFMT State,A$,B$
130   !
200  Service:  DISABLE
205      Port=(CURKEY-25)/3+11
210      Input$=AREAD$(Port)
220      UNPACK USING P1;Buff$(Port-10)
230      PRINTER IS Port
240      GOSUB X
250      PACK USING P1;Buff$(Port-10)
260      ON INPUT #Port
266      ENABLE
270      RETURN
280   !
300  X:    ON State GOTO S1,S2,S3
310  S1:    A$=Input$
320         PRINT "What's your street address "&A$&"?"
330         State=2
340         RETURN
350   !
360  S2:    B$=Input$
 .
 .

Transaction Driven Applications

The design techniques described here are suitable for the creation of application programs driven by external events, such as remote terminals controlled by users. The application program and each user exchange data in an interactive fashion. The program usually supplies prompts to facilitate communication. The user might supply commands consisting of keywords and perhaps parameters to direct the program into specific operating modes and input data when requested by the current operating mode. In response to user commands (or perhaps by default), the program may display CRT forms to facilitate data entry and may generate and transmit reports either directly to the user's remote terminal or to some other output device. Finally, in response to user commands which cannot be fulfilled, the program generates messages which give the user the proper course of action.

A transaction consists of a logically complete interchange of prompts, commands, processing, input data and output reports. A transaction may be as simple as typing in a single command, in which case the transaction is just the action performed by that command. Transactions should be kept as simple as possible, otherwise the operational requirements (user training, program reliability, etc.) become extremely demanding.

Transactions may be categorized as follows:

Security and overhead operations such as user sign on and sign off.
Data retrieval operations accessing a database or a normal file in read-only mode. The objective of the data retrieval may be either quick "on-line" access to information or a printed report.
Batch data-entry operations resulting in an intermediate or transaction file which is not the final end product of the application. The transaction file is later used as input in batch mode to a program which creates or updates the final end product (usually a database).
Interactive data-entry operations in which the database is updated immediately, making the updated information available to other users as soon as the transaction is complete. If this technique is chosen, the parallel maintenance of a transaction file, as in batch data entry, should be strongly considered to allow backup and recovery from errors.

Generally, an application program offering interactive data entry transactions must ensure that multiple users and their associated tasks are protected from one another. In the worst case, the designer may have to prevent any other access to the database while an update transaction is in progress. This includes data retrieval access in read-only mode since reporting of partially updated data may be unacceptable to the application.

State Machine Model

The State Machine Model is a conceptual framework for designing a TIO application package. It is used to keep track of where you are in the program, and how you got there. For example, in the array addressing mode example, the variable Port is used to inform the system of which terminal supplied input and where the input is to be stored.

In the executive mode example, the variable State is given a value when a routine has completed processing. When input is received from a terminal, State is used to determine the next task to perform. This method is called the Explicit State Machine Approach because the variable is explicitly assigned a value.

Controlling Your Application

The definition and priorities of the softkeys on the terminal you use to control the terminal(s) used in your application can have a strong influence on the performance of the application.

Therefore you must be aware of the relative priorities of the softkeys and the operations in your application. With this knowledge you will avoid unexpected results when running your application.

For example, if you decide that pressing a softkey on the terminal should never be allowed to interrupt your application, you should set the priority of all of the softkeys to a value lower than the priorities specified in your application program. This is done using the ON KEY # statement (refer to page 151 for the details of this statement).

Eloquence Language Manual - 19 DEC 2002