Category: Microkernel, Others
Desktop environment: CLI
Architecture: IBM S/370, IBM Mainframe
Based on: GNOSIS
The last version | Released: ? | ?
When Tymshare started work on KeyKOS in the early 1970s, there were solid business requirements justifying the project. With the price of main storage dropping, applications were too tightly bound to disk storage. Because Tymshare’s systems were accessed from around the world, continuous operation was a requirement. Existing systems were prone to failure from many causes, both hardware and software. They did not recover from these failures gracefully. These systems required significant operator intervention in both normal operation and during recovery. They did not provide the security needed to allow competing organizations to share programs and data in a controlled manner where it made economic and social sense.
Because of these deficiencies, Tymshare decided its best option was to build a system of its own. This system had a number of design goals including: high security, high reliability, economical processing of high transaction volumes, and enhanced productivity for managers, programmers, users, operators, and hardware.
KeyKOS provides persistent virtual address spaces where programs may keep data. The system caches frequently referenced data in main storage. When several processes are accessing the same data, for example the CMS “S” disk, the data blocks involved are likely to already in main storage, improving access times. Only one copy will be maintained in main storage, improving storage utilization. Persistent virtual storage allows the kernel to globally optimize disk arm movement and rotational latency. The KeyKOS implementation also provides complete separation of physical and logical DASD management. No unprivileged program is aware of the type or configuration of real DASD in the system.
KeyKOS has a system-wide checkpoint which periodically saves the state of the entire system. If a system outage occurs, the system will restart from the last checkpoint with all data and processes in a consistent state as of that checkpoint. The KeyTXF transaction processing system will recover database updates to the point of failure. Should a CPU fail, the DASD can be shared with or switched to a backup CPU to quickly restore service by restarting from the last checkpoint.
Data mirroring stores multiple copies of data for reliability and performance. The KeyKOS system continues to operate if a mirrored disk fails. When the disk is repaired, or a replacement disk is formatted and brought online, the mirrored data is automatically restored to that disk. Performance is enhanced by having several paths to a particular piece of data. The full function of the system is available in essentially any S/370 computer language. A standard invocation protocol permits high level languages to invoke low level function and low level languages to invoke high level function, enhancing the usefulness of all languages.
The KeyKOS system is designed for unattended operation. The only common operator functions are mounting tapes and servicing the printer.
The KeyKOS system is designed for continuous operation. Full system backup dumps may be taken while the system is running. When a dump has completed, the backup tapes contain an image of all data and processes in the system at a consistent instant of time. avoiding inconsistency in the data. These “tape checkpoints” are conceptually independent of the physical DASD type or configuration. They may be restored to different physical devices if necessary.
KeyKOS/370 runs on System/370-compatible single processor CPUs. It currently supports 3330, 3350, and 3380 count key data format disks and 3370 FBA format disks. System software includes the context switcher and two command systems.
Copyright © 1985, 1987, 1988, 1990 Key Logic. All rights reserved.
Permission to reproduce and redistribute this document in paper or electronic form is hereby granted, provided that this copyright notice remains intact.
No download is available.