Virtual machines in OS/390 for execution of any guest system

Abstract

A method and system comprising a single IBM S/390 computer architecture running an OS/390 operating system, and at least two guest systems executing within the S/390 computer architecture. Each guest system comprising an execution space, allocated within the virtual memory space of the S/390 computer architecture, in which a guest program or operating system may be executed. Each guest system is configured such that if a Start Interpretive Execution instruction in invoked, the instruction is interpreted and a corresponding function is performed in its place to simulate, for the guest program or operating system, the effect of the IBM S/390 computer architecture. Control is then returned to the guest system at the next instruction after the Start Interpretive Execution instruction, thus allowing the guest program or operating system to execute transparently.

Claims

What is claimed is:

1. A system comprising a single IBM S/390 computer architecture running an OS/390 operating system, and at least two guest systems executing within the S/390 computer architecture, each guest system comprising an execution space within which a guest program or operating system may be executed, each guest system further characterized in that if a Start Interpretive Execution instruction is invoked, the Start Interpretive Execution instruction is intercepted and a corresponding function is performed in its place to simulate, for the guest program or operating system, the effect of the IBM S/390 computer architecture; whereby the guest program or operating system is able to execute transparently.

2. A method for executing at least two guest programs or operating systems each transparently on a single IBM S/390 computer architecture running an OS/390 operating system, the method comprising:

establishing for each guest program or operating system the IBM S/390 computer architecture;

intercepting an invocation by a guest system of a Start Interpretive Execution instruction;

performing in the place of the Start Interpretive Execution instruction a corresponding function to simulate, for the guest program or operating system, the effect of the IBM S/390 computer architecture; and

restoring control to the guest system at a point just after the interception of the Start Interpretive Execution instruction.

Description

FIELD OF THE INVENTION

The invention relates generally to an OS/390 virtual machine. More particularly, the invention relates to a virtual machine allowing fast migration of the applications from any operating system to OS/390.

BACKGROUND OF THE INVENTION

Computer operating systems and independent computer systems or applications (stand-alone programs) are the two main kinds of software products essential for information technology. In the past, with some hardware platforms, if a user needed to use different operating systems and/or independent programs, it was necessary to run them either on different computers or on the same computer one after another, which required shutting down the previous program before loading the subsequent one. An example of such computer architecture was the development of IBM 360-370.

One example of a situation requiring the ability to execute two operating systems of different types or versions simultaneously arises during a migration from an old operating system to a new one. This ability is also needed when one consolidates in one computer center a number of operations previously carried out in separate computer centers with different equipment.

In the past the disadvantage of having to use numerous computers for simultaneously running various operating systems and/or stand alone programs has been dealt with in two ways:

by using special operating systems, such as, for example, IBM's VM operating system, allowing execution of other operating systems as its own tasks; and

