a user-friendly interface adapter

A user-friendly interface adapter

A user-friendly interface adapter simplifies input computer commands for beginners, and also has advantages for experienced users. Using a 'black box' approach, Jonathan Bowen illustrates the features of a

general-purpose interface

Most computer systems do not give any indication to users of what input is required. A manual, whether online or hardcopy, must be consulted, or help must be obtained from an expert. This paper describes a 'black box' which may be placed between a computer and a VDU to rectify this situation. The user is prompted with possible inputs at any stage during command input. Other features include local command line editing, a command recall buffer and time/date facilities. The system may be adapted for different operating systems and VDUs if required.

microsystems user interfaces VDUs

Jonathan Bowen is a research officer working as a member of the Distributed Computing Project at the Programming Research Group in the Oxford University Computing Laboratory, UK. Until the end of 1984 he was a research assistant in the Wolfson Microprocessor Laboratory at Imperial College, London, UK. His

research interests include microprocessor applications, computer graphics and distributed computing.

An interactive computer interface using a character display and keyboard typically consists of a prompt character or string, after which the user must type in a command string or character. Normally the user is assumed to know what may be typed into the computer. In general, no message is displayed until the user types a command. If the command is invalid, the error message may be as unhelpful as simply printing the user's command string followed bya question mark (eg CP/M) or it may give some clue about how to find out more information about what you are trying to do (eg by printing 'Type HELP for more information').

Some operating systems such as UCSD do prompt the user with a list of possible options but these are the exception rather than the rule. Other more modern operating systems such as that on the Apple Macintosh use menus, windows and a 'mouse' for interaction. Such systems are usually standalone and single-user and are beyond the scope of this paper.

Computing Laboratory, Oxford University. 8-11 Keble Road, Oxford OX1 3QD, UK

E X A M P L E - U S E R I N T E R F A C E

One example of a helpful user interface is not on a general-purpose computer at all, but on a microprocessor development system, the Hewlett-Packard 64000. The system consists of one or more dedicated single-user workstations and other peripherals connected together by a GPIB interface bus.

The operating system runs on a dedicated 16-bit microprocessor in each HP64000 station and is particularly noteworthy since it uses 'directed syntax'. In this mode of command input, the user is always prompted with the system syntax which may be entered at the current position in the command line. A brief description of this method of command entry on the HP64000 is given here. A more complete description is available elsewhere 1.

Command options are entered using eight 'soft keys' just below the display screen (Figure 1). At any given point whilst typing in a command the current

0141-9331/85/09432-08 $03.00 © 1985 Butterworth & Co. (Publishers) Ltd

432 microprocessors and microsystems

Figure 1. HP64000 front panel display and keyboard

possible options are displayed just above each of the soft keys at the bottom of the screen. If more options are available then the rightmost key is used as an 'ETC' key to toggle the other keys through all the possible options.

On pressing a given soft key the associated option is entered at the current position in the user command area. If the main keyboard is needed (eg for a file name), then the option is labelled in angle brackets and use of the corresponding soft key causes a description of the desired stringto be displayed on the status line.

The command line may be edited using left and right arrow keys and characters may be inserted or deleted at any point using dedicated keys to the right of the keyboard. The command is executed by pressing the 'return' key at any time.

If the command line contains a syntax error then the cursor is positioned where the error was detected, an error message is displayed on the status line and the bell is sounded. The user may edit the line and reenter it using the 'return' key. Alternatively, the line may be retyped from scratch by pressing the 'clr line' special function key to clear the command line.

Recently executed commands may be recalled into the current command line by using the 'recall' button. This is useful if a command (or similar command since the recalled commands may be edited) needs to be repeated one or more times.

If an error occurs whilst executing a command then the bell is sounded and a message is displayed on the status line. Some commands also return other information on the status line. All the commands and options consist of English words which are normally self explanatory (eg 'edit' to invoke the editor).

The H P64000 screen layout is given in Figure 2 and a typical display is shown in Figure 3.

G E N E R A L I N T E R F A C E

Unfortunately, although the HP64000 can be used in terminal emulation mode to a remote computer via an RS232 connection at the rear and a Host PASCAL compiler is also available, the soft keys are not user

programmable. Thus, the system cannot be used to experiment with a general user interface using directed syntax. This facility would also be desirable for many user application programs. Hewlett-Packard could usefully add this facility using library routines callable from Host PASCAL programs written for the H P64000.

The H P64000 directed syntax approach was used as a model for a general-purpose user interface to a remote computer. In the interest of generality, it was decided to use a standard VDU with an RS232 port for the user interface. Most modern VDUs include function keys, arrow keys and the ability to move the cursor to any position on the screen, clear the screen or the current line etc. Thus an interface similar to that of the HP64000 is possible. The RS232 is the most standard computer-user serial line interface at present so it is an obvious choice as a communications link.

An advantage of using a VDU over a dedicated workstation is that existing VDUs may be used for the interface, thereby considerably reducing its cost on a per user basis. However, the interface must be flexible enough to support a wide variety of VDUs. The interface consists of a microprocessor-based 'black box' which is connected between the VDU and the computer system being used via two RS232 ports (Figure 4).

~ Displa¥ area (18 tines)

I I I I I

S,atu, ,ine I, ,ine i Command area (3 lines) I

L- _J [option=l option=2 option=3 option=4 option=5 option#6 option#7 option#Sj

Figure 2. Typical HP64000 screen display

Figure 3.

Computer

Figure 4.

HP64000 screen layout

IFIX Slow-speed interface

RS232 adapter

Equipment layout

High-speed RS232

vol 9 no 9 november 1985 433

FEATU R ES

The interface adapter and its software has been dubbed the Interactive Friendly Interface eXecutive, or 'IFIX'. The features of IFIX have been described briefly 2 and are covered more fully here.

Hardware

The hardware consists of a Motorola 8-bit 6809 microprocessor-based board including two RS232 ports implemented using 6850 ACIAs (asynchronous communications interface adapters), several static RAM/PROM sockets and an optional calendar/timer chip (Figure 5). Virtually any general-purpose 8-bit microprocessor could have been used. The 6809 was selected because emulation facilities and high-level programming support were available for this processor.

The prototype fits into a custom-made black slim- line metal box ~25 cm × 25 cm × 5 cm. Two 'power bricks' are included to provide + 5 V for the electronics and + 12 V / - 12 V for the RS232 interface. Subsequent versions could easily be made smaller than this and could be rack mounted if desired.

The only external connections are a mains supply lead and two standard RS232 25-way 'D' type connectors (one male, one female) to connect the computer and the VDU. The external controls consist of a single mains on/off switch. This avoids the problem of the user changing any settings. Internally, the baud rates for the computer and VDU RS232 connections are separately switchable to one of 16 rates between 50 and 19 200 baud. In a production model this could be set by software.

The VDU used with the prototype was a Televideo Model 950. This has many features which helped with the design of the interface. These included a row of function keys at the top of the keyboard, line locking to prevent the status, command and option lines from scrolling, a 25th status line to label the options with the corresponding function key names, and editing keys such as arrow keys and insert/delete character or line keys. Other VDUs may have fewer features making them less easy to use with the interface. However, modern VDUs are tending towards more rather than

~"Di s~a y~r e ~'L i'-n e s ~- 21T" . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

I I I I I /

~Status line (Line 22) Optional time/date

i " . . . . . . ~option#1 option=2 option#3 option#4 option#5 option#6 option#7 ~pti~nn#8 L F1 F2 F3 F4 F5 F6 F7 F8_j

Figure 6. VDU screen layout

fewer features since the use of microprocessors within the VDU makes these easy to provide at little cost.

The remote computer used for the project was an IBM 4331 mainframe connected via an RS232 patch panel and running CMS under VM. This was chosen because it was the computer most easily available at the time. Unfortunately a Unix system was not available at the time the project was undertaken. An interface to this operating system would be more useful since it is widely used.

Usage

To a user the adapter provides a more friendly interface for a VDU connected to a remote computer via an RS232 interface. All commands to be sent to the computer are entered on a command line at the bottom of the screen (Figure 6). Soft key options are labelled below the command line indicating the possible options at the current position of the cursor in the command.

A single command line of 80 characters has proved adequate in practice. This could be extended, however, to two or more lines using wraparound if this is necessary for a particular operating system. The H P64000 uses three lines since some of its commands can become verbose if many options are used. This is probably because the designers realized that the soft keys may be used to enter long command strings with ease.

E computer

Level converters

Figure 5.

Microprocessor bus

;850 6809

T I f n

I COM 5016 baud rate generator

Block circuit diagram

w

3x 253 PRC

- ]I"IE R558174 • realtime

