SuperTerm Maintenance Manual

[Paul Koning]

> On Feb 1, 2018, at 1:01 PM, Eric Smith <spacewar at gmail.com> wrote:
> 
> On Thu, Feb 1, 2018 at 10:56 AM, Paul Koning <paulkoning at comcast.net> wrote:
> > On Feb 1, 2018, at 12:51 PM, Eric Smith via cctalk <cctalk at classiccmp.org> wrote:
> > console terminal [...] VT52. (It was not good
> > practice to use a CRT as the system console, IMO.)
> 
> As for CRTs, it all depends on the design assumptions.  Lots of operating system console interfaces are designed on the assumption you have hardcopy consoles, and if so a CRT is a bad idea.  But you can certainly make CRT consoles and have it work -- consider the CDC 6000 series.
> 
> Just a wild-ass guess, but I suspect that a typical CDC 6600 system would have had a printer that logged console interaction?  I'm only suggesting that a CRT console with no logging was a bad idea.

True.  The CDC OS would log anything interesting to a "dayfile", essentially a running log of system events including operator actions.  Those go to disk.  Dayfile messages related to a particular job would also be printed with that job output.

> Of course, in principle the logging could be to disk or tape, but I don't think most "machine-room" people would have trusted that nearly as much for a console log. One wants a log of what happened on the console even when the system was not working well.

I guess they trusted the disk enough.  Normal practice would be to save the dayfile to a regular disk file periodically (perhaps as part of daily maintenance), at which point you could print it, or archive it to tape, or whatever else comes to mind.

There was also the "accounting log", a second dayfile with accounting related messages coded in a fashion that made it straightforward to extract the data for billing.  And an "error log" with messages related to hardware problems (I/O errors with the hardware error detail data).

	paul