Trailing-Edge - PDP-10 Archives - cuspjul86upd_bb-jf24a-bb - 10,7/galaxy/galaxy.inf
There are 3 other files named galaxy.inf in the archive. Click here to see a list.

                  Operational and Internal Differences


                           GALAXY v2 to v4.1

      Copyright (C) 1982
      Digital Equipment Corporation, Maynard, Massachusetts, U.S.A.
      This software is furnished under a license and may be  used  and
      copied  only  in  accordance  with the terms of such license and
      with the inclusion of the above copyright notice.  This software
      or  any  other  copies  thereof may not be provided or otherwise
      made available to any other person.  No title to  and  ownership
      of the software is hereby transferred.
      The information in this software is subject  to  change  without
      notice  and  should  not be construed as a commitment by Digital
      Equipment Corporation.
      Digital  assumes no responsibility for the use or reliability of
      its software on equipment which is not supplied by Digital.
GALAXY 4.1                                                        Page 2

      Version 4.1 is the new release of the GALAXY Multistream Batch and
      Spooling   System  for  TOPS-10.   It  contains  mountable  device
      facilities, the ability for a spooler to drive multiple devices, a
      new  operator  interface providing a common command syntax for all
      spoolers, and a new accounting system.  The programs or components
      that make up the TOPS-10 GALAXY system are:
                ACTDAE  Accounting daemon
                BATCON  Batch controller
                CDRIVE  Card reader spooler
                GLXLIB  Sharable GALAXY Object-Time-System
                LPTSPL  Line printer spooler
                MOUNT   User mount-class command entry program
                OPR     Operator interface
                ORION   Operator interface controller
                PLEASE  Operator/User communications program
                PULSAR  Tape label and disk processor
                QUASAR  Queue manager and resource allocator
                QUEUE   User queue-class command entry program
                QMANGR  GALAXY/MPB interface
                SPROUT  Card punch, paper tape punch and plotter spooler
                SPRINT  Card reader interpreter
GALAXY 4.1                                                        Page 3


      1.1  GALAXY Startup Proceedures

      Under GALAXY version 2,  all  components  were  started  up  under
      OPSER.   With  the exception of QUASAR all had to be attached to a
      terminal  because  each  spooler  had  its  own  command  scanner.
      Furthermore,  each spooler was capable of driving only one device.
      Under GALAXY version 4.1, all components except for  the  operator
      interface  program  (OPR)  can  run  detached.   No  spoolers have
      command scanners and all may drive  multiple  devices.   A  GALAXY
      system   may   still   be  started  up  under  OPSER,  but  it  is
      counterproductive to tie up a terminal and several PTYs to control
      programs that will never type out messages or accept commands from
      the operator.  The recommended method  of  starting  up  a  GALAXY
      system  is  by  using  INITIA.   When  INITIA runs from the CTY at
      system startup, it takes its commands from SYS:SYSJOB.INI.

      Starting programs with SYSJOB has several  advantages  over  using
      OPSER.  First, SYSJOB offers extremley fast startup time.  Second,
      the SYSJOB mechanism allows programs that are critical  to  system
      operation  to get started well before all others.  When SYSJOB.INI
      is processed, LOGIN commands do not run the LOGIN CUSP.   Instead,
      the  monitor will log the job in to [1,2] in the same way that the
      CTY has the option of logging in following a disk  refresh  during
      the  ONCE  dialogue.   The  monitor  will set the PPN to [1,2] and
      assign all DEC privileges.  The job's search list  remains  empty.
      When  a program name is encountered in SYSJOB.INI, that program is
      run from SYS:.  Once the program starts up, it must detach  itself
      immediately  and  another  line  from  SYSJOB.INI is processed.  A
      sample SYSJOB.INI file would look like:
      Each pair of commands  will  LOGIN  a  job  and  run  the  program
      specified  by  the second word in the pair of commands.  First the
      accounting daemon (ACTDAE) starts  up  and  detaches  followed  by
      DAEMON and the FILDAE.  The order of these programs starting up is
      not critical unless accounting is of major importance.  The GALAXY
GALAXY 4.1                                                        Page 4
GALAXY Startup Procedures

      jobs  follow,  each  logging in and detaching.  Spoolers should be
      started after QUASAR starts.
GALAXY 4.1                                                        Page 5

      1.2  Accounting

      The Usage Accounting System  consists  of  the  accounting  daemon
      (ACTDAE)  and  the  programs that interface to it.  Those programs
      include  all  GALAXY  components  that  create  Usage   Accounting
      entries, LOGIN, BACKUP plus the LOGOUT and QUEUE.  UUOs.  All data
      concerning Usage Accounting resides on ersatz device  ACT:.   With
      this  new  style of accounting, a site has the option of requiring
      account string validation.  This feature insures that the  account
      string  selected for use by the user is valid and is stored in all
      accounting entries created for that user.  The GALAXY system  will
      perform  account  validation  prior to processing any output queue
      requests.  Validation is not done for batch  jobs  until  the  job
      starts to run because the LOGIN process will take care of it.

      Specific information relating to the content of  Usage  Accounting
      files   is  available  in  the  TOPS-10/TOPS-20  Usage  Accounting

      1.2.1  Account String Validation - Account  validation  refers  to
      the  function  performed  by  LOGIN  and various GALAXY components
      whereby the ACTDAE is asked to verify that  a  particular  account
      string  is  legal  for  a  user.  For example, a user might try to
      print a file with an account string different from the one  he  or
      she  logged  in  with.  Obviously, the logged in account string is
      legal, because LOGIN set it, but the one specified  on  the  PRINT
      command  may  not  be legal.  Prior to creating the queue request,
      the ACTDAE is queried regarding the validity of the account string
      for the user.  If the string is legal, then the queue request gets
      created normally.  If however, the string  is  illegal,  an  error
      message  will  be  printed  on the user's terminal and the request
      will not be created.  Whether or not  the  account  validation  is
      required  is determined by the setting of a bit in the monitor.  A
      site may chose not to have account validation by answering 'NO' to
      the  MONGEN  dialogue  question  'Account verification(Y,N)'.   In
      addition, at system  startup,  the  /NOVALIDATION  switch  may  be
      appended to any answer to the question 'Startup option:'.

      1.2.2  Setting Up Account Strings - All work performed for a  user
      by GALAXY gets charged to an account.  The Usage Accounting system
      uses an account string of 1 to 39  ASCII  characters  to  uniquely
      identify a user or group of users and the work that was charged to
      them.  Account strings are not stored in ACCT.SYS with the rest of
      a  user's  accounting  profile,  because  a  user may have several
      account strings.  The mapping of a PPN to  an  account  string  is
      done by the PROJCT program using input from PROJCT.ACT.  This file
      contains text that may be edited using any text editor.  Each line
      in PROJCT.ACT maps a single PPN or wildcarded PPN to a list of one
      or more account strings.  The format is:
