More items from Risks.
From the Risks Digest, Volume 17, Number 19, 19 June 1995:
Thu, 15 Jun 1995 19:45:13 -0400
I, too, am glad to see that Multics is still used. It is a system that was far ahead of its time in many respects.
In MTS (the Michigan Terminal System), a system contemporaneous with Multics which is also still in use, we solved the problem of the operators entering a bad time in a slightly different way. During initialization, the system compares the current time with the time in the last billing record recorded. If the current time is earlier or too much later (more than 12 hours, unless the day is Sunday in which case 18 hours is ok) it complains and asks the operators to confirm that the time is ok. This has several advantages: it doesn't use hard-coded dates, it is a more precise check, and it never makes the system unusable. Of course this has become less important as modern machines maintain the time of day even when not running and the clock rarely needs to be set at all.
Mike Alexander, Univ. of Michigan
And an earlier note to Risks, Volume 17, Number 18, 15 June 1995 that Mike was probably responding to:
8 Jun 1995 22:45:59 GMT
[A woodka tonic forwarded to RISKS by Donna Woodka, who probably knows my penchant (or even pun-chant) for Multics tales. Thanks to Bernard for having fortifived our archives and providing evidence that Multics still lives! PGN]
Ward Anderson at ACTC just reported an interesting crash on Multics (10.2) at ACTC -- Collection 1 initialization discovered that I became 45 years old Tuesday past, an event which was extremely unlikely, and crashed the system before the clock did damage to the file system, or so it feared.
The code in scs_and_clock_init is perfectly clear - the time "06/06/95 18:31 est Tuesday" is hard-coded in, in characters, with the comment that it is "Bernard S. Greenberg's 45th birthday". It has been there for twenty years in plain text visible to anyone reading the code! (I loved to read code in my day, especially initialization - perhaps I was the last?)
Maybe Tom Van Vleck remembers, but it is extremely likely that twenty years ago at CISL our operator at the time for the nth and last time forgot to set the clock, or set it poorly, and damaged the file system (which looks quite askance on "back to the future" jaunts), and Tom and I said "This has to end. We have to put a gullibility check in the clock init code", and I did this. Probably saved a lot of file system damage over the years. If I had it to do over again, I'd do it over again! This code did the -right-thing-!
At 25, I could not imagine I'd ever be 45, let alone that scs_and_clock_init.pl1 would be there along with me! Somehow, though, 65 doesn't seem that far away any more...
As Ward said, this is a -real- Multics story.Bernie