Browse Prior Art Database

Scheduling the Execution of Arbitrary Programs to Other Tasks

IP.com Disclosure Number: IPCOM000104811D
Original Publication Date: 1993-Jun-01
Included in the Prior Art Database: 2005-Mar-19
Document File: 4 page(s) / 101K

Publishing Venue

IBM

Related People

Campbell, JD: AUTHOR [+4]

Abstract

Disclosed is a method to have an application task schedule any of the application programs it owns, to be executed under the auspices of another process (task). This solves certain problems related to persistence and access of resources:

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Scheduling the Execution of Arbitrary Programs to Other Tasks

      Disclosed is a method to have an application task schedule any
of the application programs it owns, to be executed under the
auspices of another process (task).  This solves certain problems
related to persistence and access of resources:

o   Resources acquired because they are needed by an application task
    may need to persist beyond the lifetime of the task that realized
    the need to acquire the resources.  Typically, this is due to the
    discovery by a peer task at a later point in time that the same
    resource is required and the continued need for the resource by
    the second task after the first has completed.  The use of a
    persistent "server" task as a resource manager solves this
    problem.

o   Direct access to peer application tasks may not always be
    possible to negotiate changes in allocation or use of shared
    resources.  The use of a "server" task as an accessible
    intermediary solves this problem.

      In particular, in MVS/ESA* without this solution, there is no
mechanism for an ISPF dialog program that may be active concurrently
on behalf of two or more logical screens to share the management of
resources such as VSAM local shared resource (LSR) pools, data
control blocks (DCBs), and access method control blocks (ACBs).
There is also no mechanism for unauthorized TSO/E commands that may
be invoked repeatedly to keep such resources between uses of that
command.

      The figure illustrates the tasking structures used in a TSO/E
session.

      The disclosed mechanism is comprised of programs which allow a
task in the unauthorized control layer to:

1.  Make itself ready to receive requests for execution of arbitrary
    (nt predetermined) programs from unauthorized TSO commands and
    subtasks (A "server" task).

2.  Send requests to other tasks to execute arbitrary (not
    predetermined) programs (A "client" task).
    The requests exchanged between the client and the server tasks
    contain program identification (e.g. a pointer to the executable
    code), and areas to exchange execution parameters and results.

3.  A control mechanism which allows the "server" task to be invoked
    for purposes of "forced cleanup," when the system determines that
    candidate client tasks are terminated by the system.

      A similar mechanism allows a task in the authorized control
layer to satisfy requests originating from authoriz...