KeyKOS

null

Web site: cap-lore.com/CapTheory/KK/
Origin: USA
Category: Microkernel, Others
Desktop environment: CLI
Architecture: IBM S/370, IBM Mainframe
Based on: GNOSIS
Wikipedia: KeyKOS
Media: Install
The last version | Released: ? | ?

KeyKOS – an operating environment for S/370 computers which provides a high level of security, reliability, performance, and productivity. It allows emulation of other environments such as VM, MVS, and POSIX.

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.

KeyKOS is a predecessor of the EROS and its successors are CapROS and Coyotos operating systems.

Download

No download is available.
md5sum:

 

EROS

null

Web site: www.eros-os.org (not active)
Origin: USA
Category: Microkernel, Others
Desktop environment: CLI
Architecture: x86
Based on: KeyKOS
Wikipedia: EROS
Media: Install
The last version | Released: 1.1 | April 18, 2001

EROS (Extremely Reliable Operating System) – an operating system being implemented at the University of Pennsylvania, as a clean-room reconstruction of an earlier system, KeyKOS. The system merges some very old ideas in operating systems with some newer ideas about performance and resource management. The result is a small, secure, real-time operating system that provides orthogonal persistence.

EROS is a pure capability system. Authority in the system is conveyed exclusivly by secure capabilities, down to the granularity of individual pages.

The EROS kernel itself is implemented using multiple kernel-mode threads. This improves the performance of EROS drivers, makes them simpler to code, and greatly simplifies the design of the kernel. In addition, it enables selected kernel functionality to be preempted by higher priority user activities.

Because EROS processes are persistent, processes can hold authorities in their own right rather than inheriting them from the user. This enables a rich variety of options for security and access control that are impossible in systems lacking persistent processes.

EROS developed beginning in 1991 by The EROS Group, LLC., the Johns Hopkins University, and the University of Pennsylvania. Features include automatic data and process persistence, some preliminary real-time support, and capability-based security. EROS is purely a research operating system, and was never deployed in real world use. As of 2005, development has stopped in favor of two successor systems, CapROS and Coyotos.

The project founder is Jonathan Shapiro. He is also the driving force behind Coyotos, which is an “evolutionary step” beyond the EROS operating system.

Download

No download is available.
md5sum: