Google
 

Trailing-Edge - PDP-10 Archives - QT020_T20_4.1_6.1_SWSKIT_851021 - swskit-documentation/galaxy-v5.memos
There is 1 other file named galaxy-v5.memos in the archive. Click here to see a list.
MEMOS CONTINED IN THIS FILE:


   o	Changes for GALAXY version 5
   o	MOUNTR changes for GALAXY v5
   o	GALAXY v5 System Operations
   o	QUEUE% JSYS Support


----------------------------



1.0  PURPOSE

This describes the changes for GALAXY version 5  which  will
be  released  at  the  same  time as TOPS-20 version 6.  The
major  directions  of  change  will  be  bugfixes  with  the
previous  release,  some  new  functions,  and  functions to
specifically support the changes with TOPS-20 version 6.



2.0  AREAS OF CHANGE

2.1  Internal Changes

2.1.1  Security - With TOPS-20 V6, there has been  a  change
to  encrypt passwords.  This caused the password checking in
SPRINT to fail.  As a result, SPRINT has changed to validate
passwords with the new access function.



2.1.2  Versions/Edits - There are a number of changes to try
to  get  a  better grip on the versions of GALAXY components
and the versions of the files used to produce  a  particular
component.

All of the GALAXY components have had  their  major  version
number  changed  to  5  to indicate they are all part of the
same release.  In most cases, the number increased, but in a
few  of  the  older  components, the version number actually
decreases from 104 to 5.  (SPROUT, LPTSPL,  and  PLEASE  are
examples)

All  components  now  have   two   explicit   edit   numbers
internally.  One number will be the maintenance edit number;
the other, the development edit number.  The larger  of  the
two numbers is the edit number that will be seen with I VER.
When GALAXY is released, the maintenance number will be  set
to  the  development  number.   All  maintenance  edits will
increase  the  maintenance  edit   number,   even   in   the
development  sources.   A  particular  fix  will  not have a
seperate edit number depending on which release in which  it
is inserted.

There is now a vector in the EXE  file  for  each  component
that  identifies  the edit versions and names of the modules
used to produce  the  component.   This  includes  both  the
maintenance  and  the  development  version  numbers.   As a
result, there is a quick means to determine the exact source
modules used to produce a component.
                                                      Page 2


2.2  Terminal Types In OPR

In the past there has been a SET TERMINAL TYPE  xxx  command
in  OPR.  Since a similar command already exists in the EXEC
and since the terminal types supported in this  command  are
not  up to date, this command will be set invisible and will
be removed with the next (post version 5 of GALAXY)  release
of OPR.



2.3  QUEUE% JSYS

The purpose of the QUEUE%  JSYS  is  to  provide  a  unified
method  for  user code to communicate with GALAXY processes.
For example, print and batch requests can be generated  with
user  code through the use of this JSYS.  This is documented
in greater detail in QUEUE.MEM.



2.4  Problem Information To Operator

One of the first uses of the QUEUE% JSYS is by  the  monitor
for  the  purpose of sending system messages previously sent
only to the console, to ORION  where  the  messages  can  be
distributed  to  all  of  the  running  OPR  processes.  The
currently defined classes of messages are:

      o  BUGCHK

      o  BUGINF

      o  SYSTEM-MESSAGES -- which are the device error  type
         of messages.

In addition, the output display of  these  messages  can  be
enabled/disabled by class in OPR.



2.5  New Devices

With the CI/HSC/RA81 combination, the disk displays  contain
information  about  these  new  device types.  It is assumed
however, that these devices will behave in the same  way  as
traditional  devices, at least as far a GALAXY is concerned.
The exception to this is in a special case of the CI.

The CI needs to be able to be "separated" from  the  general
system  for  diagnostic  purposes.   That  action  itself is
simple  (a  DIAG  JSYS  function)  but   additionally,   all
structures  being  referenced through the use of the CI need
to be set unavailable to the system and the state of the  CI
needs  to  be remembered to maintain the state across system
                                                      Page 3


failures.

A new  OPR  command  will  be  provided:   OPR>SET  PORT  CI
AVAILABLE/UNAVAILABLE.   Execution  of the command will have
the following observable steps:

     1.  All OPRs are notified of all disk  structures  that
         will  be  affected  unavailable  as a result of the
         action.

     2.  A  response  of  one  of  the  following  forms  is
         required:

          o  ABORT -- "I changed my mind." The change due to
             the  command  is  too great.  Abort setting the
             port offline.  If the  command  is  aborted  at
             this point, system operation remains unchanged.

          o  FORCE -- Do as the  command  implies.   Do  not
             have  any further dialogue.  This option should
             only be exercised with caution.

          o  PROCEED -- Proceed with the command but  notify
             OPRs   of   changes.    As  each  structure  is
             dismounted, the structure is handled as  if  an
             OPR  dismount command were given.  If there are
             users of the structure, a confirmation  of  the
             structure dismount is required from OPR.


     3.  The  command  will  proceed  with  the  OPR   being
         notified  of  structure  dismounts  as appropriate.
         Note well:  a refusal of any particular dismount by
         the  OPR  will  abort  the rest of the PORT OFFLINE
         command.  All structures  already  dismounted  will
         remain dismounted.

     4.  After all structures are finished, the PORT will be
         set offline and the OPRs notified.

Note that this operation will  be  performed  asynchronously
with  other  operations.   The dialog will be completed when
disks  involved  are  all  set  correctly.   Dismounting   a
structure  separate  from this procedure will avoid the step
as part of the procedure.



2.6  Static Structure Attributes

With GALAXY Version  5,  certain  structure  attributes  are
maintained  across system failures.  The past attribute that
will   be   maintained   across   failures   is    structure
UNAVAILABLE/AVAILABLE.    In  addition,  the  new  structure
attribute, EXCLUSIVE/SHARED will also be  maintained  across
                                                      Page 4


system failures.



2.7  Common File System

With the common  file  system,  there  are  some  additional
functions that need to be performed by GALAXY.



2.7.1  Exclusive/shared - A structure can be set to be  used
only  by  one system in a CFS configuration.  This attribute
is exclusive.  Attempting to set a structure  exclusive  can
fail  if  the structure is already in use by another system.
But once the structure is set  exclusive  by  a  system,  no
other  system  in  the  CFS  configuration  can  access  the
structure.



2.7.2  Port Unavailable - Since dual ported  drives  can  be
shared  with  another  system,  and  since  setting the port
unavailable halts communication between the systems in  CFS,
all  structures  that  are  on  a dual ported drive in a CFS
configuration need to be dismounted in order to set the port
unavailable.   The  only  other option is to set the port on
the drive to this system only  which  prevents  the  use  by
other systems in the CFS configuration.



2.7.3  Structure Dismount Procedures - Since the GALAXYs  on
the   various   systems  in  a  CFS  configuration  are  not
communicating, dismounting a structure to remove it  from  a
CFS configuration has some additional steps necessary.  This
is to prevent the structure  from  being  yanked  away  from
users on other systems in a CFS configuration.  As a result,
to  dismount  the  structure  with  removal   requires   the
structure  being exclusive to the system making the request.
This may require the operator dismounting the  structure  on
all  other  systems  in  the  CFS  configuration  before the
dismount is allowed to complete.



2.7.4  "Free" Disk Drives - Due to CFS,  the  concept  of  a
free  disk  drive  (in  the  OPR>SHOW  STATUS  DISK display)
changes.  Free has indicated that the disk can be removed at
any time with no futher action by the operator.  In CFS, the
only time that can be true on a particular  system  is  when
the  disk  has  been  set  exclusive  and  then  dismounted.
Otherwise there is a risk  of  the  disk  being  in  use  on
another system in the CFS configuration.
                                                      Page 5


3.0  ENVIRONMENT DESCRIPTION

Due to some of the complexity in the operational  procedures
and  changes  in  the  CI/CFS  environment,  there  has been
another document generated describing the environment.  This
description   is   contained   in  R60SPC:OPERATIONS.MEM  on
GIDNEY/CLOYD.



4.0  FUNCTIONAL DESCRIPTION

4.1  Overview

The purpose of this is to describe the  operation  functions
on  a  function  by  function  basis.   By  doing  this, the
particular problems and shortcomings of each  operation  can
be understood as well as the basic design requirements being
called out.



4.2  Structure Available/Unavailable

In the previous release a structure could be set on a system
basis,  either  unavailable  or  available  (default).  This
attribute  held  only  until  either  MOUNTR  was  restarted
(directly  or  through  a  crash) or until the structure was
physically removed from the system.

Note that there can be two perceptions of  unavailable.   At
the   base   level  there  is  the  monitor  enforcement  of
unavailable.  This is accomplished through  MSTR  indicating
that the structure is "being dismounted".  This is effective
only when the structure itself is mounted.  The second  view
is  that  of  MOUNTR.  It attempts to enforce unavailable by
not mounting the structure which prevents such action as the
EXEC  incrementing  the mount count.  However, a priv'd user
can mount the structure behind MOUNTR's back leaving  MOUNTR
powerless to control the state of the structure any further.

With release 5  of  GALAXY,  unavailable  retains  the  same
meaning  but has a longer duration.  When a structure is set
unavailable,  it  will  retain  that  attribute  until  that
attribute  is  explicitly  cleared,  i.e.   structure is set
available again.   This  has  been  accomplished  by  adding
structures  to  the  "permanent"  disk data base (a file) if
they   have   attributes   different   than   the    default
characteristics.   The benefit of this action is to ease the
use of such structures in the CFS configuration where it may
be  a  permanent  decision  to  never  allow  the  use  of a
particular structure on a particular system.
                                                      Page 6


4.3  DISMOUNT Of Structures

Dismounting in previous releases allowed two possibilities:

      o  A user dismount command to the EXEC.

      o  A user gave a dismount with remove or  an  operator
         gave the OPR command to dismount.

In the first case, the user's  EXEC  decremented  the  mount
count.   In  the second case, the request was sent to MOUNTR
where processing continued along various paths depending  on
other uses of the structure.