GALAXY 4.1                                                        Page 6

                proj,prog = string1/switch, string2, ...
      where  'proj'  and  'prog'  can  be possibly wildcarded values.  A
      question mark (?) indicates a wild digit and  an  asterisk  (*)  a
      wild  value.   Each  string  following  the equal sign may contain
      wildcards as well.  Again, the  question  mark  indicates  a  wild
      character  and an asterisk a wild string or remainder of a string.
      An optional switch /DEFAULT may  be  appended  to  the  end  of  a
      string.   This  means  that  if a user fails to specify an account
      string,  this  one  will  be  the  default.   Typical  entries  in
      PROJCT.ACT might look like this:
      In the above examples, user [10,56] has two account  strings,  one
      upper  cased  named  'GALAXY-10'  and one lower cased 'galaxy-10'.
      User [10,3076] has four valid account  strings.   'CHUCK'  is  the
      default  account  string  when a string isn't specified and string
      beginning with 'G' or matching the pattern  'H<single-character>H'
      at  the  begining  of  a  string will be legal.  The third example
      indicates that  any  project  10  PPN  not  already  specified  in
      PROJCT.ACT  may  have  any  account  string.  User [27,5434] has a
      single account string named 'WRITER'.

      Note that by default, case is  significant.   The  ACTDAE  can  be
      reassembled  so  that it will convert all account strings to upper
      case before performing  any  validation.   This  may  be  done  by
      setting FTCASECONVERT to be non-zero in ACTDAE.MAC.

      Once the system administrator has created PROJCT.ACT,  the  PROJCT
      program  must  be  run.  It will translate PROJCT.ACT, a text file
      into PROJCT.SYS, a binary file suitable for input to the ACTDAE.

      1.2.3  Setting Account Strings For Jobs Created By SYSJOB.INI - If
      a  site  maintains  detailed  accounting records for operator jobs
      such as the GALAXY components, DAEMON, FILDAE, etc.,  then  it  is
      necessary to set an account string for jobs created by SYSJOB.INI.
      Normally LOGIN would set the account  string,  but  SYSJOB-created
      jobs are special.  The monitor logs in these jobs and bypasses the
      standard LOGIN process.  To get around  the  lack  of  an  account
      string,  the command 'SET DEFAULT ACCOUNT xxx' may be added to the
      beginning of SYSJOB.INI.  This will cause all jobs  logged  in  by
      the monitor to have account 'xxx' set for them.
GALAXY 4.1                                                        Page 7

      1.2.4  Remark Strings - The Usage Accounting System allows  remark
      text  to be specified at LOGIN time by a user.  A remark is a text
      string of 1 to 39 ASCII characters and may contain any information
      a  user  decides  to  type  in.   This text is stored in the Usage
      Accounting files and is never used internally by  the  monitor  or
      any program.

      1.2.5  Usage Files Produced By ACTDAE - The   accounting    daemon
      writes  ASCII Usage data into ACT:USAGE.OUT.  The operator has two
      options available through the OPR program  for  dealing  with  the
      ACTDAE output.  One OPR command 'SET USAGE BILLING-CLOSURE' causes
      ACTDAE to close ACT:USAGE.OUT at the specified time and rename  it
      to  on  a  daily  basis.   'yymmdd' represents the
      numeric year, month, and day that the file was  closed  and  'hhu'
      the  number  of  hours plus the fraction of an hour past midnight.
      Another OPR command, 'SET USAGE FILE-CLOSURE' will  direct  ACTDAE
      to checkpoint ACT:USAGE.OUT at the specified interval.

      1.2.6  FACT File Accounting - To ease the conversion  from  GALAXY
      version  2  to  4.1 and from FACT file to Usage Accounting, GALAXY
      components  will  produce  both  FACT  file  entries   and   Usage
      Accounting  records.   As  another  aid  to  help  the  conversion
      process, the CONV10 program will convert Usage Accounting files to
      FACT  file  formatted  files.   Future  GALAXY  releases  will not
      support FACT file accounting.  FACT file accounting may be  turned
      off should a site not wish to use two types of accounting systems.
GALAXY 4.1                                                        Page 8
Master Queue File Changes

      1.3  Master Queue File Changes

      The format of the Master Queue File has changed since  version  2.
      If  a  site  anticipates  experimenting  with version 4.1 and then
      dropping back to version 2, then one of two things should be done:
      1.   Copies  of each queue file will have to be saved and switched
      back and forth to coincide with the matching  version  of  QUASAR.
      This  method  could  prove  rather cumbersome.  2.  An alternative
      would be to convert the queue file from version 2 to  4.1  or  the
      other way around.  A conversion program (QSRCVT) is supplied as an
      unsupported tool to help any  site  that  might  want  to  attempt
      converting the queue files.
