PREVIOUS
Chapter 1. Overview
Platform
The principle guiding the development of the KeyTECH system was to
provide a portable extension to modern computer hardware that
transformed the hardware interface into one which was better suited
to the sophisticated application systems both planned and under
development. The resulting KeyTECH architecture consists of two
basic parts: the platform and a number of application environments
that run on that platform.
KeyTECH is a software platform upon which a variety of applications
and application environments run. It consists of a kernel, which runs
in the privileged state of the machine, and small set of non-privileged objects. This platform provides the fundamental functions
of most modern operating systems. These functions can be classified
as the Physical Resource Manager and include: real memory
management, DASD management, and CPU management.
Figure 1-1 illustrates this platform concept. It is the intention of this
manual to provide a basic understanding of how environments are
built and applications are run on top of this platform.
Figure 1-1 [1]
The programming environment presented by this platform supports
Objects and Capabilities. Objects are an embodiment of the Physical
Resource Manager in that they each have a separate virtual address
space of extremely large size (48 bit address) and are separately
scheduled. The small set of objects that are part of the KeyTECH
platform provide for space management, timer services, and other
fundamental system services.
It is upon the KeyTECH platform that applications and application
environments run. Those which are designed to make direct use of
KeyTECH facilities are called native environments. Those
which were designed for other hardware and operating system
facilities, but which are supported on the KeyTECH platform, are
called guest environments. Since the platform provides
the basic services of most modern application environments, it is
easy to simulate these guest environments on the KeyTECH platform.
Because the underlying platform also provides for basic
communication and data sharing facilities, it is possible to have
applications in multiple environments running simultaneously and
sharing data.
An underlying principle of building application environments on the
KeyTECH platform is that of allowing KeyTECH to handle all aspects of
multi-tasking, memory management and I/O management. Often
this means that each application in a simulated environment is
supported by a private instance of the environment. KeyTECH
supports "instantiation" of its objects in much the same
way as a "type manager" in object-oriented languages
support instances. Instances of the same KeyTECH object have their
own address space, are scheduled separately, yet share a single copy
of the code. This facility allows KeyTECH to handle all aspects of
multi-tasking. This single principle is responsible for much of the
ease of development of guest environments.
Key Logic has designed and built two native environments which run
on the KeyTECH platform. These environments are designed to
support applications which take advantage of the fundamental
features of the KeyTECH platform: capabilities and object orientation.
By combining Objects with Capabilities, these environments allow the
development of efficient and sophisticated application systems.
- KeyKOS -
- a capability-based operating system which provides knowledge of
and direct access to the primitives and underlying features of KeyTECH:
specifically objects and keys (capabilities). It provides tools and utilities for the
support of application systems: building, using, managing, and deleting objects.
- KeyTXF -
- a high performance transaction processing system which provides
extremely cost efficient transactions with high integrity. It includes standard
features such as full commit-abort logic, automatic journaling and replay, and
monitoring and control. Programmers need only code specific transaction
programs and configure them into the basic framework.
Key Logic has designed support for a number of guest environments
and has implemented three of them. These guest environments
support applications which were designed to meet the specifications
and functionality provided in the original environment without
having to alter the application code. Often it is possible to enhance
the application code in such a way as to combine guest environment
compatibility with the ability to communicate directly with objects
using capabilities. For instance, function and data in one
environment can be made available to applications in another
environment. This provides a powerful tool for application growth.
- KeyRMVS -
- This product provides support for a subset of
MVS products and applications which do not require multi-tasking in
a single address space (use of the ATTACH macro). This environment
supports programs written in higher level languages which call upon
system services through standard product run time libraries.
- KeyCP -
- This product provides support for the execution of
CMS, a component of IBM's VM/SP program product. KeyCP runs
CMS, as generated from the TEXT decks and object modules provided
on the VM/SP distribution tape, without modification. Most products
that run in CMS under VM will run in CMS under KeyCP, also without
modification. Each user's CMS runs in its own object and is supported
by a private instance of the KeyCP product. Sharing of CMS disks,
spool files, and IUCV messages are handled by unique KeyTECH
mechanisms.
- KeyNIX -
- This is Key Logic's implementation of a Version 7
UNIX kernel on the KeyTECH platform. This product currently
supports all the kernel functions required by MINIX[2] and the MINIX
utilities. The utilities must be re-compiled with a C compiler for the
System/370. Each UNIX process runs in a separate object and has a
private instance of the KeyNIX kernel emulator to support it. All
processes in a UNIX community share a common file system.
- KeyCICS -
- This environment is designed to support CICS
applications coded to meet the CICS command level interface. Each
CICS transaction runs in its own object (a private address space). All
CICS transactions that are treated as being in a single CICS partition
share a common KeyCICS environment emulator.
- KeyEDX -
- This environment is designed to support EDL
applications written for the Series/1 EDX system. Each EDL task is a
separate object, and all objects that are part of a single EDL program
would share the same memory. A single KeyEDX emulator supports
all the EDL programs that would run in a single Series/1.
Figure 1-2 illustrates several of these environments operating
simultaneously on a KeyTECH platform.
Use of application environments do not impose a layer of software
between the application and the KeyTECH platform. The application
runs in a KeyTECH supported object and executes native System/370
instructions until it requires a system service that is normally
provided by the operating system for which the application was
designed. When the system service is requested, a message is sent to
another KeyTECH object that is emulating the guest environment.
This "environment emulating object" either performs the
required service directly or sends messages to other KeyTECH objects
to provide the service.
If desired, the guest application source code can be easily modified
so that the application can directly access KeyTECH objects that
supply basic services such as data files, timer services, and
communication services. Since all KeyTECH objects run directly on
the KeyTECH platform and can be reached directly by any other
object, system services are delivered directly to applications without
going through some imposed system hierarchy.
Figure 1-2
Guest applications are generally run in their own address space, even
if the application running in the real environment would have shared
its address space with other applications. Multi-tasking is
accomplished by replicating the application and its guest
environment emulator so that each task is separated from all other
tasks. This instantiation into distinct objects increases the overall
reliability of a complex application, even when the application itself
contains bugs. Individual instances of the application may encounter
the bug without affecting other instances, which are running the
same application code but are servicing other tasks.
Data sharing is accomplished by using KeyTECH mechanisms that can
insure the proper isolation. Many copies of an application can share
read-only memory and read-write memory as required.
Applications that share read-write memory are not as isolated from
interference with each other as are those that share only read-only
memory. Data can be passed quickly and efficiently between
applications using the capabilities provided by KeyTECH.
The remainder of this document discusses the architectural
components which facilitate the creation of and support of such
diverse environments on a single platform - even some which are
not "native" to the System/370. Specific examples of
guest environments will be examined in some detail to illustrate how
these components are combined.
NEXT