Introducing the Wang Symbolic Debugger
From "VS Workshop",  Access to Wang, June 1993
[ Prior Article ]     [ Return to the Catalog of articles ]     [ Next Article ]

Few programmers anticipate using a program debugger; we all just expect it to be there when the time comes to nail the last few problems in a program. Many programmers have a routine approach to using Wang's Symbolic Debugger, never venturing past the EASY ON command that sets up a static arrangement of code and data windows. That's a pity, because the Wang Debugger offers many features that allow it to be specifically tailored to a specific task or to a programmer's capricious tastes.

Like others who have overseen two generations of Wang Debuggers, I was slow to accept the differences posed by the OS 7-level versions of the tool - differences that include a command-line orientation, an array of screen management options, and sluggish start-up. I have gradually grown used to the poor initial performance and added more features of the Debugger command set to my collection of personal favorites; nonetheless, I am still lacking in extensive explorations into many options. This is a powerful and complex tool.

My goal is to present some of the Debugger techniques I have discovered in the hope that you find some of interest to your practice.

Debugger basics

If you've used the Debugger on a busy system you know that it can take a long time to start it up. You should know why: each Debugger session creates a new background task, and that takes some resources. I'm sure that it was necessary for Wang to take this approach to get the functionality they needed, but there is definitely a cost. There is a odd advantage to this approach: it makes users of the Debugger more visible and, thus, lessens the security issues of access to debugging facilities by unscrupulous users. Symbolic debuggers offer powerful access to view and modify data, and auditors and system administrators should be concerned about who is using them. Since every Debugger session shows on the Non-Interactive Queue, it's easier to monitor this activity. Anyway, enough complaining.

The Debugger screen can show a variety of information according to the needs of the programmer. By default, the program code appears first; this is the LISTING window. The other standard windows are: DATA, the contents of program variables; TRAP, settings that stop program execution and display results according to specified conditions; and MENU, a listing of the PF keys assigned to Debugger commands. Note that the commands assigned to PF keys can also be invoked by typing them at the top of the screen. The words LISTING, DATA, TRAP, and MENU are debugger commands, setting the display to the respective display.

Besides these listing windows there is also a portion of the screen devoted to command entry and related messages. The COMMAND window covers the top three rows of the workstation, listing the code section name and providing an entry line for commands and a message line for the system to respond to those commands. This is the only portion of the Debugger that cannot be changed; the presence of any or all of the other windows is within the control of the programmer.

I believe one of the reasons that many programmers have not embraced this version of the Debugger is due to the command-prompt interface presented by the COMMAND window. The use of typed commands is a foreign concept to users of the Wang VS, where even the lowest levels of the operating system present a menu and selections by PF key. Despite this "cultural" difference in use, there are some advantages to this approach, including easier use of non-standard terminals (such access through dial-up connection software and my locally-connected PC with an industry-standard keyboard) and the ability to use sophisticated command combinations without swinging from menu to menu. With typical commands assigned to PF keys, this combination interface offers a reasonable compromise between universal access and VS cultural perspective. (Of course, it helps if the default settings for these PF key resemble other VS conventions; more on this later.)

Customizing the Debugger environment

When the Debugger is launched, an interesting set of events occurs. A script language program is invoked, setting up the size and location of the LISTING window, assigning commands to PF keys and listing those key options on the screen through the MENU window. The script file that performs this magic is DEBSTART in @SYSTEM@ on the system volume. It's worth printing a listing of this program to get an idea of how the Debugger script language works.

The logic of the script language should be easily understood from a quick review of DEBSTART. The standard Wang DEBSTART file (shown in Figure 1, below) assigns command functions to each of the 32 PF keys, moves the cursor down 17 lines, and establishes the MENU screen at that position. The program listing window appears at the top of the screen by default.

I've been referring to the "standard" version of DEBSTART because our shop uses a modified version of this file. We elected to rearrange some of the PF key assignments to more closely match Wang conventions. Some of the changes include:

PF Key	Action
PF1	VARIABLE (sets up a variable in the DATA window)
PF2, PF3	FIRST, LAST (top and bottom of listing)
PF6, PF7	PREVIOUS 1, NEXT 1 (single line movements)
PF8, PF12	FIND, DELETE (like the EDITOR)
PF16, PF32	CANCEL, CLOSE (reverse of Wang defaults)

Over time I have assembled my own conventions for Debugger use. Typically, I want to see a small portion of the LISTING windows and leave a large amount of area for the DATA window. I have assembled those preferences into my own startup file, which can be launched through a Multistation glossary entry that types the command entry load sysobj.dsbdebug.dsbstart. The LOAD command runs the Debugger script file DSBSTART in DSBDEBUG on SYSOBJ. This file specification syntax is unfamiliar to most Wang users but should be understandable.

DSBSTART contains the following commands:

w 3 attributes off cursor down 5 w 2

The commands break down as follows:

• w 3: sets the LISTING window full-size at the top of the screen. W 3 is an abbreviated form of the WINDOW 3 command, another name for the LISTING command.

• attributes off: turns off the SECTION name in the DATA window, allowing more room for data values. cursor down 5; w 2: positions the cursor; sets up the DATA window. W 2 is an abbreviated form of the WINDOW 2 command, another name for the DATA command.

This provides the screen arrangement I use most often. It is also possible to invoke such personalized startup files automatically each time the Debugger is run by naming them DEBSTART and placing them in the library set by INLIB and INVOL. I find this approach is not as practical as my MWS Glossary entry, since the values of these usage constants are usually set to a data library during program testing.