GALAXY 4.1                                                        Page 9
Operator Interface

      1.4  Operator Interface

      The new operator interface acts as  the  command  parser  for  all
      spoolers.  It consists of two parts.  The first is the OPR program
      which parses commands typed by  the  operator  and  displays  text
      generated  by  the  GALAXY  system.   The second part is the ORION
      program.  It is the operator controller  responsible  for  logging
      and  routing messages sent to and from each OPR.  The 4.1 operator
      interface is the same  one  released  with  GALAXY  version  4  on
      TOPS-20, but with TOPS-10 specific features added to it.

      In order to run OPR, a user must have Operator Privileges  granted
      to it by LOGIN.  These privilege bits are stored in ACCT.SYS using
      the REACT program.  There are three classes of operators;  SYSTEM,
      HOST  and  REMOTE.  Each type of operator privilege indicates what
      system devices may be controlled by a particular operator.   Being
      a  SYSTEM operator allows a user to control devices and batch jobs
      on all nodes in the system, process mount  requests,  and  perform
      various  SET  commands  that  affect  the  operation of the entire
      system.  A HOST operator may control  devices  and  batch  streams
      only  at  the  host  node  in a system.  REMOTE operators may only
      affect the operation of devices and batch streams  on  the  remote
      node  they  are  physically  connected  to.   In  keeping with the
      TOPS-10 philosophy that a [1,2]  PPN  affords  a  user  full  file
      access  and  the ability to read or set any system-wide parameter,
      [1,2] jobs are always allowed to run OPR with full SYSTEM operator
GALAXY 4.1                                                       Page 10
Crash Recovery Procedures

      1.5  Crash Recovery Procedures

      In the unlikely event that a GALAXY component crashes, the  method
      of  recovering  from  the  crash  will  vary  depending  upon  the
      component  in  question.   When  a  GALAXY  component  crashes  or
      stopcodes,  part  of  the  stopcode procedure attempts to save the
      state of the program for later examination by a system programmer.
      After  doing that, the stopcode processor sends a message to ORION
      (and hence to all OPRs) telling the world that a GALAXY  component
      has  crashed.  A portion of the stopcode text follows.  Except for
      the program and stopcode name,  most  of  the  information  is  of
      little  interest  to  an operations staff, but is important to the
      system programmer who will most likely want to examine the crash.
                          --  OPR terminated  --
                        job 35 [1,2] OPR    at terminal 51
        ?Stopcode - ILM - in module GLXINT on 22-Mar-82 on  4:58:50
         Reason: Illegal memory reference at PC 5064
         Program is OPR version 4(407) using GLXLIB version 1(1124)
         Crash block starts at location 674000
         Last GLXLIB error: 104 (No timer entry has expired)
      When an operator notices that  a  GALAXY  component  has  crashed,
      normal  procedure  should  require  him  or  her  to attach to the
      terminated program  and  issue  the  monitor  SAVE  command.   The
      component  should be saved with a filename like OPRxxx where 'OPR'
      indicates the OPR program and 'xxx' is  the  stopcode  name.   The
      component  should  then  be  restarted  and  a  system  programmer
      notified of the GALAXY failure.  Repeated  crashes  indicate  that
      something  is  drastically  wrong  with  the  GALAXY system and it
      should be given immediate attention.

      1.5.1  QUASAR - QUASAR is by far the most important  component  in
      the GALAXY system.  When QUASAR crashes, all other components must
      be restarted.  The order in which  the  components  get  restarted
      should  be  the same as was the case at system startup.  There are
      no restrictions governing how the GALAXY  system  gets  restarted.
      Jobs  may  be logged in under OPSER and later detached, or started
      one at a time on a terminal and then detaching them.

      1.5.2  ORION - If ORION crashes, it should  be  restarted  in  the
      same  job  slot  if possible.  This way, only the OPR jobs have to
      re-initiate communications with the restarted ORION.  OPR will  do
      that automatically when the first command is typed after the ORION
      restart.  If the same job slot cannot  be  used  for  some  reason
      (maybe  the operator logged the job out), then QUASAR will need to
      be restarted.  This implies the entire GALAXY system needs  to  be
GALAXY 4.1                                                       Page 11
Crash Recovery Procedures

      1.5.3  PULSAR - As in ORION's case, PULSAR should be restarted  in
      the  same  job slot if possible.  Otherwise, QUASAR and the entire
      GALAXY system  will  have  to  be  restarted.   When  PULSAR  gets
      restarted  in  the  same  job  slot, any users of labeled magtapes
      could have their jobs hang indefinitely if PULSAR  was  performing
      tape label processing at the time.  The jobs will show up as being
      in event wait for the tape labeler.  Users who find themselves  in
      this  state  will have to control-C out of their program, dismount
      their tape and mount  it  again.   If  PULSAR  was  processing  an
      operator  or  QUASAR  request  to mount a structure, a SHOW STATUS
      STRUCTURE  command  to  OPR  will  show   the   disk   status   as
      --Mounting--.  When this happens, typing the OPR RECOGNIZE command
      for the disk units that make up the structure will  usually  clear
      up  the  problem.   The  problem  gets a bit messy when PULSAR was
      processing an operator or QUASAR request to dismount a  structure.
      Typically,  the structure status is left as --Dismounting--.  This
      means QUASAR is waiting  for  the  dismount  to  be  completed  by
      PULSAR.   Usually,  the structure is still mounted and there is no
      combination of OPR commands that will cause QUASAR  or  PULSAR  to
      exit  this  state.   The  only method of getting QUASAR's database
      back to normal will be to run the old OMOUNT CUSP and dismount the
      structure with it.  QUASAR will now be satisfied because it wanted
      the structure dismounted, and normal operations may proceed.

      1.5.4  BATCON - BATCON  crashes  not   only   affect   the   batch
      controller,  but  cause  all  jobs  controlled  by  BATCON  to  be
      detached.  It is important to remember that, prior to restarting a
      new BATCON, the now detached batch jobs should be killed.

      1.5.5  SPRINT - SPRINT is a unique spooler in  that  it  gets  its
      jobs from a queue that the operator cannot control.  SPRINT has no
      START, STOP, and ABORT commands.  If a damaged queue request finds
      its  way  to SPRINT and causes SPRINT to crash, restarting it will
      only  produce  another  crash.   This   is   because   SPRINT   is
      automatically  started  by  QUASAR  at GALAXY startup.  As soon as
      SPRINT notifies QUASAR that it is ready to process a  job,  QUASAR
      sends it the first job in the queue.  because the previous job was
      never completed (it crashed SPRINT), it will  be  sent  to  SPRINT
      again  for  processing.   It  is  impossible  to cancel a job from
      SPRINT's queue because of the nature of the queue and the spooler.
      If  a  site  experiences  this  type of crash, a system programmer
      should be contacted immediately.
