Trailing-Edge
-
PDP-10 Archives
-
BB-LW55A-BM_1988
-
7-documentation/galaxy.doc
There are 21 other files named galaxy.doc in the archive. Click here to see a list.
DOC file for GALAXY version 6
COPYRIGHT (C), 1988, DIGITAL EQUIPMENT CORPORATION
1.0 SUMMARY
The GALAXY 6 release includes the following:
o Cluster Operator
o Remote Printing
o Unprivileged Operator
Cluster Operator is intended to aid an operator in tasks that
involve more than one node in the cluster. The intent is to
allow an operator to accomplish these tasks from a single node in
the cluster. These tasks include:
o Dismounting a structure that has been mounted on more than
one node in the cluster
o Mounting a structure on a remote node in the cluster
o Setting a structure exclusive
o Obtaining remote GALAXY information
Remote printing is intended to extend printing support to cluster
printers, LAT printers, and DQS printers. Support for TTY:
printers is also included. Unprivileged OPR is intended to give
limited operator privileges to a set of users with the new
semi-opr privilege. This set of users will be able to manipulate
site-selectable devices such as printers or tape drives.
2.0 CLUSTER OPERATOR
Cluster operator is intended to simplify operator activities that
involve more than one node in a cluster. This is possible by
making use of the new GALAXY component NEBULA.
2.1 NEBULA
NEBULA is a message router, passing messages between the local
system and all remote systems in the cluster known to NEBULA.
For each system in the cluster known to NEBULA to be running
DECnet and to be running a release 7 monitor, NEBULA will attempt
to establish DECnet communication to that node using both a
server and client fork. There will be several new OPR commands
Page 2
to query the status of NEBULA's servers and clients as well as to
manipulate them. These new commands will allow an operator to:
o Show the status of each server's and client's DECnet link.
o Show the status of the servers and clients of remote NEBULAs
in the cluster by use of the new OPR /CLUSTER-NODE: switch.
o Enable or disable a client from attempting to establish a
DECnet connection to a server. (This command is useful if it
is known that the system the client is attempting to
establish a connection to does not have cluster GALAXY
running or enabled.
o Enable or disable a client from reporting to the operators
unsuccessful DECnet connection attempts. (This command is
useful if it is known that the system the client is
attempting to establish a connection to is temporarily down.)
2.2 Structure Dismounts
It will now be possible to dismount a structure that has been
mounted by more than one system in the cluster from a single
system. An operator will give the OPR DISMOUNT command. MOUNTR
will determine if the structure has been mounted only locally, or
also remotely. If the structure has been mounted only locally,
then the structure will be dismounted. However, if the structure
is also mounted remotely, then MOUNTR will inform the operator
which systems in the cluster also the structure mounted. The
operator will, at this point, be given the option to proceed with
the dismount or abort the dismount. If the operator indicates
abort, then the dismount request is aborted. On the other hand,
if the operator indicates proceed, then MOUNTR will forward a
dismount request to the remote systems in the cluster that have
the structure mounted. The MOUNTRs of the remote systems will
dismount the structure from their systems. After all the
structures have been dismounted, the local MOUNTR will inform the
operator of this fact. If any errors occur while dismounting the
structure from the remote systems, then the local MOUNTR will
inform the operator of the errors and the systems where the
errors occurred.
2.3 Structure Mounts
It will now be possible to mount a structure on a remote system
in the cluster. This feature is primarily intended for those
cases where a structure dismount is given and then the dismount
is cancelled. If the dismount is given too late, i.e., the
structure has been dismounted from one or more remote systems,
then if desired, the structure can be mounted back on those
Page 3
systems. MOUNTR informs the operator which system or systems the
structure was dismounted from. In addition, the remote mount
request is useful for those cases where a structure set exclusive
has been given and then the structure is set shared. If the
structure has been dismounted from one or more systems in the
cluster, then the structure can be mounted back on those systems.
Again, MOUNTR will inform the operator which systems the
structure was dismounted from.
2.4 Setting Structures Exclusive
It will now be possible to set a structure exclusive from a
single system in the cluster. If an operator attempts to set a
structure exclusive and MOUNTR detects that the structure is in
use by remote systems in the cluster, then it will inform the
operator which systems have mounted the structure. As with
structure dismounts, it will query the operator as to whether to
continue with setting the structure exclusive or not. If the
operator wishes to abort setting the structure exclusive, then
MOUNTR quits its attempt; otherwise it proceeds to forward a
dismount request to the remote systems in the cluster that have
the structure mounted. After all the remote systems have
indicated that the structure has been dismounted, then MOUNTR
sets the structure exclusive and informs the operator of that
fact. Again, as with structure dismounts, if any errors occurred
while dismounting the structure from a remote system, then MOUNTR
informs the operator of the errors and which systems the
structure could not be dismounted from.
2.5 OPR SHOW/CLUSTER-NODE: Command
It will now be possible to obtain SHOW information from remote
systems in the cluster by use of the new /CLUSTER-NODE: switch.
The appropriate SHOW information will be returned from the node
indicated in the /CLUSTER-NODE: switch. The local node name may
be specified, as well as "*", which returns the requested SHOW
information from all nodes in the cluster including the local
node. The SHOW CONTROL-FILE command does not have the
/CLUSTER-NODE: switch due to security considerations and also
the SHOW TIME command does not have the /CLUSTER-NODE: switch.
3.0 REMOTE PRINTING
Remote printing is intended to enhance printing options by
allowing print requests to printers on remote nodes in a cluster,
to LAT printers and to DQS printers. Included in the printing
support is support for TTY: printers.
Page 4
3.1 Cluster Printing
It will now be possible for a user to route a print request to a
remote system in a cluster to be printed by that system's
printer. The user indicates with the EXEC /DESTINATION-NODE:
switch the node where the printer is located and with the EXEC
/UNIT: switch the printer unit number. If the /UNIT: switch is
omitted, then the first available cluster printer is used.
3.2 Lat Printing
It will now be possible for a user to route a print request to a
printer accessed through a LAT port or service on a particular
server. The user may indicate the LAT server where the print
request is to be processed using the EXEC /DESTINATION-NODE:
switch. If the user desires a particular port or service on a
particular server, then the user may use the new EXEC
/REMOTE-PRINTER: switch.
3.3 DQS Printing
It will now be possible for a user to route a print request to a
VMS node to be printed by that node. The user may indicate the
VMS node where the print request is to be processed using the
EXEC /DESTINATION-NODE: switch. If the user desires a
particular VMS queue on a particula VMS node, then the user may
use the new EXEC /REMOTE-PRINTER: switch.
3.4 TTY Printing
It will now be possible for a user to direct a print request to a
TTY: by specifying with the EXEC /UNIT: switch the unit number
that the TTY: printer was started with in OPR.
3.5 OPR Support For Remote Printing
An operator, when starting a printer, will be able to indicate
the type of printer being started. For cluster printers, this
also includes the node where the printer is located and its unit
number. (The unit corresponds to the unit number of the printer
on the remote node.) For LAT printers, this also includes the
server name which accesses the printer and the the service or
port name. For DQS printers, this also includes the VMS node
name of the node which will process the print request and the
name of the DQS queue that the print request will be placed on.
Other OPR commands that have been modified for remote printing
are:
Page 5
o ABORT
o REQUEUE
o ROUTE
o SET
o SHUTDOWN
o STOP
3.6 Support For TTY: Printing
Support for TTY: printing includes both OPR support and site
defined characteristics in LPTSPL.
3.6.1 OPR Support For TTY: Printing
A TTY: printer is started by specifying a unit number with the
/UNIT: switch and specifying the TTY: line number with the
/DEVICE: switch. There is also a /TERMINAL-CHARACTERISTIC:
switch which declares the name of the terminal printer that is
being started. The name is an alphanumeric string of up to six
characters. The terminal name corresponds to a terminal
characteristic block defined in the LPTSPL module LPTUSR. This
characteristic block is defined by the system administrator.
3.6.2 LPTSPL Support For TTY: Printing
LPTUSR.MAC is linked with LPTSPL.MAC and is the site utility
interface to LPTSPL describing the TTY: printers. All site
modifications are made in this module. LPTUSR includes
documentation on how to set up the terminal characteristic data
blocks.
4.0 UNPRILEGED OPR
Currently, a user must have WHEEL or OPERATOR privileges in order
to invoke OPR and not have ORION reject the OPR. OPR and ORION
were implemented in this fashion because of the capability of OPR
to affect other jobs running in the system, for example,
cancelling spool requests, dismounting of structures, and
cancelling tape requests, to name a few. However, not everything
OPR can do changes the state of the system or affects other jobs.
For example, the SHOW command provides information such as the
Page 6
status of request queues and status of devices which is useful to
the user. In this case, the user should be able to run OPR to
obtain this kind of information without having WHEEL or OPERATOR
privileges. A new privilege has been defined which only has the
capability to run OPR and execute certain OPR commands. This OPR
will be a semi-OPR. These commands are strictly for accessing
information and controlling certain devices. The new user
privilege is called SEMI-OPERATOR and will not have any meaning
other than to GALAXY and the EXEC. In order for a user to run
semi-OPR, the user must have the SEMI-OPERATOR privilege enabled
and GALAXY must have this feature enabled. The SEMI-OPERATOR
privilege can be set for a user by a user with WHEEL or OPERATOR
privileges via the EXEC BUILD and ^ECREATE commands. The default
for semi-OPR is disabled. However, there will be two new
privileged OPR commands to enable and disable semi-OPR,
OPR>ENABLE SEMI-OPERATOR and OPR>DISABLE SEMI-OPERATOR. A user
with WHEEL or OPERATOR privileges will still be able to run OPR
and exercise all the OPR commands while the semi-OPR will be
restricted to a subset of OPR commands that manipulate
site-selectable devices and show their status. A new prompt,
SEMI-OPR>, will differentiate the two types of OPRs.
4.1 New OPR Commands To ENABLE And DISABLE SEMI-OPR
Two new OPR commands will be added to enable and disable
semi-OPR:
o OPR>ENABLE SEMI-OPR. This command will allow users with
SEMI-OPERATOR privileges to run OPR.
o OPR>DISABLE SEMI-OPR. This command disallows users with
SEMI-OPERATOR privileges to run OPR.
These two commands are privileged OPR commands and can not be
executed by a semi-OPR.
4.2 EXEC BUILD, ^ECREATE, And INFORMATION DIRECTORY Commands
A user with WHEEL or OPERATOR privileges will be able to execute
the BUILD or ^ECREATE EXEC commands to create or modify
directories with the SEMI-OPERATOR privileges by adding the
SEMI-OPERATOR keyword as one of the subcommands. The EXEC
INFORMATION DIRECTORY command will display the SEMI-OPERATOR
privilege as a parameter of a directory.
Page 7
5.0 NEW GALGEN QUESTIONS
5.1 GALGEN Cluster Operator Options
It will be possible to specify whether the Cluster operator
should be enabled or not. If it is not, then structure mounts
and dismounts, as well as setting structures exclusive, will be
the same as for GALAXY 5. In addition, remote SHOW commands will
not be possible. The default is to have Cluster operator
enabled. Also, there is an option to run NEBULA as a system
process. The default is to run NEBULA as a system process. The
GALGEN questions are:
o Do you want to ENABLE Cluster GALAXY at GALAXY startup?
o Do you wish NEBULA to run as a system process?
5.2 GALGEN Cluster Printer Options
Cluster printing requires a directory that is common to all
systems in a cluster in order to store temporary copies of files
that are not accessible to the node that the print request is
actually printed at. The default logical name for the shared
directory is LPTXFR. However, this logical name can be
re-defined. Cluster printing also requires the new GALAXY
component LISSPL which create inferior forks which act as servers
for remote nodes in a cluster. The default number of servers
started is two. However, it is possible to start from one to
four servers. The GALGEN questions are:
o Cluster LPTSPL shared directory logical name?
o Number of LISSPL server forks?
5.3 GALGEN Questions For Device Manipulation
The system administrator will be able to determine what devices a
semi-OPR can control via GALGEN. GALGEN will have a new set of
questions in regard to the types of devices a semi-OPR can
control. The types of devices are printer, plotter, card reader,
tape drive, card punch, and paper tape punch. The default for
each question is "yes". The questions are:
o Do you want semi-OPR to be able to control the printer?
o Do you want semi-OPR to be able to control the plotter?
Page 8
o Do you want semi-OPR to be able to control the card reader?
o Do you want semi-OPR to be able to control the card punch?
o Do you want semi-OPR to be able to control the paper tape
punch?
o Do you want semi-OPR to be able to control the tape drive?