Various kinds of System reloads
Various kinds of System reloads 2354
A sysgen is a build, not an installation. The output of a sysgen is an executable that then can be booted up and run. IBM was unique in doing...
A sysgen (installation of the operating system) was required for every major version upgrade, and sometimes in the case of major reconfiguration triggered by - installation of new peripherals of types for which device drivers were not selected in the previous sysgen - addtion of new system features that had not been previously selected, such as changing to a different spooling-remote job entry subsystem, fine-grained system logging etc. A sysgen typically ran overnight or on a week-end day shift, writing a new system pack onto a spare disk mounted a removable drive that might hold user data during a normal shift.
A reboot was-is called an IPL in IBM-ese. It is a surprisingly rare event, and took-takes anywhere from 5 minutes to an hour depending on the complexity of the system.
Because of the huge variety of devices supported by OS-360 (OS-370, MVS, z-OS) it was standard procedure to only include support for the devices actually present. Much of the time taken by sysgen was spent in macro buttembly of IO data structures. In contrast, I think TOPS (and the PDP-11) shipped a kernel that usually did not need to be field modified, except to bring in site-specific system patches. On boot, the kernel would dynamically create data structures for the devices found to be present "on this system today".
Seen from today, the IBM systems were not very powerful, but by super-optimizing everything I-O related, they achieved a production throughput for administrative data processing that should have required a much more powerful system. Thus, IBM charged the customer the price of that more powerful system, which made IBM very profitable.
The few operating systems of the time that were comparatively simple to operate and with the least complexity were systems like TOPS-10, Unix and TENEX. All of these were time-sharing systems designed for a mix of CPU-bound background jobs and a terminal-i-o-bound multi-user foreground load with low actual system load per user.
The shortest boot time among time-sharing systems was the SCOPE or NOS system for CDC6600. The timesharing users might not even know the system had rebooted, because it usually managed to receover all the interactive sessions running in the PPU (peripheral processing units) when the CPU was reloaded.
Various kinds of System reloads 2356
This would have not been acceptable on PDP-10 sites. In the TOPS-10 monitor group we built at least 10 monitors every Tuesday after the...