GALAXY 4.1                                                       Page 12
Crash Recovery Procedures

      1.5.6  Other Spoolers - When  a  spooler  like  LPTSPL  or  SPROUT
      crashes,  any  jobs  currently  being  processed  will  have to be
      restarted.  No other component should be affected  by  the  crash.
      Jobs  will normally be restarted at the last known checkpoint sent
      to QUASAR by the spooler.

      1.5.7  OPR - An OPR crash is the simplest  one  to  recover  from.
      Since  OPR  only  communicates  with ORION, it directly affects no
      spooler, QUASAR or PULSAR.  OPR can be restarted in any  job  slot
      without affecting the running GALAXY system.
GALAXY 4.1                                                       Page 13


      This section briefly describes some of the internal changes new to
      GALAXY  4.1.   One  noticable difference between version 2 and 4.1
      will be the increased IPCF traffic on the system.  This should not
      pose any problem, in most cases, but it is important to understand
      why the amount of IPCF activity has  increased  greatly  and  what
      could  be  done  to  alleviate problems should they arise (section
      2.1).  Both QUASAR and BATCON have changed greatly since the  last
      release of the product, so a description of each follows (sections
      2.2 and 2.3).  PULSAR is new with 4.1 and some insight into how it
      works is discussed (section 2.4).
GALAXY 4.1                                                       Page 14
IPCF Message Flow


      With GALAXY 4.1, there is a common operator interface (OPR) and an
      operator interface controller (ORION).  No spoolers have a command
      scanner.  Under GALAXY version 2, a command to LPTSPL (like PAUSE)
      involved no other GALAXY components.  With 4.1, the equivalent OPR
      command (STOP) causes a message to be sent to ORION.  The  message
      is  logged  in the operator log file and is then passed to QUASAR.
      QUASAR determines which LPTSPL job is driving  he  printer  to  be
      stopped  and  sends  the  message to that job.  After stopping the
      printer, LPTSPL then sends an acknowledgement (ACK) to  ORION  who
      logs  it  and  routes  the  ACK  back to the correct OPR.  In this
      example, a simple command has generated five IPCF messages.

      If excessive IPCF traffic is already causing problems,  then  some
      local  modifications  to  IPCF message handling might be in order.
      Experiments in-house and at one field test site indicate that  the
      average  size  of an IPCF message is between 25 and 35 words long.
      TOPS-10 can process packet-mode transfers  faster  than  page-mode
      IPCF  messages.   A  site may experiment by increasing the maximum
      size of a packet-mode send (location %CNIPL in COMMON).  This  can
      be done while the monitor is running.

      2.2  QUASAR

      QUASAR manages queues and allocates resources.  It  comprises  one
      half  of  MDA.  It processes all operator commands and directs the
      spoolers and PULSAR to do the bulk  of  the  work  in  the  GALAXY
      system.   All  user QUEUE and MOUNT class commands and QUEUE.  UUO
      functions go to QUASAR for processing.  In addition, it interfaces
      to  the  accounting  system  when  making  accounting  entries  or
      requesting account string validation.  Its role as a queue manager
      has  changed  little  since  the  days of version 2.  What is new,
      however, is the addition of the mountable device facilities.   MDA
      (Mountable Device Architecture) is designed around the belief that
      a user will require a group of  mountable  devices  to  perform  a
      task, but that these devices will not necessarily be needed all at

      2.2.1  MDA Data Structures - The MDA database consists of a series
      of data blocks linked together in such a way as to allow ownership
      (or allocation) of resources to be traced from a  job  number  (or
      request-id)  to  each physical tape or disk drive, or given a tape
      volume or disk  unit,  find  all  jobs  (or  requests)  owning  or
      allocating the particular resource.  A partial map of the database
      follows.  The portions of  the  MDA  database  described  in  this
      section  are  all  dynamically  allocated and configured when jobs
      LOGIN or LOGOUT, batch jobs get put  into  or  taken  out  of  the
GALAXY 4.1                                                       Page 15

      queue, and when users request or give up resources.
                +-----+                 +-----+
                |     |                 |     |
         MDR    | MDR |<--------------->| MDR |
        Chain   |     |                 |     |
                +-----+                 +-----+
                /|\  /|\                  /|\
                 |    |                    |
                 |    |                    |
                 |    +---------------+    +-------------------+
                 |                    |                        |
                \|/                  \|/                      \|/
                +-----+              +-----+                 +-----+
                |     |              |     |                 |     |
         VSL    | VSL |<------------>| VSL |<--------------->| VSL |
        Chain   |     |              |     |                 |     |
                +-----+              +-----+                 +-----+
                /|\  /|\            /|\  /|\                /|\
                 |    |              |    |                  |
                 |    |              |    |                  |
                 |    |              |    |                  |          
                 |    +----------+   |    +-------------+    +--------+
                 |               |   |                  |             |
                 |               |   +-----------+      +--------+    |
                 |               |               |               |    |
                \|/             \|/             \|/             \|/  \|/
                +-----+         +-----+         +-----+         +-----+
                |     |         |     |         |     |         |     |
         VOL    | VOL |         | VOL |         | VOL |         | VOL |
        Chain   |  1  |<------->|  2  |<------->|  3  |<------->|  4  |
                |     |         |     |         |     |         |     |
                +-----+         +-----+         +-----+         +-----+
                                /|\             /|\             /|\
                                 |               |               |
                     +-----------+   +-----------+   +-----------+
                     |               |               |
                     |               |               |
                     |               |               |
                    \|/             \|/             \|/
                +-----+         +-----+         +-----+         +-----+
                |     |         |     |         |     |         |     |
         UCB    | MTA |         | MTA |         | MTB |         | MTB |
        Chain   |  0  |<------->|  1  |<------->|  0  |<------->|  1  |
                |     |         |     |         |     |         |     |
                +-----+         +-----+         +-----+         +-----+
        MDR = Mountable Device Request blocks
        VSL = Volume Set List blocks
        VOL = Volume blocks
        UCB = Unit Control Blocks
