Can a computer book remain relevant 30 years after writing?

A recent regular post on “How to read 100 books in a year and succeed in life” made me remember which books actually changed my outlook on life. Well, albeit not for life, but at least for programming, for starters.

And I recalled at the same time an old-aged book by the standards of programming, the book under the enticing title "What Mom Never Told You About VM Escort." The original title is “What Mother Never Told You about VM Service,” by Melinda W. Varian.

So, for a moment, this is 1983. The first version of MS DOS has just appeared. The appearance of CVS still wait about 8 years. Unix already exists, but has not yet received distribution (in Moscow it will appear in the form of Demos around 1986 on SM-4 machines). Most computer books of the time are hopelessly outdated today.

The book was intended for system programmers - those who were involved in the maintenance of the VM system (also known as CP 67, VM / 370, VM / SP, VM / ESA and many other names).

It would seem that such a book could be interesting for today's administrators (perhaps this is the best match for the activity that was then called system programming)? Let's see, judge for yourself.

So, the book is devoted to how to generate a kernel, apply updates and bug fixes received from IBM, make backups, and much more.

It turns out that you can still do this?


The first thing that changed then my views on programming was a way to make changes to the kernel code. Today we would call it a patch. In principle, the IEBUPDTE utility was known to me for a long time, since OS / 360, and the syntax from the patches themselves for the UPDATE utility in the CMS was very similar. The difference was that the patches themselves were able to generate the XEDIT text editor. Instead of modifying the original file, he created patches, which were then applied using UPDATE.

The process of kernel generation itself looked simplified like this - we take a distribution consisting of S / 370 assembler kernel sources, compiled object files (some sources were not supplied), macro libraries, apply patches to the kernel using the list from the so-called CONTROL file, then assembler, linker , and burning the kernel to disk.

The finished kernel also included a table of peripherals created by the system programmer from macros.

In principle, nothing complicated.

But the idea that you can get two different versions of the program by applying two different sets of patches was completely new to me and most of my colleagues.

Of course, UPDATE (even with XEDIT) is not Git. Moreover, this is not even CVS. This roughly corresponds to the capabilities of RCS, which, however, appeared around the same time. But this was one of the first applications of code versioning that I met in practice.

System Programmer Survival Rules


The second, more technical part of the book contained information on how to actually apply patches, including those released independently, to various parts of the system (CMS generation had some features).

We omit the technical details and provide only a list of rules that the author recommends to follow:

  1. NEVER CHANGE ANYTHING IBM SENDS YOU - never change what you sent from IBM
  2. KEEP YOUR STUFF SEPARATE FROM IBM'S - Keep your files separate from IBM files
  3. DON'T EXPECT IT TO WORK - don’t expect it to work
  4. ALWAYS LEAVE TRACKS - leave traces of changes
  5. VM SYSTEM PROGRAMMERS DO IT VIRTUALLY ALL THE TIME - you can check the new system at any time
  6. BACK IT UP - make backups
  7. BACK IT UP AGAIN - back up again
  8. DON'T TRUST DDR - Don't Trust DDR
  9. CHECK THE UNRESOLVED REFERENCES - Check Unresolved Links
  10. PLAN ON BACKING IT OUT - plan backups and rollbacks
  11. YOU ARE ENTITLED TO A HOME TERMINAL - you should use your (home) terminal
  12. CHANGE ONLY ONE THING AT A TIME - change only one thing at a time
  13. YOU CAN NEVER HAVE TOO MANY S-DISKS S-disks are not too many

Obviously, some points need clarification. For example, rule five meant that you could check the newly-built kernel by booting from it in a virtual machine — that is, that the VM did not need to take the time of the real machine to check for changes — it could host copies of itself as guest systems , with almost no functionality limitations.

Rule eight said about the Disk Dump Restore utility that you should not trust both the dumps themselves and the utility that makes them and restores them, especially in conditions where the tape may not be read.

Finally, Rule 13 speaks of CMS system S disks, by the letter that this drive was designated. It was meant that you can have backup copies of CMS, in any quantity you need, and there will never be too many of them.

The remaining points are obvious without explanation.

Make backups of the system before the changes, do them again after them, store your changes separately from the distribution, do not change the distribution itself, change something one at a time - I think that many will subscribe to it today.

And then even more so, for our team of system programmers this book was a must-read, and almost a desktop one, along with the usual documentation on VM. By the way, on forums for system programmers z / OS this book is still advised. There were even plans to release a new one, reflecting the realities of VM / 390.

I will not retell further. If you are interested in computer history - you better read it yourself.

The book is available in PDF on the Internet, on the site of Melinda herself. Saved the original formatting, made for then existing printers.

It has about 120 pages, and I hope it will be interesting to everyone who is interested in the history of computers and OS.

And finally, one rule of survival from ourselves, which we tried not to violate: You should not generate a system if it’s already evening already - there is a high probability that you will stay overnight to fix the consequences.

Enjoy reading!

Also popular now: