Robot Operators Keystroke automation with Multi-Station
From "VS Workshop",  Access to Wang, December 1988
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Perhaps the single most frequent question that I get from readers is for some way to automate operations that cannot be controlled by procedures and must be performed after hours. Typical examples include packaged systems where no batch processing options are available and use of the operators console or other workstation-related functions. Most of us simply put up with this situation, hiring operators or spending long nights and weekends running reports.

For the adventurous, though, there is another way: simulating user keyboard input with Multi-Station Glossary language programs. In this approach, Multi-Station Glossaries take the place of the operator. Starting a pre-determined times, these robot operators enter keystrokes, run programs, review screen messages - even logging results. Though Glossary programming is hardly a trivial undertaking, it is often the best method of preserving sanity and personal time while still meeting the processing needs of the organization.

This month I'll cover some theoretical underpinnings for using Glossary programs to automate interactive tasks, with some examples next issue (including source code fragments) to get you started. In the meanwhile, let's review Multi-Station's components with an eye towards their use as a automation tool.

Is this a job for Multi-Station?

One of the strongest advantages of VS systems over other computing environments is that they offer a standard interface - the GETPARM screen - for task interaction. GETPARM screens are relatively easy to create within a program and allow both interactive (screen-oriented) and non-interactive (batch, or background) modes from the same interface. Unfortunately, the use of GETPARMs by no means universal: for whatever reasons, many packaged software systems are not equipped with GETPARMs and thus offer no means of performing resource-hungry operations after hours when system time is more available. Often the result of this situation is that users spend long hours in evenings and weekends running updates and reports.

Wang offered a possible solution in 1984 with the introduction of their Multi-Station product, which included a built-in language (Glossary) for workstation control. A powerful and practical system, Multi-Station remains one of Wang's most popular products. While Glossary offers abilities to examine all interaction with the workstation and even ajust it's behavior, few users delve much further into it use than to for simple features. It is this type of usage that I hope to elaborate on.

Multi-Station features

Multi-Station also offers two other major functions not available to users of standard terminals: including multiple simultaneous tasks (windows), and enhanced key functions. All are of interest to those wishing to automate interactive processing.

The primary purpose of the Multi-Station product is to "split" a single physical workstation between up to four simultaneous workstation sessions. In ordinary use, this allows long workstation tasks to continue in one "logical terminal" (window) while you are free to use another window for other purposes. These same abilities are also of interest to robot operators, since it is often possible to run several batch jobs at the same time.

Multi-Station's enhanced key functions extend far beyond the usual keyboard set to add greater abilities to manual or automated operations. Useful functions for operations automation include: the "(-1,1-)" key, which positions the cursor to the first position of the first column (not necessarily just modifiable text either, like "(-home-)"); the "(-picup-)" and "(-putdn-)" (pick up and put down) keys, which allow text on any part of any screen to be copied to another; and insert mode ("(-insmd-)"), where characters typed into a modifiable field "push" existing characters to the right. Again, this additional functionality is of benefit whether the workstation is under automatic or manual control.

The most interesting aspect of Multi-Station for those interested in automation lies in the associated Glossary language. Virtually any keystroke entered at the terminal can be duplicated with Glossary language programs. In many ways, Multi-Station Glossary is similar to Word Processing Glossary. Like in WP, you use key names to simulate actual keys and can test values on the screen. Multi-Station Glossary is more powerful, though, allowing many types of conditional testing to be performed. With careful attention to design, Glossary programs can even "read" information on the workstation's screen and change their behavior.

When to use Glossary

Multi-Station glossaries work best when the task to be controlled is simple and rarely changes. Examples include simple reports and some functions that are normally performed by the user, such as exits to the command processor or operator's console.

The limited amount of programming area - hence, the limits to the sophistication of the program - is a prime reason for NOT using Glossary programs for automation. It is not feasible to do much more than a cursory examination of specific screen areas to detect processing errors, and extensive alternate operations are unlikely. For this and other reasons, delicate processes (such as transaction posting) should be left under operator or procedure scrutiny. As a general rule, if the task can be controlled by a procedure (i.e. it is GETPARM controlled), this would be the preferred means since the procedure can more easily detect bad return codes and other error information.