GALAXY 4.1                                                       Page 16
QUASAR  Mountable Device Request Blocks (MDR) - The    MDR     is
      highest  level  in  the  MDA  database architecture.  One MDR gets
      created whenever a job  logs  in  or  a  batch  queue  request  is
      created.   The  MDR  points  to  a  list  of  allocated or mounted
      resources.  The MDR contains information such as job number,  user
      name,  PPN,  address  of  associated  batch  queue  entry, account
      string, information for  queue  notification,  and  at  least  one
      pointer to a Volume Set List.  Volume Set List Blocks (VSL) - The Volume Set List is the
      data  block that describes the characteristics of a volume set.  A
      VSL gets created every time a user issues a new ALLOCATE or  MOUNT
      command.   It  contains  a  backwards link to the controlling MDR.
      VSLs exist for both tape and disks and contain nearly all  of  the
      data  specified by a user's ALLOCATE or MOUNT command.  Additional
      information is kept about the volume set itself  (tape  protection
      codes,  densities,  track status, etc.).  Associated with a VSL is
      an ASCIZ volume-set name.  This is the name specified in a  user's
      ALLOCATE  or MOUNT command.  ACK text will be stored in the VSL if
      PULSAR returns ASCIZ text in  response  to  a  mount  or  dismount
      message  from  QUASAR.   There  exist pointers to all volumes that
      make up a VSL.  For example, there will be three pointers  in  the
      VSL to volume blocks in a three tape volume set.  Volume Blocks (VOL) - The    volume    block     contains
      information   relating   to   specific  volumes  that  make  up  a
      volume-set.  REELIDs, unit IDs, owner PPNs,  volume  status,  etc.
      which  make  up  the content of several displays (SHOW STATUS DISK
      and TAPE) are stored in the VOL blocks.  The  VOL  blocks  contain
      back  pointers  to  the VSLs that point to them.  Several VSLs may
      point to a single VOL block.  If a volume  is  currently  mounted,
      the VOL will point to a physical unit block (UCB).  Unit Control Blocks (UCB) - The Unit Control Block is the
      lowest level data block in the MDA architecture.  UCBs contain the
      physical device names and alternate port names of devices,  device
      types  and characteristics, and mount counts.  Back pointers exist
      to the controlling VOL and VSL blocks.
GALAXY 4.1                                                       Page 17

      2.3  PULSAR

      PULSAR is the other half of MDA, and is the tape  label  and  disk
      processor  for  the  GALAXY  system.  As the tape label processor,
      PULSAR  is  responsible  for  the  initialization  of  tapes   and
      verifying  tape  read/write  access  and volume switching.  As the
      disk processor, it reads HOM blocks, performs  structure  mounting
      and  dismounting,  manipulates  UFDs  and  job  search  lists, and
      modifies  system  search  lists,  crash  dump  lists,  and  active
      swapping lists.

      2.3.1  Tape Initialization - Tape initialization is the process of
      writing  tape  labels  on a new volume set.  A tape volume set can
      consist of one to sixty tapes.  PULSAR's  initialization  code  is
      invoked  by  the OPR 'SET TAPE MTAx: INITIALIZE' command.  Through
      the use of switches to the command, various label  parameters  may
      be set.  These include:
                o       Density
                o       Label type
                o       Owner PPN
                o       Volume-set protection code
                o       Volume ID
      Omission  of  some  switches  is  allowed,  because  it may not be
      required for a particular parameter to be set (e.g.  owner PPN  or
      protection  code).   Some  switches  can  be  omitted  because the
      information is not required.  However, some  information  such  as
      volume  identification  must  be  supplied.   PULSAR  will  always
      attempt to read tape expiration dates prior to initializing a tape
      to insure valid data will not be overwritten.  This can pose minor
      problems if the tape is a virgin tape.  The tape will 'run  away':
      the  tape  controller  will  select  the drive and try to read the
      tape.  Because no data is available, it keeps trying to  read  for
      several  seconds.   During  this  time, the tape is kept spinning.
      Eventually, the controller gives  up  and  generates  an  off-line
      interrupt.   This  behavior  is normal for virgin tapes.  It is an
      aspect of the tape controller and cannot be programmed  around  by
      the  monitor  or  PULSAR.  To avoid this, the /OVERRIDE-EXPIRATION
      switch should be appended to the tape  initialize  command.   When
      this  switch is used, PULSAR will not make any attempt to read the
      expiration date.

      2.3.2  Tape I/O And Positioning - When using labeled tapes, PULSAR
      will  be  called  on  first  input  or  output  operations, and on
      positioning requests.  All types of I/O and tape  positioning  are
      legal  for labeled tapes except for read-backwards.  In this mode,
      buffers get filled backwards.   PULSAR  has  no  code  to  support
      reading label data in this way.
GALAXY 4.1                                                       Page 18

      ANSI standards do not support labeled  7-track  tapes.   MDA  does
      support ANSI standards, but will not prevent a user from writing a
      7-track labeled tape.  The only restriction is that the tape  will
      be readable only on another DECsystem-10 running MDA.  The code in
      PULSAR appears to work properly, though we have not done extensive
      testing  with  it  and make no claims that any deficiencies in the
      label code will be corrected for 7-track tapes.

      2.3.3  Tape Volume Switching - Volume switching occurs when end of
      tape  is encountered on a tape with a label type of NOLABELS, ANSI
      or EBCDIC.  The user's  program  never  sees  EOT.   Instead,  the
      monitor  notifies  PULSAR (via IPCF) of the EOT condition.  PULSAR
      writes the end of volume  records,  rewinds  the  tape,  and  asks
      QUASAR  for  the  next  tape  in  the  volume  set.   QUASAR  will
      determine, based on information supplied in  the  user's  original
      MOUNT  request, which tape should be assigned to the user.  It may
      be necessary for the operator to initialize a new tape to extend a
      volume  set  that is in the process of being written.  Eventually,
      QUASAR will inform PULSAR of the new tape (and possible  new  tape
      drive) to use.

      2.3.4  Forcing End Of Volume Processing - If USER-EOT  labels  are
      used,  a  program  (such  as  BACKUP)  can  force  end  of  volume
      processing to occur with a TAPOP.  UUO (function .TFFEV).  This is
      a useful feature because some programs need to write their own end
      of volume records at the end of the tape.  Forcing end  of  volume
      processing  will  cause  another tape to be assigned to the user's
      job using the same logic that exists for labeled tape processing.

      2.3.5  User/Monitor/PULSAR Interface - PULSAR may be invoked by  a
      user  attempting  to do I/O, position a labeled tape or by forcing
      end of volume processing.  Every time PULSAR intervenes in  behalf
      of  a user or monitor request, the user's job is put into an event
      wait state.  PULSAR does all of the  label  processing  while  the
      user's  job  is  suspended.   In  order  for  PULSAR  to do I/O or
      position the same tape owned by the user's job, a Label  DDB  must
      be  created.   PULSAR  does  this  with  a  TAPOP.   UUO (function
      .TFLBG).  This new Label DDB is linked to the original magtape DDB
      and  the  TUB.  PULSAR will perform all I/O and positioning on the
      Label DDB.  When label processing is completed, the user's job  is
      gotten  out  of  event  wait  when  PULSAR  does  a TAPOP.  .TFLRL
      function which releases the user's job.  One of the  arguments  to
      the  label  release function is an error code to set.  PULSAR will
      set  an  error  code  whenever  something  failed   during   label
      processing.   The  user's  program  will either see the error as a
      TAPOP.  UUO failure (in the case of a positioning request)  or  an
      I/O error.  Label I/O errors will return all I/O error bits when a
      GETSTS is done.  When this  happens,  a  program  should  issue  a
