Nearly Fifty Years
in the Making

EDS, banking systems, and WAAPDSUT

In the late 1970s, I worked for the company founded by H. Ross Perot, EDS — Electronic Data Systems. I was an application programmer on a team that maintained a banking system written in IBM Assembler. EDS was an interesting place to work in those days. We often used utilities and support programs that had been developed locally.

One of those products was called WAAPDSUT. Different prefixes identified the groups that developed and owned a product. My memory after all these years is not exact, but I believe WAAP was probably a prefix associated with system utilities. The final four characters, DSUT, most likely stood for Data Set Utility.

WAAPDSUT was a general-purpose utility for working with data sets — the mainframe term for what Windows, Unix, Linux, and other systems generally call files. We often used it to read one data set, programmatically modify its contents, and write a new data set. It could also read an input data set and produce a simple report, perhaps selecting only particular records.

I remember using it to read a master file, search for a certain type of record, zero out a value, and write an updated copy of the master file. The purpose was to force that field to be recalculated the next time the master file went through normal processing.

On other occasions, I used it to scan a data file, select records that met certain criteria, format information from those records, and print a report. In that case the result was not a modified copy of the input at all. The output was the report.

That design was what made the utility memorable to me. Instead of inventing an entirely new control language, WAAPDSUT used statements modeled on IBM 360/370 machine instructions. Assembler programming was widely used at EDS at the time, so the learning curve was easy for us. More importantly, it gave us a powerful way to manipulate data without writing, assembling, linking, and running a complete assembler program every time we needed a small one-off job.

         GET   INPUT,RECORD
         CLI   TYPE,C'X'
         BNE   NEXT
         XC    VALUE,VALUE
         PUT   OUTPUT,RECORD
NEXT     ...

I last worked with WAAPDSUT in 1979, so many of the details have faded. But while I was at EDS, I used it constantly — probably several times each week.

Missing the tool enough to keep rebuilding the idea

After I left EDS and took a position with another company, I often thought about how much I missed having access to that utility. That eventually prompted me to write my own scaled-down version that could perform some of the same basic kinds of work.

Over the years I returned to the idea many times. I implemented different versions with different capabilities, usually aimed at whatever problem I needed to solve at the time. Most were very limited and represented only a small subset of the sort of work WAAPDSUT could do. There was no master design tying those versions together.

The common thread was assembler-style statements. Some versions supported more instructions, others supported fewer. Each implementation grew only far enough to solve the immediate problem.

Unfortunately, none of those early versions have survived. Most were lost when I left the company where I had written them and the source code stayed behind. Even so, the idea itself survived. For nearly fifty years, I kept coming back to it from time to time.

The earliest versions were written in IBM Assembler. That made the implementation relatively direct: because the control language modeled machine instructions, the program could often use the actual underlying mainframe instructions to do much of the work.

Moving from assembler to C

Eventually I began considering C as the implementation language. That would largely decouple the utility from the underlying machine architecture. As I moved from assembly language to C, I came to appreciate not only how quickly I could write code, but how much easier it was to create higher-quality code in less time.

For this project, however, moving to C also created an interesting problem. I could no longer simply depend on the real machine instructions underneath the program. If the scripting language was going to behave like an IBM mainframe instruction set, I would have to implement that behavior myself.

Register operations, storage addressing, condition codes, branches, character operations, packed-decimal behavior, and the other pieces that had once come naturally from the hardware now had to be represented inside the program.

That change became the genesis of what I now call TSDSUTIL — Tommy Sprinkle's Data Set Utility.

TSDSUTIL does not really resemble WAAPDSUT beyond the basic idea that its control statements are modeled after IBM mainframe assembler. Over time, it began to feel less like a traditional utility program and more like a scripting language.

Why I sometimes call it “Monti-Python”

I often jokingly call TSDSUTIL Monti-Python.

As an assembler and C programmer, I have never particularly enjoyed using Python. When I started thinking about TSDSUTIL as a scripting language, it occurred to me that I had probably made it about as opposite from Python as I could make one. I started thinking of it as Anti-Python.

That immediately made me think of Monty Python's Flying Circus. A show known for surreal humor, absurd characters, and unconventional sketches seemed strangely appropriate for an equally unconventional assembler-inspired scripting language in the modern era.

I changed the spelling from Monty to Monti, keeping the “Anti” idea buried in the name.

Starting over and building the version I always wanted

The latest incarnation of TSDSUTIL started from scratch, but it draws on everything I learned from the many versions I attempted over the years. It is now a scripting language that combines ideas from both IBM Assembler and C programming.

TSDSUTIL models many features of the low-level System/370 architecture, including sixteen 32-bit general-purpose registers. It implements most of the non-privileged System/370 instruction set from roughly the mid-1970s, excluding floating-point instructions. Instructions can modify registers and storage, and condition codes are set according to the results of operations. Those instructions are emulated inside TSDSUTIL rather than executed by a real System/370 processor.

The current version also implements a subset of MVS-style data management facilities. These include concepts such as DCBs and GET/PUT I/O, along with other functions useful in a scripting environment. It has debugging and testing facilities such as ASSERT for checking expected conditions and TRACE for following execution at the instruction level.

Initial development has been on Linux, with an effort to keep operating-system-specific code separated from the rest of the implementation. One of my future goals is to port TSDSUTIL so that it can run on MVS 3.8 under Hercules.

Over the years I have worked with a number of IBM operating systems, including DOS/360, OS/360 MVT, SVS, MVS, and many later forms of MVS under different names. Of all of them, MVS 3.8 remains the one nearest and dearest to my heart.

When I first encountered MVS, I thought it was amazing, and I still find it amazing today. My first job as a systems programmer involved maintaining MVS 3.8. When the Hercules emulator eventually made it possible to run MVS 3.8 again, I was delighted to have the opportunity to work with it once more.