Brain Savers Strategies to make your VS work harder than you do
From "VS Workshop",  Access to Wang, November 1989
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

From my first contact with data processing, I have devoted a large amount of time to defining and controlling my processing environment. From the specification of user usage constants through issues of screen design, workstation control, and PC/VS integration, I have always had a high commitment to perfecting the work environment. Frequently, this time has paid off in better and faster work; sometimes the rewards have only been the personal satisfaction of retaining my sanity in this stressful and sometimes tedious business. I have come to refer to this pursuit as Brain Saving - the conservation of brain cells through careful application of systems savvy.

The VS environment caters to those of us who desire a personalized system face with a rich assortment of methods of controlling the individual environment of the user. These methods include user defaults (usage constants), keystroke macros (the Multi-Station Glossary language), keyboard redefinition, the use of function keys for program access, and menu-driven software. With all of these resources, it's surprising to see how primitive the operating conditions are for the average VS user. Apparently most programmers and system administrators do not believe in substituting system resources for human effort.

I expect machines to work harder than I do, and I strive to improve that balance daily. The following three principles sum up this philosophy.

Principle One: The Best Keystroke is No Keystroke

Less is more when brain-cell conservation is the goal. The less routine typing you need to do to perform your job, the better you will feel at the end of the day. Strategies to accomplish this include:

• Use menus to define the face of your environment. Menu systems are all around you. Use them to tailor the system's face to the user. You don't have to type the name of a program on a screen over and over - make a menu instead!

• Use procedures to control the inner workings of programs. Control programs with procedures to match their use to your needs. It's silly to retype the defaults into the EDITOR's screens every time you edit a program, but that's exactly what most programmers do. Simple procedures can help avoid all this typing and ensure that these values are set consistently.

• Write Glossaries for frequently-used functions. Use the Glossary language of Multi-Station or commercial PC keyboard-enhancement software (such as ProKey) to turn a single keystroke into many.

• Use "cut-and-paste". The ability to copy text from one area (or window) to another is an important advantage to programmers and system administrators. If you have Multi-Station, the "pick up" and "put down" key functions are among the most important in my arsenal. If you don't have Multi-Station but use a PC as your workstation, you may also be able to use some of the commercial keyboard-enhancement software to perform this function.

• Create and load specialized DEBUG command files. Don't like the key options in the Wang debugger? Create a personal script file and change those options. Script files can be created in the Wang EDITOR (use "Procedure" or "Assembler" for the language option) and loaded with a Multi-Station glossary (see description, below). If you are debugging a large program, it might also be useful to create a script of the variables to be examined.

Principle Two: Learn To Use Tools

The VS is rich with tools, and the existence of a standard interface (the GETPARM) allows many of these tools to be tied together to form even more powerful tools. Tactics for reaching this goal include:

• Know about system tools. Learn all you can about the File Management Utilities, USERAIDs, and other utilities on your system. Use them instead of programs for ad hoc purposes. For example, the EXTRACT option of the Wang INQUIRY utility can be used to select test records from a production file for program testing.

• Be a tool-maker. Many repetitive tasks can be reduced with specialized tools, and many of these tools can be constructed of procedures and common utilities (CREATE, INQUIRY, etc.) - even if you do not have programming experience. Learn to recognize these frequent needs and create programming solutions to them.

Principle Three: Use Workstation Features

In the early days of the VS, a terminal was simply a terminal. Improvements began with the introduction of the Multi-Station product in 1983 and continue today with PC workstations and integration with the VS. Some strategies to make your workstation smarter:

• Use windows. Programmers and system administrators (among others) should have access to multiple windows to best perform their tasks. It is far more productive for these users to be able to perform multiple tasks; the benefits far outweigh the costs of providing this functionality. (Caution: the presence of additional windows can be a burden as well as a blessing, since it is often confusing to leap from screen to screen.)

• Use the specialized key definitions of Multi-Station. The keyboard redefinition options of Wang's Multi-Station allow additional capabilities over the standard workstation. These include the "pick up" and "put down" functions mentioned above and a variety of other functions like "caps lock", "insert mode", and others. Many of these can contribute to the productivity of individual users.

