Google
 

Trailing-Edge - PDP-10 Archives - BB-PBQUC-BM_1990 - 7-documentation/mgr_guide.mem
There is 1 other file named mgr_guide.mem in the archive. Click here to see a list.












                       TOPS-20
                       System Manager's Guide

|                      Electronic Distribution



|                      June 1990

                       This document is intended for the  person  who  is
                       responsible for making final decisions for setting
                       up and maintaining the efficient  operation  of  a
                       TOPS-20 installation.

                       Change bars in margins indicate material that  has
                       been  added or changed since the previous printing
                       of this manual.

                       OPERATING SYSTEM: TOPS-20 (KL Model B) Version 7.0



                       digital equipment corporation
                       maynard, massachusetts


   First Printing, September 1985
   Revised, June 1988
|  Revised, June 1990


   The information in this document is subject to change  without  notice
   and  should  not  be  construed  as  a commitment by Digital Equipment
   Corporation.  Digital Equipment Corporation assumes no  responsibility
   for any errors that may appear in this document.

   The software described in this document is furnished under  a  license
   and  may  only  be used or copied in accordance with the terms of such
   license.

   No responsibility is assumed for the use or reliability of software on
   equipment that is not supplied by Digital Equipment Corporation or its
   affiliated companies.


|  Copyright C 1985, 1988, 1990 Digital Equipment Corporation

   All Rights Reserved.
   Printed in U.S.A.



   The following are trademarks of Digital Equipment Corporation:

   CI             DECtape     LA50             SITGO-10
   DDCMP          DECUS       LN01             TOPS-10
   DEC            DECwriter   LN03             TOPS-20
   DECmail        DELNI       MASSBUS          TOPS-20AN
   DECnet         DELUA       PDP              UNIBUS
   DECnet-VAX     HSC         PDP-11/24        UETP
   DECserver      HSC-50      PrintServer      VAX
   DECserver 100  KA10        PrintServer 40   VAX/VMS
   DECserver 200  KI          Q-bus            VT50
   DECsystem-10   KL10        ReGIS
   DECSYSTEM-20   KS10        RSX              d i g i t a l


                                      CONTENTS



   PREFACE


   CHAPTER 1       DOCUMENTATION

           1.1     DOCUMENTS AVAILABLE FROM DIGITAL . . . . . . . . . 1-1
           1.2     DOCUMENTS PREPARED AT YOUR INSTALLATION  . . . . . 1-2
           1.2.1     System Log . . . . . . . . . . . . . . . . . . . 1-3
           1.2.2     Mountable Structure Sign-Up Log  . . . . . . . . 1-6
           1.2.3     System Access Request Form . . . . . . . . . . . 1-6
           1.2.4     Operator Work Request Form . . . . . . . . . . . 1-9
           1.2.5     Operator Shift Change Log  . . . . . . . . . . . 1-9


   CHAPTER 2       PREPARING FOR SOFTWARE INSTALLATION

           2.1     SECURING THE COMPUTER ROOM . . . . . . . . . . . . 2-1
           2.2     HANDLING USER REQUESTS . . . . . . . . . . . . . . 2-1
           2.3     ORDERING SUPPLIES  . . . . . . . . . . . . . . . . 2-2
           2.4     SCHEDULING OPERATOR TASKS  . . . . . . . . . . . . 2-2
           2.5     SELECTING SYSTEM FEATURES  . . . . . . . . . . . . 2-4


   CHAPTER 3       AFTER SOFTWARE INSTALLATION

           3.1     OVERVIEW . . . . . . . . . . . . . . . . . . . . . 3-1
           3.2     SPECIAL SYSTEM DIRECTORIES . . . . . . . . . . . . 3-1
           3.2.1     <ROOT-DIRECTORY> . . . . . . . . . . . . . . . . 3-2
           3.2.2     <SYSTEM> . . . . . . . . . . . . . . . . . . . . 3-3
           3.2.3     Restoring the Directory <SYSTEM> . . . . . . . . 3-6
           3.2.4     <SUBSYS> . . . . . . . . . . . . . . . . . . . . 3-7
           3.2.5     Restoring the Directory <SUBSYS> . . . . . . .  3-16
           3.2.6     <NEW-SYSTEM> and <NEW-SUBSYS>  . . . . . . . .  3-17
           3.2.7     <ACCOUNTS>, <OPERATOR>, <SPOOL>, and 
                     <SYSTEM-ERROR> . . . . . . . . . . . . . . . .  3-18
           3.2.8     Other Useful Directories . . . . . . . . . . .  3-18
           3.3     SYSTEM-LOGICAL NAMES . . . . . . . . . . . . . .  3-20
           3.3.1     SYSTEM:  . . . . . . . . . . . . . . . . . . .  3-21
           3.3.2     SYS: . . . . . . . . . . . . . . . . . . . . .  3-21
           3.3.3     NEW: . . . . . . . . . . . . . . . . . . . . .  3-21
           3.3.4     OLD: . . . . . . . . . . . . . . . . . . . . .  3-22
           3.3.5     HLP: . . . . . . . . . . . . . . . . . . . . .  3-22
           3.3.6     SERR:  . . . . . . . . . . . . . . . . . . . .  3-22
           3.3.7     DMP: . . . . . . . . . . . . . . . . . . . . .  3-23
           3.3.8     DEFAULT-EXEC:  . . . . . . . . . . . . . . . .  3-23
           3.3.9     POBOX: . . . . . . . . . . . . . . . . . . . .  3-24
           3.3.10    NRT: . . . . . . . . . . . . . . . . . . . . .  3-24
           3.3.11    SPOOL: . . . . . . . . . . . . . . . . . . . .  3-25


                                    iii


           3.4     CONSOLE FRONT-END FILES  . . . . . . . . . . . .  3-25
           3.5     TAILORING THE BATCH SYSTEM . . . . . . . . . . .  3-29
           3.6     CHECKING THE SOFTWARE (UETP) . . . . . . . . . .  3-29
           3.7     REMOTE PRINTERS  . . . . . . . . . . . . . . . .  3-30
           3.7.1     Remote Printing Requirements . . . . . . . . .  3-31
           3.7.2     Defining DQS and LAT Printers  . . . . . . . .  3-32
           3.7.3     Setting DQS Printing Characteristics . . . . .  3-33
           3.8     TERMINAL PRINTERS  . . . . . . . . . . . . . . .  3-34


   CHAPTER 4       CREATING STRUCTURES

           4.1     OVERVIEW . . . . . . . . . . . . . . . . . . . . . 4-1
           4.2     THE SYSTEM STRUCTURE . . . . . . . . . . . . . . . 4-2
           4.2.1     What Is the System Structure?  . . . . . . . . . 4-2
           4.2.2     The Contents of the System Structure . . . . . . 4-3
           4.3     ONE-STRUCTURE SYSTEMS  . . . . . . . . . . . . . . 4-4
           4.4     MOUNTABLE STRUCTURES . . . . . . . . . . . . . . . 4-5
           4.4.1     Differences Between Mountable and System 
                     Structures . . . . . . . . . . . . . . . . . . . 4-5
           4.4.2     Similarities Between Mountable and System 
                     Structures   . . . . . . . . . . . . . . . . . . 4-5
           4.5     MULTIPLE-STRUCTURE SYSTEMS . . . . . . . . . . . . 4-7
           4.5.1     Choosing Structure Names . . . . . . . . . . . . 4-9
           4.5.2     Mounting Structures Having the Same Name . . .  4-11
           4.5.3     Maximum Size of Structures . . . . . . . . . .  4-11
           4.5.4     Increasing the Size of Structures  . . . . . .  4-13
           4.5.5     Setting Up Structures for Maximum Availability  4-14
           4.5.6     Taking Structures Off-Line . . . . . . . . . .  4-15
           4.5.7     Mounting Structures from Another Installation   4-16
           4.6     SHARING STRUCTURES (DISK DRIVES) BETWEEN TWO 
                   SYSTEMS  . . . . . . . . . . . . . . . . . . . .  4-17
           4.7     DETERMINING SWAPPING SPACE ON THE SYSTEM 
                   STRUCTURE  . . . . . . . . . . . . . . . . . . .  4-19
           4.7.1     What Is Swapping?  . . . . . . . . . . . . . .  4-19
           4.7.2     When to Increase Swapping Space  . . . . . . .  4-19
           4.8     DETERMINING THE AVAILABLE DISK SPACE . . . . . .  4-21
           4.8.1     Determining Disk Space Before Installation . .  4-21
           4.8.2     Determining Disk Space After Installation  . .  4-23


   CHAPTER 5       CREATING DIRECTORIES

           5.1     HAVING THE OPERATOR CREATE AND MAINTAIN ALL 
                   DIRECTORIES (CENTRAL CONTROL)  . . . . . . . . . . 5-2
           5.2     DELEGATING THE CREATION AND MAINTENANCE OF 
                   DIRECTORIES TO PROJECT ADMINISTRATORS (PROJECT 
                   CONTROL) . . . . . . . . . . . . . . . . . . . . . 5-2
           5.3     COMBINING CENTRAL AND PROJECT CONTROL  . . . . . . 5-3
           5.4     CENTRAL AND PROJECT CONTROL DESCRIPTIONS . . . . . 5-3
           5.4.1     Central Control  . . . . . . . . . . . . . . . . 5-4
           5.4.2     Central Control Using Subdirectories . . . . . . 5-7


                                     iv


           5.4.3     Project Control  . . . . . . . . . . . . . . .  5-14
           5.4.4     Combined Central and Project Control . . . . .  5-22
           5.5     ALLOCATING DISK STORAGE QUOTAS . . . . . . . . .  5-23
           5.6     ENFORCING DISK STORAGE QUOTAS  . . . . . . . . .  5-24
           5.7     PROTECTING DIRECTORIES AND FILES . . . . . . . .  5-26
           5.7.1     Directory and File Protection Digits . . . . .  5-26
           5.7.2     Changing Directory and File Protection . . . .  5-29
           5.8     ESTABLISHING GROUPS  . . . . . . . . . . . . . .  5-29
           5.9     GIVING USERS SPECIAL CAPABILITIES  . . . . . . .  5-38
           5.10    PRINTING DIRECTORY INFORMATION . . . . . . . . .  5-40


   CHAPTER 6       CREATING ACCOUNTS

           6.1     SETTING UP THE SYSTEM TO USE ACCOUNTS  . . . . . . 6-2
           6.1.1     Enabling or Disabling Account Validation . . . . 6-2
           6.1.2     Setting up Account Validation with Existing 
                     Files  . . . . . . . . . . . . . . . . . . . . . 6-2
           6.1.3     Setting up the System for Accounting Shift 
                     Changes  . . . . . . . . . . . . . . . . . . . . 6-3
           6.2     SELECTING AN ACCOUNTING SCHEME . . . . . . . . . . 6-3
           6.3     CREATING AN ACCOUNT DATA BASE  . . . . . . . . . . 6-7
           6.3.1     Entering Accounting Data into Files  . . . . . . 6-8
           6.3.2     Sample Data Files  . . . . . . . . . . . . . .  6-14
           6.3.3     Running the ACTGEN Program . . . . . . . . . .  6-17
           6.3.4     Data Base Failures/Recovery  . . . . . . . . .  6-19
           6.4     VALIDATING ACCOUNTS  . . . . . . . . . . . . . .  6-19


   CHAPTER 7       SYSTEM BACKUP PROCEDURES

           7.1     SAVING ALL FILES IN ALL DIRECTORIES  . . . . . . . 7-2
           7.1.1     Full Dumps . . . . . . . . . . . . . . . . . . . 7-3
           7.1.2     Incremental Dumps  . . . . . . . . . . . . . . . 7-3
           7.1.3     Security of Backup Tapes . . . . . . . . . . . . 7-4
           7.2     A COMMON BACKUP POLICY . . . . . . . . . . . . . . 7-4
           7.3     MAGNETIC TAPE REQUIREMENTS . . . . . . . . . . . . 7-4
           7.4     MAKING A SYSTEM CRASH TAPE . . . . . . . . . . . . 7-6
           7.5     MAKING A CRASH TAPE USING BATCH  . . . . . . . . . 7-8
           7.6     SAVING THE CONSOLE FRONT-END FILE SYSTEM . . . .  7-10


   CHAPTER 8       TAPE STORAGE

           8.1     FILE ARCHIVING . . . . . . . . . . . . . . . . . . 8-2
           8.1.1     Setting Up the System to Use File Archiving  . . 8-3
           8.1.2     What Happens When Users Archive Files  . . . . . 8-3
           8.1.3     What Happens When Users Retrieve Files . . . . . 8-5
           8.1.4     When to Create Archive Tapes . . . . . . . . . . 8-5
           8.1.5     Processing Retrieval Requests  . . . . . . . . . 8-7
           8.2     FILE MIGRATION . . . . . . . . . . . . . . . . . . 8-7
           8.2.1     Setting Up the System to Use File Migration  . . 8-8


                                     v


           8.2.2     Using the REAPER Program . . . . . . . . . . . . 8-8
           8.2.3     Using the DUMPER Program . . . . . . . . . . .  8-10
           8.2.4     Processing Retrieval Requests for Migrated 
                     Files  . . . . . . . . . . . . . . . . . . . .  8-11
           8.2.5     Recycling Migration (and Archive) Tapes  . . .  8-11
           8.3     TAPE DRIVE ALLOCATION  . . . . . . . . . . . . .  8-12
           8.3.1     When to Use Tape Drive Allocation  . . . . . .  8-12
           8.3.2     How to Enable/Disable Tape Drive Allocation  .  8-13
           8.3.3     Tape Mounting Policy . . . . . . . . . . . . .  8-13
           8.4     TAPE LABELING  . . . . . . . . . . . . . . . . .  8-13
           8.4.1     Why Tape Labels? . . . . . . . . . . . . . . .  8-14
           8.4.2     Setting Up the System to Use Tape Labels . . .  8-16
           8.4.3     Initializing Tapes and Drives to Use Labels  .  8-17
           8.5     SHARING TAPE DRIVES BETWEEN TWO SYSTEMS  . . . .  8-18


   CHAPTER 9       SYSTEM PROBLEMS/CRASHES

           9.1     RESTORING A SINGLE FILE  . . . . . . . . . . . . . 9-2
           9.2     RESTORING A SINGLE DIRECTORY . . . . . . . . . . . 9-2
           9.3     RESTORING <ROOT-DIRECTORY> . . . . . . . . . . . . 9-3
           9.3.1     Rebuilding the System Structure <ROOT-DIRECTORY> 9-5
           9.4     RESTORING THE ENTIRE FILE SYSTEM . . . . . . . . . 9-9
           9.4.1     Re-creating the File System on the System 
                     Structure  . . . . . . . . . . . . . . . . . . . 9-9
           9.4.2     Re-creating Mountable Structures   . . . . . .  9-10
           9.5     POWER FAILURES . . . . . . . . . . . . . . . . .  9-11
           9.6     REMOTE DIAGNOSTIC LINK (KLINIK)  . . . . . . . .  9-11
           9.7     MAKING THE CI UNAVAILABLE ON NON-CFS SYSTEMS . .  9-12
           9.8     MAKING THE NI UNAVAILABLE  . . . . . . . . . . .  9-12
           9.9     OFFLINE DISKS  . . . . . . . . . . . . . . . . .  9-12
           9.9.1     Operator Procedures  . . . . . . . . . . . . .  9-13
           9.10    DUMPING ON NON-FATAL SYSTEM ERRORS . . . . . . .  9-14
           9.10.1    Enabling DUMP-ON-BUGCHK  . . . . . . . . . . .  9-14
           9.10.2    Disabling DUMP-ON-BUGCHK . . . . . . . . . . .  9-14
           9.10.3    "Dumpable Structures"  . . . . . . . . . . . .  9-15
           9.10.4    Copying the Dump File  . . . . . . . . . . . .  9-15
           9.10.5    Time Considerations  . . . . . . . . . . . . .  9-16
           9.10.6    Controlling DUMP-ON-BUGCHK . . . . . . . . . .  9-17


   CHAPTER 10      SYSTEM PERFORMANCE

           10.1    THE CLASS SCHEDULER  . . . . . . . . . . . . . .  10-2
           10.1.1    Overview . . . . . . . . . . . . . . . . . . .  10-2
           10.1.2    Who Should Use the Class Scheduler?  . . . . .  10-4
           10.1.3    How to Begin Using the Class Scheduler . . . .  10-6
           10.1.4    Procedures to Turn On the Class Scheduler  . .  10-8
           10.1.5    Changing Class Percentages During Timesharing  10-10
           10.1.6    Disabling the Class Scheduler During 
                     Timesharing  . . . . . . . . . . . . . . . . . 10-11



                                     vi


           10.1.7    Getting Information About Class Scheduler 
                     Status . . . . . . . . . . . . . . . . . . . . 10-11
           10.1.8    A Sample Session . . . . . . . . . . . . . . . 10-13
           10.1.9    An Alternative to Using Accounts . . . . . . . 10-14
           10.2    SCHEDULING LOW PRIORITY TO BATCH JOBS  . . . . . 10-15
           10.3    FAVORING INTERACTIVE VERSUS COMPUTE-BOUND 
                   PROGRAMS . . . . . . . . . . . . . . . . . . . . 10-15
           10.4    IMPROVING PROGRAM STARTUP TIME . . . . . . . . . 10-17
           10.5    REINITIALIZING DISK PACKS  . . . . . . . . . . . 10-18
           10.6    DYNAMIC DUAL PORTING . . . . . . . . . . . . . . 10-19


   CHAPTER 11      ACCESS CONTROLS

           11.1    ACCESS CONTROL PROGRAM . . . . . . . . . . . . .  11-1
           11.1.1    Starting the ACJ . . . . . . . . . . . . . . .  11-2
           11.1.2    Defining the ACJ Environment . . . . . . . . .  11-3
           11.1.3    ENABLE and DISABLE Commands  . . . . . . . . .  11-3
           11.1.3.1    ENABLE/DISABLE Command Functions . . . . . .  11-5
           11.1.3.2    ENABLE/DISABLE Function Qualifiers . . . . . 11-14
           11.1.4    USER Command . . . . . . . . . . . . . . . . . 11-15
           11.1.5    SET Command  . . . . . . . . . . . . . . . . . 11-17
           11.1.6    SHOW Command . . . . . . . . . . . . . . . . . 11-18
           11.1.7    WRITE Command  . . . . . . . . . . . . . . . . 11-19
           11.1.8    SAVE Command . . . . . . . . . . . . . . . . . 11-19
           11.1.9    Summary  . . . . . . . . . . . . . . . . . . . 11-20
           11.1.10   Reviewing the Log Files  . . . . . . . . . . . 11-21
           11.1.10.1   Log File Format  . . . . . . . . . . . . . . 11-21
           11.1.10.2   Log File Examples  . . . . . . . . . . . . . 11-22
           11.2    PASSWORD ENCRYPTION  . . . . . . . . . . . . . . 11-23
           11.2.1    Moving Structures Among Systems  . . . . . . . 11-25
           11.2.2    Adding Encryption Algorithms to the System . . 11-25
           11.2.3    Using DUMPER . . . . . . . . . . . . . . . . . 11-26
           11.3    PASSWORD MANAGEMENT  . . . . . . . . . . . . . . 11-28
           11.3.1    Setting Password Length  . . . . . . . . . . . 11-28
           11.3.2    Changing Passwords Regularly . . . . . . . . . 11-28
           11.3.3    Disallowing Certain Passwords  . . . . . . . . 11-29
           11.4    LAST LOGIN INFORMATION . . . . . . . . . . . . . 11-30
           11.5    PREVENTING FAST LOGINS . . . . . . . . . . . . . 11-31
           11.6    PREVENTING NOT-LOGGED-IN SYSTAT  . . . . . . . . 11-31
           11.7    SECURING FILES . . . . . . . . . . . . . . . . . 11-32
           11.7.1    Secure Files and the ACJ . . . . . . . . . . . 11-33
           11.7.2    Securing Important Files . . . . . . . . . . . 11-33
           11.8    SECURITY HINTS . . . . . . . . . . . . . . . . . 11-34


   CHAPTER 12      THE COMMON FILE SYSTEM

           12.1    OVERVIEW . . . . . . . . . . . . . . . . . . . .  12-1
           12.1.1    CFS HARDWARE . . . . . . . . . . . . . . . . .  12-2
           12.1.2    CFS SOFTWARE . . . . . . . . . . . . . . . . .  12-6
           12.1.3    CFS USERS  . . . . . . . . . . . . . . . . . .  12-7


                                    vii


           12.1.4    CFS and DECnet . . . . . . . . . . . . . . . .  12-7
           12.1.5    CFS and TIGHTLY-COUPLED SYSTEMS  . . . . . . .  12-8
           12.1.6    Limitations  . . . . . . . . . . . . . . . . .  12-8
           12.1.7    "Cluster Data Gathering" . . . . . . . . . . .  12-9
           12.1.8    Cluster GALAXY . . . . . . . . . . . . . . . .  12-9
           12.2    PLACEMENT OF FILES . . . . . . . . . . . . . . . 12-10
           12.2.1    Update Files . . . . . . . . . . . . . . . . . 12-11
           12.2.2    Files on Served Disks  . . . . . . . . . . . . 12-11
           12.2.3    Mail Files . . . . . . . . . . . . . . . . . . 12-11
           12.2.4    Sharing System Files . . . . . . . . . . . . . 12-12
           12.3    LOAD BALANCING . . . . . . . . . . . . . . . . . 12-13
           12.3.1    Dedicating Systems . . . . . . . . . . . . . . 12-13
           12.3.2    Assigning Users to Systems . . . . . . . . . . 12-14
           12.4    STRUCTURE NAMES  . . . . . . . . . . . . . . . . 12-15
           12.5    SYSTEM LOGICAL NAMES . . . . . . . . . . . . . . 12-15
           12.6    SHARING STRUCTURES AMONG SYSTEMS . . . . . . . . 12-15
           12.6.1    Sharing System Structures  . . . . . . . . . . 12-16
           12.6.2    Sharing the Login Structure  . . . . . . . . . 12-16
           12.6.2.1    Creating the Login Structure . . . . . . . . 12-16
           12.6.2.2    Enabling "Login Structure" . . . . . . . . . 12-17
           12.6.2.3    Disabling "Login Structure"  . . . . . . . . 12-17
           12.6.2.4    PS: and BS: Directories  . . . . . . . . . . 12-17
           12.7    RESTRICTING STRUCTURES TO ONE SYSTEM . . . . . . 12-18
           12.8    DISMOUNTING STRUCTURES . . . . . . . . . . . . . 12-19
           12.9    MAKING THE CI UNAVAILABLE TO A SYSTEM  . . . . . 12-20
           12.10   USING DUMPER . . . . . . . . . . . . . . . . . . 12-20
           12.11   ERRORS . . . . . . . . . . . . . . . . . . . . . 12-21
           12.11.1   Communication Problems . . . . . . . . . . . . 12-21
           12.11.2   Massbus Problems with Dual-Ported Disk Drives  12-24
           12.12   SHUTTING DOWN A CFS SYSTEM . . . . . . . . . . . 12-24


   CHAPTER 13      LAT TERMINAL SERVERS

           13.1    OVERVIEW . . . . . . . . . . . . . . . . . . . .  13-1
           13.2    LAT SOFTWARE . . . . . . . . . . . . . . . . . .  13-2
           13.3    DECNET . . . . . . . . . . . . . . . . . . . . .  13-4
           13.4    CONTROLLING LAT FROM THE HOST  . . . . . . . . .  13-4
           13.5    STARTING AND STOPPING LAT  . . . . . . . . . . .  13-8
           13.6    LAT GROUPS . . . . . . . . . . . . . . . . . . .  13-9
           13.7    HOST SERVICES  . . . . . . . . . . . . . . . . . 13-10
           13.7.1    Service Ratings  . . . . . . . . . . . . . . . 13-10
           13.8    MONITORING LAT FROM THE HOST . . . . . . . . . . 13-11
           13.8.1    Displaying User Information  . . . . . . . . . 13-11
           13.8.2    Displaying Host Parameters . . . . . . . . . . 13-12
           13.8.3    Displaying Server Information  . . . . . . . . 13-12
           13.8.4    Displaying LAT Counters  . . . . . . . . . . . 13-13
           13.8.5    Displaying Pending Requests for LAT 
                     Application Terminals  . . . . . . . . . . . . 13-14
           13.8.6    Displaying All Print Requests for LAT 
                     Application Terminals  . . . . . . . . . . . . 13-15



                                    viii


   INDEX


   FIGURES

           1-1     Sample System Log (Hardware Maintenance) . . . . . 1-4
           1-2     Sample System Log (Problem Report) . . . . . . . . 1-5
           1-3     Sample Mountable Structure Sign-Up Log . . . . . . 1-7
           1-4     System Access Request  . . . . . . . . . . . . . . 1-8
           1-5     Operator Work Request  . . . . . . . . . . . . .  1-10
           1-6     Operator Shift Change Log  . . . . . . . . . . .  1-11
           4-1     System with 3 Disk Drives and 2 Structures . . . . 4-7
           4-2     Three-Structure System . . . . . . . . . . . . . . 4-8
           4-3     Domestic and Foreign Structures  . . . . . . . .  4-16
           4-4     Shared Disk Drive  . . . . . . . . . . . . . . .  4-18
           5-1     File-Sharing Group . . . . . . . . . . . . . . .  5-33
           5-2     Library Group  . . . . . . . . . . . . . . . . .  5-35
           5-3     Teacher-Student Group  . . . . . . . . . . . . .  5-37
           6-1     Accounting Scheme 1  . . . . . . . . . . . . . . . 6-6
           6-2     Accounting Scheme 2  . . . . . . . . . . . . . . . 6-7
           6-3     Correct-Data Accounting Files  . . . . . . . . .  6-15
           6-4     Unionbank Accounting Files . . . . . . . . . . .  6-16
           8-1     Organization of Labeled Tapes  . . . . . . . . .  8-15
           8-2     TX02 Tape Subsystem  . . . . . . . . . . . . . .  8-18
           12-1    Two Systems with Massbus Disks and HSC50-based 
                   Disks  . . . . . . . . . . . . . . . . . . . . .  12-2
           12-2    Two Systems with Massbus Disks . . . . . . . . .  12-3
           13-1    A LAT Network  . . . . . . . . . . . . . . . . .  13-1


   TABLES

           3-1     <SYSTEM> Files . . . . . . . . . . . . . . . . . . 3-3
           3-2     STR:<SUBSYS> Files . . . . . . . . . . . . . . . . 3-7
           3-3     Console Front-End Files  . . . . . . . . . . . .  3-26
           4-1     Differences Between Mountable and System 
                   Structures . . . . . . . . . . . . . . . . . . . . 4-6
           4-2     Similarities Between Mountable and System 
                   Structures . . . . . . . . . . . . . . . . . . . . 4-6
           4-3     Sample Device Names  . . . . . . . . . . . . . .  4-10
           4-4     Maximum Size Structures  . . . . . . . . . . . .  4-13
           4-5     Determining Swapping Space . . . . . . . . . . .  4-20
           4-6     Calculating Available Disk Space . . . . . . . .  4-22
           5-1     Directory Protection Digits  . . . . . . . . . .  5-27
           5-2     File Protection Digits . . . . . . . . . . . . .  5-28
           5-3     Special Capabilities . . . . . . . . . . . . . .  5-38
           6-1     Summary of Account Data File Commands  . . . . . . 6-9
           8-1     Tape Drive Allocation  . . . . . . . . . . . . .  8-12
           9-1     <ROOT-DIRECTORY> BUGHLTS . . . . . . . . . . . . . 9-3
           11-1    DUMPER Directory Restorations  . . . . . . . . . 11-27
           12-1    Comparison of CFS and DECnet . . . . . . . . . .  12-8


   .





















































                                     x














                                  PREFACE



   The TOPS-20 System Manager's Guide is written for the  person  who  is
   responsible for establishing policies and procedures for a timesharing
   and/or batch  processing  installation  using  the  TOPS-20  Operating
   System.   Usually,  this  person  is  responsible  for  setting up and
   maintaining  both  the  system  hardware  and  software.    The   Site
   Management  Guide,  the TOPS-10/TOPS-20 Operator's Hardware Device and
   Maintenance Guide, and the TOPS-20 Operator's Guide  provide  you  and
   your operations people with the necessary information to maintain your
   system hardware.  These three manuals are referenced  throughout  this
   guide.

   This guide deals primarily with your  system  software.   It  contains
   general suggestions for planning the installation of your software and
   for setting up your computer room  to  begin  operations.   The  guide
   contains  hints and suggestions for your system's operation, including
   when, and many times why, particular functions or procedures should be
   considered.   It  assumes that your system operator is responsible for
   implementing many of the decisions you make.   In  most  cases,  where
   lengthy   implementation  procedures  are  required,  the  appropriate
   reference is noted.

   Chapters 1 and 2      describe the documentation,  system  logs,  and
                         special forms that you should have available to
                         you,  and  in  some  cases,  to  system  users.
                         Chapter 2 also  includes  preliminary  planning
                         functions that you can do before  the  software
                         is installed.











                                     xi



   Chapter 3             describes the system directories and files that
                         your  system  contains  immediately  after  you
                         install  the  software.  It  also describes the
                         mechanisms you can use to change the  installed
                         TOPS-20 batch system and to test the  integrity
                         of your newly installed or updated  system.  In
                         addition, it describes requirements for  remote
                         printing  and  for printing on devices attached
                         to terminals.

   Chapter 4             describes using your disk-pack  and  disk-drive
                         resources  to  set  up disk structures in a way
                         that  best  suits your installation's needs. It
                         also includes guidelines  for  determining  the
                         available disk space that you  have  to  create
                         user directories.

   Chapter 5             describes creating and maintaining directories.
                         It includes a detailed description of the three
                         methods  of  administration you can choose from
                         to  control  the  creation  and  maintenance of
                         directories.  It describes how to use directory
                         and file protection codes to  expand  or  limit
                         the  type  of  access   users   can   have   to
                         directories and files, and how to  place  users
                         and directories in groups  so  that  users  can
                         share files.

   Chapter 6             describes the TOPS-20 accounting facility. This
                         description   includes   how   to   choose   an
                         accounting scheme,  how  to  create  accounting
                         files,  and  how  to  set  the  system to begin
                         validating accounts.

   Chapter 7             describes  backing up your disk structures onto
                         magnetic tape soon after software installation.
                         It   recommends   the   supplies   needed   and
                         procedures that you should follow to  save  all
                         your directories and files on  a  daily  basis,
                         and how to create a system crash  tape  in  the
                         event of a major problem with the file system.

   Chapter 8             describes how you can  use  magnetic  tapes  to
                         store  important  files (file archiving) and to
                         save   valuable   disk   space    by    copying
                         infrequently  accessed  files  to  tape   (file
                         migration).  It  also  describes  how  to  give
                         control  of  tape drive usage to the system and
                         the  operator  (tape drive allocation), and how
                         to  set  up  your  system  to use labeled tapes
                         (tape labeling).


                                    xii



   Chapter 9             describes the procedures you must follow in the
                         event  that  you  have  a problem with the file
                         system  or  that a user has lost the files in a
                         directory.  It also describes using your system
                         crash tape  and  your  daily  backup  tapes  to
                         resolve  these  problems.   In   addition,   it
                         describes  how  to prevent "offline" disks from
                         hanging user jobs, and discusses dumping memory
                         for nonfatal system errors.

   Chapter 10            describes  the tuning mechanisms that allow you
                         to change the behavior  of  your  system.  Each
                         description  includes why you may want to use a
                         particular mechanism, how to use  it,  and  the
                         effects it may have on your system.

   Chapter 11            describes the access  control  mechanisms  that
                         you can use to alter system policy decisions or
                         to   increase   security  against  unauthorized
                         system use. This chapter includes the  type  of
                         policy  changes  you  may  want to make at your
                         installation.

   Chapter 12            describes  the  Common  File System, a software
                         feature  of TOPS-20. This chapter discusses the
                         rules,  options,  and  restrictions  associated
                         with sharing files among systems.

   Chapter 13            describes  the  Local  Area   Transport   (LAT)
                         software,  for  use  with  terminal  servers in
                         Ethernet local area networks.






















                                    xiii


   The following conventions and symbols are used throughout this guide:

   Convention/Symbol     Description

   n-                    n  refers to the latest version of a particular
                         file, for example, 7-CONFIG.CMD.

   UPPERCASE             In   user   input   representations,  indicates
                         information  that  must  be  entered exactly as
                         shown.

   lowercase             In   user   input   representations,  indicates
                         variable information that is determined by you.

   underlining           Indicates the information that you must type at
                         your terminal.

   ()                    In user input representations,  encloses  guide
                         word  information.  Pressing  the   ESCAPE   or
                         ALTMODE  key on your terminal causes guidewords
                         to be printed by the computer.

   <RET>                 Indicates you should press the  RET  or  RETURN
                         key  on  your terminal. Unless otherwise noted,
                         pressing RETURN terminates all command or input
                         strings.

   <ESC>                 Indicates  you should press the ESC key on your
                         terminal.

   CTRL/key              Indicates you should press the CTRL key on your
                         terminal.  The  CTRL  key  is  always  used  in
                         conjunction  with  another  key,  for  example,
                         CTRL/Z.




















                                    xiv











                                 CHAPTER 1

                               DOCUMENTATION



   Section 1.1  describes  the  documentation  provided  by  DIGITAL  and
   recommends  the  manuals  with  which you should be familiar to manage
   your system.  Section 1.2 describes adding your own documentation, for
   example, special forms, to the documentation you receive from DIGITAL.
   Be sure you have all available documentation convenient to your system
   users.



   1.1  DOCUMENTS AVAILABLE FROM DIGITAL

   All documentation for the TOPS-20 Operating System is contained in the
   TOPS-20 Software Notebook Set.  This notebook set contains information
   pertaining to the most recent version of  TOPS-20.   It  is  organized
   functionally  to facilitate referencing manuals.  Each manual contains
   cross references to other manuals within the set that further  explain
   a subject.

   This manual assumes that you are familiar with some of the manuals  in
   the  notebook  set.   In  particular,  you should be familiar with the
   information in the TOPS-20 Operator's Guide, the TOPS-20 User's Guide,
   the  DECSYSTEM-20  Technical  Summary,  the TOPS-10/TOPS-20 Operator's
   Hardware Device and Maintenance Guide, and the TOPS-20  KL10  Model  B
   Installation Guide.

   Any additional documents that you need depend on the configuration  of
   your  system.   For  example,  if  your  system  has IBM emulation and
   termination  (DNxx),   you   should   be   familiar   with   the   IBM
   Emulation-Termination Manual.  It includes installation procedures and
   descriptions of the operator and user interfaces.  If your system  has
   DECnet, you should be familiar with the various DECnet-20 manuals.  If
   you are using LAT terminal servers in an Ethernet local area  network,
   refer to the documentation that is provided with LAT terminal servers,
   in addition to chapter 13 of this manual.

   In addition to the TOPS-20 Software  Notebook  Set,  you  receive  the
   TOPS-20  Beware  File  Listing.   It  is distributed with the software


                                    1-1
                               DOCUMENTATION


   installation and distribution magnetic tapes.  Before installing a new
   version  of  the  software  on  your system, read the Beware File.  It
   contains last-minute changes  to  the  software  that  have  not  been
   documented,  and  hints or suggestions for installing or using the new
   software.

   With  each  new  system,  you  should  also  receive  two  stand-alone
   documents,  which  are  documents  not  included  in the notebook set.
   These manuals assist you in 1) preparing your site  for  the  hardware
   installation,  the  Site  Preparation  Guide,  and  2) maintaining and
   reporting problems about your system's software and hardware, the Site
   Management Guide.

                                    NOTE

           Your   Sales   Representative   delivers   the    Site
           Preparation    Guide,    and    your   Field   Service
           Representative delivers the Site Management Guide.

   This manual (the TOPS-20 System Manager's Guide) deals primarily  with
   installing and maintaining the software on your system.  Therefore, it
   is assumed that you have already used the Site  Preparation  Guide  to
   install your system hardware.

   The Site Management Guide is designed for use by both you (along  with
   your  operations  people)  and your Field Service Representative.  You
   should begin using this manual  immediately  after  you  install  your
   hardware.   It  contains schedules, procedures, and logs for recording
   and evaluating all information pertinent to the operation and care  of
   the  system.   The  manual  belongs  to  DIGITAL,  but  it is kept and
   maintained  at  your  computer  site.   For  added   convenience   and
   organization,  many  system  managers  keep all their important system
   information in the same binder as  the  Site  Management  Guide.   For
   example,  they  keep system logs and operator shift change information
   in the same binder, along  with  other  special  forms.   Section  1.2
   describes  several forms that you may include in a system log book or,
   as suggested here, in the Site Management Guide.

   DIGITAL places a major emphasis on the documentation provided  to  its
   customers.   The Software Publications Department continues to solicit
   suggestions for improvement and corrections  from  the  users  of  its
   documentation.   Encourage users to comment on the manuals you receive
   with your system.  For convenience, a Reader Comment Form  is  located
   at the back of each manual.



   1.2  DOCUMENTS PREPARED AT YOUR INSTALLATION

   Sections 1.2.1 through 1.2.5 describe some forms that may be useful at
   your installation.  A sample form is provided in each section.



                                    1-2
                               DOCUMENTATION


   1.2.1  System Log

   Every system must  have  a  system  log  for  recording  problems  and
   procedures  relating to both hardware and software.  All operators and
   system programmers should record the following types of activities  in
   the log, along with the date, time, and their names:

         o  System backup procedures

         o  Beginning and ending of timesharing (for example,  the  times
            the system was started and stopped for preventive maintenance
            or repair)

         o  Problems in hardware or software AND  the  actions  taken  to
            correct the problems (always save the CTY (operator terminal)
            output or copy of the typescript)

         o  New or revised software installed

         o  New users or changes to existing user data or directories

         o  New structures or changes to existing structures

   Most system problems are easier to solve (and, hence, less costly)  if
   you  keep  an  accurate record of all activities.  The Site Management
   Guide has a section  set  aside  for  system  log  information.   This
   section  contains  preprinted  forms that you can use to record system
   log information, or you can design your  own  forms.   You  can  store
   these forms in the Site Management Guide or in a separate binder.

   You should design your log so  that  it  is  easy  to  use  and  read.
   Remember,  you are likely to have the most problems when the system is
   new, so NOW is the time to start using the  log.   The  following  two
   pages  contain  sample  left- and right-hand pages of a log book.  The
   left-hand page (Figure 1-1) contains information  concerning  hardware
   maintenance;  the  right-hand  page  (Figure 1-2) is a problem report,
   containing:

         o  The time of the entry

         o  A "Y" or "N" answer to whether the system had to be reloaded

         o  The name of the person making the entry

         o  A few words describing the nature of the activity

         o  A record of calls to Digital Field Service (F/S)

         o  A description of the device or program causing the problem

         o  Remarks about the entry



                                    1-3
                               DOCUMENTATION


      ____________________________________________________________________
     |                                                                    |
     |          SYSTEM LOG                                                |
     |          MAINTENANCE PERFORMED                     DATE__________  |
     |                                                                    |
     |                                                                    |
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|
     |                                                                    |
     |____________________________________________________________________|


   Figure 1-1:  Sample System Log (Hardware Maintenance)





                                    1-4
                               DOCUMENTATION


      ____________________________________________________________________
     |                                                                    |
     |                                                    PAGE__________  |
     |____________________________________________________________________|
     |                                                                    |
     |              SYSTEM LOG                            DATE__________  |
     |____________________________________________________________________|
     |      |   |      |             |     |         |                    |
     |      | R |      |             |     |         |                    |
     |      | E |      |             | F/S |         |                    |
     |      | L |      | MONITOR OR  |  A  |         |                    |
     |      | O |      |  HARDWARE   |  T  | DEVICE  |                    |
     | TIME | A | NAME | MAINTENANCE |  T  |   OR    |       ENTRY        |
     |      | D |      |  ACTIVITY   |  N  | PROGRAM |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    |
     |______|___|______|_____________|_____|_________|____________________|
     |      |   |      |             |     |         |                    | 
     |______|___|______|_____________|_____|_________|____________________|


   Figure 1-2:  Sample System Log (Problem Report)






                                    1-5
                               DOCUMENTATION


   1.2.2  Mountable Structure Sign-Up Log

   In addition to keeping the system log, you should also record requests
   from  users  to  mount structures.  (Chapter 4 describes how to set up
   and use structures.) Without a formal scheduling procedure, some users
   may  monopolize  the use of a structure and frustrate other users, who
   do not have the opportunity to mount and use their structures, usually
   because  there are no disk drives available.  To avoid this situation,
   set up a procedure whereby users inform the operator when they need to
   use  a  structure.   The operator can then schedule the length of time
   specified on the request log.  On a busy  day,  when  many  users  are
   issuing  mount  requests  for  structures, the operator checks the log
   before granting or denying the mount requests.  This scheduling allows
   you  to  service  many  requests for mounting structures in a fair and
   orderly manner.  The sample mountable structure sign-up log  shown  in
   Figure 1-3 contains:

         o  The scheduled mounting time

         o  The scheduled time needed to use the structure

         o  The actual time the structure was mounted

         o  The actual time the structure was removed

         o  The name of the user who initiated the request

         o  The structure name (or pack ID)

         o  A column for any special instructions or notes

   Remember that this log is only a sample; you should design a form that
   best suits your own requirements.



   1.2.3  System Access Request Form

   Some installations have many users requesting access to the system for
   the first time.  You need standard information from these users before
   you can process their requests and create directories for  them.   For
   example,  you  must know which system they need to access (if you have
   more than one system), their names, selected  passwords,  departments,
   accounts,  etc.  You can organize these requests by providing a System
   Access Request Form that is kept in an  easy-to-access  area,  perhaps
   outside  the  computer room.  You can require signatures of department
   managers on the access form to  ensure  that  prospective  users  have
   approval to charge computer usage to accounts.  Figure 1-4 is a sample
   of a system access request form.

   If you are using CFS-20 software, refer to Chapter 12, The Common File
   System, for further considerations in assigning users to systems.


                                    1-6
                               DOCUMENTATION


      ____________________________________________________________________
     |                                                                    |
     |                       MOUNTABLE STRUCTURE                          |
     |                            SIGN - LOG              PAGE__________  |
     |                                                                    |
     |                                                    DATE__________  |
     |____________________________________________________________________|
     |               |                |      |       |                    |
     |    SCHEDULED  |     ACTUAL     |      |       |                    |
     |_______________|________________|      |       |                    |
     |        |      |        |       |      |       |                    |
     |MOUNTING| TIME |MOUNTING| TIME  | USER | PACK  |       NOTES        |
     |  TIME  |NEEDED|  TIME  |REMOVED| NAME | ID(s) |                    |
     |________|______|________|_______|______|_______|____________________|
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    | 
     |        |      |        |       |      |       |                    |
     |        |      |        |       |      |       |                    |
     |________|______|________|_______|______|_______|____________________|


   Figure 1-3:  Sample Mountable Structure Sign-Up Log





                                    1-7
                               DOCUMENTATION


                               SYSTEM ACCESS REQUEST

   SYSTEM NAME:_______________________________ DEPT.:____________________
   YOUR NAME:_________________________________ ACCT.:____________________
   PROJECT:______________________________________________________________

   PERM. ACCESS?  ____YES   ____NO (FROM:______________TO:______________)

   SUPERVISOR:___________________________ MGR:___________________________
                      SIGNATURE                        SIGNATURE
   ----------------------------------------------------------------------

   DIRECTORY NAME (1-39 CHAR.):__________________________________________
                                                       __
   PASSWD.:___________________ DIR. PROT.(DEF.777700) |__| OTHER:________
                                              __      __
   *DO YOU REQUIRE PRIVILEGES ON THE SYSTEM? |__| N  |__| Y (TYPE:______)
                                    __     __
   DO YOU WANT TO CREATE SUBDIRS.? |__| N |__| Y (HOW MANY?_____ MAX.= 8)
                                                                   __
   DO YOU WANT TO BE IN A GROUP WITH OTHER USERS OR DIRECTORIES?  |__| N
    __
   |__| Y (NAME OF USER(S) OR DIR.(S):__________ ___________ ___________)

   BRIEFLY DESCRIBE THE TYPE OF WORK YOU WILL PERFORM. FOR EXAMPLE,
   CREATING AND EDITING FILES, APPLICATIONS PROGRAMMING, COMPILER
   PROGRAMMING, ETC._____________________________________________________
   ----------------------------------------------------------------------
   OPERATIONS USE ONLY
     DIR.      PASSWD.       STRUCTURE       WORKING QUOTA    PERM. QUOTA

   ________  ___________  _______________  _________________  ___________

          USER GROUP                    DIR. GROUP              ACCOUNT

   _________________________    __________________________
   _________________________    __________________________    ___________

      SUBDIRECTORIES       SCHED. CLASS       PRIVILEGES     DATE CREATED

   ____________________  ________________  ________________  ____________

   COMMENTS:_____________________________________________________________
     *MUST BE APPROVED BY OPERATIONS MANAGEMENT


   Figure 1-4:  System Access Request







                                    1-8
                               DOCUMENTATION


   1.2.4  Operator Work Request Form

   You may want a form  that  allows  users  to  request  work  from  the
   operator.   Examples of requests made to the operator are initializing
   tapes, transferring files  between  systems,  and  making  changes  to
   directories.   You  should  set  up  a  procedure  for  handling these
   requests.  Figure 1-5 is a sample of an operator work request form.



   1.2.5  Operator Shift Change Log

   You may want to set up a  binder  to  contain  operator  shift  change
   information.    Each  operator  records  new  procedures,  or  special
   instructions that the incoming operator needs to know.   The  incoming
   operator  reads  the operator shift log before starting the new shift.
   For example, the  first  shift  operator  changes  the  procedure  for
   storing  tapes, and records the new procedure in the shift change log.
   The information in the shift change log should  not  concern  problems
   with  the  system,  but should contain important information about the
   system or the computer room.  The incoming operator  still  reads  the
   system log book to determine the status of the system and any problems
   that have occurred during the previous shift.  Figure 1-6 is a  sample
   of an operator shift change log.






























                                    1-9
                               DOCUMENTATION


                               OPERATOR WORK REQUEST
      _____________________________________________________________________
                                        ||                                
      NAME:____________________________ || NAME OF SYSTEM:_________________
      DIRECTORY NAME:__________________ || PRIORITY: NORMAL_____ RUSH______
      DATE SUBMITTED:__________________ || DEPT. NO.:______________________
      PHONE EXT.:______________________ || ACCOUNT:________________________
      __________________________________||_________________________________
      _____________________________________________________________________
       _______                 |                      |
      |       |                |                      |                   
      | JOB 1 | INPUT _________|OUTPUT ________  DONE |INSTRUCTIONS:
      |_______| _______________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|______________________|____________________
      _________________________|______________________|____________________
      _____________________________________________________________________
       _______                 |                      |
      |       |                |                      |
      | JOB 2 | INPUT _________|OUTPUT ________  DONE |INSTRUCTIONS:
      |_______| _______________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|_______________  ____ |____________________
      _________________________|_______________ |____||____________________
      _________________________|______________________|____________________
      _________________________|______________________|____________________
      _____________________________________________________________________
      OPERATOR:___________________ || OPERATOR COMMENTS:___________________
      ____________________________ ||______________________________________
      SYSTEM:_____________________ ||______________________________________
      ____________________________ ||______________________________________
      DATE COMPLETE:_______________||______________________________________
      _____________________________||______________________________________


   Figure 1-5:  Operator Work Request








                                    1-10
                               DOCUMENTATION


      ____________________________________________________________________
     |                                                                    |
     |                      OPERATOR SHIFT CHANGE LOG                     |
     |____________________________________________________________________|
     |        |          |         |                                      |
     |  DATE  | OPERATOR |  SHIFT  |             COMMENTS                 |
     |________|__________|_________|______________________________________|
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      | 
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |        |          |         |                                      |
     |________|__________|_________|______________________________________|


   Figure 1-6:  Operator Shift Change Log






                                    1-11
























































                                    2-1











                                 CHAPTER 2

                    PREPARING FOR SOFTWARE INSTALLATION



   You can establish  many  of  the  policies  and  procedures  for  your
   computer  site before you install the software.  It may help you later
   if some of the preliminary decisions and preparations are done  before
   you begin setting up the system and handling requests from users.  The
   following  suggestions  for  preparing  your  installation   are   not
   all-inclusive.   Some TOPS-20 installations have specific requirements
   or restrictions that are not considered here.  You can use  this  list
   as  a  guideline  for the types of decisions you can make in the early
   stages of setting up your computer site.



   2.1  SECURING THE COMPUTER ROOM

   Select the type of computer room security you need  and  a  method  of
   enforcement.   Many system managers do not allow non-operations people
   to enter the computer room.  Establish an open- or closed-door policy,
   and  notify  users  of  your  policy.   If you decide on a closed-door
   policy, notify users of the procedures that they should use to contact
   you (or the operator) and to submit their job requests.



   2.2  HANDLING USER REQUESTS

   Determine how user requests will be handled.  You can handle jobs on a
   first-come  basis,  or  on  a  priority basis.  You can set up request
   boxes outside the computer room that the  operator  checks  regularly.
   You  can  also  establish  a  location where users can leave disks and
   tapes for the operator to mount.  Post a sign-up sheet so  that  users
   can  specify  the  time they need the tape or disk mounted.  Chapter 1
   describes sample forms that can  be  completed  by  users  to  request
   initial  access  to the system and to request that work be done by the
   operator.





                                    2-1
                    PREPARING FOR SOFTWARE INSTALLATION


   2.3  ORDERING SUPPLIES

   Assign  someone  the  responsibility  for  ordering  paper   supplies,
   ribbons, cards, and magnetic tapes.  Chapter 7 provides an estimate of
   the number of tapes you  should  have  to  begin  a  backup  procedure
   immediately  after  you install the software.  Be sure you have enough
   CTY (operator terminal) and line printer paper to begin operations.



   2.4  SCHEDULING OPERATOR TASKS

   The operator performs tasks  either  on  a  regular  basis  or  on  an
   as-needed  basis.   Decide which operator tasks will be performed on a
   regular  schedule.   Be  sure  to  include  hardware,  software,   and
   documentation  related  tasks.  These regularly scheduled tasks can be
   performed daily, weekly, or monthly.

   The following lists are  samples  of  hardware-  and  software-related
   tasks that your operator may perform.

                           Hardware-Related Tasks

             Regular Schedule                 As-Needed Schedule
     __________________________________________________________________

     Clean tops of disk drives.        Replenish  paper  in  the  line
                                       printer.

     Clean magnetic tape drives.       Remove  reports  from  the line
                                       printer and distribute (perhaps
                                       to mail boxes).

     Vacuum  line  printer to remove   Replenish paper  in  operator's
     paper chad.                       console.

     Load    mountable    structures   Physically  load   and   unload
     according to a schedule.          magnetic tape and disk drives.
     __________________________________________________________________















                                    2-2
                    PREPARING FOR SOFTWARE INSTALLATION



             Regular Schedule                 As-Needed Schedule

                           Software-Related Tasks
     __________________________________________________________________

     Bring  up  system  after weekly   Bring up system after a crash.
     maintenance.

     Run scheduled batch  production   Maintain  the  batch system for
     jobs.                             users.

     Save the contents  of  disk  on   Save   special  disk  areas  on
     magnetic tape.                    magnetic tape.

     Create  a  system  "crash" tape   Restore  selected   user   disk
     for backup.                       areas as needed.

     Run the SPEAR program for daily   Interact with users.
     error analysis.

     Submit a daily control file for   Create    and    update    user
     accounting.                       directories.

     Create  the  Message-of-the-Day   Monitor disk space.
     with the MAIL program.
     __________________________________________________________________


   Establish a location for keeping the hard-copy output  from  the  CTY.
   Your  Field  Service Representative needs this information if you have
   problems with your system.  Have the operator tear off  the  copy  and
   store it daily.

   Documentation-related tasks include:

         o  keeping a hand-written log of system activities (System Log)

         o  recording operator shift change information  (Operator  Shift
            Change Log)

         o  coordinating  the  mounting  and  dismounting  of  structures
            (Mountable Structure Sign-up Log)

   Chapter 1 describes creating a system log, an  operator  shift  change
   log, and a mountable structure sign-up log.








                                    2-3
                    PREPARING FOR SOFTWARE INSTALLATION


   2.5  SELECTING SYSTEM FEATURES

   Determine the system features  you  want  to  enable  during  software
   installation.  When you install the software, you create a file called
   n-CONFIG.CMD.  This file is read by a start-up program (n-SETSPD) when
   the system is started for the first time and each subsequent time that
   you reload and start the system.  The n-CONFIG.CMD  file  defines  the
   line  speeds  for  your terminals and many system parameters.  Most of
   the decisions you must make concerning the parameters in this file are
   described  throughout  this manual.  As you read each chapter, you can
   list the parameters that you want to place in the  n-CONFIG.CMD  file.
   Many  system  managers  choose  to  introduce  new  pieces of software
   slowly.  Therefore, you may want to disable  some  of  the  parameters
   until  you  have  run  the  new software for awhile.  You can edit the
   n-CONFIG.CMD file to add new software features  to  the  system.   You
   should  edit  the  file  at  a  convenient  time before you reload the
   system.  Then, when the system restarts, the new software features are
   enabled.

                                    NOTE

|          The   operator   can   run   the   n-SETSPD    program
|          interactively  during  timesharing to override many of
|          the n-CONFIG.CMD options, as described in the  TOPS-20
|          Operator's Guide.

   Chapters 3 through 13 describe setting up and maintaining your system.
   Read these chapters thoroughly.  They contain important information to
   help you  make  decisions  both  before  and  after  you  install  the
   software.
























                                    2-4











                                 CHAPTER 3

                        AFTER SOFTWARE INSTALLATION



   3.1  OVERVIEW

   After you install the TOPS-20 software, your system contains  all  the
   directories  and  files  necessary  for  you  to  start  preparing for
   timesharing  and  batch  processing.   This  chapter   describes   the
   directories,  files,  and system logical names created during software
   installation.  Also included are suggestions for  creating  additional
   directories and logical names to assist you and system users.



   3.2  SPECIAL SYSTEM DIRECTORIES

   You initialize the file system during software installation.  At  this
   time,  the  system  automatically creates nine directories on the disk
   that you defined as the system structure.  These directories are:

   <ROOT-DIRECTORY>
   <SYSTEM>
   <SUBSYS>
   <NEW-SYSTEM>
   <NEW-SUBSYS>
   <ACCOUNTS>
   <OPERATOR>
   <SPOOL>
   <SYSTEM-ERROR>

   Sections 3.2.1 through 3.2.7 describe these directories and their use.
   Section  3.2.8 describes additional directories you can create and how
   they are useful.

   Chapter 5  also  describes  creating  directories  and  discusses  the
   structure of directories.






                                    3-1
                        AFTER SOFTWARE INSTALLATION


   3.2.1  <ROOT-DIRECTORY>

   The <ROOT-DIRECTORY> contains a separate  file  for  each  first-level
   directory on the system structure as follows:

                           STR:<ROOT-DIRECTORY>
            --------------------------------------------------
                  |                |                  |
                  |                |                  |
             STR:<SYSTEM> ... STR:<SUBSYS> ... STR:<DIRECTORY>


   (where STR: is the name of the structure).

   The <ROOT-DIRECTORY> is the most important directory created.  Without
   it,  directories  and files cannot be accessed.  You must NEVER modify
   this   directory.    The   system   maintains   a   backup   copy   of
   <ROOT-DIRECTORY>  that  can  be  accessed  if  the  original  copy  is
   destroyed.  (Refer to Section 9.3, RESTORING <ROOT-DIRECTORY>.)

   Each structure you create in addition to the system  structure  has  a
   <ROOT-DIRECTORY>.  The <ROOT-DIRECTORY> on any structure points to all
   the first-level directories created under the <ROOT-DIRECTORY>.

   After you  install  the  software,  give  the  DIRECTORY  command  for
   <ROOT-DIRECTORY>.   The output on your terminal appears similar to the
   example  below.   Note  that  each  directory  is  a   file   in   the
   <ROOT-DIRECTORY>.   The  differences  between this list and the one on
   your terminal depend on the model system you  have  and  the  type  of
   unbundled software you have purchased.


   $DIRECTORY (OF FILES) STR:<ROOT-DIRECTORY><RET>

     STR:<ROOT-DIRECTORY>
   ACCOUNTS.DIRECTORY.1
   BACKUP-COPY-OF-ROOT-DIRECTORY.IMAGE.1
   BOOTSTRAP.BIN.1
   DSKBTTBL..1
   FRONT-END-FILE-SYSTEM.BIN.1
   INDEX-TABLE.BIN.1
   NEW-SUBSYS.DIRECTORY.1
   NEW-SYSTEM.DIRECTORY.1
   OPERATOR.DIRECTORY.1
   ROOT-DIRECTORY.DIRECTORY.1
   SPOOL.DIRECTORY.1
   SUBSYS.DIRECTORY.1
   SYSTEM.DIRECTORY.1
   SYSTEM-ERROR.DIRECTORY.1
   UETP.DIRECTORY.1

   Total of 14 Files


                                    3-2
                        AFTER SOFTWARE INSTALLATION


   3.2.2  <SYSTEM>

   The directory <SYSTEM> contains data and program files that the system
   uses  during normal operation.  Table 3-1 lists many of the files that
   appear in this directory.


   Table 3-1:  <SYSTEM> Files

     __________________________________________________________________

     File Name                  Explanation
     __________________________________________________________________

     0DUMP11.BIN                Contains a dump  of  front-end  memory
                                after the front end crashes.

     2060-MONBIG.EXE            The  smallest   runnable   non-ARPANET
                                monitor.

     2060-MONMAX.EXE            The   largest   runnable   non-ARPANET
                                monitor.

     n-CONFIG.CMD               Contains  definitions  of line speeds,
                                system   logical  names,  printer  VFU
                                files,   magnetic  tape  logical  unit
                                numbers,   DECnet   parameters,    and
                                additional            system-dependent
                                parameters.  These  system  parameters
                                are  set every time the system starts.
                                The  value n equals the latest release
                                of TOPS-20.

     n-PTYCON.ATO               Contains the commands that  are  given
                                automatically   at   the    operator's
                                console every time the system  starts.
                                You may modify this file to suit  your
                                own installation. The value  n  equals
                                the latest release of TOPS-20.

     n-SETSPD.EXE               Program  that  reads  the n-CONFIG.CMD
                                file  and  sets up the parameters that
                                it  contains.  The  value n equals the
                                latest release of TOPS-20.

     n-SYSJOB.EXE               Program that runs in a process created
                                by the monitor and takes commands from
                                the file  n-SYSJOB.RUN.  The  value  n
                                equals the latest release of TOPS-20.





                                    3-3
                        AFTER SOFTWARE INSTALLATION


   Table 3-1:  <SYSTEM> Files (Cont.)


     File Name                  Explanation

     n-SYSJOB.RUN               Contains    commands    that    SYSJOB
                                processes.  The  value  n  equals  the
                                latest release of TOPS-20.

     ACCOUNTS-TABLE.BIN         Contains  the information necessary to
                                validate accounts.

     AN-MONBIG.EXE              The   smallest   ARPANET   timesharing
                                monitor.

     AN-MONDCN.EXE              A monitor that  includes  ARPANET  and
                                DECnet.

     AN-MONMAX.EXE              The   largest   ARPANET    timesharing
                                monitor.

     BUGS.MAC                   Contains a list of all BUGHLT, BUGINF,
                                and BUGCHK messages.

     CHECKD.EXE                 Program  that  creates  structures and
                                checks file-system consistency.

     COMAND.CMD                 An   installation-specific  systemwide
                                COMAND.CMD file.

     DEVICE-STATUS.BIN          Contains  status  information for tape
                                drives,    disk   drives,   and   disk
                                structures.   It   is   maintained  by
                                MOUNTR.

     DUMP.CPY                   Contains a copy of main memory at  the
                                time of the last system crash.  It  is
                                copied from  DUMP.EXE  to  maintain  a
                                history  of  crashes.  This  file   is
                                written by the n-SETSPD  program  when
                                the system is rebooted.

     DUMP.EXE                   Contains a copy of main memory at  the
                                time  of  the  last  system crash. You
                                must have this file to  get  a  system
                                dump after a crash.

     ERRMES.BIN                 Contains binary system error messages.

     EXEC.EXE                   The TOPS-20 Command Processor.




                                    3-4
                        AFTER SOFTWARE INSTALLATION


   Table 3-1:  <SYSTEM> Files (Cont.)


     File Name                  Explanation

     FEDDT.EXE                  A  DDT  program used for debugging the
                                front end.

     HOSTS.TXT                  Defines ARPANET host names  and  their
                                number translations.
|  
|    INTERNET.ADDRESS           Defines  the  system's  TCP/IP address
|                               for AN20, CI20, and NIA20 interfaces.
|  
|    INTERNET.GATEWAYS          Defines   the   network  gateways  for
|                               reaching   host   systems   on  remote
|                               networks.
|  
|    INTERNET.NAMESERVERS       Lists name server hosts.

     IPALOD.EXE                 Program that loads the CI20 microcode.
                                (The microcode  is  contained  in  the
                                file.)    After    the   loading   has
                                completed, TOPS-20 starts the CI.

     KNILDR.EXE                 Program    that    loads   the   NIA20
                                microcode. (The microcode is contained
                                in  the file.) It is run automatically
                                at system startup to start the NI.

     LOGIN.CMD                  An   installation-specific  systemwide
                                LOGIN.CMD file.

     LOGOUT.CMD                 An   installation-specific  systemwide
                                LOGOUT.CMD file.

     MONITR.EXE                 The current monitor.

     MONNAM.TXT                 Contains the monitor name  printed  at
                                the beginning of the  system  greeting
                                line.

     PROGRAM-NAME-CACHE.TXT     Contains  a  list of the programs that
                                should be loaded into the program-name
                                cache. Read by the MAPPER program.

     REAPER.CMD                 Contains a list of default commands to
                                REAPER. The REAPER program reads  this
                                file each time it is run.





                                    3-5
                        AFTER SOFTWARE INSTALLATION


   Table 3-1:  <SYSTEM> Files (Cont.)


     File Name                  Explanation

     RSX20F.MAP                 Contains   symbol  locations  for  the
                                front-end processor. It is used by the
                                FEDDT program.

     SYSJOB.HLP                 Contains  information about the SYSJOB
                                program.

     SYSTEM.CMD                 Contains  OPR  commands and is read by
                                the OPR program at system startup.

     TAPNAM.TXT                 Text    file    that    contains   the
                                installation   identifier   that    is
                                written on  VOL1  labels  for  labeled
                                tapes.

     TGHA.EXE                   Program that analyzes and corrects MOS
                                memory problems.

     TGHA.HLP                   Contains  information  about  the TGHA
                                program.

     TOPS-20.DOC                Text   file   that   contains  summary
                                information  about  the latest release
                                of TOPS-20.
     __________________________________________________________________



   3.2.3  Restoring the Directory <SYSTEM>

   If the contents of <SYSTEM> are accidentally lost  or  destroyed,  you
   can  restore  the directory from the TOPS-20 Installation Tape or your
   latest system backup tape.  (Refer to Chapter 7 for information  about
   creating  system  backup  tapes.)  Use  the procedure below to restore
   <SYSTEM> directory.  If you have enabled tape  drive  allocation,  use
   the  MOUNT  command  instead of the ASSIGN command.  (Refer to Section
   8.3 for information about using tape drive allocation.)

        1.  Mount the appropriate tape (in this example, it is  on  drive
            MTA0:).

        2.  Give the following commands at your terminal.

            @ENABLE (CAPABILITIES) <RET>
            $ASSIGN (DEVICE) MTA0: <RET>
            $SKIP (DEVICE) MTA0: 4 FILES <RET>
            $RUN (PROGRAM) MTA0: <RET>


                                    3-6
                        AFTER SOFTWARE INSTALLATION


            DUMPER> TAPE (DEVICE) MTA0: <RET>
            DUMPER> RESTORE (TAPE FILES) DSK*:<*>*.*.* (TO) <SYSTEM> <RET>

            DUMPER TAPE #1 , , FRIDAY 1-NOV-88 330
            LOADING FILES INTO <SYSTEM>

            END OF SAVESET
            DUMPER>EXIT <RET>
            $



   3.2.4  <SUBSYS>

   The directory <SUBSYS> contains system programs (and their help files)
   that  the user may want to run.  The directory protection code set for
   <SUBSYS> prevents users from changing the  files  in  this  directory.
   Many of the file protections require users to enable WHEEL or OPERATOR
   capabilities to use the files.  (Refer to Chapter  5  for  information
   about  directory and file protections and special capabilities.) Table
   3-2 lists the programs and files  commonly  placed  in  <SUBSYS>.   An
   asterisk precedes all unbundled software.


   Table 3-2:  STR:<SUBSYS> Files

     __________________________________________________________________

     Programs        Explanation
     __________________________________________________________________

     ACTGEN.EXE      Program that takes  information  from  accounting
                     files  and  creates  the  account validation data
                     base.

     ACTGEN.HLP      Contains information about the ACTGEN program.

     ACTSYM.UNV      A file of universal symbols for USAGE  accounting
                     programs.

     ANAUNV.UNV      A file of ARPANET universal symbols.

     *B362LB.REL     BLISS  functions  needed  to  rebuild  the Record
                     Management   Services   facility   (RMS-20)  from
                     AUTOPATCH.

     *BASIC.EXE      The BASIC compiler.

     BATCON.EXE      Program that controls batch jobs.

     CDRIVE.EXE      Program that controls card readers.



                                    3-7
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     CHECKD.EXE      Program  that  creates  structures   and   checks
                     file-system consistency (same as in <SYSTEM>).

     CHECKD.HLP      Contains information about the CHECKD program.

     CHKPNT.EXE      Program that makes accounting entries in the file
                     <ACCOUNTS>CHECKPOINT.BIN.

     CHKPNT.HLP      Contains information about the CHKPNT program.

     CMD.REL         A  library file of routines for the COMND monitor
                     call.

     CMD.UNV         A file of universal symbols for the COMND monitor
                     call.

     *COBDDT.HLP     Contains information about COBDDT.

     *COBDDT.REL     The COBOL debugging program.

     *COBOL.EXE      The COBOL compiler.

     *COBOL.HLP      Contains information about the COBOL compiler.

     CREF.EXE        Program that produces a cross-reference listing.

     CREF.HLP        Contains information about the CREF program.

     DIL.LIB         A library file  of  data  definitions  for  COBOL
                     programs  that  use  the Data Interchange Library
                     (DIL) facility.

     DIL.REL         The DIL subroutines.

     DILV7.FOR       Contains data definitions  for  FORTRAN  programs
                     that use DIL.

     DITV7.FOR       Contains data definitions  for  FORTRAN  programs
                     that use the data transmission component of DIL.

     DIXV7.FOR       Contains data definitions  for  FORTRAN  programs
                     that use the data conversion component of DIL.

     DLUSER.EXE      Program  that  saves  and  restores the directory
                     parameters.

     DLUSER.HLP      Contains information about the DLUSER program.


                                    3-8
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     DUMPER.EXE      Program that saves and restores files to and from
                     magnetic tape.

     DUMPER.HLP      Contains information about the DUMPER program.

     DX20LD.EXE      Program that loads DX20 microcode.

     DXMCA.ADX       Microcode for DX20 tape subsystem controller.

     EDDT.REL        A component of  the  debugging  program  for  the
                     TOPS-20 monitor.

     EDIT.EXE        A line-oriented text editor.

     EDIT.HLP        Contains information about the EDIT program.

     FE.EXE          Program  that is used when copying files from the
                     front-end file system to the TOPS-20 file  system
                     and vice versa.

     FE.HLP          Contains information about the FE program.

     FEDDT.EXE       The debugging program for the front end.

     FILCOM.EXE      Program that compares the contents of two files.

     FILCOM.HLP      Contains information about the FILCOM program.

     FILDDT.EXE      A  DDT program used for examining the contents of
                     system dumps (DUMP.CPY).

     *FORDDT.HLP     Contains information about the FORDDT program.

     *FORDDT.REL     The FORTRAN debugging program.

     FORMAT.EXE      Program used to format RP04/RP06 disk packs while
                     the system is in timesharing mode.

     FORMAT.HLP      Contains information about the FORMAT program.

     *FOROTS.EXE     The FORTRAN object-time system (operating  system
                     interface).

     *FORTRA.EXE     The FORTRAN compiler.

     GALGEN.EXE      Program  that creates the parameter file (GALCNF)
                     for building the GALAXY programs.


                                    3-9
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     GLOBS.UNV       A file  of  universal  symbols  for  the  TOPS-20
                     monitor.

     GLXLIB.EXE      Object-time system used by the GALAXY programs.

     HELP.HLP        Contains information about the HELP command.

     *IBMSPL.EXE     Spooling program that sends  IBM-batch-job  files
                     to remote IBM host and retrieves the output.

     INFO.EXE        Program  that gives information to programs using
                     IPCF.

     *ISAM.EXE       Program that maintains COBOL  single-key  indexed
                     sequential files.

     *ISAM.HLP       Contains information about the ISAM program.

     KDDT.REL        A component of  the  debugging  program  for  the
                     TOPS-20 monitor.

     KNILDR.EXE      Program that loads the NIA20 microcode.

     LCPORN.REL      The LCP subprocess to the OPR program.

     LCPTAB.REL      The LCP command table.

     *LIBARY.EXE     Program  that  creates,  maintains, and lists the
                     contents of COBOL library files.

     *LIBARY.HLP     Contains information about the LIBARY program.

     *LIBO12.EXE     The COBOL object-time  system  (operating  system
                     interface).

     *LIBOL.REL      Contains the COBOL library subroutines.

     LINK.EXE        Program that loads relocatable binary programs.

     LINK.HLP        Contains information about the LINK program.

     LISSPL.EXE      Cluster  LPTSPL  listener  that  receives   print
                     requests from remote cluster LPTSPLs and forwards
                     the requests to QUASAR.

     LP64.RAM        Translation  RAM  file  for  a  64-character line
                     printer. Read by n-SETSPD.


                                    3-10
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     LP96.RAM        Translation  RAM  file  for  a  96-character line
                     printer. Read by n-SETSPD.

     LPTSPL.EXE      Program   that  controls  output  to  local  line
                     printers  as  well  as TTY, LAT, DQS, and cluster
                     printers.

     MACREL.REL      Run-time file for macros in MACSYM.

     MACRO.EXE       The MACRO assembler.

     MACRO.HLP       Contains information about the MACRO assembler.

     MACSYM.UNV      Contains system macros.

     MS.EXE          Program that sends messages to users.

     MS.HLP          Contains information about the MAIL program.

     MS.EXE          Program that receives mail from the MAIL  program
                     and places it in the appropriate mailbox.

     MAKDMP.EXE      Program that produces a standard DUMP.EXE file in
                     <SYSTEM>.

     MAKLIB.EXE      Program   that   creates  relocatable  subroutine
                     libraries.

     MAKLIB.HLP      Contains information about the MAKLIB program.

     MAKRAM.EXE      Program that creates a translation RAM  file  for
                     line printers.

     MAKRAM.HLP      Contains information about the MAKRAM program.

     MAKVFU.EXE      Program  that  creates a vertical formatting unit
                     (VFU) file.

     MAKVFU.HLP      Contains information about the MAKVFU program.

     MAPPER.EXE      Program that loads the program-name cache. (Refer
                     to Section 10.4, Improving Program Startup Time.)

     MDDT.REL        A component of  the  debugging  program  for  the
                     TOPS-20 monitor.




                                    3-11
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     MONSYM.REL      Object  file  that  contains  monitor call symbol
                     definitions.

     MONSYM.UNV      Contains symbol definitions for monitor calls.

     MOUNTR.EXE      Program that mounts tapes and structures.

     MSCPAR.UNV      A  file  of  universal  symbols used to build the
                     MSCP component of the TOPS-20 monitor.

     NEBULA.EXE      The  cluster  GALAXY message router between nodes
                     in a cluster.

     *NFT.EXE        DECnet file transfer program.

     *NFT.HLP        Contains information about the NFT.EXE program.

     *NMLT20         DECnet  program that performs the network control
                     program functions.

     NORMAL.VFU      Vertical formatting unit file for line printers.

     OPR.EXE         Program that the operator uses to interface  with
                     all jobs and devices on the system.

     OPR.HLP         Contains information about the OPR program.

     ORION.EXE       Program that processes messages sent by the  OPR,
                     MOUNTR, LPTSPL, QUASAR, EXEC, etc. programs.

     OVRLAY.REL      Overlay manager for the LINK program.

     PA1050.EXE      The TOPS-10 Compatibility Package.

     PAT.EXE         Version of PA1050 that can be used in debugging.

     PHYPAR.UNV      A   file   of   universal   symbols  for  TOPS-20
                     input/output programs.

     PLEASE.EXE      Program   that  establishes  a  dialog  with  the
                     operator.

     PROLOG.UNV      A  file  of  universal  symbols used to build the
                     TOPS-20 monitor.

     PTYCON.EXE      Program that controls many  jobs  from  a  single
                     terminal.


                                    3-12
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     PTYCON.HLP      Contains information about the PTYCON program.

     QUASAR.EXE      Program   that   does  the  central  queuing  and
                     scheduling for the batch system.

     RDMAIL.EXE      Program that allows a user to read mail sent with
                     the MAIL program.

     RDMAIL.HLP      Contains information about the RDMAIL program.

     REAPER.EXE      Program   that   marks  files  for  migration  to
                     magnetic tape.

     REAPER.HLP      Contains information about the REAPER program.

     *RERUN.EXE      Restarts COBOL programs.

     *RERUN.HLP      Contains information about the RERUN program.

     RETRFB.SPE      Contains SPEAR report templates.

     RFB.EYE         Contains internal definitions  for  the  RETRIEVE
                     function of the SPEAR program.

     RMS.EXE         RMS-20  used  in  Section  0  of  memory  to  get
                     XRMS.EXE.

     RMSCOB.EXE      RMS-20 used by COBOL V12B programs.

     RMSFAL.EXE      Program that 'listens' for DECnet file transfers.

     RMSINI.REL      Routine called by BLISS  and  MACRO  programs  to
                     initialize RMS-20.

     RMSINT.R36      Unsupported BLISS interface file for RMS-20.

     RMSINT.UNV      MACRO interface file for RMS-20.

     RMSUTL.EXE      The RMS-20 file maintenance utility.

     RSXFMT.EXE      Utility program used for converting TOPS-20 files
                     to a format used by the front end and vice versa.

     RSXFMT.HLP      Contains information about the RSXFMT program.

     RUNOFF.EXE      Program that helps with text preparation.



                                    3-13
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     RUNOFF.HLP      Contains information about the RUNOFF program.

     SCAPAR.UNV      A  parameter  file  of  symbols   for   the   SCA
                     inter-system communication routines.

     SDDT.EXE        DDT debugger for programs without a symbol table.

     *SELOTS.EXE     Program  that  interfaces   between   the   COBOL
                     language  and  the   COBOL   object-time   system
                     (LIBOL). (It is used with versions of COBOL up to
                     and including version 11.)

     SERCOD.UNV      Contains definitions for the SYSERR error codes.

     *SIX12.REL      The BLISS debugger.

     *SORT.EXE       Program that sorts files record by record.

     *SORT.HLP       Contains information about the SORT program.

     SPRINT.EXE      Program that creates batch jobs from card input.

     SPROUT.EXE      Output spooler for card punch, paper tape  punch,
                     and plotter.

     SPEAR.EXE       Segment of SPEAR program.

     SPRRET.EXE      Segment of SPEAR program.

     SPRSUM.EXE      Segment of SPEAR program.

     SYSJOB.HLP      Contains information about the SYSJOB program.

     SYSTAP.CTL      Control file that creates a system backup tape.

     TCX.EXE         A DIGITAL Standard Runoff index utility.

     TCX.HLP         Contains information about the TCX utility.

     TERMINAL.HLP    Contains information about the TERMINAL command.

     TOC.EXE         A DIGITAL Standard Runoff utility for creating  a
                     table of contents.

     TOC.HLP         Contains information about the TOC utility.

     TV.EXE          A character-oriented text editor.


                                    3-14
                        AFTER SOFTWARE INSTALLATION


   Table 3-2:  STR:<SUBSYS> Files (Cont.)


     Programs        Explanation

     UDDT.EXE        DDT debugger for programs with a symbol table.

     ULIST.EXE       Program    for    printing    information   about
                     directories and users.

     ULIST.HLP       Contains information about the ULIST program.

     VERIFY.EXE      Program that is used during software installation
                     to determine the integrity of files. It  verifies
                     checksums and version numbers of the .EXE files.

     WATCH.EXE       Program for observing system performance.

     WATCH.HLP       Contains information about the WATCH program.

     *XPORT.REL      Library containing the BLISS  transportable  I/O,
                     memory, and string functions.

     XRMS.EXE        RMS-20 library that  is  mapped  to  an  extended
                     (nonzero) section for execution of RMS functions.
     __________________________________________________________________


                                    NOTE

           All the .HLP files can be  displayed  using  the  HELP
           command; for example, the command @HELP WATCH displays
           the WATCH.HLP file.





















                                    3-15
                        AFTER SOFTWARE INSTALLATION


   3.2.5  Restoring the Directory <SUBSYS>

   If the contents of <SUBSYS> are accidentally lost  or  destroyed,  you
   can  restore  the directory from the TOPS-20 Installation Tape or your
   latest system backup tape.  (Refer to Chapter 7 for information  about
   creating  system backup tapes.) Use the procedure below to restore the
   <SUBSYS> directory.  If you have enabled tape  drive  allocation,  use
   the  MOUNT  command  instead of the ASSIGN command.  (Refer to Section
   8.3 for information about using tape drive allocation.)

        1.  Mount the appropriate tape (in this example, it is  on  drive
            MTA0:)

        2.  Give the following commands at your terminal.

            @ENABLE (CAPABILITIES) <RET>
            $ASSIGN (DEVICE) MTA0: <RET>
            $SKIP (DEVICE) MTA0: 4 FILES <RET>
            $RUN (PROGRAM) MTA0: <RET>

            DUMPER> TAPE (DEVICE) MTA0: <RET>
            DUMPER> SKIP (NUMBER OF SAVESETS) 1 <RET>
            DUMPER> RESTORE (TAPE FILES) DSK*:<*>*.*.* (TO)     <SUBSYS>
            <RET>

            DUMPER TAPE # 1 , , SATURDAY, 3-NOV-88 330
            LOADING FILES INTO STR:<SUBSYS>
            END OF SAVESET

            DUMPER> EXIT <RET>
            $























                                    3-16
                        AFTER SOFTWARE INSTALLATION


   3.2.6  <NEW-SYSTEM> and <NEW-SUBSYS>

   The first time you install the TOPS-20 software,  the  DLUSER  program
   creates  the  directories  <NEW-SYSTEM> and <NEW-SUBSYS>.  They do not
   contain files.  You can use  these  directories  when  a  new  release
   becomes  available  and  you  are  updating the existing system.  When
   DIGITAL distributes an updated monitor  on  the  TOPS-20  Installation
   Tape,  you  restore  the  first  two  savesets  from  this tape to the
   directories <NEW-SYSTEM> and <NEW-SUBSYS> respectively.  You use these
   directories  until you feel comfortable with the new software.  Should
   you have any problems with the new software, you can easily revert  to
   using  the  old  software.   Appendix  A  of  the  TOPS-20  KL Model B
   Installation Guide  detail  the  procedures  to  update  one  software
   release to another.

   If you have no problems with the new monitor, and you are  comfortable
   with  it,  copy  all  the files in the directory <NEW-SYSTEM> into the
   directory <SYSTEM> and all the files  in  the  directory  <NEW-SUBSYS>
   into  the  directory  <SUBSYS>.   You  can now delete all the files in
   <NEW-SYSTEM>  and  <NEW-SUBSYS>.   The  directories  <NEW-SYSTEM>  and
   <NEW-SUBSYS>  remain empty until a new version of the TOPS-20 software
   is distributed.

                                    NOTE

           After you copy the  new  files  into  the  directories
           <SYSTEM>  and  <SUBSYS>,  you cannot revert to the old
           system software unless you reinstall the system  using
           the old monitor or backup tapes.

























                                    3-17
                        AFTER SOFTWARE INSTALLATION


   3.2.7  <ACCOUNTS>, <OPERATOR>, <SPOOL>, and <SYSTEM-ERROR>

   <ACCOUNTS> - After installation, the directory <ACCOUNTS> contains one
   file,  SYSTEM-DATA.BIN.   This file contains all the accounting system
   entries for each user.  If the directory <ACCOUNTS> is destroyed,  the
   accounting system creates a new SYSTEM-DATA.BIN file.

   After  the  first  LOGIN  on  the  system,  the  system  creates   the
   <ACCOUNTS>CHECKPOINT.BIN  file.   This  file stores accounting entries
   for each user during the time the user is logged  in.   After  a  user
   logs  out,  the  accounting data stored in CHECKPOINT.BIN is copied to
   the SYSTEM-DATA.BIN file.  When the system comes up after a crash, the
   monitor  examines  <ACCOUNTS>CHECKPOINT.BIN  to  determine which users
   were logged in at the time of  the  crash,  and  stores  the  data  in
   CHECKPOINT.BIN  in  SYSTEM-DATA.BIN.  Therefore, users who did not log
   out in the normal fashion, because of a crash, are still  charged  for
   their log-in time.

   <OPERATOR> - The  directory  <OPERATOR>  normally  contains  the  file
   PTYCON.LOG.  This file usually contains a record of all the activities
   that occur under the operator jobs that are controlled by PTYCON.  The
   directory  <OPERATOR> may also contain files the operator needs to run
   the system.  <SPOOL> - The directory <SPOOL> contains files  that  the
   spooling system needs before performing any input or output.  They are
   kept in this area until they can be output to a slow-speed device such
   as a line printer.  This area is also used for input of files from the
   local card reader, if one is attached.  It may also be used for  input
   of     files     from     IBM     remote     stations.     The    file
   PRIMARY-MASTER-QUEUE-FILE.QUASAR is created  in  this  directory.   It
   contains  a copy of the input queues so that they are not destroyed if
   the system crashes.  You must either delete this file or  process  all
   entries  in  the  queues  before installing a new version of the batch
   system that  has  a  different  queue  format.   The  GALAXY.DOC  file
   describes  the  new  software  components  and  tells you if the queue
   format has changed.

   <SYSTEM-ERROR>  -  The  directory  <SYSTEM-ERROR>  contains  the  file
   ERROR.SYS.   The  ERROR.SYS  file contains entries about system errors
   and is read by the system error recovery program, SPEAR.



   3.2.8  Other Useful Directories

   You may want to create additional directories  for  storing  different
   versions  of  programs  or  text.   Some useful directories are listed
   below.  You should give these directories the proper protection number
   and make them files-only directories.






                                    3-18
                        AFTER SOFTWARE INSTALLATION


                       Directory and File Protection

   Directories and files that are executed or read  by  the  entire  user
   community  should  not  be  given the default protection 777700, which
   allows no access.  They  should  be  given  the  directory  protection
   777740  and  the  file  protection  777752  or  777712.   (Section 5.7
   describes directory and file protections.)

     <NEW>           The directory <NEW> can contain versions of  your
                     software that are not completely tested  or  that
                     are  drastically  different  from   the   current
                     versions. If you create a directory <NEW>,  users
                     will  find  it more convenient if you also create
                     the   system-logical   name   NEW:   defined   as
                     PUB:<NEW>,   SYS:,   where  PUB:  is  the  system
                     structure. This logical name allows them  to  run
                     all  new  software  by merely typing NEW: and the
                     program name. If there is no file with the  given
                     name  in  <NEW>,  the  system  uses  the  version
                     currently on <SUBSYS>. (Refer to Section 3.3  for
                     a description of logical names.)

     <OLD>           The directory <OLD> can contain the  old  version
                     of software as newer versions appear on <SUBSYS>.
                     If   programs  or  data  do  not  work  with  new
                     software,  the  user  has a chance to correct the
                     problems before the older software is  no  longer
                     available. Users will find it convenient  if  you
                     also  define  the  system-logical  name  OLD:  as
                     PUB:<OLD>,SYS:,  where   PUB:   is   the   system
                     structure.

   By creating the directories <NEW> and <OLD>, you  gradually  introduce
   new  software  to system users.  When a new version becomes available,
   place it in the directory <NEW>.  When the software has  been  in  use
   awhile,  move  the  version  in  <NEW> to <SUBSYS>, and the version in
   <SUBSYS> to <OLD>.  Store the version in <OLD>  on  a  system  back-up
   tape.   Every  time  you  change a version of the software, you should
   send a system-wide message to all users.

     <HELP>          The  directory <HELP> contains documents and help
                     files  that  describe  the  system  software.  As
                     different  versions   of   software   appear   on
                     <SYSTEM>, <NEW>, and <OLD>,  you  should  make  a
                     list of changes incorporated in the new  versions
                     and  place  it  in  the directory <HELP>. You can
                     move  all  files  with  the  file  type .HLP from
                     <SUBSYS>   to  the  directory  <HELP>.  The  HELP
                     command still works correctly if you  define  the
                     system-logical name HLP: to  be  PUB:<HELP>,SYS:,
                     where PUB: is the system structure.



                                    3-19
                        AFTER SOFTWARE INSTALLATION



     <REMARKS>       The directory <REMARKS>  contains  messages  from
                     users to the operator. These messages are usually
                     general  system  comments  or  complaints. When a
                     user  wants  to  send the operator a message that
                     does not require an immediate  response,  he  can
                     send a message to the directory  <REMARKS>  using
                     the MAIL program. (Refer to  the  description  of
                     the MAIL program in the  TOPS-20  User  Utilities
                     Guide.)  A  typical  message may be a request for
                     supplies,  for  example,  LA36  paper  or ribbon.
                     Creating the directory <REMARKS> avoids  constant
                     interruptions  to the operator from users issuing
                     PLEASE   requests.  The  operator  can  read  the
                     messages in <REMARKS> at a  specified  time  each
                     day, or simply when he has time.



   3.3  SYSTEM-LOGICAL NAMES

   A logical name is a descriptive word used to establish a search  route
   to locate files.  It can be up to 39 alphanumeric characters; however,
   it is usually three to six alphanumeric characters.   Because  logical
   names are used in place of device names, they always end with a colon.
   Logical names tell the system where and in what order  to  search  for
   files.   When  a  user  types  a logical name, the system searches the
   directories in the order they were defined or listed  by  the  logical
   name.   Although  users  can  define  logical  names for their own use
   (refer to the TOPS-20 User's Guide), the logical names described  here
   can be used by all users of the system.  You can define system-logical
   names in the n-CONFIG.CMD file.

   During installation, several systemwide logical names are  defined  by
   the monitor, and may be overridden in the n-CONFIG.CMD file.  They are
   SYS:, defined as PUB:<NEW-SUBSYS>, PUB:<SUBSYS>; SYSTEM:,  defined  as
   PUB:<NEW-SYSTEM>,     PUB:<SYSTEM>;    DEFAULT-EXEC:,    defined    as
   SYSTEM:EXEC.EXE; and POBOX:, defined as the public  structure.   (PUB:
   is the system structure.) You may decide to add other logical names to
   aid users in accessing files.  If you want the  logical  names  to  be
   permanent,   place   the   definitions   (using   an  editor)  in  the
   <SYSTEM>n-CONFIG.CMD file on the system structure.

   SYSTEM:, SYS:, DEFAULT-EXEC:, POBOX:, and some other  frequently  used
   system-logical names are explained below.









                                    3-20
                        AFTER SOFTWARE INSTALLATION


   3.3.1  SYSTEM:

   The logical name, SYSTEM:, defines a search list that contains all the
   system  programs  and files that the system needs to operate.  SYSTEM:
   should always contain the directory <SYSTEM> on the system  structure.
   If  you  are updating the system with a new monitor, the definition of
   SYSTEM:   in  the  n-CONFIG.CMD  file  also  contains  the   directory
   <NEW-SYSTEM>.  For example,

   DEFINE SYSTEM:  STR:<NEW-SYSTEM>,STR:<SYSTEM>

   where:

   STR:  is the name of the system structure.



   3.3.2  SYS:

   The logical name SYS:  defines a search list  that  contains  all  the
   system  programs  a user may want to run.  SYS:  should always contain
   the directory <SUBSYS> and any other library directories that  contain
   commonly  used  programs.   If  you are updating the system with a new
   monitor, the  definition  of  SYS:   in  the  n-CONFIG.CMD  file  also
   contains the directory <NEW-SUBSYS>.  For example,

   DEFINE SYS: STR:<NEW-SUBSYS>,STR:<SUBSYS>

   where:

   STR:  is the name of the system structure.

   Be sure to set the protection on the library  files  in  <SUBSYS>  (or
   <NEW-SUBSYS>) to 777740.  This protection allows access by all users.



   3.3.3  NEW:

   The logical name NEW:  defines a search list  containing  a  directory
   that  has new software, followed by the system-logical name SYS:.  The
   definition for this, which you  would  put  in  n-CONFIG.CMD,  is  the
   following:

   DEFINE NEW: STR:<NEW>,SYS:









                                    3-21
                        AFTER SOFTWARE INSTALLATION


   With this systemwide logical name, the user can give the command:

   @DEFINE (LOGICAL NAME) SYS: (AS) NEW: <RET>

   Now, when the user runs a program,  the  system  looks  first  in  the
   directory  STR:<NEW>,  and then in the normal system search list SYS:.
   This way, the user always gets the most recent version of any program.



   3.3.4  OLD:

   If you have old versions of programs, defining the system-logical name
   OLD:   may  be  helpful to users.  The usual definition of the logical
   name OLD:  is:

   DEFINE OLD: STR:<OLD>,SYS:

   The definition OLD:  has the same type of  effect  as  the  definition
   NEW:.  If the user gives the command:

   @DEFINE (LOGICAL NAME) SYS: (AS) OLD:<RET>

   whenever he runs a program, he will get the oldest version available.



   3.3.5  HLP:

   If  you  want  to  keep  programs  and   documentation   in   separate
   directories,  you  should store the documentation in <HELP>.  The HELP
   command searches the directories identified by the logical name  HLP:,
   so you must define the logical name HLP:  to be the directory <HELP>.

   The definition of HLP:  in n-CONFIG.CMD should be:

   DEFINE HLP:  STR:<HELP>



   3.3.6  SERR:

   The logical name SERR: is defined by the system at startup.  It points
   to the area <SYSTEM-ERROR> on the system structure.  The system writes
   the ERROR.SYS file to this area, which may be used  later  to  produce
   reports.








                                    3-22
                        AFTER SOFTWARE INSTALLATION


   3.3.7  DMP:

   When the system is re-booted after  a  crash,  the  file  DUMP.EXE  is
   overwritten  with a copy of memory.  Upon system startup, the n-SETSPD
   program copies the contents of DUMP.EXE to  the  DUMP-version-name.CPY
   file on the system structure (name is the name of the bug, and version
   is the edit number of the monitor that was running at the time of  the
   crash).   System  crashes  cause  DUMP.EXE  to be overwritten, but new
   versions of the .CPY file accumulate.  To keep  the  system  structure
   clear of .CPY files, define DMP:  in the n-CONFIG.CMD file as follows:

   DEFINE DMP:  STR:<DIRECTORY>

   The structure and directory are your choice; you should not specify  a
   filename.   Versions  of  the  .CPY  file  hereafter accumulate in the
   defined area.

   In  CFS  configurations,   systems   should   not   share   a   common
   DMP: definition, because this could lead to confusion about which dump
   came from which system.

   If the DUMP-ON-BUGCHK feature is enabled, the n-SETSPD program is  run
   after  continuable  system  errors,  and  it  copies  to DMP:  all new
   DUMP.EXE files that it finds from its  scan  of  dumpable  structures.
   Refer to Section 9.10 for complete information on DUMP-ON-BUGCHK.

   As n-SETSPD copies a file to the area defined  by  DMP:,  it  sends  a
   message to the CTY specifying where it's copying the file to and from.
   For example:

   Copying system dump
           from:  STR:<SYSTEM>DUMP.EXE.1
           to:    PS60:<DUMPS>DUMP-12345-WSPNEG.CPY.1



   3.3.8  DEFAULT-EXEC:

   The logical name DEFAULT-EXEC: defines a search list  that  points  to
   the  TOPS-20  Command Processor (EXEC).  When users log in or give the
   PUSH command, the EXEC program is activated.  Some  experienced  users
   may  choose  to  run  their  own  copies of the EXEC, not the standard
   system version.  Such users can define DEFAULT-EXEC:  to be  the  file
   name  for  their  private EXEC, and can take advantage of this feature
   after giving the PUSH command.  This command must be given at the EXEC
   level,  while in batch or interactive mode.  PUSH commands issued from
   other program levels may invoke the standard  system  version,  unless
   the  program  has  been written to use DEFAULT-EXEC: if it is defined.
   By default, DEFAULT-EXEC:  is defined as SYSTEM:EXEC.EXE.

   Refer to the DECSYSTEM-20 Technical Summary and the  TOPS-20  Commands
   Reference Manual for more complete information on the EXEC.


                                    3-23
                        AFTER SOFTWARE INSTALLATION


   3.3.9  POBOX:

   The  logical  name  POBOX:  defines  a  search  list  that  points  to
   structures  where  users' mail files reside.  Mail sent to a user goes
   to the first MAIL.TXT.1 file in the user's directory that  the  system
   encounters in its search.

   By default, POBOX: is  defined  as  the  public  structure.   You  can
   redefine  POBOX:  in the n-CONFIG.CMD file.  By redefining POBOX:, you
   can prevent users' mail files from filling up the public structure.

   In CFS-20 configurations, redefining POBOX: is especially useful.  You
   can   define  POBOX:  to  be  the  same  structure  for  all  systems,
   establishing  a  central  location  for  all   mail   files   in   the
   configuration.   Then,  no matter what system users log onto, they are
   automatically directed to this one area when  they  give  commands  to
   access  their  mail.   They  do  not  have  to spend time logging onto
   various systems to access mail that would otherwise have been sent  to
   a  public  structure  (which  is  a separate structure for each system
   unless the "login structure" feature is  enabled).   To  set  up  this
   central  location,  the  same DEFINE command should be entered in each
   system's n-CONFIG.CMD file.  Refer to  Chapter  12,  The  Common  File
   System, for further information on CFS-20.



   3.3.10  NRT:

   The logical name NRT: (Network Remote Terminal) is applicable only  if
   your  system  has  DECnet communications software.  When a user issues
   the SET HOST command to connect to a remote system,  the  CTERM-SERVER
   communications program is run by default.  If the remote node does not
   support CTERM, the host system tries to connect the user  again,  this
   time using the program defined by NRT:.

   Examples

        1.  For TOPS-20 to TOPS-20  communications,  give  the  following
            definition:

            DEFINE NRT: SYS:SETHOST.EXE

        2.  For multi-operating system  DECnet  communications,  you  can
            specify the HOST program (located on the TOPS-20 tools tape):

            DEFINE NRT: HOST.EXE








                                    3-24
                        AFTER SOFTWARE INSTALLATION


   3.3.11  SPOOL:

   The logical name SPOOL:  directs the system to the  directory  <SPOOL>
   on  the  system  structure.   The GALAXY batch and spooling components
   read and write files in this area.  Also, the monitor  writes  spooled
   files  to  this area.  (Section 3.2.7 contains detailed information on
   <SPOOL>.



   3.4  CONSOLE FRONT-END FILES

   The console front-end computer consists of a PDP-11  with  28K  16-bit
   words  of  memory.  When the system is brought up for timesharing, the
   front-end monitor, RSX20F, is loaded in the PDP-11 memory and started.
   The  TOPS-20 monitor is loaded in KL10 main memory and started.  Thus,
   you have two computers working together.  Both  computers  have  their
   own monitor and related software.

   The front-end file system consists of the RSX20F monitor  and  related
   programs  (tasks)  and  files.   During  software  installation, these
   front-end files are transferred from floppy disks to a special area on
   the  system  structure  unless  an  RP07  is  being used as the system
   structure.  If an RP07 is being used as the system structure, only the
   files  on  the  TOPS-20  Installation Tape will be placed on the RP07.
   The front-end files,  on  the  floppy  disks,  must  be  placed  on  a
   dual-ported  RP06 disk drive attached to the PDP-11 front end.  (Refer
   to the TOPS-20 KL Model B Installation Guide  for  the  procedure  for
   creating  the  front-end  file system when using an RP07 disk drive as
   the system structure.)

   The area the front-end files are placed on  is  called  the  FRONT-END
   FILES  area,  or FILES-11 area.  Once this area has been set-up, there
   is normally no need to get these files again from floppy  disks.   The
   floppy  disks used to install the system become backup devices in case
   the system structure is destroyed, or in the case  where  an  RP07  is
   being  used as the system structure, they can be used to recreate your
   front-end file structure.  It is a good idea to make an extra copy  of
   your  installation floppies in the event one of your original floppies
   is destroyed and you need to restore the FRONT-END FILES area.   Refer
   to  Chapter  7, System Backup Procedures, for a description of the COP
   program that is used to copy floppy disks.

   As previously stated, the front-end files must always be placed  on  a
   dual-ported  RP06  attached  to the PDP-11 front end.  This allows the
   front-end processor to access these files  while  the  main  processor
   accesses TOPS-20 files on the same or different disk packs.







                                    3-25
                        AFTER SOFTWARE INSTALLATION


   The RSX20F monitor and its related programs do the following:

         o  Control input/output and communications devices.

         o  Interface with the main computer.

         o  Load the  TOPS-20  monitor  at  system  startup,  and  reload
            TOPS-20 if a crash occurs.

         o  Report system errors to TOPS-20.

         o  Perform system diagnostic functions.

   Table 3-3 lists the programs and files located in the FRONT-END  FILES
   area,  with a brief description of each.  Files with the file type TSK
   are programs that can be run under the front-end monitor RSX20F; files
   with the type MCB contain the microcode for the host processor (KL10);
   files with the type EXB  are  bootstrap  programs  used  to  load  the
   TOPS-20  monitor; and files with the type CMD are programs that record
   information about system errors.  This  information  is  read  by  the
   system  error recovery program, SPEAR.  Beginning with TOPS-20 Version
   6,  console  front-end  filenames  include  edit-level  numbers   that
   indicate  the  versions  of  the  particular  programs,  for  example,
   F11ACP.TSK;1505.


   Table 3-3:  Console Front-End Files

     __________________________________________________________________

     File            Contents or Function
     __________________________________________________________________

     BF16N1.A11      MOS memory-timing RAM file. It is a nonexecutable
                     file containing MOS memory data.

     BF64N1.A11      Timing file for 64K RAM chips.

     BOO.TSK         Used to boot RSX20F.

     BOOT.EXB        The central processor disk bootstrap program that
                     boots TOPS-20 from disk.

     CLOCK.CMD       Saves contents of memory locations for diagnosing
                     errors   that  are  purposely  induced  by  Field
                     Service.

     COP.TSK         Copies the contents of floppy disks.

     CRAM.CMD        Saves contents of memory locations for diagnosing
                     CRAM parity errors.



                                    3-26
                        AFTER SOFTWARE INSTALLATION


   Table 3-3:  Console Front-End Files (Cont.)


     File            Contents or Function

     DEX.CMD         Saves contents of memory locations for diagnosing
                     Deposit Examine failures (PI level 0 interrupt).

     DMO.TSK         Dismounts a front-end device and allows a reboot.

     DRAM.CMD        Saves contents of memory locations for diagnosing
                     DRAM parity errors.

     EBUS.CMD        Saves contents of memory locations for diagnosing
                     EBUS parity errors.

     FMPAR.CMD       Saves contents of memory locations for diagnosing
                     fast memory parity errors.

     F11ACP.TSK      File handler for front-end disk files.

     HALT.CMD        Saves contents of memory locations for diagnosing
                     KL halt errors.

     INI.TSK         Initializes a front-end files area.

     KLDISC.TSK      Provides the KLINIK line disconnect service.

     KLI.TSK         KLINIT  program  for  initializing  the   central
                     processor  (KL20).  Loads  microcode,  configures
                     cache and main memory, loads bootstrap.

     KLRING.TSK      Provides the KLINIK line ring service.

     KLX.MCB         KL10 microcode file.

     KPALV.CMD       Saves contents of memory locations for diagnosing
                     keep alive cease errors.

     LHALT.CMD       Saves contents of memory locations for diagnosing
                     KL  halt  errors.  Provides more information than
                     HALT.CMD

     LOGXFR.TSK      Transfers  the  PARSER.LOG  file  to  the TOPS-20
                     error file.

     MIDNIT.TSK      Updates the time of day through midnight.

     MOU.TSK         Mounts a device for use with the front end.

     MTBOOT.EXB      Boots a TOPS-20 monitor from magnetic tape.



                                    3-27
                        AFTER SOFTWARE INSTALLATION


   Table 3-3:  Console Front-End Files (Cont.)


     File            Contents or Function

     PARSER.TSK      The  front-end command parser (prompts PAR>). The
                     primary means of access to front-end programs.

     PIP.TSK         Front-end program for file transfer.

     RED.TSK         Tells  the system where to look for the front-end
                     files device, SY0:.

     RP2DBT.EXB      A front-end BOOT file  with  the  DX20  microcode
                     loaded for the RP20 disk sybsystem.

     RP2MBT.EXB      A front-end MTBOOT file with the  DX20  microcode
                     loaded for the RP20 disk sybsystem.

     RSX20F.MAP      Contains symbolic definitions for RSX20F.

     RSX20F.SYS      Virgin image of front-end monitor (RSX20F).

     SAV.TSK         Saves  the  front-end  monitor  and  bootstrap on
                     disk.

     SETSPD.TSK      Sets system parameters, such as line speeds.

     TIMEO.CMD       Saves contents of memory locations for diagnosing
                     protocol timeout errors.

     TKTN.TSK        Terminates tasks, reports  errors,  and  requests
                     reloads.

     T20ACP.TSK      Interfaces between  front-end  and  TOPS-20  file
                     systems.

     UFD.TSK         Sets  up  user-file  directories in the front-end
                     files area.

     ZAP.TSK         Makes binary modifications to task images.
     __________________________________________________________________












                                    3-28
                        AFTER SOFTWARE INSTALLATION


   3.5  TAILORING THE BATCH SYSTEM

   Most installations use the parameters and defaults in the  distributed
   version  of  the  batch system.  However, you can modify some of these
   parameters if required by the  batch  processing  procedures  at  your
   installation.

   DIGITAL distributes a program with the TOPS-20  software  that  allows
   you  to  tailor  the standard batch system to the requirements of your
   installation.  This program, called  GALGEN.EXE,  is  located  in  the
   directory <SUBSYS> on the system structure.  You can run GALGEN at the
   time the system software is installed or at a later date.   In  either
   case,  you  must have a working batch system before you can generate a
   new one using GALGEN.  This means if you are  installing  the  system,
   you must first install the batch system that is distributed with every
   new version of the TOPS-20  software  (on  the  software  installation
   tape).   You  can  then  run  the  GALGEN program and tailor the batch
   system before it becomes available for general use.

   If you tailor the batch system at a later date, you can run the GALGEN
   program with users logged in.  However, for safety reasons, the system
   should be stand-alone during the critical phase of  stopping  the  old
   batch  system  and  starting  the new one.  The batch queues, however,
   need not be empty.  That is, batch jobs can be waiting to be processed
   at the time you bring the system down.

   The TOPS-20 KL Model B Installation Guide contains the procedures  for
   running the GALGEN program.



   3.6  CHECKING THE SOFTWARE (UETP)

   After the system software is installed, you or the Software Specialist
   can  run  the  User  Environment  Test  Package  (UETP).   UETP  is  a
   collection of programs, data files, and batch control  files  designed
   to  allow  you  to  test the integrity of various system elements.  In
   addition to testing that the hardware  has  been  properly  installed,
   UETP ensures that the TOPS-20 Operating System is running and that the
   languages you have selected for your operation are available.

   UETP creates a moderate load on  the  system,  consisting  of  various
   defined  procedures  that  closely  resemble  the  load  in  an actual
   operation.  Later, you may want to tailor UETP to test a software load
   that more closely resembles your particular system's use.

   The TOPS-10/TOPS-20 User Environment  Test  Package  Reference  Manual
   describes  UETP,  the  individual  component  tests,  typical  message
   information, and the procedures for adding new tests.





                                    3-29
                        AFTER SOFTWARE INSTALLATION


   3.7  REMOTE PRINTERS

   The DECSYSTEM-20s at your site may be included in  a  DECnet  network,
   local area network, or CFS-20 cluster.  These networks provide TOPS-20
   users with numerous printing options.  Users, not restricted to  local
   printers on the systems they logged in to, can direct output to remote
   printers attached to:

         o  VMS systems in a DECnet network -- Distributed Queue  Service
            (DQS) printers.

         o  LAT servers in a local area network -- LAT printers.

         o  Other  TOPS-20  systems  in  a  CFS-20  cluster  --   cluster
            printers.







































                                    3-30
                        AFTER SOFTWARE INSTALLATION


   3.7.1  Remote Printing Requirements


         o  Use of DQS printers requires DECnet.

         o  Use of LAT printers requires a LAT server  running  at  least
            Version  5.1  of  the  LAT  protocol.   Digital-supported LAT
            printers must be one of the following devices:   LA50,  LA75,
            LA100, LA120, LN03.

            When starting up a LAT printer, the  operator  must  enter  a
            description      for      the      printer      with      the
            /TERMINAL-CHARACTERISTIC:  switch to  the  OPR>START  PRINTER
            command.   (If  the switch is omitted, the system prompts the
            operator for this information.) You or  a  system  programmer
            must  establish  values for the switch argument in the LPTSPL
            module, LPTUSR.MAC.  Instructions for doing this are included
            in the GALAXY documentation file.

         o  Use of a remote cluster printer requires DECnet.

            In addition, "cluster GALAXY" must be  enabled  on  both  the
            requesting and serving systems if users are to have access to
            the full set of remote-printer  functions.   These  functions
            include:   obtaining  information  on  remote  print  queues,
            canceling remote print requests, and  receiving  notification
            of queuing and completing of the remote print job.

            A system that is servicing remote cluster print jobs must run
            LPTSPL and LISSPL.

            A system that is sending print jobs to a system that services
            them  must  run LPTSPL.  A cluster printer must be started on
            this system also.  For example, if system  SYSA  sends  print
            requests  to  system  SYSB,  the operator gives the following
            command from SYSA:

            OPR>START PRINTER CLUSTER unit number NODE SYSB<RET>

            where:

                unit number designates a printer at SYSB

            Refer to the TOPS-20 KL Model B Installation  Guide  and  the
            TOPS-20   Operator's   Guide   for   further  information  on
            installing and enabling cluster printing.








                                    3-31
                        AFTER SOFTWARE INSTALLATION


   3.7.2  Defining DQS and LAT Printers

   To specify  a  DQS  or  LAT  printer  with  the  PRINT/REMOTE-PRINTER:
   command,   users   must   first  define  that  printer  with  the  SET
   REMOTE-PRINTING PRINTER command, which  indicates  where  the  printer
   resides in the network.  It can provide a useful alias for the printer
   as well.  Users can issue the command interactively at the terminal or
   from a jobwide command file.

   More conveniently, however, users can  invoke  the  command  for  each
   available printer from a systemwide command file that you create.  You
   should name this file REMOTE-PRINTING.CMD and place it in the  SYSTEM:
   area.   Users  can  invoke  the  commands  in  this file with the TAKE
   command or the SET REMOTE-PRINTING SYSTEM-DEFINITIONS  command.   (You
   can  also place these commands in <SYSTEM>COMAND.CMD if all users on a
   system are expected to want to use this facility.) Here  is  a  sample
   systemwide printer-definition file:

   SET REMOTE-PRINTING PRINTER LN03    SWE$LN03 SYSA
   SET REMOTE-PRINTING PRINTER LISTING SI$8700  SYSB
   SET REMOTE-PRINTING PRINTER LATOP   LC14     LAT99

   The SET REMOTE-PRINTING PRINTER  command  has  three  arguments.   The
   first  argument  assigns  an  alias to the remote printer.  The second
   argument is the name of a VMS printer queue (SWE$LN03) or a  LAT  port
   or   service   (LC14)   or   the   name  of  an  existing  alias  (SET
   REMOTE-PRINTING PRINTER LAT03 LN03).  The third argument is  the  name
   of the system or LAT server that controls the printer.

   Refer  to  the  TOPS-20  Commands  Reference  Manual  for  a  complete
   description of the command.

   The REMOTE-PRINTING.CMD file can also contain specifications  for  DQS
   printing characteristics, as described in section 3.7.3.




















                                    3-32
                        AFTER SOFTWARE INSTALLATION


   3.7.3  Setting DQS Printing Characteristics

   Users can specify how they want their DQS printed  output  to  appear.
   For  example,  they  may  desire  a  "landscape"  or  "portrait"  page
   orientation, or 65 or 90 characters per line.  They can specify  these
   and  other  characteristics  with  the  PRINT/CHARACTERISTICS command.
   However, the printing characteristics must first be  established  with
   the  SET  REMOTE-PRINTING  CHARACTERISTIC  command.   Like the printer
   definitions described in Section 3.7.2, the  printing  characteristics
   can  be  established  by  invoking  the  appropriate  command from the
   terminal, a jobwide command file,  or  the  systemwide  command  file,
   SYSTEM:REMOTE-PRINTING.CMD.

   Here  is  a   systemwide   command   file   that   contains   printing
   characteristics and printer definitions:

   SET REMOTE-PRINTING CHARACTERISTIC PORTRAIT 52
   SET REMOTE-PRINTING CHARACTERISTIC P65       59
   SET REMOTE-PRINTING CHARACTERISTIC P75       53
   SET REMOTE-PRINTING CHARACTERISTIC P80       58
   SET REMOTE-PRINTING CHARACTERISTIC P90       52
   SET REMOTE-PRINTING CHARACTERISTIC P100      51
   SET REMOTE-PRINTING CHARACTERISTIC P132D    54
   SET REMOTE-PRINTING CHARACTERISTIC LANDSCAPE 0 
   SET REMOTE-PRINTING CHARACTERISTIC L100      50
   SET REMOTE-PRINTING CHARACTERISTIC L132      0 
   SET REMOTE-PRINTING CHARACTERISTIC TR10P_BOLD 61
   SET REMOTE-PRINTING CHARACTERISTIC TR14P_BOLD 62
   SET REMOTE-PRINTING CHARACTERISTIC TR18P_BOLD 63
   SET REMOTE-PRINTING CHARACTERISTIC CONDENSED 100
   SET REMOTE-PRINTING CHARACTERISTIC OVERHEAD 101

   SET REMOTE-PRINTING PRINTER   LISTING SI$8700   SYSA
   SET REMOTE-PRINTING PRINTER   LN03    CS$LN03   SYSB
   SET REMOTE-PRINTING PRINTER   LATOP   LC14      LAT99

   The SET REMOTE-PRINTING CHARACTERISTIC command has two arguments.  The
   first argument is the name of a characteristic, for example, PORTRAIT,
   or P90 (portrait orientation with 90 characters per line).  The second
   argument  is  the  numeric  value  that your site has assigned to that
   characteristic for the particular printer queue or to the name  of  an
   existing characteristic.

   You can also place this command in the <SYSTEM>COMAND.CMD file if  all
   users on a system are expected to want to use this facility.

   Refer  to  the  TOPS-20  Commands  Reference  Manual  for  a  complete
   description of the command.






                                    3-33
                        AFTER SOFTWARE INSTALLATION


   3.8  TERMINAL PRINTERS

   Your site may have printers attached to dedicated, hardwired  terminal
   lines,  such  as  an  LA50, LA100, LA120-RA, or LA120-RB.  These local
   printers are called terminal printers.  The operator starts them  with
   the following command:

   OPR>START PRINTER unit/DEVICE:TTYn/TERMINAL-CHARACTERISTIC:<RET>

   where:

            unit is the number that designates a printer

            n is the terminal line number

   You or a system programmer must assign a descriptive value to each  of
   these  printers  in  the  LPTSPL module, LPTUSR.MAC.  Instructions for
   doing this  are  included  in  the  GALAXY  documentation  file.   The
   argument  that  the  operator  gives  to the /TERMINAL-CHARACTERISTIC:
   switch with the OPR>START  PRINTER  command  must  match  a  value  in
   LPTUSR.MAC.

































                                    3-34











                                 CHAPTER 4

                            CREATING STRUCTURES



   4.1  OVERVIEW

   One of the first decisions you must make about your new (or  upgraded)
   installation  is what type of disk storage environment best suits your
   needs.  Some of the considerations that determine your decision are:

         o  How large will the data base be?

         o  How many users will be using the system?

         o  How experienced will these users be?

         o  Will there be a full-time operator?

         o  How often will you run diagnostics and  how  critical  is  it
            that the system remain available during this maintenance?

         o  Must all files be available to all users at all times  during
            system operation?

         o  Are multiple systems part of a CFS configuration?  Refer also
            to Chapter 12, The Common File System.

   The mountable structure facility of TOPS-20 provides  several  options
   for  making  this  decision.   The  option  you  choose depends on the
   answers to the previous questions and the number  of  disk  packs  and
   drives  that  are  available.  For example, if your installation has a
   number of disk packs and two or more drives, you can  store  data  and
   program files on different structures.

   A structure is a collection of data and program files contained on one
   or more disk packs and referenced under one name.

   When you install your software, you create a structure  known  as  the
   system  structure (sometimes called the boot structure).  All packs in
   this structure remain on-line at all times  during  system  operation.
   If  your  system  structure  does  not encompass all of your available
   drives you can create and mount other structures.

                                    4-1
                            CREATING STRUCTURES


   Sections 4.2 through 4.8 describe the system structure and how you can
   best utilize your disk resources and create and use other structures.



   4.2  THE SYSTEM STRUCTURE

   Sections 4.2.1 and 4.2.2  provide  an  overview  of  what  the  system
   structure  is,  including  its  relationship  to  the  system  and its
   contents.

                                    NOTE

           Unless you have enabled the "login structure"  feature
           in   a  CFS-20  configuration,  described  in  Section
           12.6.2, the public, system, boot, and login structures
           all denote the same structure.



   4.2.1  What Is the System Structure?

   The system structure is the most important structure on  your  system.
   It  is  created  and  brought  on-line at system installation when you
   answer the appropriate questions in the installation  dialog.   (Refer
   to  the TOPS-20 KL Model B Installation Guide.) The name of the system
   structure can be up to six characters.

   The system structure can be one or more disk packs, depending  on  the
   configuration  of  your system and your disk drive resources.  You may
   use one or more RP06 or  RP07  disks  as  the  system  structure;  the
   maximum  number of disks per structure is given in Table 4-4.  You may
   NOT use an RA60, RA81, or RP20 as the system structure.

   While installing the software, you copy the console front-end files to
   the  system  structure  pack  that  is  mounted on a dual-ported drive
   (usually drive 0).  The dual port allows the front-end  processor  and
   the  central  processor  to  access  the data on the system structure.
   However, if you are using an RP07 as the system  structure,  you  must
   reserve  space  for  the  front-end  files  on  an  RP06  disk that is
   dual-ported to the PDP-11 front end.  If the disk structure containing
   the  front-end  files  has  multiple  packs,  the  first  pack  of the
   structure must be permanently mounted on the dual-ported drive.

   All disk packs in the system structure must be online  at  all  times,
   because  this structure contains all the programs, files, and swapping
   area that the system needs to operate.  The  structure  also  contains
   all  user  directories  necessary  to  support  users logging into the
   system.  (If the "login structure" feature  is  enabled  in  a  CFS-20
   configuration, the login structure contains these directories and must
   also be online at all times.) If the file system is destroyed  on  the
   system  structure,  or  if  a  drive  that contains all or part of the
   structure malfunctions, the system halts.  Refer to Chapter 9 in  this

                                    4-2
                            CREATING STRUCTURES


   manual  and to the TOPS-20 Operator's Guide for the steps that you and
   the operator must follow if you have problems with the file system  or
   if a drive goes down.

   You can have another structure online that is capable of being used as
   the  system  structure.   This  structure  must  have  a  unique name,
   however, at least  while  it  is  mounted.   (Section  4.5.2  provides
   information  about  mounting structures having the same name.) Section
   4.5.5 discusses why you would have such a structure.

|  If you include the ENABLE JOB0-CTY-OUTPUT command in the  n-CONFIG.CMD
|  file, the operator is notified at the console terminal when disk space
|  becomes low on the system structure.

   If you are using CFS-20 software, refer to Chapter 12, The Common File
   System, for additional information on the system structure.



   4.2.2  The Contents of the System Structure

   The following list provides an overview of the contents of the  system
   structure:

        1.  The default TOPS-20 command processor, EXEC, which is usually
            found in <SYSTEM> or <NEW-SYSTEM>.

        2.  A  <ROOT-DIRECTORY>  (Section  3.2.1)  that  points  to   the
            location on disk of all first-level directories on the system
            structure, including the special system directories.

        3.  All the  files  in  the  directories  <SYSTEM>  and  <SUBSYS>
            (Sections 3.2.2 and 3.2.4).

        4.  The  directories  <NEW-SYSTEM>,   <NEW-SUBSYS>,   <ACCOUNTS>,
            <OPERATOR>,  <SYSTEM-ERROR>  and  <SPOOL> (Sections 3.2.6 and
            3.2.7).

        5.  The front-end monitor  (RSX20F)  and  the  console  front-end
            files   (Section   3.4).    This   normally  appears  in  the
            <ROOT-DIRECTORY>.  If you are using the RP07  as  the  system
            structure,  the  front-end file system must reside on an RP06
            dual-ported disk drive.

        6.  The required swapping area.  The size of this area depends on
            the  TOPS-20 monitor you are using.  For example, 2060-MONMAX
            uses up to 15,000 pages of disk space for  swapping.   (Refer
            to Section 4.7 for a description of the swapping area.)






                                    4-3
                            CREATING STRUCTURES


        7.  A HOME block that contains the following parameters:

             o  the structure's physical name

             o  the number of disk packs in the structure

             o  which pack this is in the structure

             o  the address and number of pages used  for  the  front-end
                file system (usually 950)

             o  the address and number of pages set aside for swapping

             o  the address of the <ROOT-DIRECTORY> and its backup copy

             o  the serial number of the KL CPU to  be  booted  from  the
                structure

        8.  A directory for every user who requires access to the system.
            Users  must  log  into a directory on the system structure to
            use the system.  Afterwards, they can mount and connect to  a
            different structure and directory.  (If the "login structure"
            is enabled, CFS-20 users log  in  to  the  designated  public
            structure.)



   4.3  ONE-STRUCTURE SYSTEMS

   A one-structure system consists of  a  single  structure,  the  system
   structure,  which  is always on-line.  All packs in the structure must
   be on-line for the system to operate.

   Usually, a one-structure system has  only  one  or  two  disk  drives.
   Smaller TOPS-20 installations choose to keep all their directories and
   files on one structure for some of the following reasons:

         o  It is the simplest system.

         o  It is the easiest system to maintain.

         o  There is no requirement to physically remove packs  from  the
            drives, for example, for security reasons.

         o  The majority of users are inexperienced.

         o  All files are available at all times, and thus  are  easy  to
            access.






                                    4-4
                            CREATING STRUCTURES


         o  A full-time operator may be unnecessary.

         o  There is only one disk drive (only one structure supported).

   Chapter 5 describes the methods you can use  to  create  and  maintain
   directories on your one-structure system.



   4.4  MOUNTABLE STRUCTURES

   If the system structure does not encompass all available disk  drives,
   you can create and mount other structures on the unused drives.  These
   "mountable" structures are created  using  the  CHECKD  program.   The
   TOPS-20 Operator's Guide describes creating structures with CHECKD.

                                    NOTE

           The system structure is the only structure created  at
           installation  time.   All other structures are created
           (using the CHECKD program) and brought on-line  during
           system operation.



   4.4.1  Differences Between Mountable and System Structures

   Unlike the system structure, a mountable structure can be mounted  and
   dismounted  during timesharing.  Also, it need not contain a front-end
   file system.  Therefore, a mountable structure does not have to reside
   on  a  dual-ported disk drive.  Although a mountable structure has its
   own <ROOT-DIRECTORY> and directory system, a user cannot  log  into  a
   mountable  structure,  but  must  log  in  as  a  user  on  the system
   structure.  A user can then mount a different structure and connect to
   directories.  Table 4-1 summarizes the differences between a mountable
   and system structure.



   4.4.2  Similarities Between Mountable and System Structures

   There are, however, many similarities between the system structure and
   mountable  structures.   Both  contain  user directories and files.  A
   mountable structure can have a front-end file system, and can be  used
   in  place  of the system structure to load the system for timesharing.
   A mountable structure is created with the  eight  special  directories
   (mentioned  in  Chapter  3)  as  for  a system structure.  Likewise, a
   mountable structure has a HOME block that contains information such as
   the  name  of  the  structure  and  the  number  of  disk units in the
   structure.  These and other similarities are summarized in Table 4-2.




                                    4-5
                            CREATING STRUCTURES


   Table 4-1:  Differences Between Mountable and System Structures

     __________________________________________________________________

     System Structure                  Mountable Structures
     __________________________________________________________________

     Always up during timesharing      Can be mounted and dismounted

     Has  a  front-end  file  system   Need not have a front-end  file
     (unless an RP07)                  system

     Resides on a drive that is dual   Need    not    reside    on   a
     ported   with   the   front-end   dual-ported disk drive
     computer (unless an RP07)

     Used   for   logging  into  the   Cannot be used for logging into
     system                            the system

     Belongs to the system             Can belong to a private user

     Has  the  <SYSTEM>,   <SUBSYS>,   Need not have these directories
     <ACCOUNTS>,         <OPERATOR>,   unless  the  structure  will be
     <SYSTEM-ERROR>,   and   <SPOOL>   used  as  the public structure;
     directories                       can   be   deleted   from   the
                                       structure

     Must contain a swapping area      Need  not  contain  a  swapping
                                       area unless the structure is to
                                       be   mounted   as   the  public
                                       structure
     __________________________________________________________________



   Table 4-2:  Similarities Between Mountable and System Structures

     __________________________________________________________________

     System Structure                  Mountable Structures
     __________________________________________________________________

     Has a HOME block                  Has a HOME block

     Has   a  front-end  files  area   Can have a front-end files area
     (unless an RP07)

     Is used to load the system        Can  be used to load the system
                                       if the proper  file  areas  and
                                       files have been established

     Contains system files             May contain system files


                                    4-6
                            CREATING STRUCTURES


     System Structure                  Mountable Structures

     Has a <ROOT-DIRECTORY>            Has a <ROOT-DIRECTORY>

     Contains user files               Contains user files

     All packs must be  on-line  for   All packs in the structure must
     the system to operate             be on-line to use the structure
     __________________________________________________________________



   4.5  MULTIPLE-STRUCTURE SYSTEMS

   A multiple-structure system consists of a system structure  and  one
   or more additional structures.  Figure 4-1 illustrates a system with
   three disk drives and two structures.  The two-pack system structure
   MASTER:   must be online during timesharing.  The one-pack mountable
   structure  ADMIN:   can  be  removed  during  timesharing.   Another
   one-pack structure can be mounted in its place.


                   UNIT 0      UNIT 1          UNIT 2
                   ______      ______          ______
                  |      |    |      |        |      |
                  |      |    |      |        |      |
                  |      |    |      |        |      |
                  |      |    |      |        |      |
                  |      |    |      |        |      |
                  |______|    |______|        |______|

                    STRUCTURE MASTER:     STRUCTURE ADMIN:


   Figure 4-1:  System with 3 Disk Drives and 2 Structures


   Using Figure 4-1, suppose  you  want  structure  ADMIN:   to  remain
   on-line  at  all  times  during  system operation.  The structure is
   automatically mounted if you turn on the  drive  that  contains  the
   structure  before  the system is brought up.  The TOPS-20 Operator's
   Guide describes mounting structures automatically.

   In addition to the system structure and  perhaps  another  permanent
   on-line  structure,  you  may choose to keep one or more disk drives
   available for users to mount and  dismount  "private"  packs  during
   timesharing.







                                    4-7
                            CREATING STRUCTURES


   Figure 4-2 illustrates a system with three  disk  drives  and  three
   one-pack  structures,  the  system  structure  MASTER:,  ADMIN:, and
   PROG:.


                   UNIT 0         UNIT 1         UNIT 2
                   ______         ______         ______
                  |      |       |      |       |      |
                  |      |       |      |       |      |
                  |      |       |      |       |      |
                  |      |       |      |       |      |
                  |      |       |      |       |      |
                  |______|       |______|       |______|

                  STRUCTURE      STRUCTURE      STRUCTURE
                   MASTER:        ADMIN:          PROG:


   Figure 4-2:  Three-Structure System


   In this example, MASTER:  contains all the directories necessary  to
   support log-ins.  ADMIN:  contains the same, a superset, or a subset
   of the same directories as those on MASTER:  and remains  online  at
   all  times  during  system operation.  The drive that contains PROG:
   is used for short-term mounting of  different  one-pack  structures.
   PROG:  remains online only for the time it is needed.

   There can be up to 64 structures online at one time.

   Several of the advantages in a mountable structure environment are:

         o  Some users or groups  of  users  may  require  a  structure
            exclusively  for their use.  They can 'own' or possibly pay
            for the use of certain structures.

         o  Service  engineers  can  mount  their  own  pack   on   the
            short-term  drive  and  perform  some  diagnostics  without
            disturbing normal system operation.

         o  Creating structures on mountable packs provides  additional
            security  to  that already within the system.  For example,
            you  can  create   a   structure   that   contains   highly
            confidential data, remove it from the drive(s) when you are
            done with it, and lock it in a security  cabinet  or  safe.
            At   the  end  of  the  day,  the  operator  locks  up  any
            confidential structures.

         o  In this type of environment, you are  not  limited  in  the
            size  of  your  system's data base.  You can create as many
            structures as you have disk packs to contain them, and  you
            can mount as many at one time as your system can support.


                                    4-8
                            CREATING STRUCTURES


   The principal disadvantages of using mountable  structures  are  the
   need for scheduling both access to the data and operator coverage to
   install and remove packs on the  drives,  as  described  in  Section
   1.2.2,  Mountable  Structure  Sign-Up  Log.  There is also some risk
   that packs will be damaged during handling.

   After the system is operating and structures have been created,  the
   operator  responds  to  requests  from  users  to mount and dismount
   structures.  Section 4.5.5 describes how to place  user  directories
   on  your  mountable  structures  to  obtain  maximum availability to
   priority jobs.



   4.5.1  Choosing Structure Names

   Each device on the system has a name,  called  the  physical  device
   name,  which  is  used when giving commands to the software.  Unlike
   the generic device name that applies to  a  class  of  devices,  for
   example:   TTY:,  DSK:,  LPT:, the physical device name applies to a
   particular device on the system; for example, TTY6:  and LPT0:.  The
   physical  device  names  for disks are structure names.  A structure
   name can be from one to six alphanumeric characters of your  choice,
   and,  like  other  device  names,  must be followed by a colon.  The
   colon indicates to the software that a device is being used and not,
   for example, a file.

   It is important to carefully assign a unique name to each  structure
   that you create.  Section 4.5.2, Mounting Structures Having the Same
   Name, explains why this precaution avoids confusion for users if  an
   operator is unavailable during timesharing.

   Because structure names are used in the device  field  (dev:)  of  a
   file  specification,  you  should not create any structures with the
   same name as a defined (or valid)  device  name.   Table  4-3  lists
   device names that may be defined in your system.

   For the same reason, avoid naming a structure with a defined logical
   name,  for  example,  SYS:, SYSTEM:, NEW:, OLD:, HLP:, etc., because
   the system searches the list of  defined  systemwide  logical  names
   before  device  names.   (Refer  to Section 3.3 for a description of
   logical names.)

   Refer to Chapter 12, The Common File  System,  for  structure-naming
   considerations in a CFS environment.









                                    4-9
                            CREATING STRUCTURES


   Table 4-3:  Sample Device Names

     __________________________________________________________________

     DSK:                 CDP:

     MTAn:                FEn:

     MTn:                 TTY:

     LPT:                 TTYn:

     LPTn:                PTYn:

     PLPTn:               NUL:

     CDR:                 PLT:

     PCDRn:               PLTn:

     PCDPn:               DCN:

     TCP:                 SRV:

     Where n is the unit number of the device.
     __________________________________________________________________


   To avoid duplication, you can get a list of all structure names  known
   to  the  system by giving the operator command, SHOW STATUS STRUCTURE.
   These structures do not have to be  online.   Their  presence  in  the
   listing  indicates  that  they  were  previously  specified  in  a SET
   STRUCTURE command, or once mounted on the system.





















                                    4-10
                            CREATING STRUCTURES


   4.5.2  Mounting Structures Having the Same Name

   A situation may arise requiring you to mount a structure that has  the
   same  name  as  a  structure  that is already online.  Perhaps another
   installation has requested that you mount its system structure  (named
   SYSA:)  for  testing  purposes, but you already have a structure named
   SYSA:  online.  Because the system notices ambiguous structure  names,
   you must mount the structure under a different name.

   Each structure that is mounted is  identified  with  two  names:   the
   physical  identification  and the alias.  Usually, these names are the
   same.  The  physical  identification  is  the  actual  structure  name
   written  in  the  HOME block of that structure.  The alias is the name
   that you use to reference the structure while it is mounted.  After  a
   structure is mounted,it is known only by its alias.  The MOUNT command
   is used to mount a structure and give it an alias different  from  the
   physical  identification.  This allows two or more structures with the
   same  physical  name  to  be  mounted  simultaneously.    The   system
   distinguishes   them   by   their  different  aliases.   (The  TOPS-20
   Operator's Guide describes this procedure.)

   Note that the structures must be mounted one  at  a  time.   That  is,
   structures cannot be online simultaneously before the MOUNT command is
   given.  One of the  structues  must  be  mounted  first.   It  may  be
   necessary to power down disk drives and bring them up again.



   4.5.3  Maximum Size of Structures

   The maximum size of a structure is  approximately  805,680  pages.   A
   structure of this size requires 3 RP20 disk drives (5 spindles).

   Structures of the maximum size, however, may not be practical for your
   installation.    Smaller   structures   enhance  the  reliability  and
   availability of the system.  Remember that  you  can  have  up  to  64
   structures on-line at one time.

















                                    4-11
                            CREATING STRUCTURES


   Also, if a structure is contained on more  than  one  disk  pack,  the
   packs  and  drive  units for that structure must all be the same type,
   that is, either  all  RP06s,  RP07s,  RP20s,  RA60s,  or  RA81s.   For
   example,


                   NOT SUPPORTED               SUPPORTED
                ______      ______         ______      ______
               |      |    |      |       |      |    |      |
               |      |    |      |       |      |    |      |
               | RP06 |    | RP07 |       | RP07 |    | RP07 |
               |      |    |      |       |      |    |      |
               |      |    |      |       |      |    |      |
               |______|    |______|       |______|    |______|

                 STRUCTURE ADMIN:           STRUCTURE ADMIN:


   Table 4-4 shows the maximum structure size  using  RP06,  RP07,  RP20,
   RA60,  and RA81 disk drives.  For all drive types, there can be 12,000
   directories per structure and 5,000 files per directory.

                                    NOTE

           The number of directories per structure and files  per
           directory that can be created is approximate.  This is
           because the disk space needed to create a directory or
           file  varies  according  to  the  lengths of the names
           chosen for directories and files.

























                                    4-12
                            CREATING STRUCTURES


   Table 4-4:  Maximum Size Structures

     __________________________________________________________________

     Type of              Max.No.Packs               No. Pages
     Disk Drive           Per Structure              Per Pack
     __________________________________________________________________


     RP04                 6                          38000

     RP06                 3                          76000

     RP07                 1                          216376

     RP20                 5                          201420

     RA60                 6                          90516

     RA81                 5                          200928
     __________________________________________________________________



   4.5.4  Increasing the Size of Structures

   You can add more disk packs  to  increase  the  size  of  a  mountable
   structure  (not the system structure) during timesharing.  To do this,
   you must:

         o  Dump the entire file structure onto magnetic tape  using  the
            DUMPER program

         o  Run the CHECKD program, specifying the new configuration,  to
            re-create the structure

         o  Restore all the directories  and  files  from  magnetic  tape
            using the DUMPER program

                                 IMPORTANT

           If possible, re-create the structure and  restore  the
           files  to  a different set of packs from the structure
           that you dumped.  This precaution ensures that you  do
           not  lose  any  valuable data should you have problems
           reading the tape back to disk.   That  is,  you  still
           have  the  original  structure  intact  and  can rerun
           DUMPER and copy the structure to another tape.






                                    4-13
                            CREATING STRUCTURES


   To increase the size of the system structure, you must shut  down  the
   system  and  follow  the  installation  procedure for bringing up this
   structure  with  more  disk  packs.   Refer  to  Chapter   9,   System
   Problems/Crashes, and to the TOPS-20 KL Model B Installation Guide.



   4.5.5  Setting Up Structures for Maximum Availability

   Before you create structures and place user directories on  them,  you
   should  determine  which  users  must  be  on the system at all times.
   Place these users' directories and files on the system  structure,  or
   on  another  structure  that  is  always available during timesharing.
   Divide the remaining users of the system by priority, and place  their
   directories  and  files on the other structures.  Although these users
   have log-in directories on the system structure, their  large  working
   area  where  they  create  and  store  files  is  on the other on-line
   structures.  You may want to help users set  up  their  LOGIN.CMD  and
   BATCH.CMD  files  so  that  they  can  mount,  connect, and access the
   appropriate directory on the structure where their files are  located,
   if it is not the system structure.  Dividing users into categories and
   placing them on structures accordingly ensures that the failure of one
   disk  drive  does  not prevent the most important users from using the
   system.  For example, if the drive that contains  ADMIN:   goes  down,
   you can remove the ADMIN:  pack from the broken drive, and mount it on
   another drive that contains a less critical structure.

   Also, on-line disk diagnostics can be  performed  during  timesharing.
   Sometimes, the service engineer can dismount a non-critical structure,
   mount the maintenance pack,  and  perform  preventive  maintenance  or
   trouble-shooting with only a portion of the user community off-line.

   To  increase  system  availability,  you  can  create  another  system
   structure  for backup using the CHECKD program.  After you create this
   structure,  you  should  follow  the  procedures  in   your   software
   installation  manual  for  creating  the  front-end  files  area.  The
   TOPS-20 Operator's Guide describes using the CHECKD program to  create
   a  backup  system  structure.   If  you have problems with the primary
   system structure, having a second system  structure  available  allows
   you to resume timesharing without reinstalling the system.

   The backup system structure can be mounted and  online  at  all  times
   under  another  name,  or  it  can be kept in storage and mounted as a
   backup if the regular system structure is destroyed.   If  the  backup
   system  structure  is  kept  in  storage, the operator must update the
   structure periodically with the System  Backup  Tape  and  the  latest
   incremental  dumper  tapes.   (Chapter  7,  System  Backup,  describes
   creating and using your System Backup  Tape  and  incremental  tapes.)
   Occasionally  updating your backup system structure (in storage) keeps
   it reasonably up-to-date.




                                    4-14
                            CREATING STRUCTURES


   If you keep your backup system structure online at all times, and  you
   have  important  files  that  are  constantly  accessed  by  the  user
   community, you can improve your system performance  by  placing  these
   files  on the backup system structure.  Now your swapping area and the
   files that you access frequently are  not  on  the  same  disk.   This
   procedure  is  useful  with any structure that you keep on-line at all
   times.

   If multiple systems are part of a CFS configuration, refer to  Chapter
   12,  The  Common  File  System, for further discussion of placement of
   files and user directories.



   4.5.6  Taking Structures Off-Line

   When a structure must be taken off-line, the  operator  should  notify
   users that it will be dismounted at a certain time.  Users should give
   the DISMOUNT command for the structure before the specified time.   If
   the  users  do  not cooperate, the operator can dismount the structure
   (via the DISMOUNT command to OPR) without leaving files in an  unknown
   state.   Files  that are open simply become inaccessible, and the user
   who had the files open receives an error.

   For information on dismounting structures in a CFS environment,  refer
   to Chapter 12, The Common File System.




























                                    4-15
                            CREATING STRUCTURES


   4.5.7  Mounting Structures from Another Installation

   If you mount a structure  from  another  installation,  or  perhaps  a
   structure  that  contains confidential data, some of the user names on
   this structure may match the user names on your system structure.  You
   must  mount this structure in what is called a FOREIGN state, to avoid
   the mishap of your users accessing directories that do not  belong  to
   them.  The same is true if you bring one of your structures to another
   installation.  You should have the operator at  the  installation  SET
   the  structure FOREIGN and then mount it.  Figure 4-3 illustrates this
   concept.


           _________________________________
          |                                 |
          |        YOUR INSTALLATION        |
          |                                 |
          |     _________     _________     |            _________
          |    |         |   |         |    |           |         |
          |    |         |   |         |  __|           |         |
          |    | SYSTEM  |   |  PROG:  |     <----------| FOREIGN |
          |    |  STR:   |   |         |  __            |   STR:  |
          |    |         |   |         |    |           |         |
          |    |_________|   |_________|    |           |_________|
          |                                 |                         
          |                                 |              
          |             DOMESTIC            |
          |_________________________________|


   Figure 4-3:  Domestic and Foreign Structures























                                    4-16
                            CREATING STRUCTURES


   A structure is brought online  in  one  of  two  states,  DOMESTIC  or
   FOREIGN, according to the setting that the operator last specified for
   this structure with the SET STRUCTURE command.  The  system  uses  the
   FOREIGN state as the default if a SET STRUCTURE command has never been
   given for this structure.  The  structure  remains  in  the  specified
   state  until  the operator changes the state with the SET STRUCTURE or
   the UNDEFINE command.  Note  that  the  setting  is  unchanged  across
   system crashes and reloads.

   You  should  bring  a  structure  online  as  DOMESTIC  only  if   the
   directories  on  that  structure  were  created for the same people as
   those on the system structure.  One can be a subset of the other,  but
   a  given  directory  name  should  represent  the same person on both.
   Conversely, you should bring a structure on-line  as  FOREIGN  if  the
   directories  on  that  structure  were not necessarily created for the
   same people as those on the system structure.  This is because a  user
   who is logged into a directory on the system structure is the owner of
   an identically named directory on a DOMESTIC structure, and  can  give
   the  CONNECT  or  ACCESS  command  to  that directory without giving a
   password (provided the directory protection allows this type of access
   for  the  owner,  which  is the usual case).  However, a user who logs
   into the system structure and gives the CONNECT or ACCESS command to a
   directory  with an identical name on a FOREIGN structure must give the
   associated password.



   4.6  SHARING STRUCTURES (DISK DRIVES) BETWEEN TWO SYSTEMS

   If you have two DECSYSTEM-20s and one or more structures that  contain
   data  common  to  both  of  these systems, you may want to set up your
   system to share disk drives alternately.  For example, you could allow
   System  A  to  use  the  drive  that contains structure ADMIN:  in the
   morning and allow System B to use this structure on the same drive  in
   the  afternoon.   THE SYSTEMS CANNOT, HOWEVER, ACCESS THE DRIVE AT THE
   SAME TIME.  (Refer to Chapter 12, The  Common  File  System,  for  the
   exception.)  Also, if one of your systems goes down, you can still use
   the drive that is connected to both systems.

   A drive that is to be shared by two systems must be supported by  both
   systems.   For  example,  you  cannot  connect an RM03 disk drive to a
   DECSYSTEM-2020 and a DECSYSTEM-2065 because the 2065 system  does  not
   support  RM03s.   Also,  the  shared  drive must be dual-ported.  Your
   field service representative must  make  the  appropriate  connections
   from  each  DECSYSTEM-20 to a port on the disk drive.  Be sure to have
   the field service representative tell you which system is connected to
   which port on the drive.  Figure 4-4 illustrates this connection.







                                    4-17
                            CREATING STRUCTURES


                          ______________                           
                         /             /|                          
                        /_____________/ |
                        |             | |
       ---------- A --->| Dual-Ported | |<--- B ----------------------
      |                 |    DRIVE    | |                             |
      |                 |_____________|/                              |
      |                                                               |
      |       ______________                      ______________      |
      |      |              |                    |              |     |
       ------| DECSYSTEM-20 |                    | DECSYSTEM-20 |-----
             |______________|                    |______________|
                     |                                   |
                     |                                   |
                _____|_____                         _____|_____
               |           |                       |           |
               | FRONT-END |                       | FRONT-END |
               |___________|                       |___________|


   Figure 4-4:  Shared Disk Drive


   The port switch on this drive must be in either the A or  B  position,
   unless  the  systems  are  part  of  a  CFS configuration.  Otherwise,
   TOPS-20 will not permit either system to access the disk while  it  is
   in the A/B position.  Error messages will be generated.

   To use  the  drive,  place  the  port  switch  in  the  position  that
   corresponds to the first system that is using the drive (A or B).  The
   operator mounts a structure using the  normal  procedure.   After  the
   first system is no longer allowed to use the drive, the operator gives
   the DISMOUNT command for the structure.

   To use the drive on the second system, the operator leaves the pack on
   the  drive  (if  you  are  using  the same structure), turns the drive
   off-line, changes the port switch to  the  corresponding  system,  and
   turns  the  drive  back  on.  Then, the operator (or a user) gives the
   MOUNT command to mount the  structure  on  this  system.   The  system
   automatically  recognizes that another drive is on-line and mounts the
   structure.













                                    4-18
                            CREATING STRUCTURES


   4.7  DETERMINING SWAPPING SPACE ON THE SYSTEM STRUCTURE

   Sections 4.7.1 and 4.7.2 describe what swapping space is  and  how  to
   determine  the  amount  of swapping space that you should allocate for
   your system.



   4.7.1  What Is Swapping?

   The  number  of  user  processes  that  can  fit  into   main   memory
   simultaneously  depends  on  the size of the individual processes, the
   size of the memory-resident portion of the monitor, and  the  size  of
   memory  physically  available.  (Only a portion of the TOPS-20 monitor
   resides in main memory at one time.) If a user wishes to run a process
   that is not currently in memory, process space must be provided.  This
   may necessitate moving some other process out of memory.   The  user's
   program or data that is transferred out of memory is placed on disk in
   the swapping area.  The system  sets  aside  a  portion  of  the  disk
   storage space on the system structure specifically for this purpose.

   On some timesharing systems, a program must be entirely in main memory
   to  execute.  Swapping then consists of moving entire programs between
   disk and memory.  Under TOPS-20, only portions  of  a  program  (those
   containing  the instructions and data currently being referenced) need
   be in memory.  Other portions of the program are brought  into  memory
   from  disk  as  they  are  needed.  In this case, swapping consists of
   moving portions of a program or data between  disk  and  memory.   The
   monitor decides which portions of which programs to swap, and when.

   The size of a program is measured in  a  unit  called  a  page.   When
   swapping  occurs,  some  of  these pages are copied between memory and
   disk.



   4.7.2  When to Increase Swapping Space

   For the most part, the size of your  swapping  space  depends  on  the
   cumulative size of processes you estimate will be on the system at any
   one time.  Table 4-5 contains guidelines for estimating the amount  of
   swapping  space  required for an approximate number of user jobs based
   on typical requirements.  This amount is  given  in  response  to  the
   question,  "HOW MANY PAGES FOR SWAPPING?" in the software installation
   procedures.

   The actual disk space used for swapping depends on the number of pages
   you  give.   The  system rounds the number of pages given upward to an
   integral number of cylinders.  The swapping space is  divided  equally
   among the disk packs in the system structure.




                                    4-19
                            CREATING STRUCTURES


   You can allow for swapping space on structures other than  the  system
   structure.   However,  this is necessary only if you plan to mount the
   structure as the system structure in the future.  Allocating  swapping
   space  avoids  re-creating the structure should you decide to mount it
   as the system structure.

   All the monitors are designed to default to an appropriate  number  of
   pages for swapping.  In most cases, you can take this default.

   The guidelines in Table 4-5 apply to systems whose users perform  many
   editing  jobs and an average or small amount of debugging programs and
   production jobs.  If your users perform a great  number  of  debugging
   and  production  jobs  and  only a small amount of editing, you should
   double the size of your swapping space.  However, if  you  double  the
   size  of your swapping space, check the maximum swapping space allowed
   for the monitor you are running.  (The TOPS-20 KL Model B Installation
   Guide lists the maximum number of swapping pages you can use with each
   monitor.) You cannot exceed this maximum.  If you enter a number  that
   is  larger than the maximum, the monitor uses the maximum allowed.  If
   you must exceed the maximum,  you  can  bring  up  a  larger  existing
   monitor,  or you can tailor your monitor by following the instructions
   in the BUILD.MEM file.  This file  is  located  in  the  documentation
   files saveset on the TOPS-20 Software Distribution tape.


   Table 4-5:  Determining Swapping Space

     __________________________________________________________________

             Estimated                   Recommended Number of
           Number of Jobs                 Pages for Swapping*
     __________________________________________________________________

             20 or less                           3000

              21 to 30                            4500

              31 to 40                            6000

              41 to 50                            7500
     __________________________________________________________________

     * For each additional 10 jobs, increase the number  of  pages  for
     swapping by approximately 1,500.

   If disk space  is  available,  it  is  better  to  overestimate  the
   swapping  space  needed.   If  not  enough  swapping  space has been
   reserved, system service may be disrupted.

|  If  you  include  the  ENABLE   JOB0-CTY-OUTPUT   command   in   the
|  n-CONFIG.CMD  file, the operator is notified at the console terminal
|  when swapping space becomes low.


                                    4-20
                            CREATING STRUCTURES


   4.8  DETERMINING THE AVAILABLE DISK SPACE

   4.8.1  Determining Disk Space Before Installation

   To determine the available disk space that you  will  have  to  divide
   among  your  users  before  installing the system, first calculate the
   swapping space required  by  your  system  (Section  4.7.2).   Second,
   insert  the  number you calculated for swapping space into the formula
   shown in Table 4-6, and perform the appropriate steps.

   Table 4-6 outlines how to calculate the available disk  space  on  the
   system  structure.  If you are calculating the available disk space on
   other structures, follow this same procedure but  eliminate  reserving
   space for any directories or areas that are not on that structure.  If
   any possibility exists that a structure may  be  used  as  the  system
   structure, reserve the swapping space.

   Note that if you plan to enable the "login  structure"  feature  in  a
   CFS-20  cluster  (see  Section  12.6.2),  much  more swapping space is
   available on the system structures.  This is because user  directories
   will reside on the shared login structure.

                                    NOTE

           Remember that as your system expands,  the  number  of
           pages   in   the  <SYSTEM>  and  <SUBSYS>  directories
           increases.  Also, the number  of  pages  reserved  for
           directory  <SPOOL>  should  be  increased if:  (1) you
           maintain large operator log files (2) users copy large
           numbers  of  files  or  large  files to LPT:.  A large
           backlog of user file retrieval requests can  also  use
           up much of the <SPOOL> area.






















                                    4-21
                            CREATING STRUCTURES


   Table 4-6:  Calculating Available Disk Space

    _____________________________________________________________________
   | TOTAL DISK SPACE:                                                   |
   |                                                                     |
   | Number of RP06 disk drives * 76000 pages     = ____________________ |
   |                              per drive         TOTAL DISK SPACE     |
   |                                                                     |
   | _____OR:___________________________________________________________ |
   | Number of RP07 disk drives * 216376 pages    = ____________________ |
   |                              per drive         TOTAL DISK SPACE     |
   |                                                                     |
   | _____OR:___________________________________________________________ |
   | Number of RP20 disk drives * 201420 pages    = ____________________ |
   |                              per spindle       TOTAL DISK SPACE     |
   |                                                                     |
   | _____OR:___________________________________________________________ |
   | Number of RA60 disk drives * 90516 pages     = ____________________ |
   |                              per drive         TOTAL DISK SPACE     |
   |                                                                     |
   | _____OR:___________________________________________________________ |
   | Number of RA81 disk drives * 200928 pages    = ____________________ |
   |                              per drive         TOTAL DISK SPACE     |
   |                                                                     |
   | RESERVED DISK SPACE:                                                |
   |                                                                     |
   | Front-end file system         =   950                               |
   |                                                                     |
   | Swapping Space                =                                     |
   |  (Enter number of pages                                             |
   |  selected and allocated                                             |
   |  for swapping)                                                      |
   |                                                                     |
   | <SYSTEM>                      =   1876                              |
   | <SUBSYS>                      =   1780                              |
   | <NEW-SYSTEM>                  =      2                              |
   | <NEW-SUBSYS>                  =      2                              |
   | <OPERATOR>                    =    500                              |
   | <UETP.*>                      =   1701                              |
   | <ROOT-DIRECTORY>              =      9                              |
   | <SPOOL (you should reserve)>  =   1000                              |
   |                                                ____________________ |
   |                                                TOTAL RESERVED SPACE |
   | SUBTRACT TOTAL RESERVED SPACE                                       |
   | FROM TOTAL DISK SPACE                          ____________________ |
   |                                                AVAILABLE DISK SPACE |
   |_____________________________________________________________________|







                                    4-22
                            CREATING STRUCTURES


   4.8.2  Determining Disk Space After Installation

   Shortly after you have  installed  the  system,  you  can  log  in  as
   OPERATOR  and  give  the  command INFORMATION (ABOUT) DISK-USAGE.  One
   line of output tells you the actual number of system  pages  that  are
   available  on  the system structure.  You can divide this disk storage
   among  your  users.   (Refer  to  Chapter  5,  Creating  Directories.)
   However,  be  careful  about  over-allocating disk space on the system
   structure.  If the space allowed to user directories exceeds the space
   free  on  the system structure after installation, then users can fill
   up the entire  system  structure.   But  if  TOPS-20  cannot  free  up
   adequate  space by expunging the system structure, then system service
   may be disrupted.  Even if space can be freed to allow the  system  to
   keep running, some user programs may be disrupted.








































                                    4-23
























































                                    5-1











                                 CHAPTER 5

                            CREATING DIRECTORIES



   A prospective user who requires access to the system must be  assigned
   a user name (normally the user's surname), a password, an account, and
   disk storage quotas, and must have a directory created for him or  her
   on   the   public  structure.   Optionally,  you  can  assign  certain
   capabilities and/or make the user or the user's directory a member  of
   one or more groups.  (Refer to Section 5.8 for a description of how to
   establish group relationships  among  users  and  Section  5.9  for  a
   description of the capabilities you can assign to users.) You can also
   create additional directories for users on mountable structures.

   This chapter describes  three  methods  you  can  use  to  create  and
   maintain  directories.   Using  one  method,  the operator creates and
   maintains all the directories on the system.  A second  method  allows
   you  to  delegate  the  responsibility  for  creating  and maintaining
   directories to project administrators.  The third method combines  the
   first  two  methods,  thus providing additional flexibility.  Sections
   5.1 through 5.3 explain these methods and the determining factors  for
   choosing  one  of  them.   These  sections  also  include  some of the
   decisions necessary to assign user names and capabilities, and how  to
   allocate  disk  storage  according to the method you use to create and
   maintain directories.  (Refer to Chapter 4 to determine the amount  of
   disk space available to divide among the directories you create.)

   Chapter 6 describes how to set up an  accounting  scheme  and  how  to
   assign  and  validate accounts.  You should read Chapter 6 if you want
   to allow users to log into the system and charge their computer  usage
   to   valid   accounts   immediately   after  you  have  created  their
   directories.

   Refer to Chapter 12, The Common File  System,  for  considerations  in
   creating directories in a CFS-20 environment.








                                    5-1
                            CREATING DIRECTORIES


   5.1  HAVING THE OPERATOR CREATE AND MAINTAIN ALL DIRECTORIES  (CENTRAL
        CONTROL)

   In this type of installation, the operator creates a directory on  the
   public  structure  for  each  new  user  and specifies the appropriate
   parameters.  The name of the directory is the  same  as  the  assigned
   user  name.   Each  user  informs  the  operator  when a change to his
   directory parameters is required.  This type of operation  allows  you
   as  system  manager  to  have  central administrative control over all
   directories and parameters.  Therefore, central control means that you
   or  the  operator create and maintain all the directories for all your
   system users.  Central control has two  types  of  directory  schemes.
   One  scheme allows you to create up to approximately 5,000 directories
   per structure.  The other scheme allows you to use subdirectories  and
   create up to approximately 12,000 directories per structure.

                                    NOTE

           The number of directories  allowed  per  structure  is
           approximate, because the disk space needed to create a
           directory or file varies.



   5.2  DELEGATING THE CREATION AND MAINTENANCE OF DIRECTORIES TO PROJECT
        ADMINISTRATORS (PROJECT CONTROL)

   An alternative type of installation  involves  project  administrative
   control.  Under this type of control, the operator creates directories
   only for the users who have been designated as project administrators,
   (e.g.,   the  representatives  of  major  departments).   The  project
   administrators, in turn, create subdirectories for users within  their
   departments  or  projects  and  control the assignment of those users'
   directory parameters.  This type of control allows you to delegate the
   responsibility  for  creating  and  maintaining  directories for other
   users and still maintain ultimate control over  your  system  and  its
   resources.

   Therefore, project control means that most of the directories  created
   by  you  or  the operator are project directories (e.g., MATH might be
   the assigned name of a project).  The system's resources, such as disk
   space,  are  divided among these project directories either equally or
   according to the expected size of  the  project.   Subdirectories  are
   then  created  under project directories for users within the project.
   The people who have been appointed project leaders  or  administrators
   are responsible for creating, assigning parameters to, and maintaining
   the subdirectories within  their  project.   The  resources  that  you
   allocate to the project directory are divided among its subdirectories
   by the project administrators.  Under project control, you are allowed
   to   create   up   to   approximately  12,000  directories  (including
   subdirectories) per structure.



                                    5-2
                            CREATING DIRECTORIES


   5.3  COMBINING CENTRAL AND PROJECT CONTROL

   A combination of central and project control can be used if  you  want
   to  keep  the majority of the user directories at the management level
   of control and separate only a portion of your  system  into  projects
   and administrative control.

   Therefore, combining  central  and  project  control  means  that  the
   operator  creates  and  maintains  directories  for most of the system
   users and creates  project  directories  for  special  projects.   The
   project   administrators   create   directories   under   the  project
   directories and are responsible for maintaining them.   Combining  the
   two   types  of  control  still  allows  up  to  approximately  12,000
   directories per structure.



   5.4  CENTRAL AND PROJECT CONTROL DESCRIPTIONS

   Sections 5.4.1  through  5.4.4  describe  the  two  types  of  central
   control,  project  control, and the combination of central and project
   control.  Each description includes:

         o  The determining factors for choosing a particular control

         o  The directory format for each type of control

         o  The procedure for assigning user names

         o  The procedure for creating user directories

         o  The procedure for creating files-only directories

         o  The restrictions, if any, that apply to  using  a  particular
            control

   Also, any additional considerations that apply to headings within each
   description are included.

   Read  each  description  thoroughly.   The   first   central   control
   description  contains  very  general  information and suggestions that
   apply to all the directory schemes.












                                    5-3
                            CREATING DIRECTORIES


   5.4.1  Central Control

   DETERMINING FACTORS:

         o  Your  business  installation  is  relatively   uncomplicated;
            therefore,  there  is no need to separate projects and assign
            the  creation  and  control   of   directories   to   various
            administrators.   All  the  directories  on  the  system  are
            created and maintained by you or the system operator.

         o  You are sure that the number of directories you need is  less
            than approximately 5,000.

   FORMAT:

   <ROOT-DIRECTORY> can point  to  approximately  5,000  directories  per
   structure.

   All directories under <ROOT-DIRECTORY> are on one level.

   ASSIGNING USER NAMES:

   The user name that you assign should include  the  user's  last  name.
   This convention is true for any type of directory scheme that you use.
   The system uses this name when recording the authors of files, sending
   mail  to  users,  and  displaying  system  status.  If you follow this
   convention, you can easily identify who is using the system  when  you
   give  a  SYSTAT  command.  If just using last names will not result in
   duplications, you can simply use the last names.  Otherwise, you might
   want  to  use the first and middle initials followed by the last name.
   (If a user has no middle initial, you can use a dash in its place.) It
   is  most  convenient  for  users  when  user  names  begin with unique
   characters,  allowing  use  of  "recognition"  when  typing  user   or
   directory names.  Use of leading initials often yields this result.

   CREATING USER DIRECTORIES:

   All directories are created using the ^ECREATE command.   (Only  users
   who  have  WHEEL or OPERATOR capability enabled can use this command.)
   In the next example, the operator is connected to the public structure
   PUBLIC:  and uses the ^ECREATE command to create a new directory named
   <BECKER> for the user who has been  assigned  the  user  name  BECKER.
   Also, the operator assigns the password MARTIN.

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) PUBLIC:<BECKER><RET>
   [NEW]
   $$PASSWORD MARTIN<RET>
   $$<RET>
   $DISABLE (CAPABILITIES)<RET>
   @



                                    5-4
                            CREATING DIRECTORIES


   This directory is called the user's logged-in directory and is  always
   on  the  public structure.  Whenever the user logs into the system, he
   is connected to this directory.  He can remain in  this  directory  or
   connect to and use files in another directory.

   Refer to the TOPS-20 Operator Command Language Reference Manual for  a
   complete description of the ^ECREATE command that the operator uses to
   create new directories, and the ULIST program that prints  information
   about all the directories on the system.

   After creating a new directory (either files-only or  user),  remember
   to  update the tape containing the monitor, TOPS-20 Command Processor,
   DLUSER, DLUSER  data,  DUMPER,  <SYSTEM>,  and  <SUBSYS>.   (Refer  to
   Chapter 7, System Backup Procedures.)

   CONSIDERATIONS:

   If two users have mistakenly been assigned the same user name and  you
   try  to  create the second directory with this duplication, the system
   prints [OLD] instead of [NEW].  Give the ABORT subcommand, assign  the
   user  a slightly different user name, and reissue the ^ECREATE command
   with the new directory name.  A common practice  is  to  precede  such
   names  with  the user's first initial.  This allows recognition on the
   user or  directory  name  without  typing  the  entire  name  and  the
   distinguishing  character.   For  instance,  if you have the two users
   Stephanie Sheldon and Andrew Sheldon, you should assign them the  user
   names S-SHELDON and A-SHELDON or SSHELDON and ASHELDON rather than use
   the names SHELDON-S and SHELDON-A.

   CREATING FILES-ONLY DIRECTORIES:

   If a user wants to have a library area in addition  to  his  logged-in
   directory,  you  can  create  a  files-only  directory  on  the public
   structure or on another structure.  The user can gain owner privileges
   to  this  directory  by  giving  the  CONNECT command and the password
   associated with the directory.  If  the  directory  is  located  on  a
   regulated  mountable  structure,the  user  must  also  give  the MOUNT
   command to use the structure before he gives the CONNECT command.  The
   user  cannot  give  the  ACCESS  command  for or log into a files-only
   directory.  For example, if you have a user named BECKER who processes
   payroll  on  a  regular  basis,  he  may  want  to develop the payroll
   programs in his  directory  and  keep  the  payroll  data  in  a  more
   restricted  directory.   To  accomplish  this,  you  can create on the
   public structure the logged-in directory <BECKER> and  the  files-only
   directory  <PAYROLL>.   The  directory  <PAYROLL> can be on some other
   structure, (e.g., ADMIN:<PAYROLL>).  BECKER now has normal  protection
   on  his  directory,  more  restrictive  protection  on  the  directory
   <PAYROLL> and can still CONNECT to <PAYROLL> by giving  its  password.
   BECKER  cannot,  however,  give  the  ACCESS  command  for or log into
   <PAYROLL>.




                                    5-5
                            CREATING DIRECTORIES


   The next example shows how to create the directory  <PAYROLL>  on  the
   public structure MAIN:.

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) MAIN:<PAYROLL><RET>
   [NEW]
   $$PASSWORD MONIES<RET>
   $$FILES (ONLY)<RET>
   $$PROTECTION (OF DIRECTORY) 774000<RET>
   $$DEFAULT (FILE) PROTECTION 770200<RET>
   $$<RET>
   $DISABLE (CAPABILITIES)<RET>
   @

   Now if user BECKER logs in and wants to use the files in <PAYROLL>, he
   can give the following CONNECT command:

   @CONNECT (TO DIRECTORY) <PAYROLL><RET>
   Password:  monies<RET>

   The TOPS-20 Operator Command Language Reference Manual  describes  all
   the parameters you can give to directories and describes how to create
   directories on mountable structures.

   CONSIDERATIONS:

   When  you  create  additional  directories  on  mountable  structures,
   consider  if files-only directories are suitable.  Some users will not
   want to give the CONNECT command to a directory each time they require
   owner  access  to  the  files  in  that  directory.   Also, files-only
   directories are members of groups only as directory group members  and
   not  user group members.  Therefore, if you create ALL the directories
   on a structure as files-only, you  cannot  establish  any  valid  user
   group  relationships  among  those directories.  (Refer to Section 5.8
   for a description of setting up groups.)

   Conversely, if you create user directories, users can give the  ACCESS
   command  to  their  additional  directory  and  gain  owner  and group
   privileges without connecting to the directory, and they can use other
   directories  on  the structure as group members.  Also, if the name of
   the  directory  you  create  is  the  same  as  the  user's  logged-in
   directory, and the structure is mounted as DOMESTIC, the user does not
   have to specify a password when giving the CONNECT or  ACCESS  command
   to the directory.  (Refer to Section 4.5.7.) This is valuable when the
   user is submitting a batch job.  No password is required on the  batch
   input; therefore, security is preserved.  In addition to creating user
   directories on the structure, you can create files-only directories to
   be used as library areas.






                                    5-6
                            CREATING DIRECTORIES


   It is also possible to create only one user directory on  a  structure
   and  to create all other directories as files-only.  In this case, all
   users required to use a files-only directory on  the  structure  could
   give the ACCESS command to the user directory (gaining owner and group
   privileges), and use the files in a files-only directory according  to
   the  group  protection  codes set.  This would be useful if you have a
   private structure that contains several library areas that are  common
   to  the owners of the private disk pack(s).  Each owner could give the
   ACCESS command for the one user directory and gain group privileges to
   all  the  library directories.  Therefore, these users would need only
   one password to gain access to all the information on the pack.

   Note that defined groups may provide  better  security  controls  than
   passwords.   If  the  password  for  the  ADMIN:<PAYROLL> directory is
   MONIES, it might be guessed, or user BECKER may write it down or  tell
   it  to  some  other  user.  On the other hand, group membership can be
   centrally controlled, and the access can be withdrawn,  if  necessary.
   Also,  the directory structure provides a record of group memberships,
   which can be displayed with the ULIST program.  Wise use of  directory
   protections  can  allow  user  members  of  a  group  to  connect to a
   files-only directory without giving a password.

   Refer to the TOPS-20 User's Guide or the  TOPS-20  Commands  Reference
   Manual for a complete description of the CONNECT and ACCESS commands.

   RESTRICTIONS:

   The number of directories  you  create  per  structure  cannot  exceed
   approximately 5,000.  This number is an approximation because the disk
   space that it takes to create a directory or file varies.



   5.4.2  Central Control Using Subdirectories

   DETERMINING FACTORS:

         o  As stated in the previous directory scheme, your installation
            does   not  warrant  segregation  of  projects  and  control.
            However, this directory scheme allows  more  directories  per
            structure  than  the previous central control scheme.  You or
            the  operator  can  create   up   to   approximately   12,000
            directories  per  structure  and  assign and maintain all the
            directory parameters.

         o  You can easily expand into  a  form  of  project  control  by
            adding project directories, and still maintain control at the
            management level over the majority of the  user  directories.
            (Refer   to  Section  5.4.4,  Combined  Central  and  Project
            Control.)




                                    5-7
                            CREATING DIRECTORIES


   FORMAT:

   <ROOT-DIRECTORY> points to 26 directories.  The name of each directory
   is a letter of the alphabet, <A>, <B>, <C>, ..., <Z>.  The directories
   point to all  user  and  files-only  directories.   The  single-letter
   directories  are  on  one  level below <ROOT-DIRECTORY>.  The user and
   files-only directories are on a second  level  below  <ROOT-DIRECTORY>
   and are pointed to by the alphabetic directories.

   Also, the directories pointed to by  the  single  letter  directories,
   (e.g.,  <A.JONES>),  can  be allowed to create directories under them.
   Perhaps user A. JONES wants to create one  or  two  subdirectories  to
   store  special  files,  such  as  memos.   The user is responsible for
   maintaining the directory he created and is allowed to  use  only  the
   disk quota you originally allocated to his logged-in directory.  Refer
   to Section 5.4.3, Project Control, if you would  like  to  allow  some
   users to create directories of their own.

   ASSIGNING USER NAMES:

   Each user name that you assign should be as close as possible  to  the
   user's  last  name  prefixed  by  a  first  initial and a period.  For
   example, Charles Baker would be assigned the user name C.BAKER.  Under
   this  type  of  directory  scheme,  you  must  follow the principle of
   prefixing the name with the first initial and a period.

   CREATING USER DIRECTORIES:

   Have the operator create 26 directories using  the  ^ECREATE  command.
   The  name  of each directory is a letter of the alphabet, that is, <A>
   through <Z>.

   The theory behind creating these alphabetic directories is the same as
   described in Section 5.4.3.  That is, you must create directories that
   are allowed to have subdirectories.  The directories  <A>,  <B>,  ...,
   <Z> can have approximately 5,000 user and files-only directories under
   them.  Therefore, you must include some  of  the  same  parameters  in
   these directories, as you would in project directories.

   Refer to the TOPS-20 Operator Command Language Reference Manual for  a
   complete  description  of  the  parameters  that  are defined when the
   operator uses the ^ECREATE command  to  create  directories,  and  the
   ULIST  program  that  prints  information about all directories on the
   system.

   The procedures for creating the alphabetic directories  and  the  user
   and  files-only  directories  under  them are described below.  In the
   example, COMMON:  is the name of the public structure.






                                    5-8
                            CREATING DIRECTORIES


                                    NOTE

           The general considerations described in Section  5.4.1
           for  creating  directories are also applicable to this
           directory description.

   Even though the alphabetic directories are not associated with  users,
   they  must  be  created as log-in directories.  However, do not assign
   passwords.   This  prevents  users  from  gaining  access   to   these
   directories.

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) COMMON:<A><RET>
   [NEW]
   $$

   Assign each directory a large number for creating subdirectories,  for
   example, 400.

   $$MAXIMUM SUBDIRECTORIES (ALLOWED) 400<RET>

   Because  many  user  directories  are  created  under  each  of  these
   alphabetic  directories  and  the  page  quota (disk space) from these
   alphabetic directories is divided among (or passed  on  to)  the  user
   directories,  you  must assign the alphabetic directories a very large
   permanent and working page quota.  Assigning them a sufficiently large
   page quota prevents any of these alphabetic directories from exceeding
   their page quota, thus requiring you to make a change to the quota  at
   a later time.  Therefore, assign each directory at least 500,000 pages
   of permanent and working disk page quota.

   $$PERMANENT (DISK STORAGE PAGE LIMIT) 500000<RET>
   $$WORKING (DISK STORAGE PAGE LIMIT) 500000<RET>

   Assign a list of SUBDIRECTORY-USER-GROUP numbers  to  each  directory.
   The  list should be the same for each directory.  The range of numbers
   you use depends on how many groups you plan  to  establish,  (e.g.,  5
   groups,  10  groups,  40  groups).   The numbers used in the following
   examples are for illustration; you can choose any sequence:

   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 200<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 201<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 202<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 203<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 204<RET>

   Later, when you create a user directory and place that user in a  user
   group,  you  must  enter  one  of  the numbers in this list.  No other
   numbers will be valid.  (Refer to Section 5.4.3, for a  more  detailed
   description of why you are using this list of numbers, and Section 5.8
   for establishing valid group relationships.)



                                    5-9
                            CREATING DIRECTORIES


   In the following example, the operator  is  connected  to  the  public
   structure COMMON:  and creates the first two directories, <A> and <B>:

   @ENABLE (CAPABILITIES) <RET>
   $^ECREATE (NAME) COMMON:<A><RET>
   [NEW]
   $$MAXIMUM-SUBDIRECTORIES (ALLOWED) 400<RET>
   $$WORKING 500000<RET>
   $$PERMANENT 500000<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 200<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 201<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 202<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 203<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 204<RET>
   $$<RET>
   $
   $^ECREATE (NAME) COMMON:<B><RET>
   [NEW]
   $$MAX 400 !You can use abbreviations<RET>
   $$WORKING 500000<RET>
   $$PERMANENT 500000<RET>
   $$SUB 200<RET>
   $$SUB 201<RET>
   $$SUB 202<RET>
   $$SUB 203<RET>
   $$SUB 204<RET>
   $$<RET>
   $ !Continue creating directories <C>
   $ !through <Z> in exactly the same manner.

   After all 26 directories are  created,  you  can  give  the  DIRECTORY
   command  to  see  all the directory files that have been created under
   <ROOT-DIRECTORY>.

   $DIR COMMON:<ROOT-DIRECTORY>

    COMMON:<ROOT-DIRECTORY>

   A.DIRECTORY.1
   B.DIRECTORY.1
   C.DIRECTORY.1
        .
        .
        .
   Z.DIRECTORY.1

   Next, after all  26  alphabetic  directories  have  been  successfully
   created,  the operator again uses the ^ECREATE command and creates all
   the user directories.





                                    5-10
                            CREATING DIRECTORIES


   In the  example  below,  the  operator  is  connected  to  the  public
   structure  COMMON:   and  creates  a directory named <A.JONES> for the
   user who has been assigned the user name A.JONES.  This  directory  is
   A.   Jones'  log-in  directory  on the public structure.  Each time A.
   Jones logs into the system, he is connected  to  directory  <A.JONES>.
   In  this  example,  the  operator also assigns the password 2BY4.  The
   operator gives the directory the system default of 250 pages for  both
   working and permanent disk quota.  Because he is using the default, he
   does not have to make any entries for these two parameters.   The  250
   pages  given to this directory are taken from the superior directory's
   quota (directory <A>).  (The PRESERVE  subcommand  can  be  issued  to
   avoid  having  the  disk  space  quota  subtracted  from  the superior
   directory's allocation.) The operator also places user A.JONES in user
   group 202 and places directory <A.JONES> in directory group 202.

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) COMMON:<A.JONES><RET>
   [NEW]
   $$PASSWORD 2BY4<RET>
   $$USER-OF-GROUP (NUMBER) 202<RET>
   $$DIRECTORY-GROUP (NUMBER) 202<RET>
   $$<RET>
   $DISABLE (CAPABILITIES)<RET>
   @

   After creating any new directories (either files-only  or  user),  you
   should  update  the  backup  tape  that  contains the monitor, TOPS-20
   Command  Processor,  DLUSER,  DLUSER  data,  DUMPER,   <SYSTEM>,   and
   <SUBSYS>.  (Refer to Chapter 7, System Backup Procedures.)

   CONSIDERATIONS:

   If users have duplicate first initials and last  names,  you  can  use
   middle initials.  For example, if two users have the name C.BAKER, you
   can assign either one of them a user name  in  the  form  CL.BAKER  or
   C.LBAKER.   If  you  use the form CL.BAKER you must create a directory
   <CL> in addition  to  directory  <C>.   If  you  do  not  create  this
   additional  directory  with  the  user's first and middle initial, you
   will receive error messages  and  will  not  be  able  to  create  the
   directory  <CL.BAKER>.   If,  instead,  you assign user Baker the user
   name C.LBAKER (the preferred method), you  can  create  the  directory
   <C.LBAKER>  as  described  above using the standard procedure.  You do
   not need to create the additional directory <CL>.  Alternatively,  you
   could  create two levels of "initial" directories, and assign users to
   third-level directories based  on  their  first  and  middle  initials
   followed by their last names, for example, C.L.BAKER.

   If  a  user  requires  special  capabilities  to  perform   privileged
   functions,  the  operator can include the parameter for the capability
   in the user's directory accordingly.  (Refer  to  Section  5.9  for  a
   description  of  the  capabilities you can assign to certain users who
   require them.)


                                    5-11
                            CREATING DIRECTORIES


   CREATING FILES-ONLY DIRECTORIES:

   If a user wants a library area in addition to the logged-in directory,
   you can create a files-only directory.

   Files-only directories can also be prefixed by a letter and a  period.
   Because the first name initials of users do not always encompass every
   letter in the alphabet, you may want to use  those  infrequently  used
   letters  as the prefix to the files-only directories, e.g., <X.FORLIB>
   or <Z.TESTS>.  Alternatively, you can place the files-only directories
   under a special prefix, such as LIB., or place them directly under the
   root directory.  The example below shows how to create  the  directory
   <X.FORLIB>  on the public structure PUBLIC:.  The operator assigns the
   password SQUASH, makes the directory files-only,  takes  the  250-page
   default  for working and permanent disk storage quotas, and places the
   directory in directory group number 202.  (User members of groups  202
   can  now accesss this directory and the files it contains according to
   group protections.)

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) PUBLIC:<X.FORLIB><RET>
   [NEW]
   $$PASSWORD SQUASH<RET>
   $$FILES-ONLY<RET>
   $$DIRECTORY-GROUP (NUMBER) 202<RET>
   $$<RET>
   $DISABLE (CAPABILITIES)<RET>
   @

   Follow the procedures in the TOPS-20  Operator's  Guide  for  creating
   directories on mountable structures.

   CONSIDERATIONS:

   The  CONSIDERATIONS  described  in  the   previous   central   control
   description  (Section  5.4.1) for files-only directories also apply to
   this description.

















                                    5-12
                            CREATING DIRECTORIES


   If the number of files-only directories you want to create  is  small,
   you  can  create them on the same level as the alphabetic directories.
   That is, <X.FORLIB> can be created as <FORLIB>.  Your directory scheme
   may look like:


                           <ROOT-DIRECTORY>
                          ------------------
                            |      |      |
                            |      |      |

                           <A>... <J>... <X>
                      --------------------------
                            |             |
                            |             |

                        <A.JONES>    <X.FORLIB>


                                   or:


                       <A>... <J>... <Z>... <FORLIB>
                   ---------
                       |
                       |

                  <A.JONES>


   RESTRICTIONS:

   The number of directories you can create per structure  cannot  exceed
   approximately 12,000.

   The number of subdirectories  under  a  single-letter  directory,  for
   example, <A>, cannot exceed approximately 5,000.

   If you reach the maximum number of directories allowed per  structure,
   the system prints the message:

   ?MAXIMUM DIRECTORY NUMBER EXCEEDED -- INDEX TABLE NEEDS EXPANDING












                                    5-13
                            CREATING DIRECTORIES


   If you reach the maximum number of subdirectories that a single letter
   directory can point to, the system prints the message:

   ?SUPERIOR DIRECTORY FULL

   You can define up to only 40 user groups with  the  ^ECREATE  command,
   because  all  the  user  groups must be specified as subdirectory user
   groups in the superior single-letter directory.  This is not as  great
   a  problem  when  all  the  user  directories  are  directly under the
   ROOT-DIRECTORY.

   If you make a superior directory FILES-ONLY, be sure to make  all  its
   subdirectories  FILES-ONLY.  Otherwise, you will be unable to recreate
   the subdirectories (refer to Chapter 9) if the structure  is  damaged,
   until all the superior directories are made not FILES-ONLY.



   5.4.3  Project Control

   DETERMINING FACTORS:

         o  The complexity and perhaps  geography  of  your  organization
            warrants  separating  small  or  large  groups  of users into
            projects.  The responsibility for  creating  and  maintaining
            the   directories  within  a  project  can  be  given  to  an
            administrator.  This is especially helpful if a large  number
            of  users  have directories on the system.  This method frees
            the operator  from  spending  an  excessive  amount  of  time
            creating directories and changing directory parameters.

         o  Even though you delegate the task of  creating  and  managing
            groups  of  directories  to project administrators, you still
            maintain ultimate control  of  the  overall  system  and  its
            resources.   This means that you still determine and allocate
            the disk space that each  project  uses.   The  administrator
            distributes the disk space you allocate to directories within
            the project.  Also, administrators can  create  and  maintain
            directories  for  their  projects  without  having  WHEEL  or
            OPERATOR capabilities by using  the  TOPS-20  BUILD  command.
            Therefore,  you  do  not  weaken the security of your system.
            Unless  you  give  WHEEL  or  OPERATOR  capabilities  to   an
            administrator,  he  cannot assign those capabilities to other
            users.










                                    5-14
                            CREATING DIRECTORIES


         o  In addition to allowing administrators to create  directories
            for  a  project,  you  can allow other users of the system to
            create subdirectories.  These users can  separate  and  store
            files  in  a  subdirectory.  According to the protection they
            place on their subdirectories, they  can  share  their  files
            with  other  users  without  losing  the  security  of  their
            superior  directory.    The   users   are   responsible   for
            maintaining the directories they create.

         o  Up to 12,000 directories (including  subdirectories)  can  be
            created per structure.

   FORMAT:

   <ROOT-DIRECTORY> can point  to  approximately  5,000  directories  per
   structure.

   Each directory under <ROOT-DIRECTORY> can point to approximately 5,000
   subdirectories.

   Each subdirectory can also point to approximately 5,000 subdirectories
   directly under it.

   The number of subdirectory levels is determined by a maximum length of
   39  alphanumeric  characters,  because each subdirectory name contains
   the name or names of any superior directories above it.  For  example,
   the  user  who owns directory <PHYSICS> under <ROOT-DIRECTORY> creates
   the subdirectory <PHYSICS.LAB-12>.  The new subdirectory name (LAB-12)
   has its superior directory's name (PHYSICS) as its prefix.  The period
   separates the different levels of the directory name and is counted as
   one of the characters in the directory name.

   ASSIGNING USER NAMES:

   The names that you assign to users should be as close as  possible  to
   the  user's last name.  In addition, the project names that you assign
   and that will be used for project directory names  should  be  closely
   related to the project, e.g., PHYS might be used for Physics and PHYED
   for Physical Education.

   When you give a SYSTAT command, the user surnames and obvious  project
   names  make  it  easier to identify who is using the system, and under
   which project.

   CREATING PROJECT AND USER DIRECTORIES:

   The user and  project  directories  that  <ROOT-DIRECTORY>  points  to
   (first-level directories) are created by you or the operator using the
   ^ECREATE command.





                                    5-15
                            CREATING DIRECTORIES


   The procedures you should use and the parameters that you must include
   in these directories are described below.

   Create all project directories  as  log-in  (user)  directories.   You
   would not create a project directory as files-only, because files-only
   directories  cannot  have  log-in  directories  created  under   them.
   However, log-in project (or user) directories can have both log-in and
   files-only subdirectories.

   Assign a disk storage quota to each  project  directory.   This  quota
   must  be large enough to accommodate both the files that are contained
   in the directory and the directories that are created under it.   Each
   time   a   directory  is  created  under  a  project  directory,  that
   directory's disk quota is taken  from  the  project  directory's  disk
   quota.   The  total disk quota for directories created under a project
   directory cannot exceed the quota  originally  given  to  the  project
   directory.

   In the example below,  the  operator  begins  to  create  the  project
   directory  <CHEM>.   He creates the directory as a log-in directory on
   the public structure ORANGE:  and  assigns  the  password  H20.   This
   procedure  allows  an  administrator to log into the directory, giving
   its password, and create the required  subdirectories.   He  may  also
   want  to  store  his  files in this directory.  The operator gives the
   directory a 10,000-page  working  and  a  10,000-page  permanent  disk
   storage quota.

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) ORANGE:<CHEM><RET>
   [NEW]
   $$PASSWORD H20<RET>
   $$WORKING 10000<RET>
   $$PERMANENT 10000<RET>
   $$

   Next, the operator enters the parameter that allows the owner  of  the
   project  directory  to  create subdirectories.  This parameter, called
   MAXIMUM-SUBDIRECTORIES (ALLOWED), specifies how many  directories  can
   be  created under the directory.  Unless you enter this parameter (the
   default  is  0),  the   owner   of   the   directory   cannot   create
   subdirectories.   For  example,  all  users of the system can type the
   BUILD command to the TOPS-20 Command Processor, but only  those  users
   who  have  the  MAXIMUM-SUBDIRECTORIES  (ALLOWED)  parameter  in their
   directory with a number greater than zero can actually use  the  BUILD
   command to create subdirectories.









                                    5-16
                            CREATING DIRECTORIES


   The following entry in the sample project directory <CHEM> allows  the
   administrator to create 100 subdirectories.

   $$MAXIMUM-SUBDIRECTORIES (ALLOWED) 100<RET>

   The administrator who is responsible for  this  sample  project  might
   create  60  directories  under  the  project  directory  and give each
   subdirectory approximately 50 pages  of  working  and  permanent  disk
   quota.   He  keeps enough pages in the project directory to allow that
   directory's files to grow and  to  create  additional  subdirectories.
   (Refer to the TOPS-20 Commands Reference Manual for the description of
   the  BUILD  command,  including  distributing  working  and  permanent
   storage quotas and maximum subdirectory quotas.)

   Also, some of the MAXIMUM-SUBDIRECTORIES (ALLOWED) quota given to  the
   project  directory  can be given to a subdirectory so that directories
   under it can be created.  The  quota  for  the  project  directory  is
   decremented by the amount of quota given to the subdirectory.

   For example, directory <CHEM> is given a subdirectory  quota  of  100.
   The  administrator  creates  the directory <CHEM.STUDENT> under <CHEM>
   and gives the directory a subdirectory quota of  10.   The  number  of
   subdirectories  that  can  now  be created under <CHEM> is 89.  If the
   administrator  creates  another  subdirectory  under   <CHEM>   called
   <CHEM.STUDENT2>  and  gives  that directory a subdirectory quota of 6,
   the number of subdirectories that can now be created under  <CHEM>  is
   82.

   If the administrator gives an  INFORMATION  (ABOUT)  DIRECTORY  <CHEM>
   command, the output line for maximum subdirectory quota is:

   MAXIMUM NUMBER OF SUBDIRECTORIES ALLOWED 84

   The two  directories  <CHEM.STUDENT>  and  <CHEM.STUDENT2>  that  were
   created  under  <CHEM> account for the two subdirectories not shown in
   the subtraction.

   Next, the operator enters the parameter that allows the  administrator
   for  this project to place users in groups.  The administrator can use
   the group facility as described in  Section  5.8  to  set  up  library
   directories and allow file sharing among members of the project.

   The SUBDIRECTORY-USER-GROUP parameter accepts a number between  1  and
   262143  as  its  argument.   You  can list a range of numbers that the
   administrator can use to establish groups within the project; however,
   you  must  enter each number separately.  Be careful to assign a range
   of numbers that is unique  to  that  project.   For  example,  project
   directory <CHEM> may be given the range:






                                    5-17
                            CREATING DIRECTORIES


   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2600<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2601<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2602<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2603<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2604<RET>

   Project directory <PHYSICS>  may  be  given  the  following  range  of
   numbers different from project CHEM.

   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 3001<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 3002<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 3003<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 3004<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 3005<RET>

   If you assign the same range of numbers to different projects, you can
   cause  a  security break among projects.  For example, a user in group
   2602 in project CHEM should not be able to access, as a group  member,
   the directories and files in project PHYSICS.

   The range of  numbers  placed  in  a  project  (or  user)  directory's
   parameter  list  does  not  imply  that  the  directory  or any of its
   subdirectories has access to those groups.  It  means  only  that  the
   administrator  (or owner of the directory) can use those group numbers
   to  establish  group  relationships  among  that  directory  and   its
   subdirectories.

   The following example shows  the  completed  parameter  list  for  the
   sample project directory <CHEM>:

   @ENABLE (CAPABILITIES) <RET>
   $ ^ECREATE (NAME) ORANGE:<CHEM><RET>
   [NEW]
   $$PASSWORD H20<RET>
   $$WORKING 10000<RET>
   $$PERMANENT 10000<RET>
   $$MAXIMUM SUBDIRECTORIES (ALLOWED) 100<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2600<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2601<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2602<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2603<RET>
   $$SUBDIRECTORY-USER-GROUP (ALLOWED) 2604<RET>
   $$<RET>
   $ DISABLE (CAPABILITIES) <RET>
   @

   Refer to the TOPS-20 Operator's Guide for a  complete  description  of
   the ^ECREATE command that the operator uses to create new directories,
   and  the  ULIST  program  that  prints  information  about   all   the
   directories on the system.




                                    5-18
                            CREATING DIRECTORIES


   After creating a new directory (either user or  files-only),  remember
   to  update  the backup tape that contains the monitor, TOPS-20 Command
   Processor,  DLUSER,  DLUSER  data,  DUMPER,  <SYSTEM>,  and  <SUBSYS>.
   (Refer to Chapter 7, System Backup Procedures.)

   CONSIDERATIONS:

   If two projects or users have mistakenly been assigned the same  name,
   and  you try to create the second directory with this duplication, the
   system prints [OLD] instead of  [NEW].   Give  the  ABORT  subcommand,
   assign  the user or project a slightly different name, and reissue the
   ^ECREATE command with the new directory name.

   A subdirectory is just like any other directory.   It  can  be  logged
   into  (if  it  is  not specified as files-only), it can be a member of
   user  and  directory  groups,  and  it  obeys  the  usual   protection
   mechanisms.    Therefore,  there  are  no  implied  rights  between  a
   directory and its subdirectories, or between two subdirectories of the
   same  directory.   Files  have three protection fields:  owner, group,
   and world; and each directory has the same  three  protection  fields.
   Refer  to  Section  5.7  for  a  description  of  directory  and  file
   protections.

   The only additional rights that the owner of a directory has over that
   directory's  subdirectory is the power to change its parameters (e.g.,
   directory protection, password, or group memberships), or to  use  the
   KILL subcommand, which deletes the subdirectory.



























                                    5-19
                            CREATING DIRECTORIES


   If you or another user choose to delete a directory,  you  must  first
   delete  any  subdirectories  under the directory.  You cannot delete a
   directory or subdirectory  that  has  existing  subdirectories.   This
   protection  insures  that  someone  (possibly  an  administrator  of a
   project) does not accidentally delete a directory  that  points  to  a
   large  portion  of  the  database.  The operator or administrator must
   connect  to  the  directory  immediately  above   the   lowest   level
   subdirectory  to  begin deleting any directories.  For example, if the
   owner of  the  directory  <PHYSICS>  wants  to  delete  the  directory
   <PHYSICS.LAB-12>,  he must first connect to directory <PHYSICS.LAB-12>
   and delete any of its subdirectories.  Then, he connects to  directory
   <PHYSICS>   and   gives   the  KILL  subcommand  to  delete  directory
   <PHYSICS.LAB-12>.  Note that the operator is the only person  who  can
   delete the directory <PHYSICS>.

   If you or the administrator choose to grant special capabilities to  a
   user,  you  can include the parameter for the capability in the user's
   directory.   (Refer  to  Section  5.9  for  a   description   of   the
   capabilities you can assign to certain users.) You should instruct the
   administrator to inform you when special capabilities are given  to  a
   system  user.   You  are protected against users randomly giving other
   users special capabilities, because the operator or the  administrator
   who assigns special capabilities to a user must have (as a user) those
   same capabilities.  A person with WHEEL or OPERATOR  capabilities  can
   assign any capability to another user.  Also, the user or operator who
   is assigning the capabilities must have those capabilities enabled  at
   the   time  the  privileged  parameter  is  entered  into  the  user's
   directory.

   Once a SUBDIRECTORY-USER-GROUP number has been allocated to a  project
   directory,  be  careful  about removing it.  If it is in use in any of
   the  subdirectories,  either  as  a  USER-OF-GROUP  number  or  as   a
   SUBDIRECTORY-USER-GROUP  number,  you  will  be unable to recreate the
   subdirectories (refer to Chapter 9) if the structure is damaged, until
   you  manually  restore the SUBDIRECTORY-USER-GROUP number into all the
   superiors.


















                                    5-20
                            CREATING DIRECTORIES


   CREATING FILES-ONLY DIRECTORIES:

   Administrators or users can have library areas in  addition  to  their
   logged-in  directories.   They  can  use  the BUILD command and create
   files-only directories under their logged-in directories, provided you
   have  given  them  the  capability  to  do  so  by  adding the MAXIMUM
   SUBDIRECTORIES (ALLOWED) parameter to the directory that will  contain
   the subdirectories.

   CONSIDERATIONS:

   Refer to the CONSIDERATIONS under the  first  description  of  Central
   Control,  Section  5.4.1.   These considerations also apply to Project
   Administrative Control.

   RESTRICTIONS:

         o  You  cannot  exceed  approximately  12,000  directories   per
            structure.

         o  The number of directories that a superior directory points to
            cannot exceed approximately 5,000.

   If you reach the maximum number of directories that you can create  on
   a structure, the system prints the message:

   ?MAXIMUM DIRECTORY NUMBER EXCEEDED -- INDEX TABLE NEEDS EXPANDING

   If either  you  or  an  administrator  reach  the  maximum  number  of
   directories that can be created under a superior directory, the system
   prints the message:

   ?SUPERIOR DIRECTORY FULL

         o  Files-only directories cannot have log-in subdirectories.  If
            you   want   to   allow   a  user  to  create  user  (log-in)
            subdirectories  under  his  directory,  you  must  make   his
            directory a log-in directory.
















                                    5-21
                            CREATING DIRECTORIES


   5.4.4  Combined Central and Project Control

   DETERMINING FACTORS:

         o  Only a portion of your organization warrants being  separated
            into  projects.  The directories for the majority of the user
            community  are  created  and  maintained   at   the   central
            management  level.   But,  where  project  administration  is
            appropriate, the task of creating  and  managing  directories
            within a project is given to administrators.

         o  For example,  if  your  company  has  groups  of  users  with
            terminals  in several distant locations, you may want to have
            the administrator at the remote location create and  maintain
            all  the directories for that site.  You can create a project
            directory for the remote location, perhaps using the name  of
            the   site  as  the  project  directory  name  (for  example,
            <CHICAGO> or <CHIC>, <SEATTLE>,  ...).   The  remaining  user
            directories at the central location are created by the system
            operator.

   FORMAT:

   <ROOT-DIRECTORY>  points  to  all  the  project  directories  and   26
   alphabetically  named  directories,  <A>  through  <Z>.   The  project
   directories point to the  user  and  files-only  directories  that  an
   administrator  creates  for  a  given  project.   The  directories <A>
   through <Z> point to  user  and  files-only  directories  created  and
   maintained  by the operator.  These directories can also be allowed to
   have subdirectories.

   ASSIGNING USER NAMES:

   If  you  create  any  user  directories  that  are   pointed   to   by
   <ROOT-DIRECTORY>,  assign  project  names  and  user names in the same
   manner as described under  Project  Control,  Section  5.4.3.   Again,
   assign  the 26 directories that will point to the majority of the user
   directories, the names <A>, <B>, <C> ....  <Z>.  The user  names  that
   will  be  the directory names under the alphabetic directories should,
   as previously stated, be  the  user's  surname  prefixed  by  a  first
   initial  and a period.  (Refer to Section 5.4.2, Central Control Using
   Subdirectories.)

   CREATING USER AND FILES-ONLY DIRECTORIES:

   Create the user,  files-only,  and  <A>  through  <Z>  directories  by
   following the instructions in Section 5.4.2.

   Create the  project  directories  according  to  the  instructions  in
   Section  5.4.3,  and  distribute  the description of the BUILD command
   (TOPS-20 Commands Reference Manual)  to  the  administrators  who  are
   responsible for creating the user directories within their project.


                                    5-22
                            CREATING DIRECTORIES


   CONSIDERATIONS:

   All the considerations that apply to both Central and Project  Control
   also apply to combining the two types of control.

   You may want to allow users  whose  directories  are  created  by  the
   operator   to   create   several  directories  under  their  logged-in
   directories.  For  example,  user  A.SMITH  creates  the  subdirectory
   <A.SMITH.MEMOS> to store files that he wants to keep separate from his
   programming files.  This user uses the BUILD  command  to  create  the
   number  of subdirectories that he is allowed to create and divides the
   quota for his logged-in directory among the directories he creates.

   In general, users can store files in these directories or, if they set
   the  appropriate  protection, can share the files in these directories
   with other users.

   RESTRICTIONS:

   Combined Central and Project Control allows up to approximately 12,000
   directories per structure.

   The number of directories that  a  superior  directory  can  point  to
   cannot exceed approximately 5,000.

   If you reach the maximum number  of  directories  per  structure,  the
   system prints the message:

   ?MAXIMUM DIRECTORY NUMBER EXCEEDED -- INDEX TABLE NEEDS EXPANDING

   If you reach  the  maximum  number  of  directories  that  a  superior
   directory can point to, the system prints the message:

   ?SUPERIOR DIRECTORY FULL



   5.5  ALLOCATING DISK STORAGE QUOTAS

   In Chapter 4 you determined the amount of disk space that is available
   on  the  system  structure  after  installation.   Once  you  know the
   available disk space, you can decide how  to  allocate  it  among  the
   directories you create.  Each directory is given a number of pages for
   both  working-storage  and  permanent-storage  allocations.    Working
   storage  refers to the disk space that a user can have during the time
   he is logged-in.  Permanent storage refers to  the  total  disk  space
   that a user can have to store files after he has logged-out.







                                    5-23
                            CREATING DIRECTORIES


   The number of pages that you should assign to directories  depends  on
   whether  you (or the operator) are creating all the directories on the
   system (central control) or you are delegating the  task  of  creating
   and   maintaining   directories  to  project  administrators  (project
   control).  When using central control, you may divide the  disk  space
   equally  among  directories,  giving regard to special requirements of
   certain users.  In the case in  which  the  operator  creates  project
   directories,  you  should  allocate  a  disk  quota  large  enough  to
   accommodate the expected size of each project.  Remember that  project
   directories  must  distribute  their  disk  space  to  the directories
   created under them.

   Several important points about working and permanent  allocations  are
   discussed below.

   Assign a large (2000-3000 page) working-storage  allocation  to  users
   who  perform considerable sorting because the temporary files required
   for this operation can occupy substantial disk space.

   As the number of users on the system increases and your disk space  on
   the public structure becomes low, you can decrease the working-storage
   and permanent allocations on the public structure to  add  new  log-in
   directories.   If  you  have  additional  disk  drives not used by the
   public structure, you can accommodate the  directories  with  many  or
   large  files by creating other structures and directories.  Users will
   log into their  directories  on  the  public  structure,  request  the
   operator  to  mount  the proper structure using the MOUNT command, and
   access their additional directories with  the  ACCESS  and/or  CONNECT
   command.  Note that in setting up the system, it is easier to accustom
   users from the start to use other structures than  to  reorganize  the
   structures  and  retrain  users  after space has run out on the public
   structure.



   5.6  ENFORCING DISK STORAGE QUOTAS

   Working-storage  allocations  are  strictly  enforced.   Users  cannot
   exceed  their  working-storage allocations unless they enable WHEEL or
   OPERATOR capabilities.  (Refer to Section 5.9 for a description of the
   special  capabilities that can be given to users who require them.) If
   users request additional space, you can increase their allocations  as
   required.

   If a user exceeds  his  working-storage  allocation  and  attempts  to
   create  or  change  a  file,  the  system  prints  the following error
   message:

   ?QUOTA EXCEEDED The user must decrease his disk usage to less than the
   working-storage  allocation  for  the  directory (in which the file is
   being changed or created) before he can  create  or  change  any  more
   files.


                                    5-24
                            CREATING DIRECTORIES


   The system informs a  user  if  he  is  over  this  permanent  storage
   allocation  when  he  logs  off  the system or connects to a different
   directory.  The system prints the following message after the  CONNECT
   or LOGOUT commands:

   <directory> OVER PERMANENT STORAGE ALLOCATION BY nn PAGES

   This message reminds users that although they may not  be  over  their
   working-storage  allocation,  they  have exceeded their expected total
   disk usage.  Users should delete any files that  are  unnecessary  for
   their  job.   Also,  because  permanent quotas are not enforced, it is
   wise  to  instruct  the  operator  or  administrator  to  police  each
   directory's  disk  usage.   The operator should run the CHKPNT program
   daily to keep a record of each directory's disk  usage.   The  TOPS-20
   Operator's  Guide  contains  the  description  of  running  the CHKPNT
   program.  If you are using  the  file  migration  facility  (refer  to
   Chapter  8),  you  may  want  to  run the REAPER program with the TRIM
   command to force users to stay below their permanent quotas.

   Every time the available disk space on the system  structure  is  less
   than 500 pages, the system prints the following warning messages:

   13-Jun-98 10:20:33 Disk space low on structure STR:, 122 free

   [STR:  Deleted files will be  expunged  from  structure  STR:   in  30
   seconds]

   After 30 seconds, the system starts expunging any deleted files in all
   directories on the structure mentioned in the warning message.

   The system prints this message when the expunging is complete:

   [STR:  Expunge of structure STR:  completed]

   The operator gets the following message:

   13-Jun-89 10:59:59 Expunge completed for structure STR:, 1993 free

   If anyone tries to create or change a file when there is no more  disk
   space available, the system prints an error message similar to the one
   below:

   ?FILE OR SWAPPING SPACE EXCEEDED

   Again, the operator or administrator should  check  to  see  how  many
   users are over permanent allocations.  Also, if you are using the file
   migration facility, you may want to migrate files on the  system  more
   frequently if you are constantly running low on systemwide disk space.
   (Refer to Chapter 8 for a description of file migration.)





                                    5-25
                            CREATING DIRECTORIES


   5.7  PROTECTING DIRECTORIES AND FILES

   Every directory and file has a protection number associated  with  it.
   The  system  uses  a  default protection number for each directory and
   file when the directory or file is created.

   Whenever a user accesses a file, the system first checks the directory
   protection.  If that protection allows the user the appropriate access
   to the directory,  the  system  then  checks  the  protection  of  the
   individual file.



   5.7.1  Directory and File Protection Digits

   The directory and file protection numbers have three  2-digit  fields.
   The  first  field  applies  to the owner of the directory or file, the
   second field to members of the same group as this directory,  and  the
   third field to all other users (or world).

                               Protection Code
                  ____________________________________
                  |   dd     |      dd      |     dd |
                  ____________________________________

                     Owner         Group         World

   The default  protection  for  directories  and  files  is  777700.   A
   directory  or  file  protection  of  77 in any given field allows full
   access.  For example, the default  protection  allows  the  owner  and
   members of his group full access but all other users no access.

                               Protection Code                  
                   ___________________________________
                   |  77     |      77      |     00 |
                   ___________________________________

                     Owner         Group         World
















                                    5-26
                            CREATING DIRECTORIES


   Table 5-1 contains a list of the directory protection digits.


   Table 5-1:  Directory Protection Digits

     __________________________________________________________________

     Digits      Privilege
     __________________________________________________________________

     04          Permits creating files in the directory.

     10          Permits connecting to the directory without giving  a
                 password  and  changing  the  accounts and protection
                 numbers of the files therein. Thus it gives  many  of
                 the privileges the directory owner has. (Refer to the
                 TOPS-20 Monitor Calls Reference Manual.)

     40          Permits, subject to the protection on the  individual
                 file,  listing  the  names  of  the  files  with  the
                 DIRECTORY command and reading the file, e.g., via the
                 TYPE, PRINT, or LIST commands.
     __________________________________________________________________


   These protection codes are actually bits in a protection word.  To get
   more  than one protection, add the digits (octal) corresponding to the
   protection you want.  Thus, 44 allows listing the files  and  creating
   new files.  There are unused bits in the protection number; therefore,
   to provide complete access to files, use 77.  Useful digit pairs are:

   00   Permits no access.

   40   Permits the files to be listed and read.

   77   Permits full (owner) access.


   A file protection number has the same format as a directory protection
   number,  but  the  meanings  of  the  digits are different.  Table 5-2
   contains a list of file protection digits.













                                    5-27
                            CREATING DIRECTORIES


   Table 5-2:  File Protection Digits

     __________________________________________________________________

     Digits       Privilege
     __________________________________________________________________

     02           Permits wildcarding of the file.

     04           Permits appending to the file.

     10           Permits executing the file.

     20           Permits writing and deleting the file.

     40           Permits reading the file.
     __________________________________________________________________


   Obtain a protection number by adding the file protection digits of the
   different protections you need.  For example, protection number 775200
   allows the owner full  privileges;  the  members  of  the  same  group
   reading,  executing,  and  directory listing privileges; and all other
   users no privileges.  Useful digit pairs are:

   00   Permits  listing  the file with the DIRECTORY command only if the
        file is specified explicitly and completely.

   12   Permits executing and using the DIRECTORY  command  to  list  the
        file only.

        This protection is useful  when,  for  example,  you  purchase  a
        program and agree in your contract  not  to  allow  any  of  your
        system users to read, write into,  or  copy  the  file.  Set  the
        protection on an execute-only file to 771212. The TOPS-20  Beware
        file   provides   additional   considerations   for   setting  up
        execute-only files.

   52   Permits  reading,  executing,  and using the DIRECTORY command to
        list the file.

   77   Permits full access.

   The system checks protection numbers starting with the  two  rightmost
   digits.   Therefore,  users  do  not  restrict  members  of a group by
   assigning the file protection 770052, because the group gets at  least
   the  execute,  read,  and  directory  list  access (52) granted to all
   users.






                                    5-28
                            CREATING DIRECTORIES


   Also, because the system checks the directory  protection  before  the
   file  protection, files that have been given a low file protection are
   still secure in a directory with  the  default  directory  protection.
   For  example, suppose the user KOHN tries to type the file EDIT.MAC in
   the directory <HESS>.  The  protection  on  the  directory  <HESS>  is
   777700  and  the protection on the file EDIT.MAC is 777752.  User KOHN
   and directory  <HESS>  are  not  in  the  same  group,  so  the  world
   protection   applies.    First,   the   system  checks  the  directory
   protection, 777700.  The last two digits  (00)  apply  and  permit  no
   access  to  the directory.  User KOHN is not allowed to type the file,
   even though the corresponding protection on the file (52) would  allow
   the  file  to be read, executed, and listed with the DIRECTORY command
   if KOHN were allowed access to files in the directory.



   5.7.2  Changing Directory and File Protection

   Users can change file protection numbers via the SET  FILE  PROTECTION
   command or the RENAME command.

   Users can change directory protection numbers via  the  SET  DIRECTORY
   PROTECTION  or  BUILD  command.   You can, however, prevent users from
   making changes to their directory protection numbers by including  the
   DISABLE  DIRECTORY-PARAMETER-SETTING command in the system file called
   <SYSTEM>n-CONFIG.CMD on the system structure.  If you make this  entry
   in  n-CONFIG.CMD,  only  users with WHEEL or OPERATOR capabilities can
   change  directory  parameters  (via  the  ENABLE  and  SET   DIRECTORY
   PROTECTION commands).

                                    NOTE

           Make an entry in n-CONFIG.CMD only if you DO NOT  want
           to  allow users to change their directory protections;
           otherwise, the system assumes that you want to use the
           system       default       command      of      ENABLE
           DIRECTORY-PARAMETER-SETTING.  (Refer to the TOPS-20 KL
           Model  B  Installation  Guide for a description of the
           parameters that are placed in the n-CONFIG.CMD file.)



   5.8  ESTABLISHING GROUPS

   You can let users share files by  placing  users  and  directories  in
   groups.   Members  of a group can access directories and files in that
   group according to  the  middle  digits  of  the  directory  and  file
   protection code fields, as described in Section 5.7.1.






                                    5-29
                            CREATING DIRECTORIES


   Each group that you establish has two types  of  members:   USERS  and
   <DIRECTORIES>.   Each group is identified by a number.  This number is
   included  as  one  of  the  directory  parameters  in  each  directory
   belonging  to  the group.  Any directory (including subdirectories) or
   user can belong to as many  as  40  groups.   You  can  set  up  group
   relationships   in   the   individual   directories   by   using   the
   DIRECTORY-GROUP and USER-OF-GROUP  subcommands  to  the  ^ECREATE  and
   BUILD commands.  The following example shows that you have placed user
   Smith in user group 268 and directory group 418:

   @ENABLE (CAPABILITIES)<RET>
   $^ECREATE (NAME) MAIN:<SMITH><RET>
   $$PASSWORD SOAR<RET>
   $$WORKING 500<RET>
   $$PERMANENT 500<RET>
   $$USER-OF-GROUP 268<RET>
   $$DIRECTORY-GROUP 418<RET>
   $$

   The DIRECTORY-GROUP or USER-OF-GROUP parameter that you place  in  the
   user's  directory  determines:   1)  if  this  user can access another
   directory's files as a group member 2) if the  files  in  this  user's
   directory  can  be  accessed  by another user as a group member, or 3)
   both.  The diagrams on the following pages illustrate  the  difference
   between being a member of a group as a directory and/or as a user.

   When a user accesses a file in a directory that is  a  member  of  the
   same  group,  the system first checks to see if this user is the owner
   of the directory.  When, in this example, it finds that  the  user  is
   not  the  owner,  the  system then checks to see if the user is in the
   same group as this directory.  In this case, the  user  and  directory
   are  in  the same group; that is, the group numbers match.  The system
   now checks the group protection code  field  of  the  directory  being
   accessed.   If the group protection allows the type of access that the
   user requested, the system proceeds to check the group  protection  on
   the individual file.

   If you are setting up groups on  different  structures,  there  is  no
   correlation between a group number on one structure and the same group
   number on another structure.  For example, group 202  on  MAIN:   does
   not  necessarily have the same user and directory members as group 202
   on another structure.












                                    5-30
                            CREATING DIRECTORIES


   Example

             ------------------------------
             |       <DIRECTORY>          | 
             |                            |<------------------USER
             |                            |
             |DIRECTORY GROUP NUMBER LIST |
             |            n               |
             |            .               |
             |            .               |
             |            .               |
             |            n               |
             |                            |
             |                            |
             |                            |
             |USER GROUP NUMBER LIST      |
             |            n               |
             |            .               |
             |            .               |
             |            .               |
             |            n               |
             ------------------------------


   Each directory has  two  lists  of  group  numbers:   Directory  Group
   Numbers and User Group Numbers.

   Directory Group Numbers identify the  various  groups  of  which  this
   <DIRECTORY> is a member.

   User Group Numbers are associated with users and identify the  various
   groups of which each user is a member.






















                                    5-31
                            CREATING DIRECTORIES


   Example

             ----------------------------
             |       <DIRECTORY>         |
             |                           |<----------------USER
             |                           |
             |DIRECTORY GROUP NUMBER LIST|
             |            n              |
             |            .              |
             |            .              |
             |            .              |
             |            n              |
             ----------------------------

             -----------------------------
             |USER GROUP NUMBER LIST      |
             |            n               |
             |            .               |
             |            .               |
             |            .               |
             |            n               |
             -----------------------------


   The Directory Group Numbers are important to users who require  access
   to  this  directory.   Those users who have a matching group number in
   the User Group Number List can access this  <DIRECTORY>  according  to
   its group protection code.

   The User Group Numbers are important to the owner of  this  directory.
   This  owner  can access any directory that has a matching group number
   in  its  Directory  Group  Number  List.   Note:  Because   files-only
   directories  are  not associated with a user, they do not contain User
   Group Numbers.

   There are three common types of groups:

        1.  A file-sharing group, whose users can access a set of library
            directories and each other's logged-in directories.

        2.  A library group, whose users can  access  a  set  of  library
            directories and their own logged-in directories, but not each
            other's logged-in directories.

        3.  A teacher-student group, in which the teacher can access  the
            students'  directories  and the students can access their own
            logged-in directories, but not their classmates'  directories
            or the teacher's directory.






                                    5-32
                            CREATING DIRECTORIES


   Figures 5-1 through 5-3 illustrate these three common groups  and  the
   association between USER and <DIRECTORY> members of a group.

   In a file-sharing group (Figure 5-1),  users  share  all  their  files
   according   to  the  group  protection  field,  both  in  the  library
   directories (here it is <MANUALS>) and in their logged-in directories.
             User PORADA                            User HOLLAND
          _________________                       _________________
         |     <PORADA>    |                     |    <HOLLAND>    |      
         | Directory Group |                     | Directory Group |
         |   Number List   |     A               |   Number List   |
         |      3, 2 <<xxxxxxxxxxxxxxxx     ----------> 2, 4       |
         |                 |          x     |    |                 |
         |    User Group   |          x     |    |    User Group   |
         |   Number List   |  B       x     |    |   Number List   |
         |      1, 2-------------     xxxxxxxxxxxxxxxxx 2, 6       |
         |_________|_______|    |           |    |_____x___________|          
                   |            |           |          x
                   |            |           |          x
                   |             -----------           x 
                   |                                   x
                 C |                  xxxxxxxxxxxxxxxxxx D
                   |                  x
                   |                  v
                   |           _______v_________
                   |          |    <MANUALS>    |
                   |          | Directory Group |
                   |          |   Number List   |
                   ----------------> 2, 8       |
                              |                 |
                              |    User Group   |
                              |   Number List   |
                              |       None      |
                              |_________________|


   Legend:

        1.  A   User HOLLAND can access directory <PORADA>

        2.  B   User PORADA can access directory <HOLLAND>

        3.  C   User PORADA can access directory <MANUALS>

        4.  D   User HOLLAND can access directory <MANUALS>


   Figure 5-1:  File-Sharing Group






                                    5-33
                            CREATING DIRECTORIES


   In Figure 5-1, the two users, PORADA and HOLLAND, are members  of  the
   same  group  (group  2).   The  directories  <PORADA>,  <HOLLAND>, and
   <MANUALS> are also members of group 2.  Users PORADA and  HOLLAND  can
   access their own directory and files according to the owner protection
   code fields.  PORADA can access directories  <HOLLAND>  and  <MANUALS>
   according to the group protection code fields, and conversely, HOLLAND
   can access directories <PORADA> and <MANUALS> according to their group
   protection  code  fields.   The  other  numbers  shown  in  the figure
   indicate that a user or directory can be a member  of  more  than  one
   group.

   In a library group (Figure 5-2),  USER  members  can  access  all  the
   <DIRECTORY>  members  but not each other's logged-in directories.  The
   library directories are usually files-only directories.   This  figure
   illustrates   a   library   group  that  consists  of  the  files-only
   directories:   <SUBROUTINES>,  <TAPE-TESTS>,  <MACROS>,   and   users:
   ALUSIC,  BROPHY  and  KOHN.   This library group illustrates that just
   because you are a  member  of  a  group  as  a  user,  your  logged-in
   directory need not belong to the same group.



































                                    5-34
                            CREATING DIRECTORIES


                      USER KOHN
                          |
                          V
                 +-----------------+
                 |     <KOHN>      |
                 |                 |
                 | DIRECTORY GROUP |
                 |  NUMBER LIST    |
                 |                 |
                 |       1         |
                 |                 |
                 |  USER GROUP     |
                 |  NUMBER LIST    |
                 |                 |
                 |       2---------|--------------
                 +-------|---------+             | 
                         |                       |
                         |                       | 
   +-----------------+   |   +-----------------+ |    +-----------------+
   |  <SUBROUTINES>  |   |   |  <TAPE-TESTS>   | |    |    <MACROS>     |
   |                 |   |   |                 | |    |                 |
   | DIRECTORY GROUP |   |   | DIRECTORY GROUP | |    | DIRECTORY GROUP |
   |   NUMBER LIST   |   |   |   NUMBER LIST   | |    |   NUMBER LIST   |
   |                 |   |   |                 | |    |                 |
   |        2<-------|-------|------>2         | |----|------>2         |
   |                 |       |                 |      |                 |
   |   USER GROUP    |       |   USER GROUP    |      |   USER GROUP    |
   |   NUMBER LIST   |       |   NUMBER LIST   |      |   NUMBER LIST   |
   |                 |       |                 |      |                 |
   |      NONE       |       |      NONE       |      |     NONE        |
   +-----------------+       +-----------------+      +-----------------+

                  USER BROPHY                  USER ALUSIC
                       |                            |
                       V                            V
              +-----------------+          +-----------------+
              |    <BROPHY>     |          |     <ALUSIC>    |
              |                 |          |                 |
              | DIRECTORY GROUP |          | DIRECTORY GROUP |
              |   NUMBER LIST   |          |   NUMBER LIST   |
              |                 |          |                 |
              |       3         |          |       5         |
              |                 |          |                 |
              |   USER GROUP    |          |   USER GROUP    |
              |   NUMBER LIST   |          |   NUMBER LIST   |
              |                 |          |                 |
              |       2         |          |       2         |
              +-----------------+          +-----------------+


   Figure 5-2:  Library Group



                                    5-35
                            CREATING DIRECTORIES


   In Figure 5-2, users KOHN, ALUSIC and BROPHY are not  directory  group
   members of the same group; however, they are all user group members in
   the same group (group 2).   User  KOHN  can  access  directory  <KOHN>
   according  to  the  owner  protection field and can access directories
   <SUBROUTINES>, <TAPE-TESTS>,  and  <MACROS>  according  to  the  group
   protection  field.  KOHN can access <BROPHY> and <ALUSIC> according to
   the "world" protection field.  Although the arrows have not been drawn
   from  users BROPHY and ALUSIC, their access privileges are the same as
   KOHN's.













































                                    5-36
                            CREATING DIRECTORIES


                                  TEACHER WILEY                           
                                       |
                                       V
                         +---------------------------+
                         |          <WILEY>          |
                         |                           |       
                         |DIRECTORY GROUP NUMBER LIST|
                         |                           |
                         |           NONE            |
                         |                           |
                         |  USER GROUP NUMBER LIST   |
                         |                           |
                         |            5              |
                         +------------|--------------+
                                      |
           STUDENT HURLEY             |              STUDENT HALL
                 |                    |                   |
                 V                    |                   V
   +---------------------------+      |      +---------------------------+
   |         <HURLEY>          |      |      |          <HALL>           |
   |                           |      |      |                           |
   |DIRECTORY GROUP NUMBER LIST|      |      |DIRECTORY GROUP NUMBER LIST|
   |                           |      |      |                           |
   |             5<------------|-------------|------------>5             |
   |                           |      |      |                           |
   |   USER GROUP NUMBER LIST  |      |      |   USER GROUP NUMBER LIST  |
   |                           |      |      |                           |
   |            NONE           |      |      |            NONE           |
   +---------------------------+      |      +---------------------------+
                                      |
          STUDENT MILLER              |            STUDENT RUSSELL
                 |                    |                   |
                 V                    |                   V
   +---------------------------+      |      +---------------------------+
   |         <MILLER>          |      |      |         <RUSSELL>         |
   |                           |      |      |                           |
   |DIRECTORY GROUP NUMBER LIST|      |      |DIRECTORY GROUP NUMBER LIST|
   |                           |      |      |                           |
   |             5<------------|-------------|------------>5             |
   |                           |             |                           |
   |   USER GROUP NUMBER LIST  |             |   USER GROUP NUMBER LIST  |
   |                           |             |                           |
   |            NONE           |             |            NONE           |
   +---------------------------+             +---------------------------+


   Figure 5-3:  Teacher-Student Group







                                    5-37
                            CREATING DIRECTORIES


   In a teacher-student group (Figure 5-3),  the  teacher,  WILEY,  is  a
   member of the group as a USER, while the directories <HURLEY>, <HALL>,
   <MILLER>, and <RUSSELL> are <DIRECTORY> members.  The teacher,  WILEY,
   can  access  the  files in the directories <HURLEY>, <HALL>, <MILLER>,
   and <RUSSELL> according to the group protection.  The  students  whose
   logged-in  directories  are  in  this group as <DIRECTORY> members can
   access the files in <WILEY> according to the protection  set  for  all
   users,  because  only their directories are members of the group; they
   are not members of the group as users.



   5.9  GIVING USERS SPECIAL CAPABILITIES

   You can give special capabilities to certain users;  they  are  WHEEL,
   OPERATOR,  SEMI-OPERATOR,  CONFIDENTIAL,  MAINTENANCE,  IPCF, ENQ-DEQ,
|  INTERNET-WIZARD, and ABSOLUTE-INTERNET-SOCKETS.  Each capability  that
   you  give  to  a user is placed in the user's directory parameter list
   when you create or change the directory.  The person  who  enters  the
   capability  in  a  user's directory must have that capability himself,
   and have it enabled at the time the capability  is  entered  into  the
   directory parameter list.  You should grant these capabilities only to
   users who absolutely need them.  Table 5-3  lists  all  the  available
   capabilities and a brief description of their function.


   Table 5-3:  Special Capabilities

     __________________________________________________________________

     Capability            Description
     __________________________________________________________________

     WHEEL                 Allows   the  user  to  modify  any  system
                           parameters  or  data.  In  particular,  the
                           WHEEL  capability  is  needed  if  the user
                           wants   to   give   the  ^EEDDT  or  ^EQUIT
                           commands.

     OPERATOR              Allows the user all  capabilities  required
                           to  control  the  system.  The user cannot,
                           however,  give   the   ^EEDDT   or   ^EQUIT
                           commands.

     SEMI-OPERATOR         Allows the user to execute only a subset of
                           the  operator  commands  --  to  get system
                           status information and to  control  certain
                           devices.

     CONFIDENTIAL          Allows  the  user  to   obtain   accounting
                           information for another user's job.



                                    5-38
                            CREATING DIRECTORIES


     Capability            Description

     MAINTENANCE           Allows  the user (usually the field service
                           representative)    to    perform    certain
                           maintenance functions, but he  cannot  give
                           the ^E commands.

     IPCF                  Allows  the  user to perform the privileged
                           functions  of  IPCF.  (Refer to the TOPS-20
                           Monitor Calls Reference Manual.)

     ENQ-DEQ               Allows   the   user   to   perform   global
                           ENQUEUE/DEQUEUE functions.
|  
|    INTERNET-WIZARD       Allows the user to perform certain INTERNET
|                          privileged functions.
|  
|    ABSOLUTE-INTERNET-    Allows  the  user  to place absolute socket
|    SOCKETS               numbers in his programs.
|  
|    INTERNET-ACCESS       Allows the  directory  owner  to  establish
|                          INTERNET network connections.

     DECNET-ACCESS         Allows the  directory  owner  to  establish
                           DECNET network connections.
     __________________________________________________________________


   With the exception of WHEEL and OPERATOR, these capabilities  are  not
   listed in a format where having one capability means you also have the
   capabilities listed below it.  The user who has WHEEL capabilities can
   perform  the OPERATOR, SEMI-OPERATOR, CONFIDENTIAL, MAINTENANCE, IPCF,
   and ENQ-DEQ functions.  The user who  has  OPERATOR  capabilities  can
   also  perform  these  privileged  functions  with the exception of the
   ^EEDDT and  ^EQUIT  commands.   But  the  user  who  has  CONFIDENTIAL
   capabilities  can  only  perform  functions  that  are allowed by this
   capability; that is, he cannot  perform  MAINTENANCE,  IPCF,  ENQ-DEQ,
|  INTERNET  WIZARD,  and  ABSOLUTE INTERNET SOCKETS functions, unless he
   has been given the individual capability.  The same principle is  true
   for the remaining capabilities.

   Also, you are giving capabilities to a user, not the user's directory.
   Therefore,  if  user  HALL  has  WHEEL  capabilities,  other users who
   connect to  or  access  the  directory  <HALL>  do  not  obtain  WHEEL
   capabilities.   However, if they log in as user HALL, they will obtain
   HALL's capabilities.  For this reason, users with special capabilities
   (especially  WHEEL  and  OPERATOR)  should  be  especially  careful in
   selecting and protecting their passwords.  They should  be  encouraged
   to  change  them  often,  and  to use passwords that cannot be readily
   guessed.




                                    5-39
                            CREATING DIRECTORIES


   5.10  PRINTING DIRECTORY INFORMATION

   The ULIST program prints information about directories on  the  system
   and  is  described  in  the  TOPS-20 Operator's Guide.  In addition to
   listing information about each directory, the ULIST program  can  list
   information about groups, capabilities, and related information.

   The LIST subcommand of the ^ECREATE command prints  information  about
   the directory or user name you are currently creating, and the ^EPRINT
   command also prints the information on an individual basis.












































                                    5-40











                                 CHAPTER 6

                             CREATING ACCOUNTS



   The TOPS-20 accounting  facility  allows  you  to  assign  and  charge
   computer usage to valid accounts.  It provides you with a means for 1)
   adding security to your system, 2) determining  charges  for  computer
   usage  and  billing  users by account, and 3) associating classes with
   accounts for  use  by  the  class  scheduler.   You  can  use  account
   validation for one or all of these reasons.

   One or more accounts can be assigned to a user for specific tasks  and
   validated  each  time  they  are used.  All accounting data, including
   records of CPU time, structures used, and  peripherals  used  under  a
   valid  account,  are  stored in a usage file and can be used later for
   reports and billing.

   This chapter describes how to set up the system to  use  accounts  and
   establish   an   accounting   data   base.   The  TOPS-20  USAGE  File
   Specification describes how to  create  accounting  reports  from  the
   Usage  file  and establish billing procedures.  The following sections
   include:

         o  How to set up your system to use accounts

         o  How to select an accounting scheme

         o  How to use your accounting scheme and  create  the  necessary
            base account and subaccount files

         o  How to run the  account  generator  program  (ACTGEN),  which
            takes  these  account  data  files and creates the accounting
            data base

         o  What the operator can do if the accounting data base does not
            work properly

         o  How to initialize your system to start validating accounts





                                    6-1
                             CREATING ACCOUNTS


   6.1  SETTING UP THE SYSTEM TO USE ACCOUNTS

   6.1.1  Enabling or Disabling Account Validation

   During software installation, you can  specify  whether  you  wish  to
   create  the  account data base and validate accounts.  You can make an
   entry  in  the  n-CONFIG.CMD  file  that  specifies   either   DISABLE
   ACCOUNT-VALIDATION  or  ENABLE ACCOUNT-VALIDATION.  If you do not make
   an entry in the n-CONFIG.CMD file for accounting, the  system  assumes
   ENABLE ACCOUNT-VALIDATION.

   If you enter DISABLE ACCOUNT-VALIDATION, meaning you do  not  wish  to
   use  the  account  validation facility, the system checks each account
   only for length.  The purpose of the  check  is  to  ensure  that  the
   maximum  number  of  alphanumeric  characters has not been exceeded in
   each account.  No other checking is performed.  If a user attempts  to
   use or create an account greater than 39 characters, the system simply
|  truncates the entry to the 39-character maximum.  The created entry is
|  sure  to  be  of  valid length if you enable account validation in the
|  future.

   If you have instructed the system  to  ENABLE  ACCOUNT-VALIDATION  but
   have  not  yet  created an account validation data base, you receive a
   warning  on  the  console  terminal  (CTY)  when  the  system   starts
   operation.  The message is:

   <SYSTEM>ACCOUNTS-TABLE.BIN NOT FOUND - ACCOUNT VALIDATION IS DISABLED

   The system continues its normal operation; however,  no  accounts  are
   validated  (except for length checking) until you create the necessary
   account data files and run the account generator program  (ACTGEN)  to
   create your account data base.

   You should not receive the above warning message if you  have  created
   your  account data base prior to bringing the system up for operation.
   Users can log into the system using their valid accounts.



   6.1.2  Setting up Account Validation with Existing Files

   If you are using account validation  on  a  system  that  already  has
   files,  the accounts for these existing files should be updated before
   account validation is enabled in the n-CONFIG.CMD  file.   Notify  the
   users  who created these files to change the existing account on every
   file to their new account(s).  This procedure ensures accurate billing
   immediately after the system is brought up and that daily DUMPER tapes
   contain files with valid  accounts.   This  means  that  if  you  must
   restore files from a backup tape, the correct account for each file is
   properly restored; therefore, the disk file storage  continues  to  be
   accurately  charged.   (Refer  to the TOPS-20 Operator's Guide for the
   procedure to follow if all files do not get updated.)


                                    6-2
                             CREATING ACCOUNTS


   6.1.3  Setting up the System for Accounting Shift Changes

   The accounting facility also allows you to change your  billing  rates
   for  system  usage  at  selected times during the day.  This action is
   called an accounting  shift  change.   Accounting  shift  changes  are
   selected by day-of-week and time-of-day.

   You must enter the appropriate commands in the  n-CONFIG.CMD  file  to
   initiate  accounting  shift changes.  The n-SETSPD program reads these
   commands each time the system is reloaded.  The format of the  command
   placed in the n-CONFIG.CMD file is:

        CHANGE time days-of-week

   You can use any format for the time and day,  that  is,  1500,  15:00,
   3:00pm,  MONDAY, MON.  Or, you can use the keywords ALL, WEEKENDS, and
   WEEKDAYS.  The default for days-of-week is ALL.  The  following  is  a
   typical set of commands that may appear in the n-CONFIG.CMD file:

   CHANGE 9:00 WEEKDAYS
   CHANGE 10:00 WEEKENDS,MONDAY
   CHANGE 12:00 TUESDAY,THURSDAY,SAT
   CHANGE 17:00

   The CHANGE (ACCOUNTING  SHIFT  NOW)  command  to  the  CHKPNT  program
   provides  you with a means of changing shifts during system operation.
   This command causes an accounting session to end and a new  accounting
   session  to  begin  for  all  active jobs on the system.  Refer to the
   TOPS-20 Operator's Guide for a description of all  the  commands  that
   can be given to the CHKPNT program.



   6.2  SELECTING AN ACCOUNTING SCHEME

   The first thing you must do before you create account  data  files  is
   set  up  an accounting scheme.  This procedure includes deciding which
   accounts you wish to create, their expiration dates if you  are  going
   to  open  and  close  accounts, the names of the users who can use (or
   charge to) those accounts and, if you are using the  class  scheduler,
   the scheduling class associated with each account.













                                    6-3
                             CREATING ACCOUNTS


   The TOPS-20 account  validation  facility  allows  several  levels  of
   project  administration  in  a  group of accounts having the same base
   account.  For example:

                                  DENVER          <-----Base Account
                                  ------
                                    |
                                    |
                                    |

                                  CHEM            <-----Subaccount
                                ---------
                                  |  |
                                  |  |
                                  |  |

          Subaccount-----> OVERHEAD  LAB-12       <-----Subaccount

   The accounts you would create using the above example are:

                                   DENVER
                                DENVER.CHEM
                            DENVER.CHEM.OVERHEAD
                                    and
                             DENVER.CHEM.LAB-12

   In this example, users at Denver University taking  a  particular  lab
   course  in  chemistry  (e.g.,  12)  would  log  in and charge to their
   assigned account, DENVER.CHEM.LAB-12.

   All accounts that you assign to users can have a maximum length of  39
   alphanumeric  characters.   The  system allows you to use a hyphen (-)
   within  the  accounts  you  create  (e.g.,  LAB-12),  but   no   other
   punctuation (including spaces) can be used.  Note that the system uses
   the period (.) as a delimiter to separate  each  part  of  multi-level
   accounts  and  the  period  is  counted  as  one of the 39 characters.
   Therefore, DENVER.CHEM.OVERHEAD is a user account with 20 characters.

















                                    6-4
                             CREATING ACCOUNTS


   The type of accounting scheme you use depends on the form  of  project
   administration  you  have  at your installation.  Multi-level accounts
   are usually created through a form of project  administration  similar
   to   that   used   when  allowing  certain  users  (perhaps  heads  of
   departments) to create subdirectories.  (Refer to Chapter 5,  Creating
   Directories.)  Remember  that  subdirectories  are just like any other
   directory.  Therefore, users must have  accounts  to  log  into  their
   directory.   Generally, all files that contain data pertaining to base
   accounts are created by you  or  the  operator,  and  all  files  that
   contain  subaccount data are created by one, or perhaps more than one,
   project administrator.  A project administrator, for example, might be
   the  head of the Chemistry Department.  (This could be the same person
   who handles the subdirectory creation for a group or groups of users.)
   Allocating  the  subaccount  file  creation to a project administrator
   allows  you  to  collect  or  budget  for  one  base  account   (e.g.,
   DENVER.CHEM)  and  not be directly concerned with the subaccounts.  In
   the example, the head of the Chemistry Department is  responsible  for
   creating  the subaccount files under DENVER.CHEM., that is, LAB-12 and
   OVERHEAD.  Section 6.3 describes how  to  create  these  account  data
   files using a sample accounting scheme.

   Figures 6-1 and 6-2 illustrate several ways that you can set  up  your
   accounting  scheme.   Figure  6-1  is  a  simple  scheme  that a small
   organization might use.  It also allows you,  as  system  manager,  to
   have complete control over all accounts because you are aware of every
   account assigned.

   Figure 6-1 shows that the manager at Correct Data Company has  decided
   to  set  up one base account for Correct Data and one base account for
   each customer using his system.  He used the  customer  name  for  the
   accounts.   All  the  people  who  use  the system at Correct Data can
   charge their computer usage to the Correct Data account, CORRECT-DATA.
   Unionbank, L & P Food, and Town Square Magazine submitted the names of
   those people who will be using the system from their respective sites.
   These  are  the only people who will be able to log in from their site
   and charge to their assigned account.  The  manager  at  Correct  Data
   also planned expiration dates for each customer account.

















                                    6-5
                             CREATING ACCOUNTS


        SAMPLE COMPANY:  Correct Data
        TYPE OF BUSINESS:  Timesharing House
        PRIMARY MODE OF OPERATION:  Batch

        _____________________________________

        ACCOUNT  CORRECT-DATA
        USER  Hudson, Holland, Gerard, Gionet, King, Kelly, Kohn
         (Note: These 7 people are all the users at Correct Data)

        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

        ACCOUNT  UNIONBANK
        USER  Warriner, Bloomstran, Prest, Pendergast
        EXPIRES  June 1, 1986

        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

        ACCOUNT  LP-FOOD
        USER  Schied, Queeny, Smith
        EXPIRES  July 1, 1986

        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

        ACCOUNT  TOWN-SQUARE
        USER  Markley, Gerhard, Dole
        EXPIRES  July 15, 1986


   Figure 6-1:  Accounting Scheme 1


   Using  the  same  sample  company,  Figure  6-2  shows  how  a  simple
   accounting  scheme of this type can be expanded into a form of project
   administration.   Here,  Correct  Data  and  one  of  its   customers,
   Unionbank, broke down the base accounts into subaccounts.

   Because Correct Data bills Unionbank for all its computer usage as one
   account,  the  manager  at  Correct  Data  is  not  concerned with how
   Unionbank subdivides its account, and is probably  not  aware  of  the
   subaccounts  at  Unionbank.   The  manager  at  Unionbank, however, is
   concerned with the computer usage costs incurred  by  each  department
   within  his  company.   He  supplies Correct Data with the name of the
   file that contains his subaccount information.










                                    6-6
                             CREATING ACCOUNTS


        SAMPLE COMPANY:  Correct Data
        TYPE OF BUSINESS:  Timesharing House
        PRIMARY MODE OF OPERATION:  Batch

        _____________________________________________

        ACCOUNT  CORRECT-DATA
        USER  Hudson, Holland

         SUBACCOUNT PAYROLL
         USER  Gerard, Kelly

         SUBACCOUNT OVERHEAD
         USER  Gionet, Kohn, Kelly
         EXPIRES  December 31, 1986

         SUBACCOUNT PROGRAMMING
         USER  King, Carlson

        _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

        ACCOUNT  UNIONBANK
        USER  Warriner

         SUBACCOUNT TRUST
         USER  Bloomstran

         SUBACCOUNT LOANS
         USER  Prest

         SUBACCOUNT MSTRCHG
         USER  Prest, Pendergast

         SUBACCOUNT PAYROLL
         USER  Bloomstran


   Figure 6-2:  Accounting Scheme 2


   Section 6.3 describes how to enter the information for Figures 6-1 and
   6-2 into files that are used to create an account data base.



   6.3  CREATING AN ACCOUNT DATA BASE

   Sections 6.3.1  through  6.3.3  describe  how  to  use  your  selected
   accounting  scheme  and create the necessary files for your data base.
   Specifically, these sections include how to enter accounting data into
   files, how to run the account generator program (ACTGEN) to create the
   data base, and what to do if an error occurs.


                                    6-7
                             CREATING ACCOUNTS


   6.3.1  Entering Accounting Data into Files

   Base and subaccount files are created using a text editor.  The format
   below  shows  the  combination  of  entries you can make in accounting
   files  using  the  CREATE  command.   Each  file  you  or  a   project
   administrator  creates can contain one or more accounts.  Each account
   can point to one subaccount file, where additional account information
   is  stored  pertaining  to  that  account.   Following the format is a
   summary of the valid commands in an account file.

                          ACCOUNT DATA FILE FORMAT

   @CREATE (FILE) <directory>filename.type<RET>
   INPUT:  filename.type.1

   00100   ACCOUNT account/SUBACCOUNT:dev:<dir>filename.type-<RET>
   00200   /CLASS:n/ALLOW:n,n<RET>
   00300   USER name,name,name,...<RET>
   00400   DIRECTORY dev:<directory><RET>
   00500   GROUP (ON STRUCTURE) dev:/USER:user group number<RET>
   00600   GROUP (ON STRUCTURE) dev:/DIRECTORY:directory group number<RET>
   00700   <ESC>
   *EU<RET>    

   <filename.type.1>

   In addition to the above entries, each entry in the file can  have  an
   expiration date in the form:

   /EXPIRES:dd-mm-yy hh:mm

   This switch indicates when the account will no  longer  be  valid  for
   that entry in the file.  For example:

   USER name1,name2/EXPIRES:10-JAN-86,name3,name4

   In the above example, name2 can no longer use this  account  after  10
   January  1986.   Name1, name3, and name4, however, can continue to use
   the account beyond  that  date.   You  could  also  place  the  switch
   immediately following the USER entry.  For example:

   USER/EXPIRES:10-JAN-86, name1, name2, name3, name4

   This format specifies that none of the users in the list can  use  the
   account after a certain date.  The account, however, remains open, and
   you can place another list of users  in  the  file  who  can  use  the
   account.

   Table 6-1 summarizes the account data file commands.  You can type the
   entire  command,  or  just the characters necessary to distinguish one
   command from another.  For example, ACCOUNT can be typed as AC.



                                    6-8
                             CREATING ACCOUNTS


   Because the ACCOUNT command has several modifiers,  you  may  have  to
   continue  typing  the  modifiers  on the next line.  To do this, use a
   hyphen at the  end  of  the  line  and  continue  typing  the  ACCOUNT
   modifiers on the next line.  For example,

   0100 ACCOUNT TEST/SUBACCOUNT:SYSA:<MARK> ACCOUNT.TXT-
   0200 /CLASS:2/ALLOW:1,3


   Table 6-1:  Summary of Account Data File Commands

     __________________________________________________________________

     Command                               Description
     __________________________________________________________________

     ACCOUNT              Specifies the name of the account that you or
                          a project administrator wish to assign.

                          Note: The ACCOUNT command must be  the  first
                          entry in an account  data  file  because  all
                          subsequent  entries  up  to  the next ACCOUNT
                          entry are modifiers.

     /SUBACCOUNT:         Modifies the ACCOUNT command. It includes the
                          specification of the  file  where  additional
                          data for the account can be found.

                          Note:  The  ACCOUNT  command accepts only one
                          /SUBACCOUNT:modifier.

                          Example:  One  of   your   accounting   files
                          contains the following commands.

                          ACCOUNT CORRECT-DATA/SUBACCOUNT:
                          <GERHARD>ACCT.TXT
                          ACCOUNT UNIONBANK/SUBACCOUNT:
                          <WARRINER>ACCTG.TXT

                          ACTGEN looks in  <GERHARD>ACCT.TXT  for  more
                          account data for  the  account  CORRECT-DATA,
                          and  it looks in <WARRINER>ACCTG.TXT for more
                          data for account UNIONBANK.











                                    6-9
                             CREATING ACCOUNTS


   Table 6-1:  Summary of Account Data File Commands (Cont.)


     Command                               Description

     /CLASS:n             Modifies the ACCOUNT command and is  used  in
                          conjunction  with  the  class  scheduler.  It
                          specifies  the scheduling class that is valid
                          for this account. For example,

                          ACCOUNT CHEM-207/CLASS:3

                          means  that  class  3 is valid when using the
                          account    CHEM-207.   ACTGEN   places   this
                          information in the system's  accounting  data
                          base   for   use   by  the  class  scheduling
                          routines. Use the /CLASS:n switch only if you
                          have  selected to specify class scheduling by
                          account.   (Refer   to  Section  10.1  for  a
                          complete  description  of  using  the   class
                          scheduler by account.)

                          When  a  user  gives an account that does not
                          have a valid class associated  with  it,  the
                          system uses the default class,  class  0.  If
                          the account has a class associated  with  it,
                          that class is used.  The  percentage  of  CPU
                          time that classes can receive is  defined  in
                          the n-CONFIG.CMD file.

                          To use class scheduling by account, you  must
                          have:

                          o  made the appropriate entries in the
                             n-CONFIG.CMD file.

                          o  updated your ACCOUNTS.CMD file (and
                             subaccount files) to specify the classes
                             that are associated with each account.

                          o  run ACTGEN with the INSTALL command to
                             update the ACCOUNTS-TABLE.BIN file.

                          o  given the ENABLE CLASS-SCHEDULER command
                             to OPR or brought the system down and back
                             up again to start class scheduling.








                                    6-10
                             CREATING ACCOUNTS


   Table 6-1:  Summary of Account Data File Commands (Cont.)


     Command                               Description

     /ALLOW:n,n           Modifies the ACCOUNT command and is  used  in
                          conjunction  with  the  class  scheduler.  It
                          allows  you  to  delegate  the  assigning  of
                          classes    to    subaccounts    by    project
                          administrators. It  specifies  the  class  or
                          classes that can be used  by  subaccounts  of
                          this account. For example,

                          ACCOUNT CHEM/SUBACCOUNT:<ABC>MORE.TXT-
                          /CLASS:2/ALLOW:1,3

                          means  the  CHEM  account  is in class 2, and
                          that subaccounts created under CHEM can be in
                          either  class  1  or  class  3.  If no /ALLOW
                          switch  is  given,  the  administrator is not
                          restricted  to  using  certain  classes  and,
                          therefore,  can  give  the  subaccounts   any
                          class. For  example,  the  administrator  can
                          give them the  same  class  as  the  superior
                          directory.  The  /ALLOW switch is useful when
                          you  want  the  superior  account  to  be  in
                          perhaps  a  higher  percentage class than its
                          inferior  accounts.  Remember  that  if   the
                          administrator  does  not give a /CLASS switch
                          to the subaccount,  users  who  log  into  or
                          change to this subaccount will be in class 0.

     USER                 Specifies  one  user or the list of users who
                          are allowed to use this account.

     *                    Specifies that an account is  valid  for  all
                          users  on  a  system.  The  *  is  a  special
                          argument to the USER command.

                          Example: One instance when you might use * is
                          if  you  have  not  established an accounting
                          scheme  but  would like to allow users to log
                          into the system. You could set up one account
                          and use the * to indicate that all users  can
                          use that account.

                          You could also use the * as follows:

                          ACCOUNT MATH-101
                          USER: MATH.*




                                    6-11
                             CREATING ACCOUNTS


   Table 6-1:  Summary of Account Data File Commands (Cont.)


     Command                               Description

                          This  means  that  all users with a user name
                          beginning  with  MATH  can  use  the MATH-101
                          account.  For example, the users assigned the
                          user   names   MATH.SMITH,   MATH.JONES,  and
                          MATH.BROWN can all use this account.

     DIRECTORY            Specifies a directory name. It indicates that
                          the account is valid for  anyone  with  write
                          access  to the directory. This feature allows
                          users to create or store files in  systemwide
                          or  groupwide  directories and to charge them
                          to an "overhead" account different from their
                          own   account.  The  usage  charged  to  this
                          directory  could  be  absorbed  by  system or
                          project  administration.  This  command  also
                          prevents  users  from  being charged for file
                          storage in files-only directories.

                          Note:  The  DIRECTORY  command also accepts a
                          form of the wildcard entry. The  valid  forms
                          are: *:<*>, dev:<*>, or *:<dir>. The asterisk
                          indicates that users with write access to any
                          of  the  directories  matching  the  wildcard
                          entry may charge their  file  creation  to  a
                          certain account.

                          Example:  The file that contains account data
                          for account  CORRECT-DATA.UNIONBANK.FUND  has
                          the entry:

                          DIRECTORY PS:<FORLIB>

                          This  entry  means  that  anyone  with  write
                          access  to  directory  <FORLIB>  can  use the
                          account    CORRECT-DATA.UNIONBANK.FUND   when
                          storing files there.













                                    6-12
                             CREATING ACCOUNTS


   Table 6-1:  Summary of Account Data File Commands (Cont.)


     Command                               Description

     GROUP                Specifies that an account is valid for use by
                          certain   user  and  directory  groups  on  a
                          structure.   (Refer  to  Section  5.8  for  a
                          description of groups.)

     /USER:nnn            Modifies the GROUP command and can be used in
     /DIRECTORY:nnn       any combination. (nnn is a  decimal  user  or
                          directory group  number.)  /EXPIRES:  can  be
                          placed after either modifier to indicate when
                          an account becomes invalid  for  use  by  the
                          group.

                          Note: Using the GROUP command is  helpful  if
                          many people are eligible to use  an  account.
                          Specifying their group number (if they are in
                          a group) eliminates typing  a  long  list  of
                          names incorrectly.
     __________________________________________________________________































                                    6-13
                             CREATING ACCOUNTS


   6.3.2  Sample Data Files

   The examples below show how you could enter the information in Figures
   6-1 and 6-2 into account data files.  The first example shows the data
   file for Figure  6-1.   Tabs  and  comment  lines  beginning  with  an
   exclamation  point (!) can be used within the file for ease in reading
   or formatting the file.  This file in particular contains all the base
   accounts  and  should  be  stored  in your directory.  You may find it
   easier   when   you   run   ACTGEN    if    you    name    the    file
   ACCOUNTS.CMD.  ACCOUNTS.CMD  is the default file that the TAKE command
   under ACTGEN looks for.  (Refer to Section 6.3.3  for  running  ACTGEN
   and giving the TAKE command.)

   @CREATE (FILE) <HUDSON>ACCOUNTS.CMD<RET>
   Input:  ACCOUNTS.CMD.1


   00100 !This file contains definitions of top-level accounts<RET>
   00200 ACCOUNT CORRECT-DATA<RET>
   00300   USER Hudson,Holland,Gerard,Gionet<RET>
   00400   USER King,Kelly,Kohn<RET>
   00500 ACCOUNT UNIONBANK/EXPIRES;1-JUN-86<RET>
   00600   USER Warriner,Bloomstran,Prest,Pendergast<RET>
   00700 ACCOUNT LP-FOOD/EXPIRES:1-JUL-86<RET>
   00800   USER Schied,Queeny,Smith<RET>
   00900 ACCOUNT TOWN-SQUARE/EXPIRES:15-JUL-86<RET>
   01000   USER Markley,Gerhard,Dole<RET>
   01100 <ESC>
   *EU<RET>

   <ACCOUNTS.CMD.1>

                                    NOTE

           Lines 300 and 400 contain all  the  users  at  Correct
           Data.   However,  you  would  not use the asterisk (*)
           because it would enable all the users of  the  system,
           including the users at Unionbank, L & P Food, and Town
           Square to charge to the CORRECT-DATA account.

   Figures 6-3 and 6-4 show what  information  to  enter  into  base  and
   subaccount  files  for  Figure 6-2.  Each block in Figures 6-3 and 6-4
   contains information to be entered into a separate file.  Some of  the
   blocks  contain  subaccount  (/SUB:) entries that point to other files
   containing more information about that particular account.









                                    6-14
                             CREATING ACCOUNTS


   Figure 6-3 shows which entries to make for  account  CORRECT-DATA  and
   its subaccounts (the top half of Figure 6-2.)

   Figure 6-4 shows which entries to make for account UNIONBANK  and  its
   subaccounts  (the  bottom  half of Figure 6-2.) Note that all the base
   account entries for both Correct Data and Unionbank are  contained  in
   the file <HUDSON>ACCOUNTS.CMD.


             +-----------------------------------------------+
             | <HUDSON>ACCOUNTS.CMD                          |
             | ACCOUNT CORRECT-DATA/SUB:<GERARD>ACCOUNT.TXT  |
             | USER Hudson, Holland                          |
             | ACCOUNT CORRECT-DATA/SUB:<GIONET>ACCT.TXT     |
             | ACCOUNT CORRECT-DATA/SUB:<KING>ACCTG.TXT      |
             +-----------------------------------------------+
                                      |
                                      |
                                      |
                                      |
             -------------------------|-----------------------
             |                        |                      |
             |                        |                      |
             |                        |                      |
             |                        |                      |
   +-------------------+ +------------------------+ +-------------------+
   |<GERARD>ACCOUNT.TXT| |<GIONET>ACCT.TXT        | |<KING>ACCTG.TXT    |
   |ACCOUNT PAYROLL    | |ACCOUNT OVERHEAD-       | |ACCOUNT PROGRAMMING|
   |USER Gerard, Kelly | |/EXPIRES:31-DEC-86      | |USER King, Carlson |
   +-------------------+ |USER Gionet, Kohn, Kelly| +-------------------+ 
                         +------------------------+ 


   Figure 6-3:  Correct-Data Accounting Files


   The accounts that will be created are:

   CORRECT-DATA.PAYROLL
   CORRECT-DATA.OVERHEAD
   CORRECT-DATA.PROGRAMMING

   Note that users Hudson and Holland can use  any  account  number  that
   begins  with  CORRECT-DATA,  but  user Gerard can use only the account
   CORRECT-DATA.PAYROLL.    User   Kelly    can    use    the    accounts
   CORRECT-DATA.PAYROLL and CORRECT-DATA.OVERHEAD.

   The file type for  account  data  files  is  optional.   Your  project
   administrators  can  use  any  file  type, for example, .TXT, .CMD, or
   .ABC.




                                    6-15
                             CREATING ACCOUNTS



               +----------------------------------------------+
               |<HUDSON>ACCOUNTS.CMD                          |
               |ACCOUNT CORRECT-DATA/SUB:<WARRINER>ACCOUNT.TXT|
               |USER Hudson                                   |
               +----------------------------------------------+
                                     |
                                     |
               +----------------------------------------------+
               |  <WARRINER>ACCOUNT.TXT                       |
               |  ACCOUNT UNIONBANK/SUB:<BLOOMSTRAN>ACCT.TXT  |
               |  USER Warriner                               |
               |                                              |
               |  ACCOUNT UNIONBANK/SUB:<PREST>ACCO.TXT       |
               |                                              |
               |  ACCOUNT UNIONBANK/SUB:<PENDERGAST>MCA.TXT   |
               +----------------------------------------------+
                                     |
                                     |
         ----------------------------|-----------------------------
         |                           |                            |
   +--------------------+ +---------------------+ +----------------------+
   |<BLOOMSTRAN>ACCT.TXT| |<PREST>ACCO.TXT      | |<PENDERGAST>MCA.TXT   |
   |ACCOUNT TRUST       | |ACCOUNT LOANS-       | |ACCOUNT MSTRCHG       |
   |USER Bloomstran     | |/SUB:<THOMAS>LO.TXT  | |USER Pendergast, Prest|
   |                    | |USER Prest           | +----------------------+
   |ACCOUNT PAYROLL     | |                     |                     
   |USER Bloomstran     | |ACCOUNT LOANS-       |
   +--------------------+ |/SUB:<MILLS>DATA.TXT |
                          +---------------------+
                                     |
                                     |
                    -------------------------------------
                    |                                   |
          +--------------------+             +-----------------------+
          | <THOMAS>LO.TXT     |             |    <MILLS>DATA.TXT    |
          | ACCOUNT INSTAL     |             |    ACCOUNT COMM       |
          | USER Thomas        |             |    USER Mills         |
          |                    |             +-----------------------+
          | ACCOUNT CORP       |
          | USER Thomas, Mills |
          +--------------------+


   Figure 6-4:  Unionbank Accounting Files









                                    6-16
                             CREATING ACCOUNTS


   The accounts that will be created are:

   CORRECT-DATA.UNIONBANK.TRUST
   CORRECT-DATA.UNIONBANK.PAYROLL
   CORRECT-DATA.UNIONBANK.MSTRCHG
   CORRECT-DATA.UNIONBANK.LOANS.INSTAL
   CORRECT-DATA.UNIONBANK.LOANS.CORP
   CORRECT-DATA.UNIONBANK.LOANS.COMM



   6.3.3  Running the ACTGEN Program

   After you create the base account files and the project  administrator
   notifies  you that all his subaccount files are complete, you can tell
   the operator to run the ACTGEN program.  ACTGEN takes  the  accounting
   information  in  these  files  and  creates an account validation data
   base.  It is through this data base that  the  monitor  validates  all
   accounts  entered by the users of your system.  ACTGEN is a privileged
   program, so you must enable  WHEEL  or  OPERATOR  capabilities  before
   giving the ACTGEN command.  The command appears as follows:

   @ENABLE (CAPABILITIES)<RET>
   $ACTGEN<RET>
   ACTGEN>

   Valid commands that can be given  to  ACTGEN  are  HELP,  EXIT,  TAKE,
   CTRL/A, and INSTALL.

   The HELP command lists information to  assist  you  when  running  the
   ACTGEN program.

   The EXIT command terminates the program and returns you to the TOPS-20
   command level ($).

   The TAKE command accepts as its argument either a  file  specification
   or  a  carriage  return.  A carriage return defaults to your connected
   directory and the filename ACCOUNTS.CMD.  If you do not name your base
   account file ACCOUNTS.CMD, the file you specify should be the one that
   contains your base account information and points to all the  existing
   subaccount  files.   The  TAKE  command  tells  ACTGEN  to look in the
   specified (or default) file for account information.   It  also  tells
   ACTGEN  to  look  at any subaccount file specifications for additional
   information pertaining to the account(s) in  the  base  account  file.
   Using Figures 6-1 and 6-2, the manager, Hudson, would specify the TAKE
   command as follows:

   @ENABLE (CAPABILITIES)<RET>
   $ACTGEN<RET>
   ACTGEN> TAKE (COMMANDS FROM FILE)<RET>




                                    6-17
                             CREATING ACCOUNTS


   If the manager in these examples  had  named  his  base  account  file
   MACCT.TXT, he would specify the TAKE command as follows:

   ACTGEN> TAKE (COMMANDS FROM FILE) <HUDSON>MACCT.TXT<RET>

                                  CAUTION

           If the data files that are pointed  to  by  your  base
           account  file are located on structures other than the
           system structure, be sure the required structures  are
           mounted.   Otherwise,  the ACTGEN program will fail on
           those accounts that have subaccount files on unmounted
           structures.

   ACTGEN takes all the information specified in the account files, forms
   the   valid   accounts,   and  creates  a  new  version  of  the  file
   ACCOUNTS-TABLE.BIN in the directory where  ACTGEN  is  running.   Each
   time  the  ACTGEN  program  is run successfully, a new version of this
   file is created.

   While ACTGEN is creating the data base file, it checks  for  duplicate
   entries,  e.g.,  two  accounts of the same name, and the length of the
   accounts.  If an error occurs, an appropriate message  is  printed  on
   the  terminal  where  ACTGEN  is running, but the program continues to
   build the data base, using only the accurate data.  You should make  a
   note  of  the  error  on an error log sheet that you have prepared and
   later correct the appropriate files using an editor.

   ACTGEN also checks expiration dates.  If two or more expiration  dates
   are  given  for the same entry in a file, the system uses the earliest
   date.  For example:  if you specify May 15,  1987  as  the  expiration
   date  for account MATH and your project administrator specifies August
   30, 1987 for the account MATH.LAB-201, the system will stop validating
   all accounts beginning with MATH as of May 15, 1987.

   You can press CTRL/A while ACTGEN is running to stop the  program  and
   return  to ACTGEN command level.  The data files are closed and no new
   version of the data base file ACCOUNTS-TABLE.BIN is created from  this
   session.

   The INSTALL command starts account validation.  When  you  enter  this
   command,  ACTGEN  copies the ACCOUNTS-TABLE.BIN file in your connected
   directory  (or  the  directory  where  ACTGEN  created  the  file)  to
   <SYSTEM>ACCOUNTS-TABLE.BIN on the system structure and enables account
   validation using this new data base.

   Because the new version of ACCOUNTS-TABLE.BIN is kept in the directory
   where  ACTGEN  was  run  and not in the directory <SYSTEM>, you have a
   means of correcting any errors that might occur without disturbing the
   version  currently  running  in the <SYSTEM>ACCOUNTS-TABLE.BIN file on
   the system structure.  You can give the INSTALL command after you have
   corrected any problems.


                                    6-18
                             CREATING ACCOUNTS


   If you do not receive any errors while ACTGEN  is  creating  the  data
   base  file  (ACTGEN has successfully completed the accounting file and
   you receive the ACTGEN prompt),  you  can  give  the  INSTALL  command
   immediately.

   You    should    keep    track    of    which    version    of     the
   <SYSTEM>ACCOUNTS-TABLE.BIN  file  you  are  using.   A  log  book that
   contains the date that ACTGEN was run and the version  number  of  the
   data  base  file  is helpful should a system problem occur and you are
   not sure of which data base file you were using.  To  find  out  which
   version  you  are  using,  enable  capabilities and give the DIRECTORY
   command for <SYSTEM>ACCOUNTS-TABLE.BIN on the system  structure.   The
   generation  number  indicates  the  version that is presently running.
   The system looks in the current data base file each time it  validates
   a given account.



   6.3.4  Data Base Failures/Recovery

   If your accounting files were set  up  inaccurately,  or  you  entered
   random incorrect data into the data base file, account validation will
   not work properly.  You are aware of this because users cannot log  in
   and/or  use accounts that are normally valid for them.  Therefore, the
   account OPERATOR is set up for the user OPERATOR and is always  valid.
   The  operator  can  log into <OPERATOR> with the OPERATOR account, fix
   the files that are in error, and run ACTGEN to get account  validation
   working again.



   6.4  VALIDATING ACCOUNTS

   An account is validated when a user gives any  one  of  the  following
   TOPS-20 commands.

         o  LOGIN - A user must have a valid account to successfully  log
            into the system

         o  SET ACCOUNT (TO) argument

         o  Any queue  commands,  for  example,  PRINT,  SUBMIT,  if  the
            account is different from the currently validated account

         o  SET FILE ACCOUNT (OF FILES) arguments (TO) argument

         o  File creation with an explicit account







                                    6-19
                             CREATING ACCOUNTS


   The system records the computer time used for  valid  accounts.   This
   includes  CPU  time,  time used per structure,[1] and peripherals used
   per job, that is, the number of pages printed  on  the  line  printer,
   tape  mounts,  tape  records read/written, card reader usage, and disk
   storage.  The computer usage incurred by each account is stored in the
   accounting USAGE.OUT file.  This file is used for reports and billing.
   (Refer to the TOPS-20 Usage File Specification for  information  about
   reading and using this file).

   How often you run ACTGEN and create a new data base  file  depends  on
   how  frequently  you  change  your  accounts.   If  you expect to have
   frequent changes (e.g., opening and closing accounts), you may want to
   establish   a   standard   time   each   week  to  run  ACTGEN.   Your
   administrators should inform the operator when  changes  are  made  to
   their subaccount files.

                                    NOTE

           Once ACTGEN is run and the data  base  file  has  been
           created,  you  can  dump  all  the  account  files  to
           magnetic tape and conserve some of  your  disk  space.
           You must copy the files to disk the next time you need
           to run the ACTGEN program.
























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

    [1]  To account for the time used on a structure, you  must  set  the
         structure  as  REGULATED.  Refer to the TOPS-20 Operator's Guide
         for a description of REGULATED and NONREGULATED structures.


                                    6-20











                                 CHAPTER 7

                          SYSTEM BACKUP PROCEDURES



   All the disk packs on your system must be backed up on magnetic  tape.
   This procedure provides both a permanent record of the contents of the
   disk and a precautionary measure in the event a disk pack  and/or  its
   contents are destroyed.  On the first day of operation, start a system
   backup procedure that includes:

        1.  Saving all the files in all the directories on all structures

        2.  Saving the directory parameters and critical system programs

        3.  Saving the front-end file system (one time only)

   These procedures should become a  part  of  the  operator's  scheduled
   duties.

   It is important to start  backing  up  the  system  immediately  after
   installation.   If  you  follow  the  backup  procedures  as  they are
   outlined here and in the TOPS-20 Operator's Guide, you can restore the
   file system quickly and easily should a mishap occur.

   DUMPER

   The following sections discuss using the DUMPER program to save files.
   Make  sure  when  you  restore  these  files  with DUMPER that you are
   running the correct version of DUMPER with your  TOPS-20  monitor  and
   that  the  tape  version  is compatible with the software.  Otherwise,
   directory passwords could become unusable and you may have to manually
   respecify  them  with  the  BUILD  command.   Refer  to  Section 11.2,
   Password Encryption, for  details.   In  addition,  project-programmer
   numbers,  supported  in  TOPS-20 Version 6, may not be restored at all
   with incompatible versions of the software.

   In a CFS configuration, DUMPER must run on the  system  to  which  the
   tape drives are attached.





                                    7-1
                          SYSTEM BACKUP PROCEDURES


   To simplify backup and  restore  operations,  you  can  create  DUMPER
   command  files  for the operator.  Rather than type a list of commands
   to DUMPER, the operator can then just give the  TAKE  command  with  a
   command  file  name  as an argument.  DUMPER will sequentially execute
   commands contained in the file.

   The TOPS-20 User Utilities Guide  and  the  TOPS-20  Operator's  Guide
   discuss the DUMPER program in detail.



   7.1  SAVING ALL FILES IN ALL DIRECTORIES

   Have the operator run the DUMPER program (with  the  /FULL-INCREMENTAL
   switch  to  the  SAVE  command)  to save all files in all directories.
   This procedure includes saving  all  the  directories  on  the  system
   structure  and  all  the  directories on any additional structures you
   have created.  You can save all the files (a full dump)  or  just  the
   files  that  have  changed since the last time the operator ran DUMPER
   (an incremental dump).

   Start a library of the magnetic  tapes  from  the  DUMPER  operations.
   Each  structure  should  be  copied  to a separate tape(s).  Each tape
   should be identified  with  the  system  model  number  or  name,  for
   example,  2060,  or  System-A,  the  date,  the  type of save (full or
   incremental), the name of the structure, and the tape number.  (A tape
   set  name  may  replace the tape number, if labeled tapes are used.) A
   typical identification may look like:

       SYSTEM-A (2060)                                 SYSTEM-A (2060)
       30-JANUARY-1988                                 30-JANUARY-1988
       Incremental                 OR:                 Full
       ADMIN:                                          ADMIN:
       Tape #1 of 2                                    Tape #3 of 3

   In addition to keeping the tapes, keep the listing of their  contents.
   (The operator includes a command to DUMPER to list the contents of the
   magnetic tapes on the line printer.) These DUMPER  log  files  can  be
   conveniently  kept  in  a  binder with the most recent listing on top.
   Identify each binder with the system model or name, for example,  2065
   or System-A.  (Chapter 9, System Problems/Crashes describes how to use
   these log files to restore directories and files.)

   Tell users that backup files do exist and  post  the  times  when  the
   operator  normally  creates the backup tapes.  Many system managers do
   not allow users to enter the computer room to mount and use the  tapes
   themselves.







                                    7-2
                          SYSTEM BACKUP PROCEDURES


                                    NOTE

           The DUMPER program DOES NOT  save  the  files  in  the
           console  front-end  file  system.   If  you lose these
           files, you must restore them from  the  floppy  disks.
           (Refer to Section 7.6)



   7.1.1  Full Dumps

   Full dumps contain  all  the  information  on  the  system,  with  the
   exception  of  the console front-end files, and can be used to restore
   many of the files that were on the system  to  their  previous  state.
   Therefore,  full dumps contain a copy of every file in every directory
   on every structure.

                                    NOTE

           Full dumps are known as FULL-INCREMENTAL dumps.   This
           name  corresponds to the /FULL-INCREMENTAL switch that
           you give with the SAVE command to DUMPER.



   7.1.2  Incremental Dumps

   Incremental  dumps  (using  the  /INCREMENTAL  switch  with  the  SAVE
   command)  cause  DUMPER  to  save the files that have never been saved
   (new files) and the files that have been updated since the  last  time
   an  incremental DUMPER operation was performed.  Many managers request
   an incremental dump Monday through Thursday and a full dump on Friday.

   The File Descriptor Block (FDB) of each file contains the  information
   necessary  to determine if the file has been updated since it was last
   saved during an incremental DUMPER operation.  A file that has changed
   since the last time it was saved is automatically saved again on tape;
   otherwise, it is passed over.

   The operator should give the INCREMENTAL switch to DUMPER and  specify
   each  structure  one  at a time.  By running DUMPER for each structure
   individually, the operator can copy each  structure  onto  a  separate
   tape.   After  running  DUMPER  and  copying  the  structures that are
   presently on-line, the operator should mount any additional structures
   that have been used that day and run DUMPER for them also.

   An incremental dump is faster than  a  full  dump  and  requires  less
   magnetic  tape.   By  specifying a value with the /INCREMENTAL switch,
   you  can  cause  modified  files  to  be  written  to  more  than  one
   incremental  backup  tape.   This is helpful if you want to be certain
   you can recover the files, even if one of the tapes has data errors.



                                    7-3
                          SYSTEM BACKUP PROCEDURES


   7.1.3  Security of Backup Tapes

   It is a good idea to protect the security of your  backup  tapes.   If
   you  allow  a  non-privileged  user  to mount them, he or she may gain
   access to confidential information, such as other user's  data  files.
   If  the  unencrypted  passwords  were saved along with other directory
   parameters, a technically sophisticated user can  retrieve  them  from
   the  DUMPER  backup  tapes, and thus obtain unauthorized access to the
   privileged accounts on the system.



   7.2  A COMMON BACKUP POLICY

   A common backup policy is outlined below.  You can  set  up  your  own
   backup policy.

        1.  Each day, take an incremental save of  the  files  that  have
            changed  from  the  previous  day's  backup  tape.   Keep the
            incremental saves until a full save is made,  at  which  time
            you can recycle the incremental tapes.

        2.  At the end of the week, take a full save of all the files  on
            the  system.   Keep  the  full saves for six months, at which
            time you can recycle the tapes into the backup system.

        3.  Every six months, take a full save and keep it for  a  number
            of years, or if you choose, indefinitely.



   7.3  MAGNETIC TAPE REQUIREMENTS

   You need  a  supply  of  magnetic  tapes  to  start  a  system  backup
   procedure.   This section provides a guideline for the number of tapes
   you should have on hand for your installation.   It  is  assumed  that
   there are 2400 feet per reel of tape.

















                                    7-4
                          SYSTEM BACKUP PROCEDURES


     __________________________________________________________________

     Type of                    Reels Per             Bits Per
     Disk Drive                 Drive                 Inch
     __________________________________________________________________

     RP06                        7                    1600

     RP06                        2                    6250

     RA60                        9                    1600

     RA60                        3                    6250

     RP20 (one                  19                    1600
     spindle)

     RP20 (both                 37                    1600
     spindles)

     RP20 (one                   6                    6250
     spindle)

     RP20 (both                 12                    6250
     spindles)

     RP07                        7                    6250

     RP07                       19                    1600

     RA81                        6                    6250

     RA81                       19                    1600
     __________________________________________________________________


   Therefore, the number of tapes you stock depends on the type of  disks
   at  your  installation.   It  also depends on the backup procedure you
   use.  For example, if you save your daily incremental tape dumps for a
   longer  time  than  usual, it takes longer to recycle these tapes into
   the backup system, and thus you need more tapes.

   Generally, during the first month after  installation,  you  may  need
   approximately  36  (2400  ft.)  tapes  for each RP06 or RA60, 45 tapes
   (6250 bit/in) or 180  tapes  (1600  bit/in)  for  each  RP20  disk  (2
   spindles), and 72 tapes for each RP07 or RA81 (1600 bit/in).








                                    7-5
                          SYSTEM BACKUP PROCEDURES


                                    NOTE

           These estimates assume a magnetic tape blocking factor
           of  1.   You  can specify a higher blocking factor and
           save much space on your  tapes.   Before  doing  this,
           however,  there  are  cautions that you must consider.
           The  description  of  DUMPER  in  the   TOPS-20   User
           Utilities Guide explains how and when you can increase
           blocking factors.



   7.4  MAKING A SYSTEM CRASH TAPE

   As the name implies, the system crash tape is used  to  re-create  the
   system  structure  should it become unusable.  This tape is created in
   addition to the tapes that contain  FULL-INCREMENTAL  and  INCREMENTAL
   saves  of  all  files  and  directories.  You should make a new system
   crash  tape  whenever  you  add  a  new  user,  change  any  directory
   parameters, or make a change (patch) to:

         o  The monitor you are running

         o  The TOPS-20 Command Processor

         o  The DLUSER program

         o  The DUMPER program

   Therefore, the crash tape contains only the files necessary to recover
   user  directory  parameters and important system programs.  User files
   themselves are restored  from  the  FULL-INCREMENTAL  and  INCREMENTAL
   saves of the public structure.

   Label this tape SYSTEM BACKUP TAPE and include  the  system  structure
   name;  DECSYSTEM-20  model  number  or  name,  for  example,  2060  or
   System-B; and the date and time the  tape  was  created.   You  should
   follow  this procedure once a day if users are allowed to change their
   own directory parameters.  (Refer to  Section  5.7.2  for  information
   about  allowing  users to change directory parameters.) If you are not
   using password encryption (refer  to  Section  11.2),  be  careful  to
   protect  the  backup  tapes  against  reading  by  unauthorized users,
   because all the passwords for your users will be accessible.

   If you are also using mountable structures,  you  should  periodically
   run  DLUSER  to  copy  their directory parameters to a file on another
   structure, preferably the system structure.  Then,  if  the  mountable
   structure is destroyed, you will be able to recreate the directories.






                                    7-6
                          SYSTEM BACKUP PROCEDURES


                                    NOTE

           Do not use a labeled tape when creating a System Crash
           Tape.   The  reason  for this is that the installation
           software that is used to create the  system  structure
           cannot read tape labels.

   The order of files on the crash tape is:

        1.  <SYSTEM>MONITR.EXE

        2.  <SYSTEM>EXEC.EXE

        3.  <SYSTEM>DLUSER.EXE

        4.  DLUSER data files

        5.  <SUBSYS>DUMPER.EXE

        6.  DUMPER save sets containing the directories:

            <SYSTEM>
            <SUBSYS>
            <NEW-SYSTEM>
            <NEW-SUBSYS>
            <UETP>
            <GALAXY-SUBSYS>

   Notice that the format of  this  tape  is  the  same  as  the  TOPS-20
   Installation Tape that you used to install the TOPS-20 software.
























                                    7-7
                          SYSTEM BACKUP PROCEDURES


   7.5  MAKING A CRASH TAPE USING BATCH

   You can create a batch job  to  make  your  crash  tape  or  type  the
   commands  at  the  operator's  terminal.  Example 1 shows the standard
   control file that you can submit as a batch job to create  this  tape.
   In the example, PUB:  is the name of the system structure.

   EXAMPLE 1

   SYSTAP Control File

   @TYPE(FILE) SYS:SYSTAP.CTL<RET>

   ! Obtain a tape drive
   @MOUNT TAPE TAPE:/WRITE/LABEL:UNLABELED

   !Systems not using Tape Drive Allocation must replace the
   !MOUNT TAPE command with @ASSIGN MTA0: and @DEFINE TAPE:
   !(AS) MTA0: commands.

   @ENABLE (CAPABILITIES)
   @REWIND (DEVICE) TAPE:

   !Save the monitor
   @GET (PROGRAM) PUB:<SYSTEM>MONITR.EXE
   @SAVE (ON FILE) TAPE:  !Save the TOPS-20 Command Language Interpreter
   @GET (PROGRAM) SYSTEM:EXEC.EXE
   @SAVE (ON FILE) TAPE:

   !Save the DLUSER program
   @GET (PROGRAM) SYS:DLUSER.EXE
   @SAVE (ON FILE) TAPE:

   !Run the same DLUSER program, saving the directory structure
   !on tape
   @START
   *DUMP (TO FILE) TAPE:
   *EXIT

   !Save DUMPER
   @GET (PROGRAM) SYS:DUMPER.EXE
   @SAVE (ON FILE) TAPE:  !Run the same DUMPER, saving SYSTEM: and SYS:
   @START
   *TAPE (DEVICE) TAPE:
   *LIST (LOG INFORMATION ON FILE) SYSTAP.LPT
   *SSNAME SYSTEM-FILES
   *SAVE (DISK FILES) PUB:<NEW-SYSTEM>,PUB:<SYSTEM>
   *SSNAME SUBSYS-FILES
   *SAVE (DISK FILES) PUB:<NEW-SUBSYS>,PUB:<SUBSYS>
   *EXIT




                                    7-8
                          SYSTEM BACKUP PROCEDURES


   !Print the DUMPER log file
   @PRINT SYSTAP.LPT/NOTE:BACKUP TAPE

   @DISMOUNT TAPE:
   @

   !Systems not using Tape Drive Allocation must replace the
   !DISMOUNT TAPE: command with @UNLOAD (DEVICE) TAPE:  and
   !@DEASSIGN TAPE: commands.

   To run SYSTAP, submit the batch control file using the TOPS-20  SUBMIT
   command.   In  the  event  the  system structure becomes unusable, the
   crash tape can now be  used  by  following  the  instructions  in  the
   TOPS-20 KL Model B Installation Guide.

                                   HINT:

           Before you store the crash tape, verify that you  have
           made  a  usable  tape.   That  is, mount the new crash
           tape, follow the instructions in the TOPS-20 KL  Model
           B  Installation  Guide  to  load  the monitor, and use
           DUMPER to get a listing of the tape's contents.
































                                    7-9
                          SYSTEM BACKUP PROCEDURES


   7.6  SAVING THE CONSOLE FRONT-END FILE SYSTEM

   The DUMPER program does not save the contents of the console front-end
   file  system.  You can, however, make a backup copy of the file system
   by copying your floppy disks using  the  front-end  program  COP  (for
   copy).   You  should  make  at  least  one backup copy of your console
   front-end file system (refer to Section 3.4).

   To run the COP program, follow the steps outlined below.  You need not
   stop timesharing when following these steps.

        1.  At the operator's console, type  CTRL/backslash;  the  system
            prints PAR>.

            CTRL/backslash

            PAR>

        2.  Type MCR COP and press the RETURN key; the system prints  the
            COP prompt.

            PAR>MCR COP<RET>
            COP>

        3.  Place the floppy disk to be copied in drive 0 and the  floppy
            to  contain  the  new files in drive 1.  Be sure to mount the
            floppy disks correctly; this includes checking that the paper
            containing  the floppy directory is not accidentally attached
            to the back of the floppy disk.

        4.  Type DX1:=DX0:  and press the RETURN key; the  system  starts
            the copying, which takes a few minutes.  After the copying is
            complete, the system verifies the copy and prints a  message.
            Type CTRL/Z to exit COP.

            COP>DX1:=DX0:<RET>
            COP - STARTING VERIFY

            COP>^Z

        5.  To return to TOPS-20 Command Level,  type  a  CTRL/backslash;
            the system prints PAR>; type another CTRL/Z, or type QUIT and
            press the RETURN key.

            CTRL/backslash

            PAR>^Z

            @





                                    7-10











                                 CHAPTER 8

                                TAPE STORAGE



   Chapters 1 through 6 deal primarily with setting  up  and  using  your
   disk  resources.   Chapter 7, System Backup, describes how to save all
   the data from your disk structures onto magnetic  tape.   These  tapes
   are  the  backup tapes that you use to restore directories and perhaps
   entire disk structures if something happens to  the  disks  (refer  to
   Chapter  9).   In  addition  to using magnetic tapes for system backup
   tapes, you can use magnetic tapes to store other  types  of  data  and
   save valuable disk space.

   This chapter  describes  two  other  uses  for  magnetic  tapes,  File
   Archiving and File Migration.  It also describes how you can allow the
   system and the operator to control all tape  drive  assignments,  Tape
   Drive  Allocation, and how you can set up some or all of your tapes to
   contain labels, Tape  Labeling.   These  uses  are  described  in  the
   following order.

         o  FILE ARCHIVING

         o  FILE MIGRATION

         o  TAPE DRIVE ALLOCATION

         o  TAPE LABELING

   In addition, the last section of the chapter discusses how to  set  up
   two DECSYSTEM-20s to share a TX02 tape subsystem.

   File archiving provides you and users of the system with  a  voluntary
   way  to  move  important  files  from  the  disk  to magnetic tape for
   long-term storage.  These tapes are stored separately from your system
   backup  tapes.   Users  can  access these tape files as easily as they
   access files on the disk.  When users want to restore  archived  files
   to  disk,  they  give a command to the TOPS-20 command processor.  The
   system then tells the operator which tapes to mount  and  proceeds  to
   restore  the  files.  Section 8.1 describes why you would use the file
   archiving facility, and how to set up your system to archive files  to
   magnetic tape.


                                    8-1
                                TAPE STORAGE


   File migration provides you with a means of  controlling  the  use  of
   disk space.  File migration is especially useful if your disk space is
   very low on a particular structure, for example, the system structure.
   This  type of disk space control is, for the most part, involuntary on
   the part of the user.  Old unused disk files  are  periodically  moved
   (migrated) to magnetic tape by the system operator.  Again, you should
   store these tapes separately from your  system  backup  tapes.   Users
   still  maintain  easy access to these files and retrieve them the same
   way as they retrieve archived files.  Section 8.2  describes  why  and
   when  you would use the file migration facility and how to set up your
   system to migrate files to magnetic tape.

   If you use the file archiving or file migration facilities,  or  both,
   remember that these tapes are in addition to your system backup tapes.
   They are not replacements.   You  must  continue  to  run  the  DUMPER
   program and create full and incremental system backup tapes.

   Tape drive allocation provides the system and computer  operator  with
   complete  control  over tape drive usage.  This means that it prevents
   users from issuing the ASSIGN command and reserving  tape  drives  for
   their  jobs.   When  users  issue  the MOUNT command, the TOPS-20 Tape
   Drive Allocation system and the operator  control  the  allocation  of
   tape  drives.   You must use the tape drive allocation facility if you
   use tape labeling; however,  using  tape  drive  allocation  does  not
   restrict you to using labeled tapes.

   Tape labeling provides a means of storing  label  information  on  the
   tape  itself  that  identifies  the tape and describes the data on the
   tape.  This label information is in an industry standard format so you
   can  read  and  write tapes to be used with different computers.  Tape
   labels can also add more security and reliability to your tape system.
   Section  8.4  describes why you would use tape labels, and also how to
   set up your system to begin labeling tapes.

   There are no dependencies among file archiving,  file  migration,  and
   tape  labeling.   For example, you can use the file archiving facility
   without using file migration or tape labeling.  Each tape facility can
   be used separately.  There is, however, the dependency that tape drive
   allocation must be turned on to use tape labels.



   8.1  FILE ARCHIVING

   File archiving provides a means of storing data on magnetic  tape  and
   freeing  valuable  disk  space.   This type of off-line storage allows
   users to store (archive) important files on tape, keeping  their  disk
   space  below their permanent allocation, and still have easy access to
   those files.

   If your installation has more than one computer  system,  the  archive
   tapes  can  be  common to all systems.  You can put files on tape from


                                    8-2
                                TAPE STORAGE


   one system, move a directory and its  files  to  another  system,  and
   still retrieve files from the tape in the ordinary manner.

   Unlike general system backup tapes, the tapes  that  contain  archived
   files  are  usually kept for a much longer time, for example, seven to
   ten years.



   8.1.1  Setting Up the System to Use File Archiving

   When you receive the TOPS-20 Installation Tape and have brought up the
   TOPS-20  monitor, your system contains a built-in default of 3650 days
   for recycling archived tapes.   To  change  the  3650  day  (10  year)
   default,  you  can  enter  a  command  in  the n-CONFIG.CMD file.  The
   command you use is:

   ARCHIVE-TAPE-RECYCLE-PERIOD days

   Select a length of time that is  appropriate  for  your  installation.
   Place the ARCHIVE-TAPE-RECYCLE-PERIOD command in the n-CONFIG.CMD file
   during software installation, or edit the file at a  later  date  when
   you are planning to reload the system.

   Each time the DUMPER program copies  an  archived  file  to  tape,  it
   places  the expiration date argument in the FDB of the file.  The MAIL
   program notifies users when a file on tape has reached its  expiration
   date.   If  the  file is no longer needed, the user can discard (using
   the DISCARD command) the information in the file's FDB that points  to
   the  file  on  tape.   After all the files on a tape have passed their
   expiration dates and no users have  FDBs  in  their  directories  that
   point  to that tape, the tape can be recycled.  Refer to Section 8.2.5
   for additional information on how to recycle tapes.



   8.1.2  What Happens When Users Archive Files

   Users archive files voluntarily by giving the ARCHIVE command.   After
   a   specific   generation   of   a   file  has  been  archived  (e.g.,
   MYFILE.CBL.6), it cannot change.  Users can obtain copies of  archived
   files  by  using  the  RETRIEVE command, but cannot alter those files.
   The TOPS-20 User's Guide describes the ARCHIVE and RETRIEVE commands.











                                    8-3
                                TAPE STORAGE


   When you establish your installation's policy for file  archiving  and
   notify  users  of  its availability, you may want to instruct users to
   archive source files only.  For example, files with a file type

   .CBL, .MAC, .TXT, .RNO, or .FOR

   should be archived; but, files with the file type

   .REL, .EXE, or .MEM

   should not be.  This restriction saves space on your magnetic tapes.

   To completely archive a file, two copies must exist in  the  archives.
   This means that each archived file is stored on two tapes.  Having the
   archived file on two tapes provides you with a backup  tape  if  later
   you  cannot retrieve a file off one of the tapes.  The DUMPER program,
   which is used to archive files, records both tape identifying  numbers
   in the FDBs of the files being archived.

   The diagrams below illustrate what happens  when  a  user  archives  a
   file.

   First, the user creates a file.   The  File  Descriptor  Block  (FDB),
   among  other  file  information, contains a pointer to the location of
   the file on the disk.


                             Pointer to File
                FDB  --------------------------------->  DISK
                              on the Disk


   The user gives the ARCHIVE command for this file.  The first  or  next
   time  the  operator  runs  DUMPER with the ARCHIVE command, the system
   locates all files that have been marked for archival  by  the  ARCHIVE
   command and copies these files to tape.  The FDB now contains pointers
   to the file on the disk and to the file on the tape.


      -----------
      |         |             Pointer to File on the Disk
      |         |  ---------------------------------------------> DISK
      |         |
      |  FDB    |
      |         |
      |         |              Pointer to File on Tape
      |         |  ---------------------------------------------> TAPE
      -----------






                                    8-4
                                TAPE STORAGE


   The second or subsequent  time  the  operator  runs  DUMPER  with  the
   ARCHIVE  command  (remember  that  archived files are contained on two
   tapes), DUMPER copies the file again to the second tape.  DUMPER  then
   deletes  the  pointer to the location of the file on the disk.  DUMPER
   places another pointer in the file's  FDB  to  the  second  tape  that
   contains the file and deletes the contents of the file on disk.  After
   a user archives a file, the file name no longer appears in the  user's
   directory  list.   The  user  must give the DIRECTORY command with the
   ARCHIVE or INVISIBLE subcommand to see the file name.


        -----------
        |         |  ----------------------------------------> TAPE
        |         |
        |  FDB    |               Two Pointers to Tape
        |         |              
        |         |  
        |         |  ----------------------------------------> TAPE
        -----------



   8.1.3  What Happens When Users Retrieve Files

   Users request files be returned  to  disk  (retrieved)  by  using  the
   RETRIEVE  command.  When the operator runs DUMPER to process retrieval
   requests, DUMPER  notifies  the  operator  of  the  second  tape  that
   contains  the file.  If the file cannot be copied from the tape (e.g.,
   the tape is bad), DUMPER notifies the operator of the first tape  that
   contains  the  file.   When  DUMPER returns a file to disk, the FDB of
   that file now contains two pointers to tape and one to the disk.   The
   pointer  to  the file on the disk remains in the FDB until the file is
   deleted from disk.



   8.1.4  When to Create Archive Tapes

   You can select how often the operator runs DUMPER  to  archive  files.
   However, running DUMPER (with the ARCHIVE command) every day before or
   after your general system backup procedure is probably closest to your
   present schedule.

   The steps below provide an example  of  a  typical  procedure.   These
   steps  assume  that  this  is  the first time you are archiving files.
   Although you do not have to use this procedure, it is  one  that  best
   utilizes your tape resources.  (The TOPS-20 Operator's Guide describes
   the procedure for running DUMPER with the ARCHIVE command.)






                                    8-5
                                TAPE STORAGE


      Step                     Procedure

      1.  The operator runs DUMPER and performs the  normal  (incremental
          or  full)  backup  procedures for the entire system.  (Refer to
          Chapter 7, System Backup Procedures.)

      2.  The operator mounts a brand new tape  (a  tape  that  has  been
          initialized  if  you  are  using  tape labels; refer to Section
          8.4.3) to contain the archived files, for example, TAPE 1.

      3.  The operator runs DUMPER  with  the  ARCHIVE  command.   DUMPER
          locates all files marked for archival and copies them to tape.

      4.  The next evening (or the next time system backup is performed),
          the  operator  mounts  a brand new tape, e.g., TAPE 2.  He does
          NOT mount the tape used the first time.

      5.  The operator runs DUMPER with the ARCHIVE command.   This  time
          DUMPER  finishes  the  archival  run  of  the previous night by
          making a second copy  of  those  files.   In  addition,  DUMPER
          locates all the files newly marked for archival and copies them
          to tape for the first time.

      6.  The operator repeats this process every day until the tapes are
          full.

      7.  For example, the third night, the  operator  mounts  the  first
          tape, TAPE 1.

      8.  The operator runs DUMPER.  DUMPER finishes the archival run  of
          the  previous  night  by  making  a second copy of the previous
          night's files.  It also locates all the files newly marked  for
          archival and copies them to tape.

      9.  The fourth night, the operator mounts the second tape, TAPE  2.
          Again,  DUMPER  finishes the archival run of the previous night
          by making a second copy of those files.  It  also  locates  all
          the files newly marked for archival and copies them to tape.

                                    NOTE

           DUMPER checks tapes for duplicate files.  It does  not
           write  both  copies of the same file on the same tape.
           If the wrong tape is mounted, DUMPER outputs an  error
           message.









                                    8-6
                                TAPE STORAGE


   8.1.5  Processing Retrieval Requests

   When a user gives the RETRIEVE command to request  an  archived  file,
   the request is stored in a queue.  You must establish a policy for how
   often the operator should process the retrieval requests contained  in
   the  queue.   (The  TOPS-20  Operator's Guide describes how to process
   retrieval requests.) If you have encouraged  users  to  archive  their
   files,  you  should instruct the operator to process the request queue
   frequently.



   8.2  FILE MIGRATION

   Some installations must control the use of disk space by  periodically
   migrating  files  to magnetic tape.  This forced file migration allows
   the management of an installation to move old unused disk files  to  a
   less  expensive  storage  medium.  Similar to archived files, migrated
   files are still easily accessible to the user.   File  migration  also
   allows   you   to   keep  users'  directories  below  their  permanent
   allocation.  (Refer to Section 5.5 for a description of permanent  and
   working storage allocations.)

   Whether you use the file migration facility depends almost entirely on
   your disk space resources.  If users are archiving files regularly, if
   their directories are  usually  below  their  allowed  permanent  disk
   allocation, and your system is not continuously interrupted with "disk
   space low" messages, you may choose not to migrate files.   Otherwise,
   if  you  are  constantly  receiving  the  [CAUTION - DISK SPACE LOW ON
   structure name] message, you may want to forcibly migrate  files  from
   the disk.

   Sections 8.2.1 through 8.2.3  describe  using  file  migration.   They
   include:

         o  the program you must run before migrating files to tape

         o  the command that can be placed in the  n-CONFIG.CMD  file  to
            change the default tape recycle period

         o  when to run the REAPER program that marks files for migration
            and  marks  for  deletion  the  contents  of  archived and/or
            migrated files

         o  a sample of the REAPER.CMD file that you can use as a default
            file to be read by the REAPER program

         o  when to run the DUMPER program that locates files marked  for
            migration and copies them to tape





                                    8-7
                                TAPE STORAGE


         o  when to process retrieval requests for migrated files

         o  when to recycle migrated (and archived) tapes



   8.2.1  Setting Up the System to Use File Migration

   When you receive the TOPS-20 Installation Tape and have brought up the
   new  TOPS-20  monitor,  your system contains a built-in default of 180
   days for recycling migrated tapes.  This default is placed in the  FDB
   of each file as it is migrated to tape.

   To change the  180-day  default,  you  can  enter  a  command  in  the
   n-CONFIG.CMD  file  to inform the system when you plan to recycle your
   migrated tapes.  This command is:

   TAPE-RECYCLE-PERIOD days

   Select a length of time that is  appropriate  for  your  installation.
   The  default of 180 days, however, is a standard time period.  You can
   place the TAPE-RECYCLE-PERIOD command in the n-CONFIG.CMD file at  the
   time  you  install  the  system  (refer  to  the  TOPS-20  KL  Model B
   Installation Guide).  Or, you can edit  the  n-CONFIG.CMD  file  at  a
   later  date.   Remember that if you edit the file at a later date, you
   must reload the system to process the  commands  in  the  n-CONFIG.CMD
   file.

                                  CAUTION

           If you decide to change the 180 day default, place the
           TAPE-RECYCLE-PERIOD  command  with the new argument in
           the  n-CONFIG.CMD  file   and   reload   the   system.
           Otherwise,  the  default  recycling  period  does  not
           change until the next system reload.



   8.2.2  Using the REAPER Program

   The REAPER program is the tool used to free disk space.   It  performs
   the following functions:

         o  Marks for migration the files that have not  been  referenced
            for a specified period of time

         o  Marks for deletion the disk contents of archived or  migrated
            files,  either  after  they  have been successfully copied to
            tape, or after they have  been  returned  to  disk  with  the
            RETRIEVE   command,  and  have  not  been  referenced  for  a
            specified period of time



                                    8-8
                                TAPE STORAGE


         o  Trims directories that are over permanent disk allocation  by
            marking files in those directories for migration

         o  Deletes (purges) the tape pointers in FDBs on the  disk  that
            have  reached  their  tape storage expiration date.  That is,
            the file's FDB will  no  longer  contain  a  pointer  to  the
            contents of the file on tape.

   You can instruct the operator to run the REAPER  program  and  perform
   one, several, or all of these functions.  The operator can give a list
   of commands to REAPER  or  use  the  TAKE  command  with  the  default
   argument  SYSTEM:REAPER.CMD.   After  the  system  is  installed,  the
   directory <SYSTEM> contains a default REAPER.CMD file.   You  can  use
   this file as it is or use an editor and change the default parameters.
   The default SYSTEM:REAPER.CMD file appears similar to the following.

   $TYPE (FILENAME) SYSTEM:REAPER.CMD<RET>

   !Sample REAPER policy file

   !Directories not to be considered (specify the structure and
   !directory)

   SKIP PUB:<NEW-SUBSYS>,PUB:<NEW-SYSTEM>,PUB:<SYSTEM>,PUB:<SUBSYS>

   PERIOD 60                 !Specifies the age limit on
                             !files

   MIGRATE                   !Migrate files older than PERIOD days

   DELETE-CONTENTS           !Delete the contents of
                             !unreferenced files older than
                             !PERIOD with tape backup

   TRIM                      !Trim directories over perm allocation
                             !back to perm allocation

   ORDER *.TMP,*.LST,*.REL   !TAKE files in this order
                             !during TRIM

   Note that the SKIP command includes a list of directories that are not
   to be touched by the REAPER program.  You can add other system or user
   directories to this list.   The  list  can  contain  approximately  75
   directories.   Be  sure that the operator always includes this command
   when running the  REAPER  program;  otherwise,  you  may  accidentally
   migrate  some  very  important  files from the disk.  You can use more
   than one SKIP command to specify additional directories to be skipped,
   rather  than  list  them all in one command.  That way, if there is an
   error in processing one command, it will not affect the processing  of
   the  other commands.  This is especially useful when SKIP commands are
   included in a file.



                                    8-9
                                TAPE STORAGE


   The REAPER program accepts the following commands.

   BEGIN (Processing files)
   DELETE-CONTENTS (Of old offline files)
   EXIT (To monitor)
   LIST (Output to file)
   MIGRATE (Old files to offline storage)
   ORDER (For trimming)
   PERIOD (For migration)
|  POLICY (does a TAKE on SYSTEM:REAPER.CMD)

   PURGE (Expired FDBs from disk)
   SCAN (Only)
   SKIP (Directories)
   TAKE (Commands from file)
   TAPE (Check of tapes in use)
   TRIM (Directories over allocation)

   The TOPS-20 Operator's Guide provides a complete  description  of  all
   the  commands that can be given to the REAPER program or placed in the
   REAPER.CMD file.  Typically, you give a number of commands to  REAPER,
   one for each operation you want performed.

   The availability of disk space determines how often you run the REAPER
   program.   If  your  disk space is low, you may want to run the REAPER
   program daily to free up  as  much  disk  space  as  possible.   Other
   installations may run it once a month or less.



   8.2.3  Using the DUMPER Program

   After the REAPER program marks files for migration, the operator  runs
   the  DUMPER program to copy the files to tape.  Similar to an archived
   file, a migrated file is not completely migrated until two  copies  of
   the  file exist on magnetic tape.  Section 8.1.4 describes a procedure
   for copying archived files to tape.  You can use this  same  procedure
   for migrated files, by using the MIGRATE command instead of ARCHIVE.

   If you use both the file archiving facility  and  the  file  migration
   facility,  do not merge archived and migrated files on the same tapes.
   The expiration dates  for  migrated  files  differ  greatly  from  the
   expiration dates on archived files.  If you put them on the same tape,
   you will end up saving migrated files for approximately ten years  and
   use up all your tape resources very quickly.









                                    8-10
                                TAPE STORAGE


   8.2.4  Processing Retrieval Requests for Migrated Files

   When a user gives a  DIRECTORY  command,  the  files  that  have  been
   migrated  to  tape  still  appear in the directory list; however, each
   file has a notation (;OFFLINE) beside the filename  to  indicate  that
   the  file  is  contained on tape and not on the disk.  The versions of
   migrated files that have been copied to tape can be returned to  disk,
   and  unlike  archived files, they can be altered and/or renamed in the
   ordinary manner.  The user requests that a migrated file  be  returned
   to  disk  with the RETRIEVE command.  These requests are stored in the
   same queue as archive requests until the operator processes the queue.
   The  TOPS-20  Operator's  Guide  describes  how  to  process retrieval
   requests.  Retrieval requests for migrated or archived files should be
   processed frequently.



   8.2.5  Recycling Migration (and Archive) Tapes

   When all the migrated or archived files on a tape  have  passed  their
   expiration dates and all pointers to these files on the disk have been
   deleted, you can recycle the tape.

   The PURGE command to REAPER checks tape expiration dates and  notifies
   users  by the MAIL program when migrated or archived files on tape are
   about to expire.  Users can retrieve the file to disk again or discard
   the tape pointer on disk if they no longer need the file.

   The operator can determine if a tape can be  recycled  by  giving  the
   TAPE command to REAPER.  If a tape is not mentioned in the TAPE output
   list, this means that none of the disk structures that are on-line  at
   this  time  and specified to REAPER contain FDB pointers to that tape.
   However, be sure that you check all possible places for on-line (disk)
   pointers  to  this tape.  That is, run REAPER with the TAPE command on
   all the disk structures on all systems that may  contain  pointers  to
   this tape.  If files have passed their expiration date and pointers to
   them still exist on the disk, the operator can  run  REAPER  with  the
   PURGE  command  to  delete  these  pointers.   The  operator should be
   certain that files  are  no  longer  needed  before  using  the  PURGE
   command.

                                    HINT

           When a migration tape is full, have the  operator  use
           the  PRINT  command  to  DUMPER  to obtain a hard-copy
           listing of the tape contents.








                                    8-11
                                TAPE STORAGE


   8.3  TAPE DRIVE ALLOCATION

   Tape drive allocation provides the system,  and  not  the  user,  with
   complete  control  over  tape  drive usage.  When accessing a magnetic
   tape, the user must give a MOUNT command to request that the  operator
   mount  the  tape on a drive.  Once the operator responds to the user's
   request, the user can access the tape.  When the user is finished with
   the  tape,  the  user  gives  the DISMOUNT command to release the tape
   drive back to the system.  From the user's point of  view,  the  MOUNT
   and  DISMOUNT  commands replace the ASSIGN and DEASSIGN commands.  The
   operator selects the drive for the user, and the  system  informs  the
   user  how  to  access the tape.  Using tape labeling requires that you
   use tape drive allocation; however, this does not restrict you to  the
   use of labeled tapes only.



   8.3.1  When to Use Tape Drive Allocation

   Table 8-1 lists the differences between using and not using tape drive
   allocation.


   Table 8-1:  Tape Drive Allocation

     __________________________________________________________________

     Tape Drive Allocation         No Tape Drive Allocation
     __________________________________________________________________

     You must make an  entry  in   No    entry    required    in    the
     the  n-CONFIG.CMD  file  to   n-CONFIG.CMD file.
     use tape drive allocation.

     Users  can  use labeled and   No support for labeled  tapes.  This
     unlabeled tapes.              means that all tapes,  whether  they
                                   contain labels or not,  are  treated
                                   as unlabeled.

     Users   cannot   give   the   Users  can  give  the   ASSIGN   and
     ASSIGN     and     DEASSIGN   DEASSIGN commands for allocated tape
     commands for allocated tape   drives  and cannot use the MOUNT and
     drives,  but  must give the   DISMOUNT commands.
     MOUNT      and     DISMOUNT
     commands.

     The operator should not use   The operator may unload tapes  using
     the  UNLOAD  button on tape   the UNLOAD button on the tape drive.
     drives,  but should use the
     DISMOUNT command to OPR.
     __________________________________________________________________



                                    8-12
                                TAPE STORAGE


   8.3.2  How to Enable/Disable Tape Drive Allocation

   To use tape drive allocation enter the command

   ENABLE TAPE-DRIVE ALLOCATION

   in the n-CONFIG.CMD file.

   You can disable tape drive allocation on a tape drive by using the SET
   TAPE-DRIVE MTAn: UNAVAILABLE command.



   8.3.3  Tape Mounting Policy

   Occasionally, you may mount a tape that the system cannot  read.   For
   example, the operator mounts a tape that has a density of 800 bits per
   inch (bits/in) on a drive that does not  support  this  density.   The
   system checks tapes for labels; even if this tape contains labels, the
   incorrect density prevents the system from recognizing them.

   With such errors, the system can be set up to immediately  unload  the
   tape  and  protect  it from being accidentally erased, or it can treat
   the tape as unlabeled and continue processing.

   If you do not want the system to classify these  tapes  as  unlabeled,
   you  can place the TAPE-RECOGNITION-ERRORS command in the n-CONFIG.CMD
   file with the  appropriate  argument.   The  format  of  this  command
   follows:

                                 REGARD-AS-UNLABELED
   TAPE-RECOGNITION-ERRORS
                                 UNLOAD

   The system uses  REGARD-AS-UNLABELED  if  no  entry  is  made  in  the
   n-CONFIG.CMD  file.   If  REGARD-AS-UNLABELED is in effect, you should
   instruct operators to be especially careful when mounting  tapes  with
   write  rings.   The tape's contents cannot be overwritten if the write
   ring is not inserted.



   8.4  TAPE LABELING

   This section describes  what  tape  labels  are  and  how,  as  system
   manager, you can initiate using them.

   Magnetic  tape  labels  are  records  that   are   interspersed   with
   user-defined  data  on  a  tape.   They are informational records that
   describe the user data in a standard fashion  that  is  recognized  by
   many computer systems.



                                    8-13
                                TAPE STORAGE


   The TOPS-20 tape labeling system allows you to  read  and  write  tape
   labels  that  conform  to ANSI (American National Standards Institute)
   and DEC standards.  The tape labeling system also allows you  to  read
   tapes that are labeled according to IBM labeling standards.

   Tape labeling is an option.  You can start or  continue  to  run  your
   system using unlabeled tapes.  If you have hundreds of unlabeled tapes
   at your installation, you may decide not  to  convert  entirely  to  a
   labeled  shop.   Instead,  you  may  have a combination of labeled and
   unlabeled tapes.

   Sections 8.4.1 through 8.4.3 describe the  advantages  of  using  tape
   labels  and  how  to  set up your system to begin labeling tapes.  The
   TOPS-20 Tape Processing Manual provides a complete description of  the
   ANSI,  DEC,  and  IBM  standard label formats and how to use them.  It
   also describes the interface between the operator and  magnetic  tapes
   and the user and magnetic tapes.



   8.4.1  Why Tape Labels?

   An unlabeled tape has a gummed label on the outside of the  reel  that
   identifies  the  contents  of  the  tape.   When the operator selects,
   mounts, and types the  identity  of  an  unlabeled  tape,  the  system
   assumes  that  the  mounted  tape  is  the  one that the user (or job)
   requested.  No checking is performed by the system.

   A labeled tape, however, contains standardized information on the tape
   itself  that  identifies  and  describes  the  data on the tape.  This
   internal label information is in addition to the gummed label  on  the
   outside  of the reel.  With labeled tapes, the operator selects a tape
   (by looking at the outside gummed  label),  mounts  the  tape  on  any
   available  drive,  but does not type in any identifying information at
   the terminal.  When a user issues a MOUNT request for a  labeled  tape
   that  is  already  mounted, the system automatically locates the drive
   containing the tape requested, and checks to ensure that  the  correct
   tape  has  been mounted.  This facility for automatically locating and
   checking tapes is described further below.

   A labeled tape consists of a volume label group, followed  by  one  or
   more  files.   (A volume is a reel of magnetic tape.) The volume label
   group is a set of one or more records at the beginning  of  the  tape.
   It  contains a volume identifier, commonly referred to as a VOLID, and
   other identifying information.   (See  Figure  8-1.)  You,  as  system
   manager, select the VOLIDs to be used at your installation.  The VOLID
   is a name containing from one to six alphanumeric characters.  A  user
   requests  access  to  a specific volume by specifying its VOLID to the
   system.





                                    8-14
                                TAPE STORAGE


   Each file on a labeled tape contains a file header  label  group,  the
   file  data  (written  by  the  user program), and a file trailer label
   group.  (See Figure 8-1).   Optionally,  the  file  can  contain  user
   labels,  whose  contents  are  specified  and  examined  only  by user
   programs.  Volume labels, header  labels,  trailer  labels,  and  user
   labels are described in the TOPS-20 Tape Processing Manual.


    _____________________________________________________________________________
   | |  V  L |  H  |               |  T  | |  H  |               |  T  |
   | |  O  A |  E  |               |  R  | |  E  |               |  R  |
   | |  L  B |  A  |               |  A  | |  A  |               |  A  |
   | |  U  E |  D  |  FILE DATA    |  I  | |  D  |   FILE DATA   |  I  |
   | |  M  L |  E  |               |  L  | |  E  |               |  L  |
   | |  E    |  R  |               |  E  | |  R  |               |  E  |
   | |       |     |               |  R  | |     |               |  R  |
   |_|_______|_____|_______________|_____|_|_____|_______________|_____|_____


   Figure 8-1:  Organization of Labeled Tapes


   Because every labeled tape contains a unique identifier, or VOLID, the
   system  can  read this VOLID and ensure that the correct tape has been
   mounted.  This automatic checking improves  the  reliability  of  your
   tape  system.   It significantly reduces the likelihood of an operator
   mounting the wrong tape.
   Also, some or all of your tape drives  can  be  set  to  automatically
   recognize  tape  volumes  as they are mounted.  This process is called
   automatic volume recognition (AVR).  Setting AVR means that after  the
   operator  mounts  a  tape,  the  system  automatically reads the first
   record and inspects it for label information.  If the tape contains no
   labels,  the  system  classifies it as unlabeled and the operator must
   key in a volume identifier for the tape.  If a request for the tape is
   pending,  the  system  readies the tape for use by the requesting job.
   If a request for the tape is not pending, the system stores the  VOLID
   in  a  table  and  waits  for  a request.  Therefore, automatic volume
   recognition provides the following benefits.

         o  The  operator  does  not  have   to   type   tape-identifying
            information to the system when mounting a labeled tape.

         o  It provides a faster connection between a user's job and  the
            tape requested.

         o  The operator can mount a tape long before it is needed.  When
            a  job  requests  the tape, the system locates the drive that
            contains the requested tape and readies it for use.






                                    8-15
                                TAPE STORAGE


   Tape  labels  also  improve  the  security  of   your   tape   system.
   DEC-standard  labels identify the owner, as well as the volume, in the
   volume label.  The  file  labels  specify  protection  codes  for  the
   individual   files.    These   labels   protect   a  tape  from  being
   inadvertently written on and valuable data destroyed  by  a  user  who
   does not have the appropriate access rights to the tape or its files.

   In  addition  to  the  added   reliability,   security,   and   volume
   recognition,  labeled  tapes provide you with a means of interchanging
   tapes between DECSYSTEM-20s and  other  computers.   This  interchange
   capability  extends  the  mobility  of data between different systems.
   You can write ANSI- and DEC-standard labeled  tapes  and  mount  these
   tapes  on  other  systems using ANSI- or DEC-standard labels, and vice
   versa.  You can mount a labeled tape that was written in  EBCDIC  with
   labels conforming to IBM's OS standards, and read it on a DECSYSTEM-20
   as if it were ANSI-standard labeled.

   Finally, if you are using the TOPS-20 tape drive allocation  facility,
   you  can  charge  users  for their tape usage.  Note that you must use
   tape drive allocation with labeled tapes, but  you  can  use  it  with
   unlabeled  tapes also.  The accounting usage file contains entries for
   all  tape-mount  requests.   The  TOPS-20  USAGE  File   Specification
   describes  the  formats  of  these  entries  and  how they are used in
   reports and billing.



   8.4.2  Setting Up the System to Use Tape Labels

   To use tape labels, you must have at least  one  tape  drive  that  is
   9-track  and  has  the  capability of using tapes at a density of 800,
   1600, or 6250 bits per inch (bits/in).  There is no restriction on the
   number  of these drives you use.  The TOPS-20 Tape Labeling system can
   be used with as many drives as are allowed for your system.

   Also, you must enter the ENABLE TAPE-DRIVE-ALLOCATION command  in  the
   n-CONFIG.CMD   file.   The  TOPS-20  KL  Model  B  Installation  Guide
   describes the format of this command and how  to  enter  it  into  the
   n-CONFIG.CMD  file  at the time you install the system.  If you do not
   enter this command during software  installation,  you  can  edit  the
   n-CONFIG.CMD file at a later date.  However, if you edit the file at a
   later date, you must shut the system down and bring it back  up  again
   to process the commands in the n-CONFIG.CMD file.











                                    8-16
                                TAPE STORAGE


   8.4.3  Initializing Tapes and Drives to Use Labels

   Tapes  must  be  initialized  before  they  can  contain  labels.   An
   initialized  tape  contains  a  volume  label set followed by an empty
   file.  The operator issues commands to OPR to initialize tapes for use
   by  the TOPS-20 Tape Labeling system.  All the necessary volume labels
   are then created on a tape.  (Refer to the  TOPS-20  Operator's  Guide
   for a description of using OPR to initialize tapes.)

   You should initialize as many scratch tapes as you will need to  store
   your  system's  data  before  users  start  issuing MOUNT requests for
   tapes.  Then, when a user issues a MOUNT command without specifying  a
   VOLID,  the  operator  mounts  an  initialized  scratch  tape  of  the
   appropriate label type.  TOPS-20 then readies  (loads)  the  tape  for
   write access by the user program.

   In addition to initializing tapes, you can set some  or  all  of  your
   tape  drives  to  use the automatic volume recognition facility (AVR).
   As described earlier, AVR  sets  your  tape  drives  to  automatically
   recognize  tape  volumes  as  they  are mounted.  To turn on automatic
   volume recognition, have the operator enter the following  command  in
   the <SYSTEM>SYSTEM.CMD file:

   ENABLE AUTOMATIC-VOLUME-RECOGNITION (FOR) object

   Where object is either TAPE-DRIVE MTAn:  or TAPE-DRIVES.

   You can turn  off  AVR  by  entering  the  following  command  in  the
   <SYSTEM>SYSTEM.CMD file:

   DISABLE AUTOMATIC-VOLUME-RECOGNITION (FOR) object

   These commands can be given to OPR at any time to  enable  or  disable
   AVR for any or all drives on the system.

   It is generally a good practice to enable AVR for all drives.


















                                    8-17
                                TAPE STORAGE


   8.5  SHARING TAPE DRIVES BETWEEN TWO SYSTEMS

   If you have two DECSYSTEM-20s, you can set up the systems to  share  a
   TX02 tape subsystem by use of the TX03 option, as Figure 8-2 shows:

           ______________                 ______________
          |              |               |              |
          | DECSYSTEM-20 |               | DECSYSTEM-20 |
          |______________|               |______________|
                 |                              |
              ___|___                        ___|___
             |  DX20 |____              ____|  DX20 |
             |_______|   |              |   |_______|
                         |              |                      
                         |              |
                         |              |
                         |              |
                         |              |
     Standard Single  ___|______________|___   TX03 Dual-Channel
        Channel----->|        |     |       |<-----Option
                     |________|     |_______|
                     |                      |
                     |         TX02         |
                     |                      |
                     |______________________|
                    /     |      |      |    \
                   /      |      |      |     \
                __/_    __|_   __|_   __|_    _\__
               |    |  |    | |    | |    |  |    |
               |    |  |    | |    | |    |  |    |
               |    |  |    | |    | |    |  |    |<--------Tape Drives
               |    |  |    | |    | |    |  |    |
               |____|  |____| |____| |____|  |____|


   Figure 8-2:  TX02 Tape Subsystem


   Note, however, that use of the drives must be  under  strict  operator
   control.   Without  this  control,  it  is  likely  that two users, on
   different systems, will eventually end up using the same tape.













                                    8-18
                                TAPE STORAGE


   Operator control is required because:

         o  Unlike disk drives, there is  no  mechanism  to  control  the
            porting  of  a tape drive between systems.  If the tape drive
            is available to the TX02, then it is available to any  system
            to which the TX02 is connected.

         o  Furthermore, the MOUNTR programs on the two  systems  do  not
            communicate,  so they cannot coordinate access to the drives.
            Thus, the MOUNTRs on the two systems would  allow  two  users
            access to the same physical tape drive.

   Operator Procedures

        1.  All drives that are not to be used  by  a  particular  system
            should be set unavailable to MOUNTR with the OPR command:

            OPR> SET TAPE-DRIVE MTAx: UNAVAILABLE

            This command takes away control of the tape drive from MOUNTR
            and  writes  an  entry in the DEVICE-STATUS.BIN file.  During
            system reloads, MOUNTR reads this file, and if a  tape  drive
            has  been set unavailable, will never try to access or assign
            the drive.  Note that if DEVICE-STATUS.BIN is  ever  damaged,
            then  a  new file is created at system startup.  However, all
            data and settings will have been lost, including data for the
            drives  that  have  been  set  unavailable.   Therefore,  the
            operator will need to repeat this step.

        2.  Setting the drive unavailable to MOUNTR does  not  prevent  a
            user  from  reserving  the drive with the ASSIGN command.  To
            prevent a user from assigning a tape that is set  unavailable
            to  MOUNTR,  a  program  under control of the operator should
            assign to itself  all  of  the  "unavailable"  drives.   This
            program should be run at system startup, before any users are
            allowed to log in.

            You could also control the assignment of tape drives with  an
            access  control  program.   Refer  to  Section  11.1,  Access
            Control Program.














                                    8-19
                                TAPE STORAGE


   An example of re-porting a tape  drive  from  system  A  to  system  B
   follows.  The operator:

        1.  Removes the tape (if any) from the tape drive that is  to  be
            ported over to system B.

        2.  Sets the drive unavailable to MOUNTR on system A.

            ( OPR> SET TAPE-DRIVE MTAx: UNAVAILABLE )

        3.  Assigns the drive to a process under control of the  operator
            on system A.

        4.  Deassigns the drive from the process that is  under  operator
            control on system B.

        5.  Sets the drive available to MOUNTR on system B.

            ( OPR> SET TAPE-DRIVE MTAx: AVAILABLE )

|  In a CFS-20 cluster, a tape drive can be used from only one system  at
|  a  time.   A  user  may  receive the error message:  "Device in use by
|  another system."































                                    8-20











                                 CHAPTER 9

                          SYSTEM PROBLEMS/CRASHES



   This chapter describes the actions to take when  you  are  faced  with
   various  system  problems.  You may have to correct a problem with the
   file system, act immediately after a power failure, or remove  the  CI
   from  system use.  There may be times when you cannot trace a problem.
   At such times, Digital  Field  Service  can  remotely  run  diagnostic
   programs on your system.  The following sections address these topics.

   Errors that require you to correct a problem in the file system seldom
   occur.   However,  if a problem of this nature arises, you can perform
   four classes of file system  corrections.   From  the  least  to  most
   severe, they are:

         o  Restore a single file in a directory

         o  Restore a single directory (other than <ROOT-DIRECTORY>)

         o  Restore <ROOT-DIRECTORY>

         o  Restore the entire file system

   The TOPS-20 Operator's Guide provides all  the  necessary  information
   for  the  operator  to  correct these types of problems.  Sections 9.1
   through 9.4 provide you with an overview of  how  these  problems  are
   solved.















                                    9-1
                          SYSTEM PROBLEMS/CRASHES


   9.1  RESTORING A SINGLE FILE

   If you receive a request to restore a file for a user, you can use the
   following procedure.

        1.  Look in the binder that contains the listing  of  the  DUMPER
            log files.  (Chapter 7 describes creating DUMPER log files.)

        2.  Write down the file specification  (including  the  structure
            and directory) to be restored, and the date and number of the
            tape  containing  the  file.   Be  sure   to   indicate   the
            destination  structure  and  directory  if  one  or  both are
            different from the structure and  directory  from  which  the
            file was saved.

        3.  Submit a request to the operator to restore the file.



   9.2  RESTORING A SINGLE DIRECTORY

   If you receive a request to restore  a  directory,  you  can  use  the
   following procedure.

        1.  Determine the structure that contains the directory.

        2.  Make sure you have a copy of the files in this directory on a
            DUMPER tape.  (Check the log files.)

        3.  Give the ^ECREATE command with the  LIST  subcommand.   Write
            down  the  list  of  parameters,  for  example, the directory
            number, allocation, etc.  You may need this information  when
            you re-create the directory.

        4.  Give the ^ECREATE command with the KILL  subcommand  for  the
            directory.  (The TOPS-20 Operator's Guide provides additional
            procedures for deleting a single directory  if  the  ^ECREATE
            command with the KILL subcommand is unsuccessful.)

        5.  Using your DUMPER backup tapes, first restore the files  from
            the  last  FULL-INCREMENTAL  DUMPER operation.  Then, restore
            files from each INCREMENTAL tape  until  the  time  when  the
            files  were  lost.   Be  sure  the  operator gives the CREATE
            command to DUMPER to restore the directory parameters.

   If the directory contains unreproducible information  and  it  is  not
   backed  up on tape, call Digital Software Services for assistance.  It
   may be possible to reconstruct the directory without losing the  valid
   information in it.





                                    9-2
                          SYSTEM PROBLEMS/CRASHES


   9.3  RESTORING <ROOT-DIRECTORY>

   Each  structure  has   its   own   <ROOT-DIRECTORY>   and   a   backup
   <ROOT-DIRECTORY>   that   is   used  by  the  system  if  the  primary
   <ROOT-DIRECTORY> is bad.  The directory  <ROOT-DIRECTORY>  contains  a
   pointer  to  each  first-level  directory  on  a structure, as well as
   several  important  system  files.    (Chapter   5   illustrates   how
   <ROOT-DIRECTORY>  points  to directories.) If <ROOT-DIRECTORY> is lost
   on the system structure, users cannot access any files in the  system.
   If  <ROOT-DIRECTORY>  is  lost  on a mountable structure, users cannot
   access files on that structure.

   You can tell that the <ROOT-DIRECTORY> on the system structure is  bad
   if  the  operator's  console  prints  any one of the BUGHLTs listed in
   Table 9-1.  When a BUGHLT appears on the console, the system stops.  A
   BUGHLT appears in the form:

   **********
   *BUGHLT name AT dd-mm-yy hh:mm:ss
   *JOB:n, USER:  user-name
   *ADDITIONAL DATA:  data,data,data
   **********

   The lines beginning with JOB:  or ADDITIONAL DATA:  may not appear.


   Table 9-1:  <ROOT-DIRECTORY> BUGHLTS

     __________________________________________________________________

     BUGHLT          Meaning
     __________________________________________________________________

     BADROT          <ROOT-DIRECTORY> is invalid

     FILIRD          The system could not initialize <ROOT-DIRECTORY>

     FILMAP          The  system  could  not map <ROOT-DIRECTORY> into
                     memory

     BADXT1          The index table is missing and cannot be created
     __________________________________________________________________












                                    9-3
                          SYSTEM PROBLEMS/CRASHES


   <ROOT-DIRECTORY> may also be bad if you get the  BOOT  error  ?FIL NOT
   FND.   If  this  error  appears,  be sure you have mounted all devices
   correctly.

   To  recover  from  a  bad  <ROOT-DIRECTORY>,  first  determine   which
   structure  contains the bad directory.  If the bad <ROOT-DIRECTORY> is
   on  a  mountable  structure,  you  can  run  CHECKD  with  RECONSTRUCT
   ROOT-DIRECTORY   and   specify  the  proper  structure.   The  TOPS-20
   Operator's Guide details the procedure for determining  the  structure
   and  using  CHECKD  for  reconstructing  <ROOT-DIRECTORY> on mountable
   structures.

   If the bad <ROOT-DIRECTORY>  is  on  the  system  structure,  you  can
   instruct   the   system   to   use   the   backup   system   structure
   <ROOT-DIRECTORY> and rebuild this directory.  Section 9.3.1  describes
   this procedure.

                                    NOTE

           If your  first  attempt  to  rebuild  <ROOT-DIRECTORY>
           fails, call your DIGITAL Field Service Representative.
           NEVER try to  rebuild  this  directory  twice  on  any
           structure.































                                    9-4
                          SYSTEM PROBLEMS/CRASHES


   9.3.1  Rebuilding the System Structure <ROOT-DIRECTORY>

   To rebuild <ROOT-DIRECTORY> on the system structure, halt the  central
   processor  and  perform Steps 7 through 21 in Chapter 2 of the TOPS-20
   KL10 Model B Installation  Guide.   The  steps  are  shown  below  for
   reference.

        1.  Type CTRL/backslash on the  operator's  console;  the  system
            prints PAR>.

        2.  Type SHUTDOWN and press the RETURN key; the system  prints  a
            few message lines.

            PAR>SHUTDOWN<RET>
            **HALTED**

            %DECSYSTEM-20 NOT RUNNING

        3.  Mount System Floppy A in drive 0 (Step 7).

        4.  Mount System Floppy B in drive 1 (Step 8).

        5.  Mount the TOPS-20 Installation Tape on MTA0: (Step 9).

            If the TOPS-20 Installation Tape  is  not  your  most  recent
            system  backup  tape,  mount  your  SYSTEM  BACKUP  TAPE that
            contains the  monitor,  TOPS-20  Command  Processor,  DLUSER,
            DLUSER  data,  DUMPER,  and save sets containing <SYSTEM> and
            <SUBSYS>.  (Refer to Section 3.2 for a description of special
            system directories.)

        6.  Place the front-end HALT switch in the ENABLE position  (Step
            10).

        7.  Set the front-end switch register  to  000007  (octal)  (Step
            11).


















                                    9-5
                          SYSTEM PROBLEMS/CRASHES


        8.  Press the ENABLE and SWITCH REGISTER switches  simultaneously
            (Step 12).

            RSX-20F VB16-00 8:55 1-JAN-88

            [SY0:  REDIRECTED TO DX0:]
            [DX0:  MOUNTED]
            [DX1:  MOUNTED]
            KLI -- VERSION VB1600 RUNNING
            KLI -- ENTER DIALOG [NO,YES,EXIT,BOOT]?
            KLI>

                                        NOTE

                    The version and edit numbers in  this  manual
                    may  differ  from the numbers printed on your
                    console.  The numbers on your console must be
                    equal  to or greater than the numbers in this
                    manual.

        9.  Type YES and press the RETURN key (Step 13).

            KLI>YES<RET>
            KLI -- KL10 S/N:  2136., MODEL B, 60 HERTZ
            KLI -- KL10 HARDWARE ENVIRONMENT
                     MOS MASTER OSCILLATOR
                     EXTENDED ADDRESSING
                     INTERNAL CHANNELS
                     CACHE
            KLI -- RELOAD MICROCODE [YES,VERIFY,FIX,NO]?
            KLI>

       10.  Type YES KLX and press the RETURN key (Step 14).

            KLI>YES KLX<RET>
            KLI -- MICROCODE VERSION 2.0 [407] LOADED

                                        NOTE

                    If  your  system  has   cache   memory,   the
                    following  question  appears  previous to the
                    question in Step 11.  (Step 15.)

            KLI -- RECONFIGURE CACHE (FILE,ALL,YES,NO)?

            Type ALL and press the RETURN key (Step 16).

            KLI>ALL<RET>
            KLI -- ALL CACHES ENABLED
            KLI -- CONFIGURE KL MEMORY [FILE, ALL, REVERSE,  FORCE,  YES,
            NO]?
            KLI>


                                    9-6
                          SYSTEM PROBLEMS/CRASHES


       11.  Type ALL and press the RETURN key (Step 17).

            KLI -- CONFIGURE KL MEMORY [FILE, ALL, REVERSE,  FORCE,  YES,
            NO]?
            KLI>ALL<RET>
            LOGICAL MEMORY CONFIGURATION
            .
            .
            .
            KLI -- LOAD KL BOOTSTRAP [YES, NO, FILENAME]?
            KLI>

       12.  Type MTBOOT and press the RETURN key (Steps 18 and 19).

            KLI>MTBOOT<RET>
            KLI -- CONFIGURATION FILE ALTERED
            KLI -- WRITE CONFIGURATION FILE [YES,NO]?
            KLI>NO<RET>
            BOOTSTRAP LOADED AND STARTED

            BOOT V11.0(315)

            MTBOOT>

       13.  Type /L and press the RETURN key (Step 20).

            MTBOOT> /L<RET>
            [BOOT:  STARTING CHN:n DX20x:0 MICROCODE Vn(n)][OK]
            [BOOT:  LOADING][OK]
            MTBOOT>

                                        NOTE

                    The message concerning the DX20 microcode  is
                    printed   only  if  you  are  installing  the
                    TOPS-20 software on  a  DECSYSTEM-20  with  a
                    DX20 tape or disk controller.

       14.  Type /G143 and press the RETURN key (Step 21).

            MTBOOT> /G143<RET>

            [FOR ADDITIONAL INFORMATION TYPE "?" TO ANY OF THE
            FOLLOWING QUESTIONS.]
            DO YOU WANT TO REPLACE THE FILE SYSTEM ON THE SYSTEM
            STRUCTURE?

                                        NOTE

                    Read Step 15 carefully before answering  this
                    question.



                                    9-7
                          SYSTEM PROBLEMS/CRASHES


       15.  Type N and press the RETURN key.  You DO NOT  want  to  clear
            all the information on the disk packs.  If you want to retain
            all the information in the file system, always type N.

            DO YOU WANT TO REPLACE THE FILE SYSTEM ON
            THE SYSTEM STRUCTURE?  N<RET>

            [PS MOUNTED]

            RECONSTRUCT ROOT-DIRECTORY?

       16.  Type Y and press the RETURN key.  This causes the backup copy
            of <ROOT-DIRECTORY> to be used.

            RECONSTRUCT ROOT-DIRECTORY?  Y<RET>

            [RECONSTRUCTION PHASE 1 COMPLETED]

            %%NO SETSPD

            System restarting, wait...
            ENTER CURRENT DATE AND TIME:

            The system restarts and runs CHECKD to  reconstruct  the  bit
            table.   The bit table contains one bit for every page in the
            file system.  If the bit is on, the page is available; if the
            bit is off, the page is in use.

       17.  Type the date and time and press the RETURN key.  Type Y  and
            press the RETURN key to confirm the date and time.

            ENTER CURRENT DATE AND TIME:  1-JAN-81 0931<RET>

            YOU HAVE ENTERED THURSDAY, 01-JANUARY-1981 9:31AM,
            IS THIS CORRECT (Y,N) Y<RET>
            WHY RELOAD?

       18.  Type OTHER and press the RETURN key.

            WHY RELOAD?  OTHER<RET>
            [REBUILDING BIT TABLE]

                                        NOTE

                    You should type a response  to  WHY  RELOAD?,
                    that   reminds   you  of  why  you  did  this
                    procedure.  This response is  stored  in  the
                    <SYSTEM-ERROR>ERROR.SYS  file.   Refer to the
                    TOPS-20 KL10 Model B Installation Guide for a
                    complete list of valid abbreviations.




                                    9-8
                          SYSTEM PROBLEMS/CRASHES


       19.  The system prints some standard  messages,  the  output  from
            CHECKD, RUNNING DDMP, and the output from SYSJOB and PTYCON.

            [REBUILDING BIT TABLE]

            [WORKING ON STRUCTURE - PS:]

            output from CHECKD

            RUNNING DDMP

            output from SYSJOB and PTYCON

            Refer to the TOPS-20 Operator's  Guide  for  samples  of  the
            output from CHECKD, SYSJOB and PTYCON.

       20.  Log in as user OPERATOR.

             TOPS-20 SYSTEM, TOPS-20 Monitor 7(21017)
            @LOGIN (USER) OPERATOR (PASSWORD) --- (ACCOUNT) OPERATOR<RET>
             Job 1 On TTY1 3-MAY-88 10:33:32



   9.4  RESTORING THE ENTIRE FILE SYSTEM

   If you are still receiving random errors and cannot  use  the  system,
   you  may  have  to  restore  the  entire  file  system  on  the system
   structure.  Before  doing  this,  you  should  contact  your  software
   specialist  to  ensure  that resorting to this procedure is necessary.
   The procedure requires shutting down the system and  reinstalling  the
   file system.



   9.4.1  Re-creating the File System on the System Structure

   The following steps outline  the  procedure  for  restoring  the  file
   system on the system structure.

        1.  Type CTRL/backslash to start the front-end command parser.

            CTRL/backslash

            PAR>

        2.  Type SHUTDOWN to  stop  the  central  processor;  the  system
            prints a few messages.

            PAR>SHUTDOWN<RET>
            **HALTED**
            %DECSYSTEM-20 NOT RUNNING


                                    9-9
                          SYSTEM PROBLEMS/CRASHES


        3.  Start at Step 9 in Chapter  2  of  the  TOPS-20  KL  Model  B
            Installation Guide and follow all the steps through Step 60.

            In Step 9, instead of mounting the TOPS-20 Installation Tape,
            mount  your system structure SYSTEM BACKUP TAPE that contains
            the monitor, TOPS-20 Command Processor, DLUSER, DLUSER  data,
            DUMPER, and save sets containing <SYSTEM> and <SUBSYS>.

        4.  After performing Step 60, restore  your  entire  file  system
            using  DUMPER.   First run DUMPER, then mount your first reel
            of the most recent full DUMPER tape and follow the procedures
            in the TOPS-20 Operator's Guide.

        5.  Re-create  the  front-end  file  system  by   following   the
            directions   in   Chapter   4  of  the  TOPS-20  KL  Model  B
            Installation Guide.

        6.  Finally, restart the system by following  the  directions  in
            Chapter 5 of the TOPS-20 KL Model B Installation Guide.

                                    NOTE

           Restore the  incremental  saves  to  obtain  the  most
           recently   saved   files.    Before   restoring   each
           incremental tape, type DUMPER>CREATE  to  restore  all
           the  directories that were created since the last time
           you ran the DLUSER program.



   9.4.2  Re-creating Mountable Structures

   If, after your efforts to correct errors on a structure other than the
   system  structure  (using  the  command  RECONSTRUCT ROOT-DIRECTORY to
   CHECKD), you still cannot use the structure, you  can  re-create  that
   structure  and restore all the directories and files.  You can restore
   structures other than the system structure during timesharing.

   To restore a mountable structure you must:

        1.  Give the SET STRUCTURE IGNORED command to the OPR program  to
            prevent other users from mounting the structure while you are
            re-creating it.

        2.  Run CHECKD to create the structure.

        3.  Run DLUSER to restore directory parameters for the  structure
            if you previously used the program to save the parameters.

        4.  Run DUMPER using the backup tapes for this  structure.   Give
            the  CREATE and RESTORE commands to DUMPER to restore all the
            directories and files.


                                    9-10
                          SYSTEM PROBLEMS/CRASHES


   The TOPS-20 Operator's Guide details the procedures for running CHECKD
   and DUMPER to re-create a structure.



   9.5  POWER FAILURES

   Unfortunately,  power  failures  and  brown-outs  sometimes  occur  at
   installations.   You should be aware of the immediate steps to perform
   and transmit this information to your operations people.  The kind  of
   attention  you  should  direct  to this type of problem depends on the
   type of outage you have.  These steps can  protect  your  system  from
   physical damage and perhaps unnecessary loss of files.
   If your system experiences a total power failure, you should:

        1.  Immediately power-off all components of the system.

        2.  Inform your DIGITAL Field Service representative as  to  when
            you expect to resume power.  The field service representative
            may ask to be present while you bring your system back up.

   If your system experiences a short instance  of  a  power  failure  or
   brown-out,  the  system  may recover on its own.  You may not have any
   problems and, usually, all your data remains intact.  If you notice  a
   problem, call your Field Service representative.

   High-performance computer systems are sensitive to the quality of  the
   electrical  power  supply.  An investment in a power conditioner or an
   uninterruptible power supply may more than repay  itself  in  improved
   system    reliability    and   availability.    Your   Field   Service
   representative may be able to assist you in evaluating  the  need  for
   such equipment.



   9.6  REMOTE DIAGNOSTIC LINK (KLINIK)

   You may occasionally have  a  problem  with  your  system  and  cannot
   determine  the  cause.   The  remote diagnostic link, available on all
   systems, allows a DIGITAL Field Service engineer to access your system
   from  a  remote location and run diagnostic programs.  This capability
   is called KLINIK.  The DIGITAL  engineer  accesses  KLINIK  through  a
   terminal  and  telephone  line  at  the  DIGITAL  Service Center.  The
   TOPS-20 Operator's Guide describes when and  how  to  use  the  KLINIK
   capability.









                                    9-11
                          SYSTEM PROBLEMS/CRASHES


   9.7  MAKING THE CI UNAVAILABLE ON NON-CFS SYSTEMS

   The CI, a computer-interconnect bus, is a key piece  of  hardware  for
   connecting  systems  in  a  CFS-20  configuration  and  for connecting
   HSC50-based disks (RA81s and RA60s) to a system.  Ordinarily, you need
   do  nothing  at  all  to  operate  the  CI.   However, you may need to
   disengage a system from the CI so Field Service personnel can  correct
   problems  with  the  CI20  or  the  HSC50.  At those times, you should
   instruct the operator to make the CI unavailable by means of  the  SET
   PORT  CI  UNAVAILABLE command.  (Refer to the TOPS-20 Operator's Guide
   for details.)

   When  the  CI  is  unavailable  to  a  system,  users  cannot   access
   HSC50-based  disks,  which  rely  on  the  CI  to  transmit data.  The
   procedure calls for the operator to dismount any structures  that  the
   system indicates are mounted on these disk drives.

   To put the CI back in operation, the operator gives the command:

        OPR>SET PORT CI AVAILABLE<RET>

   Structures that were affected must then be remounted.

   Refer to Chapter 12,  THE  COMMON  FILE  SYSTEM,  for  information  on
   disengaging the CI on CFS systems.



   9.8  MAKING THE NI UNAVAILABLE

   A system may need to be disengaged from the NI so that  field  service
   personnel can diagnose problems with the NI or the NIA20.  To make the
   NI unavailable to a system, the operator gives the command:

        OPR>SET PORT NI UNAVAILABLE<RET>

   This command prevents users of the  system  from  using  LAT  terminal
   servers  as well as any other software that uses the NI.  If DECnet or
   TCP/IP software is installed, it cannot use the NI for  data  transfer
   between  systems.   To make the NI available again, the operator gives
   the command:

        OPR>SET PORT NI AVAILABLE<RET>



   9.9  OFFLINE DISKS

   When a disk unit becomes unavailable to a system, all  jobs  accessing
   the disk "hang" until the disk becomes available again.  When the disk
   comes back online, input/output  activity  continues  from  the  point
   where it left off.


                                    9-12
                          SYSTEM PROBLEMS/CRASHES


   Also, some jobs may try to begin accessing  the  disk  after  it  went
   offline  but before it becomes available again.  They hang in the same
   way that interrupted jobs, described above,  hang.   You  can  specify
   that  offline  disks  be made unavailable to these new jobs by putting
   the following command in the n-CONFIG.CMD file:

   ENABLE OFFLINE-STRUCTURES mm:ss

   where:

        mm:ss is the  "structure  timeout  interval"  in  minutes:seconds
        format.   The  structure  timeout  interval is the length of time
        from when the system recognizes that a disk unit has gone offline
        to when it marks the structure as offline.  The maximum value for
        mm:ss is 15 minutes; the minimum is 1 second.

   It should be noted that if just one  disk  of  a  multidisk  structure
   becomes  unavailable,  then  the  entire  structure is marked offline.
   After a structure is marked offline, it  becomes  unavailable  to  new
   jobs  requesting  input/output  service.   The  system  sends an error
   message to any requestor trying to access the structure.

   This command is in effect by default with  a  timeout  interval  of  5
   seconds.   To  disable the feature, enter the following command in the
   configuration file:

   DISABLE OFFLINE-STRUCTURES

   A good reason to disable the feature is to  prevent  batch  jobs  from
   terminating  when  they  receive the error message indicating that the
   desired structure has been set offline.  You may want  batch  jobs  to
   hang until the disk is restored for use.



   9.9.1  Operator Procedures

   Privileged commands corresponding to the ones above are  available  to
   the operator during timesharing:

   $^ESET OFFLINE-STRUCTURES mm:ss

   $^ESET NO OFFLINE-STRUCUTRES

   Operators may want to set the timeout interval to a value higher  than
   five  seconds  if they are able to correct the disk problem within the
   specified period.  However, new user requests will then hang until the
   disk is marked offline (or the problem is corrected).






                                    9-13
                          SYSTEM PROBLEMS/CRASHES


   9.10  DUMPING ON NON-FATAL SYSTEM ERRORS

   The monitor can dump its memory area to a disk file when  BUGCHKs  and
   BUGINFs  occur.   This feature, called DUMP-ON-BUGCHK, helps you debug
   the system of nonfatal, "continuable" errors by providing a dump  file
   for examination.



   9.10.1  Enabling DUMP-ON-BUGCHK

   The DUMP-ON-BUGCHK feature is enabled in the  n-CONFIG.CMD  file  with
   the following command:

   ENABLE DUMP-ON-BUGCHK FACILITY

   At least one of the following commands is further required  to  enable
   dumping of all or specific BUGCHKs or BUGINFs that can be dumped:

   ENABLE DUMP-ON-BUGCHK ALL-BUGCHKS
   ENABLE DUMP-ON-BUGCHK ALL-BUGINFS
   ENABLE DUMP-ON-BUGCHK BUG bugname

   where:  bugname is the name of a BUGCHK or BUGINF

   With the first two commands, each BUGCHK or BUGINF is dumped only once
   per  loading  of  the  system.   The third command causes a dump to be
   taken each time that the specified BUGCHK or BUGINF occurs.  Dumps are
   taken  only as often as the DUMP-ON-BUGCHK timeout allows, which is 15
   seconds by default.   The  following  command  overrides  the  timeout
   constraint  and  allows a dump to be taken as often as a specified bug
   occurs:

   ENABLE DUMP-ON-BUGCHK BUG bugname IGNORE-DUMP-TIMEOUT



   9.10.2  Disabling DUMP-ON-BUGCHK

   You may want to disable this feature to save  memory  space  that  the
   monitor   uses  to  implement  it,  or  after  you've  looked  at  the
   considerations in Section 9.10.5.  You  could  save  the  feature  for
   times when the system is experiencing problems.

   If the feature is disabled, the system produces only the "crash" dumps
   associated with fatal errors, but not "continuable" dumps.  To disable
   DUMP-ON-BUGCHK, enter the following command in the n-CONFIG.CMD file:

   DISABLE DUMP-ON-BUGCHK

   The DOB-ON-BUGCHK facility is disabled by default.



                                    9-14
                          SYSTEM PROBLEMS/CRASHES


   9.10.3  "Dumpable Structures"

   The operator can specify where continuable dumps are written with  the
   command:

   OPR>SET STRUCTURE str:  DUMPABLE<RET>

   where:

        str: is the  name  of  a  structure  that  is  to  be  considered
        "dumpable."

   This command can be given for more than one structure.  Note that  the
   system structure is always dumpable.

   The dumpable status of a structure remains intact across  crashes  and
   system reloads.

   A continuable dump is  written  to  the  <SYSTEM>DUMP.EXE  file  on  a
   dumpable structure.  The system writes the file to the first structure
   that meets the following conditions:

         o  The structure is dumpable.

         o  The structure is not being initialized or dismounted.

         o  The structure is not offline, in maintenance mode,  or  write
            locked.

         o  The data in  the  monitor's  structure  data  block  for  the
            structure appears to be uncorrupted.

         o  Any <SYSTEM>DUMP.EXE files on the structure have been  copied
            (see  the  following  section)  and  therefore  will  not  be
            overwritten.




   9.10.4  Copying the Dump File

   After the dump, the n-SETSPD program scans all dumpable structures and
   copies  any  previously  uncopied <SYSTEM>DUMP.EXE files to an area on
   DMP:, if this logical name is defined.  Otherwise, it copies the files
   to  other  areas  on  the  same structures.  The new files have unique
   names of the form:








                                    9-15
                          SYSTEM PROBLEMS/CRASHES


   str:<DUMPS>DUMP-nnnn-bug.CPY.n

   where:

            str is the name of the structure

            nnnn is the edit number of the monitor that  was  running  at
            the time of the crash

            bug is the name of the BUGCHK or BUGINF

            n is the file generation number

   An informational message similar to the following is sent to  the  CTY
   after each copy:

   Copying system dump
           from:  ABC:<SYSTEM>DUMP.EXE.1
           to:    XYZ:<DUMPS>DUMP-21002-FSPOUT.CPY.1



   9.10.5  Time Considerations

   The DUMP-ON-BUGCHK facility (DOB)  turns  off  timesharing  while  the
   system is being dumped.  If DOB takes an extended period of time, LAT,
|  DECnet, or INTERNET connections may be lost.   Therefore,  you  should
   specify the fastest available device for DOB dumps.  The following are
   sample DOB times for various disk types and memory sizes:

   ______________________________________________________________________

   Device                    Memory Size                   DOB Time
                             (megawords)                   (seconds)
   ______________________________________________________________________

   RP07                      1.5                           06
   RP07                      4.0                           16
   RP06                      1.5                           11
   RP06                      4.0                           32
   RA60/81                   1.5                           21
   RA60/81                   4.0                           56
   ______________________________________________________________________











                                    9-16
                          SYSTEM PROBLEMS/CRASHES


   Problems could occur in  the  following  areas  during  extended  dump
   periods:

         o  Data from Terminal Lines

            During continuable dumps, the system  is  not  in  sufficient
            communication  with  the  front  end  to ensure that terminal
            input data gets processed.  (The  monitor  enters  "secondary
            protocol" -- refer to the RSX-20F System Reference Manual for
            details).  This  data  could  get  lost.   It  is  a  problem
            particularly with lines doing high-speed input.

         o  DECnet

            If other nodes in a DECnet network have their timeout periods
            set at a value lower than the time it takes for a continuable
            dump on this system, inter-system links could timeout.

         o  LAT

            A LAT server has a  default  maximum  timeout  value  of  two
            minutes,  which  should  suffice for continuable dumps on the
            host.  However you can decrease the  server  timeout  period.
            If  you  make it too short, all jobs on the host could become
            detached after the dump.




   9.10.6  Controlling DUMP-ON-BUGCHK

   For your convenience, there is an unsupported  program  on  the  tools
   tape  that can help you control the DUMP-ON-BUGCHK facility.  The tool
   is called DOBOPR.  It includes documentation that you can access  with
   the program's HELP command.



















                                    9-17
























































                                    10-1











                                 CHAPTER 10

                             SYSTEM PERFORMANCE



   The configurations of systems running TOPS-20 and the mix of  jobs  on
   these  systems  vary  from  installation  to installation.  TOPS-20 is
   designed to provide better  response  to  interactive  users  than  to
   provide  higher  throughput to computational tasks.  On systems with a
   typical mix of interactive and batch jobs, this design  provides  both
   good  response and adequate throughput.  Therefore, if your system has
   many timesharing users and an average amount of batch processing jobs,
   you  will  find that your system's response is good and most users are
   satisfied.

   If you have a mix of jobs or a configuration different from a  typical
   system,  you may want to change the response of your system to provide
   better service to specific users.   TOPS-20  provides  several  tuning
   mechanisms  that  allow you to experiment with and change the behavior
   of your system.  One mechanism allows you to favor classes of users by
   allocating  each  class  a  specified  percentage of the CPU.  Another
   mechanism allows you to  favor  computational  jobs  over  interactive
   jobs.   A third mechanism allows you to disable features that normally
   provide better performance, but that may not  be  applicable  at  your
   installation.

   This  chapter  describes  the  mechanisms  for  tuning  your  system's
   response  and provides guidelines for using these mechanisms.  Because
   the response of your system can be felt during actual  use  only,  you
   can  expect system tuning to be an experimental and iterative process.
   By analyzing the statistics from the WATCH program  and  by  gathering
   inputs  from  your  users, you can determine the best way to tune your
   system.

   The tuning mechanisms include:

         o  The class scheduler, which allows you to divide  the  central
            processor (CPU) resource among groups of users

         o  Assigning low priority to batch jobs for  installations  that
            do not use the class scheduler



                                    10-1
                             SYSTEM PERFORMANCE


         o  Bias control, which allows you to favor either interactive or
            compute-bound jobs on your system

         o  The program name cache for  improving  the  startup  time  of
            frequently used programs

         o  Reinitializing disk packs  in  heavily  used  structures  for
            improving file processing time

   Each mechanism can be used  independently.   Unless  otherwise  noted,
   there is no interrelationship among them.



   10.1  THE CLASS SCHEDULER

   Occasionally, certain jobs monopolize  the  central  processor's  time
   while  other  more  critical  jobs  wait for the CPU.  You may want to
   control the amount of CPU time a job receives.  You can use the  class
   scheduler  to  provide  an even distribution of CPU time or to provide
   more CPU time to critical jobs on the system.   Some  system  managers
   may  want  to  allocate  a  larger amount of processor time to special
   users than to other system  users.   Sections  10.1.1  through  10.1.9
   describe:

         o  an overview of the class scheduler

         o  who should use the class scheduler

         o  how to begin using the class scheduler

         o  turning on the class scheduler

         o  changing class percentages

         o  disabling the class scheduler

         o  getting information about class scheduler status

         o  a sample session using class scheduler commands

         o  an alternative to using the class scheduler with accounts.



   10.1.1  Overview

   The class scheduler allows you to allocate percentages of the  central
   processor's  time to individual classes of users.  Each job in a class
   receives a portion of the class percentage.  Therefore, by  using  the
   class  scheduler,  you  can provide a consistent service to predefined
   groups of users.


                                    10-2
                             SYSTEM PERFORMANCE


   The diagram below illustrates the concept of classes  and  percentages
   of CPU time allocated to each class.  Note that you can set up a class
   to include all batch jobs.  This allows  you  to  control  batch  jobs
   separately  from  timesharing  jobs.   The batch class is given a high
   percentage or a low percentage.  Now, each time a user submits a batch
   job,  the  scheduler  uses  the  batch class and not the user's class.
   Section 10.1.4, Step 5, describes how to create a batch class.

                        __________________
                       |                  |
                       |                  | 
                       |                  | 
                       |     RESEARCH     | 
                       |        40%       | CLASS 2
                       |                  | 
                       |                  |
                       |__________________|
                       |                  |
                       |                  | 
                       |       BATCH      | CLASS 1
                       |        30%       |
                       |                  |
                       |__________________|
                       |                  |
                       |  ADMINISTRATION  | CLASS 0
                       |        20%       |
                       |__________________|
                       |     STUDENTS     |
                       |________10%_______| CLASS 3


   You can define class  memberships  by  using  the  TOPS-20  accounting
   facility  or  by  writing  your  own  access control program.  Section
   10.1.9 provides an overview of using  an  access  control  program  to
   define  classes.  The following description applies to using the class
   scheduler with the accounting facility.

   Using the accounting facility, you can associate a class  number  with
   each  account  on  the  system.   Each  account  has  only  one  class
   associated with it.  Therefore, only a user who  has  access  to  more
   than  one  account  can  have access to more than one class.  The user
   changes classes by changing accounts.  To use this  method,  you  must
   enable  account  validation  so that users are required to use a valid
   account.  Section 10.1.4 describes the accounting file entries.

   The scheduler periodically computes  the  time  used  by  classes  and
   individual jobs within a class.  The scheduler's first concern is that
   a class receive its share of the CPU  time.   The  scheduler  gives  a
   greater percentage of time to the class that is the farthest away from
   its target  (the  total  percentage  allocated  to  the  class).   The
   scheduler's second concern is that each job within a class receive its
   fair share.  Periodically, the scheduler computes the  average  amount


                                    10-3
                             SYSTEM PERFORMANCE


   of  CPU  time  that  a  job has accrued.  This quantity determines the
   job's priority within the class.  A job that is requesting the CPU and
   is  farthest  way  from  receiving  its  fair  share  within the class
   receives a greater percentage of time within that class.

   Generally, the CPU has  unused  time.   This  unused  time  is  called
   windfall.   Windfall  occurs  if  one or more classes has no logged-in
   jobs, or if one or more classes has an insufficient demand for the CPU
   to use all of its class percentage.

   You can handle windfall in one of two ways:  allocate it  or  withhold
   it.   Allocating  windfall  means  that the excess CPU time is awarded
   proportionately to the active classes.  (In this discussion, the  term
   active class refers to a class that has logged-in users requesting CPU
   time.) Higher percentage classes receive proportionately more  of  the
   available  windfall than lower percentage classes.  This means classes
   can receive slightly more than their allowed percentages when there is
   windfall available.  Note that windfall is distributed proportionately
   to each class and not to each job within a class.

   Withholding windfall means that the excess CPU time is idle  time  and
   it  is  not  distributed  to  the  active classes.  It also means that
   classes do not receive more than  the  percentage  allowed  for  them.
   Usually, it is better to allocate windfall, and not withhold it so you
   don't throw away valuable computer time.



   10.1.2  Who Should Use the Class Scheduler?

   As mentioned earlier, the class scheduler allows  you  to  divide  the
   user  community  into defined classes and allocate a percentage of CPU
   time to each class.  This  intended  use  may  not  be  beneficial  or
   practical for some systems.  Tradeoffs do exist and some installations
   do not  require  class  scheduling.   Therefore,  read  the  following
   paragraphs  and  determine  if your system needs this type of control.
   Several instances that can benefit from using the class scheduler are:

         o  You can elect to sell portions of  CPU  time.   For  example,
            customer X can purchase some percentage of computer time at a
            proportional cost.  You should, in this case, invite customer
            X  to  your  installation  and  provide  an  environment that
            simulates the kind of response this customer  can  expect  at
            this  percentage.   Because  it  is  impossible to create the
            environment exactly as the customer will experience it at all
            times,  customer X may decide later to change the purchase to
            a different percentage.







                                    10-4
                             SYSTEM PERFORMANCE


         o  If you have a natural division among the users of the system,
            you  can divide these users into classes, then distribute CPU
            time to these classes with respect to their importance on the
            system.   For example, in an educational environment, you may
            have administrative  users  (doing  payroll,  grades,  etc.),
            faculty users (perhaps working on a funded research project),
            and student users (who are computer science  majors).   Using
            the  class  scheduler,  you  can  establish three classes and
            distribute the CPU time according to the  importance  or  pay
            rate of each class.

         o  If you wish to give preference to batch jobs, you can use the
            class  scheduler to give the batch class a high percentage of
            the CPU.

   Conversely, you may not want to use the class scheduler  for  some  of
   the following reasons:

         o  If you have not  realized  a  need  in  the  past  for  class
            scheduling,  or  if  you  have a new system and do not see an
            immediate requirement for class scheduling,  you  should  not
            set it up.

         o  Systems with minimal amounts  of  memory  may  experience  an
            increase  in  swapping.   This additional overhead may offset
            any advantage gained by using the class scheduler.

         o  In  addition  to  other  tasks,  the   scheduler   constantly
            maintains  usage  values  for each class and job.  Because of
            this extra overhead, the overall system throughput decreases.
            Therefore,  use the class scheduler if allocating percentages
            to individually  defined  classes  outweighs  the  throughput
            depreciation.

         o  To give batch jobs a low priority on the system, you  do  not
            have  to  use  the  class  scheduler.  Section 10.2 describes
            placing the BATCH-BACKGROUND command in the n-CONFIG.CMD file
            to  place  all  batch  jobs in a low priority (or background)
            queue.















                                    10-5
                             SYSTEM PERFORMANCE


   10.1.3  How to Begin Using the Class Scheduler

   If you elect to use the class scheduler, first divide the system users
   into  classes.   Next,  determine  the  amount  of CPU time each class
   should receive.  Percentages given to classes are typically  in  units
   of  5,  that  is,  5%, 10%, 15%, ....100%.  The sum of the percentages
   given to all classes cannot exceed 100 percent.  The result  of  these
   two  steps  depends  on  the  reason  you  elected  to  use  the class
   scheduler, and how you plan to use it at your  installation.   Because
   of  this  system  dependency,  step-by-step  procedures  for selecting
   classes and  allocating  the  CPU  cannot  be  given.   The  following
   discussion  provides  you  with  guidelines  for  setting up the class
   scheduler to meet your system's needs.

         o  Start with as few classes as possible, three or perhaps four.
            The  class  scheduler  allows  eight.   Later, you can divide
            classes further, if necessary.

         o  Determine the number of logged-in users you  expect  in  each
            class.   Be  sure that you do not overload a class, making it
            impossible to give a sufficient percentage of the CPU to each
            job in the class.  Also, you can limit the number of users in
            a class, but you  cannot  limit  the  number  of  jobs.   For
            example,  the  SUBMIT  command  creates  an  additional  job.
            Therefore, consider the type of work that users  in  a  class
            perform.

         o  Estimate the percentage of CPU time (or time purchased)  each
            class should receive.  This is a difficult step; however, you
            can experiment with  and  later  alter  the  percentages  you
            choose.   (Section  10.1.5 describes how you can change class
            percentages.) If a class consists of a large number of  users
            who are generally logged in at the same time, be sure to give
            this class sufficient  CPU  time.   For  example,  using  the
            diagram  below,  class  2  has  60  members.   It also has 60
            percent of the CPU.  This means that if approximately 60 jobs
            in  class  2  are  demanding  the  CPU, each job will receive
            approximately 1 percent.  (It may be slightly greater than  1
            percent  if you allocate windfall.) This also means that on a
            per-job basis, users in class 2, with the higher  percentage,
            may  not  get as much of the CPU as users in class 0 or class
            1.

         o  In order to avoid possible  performance  problems,  no  class
            should be allocated less than 5% of the CPU.









                                    10-6
                             SYSTEM PERFORMANCE


                                 ___________________
                                |                   |
                                |                   |
                                |                   |
                                |                   |
                                |                   |
                                |        60%        | CLASS 2
                                |                   |
                                |                   |
                                |                   |
                                |                   |
                                |                   |
                                |___________________|
                                |                   |
                                |      WINDFALL     | 
                                |                   |
                                |___________________|
                                |                   |
                                |        15%        | CLASS 1
                                |___________________|
                                |_________5%________| CLASS 0


         o  The above diagram illustrates that you can allocate less than
            100  percent  of  the  CPU  to  classes.   However, the total
            percentage for all classes cannot exceed 100 percent.

         o  The system uses class 0 as a default  for  any  account  that
            does  not  have a valid class assigned to it.  Therefore, you
            can divide a portion of the system into well-defined  classes
            and  have all other users receive the percentage given to the
            default class.

         o  You can set up the class scheduler so that one class, perhaps
            the  default  class,  receives  only  windfall.  For example,
            suppose you allow some users to log into an account  that  is
            not  yet  assigned  a class.  These users are assigned to the
            default  class  0.   Or,  suppose  several   users   log   in
            infrequently, read mail, and perform little computing.  These
            users may log into an account that is not  assigned  a  class
            (and,  therefore,  are  assigned the default class, 0), or an
            account that is associated with class  0.   You  subsequently
            assign a zero percentage to class 0.  These users may receive
            enough windfall to get their job done.  However, they are not
            allocated  CPU time and can have periods of extremely slow or
            no response.  You may find,  after  experimenting  with  this
            type  of  procedure,  that  it  is  better  to associate each
            account with a class and give the class a very low percentage
            of the CPU.





                                    10-7
                             SYSTEM PERFORMANCE


         o  Situations may arise that affect the scheduler's  ability  to
            give  a  class  its  percentage of the CPU.  For example, the
            members of  a  class  cannot  use  the  amount  of  CPU  time
            allocated  to  the  class.  Also, a situation may arise where
            the demands of the class exceed the percentage  of  CPU  time
            given the class, and windfall is available but not allocated.
            In either case, you should reevaluate  both  the  percentages
            given  to  classes,  and  whether or not you want to continue
            withholding or allocating windfall.



   10.1.4  Procedures to Turn On the Class Scheduler

   After dividing users into classes and estimating  the  amount  of  CPU
   time,  follow  these  steps  to  set  up classes and turn on the class
   scheduler.

      Step                       Procedure

      1.     Edit the <ACCOUNTS>ACCOUNTS.CMD file on the system structure
             (and  the  subaccount  files,  if any, that contain all your
             accounting  data).   Follow  the  procedure  in  Chapter  6,
             Creating  Accounts,  for  modifying or creating each account
             with the /CLASS:n switch.  For example,

             ACCOUNT COMP1/CLASS:1
             USERS KOHN,HOLLAND,MILLER

             means that when users Kohn, Holland, and Miller log into  or
             change  their  account to COMP1, they are placed in class 1.
             Each  account  has  only  one  class  associated  with   it.
             Therefore,  only  the  user  who has access to more than one
             account can have access to more than one class.  A  job  can
             be in only one class at any one time.

      2.     Run the ACTGEN program.  Give the TAKE command  and  specify
             the  <ACCOUNTS>ACCOUNTS.CMD file (or the file containing the
             accounting data).

      3.     When ACTGEN returns its prompt, give  the  INSTALL  command.
             This  command  updates  the ACCOUNTS-TABLE.BIN file that the
             system uses to validate accounts.

      4.     Edit the n-CONFIG.CMD file to include  the  CREATE  commands
             that  specify  the  classes.   Be sure account validation is
             enabled.  That is, check that the DISABLE ACCOUNT VALIDATION
             command  is  NOT  in  the  file.   (The  system  default  is
             ENABLED.) If account validation is disabled, users  can  use
             any  account and therefore any class they choose.  Enter the
             following commands in the order shown below.



                                    10-8
                             SYSTEM PERFORMANCE


             The  CREATE  command  defines  the  class  number  and   the
             percentage  of  CPU  time  the  class  should  receive.  For
             example,

             CREATE 0 .40

             means that the default class, 0, should receive  40  percent
             of  the  CPU.   Enter  the  CREATE  command  for each of the
             classes that you defined  in  the  ACCOUNTS.CMD  file.   For
             example,

             CREATE 0 .40
             CREATE 1 .20
             CREATE 2 .30

                                         NOTE

                 Remember that class 0 is  the  default  class.   Any
                 user  whose  account  (this includes subaccounts) is
                 not associated with a specific class  is  placed  in
                 class 0.

      5.     Next, if you have decided to  place  all  batch  jobs  in  a
             separate class, enter the BATCH-CLASS command.  For example,

             BATCH-CLASS 2

             means that  all  batch  jobs  will  be  placed  in  class  2
             regardless of the user's associated class.  You must use the
             CREATE command to define the percentage of CPU time that the
             batch class should receive.  Note that timesharing users can
             be in the same class as well, if the  account  they  use  is
             associated  with  that  class.  The CREATE command in step 4
             defines class 2 to receive 30 percent of the processor.   If
             you  do  not place a BATCH-CLASS command in the n-CONFIG.CMD
             file, the scheduler  treats  all  batch  jobs  the  same  as
             timesharing jobs.

      6.     Finally, enter the ENABLE CLASS-SCHEDULING command.  Be sure
             this is the last command entered.  If you reverse the order,
             that is, you enter ENABLE CLASS-SCHEDULING before the CREATE
             commands  and  BATCH  command,  all  users will receive zero
             percent of the CPU.

             The ENABLE  CLASS-SCHEDULING  command  turns  on  the  class
             scheduler  at  the next system reload.  It also specifies if
             you are  using  accounting  or  an  access  control  program
             (policy  program)  for  class  scheduling  and  if  you  are
             allocating or withholding the windfall.  The format of  this
             command is:




                                    10-9
                             SYSTEM PERFORMANCE


             ENABLE CLASS-SCHEDULING ACCOUNTS         WITHHELD
                                     POLICY-PROGRAM   ALLOCATED

             For example,

             ENABLE CLASS-SCHEDULING ACCOUNTS ALLOCATED

             means turn  on  the  class  scheduler,  use  the  accounting
             method,  and  allocate  the  windfall.   Always allocate the
             windfall.  Do not withhold windfall unless you have  a  very
             good  reason  to  do  so,  and  you are sure that your class
             scheme works.

             The entry,

             ENABLE CLASS-SCHEDULING POLICY-PROGRAM ALLOCATED

             means turn on the class scheduler, use  the  policy  (access
             control) program, and allocate the windfall.

      7.     At the next system reload (the system is  brought  down  and
             back  up  again)  the  new commands in the n-CONFIG.CMD file
             take effect.



   10.1.5  Changing Class Percentages During Timesharing

   During timesharing,  you  can  change  the  percentage  that  a  class
   receives  by  using  the  SET command to OPR.  This change lasts until
   either the next system reload, or you make another  change  using  the
   SET command.  The format of the SET command appears:

   SET SCHEDULER CLASS (number) m (to percent) n

   n can be from 0-99 inclusive.  Note that the decimal point required in
   the CREATE command is not allowed in this command.

   To make the percentage that  a  class  receives  permanent,  edit  the
   CREATE  commands  in the n-CONFIG.CMD file.  For example, you can edit
   the commands

   CREATE O .60
   CREATE 1 .30
   CREATE 2 .10

   to

   CREATE 0 .10
   CREATE 1 .05
   CREATE 2 .80



                                   10-10
                             SYSTEM PERFORMANCE


   Next, reload the system to process the commands  in  the  n-CONFIG.CMD
   file.   The classes that received a low percentage before you made the
   change now receive a higher percentage of CPU time.

   Changing class percentage may be useful if you decide  that  users  in
   one  or  two  classes  should receive a greater percentage of CPU time
   than other classes during the  day.   However,  these  high-percentage
   classes  may  not  require this time during the evening shift.  If you
   have a recurring need for such  changes,  you  may  want  to  put  the
   appropriate commands into files for use with the TAKE command in OPR.



   10.1.6  Disabling the Class Scheduler During Timesharing

   You can turn the class scheduler off and back on during timesharing by
   using  the  DISABLE  and  ENABLE commands to OPR.  The class scheduler
   remembers the class percentages that were in effect before the DISABLE
   command  was  given.   For example, suppose you use the SET command to
   change the percentage that class  1  should  receive  from  05  to  15
   percent.   Then,  you  give  the  DISABLE CLASS-SCHEDULER command, and
   later give the ENABLE CLASS-SCHEDULER command.   The  class  scheduler
   uses 15 percent for class 1.  If you reload the system after disabling
   the class scheduler, the class scheduler is enabled again and uses the
   percentages given in the n-CONFIG.CMD file.



   10.1.7  Getting Information About Class Scheduler Status

   Several TOPS-20 commands provide  information  about  different  class
   scheduler statistics.

   The INFORMATION (ABOUT) SYSTEM-STATUS command informs you if:

         o  the class scheduler is enabled or disabled

         o  the accounting method or an access control program  is  being
            used

         o  windfall is allocated or withheld

         o  the system's batch jobs are in a separate class.

   For example

   @INFORMATION (ABOUT) SYSTEM-STATUS<RET>

    CLASS SCHEDULING BY ACCOUNTS ENABLED, WINDFALL ALLOCATED, BATCH CLASS 1.





                                   10-11
                             SYSTEM PERFORMANCE


   The INFORMATION (ABOUT) MONITOR-STATISTICS command  provides  a  table
   that  shows  each active class, its target use of the CPU, its current
   use of the CPU, and the load averages for that class.  For example,

   @INFORMATION (ABOUT) MONITOR-STATISTICS<RET>

    Class Share   Use   Loads

        0  0.80  0.79    6.56   4.36   3.57
        1  0.15  0.21    5.46   1.38    .95
        2  0.05  0.00    0.00   0.00   0.00

   The SYSTAT command outputs load averages for either the entire  system
   or  a  specific  class.   When  the class scheduler is disabled, these
   averages represent the load of the entire system.  For example,

   @SYSTAT<RET>
    Wed 11-Jul-88 10:17:09  Up 11:38:12
    52+16 Jobs   Load av  5.30  4.03   4.86

   The last three numbers following Load av indicate the  average  number
   of  runnable  processes over a period of one minute, five minutes, and
   fifteen minutes.  These numbers start at zero.  The higher the numbers
   the  longer  a job has to wait for CPU time on the average.  Using the
   example, over a fifteen minute period, a given job demanding  the  CPU
   waits  approximately 4.86 times longer to run than it would if it were
   the only job running on the system.

   When the class scheduler is enabled, these load averages represent the
   status  of the job doing the SYSTAT command and not the entire system.
   For example,

   @SYSTAT<RET>
    Wed 11-Jul-88 10:28:07  Up  11:49:12
    52+10 Jobs   Load av (class 1)   1.79   2.36    2.88

   The last three numbers following Load av indicate the load averages of
   the  class  that  the job giving the SYSTAT command is in.  The SYSTAT
   command with the CLASS argument provides a breakdown of  each  job  on
   the  system.   This  breakdown  includes the class each job is in, the
   average share of the class percentage that this job can  receive,  and
   how  much  CPU  time the job is currently using.  The TOPS-20 Commands
   Reference Manual describes these commands in detail.











                                   10-12
                             SYSTEM PERFORMANCE


   10.1.8  A Sample Session

   The following examples show:

         o  The  ACCOUNTS.CMD  file  after   associating   classes   with
            accounts.

         o  The  procedures  that  you  follow  after  editing  all  your
            accounting files.

         o  A sample of the class scheduling commands that are placed  in
            the 7-CONFIG.CMD file.

   !The <ACCOUNTS>ACCOUNTS.CMD file has been edited.

   $TYPE (FILE) MAIN:<ACCOUNTS>ACCOUNTS.CMD<RET>

   ACCOUNT MYBANK/CLASS:2
   USERS BLOUNT,KONEN,ENGEL

   ACCOUNT TRUST/CLASS:1
   USERS BRAITHWAITE,HURLEY,HALL,CRISS

   ACCOUNT OVERHEAD
   USERS SAMBERG,BERKOWITZ,TAYLOR

   ACCOUNT PROG/CLASS:3
   USERS BLOUNT,KOHN,HOLLAND

   $

   !Notice that account OVERHEAD uses the default class, 0.

   !Next, run the ACTGEN program.

   $RUN ACTGEN<RET>
   ACTGEN>TAKE (COMMANDS FROM) MAIN:<ACCOUNTS>ACCOUNTS.CMD<RET>

   !After ACTGEN finishes and returns its prompt, give the
   !INSTALL command to create a new version of the
   !<SYSTEM>ACCOUNTS-TABLE.BIN file

   ACTGEN>INSTALL<RET>

   !After ACTGEN finishes and returns its prompt, give the
   !EXIT command

   ACTGEN>EXIT<RET>
   $





                                   10-13
                             SYSTEM PERFORMANCE


   $TYPE SYSTEM:7-CONFIG.CMD<RET>

   !Terminal Speeds
   TERMINAL 1 SPEED 2400
   TERMINAL 2 SPEED 9600
   TERMINAL 3 SPEED 2400
   TERMINAL 4 SPEED 2400
   TERMINAL 5 SPEED 300
   TERMINAL 6 SPEED 300
   DEFINE SYS: MAIN:<SUBSYS>
   DEFINE SYSTEM: MAIN:<SYSTEM>
   DEFINE NEW: MAIN:<NEW>,SYS:
   DEFINE OLD: MAIN:<OLD>,SYS:
   DEFINE HLP: MAIN:<OLD>,SYS:
   MAGTAPE 0 40672 TU72
   MAGTAPE 1 37719 TU72
   PRINTER 0 VFU SYS:NORMAL.VFU
   PRINTER 0 LOWERCASE RAM SYS:LP96.RAM
   TIMEZONE 6

   !Commands for the class scheduler

   CREATE 0 .05
   CREATE 1 .45
   CREATE 2 .25
   CREATE 3 .15
   BATCH-CLASS 3
   ENABLE CLASS-SCHEDULING ACCOUNTS ALLOCATED

   $

   To start the Class Scheduler, either reload the system,  or  give  the
   ENABLE CLASS-SCHEDULER command to OPR.  If you edited the n-CONFIG.CMD
   file to remove the DISABLE ACCOUNT VALIDATION command, you must reload
   the system so you can start validating accounts.



   10.1.9  An Alternative to Using Accounts

   Chapter 11 describes the access control program (policy program)  that
   is  used  to  grant and restrict access to various system hardware and
   software.  This same program also  includes  the  appropriate  monitor
   calls  to handle class scheduler decisions.  Among the requests it can
|  define are classes at login.

                                    NOTE

           You CANNOT run the access control program to implement
           class scheduler decisions at the same time you use the
           accounting method.  You must use one or the other.



                                   10-14
                             SYSTEM PERFORMANCE


   10.2  SCHEDULING LOW PRIORITY TO BATCH JOBS

   The decision to favor batch jobs or to run them  as  background  tasks
   depends   on   the   type  of  batch  environment  you  have  at  your
   installation.  For example, if users submit batch jobs that  are  long
   and/or  that do not require completion immediately, you can give batch
   jobs a low priority.  Conversely, if batch jobs are the  primary  jobs
   on the system, you can give them a high priority.

   Section 10.1 describes how to place batch jobs in either a high or low
   percentage  class by including the BATCH n command in the n-CONFIG.CMD
   file.  When a user submits a batch job, the scheduler uses  the  batch
   class and not the user's class.

   You must use the class scheduler to give batch jobs a  high  priority.
   If  you  are  not using the class scheduler, you can give batch jobs a
|  low priority.  Do this in one of two ways:
|  
|        o  Enter the BATCH-BACKGROUND command in the n-CONFIG.CMD  file.
            This  command specifies that all batch jobs run on the lowest
            priority queue, also known as  the  background  queue.   This
            means   that  after  processing  all  interactive  jobs,  the
            scheduler selects and runs batch jobs waiting in  the  queue.
            They   receive   left-over  CPU  time.   You  can  enter  the
            BATCH-BACKGROUND command into  the  n-CONFIG.CMD  file.   The
            command takes effect the next time you reload the system.

                                        NOTE

                    The BATCH-BACKGROUND command is intended  for
                    those  who  are not using the class scheduler
                    on their system but want to  give  the  batch
                    jobs a low priority.  You should not use this
                    command when you enable the class scheduler.

|        o  The operator  can  issue  the  SET  SCHEDULER  BATCH-CLASS  n
|           command  at the OPR> prompt, where n can be BACKGROUND (batch
|           jobs are run in the lowest priority queue or NONE (batch jobs
|           receive no CPU time).



   10.3  FAVORING INTERACTIVE VERSUS COMPUTE-BOUND PROGRAMS

   This section describes how you can influence the  scheduler  to  favor
   either  interactive  or  compute-bound programs.  You do this by using
   the bias control, which is analogous to turning a knob over a range of
   settings  (from  1  to  20).   When  you  select  a  lower number, the
   scheduler favors users running interactive programs.  When you  select
   a  higher  number,  the  scheduler  favors users running computational
   programs.



                                   10-15
                             SYSTEM PERFORMANCE


                                    NOTE

           You can use bias control with  or  without  the  class
           scheduler  enabled.   However,  the effect of the bias
           control is less noticeable when used  with  the  class
           scheduler.

   After you install TOPS-20 software, the system uses the  default  bias
   control number 11.  This setting distributes the scheduler's attention
   evenly to interactive and compute-bound programs.

   New users of TOPS-20 can use the default setting until  they  need  to
   favor  particular  types  of  programs.  Previous users of TOPS-20 may
   want to experiment with new control settings.  For example,  the  bias
   controls  can  serve  as  a  good tool for favoring different types of
   users at different times of the day.  For instance, you  can  set  the
   bias  to  a  low number during the day to favor on-line users and to a
   high number during the evening to favor batch users.  The response you
   receive  from your user community should determine the appropriateness
   of the selected settings.

   Setting the bias toward interactive programs gives better response  to
   the  terminal  user.   Also,  this setting may produce a higher system
   overhead, because the scheduler swaps jobs and switches from different
   tasks  more  often  in  its  effort  to  favor  interactive  programs.
   Generally, setting the bias toward interactive programs is  beneficial
   only  if  you  have sufficient memory.  Both the swapping rate and the
   scheduler overhead are likely to increase in small  systems  with  too
   little  memory.   If  your  system  has adequate memory, the scheduler
   overhead should be fairly constant over most of the bias settings.

   Setting the bias toward computational programs  should  reduce  system
   overhead  and  increase  the  total  system  throughput.  However, the
   response to the terminal user may decrease slightly.  In  some  cases,
   the  improvement  in  system  throughput more than compensates for the
   lessened response time, and users are more satisfied.

   As you experiment with the bias settings, remember  that  setting  the
   bias  control  to  the  extremes can prevent certain types of programs
   from running for long time periods.

   After you select  a  bias  control  number  that  fits  your  system's
   operation,  enter the BIAS CONTROL command in the n-CONFIG.CMD file or
   use the SET SCHEDULER BIAS-CONTROL command to the OPR program.










                                   10-16
                             SYSTEM PERFORMANCE


   The format of the command in the n-CONFIG.CMD file is:

   BIAS CONTROL m

   The format of the command to OPR is:

   SET SCHEDULER BIAS-CONTROL (TO) m

   where m is the bias control number.  You can change the  bias  setting
   during  timesharing  by  using the SET SCHEDULER BIAS-CONTROL command.
   However,  when  you  reload  the  system,  the  bias  setting  in  the
   n-CONFIG.CMD  file  takes  effect.   If  you  want  your  change to be
   permanent, edit the n-CONFIG.CMD file at a convenient time before  you
   reload the system.

   Any time you are unsure of the current setting of  the  bias  control,
   give  the  INFORMATION  (ABOUT) SYSTEM-STATUS command to determine its
   setting.



   10.4  IMPROVING PROGRAM STARTUP TIME

   Some of the programs on your system are run frequently.  This involves
   constant  searching  for  the  same file on disk, bringing the program
   pages into memory, and allocating swapping space when the  program  is
   swapped out of memory.  By storing these programs in an easy-to-access
   area, some of the startup time is saved.  To improve the startup  time
   of  the  frequently used system programs, TOPS-20 keeps a program name
   cache.

   The <SYSTEM>PROGRAM-NAME-CACHE.TXT file is  placed  in  the  directory
   <SYSTEM>  on  the system structure automatically at installation time,
   and contains a list of programs  and  files  to  be  copied  into  the
   program name cache.  These are:

   SYS:PA1050.EXE
   SYS:MACRO.EXE
   SYS:EDIT.EXE
   SYS:TV.EXE
   SYS:LINK.EXE
   SYSTEM:ERRMES.BIN

   Each time you reload the system, the <SUBSYS>MAPPER.EXE  program  runs
   under    the    SYSJOB    program    at    the   operator's   console.
   <SUBSYS>MAPPER.EXE reads the <SYSTEM>PROGRAM-NAME-CACHE.TXT  file  and
   loads  the  program name cache.  Now, when requests are made for these
   programs, the system looks first in the program name cache to  see  if
   it can retrieve the required pages quickly.





                                   10-17
                             SYSTEM PERFORMANCE


   To  further   improve   system   performance,   you   can   edit   the
   PROGRAM-NAME-CACHE.TXT   file  and  add  the  filenames  of  your  own
   frequently accessed programs.  For example, if your  system  uses  the
   FORTRAN language, you may want to add the files:

   SYS:FORTRA.EXE
   SYS:FOROTS.EXE
   SYS:FORLIB.REL

   Your list can  contain  the  names  of  up  to  16  executable  files.
   Therefore,  select  the  files  to be placed in the program name cache
   carefully.  You should consider only the  executable  files  that  are
   started  frequently  by  a  large  number  of users.  You can also add
   library files to the program name cache, for example,  SYS:FORLIB.REL.
   However,  these types of files use up swapping space.  If you have too
   many or very large files, you may create a detrimental effect on  your
   system's  performance.   The  total  library file pages that you cache
   should be no greater than 200 to 300.  Give the VDIRECTORY command for
   the  library  files you want to cache and check the number of pages in
   each file.

   If you edit the cache file, the  revised  file  takes  effect  (MAPPER
   creates  a  new  version  of  the  cache) the next time you reload the
   system.  Alternatively, you can create a  new  version  of  the  cache
   immediately  by  entering  the  following  commands  at the operator's
   console.

   ^ESPEAK                     !talk to SYSJOB
   KILL MAPPER                 !kill old version of cache
   RUN SYS:MAPPER.EXE          !read new file and create
                               !new version of cache
   ^Z                          !exit



   10.5  REINITIALIZING DISK PACKS

   After many files are created, they may no longer be contiguous on  the
   structure  (disk(s)).   This scattering of files may increase the time
   it takes to  process  them.   You  may  decrease  processing  time  by
   reinitializing  the  disk  packs in your heavily used structures.  For
   example,  the  system  structure  may  be  a  likely   candidate   for
   reinitialization.   This  procedure  places  files  into  a contiguous
   format and can be scheduled as part of a backup procedure.  How  often
   you reinitialize your packs depends on the work load of the system and
   whether you notice a difference in system performance after  following
   this procedure.







                                   10-18
                             SYSTEM PERFORMANCE


   Reinitializing disk packs requires that you dump all  the  directories
   and  files  to  tape, re-create the structure (and, in the case of the
   system  structure,  reinstall  the  system),  and  restore   all   the
   directories   and   files.   Therefore,  if  you  do  not  notice  any
   appreciable difference in your system performance  after  doing  this,
   don't schedule it on a regular basis, if at all.

   The  TOPS-20  Operator's  Guide  describes  re-creating   the   system
   structure  and other structures.  Have the operator use this procedure
   for  reinitializing  disk  packs.   If  possible,  have  the  operator
   re-create  the structure and restore the files to a different pack (or
   set of packs) from the structure that you dumped.  This  ensures  that
   you  do  not lose your files should you have problems reading the tape
   back to disk.  That is, you still have the original  structure  intact
   and can run DUMPER again to copy the files to another tape.



   10.6  DYNAMIC DUAL PORTING

   Dynamic dual porting refers to a disk drive that is dual-ported to one
   system  only.   When one of the channels is busy transferring data for
   another disk unit, input/output is automatically switched through  the
   other  disk channel.  Dynamic dual porting improves the performance of
   input and output operations.   It  is  activated  automatically  after
   field service properly sets up the RP06 or RP07 disk drive(s), and the
   operator places the drives' port switches in the A/B position.

   Dynamic dual porting is not supported for RP20 disks.  If it is tried,
   only one path to the RP20 is used.

   The DECSYSTEM-20 Technical Summary describes the  hardware  associated
   with input and output operations.





















                                   10-19
























































                                    11-1











                                 CHAPTER 11

                              ACCESS CONTROLS



   TOPS-20 provides control mechanisms that help you:

         o  Govern the access to many  of  your  system's  resources  and
            services

         o  Reduce or prevent unauthorized access to the system

         o  Provide an audit trail to  help  investigate  occurrences  of
            unauthorized access

   The following sections discuss these topics.



   11.1  ACCESS CONTROL PROGRAM

   Previous chapters deal with  administrative  policies  for  allocating
   resources.  For example, Chapter 10 describes the policy decisions you
   can make regarding the scheduler, and Chapter 8 describes  the  policy
   decisions  you  can  make  regarding tape drive allocation and labeled
   tape support.

   In addition, you can make policy decisions that govern the  access  to
   specific  system  resources.   For  instance, TOPS-20 allows a user to
   change the speed of a terminal, assign a device,  enable  capabilities
   at any time of day, mount a magnetic tape, and mount a disk structure.
   However, you may want to restrict or disallow use  of  some  of  these
   facilities.   You  may want only specified users at specified times of
   the  day  and,  perhaps,  at  specified  terminals,  to  use   certain
   facilities.   A  particular  mechanism  lets you control the access to
   such resources and services.  With it, you have  an  additional  means
   for collecting accounting or other information.







                                    11-1
                              ACCESS CONTROLS


|  The following  sections  describe  how  to  use  this  access  control
|  mechanism  through  the  TOPS-20  access  control program (ACJ).  This
|  program carries out your policy  decisions  in  many  areas.   It  can
   control  scheduling classes, the bias control, batch background queue,
   logging  in,  use  of  physical  resources  (tape  drives,  terminals,
   structures),  and  enabling  capabilities.   When  a  user  requests a
   resource (like ASSIGN TTY34:), your program identifies the  user,  the
|  user's  controlling terminal, and the type of request being made.  The
   program can merely log this information in a file, or make a  decision
   and tell the monitor to either grant or deny the request.
|  
|  
|  
|  11.1.1  Starting the ACJ
|  
|  You can start the ACJ in three ways:
|  
|       1.  $^ESET SYSTEM-ACCESS-CONTROL-JOB
|  
|           The advantage of starting the ACJ with ^ESET is that there is
|           no  corresponding  ^ESET  NO  command  to  disable  the  ACJ.
|           Starting the ACJ this way or by way of the configuration file
|           is the most secure.
|  
|       2.  ENABLE SYSTEM-ACCESS-CONTROL-JOB command in the configuration
|           file
|  
|       3.  $ESPEAK command:
|  
|           $^ESPEAK
|           [Please type SYSJOB commands - end with ^Z]
|           RUN SYSTEM:ACJ.EXE
|           ^Z
|  
|           The  disadvantage  of  using  the  ^ESPEAK  command  is  that
|           privileged users can disable the ACJ:
|  
|           $^ESPEAK
|           [Please type SYSJOB commands - end with ^Z]
|           KILL ACJ
|           ^Z













                                    11-2
                              ACCESS CONTROLS


|  11.1.2  Defining the ACJ Environment
|  
|  To tailor the ACJ environment, run the ACJDEC program:
|  
|  @RUN ACJDEC
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||                   Also, if your site is  using  "secure"  files
|                   (see  Section  11.7),  enable  all the SECURE
|                   functions.
|  
|           Section  11.1.3.1  describes   the   ENABLE/DISABLE   command
|           functions.
|  
|        o  qualifier is one of the following:
|  
|           [NO] CONSOLE         [NO] DENY-BATCH     [NO] DENY-CTY
|           [NO] DENY-DECNET     [NO] DENY-DETACHED  [NO] DENY-LAT
|           [NO] DENY-LOCAL      [NO] DENY-PTY       [NO] DENY-TCP
|           [NO] LOG             [NO] POLICY
|  
|  
|                                       NOTE
|  
|                   The following qualifiers are frequently used:
|  
|                   [NO]LOG      [NO]POLICY
|  
|                   The defaults are LOG and POLICY.
|  
|           Section  11.1.3.2  describes   the   ENABLE/DISABLE   command
|           function qualifiers.



















                                    11-4
                              ACCESS CONTROLS


|  11.1.3.1  ENABLE/DISABLE Command Functions -
|  
|                                   NOTE
|  
|          You  can  specify  ALL  to  enable  or   disable   all
|          functions.
|  
|  
|   o  ENABLE ACCESS
|  
|      This function controls the ACCESS, CONNECT,  and  END-ACCESS  user
|      commands.   It  is  recommended that this function be enabled with
|      the POLICY and LOG qualifiers so that an  audit  trail  of  failed
|      accesses  and  user connections to their "owned" subdirectories is
|      created.  (Owned subdirectories are <username*> directories on any
|      file  structure  that  is  DOMESTIC.)  Directory owners are always
|      allowed to connect to their "owned" subdirectories.
|  
|   o  ENABLE ARPANET-ACCESS
|  
|      This function controls access to TCP/IP.   The  ACJ  is  activated
|      each  time a user tries to initiate an outgoing TCP/IP connection.
|      The  implemented  policy  allows  access  for  users  with  SC%ANA
|      capability  only.   To  log  all TCP/IP access and allow all users
|      TCP/IP access, enable this function with NO POLICY.
|  
|   o  ENABLE ASSIGN-DEVICE and ENABLE ASSIGN-DUE-TO-OPENF
|  
|      These identical functions  help  prevent  two  users  on  separate
|      systems  from  accessing  the same tape drive at the same time, if
|      the two systems are not in  the  same  CFS-20  cluster.   This  is
|      important  when  there  are shared tape drives between two or more
|      systems.
|  
|      Only users with enabled WHEEL or OPERATOR privileges  are  allowed
|      to  assign  magtape  devices.   The  functions prevent non-enabled
|      users from assigning magtape devices that are set UNAVAILABLE with
|      the OPR command.  All other devices are allowed.
|  
|      It is recommended that you enable this function  with  the  POLICY
|      and NOLOG qualifiers.













                                    11-5
                              ACCESS CONTROLS


|   o  ENABLE ATTACH-JOB
|  
|      Like LOGIN, the  ATTACH  function  controls  user  access  to  the
|      system.  The attach is denied if:
|  
|          The job is a batch job.
|  
|          The target job's user profile indicates that the  target  user
|          cannot log in to the source's line type.
|  
|          WHEEL-only logins are set for the source  line  type  and  the
|          target job is not a WHEEL user.
|  
|          The target job is a batch job and the source  job  is  not  an
|          enabled WHEEL.
|  
|          The source job  has  OPERATOR  capabilities  enabled  and  the
|          target job is a user with WHEEL.
|  
|          The  source  job  is  controlled  by  a  user  with   OPERATOR
|          capability   and   the   target  job  is  a  user  with  WHEEL
|          capabilities.
|  
|      It is recommended that you enable the ATTACH function with the LOG
|      and POLICY qualifiers.





























                                    11-6
                              ACCESS CONTROLS


|   o  ENABLE CAPABILITIES
|  
|      This function controls the enabling of the capabilities  described
|      in Section 5.9.
|  
|      To allow all users to enable at any time and to log all capability
|      changes,  enable  the  CAPABILITIES  function  with  the NO POLICY
|      qualifier.   Issue  the  DISABLE  CAPABILITIES  command  to  allow
|      enabling at any time with no logging of activity.
|  
|      Setting  WHEEL  or  OPERATOR  capabilities  is  disallowed  during
|      non-prime    time    unless    you    have    issued    the   USER
|      ENABLE-NON-PRIME-TIME command (described in Section 11.1.4).
|  
|      If you use the USER ENABLE-NON-PRIME-TIME  command  (described  in
|      Section  11.1.4),  it is recommended that you also use the LOG and
|      POLICY qualifiers.
|  
|      The CAPABILITIES function provides an audit trail of all users who
|      enable capabilities.
|  
|   o  ENABLE CLASS-ASSIGNMENT
|  
|      The ACJ is activated for all attempts to  set  a  job's  scheduler
|      class using the SKED% monitor call.  An example of this is the OPR
|      command SET JOB x SCHEDULER-CLASS y.  However, if a  user  is  not
|      WHEEL  or  OPERATOR  and is trying to set another job's class, the
|      ACJ is not consulted and the user receives a CAPX1 error.
|  
|   o  ENABLE CLASS-SET-AT-LOGIN
|  
|      The ACJ is activated each time a job logs in  only  if  the  class
|      scheduler  is  on  and  class  assignments  are  set by the policy
|      program.
|  
|      The policy implemented is to use a SKED% monitor call to  set  the
|      job  in  a  particular  class  as  specified  by  the user profile
|      CLASS-AT-LOGIN (see Section 11.1.4).  Because class  zero  is  the
|      default class, no SKED% monitor call is done if the CLASS-AT-LOGIN
|      in the user profile is set to zero or if there is no user  profile
|      associated  with the user logging in.  If the job cannot be set in
|      the proper class, the ACJ log file entry is marked as "unusual."












                                    11-7
                              ACCESS CONTROLS


|   o  ENABLE CREATE-DIRECTORY
|  
|      This function prevents unauthorized manipulation  of  directories.
|      It provides an audit trail of changes to directories and attempted
|      break-ins since the last new username was created or a  capability
|      was changed.
|  
|      This function has the following effects:
|  
|          Users with OPERATOR capabilities are not allowed to  make  new
|          usernames   or  changes  to  existing  usernames  on  DOMESTIC
|          structures.  With TOPS-20, the boot structure and  the  public
|          structure are always DOMESTIC and cannot be made FOREIGN.
|  
|          Setting  passwords  or  user  or  directory  groups   on   any
|          <ROOT-DIRECTORY> is not allowed.
|  
|          Only  enabled  WHEELs  can  change  the  following   directory
|          attributes:
|  
|                   SECURE
|                   FILES-ONLY
|                   WHEEL
|                   OPERATOR or SEMI-OPERATOR
|  
|          Nonprivileged  users  must  create  subdirectories  with   the
|          FILES-ONLY and NO SECURE attributes.
|  
|      It is recommended that you enable  the  CREATE-DIRECTORY  function
|      with the LOG and POLICY qualifiers.
|  
|   o  ENABLE CREATE-FORK
|  
|      This function controls the ability to create job forks.  Each time
|      a  user  runs  a program, a process (fork) is created.  The CFORK%
|      monitor call is used to create forks.  The ACJ  is  activated  for
|      each  CFORK%  monitor  call  that  creates  more than FKCNT forks.
|      (FKCNT is a monitor cell that system programmers can patch; it  is
|      defaulted to 5.) The ACJ always allows the CFORK% monitor call.
|  
|   o  ENABLE CREATE-JOB
|  
|      This function controls access to the CRJOB monitor call.  The  ACJ
|      allows only enabled WHEELs or OPERATORs to perform the CRJOB%.  To
|      log all CRJOB-created jobs but let any user use CRJOB, enable this
|      function with NO POLICY.








                                    11-8
                              ACCESS CONTROLS


|   o  ENABLE CREATE-LOGICAL-NAME
|  
|      This function controls the ability to  create  systemwide  logical
|      names.   The  ACJ  is  activated  for each of the following CRLNM%
|      monitor call functions when the user is not a WHEEL  or  OPERATOR:
|      CLNS1,  .CLNSA,  or  .CLNSY.   The LOG qualifier provides an audit
|      trail of logical name activity.
|  
|   o  ENABLE CTERM
|  
|      This function enables incoming CTERM connections by way of the SET
|      HOST  command.  It also creates an audit trail, which provides the
|      origin of the connecting user.  (The @SYSTAT command displays user
|      origins.)
|  
|      It is recommended that you  enable  this  function  with  the  LOG
|      qualifier.
|  
|   o  ENABLE DECNET-ACCESS
|  
|      This  function  allows  access  to  the  network  for  users  with
|      DECNET-ACCESS capability.
|  
|      It is recommended that you  enable  this  function  with  the  LOG
|      qualifier  to  provide  an  audit trail of users who are accessing
|      other systems through DECnet connections.
|  
|   o  ENABLE DETACH
|  
|      This function controls the ability to detach jobs by  way  of  the
|      DETACH  command.  The ACJ always allows users to detach jobs.  The
|      LOG qualifier provides an audit trail.
|  
|   o  ENABLE ENQ-QUOTA
|  
|      This function controls user setting of ENQ quota.  The ACJ  allows
|      only a WHEEL or OPERATOR to perform the function.
|  
|   o  ENABLE GET-DIRECTORY
|  
|      The GTDIR% monitor call provides information about a directory.
|  
|      The ACJ always allows the GTDIR% monitor call  to  succeed.   This
|      function  is  primarily  to  assure an audit trail whenever a user
|      gets  information  about  a   directory   (INFORMATION   DIRECTORY
|      command).








                                    11-9
                              ACCESS CONTROLS


|   o  ENABLE GETAB
|  
|      This function controls use of the GETAB% monitor call (SYSTAT  and
|      INFORMATION MONITOR commands) to get information from the monitor.
|      The ACJ is activated for each GETAB% when the previous context  is
|      not monitor.  The ACJ always allows the GETAB%.
|  
|      You should enable this function with caution, because it increases
|      system  overhead  and  slows  system response, especially when the
|      activity is logged.
|  
|   o  ENABLE HSYS
|  
|      This function allows only users with enabled WHEEL,  OPERATOR,  or
|      MAINTENANCE  privileges  to  shut down the system with the ^ECEASE
|      command.
|  
|   o  ENABLE INFO
|  
|      This function controls access to the INFO%  monitor  call  to  get
|      information  about  systems  in  a  CFS-20  cluster  (SYSTAT  NODE
|      command) or to send clusterwide notices.
|  
|      You should enable this function with caution, because it increases
|      system  overhead  and  slows  system response, especially when the
|      activity is logged.
|  
|   o  ENABLE LATOP
|  
|      This function allows enabled wheels  and  operators  to  implement
|      .LARHC  (request  host  connect)  functions  in the LATOP% monitor
|      call.  To log all LATOP% .LARHC  functions  and  allow  all  users
|      access  to LATOP%'s .LARHC functions, enable this function with NO
|      POLICY.  These functions are performed regularly by LPTSPL for LAT
|      printers.
|  
|   o  ENABLE LOGIN
|  
|      The LOGIN function controls access to the system.  A login request
|      is denied if:
|  
|          The user tries to log in to <ROOT-DIRECTORY>.
|  
|          The user is over quota on the ps:<username> directory.
|  
|          You specified with the  USER  command  (described  in  Section
|          11.1.4)  that  the  user  cannot  log in to this terminal line
|          type.
|  
|          WHEEL-only logins are set and the user  does  not  have  WHEEL
|          capability.



                                   11-10
                              ACCESS CONTROLS


|          The login attempt is on a non-batch PTY.
|  
|          The user has OPERATOR capability and is trying to log in to  a
|          directory with WHEEL capability.
|  
|      It is important to enable the LOGIN function so that there  is  an
|      audit trail for tracking "unusual" logins.
|  
|      It is recommended that you enable the LOGIN function with the  LOG
|      and POLICY qualifiers.
|  
|   o  ENABLE LOGOUT
|  
|      The ACJ is consulted each time a user attempts to  log  out.   The
|      logout  request  is  denied  if  the  user  is  over  quota on the
|      ps:<username> directory.
|  
|      The LOGOUT function helps capture a user session in an audit trail
|      by showing when the user logged out.
|  
|      It is recommended that you enable the LOGOUT function with the LOG
|      and POLICY qualifiers.
|  
|   o  ENABLE MDDT
|  
|      This function allows access to internal monitor data structures.
|  
|      All non-WHEEL users are  prevented  from  entering  MDDT,  because
|      through  MDDT,  users  can  violate  system  security or crash the
|      system.  It is important to enable this function with the LOG  and
|      POLICY  qualifiers  so  that  an  audit  trail  of  MDDT  entry is
|      available in case of security problems.
|  
|   o  ENABLE MTA-ACCESS
|  
|      This function controls access  to  magnetic  tapes.   The  ACJ  is
|      activated for labeled MTA access in the following situations:
|  
|       o  The label type is TOPS-20 and access is by non-owner and there
|          is a protection failure.
|  
|       o  ANSI labels are used and volume accessibility is not "full."
|  
|       o  EBCDIC labels are used and the accessibility byte is from 1 to
|          3 inclusive.
|  
|      The ACJ always allows the access.







                                   11-11
                              ACCESS CONTROLS


|   o  ENABLE SECURE
|  
|      Four ENABLE/DISABLE command functions control access  to  "secure"
|      files.   These  functions  are  described below.  Refer to Section
|      11.7 for details on secure files.
|  
|      ENABLE SECURE CHFDB% allows a request  to  set  or  clear  a  file
|      SECURE, based on settings in the ACCESS.CONTROL file.  If there is
|      no ACCESS.CONTROL file in the same directory as the file to be set
|      secure, the request is allowed and logged as "unusual."
|  
|      ENABLE SECURE DELF% allows the request to  delete  a  secure  file
|      based  on  settings  in  the  ACCESS.CONTROL file.  If there is no
|      ACCESS.CONTROL file in the  same  directory  as  the  file  to  be
|      deleted, the request is allowed and logged as "unusual."
|  
|      SECURE OPENF% allows the request to open a secure  file  based  on
|      settings  in the ACCESS.CONTROL file.  If a read, write, or append
|      access is attempted to a secure file and no ACCESS.CONTROL file is
|      in  the  same  directory as the secure file, the access is allowed
|      and logged as "unusual."
|  
|      SECURE RNAMF% allows the request to rename a secure file based  on
|      settings   in  the  ACCESS.CONTROL  file.   If  rename  access  is
|      attempted to a secure file and there is no ACCESS.CONTROL file  in
|      the same directory, the access is allowed and logged as "unusual."
|  
|   o  ENABLE SET-TIME
|  
|      The STAD% monitor call sets  the  system  time.   The  ACJ  always
|      allows the monitor call to succeed.  This function is primarily to
|      assure an audit trail  whenever  the  system  date  and  time  are
|      changed.
|  
|   o  ENABLE SMON
|  
|      The SMON% monitor call sets or clears  operating  system  features
|      (such  as  account  validation, logins allowed,...) and is usually
|      invoked with commands in SYSTEM:7-CONFIG and  the  ^ESET  command.
|      The ACJ is activated for each SMON%.
|  
|      The ACJ allows only enabled WHEELs or OPERATORs to use the monitor
|      call.
|  
|      It is recommended that you enable the function with  the  LOG  and
|      POLICY  qualifiers, because SMON% changes TOPS-20 operating system
|      parameters.







                                   11-12
                              ACCESS CONTROLS


|   o  ENABLE STRUCTURE-MOUNT
|  
|      This function controls mounting of disk structures.   The  ACJ  is
|      activated  for  every  MSTR%  monitor call "increment mount count"
|      function (.MSIMC function).  A job must have  a  "regulated"  file
|      structure mounted in order to use it.
|  
|      The ACJ always allows the increment of the mount  count  and  lets
|      normal file and directory protection handle security.
|  
|   o  ENABLE SYSGT
|  
|      The SYSGT% monitor call  extracts  information  from  the  monitor
|      (SYSTAT  and  INFORMATION MONITOR commands).  The ACJ is activated
|      for each SYSGT% when the previous context is not monitor.  The ACJ
|      always allows the SYSGT%.
|  
|      You should enable this function with caution, because it increases
|      system  overhead  and  slows  system response, especially when the
|      activity is logged.
|  
|   o  ENABLE TERMINAL-SPEED
|  
|      This function disallows the setting of terminal baud rate with the
|      SET  TERMINAL  command  unless  the WHEEL or OPERATOR privilege is
|      enabled.
|  
|   o  ENABLE TLINK
|  
|      The ACJ is activated when the following commands are invoked  from
|      outside  the  monitor:   ADVISE, TALK, BREAK, and REFUSE.  The ACJ
|      always allows these functions; however  users  can  override  them
|      with the REFUSE commands.
|  
|      If the user is set SPY-ON (see Section 11.1.4), the log entry will
|      be marked as "unusual."
|  
|   o  ENABLE TTMSG
|  
|      The ACJ is activated when the ^ESEND and SEND commands are invoked
|      from  outside  the monitor.  The ACJ allows only enabled WHEELs or
|      OPERATORs to use these commands and the  associated  monitor  call
|      (TTMSG%).
|  
|   o  ENABLE USER-TEST
|  
|      This function is reserved for customer  use.   System  programmers
|      should refer to function code 400000 of the GETOK monitor call.






                                   11-13
                              ACCESS CONTROLS


|  11.1.3.2  ENABLE/DISABLE Function Qualifiers -
|  
|  The following are qualifiers that you can specify with the ENABLE  and
|  DISABLE commands described in Section 11.1.3.1.
|  
|        o  [NO]POLICY
|  
|           Causes the enforcement of the  ACJ  policy  on  a  particular
|           ENABLE  function.   The  default  is  POLICY.   The NO POLICY
|           qualifier is often combined with the LOG  qualifier;  without
|           this   qualifier,  the  effect  is  similar  to  the  DISABLE
|           function.
|  
|        o  [NO]LOG
|  
|           Creates an entry in the  ACJ  log  file  that  describes  the
|           function.  The default is LOG.
|  
|        o  [NO] CONSOLE
|  
|           The CONSOLE keyword enables display of the logging string  to
|           the console terminal.  The default is NO CONSOLE.
|  
|        o  [NO] DENY-BATCH
|  
|           The DENY-BATCH keyword causes a  request  for  this  function
|           from  any  batch  job to always be denied.  The default is NO
|           DENY-BATCH.
|  
|        o  [NO] DENY-CTY
|  
|           The DENY-CTY keyword causes a request by a  job  logged  into
|           the  system's console terminal (the CTY) to always be denied.
|           The default is NO DENY-CTY.
|  
|        o  [NO] DENY-DECNET
|  
|           The DENY-DECNET keyword causes a request by a  job  which  is
|           attached to the system through DECnet (NRT or CTERM protocol)
|           to always be denied.  The default is NO DENY-DECNET.
|  
|        o  [NO] DENY-DETACHED
|  
|           The DENY-DETACHED keyword causes a request by a detached  job
|           to always be denied.  The default is NO DENY-DETACHED.
|  
|        o  [NO] DENY-LAT
|  
|           The DENY-LAT keyword causes a request by a  job  attached  to
|           the  system  through a LAT terminal to always be denied.  The
|           default is NO DENY-LAT.



                                   11-14
                              ACCESS CONTROLS


|        o  [NO] DENY-LOCAL
|  
|           The DENY-LOCAL keyword causes a request by a job logged  into
|           any  terminal  local  to the system to always be denied.  The
|           default is NO DENY-LOCAL.
|  
|        o  [NO] DENY-PTY
|  
|           The DENY-PTY keyword causes a request by a job attached to  a
|           PTY that is not a batch job to always be denied.  The default
|           is NO DENY-PTY.
|  
|        o  [NO] DENY-TCP
|  
|           The DENY-TCP keyword causes a request by a  job  attached  to
|           the  system  through  TCP/IP  (TELNET  protocol) to always be
|           denied.  The default is NO DENY-TCP.
|  
|  
|  
|  11.1.4  USER Command
|  
|  You can make ACJ profile entries for users:
|  
|  ACJDEC>USER username keyword
|  
|  Where:
|  
|        o  username is a particular user or all users (*)
|  
|        o  keyword is one of the following:
|  
|  CLASS-AT-LOGIN n
|  
|  Sets scheduler class "n" at login.  The default is CLASS-AT-LOGIN 0
|  
|  [NO] ENABLE-NON-PRIME-TIME
|  
|  Lets users enable capabilities at times other  than  prime  time  (see
|  Section 11.1.5).  If you want to let anyone enable at any time, enable
|  the CAPABILITIES function with the NO POLICY qualifier, or  issue  the
|  DISABLE     CAPABILITIES     command.      The     default    is    NO
|  ENABLE-NON-PRIME-TIME.
|  
|  [NO] LOGIN-BATCH
|  
|  Lets batch jobs log in.  The default is NO LOGIN-BATCH.  Note that the
|  LOGIN-PTY keyword controls non-batch PTY logins.






                                   11-15
                              ACCESS CONTROLS


|  [NO] LOGIN-CTY
|  
|  Lets a job log in to the system through the system's console  terminal
|  (the CTY).  The default is LOGIN-CTY.
|  
|  [NO] LOGIN-DECNET
|  
|  Lets a job log in to the system through DECnet using the NRT or  CTERM
|  protocol.  Do not confuse this keyword with remote DECnet access using
|  the RMSFAL (which is controlled by the LOGIN-DETACHED  keyword).   The
|  default is LOGIN-DECNET.
|  
|  [NO] LOGIN-DETACHED
|  
|  Lets a job log  in  detached.   Digital-supplied  software  that  does
|  detached  logins  is  limited  to  DIU  (Data Interchange Utility) and
|  RMSFAL (RMS File Access Listener).
|  
|  [NO] LOGIN-LAT
|  
|  Lets a job log in to the system through a LAT terminal.
|  
|  [NO] LOGIN-LOCAL
|  
|  Lets a job log in to terminal  lines  connected  to  the  DECSYSTEM-20
|  (RSX20F  console  front end) that are not configured as REMOTE.  LOCAL
|  lines are normally connected directly  to  terminals  rather  than  to
|  communications equipment such as modems or port selecters.
|  
|  [NO] LOGIN-PTY
|  
|  Lets a job log in to a PTY that is not a batch job.
|  
|  [NO] LOGIN-REMOTE
|  
|  Lets a job log in to terminal  lines  connected  to  the  DECSYSTEM-20
|  (RSX20F  console  front  end)  that  are configured as REMOTE.  REMOTE
|  lines are normally connected to modems or port-selecting equipment and
|  not directly to terminals.
|  
|  [NO] LOGIN-TCP
|  
|  Lets a job log in to the system  through  a  TCP/IP  terminal  (TELNET
|  protocol).
|  
|  [NO] SPY-ON
|  
|  Users will be spied on when logging in  or  attaching  to  jobs.   The
|  default is NO SPY-ON.





                                   11-16
                              ACCESS CONTROLS


|  EXAMPLE
|  
|  USER command keywords are normally combined.  For example, if  a  user
|  should  be  able to log in only from a batch job and for DECnet access
|  using RMSFAL, you should set the keywords for that user as follows:
|  
|  NO LOGIN-CTY
|  NO LOGIN-DECNET
|  NO LOGIN-LAT
|  NO LOGIN-LOCAL
|  NO LOGIN-PTY NO
|  LOGIN-REMOTE
|  NO LOGIN-TCP
|  
|  In the example above, only LOGIN-BATCH and LOGIN-DETACHED are allowed.
|  
|  
|  
|  11.1.5  SET Command
|  
|  You can tailor the ACJ environment with the SET command:
|  
|  ACJDEC>SET keyword
|  
|  Where keyword is one of the following:
|  
|  ACCESS-LOG-FILE               PRIME-TIME-BEGIN
|  PRIME-TIME-END                SPY-CHECK-INTERVAL
|  SPY-LOG-DIRECTORY             LOG-FILE-CACHE-SWEEP-INTERVAL
|  
|  The SET command keywords are described below:
|  
|  ACCESS-LOG-FILE filespec
|  
|  Sets the log file specification.  The default is SYSTEM:LOGFILE.LOG.
|  
|  LOG-FILE-CACHE-SWEEP-INTERVAL n
|  
|  Sets the log file cache sweep interval.  The log file is updated every
|  few  seconds (or whenever it is about to be read or renamed).  The log
|  file cache sweep interval defaults to 30 seconds.  The  cache  can  be
|  disabled  by  setting  the log file cache sweep interval to zero; this
|  forces the log file to be updated each time a line is written to it.
|  
|  PRIME-TIME-BEGIN time
|  
|  Sets the time at which prime time begins on each weekday.   This  time
|  is  used  when you issue the USER ENABLE-PRIME-TIME command (described
|  in Section 11.1.4) with the ENABLE CAPABILITIES command.  The  default
|  beginning time is 07:00 (7 AM).




                                   11-17
                              ACCESS CONTROLS


|  PRIME-TIME-END time
|  
|  Sets the time at which prime time ends on each weekday.  This time  is
|  used when you issue the USER ENABLE-PRIME-TIME command with the ENABLE
|  CAPABILITIES command.  The default ending time is 18:00 (6 PM).
|  
|  SPY-CHECK-INTERVAL seconds
|  
|  Sets the time between TLINK% monitor calls  to  jobs  that  are  being
|  spied  on.   Shorter  times  increase overhead but lower the risk that
|  spying data will be lost.  The default is 10 seconds.
|  
|  SPY-LOG-DIRECTORY string
|  
|  Sets the initial part of the specification for  spy  log  files.   The
|  string  will  have "-nodename.username" appended to it to complete the
|  file specification.  The default is SYSTEM:ACJ-SPY, so spy  log  files
|  are of the form "SYSTEM:ACJ-SPY-nodename.username."
|  
|  The ACJ always makes spy log files secure.
|  
|  
|  
|  11.1.6  SHOW Command
|  
|  The SHOW command displays the items changed with the ENABLE,  DISABLE,
|  SET,  and  USER  commands.  The SHOW command is followed by one of the
|  following keywords:
|  
|        o  ALL
|  
|           Shows all information.
|  
|        o  FUNCTION ALL keyword
|  
|           Shows the  profile  of  all  functions  or  of  a  particular
|           function.
|  
|        o  SETTINGS ALL keyword
|  
|           Shows all items or a  particular  item  changed  by  the  SET
|           command.
|  
|        o  USER ALL * or username
|  
|           Shows all user profiles or a particular user profile.








                                   11-18
                              ACCESS CONTROLS


|  11.1.7  WRITE Command
|  
|  When you have finished issuing ACJDEC commands, write the ACJ settings
|  to the profile file:
|  
|  ACJDEC>WRITE filename
|  
|  Where filename is the name of the profile file.  The default  filename
|  is ACJPROFILE.CMD.
|  
|  The following is a sample profile file:
|  
|  Set PRIME-TIME-BEGIN 07:30
|  Set PRIME-TIME-END 18:00
|  Enable ACCESS
|  Enable ARPANET-ACCESS NO POLICY
|  Enable ASSIGN-DEVICE NO LOG
|  Enable ASSIGN-DUE-TO-OPENF NO LOG
|  Enable ATTACH-JOB
|  Enable CAPABILITIES DENY-DECNET DENY-TCP
|  Enable CREATE-DIRECTORY
|  Enable CTERM
|  Enable DECNET-ACCESS NO POLICY
|  Enable LOGIN
|  Enable LOGOUT
|  Enable MDDT DENY-BATCH DENY-DETACHED
|  Enable SECURE-CHFDB
|  Enable SECURE-DELF
|  Enable SECURE-OPENF
|  Enable SECURE-RNAMF
|  User FS ENABLE-NON-PRIME-TIME
|  
|  
|  
|  11.1.8  SAVE Command
|  
|  When you have written the profile file, create the ACJ:
|  
|  ACJDEC>SAVE filename
|  
|  Where filename is the name of the access control program.  The default
|  filename is ACJ.EXE.












                                   11-19
                              ACCESS CONTROLS


|  11.1.9  Summary
|  
|  Follow these steps to implement the ACJ:
|  
|       1.  Run the ACJDEC.EXE program:
|  
|               @RUN ACJDEC.EXE
|  
|               ACJDEC>
|  
|       2.  Set up the ACJ and user environments:
|  
|               ACJDEC>TAKE ACJPROFILE.CMD
|  
|               ACJDEC>Set PRIME-TIME-BEGIN 07:30
|  
|               ACJDEC>Enable ACCESS
|  
|               ACJDEC>User FS ENABLE-NON-PRIME-TIME
|               .
|               .
|               .
|  
|       3.  Write the commands into the ACJPROFILE.CMD command file:
|  
|               ACJDEC>WRITE
|  
|       4.  Create the ACJ.EXE policy program from the current settings:
|  
|               ACJDEC>SAVE SYSTEM:
|  
|               ACJ.EXE.1 Saved
|  
|       5.  Start the ACJ policy program:
|  
|               $^ESET SYSTEM-ACCESS-CONTROL-JOB


















                                   11-20
                              ACCESS CONTROLS


|  11.1.10  Reviewing the Log Files
|  
|  You should review daily the log files produced by the ACJ for possible
|  unusual  activity.   Careful  monitoring  results  in  greater  system
|  security, because repeat penetrations cause the most  severe  security
|  problems.   The log file is always made "secure" (see Section 11.7) to
|  prevent unauthorized access.  A new generation  of  the  log  file  is
|  created each time the ACJ is run and each night at midnight.
|  
|  
|  
|  11.1.10.1  Log File Format -
|  
|  The log file is split into pages with a  header  on  each  page.   The
|  first  line  of  the header contains the ACJ version, system nodename,
|  current date/time, and  page  number.   The  second  and  third  lines
|  summarize  the  activity  so far:  number of requests allowed, denied,
|  and failed; CPU time used; and "uptime" of the ACJ.
|  
|  Each activity results in one line of text in the log file.  The  first
|  item  is  the time of day.  The second item is the username requesting
|  the operator.  (For the LOGIN function, the username that is trying to
|  log  in  is  in  this  field.)  The  next  field is the access control
|  function.  Following the function, there is information about the job.
|  This  information  consists  of the job number, controlling job if the
|  job is being run on a PTY, "batch" if it  is  a  batch  job,  terminal
|  number,  network  origin  string  if the job originates from a network
|  terminal, and the job's current program name.   Finally,  the  enabled
|  capabilities of the process attempting access are displayed.
|  
|  Following that fixed information is a comma and  information  that  is
|  specific  to  this  request  type.  For example, if a user is enabling
|  capabilities, the desired capabilities are shown.
|  
|  At the end of the line one of three strings may appear.
|  
|        o  [Denied] indicates that the  ACJ  denied  the  request.   For
|           example,  a user tried to log in but is not allowed to log in
|           to that terminal type.
|  
|        o  [Failed] indicates that the ACJ allowed the request but  that
|           the  action  failed.  For example, a user tried to log in but
|           gave a bad password.
|  
|        o  [Unusual] indicates that the ACJ allowed the request  but  it
|           is  in  some way unusual.  For example, a user logged in when
|           that user is set SPY-ON.   The  conditions  under  which  the
|           request  is  considered  unusual  are  documented  in Section
|           11.1.3, ENABLE and DISABLE commands.





                                   11-21
                              ACCESS CONTROLS


|  11.1.10.2  Log File Examples -
|  
|  This section shows sample entries from a typical ACJ log file.
|  
|  The following is a sample ACJ log file header.  It shows that the  log
|  file  was  started  at  midnight and that the ACJ has been up about 12
|  hours, processing 790 requests.
|  
|       ACJ 7(100) on GARK, Thursday, February 2, 1989 00:00:00, page 1
|       Allowed 782 requests, denied 8 requests, 5 requests failed
|       Used 1:09.32 in 11:57:56.69
|  
|  The following log file entries  show  a  batch  job  execution.   User
|  OPERATOR  running  BATCON  opened  a  PTY,  assigned it to itself, and
|  created a job, which logged in to user  SCHMITT.   That  user  enabled
|  capabilities,  and  then  the  batch  job  ran to completion.  The job
|  running BATCON then logged out the batch job.
|  
|       00:00:47 OPERATOR Open-assign job 194 ctrl 193 TTY233 GALAXY opr
|       ana, device PTY7
|       00:00:47 OPERATOR Assign job 194 ctrl 193 TTY233 GALAXY opr ana,
|       TTY241
|       00:00:48 OPERATOR CRJOB job 194 ctrl 193 TTY233 GALAXY opr ana
|       00:00:48 SCHMITT Login job 206 batch TTY241 EXEC, by OPERATOR job
|       194 ctrl 193 TTY233 GALAXY
|       00:00:49 SCHMITT Caps job 206 batch TTY241 ENABLE, desired whl
|       00:01:36 OPERATOR Logout job 194 ctrl 193 TTY233 GALAXY opr ana,
|       target SCHMITT job 206 batch TTY241 EXEC
|  
|  The next two entries show  an  incoming  CTERM  connection  from  user
|  SGAGNE on system GIDNEY, who proceeds to log in to this system.
|  
|       08:35:49 OPERATOR Cterm job 0 Det SYSJOB, from GIDNEY::SGAGNE
|       08:35:55 SGAGNE Login job 214 TTY364 GIDNEY::SGAGNE(CTM) LOGIN
|  
|  Below, user GAS tried to attach to his  detached  job  and  apparently
|  typed  an  incorrect  password  (see [Failed]).  On the second try, he
|  succeeded and attached to his job.
|  
|       09:38:48 not-logged-in Attach job 214 TTY444 LAT1(LAT) ATTACH,
|       target GAS job 207 Det DETACH [Failed]
|       09:38:58 not-logged-in Attach job 214 TTY444 LAT1(LAT) ATTACH,
|       target GAS job 207 Det DETACH











                                   11-22
                              ACCESS CONTROLS


|  Below, the first entry shows the OPERATOR job running MX connecting to
|  system  VAXVLN  using  DECnet.   The  second  entry  shows  the MX job
|  delivering mail to user APUCHRIK, who has a  "secure"  MAIL.TXT  file.
|  The third entry shows this same user accessing his mail file with MS.
|  
|       09:39:32 OPERATOR DECnet job 198 ctrl 193 TTY237 MX opr ana, to
|       VAXVLN
|       09:47:11 OPERATOR Secure-OPENF job 198 ctrl 193 TTY237 MX opr
|       ana, read write PUBLIC:<APUCHRIK>MAIL.TXT.1
|       09:49:15 APUCHRIK Secure-OPENF job 199 TTY435 LAT1(LAT) MS, read
|       write preserve-dates PUBLIC:<APUCHRIK>MAIL.TXT.1
|  
|  The first line below shows a user trying to set TTY3's terminal speed.
|  The  request is denied.  The second and third lines show OPERATOR jobs
|  running DUMPER to save the system.  The second line  shows  that  user
|  RASPUZZI  did  not  allow  OPERATOR  read access to a file; the access
|  failed and the file is not backed up.  The third  line  shows  that  a
|  SECURE  file  was  opened for reading, but there was no ACCESS.CONTROL
|  file present in that directory.  The request is marked as unusual, and
|  access is allowed.
|  
|       19:17:56 JWONG Terminal-speed job 216 TTY3 EXEC, TTY3 input 2400
|       output 2400 [Denied]
|       19:38:00 OPERATOR Secure-OPENF job 215 ctrl 206 TTY243 DUMPER opr
|       ana, read preserve-dates RANDOM:<RASPUZZI.MAIL>JAN89MAIL.TXT.1
|       [Denied]
|       19:38:24 OPERATOR Secure-OPENF job 211 ctrl 206 TTY241 DUMPER opr
|       ana, read preserve-dates WORK:<DEVANS.POOF>BOBBIE.MAIL.1
|       [Unusual]



   11.2  PASSWORD ENCRYPTION

   One way to violate system security  is  through  unauthorized  use  of
   directory  passwords.  Having acquired someone's password, an intruder
   could log in or gain  access  to  restricted  system  resources.   The
   password  encryption  facility in TOPS-20, however, makes it harder to
   steal passwords.

   With  encryption  enabled,  passwords  entered  into  the  system  are
   translated  to  an  indecipherable  cyphertext  format before they are
   stored or otherwise used.  Nowhere  in  the  system  is  the  original
   plaintext  form of a password kept.  As a further security measure, no
   current TOPS-20 utility converts the cyphertext to plaintext.

                                    NOTE

           Password  encryption  is   irreversible.    Therefore,
           before  enabling  encryption,  be  sure you will never
           need to revert back  to  an  earlier  version  of  the
           operating system.


                                   11-23
                              ACCESS CONTROLS


   To enable password encryption, use the CHECKD  program.   You  can  do
   this  during  or  after system installation.  (Refer to the TOPS-20 KL
   Model  B  Installation  Guide  for  details.)  With  CHECKD,  password
   encryption  is  enabled  on  a structure-by-structure basis; after the
   procedure, all passwords for a particular structure are  encrypted  as
   previously  described.   If  you enable encryption after installation,
   run the KRYPTN program after  CHECKD  to  convert  existing  plaintext
   passwords on a structure to cyphertext.  The KRYPTN program is located
   on the tools tape, which is part of the TOPS-20 software  installation
   package.

   Encryption should be enabled for all structures except those that will
   be  used on a TOPS-20 pre-Version 6 system.  (Section 11.2.1 discusses
   this topic.)

   You can add your own encryption algorithm to the system if you  choose
   not to use TOPS-20's algorithm.  Refer to Section 11.2.2.

   Because the encryption algorithm is irreversible, care is required  in
   the following areas:

         o  Remembering one's password

         o  Working in a multiple-system environment

         o  Adding new algorithms to the system

         o  Using DUMPER

   Mistakes in these areas could invalidate passwords so  that  they  may
   need  to  be  respecified  with BUILD or ^ECREATE.  These interrelated
   topics are discussed in the following sections.






















                                   11-24
                              ACCESS CONTROLS


   11.2.1  Moving Structures Among Systems

   If you are in a multiple-system environment,  you  may  need  to  move
   structures from one system to another.  Problems could arise, however,
   if some systems are running TOPS-20 pre-Version 6 software and  others
   are  running  TOPS-20  Version  6.   For  example,  when  a  structure
   containing encrypted passwords is taken to  a  TOPS-20  pre-Version  6
   system, any access to files on the pack that requires a password to be
   supplied fails, because, in validating a password, the  older  monitor
   simply  compares  the  entered  plaintext  to the cyphertext stored on
   disk.  The older monitor is unfamiliar with the encryption process.

   To avoid this problem, you should  postpone  encryption  for  relevant
   structures until all systems are upgraded.

   Any TOPS-20 system can correctly handle unencrypted structures.

   You could also  encounter  problems  in  moving  structures  to  other
   systems  if  you  use  your  own  encryption algorithm.  This topic is
   discussed below.



   11.2.2  Adding Encryption Algorithms to the System

   You can use one or more of your own encryption algorithms  exclusively
   or  in  addition  to  TOPS-20's  algorithm.   For a description of the
   procedures involved, refer to the monitor module, STG.MAC.

   Each time a password is encrypted  and  stored  in  a  directory,  the
   version  number  of  the  algorithm used to encrypt it is also stored.
   This allows new encryption algorithms to be added to the  system  with
   no   impact   on  currently  encrypted  passwords,  provided  the  old
   algorithms have not been removed from  the  monitor.   Only  passwords
   created  since the installation of the new (current) algorithm will be
   encrypted with that algorithm.  Older passwords invoke the appropriate
   algorithms during password-required accesses.

   If you also want existing passwords to  use  the  new  algorithm,  the
   operator  must  individually  respecify  the  passwords  with BUILD or
   ^ECREATE.   The  operator  does  this  after  the  new  algorithm   is
   installed.   Note  that KRYPTN cannot be used here to convert existing
   cyphertext to new cyphertext.











                                   11-25
                              ACCESS CONTROLS


   In using your own encryption algorithms, be aware that directories  on
   structures  and  on DUMPER-created tapes include passwords that may be
   unusable at other sites.  Other TOPS-20 monitors  could  consider  the
   passwords'  algorithm  version  numbers  to  be invalid.  For example,
   these monitors may acknowledge only the  standard  TOPS-20  algorithm.
   Even  if  a  site  accepts  the  version  numbers,  its  corresponding
   algorithms may be different from the algorithms at your  site.   Thus,
   on  attempted password use, the cyphertext produced at this other site
   could never match the stored cyphertext.

   To address these problems, you could:

         o  Warn sites about the nature of the passwords  on  a  tape  or
            structure.  A site could then avoid using certain directories
            or respecify a password with BUILD or ^ECREATE if necessary.

         o  Refrain from saving directory information on tapes bound  for
            other  sites.   That  is,  do not use DUMPER's CREATE command
            when creating such tapes.

         o  Ship  only  directories  that  have  null  passwords.   These
            "passwords"  are  considered unencrypted, and should cause no
            problem on any system.



   11.2.3  Using DUMPER

   Section 11.2.2 addressed using  DUMPER  with  nonstandard  algorithms.
   This section continues the discussion of DUMPER.

   Care must be taken when restoring directories  that  were  saved  with
   DUMPER's  CREATE command.  Incompatible versions of tapes, DUMPER, and
   TOPS-20, when combined,  can  produce  a  number  of  password-related
   problems.   Note the system's behavior during tape restoration for the
   combinations in Table 11-1.  In the  table,  tape  Version  4  is  the
   version  of  tape  that DUMPER Version 4.1 creates.  Tape Version 5 is
   the version of tape that DUMPER Version 5 creates.
















                                   11-26
                              ACCESS CONTROLS


   Table 11-1:  DUMPER Directory Restorations


   ____________________________________________________________________

   Tape Version      DUMPER            MONITOR           Result
   ____________________________________________________________________

   5                 5                 6                 OK
   4                 5                 6                 OK (N1)

   5                 4.1               6                 E1
   4                 4.1               6                 OK (N1)

   5                 5                 5                 E2
   4                 5                 5                 OK

   5                 4.1               5                 E3
   4                 4.1               5                 OK
   ____________________________________________________________________


     Legend:

     N1  Passwords  are  correctly  encrypted for the first time using
         the monitor's current encryption algorithm.

     E1  The  tape  version  number  is incompatible with this DUMPER.
         DUMPER reports this fact before restoring the tape  data.  If
         directories are restored from this tape, encrypted  passwords
         are  re-encrypted,  causing  all  uses  of these passwords to
         fail.  The  passwords  will  then  have  to  be  individually
         respecified with BUILD or ^ECREATE. However, if a password is
         unencrypted  on  the tape, then it is encrypted for the first
         time, and will be usable.

         Any files on this tape are restored correctly.

     E2  Pre-version   6   monitors   have   no   logic   to    handle
         encryption-related data that the tape may contain. Therefore,
         restored  encrypted  passwords  are  unusable  and  must   be
         respecified with  BUILD  or  ^ECREATE.  Note  that  directory
         blocks  on  the  tape   may   contain   password   descriptor
         information, such as  the  encryption  version  number.  This
         descriptor data is not restored.

         Any files on this tape are restored correctly.

     E3  The  tape  version  number  is incompatible with this DUMPER.
         DUMPER reports this fact before restoring the tape data. This
         incompatibility results in the same situation as E2.



                                   11-27
                              ACCESS CONTROLS


   If these problems occur often, users and operators could refrain  from
   saving  directory  information  on  tapes,  or  they  could  use  null
   passwords for directories that are to be saved.   Null  passwords  are
   considered to be unencrypted and should cause no access problems.



   11.3  PASSWORD MANAGEMENT

   Encryption is just one part of password management.  You  should  also
   make sure that users at your site do not choose passwords that are too
   short or that are otherwise easy to  guess,  such  as  one's  name  or
   initials.
|  
|  
|  
|  11.3.1  Setting Password Length
|  
|  You can set the minimum password length in the n-CONFIG.CMD file  with
|  the command:
|  
|  ENABLE MINIMUM-PASSWORD-LENGTH n
|  
|  where:
|  
|           n is the minimum number of characters allowed for  passwords,
|           from  1  to  39  characters.   A  common  value  for  n  is 8
|           characters.
|  
|  Or, you can issue the command:
|  
|  $^ESET [NO] MINIMUM-PASSWORD-LENGTH n
|  
|  The @INFORMATION SYSTEM command reports the  minimum  password  length
|  set for your system.
|  
|  
|  
|  11.3.2  Changing Passwords Regularly
|  
|  It  would  also  be  helpful  for  users  to  change  their  passwords
|  regularly.   You can enforce this through the ^ESET command and in the
|  n-CONFIGURATION file:
|  
|  $^ESET [NO] PASSWORD-EXPIRATION (TO) N
|  
|  In the n-CONFIGURATION file:
|  
|  ENABLE PASSWORD-EXPIRATION n
|  DISABLE PASSWORD-EXPIRATION




                                   11-28
                              ACCESS CONTROLS


|  Where:
|  
|           n is the date after which passwords expire
|  
|           n is the number of days a password is valid since the time it
|           was  last  changed.   This  value  for  n  is a number from 1
|           through  366.   The  default  number  of  days  is  30.   The
|           @INFORMATION  SYSTEM  command  reports  the  number of days a
|           password is valid.
|  
|  After a password has expired, the user will be allowed to log  in  but
|  must change the password immediately.
|  
|  
|  
|  11.3.3  Disallowing Certain Passwords
|  
|  You may want to make certain combinations of  characters  illegal  for
|  use  as  passwords.   Perhaps  they  would be too easily guessed by an
|  intruder.    You    can    place    such    words    in    the    file
|  SYSTEM:PASSWORD.DICTIONARY and have them automatically matched against
|  newly supplied passwords.  If a match occurs, the password is  denied,
|  and the user must choose a new one.
|  
|  The following is a sample password dictionary file.  Note  that  words
|  must be placed in the file alphabetically.
|  
|            ABORT, S, ED, ING
|            ABUSE, S, D, \ING
|            ACQUIT, S, "ED, "ING
|            ADMIRAL, S, 'S
|  
|  The first line shows the word  ABORT.   Other  entries,  separated  by
|  commas,  indicate  suffixes  that  are  added to ABORT.  So, the first
|  line, in effect, contains the following words that cannot be  used  as
|  passwords:  ABORT, ABORTS, ABORTED, or ABORTING.
|  
|  In the second line, the  backslash  character  (\)  removes  the  last
|  character  from  the  base word and adds the suffix.  The base word is
|  ABUSE.  After the final E is  removed  and  ING  is  added,  the  word
|  ABUSING is formed and cannot be used as a password.
|  
|  In the third line, the quote character (") duplicates the last  letter
|  of the word before adding the suffix; ACQUIT becomes ACQUITTED.
|  
|  In the final line, the apostrophe is  taken  as  is.   The  base  word
|  ADMIRAL becomes ADMIRAL'S.







                                   11-29
                              ACCESS CONTROLS


|  You can enable and disable the dictionary-checking feature through the
|  ^ESET command or in the n-CONFIG.CMD file:
|  
|  $^ESET [NO] PASSWORD-DICTIONARY
|  
|  In the n-CONFIG.CMD file:
|  
|  ENABLE PASSWORD-DICTIONARY
|  DISABLE PASSWORD-DICTIONARY
|  
|  The @INFORMATION SYSTEM command reports whether or  not  the  password
|  dictionary is enabled.



   11.4  LAST LOGIN INFORMATION

   When users log into the system, the dates and times they  last  logged
   in  are  displayed  on  their terminals.  This information helps alert
   them to instances of illegal system or account entry.  For example, if
   users  keep  track of their actual login times, they can compare those
   times to the ones displayed.  Then, if there is  a  discrepancy,  they
   will know the exact time that someone else logged into their directory
   using their password.

|  The system also provides login-failure information.
|  
|  Information  is  provided  for  both  interactive  and  noninteractive
|  logins.  An example of a noninteractive login is one for a batch job.

























                                   11-30
                              ACCESS CONTROLS


   11.5  PREVENTING FAST LOGINS

   By using the /FAST switch with the LOGIN  command,  users  can  bypass
   processing  of  the  system's  and  their own LOGIN.CMD and COMAND.CMD
   files.  Managers sometimes set up these command files to limit  users'
   computing  environments,  however.   For example, sets of users may be
   allowed only to read mail or run some other computer application.  You
   can prevent fast logins at your site by entering the following command
   in the n-CONFIG.CMD file:

   DISABLE FAST-LOGIN-OPTION

   The ENABLE FAST-LOGIN-OPTION command is in effect by default.  You can
   also enable and disable fast logins with the ^ESET privileged command.

   Refer to the TOPS-20 User's Guide for information on the LOGIN.CMD and
   COMAND.CMD files.  The TOPS-20 Commands Reference Manual describes the
   LOGIN command.

|  Also, with fast logins, system mail is not displayed, nor is notice of
|  new mail given.
|  
|  
|  
|  11.6  PREVENTING NOT-LOGGED-IN SYSTAT
|  
|  You can prevent people who are not logged in to a system from  finding
|  out  the  usernames  of  people  who  are logged in.  If your site has
|  public or network access, you  should  disable  not-logged-in  SYSTAT.
|  Enter the following command in the n-CONFIG.CMD file:
|  
|  DISABLE NOT-LOGGED-IN-SYSTAT
|  
|  This increases security by making it harder  for  intruders  who  have
|  connected  to  a  system  but  not  yet  logged  in  to find out valid
|  usernames for the system.  To allow the SYSTAT command when users  are
|  not logged in, enter the following command in the configuration file:
|  
|  ENABLE NOT-LOGGED-IN-SYSTAT















                                   11-31
                              ACCESS CONTROLS


|  11.7  SECURING FILES
|  
|  You and users can restrict access to files and  directories  according
|  to the type of access or the particular user who attempts access:  The
|  command @SET FILE [NO] SECURE sets a file "secure" or not secure,  and
|  the  commands @SET DIRECTORY and @BUILD cause all new files created in
|  the directory to be  set  secure.   (Refer  to  the  TOPS-20  Commands
|  Reference Manual for details on these commands.)
|  
|  When a request is made to access a "secure" file, the monitor asks the
|  ACJ  for  permission to open the file before the request is granted or
|  denied.  The ACJ bases its decision on the  information  contained  in
|  the  ACCESS.CONTROL  file,  which you or users create and place in the
|  same directory as files that are marked as secure.  This file contains
|  a  list  of  filenames,  access  keywords,  and  usernames  that  have
|  unrestricted access.  It is important that the ACCESS.CONTROL file  be
|  set secure so that it cannot be changed.
|  
|  The format of the ACCESS.CONTROL file is:
|  
|       filename keyword user, keyword user,...,-
|  
|       Where:
|  
|        o  filename is the name of the file to be set secure
|  
|        o  keyword determines the type of access  granted  to  users  of
|           secure files:
|  
|           ALL (all access)
|           APPEND (append access)
|           DELETE (delete access)
|           NOSECURE (permission to clear the SECURE bit)
|           READ (read access)
|           RENAME (permission to rename the file from or to filename)
|           SECURE (permission to set a file secure)
|           WRITE (write access)
|  
|        o  user is the user who is granted access
|  














                                   11-32
                              ACCESS CONTROLS


|  The following is a sample ACCESS.CONTROL file:
|  
|  ACCESS.CONTROL.*  READ Operator Staff.Mike Staff.Greg,-
|  SECURE Operator Staff.Mike Staff.Greg,-
|  WRITE Staff.Mike Staff.Greg,-
|  RENAME Staff.Mike Staff.Greg
|  
|  ACJ.EXE.*   READ Operator Staff.Greg,-
|  SECURE Operator Staff.Greg,-
|  WRITE Staff.Greg,-
|  NOSECURE Staff.Greg
|  
|  *.*.*   READ *,-
|  WRITE Staff.* Operator,-
|  SECURE Staff.* Operator,-
|  RENAME Staff.*,-
|  ALL Staff.Mike Staff.Greg Staff.Dave
|  
|  
|  
|  11.7.1  Secure Files and the ACJ
|  
|  To implement the secure-file feature, enable the  SECURE  policies  in
|  the  ACJ, as described in Section 11.1.3.1.  Refer to the descriptions
|  of ENABLE SECURE-CHFDB, ENABLE SECURE-DELF, ENABLE  SECURE-OPENF,  and
|  ENABLE SECURE-RNAMF.
|  
|  
|  
|  11.7.2  Securing Important Files
|  
|  It is recommended that you set secure those files that  are  sensitive
|  to  the  operation  and  health  of  the  system.   Such files include
|  MONITR.EXE.  The ACCESS.CONTROL files should also be set secure.




















                                   11-33
                              ACCESS CONTROLS


|  11.8  SECURITY HINTS
|  
|  Listed below are some general tips for enhancing the security of  your
|  TOPS-20 system.
|  
|        o  Usernames:  No username should  be  used  by  more  that  one
|           person at a time.  It is important that each person accessing
|           the system do so with a username uniquely  assigned  to  that
|           person.    Sharing  usernames  hampers  or,  in  some  cases,
|           prevents auditing of security problems.
|  
|        o  Capabilities:  Since a user with WHEEL or OPERATOR capability
|           has the power to change many aspects of system operation, the
|           WHEEL and  OPERATOR  capabilities  should  be  granted  to  a
|           minimum number of usernames on the system.
|  
|           A need to access files should be handled by the directory and
|           user   groups   structure   but   not  by  granting  OPERATOR
|           capability.
|  
|           Note that it is a particularly BAD idea to have one  username
|           with WHEEL or OPERATOR that a number of persons use.
|  
|        o  Backups:  A "system tape" (containing the monitor, exec, user
|           information, and system files from the boot structure) should
|           be created once a week.  Not only is this useful for hardware
|           failures,  but it can also provide a known secure copy of the
|           monitor and all other software running  on  the  system  with
|           enabled capabilities.
|  
|        o  FILES-ONLY directories:   Directories  on  the  system's  PS:
|           structure  that are not normally used for usernames should be
|           set FILES-ONLY.  This prevents usernames from being  created,
|           which can lead to security problems.
|  
|        o  OPERATOR  username:   Prevent  the  OPERATOR  username   from
|           logging   in   interactively  by  removing  or  expiring  its
|           password.  OPERATOR should be used to  run  jobs  needed  for
|           system  operator  (for  example,  jobs under SYSJOB or PTYCON
|           that are logged in when the system is reloaded).
|  
|           A password does not have to be set for OPERATOR in order  for
|           jobs to log in to OPERATOR under SYSJOB or PTYCON.  Operators
|           should use their own usernames to back up  the  system  areas
|           and  run OPR.  (The OPERATOR user can run DUMPER under PTYCON
|           to save the system areas.)
|  
|        o  Local Changes:  It is  important  not  to  underestimate  the
|           positive  effect  that a few minor site-specific changes have
|           on security.  Anything that makes your system just  a  little
|           different  will  slow down attempted break-ins.  For example,
|           change the ACJ log filename from the default.


                                   11-34











                                 CHAPTER 12

                           THE COMMON FILE SYSTEM



   12.1  OVERVIEW

   The Common File System (CFS) is a feature of TOPS-20 that allows users
   from  more  than  one  system  to  simultaneously  access  files.  Any
   structure in the CFS configuration can be made available to  any  user
   for reading or writing.

   Each TOPS-20 system in the CFS configuration  has  its  own  operating
   system,  main  memory, system structure, console, unit-record devices,
   and processes to be scheduled and run.  But  the  systems  are  linked
   through  a  shared  file  system.   This  unified  file  system can be
   composed of all the disk structures on all systems.  These  structures
   appear to users as local to their own systems.

   The main features of CFS are:

         o  It increases file accessibility.  For example, if a system is
            down  for  maintenance, users can log onto another system and
            still access all files that do not depend on the down  system
            for access.

         o  It lets you adjust loads on systems by reassigning  users  as
            loads  require.   (Or,  users  themselves  may  be allowed to
            switch systems as they  see  fit.)  These  changes  need  not
            result in file-access limitations.

         o  It lets you  reduce  the  time  that  would  be  involved  in
            maintaining duplicate sets of files.

         o  It lets you save disk  space  by  minimizing  duplication  of
            files on different systems.
|  
|  CFS (with Cluster GALAXY  software)  also  lets  users  send  jobs  to
|  printers connected to any system in the configuration.





                                    12-1
                           THE COMMON FILE SYSTEM


   12.1.1  CFS HARDWARE

   The following are typical CFS configurations:


               +--------------+                  +--------------+
               |              |                  |              |
    SYSTEM ----| DECSYSTEM-20 |-------DISK-------| DECSYSTEM-20 |-- SYSTEM
   STRUCTURE   |              |-------DISK-------|              |  STRUCTURE
               |       +------|                  +------+       |
               |       | CI20 |                  | CI20 |       |
               +--------------+                  +--------------+
                           \\                      //            
                            \\                    //
                             \\                  //
                              \\                //
                               \\              //
                                \\            //
                                 \\          //
                               +----------------+
                               |                |
                               |      STAR      |
                               |                |
                               |     COUPLER    |
                               |                |
                               +----------------+
                                 ||          ||
                                 ||          ||
                               +----------------+---DISK
                               |                |---DISK
                               |     HSC 50     |---DISK
                               |                |---DISK
                               +----------------+


   Figure 12-1:  Two Systems with Massbus Disks and HSC50-based Disks


















                                    12-2
                           THE COMMON FILE SYSTEM



               +--------------+                  +--------------+
               |              |                  |              |
    SYSTEM ----| DECSYSTEM-20 |-------DISK-------| DECSYSTEM-20 |-- SYSTEM
   STRUCTURE   |              |-------DISK-------|              |  STRUCTURE
               |       +------|-------DISK-------+------+       |
               |       | CI20 |-------DISK-------| CI20 |       |
               +--------------+                  +--------------+
                           \\                      //            
                            \\                    //
                             \\                  //
                              \\                //
                               \\              //
                                \\            //
                                 \\          //
                               +----------------+
                               |                |
                               |      STAR      |
                               |                |
                               |     COUPLER    |
                               |                |
                               +----------------+


   Figure 12-2:  Two Systems with Massbus Disks


   Star Coupler

   The star coupler provides the  physical  interconnection  for  the  CI
   cables among DECSYSTEM-20s and HSC50s.  The maximum distance between a
   system and the star coupler is 45 meters.

   A DECSYSTEM-20 can be connected to just one star coupler.  That is, it
   can be part of only one CFS cluster.


   CI

   The Computer Interconnect (CI) bus is the communications link used  by
   CFS.  It also connects systems to HSC50-based disks (RA60s and RA81s).
   In addition, it provides access to massbus disks for systems without a
   direct  connection  to  those  disks, for example, to another system's
   system structure.

   Each system has four communications links to the star coupler.  Two of
   them  are  for  transmitting  data and the other two are for receiving
   data.   The  redundant  CI  connections   are   used   for   increased
   availability  and performance.  When one of the connections has failed
   or is in use,  the  CI  microcode  chooses  the  other  one  for  data
   transmission.   At start-up, TOPS-20 verifies that at least one set of
   transmit and receive connections is working.


                                    12-3
                           THE COMMON FILE SYSTEM


   CI20

   The CI20 port adapter provides the interface between the  DECSYSTEM-20
   and the CI bus.  Only one CI20 is allowed per system.


   Massbus Disks

   Multisystem access may be granted to all massbus disks.

   It is  recommended  that  massbus  disks  intended  to  be  shared  be
   dual-ported  between  two DECSYSTEM-20s (drive port switches placed in
   the A/B position).  With a two-system CFS  cluster,  this  avoids  the
   overhead  involved in file-server activity, as described later in this
   section.  However, the systems must be able to communicate  with  each
   other  over  the  CI; they must be connected to the same star coupler.
   Otherwise, neither system will be allowed access to the  disk.   Thus,
   the following configurations are not supported:


               +--------------+                  +--------------+
               |              |                  |              |
               |     G        |                  |      H       |
               |              |-------DISK-------|              |  
               |              |       (A/B)      |              |
               |              |                  |              |
               +--------------+                  +--------------+







   +--------------+                  +--------------+    +--------------+
   |              |                  |              |    |              |
   |     G        |                  |      H       |    |     I        |
   |              |-------DISK-------|              |    |              |
   |              |       (A/B)      |              |    |              |
   |              |                  |              |    |              |
   +--------------+                  +--------------+    +--------------+
                                            |                    |
                                            |                    |
                                            |                    |
                                            |                    |
                                            |                    |
                                            |                    |
                                     --------------------------------- CI






                                    12-4
                           THE COMMON FILE SYSTEM




   +--------+    +--------+                  +--------+    +--------+
   |        |    |        |                  |        |    |        |
   |   G    |    |  H     |                  |    I   |    |     J  |
   |        |    |        |-------DISK-------|        |    |        |
   |        |    |        |       (A/B)      |        |    |        |
   |        |    |        |                  |        |    |        |
   +--------+    +--------+                  +--------+    +--------+
       |              |                          |              |
       |              |                          |              |
       |              |                          |              |
       |              |                          |              |
   ------------------------- CI               ------------------------ CI


   In the first two figures, systems G and H are  not  joined  in  a  CFS
   configuration.   The  same  applies  to  systems  H and I in the third
   figure.  TOPS-20 maintains the integrity of data on  shared  disks  by
   ensuring  that  the  systems  can, over the CI, coordinate accesses to
   those disks.

   Massbus disks not directly connected to a system  are  called  "served
   disks"   because   TOPS-20's  MSCP  (Mass  Storage  Control  Protocol)
   file-served facility makes this "outside" access possible.  To  enable
   an  outside path to a massbus disk, that is, to make it a served disk,
   enter an ALLOW command in the n-CONFIG.CMD file, on a system to  which
   the disk drive is connected, in the form:

   ALLOW <drive type> serial number

   The drive type is one of the following:  RP06, RP07, or RP20.  You can
   obtain the serial number with the command:

   OPR>SHOW CONFIGURATION DISK-DRIVE<RET>

   Note that TOPS-20 creates an RP20 serial number by adding 8000 to  the
   disk drive unit number.  Therefore, RP20 unit numbers should be unique
   among CFS systems.

|  To disallow access to a served disk that was allowed access, enter the
|  following command in the n-CONFIG.CMD file:
|  
|  RESTRICT <drive type> serial number
|  
|  Disks are RESTRICTED by default if you do not specify ALLOW commands.

                                    NOTE

           Disks that make up the system structure  must  not  be
           dual ported to another TOPS-20 system.



                                    12-5
                           THE COMMON FILE SYSTEM


   12.1.2  CFS SOFTWARE

   Intersystem communication is an integral part of  CFS.   When  TOPS-20
   starts  up, it makes a CFS connection with each TOPS-20 system that is
   already  running.   This  establishes  the   contact   necessary   for
   intersystem file-system management.

   In reality, only one system writes to a 256K section of a  file  at  a
   time.   When  a  system  needs  write  access  to  a  file section, it
   broadcasts  a  request  for  that  resource  to  all  systems  it  has
   established  contact with.  If another system already owns the desired
   write access, that system will respond negatively.  Clearance will  be
   granted  to  the  requesting  system  only  after the other system has
   completed the write operation by writing the data back  to  disk  from
   its  memory.   Thus,  systems  negotiate for write access to files and
   keep each other informed of the state of the disks  that  they  share.
   This ensures the integrity of data on those disks.

   Because intersystem communication is  vital  to  CFS  operations,  the
   systems  stay  alert to CI problems and to other indications that they
   may have lost contact with each other.  Section 12.11.1, Communication
   Problems,  discusses  the  actions  that  systems take when there is a
   breakdown in communications.

   The INFORMATION CLUSTER command displays the names of HSC50s  and  CFS
   systems that are currently accessible.

   DATE and TIME

   When a CFS system starts up, it takes  the  date  and  time  from  the
   systems  that  are  already running.  The operator is not prompted for
   this information.  Instead, the system types a message similar to  the
   following on the operator's terminal:

   The date and time is:  Wednesday, 11-MAY-1988 9:38AM

   This typeout serves as a check on the date  and  time.   If  no  other
   system is running, the operator is prompted for the information.

   When the date and time are changed on any CFS system, such as with the
   ^ESET  command,  all  other  systems  are  notified  so  that they can
   re-synchronize.  This synchronization ensures that the  creation  date
   and  time  of  files  written  from one system are consistent with the
   other CFS systems.  Otherwise, many programs that use this information
   could malfunction.









                                    12-6
                           THE COMMON FILE SYSTEM


   12.1.3  CFS USERS

   CFS is transparent to users:

         o  Users are normally unaware that someone from  another  system
            may  be  accessing  a  file  at  the same time that they are,
            except in such cases as the following.  A file being read  on
            system "A" will prevent its being renamed on system "B."

         o  Users are not required to know about the  CFS  configuration.
            Specifically,  they do not need to know how massbus disks are
            ported.  To access files, all they need to know are structure
            names, as on non-CFS systems.

   The INFORMATION CLUSTER  command  lets  users  know  what  HSC50s  and
   TOPS-20 systems are currently accessible to their systems.



   12.1.4  CFS and DECnet

   A CFS configuration differs from a DECnet  network.   Although  a  CFS
   configuration  comprises  multiple  independent  systems,  the systems
   share a unified file system and  cooperate  in  its  operation.   They
   function more as a single system than as systems merely communicating.
   If the optional DECnet-20  software  is  installed,  each  CFS  system
   running DECnet is a DECnet network node with its own node name.

   The files in CFS disk structures may be accessible to  remote  systems
   by  way  of  such  DECnet  facilities as NFT.  However, a node name is
   needed to access files in this way.  CFS users, on the other hand,  do
   not need to specify node names.

   All systems in a CFS configuration must  be  TOPS-20  systems.   In  a
   DECnet  network,  however,  other  systems  that support DECnet can be
   included.

   DECnet on a system allows access to other  CFS  clusters  as  well  as
   DECnet  communication  between systems in a cluster (for example, with
   the SET HOST command).














                                    12-7
                           THE COMMON FILE SYSTEM


   Table 12-1:  Comparison of CFS and DECnet


     __________________________________________________________________

     Characteristic                           CFS            DECnet
     __________________________________________________________________

     Multiple systems                         X              X

     TOPS-20 systems only                     X

     One file system                          X

     Node name in file spec                                  X

     DECnet software                                         X

     CI                                       X              X

     NI                                                      X
     __________________________________________________________________



   12.1.5  CFS and TIGHTLY-COUPLED SYSTEMS

   A  CFS  cluster  also  differs  from  tightly-coupled  multiprocessing
   environments.   Each  CFS system has its own main memory, which is not
   shared with another system.  It also has its own system structure  for
   booting and swapping and may have its own public structure for logging
   in.  Also, CFS systems do not perform automatic load balancing.   That
   is,  the  CPUs do not relieve each other of processing during high job
   loads.  All jobs, including batch jobs, run only on the computer  that
   the user logs onto.



   12.1.6  Limitations

   CFS does  not  coordinate  use  of  the  following  facilities  across
   systems:   IPCF  and  OPENF OF%DUD.  As an example, a DBMS application
   cannot span multiple systems,  because  DBMS  uses  the  OPENF  OF%DUD
   facility.   Therefore,  such  applications  should  be restricted to a
   single system.  Attempts to cross systems using these facilities  will
   generate error messages.

   CFS allows for shared disk files and line printers.  However, it  does
   not provide for shared magnetic tapes.





                                    12-8
                           THE COMMON FILE SYSTEM


   12.1.7  "Cluster Data Gathering"

   The "cluster data gathering" system application (CLUDGR) is enabled by
   default   in   the   n-CONFIG.CMD   file.    This   "SYSAP"   collects
   cluster-related data so that, for example:

         o  Users can obtain information on remote systems in the cluster
            by way of the SYSTAT command.

|        o  Users can send messages throughout the cluster with the  SEND
|           command.

         o  Operators can obtain scheduling information on remote systems
            (SHOW  SCHEDULER),  receive structure status information from
            system responses during remote structure dismounts, and  send
            messages to users throughout the cluster (^ESEND and SEND).

         o  System programmers can use the INFO% monitor call  to  obtain
            information  on  remote  cluster  systems.   (As described in
            Section 11.1, you can control access  to  the  INFO%  monitor
            call through the access control program.)

   You can disable and enable user, operator, and programmer CLUDGR SYSAP
   functions in the n-CONFIG.CMD file with the following commands:

   DISABLE CLUSTER-INFORMATION
   DISABLE CLUSTER-SENDALLS

   ENABLE CLUSTER-INFORMATION
   ENABLE CLUSTER-SENDALLS

                                    NOTE

           The CLUDGR SYSAP functions cannot be disabled for  the
           GALAXY components.

   During timesharing, the operator can disable  and  enable  these  same
   functions with the following privileged commands:

   ^ESET [NO] CLUSTER-INFORMATION
   ^ESET [NO] CLUSTER-SENDALLS



   12.1.8  Cluster GALAXY

   GALAXY is the TOPS-20 batch and spooling subsystem.  In a cluster,  it
   lets operators:

         o  Dismount a structure from a single terminal in a cluster even
            if  the  structure  is mounted on more than one system in the
            cluster.  The dismount with removal process is automated.


                                    12-9
                           THE COMMON FILE SYSTEM


         o  Mount structures on a remote system in the cluster.

         o  Set a structure exclusive from a single terminal in a cluster
            even  if  the  structure  has  been  mounted on more than one
            system in the cluster.  This process is automated.

         o  Send messages to all users on remote systems in the cluster.

|        o  Control cluster printers

         o  Obtain remote information through most of the SHOW commands.

         o  Obtain the status of inter-system GALAXY DECnet connections.

|  Cluster GALAXY lets users:
|  
|       1.  Send jobs to cluster printers
|  
|       2.  Receive information on remote print requests
|  
|       3.  Cancel remote print requests
|  
|       4.  Receive  notification  of  remote  print  job   queuing   and
|           completion

   "Cluster GALAXY"  requires  DECnet,  TOPS-20  version  7,  and  GALAXY
   version 6.

   You can disable cluster GALAXY on one or more systems by  way  of  the
   GALGEN  dialog.   This  dialogue  can  be  run  during or after system
   installation, and then GALAXY must  be  rebuilt.   However,  with  the
   feature  disabled,  none  of  the  remote  functions  listed above are
   available; the operating environment is as it was in GALAXY version 5,
   with   TOPS-20  version  6.1.   For  example,  to  dismount  a  shared
   structure, the operator had to give commands from a terminal  on  each
   system  on  which the structure was mounted, and there was not a great
   deal of remote information to help the operator with this activity.

   This chapter assumes that the feature is enabled.



   12.2  PLACEMENT OF FILES

   This section offers guidelines for arranging files on CFS systems  for
   maximum performance and efficiency.








                                   12-10
                           THE COMMON FILE SYSTEM


   12.2.1  Update Files

   Simultaneous shared writing to a file from multiple systems incurs the
   most  overhead  of  any  CFS  file  access operation.  This is because
   systems involved in shared writing spend  time  seeking  and  granting
   write   permission   and  coordinating  their  moves  in  other  ways.
   Therefore, you might want to place the  involved  users  on  the  same
   system.



   12.2.2  Files on Served Disks

   For optimum performance, you should not place on  served  disks  files
   that  require  frequent access from multiple systems.  This applies to
   both reads and writes.  MSCP file-server operations incur considerable
   overhead, because the system with the direct connection acts as a disk
   controller for the accessing system.   Therefore,  such  files  should
   reside  on  HSC50  disks  or,  in  a  two-system CFS configuration, on
   massbus disks dual ported between systems.



   12.2.3  Mail Files

   By default, users'  mail  files  are  created  and  updated  in  their
   logged-in  directories  on the public structure.  To access this mail,
   users log in and issue appropriate mail commands.  They may have to go
   through  this  login procedure for every system that contains mail for
   them.  You can change this default arrangement  and  simplify  matters
   for  the CFS user who has accounts on multiple systems.  By redefining
   the systemwide logical name POBOX:, as described in Section 3.3.9, you
   can  establish a central location on a sharable structure for all mail
   files in the CFS configuration.  Then, no matter where users  log  in,
   the  mail  facility  sees an accumulation of mail that could have been
   addressed to them at any system in  the  configuration.   Mail  is  no
   longer isolated on individual public structures.

   An added advantage to redefining POBOX:  is that public structures  do
   not fill up with mail files.

   You must create a directory on the structure defined  by  POBOX:   for
   every user in the CFS configuration who is to receive mail.











                                   12-11
                           THE COMMON FILE SYSTEM


   12.2.4  Sharing System Files

   Most of the files that normally reside on  system  structures  can  be
   moved  to  a  shared  structure.   Rather than duplicate files in such
   areas as SYS:  and HLP:  across systems, you can keep one set of these
   files on a shared structure.  This saves disk space and eases the task
   of maintaining the files.  Also, time and tape are saved during DUMPER
   backup  and  restore  operations.   Because system files are primarily
   read and not often updated, system performance does not suffer because
   of  this file sharing, provided the structure is not on a server disk.
   If  you  consolidate  system  files,  remember  to  include   in   the
   definitions  for  the  systemwide  logical  names  the structures that
   contain the files.  For example, if the  SYS:   files  reside  on  the
   structure COMBO:, the definition for SYS:  would be:

   DEFINE SYS: (AS) COMBO:<NEW-SUBSYS>, COMBO:<SUBSYS>,-<RET>
   MAIN:<NEW-SUBSYS>, MAIN:<SUBSYS><RET>

   where:

            MAIN:  is the name of a system structure

   You should define structures in this way on all  the  systems,  giving
   the  appropriate  system  structure  name.   Make sure that the shared
   structure or structures are mounted UNREGULATED so that users will  be
   able to access the files without having to give a MOUNT command.

   The drawback to sharing system files is that if there is trouble  with
   the shared structure, users on all systems suffer.

   Most of the SYSTEM:  files must remain on the  system  structures,  so
   sharing these files is not recommended.


   START-UP FILES

   Certain files must remain on each system structure.  These  files  are
   involved  in  system  start-up  and  are  required before a non-system
   structure is made available to a system.  The following  files  should
   remain in each <SYSTEM> area:

   7-CONFIG.CMD
   7-PTYCON.ATO
   7-SETSPD.EXE
   7-SYSJOB.EXE
   7-SYSJOB.RUN
   ACCOUNTS-TABLE.BIN
   CHECKD.EXE
   DEVICE-STATUS.BIN
   DUMP.EXE
   ERRMES.BIN
   EXEC.EXE


                                   12-12
                           THE COMMON FILE SYSTEM


   HOSTS.TXT
   IPADMP.EXE
   IPALOD.EXE
   KNILDR.EXE
   MONITR.EXE
   MONNAM.TXT
   TGHA.EXE

   In addition, all the GALAXY files should remain in each <SUBSYS> area.
   These  files  come from the GALAXY saveset on the TOPS-20 Distribution
   Tape.  (Refer to the TOPS-20 KL Model B Installation Guide.)

   Command files that are used at your installation during start-up  also
   should  be  kept  on  separate system structures.  These files include
   SYSTEM.CMD and NETWORK.CMD.



   12.3  LOAD BALANCING

   This section discusses the distribution of jobs across CFS systems.



   12.3.1  Dedicating Systems

   One way to balance loads is to establish the types of jobs  that  will
   run on particular systems.  For example, you might relegate batch jobs
   to  one  system,  freeing  other  systems  to  run  interactive   jobs
   unimpeded.   To  encourage  users to adopt this arrangement, you could
   give batch jobs the lowest priority on all  but  the  batch-designated
   system.  Users will have to wait a relatively long time for completion
   of batch jobs on non-batch systems.  Refer to Section 10.2, SCHEDULING
   LOW PRIORITY TO BATCH JOBS, for further information.

   Conversely, on the batch system,  you  could  accord  batch  jobs  the
   highest  priority.  Refer to Section 10.1.4, Procedures to Turn On the
   Class Scheduler, for details.  Dedicating a system in this  manner  is
   especially  useful  when  there are many long-running batch jobs at an
   installation.

   Another suggestion is to put software development jobs on  one  system
   and production jobs on another.  Also, you may want to keep one system
   lightly loaded for critical jobs.

   DBMS  applications  and  programming   applications   requiring   IPCF
   facilities  must  be confined to one system.  These are other items to
   consider if you  choose  to  establish  certain  uses  for  particular
   systems.

   Keep in mind that users must log onto the  systems  that  are  to  run
   their  particular  jobs.   This  applies  to  batch jobs also (without


                                   12-13
                           THE COMMON FILE SYSTEM


   DECnet).  Batch jobs must be submitted by a  user  logged  in  on  the
   system where they are to run.  The control and log files may reside on
   shared disks.



   12.3.2  Assigning Users to Systems

   In the CFS environment, much of the load balancing is expected  to  be
   performed  by users.  The systems, for example, do not detect that one
   CPU is  overburdened  and  that  another  one  is  underutilized  and,
   accordingly,  reassign  users'  jobs.  Instead, users themselves could
   determine whether or not they should log off a  system  and  log  onto
   another  one  when  system  response  is slow.  Such user tools as the
   SYSTAT and INFORMATION SYSTEM commands and  the  CTRL/T  function  can
   help users in this area.  These tools report on the current state of a
   system.  Among the items reported are the number of jobs running on  a
   system, load averages, the current setting of the bias control "knob,"
|  and whether  batch  jobs  are  assigned  to  a  special  class.   This
|  information  can be obtained for all systems in the configuration, not
|  just for the user's logged-in system.

   If  you  choose  this  load  balancing  scheme,  you   should   create
   directories  for  all  users  on  all the system structures in the CFS
   configuration.  Also, directory usernames should be unique  throughout
   the  configuration,  as described below.  Then, users can log onto any
   system with no problem.

   USERNAMES

   Directory usernames should be unique throughout the CFS configuration.
   For  example,  there should be only one user with the username <BROWN>
   at an installation.  This lets users access system  resources  without
   encountering password-related obstacles or causing security breaches.

   If two  users  on  different  systems  have  the  same  usernames  but
   different  passwords, their passwords will be invalid when they switch
   systems.   If  these  same  users  should  by  chance  have  the  same
   passwords,  they  will have complete access to each other's files when
   they switch systems.  Also, if a structure is mounted on both  systems
   as  domestic, neither user will have to give a password when accessing
   the directory on that structure that has their  username.   (Refer  to
   Section  4.5.7,  Mounting  Structures from Another Installation, for a
   discussion of foreign and domestic structures.)

   DIRECTORY AND USER GROUPS

   To facilitate user access to CFS files, you could make  directory  and
   user  group  numbers  consistent  on  all structures.  That way, users
   could change structures or systems and  their  access  attempts  would
   have predictable outcomes.



                                   12-14
                           THE COMMON FILE SYSTEM


   12.4  STRUCTURE NAMES

   Because the structures on all systems  are  part  of  a  unified  file
   system,   structure   names   must   be   unique  throughout  the  CFS
   configuration.

   If it is necessary to  mount  structures  with  duplicate  names,  the
   operator should mount one of the structures using an alias.  (Refer to
   Section 4.5.2, Mounting Structures Having the Same Name.)  The  system
   recognizes  a  structure  by  its  alias,  which  is  the  same as the
   permanent structure identification name, unless  otherwise  specified.
   Note  that  everyone  throughout the CFS configuration must refer to a
   structure by the same alias.



   12.5  SYSTEM LOGICAL NAMES

   Logical names are implemented differently  from  structure  names  and
   their  aliases.   Logical names are local definitions that need not be
   unique nor consistent throughout the  CFS  configuration.   Thus,  the
   same logical name on two different systems can refer to two completely
   different disk areas.  However, because users are likely to be mobile,
   systemwide  logical  names  should be consistent across systems.  This
   will avoid confusion for users who switch systems.

   Refer to Section 3.3, SYSTEM-LOGICAL NAMES, for further information.



   12.6  SHARING STRUCTURES AMONG SYSTEMS

   By default, all structures in the CFS configuration are accessible  to
   all  systems, provided outside paths have been established for massbus
   disks where necessary, using  the  ALLOW  command  (refer  to  Section
   12.1.1,  CFS HARDWARE).  It is necessary to "mount" a structure on any
   system that is to access files on it, however.  That is, the  operator
   or a user on that system must issue a MOUNT command for the structure.
|  (There can be up to 64 structures  online  on  one  system.)  After  a
   structure  is  mounted  on a system, users can access it as on non-CFS
   systems.  Users have automatic access to their public structure files,
   as on non-CFS systems.

   If a structure has been restricted to a system through previous use of
   the  operator  command,  SET STRUCTURE str: EXCLUSIVE,  it can be made
   sharable  again  with  the  SET STRUCTURE str: SHARED  command.    The
   operator issues this command from a terminal running OPR on the system
   that has exclusive use of the structure.  Then, MOUNT commands can  be
   issued  for  the  structure  that has been made sharable.  The default
   setting for structures is sharable.




                                   12-15
                           THE COMMON FILE SYSTEM


   The operator command, SHOW STATUS STRUCTURE, indicates the  shared  or
   exclusive status for all structures known to a system.

   STRUCTURE ATTRIBUTES

   The operator  specifies  attributes  for  a  structure  with  the  SET
   STRUCTURE  command,  as  described  in  the TOPS-20 Operator's Command
   Language Reference Manual.  They are permanent settings  that  do  not
   revert to default values after system crashes and reloads.

   Note that all systems need not have the same attributes in effect  for
   a  structure.  For example, one system can have a structure mounted as
   foreign and regulated, and another system can have the same  structure
   mounted as domestic and unregulated.  Except for SHARED and EXCLUSIVE,
   attributes are on a single-system basis only.



   12.6.1  Sharing System Structures

   Bear in mind that when system structures are shared, privileged  users
   can  create  privileged  accounts  on  any  system structure, with the
   ^ECREATE command.  This may or may not be desirable.



   12.6.2  Sharing the Login Structure

   In a CFS-20 cluster, it may be advantageous to set  up  a  homogeneous
   environment  where  all  user  accounts  reside  on  a  shared  "login
   structure".  Then, you do not need to maintain  an  account  on  every
   system to which a user has access.



   12.6.2.1  Creating  the  Login  Structure - To  create   this   shared
   structure,  give the following command to the CHECKD program for every
   system in the cluster:

   CHECKD>ENABLE LOGIN-STRUCTURE(FOR STRUCTURE)str:(FOR CPU)cpu<RET>

   where:  str is the name of the login structure and cpu is the system's
   CPU serial number.  The default serial number is the current system's.

   This command adds the CPUs' serial numbers to  the  login  structure's
   home  blocks.   The  following command displays all the serial numbers
   that were entered into the blocks:







                                   12-16
                           THE COMMON FILE SYSTEM


   CHECKD>SHOW (INFORMATION  FOR)  LOGIN-SERIAL-NUMBERS  (FOR  STRUCTURE)
   str:<RET>

   where:  str is the name of the login structure

   You should create a directory on this structure for each user  in  the
   cluster.   (You  can also put any other kind of directory on the login
   structure.) Users' LOGIN.CMD files and their .INIT files  for  various
   system programs should reside in these directories.



   12.6.2.2  Enabling  "Login  Structure" - The  system  looks  for  user
   accounts on the login structure rather than on the boot structure when
   you enter the following command in the n-CONFIG.CMD file:

   ENABLE LOGIN-STRUCTURE



   12.6.2.3  Disabling "Login Structure" - You  can  disable  the  "login
   structure" feature with the following commands:

   n-CONFIG.CMD file:

   DISABLE LOGIN-STRUCTURE

   CHECKD program:

   CHECKD>DISABLE LOGIN-STRUCTURE(FOR STRUCTURE)str:(FOR CPU)cpu<RET>

   where:  str is the name  of  the  shared  structure  and  cpu  is  the
   system's  CPU serial number.  The default serial number is the current
   system's.

   These commands cause the system to look for user accounts on the  boot
   structure, which is the default condition.



   12.6.2.4  PS:  and BS:  Directories - Before  you  enable  the  "login
   structure"  feature,  the public structure (PS:) is the boot structure
   (BS:), and is also known as the system structure.

   After you enable the feature, the system  considers  PS:   to  be  the
   login  structure,  the  structure  that  contains  all  the user login
   directories.







                                   12-17
                           THE COMMON FILE SYSTEM


   The special system directories, described in Section 3.2, must  remain
   on  BS:,  although you may choose to move many of their files to other
   directories.  However, the files listed in Section 12.2.4 must  remain
   on the boot structure in <SYSTEM>:

   Also, the GALAXY components write files to SPOOL:,  which  the  system
   defines at startup to be BS:<SPOOL>.

                                    NOTE

           Except where noted, this manual assumes that you  have
           not enabled the "login structure" feature.



   12.7  RESTRICTING STRUCTURES TO ONE SYSTEM

   There may be times when you want to restrict use of a structure  to  a
   particular   system.    Such  a  structure  might  be  used  for  DBMS
   applications (refer  to  Section  12.1.6,  Limitations),  or  security
   measures  may  call  for  restricted  use.   For  whatever reason, the
   operator restricts a structure with the following command:

   OPR> SET STRUCTURE str: EXCLUSIVE<RET>

   When the operator gives this command, the system first checks  to  see
   that  the  structure  is  not  in use on other systems.  If it is, the
   operator is given a list of those systems and  asked  whether  or  not
   this  system  should  proceed with an automatic remote dismount of the
   structure from those  systems  (with  the  NO-REMOVAL  option).   This
   information  and  automatic  dismount  requires  cluster  GALAXY to be
   enabled.  Ideally, the operator should beforehand  follow  the  normal
   dismount  procedure  of  making the structure unavailable to new users
   and notifying existing users of the pending dismount.   The  structure
   should be kept unavailable for all systems except the exclusive one so
   that the structure will not be inadvertently shared  when  the  owning
   system crashes.

   After a structure has been dismounted  from  other  systems,  the  SET
   STRUCTURE  EXCLUSIVE command can take effect.  It remains in effect on
   the system, as do all SET STRUCTURE specifications, throughout crashes
   and  reloads.  If users give the MOUNT command for a structure that is
   exclusive  to  another  system,  an  error  message  will  be  issued,
   indicating that the structure is unavailable.

   Note that any system can have exclusive use of any sharable  structure
   except another system's system structure.

   Refer  to  the  TOPS-20  Operator's  Guide  for  details  on   setting
   structures exclusive.




                                   12-18
                           THE COMMON FILE SYSTEM


   12.8  DISMOUNTING STRUCTURES

   When issuing a DISMOUNT command for a structure,  operators  have  the
   option  of  specifying that the structure be physically removed from a
   disk drive.  In the CFS environment, however, the system first ensures
   that  the structure is not in use on other systems.  If a structure is
   mounted on another system,  the  operator  is  notified  and  must  go
   through  the  normal  procedure of dismounting the structure (with the
   NO-REMOVAL option) from that system.

   Note that with cluster  GALAXY  enabled,  the  operator  can  dismount
   structures  remotely by performing all activities from an OPR terminal
   on the local system.  The operator does not need to log onto any other
   system.

   Throughout  the  dismount  process,  the  operator  receives   various
   informational  messages as well as error messages if, for example, the
   system cannot get an exclusive lock on the structure  by  way  of  the
   ENQ%  monitor call or communicate with nodes on which the structure is
   mounted.  (The system cannot communicate  with  nodes  that  have  the
   cluster GALAXY feature disabled.)

   Refer to the TOPS-20  Operator's  Guide  for  details  on  dismounting
   structures.

   The default setting on CFS systems is for a structure to be dismounted
   with the no-removal option.

   Sometimes the system instructs the operator  to  dismount  structures.
   This can occur for the following reasons:

         o  The operator attempts to shut down a system.

         o  The operator attempts to make the CI unavailable to a system.
|  
|        o  A system has been granted exclusive use of a structure.
|  
|        o  A structure  has  been  physically  dismounted  from  another
|           system.
|  
|  Refer to Sections 12.7, 12.9, and 12.12 for details.
|  
|  These dismount instructions appear if you  have  included  the  ENABLE
|  JOB0-CTY-OUTPUT command in the n-CONFIG.CMD file.










                                   12-19
                           THE COMMON FILE SYSTEM


   12.9  MAKING THE CI UNAVAILABLE TO A SYSTEM

   Ordinarily, you need do nothing at all to operate  the  CI.   However,
   you  may  need  to  disengage  a  system  from the CI so Field Service
   personnel can diagnose and/or correct problems with the  CI20  or  the
   HSC50.    Or,   you   may  wish  to  remove  a  system  from  the  CFS
   configuration.  At those times, you should instruct  the  operator  to
   make  the  CI  unavailable  by  means  of  the SET PORT CI UNAVAILABLE
   command.  (Refer to the TOPS-20 Operator's Guide for details.)

   When  the  CI  is  unavailable  to  a  system,  users  cannot   access
   multi-access  disks  (dual-ported  disks, HSC50-based disks, or served
   disks on other systems).  These disks rely on  the  CI  to  coordinate
   accesses  and/or  to  transmit  data.   Served  disks  on  the  system
   disengaging  from  the  CI  will  be  unavailable  to  other  systems.
   Dual-ported  massbus disks in the A/B position will have to be powered
   down and switched to one system.

   When the operator gives the  SET  PORT  CI  UNAVAILABLE  command,  the
   system  indicates  the  structures  that need to be dismounted and the
   disk drives that need to be made unavailable.  The operator is advised
   to   follow   the   normal  procedures  of  forewarning  users  before
   dismounting  structures  and  making  disk  drives  unavailable.   The
   command  option  to  forcibly disengage a system from the CI should be
   reserved for emergencies.  If the operator determines that disengaging
   from  the  CI  will  be  too disruptive to users, the operator has the
   option of aborting the procedure.

   To put the CI back in operation, the operator gives the command:

   OPR>SET PORT CI AVAILABLE<RET>

   The operator is then asked if any other TOPS-20 system is  running  on
   the  CI.   If  yes, the system rejoining the CFS configuration must be
   rebooted.  If no, the CI20 will  be  reloaded  and  started.   If  the
   operator  answers  "no"  and another TOPS-20 system is found after the
   CI20 has started, a CFRECN BUGHLT is issued on processors  with  lower
   serial  numbers  than  the  system  joining  the  cluster  and on this
   processor also, if there's a system  in  the  cluster  with  a  higher
   serial  number.   (See  Section 12.11.1 for details.) After the system
   rejoins the configuration, structures that were affected when  the  CI
   was made unavailable will need to be remounted.



   12.10  USING DUMPER

   CFS offers operators and users flexibility  in  saving  and  restoring
   disk  files.  The only restriction is that DUMPER must be running on a
   system to which tape drives are attached.  Tape drives are not  served
   through CFS.



                                   12-20
                           THE COMMON FILE SYSTEM


   12.11  ERRORS

   This section discusses the actions  you  or  the  operator  take  when
   errors  occur  in  the  CFS  environment.   It  also describes how CFS
   systems react to  various  errors.   Note  that  there  is  no  single
   hardware  or  software point that can disable the whole configuration.
   For example, systems can start up or crash with little impact on other
   systems.



   12.11.1  Communication Problems

   CFS systems are sensitive to breaks in communication, whether they are
   caused  by  CI20 errors or system crashes.  Because the data integrity
   of shared structures depends  on  unbroken  intersystem  contact,  the
   systems  take quick action to prevent data corruption.  Therefore, you
   may observe any of the following when systems lose contact  with  each
   other.  These should be rare occurrences.

         o  For a period of time calculated as 5 seconds per node  (hosts
            and  HSCs),  no  system  in  the configuration can access any
            multi-access disks  (dual-ported  disks,  HSC50-based  disks,
            served disks on other systems).

            This interval allows each system to check that its  own  CI20
            and  segment  of  the  CI bus are working.  Most likely, some
            system's CI20 microcode  has  stopped  and  is  automatically
            reloaded  during  the  interval,  or  a  system  has crashed.
            (There  may  be   other,   unpredictable   reasons   for   CI
            disruption.)  Jobs that were accessing multi-access disks are
            suspended until data integrity is assured.

            If the CI20 and CI bus are working  before  the  end  of  the
            interval,  the  system  can resume accessing all multi-access
            disks except server disks on a crashed system.

         o  A system crashes with a KLPNRL BUGHLT.  This happens  if  the
            CI20  microcode takes longer to reload than 10 seconds.  This
            BUGHLT is expected to occur  rarely,  because  the  microcode
            should be reloaded within a couple of seconds.













                                   12-21
                           THE COMMON FILE SYSTEM


         o  If communication resumes after the interval mentioned at  the
            beginning  of  this section, without the faulty system having
            crashed and restarted,  the  system  with  the  lower  serial
            number  crashes  with  a  CFRECN BUGHLT message as the faulty
            system tries to establish contact with each  running  system.
            That  is,  a  system joining the cluster illegally will crash
            any system already in the cluster with  a  lower  CPU  serial
            number.   The  node  itself  will crash if there is already a
            node in the cluster with a higher  CPU  serial  number.   For
            example,  this  occurs when the SET PORT CI AVAILABLE command
            has  caused  communication  to  resume  incorrectly  due   to
            operator  error,  as described in Section 12.9, MAKING THE CI
            UNAVAILABLE TO A SYSTEM.

            With such a delayed  reconnection,  a  system  is  likely  to
            contain   old,   invalid  information  about  the  status  of
            multi-access  disks.   This  is  because  other  systems  are
            allowed  to  access the disks after the interval, believing a
            faulty system is no longer running.  Therefore,  systems  are
            selected to crash so that a fresh database can be established
            for the disks when the systems restart.

            EXAMPLE

            There are four systems in a cluster with serial  numbers  one
            through four:

                System                Serial Number

                   A                                            1
                   B                                            2
                   C                                            3
                   D                                            4

            System B leaves the cluster and then tries  to  rejoin  after
            the  delay  allowance  has expired.  System A crashes because
            its serial number is lower than system B's.  System B crashes
            when  it  tries to establish contact with either systems C or
            D, whose serial numbers are higher than B's.  Systems C and D
            remain running.














                                   12-22
                           THE COMMON FILE SYSTEM


   AT STARTUP

   Sometimes, communication problems begin at system startup.   A  system
   that has just started up tries to communicate with each TOPS-20 system
   and HSC that is already running.  After the SETSPD  program  sets  the
   systemwide  defaults,  a system joining the CFS cluster checks to make
   sure that:

         o  Its own CI20 is working.  If there is  any  malfunction,  the
            "CFS  joining"  process  is  aborted.   The  system  makes no
            further attempts to communicate  with  other  CFS  nodes  and
            remains outside the CFS cluster.

         o  Its segment of the CI bus is working.

   If the areas above are  satisfactory,  the  system  starting  up  then
   checks to see if, for each cluster node:

         o  The CI20 at the remote node is in maintenance  mode  (TOPS-20
            nodes  only,  not  HSCs).   If  so,  the system knows that it
            cannot communicate with that  node  and  tries  to  establish
            contact with the next node.

         o  Its own CI20 driver has created a system block for the remote
            node.   The  driver creates this block when the remote system
            responds to its request for recognition.   The  system  block
            allows  for  a  virtual circuit to be established between the
            two systems, over which inter-node data and messages are sent
            on the CI.  If the block does not yet exist, the system sends
            a  message  to  the  CTY  so  that  the  operator  can   take
            appropriate  action  on  the  remote  node.   This  situation
            usually indicates a hardware problem with the remote system's
            CI20.

   If a system block has been created for  a  remote  TOPS-20  node,  the
   system  tries  to  establish a CFS connection with that node by way of
   the virtual circuit.  It  is  through  CFS  connections  that  systems
   communicate  in  order  to  coordinate access to shared disks.  If the
   attempt fails, a message is sent to the CTY for operator action.  This
   situation  usually  indicates  a  software  problem,  most likely that
   TOPS-20 is not running at the remote node.

|  If the attempt at communication is successful, a confirming BUGINF  is
|  sent to the starting system's CTY.

   A system starting up makes these communication checks for every  other
   node in the cluster.

   Refer to the TOPS-20 Operator's Guide  for  details  on  the  operator
|  information and error messages.




                                   12-23
                           THE COMMON FILE SYSTEM


   12.11.2  Massbus Problems with Dual-Ported Disk Drives

   Dual-ported disk drives  are  accessed  by  each  system  through  the
   massbus  hardware  connections.  However, if for some reason a massbus
   path becomes unavailable to a system, the other system,  with  working
   massbus  connections,  can provide access to the drives affected, with
   the MSCP file server.  The disks become "served."

   The operator enables this facility by  powering  down  the  disks  and
   flipping the drive port switches from the A/B position to the position
   that corresponds to the servicing  system.   Then  the  operator  must
   reboot  the system with the faulty massbus link.  These procedures are
   required because a running system will never invoke  the  MSCP  server
   after  identifying  a  massbus path for a disk.  It is assumed that an
   ALLOW command has been entered in the n-CONFIG.CMD file for  the  disk
   drives, as described in Section 12.1.1, CFS Hardware.

   The operator returns the switches to the A/B position when the massbus
   problem  is  corrected.   The  PHYTPD BUGINF is then issued to confirm
   that the massbus will now be used for data transmission.



   12.12  SHUTTING DOWN A CFS SYSTEM

   When an operator issues the ^ECEASE command to  shut  down  a  system,
   outside  jobs  that  may be accessing the system's served disks do not
   hang, with the following procedure.  If any  served  disks  have  been
   mounted  from other CFS systems, the operator is warned to check those
   systems for possible structure dismounting instructions.

   At the other systems, meantime, if any served disks are mounted on the
   system  shutting  down, the operator is warned of the pending shutdown
   and is advised to dismount the structures listed.

   In a CFS-20 cluster, a shutdown on one  system  causes  "system  going
   down"  messages to be transmitted to all systems in the cluster at the
   sixty-minute, five-minute, and one-minute marks.  For example, if SYSA
   is shutting down, the following messages appear clusterwide:

   [System SYSA going down in 60 minutes at 1-Dec-87 16:29:22]

   [System SYSA going down in 5 minutes at 1-Dec-87 16:29:22]

   [System SYSA going down in one minute!!]









                                   12-24











                                 CHAPTER 13

                            LAT TERMINAL SERVERS



   13.1  OVERVIEW

   A local area network is a collection of computers and their  resources
   that are linked together in a small geographic area, such as a college
   campus or a large  building.   Local  Area  Transport  (LAT)  software
   enables  special-purpose  computers  to be used as terminal servers in
   such a network.  With LAT software,  user  and  application  terminals
   that   would   otherwise   be   individually  wired  to  host  systems
   (DECSYSTEM-20s, for example) are instead connected directly to  a  LAT
   terminal  server.  The server, in turn, is linked to one or more hosts
   by way of the Ethernet  Network  Interconnect  cable  (NI),  as  shown
   below:


                         +-------+          +-------+
                         |  LAT  |          |  LAT  |
                         |  HOST |          |  HOST |
                         |       |          |       | 
                         +---0---+          +---0---+
                             |                  |
                             |                  |
                             |                  |
       NI ===================0==================0============0=======
                                                             |
                                                             |
                                                             |
                                                         +---0---+
                            Application Terminal  -------|  LAT  |
                                   User Terminal  -------|SERVER |
                                   User Terminal  -------|       |
                                                         +-------+


   Figure 13-1:  A LAT Network


   A LAT host might be a TOPS-20, VMS, or RSX-11 system.  The LAT  server


                                    13-1
                            LAT TERMINAL SERVERS


   is any NI-based terminal server.

   An  application  terminal  is  a  device  under  the  control  of   an
   application  process  on  the  host.   A  printer  is an example of an
   application terminal.  An application process such as LPTSPL  requests
   a  connection  to the LAT server when users want access to the device.
   The type of application terminal referred to in this manual is  a  LAT
   printer.  Section 3.7 contains further information on LAT printers.

   The main features of LAT servers are:

         o  Users can connect to  any  NI  host  that  supports  the  LAT
            protocol,  and  it  appears to them that their terminals have
            direct connections to those hosts.  Connections  between  LAT
            terminal  users  and hosts are called sessions.  There can be
            up to 128 sessions on a TOPS-20 host.

         o  By requesting multiple host connections, a LAT terminal  user
            can  enable multiple sessions at one host or at several hosts
            simultaneously.  With one keystroke, such  users  can  switch
            between their jobs on these systems.

         o  LAT servers can balance user loads among hosts according to a
            rating system that you set up.

         o  Users  throughout  the  network  can  share  LAT  application
            terminals.   An LN03 printer on a LAT server, for example, is
            not restricted to local host use.

   Note that LAT software runs on host systems as well as on LAT servers.
   This  chapter  discusses  how  to  control  LAT  host  software from a
   DECSYSTEM-20.  You can also issue commands directly to a LAT  terminal
   server.   Refer  to  the documentation provided with your LAT terminal
   server hardware for details on those commands.



   13.2  LAT SOFTWARE

   Each host that supports the  LAT  protocol  for  interactive  terminal
   service periodically broadcasts this fact to all LAT terminal servers.
   Each server maintains a list of hosts that have sent such messages.  A
   terminal  user  can issue a command to the server to display this list
   to see which hosts are accessible.

   The logical path between a LAT host and server is called a LAT virtual
   circuit.   There is one virtual circuit for each server/host pair that
   has at least one  active  terminal  session.   When  a  terminal  user
   requests  a connection to a host, the server creates a virtual circuit
   to that host if none exists.  Otherwise an already existing circuit is
   used  for  data  transmission.   As system manager, you can decide the
   maximum number of virtual circuits that can  exist  at  a  host.   The


                                    13-2
                            LAT TERMINAL SERVERS


   number that you decide upon can affect system performance.  This topic
   is discussed in Section 13.4.

   Virtual circuit messages are transmitted between host  and  server  at
   periodic intervals determined by a circuit timer maintained in the LAT
   server.  When the timer expires, the server assembles  into  a  single
   virtual  circuit  message  any terminal input received during the past
   interval for a particular host and transmits it to the host.  You  can
   set  this  timer only at the server.  It has a recommended value of 80
   milliseconds, which is the default.

   The data associated with  a  particular  terminal  are  grouped  in  a
   virtual  circuit  message  in  units  called slots.  A virtual circuit
   message may contain slots from many terminals  and  may  contain  more
   than  one  slot from a single terminal.  The maximum size of a slot is
   another parameter that you can set.

   Having received a virtual circuit message, the host assembles as  much
   terminal  output  data as possible into a single message and transmits
   it to the server.  If no output is waiting for any  terminal  at  that
   server,  a message is sent with no slots.  The host's response message
   acknowledges the previously received message from  the  server.   This
   message  will be acknowledged by the server message transmitted at the
   next tick of the circuit timer.

   To reduce NI utilization and load on the host, the server transmits  a
   message  only  when  there is something to send.  It could happen that
   when the server has no data to transmit, there is more terminal output
   data  waiting  at the host.  But because the last host message remains
   unacknowledged, output flow  from  the  host  would  stop.   For  this
   reason, the host is permitted to transmit one "unsolicited" message to
   the server.  (Refer to the description of the  HOST  RETRANSMIT  TIMER
   dynamic  parameter  in  Section  13.4 for additional information.) The
   host sets a flag in the message, which forces the server to respond at
   the   next   tick  of  the  circuit  timer.   This  "forced"  response
   acknowledges  all  the  host's  previously  transmitted  messages  and
   returns all transmit buffers so that they may be used again.

   The host maintains a circuit  timer  with  a  default  interval  of  1
   second.   (You can set it up to 2 seconds.) The function of the host's
   circuit timer differs from that of the server's circuit timer:  it  is
   used   solely   as  a  retransmit  timer.   When  the  host  sends  an
   "unsolicited" message, as  described  above,  it  starts  its  circuit
   timer.  Because the server's circuit timer is shorter than the host's,
   the server should have acknowledged all outstanding host messages well
   before  the  host's  timer expires.  If this does not happen, the host
   retransmits all unacknowledged messages.  This continues until  either
   the  server  responds with an acknowledgement, or the retransmit limit
   is reached.  If the retransmit limit is reached, the host assumes  the
   connection  to  the  server  is no longer useable and detaches all LAT
   jobs from  that  server.   (Refer  to  the  description  of  the  HOST
   RETRANSMIT  TIMER  and the HOST RETRANSMIT LIMIT dynamic parameters in


                                    13-3
                            LAT TERMINAL SERVERS


   Section 13.4.)



   13.3  DECNET

   LAT, for the most part, is independent of DECnet.  It does not require
   DECnet  for  general  operations.   However,  DECnet is required on at
   least one host for start-up of LAT servers.  Software from a  host  is
   loaded  into the server's memory by DECnet's Network Management.  This
   "down-line loading" of LAT servers occurs  when  the  operator  either
   physically  boots  the  server  or  triggers  a  boot of the server by
   issuing a DECnet command from a host running DECnet.  In either  case,
   any host that has DECnet and the appropriate load files may respond to
   the boot, and then be selected by  the  server  to  load  its  memory.
   DECnet  is  also  needed for "dumping" files of LAT memory images to a
   host for problem diagnosis on the host.  Refer to the DECnet-20/PSI-20
   System Manager's Guide for the operator procedures involved in loading
   and dumping LAT servers.

   If a system supports DECnet, its node name and number are taken to  be
   the  LAT  name  and number also.  You do not need to respecify them in
   the n-CONFIG.CMD file.  Refer to the discussion of  static  parameters
   in Section 13.4.



   13.4  CONTROLLING LAT FROM THE HOST

   There are three ways for you or the operator or a system programmer to
   control LAT from a host:

         o  By rebuilding the monitor with new permanent parameters.

         o  By changing static parameters in the n-CONFIG.CMD file

         o  By changing dynamic parameters with the LAT  Control  Program
            subsystem of the OPR program

   The lists below briefly describe these parameters.  Many are discussed
   more fully later.

   Note that you can also control LAT from the server itself.   Refer  to
   the documentation that came with your LAT server for details on server
   commands.


   Permanent Parameters

   Normally, you do not need to change permanent parameters.   To  change
   them, a system programmer familiar with monitor internals must rebuild
   the monitor.


                                    13-4
                            LAT TERMINAL SERVERS


         o  FRAME SIZE - The  host  or  server  guarantees  that  it  can
            receive  NI datagrams of at least this size.  Usually three (
            2 transmit and 1 receive) buffers of this size are  used  for
            each  LAT circuit.  The default and recommended value is 1504
            bytes.

         o  MAXIMUM HOST SERVICES - Sets the maximum number  of  services
            that  this  host  can  offer.   You  can  specify  up  to 254
            services.  The default and recommended maximum is  8.   Refer
            to Section 13.7, HOST SERVICES.

         o  MAXIMUM SLOTS - Sets the maximum number of slots that may  be
            entered  into a virtual circuit datagram for a given circuit.
            It is agreed upon by the server and  host  when  the  virtual
            circuit   between  them  is  established.   The  default  and
            recommended value is 64.

         o  MAXIMUM SLOT SIZE - Sets the maximum number of bytes of  data
            (not including the slot header) that the host can accept from
            the server in any slot.  The slot size can range  from  1  to
            255.  The default and recommended value is 40.

         o  MAXIMUM SERVER CACHE - Sets the  maximum  number  of  servers
            whose  characteristics  are kept in memory.  The LCP command,
            SHOW  SERVER,  displays  these  characteristics.   (Refer  to
            Section  13.8.3,  Displaying Server Information.) The default
            and recommended value is 20.


   Static Parameters

         o  DEFAULT LAT ACCESS STATE - Determines  LAT  accessibility  to
            and from the host.  Values for the state are ON (the default)
            and OFF.  The LAT access state  can  be  changed  dynamically
            with  a  LAT  Control  Program  command.   When the system is
            reloaded, however, the value for this static parameter  again
            takes effect.

            Refer  to  Section  13.5,  STARTING  AND  STOPPING  LAT,  for
            additional information.

         o  HOST NAME - Uniquely identifies the  host  within  the  local
            area  network.   It  may  contain  up to a combination of six
            alphabetic  and  numeric  characters,  with  at   least   one
            alphabetic  character.   The  default host name is the DECnet
            node name, if the system supports DECnet.  If the system does
            not  support  DECnet,  you  must specify a name.  For related
            information,  refer  also  to  Section  13.7.   That  section
            discusses host service names.

         o  HOST NUMBER - Uniquely identifies the host within  the  local
            area  network.   The number can range from 0 to 65535.  It is


                                    13-5
                            LAT TERMINAL SERVERS


            passed to the server when the virtual  circuit  between  host
            and  server is established.  The default number is the DECnet
            node number, if the  system  supports  DECnet.   This  is  an
            optional parameter for use by one of your system programmers.

   The n-CONFIG.CMD file commands that set these static parameters are:

        - NODE hostname  hostnumber

        - LAT-STATE default LAT access state

        where the default LAT access state is ON or OFF

|       Refer  to  the  DECnet-20  PSI-20  System  Manager's  Guide   for
|       DECnet-related SETSPD commands, if applicable.


   Dynamic Parameters

   As system manager, you will probably be most  concerned  with  dynamic
   parameters:

         o  HOST GROUP CODES - Defines the  group  codes  for  the  host.
            They  can range from 0 to 255.  Code 0 is enabled by default.
            You can define any number of codes for a host.  A LAT  server
            will not connect to the host unless both server and host have
            at least one group code defined in common.  Refer to  Section
            13.6, LAT GROUPS.

         o  HOST IDENTIFICATION - Supplies information  about  the  host.
            It  appears  in  various  displays  requested by managers and
            users.  The identification may contain  up  to  64  printable
            characters.  The default identification is the TOPS-20 banner
            message from SYSTEM:MONNAM.TXT.

         o  HOST NUMBER - Uniquely identifies the host within  the  local
            area  network.   The number can range from 0 to 65535.  It is
            passed to the server when the virtual  circuit  between  host
            and  server is established.  The default number is the DECnet
            node number if  the  system  supports  DECnet.   This  is  an
            optional parameter for use by one of your system programmers.

         o  HOST MULTICAST TIMER - Determines the interval at  which  the
            host  announces  to all servers that its LAT terminal service
            is available.  The default value is 60 seconds.

         o  HOST RETRANSMIT LIMIT - Sets the maximum number of times that
            the  host  retransmits  a  message  at the expiration of HOST
            CIRCUIT TIMER.  The virtual circuit is closed  and  all  jobs
            associated with the virtual circuit become detached when this
            limit is exceeded.  The default value is 30 times.



                                    13-6
                            LAT TERMINAL SERVERS


         o  HOST RETRANSMIT TIMER - Determines the interval at which  the
            host  retransmits  any unacknowledged messages to the server.
            It is started when the host sends  an  "unsolicited"  message
            and  is  stopped  when the host receives any message from the
            server  that  acknowledges  all  outstanding  messages.   The
            default  value  is 1000 milliseconds (one second).  It can be
            set from 1000 to 2000 milliseconds, however.   Refer  to  the
            description  of  the  HOST  RETRANSMIT  LIMIT  parameter  for
            related information.

         o  HOST SERVICE NAME - Specifies the name of a service that  the
            host  provides for users.  It may contain a combination of up
            to 16 alphabetic and numeric characters as well as the dollar
            sign  ($),dash  (-), and underscore (_).  The default service
            name is the host name.  Refer to Section 13.7, HOST SERVICES.

         o  HOST SERVICE NAME RATING - Assigns  a  rating  to  a  service
            name.   It  can be a fixed number in the range of 0 to 255 or
            it can be DYNAMIC.  Refer to Section 13.7.1, Service Ratings.

         o  LAT ACCESS STATE - Determines LAT accessibility to  and  from
            the host.  The default state allows LAT access.  This dynamic
            parameter is affected by the LCP START and STOP commands.

         o  MAXIMUM ACTIVE CIRCUITS - Sets  the  maximum  number  of  LAT
            virtual  circuits  that can exist simultaneously at the host.
            The default value is 20.

         o  MAXIMUM SESSIONS  -  Sets  the  maximum  number  of  terminal
            sessions  that may be active at the host simultaneously.  The
            default value  is  equivalent  to  the  number  of  terminals
            allowed in your system configuration.  Section 13.1 discusses
            sessions.

   The dynamic parameters are changed with the LAT Control Program (LCP).
   To use LCP, the operator enters the following from the OPR prompt:

        1.  For many LCP commands:

            OPR> ENTER LCP<RET>
            LCP> <LCP command><RET>
            LCP> <LCP command><RET>
            LCP> <LCP command><RET>
            LCP> <LCP command><RET>
            LCP> RETURN<RET>
            OPR>

        2.  For a single command:

            OPR> LCP <LCP command><RET>
            OPR>



                                    13-7
                            LAT TERMINAL SERVERS


   The LCP commands  also  let  you  start  and  stop  operations,  check
   parameter values and other information, and access counters maintained
   by the NI and servers.  These LCP functions  are  discussed  in  later
   sections.   The  Operator's  Command  Language  Reference Manual fully
   describes LCP.

   The following is a summary of the LCP commands:

   START
   STOP
   SET GROUPS (0,1-5,....255)
   SET SERVICE-NAME service-name{/RATING:{nn|DYNAMIC}|
                              /IDENTIFICATION:"text"|
                               nothing}
   SET IDENTIFICATION "text"
   SET NUMBER number
   SET MAXIMUM ACTIVE-CIRCUITS number
   SET MAXIMUM SESSIONS number
   SET MULTICAST-TIMER seconds
   SET RETRANSMIT LIMIT number
   SET RETRANSMIT TIMER number

   CLEAR GROUPS (0,1-5,....255)
   CLEAR SERVICE-NAME service-name
   CLEAR IDENTIFICATION
   CLEAR MAXIMUM CIRCUITS
   CLEAR MAXIMUM SESSIONS
   CLEAR MULTICAST-TIMER
   CLEAR NUMBER
   CLEAR RETRANSMIT LIMIT
   CLEAR RETRANSMIT TIMER

   SHOW CHARACTERISTICS
   SHOW HOST-INITIATED-REQUESTS
   SHOW PENDING-REQUESTS
   SHOW SESSIONS
   SHOW COUNTERS{/SERVER:server-name|
                 nothing}
   SHOW SERVER{/ALL|
               server-name|
               nothing}

   ZERO COUNTERS{/SERVER:server-name|
                 nothing}



   13.5  STARTING AND STOPPING LAT

   Support for LAT servers is enabled by default in TOPS-20.  That is,the
   LAT  access  state  is  enabled  unless  specifically  disabled in the
   n-CONFIG.CMD file.  Disabling it is useful if you  wish  to  establish


                                    13-8
                            LAT TERMINAL SERVERS


   guidelines and set restrictions for LAT use before you enable it.  You
   can set groups  and  the  host  identification,  for  example,  before
   enabling  LAT.   The  operator  can  enable and disable the LAT access
   state dynamically with the LCP START and STOP commands.

   The host name and number are other parameters that you specify in  the
   n-CONFIG.CMD  file (unless DECnet is supported on the host).  They are
   required items that uniquely identify  the  host  in  the  local  area
   network.

   After the host name and number have  been  established,  and  the  LAT
   access  state has been enabled, the operator starts LAT by booting the
   server or by issuing a DECnet command from the host, as  discussed  in
   Section 13.3.

   It is recommended that you disable the LAT access state if LAT is  not
   intended to be used for an extended period of time.  This will improve
   system performance.



   13.6  LAT GROUPS

   By using group codes, you can  divide  the  local  area  network  into
   smaller  networks.   That  is,  you  can  allow or prevent connections
   between specified servers and hosts.  When users give a LAT command to
   display   the   names  of  available  services,  only  those  services
   corresponding to  hosts  within  a  server's  "group"  are  displayed.
   (Refer  to  Section  13.7  for a discussion of services.) Codes in the
   range of 0 to 255 can be assigned to DECSYSTEM-20s and LAT servers.  A
   LAT  server  will  connect to a host only if it has at least one group
   code defined in common with the host.  (Refer to the LAT documentation
   set for information on assigning codes to LAT servers.) Note that code
   0, the default for hosts and servers, allows universal  access.   When
   servers  and  hosts  implement  the  default, users have access to all
   hosts.

   In  the  example  below,  an  operator  enables  access  between  this
   DECSYSTEM-20  and  any LAT server assigned a code in the range of 1 to
   5.  No connection is allowed with any other server.

   LCP> SET GROUPS 1:5<RET>
   LCP> CLEAR GROUPS 0<RET>

   User terminals wired to servers in any one of  these  groups  will  be
   able to access the system.

   Group settings stay in  effect  until  reset  with  the  CLEAR  GROUPS
   command.





                                    13-9
                            LAT TERMINAL SERVERS


   13.7  HOST SERVICES

   Another name for a LAT host is a service node (a node being  a  system
   in  a  network).  This refers to the fact that hosts provide computing
   services.  Users access hosts in order to have some type of  computing
   need  served--to  compile a program, update a file, or print a report,
   for example.  LAT terminal servers deliver these services to users.

   Users refer to hosts by the services that they offer, rather  than  by
   host  name.   When  they  request  the LAT server to connect them to a
   host, they specify a service name that you have previously established
   for  that host.  The server maintains a list of host and service names
   and lets users display service names assigned to hosts in  the  user's
   group.   (The server also displays any service identification text you
   specified.) With the SET SERVICE-NAME command, you can specify one  or
   more services for a host:

   LCP> SET SERVICE-NAME LASER-PRINTER/IDENTIFICATION:"OMEGA System"<RET>
   LCP> SET SERVICE-NAME ARPA-GATEWAY<RET>

   The default service name for a host is the host name.  You may want to
   specify  some identifying text for such services.  For example, on the
   host ALPHA, you could give the command:

   LCP> SET SERVICE-NAME ALPHA/IDENTIFICATION:"A DECnet System"<RET>

   You can assign the same service name to multiple hosts.  The following
   section discusses this topic.



   13.7.1  Service Ratings

   You can arrange  for  LAT  servers  to  distribute  users  among  host
   systems, according to a rating system that you set up.  This is useful
   for hosts with service names in common.  Perhaps several  systems  are
   part  of a CFS cluster.  You can assign the same service name, CFS, on
   each host but specify a unique service rating for each one:

   LCP> SET SERVICE-NAME CFS/RATING:3
       /IDENTIFICATION: "ALPHA/BETA/OMEGA Cluster"<RET>
   LCP> SET SERVICE-NAME CFS/RATING:9
       /IDENTIFICATION: "ALPHA/BETA/OMEGA Cluster"<RET>

   If a user requests connection to CFS, the server will  pick  the  host
   with  the  highest rating for that service.  If, for some reason, that
   connection fails, the server will try the host with the  next  highest
   rating.






                                   13-10
                            LAT TERMINAL SERVERS


   Ratings can be a fixed number from 0 to 255.  Or they can be  DYNAMIC.
   When  hosts  with  common  service  names have DYNAMIC ratings for the
   service, the hosts compute ratings using an algorithm based on  system
   load  averages.   Generally,  the host with the lowest load average is
   given the  highest  rating.   That  host  probably  has  the  greatest
   available computing capacity.

   You can use common service names for any collection of hosts  offering
   the same function.

   The default rating is 1 for  the  default  service  name,  and  0  for
   services created with the SET SERVICE-NAME command.


   Service Rating Example

   Hosts SOLAR and LUNAR, in addition to providing a timesharing  service
   as  service  names  SOLAR  and  LUNAR, each have the service name CFS.
   SOLAR assigns a host rating to name CFS of 5; whereas LUNAR assigns 3.
   A  LAT  terminal  user,  when  displaying  the  list  of available LAT
   services, will see SOLAR, LUNAR, and CFS.  If  the  user  connects  to
   CFS, the server will first attempt to access SOLAR.  If that fails, it
   will try LUNAR.



   13.8  MONITORING LAT FROM THE HOST

   The following sections show various LAT informational displays.



   13.8.1  Displaying User Information

   The SHOW SESSIONS command displays  information  about  connected  LAT
   terminals:

   LCP>SHOW SESSIONS<RET>
   LCP>
   10:52:26                      [LCP] Active LAT sessions 

   Job Line Program Server Name      Port Name        User
   105  326 EXEC    COTTAGE          PORT7            DOPEY
   114  327 LPRINT  PALACE          *LASER-PRINTER    THE_QUEEN
   114  330 LPRINT  PALACE           ROYAL-TTY        THE_QUEEN
   120  331 EXEC    COTTAGE          PORT3            GRUMPY
   113  332 EMACS   PALACE           KINGS-TTY        THE_KING
    * indicates an Application Terminal


   The TOPS-20 SYSTAT user command shows much of this same information.



                                   13-11
                            LAT TERMINAL SERVERS


   13.8.2  Displaying Host Parameters

   The SHOW CHARACTERISTICS command displays many of  the  LAT  parameter
   settings:

   LCP>SHOW CHARACTERISTICS<RET>

   LCP>
   09:20:41 [LCP]                                    -- Host Characteristics --

   LAT Access State: ON
   Host Name: ALPHA
   Host id: ALPHA, TOPS-20 Development System, TOPS-20 Monitor 7(20753)
   Host number: 140
   Retransmit Limit: 60
   Retransmit Timer: 1000
   Multicast Timer: 30
   Groups: 3:4,7,10,18,21:23,45,47

                        Current   Maximum
                        -------   -------
   Allocated circuits       6        32
   Active circuits          6        20
   Sessions                 8       128

   Service name   Rating        Identification
   ------------   ------   ------------------------
      ALPHA         1      ALPHA - More Networks per CPU
      SGROUP        D      Software Engineering Cluster

   The D that appears for the service name  rating  indicates  a  dynamic
   rating.



   13.8.3  Displaying Server Information

   The SHOW  SERVER  command  displays  information  about  servers  with
   connections  to  this  host.   The  host  tries to keep information in
   memory on all servers that have connected since the last monitor load.
   However,  this  could  require  a  very  large  data base.  Therefore,
   information is kept only for the number of servers  specified  in  the
   MAXIMUM  SERVER CACHE permanent parameter.  (Refer to Section 13.4 for
   information on this parameter.) When  this  number  is  exceeded,  the
   oldest inactive entry is deleted from the data base, making room for a
   new entry.








                                   13-12
                            LAT TERMINAL SERVERS


   You can specify a single-line summary for each server  or  a  detailed
   display for a single server:

   LCP>SHOW SERVER/ALL<RET>
   LCP>
   14:55:32                      [LCP] Summary of all servers 

   Server Name(Number): Finance(8) Address: 08-00-2B-00-17-BA
   Server Name(Number): Accounting(22) Address: 08-00-2B-02-08-C0
   Server Name(Number): Payroll [LAT3](3) Address: AA-00-03-01-25-38
   Server Name(Number): Development(2) Address: AA-00-03-01-06-AB


   LCP>SHOW SERVER FINANCE<RET>
   LCP>
   14:56:12                      [LCP] Information about server Finance

   Server Number: 8
   Server Location: Near vending machines
   Server Type: DECserver-100
   Ethernet Address: 08-00-2B-00-17-BA
   Server Status: Connected
   Max Slots: 32
   Data Link Size: 1518
   Circuit Timer(ms): 80
   Keep-alive Timer(s): 20



   13.8.4  Displaying LAT Counters

   The SHOW COUNTERS command  displays  counters  kept  by  LAT  software
   modules.   These  counters  provide  information such as the number of
   messages transmitted, the number of transmission errors,  and  so  on.
   You  can  obtain  these numbers for a single server, or you can obtain
   cumulative figures for all servers that have connected since the  last
   monitor reload:

   LCP>SHOW COUNTERS<RET>
   LCP>
   14:48:11                      [LCP] Counter totals for all servers 

   Messages received: 33955
   Messages transmitted: 36413
   Messages retransmitted: 0
   Sequence errors received: 21
   Illegal messages received: 0
   Illegal slots received: 0
   Resource failures: 0





                                   13-13
                            LAT TERMINAL SERVERS


   LCP>SHOW COUNTERS/SERVER:PUBLICATIONS<RET>
   LCP>
   14:48:34                      [LCP] Counters for server PUBLICATIONS

   Messages received: 28189
   Messages transmitted: 30132
   Messages retransmitted: 0
   Sequence errors received: 0
   Illegal messages received: 0
   Illegal slots received: 0
   Resource failures: 0

   The single-server  counts  are  available  even  after  a  server  has
   disconnected  from  the  host.   However,  this  availability,  as the
   information displayed with the SHOW SERVER  command,  depends  on  the
   limit set with the MAXIMUM SERVER CACHE permanent parameter.

   The cumulative counters are incremented each  time  individual  server
   counters  are.   It is possible that the sum of all server counters is
   not equal to the cumulative counts, because you can zero the  counters
   for  any  server,  as  discussed below, or the data base may have been
   cleared according to the MAXIMUM SERVER CACHE parameter limitation.

   When using the counters to monitor performance or to isolate  hardware
   failures,  it  is  often  desirable  to be able to reset (or zero) the
   counters.  The ZERO COUNTERS command lets you do this.  You can  reset
   counters  for  one  server  or  for  all  the  servers.  Resetting the
   cumulative counts  does  not  affect  the  counts  of  the  individual
   servers.



   13.8.5  Displaying Pending Requests for LAT Application Terminals

   The SHOW PENDING-REQUESTS command  displays  information  on  pending,
   rejected, and canceled requests for LAT application terminals:

   LCP>SHOW PENDING-REQUESTS<RET>
   LCP>
   09:20:49 [LCP]                       -- Current Pending Connect Requests --


   Job Status    Server Name     Service Name      Port Name     User
   --- ------ ---------------- ---------------- ------------ ----------
   146 QUE  1 LAT100                            LN03         WADDINGTON

   QUE nn means request was queued; entry is nn requests into the queue

   A total of 1 request was found
   LCP>




                                   13-14
                            LAT TERMINAL SERVERS


   13.8.6  Displaying All Print Requests for LAT Application Terminals

   The SHOW HOST-INITIATED-REQUESTS command displays information  on  all
   active and pending requests for LAT application terminals:

   LCP>SHO HOST
   LCP>
   09:21:10 [LCP]                                    -- Current Host-Initiated Requests --


   Job Status    Server Name     Service Name      Port Name          User
   --- ------ ---------------- ---------------- ---------------- ---------------
   130 TTY334 LAT100                            LN03             OPERATOR
   146 QUE  1 LAT100                            LN03             WADDINGTON

   TTYnnn means connect is active and terminal nnn was assigned
   QUE nn means request was queued; entry is nn requests into the queue

   A total of 2 requests were found
   LCP>


































                                   13-15
                            LAT TERMINAL SERVERS


   .
                                        


                                   INDEX



               -A-                     Application terminal, 13-2
                                       Automatic Volume Recognition
   ABSOLUTE-INTERNET-SOCKETS               (AVR), 8-15, 8-17
     capability, 5-39                  AVR, 8-15, 8-17
   Access control job (ACJ), 11-1
     class scheduler, 10-14                        -B-
   Accounts
     account data file commands,       B362LB.REL, 3-7
         6-13                          Backup
     ACTGEN program, 6-17                common policy, 7-4
     creating, 6-1                       console front end files, 7-10
     creating the data base, 6-7         full dumps, 7-2
     disabling, 6-2                      system, 7-1
     enabling, 6-2                       system crash tape, 7-6, 7-8
     errors, 6-19                        tape requirements, 7-4
     OPERATOR account, 6-19            BASIC.EXE, 3-7
     selecting schemes, 6-3            Batch jobs
     setting up for shift changes,       scheduling low priority to,
         6-3                                 10-15
     setting up with existing files,   Batch system
         6-2                             tailoring, 3-29
     validating, 6-19                  BATCON.EXE, 3-7
   ACCOUNTS-TABLE.BIN, 3-4             Beware file, 1-1
   <ACCOUNTS>, 3-18                    Bias controls, 10-15
   ACJ, 11-2                           Blocking factor
     ACJDEC program, 11-3                magnetic tape, 7-6
     DISABLE command, 11-14            Boot Structure, 4-2
     ENABLE/DISABLE command, 11-3,     BS:, 12-17
         11-5                          BUGCHK, 9-14
     ENABLE/DISABLE command            BUGINF, 9-14
         qualifiers, 11-14             BUGS.MAC, 3-4
     HELP command, 11-3                BUILD.MEM, 4-20
     log files, 11-21
     SAVE command, 11-19                           -C-
     SET command, 11-17
     SHOW command, 11-18               Cache
     starting, 11-2                      program name, 10-17
     TAKE command, 11-3                Capabilities, 5-38
     USER command, 11-15               CDRIVE.EXE, 3-7
     WRITE command, 11-19              CFS, 12-1
   ACTGEN program, 6-17                  ALLOW command, 12-5
   ACTGEN.EXE, 3-7                       batch jobs and, 12-8, 12-13
   ACTGEN.HLP, 3-7                       CFRECN BUGHLT, 12-20, 12-21
   ACTSYM.UNV, 3-7                       "cluster data gathering"
   AN-MONBIG.EXE, 3-4                        (CLUDGR), 12-9
   AN-MONDCN.EXE, 3-4                    cluster GALAXY, 12-9
   AN-MONMAX.EXE, 3-4                    date/time, 12-6
   ANAUNV.UNV, 3-7                       DECnet and, 12-7


                                  Index-1
                                        


   CFS (Cont.)                         Cluster GALAXY, 3-31, 12-9
     directory groups, 12-14           Cluster printers, 3-30
     dismounting structures, 12-19,    CMD.REL, 3-8
         12-24                         CMD.UNV, 3-8
     DMP:, 3-23                        COBDDT.HLP, 3-8
     dual-ported disks, 12-5, 12-21,   COBDDT.REL, 3-8
         12-24                         COBOL.EXE, 3-8
     DUMPER, 12-20                     COBOL.HLP, 3-8
     ^ECEASE, 12-24                    COMAND.CMD, 3-4
     ENQ-DEQ, 12-8                     Common File System
     errors, 12-21                       see CFS
     exclusive structures, 12-18       Computer room security, 2-1
     file server, 12-4                 CONFIDENTIAL
     hardware, 12-2                      capability, 5-39
     IPCF, 12-8                        CONFIG.CMD, 2-4, 3-3
     limitations, 12-8                 Console front-end files, 3-25,
     load balancing, 12-8, 12-13           4-2, 7-10
     logical names, 12-15              CREF.EXE, 3-8
     login structure, 12-16            CREF.HLP, 3-8
     mail files, 12-11
     massbus disks, 12-4, 12-24                    -D-
     MSCP file server, 12-4, 12-11,
         12-24                         DECnet, 9-17, 12-7
     printers, 3-30                      Cluster GALAXY, 12-10
     privileged users, 12-16             DQS printers, 3-30
     served disks, 12-5, 12-11,        DECNET-ACCESS
         12-20, 12-21, 12-24             capability, 5-39
     sharing structures, 12-15         DEFAULT-EXEC:, 3-23
     software, 12-6                    Device names, 4-10
     structure names, 12-15            DEVICE-STATUS.BIN, 3-4
     system structure, 12-3, 12-18     Diagnostic link
     tape drives, 8-20                   remote (KLINIK), 9-11
     tightly-coupled systems and,      DIL.LIB, 3-8
         12-8                          DIL.REL, 3-8
     updating files, 12-11             DILV7.FOR, 3-8
     user groups, 12-14                Directories
     usernames, 12-14                    creating, 5-1
     users, 12-7                         creating (central control), 5-2,
     writing files, 12-11                    5-4
   CHECKD program, 4-13                  creating (project and central
     login structure, 12-16                  control), 5-3, 5-22
   CHECKD.EXE, 3-4, 3-8                  creating (project control), 5-2,
   CHECKD.HLP, 3-8                           5-14
   CHKPNT.EXE, 3-8                       printing information about,
   CHKPNT.HLP, 3-8                           5-40
   CI                                    protection code, 5-7, 5-26
     making unavailable (non-CFS),       restoring, 9-2
         9-12                            system, 3-1
   CI (CFS), 12-3                      Directory group numbers, 5-29
   CI20, 12-4                          Disk drives, 4-12
   Class scheduler, 10-2                 dual ported, 4-17
   CLUDGR, 12-9                          dual-ported (CFS), 12-21, 12-24


                                  Index-2
                                        


   Disk drives (Cont.)                 FE.EXE, 3-9
     dynamic dual porting, 10-19       FE.HLP, 3-9
     timeout interval, 9-13            FEDDT.EXE, 3-5, 3-9
     unavailable, 9-12                 FILCOM.EXE, 3-9
   Disk packs                          FILCOM.HLP, 3-9
     reinitializing, 10-18             FILDDT.EXE, 3-9
   Disk space                          File archiving, 8-1, 8-2
     allocating, 5-23                    archive cycle, 8-3
     determining, 4-21                   recycling tapes, 8-3, 8-11
     enforcing quotas, 5-24              retrieving files, 8-5, 8-7
     permanent quota, 5-23               sample procedure, 8-5
     working quota, 5-23                 setting up system, 8-3
   DITV7.FOR, 3-8                        when to create tapes, 8-5
   DIXV7.FOR, 3-8                      File Descriptor Block (FDB), 8-4
   DLUSER program, 9-10                File migration, 8-2, 8-7
   DLUSER.EXE, 3-8                       processing retrieval requests,
   DLUSER.HLP, 3-8                           8-11
   DMP:, 3-23, 9-15                      recycling tapes, 8-11
   Documents                             setting up system, 8-8
     available from DIGITAL, 1-1         using DUMPER, 8-10
     prepared at your site, 1-2          using REAPER, 8-8
   Domestic structures, 4-16           File system
   DQS printers, 3-30                    restoring, 9-9
   DUMP-ON-BUGCHK, 9-14                Files
   DUMP.CPY, 3-4                         protection code, 5-26
   DUMP.EXE, 3-4                       FORDDT.HLP, 3-9
   0DUMP11.BIN, 3-3                    FORDDT.REL, 3-9
   DUMPER program, 7-1                 Foreign structures, 4-16
     CFS systems, 12-20                FORMAT.EXE, 3-9
     file archiving, 8-3               FORMAT.HLP, 3-9
     file migration, 8-10              FOROTS.EXE, 3-9
     password encryption, 11-26        FORTRA.EXE, 3-9
   DUMPER.EXE, 3-9                     Front-end files, 3-25, 4-2, 7-10
   DUMPER.HLP, 3-9
   DX20LD.EXE, 3-9                                 -G-
   DXMCA.ADX, 3-9
                                       GALAXY documentation file, 3-31,
               -E-                         3-34
                                       GALCNF, 3-9
   ^ECEASE, 12-24                      GALGEN.EXE, 3-9
   EDDT.REL, 3-9                       GLOBS.UNV, 3-10
   EDIT.EXE, 3-9                       GLXLIB.EXE, 3-10
   EDIT.HLP, 3-9                       Groups, 5-7
   ENQ-DEQ                               directory, 5-29
     capability, 5-39                    user, 5-29
   ERRMES.BIN, 3-4
   EXEC.EXE, 3-4                                   -H-
    
               -F-                     HELP.HLP, 3-10
                                       <HELP>, 3-20
   FAL.EXE, 3-13                       HLP:, 3-22
   FDB, 8-4                            Home block, 4-4


                                  Index-3
                                        


   HOSTS.TXT, 3-5                      LAT (Cont.)
                                         service ratings, 13-10
               -I-                       services, 13-5, 13-7, 13-10
                                         sessions, 13-2, 13-7
   IBMSPL.EXE, 3-10                      slots, 13-3, 13-5
   INFO.EXE, 3-10                        starting and stopping service,
   INTERNET-ACCESS                           13-5, 13-7, 13-8
     capability, 5-39                    users, 13-2, 13-11
   INTERNET-WIZARD                       virtual circuit, 13-2, 13-6,
     capability, 5-39                        13-7
   INTERNET.ADDRESS, 3-5               LCPORN.REL, 3-10
   INTERNET.GATEWAYS, 3-5              LCPTAB.REL, 3-10
   INTERNET.NAMESERVERS, 3-5           LIBARY.EXE, 3-10
   IPALOD.EXE, 3-5                     LIBARY.HLP, 3-10
   IPCF                                LIBO12.EXE, 3-10
     capability, 5-39, 12-8            LIBOL.REL, 3-10
   ISAM.EXE, 3-10                      LINK.EXE, 3-10
   ISAM.HLP, 3-10                      LINK.HLP, 3-10
                                       LISSPL.EXE, 3-10
               -J-                     Local Area Network, 13-1
                                       Local Area Transport
   Jobs                                  See LAT, 13-1
     hung, 9-12                        Logical names, 3-20
                                         CFS, 12-15
               -K-                     LOGIN command, 6-19
                                         dates/times of login, 11-30
   KDDT.REL, 3-10                        fast login, 11-31
   KLINIK, 9-11                        Login structure, 4-2, 12-16
   KNILDR.EXE, 3-5, 3-10               LOGIN.CMD, 3-5
                                       LOGOUT.CMD, 3-5
               -L-                     LP64.RAM, 3-10
                                       LP96.RAM, 3-11
   Labeled tapes, 8-13                 LPTSPL.EXE, 3-11
   LAT, 13-1                           LPTUSR.MAC, 3-31, 3-34
     circuit timer, 13-3
     counters, 13-13                               -M-
     DECnet and, 13-4
     DUMP-ON-BUGCHK, 9-17              MACREL.REL, 3-11
     features, 13-2                    MACRO.EXE, 3-11
     groups, 13-6, 13-9                MACRO.HLP, 3-11
     host identification, 13-6         MACSYM.UNV, 3-11
     host name, 13-5                   Magnetic tape, 8-1
     host number, 13-5                   backup requirements, 7-5
     LCP commands, 13-7                  blocking factor, 7-6
     load balancing, 13-10               recycling, 8-11
     multicast timer, 13-6             Mail, 3-24, 12-11
     parameters, 13-4, 13-12           MAINTENANCE
     printers, 3-30                      capability, 5-39
     retransmit limit, 13-6            MAKDMP.EXE, 3-11
     retransmit timer, 13-3, 13-7      MAKLIB.EXE, 3-11
     server characteristics, 13-5,     MAKLIB.HLP, 3-11
         13-12                         MAKRAM.EXE, 3-11


                                  Index-4
                                        


   MAKRAM.HLP, 3-11                    Operator (Cont.)
   MAKVFU.EXE, 3-11                      shared disk drive procedure,
   MAKVFU.HLP, 3-11                          4-18
   MAPPER.EXE, 3-11                      shared tape drive procedure,
   MDDT.REL, 3-11                            8-18
   2060-MONBIG.EXE, 3-3                Operator shift change log, 1-9
   MONITR.EXE, 3-5                     Operator work request form, 1-9
   2060-MONMAX.EXE, 3-3                <OPERATOR>, 3-18
   MONNAM.TXT, 3-5                     OPR, 9-15
   MONSYM.REL, 3-12                    OPR.EXE, 3-12
   MONSYM.UNV, 3-12                    OPR.HLP, 3-12
   Mountable structure sign-up log,    ORION.EXE, 3-12
       1-6                             OVRLAY.REL, 3-12
   Mountable structures, 4-5, 9-10
   MOUNTR.EXE, 3-12                                -P-
   MS.EXE, 3-11
   MS.HLP, 3-11                        PA1050.EXE, 3-12
   MSCPAR.UNV, 3-12                    Page, 4-19
                                       Password encryption, 11-23
               -N-                       algorithms, 11-25
                                         DUMPER program, 11-26
   NEBULA.EXE, 3-12                      multiple-system environment,
   Network Interconnect                      11-25
     See NI, 13-1                      Password management, 5-7, 11-28
   <NEW-SUBSYS>, 3-17                  PAT.EXE, 3-12
   <NEW-SYSTEM>, 3-17                  Performance, 10-1
   NEW:, 3-21                            batch background, 10-15
   <NEW>, 3-19                           bias controls, 10-15
   NFT.EXE, 3-12                         class scheduler, 10-2
   NFT.HLP, 3-12                         dynamic dual porting, 10-19
   NI, 13-1                              interactive versus
     setting unavailable, 9-12               compute-bound programs,
   NMLT20, 3-12                              10-15
   NORMAL.VFU, 3-12                      program name cache, 10-17
   NRT, 3-24                             reinitializing disk packs,
                                             10-18
                                       Permanent storage, 5-23
               -O-                     PHYPAR.UNV, 3-12
                                       PLEASE.EXE, 3-12
   Offline structures, 9-12            POBOX:, 3-24, 12-11
   OLD:, 3-22                          Power failures, 9-11
   <OLD>, 3-19                         Printers
   OPERATOR                              remote, 3-30
     capability, 5-39                    terminal, 3-34
   Operator                            Privileges, 5-38, 12-16
     accounting, 6-19                  Program name cache, 10-17
     alternative to PLEASE requests,   PROGRAM-NAME-CACHE.TXT, 3-5
         3-20                          PROLOG.UNV, 3-12
     archiving procedures, 8-5         PS:, 12-17
     handling user requests, 2-1       PTYCON.ATO, 3-3
     <REMARKS>, 3-20                   PTYCON.EXE, 3-12
     scheduling tasks, 2-2             PTYCON.HLP, 3-13


                                  Index-5
                                        


               -Q-                     Security, 5-7, 11-1
                                         access control job, 11-1
   QUASAR.EXE, 3-13                      computer room, 2-1
                                         fast login, 11-31
               -R-                       labeled tapes, 8-16
                                         last login information, 11-30
   RA60, 4-13, 7-5                       password encryption, 11-23
   RA81, 4-13, 7-5                       password management, 11-28
   RDMAIL.EXE, 3-13                      passwords vs groups, 5-7
   RDMAIL.HLP, 3-13                    SELOTS.EXE, 3-14
   REAPER program, 8-8                 SEMI-OPERATOR
   REAPER.CMD, 3-5                       capability, 5-39
   REAPER.EXE, 3-13                    SERCOD.UNV, 3-14
   REAPER.HLP, 3-13                    SERR:, 3-22
   Reinitializing disk packs, 10-18    SETSPD, 2-4
   <REMARKS>, 3-20                     SETSPD.EXE, 3-3
   Remote printers, 3-30               Shift change log, 1-9
     characteristics, 3-33             SIX12.REL, 3-14
     printer definitions, 3-32         Software
   REMOTE-PRINTING.CMD file, 3-32        after installation, 3-1
   RERUN.EXE, 3-13                       before installation, 2-1
   RERUN.HLP, 3-13                       checking (UETP), 3-29
   RETRFB.SPE, 3-13                      updating, 2-4, 3-17, 3-19
   RFB.EYE, 3-13                       SORT.EXE, 3-14
   RMS.EXE, 3-13                       SORT.HLP, 3-14
   RMSCOB.EXE, 3-13                    SPEAR.EXE, 3-14
   RMSINI.REL, 3-13                    SPOOL:, 3-25
   RMSINT.R36, 3-13                    <SPOOL>, 3-18
   RMSINT.UNV, 3-13                    SPRINT.EXE, 3-14
   RMSUTL.EXE, 3-13                    SPROUT.EXE, 3-14
   <ROOT-DIRECTORY>                    SPRRET.EXE, 3-14
     definition, 3-2                   SPRSUM.EXE, 3-14
     rebuilding on system structure,   Star coupler, 12-3
         9-5                           Structures
     restoring, 9-3                      alias, 4-11
   RP06, 4-13, 7-5                       boot, 4-2
   RP07, 4-13, 7-5                       BS:, 12-17
   RP20, 4-13, 7-5                       differences between system and
   RSX20F, 3-25                              mountable, 4-6
     DUMP-ON-BUGCHK, 9-17                dismounting, 4-15
   RSX20F.MAP, 3-6                       dismounting (CFS), 12-19
   RSXFMT.EXE, 3-13                      domestic, 4-16
   RSXFMT.HLP, 3-13                      dumpable, 9-15
   RUNOFF.EXE, 3-13                      exclusive (CFS), 12-18
   RUNOFF.HLP, 3-14                      foreign, 4-16
                                         increasing the size of, 4-13
                                         login, 4-2, 12-16
               -S-                       mountable, 4-5, 4-7, 4-8
                                           re-creating, 9-10
   SCAPAR.UNV, 3-14                      multiple, 4-7
   SDDT.EXE, 3-14                        names, 4-9, 4-11
   Secure files, 11-4, 11-32             names (CFS), 12-15


                                  Index-6
                                        


   Structures (Cont.)                  TCX.EXE, 3-14
     offline, 9-12                     TCX.HLP, 3-14
     PS:, 12-17                        Terminal printers, 3-34
     public, 4-2                       Terminal server
     sharing among CFS systems,          definition, 13-1
         12-15                         /TERMINAL-CHARACTERISTIC: switch,
     sharing between systems, 4-17         3-31, 3-34
     size, 4-11                        TERMINAL.HLP, 3-14
     system, 4-2                       TGHA.EXE, 3-6
     system limit, 4-8                 TGHA.HLP, 3-6
   Structures > similarities between   Timeout problems, 9-17
       system and mountable, 4-6       TOC.EXE, 3-14
   <SUBSYS>                            TOC.HLP, 3-14
     files, 3-7                        TOPS-20.DOC, 3-6
     restoring, 3-16                   Tuning mechanisms, 10-1
   Supplies, 2-2                       TV.EXE, 3-14
   Swapping space, 4-19
   SYS:, 3-21                                      -U-
   SYSJOB.EXE, 3-3
   SYSJOB.HLP, 3-6, 3-14               UDDT.EXE, 3-15
   SYSJOB.RUN, 3-4                     UETP, 3-29
   SYSTAP.CTL, 3-14                    ULIST program, 5-40
   System                              ULIST.EXE, 3-15
     problems, 9-1                     ULIST.HLP, 3-15
     selecting features, 2-4           User requests, 1-9, 2-1
   System access request form, 1-6     User-group numbers, 5-29
   System crash tape, 7-6, 7-8         Usernames
   System log, 1-3                       assigning, 5-4, 5-8, 5-15, 5-22
   System structure                      CFS, 12-14
     backup, 4-14
     contents, 4-3                                 -V-
     definition, 4-2
     dual porting, 12-5                VERIFY.EXE, 3-15
     re-creating, 7-6, 7-8             VOLID, 8-14
     rebuilding <ROOT-DIRECTORY>,
         9-5                                       -W-
   <SYSTEM-ERROR>, 3-18
   SYSTEM.CMD, 3-6                     WATCH.EXE, 3-15
   SYSTEM:, 3-21                       WATCH.HLP, 3-15
   <SYSTEM>                            WHEEL
     files, 3-3                          capability, 5-39
     restoring, 3-6                    Windfall, 10-4
                                       Work request form, 1-9
               -T-                     Working storage, 5-23
    
   Tape drive allocation, 8-2, 8-12
   Tape drives                                     -X-
     sharing between systems, 8-18
   Tape labeling, 8-13                 XPORT.REL, 3-15
   TAPNAM.TXT, 3-6                     XRMS.EXE, 3-15