![[Access to Wang masthead]](images/access89.gif)
|
|
Inner WorkingsPart 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:
Not recommended by Wang: the techniques described here may not be advised or even acknowledged by Wang Laboratories.
Some risk: file patching techniques carry a great deal of potential risk. Some expertise in the technical aspects of disk organization, data storage, and programming is assumed. This is not a good place to begin your technical education.
Pay attention: careful attention to technique must be maintained at all times. Haste and sloppiness will almost invariably result in damage and rework.
Make backups: the prudent investigator will always retain copies of the unmodified file and work only on copies.
May not work in the future: any modifications you make may work today but fizzle with a new operating system or a change to a key Wang system utility.
Document your changes: it is important to document the changes you make - particularly if is likely that new versions of the program will be installed in the future and require re-application of the changes.
Don't steal software: file modifications made to defeat copy protection or abridge the rights of software authors are unethical.
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:
Implied GETPARMs: whether it shows or not, every file OPEN statement issued by a program contains an implied GETPARM. Many of these OPENs use the NODISPLAY approach: that is, the program attempts to find the file and open it without prompting the user for it's location. If the GETPARM's Parameter Reference Name (PRNAME) is known, ENTER or DISPLAY statements in a procedure will override program defaults for the file's location.
Object file types: the Release 7.xx operating systems introduced a new object file format (Format 1). This record format - created by the LINKER - does not run under prior operating systems. Latest versions of the LINKER contain an option to create older (Format 0) object code, which will work with any VS. Older programs such as USERAIDS may need to retain the Format 0 format. This is particularly relevant because changes to common subroutines (USERSUBS or VSSUBS) have made it necessary to re-LINK older programs.
Device types: many programs require specific device types or usage, and may check the system for these items. Older programs may become confused by new device types and addresses. These new items may need to be added to the program's internal table of acceptable values.
Access profile: some programs are sensitive to the user's security profile. For example, the SCRATCH USERAID (not to be confused with the subroutine by the same name) will not delete files beyond the user's original security profile even if the program is assigned System Security Administrator rights. (Normally, the user inherits the rights of a program while using that program.)
The tools you need for program modification include the following major groups:
Search tools: tools to find problems. Includes Wang utilities FILEDISP, READVTOC, and VERIFY and the USERAIDS CONVERTC, FILEINFO, FILEREAD, FINDTEXT, and SCANOBJ.
Viewing tools: tools to see the file. The most important is the humble Wang DISPLAY utility; also includes TAPEDUMP, REPORT, INQUIRY, and the DISPMANY USERAID.
Modification tools: tools to change files. Wang's CREATE, DATENTRY, PATCH, SETOPTS, and TRANSL utilities and the EZPATCH and TRANSL8 USERAIDS head the list.
Control tools: tools to control the modification process. Procedure Language is the most important, but Wang's TABLEDIT is also necessary.
Comparison tools: tools that compare files and list differences. Includes the COMPHEX, COMPRLIB, and DIFF USERAIDS.
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.
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.
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:
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.
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.
Copyright © 1989 Dennis S. Barnes
Reprints of this article are permitted without notification
if the source of the information is clearly identified