A recent post on the topic “How to read 100 books a year and achieve success in life” made me remember which books actually changed my outlook on life. Well, if not for life, but at least for programming, for a start.

And I remembered with this old-aged by the standards of programming the book under the enticing title “What mother never told you about the maintenance of VM”. In the original, it is called "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. CVS is still waiting for about 8 years. Unix already exists, but has not yet received distribution (in Moscow it will appear as Demos around 1986 on SM-4 machines). Most of the computer books of that time are hopelessly outdated today.

The book was intended for system programmers - those who were involved in maintaining the VM system (also known as CP 67, VM / 370, VM / SP, VM / ESA, and under many other names).
')
It would seem, can such a book be interesting to today's admins (perhaps this is the best match for the activity, which was then called system programming)? Let's see, judge for yourself.

So, the book is dedicated to how you need to generate the kernel, apply updates and bugfixes received from IBM, make backups, and much more.

It turns out that it is still possible?

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

The very process of generating the kernel simplifiedly looked like this - we take a distribution kit consisting of the source code of the kernel in S / 370 assembler, compiled object files (some of the sources were not supplied), macro libraries, apply patches to the kernel according to the list from the so-called CONTROL file, then assembler, linker and write the kernel to disk.

The ready kernel also included the table of peripheral devices 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, for me and most of my colleagues, was completely new.

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

The rules of survival of the system programmer

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

We omit the technical details, and give only a list of the rules, which the author recommends following:

1. NEVER CHANGE ANYTHING IBM SENDS YOU - never change what you were 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 PROGRAMERS 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 - do not trust DDR
9. CHECK THE UNRESOLVED REFERENCES - check unresolved links
10. PLAN ON BACKING IT OUT - plan backups and kickbacks
11. YOU ARE ENTITLED TO A HOME TERMINAL - you need your own (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 never too many

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

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

Finally, rule 13 speaks of the CMS system S-disks, by the letter by which this disk was designated. It was meant that you can have CMS backups, 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, make them again after them, keep your changes separate from the distribution, do not change the distribution itself, change something one at a time - I think that today many will subscribe to it.

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

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

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

It has about 120 pages, and I hope it will be of interest to anyone interested in the history of computers and OS.

And finally, one rule of survival from ourselves, which we tried not to violate: It’s not worth generating the system, if it is already evening in the yard - there is a high probability that you will stay the night to repair the consequences.

Enjoy reading!