4 ~tMC clock VDU

Level conveners

COM 5016 baud rate generator


Each option label may be nine characters long on a standard 80 character width screen with eight options and al lowing for a space between each option. This is enough to give meaningful labels. The name of the corresponding key on the keyboard is displayed permanently below the option labels. This makes it easier to find the correct key on VDUs with detached keyboards. In the prototype version this line is displayed on the 25th VDU status line which may be loaded with a user string on the Model 950. In a more general version it may prove necessary to move the status, command and option lines up one position to accommodate this line on VDUs wi thout such a status line.

Ideally the labels should correspond to a line of function keys at the top of the keyboard. Alternatively, if no funct ion keys are available, the numeric keys could be used although this may cause problems if one of the options is to enter numeric data. As on the H P64000 system, the rightmost soft key may be an'etc' key if more than eight options are available. In the prototype, however, like the H P64000, there are never more than three sets of options at any one level to allow speedy access. This could be extended if necessary on more complicated operating systems.

As on the H P64000, the soft keys are used to enter a command string at the current position in the command line and their functions and labels are updated automatically as the cursor position moves through the command. The command line is normally edited locally using left/r ight arrow and insert/delete keys before the command line is sent to the computer by pressing the 'return' key.

Previously entered commands are stored in a circular buffer and may be recalled into the command buffer, edited and retransmitted as desired. This is achieved by using the up and down arrow keys to scroll through the commands in either direction. The number of commands stored is l imited by the amount of RAM available. The command line may be considered as a one-l ine window into the circular command buffer. This is an improvement over the HP64000 which only allows searching in the reverse direction. This can be annoying since, when repetit ively pressing the 'recall' button, it is easy to go one command too far.

Characters arriving from the computer are buffered and displayed on the VDU screen as soon as possible. A status line above the command line indicates any errors which occur (eg parity errors). This line could also be used to display the time, date, baud rates etc. The local RS232 connection to the VDU may be high- speed (up to 19 200 baud) al lowing fast transfer between the adapter and the screen even if the remote computer runs at a slow baud rate (eg over a modem or a wide area network).

The options may be labelled with a meaningful name rather than the command string itself, if this is cryptic on a particular operating system. For example, one soft key on the prototype is labelled 'directory'. This puts the command name to list a directory in the command line. For CMS this is the string 'list'. The soft keys are then redefined to the options available for this command. If used with other operating systems, the same key could be used to produce a different command string. This would aid users who transfer between different operating systems regularly.

When a command is given to call up a program such

as an editor, the base level of command options may be changed to editor commands until the editor is exited when the options return to the standard operating system commands. Some options may be executed immediately if desired, ie a command string or character is sent directly to the computer when it is used. This is useful in a screen editor, for example, where keys may be used to scroll through the file being edited and insert or delete characters or lines. Many screen editors use control characters for these functions. Using the function keys means that each key is labelled with its operation and control character commands need not be learnt.

On most operating systems, the number of possible commands will far outstr ip the number of possible options (a maximum of 21 at any given level if the number of sets of commands using the 'etc' soft key is l imited to three). Thus, either a restricted set of the most useful commands must be given or extra levels must be introduced. For example, a 'compile' soft key could be available at the base level which will then allow the language to be selected. The user is allowed to type in any command directly even if it could have been created using soft keys. Thus, experienced users may type in commands which are not available using the soft keys as they would if the adapter were not being used.

If an option involves typing a string on the main keyboard (eg a file name) then pressing the corresponding soft key causes a helpful message to appear on the status line giving details of what is required. The command line and display may be cleared by pressing the 'clear' key. The cursor may be moved to the start of the command line by pressing the 'home' key. If these keys are not available on a particular VDU then control characters may be used. However, this involves more learning by the user, or special labels for the VDU keyboard.

In practice, as a user becomes more experienced, the positions of the soft key and other keys become well known and may be accessed with only a glance at the labels. New users will be slower but they wil l eventually find the key which they are looking for. Thus, the system is useful to both kinds of user. In addit ion the local command edit ing and recall buffer is a boon to all types of user, especially if the line to the remote computer runs at a slow baud rate.

Appendix 1 shows a short fragment of a possible interactive session to illustrate the adapter in use.

Software

