MGR_GUIDE
TOPS-20
TOPS-20
System Manager's Guide
System Manager's Guide
| Electronic Distribution
June 1990
| 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:
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 . . . . . . . . . . . . . . . . 3-2
3.2.2 . . . . . . . . . . . . . . . . . . . . 3-3
3.2.3 Restoring the Directory . . . . . . . . 3-6
3.2.4 . . . . . . . . . . . . . . . . . . . . 3-7
3.2.5 Restoring the Directory . . . . . . . 3-16
3.2.6 and . . . . . . . . 3-17
3.2.7 , , , and
. . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . 9-3
9.3.1 Rebuilding the System Structure 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 Files . . . . . . . . . . . . . . . . . . 3-3
3-2 STR: 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 BUGHLTS . . . . . . . . . . . . . 9-3
11-1 DUMPER Directory Restorations . . . . . . . . . 11-27
12-1 Comparison of CFS and DECnet . . . . . . . . . . 12-8
.
x
PREFACE
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
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.
Indicates you should press the RET or RETURN
key on your terminal. Unless otherwise noted,
pressing RETURN terminates all command or input
strings.
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
CHAPTER 1
DOCUMENTATION
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
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
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
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
DOCUMENTATION
1.2.1 System Log
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
DOCUMENTATION
____________________________________________________________________
| |
| SYSTEM LOG |
| MAINTENANCE PERFORMED DATE__________ |
| |
| |
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
| |
|____________________________________________________________________|
Figure 1-1: Sample System Log (Hardware Maintenance)
Figure 1-1: Sample System Log (Hardware Maintenance)
1-4
DOCUMENTATION
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)
Figure 1-2: Sample System Log (Problem Report)
1-5
DOCUMENTATION
DOCUMENTATION
1.2.2 Mountable Structure Sign-Up Log
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
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
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
Figure 1-3: Sample Mountable Structure Sign-Up Log
1-7
DOCUMENTATION
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
Figure 1-4: System Access Request
1-8
DOCUMENTATION
DOCUMENTATION
1.2.4 Operator Work Request Form
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
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
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
Figure 1-5: Operator Work Request
1-10
DOCUMENTATION
DOCUMENTATION
____________________________________________________________________
| |
| OPERATOR SHIFT CHANGE LOG |
|____________________________________________________________________|
| | | | |
| DATE | OPERATOR | SHIFT | COMMENTS |
|________|__________|_________|______________________________________|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
|________|__________|_________|______________________________________|
Figure 1-6: Operator Shift Change Log
Figure 1-6: Operator Shift Change Log
1-11
2-1
CHAPTER 2
CHAPTER 2
PREPARING FOR SOFTWARE INSTALLATION
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
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
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
PREPARING FOR SOFTWARE INSTALLATION
2.3 ORDERING SUPPLIES
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
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
Hardware-Related Tasks
Regular Schedule As-Needed Schedule
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
PREPARING FOR SOFTWARE INSTALLATION
Regular Schedule As-Needed Schedule
Regular Schedule As-Needed Schedule
Software-Related Tasks
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
PREPARING FOR SOFTWARE INSTALLATION
2.5 SELECTING SYSTEM FEATURES
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
CHAPTER 3
AFTER SOFTWARE INSTALLATION
AFTER SOFTWARE INSTALLATION
3.1 OVERVIEW
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
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:
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
AFTER SOFTWARE INSTALLATION
3.2.1
3.2.1
The contains a separate file for each first-level
directory on the system structure as follows:
STR:
--------------------------------------------------
| | |
| | |
STR: ... STR: ... STR:
(where STR: is the name of the structure).
The 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
that can be accessed if the original copy is
destroyed. (Refer to Section 9.3, RESTORING .)
Each structure you create in addition to the system structure has a
. The on any structure points to all
the first-level directories created under the .
After you install the software, give the DIRECTORY command for
. The output on your terminal appears similar to the
example below. Note that each directory is a file in the
. 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:
STR:
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
AFTER SOFTWARE INSTALLATION
3.2.2
3.2.2
The directory 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: Files
Table 3-1: Files
__________________________________________________________________
File Name Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-1: Files (Cont.)
Table 3-1: Files (Cont.)
File Name Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-1: Files (Cont.)
Table 3-1: Files (Cont.)
File Name Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-1: Files (Cont.)
Table 3-1: Files (Cont.)
File Name Explanation
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
3.2.3 Restoring the Directory
If the contents of 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
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)
______ _____ _____
$ASSIGN (DEVICE) MTA0:
____ _____ _ _____ _____
$SKIP (DEVICE) MTA0: 4 FILES
___ _____ _____
$RUN (PROGRAM) MTA0:
3-6
AFTER SOFTWARE INSTALLATION
AFTER SOFTWARE INSTALLATION
____ _____ _____
DUMPER> TAPE (DEVICE) MTA0:
_______ _____________ ________ _____
DUMPER> RESTORE (TAPE FILES) DSK*:<*>*.*.* (TO)
DUMPER TAPE #1 , , FRIDAY 1-NOV-88 330
LOADING FILES INTO
END OF SAVESET
____ _____
DUMPER>EXIT
$
3.2.4
3.2.4
The directory contains system programs (and their help files)
that the user may want to run. The directory protection code set for
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 . An
asterisk precedes all unbundled software.
Table 3-2: STR: Files
Table 3-2: STR: Files
__________________________________________________________________
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
Programs Explanation
CHECKD.EXE Program that creates structures and checks
file-system consistency (same as in ).
CHECKD.HLP Contains information about the CHECKD program.
CHKPNT.EXE Program that makes accounting entries in the file
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
.
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
Table 3-2: STR: Files (Cont.)
Table 3-2: STR: Files (Cont.)
Programs Explanation
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
AFTER SOFTWARE INSTALLATION
3.2.5 Restoring the Directory
3.2.5 Restoring the Directory
If the contents of 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
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)
______ _____ _____
$ASSIGN (DEVICE) MTA0:
____ _____ _ _____ _____
$SKIP (DEVICE) MTA0: 4 FILES
___ _____ _____
$RUN (PROGRAM) MTA0:
____ _____ _____
DUMPER> TAPE (DEVICE) MTA0:
____ _ _____
DUMPER> SKIP (NUMBER OF SAVESETS) 1
_______ _____________ ________
DUMPER> RESTORE (TAPE FILES) DSK*:<*>*.*.* (TO)
_____
DUMPER TAPE # 1 , , SATURDAY, 3-NOV-88 330
LOADING FILES INTO STR:
END OF SAVESET
____ _____
DUMPER> EXIT
$
3-16
AFTER SOFTWARE INSTALLATION
AFTER SOFTWARE INSTALLATION
3.2.6 and
3.2.6 and
The first time you install the TOPS-20 software, the DLUSER program
creates the directories and . 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 and 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 into the
directory and all the files in the directory
into the directory . You can now delete all the files in
and . The directories and
remain empty until a new version of the TOPS-20 software
is distributed.
NOTE
After you copy the new files into the directories
and , 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
AFTER SOFTWARE INSTALLATION
3.2.7 , , , and
3.2.7 , , , and
- After installation, the directory contains one
file, SYSTEM-DATA.BIN. This file contains all the accounting system
entries for each user. If the directory is destroyed, the
accounting system creates a new SYSTEM-DATA.BIN file.
After the first LOGIN on the system, the system creates the
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 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.
- The directory 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 may also contain files the operator needs to run
the system. - The directory 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.
- The directory 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
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
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.)
The directory 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 , users
will find it more convenient if you also create
the system-logical name NEW: defined as
PUB:, 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 , the system uses the version
currently on . (Refer to Section 3.3 for
a description of logical names.)
The directory can contain the old version
of software as newer versions appear on .
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:,SYS:, where PUB: is the system
structure.
By creating the directories and , you gradually introduce
new software to system users. When a new version becomes available,
place it in the directory . When the software has been in use
awhile, move the version in to , and the version in
to . Store the version in 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.
The directory contains documents and help
files that describe the system software. As
different versions of software appear on
, , and , you should make a
list of changes incorporated in the new versions
and place it in the directory . You can
move all files with the file type .HLP from
to the directory . The HELP
command still works correctly if you define the
system-logical name HLP: to be PUB:,SYS:,
where PUB: is the system structure.
3-19
AFTER SOFTWARE INSTALLATION
AFTER SOFTWARE INSTALLATION
The directory 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 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 avoids constant
interruptions to the operator from users issuing
PLEASE requests. The operator can read the
messages in at a specified time each
day, or simply when he has time.
3.3 SYSTEM-LOGICAL NAMES
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:, PUB:; SYSTEM:, defined as
PUB:, PUB:; 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
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
AFTER SOFTWARE INSTALLATION
3.3.1 SYSTEM:
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 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
. For example,
DEFINE SYSTEM: STR:,STR:
where:
STR: is the name of the system structure.
3.3.2 SYS:
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 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 . For example,
DEFINE SYS: STR:,STR:
where:
STR: is the name of the system structure.
Be sure to set the protection on the library files in (or
) to 777740. This protection allows access by all users.
3.3.3 NEW:
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:,SYS:
3-21
AFTER SOFTWARE INSTALLATION
AFTER SOFTWARE INSTALLATION
With this systemwide logical name, the user can give the command:
______ ____ ____ _____
@DEFINE (LOGICAL NAME) SYS: (AS) NEW:
Now, when the user runs a program, the system looks first in the
directory STR:, 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:
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:,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:
whenever he runs a program, he will get the oldest version available.
3.3.5 HLP:
3.3.5 HLP:
If you want to keep programs and documentation in separate
directories, you should store the documentation in . The HELP
command searches the directories identified by the logical name HLP:,
so you must define the logical name HLP: to be the directory .
The definition of HLP: in n-CONFIG.CMD should be:
DEFINE HLP: STR:
3.3.6 SERR:
3.3.6 SERR:
The logical name SERR: is defined by the system at startup. It points
to the area 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
AFTER SOFTWARE INSTALLATION
3.3.7 DMP:
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:
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:DUMP.EXE.1
to: PS60:DUMP-12345-WSPNEG.CPY.1
3.3.8 DEFAULT-EXEC:
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
AFTER SOFTWARE INSTALLATION
3.3.9 POBOX:
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:
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
AFTER SOFTWARE INSTALLATION
3.3.11 SPOOL:
3.3.11 SPOOL:
The logical name SPOOL: directs the system to the directory
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
.
3.4 CONSOLE FRONT-END FILES
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
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
Table 3-3: Console Front-End Files
__________________________________________________________________
File Contents or Function
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
AFTER SOFTWARE INSTALLATION
Table 3-3: Console Front-End Files (Cont.)
Table 3-3: Console Front-End Files (Cont.)
File Contents or Function
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
AFTER SOFTWARE INSTALLATION
Table 3-3: Console Front-End Files (Cont.)
Table 3-3: Console Front-End Files (Cont.)
File Contents or Function
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
AFTER SOFTWARE INSTALLATION
3.5 TAILORING THE BATCH SYSTEM
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 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)
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
AFTER SOFTWARE INSTALLATION
3.7 REMOTE PRINTERS
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
AFTER SOFTWARE INSTALLATION
3.7.1 Remote Printing Requirements
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
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
AFTER SOFTWARE INSTALLATION
3.7.2 Defining DQS and LAT Printers
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 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
AFTER SOFTWARE INSTALLATION
3.7.3 Setting DQS Printing Characteristics
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 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
AFTER SOFTWARE INSTALLATION
3.8 TERMINAL PRINTERS
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:
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
CHAPTER 4
CREATING STRUCTURES
CREATING STRUCTURES
4.1 OVERVIEW
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
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
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?
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
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
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 or .
2. A (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 and
(Sections 3.2.2 and 3.2.4).
4. The directories , , ,
, and (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
. 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
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 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
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
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
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
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 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
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
CREATING STRUCTURES
Table 4-1: Differences Between Mountable and System Structures
Table 4-1: Differences Between Mountable and System Structures
__________________________________________________________________
System Structure Mountable 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 , , Need not have these directories
, , unless the structure will be
, and 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
Table 4-2: Similarities Between Mountable and System Structures
__________________________________________________________________
System Structure Mountable 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
CREATING STRUCTURES
System Structure Mountable Structures
System Structure Mountable Structures
Has a Has a
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
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
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
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
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
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
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
CREATING STRUCTURES
Table 4-3: Sample Device Names
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
CREATING STRUCTURES
4.5.2 Mounting Structures Having the Same Name
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
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
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
CREATING STRUCTURES
Table 4-4: Maximum Size Structures
Table 4-4: Maximum Size Structures
__________________________________________________________________
Type of Max.No.Packs No. Pages
Type of Max.No.Packs No. Pages
Disk Drive Per Structure Per Pack
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
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
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
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
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
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
CREATING STRUCTURES
4.5.7 Mounting Structures from Another Installation
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
Figure 4-3: Domestic and Foreign Structures
4-16
CREATING STRUCTURES
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
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
CREATING STRUCTURES
______________
/ /|
/_____________/ |
| | |
---------- A --->| Dual-Ported | |<--- B ----------------------
| | DRIVE | | |
| |_____________|/ |
| |
| ______________ ______________ |
| | | | | |
------| DECSYSTEM-20 | | DECSYSTEM-20 |-----
|______________| |______________|
| |
| |
_____|_____ _____|_____
| | | |
| FRONT-END | | FRONT-END |
|___________| |___________|
Figure 4-4: Shared Disk Drive
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
CREATING STRUCTURES
4.7 DETERMINING SWAPPING SPACE ON THE SYSTEM STRUCTURE
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?
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
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
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
Table 4-5: Determining Swapping Space
__________________________________________________________________
Estimated Recommended Number of
Estimated Recommended Number of
Number of Jobs Pages for Swapping*
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
CREATING STRUCTURES
4.8 DETERMINING THE AVAILABLE DISK SPACE
4.8 DETERMINING THE AVAILABLE DISK SPACE
4.8.1 Determining Disk Space Before Installation
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 and directories
increases. Also, the number of pages reserved for
directory 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 area.
4-21
CREATING STRUCTURES
CREATING STRUCTURES
Table 4-6: Calculating Available Disk Space
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) |
| |
| = 1876 |
| = 1780 |
| = 2 |
|