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.