Most of the software for IFIX is writ ten in HP64000 PASCAL to aid portabil ity. This version of PASCAL has various extensions to the standard language to aid programming of microprocessors. For instance, interrupt routines may be included and variables may be relocated to any memory address al lowing memory- mapped I/O to be performed directly. The only assembler code needed is for machine-dependent instructions such as the 6809 instructions 'AN DCC' and 'ORCC' for enabling and disabling of interrupts. The software is interrupt driven to avoid loss of incoming characters from the remote computer or the user keyboard.


The cursor is disabled and the status, command and option lines are locked whilst output from the remote computer is being displayed. This avoids annoying cursor flicker as it flashes across the screen and prevents the special lines at the bottom of the screen from scrolling. On VDUs which cannot disable the cursor, the display may look rather messy whilst it is being updated. If lines cannot be locked then the bottom lines may need to be redisplayed after the display area has been updated.

The initial prototype software is designed to run on a Televideo Model 950VDU connected to an IBM mainframe computer running the operating system CMS. The software is held in three PROMs, one containing the main program and the other two containing the computer-specific and VDU-specific routines respectively. This modular approach allows a different operating system or VDU to be catered for by simply changing a PROM. Alternatively, banks of PROMS could be switched in as necessary.

The operating system command information consists of a hierarchical tree of options which is descended each time the user edits the command line, to check the current options to be displayed. Thus, the microprocessor has to do a significant amount of work each time a key is pressed and around 100 characters may be sent to the VDU if the options change. In practice, with a high-speed RS232 link the delay is not noticeable to the human eye provided the cursor can be disabled during the update.

The overall structure of the interrupt service routine is shown in Figure 7. Each of the 'read' routines places the read character into a circular buffer. The buffer for the remote computer is large (eg 256 characters) to accommodate possible delays in the rest of the software. A message is displayed on the status line if the circular buffer for the remote computer is overfilled. Additionally an XON/XOFF protocol may be used to control the output of the remote computer depending

~.~nte rrupt

Rei~d character from remote

computer

Figure 7.

Read character from keyboard

1 C End

Interrupt routine

1 Update time I ioptionai) l

T

on the number of characters in the remote character circular buffer.

The circular buffer for keyboard characters is small (eg four characters). Type ahead is limited to this number of characters. This has proved desirable in practice since it prevents the 'auto-repeat' key on the VDU from filling the command buffer too quickly. Lost characters from the keyboard are ignored for this reason.

The calendar/timer chip may also interrupt the processor if this feature is required. This updates global variables containing the time and date together with an update flag. It has not proved necessary to use interrupts for the output of characters from the adapter in the current implementation although it would be possible to add this as well.

Figure 8 shows the overall structure of the rest of the software. The circular buffers and optionally the global time are monitored. If any change is detected then the appropriate action is taken. If nothing needs to be done then a'CWAI' instruction is used to wait for the next interrupt.

( h u,e )

Time update

Unlock VDU lines

