Name, Rank & Serial Number Part II: Advanced VS file investigation
From "VS Workshop",  Access to Wang, September 1989
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Last month we covered a few ways to tailor existing software to more closely fit your needs by patching and finding hidden GETPARM screens. This time I will cover some means of identifying program versions (object files) and diagnosing internal problems with these and other file types.

The version problem

The file format only a CPU could love, object files are the most difficult to provide revision history on. Thoughtful program developers provide on-screen version numbers and may also include the release date, copyright, and other information within the object itself. Much can also be told from the modification history for the file - provided that information has been carefully preserved. Beyond these simple measures, there is little means of identifying which version of a program is in use.

Why would you need to know a program's version, anyway? Some reasons include:

• You are working with your software vendor to resolve a program problem and need to know whether the vendor's test conditions are identical to yours.

• Your disk drives have been flaky and you suspect that some of your object files have been damaged.

• You are unsure whether a utility will work with your operating system. The vendor quotes a release level but does not mention which version is which.

As in last month's column, here are some real-life strategies for coping with release level uncertainty.

Strategy 1: Preserve Copies of the Original File

The first strategy should seem self-evident, but it is surprising how often it is overlooked: save "virgin" copies of everything you load on your system. This could be accomplished by saving the files to diskette, tape, or an extra platter; in any case, it should be a removable storage medium to lessen the likelihood that the files be inadvertently modified. (It's unfortunate that the VS does not have a "read-only" status like PC operating systems.)

The availability of all versions of a program provide the following three benefits:

• Files can be compared record-by-record to verify the exact version in place.

• The original owner ID and modification history will be present (provided BACKUP was used to make the copy).

• The files can be restored if necessary.

This is why for greatest benefit it is important that all recent program versions be retained. In shops where a large amount of development is underway, this could be a large storage requirement. For this reason, it is best that the storage medium be inexpensive enough that there is not hesitation to retaining the extra copies indefinitely.

Strategy 2: Compare Modification History

Another seemingly obvious clue - the file's create, modification, and expiration dates - are often obliterated accidentally through careless file installation. Either Wang's BACKUP utility or a version of COPY that restores this history (versions are sold be several vendors) should be used so that this important information is not wiped out.

Strategy 3: Search for version number

As mentioned above, some vendors place the program's version number on the screen during operation. This is helpful - provided that the program runs. What if the number is not there or the program doesn't work? Sometimes a little detective work is necessary.

As an example, Wang Labs uses three methods to identify object files: a program number on the screen; a version number in a dummy program header (read by the VERSIONS program); and a short text area within the object file itself. The VERSIONS program - a Wang utility - reads object files that have a program header named SYSCODET and returns information about the program's release level, date of compile, and a copyright notice. Unfortunately, this approach works only with object files - not microcode files, subroutines, or any other file type. Worse, the SYSCODE header works only with Format 0 object (the type generated by the old LINKER), not Format 1 (from the new LINKER).

While the new LINKER eliminated the possibility for using the VERSIONS program to identify program versions, it did add one additional capability: a 45-character text field and date and version information that appear in the first record of the object file. This means that you will have to use DISPLAY to read the file and uncover it's version number. A quick scan of recent Wang utilities will tell you how frequently this approach is being used; almost no system utilities use the SYSCODE approach.

By the way, it is possible to find the programs that use the SYSCODE approach without using VERSIONS: simply use the SCANOBJ utility from ISWU (available from the International Society of Wang Users) to search for a section named SYSCODET.

Strategy 4: Possible File Damage

While object files are not immune from file scratching or other unauthorized file activity, they are generally safe from file damage. Disk damage can occur at any time or location, however, and it is possible that an object file sits on a bad spot on the disk drive.

Some of the ways you can detect this is through comparison with clean copies of the same version. COMPHEX (distributed by ISWU) compares two files and returns the location of all differences. Another good tool for this purpose from ISWU is the COMPRLIB utility, which compares the contents of two libraries and lists files that have changed. Best of all is the COMPARE utility distributed by Wang with the 7.20 operating system; it combines the library comparisons of COMPRLIB, the byte-by-byte comparison of COMPHEX, the split-screen visual display of COMPAREF (a comparison utility that is no longer available), the "redlining" abilities of DIFF, and easy access to the DISPLAY utility to see the differences.

If you discover a problem with the object file, it is likely that the physical location of the disk is bad. For this reason, be sure to rename the bad file in place and make a new copy from your archive storage medium. The RENAME verb in Procedure language (or the RENAME subroutine from Wang) allows you to rename both the file and the library at the same time without disturbing the physical location of the file; thus, the new copy lands in a different and, hopefully, better location on the disk.

Future solutions

Program installation and version control are often maddeningly persistent problems. Wang's architecture does not address the problem well due to the limited amount of information retained within the file's descriptor and the fragile nature of the Volume Table of Contents (VTOC) on disk systems. The security logging facility provides some means of tracking some types of damaging activities, but not in ways that meaningful and worth the disk storage space. Until more file information can be retained and there is a greater emphasis on fault tolerance for disk systems, we will all have to carefully maintain backups of program versions for the inevitable problems.