GALAXY 4.1                                                       Page 19

      TAPOP.   UUO  (function  .TFLTC)  to read the extended error code.
      Normal I/O or tape positioning will not be allowed to continue  on
      that device until the errors have been cleared by the program.

      2.3.6  Disk HOM Block Reading - PULSAR will be called by QUASAR to
      read  disk  HOM blocks whenever a disk on-line interrupt occurs or
      the  operator  issues  a  RECOGNIZE  command.   The  procedure  is
      straight-forward.   PULSAR  will extract all information necessary
      to mount the structure that the disk unit belongs to,  and  return
      that  information  to  QUASAR.   The HOM block data of interest to
      QUASAR includes:
                o       Unit ID
                o       Next unit in structure
                o       Logical unit in structure
                o       Structure name
                o       Owner PPN
                o       Hardware-write-protect status
      QUASAR will use this data  (and  possibly  data  from  other  disk
      units)  to  decide  when all the required units of a structure are
      available.   Determining  the  hardware-write-protect  status  has
      proven to be a rather awkward task.  Some disk controllers are not
      capable of telling the monitor the write-protect status.   To  get
      around  the hardware deficiencies, PULSAR must try to write to the
      disk.     A    failure    indicates    that    the     unit     is

      2.3.7  Structure Mounting - When QUASAR determines  that  all  the
      required  units of a structure are available, it directs PULSAR to
      mount the structure.  The IPCF message from QUASAR  includes  much
      of  the  same  information PULSAR had supplied to QUASAR when each
      disk unit's HOM blocks were originally read.  In addition, if  the
      operator  asked  to  have  the structure mounted with a name other
      than the one written into the HOM blocks (alias name),  the  alias
      name  is  included  in  the  message.  During the mounting process
      (while filling the structure data block) PULSAR will  compare  the
      owner PPN from the HOM blocks with the one supplied by QUASAR.  If
      there is a mismatch, the operator is informed of the  discrepency.
      The owner PPN is then cleared in the structure data block to avoid
      the possibility if any security problems that could arise from the
      wrong owner PPN being set up.
GALAXY 4.1                                                       Page 20

      2.3.8  Structure Dismounting - At the  request  of  the  operator,
      through the use of an OPR DISMOUNT or LOCK command, PULSAR will be
      directed  to  dismount  a  structure.   Part  of  this  processing
      involves  the  checking  of  several  conditions  that could cause
      operational difficulties, GALAXY failure or system failures should
      a  structure  be dismounted.  Checks are made for a structure that
                o       In the system search list
                o       Containing the queues
                o       Containing a system catalog (STRLST.SYS)
                o       Being in the crash dump list
                o       Containing a KL10 front-end file system
                o       Containing a KS10 front-end file system
                o       Mount count being non-zero
                o       Number of queue requests being non-zero
                o       Having units in active swapping list
      Before the structure is dismounted, if any checks detect potential
      problems, the operator will be notified of the conflict and  asked
      to abort or proceed with the structure removal.

      2.3.9  UFD And Job Search List Handling - When  users   mount   or
      dismount  structures,  PULSAR  gets  called by QUASAR to create or
      delete UFDs and manipulate job search lists.   There  is  actually
      very  little  code  in  PULSAR  proper  to deal with these things.
      PULSAR is loaded with the UFDSET subroutine package.  UFDSET is  a
      self  contained  package of routines written explicitly for use by
      LOGIN and PULSAR to process all types of UFD operations.   It  can
      easily  be  interfaced  to  any  program  wanting  to  do  mounts,
      dismounts and disk recomputation for any job or UFD.  In  addition
      it  will  add  or  remove  structures from the system search list.
      PULSAR has about a page or so of UFDSET interface code to  set  up
      the  argument block and process text messages generated by UFDSET.
      All informational, warning and fatal messages produced  by  UFDSET
      are  passed back to the user as part of the mount or dismount ACK.
      Fatal messages are checked against a  list  of  error  codes  that
      indicate  possible  monitor or GALAXY system failures.  Should one
      of these errors occur, the operator will be notified.
GALAXY 4.1                                                       Page 21

      2.4  BATCON

      Internally,  the  batch  controller  (BATCON)  has  been   changed
      extensively.   This caused no compatibility problems with existing
      control files.  First, Full SCNSER PTYs are used.   This  type  of
      PTY  is  unique in that it is an echoing PTY.  All of BATCON's PTY
      logic and a large part of the log file logic had to  be  rewritten
      to  accomodate  the  new  type of PTYs.  The result of this change
      shows up  mostly  in  the  log  files  (line  identifiers,  etc.).
      Second, the operator interface was completely rewritten.  This was
      done to provide more informative  and  friendly  messages  to  the
      operator  as  well  as  better response during command processing.
      The  third  major  change  involved  the  implementation  of   the
      MDA/batch  interface.   This interface, known as batch prescanning
      (or preprocessing) provides a mechanism for  QUASAR  to  determine
      the  resource  requirements of a batch job.  When a user submits a
      control file, the request is put into the  input  queue,  but  not
      considered   for   scheduling   until   the   request's   resource
      requirements are known.  BATCON is directed by QUASAR  to  prescan
      the control file for a special header block at the begining of the
      file.  This block, known as the step header, may contain  ALLOCATE
      and  MOUNT  commands identical to those used by timesharing users.
      If one or more  commands  are  found,  they  are  parsed  and  the
      allocation  or  mount request information is passed back to QUASAR
      for use during the batch job scheduling process.  For the sake  of
      compatibility, the step header block is optional and users are not
      required to put one in their control files.
