The puzzle of why the emulators for these complex environments are so much smaller than the native environments is solved by considering several factors. First, KeyTECH and the KeyTECH objects provide much of the function that is common to all operating systems, so this code is not repeated in the emulators. Second, the object orientation of KeyTECH reduces the complexity of many tasks, particularly emulation. And finally, most applications use only tiny portions of the facilities of complex environments, and vast portions of the environment can be omitted from the emulation until required.
KeyKOS emulation environments are composed primarily of KeyKOS objects called domains. A KeyKOS domain is a fundamental object which executes some code (its program) and contains some data and some keys that the program can reference. Domains are durable; they remain in existence until explicitly destroyed. A domain can be thought of as a stylized virtual machine having its own memory and registers and exerting authority over various resources.
These three objects interact to provide the Reduced MVS environment. Not all MVS functions are supported by this emulator, specifically multi-tasking (which is provided in KeyTECH by separate instances of objects for each task). With the exception of PL/I multi- tasking support, all of the compilers and the output of those compilers run in this environment.
The following sections describe each of the three domains and their interaction. Refer to Figure 3-1 for a graphic representation of their relationships.
Figure 3-1
Multi-tasking support can be provided by having more than one User Domain share the same address space and the same OS Simulator Domain. This approach takes the maximum advantage of the KeyTECH system to actually perform all the task scheduling and address space management functions.
Figure 3-2
All Diagnose and other privileged instructions are handled by the CP Simulator domain. CMS SVCs are reflected back to the CMS domain by SVC assist code in the kernel rather than to the CP Simulator. This small change to the KeyTECH kernel made a significant improvement in the performance of CMS in this emulated environment.
CMS contains its own file system, which relies on the concept of virtual disks provided by CP. The CP simulator contains code that emulates mini-disks using KeyTECH segments. This emulation includes simulating channel programs which read and write data and key areas when it simulates count-key-data (CKD) devices.
Each user's CMS has a companion CP simulator which knows only about that single CMS domain. Support of inter-CMS communication such as spool files, IUCV, and MSG is handled by a VMGROUP object that defines a VM community.
Disk sharing is not handled in the CP or VMGROUP objects. Each minidisk is packaged into a LINK object which handles the access interlocks. This insures that only one CP simulator at a time can be using the disk in a read write fashion. Each CP simulator has a directory of LINK objects that constitute the authorized disks for that user.
UNIX concepts such as I-NODEs and Directories are emulated with corresponding KeyTECH objects. This practically one-to-one mapping to KeyTECH objects eliminates almost all of the complex UNIX kernel code required to handle these structures. Figure 3-3 shows the relationships of these components.
Figure 3-3
A UNIX logon begins with the KeyTECH receptionist calling the INIT object with Keys to the logon terminal. INIT is a special process that is partly a KeyTECH native object and partly a UNIX process. As a UNIX process, it has a kernel emulator and can perform standard UNIX system calls. It also can manipulate Keys directly. It uses its mixed heritage to make the transition from KeyTECH to UNIX smoothly. INIT forks a process and loads the Shell into what becomes the head of the user's process family. It then uses the Keys to the terminal to build an object that emulates the UNIX terminal functions (/dev/tty). At this point the user is connected to a pure UNIX Shell in a complete UNIX emulated environment.
A UNIX file system is represented as a Key to the Root Directory of the file system and an accompanying File Table. When a file is opened, the KeyNIX kernel emulator uses directory objects (Record Collections) to look up the name of the file. Directories are KeyTECH B-Tree objects, so the search logic is not in the kernel emulator. The Key returned by the Directory object is to an I-NODE object. The KeyNIX kernel emulator sends messages to the I-NODE object to OPEN the I-NODE. This action causes the I-NODE object to create a File Accessor Object that understands the correct file protocol for the particular type of file. The Keys to the I-NODE and the File Accessor are kept in the file table.
When a process Forks, its memory is copied and a new domain and domain keeper are built. The process table entries for this new process are copies from the process table entries of the mother task so that the File Table entries are shared for opened files.
CICS applications also need to communicate with each other, and this inter-transaction communication requires a common object (system interface) to emulate the CICS region functions.
CICS transaction applications fit best into a KeyTXF (Key Logic's transaction processing facility) environment in which some of the transaction management functions are already provided. In this environment, a transaction manager initiates a transaction of a particular type and gets an instance of the appropriate application pre-linked with the CICS subroutines. Subsequent CICS calls that require inter-transaction communication or chaining of transactions to other transactions go to the CICS region emulator. It is associated with the CICS community which is controlled by that particular KeyTXF transaction manager.
The EDL Program Domain's address space is divided into two parts. The lower 64K represents the EDX partition. The data area is laid out here identically with the layout in the real environment. Each EDL statement is represented in this 64K area by a 4 byte place holder indicating the address of the code which emulates that EDL instruction in the domain's address space above the 64K boundary.
EDL statements are compiled into System/370 instructions in the address space above 64K. This allows the emulation to preserve all 16-bit addresses, including branch addresses and exit addresses. The code compiled to execute the EDL GOTO instructions and the code that handles the exits both use the place holder address to find the real address of the branch or exit.
All EDL Program Domains from a single Series/1 share an EDX emulator. This emulator handles system calls (SVCs) from the compiled EDL code and manages tasks, timer services, I/O requests and communication requests. Some of these requests may be handled by subroutines included in the EDL Program Domain. Attached tasks of an EDL program are supported by separate domains that share the same memory of the parent domain (much like OS multi-tasking).