Control of mutually exclusive user memory and execution formats giving illusion of simultaneous execution
(The official version of this article was made available in July, 2007.)
Timothy D. Greer
Disclosed is a method for allowing moderately time-critical applications to function in a situation where the human user perceives the application and underlying code, such as an operating system, to be frozen. Consideration is also given to the problem of a pair of such applications. Features of IBM's VM operating system provide the illustrative mechanisms. Guests running environments exclusively relying on a single memory space and execution environment do not encounter the problem, but guests may instead be using the dual environment known as the ADJUNCT.
VM includes the ADJUNCT facility, with which a guest can switch between a PRIMARY memory and execution environment and an ADJUNCT memory and execution environment. These environments are mutually exclusive on a temporal basis; that is, while one runs, the other is frozen. The typical use is to run a 2nd-level system (an operating system, e.g. Linux or VM) in the PRIMARY and CMS (a human-friendly environment commonly used for accessing and running applications) in the ADJUNCT, giving a person access to 1st-level CMS facilities without taking down the 2nd-level system.
A question that almost always comes up when explaining this environment to a new user is, "Are they running simultaneously?" The answer is no -- one is frozen while the other runs. (However, one can from the ADJUNCT issue CP commands on the PRIMARY, e.g. DISPLAY STORAGE.) This freezing has advantages, but sometimes there are disadvantages as well. For example, if a 2nd-level system running in the PRIMARY has active communication links to other systems, the other systems may conclude that the links have dropped if the PRIMARY stays frozen too long.
Typical use of the ADJUNCT involves little actual execution time, but possibly considerable human time looking at the screen. So a solution to the disadvantages is to leave the ADJUNCT's screen on display for the human, while switching to the PRIMARY whenever the ADJUNCT is not actually executing some program or other function.
Leaving the ADJUNCT's screen on display can be accomplished by running the ADJUNCT/PRIMARY guest through a logical device controlled by a second guest, using VM's Logical Device Support Facility (diagnose x'7C'). A program in the second guest displays whatever is on the ADJUNCT screen, and passes through any user commands to the ADJUNCT, wrapped within ADJUNCT BEGIN and ADJUNCT STOP commands so that the PRIMARY is running otherwise. The display on the second guest can utilize a window of the CMS FULLSCREEN facility to help the human keep track of where various commands are going. Special keys or commands can be used if the user wants to display and interact with the PRIMARY, or wants to temporarily shift to the mode of operation where the PRIMARY is frozen whenever the ADJUNCT screen is displayed.
While typical use of the Adjunct facility is to run CMS in the ADJUNCT and a 2nd-level system in the PRIMARY, the facility gets other uses, in testing particularly. Test ideas may generate rather eclectic examples ranging from simple CMS in both PRIMARY and ADJUNCT, to a Linux system in one and z/OS in the other. In such a situation, where a 2nd-level system is active in both the PRIMARY and the ADJUNCT, it may be important not to leave either side frozen for too long. To accomplish such a thing requires either a continuously running program in the second guest -- the guest controlling the logical device -- or a program on the second guest that posts timer interrupts for itself. Through such an arrangement the program can ensure that alternate ADJUNCT BEGIN and ADJUNCT STOP commands are entered at maximum intervals, while leaving the display presented to the human user static.
The information provided, and views expressed on this site are my own and do not represent the IBM Corporation.