X-NEWS: spcvxb comp.os.vms: 49645
Relay-Version: VMS News - V6.1B7+SPC1,2 05/22/93 VAX/VMS V5.5-2; site spcvxb.spc.edu
Path: spcvxb!uunet!math.fu-berlin.de!news.belwue.de!news.uni-stuttgart.de!rz.uni-karlsruhe.de!usenet@rz
Newsgroups: comp.os.vms,de.comp.os.vms,uka.jokes
Subject: VAX/VMS Genesis Reference Manual :-)
Message-ID: <1tvkfj$6uv@nz12.rz.uni-karlsruhe.de>
From: S_ONASCH@iravcl.ira.uka.de (|S| Bernd Onasch)
Date: 26 May 1993 11:32:03 GMT
Reply-To: uranus@pilhuhn.ka.sub.org
Followup-To: comp.os.vms
Distribution: world
Organization: University of Karlsruhe, FRG
Summary: Parody of VMS bootstrapping
NNTP-Posting-Host: irav1.ira.uka.de
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-News-Reader: VMS NEWS 1.25
Lines: 142

Well,

Some people asked too often "when in bootstrap does ... (not) happen" :-)

Greetings, Bernd Onasch

-------------------------------------------------------------------------------

VAX/VMS Genesis Reference Manual
================================

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 found.
Those rules took a long time to grow and complete verification error-free,
  and finally, led to the scientific divisions of electronics and computers.
(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 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 ROM's didn't know of their importance.)
(This third day saw the creation of firmware and system bugs.)

After becoming aware of itself, the CPU searched for VMB.EXE
  to be able to use those masses of small useless 'RAM' boxes around.
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 only 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.
The third one called itself SYSLICENSE.EXE and (by the force of the producer)
  thought it was the most essential module and
  it would be able to decide whatever program might run or not.
  (This guess was wrong as producers force lost power in the distance.)
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 had gone back before).
Then, the CPU got lost in all this empty memory areas and
  summoned some processes (so chaos could come and start its work).
First, the Scheduler - to check and control all the others,
  unfortunately itself not visible as process.
Second, the Null process - something that is always able to use CPU cycles,
  but totally useless (and because of that sometimes invisible).
Third, the Swapper - to keep usage of the remaining memory low,
  exspecially for later processes (ever swapped the swapper out ?).
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 other modules, each of lesser 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 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 of the OPCOM
    and perform a secure (never stoppable ?) logfile handling,
  adding a process JBC_CONTROL to create user (*shiver*) processes,
  adding a process QUEUE_MANAGER to emulate printer queues that never work,
  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 Processor to another)
    like DECnet, LAST, LAT and TCP/IP.
  adding several user (*iiiieks* again) 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 (the day of SUN systems) the (DIGITAL) CPU decided to rest.
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 (in front of their processes) tried to solve
  some very small (human) problems in a very slow (again human) manner,
  programming some small and useless packages.
Following the rule of humans erraneous thoughts,
  those programs were never bug-free or fully operational.
  The more logic variant was a programming bug that messed up all ressources
  and brought down the six day work of system bootstrap within a second.
  (This feature 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.
  (Here it is possible that even a debugger has no chance)
Another nice possibility is the AUDIT_SERVER,
  detecting a full system disk (that happens sometimes),
  and stopping every work yelling "Gimme 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 behind.
(This day returned the CPU to day ZERO - where everything began)

-------------------------------------------------------------------------------

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

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

Written 1993 by Bernd 'Uranus' Onasch, VAXman i.R.

-------------------------------------------------------------------------------