Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

System Administration Structure

IP.com Disclosure Number: IPCOM000118306D
Original Publication Date: 1996-Dec-01
Included in the Prior Art Database: 2005-Apr-01
Document File: 4 page(s) / 97K

Publishing Venue

IBM

Related People

Follis, DA: AUTHOR

Abstract

Disclosed is a method for an unskilled computer user in a UNIX* rlogin environment to perform MVS/ESA** OpenEdition** system administration tasks (e.g., backup a file, add a user).

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

System Administration Structure

      Disclosed is a method for an unskilled computer user in a
UNIX* rlogin environment to perform MVS/ESA** OpenEdition** system
administration tasks (e.g., backup a file, add a user).

      A method is provided for users in the rlogin environment to
perform certain system administration functions and an Application
Programming Interface (API) to these functions so that they can be
accessed from vendor or user written applications.

      This is illustrated with a system administration function
called EZPING.  To implement this function, a load module called
EZPING is provided which may be invoked as a command to perform the
'ping' function.  As the 'ping' function must also be available as an
API, the module will consist of two parts:  the command processor and
the API module (Fig. 1).  It is not possible to actually perform the
desired system administration function in the API module since the
rlogin address space only has the Time Sharing Option (TSO)
Environment Services set up and the commands we must issue require
more services than are available in that environment.  Therefore, the
API module must pass the request to another address space.  In
general, implementing the various system administration functions
will require a job to run.  Some jobs may result in messages being
issued that require action (tape mount requests).  These messages
will need to be handed back to the user when they occur, without
terminating the command processing.  Additionally, all commands must
be able to recognize a failure in processing the command.  Therefore,
a monitoring address space is required.  This address space is
contacted by the API module and handles starting the appropriate job,
watches for messages indicating the success or failure of the job,
and returns appropriate results to the API module.  Thus, a new part
in our structure called the System Administration Server is defined
and is illustrated in Fig. 1.

      Looking closer at the System Administration Server, we see that
it must really provide two services:  for each request from an API
module it must start an appropriate batch job running and as messages
are received as a result of the actions of the running job, it must
pass this information (tape mount, job failed, job succeeded) back to
the API module which requested the function....