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 edit. They had to be complete by the time TW strolled in at 3AM Wednesday morning.

And this part would have caused us to never ship :-). If there were errors, the code could be patched and run. Now, granted, a customer site would be more cautious but their systems guy would have never stopped here. This is typically an IBMish method of developing a software package. Find one error, stop, fix, go back to step 1 of the build. This is the style of work one had to do when cards were the only coding medium. None of the PDPs would have tolerated this long delay.

We used a similar style of development with the exception that we did these things in minutes, days, or a few weeks. The weeks only happened at the very, very, very beginning of a major development project where everything is broken.

That may be what I'm thinking of--if that is the reason it took more than a few minutes to boot and be up for operation. No PDP-10 site would tolerate any booting that took 30 minutes. TOPS-10 took a minute or two to zero all of memory and that caused technical people to twitch. Twitching was not a good thing and an indication of "needs work".

Zeroing memory was the only thing that my bit gods couldn't improve; they always honored the laws of physics and never broke them.

BAH