• Use attached printers. Programmers and system administrators should have ready access to a printer to print screen dumps and other short listings. The best way to accomplish this is through a printer attached to the workstation - either through the printer port of a 2110A workstation or (more likely) through a PC workstation with a printer. The best combination of all is a PC workstation with an attached printer and PC-to-VS transfer software (LightSpeed MVS, VSPC928, PowerDriver, etc.) to move files between the two environments.

Example Glossary routines

The Multi-Station Glossary function can contribute much to the livability of the workplace, but is seldom used. Here are a few standard routines that I use:

Move to the Next character: moves the cursor to the next non-blank character, ignoring Field Attribute Characters (FACs) and other non-text elements. Great in combination with "pick up" functions in programming.

movenext: procedure options ('4'); declare col fixed; col = cursorcol; do col = col to 80; /* find next blank */ if rank (substr(screen(cursorrow),col,1)) < 33 or rank (substr(screen(cursorrow),col,1)) > 122 or rank (substr(screen(cursorrow),col,1)) = 45 then leave; end; do col = col to 80; /* roll to next non-blank */ if rank (substr(screen(cursorrow),col,1)) > 32 or rank (substr(screen(cursorrow),col,1)) < 123 or rank (substr(screen(cursorrow),col,1)) ^= 45 then leave; end; if col > 80 then do col = 1 to 80 /* move to first item */ if rank (substr(screen(cursorrow),col,1)) > 32 or rank (substr(screen(cursorrow),col,1)) < 123 or rank (substr(screen(cursorrow),col,1)) ^= 45 then leave; end; cursorcol = col; end movenext;

Move to last character: moves the cursor to the last non-blank character. Great for inserting or deleting periods in COBOL programs.

movelast: procedure options ('6'); declare col fixed; col = 79; do forever; if col < 2 then leave; if rank(substr(screen(cursorrow),col,1)) < 33 or rank(substr(screen(cursorrow),col,1)) > 122 then col = col - 1; else leave; end; end movelast;

Load DEBUG script file: types the command to load a script file in the Debugger, stopping after the file name so other files can be specified. As set up here, press the GL (glossary) and BACK SPACE keys to type the string "LOAD volume.library.dsbdebug" and stop for modification or the RETURN key.

debug: procedure options ('(-bkspc-)'); call playout ('(-home-)LOAD volume.library.dsbdebug'); end debug;

Look at personal libraries: calls the Command Processor and enters Manage Files and Libraries with the user's initials as a prefix. Allows review of the contents of personal libraries without hassle.

liblook: procedure options ('3'); call playout ('(-help!-)'); call waitforunlock; call playout ('(-pf-5-)volumeuid (-enter-)'); end liblook;

Using a procedure to save screen information

Sometimes a program needs to be run repeatedly from the workstation until you are satisfied with the result, such as when using REPORT or CREATE for those notorious "one-time" programming needs. Since the program's defaults are not usually the values you need to enter, much effort is lost re-typing the same values repeatedly. In such cases, I use a procedure to capture and re-enter the values of the previous session's entries. For example, consider this procedure:

PROCEDURE MCREATE - captures CREATE GETPARM information RUN CREATE [ in LIBRARY on VOLUME ] C1: DISPLAY OUTPUT C1: DISPLAY OUTPUT (C1) C1: DISPLAY OUTPUT (C1) C1: DISPLAY OUTPUT (C1) [ repeat line ] C2: DISPLAY INPUT C2: DISPLAY INPUT (C2) C2: DISPLAY INPUT (C2) C2: DISPLAY INPUT (C2) [ repeat line ] [ repeat for other fields ] RETURN

This procedure will issue a number of PUTPARMs to cover the Parameter Reference Name (PRNAME) of the associated GETPARMs in the CREATE utility. Each refers to the values entered in the last execution of the program, displaying these for your modification. The amount of DISPLAY statements you create depends on the maximum number of times you expect to re-run the process. Try this approach with the REPORT utility.

I hope this discussion give you some ideas for improving your working environment. As always, I am interested in any other ideas you have.