Note also that a workstation must be logged on at the inception of the Glossary functions and all times until the job ends. This workstation must be placed in a secure area since any access to the terminal might allow tampering, cancellation, or review of the Glossary program. All it takes is a simple press of the HELP key (with its implied RESET) and an executing Glossary will abort, erasing all stored keystrokes.

Reprogramming the workstation

All items under of the control of the Multi-Station package - including window size and location, Glossaries, keyboard mapping, character sets, and miscellaneous workstation features - are contained within a small portion of microcode that must be loaded into the workstation. This file is referred to as a WORKSTATION PERSONALITY. In normal use, a single workstation personality file might be loaded at the time the user logs on and used for the remainder of the session. The larger needs of keystroke automation programs may exceed the programming area within a single personality and dictate that several different personalities be loaded over the course of processing.

Workstation personality files are maintained by the Personality editor, WSPERSON (a.k.a. PERSON). WSPERSON imports a copy of the user's default personality file (if held in the default library locations) and allows changes to this file. For operations automation, you must typically load another personality file (an option in WSPERSON) since it is unlikely you will want to use your personal workstation personality for automation purposes.

From WSPERSON, you select the option to edit Glossary information and specify the Glossary source file to be edited. Again, you will probably need to change the file name from the default supplied by WSPERSON. Once you specify the file to be processed, the Wang EDITOR is invoked and the file loaded. Like other VS languages, you must compile the program to produce the machine-language code required for execution. Once compiled, the machine-language code must be linked to a personality file. This link attaches the Glossary to the personality file CURRENTLY LOADED IN THE WORKSTATION; for this reason, I advise caution in editing and linking Glossary files to workstation personalities. (The WSPERSON utility allows you to accept (save) or reject any changes made during an editing session. This is a final chance to check your input files.)

While Glossary language programs can be developed in much the same manner as any other high-level VS language, there are several important differences. The most apparent of these is the severe space limitations imposed by Multi-Station: all of the compiled code must nestle within the 2048 bytes allowed within a workstation personality file. This is rarely a problem with routine glossary use, but can be troublesome if your task involves many keystrokes or sophisticated conditional testing - such as when attempting to automate an entire evening's batch jobs.

Other differences lie in the structure and use of the language itself. A subset of PL/I, Glossary syntax is closer to Pascal than COBOL. Routines (referred to as "procedures") exist apart from each other and share no data unless they use specially-defined variables; this practice allows the re-use of variable names and makes it easier to write generic procedures for common functions.

Publication space limitations do not allow me to describe much of the syntax of Glossary other than point out some of the features of interest for automation purposes. I recommend two approaches to learning Glossary: first, review the excellent sample Glossaries in the VS Multi-Station User's Reference (Wang publication number 800-1149-01); and second, try using the Glossary-by-Example function and Append function within WSPERSON to convert stored keystrokes into Glossary source code. We'll continue next month with a look at some sample Glossary programs and related procedures to load them.

Miscellany

Some time back, Wang announced intentions to support some subroutines and utilities formerly distributed by the International Society of Wang Users (ISWU). With the release of the 7.13 operating system, seven user subroutines (known as USERSUBS or ISWUSUBS) became supported products - VSSUBS. Now the Operating System Release 7.20 Software Bulletin (Wang publication number 715-1071) lists other supported items.

Subroutines to be supported by Wang include all of those listed in the VS USERSUBS Reference (published in 1982) plus HEAPCNTL, SCREEN, SORTCALL, SORTLINK, and TRANSFER. The utilities (USERAIDS or ISWUAIDS) to receive support include COBGEN, COMPARE, COMPILE, CREATE, EZPRINT, FILEDISP, PROCGEN, RPTGEN, SELPRINT, and TAPEDUMP. New documentation is also available, including the VS VSSUBS Reference (publication number 715-0599), the VS Media, Transfer, and Device Utilities Reference (publication number 715-1716), and the VS File Management and Application Development Utilities Reference (publication number 715-1715).