GALAXY 4.1                                                       Page 22
Making Local Modifications


      In general, sites will find it easier to make local  modifications
      to  GALAXY  4.1  than  to version 2.  Once familiar with the code,
      changes to spoolers should pose no problems.  The code in  QUASAR,
      PULSAR and ORION however is a bit more complex.

      2.5.1  QUASAR - The overall  size  and  complexity  of  QUASAR  is
      overwhelming,  especially  the  MDA  code.   But if each module or
      function is viewed as a separate entity it is not nearly  so  bad.
      The bulk of QUASAR's duties revolve around queue management.  Some
      of the more popular queues are:
                o       INP     Input
                o       LPT     Line printer
                o       PTP     Paper tape punch
                o       CDP     Card punch
                o       PLT     Plotter
      QUASAR has many queues most people are not aware of.  Some are:
                o       BIN     SPRINT
                o       DBM     DBMS journaling
                o       RDR     Card reader
                o       SPL     Spooled file deletion
                o       PSB     Processor status block
                o       OBJ     Object (INP, LPT, PTP, etc.)
                o       USE     Jobs in use
                o       STR     Structure
                o       NET     Network
      Many sites will find it necessary to add queues of their own.  Due
      to the amount of functionality and flexibility of QUASAR, creating
      a  new queue involves more than adding an entry to a macro or two.
      Some queues are actually related to some spooling  action  (LPTSPL
      gets jobs from the LPT queue).  Some queues may be displayed (LPT)
      while others are invisible (PSB).  Some queues are  of  the  input
      variety  (INP  and  BIN)  while  others  are output related (PLT).
      Another category is the free running queue.  These queues  require
      no operator interaction and are automatically started by QUASAR at
      GALAXY startup time.  DBMS queue is one of these.

      The following steps are needed to add a new queue to QUASAR:

      Assume a site has  a  XEROX  9700  or  similar  unit,  capable  of
      reproducing  printed  text  directly  from a magtape.  Users would
      want the queued files to be printed on the XEROX machine and to be
      able  to  examine the queues at any time.  Operators would want to
      control the spooling using standard OPR commands like START, STOP,
      ABORT,  SHUTDOWN, etc.  Every queue needs a unique three character
      name.   Let's  call  the  XEROX  queue  XER.   In  the   following
      discussion,  all  references to the queue name refer to the unique
GALAXY 4.1                                                       Page 23
Making Local Modifications

      three character name selected for the queue (XER).

      The first step would be to find the QUEUES macro  in  QSRMAC.   It
      looks like this:
                DEFINE  QUEUES,<
                        X       INP,QNTSIZ,.QHTIP,0,S$INPT,LIQBAT
                        X       LPT,QNTSIZ,.QHTOU,0,S$LPT,LIQLPT
                        X       PTP,QNTSIZ,.QHTOU,0,S$PTP,LIQPTP
                        X       CDP,QNTSIZ,.QHTOU,0,S$CDP,LIQCDP
                        X       PLT,QNTSIZ,.QHTOU,0,S$PLT,LIQPLT
                        X       RET,QNTSIZ,.QHTAR,QH.INV,S$RET,LIQRET
                        X       NOT,QNTSIZ,.QHTAR,QH.INV,S$NOT,0
                        X       BIN,QNTSIZ,.QHTIP,QH.INV,S$BIN,0
                        X       DBM,QNTSIZ,.QHFRR,QH.INV,S$DBM,0
                        X       RDR,QNTSIZ,.QHFRR,0,S$RDR,0
                        X       SPL,SPLSIZ,.QHTQS,QH.INV,0,0
                        X       PSB,PSBSIZ,.QHTQS,QH.INV,0,0
                        X       OBJ,OBJSIZ,.QHTQS,QH.INV,0,0
                        X       USE,USESIZ,.QHTQS,QH.INV,0,0
                        X       STR,STRSIZ,.QHTQS,QH.INV,0,0
                        X       NET,NETSIZ,.QHTQS,QH.INV,0,0
                >  ;END OF DEFINE QUEUES
      Each entry contains six arguments.  The first is the  queue  name.
      The  second  is  the  in-core  queue  entry  (QE)  size.  Unless a
      non-standard QE is used, QNTSIZ should be  the  queue  size.   The
      third  argument  is  the  queue type.  The new XER queue is nearly
      identical to the LPT queue (except  for  output  device),  so  the
      queue  type  should  be  .QHTOU (output).  Queue flags make up the
      fourth argument.  Currently only  one  flag  is  defined  (QH.INV)
      indicating  the  queue  is  invisible.  Because users will want to
      display the XER queue, it can't be invisable.  Therefore, the flag
      word argument should be zero.  The fifth argument is the scheduler
      dispatch table used to select a job to run.  The scheduler resides
      in  QSRSCH  and  all  global entry points have symbols of the form
      S$xxxx.  Lets call the XEROX scheduler dispatch  table  S$XER  and
      make  that the fifth argument.  The sixth and last argument is the
      queue listing bit for QSRDSP.  The listing  bits  are  defined  in
      QSRMAC  where  the LIST message is defined.  The bits have symbols
      of the form LIQxxx where 'xxx' is the  queue  name.   LIQXER  will
      have to be defined and entered as the sixth argument in the QUEUES
      macro.  The QUEUES macro  entry  is  now  complete.   It  will  be
      expanded  in  QSRQUE,  producing  what are known as queue headers.
      Each header is pointed to by the symbol HDRxxx where 'xxx' is  the
      queue name.  In addition to the information supplied in the QUEUES
      macro, the queue headers will also point to  the  linked  list  of
      entries for each queue.
