[Access to Wang masthead]

Inner Workings

Part I: Advanced VS file investigation

From "VS Workshop",  Access to Wang, August 1989
  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  

As good as the working environment for VS users generally is, there are always some things that might be improved. Perhaps you are weary of the repetitive typing of required to override inappropriate default values in a utility. Perhaps you wish to enforce a shop standard to retain modification codes in source files, only to have someone errantly accept the default value on a copy and wipe out this valuable information. Perhaps you have a great diskette utility that only works with 8" diskettes and you are using the 5-1/4" format, or the text on a utility's screen displays meaningless information that will confuse unsophisticated users.

In most cases the best way to control your work environment is with procedures. Procedures can help reduce keystrokes and standardize usage - I haven't run the EDITOR directly in years - but any program driven by a procedure can also be run directly and thus defeat the goal of standardization. Also, in most cases, programs run from a procedure cannot accept information passed from another procedure. These and other reasons can drive intrepid VS technicians to take matters unto themselves and dive into the hex code (the process known as patching) or take other radical steps to make programs work better. In the next two columns I will cover some techniques I have used to reveal hidden features in a program, make it work with new device types, or otherwise change it to meet new requirements. Much of the processes described here stemmed from the research I did on the aging USERAIDS collection for my book, USERAIDS: A Guide to Low-Cost VS Software. Before embarking on this tour I must state a few ground rules:

The technical end

Those who wish to modify object files must be part technician, part detective, and part archaeologist. Here are some of the operational characteristics of the VS that must be understood:

The tools you need for program modification include the following major groups:

Most of these tools should be in your possession and familiar to you. It not, consult the System Utilities Reference (pub. # 715-0421A) and the catalog of VS Software from the International Society of Wang Users (ISWU) for further details.

The next three situations should give you some ideas for your shop.

Situation 1: Bad Defaults

Suppose you wished to change the default values of a utility? New Wang software is gradually using the form file library (@SYSFRM@) and the SETOPTS program to allow user setup of selected defaults, so this is the best route where possible. The SETOPTS function, though, only covers selected options for a handful of utilities. What can you do with the rest?

In most cases, the object file contains displayable text for most default values. This means that you can use the BLOCK mode of DISPLAY to locate the value, then PATCH or EZPATCH to change it. For example, the SMF utility (available from ISWU) stores only the last digit of the year in it's date fields. SMFDISP - the on-line display program - adds the decimal digit to the left of this year digit and displays the result; unfortunately, the value of the decade is '7' instead of '8'. Using the DISPLAY utility, I located the 7 (at position 1416, by the way) and changed the seven (h'37') to eight (h'38') with EZPATCH. While there, I also changed the file, library, and volume of the REPORT file associated with SMFDISP and the scratch option (formerly YES).

The EDITOR is another area where default value changes can increase productivity. Likely changes include the option to retain modification codes within source files created from the External Copy (XCOPY) screen.

Situation 2: Find Hidden GETPARMs

As mentioned above, many programs suppress the normal GETPARM that accompanies any file open. I use several approaches to locate the PRNAMEs of these GETPARMs, including text searches (DISPLAY again) and the use of bogus usage constants (described below).

Text searches are less successful when GETPARM information is sought, since there is little to distinguish a GETPARM from other object code. Sometimes a pattern appears in the object that matches other known GETPARMs and others can be described.

Another approach is to write a procedure that uses the DISPLAY verb and a number of PRNAMEs that often appear in programs. For example, consider this short procedure:


PROCEDURE FINDGP
RUN MYSTERY IN USERLIB ON VOLUME
DISPLAY OPTIONS
DISPLAY INPUT
DISPLAY OUTPUT
DISPLAY WORK
DISPLAY INFILE
DISPLAY OUTFILE
DISPLAY PRINT
  etc. . .

The PRNAMES shown above are typical for many programs, and are likely to be found in the examined program. If any of these names apply, the GETPARM will be displayed.

A sneakier approach is to use bogus usage constants and wait for the CORRECTION GETPARMs. For example, temporarily change your WORKVOL and SPOOLVOL usage constant values to invalid names and wait for the program to ask for respecification. This technique works well for locating work and print file specifications; I used it to identify the name of the print files created by LISTCLIB (a COBOL cross-reference USERAID) and increase the primary record allocation.

Situation 3: New Device Not Supported

Since many USERAIDS were written in the late 1970's, the likelihood of a device error of this sort grows every year. Typically, the program contains a list of acceptable device types and new devices simply do not appear; ergo, the program aborts.

One such program is the INITMANY USERAID, which initializes large quantities of diskettes. Designed to work with 8" diskettes, it rejected the mini-archiver (4250) that I wanted to use. Further investigation yielded the fact that the device number table used the numbers described in the Operating System Services Reference (Wang Pub. # 744-0423; pp. 4-98 through 4-103). Following this table, I located a device number I didn't need (the 2270V diskette drive; type 53) and searched the object file for it's hex value (h'35'). I then used EZPATCH to change it to the value for a 2270V-6 (h'D1'). The completed utility worked normally with 5-1/4" VS-format diskettes.

Next month I'll cover more advanced explorations of VS files. See you then.


  [ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]  


Copyright © 1989 Dennis S. Barnes
Reprints of this article are permitted without notification if the source of the information is clearly identified