Figure 3-1In each of the sections that follow, an architectural overview of several environment emulators will be discussed. These specific examples cover a broad range of environments and a broad range of emulation techniques. The largest of these emulators consists of some 20,000 lines of assembly language and the smallest is 5,000 lines of C (which is roughly equivalent to 20,000 lines of assembly language).
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.
The MVS emulator (KeyRMVS) is probably the most complex because it is a hybrid of Application Interface and System Interface emulation. The basic structure consists of three objects. The application program and the run time libraries are bound together and provide the program for the User Domain. The OS System Interface emulation is done in a second object that acts as the Domain Keeper of the User Domain and is often referred to as the OS Simulator Domain. The third object is a file definition (FILEDEF) object that manages the mapping between data definition name (DDNAME) and the data set name (DSNAME). FILEDEF is the name of this function in CMS.
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
The FILEDEF domain has two interfaces. The user interface interprets commands that bind DDNAMES with DSNAMES. In KeyTECH, the DSNAME is actually the name of a key in the user's directory which designates the KeyTECH storage object that contains the data. These storage objects can be Segments, Record Collections, Tapes, or Terminals. There is a program interface to the FILEDEF domain that is used by the OS Simulator Domain (during OPEN, for instance) to resolve the mapping between DDNAME and the KeyTECH storage object that will act as the file (DSNAME).
The OS Simulator Domain is responsible for handling the supervisor calls (SVCs) issued by the User Domain. Each OS system call is made using a different SVC. The OS Simulator Domain windows over the memory of the User Domain so that it can easily move data into and out of the User Domain as it constructs and processes the same control blocks that would be processed by the native MVS system. For instance, the OPEN SVC is handled by constructing all of the IOB, DEB, DECB, JFCB, and other control blocks that MVS would construct and by linking those control blocks into the data control block (DCB) that is being opened. These control blocks are maintained with enough detail to keep the runtime libraries of PL/I, COBOL, and other languages convinced that MVS is actually providing the I/O services.
The User Domain consists of the user application bound with the normal runtime library and an additional runtime library which supports the access methods (BSAM, QSAM, QISAM, BDAM, etc). When the user program access a file, the runtime library issues an OPEN SVC which is handled by the OS Simulator Domain. It in turn builds the control blocks and their KeyTECH extensions that map the DCB to a capability (Key) that was obtained from the FILEDEF Domain. When the application reads the file, the access method emulation routines are called as subroutines from the library. Those routines directly use the Key to the KeyTECH storage object to move data in and out of the buffers pointed to by the IOB and the application data areas.
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.
The CP Simulator is an example of a System Interface emulator. It consists of two main components and some auxiliary domains, depending on the configuration desired. The CMS operating system and the CMS applications are in the CMS domain. The simulation of CP functionality and privileged instructions is handled in the CP Simulator domain, which is the Domain Keeper of the CMS Domain. Figure 3-2 shows the relationship between the domains of this environment.
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.
The KeyNIX environment is also a System Interface emulation which consists of a pair of domains for each UNIX process. The User Process Domain contains only the application code and its Domain Keeper simulates the UNIX kernel for that process. All the processes in a UNIX community share a common Process and File table.
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.
The emulation of the CICS environment presents another opportunity to use a hybrid approach. The Command Level interface to CICS is an extremely well defined interface to CICS system functions. All system functions go through CICS command invocations (application interface) with no exceptions. Well behaved CICS applications are those which use the command level interface exclusively and do not depend on the specifics of control block structure or contents.
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 Series/1 EDX operating system presents an opportunity similar to the KeyCP product. In this proposal, each EDL program is a cluster of domains (one per task) that shares an EDX emulator with all other EDL programs in the same "system". Several of these "systems" can operate simultaneously on the KeyTECH platform, each one of which represents a Series/1 computer system.
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).