With release 5 of GALAXY there is additional processing  due
to the support of release 6 and CFS and an additional option
to the OPR dismount command to allow  dismounting  from  the
system  without  physically  removing the structure from the
disk  drive.   This  allows  another   system   in   a   CFS
configuration   to   continue   using  the  structure.   The
following  describes  the  steps  necessary  to  perform   a
structure dismount:

     1.  Remember the current state of the structure and set
         the structure "being dismounted".

     2.  Determine if there is any use of the structure.  If
         there are no users, go to step 5.

     3.  The structure is in use.   Query  the  operator  to
         determine if to proceed or to abort the dismount.

     4.  If the operator indicates abort, set the  structure
         back  to  the  state  previous  to  step 1.  Give a
         notification to the requestor, clean up and quit.

     5.  If no removal required, or not CFS, go to step 10.

     6.  Try to set the structure exclusive.  If success, go
         to step 10.

     7.  Can't set structure exclusive.  Query the  operator
         to  have  the  structure dismounted without removal
         from other systems in CFS configuration or to  have
         the dismount process aborted.

     8.  If  the  operator  indicates  abort,  perform  same
         action as in step 4.

     9.  Operator  believes  structure  can   now   be   set
         exclusive, go back to step 6 and try it.

    10.  Dismount structure.
                                                      Page 7


    11.  If no removal needed notify the original  requester
         and done.

    12.  Ask the operator to remove the structure.

    13.  When the structure is removed, notify the  original
         requestor and done.

Some observations about this procedure are worth mentioning:
The  purpose  of  step  one is to prevent further users from
incrementing the mount count and using the structure.  There
is  a  flaw to the EXEC's portion of this procedure however.
When the EXEC fails to increment the mount count, it  simply
aborts  the  request.   As  a  result,  the  operator is not
notified that there may be additional users  requesting  use
of the structure, and the user cannot submit mount requests.
It probably would make more sense for the EXEC to  go  ahead
and submit the mount request to GALAXY where it can be added
as  a  pending  queue  request   but   this   is   currently
uncommitted.   The  operator could then use this information
to help decide whether to proceed with the  dismount  or  to
cancel the user's mount request if appropriate.

Once the structure is logically dismounted, it  is  unusable
as  a  normal structure until it is physically dismounted or
until the structure  is  explicitly  set  available  by  the
operator.  There are at least 2 difficulties in this.  There
is currently no  display  to  tell  the  operator  that  the
structure  is  in  this  state  but that information will be
added to a new display.  And setting the structure available
to  clear  this  state  is not obvious.  Also, while in this
state, the structure can be touched and logically mounted by
a priv'd user behind MOUNTR's back.



4.4  Structure EXCLUSIVE/SHARED

With release  6  of  TOPS-20  there  is  a  "new"  structure
attribute  for  indicating whether a particular structure is
available for use throughout a CFS configuration or only  on
a  particular  system.   Since  exclusive  is  used to limit
access of a structure to one system,  it  is  reasonable  to
assume  that  a  structure  will  always  be  exclusive to a
particular system.  As a result, the exclusive attribute  of
a  structure  will  be  kept  as a permanent attribute, i.e.
MOUNTR will try to keep  a  structure  exclusive  until  set
shared,  even  across system crashes.  Exclusive/shared is a
normal structure attribute that can  be  set  in  OPR.   For
release  6 systems that do not include CFS, there will be no
observed effect from this command.

There are three  ways  in  which  a  structure  can  be  set
exclusive/shared.   It is only the setting of a structure to
exclusive that is interesting.  This is  because  setting  a
                                                      Page 8


structure  shared should always succeed unless the structure
is not visible in which case, who cares.  The  first  way  a
structure  can  be set exclusive is with an OPR command.  In
this case MOUNTR performs the following steps:

     1.  MOUNTR tries to set the structure exclusive.

     2.  If success, send acknowledgement and done.

     3.  If failure, send a message to the  operator  asking
         for  the  structure to be dismounted from all other
         systems in the CFS configuration.

     4.  If the operator responds with abort, then quit.

     5.  If the operator responds with proceed, go  back  to
         step one.

The other way a structure can be set  exclusive  is  through
the  "past"  in  which  the structure was exclusive the last
time MOUNTR was run.  This  case  is  more  difficult  since
there  is  no  guarantee  that setting a structure exclusive
will always succeed but yet there is no  operator  that  has
actively  made  the  request  to  query  about  any problems
encountered.


                            NOTE

               We are still  restricting  the
               discussion  to  the  exclusive
               case.  Shared is  the  default
               and   always   succeeds  in  a
               sense.   If  a  structure   is
               exclusive  to  another system,
               this MOUNTR will  not  see  it
               and  will  not  fail to set it
               shared since it will not  even
               try.


Given this, there three alternatives:

     1.  Set the structure shared with a big warning to  OPR
         that a previously set state has changed.

     2.  Send a warning of the failure and continue  to  try
         to set the structure exclusive.

     3.  Ask the operator to  dismount  the  structure  from
         other  systems  and  tell MOUNTR when to proceed to
         retry the setting exclusive.

Of the three alternatives, the last  one  has  been  chosen.
The only reason the problem exists is because there has been
                                                      Page 9


a failure in administrative procedures.  It is assumed to be
an  administrative  procedure to set a structure unavailable
on one system to set  the  structure  exclusive  on  another
effectively.   If  that  has  not happened, it does not make
sense to proceed to try to set it exclusive without  someone
being  asked  to  correct the procedural failure.  The first
alternative is not reasonable since the exclusive  attribute
can  be  due  to  a security constraint and to simply send a
message and forget about it is probably inappropriate.



4.5  Setting Port CI Unavailable

With this release, it is  possible  to  set  the  entire  CI
unavailable for further use by the system.


                            NOTE

               It  can't  be  emphasized  too
               much  that  this  is not to be
               considered      a       normal
               operational  action.  The only
               foreseeable reasons  for  this
               action  involve  some  type of
               maintenance  action.    Either
               there  is a serious failure on
               the   CI   and   it   is   set
               unavailable   to   allow  some
               diagnostic procedure, or it is
               part  of  a  CFS configuration
               and  the  systems  are   being
               split   to  allow  maintenance
               work on one  of  the  systems.
               In  this case, it is desirable
               to isolate one system from the
               other   and   setting  the  CI
               unavailable  is  used   as   a
               reconfiguration procedure.


This procedure attempts to accomplish three actions.   First
it  attempts to halt further use of the CI in an orderly way
by  dismounting  and  setting  unavailable  all  disks   and
structures  that  are  being  accessed  due to the CI.  This
includes structures that are either  directly  connected  to
the CI or structures that are connected to another system in
a  CFS  configuration  and  are  accessed  through  the  CI.
Second,  if  CFS  is available, it attempts to "resolve" all
disk drives that are  potentially  dual  ported  to  another
system  since  access  to these structures will be lost when
the CI becomes unavailable.  Finally,  this  procedure  will
set  the  CI  unavailable.   In  more  detail, the procedure
performs the following steps:
                                                     Page 10


     1.  Determine if CI  exists  and  if  not,  reject  the
         request.

     2.  Determine  and  generate   a   message   describing
         components affected.

         1.  Determine   all   structures   either   mounted
             directly or indirectly on the CI.

         2.  If  CFS,   find   all   structures   that   are
             potentially dual ported.


     3.  Send a message to the operator describing disks and
         structures  to  be  affected.   The  operator has a
         choice of one of three alternative, either to force
         the thing, proceed normally, or to forget it.

     4.  Wait for an operator response.

     5.  If the response is to  abort,  clean  up  and  exit
         procedure.

     6.  If the response is  to  force,  remember  that  and
         continue.

     7.  If the response is to proceed, then continue.

     8.  Loop through all the  disks  searching  for  remote
         accessed disk drives.  If no more, go to next step,
         otherwise perform the following procedure:

         1.  Set disk unavailable due to port operation.

         2.  If CFS and the disk drive is  dual  ported  and
             this   is  not  a  forced  procedure,  ask  the
             operator to set it single ported to this system
             or   to  dismount  the  structure  (if  one  is
             present) and set it single ported to the  other
             system.   The  operator can respond with either
             abort, which terminates the  entire  procedure,
             proceed,  which  retrys  this step (but now the
             disk should be single ported) or to ignore.  If
             proceed,  and  the disk is now single ported to
             either system,  we  are  done  with  this  disk
             drive.   If ignore is specified, go to the next
             step.

         3.  If there is a structure  mounted,  perform  the
             normal  structure  dismount  operation with one
             exception.  If this is a forced  procedure,  do
             not ask the operator for permission to dismount
             the structure.
                                                     Page 11


         4.  If  the  dismount  failed,  abort  any  further
             action  with  this  procedure.   Note  that any
             previously dismounted disks  remain  dismounted
             and  unavailable until explicitly set available
             again.


     9.  Once all disk drives have been processed,  set  the
         port  unavailable  (with the DIAG JSYS), and notify
         the operator of completion of the action.

    10.  DONE

There are some observations about the  above  procedure  and
actions.

      o  Note  the  statement   about   setting   the   disk
         unavailable due to port operation.  This is not the
         same as setting a disk unavailable which  sets  the
         disk  drive  unavailable  forever  until  set other
         wise.  This unavailable due  to  a  port  operation
         stays  only  until the port is set available again.
         As part of that procedure, the disk will be set  to
         its previous state.  As an example, consider a disk
         set unavailable.  Then that disk is set unavailable
         due  to  a  port operation.  When the port is again
         set available, the  disk  will  no  longer  be  set
         unavailable  due  to  the  port  operation but will
         still be unavailable.

      o  The setting of a port unavailable  is  a  permanent
         operation.  That is, that state is preserved across
         system crashes.




4.6  Setting Port CI Available

