Very slow booting and running and braindead OS's 4535

the vm370 based commercial timesharing services

started running into this problem as they started acquiring customers all around the world (early to mid 70s) ... and were faced with providing 7x24 service.

one of the increasing problem issues was that the field service people needed to take over a machine once a month (or sometimes more often) for service (and with 7x24 operation ... traditional weekend sat or sun midnight period was becoming less and less acceptable). at least some of the service required a whole system infrastructure .. where they would run various kinds of stand-alone diagnostics.

to compensate, the ran loosely-coupled (cluster) configurations and added software support for process migration across processors in cluster. they even claimed to being able to migrate a process from a cluster in datacenter on the east coast to cluster in datacenter on the west cost ... modulo amount of context-data that was required ... back in the days of 56kbit telco links.

much later when we were doing ha-cmp we coined the terms disaster survivability and geographic survivability

now, fast reboot had already been done back in the late 60s for cp67 ... was cp67 systems were starting to move into more and more critical timesharing (and starting to offer 7x24 service). this then carried forward into vm370.

old tale about how fast cp67 rebooted (after a problem, in contrast to multics)

mentioning cp67 crashing (and restarting) 27 times in one day.

cp67 had been done on 4th flr of 545 tech sq, multics on 5th flr of 545 tech sq ... and for some reason i believe MIT USL was in one of the other tech sq bldgs (across the courtyard). tech sq had three 10 story bldgs (9 office floors, there was 10th?) forming a courtyard ... with two-story Polaroid bldg on the 4th (street) side (i've told before 4th floor science center overlooked land's balcony and once

the cause of the multiple cp67 crashes was a local software modification that had been applied to the USL system. I had added ascii-tty support to cp67 when i was undergraduate at the univerisity ... and played some games with using one byte values. the local USL modification was to increase the maximum tty terminal size from 80chars to something like 1200(?) for some sort of new device (some sort of plotter?) over at harvard. the games with one byte value resulted in calculating incorrect lengths if the max. line size was increased past 255 (which then resulted in system failing).

some more on tech sq:

note that in the above discription ... the (IBM) boston programming center also shared the 3rd floor of 545 tech sq. when the cp67 group split off from the science center, they moved to the 3rd flr, abosrbing the boston programming center. as the group expanded and morphed into the vm370 group ... it outgrew the 3rd floor and moved out to the old sbc bldg in burlington mall (vacated when sbc was sold-transferred to cdc).