TRemo~a [computer

character

Lock status/ command~option

lines

'Immediate command or RETURN key T o~er

keyboard characters

Unlock VDU lines

Otherwise

Update status line with new

time

Update main display

Send command or line to

remote computer

Figure 8.

Update status/ command/options lines as necessary

Main software structure

(End_)

Wait for interrupt


The 'lock' and 'unlock' routines only send the necessary escape sequence to the VDU if it is currently in the wrong state (recorded by a global flag in the software). Locking and unlocking the display on a Televideo 950 VDU repetit ively and too quickly has proved to cause the VDU to hang up until it is powered off and on again.

Advantages and disadvantages

The main advantage of ~he unit is increased ease of use of the operating system on the remote computer, especially for new users. The user is not left to guess what input is required. Other gains are applicable to all types of user. The main advantages of using the adapter may be summarized as follows.

• Directed syntax approach means faster input of commands and fewer references to manuals are needed.

• Local line edit ing means less CPU loading and faster input on slow-speed computer links.

• Recall buffer means easy reexecution and edit ing of previously used commands.

• Standard soft key labels and positions make transfer between supported operating systems easier for the user.

Apart from cost, the main disadvantage is the necessity of the interface adapter itself. A mains or +5 V / + I 2 V / - I 2 V supply is necessary together with extra RS232 cabling between the unit and VDU. The main disadvantages may be summarized as follows.

• Extra unit required between VDU and computer means greater cost, extra power and RS232 leads, greater possibil i ty of equipment failure.

• Some VDUs, particularly 'dumb' terminals, may not work well with the adapter.

• The adapter may not support all the facilities of a particular operating system.

If the adapter is kept close to the VDU (and this is recommended to keep the high-speed RS232 link short) then if the adapter does fail it can be removed easily and the VDU may be plugged directly into the remote RS232 line temporarily. Thus, its failure is not as catastrophic to the user as the failure of the VDU or computer.

POSSIBLE FUTURE ENHANCEMENTS

The adapter should be able to support a variety of operating systems as well as a variety of VDUs. Banked PROMs could be used for this, as discussed earlier.

The software should be table- and data-driven where possible. This makes it easier to incorporate support for new operating systems and VDUs. At present file names, for instance, are parsed by a special routine. Such strings should be described in more general terms. Regular expressions, as used in Unix 3, would be useful for this.

Some programs, such as some screen editors, may assume that the entire 80 × 24 character display of a standard VDU is available to them. In this case the status, command and option lines must be disabled whilst it is being used. It would be useful if the unit could be switched to such a mode both manually by

the user from the keyboard and automatically from the computer. The unit would be transparent to characters passing in both directions (ie it would act as if the RS232 links were connected directly through it) unti l some escape sequence was received from either end. In this case the soft keys could not be labelled on the screen (unless a 25th VDU status line was available on the particular VDU being used). However, they could still be used for functions if required.

A calendar/t imer chip has been included in the design. This could allow the t ime and/or date to be displayed on the status line if desired. It could also be used to load the t ime and date to the remote computer or vice versa. This may be connected to the FIRQ interrupt input of the 6809 rather than the IRQ input used by the ACIAs. This means less interrupt source detection software is required.

A future version of the software could load the command menu from the remote computer thus allowing individual users to tailor the adapter to prompt them with their most used commands. This would also allow individual application programs to use the adapter to prompt the user with possible options. The command menu could be an ASCII file which may be copied to and interpreted by the interface. This would allow easy edit ing on the remote computer.

For simplicity, the command line itself could be different from that sent to the remote computer. This would mean that a simple general-purpose set of commands could be selected. These could be the same even if a variety of operating systems was used. The command line would then be parsed and the appropriate command string, depending on the operating system, passed to the computer when the user presses the 'return' key. However, this would involve considerable extra software within the adapter.

The interface could be incorporated within the VDU itself since all modern VDUs are microprocessor based. This could simply involve software changes for some VDUs. A project of this type would probably best be carried out by the relevant manufacturer. Alterna- tively, the ideas of the interface could be incorporated into a cheap microcomputer with an RS232 interface such as the Acorn BBC. A profusion of ROM-based terminal emulators already exist for this microcomputer. One of these could easily be adapted.

UNIX INTERFACE

A useful application for the adapter would be a version for Unix since the standard user interfaces for this otherwise excellent operating system, the shells 'sh' and 'csh', and the standard program command names are notoriously unfr iendly and cryptic. For example the program 'Is' is used to list a directory.

Unix includes descriptions of a great many VDU characteristics such as cursor motion sequences, funct ion/arrow key output sequences etc, in a file called 'termcap '4. Addit ionally, a shell variable 'term', which gives the name of the terminal in use, allows access to the correct entry in this file. These could be used to automatically set up the terminal characteristics in the adapter and thus obviate the need to store a large database of VDU characteristics within the adapter itself.


The Berkeley Unix shell 'csh 's (C shell) includes a 'history' command which is made largely superfluous by the recall buffer in the adapter. Another useful command is 'alias' which allows the user to redefine a command string to another string (eg 'alias h history' allows the user to type 'h' instead of 'history'). This is useful for long but commonly used command strings. A similar facility could be included within the interface for use on any operating system.

An alternative approach would be to write a completely new shell for Unix which would drive VDUs using directed syntax. This is easy on Unix compared to other operating systems since the shell is just another program as far as Unix is concerned. A particular program may be specified as a user's standard log-in shell in the ' /etc/passwd' file.

Menu selection shells have already been written for some versions of Unix. One example suitable for the casual user is the Xenix Visual Shell 'vsh' for the IBM PC-AT 6. However, this introduces a considerable I /O overhead for the CPU so the distr ibuted approach of the interface adapter may still be preferable, especially on large mult iuser systems with many interactive users.

This distr ibuted processing is an advantage of the interface for all types of operating system since the command line is buffered within the adapter. Thus, lines are received by the computer a line at a t ime rather than a character at a time. This feature could be used to advantage in a specially tailored operating system since line edit ing facilities such as 'backspace' and 'delete line' are not needed for system commands when the adapter is used.

CONCLUSION

The 'black box' described here could be used with virtually any VDU with function keys and which is attached to a computer system via an RS232 interface. It improves the user interface by prompting the user with possible inputs rather than al lowing the user to guess them. It would be especially helpful for new computer users.

Further work needs to be done to make the unit into a useful general-purpose product. In particular a Unix interface would be most helpful. However, it is hoped that the ideas expressed here will be of interest to others involved in the design of user interfaces.

REFERENCES

1 64000 logic development system, system overview Hewlett-Packard, Colorado, USA (1980) Chapters 3 and 4

2 Bowen, l P'The Wolfson Microprocessor Research Support Unit, documentat ion and usage 1981- 1984' Publication DoC 84/25, Imperial College, London, U.K (1984) Appendix E

3 REGEX(3), Unix programmer's manual, 4.2 BSD University of California, Berkeley, USA (1983) Vol lb , section 3

4 Joy, W and Horton, M TERMCAP(5), Unix programmer's manual, 4.2 BSD University of California, Berkeley, USA (1983) Vol I b, section 5

5 Joy, W CSH(1), Unix programmer's manual, 4.2 BSD University of California, Berkeley, USA (1983) Vol la, section 1

6 IBM Personal Computer XENIX general information manual IBM, USA (1984) p 6

APPENDIX 1: AN EXAMPLE SESSION

This short fragment of a possible interactive session shows how the adapter could work with a Unix system (since more readers are likely to be familiar with this operating system). The sessions starts with the soft keys defined at the base level of the operating system.

directory remove move copy

1 2 3 I 4

i

I

link make__dir change__dir ETC

5 6 7 I 8

m

i

ACTION: press 'directory' (soft key # 1) RESULT: 'Is' entered on command line and soft keys

redefined as follows long group all size

i-number by_t ime reverse ETC

ACTION: press 'all' (soft key # 3) RESULT: '-a' option entered on command line and 'all'

label blanked out ACTION: press RETURN Key RESULT: command line 'Is -a' sent to remote com-

puter causing all files in the current directory listed on display screen and soft key labels to return to original values

ACTION: press 'ETC' (soft key #8) RESULT: soft keys redefined as follows

edit 'c' " pascal fortran

assemble load FILE ETC

ACTION: press 'edit ' (soft key #1) RESULT: 'ed' entered on command line and soft keys

redefined as follows FILE parent child home

1 2 3 I 4 I

root

ACTION: p ress 'FILE' RESULT: s ta tus l ine d i sp lays :

'ENTER: file n a m e up to 14 c h a r a c t e r s (de fau l t ---- n o n e ) '


ACTION: type file name (parent/chi ld/etc may be used to specify a file in another directory

RESULT: file name entered on command line ACTION: press RETURN key RESULT: editor entered and soft keys redefined as

follows: insert append delete find

substitute LI N E end ETC

ACTION: press 'append' (soft key # 2) RESULT: 'a' sent to remote computer and soft keys

redefined: TEXT

s l l0 II 3 1 4 1

end

ACTION: enter lines of text fol lowed by 'end' (soft key # 7)

RESULT: text and '.' sent and soft keys return to base level of editor

ACTION: press 'end' (soft key #7) again RESULT: 'w' and 'q' commands sent to remote com-

puter and soft keys return to base level of operating system

ACTION: press up-arrow key twice and press RETURN key

RESULT: 'Is -a' placed in command line and sent to remote computer again

ACTION: press 'c' (soft key #2) RESULT: command line cleared and soft keys redefined

to 'c' subsystem

preprocess compile

11112r debug load

61

verify beautify

3 4

run

17 10r ACTION: press 'verify' (soft key #3) RESULT: 'l int' (C program verifier) entered on com-

mand line and soft keys redefined to ' l int ' options

ACTION: enter desired soft key options and file name and press RETURN key

RESULT: ' l int ' invoked on remote computer


a user-friendly interface adapter

Documents