This is a  fairly  simple  operation.   First  the  DIAG  is
performed  to  indicate  the  CI is now available for system
use.  Next, all  disks  are  scanned  for  drives  that  are
unavailable  due  to  port unavailable and that attribute is
cleared returning the drive to its state previous to setting
the  CI  unavailable.   The  operator  is  notified  of  the
completion of the action.



4.7  Disk And Structure Displays

Given all of the changes to the state  of  disk  drives  and
structures,  the  current SHOW STATUS DISK in OPR is clearly
inadequate.  As a result, the display will  be  broken  into
two  separate  commands.   SHOW  STATUS  DISK  will show the
                                                     Page 12


status of known disk drives much as it does  now.   However,
only  structure  names  will  be  included.   All attributes
described will be  only  disk  attributes.   The  additional
structure  information  will  be included in the SHOW STATUS
STRUCTURE display.  This will contain  information  for  all
structures known and will contain structure attributes.  The
disk information provided will only include disk type (RP06,
etc.).   Finally, there will be a SHOW STATUS DISK/OLD which
will make an  effort  to  provide  all  of  the  information
included in the old SHOW STATUS DISK command.



4.8  Setting Disk Drive Exclusive

It is as yet uncommitted but it would be desirable to have a
command  to  set  a  disk  drive  exclusive  to a particular
system.  This would allow a  system  administrator  to  have
control  of  his  own resources when in a CFS configuration.
(Indeed, the same action could be  accomplished  by  setting
the  same disk unavailable on the other system, but that has
the generic disk  unavailable  problem  which  is  described
below,  as  well  as  not  giving  the administrator on this
system the control over this system's own resources.)

A subset of this is a request that has been made to  disable
the  use  of  a  particular  disk  by the MSCP server.  That
request is not agreeable since it is really a  configuration
parameter  and  does  not make sense as an operation command
since its results may be unexpected.  For example, if a disk
drive is dual ported, performing this function would have no
effect since the other system could still access the disk by
using  the  other  port.   However,  implementing a set disk
drive  exclusive  command  would  solve   the   problem   of
controlling the MSCP server in a form that makes operational
sense.



5.0  ISSUES AND RESTRICTIONS


      o  GALAXY does not communicate across  CFS.   GALAXY's
         inability to communicate across the CI results in a
         number of awkward procedures and  race  conditions.
         But   due   to   limited   resources,  and  limited
         communication facilities (no DECNET on the CI) this
         communication  will  not  occur  in  version  5  of
         GALAXY.

      o  Dismounting a  structure  in  a  CFS  configuration
         seems awkward.  This is a direct result of previous
         item.  It is necessarily awkward  to  prevent  race
         type conditions.
                                                     Page 13


      o  MSCP server control.  It has  been  suggested  that
         there  be  an  OPR  command  to indicate on a drive
         basis whether the drive is to receive MSCP service.
         This will not be implemented.

      o  Dismounting a structure set to exclusive loses  its
         exclusivity  (exclusive  to the operating system is
         an attribute of being mounted).  As a result, there
         is   a   window  between  logical  dismounting  and
         physical  dismounting  of  the  disk  during  which
         another  system  in the CFS configuration can mount
         the disk.  This problem  could  be  solved  by  the
         uncommitted ability to set the disk drive exclusive
         for use by this system.  MOUNTR could set the  disk
         drive(s)  containing the structure exclusive to the
         system until the structure is dismounted.   Failing
         to  have  that function, the only other solution is
         operational  which  is  to   assume   that   proper
         operation    requires    setting    the   structure
         unavailable  on  the  other  systems  in  the   CFS
         configuration.

      o  Setting a disk drive unavailable is  only  enforced
         in  MOUNTR.   This  has  always been true but has a
         greater impact with CFS.
MOUNTR-BACKGROUND.MEM


1.0  INTRODUCTION

This is a first shot at documenting the background changes  to  MOUNTR
for  GALAXY  release  5.   The  intent  is not to document the changes
specific to the support of TOPS-20 version 6 since that remains pretty
much  the  same as previously documented.  (The only exception to this
is the handling of the SET EXCLUSIVE.)



2.0  AGGRESSIVNESS IN MOUNTR

2.1  Motivation

In the past, MOUNTR has been pretty  much  a  passive  system  service
program.   It always believed whatever it was told by the monitor.  As
a result, some of the commands an operator  may  give  would  fail  to
perform   the   actual  action.   For  example,  setting  a  structure
unavailable only lasted until either the structure was  dismounted  or
until  the  structure  was  set available or until an external process
changed the state.  (external process may be STRTST or may have been a
monitor  failure).   When MOUNTR was told, the structure was available
as indicated by the monitor, it simply believed.

For the next release of GALAXY, there needed to be  a  mechanism  that
prevented  further  use of a disk drive that was to be set unavailable
due  to  a  port  operation.   With  the  old  MOUNTR,  the  following
difficulties occur:

     1.  The disk drive would be set unavailable but structure use  on
         the drive was not correctly curtailed.

     2.  If the structure was correctly set unavailable, the mechanism
         could be easily bypassed.

     3.  There was no way to determine disk unavailable as opposed  to
         structure unavailable.

     4.  Unavailable could mean the structure is  in  the  process  of
         being  dismounted,  the  structure  is on an unavailable disk
         drive, or the structure is really unavailable.

     5.  If the structure is dismounted, all trace of the  unavailable
         state   was   lost,  allowing  remounting  of  the  structure
         immediately on the drive.




2.2  New Behavior

To correct these problems, the first and primary step was to establish
a  MOUNTR data base of the available states and to enforce the states.
The monitor provides one attribute that effects structure use, this is
"structure  is  being  dismounted",  which has been referred to in the
                                                                Page 2


past as the structure unavailable attribute.  Now there are  a  number
of states that map into that single attribute.  Consider the following
states:

     1.  Structure has been set unavailable by OPR command.

     2.  Structure is no longer available until dismount is complete.

     3.  Structure is no longer available due to having a  disk  on  a
         disk drive that has been set unavailable.

     4.  Structure is no longer available due  to  errors  encountered
         with the structure.

     5.  Structure is no longer available due to having a  disk  on  a
         disk drive that is unavailable due to a port operation.

Any  of  those  states  requires  the  "structure  being   dismounted"
attribute  to  be  set.  In addition, since that attribute only exists
for mounted structures, MOUNTR enforces the  attribute  by  trying  to
prevent further mounting of the structure once is has been dismounted.
(excluding state 2).

With these states established it is now possible for  MOUNTR  to  know
the  expected  state  of  a  structure.   And  to  set  the attributes
appropriately.  For example, if MOUNTR believes the  structure  should
be   unavailable,  external  attempts  to  change  that  attribute  to
available will be met with an error message followed with  an  attempt
by  MOUNTR  to  set  the  attribute  back to unavailable.  MOUNTR will
attempt    this    with    available/unavailable,    domestic/foreign,
regulated/unregulated,   and   exclusive/shared.    If   however,  the
structure is mounted with an external source such  as  STRTST,  MOUNTR
will  only  note  the  recognition of the previously mounted structure
(including notifying the operator though ORION/OPR), and make sure the
attributes  are  correct.   It  will  not  change a mounted/dismounted
attribute on its own due to possible negative impact to users  of  the
structure.

Along with this change is a change to the  meaning  of  the  attribute
acknowledged/ignored.   Ignored  will  now  mean  that MOUNTR will not
attempt to change the attributes of the structure thus  disabling  the
behavior noted in the previous paragraph.



3.0  STATIC DATA BASE/STRUCTURE ATTRIBUTES

Now that  we  have  all  these  wonderful  states  defined,  it  seems
reasonable  to  keep  those  states  around.   The  new  MOUNTR  keeps
structure attributes in SYSTEM:DEVICE-STATUS-FILE.BIN file.  There are
a  number  of  reasons  for this.  First, with the direction of things
such as CFS, it seems that those attributes are  not  intended  to  be
fleeting.   For  example,  if a structure is to be used exclusively by
one system in a CFS configuration, the intent  is  probably  for  that
always  to  be  so.   In  addition, the system not using the structure
                                                                Page 3


probably always  wants  the  structure  to  be  unavailable.   Second,
consider  these  circumstances:  User A brings in structure pack to be
used on Tues.  He gets it mounted by operator but still cannot use  it
since  he  has  no  privs  and  the structure is mounted by default as
foreign.  He buys operator a cup of coffee and operator  is  nice  guy
and  sets structure domestic.  User brings structure back Thursday and
it costs him another cup of coffee to use the structure.  Either  that
or  he  has  operator  edit MOUNTR.CMD (more on that later) to add his
structure to the system list.  That could cost a donut as well.   With
the new scheme, the structure is mounted, set domestic, and stays that
way across system crashes, etc.  barring failure of the actual  device
status file.



4.0  MOUNTR.CMD

Now that we have a mechanism for maintaining the structure attributes,
the need/use of MOUNTR.CMD goes away.  In fact, allowing continued use
of MOUNTR.CMD is a bad idea since it would require MOUNTR  to  resolve
conflicts  between  the static data base and MOUNTR.CMD.  In addition,
the code supporting MOUNTR.CMD in  MOUNTR  proper,  is  confusing  and
probably expensive to use.

The result of this is to not support  MOUNTR.CMD  with  version  5  of
GALAXY.   It  is  recommended that old MOUNTR.CMD files be turned into
command files that can be read as command files by  OPR.   It  may  be
useful to recommend the creation of such a command file in any case as
a hedge against future disk failures that could damage the disk status
file.   It  is  also  possible  that  in  the future the format of the
command file will change sufficiently that the file  may  need  to  be
recreated.  Indeed, a version number for the disk status file will now
be included and the current MOUNTR will reset the device  status  file
if  the  version number is not the expected version number.  In such a
case, having the proper set of commands to set  the  structure  states
may have a small benefit.



5.0  OLD EXTERNAL CHANGES

5.1  OPR>SHOW STATUS DISK

The old disk status display  was  a  mixture  of  disk  and  structure
information.   For  example, available/unavailable state indicated was
for   the   structure.    There   was    no    indication    of    the
available/unavailable state of the disk drive itself.

The new display contains 2 distinct  types  of  information  organized
into  left and right halves.  The left half contains information about
the disk drive such as type, path (channel,controller,unit), and state
(disk  available/unavailable).   The  right  half contains information
about the structure packs contained on  the  respective  disk  drives.
The  structure  information contained is only to provide a view of the
state of the disk drives.  Attribute information for the structure  is
                                                                Page 4


provided only for attributes affecting the use of the disk drive.  For
a complete picture of the  state  of  a  structure,  there  is  now  a
structure status display.

In addition, free and mounted drives are now intermixed.  The operator
can still request only the free drives or mounted drives but if all is
requested (the default case) the drives  will  not  be  separated.   A
benefit  of  this  is for more information to be provided for the free
drive cases.



6.0  NEW EXTERNAL CHANGES

6.1  OPR>SHOW STATUS STRUCTURE

This  display  provides  the  structure  alias,   name,   state,   and
attributes.   This  display  also  contains structures that may not be
mounted currently.  Thus it provides a view  of  the  saved  structure
states  as  well.   The  command  also  provides 3 options that can be
selected.  The default is ALL which provides information for all known
structures.   The MOUNTED option, provides a display of all structures
currently mounted.  The UNMOUNTED option provides  a  display  of  all
structures  contained  in the static database including attributes but
not including any structure currently mounted.  Finally, the structure
display  includes  a special indicator of which structure is currently
the primary public structure.



6.2  OPR>SHOW STATUS STRUCTURE FOO:

For a quick glance at the complete status of a  particular  structure,
the  structure name can be included with the status structure command.
This display which includes only the named structure contains 3 parts.
The  first  part  is  the  one  line contained in the normal structure
status including header.  This is  the  only  part  included  with  an
unmounted  structure.  The second part is the information contained in
the status disk display for all disk packs contained in the structure.
The  third  and final part is the current usage of the structure.  The
information contained will be similar to information contained in  the
EXEC  command,  INFORMATION  (ABOUT)  STRUCTURE  indicating  the users
currently with the structure mounted, accessed, and connected.



6.3  OPR>UNDEFINE STRUCTURE FOO:

Now that we  have  this  wonderful  static  data  base,  we  may  have
structures  defined  that  we  no longer care for, (remember that disk
pack someone  dropped?).   For  those  cases,  the  structure  can  be
undefined  which causes MOUNTR to remove the structure from its static
data base both internally and on its disk data base.   This  operation
will only succeed if the structure is currently not mounted.
                                                                Page 5


6.4  OPR>MOUNT STRUCTURE FOO:  [Tentative]

There are 2 cases that call for such a command.  If  a  structure  has
been  dismounted but not removed yet from the system, and the operator
would like to again permit use of the structure,  this  command  would
clear  the  structure  being  dismounted  state  and  then  mount  the
structure.  The second case involves causing structures to be  mounted
upon physical mounting.  For example, during system startup, a startup
file can indicate that a certain structure (like PUBLIC on G/C) is  to
be  mounted immediately upon being found.  Note that this is different
from a normal user mount.   This  only  causes  the  structure  to  be
mounted.   It  does  not  increment the mount count which happens in a
normal user mount case.



6.5  Misc.  Noise


      o  Messages are generated when the device status file is  reset.
         This used to happen very quietly.

      o  When certain entries are added to the device data  base  such
         as port entries, notification of the event occurs.

      o  There are messages generated whenever  a  previously  mounted
         structure  is  detected by MOUNTR or when a structure mounted
         by MOUNTR is dismounted by another source.

      o  There are messages generated whenever a  structure  attribute
         is  changed behind MOUNTR's back.  The message is twofold, it
         contains the  attribute  in  error  and  then  indicates  the
         success/failure  to  restore  the  attribute  to  the correct
         setting.




7.0  OPERATIONAL CHARACTERISTICS/PROCEDURES

7.1  Mounting

User mount requests will occur as they have in the past.  In addition,
when the operator receives the request his procedure can be different.
SHOW STATUS DISK will show likely candidates to be dismounted assuming
there  are  no  drives  already  available.   Once a structure seems a
likely candidate for removal, (indicated by either being  free  or  by
having  a  mount  count  of  0)  the  operator  can give a SHOW STATUS
STRUCTURE x:  for that particular structure.  This will show any users
accessing  structure without having incrementing the mount count (this
occurs when the structure is unregulated).
                                                                Page 6


7.2  Dismounting

Structures are dismounted as in the past.  There is now  an  important
notice  in  the removal statement which will indicate if the structure
can be removed now that the dismount has occured.   Any  default  user
request for dismount only causes the mount count to be decremented.  A
user request with a removal switch causes the structure to be  removed
even  if  that  request  may cause the structure to be dismounted from
more than one system in a CFS configuration.



7.3  Mounting A Previously Dismounted Structure

In this case the new OPR>MOUNT STRUCTURE x:  command needs to be given
to  clear  the  structure  being  dismounted state.  (Isn't this a lot
easier to remember than to set the struture available?) The reason for
this reqirement is as follows:  User A wants to dismount the structure
and take it home.  The structure is dismounted and the operator  heads
for the disk drive.  Meanwhile User B attempts to mount the structure.
Without the  structure  being  set  unavailable  due  to  dismount  in
progress,  the structure is mounted and the operator carefully removes
a currently mounted structure.

There is another possible procedure.  Once the structure  is  offline,
the  structure  being  dismounted attribute is cleared.  The structure
can then be returned to online and remounted correctly.



7.4  Port Switching On A Dual Ported RA81

If an HSC crashes when 2 HSCs are used to  provide  high  availability
the structure will be detected as having gone offline on the path used
by the crashed HSC and will then be detected as a  previously  mounted
structure returning online on the new HSC.



7.5  Meaning For Channel/controller/unit Numbers

The channel if 7 indicates the CI.  If that is so, then the controller
number  indicates  CI node.  The controller and unit numbers will also
now be in decimal.  The unit number  of  a  massbus  disk  on  another
system  accessed with MSCP will be an encoding of the channel and unit
number information for the other system.



7.6  Exclusive

The procedure for setting a structure exclusive is  changed  from  the
origional   specification.   It  is  now  handled  as  are  all  other
attributes, if the structure is to be set to exclusive due to  an  OPR
command  and  it  fails  (probably  due to the use of the structure by
                                                                Page 7


other systems) the set command will be rejected.   The  operator  then
needs  to  stop  use  of  the  structure  by  other systems in the CFS
configuration (by dismounting and setting unavailable) and then  retry
the command.  A response will not be called for.



7.7  Structure Name VS Structure Alias

The use of these in the past has been somewhat loose.  This is what  I
believe they mean and what MOUNTR does with them.

Structure name is the name of the disk  pack  contained  in  the  home
blocks  of  the  disk  pack.   When  the  structure  is mounted, it is
referenced by its alias.  A structure name does  not  have  attributes
since the attributes of a structure refer to a mounted structure.  For
this reason, all commands referring to structures in OPR are referring
to   the   structure   alias.   (examples:   SET  STRUCTURE,  UNDEFINE
STRUCTURE, DISMOUNT STRUCTURE)  Saved  structure  characteristics  are
based on structure alias only.

Please note that this is not too serious a statement since  structures
are almost always mounted with the name being equal to the alias.  The
only point here is to make the distinction for the cases where it  may
matter.



8.0  POSSIBLE ADDITIONS


      o  Would like to provide the last  date/time  mounted  with  the
         structure status display for a particular structure.

      o  Would like for the EXEC to never reject a request due to  the
         monitor  attribute  "structure  being dismounted".  In such a
         case, the operator should be notified.


      +---------------------------+
      !   !   !   !   !   !   !   !     i n t e r o f f i c e
      ! d ! i ! g ! i ! t ! a ! l !
      !   !   !   !   !   !   !   !      m e m o r a n d u m
      +---------------------------+


      To: Distribution                  Date: 12-May-83
                                        From: David Kovalcin
                                        Dept: LSG Software Engineering
                                        Ext: DTN 231-4155
                                        LOC/MAIL STOP: MR1-2/L14


      Subject:  Operations in a TOPS-20 R6 Environment



      It is clear that there are some grey areas surrounding  operations
      in TOPS-20 R6 with and without a CI and with and without CFS.  The
      purpose of this document is to try to describe those environments.



      1.0  OPERATIONS IN RELEASE 6 WITHOUT CI OR CFS

      This is the easy one.  There should be few  changes  from  current
      operations  for  this  configuration.   There  are  some  new  OPR
      commands but often the command will be rejected, or will  have  no
      effect.  The following sections describe some of these changes.



      1.1  New Aspect To Setting Structure Unavailable

      It has been true for some time (or maybe always)  that  setting  a
      DISK-DRIVE  unavailable  has had a permanent effect.  That is, the
      disk drive was not available until the OPR set it available.  This
      attribute  remained set across system crashes.  On the other hand,
      setting a structure unavailable only lasted until the next  system
      crash  (or  until  the operator negated the command by setting the
      structure available).  Due to expected  operational  changes  with
      CFS,  the  set  structure  unavailable  command  will  now  have a
      permanent effect.



      1.2  New System Messages

      Some messages that were only printed on the  console  device  will
      now also be printed at OPR terminals.  The output display of these
      messages can be controlled with new options to the  ENABLE/DISABLE
      OUTPUT-DISPLAY  command.   The  three classes are BUGCHK-MESSAGES,
      BUGINF-MESSAGES, and SYSTEM-MESSAGES.  The SYSTEM-MESSAGES  option
      controls the printing of such messages as:
                                                                  Page 2


       o  Job 0 crash

       o  Swapping space low

       o  SPT space low

       o  Disk space low

       o  Recoverable AR/ARX and MEMORY parity erors




      1.3  Dismounting Structures From OPR

      There  is  a  new  remove/noremove  option  to  the   OPR>DISMOUNT
      STRUCTURE  command.   This  will  be  described in the dismounting
      structures in a CFS environment section.



      1.4  New Structure Attribute

      There is a new shared/exclusive attribute which  can  be  set  but
      will have no effect in this configuration.  It is described in CFS
      operations section.



      1.5  SET PORT CI AVAILABLE/UNAVAILABLE Command

      In the non-CI environment this command  will  be  rejected.   This
      command is described in other sections.



      2.0  OPERATIONS IN RELEASE 6 WITH CI AND DISKS BUT WITHOUT CFS

      This case has the same attributes as the previous  case  but  with
      some  additions.   Shared  and  exclusive  still  work but have no
      effect.  Setting the structure unavailable is no longer transient.
      But there are some additional items as well.



      2.1  Disks On The CI

      The one observable change is new disk types included in  the  show
      status disk display (RA81, etc).  They will be identified as being
      on channel  "CI-7".   In  addition,  the  controller  number  will
      indicate which HSC owns the disk.  Consider the following example:
                                                                  Page 3


                                        CI     
                ==============================
                        |               |
                     --------        --------
                     | HSC1 |        | HSC2 |
                     --------        --------
                        |    ------     |
                        |----|RA81|=====|
                        |    |FO1:|     |
                        |    ------     |
                        |               |
                        |    ------     |
                        |====|RA81|-----|
                        |    |FO2:|     |
                             ------

      For redundancy, there are two HSCs and two RA81s (could be  more).
      In  this  example, FO1:  is currently "owned" by HSC2 and FO2:  is
      "owned" by HSC1.  (The controller number is the same as  the  node
      number  of  the  HSC.) Further information about CI and HSC may be
      available as part of diagnostic tools being developed, but this is
      not  considered  to  be  part  of  standard  operations and is not
      available as part of the operator interface (OPR).

      Note:  Ownership as described above can be asserted in one of  two
      ways  I  believe.  Either the RA81 has been ported through the use
      of the port switches on the front panel or an  HSC  has  used  the
      RA81 and that HSC's node number is retained by the RA81.



      2.2  CI Unavailable/Available

      A new procedure that may occur  is  setting  the  CI  unavailable.
      (This has been previously referred to as "offline" and "disabled")
      This is considered a drastic action and  should  not  occur  as  a
      normal  procedure.   The  purpose  of  the  command  is to end the
      system's normal use of the CI and any disks that are connected due
      to  the  CI.   In  addition, setting the CI unavailable for normal
      system action, enables the CI for diagnostic use.  This  solves  a
      possible security issue.  Until this action, diagnostic use of the
      CI is disallowed by the monitor.

      The following describes the steps that will occur in  setting  the
      port UNAVAILABLE:

      1.  The operator gives the following command:
          OPR>SET PORT CI UNAVAILABLE

      2.  The operator will receive a list of structures that are on the
          CI.  This message will include 3 parts:

           o  A statement that setting the port unavailable will  affect
              the following disk drives.
                                                                  Page 4


           o  A table in the form of a SHOW  STATUS  DISK  display  that
              only contains entries for disks effected.

           o  A request for the operator to respond.


      3.  The operator now has a choice of actions,  either  proceed  to
          the   next  step,  or  resolve  all  the  disks  indicated  by
          dismounting and then  proceeding  with  the  next  step.   The
          reason  the  operator  may  choose  to manually dismount these
          disks  is  to  limit  the  interaction  with  MOUNTR  (through
          OPR/ORION) that is to follow.

      4.  The operator gives one of the following responses:

           o  ABORT -- "I changed  my  mind."  The  change  due  to  the
              command is too great.  Abort setting the port unavailable.
              If the command is aborted at this point, system  operation
              is not changed.

           o  FORCE -- Do as the  command  implies.   Do  not  have  any
              further  dialogue.   This  option should only be exercised
              with caution.

           o  PROCEED -- Proceed with the command  but  notify  OPRs  of
              changes.   As  each structure is dismounted, the structure
              is handled as if an OPR dismount command were  given.   If
              there  are  users  of the structure, a confirmation of the
              structure dismount is required from OPR as in  the  normal
              dismount case.


      5.  The operator now goes through the normal  dismount  dialog  on
          the remaining affected drives.  Note that this will only occur
          for disk drives that  were  not  manually  dismounted  by  the
          operator  previously.   GALAXY  will detect any drive that was
          dismounted by the operator in response to the  first  message.
          Also  note  that a refusal of any dismount will be interpreted
          as an abort of the entire port unavailable command.   If  this
          occurs,  further  dismount  requests  will be canceled but any
          disks  already  dismounted  will  remain  dismounted  and  set
          unavailable.

      6.  After all disks are dismounted, the port  is  set  unavailable
          and all OPRs notified.




      3.0  OPERATIONS IN A CFS ENVIRONMENT

      Operations in this environment have the attributes  of  operations
      in the CI environment with additional attributes.
                                                                  Page 5


      3.1  Structure SHARED/EXCLUSIVE

      SHARED/EXCLUSIVE is a new structure attribute.  A  structure  that
      is SHARED can be used by any system in the CFS configuration.  Any
      user on the CFS configuration can use that structure as if it were
      a structure on a single system.  A structure that is set EXCLUSIVE
      can be used only by the system that has set  it  exclusive.   This
      would  be  used  when  the  structure contains data that should be
      protected from users on the other system for example.

      The SHARED/EXCLUSIVE attribute can be set either in MOUNTR.CMD  or
      in OPR using the SET STRUCTURE FOO:  SHARED/EXCLUSIVE.  The effect
      of this structure attribute is permanent across  system  failures.
      However, due to the GALAXYs not communicating between systems in a
      CFS configuration, there are some failures that can be  perceived.
      If  a  system that owns structure FOO:  exclusively crashes, there
      is nothing to prevent the other systems in the  CFS  configuration
      from attempting to use the structure.  When the system returns, it
      will find the structure already  shared  which  will  prevent  its
      setting   the  structure  exclusive.   For  this  reason,  when  a
      structure is set exclusive for use by  a  particular  system,  the
      same  structure should also be set unavailable by other systems in
      the CFS configuration.



      3.2  Dismounting Structures

      Dismounting structures has changed in CFS because  structures  can
      be  used by more than one system at a given time.  (Note:  GALAXYs
      on each  system  in  a  CFS  configuration  do  not  communicate.)
      Dismounting  a structure from a system without removing it has not
      changed  with  this  release.   Dismount  with  removal   however,
      requires  dismounting  the structure from all systems.  To protect
      from physically removing a structure before it has been dismounted
      from all systems in a CFS environment, there is a new requirement.
      A structure must be exclusive to  a  system  for  that  system  to
      remove the structure.

      To assist in fulfilling this  new  requirement,  the  OPR>DISMOUNT
      STRUCTURE  command  has  an  additional  option.  In the past, the
      OPR>DISMOUNT  STRUCTURE  command  caused  the  structure   to   be
      dismounted  and automatically removed.  The operator will now have
      the choice of whether to have structure  removed.   In  a  non-CFS
      environment,  this  command  will default to remove so the command
      will work as before.  In  a  CFS  environment,  the  command  will
      default   to  no-remove  which  seems  more  appropriate  for  the
      environment.  The OPR>DISMOUNT STRUCTURE command can now have  one
      of the following three forms:

       o  OPR>DISMOUNT STRUCTURE FOO:
          (Which implies no removal for CFS systems)
                                                                  Page 6


       o  OPR>DISMOUNT STRUCTURE FOO:  (with) REMOVAL

       o  OPR>DISMOUNT STRUCTURE FOO:  (with) NO-REMOVAL


      The operational procedure to remove structure  FOO:   from  a  CFS
      system   containing  systems  A::   and  B::   would  include  the
      following steps:

          SYSTEM A::                   SYSTEM B::

      1)  User requests DISMOUNT FOO:/REMOVE or
          OPR>DISMOUNT STRUCTURE FOO: (with) REMOVAL
      1a) If structure is in use, OPR will be asked to respond before
             proceeding
      2)  GALAXY will attempt to set the structure exclusive if the
             dismount fails.  If successful, go to step 8
      3)  OPR is told structure cannot be set exclusive and needs to
             be dismounted from the other system

      4)                       OPR>SET STRUCTURE FOO: UNAVAILABLE
      5)                       OPR>DISMOUNT STRUCTURE FOO: (with) NOREMOVE

      6)  Respond to request in 3 with proceed
      7)  Go back to step 2
      8)  Dismount and remove structure FOO:

      Step 3 will not succeed until 4 and 5 are successfully  completed.
      Step 4 is necessary to insure that SYSTEM B::  does not attempt to
      remount structure FOO:  before SYSTEM A::  has set it exclusive.



      3.3  Setting CI Unavailable

      In a CFS environment, setting the CI unavailable will  follow  the
      same  procedures  as in a non-CFS environment with some additional
      steps.  The problem that needs to be solved is the problem of dual
      ported  massbus  disks.   If the CI is being set unavailable, then
      CFS will cease to function.  Massbus disks that  are  dual  ported
      between two systems in the CFS configuration can no longer use CFS
      to arbitrate the use of the disks.  The CFS  systems  have  agreed
      upon protocols that will attempt to prevent any destructive use of
      the disks.  However, consider the following scenario:  The  CI  is
      being set unavailable to give one of the systems to field service.
      They run a release 4 system as part of  their  diagnostics.   That
      software  would not understand the protocols that CFS systems have
      agreed upon and dual ported disks could receive file damage.  As a
      result, the procedures for setting the CI unavailable will attempt
      to resolve any possible dual porting problems.  In  a  sense,  the
      procedure  for  setting  the  CI  unavailable is a reconfiguration
      process.

      The following steps are additions for setting the  CI  unavailable
      in a CFS environment:
                                                                  Page 7


       o  When the operator is notified of disks affected in step  2  of
          the  CI unavailable procedure, notification will also be given
          of disk drives that are potentially dual ported.

       o  The operator has the option of changing  port  switches  along
          with dismounting disks.

       o  In  addition  to  the  messages  for  each  dismount  that  is
          required,  there  will  also be a request to resolve each dual
          ported disk drive.  The operator will be given the  choice  to
          ABORT,  IGNORE  or  PROCEED.   ABORT terminates setting the CI
          unavailable.  IGNORE indicates that the dual portedness is  to
          be  ignored.   This would be a reasonable response for example
          if the disk drive had 2 ports but  the  second  port  was  not
          connected  at all.  PROCEED indicates the port switch has been
          set to one system or the other and the drive should no  longer
          be  dual ported.  (The disk may no longer be available to this
          system at this point)

      Definition -- "Potentially dual ported" -- any disk that  has  two
      ports  and the system is unsure of where the second port connects.
      If a disk drive has 2 ports both connected to this system,  it  is
      not  potentially  dual ported.  It is unclear at this time whether
      the disks dual ported to the front end will be detected.


     QUEUE% JSYS





     1.0  SUMMARY

     The QUEUE% JSYS is intended  to  provide  an  interface  between  user
     programs  and  system  processes.   Actually, it is probably misnamed.
     Even with the initial applications it will  provide  a  mechanism  for
     communicating  with  the  operator  interface  (ORION)  as  well  as a
     mechanism for initiating queue and mount/dismount requests.

     The goal for release 5 of GALAXY is to support the queueing  functions
     and  the  operator communication functions.  Some mention is made here
     to the tape/structure functions (which are available on  the  10)  but
     that  is  only  for consistency.  The tape/structure functions are not
     planned to be supported with release 5.



     2.0  STRUCTURE

     Although at first glance the structure of its use appears  complicated
     and  confusing (maybe even at second glance), the structure was chosen
     for its flexibility.  Monitor modifications will only be necessary  if
     a new application or new function is added, and then only to add a new
     PID designator or dispatch entry.

     The two essential pieces of information that are needed to use  QUEUE%
     are:

      o  Function type - Print request, write to operator, etc.

      o  Set of argument blocks appropriate for the function type

     There is no need for the user to know the actual process that receives
     the request.

     There are 2 classes of functions that the  initial  implementation  of
     QUEUE%  will  provide.   One  set, the actual queueing functions, will
     cause a job request to be presented to QUASAR to  be  processed  as  a
     normal  job.   The  other  set enables limited communications with the
     operator.  Generally, each of these classes has a set  of  appropriate
     argument  blocks.  Further, certain argument blocks may be appropriate
     only for specific functions in a class.

     For example, consider a print job.  One item required for all queueing
     functions  as  an  argument block is a file specification.  So a print
     request requires a file argument block to be included.  Further, there
     is an argument block to indicate a log file is desired.  That argument
     block is inappropriate for a print request.
                                                                     Page 2


                                      NOTE

         A feature/aspect of the structure and operation of the  QUEUE%
         JSYS  is  where  the  argument blocks are parsed.  The monitor
         does not have actual knowledge of the required argument blocks
         for  a  particular  function.   This  is a feature because the
         monitor does not need updated due to an argument  block  being
         added  or  changed.   It  is only the application process that
         needs to be changed.  It is an aspect because the monitor will
         not  detect wrong combinations of the argument blocks and will
         not generate an explicit error message  available  from  ERSTR
         other  than "error received from application".  The processing
         and error string will be generated by the application process.


     In addition to performing the requested function, QUEUE% will return a
     response  unless  a  flag is set explicitly declining a response.  For
     the queueing functions the response is an ASCII string indicating  the
     job  has  been  accepted  (same as the acknowledgment line provided in
     response to a queue request in the EXEC).  The response  will  have  a
     slightly  different meaning depending on use for the write to operator
     functions.  This is described in that section that follows.



     2.1  Queueing Functions

     Queueing functions perform tasks normally accomplished with PRINT  and
     SUBMIT  commands.   For these functions, a file descriptor argument is
     required before any  other  argument  blocks.   Any  number  of  other
     argument blocks may be included after to declare various attributes of
     the request.  These arguments are similar to the  switches  associated
     with those commands.


                                      NOTE

         The reason to require the file descriptor argument block to be
         first  is to allow for easy future expansion.  It is a goal to
         eventually (post GALAXY V5) allow multiple files be  specified
         in  a  queue request.  In this case, attributes that are to be
         associated with the entire request will be  before  the  first
         file  descriptor  block,  and attributes for a particular file
         will be after the file descriptor and  before  the  next  file
         descriptor.
                                                                     Page 3


     2.2  Write To Operator Functions

     The write to operator functions perform the  same  functions  normally
     associated  with use of the PLEASE program.  The response to this type
     of function depends on the function.  For a write to operator  without
     reply,   the  acknowledgment  indicates  that  the  message  has  been
     received.  For a write to operator with reply, the process will remain
     blocked  until the operator responds to the message which should be in
     the form of a request.  In this  case,  the  response  is  the  actual
     reply.



     3.0  JSYS INTERFACE

     The user builds a set of argument blocks and presents  them  with  the
     header information in the parameter block.


                                      NOTE

         If the user does not accept a response, there is no  guarantee
         the  request  has  been accepted.  As noted above, the monitor
         only does some basic consistancy checks.  If the failure is  a
         bad  combination of argument blocks, and the user has declined
         receiving a response, the user will not be notified of the bad
         argument block set.


     ACCEPTS IN AC1:  Length of parameter block
                AC2:  Address of parameter block

     RETURNS     +1:  always

     Parameter block:

         +-------------------------------------+
         |FLAGS |RESP LENGTH|  FUNCTION CODE   | header
         |-------------------------------------|
         |        RESPONSE BLOCK ADDRESS       |
         |-------------------------------------|
         |I|    LENGTH      |  ARGUMENT TYPE   | first argument
         |-------------------------------------|    block
         |           VALUE OR ADDRESS          |
         |-------------------------------------|
         |                                     | additional argument
         |                  .                  |    blocks
         |                  .                  |


     Actual contents (to be defined in MONSYM):

     Word       Field           Contents/value
     ----       -----           --------------
                                                                     Page 4


     0 (.QUFNC) B0-B7(QF%FLG)   Flag bits               
                B0(QU%NRS)      No response (don't wait)
                B1(QU%DBG)      Use debugging PID
                B8-B17(QF%RSP)  Length of response block (1 page max.)
                B18-B35(QF%FNC) Function code

                                QUEUEING FUNCTIONS
                        .QUPRT=1        Print file
                        .QUCDP=2        Punch cards
                        .QUPTP=3        Punch paper tape
                        .QUPLT=4        Plot
                        .QUBAT=5        Batch

                                MOUNT/DISMOUNT FUNCTIONS
                                (Reserved for future use)
                        .QUMNT=10       Mount volume
                        .QUDIS=11       Dismount volume

                                WRITE TO OPERATOR FUNCTIONS
                        .QUWTO=12       Write to operator
                        .QUWTR=13       Write to operator with reply

     1 (.QURSP)                 Address of response block

     2 (.QUARG)                 Beginning of argument blocks
                        .QATYP=0        First word of argument block
                         B0(QA%IMM)     On implies immediate argument value
                         B9-B17(QA%LEN) Length of argument value
                         B18-B35(QA%TYP)Argument type
                        .QADAT=1        Data type
                          (For more info see arg block desc.)



     4.0  MONITOR INTERFACE

     4.1  Parameter Block Sent By Monitor

     Given the parameters described above by the  user,  the  monitor  will
     repackage  the  information,  and  send the package to the appropriate
     GALAXY component for processing.  The  repackaging  requires  fetching
     all  indirect arguments and making them immediatly follow the argument
     function word.  The length is changed to indicate the  length  of  the
     new argument block itself including the header.  In addition, there is
     a new system code (.IPCCG = 4) that is set in the flag word of the PDB
     (packet  descriptor block) to indicate QUEUE% processing as the source
     of the message.

     The message sent is  based  on  the  standard  GALAXY  message  header
     information.   This  requires  the  monitor  module  (JSYSA) to search
     GLXMAC.UNV.
                                                                     Page 5


                                      NOTE

         This is a departure from the origional specification.   First,
         the  origional  specification  specified  the  format  of  the
         message without referencing the source of the format (GLXMAC).
         Second, the origional specification required the monitor build
         a specific argument block to contain the user's function code.
         The  function  code in the header was then set to "65" which I
         believe was a free GALAXY message code.  It  was  feared  that
         using  the user function codes specified in MONSYM with values
         similar to other messages in GALAXY would lead  to  confusion.
         But since the source can already be determined from the .IPCCG
         flag, analyzing the function in that context seems appropriate
         and  consistant.   This  is  also a departure from the TOPS-10
         implementation.



     Parameter block (one page maximum):

         +-------------------------------------+
         |   TOTAL LENGTH   |  FUNCTION CODE   | header
         |-------------------------------------|
         |                  0                  |  (flags,,suffix)
         |-------------------------------------|
         |                  0                  |  (ACK code)
         |-------------------------------------|
         |                  0                  |  (flag word)
         |-------------------------------------|
         |       NUMBER OF ARGUMENT BLOCKS     |
         |-------------------------------------|
         |      LENGTH      |  ARGUMENT TYPE   | first user argument
         |-------------------------------------|    block
         \           ARGUMENT DATA             \
         |-------------------------------------|
         |                                     | additional argument
         |                  .                  |    blocks
         |                  .                  |


     Actual contents (from GLXMAC;  only info of interest):

     Word       Field           Contents/value
     ----       -----           --------------

     0 (.MSTYP) B0-B17(MS.CNT)  Total length of the message
     [was .QJLTY]                 (including this header word)
                B18-B35(MS.TYP) Function code
     1 (.MSFLG) B0-B17          Message flags
     [was .QJMB1]
                 1B0 (MF.ACK)   Acknowledgment requested
                 1B1 (MF.NOM)   An acknowledgment message
                B18-B35(MF.SUF) Suffix for text (not set)
     2 (.MSCOD)                 Acknowledgment code
     [was .QJMB2]
                                                                     Page 6


     3 (.OFLAG)                 Flag word
     [was .QJMB3]
     4 (.OARGC)                 Argument block count
     [was .QJMBC]
     5 (.OHDRS)                 Length of header information and
     [was .QJFNC]                 beginning of argument blocks

                        ARGUMENT BLOCKS
     0 (ARG.HD) B0-B17(AR.LEN)  Length of argument block
                                  (including this header word)
                B18-B35(AR.TYP) Argument type
     1 (ARG.DA)                 Beginning of data for argument



                                      NOTE

         The ACK code word contains the job  number  of  the  job  that
         issued  the  QUEUE% JSYS.  This is because in those situations
         where no response is requested, the PID  of  the  job  may  be
         released  before  GALAXY  has  a  chance to get the job number
         associated with the PID.






     4.2  Response Block Received By Monitor

     Once the message is processed by the  component,  a  response  message
     will be provided if requested.  That message will have the same format
     as the message sent by the monitor.  In this case, the flag indicating
     acknowledgment  will  be  set  and one argument block, a text argument
     block containing  the  textual  response,  will  be  included  in  the
     message.



     5.0  ARGUMENT BLOCKS

     Argument blocks have the following general format:

         |                                     |
         |-------------------------------------|
         |I|    LENGTH      |  ARGUMENT TYPE   |
         |-------------------------------------|
         |           VALUE OR ADDRESS          |
         |-------------------------------------|
         |                                     |

     where I is a bit to indicate an immediate argument, LENGTH  is  length
     of  the  actual  argument  (1  if immediate), ARGUMENT TYPE is what it
     claims to be, and VALUE OR ADDRESS is the value of the argument  if  I
     is set or the address of the argument if I is not set.
                                                                     Page 7


     The following sections describe in detail each of the argument blocks.
     Note  that  in  the example blocks, if a one word entry is appropriate
     for  the  actual  argument  value,  only  that  format  is  displayed.
     However, in actual use even a one word argument can be identified with
     a pointer to that one word from the argument block.

     The use section indicates the type  of  functions  that  the  argument
     block  has  use.   Specifics  only address the PRINT and BATCH queuing
     functions.  I.E.   specifics  about  plotting  and  punching  are  not
     included at this time.



     5.1  Account Argument Block


          |                                     |
          |-------------------------------------|
          | Length of text   |      .QBACT      |
          |-------------------------------------|
          |   Pointer (address) to ASCIZ text   |  (account as ASCII string)
          |-------------------------------------|
          |                                     |

     This block indicates the account to be charged for the job execution.

     USE:  Any of the queuing functions.



     5.2  Begin Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBBGN      |
          |-------------------------------------|
          |  Number indicating where to begin   |
          |-------------------------------------|
          |                                     |

     This block is used to specify the beginning of processing of the job.

     USE:  Any of the queuing functions.  For different queuing  functions,
     the  attribute  has a different meaning.  For PRINT jobs, it indicates
     the number of the page on which printing is to begin.  For BATCH jobs,
     it indicates processing is to start at the line number indicated.
                                                                     Page 8


     5.3  Copies Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBCOP      |
          |-------------------------------------|
          |         Number of copies            |
          |-------------------------------------|
          |                                     |

     This block indicates the number of copies to be generated.

     USE:  This is  used  exclusively  for  output  requests,  i.e.   PRINT
     requests.



     5.4  Display Type Argument Blcok


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBDTY      |
          |-------------------------------------|
          |     .QBCHK, .QBINF, or .QBSYS       |
          |-------------------------------------|
          |                                     |

     This argument block is  used  with  write  to  operator  functions  to
     indicate  the  type  of  display message.  The currently defined types
     are:

      o  .QBCHK indicates BUGCHK display (monitor use only)

      o  .QBINF indicates BUGINF display (monitor use only)

      o  .QBSYS indicates SYSTEM messages (monitor use only)

     USE:  Write to operator messages (with or without reply)



     5.5  Disposition Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBODP      |
          |-------------------------------------|
          |     0 to preserve, 1 to delete      |
          |-------------------------------------|
          |                                     |

     This argument is used to indicate  whether  certain  files  associated
                                                                     Page 9


     with  this  request  are  to  be  deleted  or  kept  (preserved)  upon
     completion of the job.

     USE:  Any of the queuing functions.  In a PRINT job, the printed files
     are deleted or preserved.  In a BATCH job, it is the control file that
     is preserved or deleted with this parameter.



     5.6  File Descriptor Argument Block


          |                                     |
          |-------------------------------------|
          | Length of text   |      .QBFIL      |
          |-------------------------------------|
          |   Pointer (address) to ASCII text   |  (filename as ASCII string)
          |-------------------------------------|
          |                                     |


     USE:  This argument is the only one required for any  of  the  queuing
     functions.  For a PRINT job, it indicates the file to be printed.  For
     a BATCH job, it indicates the control file to be used  for  the  batch
     job.



     5.7  File Format Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBFMT      |
          |-------------------------------------|
          |  .QBFAS, .QBFCB, .QNF11, or .QBFFR  |  file type
          |-------------------------------------|
          |                                     |

     This argument is used to describe the format of the file.  Using  this
     information  the  printer  spooler  can interpret the data in the file
     correctly for printing.  The currently supported arguments are:

      o  .QBFAS indicates the file is ASCII

      o  .QBFCB indicates the file is COBOL

      o  .QBF11 indicates the file is ELEVEN

      o  .QBFFR indicates the file is FORTRAN


     USE:  PRINT requests only.
                                                                    Page 10


     5.8  Forms Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBFRM      |
          |-------------------------------------|
          |         Forms name in SIXBIT        |
          |-------------------------------------|
          |                                     |

     This argument is used to indicate the  form  (as  set  by  the  system
     administrator)  to  be  used for the output such as type of media, and
     characteristics of the media (width, height, etc.)

     USE:  Output queue requests, PRINT.



     5.9  Device Type Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBUNT      |
          |-------------------------------------|
          | .QBUGN, .QBULC,  |    Unit # if     |
          | .QBUUC or .QBUPH |      .QBUPH      |
          |-------------------------------------|
          |                                     |

     This argument is  used  to  indicate  the  unit  (object)  number  and
     characteristics   of   the  object  to  process  the  job.   Currently
     implemented characteristics:

      o  .QBUGN indicates the device is generic.

      o  .QBULC indicates the device is lowercase.

      o  .QBUUC indicates the device is uppercase.

      o  .QBUPH indicates a physical unit number is provided.


     USE:  Any of the queuing functions.  The  unit  number  indicates  the
     stream   number   in   the   case   of  a  BATCH  job.   The  physical
     characteristics are only applicable to PRINT requests.
                                                                    Page 11


     5.10  Job Name Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBJBN      |
          |-------------------------------------|
          |         Job name in SIXBIT          |
          |-------------------------------------|
          |                                     |

     This is used to  set  a  jobname  other  than  the  default  which  is
     generated  from  the  first  6 characters of the filename in the queue
     request.  The argument value is from 1 to 6 sixbit  characters.   This
     jobname can be used for modifications to the request.

     USE:  Any of the queuing functions.



     5.11  Limit Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBLIM      |
          |-------------------------------------|
          |        Limit of job as number       |
          |-------------------------------------|
          |                                     |

     This argument is to limit the amount resources to be allocated to this
     job.   It  also has a secondary use in that it is an attribute that is
     considered in the scheduling of jobs.

     USE:  Any of the queuing functions.  For PRINT jobs, it indicates  the
     maximum  number  of pages to be printed.  For BATCH jobs, it indicates
     the time limit for the job.



     5.12  Log Conditions Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBLOG      |
          |-------------------------------------|
          |      .QBLNL, .QBLLG, or .QBLLE      |
          |-------------------------------------|
          |                                     |

     This argument is used to indicate the conditions upon which a log file
     is to be generated.  The possible conditions are:
                                                                    Page 12


     1.  .QBLNL  -  no log file is to be generated.

     2.  .QBLLG  -  always generate a log file.

     3.  .QBLLE  -  generate a log file only if an error occurs.


     USE:  Log files are only generated by  BATCH  jobs  so  this  argument
     block is appropriate only for BATCH jobs.



     5.13  Batch Log Disposition Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBBLT      |
          |-------------------------------------|
          |      .QBBND, .QBBDE or .QBBSP       |
          |-------------------------------------|
          |                                     |

     This  block  is  used  to  indicate  how  the  log  file   should   be
     created/disposed.  The possible conditions are:

     1.  .QBBND  -  append log file for this job to the currently  existing
         log file (if one exists).

     2.  .QBBDE  -  supersede the  currently  existing  log  file  (if  one
         exists).

     3.  .QBBSP  -  spool the log file on completion of the job.


     USE:  Log files are only generated by  BATCH  jobs  so  this  argument
     block is appropriate only for BATCH jobs.



     5.14  Message Text Argument Block


          |                                     |
          |-------------------------------------|
          |      Length      |      .QBMSG      |
          |-------------------------------------|
          |   Pointer (address) to ASCIZ text   |  (text containing msg)
          |-------------------------------------|
          |                                     |

     This block is used to send a text message from one GALAXY component to
     another, generally for display purposes.

     USE:  Write to operator messages (with or without reply)
                                                                    Page 13


     5.15  Message Text (privileged) Argument Block


          |                                     |
          |-------------------------------------|
          |      Length      |      .QBTYP      |
          |-------------------------------------|
          |   Pointer (address) to ASCIZ text   |  (text containing msg)
          |-------------------------------------|
          |                                     |

     This block is used to send a text message from one GALAXY component to
     another,  generally  for display purposes.  The sender of this type of
     block is checked for privs.

     USE:  Write to operator messages (with or without reply)



     5.16  Node Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBNOD      |
          |-------------------------------------|
          |          Node name in SIXBIT        |
          |-------------------------------------|
          |                                     |

     This is used to  associate  a  node  with  the  request.   How  it  is
     interpreted depends on the context.

     This is probably a bad idea.  It propogates the problem  we  currently
     have  with  OPR  due to the node switch having an ambiguous meaning in
     certain  contexts.   We  really  need   probably   3   possible   node
     designators.

     USE:  For a write to operator, this  indicates  that  the  message  is
     destined  for  only  operators  on  the  node  specified.   For  PRINT
     requests, it indicates the node on which the  printing  is  to  occur.
     For BATCH requests ???  See above paragraph.



     5.17  Note Argument Block


          |                                     |
          |-------------------------------------|
          |  length (2 max)  |      .QBNTE      |
          |-------------------------------------|
          |   Pointer (address) to SIXBIT text  |  (Note in SIXBIT)
          |-------------------------------------|
          |                                     |
                                                                    Page 14


     This allows up to 12 sixbit characters to be associated with a queuing
     request.

     USE:  Output (PRINT) requests.



     5.18  Notification Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBNOT      |
          |-------------------------------------|
          |  0 if no notify, .QBNTY to notify   |
          |-------------------------------------|
          |                                     |

     This block enables the requestor to be notified upon completion of the
     job.

     USE:  Any queuing request.



     5.19  Priority Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBPRI      |
          |-------------------------------------|
          |  Number 0<#<63 indicating priority  |
          |-------------------------------------|
          |                                     |

     This block allows the user to specify the  priority  of  the  job  for
     scheduling  purposes only.  (note:  a batch job with a higher priority
     may  be  scheduled  quicker  with  a  higher  priority  but   priority
     specification  has  no impact on the system resources available to the
     job once started.) There are some restrictions on which priorities may
     be selected by non-privileged users.

     USE:  Any queuing requests.



     5.20  Restart Argument Block
                                                                    Page 15


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBRES      |
          |-------------------------------------|
          |     .QBRNO (no) or .QRNYE (yes)     |
          |-------------------------------------|
          |                                     |

     This block allows the job to be restarted after a system failure.

     USE:  BATCH requests only.



     5.21  Start Time (after) Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBAFT      |
          |-------------------------------------|
          |      Date/time in UDT format        |
          |-------------------------------------|
          |                                     |

     This parameter allows a job to be started at some future time.

     USE:  Any queuing request.



     5.22  Unique Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBUNQ      |
          |-------------------------------------|
          |     .QBUNO (no) or .QBUYE (yes)     |
          |-------------------------------------|
          |                                     |

     This block enables the user to allow/disallow the simultaneous running
     of multiple batch jobs.

     USE:  BATCH requests only.



     5.23  User Identification Argument Block
                                                                    Page 16


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBOID      |
          |-------------------------------------|
          |             User number             |
          |-------------------------------------|
          |                                     |

     This argument block identifies the user by  his  logged  in  directory
     number.

     USE:  Any queuing request.



     6.0  ARGUMENT BLOCKS ON THE 10 NOT ON THE 20

     6.1  Connected Directory Argument Block

     This argument block is used on the 10 to provide additional  directory
     information   such   as  SFD  information.   The  connected  directory
     information on the 20 is  found  by  QUASAR  detecting  the  connected
     directory of the requesting job.



     6.2  User Name Argument Block

     This allows the user to specify a character string of up to 12  sixbit
     characters  to  identify  the initiator (the user) of the job.  On the
     20, the user is identified based on the directory name.

     USE:  queueing requests



     7.0  ARGUMENT BLOCKS FOR NOT IMPLEMENTED MOUNT FUNCTIONS

     The following argument blocks are included only for future reference.



     7.1  Density Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBDEN      |
          |-------------------------------------|
          |             Tape density            |
          |-------------------------------------|
          |                                     |

     ???  How is the density specified ???
                                                                    Page 17


     USE:  Tape mount requests



     7.2  Label Type Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBLTP      |
          |-------------------------------------|
          |             Label type              |
          |-------------------------------------|
          |                                     |

     ???

     USE:  Mount requests



     7.3  Mount Flags Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBMFG      |
          |-------------------------------------|
          |        Mount/dismount flags         |
          |-------------------------------------|
          |                                     |

     This argument block is used to indicate certain characteristics of the
     mount request.

     USE:  Mount requests.



     7.4  Remark Argument Block


          |                                     |
          |-------------------------------------|
          |      Length      |      .QBRMK      |
          |-------------------------------------|
          |   Pointer (address) to ASCIZ text   |
          |-------------------------------------|
          |                                     |


     USE:  Mount/dismount requests
                                                                    Page 18


     7.5  Track Number Argument Block


          |                                     |
          |-------------------------------------|
          |I|       1        |      .QBTRK      |
          |-------------------------------------|
          |   .QBDR9 (9 trk) or .QBDR7 (7 trk)  |
          |-------------------------------------|
          |                                     |

     This argument block is  to  request  the  number  of  tape  tracks  to
     associate with the request.

     USE:  Tape mount requests



     7.6  Volume List Argument Block


          |                                     |
          |-------------------------------------|
          |     Length       |      .QBOID      |
          |-------------------------------------|
          |    Address of volume names list     |
          |-------------------------------------|
          |                                     |


     USE:  MOUNT requests



     7.7  Volume Set Name Argument Block


          | |
          |-------------------------------------|
          |      Length      |      .QBVSN      |
          |-------------------------------------|
          |   Address of ASCIZ volume set name  |
          |-------------------------------------|
          |                                     |


     USE:  MOUNT requests.
                                                                    Page 19


     8.0  LIMITATIONS


      o  Only one file may be included in a queuing request.  This  one  is
         soluable  by  adding an order dependency to the arguments.  (there
         may already be  some  order  dependencies  in  the  mount/dismount
         function)

      o  There is no method for modification of  queue  requests  with  the
         currently  implemented  QUEUE% JSYS functions.  (jobs can still be
         modified using existing EXEC commands)

      o  There is no  method  to  obtain  information  with  the  currently
         implemented functions.

      o  The maximum size message to be received  from  the  monitor  is  1
         page.   This is a limitation in itself but also causes a "vaguely"
         defined limit to be imposed on the user of the JSYS.




     9.0  IMPLEMENTATION DETAILS

     9.1  Information Flow

     The user process presents a QUEUE% request.  Given  the  request,  the
     monitor  performs  some  basic  checks, repackages the arguments, then
     presents the request to an application process based on  the  function
     type.   If  the user process has not requested a response, the monitor
     would then return processing to the user process.  Otherwise, the user
     process  blocks  waiting  for a response from the application process.
     The application process receives the request as a normal IPCF message,
     performs  the  appropriate  action,  and  then returns a response in a
     normal IPCF message to the monitor if  requested.   The  monitor  then
     places  the response into the user designated area and returns to user
     context.



     9.2  Monitor

     The monitor takes the arguments presented by the  user  and  builds  a
     message  for  the  application process.  It checks the total length of
     the  parameter  block  to  see  if  it  is  a  valid  length,  (header
     information  plus  2 times number of argument blocks).  The header for
     the outgoing parameter block is built.  Then for  each  user  argument
     block, the argument block header is appended to the outgoing parameter
     block, and the value is  placed  immediately  following  the  argument
     block  header.   The  immediate  bit is cleared, and the length of the
     newly built argument block, including header word, is  placed  in  the
     length field of the argument header.  That length is also added to the
     total length of the outgoing parameter block.  The total length of the
     outgoing  parameter  block  is  checked to verify it is within the one
     page  maximum  limit.   If  the  user   requested   a   response   the
                                                                    Page 20


     acknowledgment  requested  flag  in  the  parameter block is set.  The
     outgoing parameter block is then sent as an IPCF message  to  the  PID
     indicated  by  the  function type and the debugging PID flag if set in
     the user's parameter block.   If  it  is  a  queueing  function  or  a
     mount/dismount  function,  it  is  either  sent  to  QUASAR  or to the
     debugging QUASAR if the debug pid flag is set.  If it is  a  write  to
     operator function, it is sent to the ORION pid or debugging ORION pid.
     In any case, the flag indicating the message is from QUEUE% is set  in
     the  PDB.   If the user did not request a response, return immediately
     to user context.  Otherwise, block the user process until  a  response
     is  received.   Upon  receiving  a response message, move the response
     from the message to the response area specified by the user and return
     to user context.



     9.3  ORION

     ORION receives the IPCF message.  First the source of the  message  is
     examined  for  the system code .IPCCG that indicates the source is the
     QUEUE% JSYS.  Then all of the argument block types are altered to  the
     internal  Galaxy  codes for the same argument types.  Then the message
     is returned to normal processing as a WTO/WTOR type message.



     9.4  QUASAR

     QUASAR receives the IPCF message and must immediately detect QUEUE% as
     the  source  of  the  message  since  some of the message types are in
     conflict with normal message types that may  be  received  by  QUASAR.
     Once  that  determination  is made, QUASAR then translates the message
     into a normal short create message which is  then  translated  into  a
     normal create message for processing as a QUEUE request.



     10.0  TESTING

     As part of the development for the QUEUE% JSYS, a test program will be
     developed.   This  program  will emulate EXEC commands to allow all of
     the queueing and mount/dismount functions that are available with  the
     QUEUE%  JSYS.   In  addition, a write to operator command will also be
     implemented.

     Testing will then be accomplished by executing various  commands  with
     this test program.
                                                                    Page 21


     11.0  BUGCHK, BUGINF, AND SYSTEM PROBLEMS TO OPR USING QUEUE%

     Once QUEUE% is established, all that is necessary for  the  QUEUE%  is
     for  the monitor to perform a QUEUE% with both a display type argument
     and a priv.  message text argument block.


                                      NOTE

         In addition, it would be appropriate for the monitor to set an
         additional  flag  in the IP%CFC field in the flags word of the
         packet descriptor block to indicate the message is indeed from
         the monitor and not in behalf of another user.