Removable Checkpoints

There is now a facility to produce checkpoints on tape. This involves code in the kernel and outside that is not documented yet.

We consider here functions that must be performed by people on a moment's notice to support the function of the system. We segregate these functions according to whether the people are required to be in the machine room.

Machine Room Functions

IPL & Shutdown
We now support IPL'ing and restarting from a checkpoint.

It seems that warnings of shutdowns must be integrated to some extent with the application. Newer work stations require specialized support in order to get a message to the operator at that station. The nature of the application may require special considerations with regard to shutdown. There may be other systems outside the computer center (not just the "users") that need to be warned.

The collection and analysis of hardware malfunction information.
disk and CPU

Network operations control
These operations must be in the machine room because the people normally informed about the state of the network and the adjacent network hardware are there.

For each base perceived by the kernel:

answer

shut

Display of configuration information. The operator needs to know:
how much core the kernel thinks there is,

what DASD addresses are currently "mounted" in the Gnosis kernel terminology.

at what addresses the kernel will recognize disk drives,

what Tymnet bases are in what states,

at what addresses the kernel will talk to Tymnet bases.

How many circuits are thru each base and to some as yet unspecified degree, who they are.

Security may require some discretion here. Circuits to servers should be known to operators contemplating stopping a base.

Reconfiguration of core & disk.

Messages to users who are willing to receive.

There needs to be a way for a terminal system to subscribe to some broadcast service, such as warnings from operations about impending stoppage of service.

There also needs to be a system status bulletin board available upon which to post downtime schedules and such.

Problems
What happens if a twinned pack is momentarily dismounted (to move it) when the kernel decides to swap out a page onto that range? Is the twin ruined?

Gnosis disk packs may be initialized so that some of the information on them is stored redundantly.

Normally this is done so as to provide safety against failure of disk drives. In this case we are likely to place the redundant storage on different controllers and better different channels.

Each time a page or nodepot is written into this redundant it is quickly written into both. Upon reading either copy is used depending on busyness of the hardware.

Upon reintroduction of the repared drive we initiate a resynchronizing process to return to the redundant state.

{ni}Spare Drives

Concern has been expressed over the eventuality of a disk failure while its twin is being repaired. Repairing a drive may take a day. One is nervous about depending on a single drive for that day. The following greatly reduces that exposure: We configure several hot spare drives. When the kernel detects a damaged drive it assigns one of these spare drives to assume the role of the new twin of the surviving twin. The ex-spare is immediately formatted with ranges matching the broken drive and then the drive is adopted by the kernel for normal "re-synching".

In this scheme the exposure is limited to the likelihood of a disk failure in the 20 to 40 minutes required to regenerate the new disk.