Browse Prior Art Database

Invocation and return of 1st-level adjunct program from a live 2nd-level system Disclosure Number: IPCOM000021203D
Original Publication Date: 2004-Jan-02
Included in the Prior Art Database: 2004-Jan-02
Document File: 2 page(s) / 14K

Publishing Venue



From a running 2nd-level system on VM, a program can be invoked on the adjunct configuration of the 1st-level user, and program output returned to the invoker on the 2nd-level system. It can be transparent to the 2nd-level user that the program actually ran in the adjunct.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 55% of the total text.

Page 1 of 2

Invocation and return of 1st-level adjunct program from a live 2nd-level system

Disclosed is a method to invoke, from a live 2nd-level system, a
program in the 1st-level adjunct. Using this method, the
2nd-level system continues to run unimpeded, except for the time
while the adjunct is actually running. The adjunct program can
be invoked from a program running in a virtual machine of the
2nd-level system, and return codes and other output can be
returned from the adjunct program to the program on the 2nd-level
system virtual machine.
The VM operating system presents each user with its own virtual
machine. A virtual machine can have an adjunct machine, which in
many respects behaves as a separate virtual machine. The first
virtual machine is known as the primary. The primary and the
adjunct share certain resources, and in particular they share
time: exactly one of the two is running at a given time. A user
selects whether the adjunct or the primary is to run using the CP
(Control Program) commands ADJUNCT START (to initialize the
adjunct), ADJUNCT STOP (to return to the primary), ADJUNCT BEGIN
(to switch from primary to adjunct) and ADJUNCT END (to terminate
the adjunct). When the adjunct is running, the primary is
frozen, and vice versa.

VM also facilitates use of guest operating systems. A VM user
can run an operating system in the primary (or the adjunct, or
both). That operating system is known as a 2nd-level system to
distinguish it and its users from the lower level operating
system, the 1st-level system on which the original user is
running. An important use of the adjunct is with this
environment, where the adjunct is able to retain the
characteristics of a 1st-level user while the 2nd-level system
exists in the primary. A person can run programs and execute
1st-level commands in the adjunct without having to take down the
2nd-level system. In particular, the adjunct may be used to
examine the 2nd-level system while it is frozen (display memory
data, for example).

A problem with this arrangement is that the movement between the
primary and the adjunct is manual. The usual practice is to use
a programmed key (PA1) to cause the primary to drop into
1st-level CP READ, then issue ADJUNCT BEGIN to get to the
adjunct. Since ADJUNCT BEGIN is a CP command, there is no
facility for invoking a program on the adjunct as part of that
command. Rather, one must invoke the desired program or other
action with a subsequent command.

The PA1 step to drop into 1st-level CP READ can be circumvented
by using diagnose x'08' on VM. This can be arranged on 2nd-level
VM operating systems by adding a CP exit to invoke the diagnose
x'08'. See author Tim Greer's