The VAX/VMS Genesis Manual
Bernd Onasch
The VAX/VMS Genesis Manual

Bernd Onasch


Order Number: EY-0815XY-3D

May 1993

This manual describes as parody how a VAX should bootstrap.

Revision/Update Information: This is a new manual.
Software Version: VMS version 5.0 and later


At the very beginning, there was really nothing (except space). A short time later, some possibly useful physical rules were introduced. Those rules took a long time to grow and complete verification error-free, and finally, led to the scientific divisions of electronics and computers (among many others).

(This first day ended happy because of lack of serious problems)


At the beginning of the next day, a large green flat board appeared. A long time later, some black multi-footed boxes, escorted by some other small objects, appeared above that board. Then, not so long a time later, some connections between these feet were made.

(This was the second day - the day where the hardware problems began)


Then, another millenia of milliseconds later, chaos was introduced and the wired black boxes decided to use electricity and start working. The largest box called itself CPU and initialized the other boxes. Henceforth it used a small box labeled 4.77 MHz to get a sense of time and some other small boxes called ROM to load its ability to think from. (Obviously, those boxes didn't know of their importance)

(This third day saw the creation of firmware including some system bugs)


After becoming aware of itself, the CPU searched for VMB.EXE to be able to use those masses of small boxes labelled «RAM» that occupied so much so far useless space on the board. After loading and executing VMB, the CPU developed the knowledge of memory, but (who expected anything else) had no use for it. Millions of system ticks later, the CPU found a module called SYSBOOT.EXE, residing on a very slow object called «boot device» and loaded it.

(This fourth day became the day of bootstrap problems)


When executing this curious SYSBOOT, there was the need to load many other programs from this slow object and to fill the formerly useless memory with more or less useful data and programs (or merely some modules ?).

  • The first one was SYS.EXE that looked, in the eyes of the CPU, somehow useful.
  • The second one was RMS.EXE that was very huge and looked totally unusable, but (surprised CPU interrupt) when using this large beast, the slow object called «boot device» looked much better structured and useful than before.
  • The third one called itself SYSLICENSE.EXE and (by the power of the producer) thought it was the most important module and would be able to decide whatever other program might execute or not (so far, the CPU had no concept of «program»).

After loading all those modules, the CPU looked around in search of other green boards and devices, thinking "Is there nothing else ? Is this really all ?", and found some additional more or less slow devices.

Then, using the knowledge of SYS.EXE, it loaded some drivers and started to talk to those devices in the hope of answers, but most of the time, the CPU just waited for the line noise. (Strangely, sometimes, those devices answered to very old questions)

(This fifth day finished with the knowledge of advanced bootstrap problems)


This days first decision was to power up another black and huge box and turn memory into virtual mode (where no bit has gone before). Then, the CPU itself got lost in all this empty memory areas and summoned ( by the power of SYSBOOT - a once only spell) some processes (so chaos might come and start its busy work).

  • First, the Scheduler - to check and control all the others, unfortunately itself not visible to the others (God's paradoxon ?).
  • Second, the Null Process - something that is always able to occupy precious CPU cycles, but totally useless (and because of that sometimes invisible).
  • Third, the Swapper - to keep usage of the remaining memory low, especially for later processes (ever told the swapper to swap itself out of memory ?).
  • Then, SYSINIT appeared and added some more modules to memory -
    DCL.EXE that looked like a module whose only sense is to wait,
    F11XQP that tried to use the very early on loaded RMS more effectively,
    SDA.EXE, an essential programm ("Damn! Another screwdriver lost..."),
    DEBUGSHR.EXE, a module to control another one, how confusing, and many many other modules, each of more or less usefulness.
  • Finally, STARTUP.COM was loaded and began to test the waiting module DCL,
    adding a process CONFIGURE to allow highly secure system configurations,
    adding a process IPCACP to allow the producer (and noone else ?) some communication between different processes,
    adding a process ERRFMT to display all the errors in a pretty format,
    adding some xxx_SERVER processes to cache so far useless data packages,
    adding a process OPCOM to log errors and messages to the sysop,
    adding a process AUDIT_SERVER to guarantee the correct logging by the OPCOM and perform a secure (never stoppable ?) logfile handling,
    adding a process JBC_CONTROL to create user (*shiver* the CPU missed totally shocked a clock cycle) processes,
    adding a process QUEUE_MANAGER to emulate printer queues ("...are those some of these really slow devices ?"),
    adding a process SMISERVER that should communicate with other CPU's around ("... and seek out new operating systems"),
    adding several processes called xyzACP to support strange protocols ("In memory, every protocol is a correct protocol" from one CPU to another) like DECnet, LAST, LAT and TCP/IP.
    adding several user (*iiiieks* once again the CPU misses some heart beats) dependant processes to slow down every useful work the CPU had.

(This sixth day saw system installation and software problems - the nemesis)


On the seventh day CPU decided to rest ("...all those user processes drive me crazy...").

  • This good idea (the Null Process needs testing) was disturbed by many user processes that started to do nothing worthwhile except allocating too much resources.
  • Then some lonely users ("Why does this program not work ?") tried to solve some small problems in a very slow (i.e. human) manner, by adding small and useless packages (i.e. printf) to their programs.
  • Following the rule of humans erraneous thoughts, those programs were never bug-free or fully operational (Murphy's Law proved it). The more logic variant was a programming bug that messed up all ressources and brought down the six day work of system bootstrap within just a second (This minor drawback is solvable by debugging in white text on black background).
  • Some more sophisticated user processes might move to kernel mode - and loose self control and memory management there - so everything got lost in the vast of endless dark addressing space ("...entering a no-win scenario.").
  • Another nice possibility is the AUDIT_SERVER, detecting a full system disk (that won't happen - or won't happen ever again), stopping every work yelling "Gimme some disk space !" (This stops everything before a debugger can intervene).

After testing all these features, the CPU disappeared in a orange cloud of logic - leaving all the bit patterns (with a puzzled look) behind.

(This day returned the CPU to day zero - where everything began)



Some ideas were taken from Ruth E. Goldenbergs book "Internals and Data Structures" - I hope I have taken real procedings in account as much as is necessary.

Annotation: The Virtual Memory is enabled (later) by the swapper. There are much more (and more important) sharable images to be loaded.


Special thanks to Frank 'ComRam' Kargl and his uncountable questions and to Petra 'stargazer' Zeidler for all the spell checking.

Written 1993 by Bernd 'Uranus' Onasch

© 2004 by Bernd Onasch - Imprint Last change 01.02.2004