229

Developments and European Programmes

A User View of Virtual Terminal Standardisation

Brian G I L M O R E University of Edinburgh, ERCC, Jemb. Kings Buildings, May- field Rd., Edinburgh, UK

1. The Need for a Virtual Terminal Specification

Terminals are connected to computer systems by a variety of means: direct connection, circuit switch, local or wide area network. The character- istic behaviour of a terminal both for the user and the driver program differs according to the access method.

The model matched by most computer manu- facturers in the past was that of a simple, hard copy terminal which printed out a line at a time then moved one line down the paper. Although most terminals are now based on VDUs, the basic method of handling them has remained the same, the output being scrolled up the screen one line at a time. As a consequence almost all ASCII asynchronous terminals are capable of this mode of operation. When a process requires to use the terminal in a more sophisticated manner each terminal manufacturer has used a different method to drive such operations as "clear to screen" or "move to position x, y". Two methods are used by implementors to overcome the problem, either use a specific terminal type with a particular computer manufacturer, eg 3270 type terminals with IBM machines, VT100 type terminals with DEC V A X / V M S systems, or for the operating system, or particular process, to be capable of recognising a wide range of terminal types, possibly in excess of 30, such as with Unix systems.

North-Holland Computer Networks and ISDN Systems 13 (1987) 229-233

Typically, if an incorrect or unrecognised terminal type is used on a system this will lead to a lower quality of service to the user. One obvious example of this is the line by line use of an ASCII terminal on an IBM operating system.

The use of a terminal through a network causes new problems as the terminal may well be used to communicate with a number of different, incom- patible, hosts and inherent network delays can lead to differences in the way that the terminal must be handled.

The use of a Virtual Terminal Protocol removes these problems as it handles the communication in a device independent manner.

2. Requirements for a Virtual Terminal

The requirements for a VT are twofold, firstly the need to handle output to the screen and sec- ondly the need to control key strokes from the user.

The handling of screen output in a device inde- pendent manner by encapsulating screen directi- ves within a data stream have now been in use for a long period and the construction of a Virtual Terminal Protocol to remove the dependence on the physical hardware is not difficult. Of more interest is the handling of 'newer' characteristics such as emphasis, colour, different fonts and graphics.

Changing emphasis, colour and to a certain extent fonts is not substantially more complex than the simple requirements. Of much more in- trinsic difficulty is the handling of non-propor- tional fonts and graphics, a challenge which can not be met by any protocol which is based on a simple rectangular character matrix.

The problem of handling key strokes from the

230 B. Gilmore / A User View of Virtual Terminal Standardisation

user can be separated into the handling of echo and processing of special keys, such as insert line and delete line. The handling of echo is only complex in the networking environment. With a directly connected terminal, or one that appears to be directly connected, it is feasible to allow the host processor to receive each keyboard stroke and take the decision as to whether, when and where to place any echo characters.

The more conventional way to handle echo, eg using local echo, can cause destruction of the screen image as control over keystrokes is lost and so is not suitable for use in a screen image type process such as form filling.

Special keys cause problems with all types of connection. As with output each manufacturer has chosen a different method of signalling that a special key has been pressed. The most common method is via an escape sequence, for example the character escape followed by one to three bytes to define the key pressed. There is nothing in com- mon with the number of function of keys supplied on the keyboard.

forwarding set in use; so if the PAD is not for- warding all keystrokes then the sequence may not be correctly interpreted by the host.

Host applications software operating in this mode has full control of the screen image. The disadvantages of this use of XXX are as follows:

All characters typed by the user which are echoed to the screen must traverse the network twice. This is necessary to ensure that the host maintains full control of the contents of the dis- play.

Provision must be made in the host to support each terminal type attached to the network. Ta- bles must be built to describe the terminal char- acteristics such as erase screen and set cursor.

Across networks with any degree of inherent delay this leads to an extremely poor response for the user which is only tolerated because there is currently no alternative. The number of packets, and hence the cost of a call, generated by a user working in this mode is greater than the number generated by a simple line by line conversation due to the single character packets containing user input or the associated echo.

3. Problems with Networked Terminals

As has been shown above, handling terminals across a network causes additional problems to those associated with a directly connected termi- nal.