GALAXY 4.1                                                       Page 24
Making Local Modifications

      An object type  must  be  created.   Objects  are  line  printers,
      plotters,  card punches, etc.  Object symbols have the form .OTxxx
      where 'xxx' is the queue  name.   The  OBJCTS  macro  defines  all
      object  types and the ASCIZ name of the queue.  OBJCTS is found in

      If the XER queue will be associated with a  spooled  device  type,
      then  an entry must be made in the DEVOBJ macro in QSRT10 to allow
      the processing of spooled file requests to be  made.   The  DEVJOB
      macro looks like:
                DEFINE DEVOBJ,<
                        X       LPT,.TYLPT,.OTLPT
                        X       CDP,.TYCDP,.OTCDP
                        X       PTP,.TYPTP,.OTPTP
                        X       PLT,.TYPLT,.OTPLT
                        X       LL,.TYLPT,.OTLPT
                        X       LU,.TYLPT,.OTLPT
                >  ;END DEFINE DEVOBJ
      The DEVOBJ macro takes three arguments:  the queue name (XER)  the
      monitor device type .TYXER and the object type .OTXER.

      Some  queues  may  have  attributes  associated  with  them.   For
      example,  the LPT queue has lower and upper case considerations to
      be made when scheduling jobs.  The ATTRIB macro in QSRMAC  defines
      the known attributes for all queues.  Data generated by the ATTRIB
      macro is also used in the SHOW PARAMETER displays.

      Now scheduler code must be written.  The  scheduler  routines  are
      accessed through the scheduler dispatch table for each queue.  The
      offsets into the table are defined in QSRMAC.  They are:
                o       SCHLNK = 0      Link in a new entry
                o       SCHSCH = 1      Schedule a job
                o       SCHDEF = 2      Fill in queue defaults
                o       SCHMOD = 3      Modify queue dependent parameters
                o       SCHRJI = 4      Release a job
                o       SCHFJB = 5      Find a job for an object
      In our example, S$XER was the address of the dispatch  table.   It
      would be set up as follows:
                S$XER:: JRST    XERLNK  ;LINK IN A NEW ENTRY
                        JRST    XERSCH  ;SCHEDULE A JOB FOR AN OBJECT
                        JRST    XERDEF  ;FILL IN DEFAULTS FOR A JOB
                        JRST    XERMOD  ;MODIFY QUEUE PARAMETERS
GALAXY 4.1                                                       Page 25
Making Local Modifications

                        JRST    XERRJI  ;RELEASE A JOB INTERLOCK
                        JRST    XERFJB  ;FIND A JOB FOR AN OBJECT
      All  routines  pointed  to  by  the  scheduler dispatch table must
      return TRUE or FALSE.  For example, a FALSE return from the XERSCH
      routine  would indicate that the job QUASAR was trying to schedule
      could not be run for some reason.  A TRUE would  mean  a  job  was
      found to run on the selected object.

      The above description of adding a queue to QUASAR is by  no  means
      complete,  but should serve as a guide and details the major areas
      of QUASAR needing attention when attempting such  a  task.   Also,
      keep  in  mind  that  some amount of work will also be required in
      ORION to  add  support  for  the  OPR  commands  that  affect  the
      operation  of  the  new  spooler.   For the most part, duplicating
      existing  command  tables  for  other  spoolers  is  all  that  is

      2.5.2  BATCON - BATCON contains a dummy module, BATUSR, that  gets
      called  from  several  places within BATCON.  This module contains
      user (customer) exit code.  By putting all customer  modifications
      in  this  module,  changes  to  supported  BATCON  modules will be
      minimized.   Each  routine  has  a  description  of  the   calling
      sequences,  the  ACs  available  and  when  they  are  called.  In
      addition, many  routines  show  examples  of  how  to  use  BATCON
      facilities to make log file entries, send text to PTYs, etc.  Only
      the BATCON hooks are supported.  An attempt was  made  to  provide
      calls  to BATUSR from places in BATCON where the customer would be
      most likely to make local modifications.  Calls to BATUSR include:
                o       BATCON initialization
                o       Scheduler loop
                o       IPCF message processing
                o       Nextjob setup
                o       Start of job processing
                o       Log file header generation
                o       LOGIN command building
                o       Post LOGIN processing
                o       Job processor loop
                o       Pre-KJOB processing
                o       End of job processing
      Please  do  not take this as a commitment on DEC's part to provide
      subroutine calls in every major BATCON routine.   This  module  is
      completely   unsupported.    Any   suggestions   to  improve  it's
      usefulness will be accepted, but do not expect all suggestions  to
      be implemented.
GALAXY 4.1                                                       Page 26

      2.6  DEBUGGING

      New features exist with  GALAXY  4.1  to  facilitate  debugging  a
      GALAXY  system  under  timesharing  without  conflicting  with the
      running GALAXY system.  In most cases, debugging may be done under
      a non-privileged PPN.  Most MDA related functions do require [1,2]
      privileges  however,  and  structure  mounting,  dismounting   and
      locking operations could conflict with system MDA operations.

      A debugging GALAXY system is frequently refered to as  a  'private
      GALAXY  world'.   Setting  up  a  private world is simple.  JOBDAT
      location .JBOPS (135) is reserved for Object  Time  Systems.   The
      OTS  for  GALAXY  is GLXLIB and it makes use of this reserved word
      for debugging purposes.  When .JBOPS is set to a  non-zero  value,
      all  IPCF  generated  by  the library is directed to special PIDs.
      The special PIDs are found by associating an  ASCIZ  name  with  a
      PID.  PID names are of the form:
      where  [PPN]  is the PPN your job is running under and 'component'
      is the component name.  For example, if  user  [10,56]  started  a
      private BATCON, the PID name would be [10,56]BATCON.  Note that in
      order to assign a name to a PID, SYSINF must be running.  This  is
      the  only  dependancy  in  GALAXY  on  SYSINF.  Although the QUEUE
      program does not use GLXLIB, it also behaves in this manner.  Once
      the private world has been started, all normal GALAXY tasks may be

      [End of GALAXY.INF]