by logical partitioning (LPAR), which allowed independent execution of different operating systems or stand alone programs on one computer (such as, for example, IBM's LPAR in the 390 architecture).

Although both solutions make it possible to run various operating systems and/or independent programs on one computer, such approaches have a number of drawbacks.

In case of a VM operating system, instead of using additional computers it becomes necessary to use an additional operating system. In other words, one additional resource (extra computers) is substituted by another additional resource (operating system). The VM approach merely substitutes one problem for another--while it saves the use of additional computers, it requires the use of an additional operating system. An illustration of this drawback is the process of migration from an old operating system to a new one using a VM. Instead of using two (new and old) operating systems, the third operating system (VM) becomes involved, which increases costs, requires extensive personnel training and adds to resource requirements.

In case of logical partitioning, there exist the following three drawbacks:

1. A computer can be partitioned into only a limited number of LPARs (15 for IBM 390). However, it is often desirable to be able to execute more different operating systems and/or stand alone programs on one computer, in which case 15 LPARs is simply not enough.

2. Limited access from one operating system to the capabilities of another operating system or stand alone program running simultaneously on the same machine. For example, since LPAR 390 was specifically designed for separating different processes, interaction of operating systems running in different LPARs is basically similar to interaction of operating systems on separate computers.

3. Transition from dynamic resource allocation in case of one operating system to static resource allocation in LPAR, resulting in a loss of the possibility to reallocate available resources during execution. Such a loss results in insufficient exploitation of existing resources and capabilities or in the need to buy additional resources.

It is, therefore, desirable to have a system and method for a fast and efficient migration of the applications from any operating system to OS/390. Thus, there is a need in the art to develop a program and method for executing different operating systems and/or stand alone programs on one machine without using special operating systems or without having to use partitioning.

SUMMARY OF THE INVENTION

The present invention overcomes the drawbacks and disadvantages existing in the art by enabling the execution of any non-OS/390 operating system and its applications as a guest task in the OS/390 environment. Such execution is accomplished by creation of an interpretive space--a virtual storage area of the OS/390 address space used by the present invention in interpretive execution mode of ESA/390.

It is, therefore, an object of the present invention to allow users to execute simultaneously on one computer various operating systems and applications (collectively called "guests") without having to use special operating systems, such as VM, but using an operating system already existing in a computer (such as OS/390 or VSE).

It is another object of the present invention to allow a more flexible resource allocation for guest execution than that of LPAR or VM.

Yet another object of the present invention is to enable guest execution of either IBM or non-IBM 370-390 operating systems in OS/390-VSE on the computers implementing S/390 principles of operation. Among these are all IBM 9672, multipurpose 2000, P/390, R/390 computers.

It is also an object of the present invention to provide for such execution of any guest system on the S/390 platform, which will not require any changes in a host system and in a guest system of any vendor.

It is also an object of the present invention to provide for fast and seamless transition of an application running on any operating system to OS/390, consolidation process based on one machine without LPARs under OS/390 with dynamic resource allocation.

It is yet another object of the present invention to give access to OS/390 system facilities to applications normally executed in other operating systems, such as S/370, and to reduce the average system reaction time on the same equipment (reduction of start-stop time for task execution by transferring I/O from 370 to 390).

In OS/390 address space controlled by the present invention, the OS/390 operating service is replaced by an operating service required by various application programs. Several OS/390 regions can be used by the present invention to run different applications in their own operating environment simultaneously. Running non-OS/390 applications in OS/390 address spaces, controlled by the present invention, lets OS/390 users work with those applications and their operational environment while sharing the OS/390 system resources with other users.

Functionally, the present invention is an OS/390 task, which allows it to use OS/390 capabilities unavailable in VM and LPAR. For example, DPPX and VSE IBM operating systems being executed in the interpretive space provided by the present invention can use virtual FBA (Fixed Block Architecture) disks located on VSAM (Virtual Sequential Access Method) files. Since VSAM files are visible for OS/390, OS/390 technologies can be used for DPPX and VSE disk images and DPPX and VSE files, which is impossible in other cases. Another example is a virtual inernetworking capability between guest systems being executed in OS/390. For instance, various DPPX or VSE guests executed in the interpretive space of the present invention can interact with each other via virtual TRN (Token Ring) without exiting to the physical network.

Compared to LPAR, the number of guest systems executed with the help of the interpretive space of the present invention is not limited to ten per one machine. Dynamic resource allocation is more efficient among OS/390 tasks (guest systems under ISX) than between LPARs. DPPX and VSE operating systems together with their applications become executable in OS/390 SYSPLEX (a multi-computer complex).

Compared to VM, ISX's requirements for various resources, including maintenace, are very insignificant. ISX needs several segments of the main storage and several volume tracks.

The execution of applications with their own operational services is essentially simplified due to OS/390 resource allocation and control facilities, and the device emulation facilities provided by the present invention. Implementation of the present invention takes full advantage of the ESA/390 Interpretive Execution Mode.

Any operating system (except VM/ESA) together with applications could be executed in the virtual machine created by the present invention. At the same time it is possible to start some independent virtual machines in OS/390, in which different operating systems (for instance, DPPX, VSE) could be executed as OS/390 tasks. Therefore, the OS/390 functionality becomes accessible for other systems. The present invention provides virtual facilities for disks, networks and terminals, creating a possibility to transfer the processing to other geographical locations (transferability/mobility).

The present invention is used to achieve fast and inexpensive outsourcing, such as guest executing of non-OS/390 operating systems and tasks in OS/390, consolidation of various information technologies on OS/390 (for example, transfer of DPPX, VSE, MVS execution to OS/390), fast migration to OS/390, resulting in consolidation of computing equipment.

These and other advantages of the present invention will be more readily apparent from the detailed description of the invention and the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWING FIGURES

FIG. 1 is a block diagram illustrating the general structure of ISX/390.

FIG. 2 is a block diagram illustrating the three parts of the main ISX process.

FIG. 3 is a block diagram illustrating the real I/O guest execution process.

FIG. 4 is a block diagram illustrating the general structure of device emulation.

FIG. 1.1 is a diagram illustrating the process of fast migration to OS/390.

FIG. 1.2 is a block diagram illustrating dynamic resource allocation upon consolidation of various operating systems on OS/390.

FIG. 1.3 is a block diagram illustrating a consolidation process.

FIG. 2.1 is a block diagram illustrating the structure of the ISX.

FIG. 3.1 is a block diagram illustrating communication between a host and guest applications.

FIG. 3.2 is a block diagram illustrating execution of operating systems and applications.

FIG. 4.1 is a block diagram illustrating the process if fast migration to OS/390.

FIG. 5.1 is a block diagram illustrating the process of switching from static to dynamic resource allocation.

FIG. 6.1 is a block diagram illustrating the process of overcoming restrictions of an old operating system.

FIG. 7.1 is a block diagram illustrating a joint system environment.

FIG. 8.1 is a block diagram illustrating a TCP/IP connection to an old application.

FIG. 9.1 is a block diagram illustrating data base coexistence.

FIG. 10.1 is a block diagram illustrating network coexistence.

FIG. 11.1 is a block diagram illustrating a multi-machine system migration to dynamic networking.

FIG. 11.2 is a block diagram illustrating a mobile S/390 guest application.

FIG. 12.1 is a block diagram illustrating OS/390 common security for old and new applications (RACF).

FIG. 13.1 is a block diagram illustrating DCE common security for old and new applications.

FIG. 14.1 is a block diagram illustrating creation of static and dynamic windows.

FIG. 15.1 is a block diagram illustrating virtual time structure.

FIG. 16.1 is a block diagram illustrating S/390 back up operation.

FIG. 16.2 is a block diagram illustrating the configuration of back up centers.

FIG. 17 is a table illustrating the ISX family of system products.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

From the point of view of the host operating system (such as OS/390), ISX is a user's application program that is running under control of the host operating system as a usual user's work process.

During initialization ISX creates a number of subprocesses for execution of its functions using standard facilities of the host operating system (FIG. 1.1). The highest priority subprocess is designed to perform ISX communications with the ISX operator via the console facility of the host operating system.

Lower priority subprocesses are created to perform emulation of different types of I/O devices. The lowest-priority process is the main ISX process used to perform service functions and execution of a guest operating system.

The main process and its subprocesses are executed in parallel to each other or on the multiprogramming base of the host operating system depending on the number of CPUs of the real mainframe.

The main ISX process consists of three parts together with a main Dispatcher that routes control to one or another of the three parts (FIG. 2). The first part of the main ISX process is the Real I/O and Guest Execution Processing. The second part of the main ISX process is ISX Command Execution Processing. The third part is Deferred Function processing. ISX Command Execution Processing is initiated by the Operator Console Communications subprocess when the ISX operator issues and ISX command. The guest execution processing is initiated by a request of ISX Command Execution Processing as the result of ISX operator order to start initial program loading of a guest system. Deferred Function Processing can be initiated by any component of ISX when it is not possible to execute a required function at the moment it is requested.

The most important function of the main ISX process is execution of a guest system and I/O operations requested by the guest system (FIG. 3). Because an operating system cannot run in any operating environment, ISX creates an environment for a guest system that looks like a real machine using the real machine instruction "Start Interpretive Execution" (SIE) from the S/390 architecture and resources received from the host operating system. The instruction is used every time when control has to be passed to a guest operating system. From the point of view of the host operating system, ISX performs a long executed machine instruction, while from the point of view of the guest operating system it is running in a real machine. When an I/O operation or a special CPU function is requested by the guest system the SIE instruction is intercepted and ISX receives control to the point just after the SIE instruction. ISX recognizes the reason for the interception and performs the corresponding function. If an I/O operation is requested with a real I/O device, ISX requests the host operating system to execute it using its standard facilities. If an I/O operation is requested with an emulated I/O device ISX requests the corresponding subprocess to handle the I/O operation. If CPU simulation is necessary to perform the corresponding handler it is entered directly. When initiated I/O operations have been completed, the corresponding I/O interrupts are reflected to the guest system.

There are the following subprocesses to emulate I/O devices for the guest system (FIG. 4):

unit record device (card reader, card punch, printer, printer keyboard) emulation subprocess;

fixed block architecture direct access storage device emulation subprocess;

locally connected display unit emulation subprocess; and

channel-to-channel or token ring adaptor emulation process.

Every emulated guest device and its state is described by the corresponding device description block and every emulated device type has its own interpreter of I/O operations. The I/O Device Dispatcher performs a routing function to emulate a number of devices in the same subprocess.

FIG. 1 represents a block diagram, illustrating various operating systems, which can be executed together with their applications in OS/390 as OS/390 tasks. The structure of the interpretive space 10 (ISX) comprises three layers, as illustrated in FIG. 2.1(a). Layer 1 is a user interface of the host operating system. Layer 3 represents a virtual machine, implementing 370 or 390 principles of operation. Layer 2 represents an execute core of the present invention. FIG. 2.1(b) shows that the present invention (layer 10) is started up as a user task of the host operating system. After the start up, the initial program load (IPL) 12 of the guest system is loaded in top of layer 10. The resulting structure, presented in FIG. 2.1(b), comprises user interface on a host operating system 14, and a user task 16 for the host operating system 14, user task 16 comprising applications 18 on top of guest operating system 12 and interpretive space 10. It is understood that as many user tasks 16 can be initiated by the host system 14 as can be handled by the host system. Guest operating system 12 denotes different operating systems executed as tasks on the host system 14.

FIG. 3.1 shows the possibilities of using virtual and real channel-to-channel adapters (VCTC and CTC) as mechanisms enabling communication between guest and host applications. Communication between guest applications G1 and G2, running in the same host operating system, is provided in a standard manner through the physical CTC (the ESCON channel) or through an interpretive space system facility--virtual CTC (VCTC), wherein the latter is provided without activating the I/O operations.

As illustrated in FIG. 3.1, communication between guest applications placed in different host operating systems, such as G2 and G3, or between native applications N1 and N2 of the host operating system is accomplished through standard CTC upon ESCON base. Additionally, native tasks of the host operating system, called agents (such as A1 and A2), were developed to allow communication between guest and host tasks. On the one hand, agents have access to OS/390 standard communication facilities, such as TSO, VTAM, TCP/IP. On the other hand, agents are connected to a guest applications (G1, G2, or G3) through CTC providing a guest application with access to the OS/390 facilities. Therefore, an application of any guest operating system is provided with the OS/390 networking facilities.

The present invention contemplates at least two ways to implement virtual interaction of different types of guest systems in interpretive space (address space to address space): virtual TRN (VTRN) and virtual Channel-to-Channel Adapter (VCTC).

The VTRN product is a virtual implementation of the following physical situation: exit from DPPX or VSE via ICA TRN to physical TRN and entrance from physical TRN via one or several ICA (Integrated Communication Adapter) TRN to one or more DPPXs or VSEs. Since ICA TRN is supported in both DPPX and VSE, any number of guest systems of this type are able to communicate via virtual network without exit to physical network.

The VCTC product is a virtual implementation of the physical connection between operating systems via a CTC adapter. Since CTC is supported in both VSE and OS/390, any number of OS/390 guests and/or VSE can communicate with each other via the virtual network of CTC adapters without exit to the physical network.

The present invention also provides for a virtual network architecture for three kinds of guest operating systems: DPPX, VSE, and OS/390. DPPX guest systems communicate between themselves and with VSE via virtual TRN. VSE guest systems communicate with DPPX systems via virtual TRN, and with OS/390--via virtual CTC. VSE systems communicate between themselves via both the virtual TRN and virtual CTC. OS/390 systems communicate between themselves via the virtual CTC. Such virtual communication capabilities enable communication between networks of different operating systems without exiting to the physical network.

FIG. 3.2 is a structural diagram illustrating execution of operating systems and applications dependent on FBA-DASD, such as DPPX and VSE, by using FBA emulation in VSAM files stored on CKD DASD. Such execution is accomplished by placing an FBA emulation product (VFBA) 30 in the interpretive space 32, which placement does not require changes either in the guest or in the host operating systems. In addition, as shown in FIG. 3.2, OS/390 has no access to VSE and DPPX files stored directly on FBA, but it can access and operate VSAM files, therefore allowing for sharing different operating systems. As a result, the VSE and DPPX files can be protected by OS/390 RACF (Resource Access Control Facility).

FIG. 4.1 represents the procedure of the fast migration to OS/390. As an example, FIG. 4.1 illustrates transition from OS 1 to OS/390. During the transient period of time, it is intended to run both operating systems: the old OS1 and the new OS/390. Fast migration of the old operating system with its applications could be performed within several hours, providing the guest applications with OS/390 system facilities.

The transition procedure comprises four steps, which do not involve any physical configuration changes of the hardware:

1. ISX is stored in the user library on disks;

2. ISX is started as an OS/390 user task;

3. OS1 is initially loaded in ISX (Initial Program Load IPL) by ISX facilities,

4. Application A1 is started up in the guest operating system OS 1 parallel to A2 in LPAR 1.

Taking into consideration the fact that training in ISX takes 2-3 hours, the system and method of the present invention allows to any application as an OS/390 guest application within one calendar day. Technical personnel can continue to use the programming language of the old operating system and does not have to know in0depth knowledge of OS/390.

FIG. 5.1 illustrates transition from static resource allocation in an LPAR machine to dynamic resource allocation in OS/390. As shown in FIG. 5.1(a), each of the formed LPARs (LPAR1-LPAR4) is supported by hardware (network equipment, terminals, printers A, B, C, D), as well as by connection to DASD. However, it is possible to improve the processing parameters on the same computer equipment by changing the logical processor configuration and using OS/390 virtual facilities without physical system changes. As can be seen in FIG. 5.1(b), the processor is loaded with only OS/390, wherein the other three operating systems (VSE 1.4, VSE 2.1, DPPX) together with their applications APP represent the IPL of OS/390 and are executed as OS/390 guests.

Comparing system configurations illustrated in FIGS. 5.1(a) and 5.1(b), it is shown that in the 5.1(b) configuration the resources of the processor, main storage unit, logical data channels from the processor to DASD are allocated dynamically. In other words, the resources are not statically pre-assigned to one of the operating systems before execution, but are allocated as required by various OS/390 tasks. Consequently, the throughput of the 5.1(b) system configuration increases due to a better use of the available computing resources, compared to that of the 5.1(a) system configuration. Moreover, in the 5.1(b) configuration each of the guest operating systems has four logical channels to DASD instead of only one logical channel, as shown in FIG. 5.1(a). The reliability of the system configuration, illustrated in FIG. 5.1(b), is higher than that in FIG. 5.1(a), because an operating system can communicate with DASD via OS/390 using any one of four logical channels. In the system shown in FIG. 5.1(a), each operating system communicates with DASD via only one dedicated channel.

As also follows from FIG. 5.1(b), since peripheral device A (or B, C, D) is equally accessible for any guest operating system, the number of peripheral devices and channel cards for both the processor and the external devices is reduced. Such reduction leads to lower total configuration costs and to the possibility of using devices B, C, D as a back up. Therefore, the advantages of dynamic resources allocation based on using the OS/390 virtual facilities are the following:

better throughput,

improved reliability,

reduction of necessary hardware equipment,

reduction of system complexity.

It is illustrative to describe what disadvantages and restriction of old non-OS/390 operating systems can be overcome by using the present invention. For example, an old operating system is often restricted to using old peripheral devices (any device through ESCON for the 370 mode, CKD (Count Key Data) disks for DPPX, tape libraries for VSE). It usually lacks access to new OS/390 system facilities (access to RACF or to the most recent protocols) and internal operating system resources.

FIG. 6.1 shows that when an old operating system, such as DPPX, runs as an OS/390 guest task by using the interpretive space of the present invention, many of the above-enumerated restrictions are eliminated. The 370 operating system together with its applications can be run on a 9672 G4 computer, which has no 370 mode and uses devices connected through ESCON. Any old application (A1, A2 in FIG. 6.1), running as an OS/390 task through the interpretive space ISX, uses the resources of the old operating system (DPPX) in monopoly, but at the same time it utilizes hardware and software resources, facilities and protocols of OS/390, and also gets some virtual time from OS/390 and other guest tasks to build timing windows or to test Year 2000 compliance.

Most problems with transition from an old operating system to a new one are associated with the old system's dependence on a particular kind of equipment, API (Application Programming Interface), middleware and network architecture. Such problems are successfully solved by executing old operating systems and applications as guests in the OS/390 system by means of the interpretive space of the present invention, as can be seen in FIG. 7.1. The solution is based on creating a joint system environment 70. In such environment, application A (76), designed for an old operating system 78, for example, DPPX, continues to use the system resources 71 operating in the old operating system. At the same time, application 76, running as a guest task in the OS/390 environment through the interpretive space of the present invention, has access to the resources 73 supported by the new operating system OS/390 (79 in FIG. 7.1). Joint environment can be used to provide coexistence of the old and new Data Base Management Systems (DBMS), or coexistence of the new and old networks during the period of transition between the new and old operating systems.

For example, as shown in FIG. 7.1, if DPPX (old OS 78)/ISX/OS/390 is run on a 9221 machine, the old FBA disks in 71 (not supported in OS/390) and the new RVA ESCON Connectors in 73 (not supported in DPPX) will be equally accessible by guest application 76, running on guest DPPX OS 78.

Applications running in the old operating systems, such as VSE/SP, DPPX, VSE/ESA etc., do not have connection to a TCP/IP network available in OC/390. When the interpretive space of the present invention makes it possible to execute an application and its old operating system as guests in OS/390, the application gains access to TCP/IP networks, as illustrated in FIG. 8.1. Such connection is accomplished via use of agents--OS/390's own tasks comprising three layers. Layer 80 is an application interface, layer 82 is an agent's body, layer 84 can be a TCP/IP interface or an interface to another OS/390 resource. The application interface can be realized either through virtual or real CTC, or through APPC (Advanced Pear-to-Pear Channel), depending on the availability of these resources in the guest operating system, or by using any other task-task access resources supported by both host and guest operating systems. If an old operating system is DPPX, it is connected to TCP/IP resources the following way:

Similarly, an agent (through layer 84) can serve as a connector to other OS/390 system resources, such as CICS, DB2 and others.

In order to give DPPX guest system access to TCP/IP networks, the guest DPPX in APPN mode is connected on TRN via VICATR and one OSA-2 port, and via other TRN OSA-2 (Open System Adapter) port comes back to OS/390 VTAM. Then OS/390 communicates with the terminals connected to TCP/IP via TELNET. For example, HCF (Host Communication Facility) is in OS/390 VTAM (Virtual Telecommunication Access Method), its display is on TELNET, terminal--on TCP/IP, and DHCF (DPPX Host Communication Facility)--in DPPX. Such a switch over to a TCP/IP network is also possible for a guest DPPX group creating a virtual APPN (Advanced Pear-to-Pear Network) on a virtual TRN. In this case all of them will output on OS/390 VTAM (Virtual Telecommunication Access Method) via DPPX, connected to OSA-2. Moreover, any TCP/IP network terminal TN3270 (TELNET) can be activated as a local non-SNA (System Network Architecture) DPPX terminal--product LRTE (Local Remote Terminal Emulation).

During the transition period from an old operating system to a new one, it is often necessary to provide for coexistence of the old and new data bases management systems (DBMS). The guest execution of the old DBMS in OS/390 is shown in FIG. 9.1. The stream of data flowing to the old DBMS is split into two data streams: one data stream directed to the old DBSM, the other one--to the new DBMS. The idea under splitting the data stream into two streams is to synchronize the data bases during the transient period, ensuring that the newly developed OS/390 applications and the old applications work with the same data. Splitting the data stream into two data streams is accomplished by creating two special areas in the old operating system (VSE in FIG. 9.1). One special area is an executive part EPART, the other one is a telecommunication part TPART, as illustrated in FIG. 9.1. The exchange between TPART and EPART is carried out at the agent level in the operating system. The data flow is divided into the new and old DBMS with realization of any function, such as, for example, comparison of acknowledgements received from the old and new DBMS before the transmission of the acknowledgements to the network, i.e. automation of the old and new applications joint debugging.

The same parallel execution is implemented not only for DBMS, but also for other old and new operating system resources, for example, for networks, as shown in FIG. 10.1. At the beginning of the transient period application A runs on the old terminals across the old network. At the end of the transient period application A and application AN, the newly developed application for OS/390, both work with new terminals across the network associated with the new operating system. During the transient period both the old and the new applications run on old terminals across the old network and on new terminals across the new network.

The potential problem of synchronizing operation of the old and new terminal systems may arise due to the fact that the new terminals and protocols might not be supported by the old operating system. Similarly, the old terminals and protocols might not by supported by the new operating system. In the present invention the problem is solved by utilizing OS/390 guest facilities, as indicated in FIG. 10.1. The solution is based on the use of an AGENT--a 4-way switch, supporting simultaneous operation of two guest and two native applications. In that Figure, EPART is an executive part of the old application, TPART is a network part of the old application running on the old terminal net, NEW EPART is an executive part of the new application, NEW TPART is a network part of the new application operating on the new terminal net. The exchange between the allocated parts of the old and the new applications is set up by system resources, which are accessible to the guest system in a manner shown in FIG. 10.1.

Migration from a multi-machine system to a system with fewer machines, which utilizes dynamic networking, is illustrated in FIG. 11.1. N is the number of computers existing in the old network. K, which is smaller than N, is the number of computers existing in the new network. If L applications are running on N computers of the old network with static resource allocation, then it is possible that all L applications will not be executed on all N computers due to inevitable differences and diversity of the operating environment. After migration to K computers of higher performance, configured in a manner shown in FIG. 11.1, each application L can be executed on any machine by means of dynamic resource allocation.

The logical structure of RACF (OS/390 common security for old and new applications) interacting with guest applications A1 and A2 is shown in FIG. 12.1. After the process of migration has been finished, guest applications A1 and A2 together with guest operating systems OS1 and OS2 run in the interpretive space of the present invention as OS/390 tasks and, like any OS/390 task, can be controlled by RACF resources. If a tighter security control over access to a OS/390 network is required, the message flow between guest tasks and OS/390 network resources can be directed to an agent task. This agent task is similar to the agent task described with regard to the connection between TCP/IP networks and old applications in FIG. 8.1. If it is necessary to perform individual checking procedures while at the same time controlling access to system resources not protected by RAFC, an additional OS/390 resource SAF (System Authorization Facility, FIG. 12.1) can be used. SAF and RACF interaction procedure is shown in FIG. 12.1.

It may become necessary to integrate independently developed TCP/IP networks (distributed computing systems) and classical centralized systems, implemented according to SNA (including systems running on operating systems without TCP/IP communication resources and, moreover, systems not supporting distributed computer environment (DCE)). Certain elements of system solutions based on ISX, discussed in the foregoing sections, allow to integrate the centralized (OS/390) and distributed (Unix, Windows NT) systems under common security system (DCE security server) in a manner presented in FIG. 13.1. One solution is based on the OS/390 standard construction of the implementation of such integration, shown in FIG. 13.1. As can be seen in FIG. 13.1, the first step is to upgrade OS/390 applications combined and their operating systems to OS/390 guest mode. After the upgrade, the applications become OS/390 resources secured by RACF. The second step is to upgrade the traffic between the applications to the TCP/IP level. Upgrading old applications can be performed in accordance with the approach discussed above with regards to FIG. 8.1. The third step is to upgrade the traffic between the applications to the DCE level. This upgrade is performed by intercepting the application traffic at the TCP/IP driver level and re-directing the traffic to other addresses in the DCE infrastructure. (Various system products of independent vendors can be used to the step three upgrade). Finally, the fourth step, if necessary, is to improve the confidentiality of the system by creating and implementing the system's own (proper, individual) encryption instead of commercially available encryption. This procedure is implemented according to the OPEN GROUP standard GCS-API, as shown in FIG. 13.1.

The interpretive space of the present invention offers possibilities to test if a particular application is Year 2000 compliant. The testing can be done by creating static or dynamic time windows for guest tasks. There are two functions in ISX for operating guest systems: VDAT, VTIME. VDAT inputs a particular date separately into each guest operating system, such as DPPX, for example (FIG. 14.1). A separate input enables parallel testing of either several systems or only one system. VTIME allows to "fast forward" guest DPPX's virtual time to a required date, accelerate the testing and create an algorithm for a long-term forecast of the system's time related behavior.

The implementation of the interpretive space makes it possible to perform back up operations in an OS/390 computer center after various other operating systems have been integrated into a network (FIG. 16.1). Without changing the computer center's operating system configuration, the interpretive space enables execution of the configuration of all backup centers with all their existing setups as guests of OS/390 in a manner shown in FIG. 16.2. The stand-alone programs can also be executed as OS/390 guests, so there will be no need to stop the OS/390 facilities or to use a specific machine, LPAR, or VM.

Preparing for a back-up comprises the following steps:

1. Backing up a migrated operating system, for instance, with a DDR utility.

2. Loading the interpretive space (ISX) utility on the back-up computer center.

3. Restoring the backup operating system by with DDR at the back-up computer center.

4. Starting the ISX as a OS/390 user TASK and utilizing the ISX to perform IPL of the backup operating system on top of ISX.

After that the backup operating system is ready to run backup applications.

ISX/390 Installation

Machine Requirements.

One can install and run ISX/390 in OS/390 system on any IBM S/390 processor that has interpretive execution facility and is supported by OS/390 operating system.

One magnetic tape device (e.g. 34xx tape unit) is used to install ISX/390.

Auxiliary DASD storage space is desired for the following resources:

SYSPRINT, if routed to DASD,

Library space--8 tracks of library space on a DASD device, such as a 3380 type device for a new library.

System Requirements

ISX/390 requires OS/390.

Virtual Storage Requirements

The minimum ISX/390 storage requirements are the following:

256K to run ISX/390,

4K for every I/O device used by a guest system,

OS/390 system usage requirements,

the size of the main storage should be known by a guest system.

Installing ISX/390 in OS/390

ISX/390 distribution tape is a standard-labeled 9-track magnetic tape written at 6250 bpi with volume serial number ISX390.

To install ISX/390, the following sequence is executed:

    //ISXINST       JOB (account),`name`,TIME=1440,REGION=1M,
    //              CLASS=c,MSGLEVEL=(1,1),MSGCLASS=m,
    //              NOTIFY=userid,USER=userid
    //ISXSTEP       EXEC PGM=IEBCOPY
    //SYSUT1        DD DSNAME=ISX390.LINKLIB,DISP=SHR,
                    LABEL=(1,SL),
    //              UNIT=TAPE,VOL=SER=ISX390
    //SYSUT2        DD DSNAME=ISX.LINKLIB,DISP=(,CATLG),
                    UNIT=3380,
    //              SPACE=(TRK,(8,1,2)),VOL=SER=xxxxxx,
    //              DCB=(RECFM=U,BLKSIZE=32740)
    //SYSPRINT      DD SYSOUT=*

        //ISXRUN      JOB (account),`name`,TIME=1440,
        //            CLASS=c,MSGLEVEL=(1,1),MSGCLASS=m,
        //            NOTIFY=userid,USER=userid
        //ISXSTEP     EXEC PGM=ISXINI
        //SYSLIB      DD DSNAME=ISX.LINKLIB,DISP=SHR
        //STEPLIB     DD DSNAME=ISX.LINKLIB,DISP=SHR
        //SYSPRINT    DD SYSOUT=A
        //SYSIN       DD DUMMY

        //ISXCR  JOB MSGLEVEL=(1,1),MSGCLASS=H,CLASS=A
        //  EXEC PGM=IDCAMS
        //SYSPRINT DD SYSOUT=H
        //SYSIN DD *
            DEFINE CLUSTER -
                (NAME(DISK)   -
                NUMBERED   -
                SUBALLOCATION  -
                RECORDSIZE(512 512) -
                RECORDS(360036) -
                VOLUMES(DSKFBA) -
                SHAREOPTIONS(4) -
                REUSE)
        /*

    //FBA         JOB MSGLEVEL=(1,1),MSGCLASS=H
    //            EXEC PGM=ISXFBI
    //STEPLIB     DD DSN=ISX.LINKLIB,UNIT=SYSDA,DISP=SHR
    //SYSPRINT    DD SYSOUT=H
    //

    ISXNODE     VBUILD    TYPE=APPL
    APPLISXA    APPL      AUTH=ACQ,              permits to acquire
                                                 LUs
                          EAS=3,                 concurrent
                                                 sessions
                          ACBNAME=APPLISXA,      application name
                          SRBEXIT=YES            authorized to use
                                                 SRB

    Hexadecimal code         Related device
    X'00..00000000..........00' For non-SNA (LU 0)
    X'02..00000000..........00' For SNA (LU 2)
    X'..00....................' Device without extended data
                             stream capability
    X'..80....................' Device with extended data
                             stream capability(it is not supported)
    x'............0000000001..' Buffer size 480 (12 .times. 40) only
    X'............0000000002..' Buffer size 1920 (24 .times. 80) only
    X'............0C2800007E..' for 480 or 960 (12 .times. 40 or 12 .times. 80)
    X'............185020507F..' for 1920 or 2560 (24 .times. 80 or 32 .times.
     80)
    X'............18502B507F..' for 1920 or 3440 (24 .times. 80 or 43 .times.
     80)
    X'............18501B847F..' for 1920 or 3564
                             (24 .times. 80 or 27 .times. 132)
    X'............185000007E..' for 1920 (24 .times. 80) only

                             ACCount

        Device state:   I/O REDRIVED / I/O HAS COMPLETED /
                        I/O IN PROGRESS
                        / DEVICE IS BUSY / DEVICE NOT USED
                        / I/O NOT COMPLETED

           ...
                       >> zzzzzzzz      >> uuuuuuuu
           ...

          Subchannel      Device      Class
             ssss          dddd       cccc  Real.vertline.Emulated
             ....          ....       ....       ..........

                       READY gdevaddr[.count]

                       RESET [gdevaddr[.count]]

                           RESTART

            SAVEsys name {fpage1-1page1 [fpage2-1page2]....vertline.
                fpage1.count1 [fpage2.count2]...}

        SET
     [AUTOPoll.vertline.ACCount.vertline.VMmode.vertline.ASSist.vertline.JOBNam
    e.vertline.XMSG.vertline.
        MSG ON.vertline.OFF
         CONSname consolename.vertline.OFF
          STorage nnM
           IDP ppppppppmmmm
            DATE dd/mm/yyyy TIME hh/mm/ss
             ZONE [-.linevert split.+]hh/mm
              RATIO rrrr/vvvv.vertline.OFF.vertline.FORCE
               PASSword xxxxxxxx
                EXPire mm/yyyy
                 List]

                           SHUTDOWN

      R-TIME    T-TIME    G-TIME       SIE       R-SIO      E-SIO      LCP
      xxxxxx    xxxxxx    xxxxxx    xxxxxxxx   Xxxxxxxx   Xxxxxxxx   xxxxxx
                 xxx %     xxx %       xxx        Xxx        Xxx       xxx
      xxxxxx    xxxxxx    xxxxxx    xxxxxxxx   Xxxxxxxx   Xxxxxxxx  xxxxxxxx
                 xxx %     xxx %       xxx        Xxx        Xxx       xxx
        --        --        --         --         --         --        --

                       [STOP] [hexaddr.vertline.OFF]

                    STore {[R.vertline.P.vertline.S.vertline.H]hexaddr hexdata
     .vertline.
                       Greg hexword1 ....vertline.
                        Zreg hexword1 ....vertline.
                         Yreg hexdoubleword1 ....vertline.
                          Xreg hexwordl ....vertline.
                           Psw hexdoubleword.vertline.
                            CPU}

              Take gdevaddr[.count] [AS] newgdevaddr .vertline.
                  gdevaddr[.count] code1 [AS] code2 .vertline.
                   gdevaddr[.count] [AS] LUname 11111111

              ENTER              enter function key
              PF1                program function 1 key
              PF2                program function 2 key
              PF3                program function 3 key
              PF4                program function 4 key
              PF5                program function 5 key
              PF6                program function 6 key
              PF7                program function 7 key
              PF8                program function 8 key
              PF9                program function 9 key
              PF10               program function 10 key
              PF11               program function 11 key
              PF12               program function 12 key
              PA1                program attention 1 key
              PA2                program attention 2 key
              PA3                program attention 3 key

              ENTER             enter function key
              PF1               program function 1 key
              PF2               program function 2 key
              PF3               program function 3 key
              PF4               program function 4 key
              PF5               program function 5 key
              PF6               program function 6 key
              PF7               program function 7 key
              PF8               program function 8 key
              PF9               program function 9 key
              PF10              program function 10 key
              PF11              program function 11 key
              PF12              program function 12 key
              PA1               program attention 1 key
              PA2               program attention 2 key
              PA3               program attention 3 key
              TESTREQ           test request function key
              SYSREQ            system request function key
              SWITCH            terminal switch key

              TRace [event codes] [filter]
                  [Display] [Print Class x] [Halt] [Skip nnnnn]
                   [ON.vertline.OFF]

                         Ugdevaddr[.count]