The most widely used non-manufacturer specific protocol in use is XXX (X.3, X.28 and X.29) [1]. These protocols describe a parameter driven service rather than a true virtual terminal model and were designed to provide a line ori- ented display with simple editing facilities. Host applications which require extensive control of the displayed image normally need more facilities than are provided in the terminal support. There is a tendency for hosts to use a particular mode of operation of XXX to avoid the restrictions.

Firstly, local echo of user keystrokes is sup- pressed. This avoids damage to the screen image from user keystrokes. Secondly, the parameter which controls how long the PAD waits before forwarding characters in its input buffer is set to a very low value to ensure the PAD will at tempt to send each character to the host as it is typed. A particular problem arises with escape sequences. The final character may well not be one in the

4. A Simple Screen Management Protocol

The heavy reliance on supporting terminal ses- sions across networks has generated a lot of user pressure to improve services. This has lead the U K Academic Community to develop a protocol, modelled as a intercept of the ISO Forms Class Virtual Terminal Service. The protocol is called the Simple Screen Management Protocol or SSMP

[21. SSMP is a half-duplex protocol. The control

and synchronisation, handled by the Session Layer in the ISO model is handled within SSMP. Con- nection establishment and Connection Release are Session Layer functions which are considered to be carried by lower level network services present- ing an essentially error-free environment to the SSMP application.

SSMP operates by enabling the host to define an arbitrary protected area, or box, on the screen. While the terminal end is processing the input characters it echoes them to the screen until the user presses a key which either moves the cursor outside the box or causes some other function, for example move a page, which necessitates action by

B. Gilmore / A User View of Virtual Terminal Standardisation 231

the host signalled by the transfer of the control token. While the host is processing the input, potentially redrawing the screen and redefining the box, any user keystrokes are queued and processing of them delayed until the terminal end has been passed the token.

4.1. Implementation

The protocol was published in July 1985 and work has continued since to provide implementa- tions. Newcastle University, who did the major work in defining the protocol, have written both a reference implementation in Pascal to provide a portable editor for a host system and a corre- sponding implementation for a micro to emulate the terminal end. The micro end has now been implemented on a number of micros including the IBM PC and BBCs. A recent development is a cheap micro in a package which is inserted be- tween a dumb terminal and a PAD enabling the terminal to work in SSMP mode. Currently less than 10 types of terminal are supported although new types are being added as the demand be- comes apparent.

4.2. Limitations

SSMP is described as a simple protocol because various restrictions were imposed in order to limit the scope of the problem and ensure that the protocol was developed in a reasonable time scale. The main limitations are - Characters in use must be in the 128 instances

defined in International Standard 646. - The Display Screen model is a rectangular ma-

trix of fixed size characters. - Control of font and colour is excluded and only

one display attribute can be used on a character position.

- The presence of a keyboard is assumed - Local processing capability is assumed.

5 . I S O S t a n d a r d s

The work in ISO to produce a VT protocol was split into a number of distinct parts. Each part describes a class of protocol and the service needed to support the protocol. The two classes that we are particularly interested in here are the Basic

Class and the Forms Class. Work in ISO pro- gresses through a number of stages, the standard is published first as a Draft Protocol (DP), then a Draft International Standard (DIS) and finally an International Standard (IS). Each stage is subject to a ballot, and there can be a number of ballots at any stage if disagreements still exist.

In June 1986, ISO published for ballot DIS 9040 and DIS 9041. These are the service and protocol standards for Virtual Terminals - Basic Class.

This VT draft standard is a true virtual termi- nal protocol and represents an improvement over the features offered by XXX. As such the prob- lems of handling a screen image rather than a scroll mode terminal have been addressed and thus removes the necessity of identifying the terminal type.

A number of features of the VT represent a significant advance over current facilities. The basic display object can be up to a three dimen- sional array, as against the typical 2 dimensional array. Rendition attributes such as emphasis, fore- ground colour, background colour and font have been defined.

There are a number of problems with the use of basic Class from the point of view of the need for full screen access. - The control in the basic protocol of input seems

little better than that offered by XXX. - It would appear to be difficult to handle special

characters without extensions although some functions have been implemented. For example, erase line, erase part of line and erase screen can be mapped but the functions which require the movement of text such as insert line do not appear to be present.

- There is no provision to handle a 'break in' from a user, and unsolicited messages from a host, for example a status message from the operating system.

- A large number of features are left to 'profiles'. Although there are a number of standard pro- files and others may be defined and registered it could lead to a number of implementations that use sets of incompatible profiles. An attempt has been made to address some of

these problems in the past year. Two provisional draft addenda (PDADs) have been published and cover the following areas. - Extended Facility Set

232 B. Gilmore / A User View of Virtual Terminal Standardisation

- Ripple Function The extended Facility Set introduces the con-

cept of addressable 'Blocks' and 'Fields' along with a number of additional control objects. It would appear that the offered facilities are enough to allow an efficient implementation of ' form fill- ing' across a network. It does not appear to ad- dress the needs of screen editors. For example, the control over input is still not sufficient enough to allow local control over cursor movement. When a user inputs a cursor key it would appear to be necessary to terminate the input and leave it to the remote end to action the cursor key and then set up another input sequence.

The Ripple function does enable a basic editing operation to be handled efficiently. It allows the insertion or deletion of single characters in an area with an automatic moving up or down of the rest of the characters.

Another major problem with the current set of standards is the lack of a defined user interface. The effect of this is that the text of the standard does not define what the effect of the operations defined by the standard. For example, the display object is three dimensional. It could be possible for two implementations to have different inter- pretations of what the dimensions mean, with the horizontal and vertical directions represented by different dimensions of the array. While this seems rather unlikely it does point out the work that is still required by either ISO or potentially a Func- tional Standard.

6. The Impact of Personal Computers

With the first influx of personal computers there was an assumption that mainframes or even minicomputers would no longer be necessary. The reality is somewhat different. First of all the penetration of PCs into user communities has not been as complete as some people predicted, sec- ond, those with PCs discovered that not all func- tions can be handled by their own machine and limitations of store, disc or compute power means that they are also used as terminals.

The current method of connection of a PC to a larger machine tends to be implemented via sim- ple terminal emulation software in the PC. This method of course means that the functionality is little better than the emulated terminal although

one would expect to be able to exchange files with the host machine.

The availability of a user programmable processor within the PC makes it ideal for hosting a Virtual Terminal Protocol and, if anything, tends to highlight the need for such a protocol.

The use of a Virtual Terminal emulator is not the ideal solution. A better model is a much closer relationship between the PC and its host com- puter, possibly executed with the use of remote procedure calls to allow the user to call upon the resources of the larger machine without the incon- venience of 'leaving' his known environment. The protocols necessary to implement any general solution to this problem are potentially more dif- ficult than VT protocols and so will not be seen for a correspondingly longer period.

At first sight it might appear that the part file access parts of FTAM could be used to provide these facilities, in fact FTAM does not provide enough functionality for the purpose. One require- ment for such a protocol is that the user end would wish to send the 'host ' end a request to 'send the block of text which contains a given string'.

7. Conclusion

There is a significant user demand for Virtual Terminal facilities which are now being partially addressed by ISO. To a certain extent the problem is that the demand is for a moving target, whereas a basic VTP may have been sufficient a few years ago the current demand is oriented towards docu- ments with their problems of proportional fonts and the ability to mix text and graphics.

T h e use of micrcomputers as terminals will require a completely different style of protocol to make full use of the potential of the micro and mainframe combination.

These protocols will take a long period to ma- ture and in the shorter term it is important to give ISO encouragement to produce protocols that offer an advance over the existing, unsatisfactory posi- tion.

The current rate of progress in standardisation would indicate both the attainment of IS for Basic Class and the acceptance of the addenda by the end of '87 or the first quarter of '88. In order to

B. Gilmore / A User View of Virtual Terminal Standardisation 233

m a k e use o f these s t a n d a r d s it wil l be necessa ry to

s ta r t w o r k on F u n c t i o n a l S t a n d a r d i s a t i o n as soon

as poss ib le .

References

[1] CCITT Recommendation X.3, X.28 and X.29 (1980, 1984) [2] A Simple Screen Management Protocol - The Joint Net-

work Team, c /o Rutherford Appleton Laboratory, Chilton, Didcot, Oxfordshire OXll 0QX