Mainframe Word Processing?

Well, yes, the title is a blatant attempt to squeeze a few keywords into one phrase. But, yes, there was word processing on mainframe computers, even before there were PCs.
This is the story of bending such a text processing system to do my will.

Back in the olden days, there were things called “mainframe computers”. They got that name because they were in mainly big – very big – frames, and computed, and were kept in air-conditioned rooms while human beings lived in the heat and humidity that had been their lot in life for generations. Ah, to be a mainframe technician! It meant staying cool in the weather of the East Coast. But anyway, these massive machines were connected to terminals, each providing typed input and showing the output of programs running on the computer in a time-shared environment. Sounds like client-server? Well, not so far off.

Well, the mainframes had programs which could format text into printed materials. These were text processors. The output was printed on equally massive line printers in the same air-conditioned room as the mainframe. One had to walk down the hall to get one’s “print-out’, and check it for errors. IBM had a very good example of this system with their IBM/370’s and their Script/VS text processing program.

This was the beast that had to be tamed.

Script/VS was a good program. It let you write your documentation using tags. Paragraphs, lists, tables, etc. – all were explained to the program in a text file using formatted keywords, each beginning with a full-stop. Think “HTML with a period instead of angle brackets”. Yes, it’s amazing how many times the same wheel spins around again. Script/VS served the purpose for reference manuals, engineering guides, proposals, etc. The font selection was limited. The line printers had only one chain and could really print in only one font. (Research question: what font was it?) But it did a tolerable job.

Script/VS even had “deferred tags” for things like Table of Contents and Indexes. Unfortunately, those tags were quite limited.

I do not recall at the moment – this was almost 40 years ago – the exact nature of those limitations, but in being tasked to write reference documentation for our electrical engineering project at IBM in Essex Junction, Vermont, I found that Script/VS could not do what I wanted it to do! So, I got copies of all of its reference manuals, and read up. It turned out that one could define one’s own tag or tags to do new things! Be still, my beating heart! This was the answer. All I had to do was figure out how to program in the macro language and create new tags, and my documents would have indices and tables of contents and drop-caps like nobody’s business!

So, I embarked on writing, documenting and debugging macros for new tags. I did this in my spare time, since other ‘experienced’ people around me were satisfied with Script/VS as it was, and pushed ahead on the project in the normal fashion. I succeeded, and created what everyone loved: unexpectedly professional and comprehensive technical documentation. “Well, what else would you expect anyway?” I asked myself silently.

And so, I strengthened my conviction that, given a sufficiently programmable system, one could “turn it to one’s will” with willpower and time at the keyboard. Making confident claims to being able to “improve the system” could yield great results, and kudos from one’s team mates (and management).