It is the responsibility of the system manager to set up and maintain the database of workstation name translations. This section describes the structure of the database and the modifications that the system manager typically has to make when installing the system.
The GKS workstation names are stored in a text file which is found by looking in turn for:
gns_gksnamesin a directory found by translating the environment variable
../etc/gns_gksnamesrelative to each directory on the PATH.
Each line in the file describes one workstation name and contains the name, the GKS workstation type that it translates to, the device name of the workstation, a short description of the workstation and, optionally, the network node from which the device is accessible and a sequence number (see section 3.1.3). The fields are separated by the slash (/) character and a complete record might look like:
However, the device name field is usually blank which means that the default device associated with the workstation type is used, the node field will usually be blank as it is only used on VMS systems and the sequence number will normally be absent; so most records in the file will be more like:
An explicit device name is only required when you need different names for two or more devices of the same type.
For X window devices the device name is used as the GWM window name, and the sequence number should be left blank.
The system is distributed with a file containing a name for every workstation type supported by RAL-GKS and so will work without any modification. However, programs that list the available workstations will present users with a long list of workstation names, many of which are probably not available, so the first task is to delete from the file the definitions for devices that are not available on your system.
As well as eliminating extraneous names from listings of available workstations this will also make
abbreviations more useful. For example, some of the names are somewhat unwieldy because they
have to be able to distinguish between different devices made by the same manufacturer such as
cifer_t5 for the Cifer T5 terminal and
cifer_2634 for the Cifer 2634. If, on a system with only one
sort of Cifer terminal the unwanted name is deleted, then
cifer becomes an acceptable
gns_gksnames you should test the system by running the demonstration program
described in section 2.4.
The IDI workstation names are stored in a text file which is opened in the same way as the GKS names files but with GKS replaced by IDI. Each line in the file describes one workstation name and contains the name, the IDI workstation type that it translates to (a two or three character code), the device name of the workstation, a short description of the workstation and, optionally, the network node from which the device is accessible and a sequence number (see section 3.1.3). For example:
The use of the node name field is the same as for GKS names (see section 3.1.1). For X window devices the first two characters of the workstation type must be ’XW’, the device name is a string (up to 10 characters) which is used as the GWM window name, and the sequence number should be left blank.
The sequence number can be thought of as a kind of serial number which uniquely identifies a device. The main purpose of the sequence number is to identify multiple names that refer to the same physical device (or workstation window). Each device has to have its own sequence number as in the following GKS example:
The sequence number refers to the physical device, so that devices that have multiple names should have the same sequence number. This also applies to devices that have multiple GKS workstation types, such as an overlay plane, or image display with VT terminal interface.
If a sequence number has been set in the
gns_gksnames file and the same device has an entry in the
gns_idinames file then it should be given the same sequence number (and vice versa). That is if a
device supports both GKS and IDI then the sequence number should be the same in both
files. Continuing the previous example the
gns_idinames file would have the following
A sequence number is an integer in the range 1 to 99. If the sequence number is not present in the database then a default value of 0 is used.
The workstation description file only needs to be modified if a new device type is supported by GKS so this section will only be of interest to someone adding a new workstation handler.
The workstation description table is stored in a binary file
gns_gksdevices (located in a similar way to
the names files). This binary file is built from a text version of the description table by running the
gksbuild is not normally installed and must be created by re-building the gns
The description table distributed with the system contains an entry for every workstation type
supported by GKS-UK and is built from the text file
gksdevices.txt which can be used as a template
for any changes or additions.
The text file looks something like:
Each workstation description starts with
WORKSTATION =type and contains a list of statements of the
The value field takes one of the following forms:
character is used as an “escape” character for inserting control characters (e.g. control Z (ASCII 26) is represented by
). A literal
character is represented by
The only mandatory keyword is
CLASS which indicates to which category of device
the workstation belongs and must have one of the following keywords as its value
For all workstation types other than those of class
DEFAULT_NAME is also mandatory. The value must be the name of the device used when
the workstation is opened with a connection identifier of 0. For devices of class
logged-on terminal is used in these circumstances.
Other keywords describe such things as the approximate size of “device units” and a character string that can be used to clear the text screen of a terminal.
A complete list of all the keywords that can appear in the description file can be found in appendix A.
There is an equivalent description file for IDI stored in a binary file
gns_ididevices (located in a
similar way to the names files). This binary file is built from a text version of the description
table by running
idibuild. At present the description table only contains one entry which
AGITYPE; this is mandatory for an IDI workstation. The text file looks something
1an image overlay is a graphics overlay that is also capable of plotting cell arrays