Digital PDFs

AA-M547A-TE

December 1982

272 pages

Original

12MB

Document:	VAX/VMS System Management and Operations Guide
Order Number:	AA-M547A-TE
Revision:
Pages:	272
Original Filename:	http://bitsavers.org/pdf/dec/vax/vms/3.0/AA-M547A-TE_VAX_VMS_3.0_System_Management_and_Operations_Guide_198205.pdf

OCR Text

VAX/VMS
System Management
and Operations Guide
Order No. AA-M547 A-TE

May 1982
This document describes the following tasks of system management with
the aim of providing required information and guidelines for efficient operations: 1) setting up users' accounts, 2) managing public files and volumes,
3) controlling printing and batch operations, 4) monitoring and tuning
system activity, 5) recognizing and responding properly to system errors
and failures.

REVISION/UPDATE INFORMATION:

This document supersedes the
VAX/VMS System Manager's Guide
(AA-00278-TE) and the VAX/VMS
Operator's Guide (AA-00258-TE).

SOFTWARE VERSION:

VAX/VMS Version 3.0

digital equipment corporation · maynard, massachusetts

First Printing, May 1982
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 be used or copied only 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

The postpaid READER'S COMMENTS form on the last page of this document
requests the user's critical evaluation to assist in preparing future
documentation.
The following are trademarks of Digital Equipment Corporation:
DEC
DEC/CMS
DECnet
DECsystem-IO
DECSYSTEM-20
DEC US
DECwriter

DIBOL
EduSystem
!AS
MASSBUS
PDP
PDT
RSTS

RSX
UNIBUS
VAX
VMS
VT

mamaama
ZK2156

HOW 10 ORDER ADDITIONAL DOCUMENTATION
In Continental USA and Puerto Rico call 800-258-1710

DIRECT MAIL ORDERS (CANADA)

In New Hampshire, Alaska, and Hawaii call 603-884-6660

Digital Equipment of Canada Ltd.
940 Belfast Road .
Ottawa, Ontario K1G 4C2
Attn: A&SG Business Manager

In Canada call 613-234-7726 (Ottawa-Hull)
800-267-6146 (all other Canadian)
DIRECT MAIL ORDERS (USA & PUERTO RICO)*

Digital Equipment Corporation
P.O. Box CS2008
Nashua, New Hampshire 03061

DIRECT MAIL ORDERS (INTERNATIONAL)

Digital Equipment Corporation
A&SG Business Manager
c/o Digital's local subsidiary or
approved distributor

*Any prepaid order from Puerto Rico must be placed
with the local Digital subsidiary (809-754-7575)
Internal orders should be placed through the Software Distribution Center (SOC), Digital Equipment
Corporation, Northboro, Massachusetts 01532

CONTENTS

Page
PREFACE

xiii

SUMMARY OF TECHNICAL CHANGES

xvii

1. 0
2.0
3.0
4.0
CHAPTER 1

INFORMATION RELOCATED WHEN THE MANUALS WERE
COMBINED • • • • • • • • • • • • •
TECHNICALLY CHANGED INFORMATION
NEW INFORMATION • • • • • •
MISCELLANEOUS IMPROVEMENTS • • • •
INTRODUCTION

OVERVIEW OF SYSTEM MANAGEMENT • • •
1.1
System Management Tasks
• •
1.1.1
1.1. 2
Operational Tasks ~ • • • • •
1. 2
MANAGING THE VAX/VMS ENVIRONMENT • •
1. 2.1
VAX/VMS Components • • • • • • • •
1. 2. 2
Privileges • • • • • • • • • • •
1. 2. 3
DIGITAL Command Language Commands
1.2.3.1
Command Line Format
1.2.3.2
Summary of DCL Commands
1. 3
UTILITIES • • • •
CHAPTER 2
2.1
2.2
2.3
2.4
2.4.1
2.4.2
2.4.3
2.4.4
2.4.5
2.4.6
2.5
2.6
2.7
CHAPTER 3
3.1
3.2
3.3
3.4
3.4.1
3.4.2
3.4.3
3.4.4

xvii
xvii
xv ix
xv ix

• • • • • • •
•
• • • • • • •
• • • • • • •
• • • • • • •
• •••••
• • • • • • •
•
• • • • • •
• • • • • •

1-1
1-2
1-2
1-3
1-3
1-4
1-4
1-4
1-5
1-9

AUTHORIZING SYSTEM USERS
THE USER AUTHORIZATION FILE
LOGIN SEQUENCE • • • •
• • • •
• • • • •
GENERAL MAINTENANCE OF THE UAF
ADDING A USER ACCOUNT
• • • • •
Name and Password
• • • •
•
User Identification Code •
User Directory and Default File Specification
Login Command Procedures • •
• •••
Logout Command Procedures
Authorize Utility
DELETING A USER ACCOUNT
DISABLING A USER ACCOUNT •
• • • • • • • •
ALTERNATE LOGIN PROCEDURES

•
•
•
•
•
•
•
•
•

2-1
2-2
2-3
2-4
2-5
2-6
2-6
2-7
2-9
2-10
2-11
2-12
2-13

•
SPECIFICATION OF UIC • • • • • • • • •
•
SPECIFICATION OF PROTECTION • • • • •
USER ACCOUNTS AND PROCESSES
• • • • • • • •
•
FILES-11 FILES • • • • • • • • • • • •
•
Default Protection of Files • • • •
Explicit Protection of Files •
•
Directory Protection • • • • • •
• • • • • •
Mail File Protection •
• ••• • • • • • •

3-2
3-3
3-5
3-6
3-6
3-6
3-7
3-7

UIC-BASED PROTECTION

iii

CONTENTS
Page
3.6
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.18
CHAPTER 4
4.1
4.1.1
4.1. 2
4.1.3
4.1. 4
4.1. 5
4.1.6
4.1. 7
4.1.8
4.1.9
4.1.10
4. 1. 11
4.1.12
4.1.13
4.2
4.3
4.3.1
4.3.2
4.3.3
4.3.4
4.3.5
4.3.6
4.3.7
4.3.8
4.3.9
4.3.10
4.3.11
4.3.12
4.3.13
4.3-.14
4.3.15
4.3.16
4.3.17
4.3.18
4.3.19
4.3.20
4.3.21
4.3.22
4.3.23
4.3.24
4.3.25
4.3.26
4.3.27
4.3.28
4.3.29
4.3.30
4.3.31
4.4

SECTIONS • • • • • • • • •
COMMON EVENT FLAG CLUSTERS
STRUCTURED VOLUMES • • • •
FOREIGN VOLUMES
NON-FILE DEVICES • • •
DEVICE ALLOCATION • • • •
INTERPROCESS CONTROL •
LOGICAL NAMES • • • •
STATUS INFORMATION •
FORMING GROUPS • • •
SECURING SYSTEM DATA •
SECURING SYSTEM DEVICES · •
PROTECTING USER FILES

•
• • • • 3-8
•
• • • • • 3-8
• • • • •
• • • • • 3-9
• • • • • •
3-10
3-11
3-11
3-11
• • • • • • • •
3-13
3-14
3-14
. . . . . . . . .
3-15
• • • • • • •
3-16
• • • • 3-16

RESOURCE CONTROL
LIMITS ON REUSABLE SYSTEM RESOURCES
• • • • 4-1
AST Queue Limit (ASTLM)
• • • • •
• • • • 4-2
Buffered I/O Count Limit (BIOLM) •
• • • • 4-2
Buffered I/O Byte Count Limit (BYTLM)
• • 4-2
CPU Time Li~it (CPULM) • • • •
• • • • • 4-3
Direct I/O Count Limit (DIOLM) • • • • • • • • • 4-3
Enqueue Quota (ENQLM)
• • • • • • • •
• • 4-3
Open File Limit (FILLM)
• • • • • 4-4
Paging File Limit (PGFLQUOTA)
• • • • • • • • • 4-4
Subprocess Creation Limit (PRCLM)
• 4-4
Timer Queue Entry Limit {TQELM)
• • • • • 4-4
Working Set Default (WSDEFAULT)
• • 4-4
Working Set Extent (WSEXTENT)
• • • • • • • • • 4-5
Working Set Quota (WSQUOTA)
• • • • • •
• 4-5
PRIORITY • • • • • • •
• • • • • • • • • 4-5
PRIVILEGES • • • • • • • • •
• • • • • • • • • 4-6
ACNT Privilege • • •
• • • • •
• • 4-8
ALLSPOOL Privilege •
• • • • • • • • • 4-8
ALTPRI Privilege • • • • • • • • •
• • • • • 4-8
BUGCHK Privilege •
• • • • • • • • • 4-9
BYPASS Privilege •
• • • • •
• 4-9
CMEXEC Privilege •
• • • • • • • • • • • • • 4-9
CMKRNL Privilege •
• • • • • • •
4-9
DETACH Privilege •
• • • • •
4-10
DIAGNOSE Privilege •
• • • • •
4-10
EXQUOTA Privilege
• • • •
• • • •
4-10
GROUP Privilege
• • • •
4-10
GRPNAM Privilege •
• • • • •
4-10
LOG IO Privilege • • • • •
• • • •
4-11
MOUNT Privilege
• • • •
4-11
NETMBX Privilege • • • •
• • • • •
4-11
OPER Privilege • •
• • • •
4-11
PFNMAP Privilege •
• • • •
4-12
PHY IO Privilege •
• • • •
4-12
PRMCEB Privilege •
• • • • •
4-12
PRMGBL Privilege • • • • • • • • •
• • • •
4-13
PRMMBX Privilege •
4-13
PSWAPM Privilege •
• • • • •
4-13
SETPRV Privilege • • • • •
• • • • • •
4-14
SHMEM Privilege
• • • • •
4-14
SYSGBL Privilege • • • • •
• • • • •
4-14
SYSLCK Privilege •
• • • • • • • •
4-14
SYSNAM Privilege • • • • • • • • • •
4-14
SYSPRV Privilege • • • • • • • • • • • •
4-15
TMPMBX Privilege •
• • • • • • • •
4-15
VOLPRO Privilege •
• • • • • • • • •
4-15
WORLD Privilege • • • • • • • • • • • •
4-16
ACCOUNTING FOR THE USE OF SYSTEM RESOURCES • • • 4-16
iv

CONTENTS
Page
CHAPTER 5

MAINTAINING PUBLIC FILES AND VOLUMES

5.1
5.1.1
5.1.2
5.1.3
5.1.4
5.1.5
5.1.6
5.1.7
5.1.8
5.1.9
5.1.10

FILES-11 DISK STRUCTURE • • • • • •
• 5-2
Index File • • • • • • • • • • • • • • • • • • • 5-2
Storage Bit Map File •
• • • • • • • • 5-3
Bad Block File • • • • -·
• 5-3
Master File Directory
• 5-3
Core Image File
• • • • •
• • • • • 5-4
Volume Set List File •
• • • • • 5-4
Continuation File • • • • • • • • • • •
• • 5-4
Back-up Log File • •
• • • •
• • • • • 5-4
Pending Bad Block Log File
• • • • • • • • • 5-4
Files-11 Structure Level 1 Versus Structure
Level 2 • • • • • • • • • • • • •
• • • • • 5-4
5.2
SETTING UP PUBLIC FILE STRUCTURES • •
• • 5-5
Deciding Where to Put User Files • •
• 5-5
5.2.1
5.2.2
Should You Use Volume Sets?
• • • •
• 5-6
Should You Make the System Disk Part of a Volume
5.2.3
Set? • • • • • • • • • • .
• • • • •
• 5-6
FORMATTING DISKS • • • • • •
• 5-7
5.3
INITIALIZING PUBLIC VOLUMES • • • • • • • • • • • 5-7
5.4
/ACCESSED Qualifier
• • • •
• • 5-7
5.4.1
5.4.2
/CLUSTER SIZE Qualifier
• • • • • • • • 5-8
5.4.3
/EXTENSION Qualifier • • •
• • • • • • • • • 5-8
/HEADERS Qualifier • • •
• • • • • • • • • 5-8
5.4.4
5.4.5
/INDEX Qualifier • • • •
• • • • • • • • • 5-8
5.4.6
/MAXIMUM FILES Qualifier
• • • •
• 5-8
5.4.7
/WINDOW Qualifier
• • • • •
5-8
5.5
MOUNTING PUBLIC VOLUMES • • • • • • • • • • • • • 5-9
5.5.1
/ASSIST Qualifier
• • • • • • • • • • • • • 5-9
5.5.2
/COMMENT Qualifier • • • •
• • • • • • • • 5-9
5.5.3
/MOUNT VERIFICATION Qualifier
• • • • • • • •
5-10
5.5.4
/PROCESSOR Qualifier • • • • • •
5-10
MAINTAINING VOLUME INTEGRITY • •
• • • • • •
5-10
5.6
5.7
MOUNT VERIFICATION • • • • • • • •
• • • • •
5-11
5.7.1
Device Offline Mount Verificaton • •
5-11
5.7.2
Device Write-Lock Mount Verification • • • • •
5-12
Cancelling Mount Verification • • • ~ • • • •
5-13
5 ·' 7. 3
5.7.3.1
MVTIMEOUT System Parameter • • • • • • • • •
5-14
5.7.4
Cancellation Commands
• • • • • • • • • • • •
5-14
5.7.5
Dismounting the Volume to Abort Mount
5-15
Verification • • • • • •
• ••••••
5.8
5-16
BACKING UP PUBLIC VOLUMES
• • • • • • • •
5.8.1
5-17
Rotating Back-up Sets • • • • • • • • •
5.8.2
Backing Up Disk Volumes • • • • • • • • • • •
5-18
5.8.3
Backing Up the System Disk (Using Stand-alone
BACKUP)
• • • • • • • • •
• • • • • • •
5-18
5.8.4
Restoring the System Disk (Using Stand-alone
BACKUP)
• • • • • • • • • • • • • • • •
5-18
5.8.5
Backing Up a Public Disk to Disk • • • •
5-18
5.8.6
Selective Back-Up of Files Using BACKUP
5-21
5.8.7
Incremental Back-ups • • • • • •
5-22
5.8.8
Performing Daily Back-up Operations
• • • • •
5-23
5.8.9
Performing Weekly Back-up Operations • • •
5-23
5.8.10
Performing Monthly Back-up Operations
5-23
5.8.11
Backing Up and Restoring the Console Medium
5-24
5.8.12
Sequential Disk Save Sets
• • • • • • •
5-24
5.8.12.1
Saving Data to Sequential Disk Save sets • •
5-24
5.8.12.2
Restoring Data from Sequential Disk Save Sets 5-25
5.8.12.3
Summary • • • • • • • • • • • •
5-25
5.9
BACKUP JOURNAL FILES • • • • • • • • • • • •
5-26
5.9.1
Backing Up Volumes and Volume Sets • • • •
5-27
5.9.1.1
Backing Up An Entire Volume Set
• • • •
5-28
5.9.1.2
Backing Up a Disk Volume Set When Drives Are
5-28
Limited
• • • • • • • • • • • • • • • •

CONTENTS
Page
Restoring Entire Disk Volumes • • • • • • • •
Changing Volume Initialization Parameters
Before Restoring • • • • • • • • • • • • • •
5.9.2.2
Restoring a Volume From Incremental Back-ups
5.9.3
Restoring Individual Files
• • • •
5.9.4
BACKUP Media Security • • • • • • • • • •
5.10
DISK SPACE MANAGEMENT
5.10.1
File Expiration • • • • • • • • • • • • •
5.10.2
Disk Quotas • • • • • • • • • • •
5.10.2.1
Disk Quota Operations • • • • • • • • •
5.10.2.1.1
Exceeding the Quota
5.10.2.1.2
Suspending Quotas
••••••••
5.10.2.1.3
Ensuring Quota File Accuracy with REBUILD
on Mount • • • • • • • • • • • • • • •
5.10.2.2
Restrictions on Other System Operations
5.11
ACCESSING TAPE AND DISK VOLUMES
5.12
REQUESTS 'TO MOUNT VOLUMES • • • • • •
5.12.1
Requests from the MOUNT Command
5.12.2
Requests from the Magnetic Tape File System
5.12.3
Requests from the Backup Utility
• • •
5.12.3.1
Writing to a Save Set
• • • • • • • • •
5.12.3.2
Reading from a Save Set • • • • • • • • • •
5.12.3.3
Recovering from an Error • • • • • • • • • •
5.12.4
Notification of Volume Mounts and Dismounts
5.9.2
5.9.2.1

CHAPTER 6

5-29
5-30
5-31
5-31
5-32
5-32
5-33
5-33
5-34
5-34
5-34
5-34
5-34
5-35
5-36
5-37
5-37
5-38
5-38
5-38
5-39

INSTALLING IMAGES AS KNOWN IMAGES

6.1
EXECUTABLE AND SHAREABLE IMAGES
• • • •
•
6.2
KNOWN FILE LISTS • • • • • •
• • • • • • • •
OPERATIONAL CONSIDERATIONS •
• • • • • • • •
6.3
6.3.1
Start-up Procedures
• • • • • • • •
Order of Installation •
• • • • • • • •
6.3.2
6.3.3
Privileges • • • • • • • • • •
•
6.3.3.1
Privileged Executable Images
• • • •
Privileged Shareable Images • • • • • • • • •
6.3.3.2
6.3.4
Deleting Known Images and Dismounting Volumes •
6.3.5
Shareable Image Files • • • • • • • • • • • • •
6.3.6
MA 780 Multi po rt Memory • • • • • • • • • • • • •

CHAPTER 7

5-29

6-1
6-2
6-2
6-3
6-3
6-3
6-3
6-3
6-4
6-4
6-5

START-UP AND SHUTDOWN

RESTARTING THE OPERATING SYSTEM • • • • • • • • • 7-1
The Start-up Command Procedure • • • • • • • • • 7-1
Bootstrapping to Restart the System
• 7-1
Boostrapping the System with an Alternate
STARTUP Command File •
• •••
• • • 7-2
7.1.4
Restarting Problems • • • • • • • •
• 7-2
7.1.4.1
Hardware Problems • • • •
• • • 7-2
7.1.4.2
• 7-2
Software Ptoblems • • • •
7.2
SHUTTING DOWN THE OPERATING SYSTEM • • • • •
• 7-3
7.2.1
Orderly Shutdown of the System (With
SHUTDOWN.COM)
• • • • • • •
• • • • • • 7-3
7.2.2
Emergency Shutdown of the System (with OPCCRASH) 7-6
7.2.3
Forcing the System to Fail (with CRASH or its
Equivalent)
• • • • • • • • • • • • • • • • • • 7-7
7.3
START-UP COMMAND PROCEDURES • • • • • • • • • • 7-10
7.3.1
Site-independent Start-up Command Procedure
7-10
7-10
7.3.1.1
Housekeeping Chores • • • • • • • • • •
Symbolic Debugger • • • • • • • • • • • • • 7-11
7.3.1.2
7.3.1.3
RSX-llM Programs • • • • • • • • • • • • • • 7-11
7.3.1.4
System Libraries and Help Files • • • • • • 7-11
7.3.1.5
Error Logging, Job Controller, and Operator's
Log • • • • • • • • • • • • • • • • • • • • 7-11
7.1
7.1.1
7.1.2
7.1.3

CONTENTS
Page
7.3.1.6
7.3.1.7
7.3.1.8
7.3.1.9
7.3.1.10
7.3.2
7.3.2.1
7.3.2.2
7.3.2.3
7.3.2.4
7.3.2.5
7.3.2.6
7.3.2.7
7.3.2.8
7.3.2.9
7.3.2.10
7.3.2.11

Known Images • • • • • • • • •
I/O Devices and Drivers
VAX-11 RMS File Sharing
Install Deferred Swapping File if Present
Termination of the Procedure • • • • • •
Site-specific Start-up Command Procedure •
Disable Error Processing • • • • • • •
Public Disks • • • • • • • • • • • • •
Logical Names • • • • • • • • • • • • •
Optional Software Logical Name Requirements
Device Characteristics •
• ••••
Queues • • • • • • •
Known Images • • • •
System Dump Analyzer • •
Operator's Log File • • • • •
Standard Batch Jobs • • • •
Manually Connected Devices and Multiport
Memory Units • • • • • • •
• •••
7.3.2.12
VAX-11 RMS File Sharing
••••
7.3.2.13
Secondary Paging and Swapping Files • • • •
7.3.2.14
Announcements
SYS$ANNOUNCE •
7.3.2.14.1
7.3.2.14.2
SYS$WELCOME
7.3.2.15
Redefining the Number of Interactive Users •
CHAPTER 8
8.1
8.1.1
8.1. 2
8.2
8.2.1
8.2.2
8.2.3
8.2.4
8.2.5
8.2.6
8.2.7
8.3
8.3.1
8.3.2
8.3.3
8.3.4
8.3.5
8.3.6
8.3.7
8.3.8
8.3.9
8.3.10
8.3.11
8.3.12
8.3.13
8.4
8.5
8.5.1
8.5.2
8.5.3
8.5.4
8.5.5

7...;11
7-12
7-12
7-12
7-12
7-12
7-12
7-13
7-13
7-13
7-14
7-14
7-14
7-15
7-15
7-15
7-15
7-16
7-16
7-16
7-16
7-16
7-17

BATCH AND PRINT JOBS

............
.. 8-2
.
.
8-3
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8-4
. . . . . . . . . . . . .. 8-4
.
.
.
.
.
8-5
.
.
.
. . . . . . . . . . . . .. 8-5
8-5
.
8-6
....
. . . . .. 8-6
8-6

SPOOLING
Establishing Spooled Devices
Turning Off Spooling
BATCH JOBS
Creating Batch Queues
Starting Batch Queues
Stopping Batch Queues
Deleting Batch Queues
Emptying the Queue File
Batch Versus Interactive Jobs
Setting Up Batch Queues
PRINT QUEUES
Creating Print Queues
Starting Print Queues
Stopping Print Queues
Deleting Print Queues
Emptying the Queue File
Assigning a Named, or Logical, Print Queue to a
Printer
Deassigning a Named, or Logical, Print Queue
from a Printer
Adjusting Vertical Page Size
Page Length of Native Mode Image Listings
Page Length of Compatibility Mode Image
Listings
Forms Control
Printer Characteristics
Guides to Setting Up Print Queues and Spooled
Line Printers
COMMANDS FOR CONTROLLING PRINT AND BATCH QUEUES
PROCEDURES FOR CONTROLLING PRINT AND BATCH QUEUES
Merging Print Queues
Preventing Loss of Data When the Line Printer
Runs Out of Paper
Terminating the Execution of a Batch Job
Terminating the Printing of a Print Job
Removing a Batch or Print Job from a Queue

......

. 8-7
. . .. .. . . .8-10
8-9
.. .. .. .. . . . . .. .. .. .. 8-10
8-10
.
.
.
8-10
.
.
.
. . . . . . . . 8-11

............
. . . . . . . .. .. .. .. .. .. ..
. . . .. .. .. .. .. .. . . . . .. .. .. .
.
. ..

8-11
8-11
8-11
8-11
8-12
8-12
8-13

... . .
. . . . . . . . . . . . . . . . 8-13
8-19
8-20
. . . . . . . . . . . . . 8-20
. . . . . . . . . . . ..
8-21
8-22

vii

8-23
8-23

CONTENTS
Page
8.5.6
Restarting the Job Controller
8.6
USING THE CARD READER
8.6.1
Types Of Card Decks
• • • • •
8.6.1.1
Batch Job Carp Deck
• • • • •
Checking Batch Job Card Deck
8.6.1.1.1
Checking Batch Job Output
•
8.6.1.1.2
A Data Card Deck • • • • • • •
8.6.1.2
8.6.2
Card Reader Translation Modes
•
8.6.3
Tending The Card Reader
Replacing Physically Defective
8.6.3.1
8.6.3.2
Operating the Card Reader
CHAPTER 9

• ••••
• • • • •
Input •
• • •
•
• • • •
• • • • • • •
••••
Cards •
• • • • •

8-24
8-24
8-25
8-25
8-25
8-25
8-26
8-26
8-26
8-27
8-27

ERRORS AND OTHER SYSTEM EVENTS

ERROR LOG
• • • • •
• 9-1
9.1
Operations • •
• • • • • • • • •
. 9-1
9.1.1
Using Error Reports • • • •
• • • • • • • • 9-2
9.1. 2
Maintaining the Error Log Files • • • • • • • • 9-3
9.1. 3
9.1. 4
Printing The Error Log File
• • 9-3
OPERATOR'S LOG FILE • • • • • • • •
• • 9-6
9.2
Maintaining The Operator's Log File
• • 9-7
9.2.1
Printing The Operator's Log File • • • • • • • • 9-7
9.2.2
9.2.3
Restarting OPCOM • • • • •
• • • • • • 9-8
9.2.4
Messages in the Operator's Log File
• 9-8
Initialization Messages • • • • • • • • • • • 9-9
9.2.4.1
9.2.4.2
Device Status Messages • • • • • • • • • • • • 9-9
Terminal Enable and Disable Messages •
• 9-9
9.2.4.3
9.2.4.4
Volume Mount and Dismount Messages •
9-10
9.2.4.5
User Request and Operator Reply Messages
9-10
Changes to System Parameters Through the'
9.2.4.6
SYSGEN Utility • • • • •
• ••••
9-11
9.2.4.7
DECnet-VAX Messages
9-11
REPORTING SOFTWARE PROBLEMS • • • •
9-11
9.3
9.3.1
9-13
The Problem Environment
9.3.2
Limiting the Problem Scope
9-13
9-13
9.3.3
Machine-readable Files • •
9.3.4
9-14
System Environment • • • •
User Analysis (Optional) •
9-14
9.3.5
9.3.6
Problem-specific Information to Include
9-14
CHAPTER 10

SYSTEM PARAMETERS

10.1
PARAMETER CATEGORIES
• • • • •
10-1
10.2
PARAMETERS • • • • •
• • • • • • • • • 10-12
10.2.1
ACP BASEPRIO Parameter •
• • • •
• 10-12
10.2.2
ACP-DATACHECK Parameter
• • • • 10-12
10.2.3
ACP-DIRCACHE Parameter •
• • • • •
10-13
10.2.4
ACP-EXTCACHE Parameter • •
• • • • • • • • 10-13
10.2.5
ACP-EXTLIMIT Parameter •
• 10-13
ACP-FIDCACHE Parameter • •
• 10-13
10.2.6
10.2.7
ACP-HDRCACHE Parameter •
• • • • 10-13
10.2.8
ACP MAPCACHE Parameter • • • • • • • • • • • • 10-14
ACP-MAXREAD Parameter
• • • •
• 10-14
10.2.9
10.2.10
ACF-MULTIPLE Parameter •
• • • • •
• 10-14
ACP-QUOCACHE Parameter •
• 10-14
10.2.11
ACP-SHARE Parameter
• • • •
• • • •
• 10-14
10.2.12
10.2.13
ACP-SWAPFLGS Parameter •
• • • • •
• 10-14
10.2.14
ACP-SYSACC Parameter •
• • • •
• • 10-15
10.2.15
ACF-WINDOW Parameter •
• • • • • 10-15
10.2.16
ACP-WORKSET Parameter • • • • • • • • • • • • 10-15
10.2.17
ACP-WRITEBACK Parameter
• • • •
• 10-15
10.2.18
AWSMIN Parameter •
•
• • 10-15
10.2.19
AWSTIME Parameter • • • • • • • • • • • • • • 10-16
viii

CONTENTS
Page

10.2.20
10.2.21
10.2.22
10.2.23
10.2.24
10.2.25
10.2.26
10.2.27
10.2.28
10.2.29
10.2.30
10.2.31
10.2.32
10.2.33
10.2.34
10.2.35
10.2.36
10.2.37
10.2.38
10.2.39
10.2.40
10.2.41
10.2.42
10.2.43
10.2.44
10.2.45
10.2.46
10.2.47
10.2.48
10.2.49
10.2.50
10.2.51
10.2.52
10.2.53
10.2.54
10.2.55
10.2.56
10.2.57
10.2.58
10.2.59
10.2.60
10.2.61
10.2.62
10.2.63
10.2.64
10.2.65
10.2.66
10.2.67
10.2.68
10.2.69
10.2.70
10.2.71
10.2.72
10.2.73
10.2.74
10.2.75
10.2.76
10.2.77
10.2.78
10.2.79
10.2.80
10.2.81
10.2.82
10.2.83
10.2.84

BALSETCNT Parameter
• •
BJOBLIM Parameter
•
BORROWLIM Parameter
BUGCHECKFATAL Parameter
BUGREBOOT Parameter
• •
CLISYMTBL Parameter
CRDENABLE Parameter
DEADLOCK WAIT Parameter
DEFMBXBU~QUO Parameter •
DEFMBXMXMSG Parameter
•
DEFMBXNUMMSG Parameter
DEFPRI Parameter • • • •
DISMOUMSG Parameter
• •
DUMPBUG Parameter
EXTRACPU Parameter • •
FREEGOAL Parameter •
FREELIM Parameter
GBLPAGES Parameter • • •
GBLPAGFIL Parameter
• •
GBLSECTIONS Parameter
•
GROWLIM Parameter
IJOBLIM Parameter
INTSTKPAGES Parameter
IRPCOUNT Parameter • •
IRPCOUNTV Parameter
• •
JOBQUEUES Parameter
KFILSTCNT Parameter
• •
LAMAPREGS Parameter
• •
LOCKIDTBL Parameter
LOGGHASHTBL Parameter
LOGPHASHTBL Parameter
•
LOGSHASHTBL Parameter
•
LONGWAIT Parameter •
LRPCOUNT Parameter • • •
LRPCOUNTV Parameter
• •
LRPSIZE Parameter
MAXBUF Parameter • • • •
MAXPRINTSYMB Parameter •
MAXPROCESSCNT Parameter
MAXSYSGROUP Parameter
MINWSCNT Parameter • • •
MOUNTMSG Parameter • •
MPW HILIMIT Parameter
MPW-LOLIMIT Parameter
•
MPW-THRESH Parameter • •
MPW-WAITLIMIT Parameter
MPW-WRTCLUSTER Parameter
MVTIMEOUT Parameter
• •
NJOBLIM Parameter
NPAGEDYN Parameter •
NPAGEVIR Parameter •
PAGEDYN Parameter
PAGFILCNT Parameter
PAPOLLINTERVAL Parameter
PAPOOLINTERVAL Parameter
PASTDGBUF Parameter
PASTIMOUT Parameter
• •
PASTRETRY Parameter
PFCDEFAULT Parameter
PFRATH Parameter • • •
PFRATL Parameter • • •
PQL_DASTLM Parameter •
PQL DB IOLM Parameter •
PQL-DBYTLM Parameter • •
PQL=DCPULM Parameter •
iv

• •
• • • •
• •
• •
• •
• •
• •
• •
• •

• •
• •
• •

• •
• •
• •
• •
• •
• •
• •

• •
••••••••
• •
• ••••
• •
• •
•••••••••
• •
• ••••
• • • • •
•
• ••••
• • • •
•
• • • • •
•
•
• ••
• •
• • • • •
• • • • •
• ••
•••••
•
•
• •
• • • • •
• •
•••••
•••••
•
• • • •
• ••
• ••••
• • •
•
• • •
•
• • • • • • • • •
• • • • •
• •
• •
• • • •
• •
•
• • • •
• • •
• • • • •
•

• • • •

• • •
• • • •
• • • •
• • • • • •
•
• • •
• • • •
• • • • •
• •
•
•
• •
•

• • • •
• • • •
• •
• • • •
• • •

• • • •
• • •
• • • • •

••
• • •
• ••
••
• • • • •
• • • • •
•
• •
•••••
• •
• • • • •
•
• •••
•
• •
• • • • •
•
• •
••
• ••
• ••
• • • • •
• • • •
•
• •
• • • • •
• • • •
• • • • •
• •
•
•
• ••
• ••

10-16
10-16
10-16
10-16
10-17
10-17
10-17
10-17
10-17
10-17
10-18
10-18
10-18
10-18
10-18
10-18
10-18
10-19
10-19
10-20
10-20
10-20
10-20
10-21
10-21
10-21
10-21
10-21
10-22
10-22
10-22
10-22
10-22
10-23
10-23
10-23
10-23
10-24
10-24
10-24
10-24
10-24
10-24
10-25
10-25
10-25
10-25
10-26
10-26
10-2 6
10-26
10-26
10-27
10-27
10-27
10-27
10-27
10-28
10-28
10-28
10-28
10-29
10-2 9
10-29
10-29

CONTENTS
Page
10.2.85
10.2.86
10.2.87
10.2.88
10.2.89
10.2.90
10.2.91
10.2.92
10.2.93
10.2.94
10.2.95
10.2.96
10.2.97
10.2.98
10.2.99
10.2.100
10.2.101
10.2.102
10.2.103
10.2.104
10.2.105
10.2.106
10.2.107
10.2.108
10.2.109
10.2.llO
10.2.lll
10.2.ll2
10.2.ll3
10.2.ll4
10.2.ll5
10.2.ll6
10.2.ll7
10.2.ll8
10.2.ll9
10.2.120
10.2.121
10.2.122
10.2.123
10.2.124
10.2.125
10.2.126
10.2.127
10.2.128
10.2.129
10.2.130
10.2.131
10.2.132
10.2.133
10.2.134
10.2.135
10.2.136
10.2.137
10.2.138
10.2.139
10.2.140
10.2.141
10.2.142
10.2.143
10.2.144
10.2.145
10.2.146
10.2.147
10.2.i48
10.2.149

. . .. .. . . .. .. 10-29
....
. 10-29
10-30
..
. . .. 10-30
10-30
..
.
10-30
. .. .. 10-30
10-30
.........
. . . . . . .. .. .. .. 10-31
10-30
.. .. .. .. .. . . . .
. 10-31
10-31
.. . . . . .. . . . . . . .. 10-31
10-31
. .. . . . .
.. .. 10-31
.
. .. 10-32
10-32
10-32
.. .. .. . . .. . . .
10-32
.
.. . . . . . . . . . .. 10-32
10-32
.. 10-33
. . . .. .. .. . .
10-33
.
.
.
10-33
.
.
10-33
. . .. .. .. . . . .. .. .. .. .. 10-33
10-34
.. 10-34
. .. ... ... ... .. . .
10-34
10-34
.
.. . . . . . . .
.. 10-34
10-34
..
. . . . .. 10-34
10-35
.. .. .. .. . . . . . . . .. 10-35
.. 10-35
10-35
.
10-35
.. .
10-35
.. .. .. .. .. . . . . . . ... 10-36
10-36
.
. . . . . . .. 10-36
......
10-36
.. 10-36
10-47
10-37
.
...
10-37
. . . . . . .. .. . . . ... 10-37
10-38
10-38
. .. . . . .. 10-38
.
.
.
.
.
.
.
. . . . . . . .. . . . .. 10-38
10-38
.
10-39
.. .. .. .. . ... 10-39
10-39
.. 10-39
10-39
. . . . .. .. .. .. . . .
.. . . . . .. .. .. .. .. 10-40
10-41
.....
. .. 10-41
10-41
.. . . . . .
. .. 10-41
10-41
......
. 10-41

PQL DDIOLM Parameter • •
PQL-DENQLM Parameter • •
PQL-DFILLM Parameter • •
PQL=DPGFLQUOTA Parameter
PQL_DPRCLM Parameter • •
PQL DTQELM Parameter • •
PQL-DWSDEFAULT Parameter
PQL=DWSEXTENT
PQL DWSQUOTA Parameter •
PQL-MASTLM Parameter •
PQL-MBIOLM Parameter
PQL-MBYTLM Paramet~r
PQL-MCPULM Parameter
PQL-MDIOLM Parameter
PQL-MENQLM Parameter
PQL-MFILLM Parameter •
PQL-MPGFLQUOTA Parameter
PQL-MPRCLM Parameter
PQL-MTQELM Parameter
PQL-MWSDEFAULT Parameter
PQL-MWSEXTENT Parameter
PQL-MWSQUOTA Parameter
PROCSECTCNT Parameter
QUANTUM Parameter
REALTIME SPTS Parameter
_FEINITQUE Parameter
RESHASHTBL Parameter
RJOBLIM Parameter
RMS DFMBC Parameter
RMS-DFMBFHSH Parameter
RMS-DFMBFIDX Parameter
RMS-DFMBFREL Parameter
RMS-DFMBFSDK Parameter
RMS-DFMBFSMT Parameter
RMS-DFMBFSUR Parameter
RMS EXTEND SIZE
RMS-FILEPROT Parameter
RMS-PROLOGUE Parameter
SCSBUFFCNT Parameter
SCSCONNCNT Parameter
SCSFLOWCUSH Parameter
SCSMAXDG Parameter
SCSMAXMSG Parameter
SCSRESPCNT Parameter
SCSSYSTEMID Parameter
SETTIME Parameter
SPTREQ Parameter
SRPCOUNT Parameter
SRPCOUNTV Parameter
SWPFILCNT Parameter
SWPOUTPGCNT Parameter
SYSMWCNT Parameter
TIMEPROMPTWAIT Parameter
TTY ALTALARM Parameter
TTY-ALTYPAHD Parameter
TTY-BUF Parameter
TTY-CLASSNAME
TTY-DEFCHAR Parameter
TTY-DEFCHAR2 Parameter
TTY-DIALTYPE Parameter
TTY-DMASIZE Parameter
TTY-OWNER Parameter
TTY-PARITY Parameter
TTY-PROT Parameter •
TTY-RSPEED Parameter
v

CONTENTS
Page
10.2.150
10.2.151
10.2.152
10.2.153
10.2.154
10.2.155
10.2.156
10.2.157
10.2.158
10.2.159
10.2.160
10.2.161
10.2.162
10.2.163
10.2.164
CHAPTER 11
11.1
11.1.1
11.1.2
11.1.3
11. 2
11. 3
11. 4
11. 5

CHAPTER 12

TTY SCANDELTA Parameter
TTY-SILOTIME Parameter •
TTY-SPEED Parameter • • ••
TTY-TYPAHDSZ Parameter •
UAFALTERNATE Parameter •
UDABURSTRATE Parameter •
USERDl Parameter •
USERD2 Parameter • • • • • • •
USER3 Parameter
USER4 Parameter
VIRTUALPAGECNT Parameter
WSDEC Parameter
WSINC Parameter
WSMAX Parameter • • • •
XFMAXRATE Parameter • • • •

•
• • • • • • •
•
•
• • • • • •
• •
• • • • • •
•
•
• • • • • •
• • • • •
• • • • •

10-41
10-42
10-42
10-42
10-42
10-42
10-42
10-43
10-43
10-43
10-43
10-43
10-43
• 10-43
• • • 10-44

SYSTEM GENERATION
11-1
. . . . . . . . . . . . . 11-2

SYSTEM PARAMETERS
Creating a Parameter File
Modifying the System Image • • •
Modifying the Active System
DEVICES AND DEVICE DRIVERS
SYSTEM FILES • • • • • • •
START-UP COMMAND PROCEDURE
MULTIPORT (SHARED} MEMORY

11-3
11-3
11-3
11-4
11-6
11-7

TUNING CONSIDERATIONS

12.1
PRETUNING CONSIDERATIONS •
12.1.1
Hardware Resources • • •
Workload Distribution
12.1.2
12.1.3
Sharing of Code • • • •
• •••
SYSTEM PERFORMANCE (BACKGROUND DISCUSSION}
12.2
12.3
TUNING TOOLS • • • • • • • • • •
12.3.1
System Parameters and Files • • • • • • • • •
12.3.2
User Authorization File
12.3.3
DCL Commands • • •
12.3.4
Monitor Utility • • • •
12.4
TUNING SMALL SYSTEMS
•
• • • • •
12.4.1
Working Set Size •
• ••
12.4.1.1
Initial Working Set Limits •
• • • • • •
• •
12.4.1.2
Adjustments • • • • • • • • • • • •
• • •
12.4.2
Page Cache • • • •
• • • •
12.4.2.1
Cache Sizes
••••••
12.4.2.2
• • • • • • • • •
Cluster Size • •
12.4.3
Priority, Quantum, and Compute-bound Swapping
••••••
Rate • • • • • • •
•
12. 4. 3.1
Very Large Working Sets • • • •
•
12.4.3.2
Compute-bound Programs
• • • • • • • •
12.4.4
System Requirements
• • • • •
12.4.4.1
Nonpaged Dynamic Pool
• •
12.4.4.2
System Working Set
• • • • •
12.4.4.3
VAX-11 RMS Buffers •
•
12.5
TUNING LARGE SYSTEMS • • • • • •
• • • • •
12.5.1
Header Cache • • •
•
12.5.2
Directory Cache
••••
• •
12.5.3
Quota Cache
••••
•
12.5.4
System Directory Cache • • • • •
•
12.5.5
Multiple ACPs • • • •

12-1
12-2
12-2
12-3
12-3
12-5
12-5
12-7
12-8
12-9
12-10
12-10
12-10
12-11
12-12
12-12
12-13
12-13
12-13
12-14
12-14
12-14
12-15
12-15
12-15
12-16
12-16
12-17
12-17
12-17

CONTENTS
·Page
FIGURES
FIGURE

2-1
2-2
2-3
2-4
8-1
8-2

8-3

8-4
9-1
9-2
11-1
12-1
12-2

Command Procedure Template for Adding a User •
2-5
Sample SYS$MANAGER:SYLOGIN.COM Login Command
Procedure
• • • • • • • • • • • • • • • • • • • • 2-8
Sample LOGIN.COM Login Command Procedure • •
• 2-9
Command Procedure Template for Deleting an
Account's Files
• • • • • • • • •
2-12
Setting Up a Spooled Printer and a Print Queue on
a System with One Line Printer • • • • • • • • •
8-15
Setting Up Spooled Printers and Print Queues on a
System with Two Line Printers with the Same
Characteristics
• • • • • • • • • • • • • •
8-16
Setting Up Spooled Printers and Print Queues on
a System with Three Line Printers; Two with the
Same Characteristics and One with Special
Characteristics or in a Remote Location • • • • • 8-17
Setting Up Spooled Printers and Print Queues -Adding a Logical Queue to the System with Three
Line Printers • • • • • • • • • • • • • • • • • • 8-18
Sample Operator's Log File
(SYS$MANAGER: OPERATOR. LOG) • • • • • •
• • 9-6
9-12
Software Performance Report (SPR)
11-8
Example of Multiport Memory Structures
12-3
VAX/VMS Memory Configuration • • • • • • •
12-6
Sample CONFIG.DAT and PARAMS.DAT Files •

TABLES
TABLE

1-1
1-2
1-3
3-1
3-2

3-3
4-1
4-2
5-1
8-1
8-2

8-3
9-1
10-1
10-2
10-3
10-4
10-5
10-6
10-7
10-8
12-1

• 1-5
System Management Privileges •
DCL Commands Commonly Used • • • • • • •
• 1-6
1-9
System Management Utilities
••••
• • 3-4
Logical Structure of Protection Mask
DCL Commands Affected by GROUP and WORLD
3-12
Privilege
••••••••••••••••
System Services Affected by GROUP and WORLD
Privilege
• • • • • • • •
• ••••••••
3-12
• 4-2
Summary of System Limits •
• •••
4-6
VAX/VMS Privileges • • •
VAX/VMS Reserved Files • • • • • •
• 5-2
DCL Commands Used in Regulating Spooling and
8-2
Queuing
• • • • • •
• • • •
DCL Commands for Controlling Print and Batch
Queues • • • • • • • • • • • • • • • • • • •
8-19
Card Reader Errors: Causes and Corrective Actions 8-28
Typical Information Requirements for SPRs
9-15
10-2
MAJOR Parameters • • • • •
• • • •
SYS Parameters
• • • • •
10-4
TTY Parameters •
. . . . . . . . . •
10-7
JOB Parameters •
• • • • •
10-8
ACP Parameters •
• • • • • • •
10-9
RMS Parameters
• • • •
• • • • •
10-9
• • 10-10
PQL Parameters
••••
• 10-11
SCS Parameters
• • • •
• • • •
12-6
AUTOGEN Parameter Values •

xi i

PREFACE

MANUAL OBJECTIVES
The VAX/VMS System Management and Operations Guide is a reference book
for
all users responsible for system management and operations.
This
guide has the following objectives:
•

To give the reader an understanding of the reasons for
performing VAX/VMS system management tasks and to show how to
perform these tasks.

•

To provide general information about day-to-day operations
the VAX/VMS operating system.

•

To serve as a one-volume reference source of information,
procedures, and examples that pertain to the operation of the
VAX-11 single-processor system.

•

To introduce utilities and commands used
in VAX/VMS system
management and operation, and to provide cross-references to
other books in the document set that contain reference
information on the subject.

INTENDED AUDIENCE
This guide is intended for users of the VAX/VMS system who must
perform the functions of a system manager or operator on one or more
VAX/VMS single-processor systems.
Section 1.1 outlines and briefly
describe these duties.
The reader of this guide is most likely a data
processing generalist, not necessarily a programmer, and probably not
a systems programmer.
Note that this manual does not address any of the issues of managing a
VAX-11/782 attached-processor system.
The VAX-11/782 User's Guide
presents this information.

STRUCTURE OF THIS DOCUMENT
This document covers all aspects of controlling the operations of a
VAX/VMS installation, in twelve chapters and one appendix, as follows:
•

Chapter 1 briefly describes the functions of system management
and operations and the duties entailed

•

Chapter 2 explains how to add and remove users from the
system,
using the Authorize Utility (AUTHORIZE) to maintain
the user authorization file

•

Chapter 3 describes how various system resources are protected
through the mechanism of the user identification code (the
UIC)
xiii

PREFACE
•

Chapter 4 describes the use of limits, quotas, and
in controlling the system resources

privileges

•

Chapter 5 describes how to handle files and volumes

•

Chapter 6 describes how to install images as known images

•

Chapter 7 describes how to shut down and restart the system

•

Chapter 8 describes how to control print and batch queues

•

Chapter 9 describes the tools available to detect and
errors

correct

•

Chapter 10 describes the system parameters,
values, and information needed to adjust them

default

their

11 describes the System Generation Utility (SYSGEN)
• Chapter
and its role in generating and maintaining a well-running
system
•

Chapter 12 describes how to monitor the system and tune it for
improved performance

ASSOCIATED DOCUMENTS
The VAX-11 Information Directory and Index lists and describes all the
documents that you may need to-refer to in the course of performing
system management and operations, and contains a master index of all
topics discussed in the VAX/VMS document set.
For general background information about the system, see
Summary Description and Glossary and the VAX/VMS Primer.

the

VAX/VMS

The following documents may also be useful:
•

VAX/VMS Command Language User's Guide

•

VAX/VMS Release Notes

•

VAX-11 Utilities Reference Manual

•

VAX/VMS System Messages and Recovery Procedures Manual

VAX-11/RSX-llM User's Guide

•

RMS-11 User's Guide (For those users who continue to use the
RMSBCK and RMSRST utilities to back up and restore files.
This book is no longer part of the VAX/VMS document set since
new VAX/VMS utilities offer improved functionality)

•

VAX/VMS Magnetic Tape User's Guide

You should also consult
VAX-11 processor.

the

software

installation

guide

for

your

For hardware operating instructions, refer to the appropriate hardware
manual for VAX-11 users.
For managing network
Manager's Guide.

operations,

refer

For managing VAX-11/782 ,attached-processor
VAX-11/782 User's Guide.
xiv

the

DECnet-VAX

systems,

refer

System
to

the

PREFACE
CONVENTIONS USED IN THIS DOCUMENT
Meaning

Convention
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>

prompt characters that the system prints or
displays in black letters. All user-entered
commands are shown in red letters.
used
type

in
the

Uppercase words
and letters

Uppercase words
and
letters,
examples, indicate that you should
word or letter exactly as shown.

Lowercase words
and letters

Lowercase words and letters, used in format
examples, indicate that you are to substitute
a word or value of your choice.

Quotation marks
Apostrophes

The term "quotation marks" refers to double
quotation marks {"). The term "apostrophe"
refers to a single quotation mark {').

[

Square brackets indicate that the enclosed
item is optional. However, square brackets
are not optional in:

]

The syntax of a directory name
A file specification
The syntax of a substring specification
The SET UIC command

A horizontal ellipsis indicates that the
preceding item{s) can be repeated one or more
times.
For example:
file-spec [, ••• ]
A vertical ellipsis indicates that not
the statements in an example or figure
shown.
$ RUN
$ File:

In examples of commands you enter and system
responses, all output lines and prompting
characters that the system prints or displays
are shown in black letters. All the lines
you type are shown in red letters.

<RET>

(CTRL/Yl or

all
are

CTRL/x

A
symbol
with
a
1to
3-character
abbreviation indicates that you press a key
on the terminal.
Th~

symbol CTRL/x indicates that you must
press
the
key
labeled CTRL while you
key,
for
simultaneously
press
another
example, CTRL/C, CTRL/Y, CTRL/O.

Unless otherwise noted, all numeric values are represented in
notation.
Unless otherwise specified, you terminate
RETURN key.

commands

decimal

pressing

the

SUMMARY OF CHANGES

While this is a new manual in title and format,
it contains much
material from the earlier manuals it replaces:
the VAX/VMS System
Manager's Guide and the VAX/VMS Operator's Guide.
Thus,
it is
possible to
identify technical areas in this new manual where major
changes have occurred .since the Version 2. 0 publication of the
corresponding information.

1.0

INFORMATION RELOCATED WHEN THE MANUALS WERE COMBINED

You will find that reference material for the following utilities
formerly found in the VAX/VMS System Manager's Guide has been moved to
the VAX-11 Utilities Reference Manual:
e

Authorize Utility (AUTHORIZE)

•

Disk Quota Utility (DISKQUOTA)

•

Display Utility (DISPLAY) -- replaced by the Monitor Utility
(MONITOR), which is also described in the VAX-11 Utilities
Reference Manual

•

Install Utility (INSTALL)

•

RMS Share Utility (RMSSHARE)

•

SYE Utility

•

System Generation Utility (SYSGEN)

Note also that the error messages for each of these utilities have
been relocated to the VAX/VMS System Messages and Recovery Procedures
Manual.
The descriptions of all commands requiring the operator privilege
(OPER)
that were formerly found in the VAX/VMS Operator's Guide have
been moved to the VAX/VMS Command Language User's Guide, where they
appear in alphabetical order with the other DCL commands.

2.0

TECHNICALLY CHANGED INFORMATION

Technical changes in the following major areas reflect changes in
Version 3.0 software:
•

MONITOR
All references to the Display Utility
updated to refer to the new Monitor Utility.

•

BACKUP -- All
references to the Disk Save and Compress
Utilities have been updated to show the new Backup Utility as
the preferred utility.
Also, new descriptions featuring
BACKUP facilities have been added.

vui i

have

the
been

SUMMARY OF CHANGES
•

Quotas -- Two new quotas, the enqueue quota (ENQLM) an&
working set extent quota (WSEXTENT), have been added.

•

Privileges -- The new privilege SYSLCK has been added.

•

Logical names for the system device, system disk, and system
directories -- The new logical names are reflected throughout
the manual.

•

Mounting disks
The new features of mount verification
operator-assisted mounts have been described.

•

Operator messages -- The messages have changed significantly.
All OPCOM messages now include the full date. Also, the
technique for numbering requests has changed.
As a result,
request id numbers are not immediately reused after a request
completes.

•

System start-up and shutdown -- The procedures STARTUP.COM and
SHUTDOWN.COM have been modified. See Chapter 7.

•

Restarting the job controller, error logger, and OPCOM
method for restarting these processes has changed.

•

Emptying the queue file -- See Chapter 8 for a description of
how to use the new system parameter REINITQUE to clear a
corrupted queue file.

•

Concealed device names -- Examples generally conceal. physical
device names with logical names, in keeping with the new
VAX/VMS conventions.

•

Automatic generation of parameter files
The
default
parameter
file
is now automatically generated using a
procedure named AUTOGEN.COM, which means that DIGITAL no
longer ships the nUSER.PAR files such as 32USER.PAR. You can
still create you own parameter files, if necessary.
However,
the file AUTOGEN creates should be a more accurate reflection
of your configuration than the DIGITAL-supplied files of
previous versions were.

•

Tuning -- The system permits growth in a number of key areas
where the system parameters formerly provided fixed limits.
As a result, the system can do more to tune itself, so you
should have even less need now to perform tuning. The chapter
on tuning the system has been revised to reflect this
philosophy and explain the changes.

changes

have

been

the

and

The

made.

dynamic pool size -- The rules for configuring the
• Nonpaged
size of nonpaged pool have been greatly simplified. In
addition, each of the nonpaged pool areas can grow beyond its
current size.
There is little penalty for underconf iguring
one of the size parameters.

xviii

SUMMARY OF CHANGES
3.0

NEW INFORMATION

This manual contains information on the following new subjects:
•

Accounting Utility -- This new utility is introduced here as
are the older system management utilities; however, reference
material for all the utilities ,now resides in the VAX-11
Utiliti~s R•ference Manual.

•

Mounting disks -- The new features of mount verification
operator-assisted mounts are described in Chapter 5.

and

•

New System Parameters -- Chapter 10 includes
the new system parameters:

BORROWLIM
DEADLOCK WAIT
DISMOUMSG
l?'REEGOAL
FREELIM
GBLPAGFIL
GROWL IM
IRPCOUNTV
JOBQUEUES
LOCKIDTBL
LOGGHASHTBL
LOGPHASHTBL
LOGSHASHTBL
LONGWAIT
LRPCOUNT LRPCOUNTV
LRPSIZE
MOUNTMSG
MPW THRESH

4.0

MPW WAITLIMIT
MVTIMEOUT
NPAGEVIR
PAGFILCNT
PAPOLLINTERVAL
l?APOOLINTERVAL
PASTDGBUF
PASTIMOOT
PASTRETRY
PQL DENQLM
PQL-DWSEXTENT
PQL~MENQLM

PQL......MWSEXTEN'r
REIN!TQUE

RESHASHTBL
RJOSLIM
RMS EXTEND SIZE
RMS-FILEPROT
RMS.....PROLOGUE

descriptions

SCSBUFFCNT
SCSCONNCNT
SCSFLOWCUSH
SCSMAXDG
SCSRESPCNT
SCSSYSTEMlD
SRPCOUNT
SRPCOUNTV
SRPSIZE
SWPFILCNT
TIMEPROMP".I'WAIT
TTY ALTALARM
TTY-ALTYPAHD
TTY-CI..ASSNAME
TTY-DEFCHAR2
TTY-DIALTYPE
TTY-DMASIZE
TTY-S!LOTIME
UDABURSTRATE

•

New user-Defined system Para~eters
You can define any of
the following reserved system parameters for site-specific
purposes: USERDl, USERD2 1 USER3 1 and USER4.

•

Announcements -- You can define the logical names SYS$ANNOUNCE
and SYS$WELCOME to provide site specific announcements and
welcome messages.

•

Primary and secondary days -- You can define days of the week
and periods within those days as enabled or disabled for user
logins, on a user-by-user basis. See Chapter 2.

•

Uses of the new DCL commands
are
suggested
wherever
appropriate, and behavior changes in the existing commands are
shown in the descriptions.

MISCELLANEOUS IMPROVEMENTS

Chapter 2 1 User Adcounts, has been e~panded to describe
more
procedures for establishing and deleting user accounts and for writing
login command procedures.
The chapter entitled Protection and Control has been rewritten
more compreh~nsive. (See Chapter 3, UIC-Based Protection.)

SUMMARY OF CHANGES
Likewise, the description of Software Performance Reports
(SPRs)
has
been expanded to provide guidelines for supplying the information
required by DIGITAL with your report.
The chapter entitled Print and
(See Chapter 8.)

Batch

Queues

has

been

reorganized.

CHAPTER 1
INTRODUCTION

main
These

System management of a VAX/VMS installation entails
two
responsibilities:
system performance and system operationi
responsibilities require that you:
•

Make decisions that relate to
optimizing
performance and efficiency of the system

•

Perform procedures that relate to the overall
control of the system

the

overall

management

and

To make good decisions, you must understand both the needs of users
and the capabilities of the VAX/VMS operating system. To perform
system management procedures well, you must have a working knowledge
of the functions of the VAX/VMS operating system.
The pattern followed throughout this guide is to discuss the
issues
and the facts that will help you make decisions and then to give
general rules and guidelines for performing the procedures of system
management.
It is not possible to prescribe a precise set of formulas for setting
up and running a VAX/VMS system.
System management cannot be done by
rote or from a cookbook.
Rather, you must -- by combining an
understanding of users' needs and system capabilities with a working
knowledge of the functions of VAX/VMS -- work out your own strategy
for effective system management.

1.1

OVERVIEW OF SYSTEM MANAGEMENT

In its most abstract sense, system management means the overall
control of the operations of a computer system for the benefit of the
users of the system.
System management is a function that can be
performed by one individual, or by a single system manager who is
assisted by one or more system operators, or it can be shared by
several persons, some or all of whom may also serve as system
operators. Since the designation of these roles varies from site to
site, this guide does not make job distinctions between system
managers and operators. For the most part, as you read this document
it will appear that one person is performing all the functions.
Bear
in mind that this is not always the case.
A computer installation exists to serve its users.
Ideally, then,
it
should be operated to provide service to all users with efficiency and
economy. This is the challenge of system management.

1-1

INTRO.DU CT I ON

1.1.l

System Management Tasks

For practical purposes, system management is best defined in terms of
the tasks performed.
The tasks 6f system management typically fall
into the following categories;
•

Bringing the system up

•

Setting up users' accounts

•

Controlling the operation of the system (see Section 1.2)

•

Configuring the system for good performance

•

Planning to meet future requirements

The first topic (bringing the system up) is the subject of the
software installation guide for your VAX-11 processor. The next three
topics are the subjects of this sys~em management and operations
guide. The final topic is beyond the scope of this manual.

l.1.2

Operational Tasks

The VAX/VMS system runs, to a great extent, without
operator
intervention.
However, in many installations, one or more operators
keep the system running smoothly by performing some of the following

tasks:
•

Physically mounting magnetic tapes and disks at the request of
the user$ who own them

•

Initializing and mounting system volumes

•

Backing up public files and volumes

•

Carrying out user requests

•

Sending messages to specific users

•

Broadcasting messages to all users

•

Controlling print and batch queues

•

Tending line printers

•

Tending card readers

•

Monitoring the system

•

Observing and responding to emergencies

•

Printing copies of the operator's log file and the
file

•

Shutting down and restarting the system

•

Bringing up and shutting down network components

error

To carry out these tasks, you will probably have to interact with:
•

Other users of the system

1-2

log

INTRODUCTION
•

The VAX/VMS operating system

•

The VAX-11 processor on which the operating system runs

As a VAX/VMS system operator, you can perform many of your duties from
user terminals.
However, one of your chief functions, communicating
with other users, must be performed at a terminal that has been
defined as an operator's terminal. You can define a terminal to be an
operator's terminal by using the privileged command REPLY/ENABLE
(described in Section 9.2.4.3). Your relationship with the users and
their programs is based on messages that pass between you and other
users.
A record of these messages is displayed on the operator's
terminal; the messages are also entered in the operator's log file
for later reference.
Other operator functions can be performed only from the system console
terminal.
These functions include bootstrapping and communicating
with the VAX-11 processor's console subsystem.
The interactions between you and the VAX/VMS operating system are
based on your ability to use the entire set of VAX/VMS commands and on
your understanding of the system messages displayed or printed on the
operator's terminal.
(System messages are also entered in the
operator's log file.)
Interactions between you and the VAX-11 processor require you to
operate and maintain the peripheral devices supported by the system.
For detailed instructions on operating
and
maintaining
these
peripheral devices, see the appropriate hardware manual for VAX-11
users.

1.2

MANAGING THE VAX/VMS ENVIRONMENT

In managing the environment of a VAX/VMS system, you need to
understand the functions to be performed and the tools available. You
have at your command powerful utilities and commands to monitor and
control the system resources.

1.2.1

VAX/VMS Components

Among the first and most important of your responsibilities is getting
the VAX/VMS system up and running.
At a minimum, this means the
bootstrap loading of the operating system distributed by DIGITAL.
You will also have to customize some of the operations of the
operating system and incorporate optional software into the system.
Optional software, which runs under control of the VAX/VMS operating
system, includes languages such as VAX-11 FORTRAN and data management
systems such as VAX-11 DBMS.
For an explanation of the steps that you may have to take to install a
VAX/VMS system, see the software installation guide for your VAX-11
processor.
The components of the VAX/VMS operating system are cataloged in nine
directories on the system distribution medium. The logical names of
these directories and brief descriptions of their contents foll~w:
•

SYS$LIBRARY or SYS$SHARE
This directory contains various macro and object libraries and
shareable images.

1-3

INTRODUCTION
•

SYS$MESSAGE
This directory contains system message files.

•

SYS$MANAGER
This directory contains files used in managing
system.

the

operating

SYS$HELP
This directory contains text files and help libraries for
Help Utility.

the

•

SYS$ERRORLOG
This is the directory for the error log file (ERRLOG.SYS).

•

SYS$TEST
This directory contains files used in testing the functions of
the operating system.

•

SYS$MAINTENANCE
This directory contains system diagnostic programs.

•

SYS$UPDATE
This directory contains files used in applying system updates.

SYS$EXAMPLES
This directory contains sample driver programs,
system services, and other source programs.

user-written

SYS$SYSTEM
This directory contains the executable images of most
functions of the operating system.

the

For a complete list of the files contained on the distribution medium,
see the software installation guide for your VAX-11 processor.

1.2.2

Privileges

System management functions require privileges that are denied to most
users.
Table 1-1 summarizes the privileges you need to use certain
procedures and commands documented in this manual.
Chapter
2
describes how to set up authorization records that grant these
privileges. Chapter 4 provides more detailed information about the
privileges and who should receive them.

1.2.3

DIGITAL Command Language Commands

This manual contains numerous references to the DIGITAL Command
Language
(DCL)
commands used most often to keep a VAX/VMS system
running smoothly. Most of these commands require the OPER user
privilege.
For detailed descriptions of these commands, see the
VAX/VMS Command Language User's Guide.

1.2.3.1

Command Line Format - The general format of a DCL command is:

command-name{/qualifiers ••• ] parameter[/qualifiers ••• ] [ ••• ]
Because a command can be continued on more than one line, the term
"command string"
is used to define the entire command that is passed

1-4

INTRODUCTION
to the system. A command string is the complete specification of a
command,
which
includes the command name, command qualifiers,
parameters, and parameter qualifiers.
See the VAX/VMS
Command
Language User's Guide for a detailed description of command syntax.
Table 1-1:

System Management Privileges

Privilege

Function

ACNT

Create a process for which no accounting records
made

ALLS POOL

Allocate spooled devices

ALT PR I

Increase the base execution priority for any process

BYPASS

Bypass user identification code (UIC)
accessing files

CMKRNL

Change execution mode to kernel

GROUP

Affect processes within the same group

GRPNAM

Insert logical names
table

LOG IO

Issue logical I/O requests

NETMBX

Create network devices

OPER

Execute operator functions

PHY IO

Issue physical I/O requests

PRMCEB

Create or delete permanent common event flag clusters

PRMMBX

Create permanent mailboxes

PSWAPM

Change process swap mode

SHMEM

Create or delete data structures in shared memory

SYSGBL

Create system global

SYS NAM

Insert logical names into
table

SYSPRV

Take system UIC protection when accessing files

TMPMBX

Create temporary mailboxes

VOLPRO

Override volume protection

WORLD

Control the execution of any process in the system

into

the

group

are

protection

logical

name

section~

the

system

logical

name

1.2.3.2 Summary of DCL Commands - Table 1-2 briefly describes the DCL
commands you will use most frequently.

1-5

INTRODUCTION
Table 1-2:

DCL Commands Commonly Used

Command

Function

ACCOUNTING

system
Provides
reports
on
resource
utilization based on
data recorded in the accounting
log file

ALLOCATE

Reserves a device for use by a
single
user
and, optionally,
assigns a logical name to the
device

ANALYZE/DISK_STRUCTURE

Checks
the
readability
and
validity of Files-11 Structure
Level l and Files-11 Structure
Level 2 disk volumes

ASSIGN/MERGE

Removes all jobs from one queue
and places them in another queue

ASSIGN/QUEUE

Assigns a logical
specific device

BACKUP

Saves, copies,
restores,
compares
files;
lists
information in a save set

COPY

Copies one or more files into one
or more additional files

DEALLOCATE

Relinquishes use of a previously
allocated device, thus making the
device available to other users

DEASSIGN/QUEUE

Deassigns a queue from a specific
device

DELETE/ENTRYl

Deletes an entry from a print or
batch queue or stops processing
of the current job

DELETE/QUEUE

Deletes batch and print queues

directory

Index File

Every Files-11 volume has an index file, which is created when the
volume is initialized. This index file identifies the volume to the
operating system as a Files-11 structure and contains the access data
for all files on the volume. The index file, which is listed in the
master file directory as INDEXF.SYS;l, contains
the
following
information:
•

Bootstrap block -- The volume's bootstrap block is virtual
block number 1 of the index file.
If the volume is a system
volume, this block contains a bootstrap program that loads the
operating system into memory.
If the volume is not a system
volume, this block contains a program that displays a message
that the volume is not the system device but a device that
contains users' files only.

c;._?

MAINTAINING PUBLIC FILES AND VOLUMES

5.1.2

•

Home block -- The home block establishes the specific identity
of the volume, providing such information as the volume name
and protection, the maximum number of files allowed on the
volume, and the volume ownership information. The home block
is virtual block number 2 of the index file.

•

Back-up home block -- The back-up home block is a copy of the
home block.
It permits the volume to be used even if the
primary home block is destroyed.

•

Back-up index file header -- The back-up index file header
permits recovery of data on the volume if the index file
header goes bad.

•

Index file bit map -- The index file bit map controls the
allocation of file headers and thus the number of files on the
volume. The bit map contains a bit for each file header that
is allowed on the volume.
If the value of a bit for a given
file header is O, a file can be created with this file header.
If the value is 1, the file header is already in use.

•

File headers -- The largest part of the index file is made up
of file headers.
Each file on the volume has a file header,
which describes such properties of the file as file ownership,
creation date and time, file protection, and location of the
file's blocks. The file header contains all the information
needed for gaining access to the file.

Storage Bit Map File

The storage bit map file controls the available space on a volume;
this file is listed in the master file directory as BITMAP.SYS;l.
It
contains a storage control block, which
consists
of
summary
information intended to optimize the Files-11 space allocation, and
the bit map itself, which lists the availability of individual blocks.

5.1.3

Bad Block File

The bad block file, which is listed in the master file directory as
BADBLK.SYS;l,
contains all the bad blocks on the volume.
The system
detects bad disk blocks dynamically and prevents their reuse once the
files to which they are allocated have been deleted.

5.1.4

Master File Directory

The master file directory
(MFD)
itself is listed in the MFD as
000000.DIR;l.
The MFD,
which is the root of the volume's directory
structure, lists the reserved files that control the volume structure
and may list both users' files and users' file directories.
Usually,
however, the MFD is used to list the reserved files and users'
file
directories;
users seldom enter files in the MFD, even on private
volumes.
In fact, on a private volume, it is most convenient for a
user to create a directory that has the same name as the user's
default directory on a system disk.
For an explanation of users' file
directories and file specifications, see the VAX/VMS Command Language
User's Guide.
When the Backup Utility creates sequential disk· save sets,
it stores
the save set file in the MFD.
(See Section 5.8.12 for a discussion of
sequential disk save sets.)

MAINTAINING PUBLIC FILES AND VOLUMES
5.1.5

Core Image File

The core image file is listed in the MFD as CORIMG.SYS;l.
used by VAX/VMS.

5.1.6

not

Volume Set List File

The volume set list file is listed in the MFD as VOLSET.SYS;l.
This
file is used only on relative volume 1 of a volume set. The file
contains a list of the labels of all the volumes in the set.

5.1.7

Continuation File

The continuation file is listed in the MFD as CONTIN.SYS;l.
This file
is used as the extension file identifier when a file crosses from one
volume to another volume of a loosely coupled volume set.
This file
is used for all but the first volume of a sequential disk save set
(see Section 5.8.12 for a discussion of sequential disk save sets).

5.1.8

Back-up Log File

The back-up log file is listed in the MFD as BACKUP.SYS;l.
is reserved for future use.

5.1.9

This

file

Pending Bad Block Log File

The pending bad block log file is listed in the MFD as BADLOG.SYS;l.
This file contains a list of suspected bad blocks on the volume that
are not listed in the bad block file.

5.1.10

Files-11 Structure Level 1 Versus Structure Level 2

Files-11 Structure Level 2, a compatible superset of Structure Level
1,
is the preferred disk structure on VAX/VMS for
reasons of
performance and reliability. At volume initialization time
(see the
INITIALIZE command
in the VAX/VMS Command Language User's Guide),
Structure Level 2 is the default.
Structure Level 1 should be
specified only for volumes that must be transportable to RSX-llM,
RSX-llD, RSX-llM-PLUS, and !AS systems, as these systems support only
that structure level.
Additionally, you may be required to handle
Structure Level 1 volumes transported to VAX/VMS from one of the above
systems.
Where Structure Level 1 volumes are in use on the system,
bear in mind the following limitations on them:

you

should

•

Directories -- No
hierarchies
of
directories
and
subdirectories, and no ordering of directory entries (that
is, the file names)
in
any
way
(RSX-llM,
RSX-llD,
RSX-llM-PLUS, and !AS systems do not support subdirectories
and alphabetical directory entries)

•

Wild cards -- Wild card characters only for complete fields
of file specifications
(for example, *USER.TXT is illegal,
while *.TXT is legal)

MAINTAINING PUBLIC FILES AND VOLUMES
•

Disk quotas -- Not supported

•

Multivolume files and volume sets -- Not supported

•

Placement control -- Not supported

•

Caches -- No
caching
of
file
header
identification slots, or extent entries

•

System disk -- Cannot be a Structure Level 1 volume

•

Clustered allocation -- Not supported

•

Back-up home block -- Not supported

•

Protection code E -- Means extend for RSX-llM, but is ignored
by VAX/VMS

•

File versions -- Limited to 32767;
supported

version

blocks,

limits

are

file

not

Future enhancements to VAX/VMS will be based primarily on Structure
Level 2, so that further restrictions on Structure Level 1 volumes may
be incurred.
As explained in the VAX-11 Utilities Reference Manual, if you choose
the DSC utilities for back-ups, you must use DSCl to back up Structure
Level 1 volumes and DSC2 to back up Structure Level 2 volumes.
The
preferred utilities are the Backup Utility and the Verify Utility,
which support both Structure Level 1 and Structure Level 2.

5.2

SETTING UP PUBLIC FILE STRUCTURES

A major duty in system management is maintaining public
file
structures.
You must strike a balance between your users' needs and
the system's available mass storage resources.
You must determine how
mass storage devices on your system will be configured, which devices
will hold public system volumes, which devices will be available for
users' private volumes, and how the public volumes will be configured.
You are also responsible for creating top level user file directories
as needed, and monitoring users' disk space usage.

5.2.1

Deciding Where to Put User Files

In most circumstances, you will want to dedicate most of your large
disk drives to public disk storage.
In relatively large system
configurations, you should not put user files on the system volume.
The system disk will be kept active with paging and swapping, spooling
files, maintaining system logs, and so forth.
Furthermore,
if you
ever find
it necessary to build a new system disk from scratch, you
will find that having user files on it makes the process much more
difficult and time-consuming.
If you have a relatively small mass storage configuration, you will
have no other choice than to allocate user files on the system volume.
Under these circumstances, you should take adequate precautions with
disk quotas and user education to ensure that users' files do not
exhaust the free space on the system disk.

5-5

MAINTAINING PUBLIC FILES AND VOLUMES
5.2.2

Should You Use Volume Sets?

A volume set is a collection of disk volumes that have been bound into
a single entity, by the MOUNT/BIND command. A volume set appears to
be a single, large volume. Files are automatically allocated anywhere
on the volume set that space is available, disk quotas are enforced
over the set as a whol.e, and a single directory structure - covers the
whole volume set.
If you want to provide a large homogeneous public
file space, use a volume set. You must also use a volume set if you
intend to create data base files that are larger than any single disk
volume.
It is worth noting that the file system attempts to balance
the load on the volume, with tactics such as creating new files on the
volume that is the least full at the time.
On the other hand, if you want several distinct areas of file storage,
with different user bases or different management policies, you must
use a separate volume (or volume set) for each area.
Each separate
volume or volume set must contain a top-level user file directory for
each user who will keep files on that volume. For example, you might
want one volume for permanent user storage, with carefully limited
quotas and careful back-ups, and another volume for "scratch" use,
which has liberal or no quotas, is not backed up, and whose files are
cleaned out on a periodic basis. Another advantage of using separate
volumes is their modularity.
Should one of the drives holding a
volume set be out of service, the whole volume set will be unavailable
because of the interconnected nature of its directory structure.
On
the other hand, when a drive holding a single volume is unavailable,
only a well-defined set of files becomes unavailable.
For planning purposes, remember:
•

Any single volume can be turned into a volume set by binding
it with a newly initialized volume.
Likewise, you can always
add another newly initialized volume to an existing volume
set.

•

You can bind disk volumes of different
volume set.

•

You cannot bind two existing separate volumes containing files
into a volume set.
(The MOUNT command will let you do this,
but the result will not be a coherent volume set.)

•

You only need to issue the MOUNT/BIND command once to effect
binding;
thereafter, the volume-set association is recorded
on the volumes.

•

Once you have bound two or more volumes into a volume set,
they cannot be separated. The only way to separate a volume
set is to selectively copy sets of directories using BACKUP.

types

into

For more information on volume sets, see the VAX/VMS Command
User's Guide.

5.2.3

the

same

Language

Should You Make the System Disk Part of a Volume Set?

DIGITAL does not recommend that you make the system disk part of a
volume set. While VAX/VMS will continue to boot and run successfully
if you do this, optional product installations, maintenance updates,
and system upgrades will not in~tall correctly on a system disk that
is part of a volume set.
Once you have installed an update or
software product, system files can be allocated anywhere on the volume
set, and VAX/VMS will no longer boot successfully.

5-6

MAINTAINING PUBLIC FILES AND VOLUMES
5.3

FORMATTING DISKS

Disks that you purchase from DIGITAL are preformatted with the EVRAC
disk formatter.
However, under some circumstances you may need or
want to format a disk.
Disks must be reformatted if they have been
exposed to X rays, degaussing, or certain kinds of power disruptions.
Also, you may find formatting desirable if you are experiencing
excessive parity errors on a disk.
In such cases, you should contact
your Field Service representative for assistance.

5.4

INITIALIZING PUBLIC VOLUMES

The purpose of initializing a disk volume is to delete all old
information from the volume and to impart to the volume a Files-11
structure that the operating system recognizes.
This structure
prepares a volume to receive data and permits the operating system to
locate data stored on the volume.
In initializing a public volume (by using the qualifier /SYSTEM), you
may need to use one or more of the following qualifiers of the DCL
command INITIALIZE:

• /ACCESSED=n
• /CLUSTER_SIZE=n
• /EXTENSION=n

• /HEADERS=n
• /INDEX=position
• /MAXIMUM_FILES=n
• /WINDOW=n
As described below, selecting appropriate values for n and selecting
the appropriate position for the /INDEX qualifier often involve making
trade-offs.
The following guidelines for initializing public volumes supplement
information presented in the VAX/VMS Command Language User's Guide.

5.4.1

/ACCESSED Qualifier

The /ACCESSED qualifier provides an estimate of the number of
directories expected to be in use concurrently on a volume. The file
system keeps this number of directory file control blocks in system
space for
ready access on the basis of which directories were most
recently used. The result is a substantial reduction of overhead in
directory operations. For volumes mounted with the /SYSTEM qualifier,
the system parameter ACP_SYSACC overrides this value.
When you create a volume set, specify reasonable values for the
/ACCESSED qualifier on each volume because the total number of
directory file control blocks retained will be the sum of the values
of all the /ACCESSED qualifiers specified for the volume set.

5-7

MAINTAINING PUBLIC FILES AND VOLUMES
5.4.2

'/CLUSTER_SIZE Qualifier

The /CLUSTER SIZE qualifier specifies the fundamental
unit
of
allocation
(expressed
in blocks)
on a volume.
In selecting the
cluster size, wasted space at the end of files is traded off against
the size of the volume storage bit map, which must contain one bit for
each cluster on the volume (or one block for each 4096 clusters).

5.4.3

/EXTENSION Qualifier

The /EXTENSION qualifier specifies the default number of blocks
allocated for
extending files on a volume.
This value is less
important on the VAX/VMS system than on the RSX-llM,
RSX-llD,
RSX-llM-PLUS,
and IAS systems, because VAX-11 Record Management
Services use an adaptive algorithm maximized against /EXTENSION.
The
value of this qualifier should be an even multiple of /CLUSTER_SIZE.

5.4.4

/HEADERS Qualifier

The /HEADERS qualifier specifies the number of file headers to be
allocated
initially to the
index file.
The primary advantage of
preallocating file headers is that they will then be located near the
storage map file (usually in the middle of the disk).
This placement
of file headers helps reduce head motion during file manipulation.
This value should be estimated conservatively, because space allocated
to headers cannot later be made available for file storage.

5.4.5

/INDEX Qualifier

The /INDEX qualifier specifies the location of the
index file on a
volume.
The default position (MIDDLE) results in m1n1mum head motion
during file processing.
The position BEGINNING should be used if the
disk is to contain only one or a few very large contiguous files.
When the Backup Utility copies a volume as the result of
a
BACKUP/IMAGE command, it preserves the placement of the index file, if
the output device is the same type.
Otherwise, it defaults to MIDDLE.
(The Disk Save and Compress
(DSC) Utilities position the index at
BEGINNING.)

5.4.6

/MAXIMUM_FILES Qualifier

The /MAXIMUM FILES qualifier specifies the maximum number of files
that a volume can contain.
The default value is fairly liberal.
A
closer estimate of it helps optimize the dynamic allocation of the
index file;
once set, however,
the maximum number of files for a
volume cannot be increased.
Note that each directory and each
extension header of a multiheader file counts as a file against this
maximum value.

5.4.7

/WINDOW Qualifier

The /WINDOW qualifier specifies the default number of map pointers in
a
file access window.
This value is the number of extents of a file
to which access can be gained without the cost of file system
overhead.
5-8

MAINTAINING PUBLIC FILES AND VOLUMES
5.5

MOUNTING PUBLIC VOLUMES

The purpose of mounting a volume or volume set is to establish a
relationship between the volume or volume set, the device(s) on which
the volume is physically mounted, and one or more processes that can
gain access to the volume.
In mounting a public volume (by using the qualifier /SYSTEM), you may
need
to use one or more of the qualifiers /ACCESSED, /EXTENSION, and
/WINDOW (described in Section 5.4), or the following additional
qualifiers:
e

/ASSIST

•

/COMMENT=text

/MOUNT_VERIFICATION

/PROCESSOR=option

The following guidelines for mounting disk
supplement information presented
in the
User's Guide.

5.5.1

volumes
VAX/VMS

for public use
Command Language

/ASSIST Qualifier

The /ASSIST qualfier enables or disables the operator-assisted mount
feature.
Section
5.12 describes operator-assisted mounts.
By
default, this feature is enabled.
You should encourage your users to
take advantage of this feature.
There is a situation where operator-assisted mounts generally prove
undesirable.
During the execution of SYSTARTUP.COM, operator-assisted
mounts are disabled by default.
The reason for this is that the
absence of some system volume normally mounted during SYSTARTUP.COM
would prevent the system from booting.
If you have one or more
volumes that must be present for the correct operation of your system,
you can specify the /ASSIST qualifier in the commands to mount them,
if you are prepared for the following consequences if any volume
proves to be offline or unavailable.
The operator assistance software
will issue an operator request to have the volume made ready, and will
wait for its completion.
There is no problem if you can ready the
volume.
However, if you cannot ready the volume {perhaps the drive is
down or the volume is corrupted), you cannot complete SYSTARTUP.COM.
To abort the mount request,
you would have to issue a REPLY/ABORT
operator command.
However,
the
system
console
is
running
SYSTARTUP.COM and
is unavailable.
Furthermore,
the other system
terminals are usually not yet properly configured or logins are not
yet enabled.
Under these circumstances, the only way to boot the
system is to invoke the command procedure SYS$SYSTEM:STARTUP.MIN.

5.5~2

/COMMENT Qualifier

The /COMMENT qualifier
includes the quoted text string that you
specify as part of the mount request,
thus passing it on to the
operator if the mount requires operator assistance.
This qualifier is
primarily useful in situations where operator assistance is expected,
such as to
inform the operator of the physical location of a
particular volume that is required.
You should encourage your users
to take advantage of this feature.

5-9

MAINTAINING PUBLIC FILES AND VOLUMES
5.5.3

/MOUNT_VERIFICATION Qualifier

The /MOUNT VERIFICATION qualifier enables or disables the mount
verification feature on Files-11 disks.
This feature is explained in
Section 5.7.
By default, the mount verification feature
is enabled.
However, note that this feature has no effect for foreign disks or
magnetic tapes.

5.5.4

/PROCESSOR Qualifier

The /PROCESSOR qualifier specifies the number of ancillary control
processes
(ACPs)
to be used in controlling various public volumes.
Selecting an appropriate option for the /PROCESSOR qualifier involves
making a trade-off.
If you specify the option SAME, file system
parallelism and performance may be sacrificed for the sake of saving
system space.
Conversely,
if you specify the option UNIQUE, system
space is sacrificed for the sake of file system parallelism and
performance.
Unless you have substantial memory to waste, you should
use the system default.
(See Chapter 10 for a description of the
ACP_MULTIPLE system parameter.)
You can monitor Files-11 ACP performance with the MONITOR FCP command
of
the
Monitor Utility.
(See the VAX-11 Utilities Reference
Manual.)
The information MONITOR provides can help you determine how
to configure your file system.

5.6

MAINTAINING VOLUME INTEGRITY

To enhance performance, the system caches in memory information
concerning a volume's free space, file identifications, quota file
entries, and file headers. You determine the degree of caching with
the ACP cache system parameters (see Chapter 10).
Individual users
can alter cache sizes on their volumes with qualifiers to the DCL
command MOUNT
(see the VAX/VMS Command Language User's Guide).
The
system writes the information in the caches to the disk when the disk
is dismounted or the system is shut down. Naturally, removal of a
disk before the caches are written back loses any changes made to the
information in the caches.
Therefore, you and the individual user
should:
1.

Not write-lock a volume while it is mounted

Not remove a volume from a drive until it has been dismounted

Not halt the system without performing
procedure (see Chapter 7).

the

orderly

shutdown

If anyone write-locks a volume at mount time, the system additionally
applies a software write-lock.
If you need to write-enable a volume
that was mounted while the write-lock switch was on, you must first
dismount the volume, then write-enable the drive, and then remount the
volume.
If a volume was mounted on a drive with write-lock off and
then
someone
toggles the write-lock switch on
(and if mount
verification is enabled for the volume, which it is by default),
the
volume enters mount verification. All I/O operations to the volume
are suspended.
Section 5.7.2 describes how recovery is effected with
write-lock
mount verification.
(Without the mount verification
facility, you would have to dismount the volume, write-enable the
drive, and then remount the volume.)
At mount time, if the system detects that the caches were not written
back the last time the volume was used, the system automatically
5-10

MAINTAINING PUBLIC FILES AND VOLUMES
rebuilds the file information by scanning the content's of the volume.
However, file headers for files open at the time of the improper
dismount may be partially or wholly lost.

5.7

MOUNT VERIFICATION

The mount verification feature of Files-11 disk handling generally
leaves users unaware that a mounted disk has gone offline and returned
online or in some other way has become unreachable and then restored.
Mount verification is enabled by default with the /MOUNT VERIFICATION
qualifier when the disk is mounted. To disable mount verification,
the user must specify /NOMOUNT VERIFICATION when mounting the disk.
Note that this feature does not apply to foreign disks or to magnetic
tapes.
Mount verification sends messages to OPCOM. Because there are cases
where mount verification messages are needed at the operator's console
and OPCOM might not be able to provide them, mount verification also
sends special messages with the prefix %SYSTEM-I-MOUNTVER to the
operator's console only, that is, to OPAO. For example, if the system
disk undergoes a mount verification or if the OPCOM process is not
present on a system, the operator would at least receive the messages
with the %SYSTEM-I-MOUNTVER prefix. Under normal circumstances, both
messages are received at the
operator's
terminal,
with
the
%SYSTEM-I-MOUNTVER message arriving first.

5.7.1

Device Offline Mount Verificaton

If a mounted disk volume goes offline while mount verification is
enabled, you can follow the steps in the procedure below to resume
operations.
Procedure
When a device is taken offline, the steps in mount verification are as
follows:
1.

Due to a hardware or user error, a disk volume is taken
offline
(for example,
it might be spun down). Most disk
drives generate a special interrupt when the volume comes back
online, which causes the software to mark the volume as
invalid. However, some disk drives (such as the RXOl,
RX02,
RL02,
and TU58) do not generate online attention interrupts.
For these devices, an offline condition is only detected when
an I/O operation is initiated for the drive.

An I/O operation fails with a medium offline or volume invalid
status.
The software marks the volume to indicate that it is
undergoing mount verification, and all I/O operations to the
disk are stalled.

OPCOM issues a message to the operators enabled for DISKS and
DEVICES to announce the disk's unavailability, as follows:
%0PCOM, dd-mmrn-yyyy hh:mm:ss.cc, Device device-name is offline.
Mount verification in progress.

You may simply choose to take the disk out of the offline and
verification pending state by shutting down mount verification
with one of the three techniques described in Section 5.7.3.
These techniques cause the pending and future I/Os to the
volume to fail.
5-11

MAINTAINING PUBLIC FILES AND VOLUMES
5.

Otherwise, you take corrective action.
Perhaps the drive can
be brought back online.
If the disk drive is faulty, but
another functioning drive is available on the same controller,
you can move the disk to the functioning drive and swap the
unit select plugs.

The disk comes back online, which is detected by
verification software that polls the disk drive.

The system verifies that the disk's home block matches the one
in the data base of mounted volumes, thus confirming that this
is the same disk as previously mounted.

If the drive does not contain the correct volume, OPCOM issues
the following message:

the

mount

%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, Device device-name contains the wrong volume.
Mount verification in progress.

After the mount verification succeeds, the disk is
valid.
OPCOM issues the following message:

marked

%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, Mount verification completed for device device-name

At this point I/O
proceed.

operations

the

disk

are

allowed

Example
%0PCOM, 15-JUN-1982 11:54:54.12, Device DMAO is offline.
Mount verification in progress.
%0PCOM, 15-JUN-1982 11:57:34.22, Mount verification completed for device DMAO

The message from OPCOM alerts the operator that device DMAO has
gone offline and mount verification has been initiated. The
operator finds the drive was accidentally spun
down
and
successfully spins it back up. The next message indicates that
mount verification is satisfied that the same volume is on the
drive
(which it has found is online again), and all I/Os to the
volume resume.

5.7.2

Device Write-Lock Mount Verification

If for some reason a mounted disk volume becomes write-locked while
mount verification is enabled, you can follow the steps in the
procedure below to resume operations.
Procedure
1.

A Files-11 disk volume is mounted for writing
(the /WRITE
qualifier is the default).
Through some hardware or user
error, the disk becomes write-locked.

The software discovers that the disk
is
write-locked
(typically an I/O fails with a write-lock error). The disk
is marked that verification is in progress.
OPCOM issues a
message to the operators enabled for DISKS and DEVICES to
announce the disk's unavailability, as follows:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, Device device-name has been write locked.
Mount verification in progress.

5-12

MAINTAINING PUBLIC FILES AND VOLUMES
3.

You may simply choose to take the disk out
of
the
verification
pending
state
by
shutting
down
mount
verification with one of the techniques described in Section
5.7.3.
These techniques cause the pending and future I/Os to
the volume to fail.

Otherwise, you take corrective action.
Perhaps the drive can
simply be write-enabled by toggling the drive's hardware
write-lock switch.
If the disk drive is faulty, but another
functioning drive is available on the same controller, you
can move the disk to the functioning drive and swap the unit
select plugs.
(Note that switching to another drive will
cause the volume to undergo offline mount verification
(see
Section 5.7.1).
Once that completes, the write-lock mount
verification continues.)

The mount verification software that polls the disk drive
determines that the volume is in a writeable state. At this
point, I/O operations to the disk are allowed to proceed.
However,
OPCOM does not issue a message indicating that the
write-lock mount verification has completed.

Example
%0PCOM, 29-JUN-1982 15:28:54.07, Device DMAl has been write locked.
Mount verification in progress.
The OPCOM message alerts the operator that device DMAl is
write-locked.
The operator toggles the write-lock switch on the
drive to eliminate the write-lock.
I/O operations to the disk
resume, with no further messages.

5.7.3

Cancelling Mount Verification

If you fail
to either bring a system disk back online or to
write-enable it as appropriate while mount verification is enabled,
the whole system can become hung, if the disk uses the same file ACP
as the sys~em disk.
In that case, you cannot issue a DISMOUNT command
to abort the request. This is because the file ACP that must handle
the I/O operation is single-threaded.
It cannot process any other
request until the stalled I/O completes. Thus, as individual users
make further requests for ACP services, they each become hung.
Under
these circumstances, you must cancel the pending mount verification,
using one of the first two techniques described below.
You can cancel a mount verification request in one of three ways:
1.

Allow the mount verification in progress to continue the
number of seconds defined by the system parameter MVTIMEOUT.
When the time expires, the system automatically cancels the
pending mount verification.
Note that a mount verification
initiated by a write-lock will not time out.

Invoke a special cancelling routine from the console terminal.

Dismount the volume with the
process that is not hung.

DCL

command

DISMOUNT

from

MAINTAINING PUBLIC FILES AND VOLUMES
5.7.3.1 MVTIMEOUT System Parameter - The MVTIMEOUT system parameter
defines the time
(in seconds)
that is allowed for a pending mount
verification to complete before it is automatically cancelled
(see
Chapter 10).
This dynamic parameter should always be set to a
reasonable value for the typical operations at your site. See Chapter
11 for
instructions on how to display and modify dynamic system
parameters with the System Generation Utility (SYSGEN).
Note that
resetting the value of the MVTIMEOUT parameter will not affect a mount
verification that is currently in progress.
You will probably find that 10 minutes (600 seconds) is a good value
for MVTIMEOUT, whether you normally operate with or without an
operator.
When a pending mount verification is cancelled by
prints the following message:

timing

out,

OPCOM

%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, Mount verification aborted for device device-name

After a mount verification times out, all pending and future I/O
requests to the volume will fail.
Thus, you must dismount and remount
the disk before you can access it again.
Note that a write-lock mount verification will not time out.

5.7.4

Cancellation Commands

If you must stop a mount verification before the time specified by
MVTIMEOUT can elapse, enter the following sequence of commands from
the console terminal of your VAX-11 processor:
(CTRL/P)

»>HALT
»>D/I 14 C
»>CONT
IPC>
While you are at the IPC> prompt, all system operation
(Press CTRL/Z when you are ready to exit.)
Note the following special characteristics of the
cancelling routine:

mount

suspended.
verification

•

Lowercase characters are converted to uppercase.

•

Illegal characters (such as most control characters)
are not
echoed;
instead, the terminal bell character is issued as a
warning alarm.

•

Leading spaces are ignored and are not echoed.

•

Multiple spaces are compressed into a single space;
all space characters after the first are ignored.

that

is,

There are two commands you can enter in response to the IPC> prompt:
C device
This command cancels any pending mount
specified.
(A warning is given if
progress for the device specified.)

S-1 4

verification on the device
no mount verification was in

MAINTAINING PUBLIC FILES AND VOLUMES

x
This command transfers control to the debugging tool XDELTA (provided
it was loaded with the system by setting the appropriate value in the
boot file).
If XDELTA has not been loaded, the prompt IPC> is
reissued.
XDELTA, which is described in the VAX/VMS Guide to Writing
a Device Driver, may prove especially useful
if you are debugging
privileged software on a VAX-11/782 attached processor system.
Press CTRL/Z to exit from the mount
and resume system operation.

verification

cancelling

When a pending mount
following message:

OPCOM

verification

cancelled,

routine

prints

the

%0PCOM, dd-rnrnrn-yyyy hh:rnm:ss.cc, Mount verification aborted for device device-name

After you successfully cancel a pending mount verification with this
technique, you must dismount and then remount the volume before you
can access it again.
Example
%0PCOM, 15-JUN-1982 10:54:54.12, Device DBAO is offline.
Mount verification in progress.
(CTRL/P)

>»HALT
>» D/I 14 C
>»CONT
IPC>C DBAO
(CTRL/Z)

%SYSTEM-I-MOUNTVER, DBAO: has aborted mount verification.
%0PCOM, 15-JUN-1982 T0:56:26.13, Mount verification aborted for device DBAO
The operator observes that device DBAO is offline but is unable to
spin the disk back up.
There is no other available drive on the
controller, so it is not possible to switch the unit select plugs of
the two drives.
(The operator also rejects the possibility of issuing
a DISMOUNT command for the disk (see Section 5.7.5), because it was
mounted as a private volume.)
Rather than wait ten minutes for the
mount verification to time out, the operator decides to invoke the
cancellation commands at the console terminal.
Observe that the
%SYSTEM-I-MOUNTVER message also appears here because this is the
console terminal.

5.7.5

Dismounting the Volume to Abort Mount Verification

In some cases, you can abort mount verification by dismounting the
volume in question.
This only works if it is possible for you to
issue the DCL command DISMOUNT for the volume when both of the
following conditions are true:
1.

The system file ACP is not hung

You are allowed access to the volume; that is, the
was mounted with the /SYSTEM or /GROUP qualifiers

volume

Follow the steps in the procedure below.
Procedure
1.

MAINTAINING PUBLIC FILES AND VOLUMES
2.

Enter the DISMOUNT command for the volume

When you cancel a pending mount verification by
the volume, OPCOM issues the following message:

dismounting

%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, Mount verification aborted for device device-name

If you do not have access to the volume, you did not satisfy
the second condition above, and you will receive an error
message. You can try again if you can find an appropriate
process to use.
If your process hangs, it is the system file
ACP that is hung (first condition above was not met), and you
cannot use this technique to cancel mount verification.
4.

5.8

Once the cancellation succeeds, remove the
drive.

volume

from

the

BACKING UP PUBLIC VOLUMES

Backing up a volume means copying the contents of the volume to
another volume or set of volumes (for example, another disk or tape).
Backing up volumes is a precautionary measure to allow you to recover
from the loss or destruction of valuable information.
Most sites establish a policy and a schedule for regularly backing up
files on public volumes. Sections 5.8.3 through 5.8.12 provide·the
operating procedures for backing up both selected files and entire
volumes.
It is just as desirable to back up information on private volumes as
it is to back up public volumes. However, responsibility for backing
up the files on private volumes usually is left to the individual
owners of those files and volumes.
There are two kinds of back-ups of public disk files and volumes:
(1)
incremental, or partial, back-ups, and (2) full, or all-inclusive,
back-ups. The back-up medium, in either case, can be disk or tape.
Incremental backups efficiently capture only those files that have
been modified recently.
Periodic full
back-ups are necessary to
provide the basis for reconstruction of a lost volume.
As a rule, incremental back-ups are done more frequently than system
back-ups.
Normally, you decide, after consulting with users of the
system, how frequently to back up files and volumes and how long to
retain back-up media.
Generally, you are responsible for setting up a schedule
up files and volumes and for maintaining this schedule.

for

backing

The following schedule for backing up public disk volumes on magnetic
tape affords adequate protection of data for many installations:
•

Daily -- An incremental back-up retained for seven days. This
schedule requires seven daily tapes that are rotated once a
week.

•

Weekly -- An incremental back-up retained for four weeks.
This schedule requires four weekly sets of tapes that are
rotated once every four weeks.

•

Monthly -- An all-inclusive back-up retained for a year.
This
schedule requires twelve monthly sets of tapes that are
rotated once a year.
5-16

MAINTAINING PUBLIC FILES AND VOLUMES
Despite all precautions, there is always the risk of losing a file.
Frequent back-ups and longer retention periods reduce this risk.
You can perform full (all-inclusive) back-ups to tape or copy the
volume to another disk.
Each has its advantages and disadvantages.
The advantage of using tape for back-ups is the much lower media cost,
which may in turn permit you to retain back-ups longer than keeping
full back-ups on disk would.
Tb~re are several advantages to keeping copies on disk, which in
some
cases
outweigh
their higher cost.
Disks exhibit better data
reliability than tapes.
Furthermore, disks tend to degrade less in
storage.
Also, if you have to replace a lost volume from its back-up
medium, a disk back-up volume is ready for immediate use, whereas you
must first restore a tape to disk.

Finally, if you use disks for back-up, you can make use of ~ "rotating
back-up set,"
in which several disks or sets of disks are used in
rotation on the system. At the end of each period of use
(for
example, once a month), the volume or volume set currently in use is
copied to the oldest set of disks, the current volume is retired,
and
the new copy is put online for use during the next period.

5.8.1

Rotating Back-up Sets

Rotating back-up sets have their own advantages and disadvantages,
this section describes.

A rotating back-up set offers two major advantages:
1.

Your back-up copy (the volume or volume set just retired)
is
known to be good, since it has been in use.
The integrity of
the new copy will be confirmed by its subsequent use;
any
defects discovered can be repaired using the back-up copy.

The free space on the new volume is compressed, and all the
files
on it are made contiguous or almost contiguous,
resulting in better file system performance.

There are three disadvantages to a rotating backup set:
1.

Rotating back-up sets are more vulnerable to disk errors than
sets created by retiring the copy and continuing to run with
the original. A disk error during the copy operation results
in corrupted data on your new volume;
disk errors in
directories or file headers will result in the loss of one or
more files.
Thus, you must monitor the copy operation very
carefully for errors and manually repair any problems that
arise.

You cannot perform the copy operation while users are updating
files.
The volume or volume set must be write-locked so that
the copy will be consistent. This restriction only applies to
rotating back-up sets;
it does not apply when you make a
back-up copy that will be retired for back-up use.
{Even
though individual files may be incomplete, they will be
covered. by the next incremental back-up.)

~-17

MAINTAINING PUBLIC FILES AND VOLUMES
3.

5.8.2

Files created with explicit placement lose their placement
when the 'volume is copied. This means you should not use a
rotating back-up set if the volume's primary contents are a
set of data base files that were carefully placed for
optimized performance.

Backing Up Disk Volumes

The preferred method is to use the Backup Utility
incremental and full back-ups.

(BACKUP)

for

both

NOTE
DIGITAL does not intend to support the
use of the Disk Save and Compress (DSC)
utilities on VAX/VMS starting with the
next major release.
For this reason,
users who are new to the system should
use the Backup Utility and not the DSC
utilities. Current users of DSC should
begin
planning
their transition to
BACKUP now.
For more information on the
Utilities Reference Manual.

Backup

Utility,

refer

The following sections discuss various ways you can
and files.

5.8.3

the

VAX-11

back

volumes

Backing Up the System Disk (Using Stand-alone BACKUP)

To back up the system disk, you need to use Stand-alone BACKUP.
You
can back up the system disk onto magnetic tape or another disk. You
should follow the procedures given in the software installation guide
for your VAX-11 processor.

5.8.4

Restoring the System Disk (Using Stand-alone BACKUP)

To restore the system disk, you need to use Stand-alone BACKUP.
You
should follow the procedures given in the software installation guide
for your VAX-11 proc~ssor.

5.8.5

Backing Up a Public Disk to Disk

The procedure below describes how to copy the contents of a public, or
nonsystem, disk to another disk. A public disk is a disk that has
been mounted with the /SYSTEM qualifier.
This procedure is performed online. Confirm that your intended target
volume · has sufficient capacity. You need only write-lock the source
volume device to prevent users from changing any data on the disk.
However, users still can read data.

5-18

MAINTAINING PUBLIC FILES AND VOLUMES
Procedure
1.

Issue the following command to warn all users that the disk
will be dismounted and write-locked so the contents of the
disk can be copied to another disk:
REPLY/ALL/BELL

message-text"

This message should include the name of the source disk being
write-locked and indicate in how many minutes the write-lock
will occur.
2.

Use the SHOW/DEVICE/FILE command to ensure that all files on
the disk have been closed;
broadcast messages to users with
open files, as necessary.

At the time
indicated
DISMOUNT/NOUNLOAD command
disk as follows:

by
to

the
message,
issue
the
logically dismount the source

DISMOUNT/NOUNLOAD device-name
4.

Write-lock the source disk by pressing the WRITE-PROTECT
switch to the ON position. This switch is located on the
front panel of the disk drive.

Mount the source
follows:

disk

again

MOUNT/SYSTEM device-name:
6.

Allocate a drive for the target
command:

using

the

MOUNT

command

volume-label
volume

with

the

following

ALLOCATE device-name:
7.

Place the target volume in the allocated drive and ready the
device by pressing the RUN/STOP button or the START/STOP
switch.

Mount the target volume by issuing the following command:
MOUNT/FOREIGN device-name:

Invoke the Backup Utility with the following command:
BACKUP/IMAGE/VERIFY input-device:

output-device:

10.

See the VAX/VMS System Messages and Recovery Procedures
Manual or the VAX-11 Utilities Reference Manual if the Backup
Utility returns any ver1f1cat1on error messages.

11.

Dismount and deallocate the target volume with the
comands:

following

DISMOUNT device-name:
DEALLOCATE device-name:
12.

Remove the target volume from the drive and put a label on
the outside of the volume that specifies the volume label and
current date.

~-lQ

MAINTAINING PUBLIC FILES AND VOLUMES
13.

Dismount the source disk
command as follows:

issuing

the

DISMOUNT/NOUNLOAD

DISMOUNT/NOUNLOAD device-name:
14.

Write-enable the source disk by
switch to the OFF position.

15.

Remount the source disk with the MOUNT command as follows:
MOUNT/SYSTEM device-name:

16.

pressing

the

WRITE-PROTECT

volume label

Inform all users that the source disk is
write-locked by issuing the following command:

longer

REPLY/ALL/BELL "message-text"
Example

$ REPLY/ALL/BELL "DMA2:

WILL BE WRITE-LOCKED IN 5 MINS.

FOR BACK-UP."

OPAO:,SYSTEM
06:31:29.78
DMA2: WILL BE WRITE-LOCKED IN 5 MINS. FOR BACK-UP.
$ SHOW DEVICE/FILES DMA2:

$ DISMOUNT/NOUNLOAD DMA2:
$ MOUNT/SYSTEM DMA2: PUBLIC
%MOUNT-I-WRITELOCK, volume is write locked
%MOUNT-I-MOUNTED, PUBLIC
mounted on DMA2:
$ ALLOCATE DMAl:
DMAl: Allocated
$ MOUNT/FOREIGN DMAl:
%MOUNT-I-MOUNTED, PUBLIC
mounted on DMAl:
$ BACKUP/IMAGE/VERIFY DMA2: DMAl:
$ DISMOUNT DMAl:
$ DEALLOCATE DMAl:
$ DISMOUNT/NOUNLOAD DMA2:
$ MOUNT/SYSTEM DMA2: PUBLIC
%MOUNT-I-MOUNTED, PUBLIC
mounted on DMA2:
$REPLY/ALL/BELL "DMA2: IS NO LONGER WRITE-LOCKED."
OPAO:,SYSTEM
06:46:44,23
DMA2: IS NO LONGER WRITE-LOCKED.
$

The operator informs all system users that DMA2 will
dismounted
and write-locked for back-up purposes.
operator logically dismounts the source disk, write-locks
and then remounts it. After remounting the source disk,
operator performs the necessary steps to mount and ready
target disk.

be
The
it,
the
the

The operator then issues the BACKUP command to perform an
image copy from DMA2 to DMAl with verification. The operator
dismounts and deallocates the target volume and removes it
for storage. The source volume is dismounted so that it can
be write-enabled. Once this is done, the operator notifies
the users that DMA2 is available and the dollar sign prompt
($) returns.
The operator then dismounts and deallocates the target disk,
dismounts, write-enables, and remounts the disk on DMA2, and
finally, informs all users that they can write to DMA2.

MAINTAINING PUBLIC FILES AND VOLUMES
5.8.6

Selective Back-Up of Files Using BACKUP

The procedure below describes how to copy selected files from one disk
to another. Selective back-ups may be necessary for certain groups of
files requiring special treatment. Generally, if files must be backed
up regularly, you should create a command procedure that contains the
required back-up commands.
For more information on creating command procedures,
VAX/VMS Guide to Using Command Procedures.

refer

the

Procedure
1.

Allocate a drive for the target volume with the command:
ALLOCATE device-name:

Place the target volume in the allocated drive.
Ready that
device
by pressing either the RUN/STOP button or the
START/STOP switch.

Mount the target volume with the command:
MOUNT output-device-name:

Issue the following command
source disk:

volume-label

allocate

drive

for

the

ALLOCATE source-device-name:
5.

Place the source disk in the allocated drive and ready that
device by pressing the RUN/STOP button or the START/STOP
switch.

Mount the source disk by typing:
MOUNT source-device-name:

volume-label

Copy the files from the source disk to the target volume with
the following command:
BACKUP input-spec output-spec
This command is repeated as necessary for the sets of files
that are to be saved.
Note that BACKUP creates output
directories automatically.

Dismount and deallocate the target volume with the commands:
DISMOUNT device-name:
DEALLOCATE device-name:

Remove the target volume from the device and affix a label to
the outside of it that indicates the volume label and the
current date.

10.

Dismount and deallocate the source disk with the commands:
DISMOUNT device-name:
DEALLOCATE device-name:

11.

Remove the source disk from the device.

5-21

MAINTAINING PUBLIC FILES AND VOLUMES
Example
$ ALLOCATE DMAO:
DMAO: ALLOCATED
$ MOUNT DMAO:
SPBACKUP
%MOUNT-I-MOUNTED, SPBACKUP
mounted on DMAO:
$ ALLOCATE DMAl:
DMAl: ALLOCATED
$ MOUNT DMAl:
DATCOM
%MOUNT-I-MOUNTED, DATCOM
mounted on DMAl:
$BACKUP DMAO: [GEORGE ••• ] ·DMAl: [* ••• ]/OWNER ITIC=ORIGINAL
$BACKUP DMAO: [SYSEXE]DUNGEON.*;* DMAl: [SYSEXE]
$ DISMOUNT DMAO:
$ DEALLOCATE DMAO:
$ DISMOUNT DMAl:
$ DEALLOCATE DMAl:
The operator copies files from three directories on DMAl to three
newly
created
directories on DMAO.
After performing the
necessary steps to mount and ready the target and source volumes,
the operator uses BACKUP commands to copy:
•

All the files in the [GEORGE] directory and its subdirectories
on the· source disk to the directories with the same name on
the target volume

•

All the files with the file name DUNGEON in the
[SYSEXE]
directory on the source disk to the [SYSEXE] directory on the
target volume

When the back-up operation completes, the operator dismounts
deallocates the target and source volumes.

5.8.7

and

Incremental Back-ups

Rather than save all the files on a volume every time a save is
performed,
it is better to save only those files that were created or
modified since the last save operation. This is termed an incremental
back-up.
To perform incremental back-ups, use the /SINCE=BACKUP input qualifier
and the /RECORD command qualifier. The /SINCE=BACKUP input qualifier
directs BACKUP to select only those files that have been created or
modified
since
the last BACKUP/RECORD operation.
The /RECORD
qualifier directs BACKUP to record the current date in. the back-up
date field of each file's header.
For example:
$BACKUP/RECORD DB2: [* ••• ]/SINCE=BACKUP MTA0:19JUN.BCK
To use the /RECORD command qualifier, you must own the files
the user privilege SYSPRV.
NOTE
If you use the /RECORD command qualifier
to perform incremental back-ups on disk
volumes, it is a good idea to discourage
its use by other users.
Incomplete
back-ups may occur if
other
users
perform
back-ups
using the /RECORD
command qualifier.
5-22

have

MAINTAINING PUBLIC FILES AND VOLUMES
The drawback to performing incremental back-ups is that you accumulate
a large number of tape or disk volumes containing the incremental savesets. You should perform incremental back-ups at regular intervals
{daily and weekly, for example) and full back-ups at greater intervals
{once a month, for ·example).

5.8.8

Performing Daily Back-up Operations

In performing daily back-ups, you would follow the suggestions in
Section 5.8.7 for
incremental back-ups, but may want to include the
/IGNORE=INTERLOCK qualifier.
This qualifier instructs the Backup
Utility to copy files even if they ar~ open for writing. This means
that you do not need to write-lock the source volume prior to
initiating the back-up operation.
Example
$ MOUNT/FOREIGN MTAO:
%MOUNT-I-MOUNTED, INCDSJ mounted on MTAO:
$ BACKUP/IGNORE=INTERLOCK/RECORD/SINCE=BACKUP PUBLIC:[* ••• ]' MTAO:INCD12JUN
$ DISMOUNT MTAO:

5.8.9

Performing Weekly Back-up Operations

You can perform weekly back-ups in much the same manner as daily
back-ups. However, the /SINCE qualifier specifies the date of the the
last weekly back-up, normally one week earlier.
Example
{This example assumes that the current date is 14-JUN-1982.)

$ MOUNT/FOREIGN MTAO:
%MOUNT-I-MOUNTED, INCW7J mounted on MTAO:
$ BACKUP/IGNORE=INTERLOCK/RECORD/SINCE=7-JUN-1982 PUBLIC:[* ••• ] MTAO:INCW14JUN
$ DISMOUNT MTAO:

5.8.10

Performing Monthly Back-up Operations

Monthly back-ups should be all-inclusive; that is, they should be
full back-ups.
Thus, you specify the /IMAGE qualifier to copy not
just the files, but all the information required to initialize the
volume or volume set when you need to perform a restore operation.
Example

$ MOUNT/FOREIGN MTAO:
%MOUNT-I-MOUNTED, FULLMA mounted on MTAO:
$ MOUNT/FOREIGN MTAl:
%MOUNT-I-MOUNTED, FULL02 mounted on MTAl:
$ BACKUP/IMAGE/IGNORE=INTERLOCKiRECORD PUBLIC: MTAO:FULLJUN82,MTA1:
%BACKUP-I-RESUME, resuming operation on volume 2
%BACKUP-I-RESUME, resuming operation on volume 3
%BACKUP-I-RESUME, resuming operation on volume 4

$ DISMOUNT MTAO:
$ DISMOUNT MTAl:

MAINTAINING PUBLIC FILES AND VOLUMES
5.8.11

Backing Up and Restoring the Console Medium

The procedures for backing up and restoring the console medium are
processor-dependent.
You can find descriptions of the procedures in
the software installa_tion guide for your VAX-11 processor.

5.8.12

Sequential Disk Save Sets

The Backup Utility can treat a disk volume as it would a tape volume.
In such a case the disk volume is called a sequential disk save set.
However, there ar·e a few minor differences, as described in this
section.
A disk volume that contains a sequential disk save set must
be mounted with the /FOREIGN qualifier. The Backup Utility manages
the file structure on the volume.
To use sequential disk save sets consisting of more than
you must have the user privilege LOG_IO.

one

volume,

An example of a system where sequential disk save sets would be used
is a system having a large fixed-media disk and a small removable disk
but no tapes. The small disk would be used to contain sequential disk
save sets.

5.8.12.1 Saving Data to Sequential Disk Save sets - To save data to a
sequential disk save set, make certain that the output-specifier
contains a device name for a disk device, a save-set-name, and the
/SAVE SET qualifier. The output-specifier cannot contain a directory
name.- For example:
$BACKUP (ROGERS ••• ] DLA0:29JUN.BCK/SAVE_SET
The output disk is initialized by d~fault. The volume label is either
derived from the save-set-name or specified with the /LABEL output
save set qualifier.
If there are files on the output disk that you
want to save, use the /NOINITIALIZE qualifier.
For example:
$ BACKUP/NOINITIALIZE [JONES ••• ] DLA0:30JUN.BCK/SAVE_SET
Note, that the following
/NOINITIALIZE qualifier:

restrictions

apply

you

use

the

•

The disk must be Files-11 Structure Level 2

•

The disk must not be part of a volume set

•

The cluster factor on the disk must be 1

•

The free space on the disk cannot be fragmented into more than
100 pieces

•

The index file cannot be extended

•

The Master File Directory (MFD) cannot be extended

The last two restrictions limit the number of save sets that
place on a sequential disk to approximately 20.
NOTE
A set of disks written with BACKUP's
sequential disk handling is referred to
5-24

you

can

MAINTAINING PUBLIC FILES AND VOLUMES
as a loosely coupled volume set.
That
is,
it is a volume set without some of
the informational structures that are
present in a normal volume set, such as
the volume set list file.
Because of
the subtle differences in the structure,
you should not write files onto
a
sequential disk volume as if it were a
normal Files-11 disk;
confusing and
somewhat
obscure errors may result.
Because the sequential disk volumes are
part of a volume set, they cannot be
processed individually by the Verify
Utility.

5.8.12.2 Restoring Data from Sequential Disk Save Sets - VAX/VMS can
read a sequential disk save set either as a sequential disk (if the
volume is mounted using the /FOREIGN qualifier)
or as a Files-11
volume.
If the volume is read as a sequential disk, the default
directory for the save set file-specifier is [000000].
If the volume
is read as a Files-11 volume, the default directory is the default
directory for your process; to read the save set you must specify the
directory [000000].
The following two examples illustrate a user reading data first
sequential disk and then as a Files-11 volume.

$ MOUNT/FOREIGN DLAO:
%MOUNT-I-MOUNTED, 29JUN01 mounted on DLAO:
$BACKUP DLA0:29JUN.BCK/SAVE SET DB27[ROGER ••• ]
$
$ MOUNT DLAO: 29JUN01
%MOUNT-I-MOUNTED, 29JUN01 mounted on DLAO:
$BACKUP DLAO: [000000]29JUN.BCK/SAVE SET DB2: [ROGER ••• ]
$

Multivolume save sets are handled differently when you read the disk
as a sequential disk than when you read the disk as a Files-11 disk.
If you read the disk as a sequential disk,, the volumes must be mounted
one at a time as you would a multivolume tape save set.
If you read
the disk as a Files-11 disk, all the volumes must be mounted
(as for
any Files-11 volume set).

5.8.12.3 Summary - The following items are identical when
with sequential disk save sets or tape volume save sets:

dealing

•

Volume must be mounted using the /FOREIGN qualifier

•

Volumes can be mounted one by one

•

More than one device can be specified to overlap mounting
dismounting the volumes

and

The following items differ between tape save sets and sequential
save sets.

disk

Save operations to tape simply require a
• specified
in
the output-specifier;

tape device to be
Save operations to
sequential disks require a disk device to be specified in the
output-specifier,
and
the
/SAVE SET qualifier must be
specified with the output-specifier. 5-25

MAINTAINING PUBLIC FILES AND VOLUMES
To place more than one save
• output
save-set qualifier

the. /NOREWIND
set on a tape,
to place more
must be specified;
than one save set on a sequential disk,
the /NOINITIALIZE
command qualifier must be specified.

•

5.9

LOG IO privilege is necessary to write multivolume sequential
disk save sets; however, it is not necessary to write tapes.

BACKUP JOURNAL FILES

A BACKUP journal file contains records of BACKUP save operations and
the file specifications of the files that were saved with each
operation.
To find a particular file in a multivolume save set,
you
can review the BACKUP journal file to find the tape volume that
contains the file.
Use the /JOURNAL command qualifier to create, or append
information
to,
a BACKUP journal file.
If no file-specifier appears with the
/JOURNAL command qualifier,
the name of the BACKUP journal file
defaults to SYS$DISK:BACKUP.BJL.
The default file type for BACKUP
journal files is BJL.
If the specified BACKUP journal file does not exist,
it is created;
if it already exists, the new journal information is appended to the
existing journal file.
You can start a new version of a BACKUP
journal file by creating an empty file with an editor such as EDT or
the DCL command CREATE.
To list a BACKUP journal file, enter the command:
BACKUP/LIST[=file-spec]/JOURNAL[=file-spec]
with
a
You must not specify an
inputor
output-specifier
BACKUP/JOURNAL/LIST command.
If the file specification is omitted
if the
from the /LIST qualifier, output is directed to SYS$0UTPUT;
file specification is omitted from the /JOURNAL qualifier, the default
BACKUP journal file is used.
You can use file selection qualifiers with the BACKUP/JOURNAL/LIST
command.
This allows you to locate a set of files in a save set just
as the DIRECTORY command allows you to locate a set of files on a
disk.
The following example shows all files
in the directory
[SMITH.PROGS] backed up after July 5,
1982,
listed
in the BACKUP
journal file ARCH.BJL:
$ BACKUP/LIST/JOURNAL=ARCH.BJL/SELECT=[SMITH.PROGS]/SINCE=S-JUL-1982
The following example shows the use of BACKUP journal files.
$BACKUP/JOURNAL/LOG/IMAGE

DRA2: MTA0:3JUL.FUL

(first set is printed here)
%BACKUP-I-RESUME, resuming operation on volume 2
%BACKUP-I-READYWRITE, mount volume 2 on MTAO: for writing
Press return when ready: ~
(second set is printed here)
$ BACKUP/JOURNAL/LIST
Listing of BACKUP journal
Journal file DB2: [SYSMGR]BACKUP.BJL;l on 3-JUL-1981 00:40:56.36
5-26

MAINTAINING PUBLIC FILES AND VOLUMES
Save set 3JUL.FUL created on 3-JUL-1982 00:40:56.36
Volume number 1, volume label 3JUL01
[COLLINS]ALPHA.DAT;4
[COLLINS]EDTINI.EDT;5
[COLLINS]LOGIN.COM;46
[COLLINS]LOGIN.COM;45
[COLLINS]MAIL.MAI;l
[COLLINS]MAR.DIR;l
[COLLINS.MAR]GETJPI.EXE;9
[COLLINS.MAR]GETJPI.LIS;l4

[LANE]LES.MAI;l
Save set 3JUL.FUL created on 3-JUL-1982 00:40:56.36
Volume number 2, volume label 3JUL02
[LANE]MAIL.MAI;l
[LANE]MEMO.RN0;5
[LANE]MEMO.RN0;4

[WALTERS.VI]KD.RN0;52
End of BACKUP journal

5.9.1

Backing Up Volumes and Volume Sets

To back up an entire disk volume or volume set, use the command
BACKUP/IMAGE.
The /IMAGE qualifier directs BACKUP to create a save
set that contains data necessary for reinitializing the disk volume.
You cannot use other file selection qualifiers with the /IMAGE command
qualifier. All files on the disk are saved;
this includes reserved
files and lost files (files that have no directory entry).
The following example shows a save operation from a Files-11
tape:
$ BACKUP/IMAGE DRAl:

disk

MTAO:lJUN.BCK

If you use tape as the back-up medium, you may need to mount
additional tapes. The number of tapes depends on the size of the disk
being saved.
If you use disks as the back-up medium, you can either use BACKUP to
copy files to the new disk or you can create a save set on the new
disk.
If you create a save set on the new disk, you must create a
directory to which the save set will be written and you must use the
/SAVE SET output save set qualifier. The directory must be included
in the save-set-name or it must be your default directory.
For example:
$ SHOW DEFAULT
DMAl: [SYSTEM]
$BACKUP/IMAGE DMAl: DB4: [BACKUPS]21JANDMA1.BCK/SAVE_SET
You should specify the /RECORD command qualifier if you are performing
the full volume back-up in conjunction with incremental back-ups that
use the /RECORD qualifier.

5-27

MAINTAINING PUBLIC FILES AND VOLUMES
5.9.1.1 Backing Up An Entire Volume Set - You can back up an entire
volume set by following the procedures outlined in Section 5.9.1.
Simply name the device on which the root volume (volume number 1)
is
mounted.

5.9.1.2 Backing Up a Disk Volume Set When Drives Are Limited - BACKUP
requires that you mount all volumes of a volume set for back-up.
Thus, it may not be possible to copy a large volume set directly to
disk if you have a limited number of disk drives. You can copy the
volume set one volume at a time with the BACKUP/IMAGE/VOLUME command
using one more drive than the number of volumes in the volume set.
You must write-lock the volume set during the entire procedure to
ensure consistency.
Example
(suitable warning broadcasts)

$ DISMOUNT/NOUNLOAD DRAO:
$ MOUNT/SYSTEM/NOWRITE DRAO:,DRA1:,DRA2: PUBLIC01,PUBLIC02,PUBLIC03
%MOUNT-I-MOUNTED, PUBLICOl mounted on DRAO:
%MOUNT-I-MOUNTED, PUBLIC02 mounted on DRAl:
%MOUNT-I-MOUNTED, PUBLIC03 mounted on DRA2:
$ MOUNT/FOREIGN DRA3:
%MOUNT-I-MOUNTED, SCRATCHOl mounted on DRA3:
$ BACKUP/IMAGE/VOLUME=! DRAO: DRA3:
$ DISMOUNT DRA3:
$ MOUNT/FOREIGN DRA3:
%MOUNT-I-MOUNTED, SCRATCH02 mounted on DRA3:
$ BACKUP/IMAGE/VOLUME=2 DRAO: DRA3:
$ DISMOUNT DRA3:
$ MOUNT/FOREIGN DRA3:
%MOUNT-I-MOUNTED, SCRATCH03 mounted on DRA3:
$ BACKUP/IMAGE/VOLUME=3 DRAO: DRA3:
$ DISMOUNT DRA3:
$ DISMOUNT/NOUNLOAD DRAO:
$MOUNT/SYSTEM DRAO:,DRA1:,DRA2: PUBLIC01,PUBLIC02,PUBLIC03
%MOUNT-I-MOUNTED, PUBLICOl mounted on DRAO:
%MOUNT-I-MOUNTED, PUBLIC02 mounted on DRAl:
%MOUNT-I-MOUNTED, PUBLIC03 mounted on DRA2:

(announce public disk is available again)
The operator needs to back up a three-volume volume set.
Thus,
at least four drives are required.
The operator warns the users
that drives DRAO, DRAl, and DRA2 are about to be write-locked for
back-ups.
Next the operator issues MOUNT commands for the
volumes PUBLICOl, PUBLIC02, and PUBLIC03 on drives DRAO,
DRAl,
and
DRA2,
respectively, to specify write-locking with the
/NOWRITE qualifier. Note that PUBLICOl is the root volume.
A
scratch volume is mounted on drive DRA3 to be used for the target
volumes. As the volume on DRA3 is filled, it is dismounted and a
new scratch volume is mounted.
This procedure repeats until the
third volume has been copied. Then the last volume on DRA3 is
dismounted.
To enable wr'iting on the volume set again, the
operator dismounts (but does not unload) DRAO,
then mounts the
volumes again, omitting the /NOWRITE qualifier. As a final step,
the operator announces to the users that the volume set is
available again for writing.
5-28

MAINTAINING PUBLIC FILES AND VOLUMES
5.9.2

Restoring Entire Disk Volumes

To restore an entire disk volume from a save set that was created
using the /IMAGE command qualifier, you must mount the new volume
using the DCL command MOUNT/FOREIGN. You must then restore the volume
with the BACKUP/IMAGE command.
When a save set is created using the /IMAGE command qualifier, the
data necessary for reinitializing the volume is placed in the save
set. When the /IMAGE command qualifier is used to restore the volume,
the new volume is initialized using that data in the save set.
For example:
$ MOUNT/FOREIGN DRAl
%MOUNT-I-MOUNTED, 24JUND mounted on DRAl:
$BACKUP/IMAGE MTA0:24JUNDMA1.BCK DRAl:
$

The volume is initialized using the initialization parameters saved in
the save set. All files and directories in the save set are restored
to the new volume.
To restore a volume set in image mode, you must mount all the volumes
of the set as foreign volumes. You must also specify the list of
devices on which the volumes are mounted in the output-specifier of
the BACKUP command.
$ MOUNT/FOREIGN DRAO:
%MOUNT-I-MOUNTED, PUBLICOl mounted on DRAO:
$ MOUNT/FOREIGN DRAl:
%MOUNT-I-MOUNTED, PUBLIC02 mounted on DRAl:
$ MOUNT/FOREIGN DRA2:
%MOUNT-I-MOUNTED, PUBLIC03 mounted on DRA2:
$BACKUP/IMAGE MTA0:31JUNPUB DRAO:,DRA1:,DRA2:
The volumes receive volume set numbers in the order in which they are
listed in the BACKUP command.
In this example, DRAO:, DRAl:, and
DRA2:
become volumes 1, 2, and 3, respectively.

5.9.2.1 Changing
If you need to
volume, you must:

Volume Initialization Parameters Before Restoring change the volume initialization parameters for a

Initialize the
parameters.

new

volume

Mount the new volume using the /FOREIGN qualifier.

Restore the volume
command qualifier.

with

using

BACKUP,

the

using

new

the

initialization

/NOINITIALIZE

In the following example the cluster size of the volume is being
changed to 3. ·
The other volume initialization parameters take the
default values from the INITIALIZE command.
$ ALLOCATE DRA2
DRA2: ALLOCATED
$ INITIALIZE/CLUSTER SIZE=3 DRA2: TEST PROGS
$ MOUNT/FOREIGN DRA2%MOUNT-I-MOUNTED, TEST PROGS mounted on DRA2:
$ BACKUP/IMAGE/NOINITIALIZE/TRUNCATE MTAO:lJUN.BCK

£;-?Q

DRA2:

MAINTAINING PUBLIC FILES .AND VOLUMES
The only initialization parameter that you cannot change is the
structure level of the volume.
If you change the cluster factor, as
in the above example, it is good practice to include the /TRUNCATE
qualifier.

5.9.2.2 Restoring a Volume From Incremental Back-ups - If you
have
been performing a combination of full and incremental back-ups on a
public volume, you must use the following procedure to recover the
volume from its back-ups, should the volume be lost.
First, restore the volume from the last full back-up, using an image
restore operation. The /RECORD qualifier is required for the correct
operation of this procedure.
$ MOUNT/FOREIGN DRAO:
%MOUNT-I-MOUNTED, SCRATCH mounted on DRAO:
$ MOUNT/FOREIGN MTAO:
%MOUNT-I-MOUNTED, FULLMA mounted on MTAO:
$ MOUNT/FOREIGN MTAl:
%MOUNT-I-MOUNTED, FULL02 mounted on MTAl:
$ BACKUP/IMAGE/RECORD MTAO:FULLJUN82,MTA1: DRAO:
%BACKUP-I-RESUME, resuming operation on volume 2
%BACKUP-I-RESUME, resuming operation on volume 3
%BACKUP-I-RESUME, resuming operation on volume 4

$ DISMOUNT MTAO:
$ DISMOUNT MTAl:
$ DISMOUNT/NOUNLOAD DRAO:
Now mount the disk as a file-structured volume and apply the
incremental back-ups in reverse chronological order. Start with the
last daily back-up; then apply the preceding daily back-ups, and
finally the weekly back-~ps, as follows:
$ MOUNT DRAO: PUBLIC
%MOUNT-I-MOUNTED, PUBLIC mounted on DRAO:
$ MOUNT/FOREIGN MTAO: INCD17
%MOUNT-I-MOUNTED, INCD17 mounted on MTAO:
$BACKUP/INCREMENTAL MTAO:INCD17JUN DRAO:
$ DISMOUNT MTAO:
$ MOUNT/FOREIGN MTAO: INCD16
%MOUNT-I-MOUNTED, INCD16 mounted on MTAO:
$BACKUP/INCREMENTAL MTAO:INCD16JUN DRAO:
$ DISMOUNT MTAO:
$ MOUNT/FOREIGN MTAO: INCD15
%MOUNT-I-MOUNTED, INCD15 mounted on MTAO:
$BACKUP/INCREMENTAL MTAO:INCD15JUN DRAO:
$ DISMOUNT MTAO:
$ MOUNT/FOREIGN MTAO: INCW14
%MOUNT-I-MOUNTED, INCW14 mounted on MTAO:
$BACKUP/INCREMENTAL MTAO:INCW14JUN DRAO:
$ DISMOUNT MTAO:
$ MOUNT/FOREIGN MTAO: INCW7J
%MOUNT-I-MOUNTED, INCW7J mounted on MTAO:
$BACKUP/INCREMENTAL MTAO:INCW7JUN DRAO:
$ DISMOUNT MTAO:
.

5-30

MAINTAINING PUBLIC FILES AND VOLUMES
Applying the latest incremental back-up using the
/INCREMENTAL
qualifier causes the volume's directories to be restored to their
state at the time the back-up was taken.
In addition, all the files
in the incremental save set are restored. Files that are present on
the volume from the full restore operation, but are not present in the
directories of the
incremental back-up, are deleted.
{These files
were deleted by users during the time period between the full back-up
and the last incremental back-up.)
In applying the earlier incremental back-ups, BACKUP restores the
remaining files that have directory entries on the volume.
These are
files that were last modified some time before the last incremental
back-up, and were still present when the last incremental back-up was
taken. Note that BACKUP will restore the volume correctly regardless
of the order in which the incremen,tal back-ups are applied;
using
reverse chronological order is most efficient.
The /RECORD and
/INCREMENTAL qualifiers must be used where shown to obtain the correct
operation.
If you choose to selectively exclude certain files in your incremental
back-ups
{for example, listing files or batch logs), these files will
not be restored, but will have directory entries in the resulting
volume.
You can clean up these "null" directory entries by running a
repair pass with the Verify Utility (see the VAX-11 Utilities
Reference Manual).

5.9.3

Restoring Individual Files

To restore individual files or directories, use the BACKUP restore
commands documented in the Backup Utility chapter of the VAX-11
Utilities Reference Manual.
To restore individual files
in
large
save
sets,
use
the
BACKUP/LIST/JOURNAL command to find the volume that contains the
files.
Mount the volume, then enter the BACKUP command to select and
restore the desired files.
If the volume is not the first volume in a
multivolume save set, you will receive the warning message:
%BACKUP-W-NOT1STVOL, tape 'name'

5.9.4

is not the start of a save set

BACKUP Media Security

Remember that the file system treats a BACKUP save set, whether it is
stored on disk or on tape, as a single file.
BACKUP does not check
protection on individual files within the save set. Therefore, it is
crucial to the system's file security to protect save sets adequately.
Give save 'set files that you keep online a restrictive
file
protection.
(Use the /OWNER UIC and /PROTECTION qualifiers to the
BACKUP command, as described- in the VAX-11 Utilities Reference
Manual.) Provide physical security for save sets that you keep offline
(for example, tapes and sequential disks); preferably you should lock
them up.
·
If a user comes to you wanting to restore a particular file,
you
should not loan out the back-up tape because you would give out access
to all the files on the tape. The safest way to restore a particular
file
is tor you to mount the tape and restore the file with a command
of the form:
$ BACKUP MTAO: SAVE SET/SELECT= [JONES. TEXTPROC] LASTMONTH. DAT [ * ... ] /OWNER_UIC=ORIGINAL

5-31

MAINTAINING PUBLIC FILES AND VOLUMES
The file will be restored with its original directory, ownership,
and
protection, allowing the file system to determine whether the user was
ever allowed access to the file.

5.10

DISK SPACE MANAGEMENT

Parkinson's Law, as applied to public disk storage, states that user
files will expand to exceed the available disk storage space.
You
have two tools at your disposal to combat this problem:
•

File expiration

•

Disk quotas

5.10.1

File Expiration

File expiration is a file system feature
(available on Files-11
Structure Level 2 disks only) that uses the expiration date of each
file to track the file's use.
The expiration dates aid the disposal
of seldom-used files.
To enable the setting of expiration dates, use the command
SET VOLUME devname: /RETENTION=(min,max)
For min and max you specify the minimum and maximum retention periods
for files on the volume, expressed as delta time values.
For example,
the following command sets the minimum retention period to 15 days and
the maximum to 20 days:
$ SET VOLUME DRAO: /RETENTION=(l5-0:0,20-0:0)
The retention periods operate as follows:
every time a user accesses
a file
(for either a read or write operation), and that file's
expiration date is earlier than the cur~ent date plus the m1n1mum
retention period, the file's expiration date is updated to the current
date plus the maximum retention period. Thus, the expiration date of
a frequently accessed file fluctuates between the minimum and maximum
period plus the current date.
When you set a suitable interval
between minimum and maximum retention periods, you can trade between
accuracy and efficiency in maintaining expiration
dates.
The
difference between the two periods is the
interval at which the
expiration date of a frequently accessed file will be updated.
If you specify only a single value
in the SET VOLUME/RETENTION
command,
it becomes the minimum retention period;
the maximum
retention period is set to twice the minimum or th& minimum plus 7
days, whichever is less.
You can simulate the maintenance of "access dates," available in some
other operating systems, by setting the retention periods to very
small values {for example, 1 hour). Note, however, that doing so will
incur substantial overhead in the file system in updating expiration
dates so frequently.
This feature does not automatically remove unused files;
it maintains
expiration dates to permit you to develop your own policy for handling
files with little or no activity. For example, the following BACKUP
command will copy to tape and then delete all expired files:
$BACKUP/DELETE PUBLIC: [* ••• ]/BEFORE=TODAY/EXPIRED MTAO:ARCH20JUN

5-32

MAINTAINING PUBLIC FILES AND VOLUMES
(Plan to retain the resulting tape for a substantial
unless you are unperturbed by user ire.)

period

time

NOTE
If you start maintaining
expiration
dates on a previously existing volume,
you should be aware that the expiration
dates on existing files are zero (until
the files are accessed).
Files with
expiration dates of zero are considered
expired.

5.10.2

Disk Quotas

You limit the amount of space available to individual users on public
volumes
(or volume sets) by creating and maintaining quota files on
those volumes.
Individual users can similarly restrict usage on
private volumes.
Quotas are maintained and enforced on a per-volume
basis. Each volume or volume set has its own quota file; a volume on
which quotas are not maintained has no quota file; on a volume set,
volume 1 contains the quota file.
Each entry in a quota file includes
the following information:
•

UIC -- UIC of a user entitled to maintain files on the volume

•

Usage -- Number of blocks on the volume taken up by the user's
files

•

Quota -- Maximum number of blocks on the volume that the
user's files can take up before an error message is issued

•

Overdraft
Number of blocks over the quota that
files can take up

the

user's

The absolute maximum number of blocks permitted a user on a volume
the sum of the quota and the overdraft.

You (or the user maintaining the volume)
identify UICs and assign
quotas and overdrafts with the Disk Quota Utility (see the VAX-11
Utilities
Reference
Manual).
Usage
counts
are
maintained
automatically by the system during normal file activities.
The name of the quota file
volume.

[OOOOOO]QUOTA.SYS

the

applicable

A quota file is initialized with an entry for UIC
[O,O].
The usage
count for this UIC should not change from 0 -- the UIC should own no
files.
Its quota and overdraft, however, serve as defaults in certain
situations, and so should be set to values most likely to be assigned
as quotas and overdrafts to other UICs.
A quota file requires one block of disk storage for each 16 entries.

5.10.2.1 Disk Quota Operations - During normal use of a volume with a
quota file, the system automatically updates the usage counts as users
create, delete, extend, and truncate files.
Users without entries in
the quota file are not allowed to create files or allocate space on
the volume, unless they have the EXQUOTA privilege.

5-33

MAINTAINING PUBLIC FILES AND VOLUMES
5.10.2.1.1 Exceeding the Quota - If an operation to add a new file or
expand a current file will put a user's usage count over the quota,
the system prohibits the operation and issues the following message:
disk quota exceeded
If the rejected operation is an extension of a file opened for write,
a user with an overdraft can perform the operation by retrying it.
Operations to extend the file will succeed until usage exceeds the sum
of the quota and the overdraft. At this point, the system reissues
the above message and prohibits further extensions to the file.
To create new
overdraft).

files,

user's

usage

must

below

Quota restrictions are not enforced for users with
privilege. However, their usage counts are maintained.

quota
the

(not

EXQUOTA

5.10.2.1.2 Suspending Quotas - The DISABLE command of the Disk Quota
Utility
(see the VAX-11 Utilities Reference Manual) suspends quota
operations on a volume. The ENABLE command of the Disk Quota Utility
lifts the suspension.
In addition, quota operations on a volume can
be suspended at mount time by specifying the /NOQUOTA qualifier to the
DCL command MOUNT. Note that when you suspend and then resume quota
operations on a volume, you will probably find incorrect usage values
in the quota file.
You carr correct the usage values with the REBUILD
command of the Disk Quota Utility or with the Verify Utility.
(The
VAX-11 Utilities Reference Manual describes both utilities.)
To discontinue quota operations on a volume, execute the
command, exit from DISKQUOTA, and delete the QUOTA.SYS file.

DISABLE

5.10.2.1.3 Ensuring Quota File Accuracy with REBUILD on Mount - When
a volume is mounted that was not properly dismounted the last time it
was used, the system performs an automatic REBUILD operation.
If
quotas are enforced on the volume, this action ensures that the quota
file accurately reflects usage of the disk,
in the event that the
system
failed,
the volume was physically removed before being
dismounted, or the WRITE PROTECT button was pushed.

5.10.2.2 Restrictions on Other System Operations - The
following
restrictions and limitations apply whether or not disk quotas are
being used:

5.11

•

The SYSPRV privilege is required to change the owner UIC of a
file,
because a change in file ownership consumes the
resources of another user

•

Relative volume 1 of the volume set
times.

must

online

all

ACCESSING TAPE AND DISK VOLUMES

Users may prepare their own volumes for use.
Or, depending on the
physical arrangement of the installation and the type of volume to be
accessed, you may be called upon to assist in the preparation of
volumes for use.
The following are some of the reasons why your
assistance may be required:
5-34

MAINTAINING PUBLIC FILES AND VOLUMES
•

The processor and its peripheral devices are off limits to
remotely located from some or all users

•

The magnetic tape file system has requested that a tape volume
be mounted

•

A system or public disk needs to be mounted

Therefore, at some installations, users must communicate with you to
either gain access to or create files.
Tape and disk volumes must be
physically mounted on devices, and the files contained on these
volumes must be backed up regularly.
Physically mounting a volume means placing the volume on a specific
drive and starting the drive. For tape drives, you load the tape into
the drive and then press the LOAD button to start the tape drive.
For
disk drives, you place the disk in the disk drive and then press the
START or RUN button to start the disk drive.
Before a user can access a tape or disk volume,
must be performed:

the

following

steps

The device on which the volume is placed should be
using the ALLOCATE command.

allocated

The volume must be physically mounted on the device.

New volumes must be initialized using the INITIALIZE command.

The user must mount the volume using the MOUNT command.

If you do not need to initialize the disk, the above steps can be
accomplished by a single MOUNT command that allocates the device and
requests assistance as necessary from the operator.
Allocating devices and initializing and mounting volumes are fully
described in the VAX/VMS Command Language User's Guide under the
ALLOCATE, INITIALIZE, and MOUNT commands and in the chapter in that
manual pertaining to disk and tape volumes.
You should also consult the VAX/VMS Magnetic Tape User's
more information on handling magnetic tape volumes.

Guide

for

The following sections discuss when and how to assist users in gaining
access to files on particular volumes.

5.12

REQUESTS TO MOUNT VOLUMES

Requests and notifications concerning the mounting and dismounting
disk and tape volumes fall into the following categories:

•

MOUNT requests -- Requests issued by the MOUNT command,
behalf of the user, to load disk and tape volumes

•

MTAACP requests -- Requests issued by the magnetic tape file
system
(MTAACP), on behalf of the user, to load additional
volumes in a magnetic tape volume set and to recover from
errors

•

BACKUP requests -- Requests issued by the Backup
behalf of a batch job, to load additional
multivolume save set and to recover from errors

Utility, on
volumes in a

MAINTAINING PUBLIC FILES AND VOLUMES
•

Mount and dismount notifications -- Messages
users mount and dismount disks and tapes

indicating

You must be enabled as a disk operator to receive disk
enabled as a tape operator to receive tape requests.

5.12.1

requests

when
and

Requests from the MOUNT Command

You receive requests to load disk and tape volumes when a MOUNT
command does not complete successfully (providing the user issuing the
MOUNT command has the TMPMBX privilege and does
not
specify
/NOASSIST).
See the VAX/VMS Command Language User's Guide for a
description of the MOUNT command.
The specific instances in which
follows:
•

you

receive

such

requests

are

Volume not online -- The device is not ready with the proper
volume.
The request you receive states the date and time, a
request number, the user name, the volume name
(does not
appear if not specified in the MOUNT command), and the device
name, as shown in the following example:
%0PCOM, 6-JUN-1982 17:02:30.29, request 24, from user TOM
Please mount volume TOMVOL in device DMAO:
You can also receive a comment from the user.
To satisfy the
request, load the volume and ready the device, or redirect the
mount operation to another device.

•

Wrong volume -- The device contains the wrong volume.
The
request you receive states the date and time, a request
number, the user name, the volume name (does not appear if not
specified in the MOUNT command), and the device name, as shown
in the following example:
%0PCOM, 6-JUN-1982 17:02:30.29, message from user TOM
Device DMAO:
contains the wrong volume
%0PCOM,-6-JUN-1982 17:02:31.14, request 24, from user TOM
Please mount volume TOMVOL in device DMAO:
You can also receive a comment from the user.
To satisfy the
request, unload the current volume in the device, load the
proper volume, and ready the device, or redirect the mount
operation to another device.

•

In use -- The device is allocated by another user.
The
request and subsequent cancellation message you receive state
the date and time, a request number, the user name, and the
device name, as shown in the following example:
%0PCOM, 6-JUN-1982 17:02:30.17, request 24, from user TOM
%0PCOM, device DMAO:
is not available for mounting.
If the requested device does not appear to be in use, attempt
to
free
it by asking the user to whom it is allocated to
deallocate it or by stopping that user's process, then load
and ready the device per the request. You can also redirect
the mount operation to another device.

You need not respond to the user with the REPLY command in those
instances that you load and ready the requested device. The system

5-36

MAINTAINING PUBLIC FILES AND VOLUMES
detects the event and so informs the user.
In addition,
sends you a message, as shown in the following example:

the

system

%0PCOM, 6-JUN-1982 17:02:32.28, request 24 was satisfied
To redirect the mount operation to another device, load the user's
volume on the alternate device, ready the device, and issue a REPLY/TO
command stating as the text parameter the word SUBSTITUTE
(which you
can specify in uppercase or lowercase, and abbreviate down to one
character) followed by the name of the device.
In the following
example, a mount operation is redirected to DMAl:

$ R~PLY/T0=24 "SUBSTITUTE DMAl"
If the user cancels a request by typing CTRL/Y, you receive a
to that effect, as shown in the following example:

message

%0PCOM, 6-JUN-1982 17:02:32.28, request 24 was canceled

5.12.2

Requests from the Magnetic Tape File System

As a tape operator, you receive requests to switch volumes during
multivolume operations and to reload a volume in the event of a
hardware error on a tape drive. See Chapter 3 of the VAX/VMS Magnetic
Tape User's Guide for procedures on switching volumes.
On a hardware error, the request tells you the date and time, the user
name, the volume name and relative volume number, and the device name.
You should take one of the following actions:
•

REPLY/TO -- If you can fix the problem, load
(if necessary)
the volume, ready the device, and issue a REPLY/TO command.

•

REPLY/ABORT -- If you cannot fix the problem, you must
to the REPLY/ABORT command.

resort

Assume, for example, that you receive the following messages:
%0PCOM, 6-JUN-1982 17:02:30.58, message from user TOM
MFAO: of f l ine
%0PCOM, 6-JUN-1982 17:02:31.14, request 24 from user TOM
Remount relative volume 1 (TOMVOL) on MFAO:
You check the drive and find that it simply lost its vacuum.
Remedy
the situation by readying the tape drive and issuing the following
command:

$ REPLY/T0=24
6-JUN-1982 17:02:32.31, request 24 completed by operator OPAO

5.12.3

Requests from the Backup Utility

When the Backup Utility runs as a batch job, you receive requests to
load the next volume of a save set and to reload a volume in the event
of an error.
(These requests go to the user when the Backup Utility
is invoked interactively.)

MAINTAINING PUBLIC FILES AND VOLUMES
5.12.3.1 Writing to a Save Set - If a save operation
(writing from
files to a save set) requires the loading of an additional volume, you
receive messages stating the date and time, a request number, the user
name, and the device name, as shown in the following example:
%0PCOM, 6-JUN-1982 17:02:32.31, request 24, from user TOM
%BACKUP-I-READYWRITE, mount volume 2 on MTAO:
for writing
To continue the back-up operation, load a scratch volume, ready the
device, and type a REPLY/TO command, as shown in the following
example:

$ REPLY/T0=24
6-JUN-1982 17:02:34.14, request 24 completed by operator OPAO
You can also abort the back-up operation by
command, as shown in the following example:

typing

REPLY/ABORT

$ REPLY/ABORT=24
6-JUN-1982 17:02:34.14, request 24 aborted by operator OPAO

5.12.3.2 Reading from a Save Set - If a restore operation (reading
from a save set to files)
requires the loading of an additional
volume, you receive messages stating the date and time, a request
number, the user name, and the device name, as shown in the following
example:
%0PCOM, 6-JUN-1982 17:02:32.31, request 24, from user TOM
%BACKUP-I-READYREAD, mount volume 2 on MTAO:
for reading
To continue the restore operation, place the next volume of the save
set on the drive, ready the device, and type a REPLY/~O command, as
shown in the following example:

$ REPLY/T0=24
6-JUN-1982 17:02:34.14, request 24 completed by operator OPAO
You can also abort the restore operation by
command, as shown in the following example:

typing

REPLY/ABORT

$ REPLY/ABORT=24
6-JUN-1982 17:02:34.14, request 24 aborted by operator OPAO

5.12.3.3 Recovering from an Error - On certain errors, you receive
messages stating the date and time, a request number, the user name,
the device name, and reply options. On read errors from the save set,
the options are usually CONTINUE and QUIT.
On write errors to the
save set, the options are- usually RESTART and QUIT. You should take
one of the following actions:
•

REPLY/TO "CONTINUE" -- If you can fix the problem and are
given the CONTINUE option, ready the device, and issue a
REPLY/TO command specifying the word CONTINUE as text.

•

REPLY/TO "RESTART" ~- If you can fix the problem and are given
the RESTART option, load (if necessary) the volume, ready the
device, and issue a REPLY/TO command specifying the word
RESTART as text~

MAINTAINING PUBLIC FILES AND VOLUMES
•

REPLY/TO "QUIT" -- If you cannot fix the problem,
REPLY/TO command specifying the word QUIT as text.

issue

The text in the REPLY/TO command can be uppercase or lowercase, and
can be abbreviated down to the first character. See the VAX-11
Utilities Reference Manual for additional information on errors and
recovery procedures.
Assume, for example, that you receive the following messages during
restore operation (the save set is being read):

%0PCOM, 6-JUN-1982 17:02:30.58, message from user RESJOB
%BACKUP-E-FATALERR, fatal error on MT: []SAVE.;
%0PCOM, 6-JUN-1982 17:02:30.89, message from user RESJOB
-SYSTEM-F-MEDOFL, medium is offline
%0PCOM, 6-JUN-1982 17:02:31.05, request 24, from user RESJOB
%BACKUP-I-SPECIFY, specify option (QUIT or CONTINUE)
You check the drive and find that it simply lost its vacuum.
Remedy
the situation by readying the tape drive and issuing the following
command:

$ REPLY/T0=24 "CONTINUE"
CONTINUE
6-JUN-1982 17:02:33.41, request 24 completed by operator OPAO
If you find the drive inoperable, you issue the QUIT reply:

$ REPLY/T0=24 "QUIT"
QUIT
6-JUN-1982 17:02:33.41, request 24 completed by operator OPAO
If the error occurs during a save operation (the save
written), you have a choice of QUIT or RESTART:

tape

being

%0PCOM, 6-JUN-1982 17:02:30.58, message from user RESJOB
%BACKUP-E-FATALERR, fatal error on MT: []SAVE.;
%0PCOM, 6-JUN-1982 17:02:30.89, message from user RESJOB
-SYSTEM-F-MEDOFL, medium is offline
%0PCOM, 6-JUN-1982 17:02:31.05, request 24, from user RESJOB
%BACKUP-I-SPECIFY, specify option (QUIT or RESTART)
<You ready the tape drive.>
$ REPLY/T0=24 "RESTART"
RESTART
6-JUN-1982 17:02:33.35, request 24 completed by operator OPAO
The RESTART option permits you to restart a multivolume back-up
operation at the beginning of the current volume.
If you specify the
QUIT option, you must restart the back-up operation completely.

5.12.4

Notification of Volume Mounts and Dismounts

If the system parameter MOUNTMSG has a value of 1, you receive a
message whenever a volume is mounted.
If the system parameter
DISMOUMSG has a value of 1, you receive a message whenever a volume is
dismounted.
These parameters have an initial value of O, so you must
set them with the AUTOGEN command procedure or the SYSGEN Utility.
An interval of up to 30 seconds can pass between the mount or dismount
occurring and the notification message being issued.

C'.

MAINTAINING PUBLIC FILES AND VOLUMES
The notification message contains the date and time, the name of the
volume, and the name of the device.
The user name in the message is
always SYSTEM
(the ERRFMT process actually issues the message).
Volume names are padded with blanks to 12 characters. The following
example shows a mount notification message:
%0PCOM, 6-JUN-1982 17:02:30.29, message from user SYSTEM
11
Volume 11 TOMTAPE
mounted, on physical device MTAO:
The next example shows a dismount notification message:
%0PCOM, 6-JUN-1982 17:02:30.29, message from user SYSTEM
11
Volume 11 TOMTAPE
dismounted, on physical device _MTAO:
The messages require no reply.

CHAPTER 6
INSTALLING IMAGES AS KNOWN IMAGES

You enhance the performance of selected executable and shareable
images by installing them as known images with the Install Utility
(INSTALL).
INSTALL is described in the VAX-11 Utilities Reference
Manual. Known images can be assigned the following attributes:

6.1

•

Permanently open -- Directory information on the image file
remains permanently resident, eliminating the usual directory
search required to locate a file.
The cost of keeping an
image file permanently open is a minimum of 192 bytes of
nonpaged dynamic memory.

•

Header resident -- The header of the image file (native images
only)
remains permanently resident, saving one disk I/O
operation per file access, at a cost of less than one page of
paged dynamic memory.
The image must also be declared
permanently open.

•

Privileged -- Amplified privileges are temporarily assigned to
any process running the image
(executable images only),
permitting the process
to
exceed
its
UAF
privilege
restrictions during execution of the image.
In this way,
"normal"
users
can
run
programs
that
require
higher-than-normal privileges.

•

Protected -- A shareable image contains protected code,
that
is, code that runs in kernel or executive mode but that can be
called by a user-level image.

•

Shared -- More than one user can access the read-only and
non-copy-on-reference
(non-CRF)
read/write sections of the
image concurrently, so that only one copy of those sections
ever need be in physical memory.
(CRF sections always require
a separate copy for each process.) The image must also be
declared permanently open.

•

Writeable -- When a shared non-CRF writeable section
is
removed from physical memory (for paging reasons or because no
processes are referencing it), it is written back to the image
file.
Any updates made by using processes, therefore, are
preserved (while the initial values are lost). The image must
also be declared shared.

EXECUTABLE AND SHAREABLE IMAGES

Many images installed as known images are executable images.
An
executable image is one linked with the /EXECUTABLE qualifier or
without the /SHAREABLE qualifier.

~-1

INSTALLING IMAGES AS KNOWN IMAGES
You can also install shareable images as known images.
A shareable
image is one linked with the /SHAREABLE qualifier. A shareable image
must subsequently be linked into an executable image to be used.
Do not confuse shareable images with known images installed
/SHARED qualifier:

with

the

•

Shareable images
A shareable image is not copied into the
executable images that link with it. Thus, only one copy of
the shareable image need be on disk, no matter how many
executable images have linked with it.

•

Shared images -- The shared attribute can be assigned to, or
withheld from,
any known image -- shareable or executable.
Its assignment results in the creation of permanent, system
global
sections.
Execution of non-CRF global sections
requires only one copy per section to be in physical memory,
no matter how many processes are running the image to which
the sections belong. Global sections are created for CRF
sections, but the sections are not shared in memory.

When an image is not installed; or is installed without the shared
attribute, each process running the image requires private sections in
memory.
(A shareable image linked to an executable image need not be
installed to be executed. At image execution time, the system will
create private sections from the shareable image. The only exception
is that a shareable image containing a writeable non-CRF section must
be installed as a known image with the shared and
writeable
attributes.)
The number of images that can be installed with the shared qualifier
is restricted by the GBLPAGES and GBLSECTIONS system parameters (see
Chapter 10).

6.2

KNOWN FILE LISTS

The system defines known images on internal data structures called
known file lists.
Each known file list contains entries for all
known images whose device, directory, and file type are identical.
For
example,
all
known
images
with
the
file
name
SYS$SYSDEVICE:[MAIN]file-name.EXE would be on one known file list,
while
all
known
images
with
the
file
name
SYS$SYSDEVICE:[TEST]file-name.EXE would be on another known file list.
The number of known file lists is restricted by the KFILSTCNT system
parameter
(see Chapter 10).
Once a known file list is created, it
remains associated with a specific device and directory.
If that
known file list becomes empty, it cannot be reused for a different
device and directory. Take care to anticipate the number of known
file lists required or else avoid using up all available list heads by
installing images as known files from the same device and directory
wherever possible.

6.3

OPERATIONAL CONSIDERATIONS

Certain operational considerations come into play
are installed and used.

when

known

images

INSTALLING IMAGES AS KNOWN IMAGES
6.3.1

Start-up Procedures

Known file lists only last while,the system is up.
If the system is
shut down or fails for any reason, all known images· must be
reinstalled after the system is booted. For this reason, the siteindependent
start-up
command
procedure, SYS$SYSTEM:STARTUP.COM,
includes an INSTALL run that installs certain system programs as known
images.
You are encouraged to include in the site-specific start-up
command procedure, SYS$MANAGER:SYSTARTUP.COM, an INSTALL run
to
install additional images that are run frequently, that are usually
run concurrently by several processes, or that require special
privileges.
(See Chapter 7 for information on the start-up command
procedures.)

6.3.2

Order of Installation

In local memory, installing less frequently used images first and more
frequently used images last
(on each known file list) enhances
run-time performance.
In MA780 multiport memory, installing the more
frequently used images first enhances run-time performance.

6.3.3

Privileges

VAX/VMS allows images to execute in an enhanced privilege environment
through two mechanisms.
You can install existing executable images
with extra privileges to allow a nonprivileged process to perform the
privileged functions of the image. Privileged shareable images are
used to implement user-written
system
services,
which
allow
nonprivileged images to execute select portions of privileged code,
without enhancing the privileges of each image that uses
the
privileged portion of code.

6.3.3.1 Privileged Executable Images - You install executable images
with
enhanced
privileges
through
use
of
the
/PRIVILEGED=(privilege-list) option to the Install Utility.
Once
executable images are installed with enhanced privileges, users should
also link them with the /NODEBUG and /NOTRACE qualifiers to further
maintain system integrity and system security.

6.3.3.2 Privileged Shareable Images - VAX/VMS supports user-written
system services through a mechanism called privileged shareable
images.
(See the VAX/VMS Real-Time User's Guide for a description of
how
to
create privileged shareable images.)
You must link a
privileged shareable image with the PROTECT=option or the /PROTECT
command qualifier, so that it acquires its particular form of enhanced
privileges:
part

privileged

•

Use the PROTECT=option when only
shareable image requires protection.

•

Use the /PROTECT command qualifier when all parts of an
require protection.

image

You then install the privileged shareable image with the Install
Utility, specifying both the /PROTECTED and /SHAREABLE qualifiers.
If
you fail to follow all these steps, you will prevent successful
activation of a privileged shareable image.

INSTALLING IMAGES AS KNOWN IMAGES
6.3.4

Deleting Known Images and Dismounting Volumes

System operations are affected by two characteristics of known images:
•

Deletion -- A known image is not deleted as soon as the
/DELETE qualifier is applied. The deletion occurs only after
all processes using the image have released it.

•

Dismounting -- A volume cannot be dismounted while
file lists associated with it contain entries.

any

known

To dismount a volume, then, you must not only delete all known images
associated with it, but you must wait for all processes using those
images to release them and for the system to write writeable images
back to their files. You can use the DCL command SHOW DEVICES/FILES
to determine the status of the files.

6.3.5

Shareable Image Files

At execution time, a shareable image must reside in the directory
SYS$SHARE
(which is normally equivalent to SYS$LIBRARY), or the file
name must be defined as the logical name of the file specification of
the shareable image.
For example,
if the file specification of a
shareable image is SYS$SYSDEVICE:[TEST]STATSHR.EXE, the user must
define the logical name STATSHR to the file specification before
running any executable image that calls STATSHR:
$ DEFINE STATSHR SYS$SYSDEVICE: [TEST]STATSHR

The file type defaults to EXE.
If the file specification for STATSHR
were SYS$SHARE:STATSHR.EXE, no DEFINE command would be necessary.
Likewise, one shareable image can be substituted for another without
requiring the calling executable image to relink. The user simply
defines the file name of the old shareable image as the logical name
of the file specification of the new shareable image. The following
statement defines the file name STATSHR as the logical name of the
shareable image SYS$SYSDEVICE:[MAIN]STATSHR.EXE for executable images
calling STATSHR:

$ DEFINE STATSHR SYS$SYSDEVICE: [MAIN]STATSHR
Again the file type defaults to EXE.
(Logical name redirection in the
process or group logical name table is ignored when you run a
privileged executable image.)
If the new image is installed with the /SHARED qualifier, executable
images linked against the old image will be mapped to global sections
for the new image. Otherwise, they will be mapped to private sections
for the new image.
As demonstrated in the example, the old and new images can have the
same name, but must reside in different directories. You should not
substitute one version of a file for another in the same directory.

INSTALLING IMAGES AS KNOWN IMAGES
6.3.6

MA780 Multiport Memory

To install a shared image so that the global sections will reside in a
multiport memory unit, you issue the DCL command DEFINE {an ASSIGN
command could also be used) in the format:
DEFINE GBL$file-name shmem-name:f ile-name
The following example ensures that any global sections created for an
image whose file name is STATSHR reside in the MA780 multiport memory
unit whose logical name is SHRMEMl:
$·DEFINE GBL$STATSHR SHRMEMl:STATSHR
$ RUN SYS$SYSTEM:INSTALL
INSTALL> STATSHR/OPEN/SHARED

6-5

CHAPTER 7
START-UP AND SHUTDOWN

This chapter describes procedures for restarting the system
(assuming
that a complete installation has been done) and three procedures for
shutting down the system.
Finally, the chapter describes how to set
up both the site-independent start-up command procedure and the
site-specific start-up command procedure.

7.1

RESTARTING THE OPERATING SYSTEM

Full details for installing the VAX/VMS operating system are provided
in the software installation guide for your VAX-11 processor. These
descriptions cover the steps necessary to start up your system
initially.
Restarting the system means loading the operating system
into memory and performing the necessary housekeeping functions for
the system to run properly.
Generally, when the system fails, it
automatically restarts itself. However, sometimes your assistance is
required to restart the system. This usually occurs after you have
halted the operating system by one of the methods described in Section
7.2.

7.1.1

The Start-up Command Procedure

When the operating system is bootstrapped, the command procedure
SYS$SYSTEM:STARTUP.COM
is
automatically
executed.
This
DIGITAL-supplied command procedure
contains
commands
for
the
site-independent operations that must be performed if the system is to
run properly. These operations include assigning system-wide logical
names,
installing executable images as known images, and creating
permanent global sections.
The
SYS$SYSTEM:STARTUP.COM
command
procedure
also
invokes a site-specific command procedure named
SYS$MANAGER:SYSTARTUP.COM
in
which
you
place
site-specific
initialization commands.
An empty file by this name is furnished in
the VAX/VMS distribution kit.
See Sections 7.3.1 and 7.3.2 for more
information on these command procedures.

7.1.2

Bootstrapping to Restart the System

The procedure to restart the VAX/VMS operating system after it has
been shut down and consequently needs to be bootstrapped varies from
processor to processor. For this reason, you should refer to the
software installation guide for your VAX-11 processor. To perform
this procedure, you must enter the commands from the system console.

7-1

START-UP AND SHUTDOWN
Normally you only boot the standard system (number 0).
However,
if
you have multiple systems on your system disk, you can specify that
you want to boot a particular copy of the system.
The procedure
requires that you load the system number (a hexadecimal value in the
range O through F) into bits 28 through 31 of register 5 at boot time.
(The technique for
loading a number into register 5 is described in
the software installation guide for your VAX-11 processor.)

7.1.3

Boostrapping the System with an Alternate STARTUP Command File

If you need to bootstrap your system and want to avoid autoconfiguring
all devices or invoking SYS$MANAGER:SYSTARTUP.COM, you should boot
following the standard procedure for your VAX-11 processor, but you
should stop in SYSBOOT (see the software installation guide for your
VAX-11 processor).
Then issue the following command:
SYSBOOT>SET /STARTUP SYS$SYSTEM:STARTUP.MIN
Note that the start-up file
directory, such as SYS$SYSTEM.

7.1.4

must

have

explicit

device

and

Restarting Problems

Sometimes the operating system does not bootstrap after you have
issued the BOOT command.
This can be caused by either a hardware or
software malfunction.

7.1.4.1 Hardware Problems - A read error on a disk drive or console
medium, or a machine check error may indicate a hardware malfunction.
Whenever a hardware problem occurs,
a question mark
(?) character
usually precedes the error message that is displayed on the system
console terminal. When a hardware problem occurs, you should:
•

Consult the
processor

appropriate

hardware

manual

for

your

VAX-11

•

Contact the appropriate DIGITAL field service representative

7.1.4.2 Software Problems - When the operating system is loaded
into
memory,
but the STARTUP.COM command procedure
is not executed, a
software malfunction has probably occurred.
You would probably
suspect this if the usual message specifying the number of interactive
users does not appear.
You can perform one or more of the following actions
situation:

correct

the

•

Try again, by repeating the bootstrapping procedure to restart
(see
the
software
installation guide for your VAX-11
processor)

•

Place the system disk in another drive or try a different copy
of the disk
in the same drive and repeat the restarting
procedure as above

7-2

START-UP AND SHUTDOWN
7.2

SHUTTING DOWN THE OPERATING SYSTEM

There are three procedures you can use to shut down the system:
•

An orderly shutdown of the system

•

Two emergency shutdowns of the system

The first procedure is a command procedure that is distributed with
the
VAX/VMS
software.
This
command
procedure
is
named
SYS$SYSTEM:SHUTDOWN.COM.
Once invoked, SHUTDOWN.COM automatically
performs specific housekeeping functions that ensure a smooth shutdown
of the system. These housekeeping functions include disabling future
logins, stopping the batch and de~ice queues, dismounting mounted
volumes, and stopping user processes. This procedure also
invokes a
site-specific command procedure named SYS$MANAGER:SYSHUTDWN.COM that
you tailor to the needs of your specific
installation.
The
SYSHUTDWN.COM file
is present in the VAX/VMS distribution kit but
contains no commands.
If the operating system cannot be shut down by means of the
SHUTDOWN.COM
command procedure, you should invoke an emergency
shutdown program with the following command:
$ RUN SYS$SYSTEM:OPCCRASH
This program shuts down the system immediately. The error log buffers
are written to the system dump file.
Pages on the modified list are
written to disk. Then the system disk is dismounted.
Data may be
lost, since the OPCCRASH program performs only minimal housekeeping
functions.
Therefore, you should only invoke an emergency shutdown of
the system if the orderly shutdown procedure fails.
There is another program you can use for an emergency shutdown of the
system if OPCCRASH cannot shut down the system. On the VAX-11/780,
VAX-11/782, and VAX-11/730 processors, this procedure is supplied as a
console command program named CRASH that is stored on the system
console medium.
(See Section 7.2.3, which also describes
the
individual instructions you need to enter to obtain equivalent results
on a VAX-11/7 50.)

7.2.1

Orderly Shutdown of the System (With SHUTDOWN.COM)

The procedure below describes how to shut down the system in an
orderly fashion.
This procedure is contained in a command file that
you should not modify. At your discretion commands can be added to
the SYS$MANAGER:SYSHUTDWN.COM command procedure to perform additional
housekeeping functions.
You must have either the SETPRV privilege or
all the following privileges to run SHUTDOWN.COM: CMKRNL, SYSNAM,
OPER, WORLD, SYSPRV, and EXQUOTA.
(If you have the SETPRV privilege,
the procedure will automatically assign the required privileges to
you.)
Procedure
1.

Issue the following command from any terminal and any account
to begin the shutdown procedure:
$ @SYS$SYSTEM:SHUTDOWN

7-3

START-UP AND SHUTDOWN

Enter an integer in response to the
unless you want an immediate shutdown:

following

question,

How many minutes until shutdown [O]?
3.

In response to the following
shutting down the system:

prompt,

give

the

reason

for

Reason?
4.

Respond by typing a Y
question:

(Yes)

(No)

the

following

Do you want to spin down the disks [No]?
5.

Respond to the next question with a time in the format you
want printed in the message that will be broadcast to the
users. For example, you could specify IMMEDIATELY, or IN 10
MINUTES, or a time such as 2 P.M. or 2:00.
If you do not
know when the system will be available again, press RETURN.
Expected uptime (<RET> if not known)?

Respond to the next question depending on whether or not you
want the system to automatically reboot. By default, the
system does not automatically reboot.
However,
if you
respond with Y (Yes), the logical name OPC$REBOOT is defined
as true. As a result, when the shutdown is complete, an
attempt is made to automatically reboot the system. Note
that the system can only be automatically rebooted if the
appropriate hardware switch is also set on the processor and
the default boot command file is properly set.
(See the
software installation guide for your VAX-11 processor.)
The following events occur as the
shutdown
procedure
continues, and the corresponding messages are printed on the
terminal:
a.

A message that requests users to log out is broadcast to
all users on the system. This message is broadcast at
decreasing time intervals.

Batch and device queues are stopped and all future
nonoperator logins are disabled when there are four or
fewer minutes left until system shutdown.

Next,
the
site-specific
command
procedure
SYS$MANAGER:SYSHUTDWN.COM
is
invoked.
This command
procedure contains commands inserted to tailor
the
shutdown procedure to the needs of the installation.

All user processes are stopped. However, the following
processes continue:
NULL, SWAPPER, JOB CONTROL, OPCOM,
ERRFMT, ancillary control
processes -(ACPs),
print
symbionts, and the process running the SHUTDOWN.COM
command procedure. ACPs may delete themselves when their
mounted volumes are finally dismounted.

All mounted volumes are dismounted and,
if you request
it, the disks are spun down. Note, however, the system
disk cannot be spun down.

The operator's log file is closed.

The program
the system.

SYS$SYS~EM:OPCCRASH

7-4

is invoked to

shut

down

START-UP AND SHUTDOWN

If you did not request an automatic reboot,
message appears on the system console:

the

following

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
Otherwise, the system automatically reboots, provided the
switches on the CPU cabinet and the boot command file are
correctly set.
8.

If you are not automatically rebooting, you must press CTRL/P
after the above message is printed at the console terminal.
Then follow the standard procedure given in the software
installation guide for your VAX-11 processor to halt the
system.

Example
$ @SYS$SYSTEM:SHUTDOWN
System shutdown command procedure.
How many minutes until shutdown [OJ? 5
Reason? MONTHLY PREVENTIVE MAINTENANCE
Do you want to spin down the disks [No]? YES
Expected uptime (<RET> if not known)? 1:25
Enable automatic reboot [No]? (BD)
%0PCOM, 17-JUN-1982 11:12:20:32, operator status for operator OPAO
CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS, NETWORK, OPERl, OPER2,
OPER3, OPER4, OPER5, OPER6, OPER7, OPER8, OPER9, OPERlO, OPERll,
OPER12
OPAO:,SYSTEM
11:12:20.72
System shutdown in 5 minutes; up 1:25
MONTHLY PREVENTIVE MAINTENANCE
OPAO:,SYSTEM
11:12:22.73
MONTHLY PREVENTIVE MAINTENANCE
Login quotas - Interactive limit=O, Current interactive value=32
Non-operator logins are disabled.
%JBC-E-SYMBDSAB, symbiont manager is disabled
OPAO:,SYSTEM
11:14:27.30
Batch and device queues have been stopped.
OPAO:, SYSTEM
ll:l4:29.86
System shutdown in 2 minutes; up 1:25.
MONTHLY PREVENTIVE MAINTENANCE

Logins are disabled; please log out.

OPAO:,SYSTEM
ll: 15: 32. 62
System shutdown in 1 minute; up 1:25.
MONTHLY PREVENTIVE MAINTENANCE

Logins are disabled; please log out.

OPAO:, SYSTEM
ll:l6:35.39
System shutdown in 0 minutes; up 1:25.
MONTHLY PREVENTIVE MAINTENANCE

Logins are disabled; please log out.

Invoke installation dependent shutdown procedure.

Stop all user processes.
Remove installed images.
Dismount all mounted volumes.
%0PCOM, 17-JUN-1982 11:16:43.62, message from user SYSTEM
~OPAO:, Operator requested shutdown

START-UP AND SHUTDOWN
%0PCOM, 17-JUN-1982 11:16:45.02, logfile closed by operator OPAO
logfile was SYS$MANAGER:OPERATOR.LOG
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

In this example, the operator requests that the system be shut down in
five minutes to allow monthly preventive maintenance. The operator
then indicates that the disks should be spun down, that the system is
expected to be available again at 1:25, and that automatic rebooting
is not desired. The system then performs housekeeping functions that
ensure a clean shutdown. When housekeeping operations are complete, a
system message indicates ,that the site-dependent shutdown procedure
will
be
invoked.
When the site-dependent shutdown procedure
completes, SHUTDOWN.COM stops all user processes, dismounts all
mounted volumes, and spins down the disks {except the system disk).
It closes the operator's log file, then invokes OPCCRASH to shut down
the system. The operator must press CTRL/P and the halting command to
complete the system shutdown procedure.

7.2.2

Emergency Shutdown of the System {with OPCCRASH)

The procedure below describes chow to halt the system immediately
without performing any of the housekeeping functions that ensure a
smooth shutdown. Generally, you shut down the system by following the
orderly shutdown procedure described in Section 7.2.1. However, if
that procedure fails, you can perform the emergency shutdown procedure
described in this section.
To perform this procedure, you must possess the CMKRNL privilege.
can enter the commands from any terminal and any account.

You

Procedure
1.

Enter the following command to force an immediate shutdown of
the system:

$ RUN SYS$SYSTEM:OPCCRASH
2.

If the system fails to accept or to respond
issued in Step 1, use the appropriate
procedure for your VAX-11 processor from
described in Section 7.2.3.

Observe the following message typed on the system console:

to the command
alternate crash
those that are

SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
4.

Press CTRL/P after the above message is printed at the
console terminal.' Then, follow the standard procedure given
in the software installation guide for your VAX-11 processor
to halt the system.

Example for a VAX-11/780
1.

$ RUN SYS$SYSTEM:OPCCRASH
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
(CTRL/P)

>»HALT
HALTED AT 8000708A

7-6

START-UP AND SHUTDOWN
The VAX-11/780 operator types the command string for an
emergency shutdown.
The system then instructs the operator
to use the console to halt the system. The operator presses
CTRL/P to return the console terminal to the control of the
console subsystem. The console subsystem responds with the
console command language prompt
(>>>). The operator then
issues the HALT or H command to halt the system.

7.2.3

Forcing the System to Fail (with CRASH or its Equivalent)

The CRASH console program command file described below
forces
VAX-11/780, VAX-11/782, and VAX-11/730 systems to fail, which results
in an immediate shutdown of the system.
After the CRASH console
program command file is invoked, a fatal bugcheck message is printed
at the console terminal and the system dump file
is written to the
disk.
Later, the dump file can be used to determine why the system
did not respond to command input. However, data may be lost, since no
other housekeeping functions are performed. Therefore, you should
only use CRASH if the system will not accept command input; that is,
if the system fails to accept or respond to OPCCRASH when you follow
the instructions in Section 7.2.2.
The console program command file CRASH is not included in the VAX/VMS
distribution kit for a VAX-11/750 system.
If it becomes necessary to
perform an emergency crash of a VAX-11/750 system, you can enter - the
equivalent instructions manually, as described in the second procedure
below.
Note that, if a copy of the system dump file is sent to DIGITAL later
for analysis, a copy of the console listing should also be sent. This
listing displays fatal bugcheck information that is not contained in
the system dump file (for example, program counter (PC) and processor
status longword (PSL) data) •
All commands that invoke the CRASH console program command
be typed from the system console terminal.

file

must

Procedure for VAX-11/780, VAX-11/782, and VAX-11/730 Systems
1.

Press CTRL/P to
language level.

return

control

The VAX-11/780 or VAX-11/782 system responds by printing the
console command language prompt (>>>). The VAX-11/730 system
responds by printing a halt code and then the console command
language prompt (>>>).

After the prompt, type HALT.
command language prompt.

You

the

receive

console

command

another

console

The console command @CRASH invokes the CRASH console
command file.

program

After the prompt, type @CRASH as follows:
>»@CRASH
4.

Additional messages and information, such as the fatal
bugcheck message, are printed at the console terminal, as
shown in the example below. The system dump file is written
to the disk.

START-UP AND SHUTDOWN
Example for a VAX-11/780 System
(CTRL/P)

>»HALT
>»@CRASH

Command file to crash VMS abnormally

HALT

! HALT SYSTEM, EXAMINE PC,

HALTED AT 8000702A
EXAMINE PSL
PSL,
00000000
EXAMINE/INTERN/NEXT: .4 0
I
00000000
I
00000001
I
00000002
I
00000003
I
00000004
DEPOSIT PC=-1
DEPOSIT PSL=lFOOOO

And all stack pointers
80001048
00000000
00000000
00000000
8009E600
Invalidate PC
! Kernel mode, IPL 31

CONTINUE
<@EOF>
<@EXIT>

**** FATAL BUG CHECK, VERSION
ASTDEL or on interrupt stack
CURRENT PROCESS

3.0 INVEXCEPTN, Exception while above

NULL

REGISTER DUMP
RO
OOOOOOlF
Rl
OOlFOOOO
R2
00000000
R3
00000000
R4
00000000
RS
00000000
R6
00000000
R7
00000000
RS
00000000
R9
00000000
RlO= 00000000
Rll= 00000000
AP
00000000
FP = 00000000
SP = 80001014
PC = 800038Cl
PSL= 001F0009

7-8

START-UP AND SHUTDOWN
KERNEL/INTERRUPT STACK
80001DlC
80001020
80001024
80001D28

00000004
00000000
FFFFFFFD
00000000

HALT INST EXECUTED
HALTED AT 80007183
>»
Typing @CRASH invokes the CRASH console program command file on the
VAX-11/780 system. This procedure instructs the system to examine the
program counter (PC), the processor status longword
(PSL), and the
stack pointers.
Values are deposited in the PC and PSL to cause an
exception condition that forces a system. dump.
The fatal bugcheck
message is printed at the console terminal. Finally, the system halts
and prints the contents of the program counter.
The console system
prompt (>>>) returns.
If enabled, some systems will halt and then automatically rebootstrap.
However, you must rebootstrap systems that are not enabled to
automatically rebootstrap.
In some cases, on VAX-11/782 attached processor systems only, there
may be a delay of up to two minutes before the system responds to the
@CRASH command.
Procedure for VAX-11/750 Systems
On the VAX-11/750 you must type in the
console terminal to crash the system:

following

commands

the

(CTRL/P)

80007806 02
>»E/G F
G
OOOOOOOF
>»E p
00000000
>»E/I 0
I
00000000
>»E/I 1
I
00000001
>»E/I 2
I
00000002
»>E/I 3
I
00000003
»>E/I 4
I
00000004
>>>D/G F FFFFFFFF
>»D P lFOOOO
»>C

800078 06

800009DO
00000000
00000000
00000000
8013COOO

**** FATAL BUG CHECK, VERSION
ASTDEL or on interrrupt stack
CURRENT PROCESS

= NULL

7-9

3. 0 INVEXCEPTN, Exception while above

START-UP AND SHUTDOWN
The commands instruct the system to examine the program counter
(PC) ,
the processor status longword (PSL), and the stack pointers. Values
are deposited in the PC and PSL to cause an exception condition that
forces a system dump. The fatal bugche~k message is printed at the
console terminal. Additional messages and information, such as the
register dump, are printed at the VAX-11/750 console terminal, as
shown in the previous example for the VAX-11/780.
The system dump
file is written to the disk. Finally, the system halts and prints the
contents of the program counter.
The console system prompt
(>>>)
returns.
If enabled, some systems will halt and then automatically rebootstrap.
However, you must rebootstrap systems that are not enabled to
automatically rebootstrap.

7.3

START-UP COMMAND PROCEDURES

The software
procedures:

distribution

kit

contains

two

start-up

command

•

SYS$SYSTEM:STARTUP.COM -- Commands that, in general, must be
executed at initialization time for any VAX/VMS system to run
properly

•

SYS$MANAGER:SYSTARTUP.COM
STARTUP.COM,
that
you
initialization comm~nds

An
can

empty
load

file,
with

called
by
site-specific

Although you can tailor the site-independent command
procedure
(STARTUP.COM)
and the site-specific command procedure {SYSTARTUP.COM)
with any text editor~ DIGITAL discourages you
from
modifying
STARTUP.COM.
You should generally put site-specific commands in
SYSTARTUP.COM rather than modifying STARTUP.COM, because a new version
of the STARTUP.COM command file is provided with each major release of
VAX/VMS. Furthermore, SYS$SYSTEM:STARTUP.COM is subject to change in
VAX/VMS maintenance updates.

7.3.1

Site-independent Start-up Command Procedure

STARTUP.COM is automatically executed immediately after the operating
system has been booted. The command procedure includes commands for
performing housekeeping chores, assigning system-wide logical names/
starting up the three processes that control error logging, the job
controller, and the operator's log, installing known images, building
the I/O data base and loading the I/O drivers, enabling VAX-11 RMS
file sharing, calling the site-specific start-up command procedure,
and logging out.

7.3.1.1 Housekeeping Chores - The first two commands in STARTUP.COM
ensure that execution of ·the command procedure occurs without the
commands being echoed on the terminal and without interruption on an
error condition:
$ VERIFY = 'F$VERIFY{O)
$ SET NOON

7-10

START-UP AND SHUTDOWN
The next sequence of commands determines the default directory for the
location of the system executable images, ending with the following
command:
$ SET DEFAULT SYS$SYSTEM

7.3.1.2 Symbolic Debugger - The VAX-11 Symbolic Debugger requires the
following logical name assignments:
$ ASSIGN/SYSTEM SYS$INPUT: DBG$INPUT:
$ ASSIGN/SYSTEM SYS$0UTPUT: DBG$0UTPUT:

7.3.1.3 RSX-llM Programs - RSX-llM compatibility mode programs
(such
as BAD, SOS, and PIP) require the following logical name assignments:
$ ASSIGN/SYSTEM 'ROOT' LB:
$ ASSIGN/SYSTEM 'ROOT' LBO:
$ ASSIGN/SYSTEM SYS$SCRATCH WK:
$ ASSIGN/SYSTEM SYS$SCRATCH WKO:
$ ASSIGN/SYSTEM 'DISK' SP:
$ ASSIGN/SYSTEM 'DISK' SPO:
The definitions of the DCL symbols ROOT and DISK depend on the system
number being booted and the boot device. For example, if you boot the
default system from device DBAO, then ROOT is ~DBAO: [SYSO.] and DISK
is DBAO:.

7.3.1.4 System Libraries and Help Files - The language
processors,
the VAX-11 Linker, the image activator, and the help processor require
the following logical name assignments:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSEXE] SYS$SYSTEM:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSMSG] SYS$MESSAGE:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSLIB] SYS$SHARE:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSLIB] SYS$LIBRARY:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSHLP] SYS$HELP:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSHLP.EXAMPLES] SYS$EXAMPLES:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSMGR] SYS$MANAGER:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSUPD] SYS$UPDATE:
$ASSIGN /SYSTEM SYS$SYSROOT:[SYSTEST] SYS$TEST:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSMAINT] SYS$MAINTENANCE:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSERR] SYS$ERRORLOG:
$ ASSIGN /SYSTEM SYS$SYSROOT: [SYSCBI] SYS$INSTRUCTION:

7.3.1.5 Error Logging, Job Controller, and Operator's Log - The next
sequence of commands in STARTUP.COM starts up the error logger, the
job controller and the operator's log.

7.3.1.6 Known Images - STARTUP.COM installs certain system executable
images that are run frequently, that are usually run concurrently by
several processes, or that require special privileges using the
command procedure SYS$MANAGER:VMSIMAGES.COM.

7-11

START-UP AND SHUTDOWN
7.3.1.7 I/O Devices and Drivers - STARTUP.COM automatically connects
devices physically attached to the system and loads their I/O drivers:
$ RUN SYS$SYSTEM:SYSGEN
AUTOCONFIGURE ALL

7.3.1.8 VAX-11 RMS File Sharing - STARTUP.COM enables VAX-11 RMS file
sharing with a maximum page count of 20:
$ RUN SYS$SYSTEM:RMSSHARE
20

7.3.1.9 Install Deferred Swapping File if Present - For
VAX-11/730
processors with RL02 system disks,
installation of the primary
swapping file is deferred until after the ERRFMT, JOB CONTROL,
and
OPCOM processes have been initiated. The STARTUP.COM procedure checks
for the presence of the deferred swapping file, which is named
SYS$SYSTEM:SWAPFILE1.SYS, and if it is present, STARTUP.COM installs
it at this time with the SYSGEN command:
$ RUN SYS$SYSTEM:SYSGEN
INSTALL SYS$SYSTEM:SWAPFILE1.SYS /SWAPFILE

7.3.1.10 Termination of the Procedure - SYS$SYSTEM:STARTUP.COM calls
the site-specific start-up command procedure, sets the number of users
who can log in at one time, and logs the site-independent command
procedure off:
$ @SYS$MANAGER:SYSTARTUP
$ SET LOGIN /INTERACTIVE=64
$ LOGOUT/BRIEF

7.3.2

Site-specific Start-up Command Procedure

SYS$MANAGER:SYSTARTUP.COM, called from STARTUP.COM, performs
any
commands you want to place there. Typically, these commands mount
public disks,
assign logical names, set the characteristics of
terminals and other devices, establish and start queues, install known
images, run the System Dump Analyzer, purge the operator's log file,
submit batch jobs that are run at the time the system is initialized
and that are periodically resubmitted, manually connect devices and
multiport memory units, install secondary paging and swapping files,
and announce that the system is up and running.
NOTE
The commands shown in the following
sections are provided as models; do not
copy them line for line.

7.3.2.l Disable Error Processing - You can disable
with the following command:
$ SET NOON

7-1?

error

processing

START-UP AND SHUTDOWN
7.3.2.2 Public Disks - You will probably want to include
mount
commands to mount your public disks for system-wide access.
It is
worth considering some of the advantages of using logical volume names
to conceal the physical devices.
When you mount a disk, MOUNT
produces a special logical name called a logical volume name that you
can use to reference the volume. When you dismount the volume, the
logical name is deleted. For example:
$ MOUNT/SYSTEM

DRAl:

USERFILES

USER

This command produces the logical volume name USER and equates it to
the
concealed device name string
DRAl:.
However, USER only
translates to a physical device while~the data disk is actually
mounted.
If you mount a disk and do not give an explicit logical volume name,
MOUNT assigns a default name of the form:
DISK$volume label.
In the
example above, if no logical volume name were specified~ the default
logical volume name would have been DISK$USERFILES. Since the logical
volume name is printed on the flag page of listings and by the DCL
commands SHOW DEVICE/FILES and SHOW MEMORY/FILES, you may occasionally
see such labels.
If you and the users consistently use the logical volume name, it is
not necessary to know what physical drive the volume is mounted on.
Thus, you can avoid including physical device names in programs and
command procedures.
Note that when you run SYSTARTUP.COM (and only then), the default on
the MOUNT command is /NOASSIST.
This means that operator-assisted
mounts are disabled.
If you want to enable this feature during
SYSTARTUP, you must specify /ASSIST with each MOUNT command. See
Chapter 5 for more information on mounting public disks.

7.3.2.3 Logical Names - You can assign system-wide logical names in
addition to the logical names assi9ned in the site-independent
start-up command procedure:
$ ASSIGN/SYSTEM SYS$SYSROOT:

SYSDSK

See the chapter, File Specifications and Logical Names, in the VAX/VMS
Command Language User's Guide for more detailed information on logical
name assignments.

7.3.2.4 Optional Software Logical Name Requirements - You may need to
add logical name assignments for other components (such as VAX-11
BLISS-32 and VAX-11 BASIC).
The logical name assignments for FOROOS, FOR$ACCEPT, and FOR$READ to
SYS$INPUT, and FOR006, FOR$PRINT, and FOR$TYPE to SYS$0UTPUT are
embedded in VAX-11 FORTRAN, and need not be stated explicitly.
If you run VAX-11 COBOL-74 Version 4.3 or earlier programs
site, you will need the following logical name assignments:
$ ASSIGN/SYSTEM SYS$INPUT:
$ ASSIGN/SYSTEM SYS$0UTPUT:
$ ASSIGN/SYSTEM SYS$ERROR:
$ ASSIGN/SYSTEM SYS$INPUT:
$ ASSIGN/SYSTEM SYS$INPUT:
$ ASSIGN/SYSTEM SYS$0UTPUT:
$ ASSIGN/SYSTEM SYS$0UTPUT:

COB$INPUT
COB$0UTPUT
COB$CONSOLE
COB$CARDREADER
COB$PAPERTAPEREADER
COB $LINE PRINTER
COB$PAPERTAPEPUNCH
7-1~

your

START-UP AND SHUTDOWN
VAX-11 PASCAL programs require the following logical name assignments:
$ ASSIGN/SYSTEM SYS$INPUT:
PAS$INPUT
$ ASSIGN/SYSTEM SYS$0UTPUT:
PAS$0UTPUT

7.3.2.5 Device Characteristics - You use a series of SET commands to
establish the characteristics of the terminals and other devices on
the system, as in the example below. You may want to include comments
that give the user names for terminal owners.
$ SET TERMINAL TTC2:
$ SET TERMINAL TTDl:
$ SET TERMINAL TTD4:
$ SET TERMINAL TTG4:
$ SET PRINTER LPAO:
$ SET DEVICE
LPAO:

/SPEED=300/DEVICE TYPE=LA36/PERMANENT
/SPEED=9600/PERMANENT
/SPEED=l200/PERMANENT
/SPEED=l200/MODEM/PERMANENT
/LOWER/NOCR
/SPOOLED

!JONES
!WRENS
!JRSMITH
!DIALUPl

Note that the /SPEED qualifier sets both transmission and reception
speeds to the same value. The /MODEM qualifier defines a terminal for
use on a dial-in line. Printer characteristics (SET PRINTER and SET
DEVICE above)
must be set prior to establishing queues for the
printers.

7.3.2.6 Queues - The first time the system is booted, batch and print
queues must be initialized and started.
Whenever the system is
rebooted, the queues must merely be started. The following commands
provide for both contingencies by testing $STATUS:
START/QUEUE LPAO
IF $STATUS THEN GOTO ENDLPAO
INITIALIZE/QUEUE /FLAG LPAO
START/QUEUE LPAO
START/QUEUE LPBO
IF $STATUS THEN GOTO ENDLPBO
INITIALIZE/QUEUE /FLAG LPBO
START/QUEUE LPBO

$
$
$
$
$ ENDLPAO:
$
$
$
$ ENDLPBO:

See Chapter 8
queues.

for

information

initializing

and

starting

7.3.2.7 Known Images - You often install user and system programs (in
addition to the ones installed in the site-independent start-up
command procedure) so that they can be located quickly, shared, or
provided privileges:
$ RUN SYS$SYSTEM:INSTALL
BLISS32 /OPEN/SHARED/HEADER RESIDENT
COPY /OPEN
LINK /OPEN
MACR032 /OPEN/SHARED
DIRECTORY /OPEN
The most frequently used images should be installed last
memory,
but first in shared memory.
See Chapter 6
information on installing images as known images.

7-1.i\

in local
for more

START-UP AND SHUTDOWN
7.3.2.8 System Dump Analyzer - Each time the system is booted, you
should run the System Dump Analyzer (in case the system failed the
last time it was running):
$ ANALYZE/CRASH DUMP SYS$SYSTEM:SYSDUMP.DMP
COPY SYS$ERRORLOG:SYSDUMP.DMP
SET OUTPUT LPAO:SYSDUMP.LIS
SHOW CRASH
SHOW STACK/ALL
SHOW SUMMARY
SHOW PROCESS /PCB /PHD /REGISTERS
EXIT
If further information is required, you can invoke the System
Analyzer for an interactive session upon completion of start-up.
the VAX/VMS System Dump Analyzer Reference Manual.)

Dump
(See

7.3.2.9 Operator's Log File - Chapter 9 offers some suggestions for
maintaining the operator's log file.
If you decide not to put them
into practice, you might instead add the following command to purge
all but the last two or three versions of the operator's log file:
$ PURGE/KEEP=2 SYS$MANAGER:OPERATOR.LOG

7.3.2.10 Standard Batch Jobs - Some sites may have batch jobs that
are submitted at system start-up time and that resubmit themselves to
run at intervals as long as the system is running.
For such jobs, the
DCL command SUBMIT is used in the start-up file:
$ SUBMIT SYS$MANAGER:LOGJOBS

7.3.2.11 M'anually Connected Devices and Multiport Memory Units - You
run the SYSGEN Utility to connect devices not automatically connected
in STARTUP.COM and to initialize or connect multiport memory units:
$ RUN SYS$SYSTEM:SYSGEN
SHARE MPMl SHR_MEM_l /INITIALIZE
For installations that require perm~nent residence of the console
block storage device, you must explicitly connect the device by
including the following command when you run the SYSGEN Utility:
$ RUN SYS$SYSTEM:SYSGEN
CONNECT CONSOLE
See Chapter 11 and the VAX-11 Utilities
detailed discussion of the SYSGEN Ut1l1ty.

Reference

Manual

for

The console block storage device should also be mounted with a command
of the form:
$ MOUNT/FOREIGN/SYSTEM/PROTECTION=(SYSTEM:RWLP) CSAl:

CONSOLE

Failure to mount the console block storage device with appropriate
protection permits users to mount and access it, because the device is
in RT-11 format and has no file protection.

7-1~

START-UP AND SHUTDOWN
7.3.2.12 VAX-11 RMS File Sharing - STARTUP.COM enables VAX-11
RMS
file sharing with a maximum page count of 20.
If you estimate a
larger maximum page count
(see the description of the RMS Share
Utility in the VAX-11 Utilities Reference Manual) you should run the
RMS Share Utility with your value:
$ RUN SYS$SYSTEM:RMSSHARE
Be sure that this new value does not exceed half
dynamic memory.

the

size

7.3.2.13 Secondary Paging and Swapping Files - You run
Utility to install secondary paging and swapping files:

the

paged

SYS GEN

$ RUN SYS$SYSTEM:SYSGEN
INSTALL DISK$SYS2: [SYSTEM]PAGEFILE2.SYS /PAGEFILE
INSTALL DISK$SYS2: [SYSTEM]SWAPFILE2.SYS /SWAPFILE

•
7.3.2.14 Announcements - The last command in SYSTARTUP.COM typically
announces to all terminals that the system is up and running:
$ REPLY /ALL/BELL "VAX/VMS System Initialized"
Before SYSTARTUP.COM exits you may want to provide site-specific
definitions
for
one or both of the following logical names:
SYS$ANNOUNCE and SYS$WELCOME.
These logical names are
checked
whenever a user logs in and provide special messages at that time.

7.3.2.14.1 SYS$ANNOUNCE - SYS$ANNOUNCE defines text to be printed
whenever a user begins to log in;
that is, the text is printed
immediat~ly after a successful dial in, CTRL/Y, or RETURN
is sensed.
The text may consist of up to 63 characters. For longer messages, you
can precede the name of a text-containing file with an at sign (@)
so
that the login command procedure prints the entire file as an
announcement.
For example, you could include a command of the following form in your
SYSTARTUP.COM file:
$ DEFINE/SYSTEM SYS$ANNOUNCE "HAVE A NICE DAY"
Or, you might prefer to print a file:
$ DEFINE/SYSTEM SYS$ANNOUNCE "@SYS$MANAGER:ANNOUNCE.TXT"
If you do not define SYS$ANNOUNCE, no announcement is printed.

7.3.2.14.2 SYS$WELCOME - SYS$WELCOME defines text to be
printed
whenever a user succeeds in logging in; that is, the text is printed
immediately after the correct password is entered.
The text may
consist of up to 63 characters. For longer messages, you can precede
the name of a text-containing file with an at sign
(@)
so that the
login command procedure prints the entire file as a welcoming
announcement.

7-16

START-UP AND SHUTDOWN
For example, you could include a command of the following form in your
SYSTARTUP.COM file:
$ DEFINE/SYSTEM SYS$WELCOME "WELCOME TO THE BEST VAX/VMS SITE IN THE USA"

Or, you might prefer to print a file:
$ DEFINE/SYSTEM SYS $WELCOME "@SYS $MANAGER: WELCOME. TXT"
If you do not specifically define SYS$WELCOME,
welcome message is printed:

the

standard

VAX/VMS

Welcome to VAX/VMS Version V3.0
Note that this message may end by specifying the DECnet-VAX node
if the logical name SYS$NODE is defined.

name

7.3.2.15 Redefining the Number of Interactive Users - If the number
of interactive users that your site permits to log on at one time
differs from 64, you should consider ending SYSTARTUP.COM with the
following commands:
$ SET LOGIN /INTERACTIVE=n
$ LOGOUT/BRIEF
You specify the appropriate number of users for n.
If you include the
LOGOUT command, there will be no return to STARTUP.COM. This is
necessary, since STARTUP.COM concludes with a SET LOGIN command that
would override the value you have just specified for n.

7-17

CHAPTER 8
BATCH AND PRINT JOBS

System performance can be greatly influenced by how you establish
spooled devices, create and control input and output queues, and
control batch and print jobs.
Typically, you are responsible for
performing the following six closely related functions:
- •

Establishing spooling of input and output -- The VAX/VMS
operating system supports input spooling of batch job files
from card readers and transparent spooling of output files for
line printers and terminals. Using DCL commands, you specify
which output devices are to be spooled. Section 8.1 describes
spooling and the use of DCL commands to establish spooled
devices.

•

Controlling batch
jobs -- Section
8.2
describes
batch
processing and the use of DCL commands to control batch jobs.

•

Controlling print jobs
Section 8.3 describes queuing output
to line printers and the use of DCL commands to control print
jobs.

•

Controlling print and batch queues through DCL commands
Section 8.4.

•

Controlling print and batch queues
Section 8. 5.

•

Using the card reader -- See Section 8.6.

through

See

procedures -- See

You need not learn all the inner workings of spooling and queuing.
However, you must have a working knowledge of how to establish spooled
devices and how to create and control queues in order to keep the
system running efficiently. To do so, you must first become familiar
with the DCL commands listed in Table 8-1. The use of these commands
is restricted to users who have operator privilege (OPER). The
VAX/VMS Command Language User's Guide fully describes these commands.
In addition, three other DCL commands play a role in
batch and print jobs:

the

control

SHOW QUEUE -- Displays information about a file
(or files)
• queued
for batch execution or for output. No privilege is
needed to use this command.
•

SET QUEUE -- Changes the attributes of a
queued for batch execution or for output.

file

(or

files)

Ordinarily, no privilege is needed to use this command to
affect your own files.
However, you need the OPER, GROUP, or
WORLD privilege to to use the command to modify queued
jobs
entered by a member of another group. You need the OPER or
ALTPRI privilege to increase the queue priority of a job.
0

BATCH AND PRINT JOBS
•

DELETE/ENTRY -- Deletes jobs from queues.
No privilege is needed to delete entries you have queued;
however, you need group privilege (GROUP) to delete a queued
job entered by another member of the same group and you need
world (WORLD) or operator privilege (OPER) to use this command
to delete a queued job entered by a member of another group.

These commands are described fully in
User's Guide.
Table 8-1:

the

VAX/VMS

Command

Language

DCL Commands Used in Regulating Spooling and Queuing

Command

Function

ASSIGN/MERGE

Removes jobs from queues
them in other queues

ASSIGN/QUEUE

Assigns queues to devices

DEASSIGN/QUEUE

Deassigns queues from devices

DELETE/QUEUE

Deletes queues

INITIALIZE/QUEUE

Creates queues

SET DEVICE/NOSPOOLED

Turns off
terminals

SET DEVICE/SPOOLED

Establishes
spooled
printers
or
terminals, and assigns queues to them

START/QUEUE

Starts queues

STOP/ABORT

Aborts printing
being printed

STOP/QUEUE

Stops queues

STOP/REQUEUE

Stops the printing of jobs currently
being printed and requeues them

8.1

spooling

and

places

printers

files

currently

SPOOLING

Spooling is the technique of using secondary storage to buffer data
passing between slow I/O devices
(such as line printers and card
readers) and physical memory. The slow devices, which can be either
the ultimate sources or the ultimate destinations of buffered I/O
data, are called spooled devices; the secondary storage devices are
called intermediate devices.
As a rule, programs demand input and produce output at irregular
intervals during their execution.
If programs were allowed to read
directly from slow devices and to write directly to slow devices, the
execute time of programs would be limited by the speed of the slow
devices.
If a process output data directly to a printer, the pro~ess
would be tied up for the time it took to print the listing. Also,
other processes needing the printer would have to wait.

BATCH AND PRINT JOBS
To balance these input/output demands and enhance throughput, you can
establish spooled devices;
to all other users, and their programs,
the mechanism of spooling is transparent.
Input spooling makes input from a spooled device
(such as a card
reader)
available for processing by placing it into a file on an
intermediate device
(such as a disk).
Input spooling is used
principally to create,
from card reader input, batch input files on
disk. After they are spooled to disk, batch jobs are queued for
processing according to their priority.
Output spooling makes output from the processor available
for
transmission to a spooled device (such as a line printer) by placing
it into files on an intermediate device
(such as a disk).
Output
spooling is used principally to create printer output files on disk.
After they are spooled to disk, print jobs are queued for printing
according to their priority.
The actual transfer of inputs from a spooled device to an intermediate
device or the transfer of outputs from an intermediate device to a
spooled device is carried out by processes called symbionts.
Input symbionts read input at the speed of the
input spooled device
and buffer it in a file on the intermediate device.
Later, when the
input is needed, it is read directly from the file on the intermediate
device rather than from the spooled device. While one set of input
data is being processed, the input symbiont is free to read another
set of input data into another file on the intermediate device.
Output symbionts read data from an intermediate device and write the
data to an output spooled device at the speed of that output device.
The data on the intermediate device is generated by programs that
produce outputs directly into files on the intermediate device.
The
I/O waiting time of programs is thus minimized. When an output file
is complete, it is queued for printing by an output symbiont. As with
input symbionts, there is an overlapping: while an output symbiont is
printing a file stored temporarily on an intermediate device, another
program can be producing another output file on the intermediate
device.

8.1.1

Establishing Spooled Devices

Card readers are spooled by default.
(To use a card reader without
spooling,
users must allocate the reader before making it ready to
read a card deck.)
By default, also, the queue SYS$BATCH is used to
queue spooled jobs. Thus, no special command is needed to establish
card readers as spooled devices.
However, you must use the DCL command SET DEVICE to establish a line
printer or a terminal as a spooled device.
The use of this command is
restricted to users with the OPER privilege.
The VAX/VMS Command
Language User's Guide describes the SET DEVICE command in detail.
Typically, you must decide which devices to include in the system's
basic complement of spooled devices.
Often, you set up devices for
spooling by making entries in the system start-up command procedure.
At a minimum, you should see that at least one line printer is set
spooled when the system is started up.
In a system with only one line
printer, this is the default system printer.
Depending on system
configuration and anticipated operational needs, more spooled devices

BATCH AND PRINT JOBS
can be established at start-up. Moreover, in the course of normal
operations
(to meet special operational needs), you can define still
other devices as spooled devices without having to reboot the system.
Normally, all line printers should be spooled.
You can use the SET DEVICE command to specify the intermediate device
for each output spooled device.
When you select an intermediate
device, ensure that it has sufficient free space for the volume of
queued output you expect.
If you plan to enforce disk quotas on the
intermediate device, ensure that all expected users of the spooled
device have a quota authorized on the intermediate device.
Finally, and most important, on a system with both spooled input
devices and spooled output devices, you must create and start at least
one batch queue to handle spooled input and one output queue to handle
output for each spooled output device.

8.1.2

Turning Off Spooling

You can, as necessary, turn off spooling to spooled printers and
terminals by use of the DCL command SET DEVICE. However, you must
stop the corresponding device queues before you can change the
spooling status.

8.2

BATCH JOBS

Batch jobs can be submitted to
execution in two ways:

the

VAX/VMS

system

and

queued

for

•

As command procedure disk files submitted by use of the SUBMIT
command (see the VAX/VMS Command Language User's Guide).
These files are also placed in a batch queue and selected for
execution according to their priority. By default, the name
of this batch queue is SYS$BATCH.

•

As batch job files submitted by use of the JOB command
(see
the VAX/VMS Command Language User's Guide) from a card reader.
These batch job files are spooled onto disk by an input
symbiont and placed in a batch queue according to their
priority. Unless the $JOB card specifies otherwise, the name
of this batch queue is SYS$BATCH (by default). From the batch
queue, batch jobs are selected for execution.

Batch jobs cannot be executed unless at least one batch queue has been
created on the system and unless that queue has been started. By
default, SYS$BATCH is the batch queue.
In the VAX/VMS system, many jobs, or streams, can be executed at the
same time from each of several batch queues. Thus, you can create and
start several batch queues at once and can specify the number of jobs,
or streams, that can be executed at the same time from each queue.
In a batch queue that has been started, the job with the highest
priority is the first candidate for execution. Whether or not that
job is actually started up, however, depends on an evaluation of the
following limits' and conditions:
•

The maximum number of batch jobs allowed to be executed from
the queue at the same time.
You specify this limit with
either of the DCL commands INITIALIZE/QUEUE or START/QUEUE.

BATCH AND PRINT JOBS
•

The maximum number of all jobs allowed to be executed
system at the same time.

•

The number of jobs currently being executed in the system.

the

Hence, the highest priority batch job in a queue is started up only if
both of the following conditions are satisfied:

8.2.1

•

Fewer than the maximum number of
currently running from the queue.

batch

•

The system is not saturated with other jobs.

jobs

allowed

are

Creating Batch Queues

The DCL command INITIALIZE/QUEUE is used to create or initialize a
batch queue. The use of this command is restricted to users with the
OPER privilege. The VAX/VMS Command Language User's Guide describes
the INITIALIZE/QUEUE command in detail.
Typically, you must decide on the number of batch queues for an
installation, on the job limit of each queue, on the priority of each
queue, and on the swap mode of- each queue. Often, you create batch
queues by making entries in the system start-up command procedure.
Note that you can define no more than 64 queues.
Setting up batch queues is not restricted to start-up time.
In the
course
of
normal operations, you can create batch queues as
operational needs dictate.

8.2.2

Starting Batch Queues

The execution of batch jobs from a batch queue
(dequeuing)
can only
take place if the batch queue has been started. The DCL command
START/QUEUE starts a batch queue.
The use of this command is
restricted to users with the OPER privilege. The VAX/VMS Command
Language User's Guide describes the START/QUEUE command in detail.
Typically, you must see that batch queues created by use of the
INITIALIZE/QUEUE command are_ started. Often, you start batch queues
by making entries in the system start-up command procedure.
Starting batch queues is not restricted to start-up time.
In the
course of normal operation, you can start queues as operational needs
dictate.

8.2.3

Stopping Batch Queues

You can, as necessary, abort a job in a batch queue or disable all
processing from the queue until the queue is restarted by use of the
START/QUEUE command. The DCL command STOP/QUEUE is used to stop batch
queues.
The VAX/VMS Command Language User's Guide describes this
command in detail.

8-5

BATCH AND PRINT JOBS
8.2.4

Deleting Batch Queues

You can delete batch queues, as necessary, by use of the DCL command
DELETE/QUEUE.
The VAX/VMS Command Language User's Guide describes
this command in detail.

8.2.5

Emptying the Queue File

If the queue file
(SYS$SYSTEM:JBCSYSQUE.EXE)
becomes corrupted,
it
will be necessary to restart the system to create an empty queue file.
You should suspect the queue
is corrupted whenever you notice
irregularities in the display produced by the DCL command SHOW QUEUE,
when jobs are not being run,
and/or
jobs seem to disappear.
The
system parameter REINITQUE is provided for this purpose. First you
would execute the following commands:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET REINITQUE 1
SYSGEN> WRITE CURRENT
%0PCOM, 25-JUN-1982 16:14:09.41, message from user SYSTEM
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process ID • • •
SYSGEN> EXIT

Next you should shut down the system, using the procedure SHUTDOWN.COM
(see Chapter 7).
Reboot,
following the procedure defined in the
software installation guide for your VAX-11 processor.
The job
controller creates a new empty queue file.
If you plan to submit a
Software Performance Report regarding your corrupted file (see Chapter
9), you should save the old JBCSYSQUE.EXE file and submit it with your
report.
(To save space you may choose
to
purge
the
file
JBCSYSQUE.EXE.)
Next, you need to reset the reinitialize queue system parameter so
that your queue file will not be emptied by default the next time you
reboot.
You can use the following sequence of commands:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET REINITQUE 0
SYSGEN> WRITE CURRENT
%0PCOM, 25-JUN-1982 16:14:09.41, message from user SYSTEM
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process ID • • •
SYSGEN> EXIT

8.2.6

Batch Versus Interactive Jobs

You should normally encourage users to submit large jobs
(such as
compiling and linking large programs)
as batch jobs and reserve
interactive use of the system for jobs that do not require extensive
resources. A technique toward this end is to (1) restrict the working
set size of interactive jobs by providing a small (for example,
200)
WSQUOTA value in the UAF records and (2) expand the working set size
of batch jobs by providing a large (for example, 500) WSQUOTA value in
the START/QUEUE and INITIALIZE/QUEUE commands.
You can likewise
restrict and expand time limits on jobs by setting the CPU values.

8-6

BATCH AND PRINT JOBS
8.2.7

Setting Up Batch Queues

The following guidelines are useful in setting up a batch queue for
system that is predominantly interactive:
1.

Set up one batch queue
default batch queue.

named

SYS$BATCH,

Give SYS$BATCH the following characteristics:
a.

Job limit -- 1 to 4

Priority -- 3 or 4

Swapping mode

Working set default -- 120

Working set quota -- 200 to 500

Working set extent -- 400 and up

CPU default

INFINITE

CPU maximum

INFINITE

the

name

the

start

this

swapping enabled (by default)

You execute the following command procedure to create and
queue:

$ START/QUEUE SYS$BATCH
$ IF $STATUS THEN GO TO BATCH DONE
$ INITIALIZE/QUEUE/BATCH/JOB LIMIT=l/PRIORITY=3/WSDEFAULT=300/WSQUOTA=500/WSEXTENT=20007CPUDEFAULT=INFINITE/CPUMAXIMUM=INFINITE SYS$BATCH
$ START/QUEUE SYS$BATCH
$ BATCH DONE:
The first START command. and the test
existing queue is not initialized.
Normally, these commands
procedure (see Chapter 7).

are

contained

$STATUS

ensure

that

start-up

command

the

The following rules of thumb are useful in setting up batch queues for
a system that is predominantly a batch system and in which editing is
the principal interactive activity:
1.

Set up three batch queues as follows:
a.

SYS$BATCH -- the default batch queue.

FAST -- a high-priority queue for executing high-priority
jobs that should not be swapped out of memory.

SLOW -- a low-priority background queue for processing
low-priority jobs. Typically, these are large jobs with
large requirements for physical memory.
Usually,
it is
uneconomica1 to swap such jobs out of memory. You can
adjust the system workload by stopping and restarting
background queues as needed.

Give SYS$BATCH the following characteristics:
a.

Job limit -- 6 to 10

8-7

BATCH AND PRINT JOBS

Priority

Swapping mode

-- swapping enabled

(by default)

Give FAST the following characteristics:

-- 1 (by default)
Priority -- 4 (by default)

Swapping mode -- swapping disabled

-- 4 (by default)

Job limit

Give SLOW the following characteristics:
a.

Job limit -- 1 (by default)

Priority -- low (3, for example)

Swapping mode -- swapping disabled

NOTE
This
configuration
should
not
be
attempted on a small system (under lMB) •
Additionally, you should add up the
pages required for the batch working
sets and insure that
enough
fluid
memory! remains for interactive jobs.
Otherwise, you must reduce the number of
batch jobs or make the FAST and SLOW
jobs swappable.
In particular, you must
not let fluid memory drop below the
value of the WSMAX system parameter, or
a deadlock could result.
Execute the following command procedure
queues:

create

and

$ START/QUEUE SYS$BATCH
$ IF $STATUS THEN GOTO BATCH DONE
$ INITIALIZE/QUEUE/BATCH/JOB-LIMIT=6 SYS$BATCH
$ START/QUEUE SYS$BATCH
$ BATCH DONE:
$ START7QUEUE FAST
$ IF $STATUS THEN GOTO FAST DONE
$ INITIALIZE/QUEUE/BATCH/DISABLE SWAPPING FAST
$ START/QUEUE FAST
$ FAST DONE:
$ START/QUEUE SLOW
$ IF $STATUS THEN GOTO SLOW DONE
$ INITIALI.ZE/QUEUE/BATCH/PRIORITY=3/DISABLE SWAPPING
$ START/QUEUE SLOW
$ SLOW DONE:

start

these

SLOW

1. Fluid memory refers to memory that can be reassigned from one
process to another through swapping and paging. You can calculate
fluid memory as the space that remains when you subtract the number of
pages permanently allocated to VAX/VMS from the total memory. You can
obtain these values by issuing the DCL command SHOW MEMORY.
8-8

BATCH AND PRINT JOBS
Normally, these commands should
start-up command procedure.

8.3

contained

the

site-specific

waiting

executed.

command.

PRINT QUEUES

A queue is a list containing jobs that are
Jobs are executed according to priority.

Print jobs are placed in print queues by means of the
Print queues can be any one of the following:
•

Physical-device queues -- queues associated
named for) a specific print device.

with

(that

is,

•

Generic queues -- queues from which jobs can be given to
available print device that has matching characteristics.

any

•

Named, or logical, queues -- queues that are not associated
with a print device. To obtain printed output from a logical
queue, you must explicitly assign the queue to a print device.
The ASSIGN/QUEUE command, described in the VAX/VMS Command
Language User's Guide, is used for this purpose.

Terminal queues are print queues destined for terminal devices
(which
are probably being used as remote printers, never interactively).
They are created and controlled by use of the same commands that are
used to create and control regular print queues. Print jobs in
generic print queues are not dequeued to a terminal device queue
unless the generic queue is initialized or started with the /TERMINAL
qualifier.
·
Unless a line printer is associated with a physical queue
(a queue
that has the same name as the line printer device name) and unless
that queue has been started, no queued output can occur on that line
printer.
Print jobs are queued for processing in one of two ways: without the
direct intervention of a user (that is, implicitly) or with the direct
intervention of a user (that is, explicitly).
An implicitly spooled file is created when a program or DCL command
sends its output to a spooled printer. When an implicitly spooled
print file destined for a spooled printer is closed, the file
is
placed in a print queue. Both the spooling of the output fi1e to an
intermediate device and the subsequent queuing of a job consisting of
this file occur without the direct intervention of a user.
By use of the PRINT command, a user can explicitly queue a disk file
or several files for printing. The VAX/VMS Command Language User's
Guide describes the PRINT command in detail. The disk file or files
specified in the PRINT command are queued as a print job;
if several
files make up a print job, they will be printed together.
Print jobs are placed in queues according to their priority.
From
these queues, print jobs are selected for initiation. Among the jobs
in a print queue for a particular printer at any given time, the job
with the highest priority is the one chosen for printing.
By default, print jobs queued by use of the PRINT command are placed
in the queue named SYS$PRINT. Thus, to use the default version of the
PRINT command in a system with only one line printer, the system

8-9

BATCH AND PRINT JOBS
logical name SYS$PRINT is equated with the name of the physical line
printer.
To use the default version of the PRINT command in a system
with several line printers of matching characteristics, SYS$PRINT is
normally established as the name of a generic queue.
The maximum number of physical device queues that can be prlnting at
one time is restricted to the value of the MAXPRINTSYMB system
parameter.
See Chapter 10 for further
information
on
system
parameters.

8.3.1

Creating Print Queues

The DCL command INITIALIZE/QUEUE is used to create or initialize a
print queue. The use of this command is restricted to users with the
OPER privilege. The VAX/VMS Command Language User's Guide describes
the INITIALIZE/QUEUE command in detail.
Typically, you must decide on the number of print queues for an
installation and on their attributes. Often, you create print queues
by making entries in the site-specific start-up command procedure.
Note that you can define no more than 64 queues.
Setting up print queues is not restricted to start-up time.
In the
course
of
normal operations, you can create print queues as
operational needs dictate.

8.3.2

Starting Print Queues

The initiation of print jobs from a print queue (dequeuing)
can only
take place if the print queue has been started. The DCL command
START/QUEUE starts a print queue.
The use of this command is
restricted to users who have the OPER privilege. The VAX/VMS Command
Language User's Guide describes the START/QUEUE command in detail.
All options that can be specified in the INITIALIZE/QUEUE command can
also be specified in the START/QUEUE command.
Typically, you must see that print queues
created
with
the
INITIALIZE/QUEUE command are started. Often, you start print queues
by making entries in the site-specific start-up command procedure.
Starting print queues is not restricted to start-up time.
In the
course of normal operations, you can start queues as operational needs
dictate.

8.3.3

Stopping Print Queues

You can abort a job in a print queue, suspend the printing of a
job
currently being printed, or disable processing from the queue entirely
until the queue is restarted, with the START/QUEUE command.
The
STOP/QUEUE command is used to stop print queues and to suspend
printing of jobs. The VAX/VMS Command Language User's Guide describes
these commands in detail.

8.3.4

Deleting Print Queues

You can delete print queues, as necessary, by use of the DCL command
DELETE/QUEUE.
The VAX/VMS Command Language User's Guide describes
this command in detail.
8-10

BATCH AND PRINT JOBS
8.3.5

Emptying the Queue File

If the queue file becomes corrupted, you can use
given in Section 8.2.5.

8.3.6

the

same

technique

Assigning a Named, or Logical, Print Queue to a Printer

The DCL command ASSIGN/QUEUE is used to assign or redirect a named, or
logical, print queue to a printer.
The use of this command is
restricted to authorized users with the OPER privilege.
The VAX/VMS
Command Language User's Guide describes the ASSIGN/QUEUE command in
detail.
To produce printer output, a logical queue must first be assigned to a
printer and then started.
Typically, the print files of a group of low-priority users can be
placed in a logical queue and held there until off-peak hours.
Then,
to print the files, you can assign the queue to a line printer and
start the queue.

8.3.7

Deassigning a Named, or Logical, Print Queue from a Printer

The DCL command DEASSIGN/QUEUE is used to deassign a named, or
logical, print queue from a printer.
The use of this command is
restricted to users with the OPER privilege.
The VAX/VMS Command
Language User's Guide describes the DEASSIGN/QUEUE command in detail.

S.3.8

Adjusting Vertical Page Size

By default, the various system utilities (including the EDT editor,
the compilers, and the linker) produce listings with a vertical page
size of 66 lines.
(The page size is defined as the number of lines
between perforations.)
You may change the vertical page size for
listings with one of the following techniques, depending on whether
the program was run in native mode or compatibility mode.

8.3.9

Page Length of Native Mode Image Listings

You may change the vertical page size for listings produced by the
native mode utilities by specifying a numeric value, an integer in the
range of 30 to 99,
inclusive,
for the
system
logical
name
SYS$LP LINES.
The following example changes the vertical page 'size
for all users to 60 lines per page:

$ DEFINE /SYSTEM SYS$LP_LINES 60
Individual users may change the vertical
process basis.

page

size

group

A vertical page size of less than that specified by the DCL command
SET PRINTER/PAGE
(which defaults to 64) causes a skip to the head of
the next form each time the specified line count is reached.
A
greater vertical page size causes the excess lines to overflow to the
next form and then skip to the head of the following form when the
count is reached.

8-11

BATCH AND PRINT JOBS
8.3.10

Page Length of Compatibility Mode Image Listings

The default page length of 66 applies
following compatibility mode programs:

listings

MAC.EXE (MACRO/RSXll)

•

TKB. EXE (LIN.K/RSXll) ,

•

CRF.EXE (Compatibility Mode Cross Reference)

SOS.EXE (EDIT/SOS)

•

SLP.EXE (EDIT/SLP)

created

the

To modify this default page length, use the command procedure
LINEPAGE.COM in SYS$UPDATE.
Users with a system UIC or read/write
access to system files can execute this command procedure.
Perform the following steps to change the default page length:
1.

Change the current default with the following command:
$ SET DEFAULT SYS$UPDATE

Execute the procedure, located in this directory,
the count of lines per page as a parameter:

specifying

@LINEPAGE line-count
For example, to set the default line count per
execute the procedure as shown below:

page

54,

$ @LINEPAGE 54
NOTE
The command procedure produces a new copy of the
images
being
patched.
If the image had been
previously installed, remember to reinstall it
(with
the Install Utility) after patching, or else you must
reboot the system. You can delete the old versions
of the image files;
if you need the standard 66
lines per printer page format, just run the command
procedure again, giving the line-count as 66.
(The
procedure can be run multiple times.)

8.3.11

Forms Control

You specify the forms type of a print queue with the /FORMS TYPE
qualifier to the INITIALIZE/QUEUE or START/QUEUE command.
If a-user
enters a print job with a forms value (/FORMS qualifier to the PRINT
command) different from that of the queue, the job is placed on a hold
status until the forms value of the queue is set equal to the forms
value of the job.
(You should stop the queue, physically change the
forms, and start the queue specifying the new value for
the
/FORMS_TYPE qualifier.)
The forms type can be specified as a number or an alphabetic code.
Alphabetic
codes
must
be
defined
in
the
file
SYS$MANAGER:FORMSTYPE.DAT, one code per line, in the following format:

% code number comments
8-12

BATCH AND PRINT JOBS
You can include lines of text in the file
if desired.
Only lines
beginning with a percent sign are taken as code-number definitions.
The following example defines the code NORMAL as the number 0:
% NORMAL 0 NORMAL LINE PRINTER PAPER
A specification of /FORMS=NORMAL (or /FORMS=N, /FORMS=NO, and so on)
is interpreted to mean /FORMS=O.
Note, however, that the first match
found in FORMSTYPE.DAT prevails with no ambiguity checks made, so that
potentially conflicting names (that is, names starting with the same
letter) should be avoided.

8.3.12

Printer Characteristics

You specify the printer characteristics of a print queue with the
/CHARACTERISTICS qualifier to the INITIALIZE/QUEUE or START/QUEUE
command.
If a user enters a print job with a characteristic
(/CHARACTERISTICS qualifier to the PRINT command) not included in
those for the queue, the job is placed on a hold status until the
characteristics
of
the
queue
are
set
to
include all the
characteristics of the job.
(You should stop the queue, physically
change the characteristics of the printer, and start the queue
specifying the new values for the /CHARACTERISTICS qualifier.)
A characteristic can be specified as a number or an alphabetic code.
Alphabetic codes must be defined in the file SYS$MANAGER:CHARTYPE.DAT,
one code per line, in the following format:
% code number comments
You can include lines of text in the file if desired.
Only lines
beginning with a percent sign are taken as code-number definitions.
The following example defines the code REDINK as the number 3:
% REDINK 3
Subsequent INITIALIZE/QUEUE or START/QUEUE and PRINT commands can use
the number 3 or the alphabetic code REDINK to describe one printer
characteristic.
Note, however,
that the first match found
in
CHARTYPE.DAT
prevails
with no ambiguity checks made, so that
potentially conflicting names (that is, names starting with the same
letter) should be avoided.

8.3.13

Guides to Setting Up Print Queues and Spooled Line Printers

The following rules of thumb are useful in setting up
print queues and spooled line printers:

and

regulating

Normally, set all line printers spooled.

To produce output on a spooled line printer,
initialize a
print queue with the same name as the spooled printer and
start that queue.

If more than one line printer is on the system, enable
generic printing from as many print queues as possible, and
make at least one print queue (SYS$PRINT)
a generic queue.
Queues for line printers that are in remote locations, that
use special forms,
or
that
possess
unique
printer
characteristics should not be enabled for generic printing.

0_1~

BATCH AND PRINT JOBS
4.

To use special forms or apply unique printer characteristics
to a general-purpose queue, stop the queue, physically change
the forms or apply the printer characteristics, and start the
queue with the appropriate /FORMS TYPE or /CHARACTERISTICS
qualifier. After the special jobs -are printed, stop the
queue, physically reset the forms or printer characteristics,
and start the
queue
with
the
original
/FORMS
or
/CHARACTERISTICS value.

Figures 8-1 through 8-4 illustrate some of
the
most
common
arrangements of spooled line printers and print queues. These figures
can be used, with the rules of thumb listed above, as guidelines in
setting up spooled line printers and print queues.
NOTE
The commands shown
in the
examples
assume
manual
entry
at run time.
Command
procedures
especially
start-up
command
procedures
containing INITIALIZE and START commands
should contain logic to ensqre that an
existing queue is not initialized.
See
Chapter 7 and the examples in Section
8.2.6.
If
an
existing
queue
is
initialized, any jobs in that queue are
lost.
Figure 8-1 illustrates a typical spooling
for a system with one line printer.
figure produce the following results:

and queuing configuration
The commands listed in this

The line printer LPAO is set spooled.

&ystem-wide, the logical name SYS$PRINT is equated with the
name LPAO.
The equivalence of these names is recorded in the
system logical name table.

The print queue LPAO is initialized and started.

All print jobs explicitly directed to the printer LPAO are
placed in the queue LPAO and are printed from that queue.

All print jobs that normally would-be placed by default in a
queue named SYS$PRINT
(if that queue existed) are actually
placed in the queue LPAO (in this case,
the system default
print queue) and are printed from that queue.

Figure 8-2 illustrates a typical spooling and queuing configuration
for
a
system
with
two
line
printers that have the same
characteristics. The commands listed
in this figure produce the
following results:
spooled~

The line printer LPAO is set

The line printer LPBO is set spooled.

The generic queue SYS$PRINT is initialized and started.

Physical queues LPAO ~nd LPBO are initialized
with generic printing enabled by default.

and

started,

BATCH AND PRINT JOBS
5.

All print jobs explicitly directed with the PRINT command to
one of the two printers are placed in the queue associated
with the specified printer.
-

Print jobs queued with the PRINT command without device
specification are placed by default in the generic queue
SYS$PRINT.
From the generic queue,
jobs are printed on
whichever printer is free, by way of either of the two
physical queues, LPAO or LPBO.

Spooled print files destined either for LPAO or for LPBO are
placed in the generic queue SYS$PRINT, which was associated
with both these printers. From the generic queue, these jobs
are printed on whichever printer is free.
COMMANDS

$SET DEVICE/SPOOLED:LPAO LPAO
$ ASSIGN/SYSTEM LPAO
SYStPRINT
!!i

INTTTt1LJZE/DUCUE_/FL_t1C

START/QUEUE

LF't-10

LPAO

Queue

Line Printer

LPAO
Default Print
Queue

LPAO
ZK-1005-82

Figure 8-1: Setting Up a Spooled Printer and a Print
Queue on a System with One Line Printer
Figure 8-3 illustrates a typical spooling and queuing configuration
for a system with three line printers:
two that have the same
characteristics and one that uses special forms, has unique printer
characteristics, or is in a remote location. The configuration shown
in Figure 8-3 is basically the same as the one in Figure 8-2, with the
addition of the spooled printer LPCO and the creation and starting of
the queue LPCO. Because of the special forms, unique characteristics,
or the remote location, printer LPCO is not suited for general
printing. Thus, with the following exceptions, the commands listed in
Figure 8-3 produce the same results as the commands listed in Figure
8-2:
1.

The line printer LPCO is set spooled.

The physical queue LPCO is
generic printing disabled.

Only print jobs explicitly directed to the printer LPCO are
ever placed in the queue LPCO; no generic printing is ever
done on printer LPCO by way of the queue SYS$PRINT.

initialized

and

started

with

BATCH AND PRINT JOBS
COMMANDS

$
$
$
$
$
$
$
$

SET D l,JICE/SPOOL D=SY
SET D I.) I CE SPOOL D=S\'
IN IT I LI ZE QUEUE FLAG
START QUEU SYS$ RINT
IN IT I LIZE QUEUE FLAG
START QUEU LPAO
IN IT I LIZE QUEUEi FLAG
START QUEU LPBO

$PRINT L
$PRINT I.._
GENERIC

·HR INT

LPAO
LPBO

Queues

Line Printers

SYS$PRINT
Generic Print
Queue

LPAO
Generic Printing
Enabled

LPAO

LPBO
Generic Printing
Enabled

LPBO
ZK-1006-82

Figure 8-2: Setting Up Spooled Printers and Print
Queues on a System with Two Line Printers with
the Same Characteristics
Figure 8-4 adds still another feature to the configuration illustrated
in Figure 8-3. This is a logical queue, which is a named, nongeneric
queue that is not directly associated with any line printer.
When a
logical queue is assigned to a line printer and started, however,
output to a line printer can occur.
Logical queues can be used, for example, to pold print jobs of
low-priority users for printing during off-peak hours. To channel the
print jobs of these users into a logical queue, the name of the
logical queue
(HOLD, for example)
must be assigned to the name of
their default print queue (SYS$PRINT).

Q_1 e::.

BATCH AND PRINT JOBS
COMMANDS
$
$
$
$
$
$
$
$
$
$
$

SET DEVICE/SPOOLED=SYSSPRINT LPAO
SET DEVICE/SPOOLED=SYSSPRINT LPBO
SET DEVICE/SPOOLED=LPCO LPCO
INITIALIZE/QUEUE/FLAG/GENERIC SYSSPRINT
START/QUEUE SYSSPRINT
INITIALIZE/QUEUE/FLAG LPAO
START/QUEUE LPAO
INITIALIZE/QUEUE/FLAG LPBO
START/QUEUE LPBO
)NITIALIZE/QUEUE/FLAG/NOENABLE_GENERIC_PRINTING LPCO
START/QUEUE LPCO

Queues

Line Printers

SYS$PRINT
Generic Print

Queue

LPAO
Generic Printing
Enabled

LPAO

LPBO
Generic Printing
Enabled

LPBO
LPCO
No Generic
Printing

LPCO
ZK-1007-82

Figure 8-3: Setting Up Spooled Printers and Prine Queues on a System
with Three Line Printers; Two with the Same Characteristics and One
with Special Characteristics or in a Remote Location
As shown in Figure 8-4, the DCL command INITIALIZE/QUEUE is used to
initialize the logical queue HOLD. This queue is initialized with
generic printing disabled. When the queue HOLD is assigned to the
printer LPBO and started, the jobs in the queue HOLD are printed on
the line printer LPBO by way of the physical queue LPBO.

8-17

BATCH AND PRINT JOBS
COMMANDS
$
$
$
$
$
$
$
$
$
$
$
$
$
$

SET DEVICE/SPOOLED=SYSSPRINT LPAO
SET DEVICE/SPOOLED=SYSSPRINT LPBO
SET DEVICE/SPOOLED=LPCO LPCO
INITIALIZE/QUEUE/FLAG/GENERIC SYSSPRINT
START/QUEUE SYSSPRINT
INITIALIZE/QUEUE/FLAG LPAO
START/QUEUE LPAO
INITIALIZE/QUEUE/FLAG LPBO
START/QUEUE LPBO
INITIALIZE/QUEUE/FLAG1NOENABLE_GENERIC_PRINTING LPCO
START/QUEUE LPCO
INITIALIZE/QUEUE/FLAG'NOENABLE_GENERIC_PRINTING HOLD
ASSIGN/QUEUE LPBO HOLD
START/QUEUE HOLD

Queues

Line Printers

SYS$PRINT
Generic Print
Queue

LPAO
Generic Printing
Enabled

LPAO

LPBO
Generic Printing
Enabled

LPBO
LPCO
No Generic
Printing

HOLD
Logical Prfnt
Queue

LPCO

ZK-1008-82

Figure 8-4: Setting Up Spooled Printers and Print Qu•ues
Adding a Logical Queue to the System with Th~ee
Line Printers

8-18

BATCH AND PRINT JOBS
8.4

COMMANDS FOR CONTROLLING PRINT AND BATCH QUEUES

The commands listed in Table 8-2 allow you to manipulate queues and
the
jobs that they contain.
These commands are described in the
VAX/VMS Command Language User's Guide.

Table 8-2: DCL Commands for Controlling
Print and Batch Queues
Command

Function

ASSIGN/MERGE

Removes all jobs from one queue
and places them in another queue

ASSIGN/QUEUE

Assigns a
queue

DEASSIGN/QUEUE

Deassigns a device from a queue

DELETE/ENTRYl,2

Deletes an entry from a print or
batch job queue or stops printing
the current job

DELETE/QUEUE

Deletes print and batch queues

INITIALIZE/QUEUE

Creates print and batch queues

PRINTl

Queues one or more files for
printing, either on a default
system printer or other device

SET DEVICE

Establishes the
spooling
and
error-logging status on a device

SET QUEUE/ENTRYl,2

Changes the status or attributes
of jobs in print or batch queues
that have not yet been processed
by the system

SHOW DEVICEsl

Displays the status of devices in
the system

SHOW QUEUEl

Displays
the
names,
job
identification
numbers,
and
status of current and pending
jobs in print or batch queues

START/QUEUE

Starts print or batch queues

STOP 2

Halts execution of
procedure,
program,
or detached process

STOP/ABORTl,2

Stops printing of a job
currently printing

1.
This command does not
(OPER).

require

the

device

operator

logical

a
command
subprocess,
that

user

privilege

2. A user with either operator (OPER) or world (WORLD)
can use this command to affect any job in the system.

privilege

(continued on next page)
8-lC}

BATCH AND PRINT JOBS
Table 8-2 {Cont.): DCL Commands for Controlling
Print and Batch Queues
Function

Command
STOP/ENTRYl,2

Stops execution of a batch
that is currently running
deletes it

STOP/QUEUE

Suspends print queues
batch queues

STOP/REQUEUEl,2

Stops printing of a job that is
currently printing and requeues
that job, giving it a priority of

and

job
and
stops

SUBMITl

Enters a job in a batch queue

1. This command does not
(OPER).

user

privilege

2. A user with either operator (OPER) or world (WORLD)
can use this command to affect any job in the system.

privilege

8.5

require

the

operator

PROCEDURES FOR CONTROLLING PRINT AND BATCH QUEUES

The following sections contain step-by-step procedures for controlling
print and batch queues established on the VAX/VMS operating system.

8.5.1

Merging Print Queues

When a problem occurs with a print device, the queue associated with
that print device should be rerouted to another print device. The
procedure below describes how to merge two print queues without losing
jobs in either queue.
Procedure
1.

Stop the queue associated with the malfunctioning
device by issuing the following command:

STOP/QUEUE/NEXT queue-namel
This command inhibits further dequeuing but permits the
current job to be completed. However, if the print device is
inoperable, the current job will not be completed.
2.

Requeue the current job by typing the following command:
STOP/REQUEUE queue-namel
By requeuing the current job, this command ensures this job
will be printed in its entirety. Other jobs in the queue
will not be dequeued because the queue is stopped.

Take the device offline.

R-?O

BATCH AND PRINT JOBS
4.

Reroute the jobs queued to the malfunctioning print device to
qnother print device by entering the following command:
ASSIGN/MERGE queue-name2 queue-namel
You should check that the characteristics of
device are appropriate for the new jobs.

the

Optionally,
delete
the
queue
associated
malfunctioning print device by typing:
DELETE/QUEUE

new

with

the

queue-name

Example

$ STOP/QUEUE/NEXT
LPBO
$ STOP/REQUEUE
LPBO
$ ASSIGN/MERGE LPAO
LPBO
$ DELETE/QUEUE
LPBO

The STOP/QUEUE/NEXT command prevents further dequeuing from
the LPBO queue. The STOP/REQUEUE command terminates the job
currently being printed or attempting to print and places it
back in the queue with a priority of 1. The next job in the
LPBO queue will not be dequeued because the queue has been
stopped.
The ASSIGN/MERGE command removes the jobs from the
print queue LPBO and places them in the print queue LPAO.
The print queue LPBO is then deleted by means of the
DELETE/QUEUE command.

8.5.2

Preventing Loss of Data When the Line Printer Runs Out of Paper

The procedure below describes how to prevent loss of data while
is loaded in the line printer.

paper

When a line printer runs out of paper, OPCOM prints the following form
of message on the operator's terminal to indicate that the device is
not ready:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, Device device-name is offline.
Procedure
1.

Suspend the current queue operation by issuing the
DCL command:

following

STOP/QUEUE queue-name
The DCL command SHOW QUEUE queue-name will now show the queue
as PAUSED.
2.

Take the printer offline.

Load a new box of paper in the printer and return the printer
online.

Resume printing by entering the DCL command:
START/QUEUE/optional-qualifier queue-name

8-?1

BATCH AND PRINT JOBS
Note that you can optionally append one of the following
qualifiers to the above command to insure the output of the
interrupted print job is complete:
/BACKSPACE

Backspaces
resumes.

/TOP_OF_FILE

Starts at the beginning of the file that
was being printed when the paper ran out.

one

page

printing

before

Example
%0PCOM, 19-JUN-1982 22:08:43.40, Device LPAO is offline.
$ STOP/QUEUE LPAO
$ START/QUEUE/TOP_OF_FILE

LPAO

OPCOM notifies the operator that line printer LPAO went offline
at 22:08:43.40. The operator stops the queue associated with the
printer and takes the printer offline. After loading a new box
of paper in the printer, the operator returns the printer online.
Printing resumes after the operator types the
START/QUEUE
command.
The /TOP OF FILE qualifier indicates that the job that
was being printed when-the operator issued the STOP/QUEUE command
will be restarted at the beginning of the file.

8.5.3

Terminating the Execution of a Batch Job

The procedure below describes how to terminate the execution of a
batch job. You usually perform this task only when careful assessment
shows a job must be terminated or the owner of the job requests the
termination.
Procedure
1.

Type the following command to determine the job number of the
batch job and the name of the queue in which the job is
located:

$ SHOW QUEUE/BATCH/ALL
2.

Delete the
commands:

batch

job

STOP/ENTRY=job-number
DELETE/ENTRY=job-number

issuing

one

the

following

queue-name
queue-name

Example

$ SHOW QUEUE/BATCH/ALL

* Batch queue "SYS$BATCH" Joblim~S, Basepri=4, Swap
CURR
AFTER
AFTER
CURR
CURR

1662 DEBUG
1710 JEROME
1703 SYSTEM
1708 SYSTEM
1706 LANGLEY

DBGBUILD
BEGINBLD
DELETE LO
LNK32
FORPROG

Pri=4
Pri=4
Pri=4
Pri=4
Pri=4

7-JUN-1982
7-JUN-1982
7-JUN-1982
7-JUN-1982
7-JUN-1982

12:25
18:49
22:23
12:20
12:18

BATCH AND PRINT JOBS

* Batch queue "SYS$BUILD" Joblim=7, Basepri=4, Swap
* Batch queue "SYS$CHECKIN" Joblim=l, Basepri=4, Swap Stopped
* Batch queue "SYS$LOAD" Joblim=lOO, Basepri=4, Swap Stopped
$ STOP/ENTRY=l706

SYS$BATCH

Assume a user has observed that job 1706 is a runaway job.
The user is not the owner of the job, and lacks sufficient
privilege to stop it. The user enlists the operator's aid.
The
operator types the SHOW QUEUE/BATCH/ALL command to
determine the queue in which the job has been entered.
The
display shows that job 1706 is in the SYS$BATCH queue. The
operator then deletes the job by typing the STOP/ENTRY
command.

8.5.4

Terminating the Printing of a Print Job

The procedure below describes how to terminate a print job that is
currently being printed on a print device. You usually perform this
task only if the system manager or the owner of a
job requests that
the job be terminated, or if you observe garbled output on the print
device.
Procedure
Enter the following command:
STOP/ABORT print-device
This command terminates the current job and
the next job in the queue.

begins

printing

Example
$ STOP/ABORT

LPAO

This command terminates the printing of the current print job
on LPAO.
The next job in the queue is immediately dequeued
for printing.

8.5.5

Removing a Batch or Print Job from a Queue

The procedure below describes how to delete a batch or print job that
has been entered in a queue but has not yet been processed. You
usually perform this task only after careful assessment that it is
necessary or at the request of the owner of the job.
Procedure
1.

Type the following command to determine the job number
the name of the queue in which the job is located:
$ SHOW QUEUE/DEVICE/ALL

Delete the job by issuing the following command:
DELETE/ENTRY=job-number queue-name

and

BATCH AND PRINT JOBS
Example
$ SHOW QUEUE/DEVICE/ALL

* Generic Device queue "SYS$PRINT"

Flag

* Device queue "LPAO" Forms=O, Genprt Lower Flag
CURR

1327 RAP

Pri=4

7-JUN-1982 12:36 Size=73

* Terminal queue "TTF4" Forms=O, Nogen Lower
* Device queue "LQP" Forms=O, Nogen
This queue assigned to TTF4

* Device queue "LPCO" Forms=O, Nogen Lower Flag
CURR

1328 SMITH

OEUVRE

Pri=4

7-JUN-1982 12:54 Size=312

* Terminal queue "TTHO" Forms=O, Nogen Lower
* Device queue "PLOTQ" Forms=O, Nogen
This queue assigned to TTHO
$ DELETE/ENTRY=l328 LPCO

A user has requested that job 1328 be deleted.
The operator
types the SHOW QUEUE/DEVICES/ALL command to determine in
which queue the job has been entered. The display shows that
job 1328 is in the LPCO queue. The operator then aborts the
job by typing the DELETE/ENTRY command and by specifying the
job-number 1328.

8.5.6

Restarting the Job Controller

If it becomes necessary to restart the job controller, you can
the STARTUP.COM procedure as follows:

invoke

$ @SYS$SYSTEM:STARTUP JOBCTL

8.6

USING THE CARD READER

The card reader is used to read card decks.
Users may submit the
following types of card decks for processing:
•

Batch job card decks

•

Data card decks

two

You must understand the two types of card decks and how to tend the
card reader in order to use the card reader and ensure card decks are
processed efficiently. This chapter describes which cards you should
check before processing a card deck through the card reader and how to
determine which cards are damaged.
Section 8.6.3.2 outlines a
procedure for processing a card deck through the card reader.

8-24

BATCH AND PRINT JOBS
8.6.1

Types Of Card Decks

Before loading a card deck into the card reader, you should determine:
•

Whether the deck is a batch job or a data deck, because
processing requirements differ.

•

Whether the card reader is
mode.

set

the

correct

their

translation

8.6.1.1 Batch Job Card Deck - A batch job card deck can be divided
into three segments:
the initial cards, the program cards or the
cards containing the batch job, and the last card.
The initial two
cards in a batch job card deck are the $JOB and the $PASSWORD cards.
These cards log in the user and the batch job to the system.
Following the initial two cards are program cards.
Program cards
contain instructions that direct the system to libraries,
routines,
and data needed to complete the batch job. The last card must be
either an End-Of-Job command card ($EOJ) or an End-Of-File (EOF) card.
Both of these cards tell the system this is the end of the job.

8.6.1.1.1 Checking Batch Job Card Deck Input - When a batch job is
inserted into the card reader input hopper for processing, the first
two cards in the card deck must be:
•

A $JOB card

•

A $PASSWORD card

The system cannot execute the job without these cards.
If you are
given a card deck with these cards omitted, you should return the deck
so the user can insert these cards.
Since the card deck contains the user's password, you must ensure it
is always handled with care to preserve the security of the user's
account.
The last card in the deck must be one of the following:
•

A $EOJ card

•

An EOF card (12-11-0-1-6-7-8-9 overpunch)

If the last card is not one of these end cards, you can
the card punch and insert it at the end of the deck.

type

one

8.6.1.1.2 Checking Batch Job Output - The log file produced by a card
reader batch job is queued for printing to the default system print
queue, SYS$PRINT. To have the log file queued to a different queue,
the user can include an $ASSIGN or $DEFINE card in the job to redefine
SYS$PRINT. The VAX/VMS Command Language User's Guide explains how to
use the ASSIGN and DEFINE commands.
If an error occurs while the system is attempting to validate the $JOB
and $PASSWORD cards, a listing containing the error message is queued
to SYS$PRINT. The user's name {if any) on the listing flag page is
the user's name from the $JOB card. The job name is INPBATCH.ERR.
When the user's name cannot be determined from the $JOB card, the deck
is simply flushed through the card reader and no listing is queued.

BATCH AND PRINT JOBS
8.6.1.2 A Data Card Deck - A data deck is a deck of cards containing
data that either will be read by a program or copied to a file for
later use. The process that will
read the data deck usually is
associated with an interactive user at a terminal or a batch job that
is submitted by an interactive user.
Since the user and process
already are logged
in to the system, the first card can contain any
data the user wants to specify. However, the program must read the
exact number of cards supplied, or the last card should be an EOF card
(12-11-0-1-6-7-8-9 overpunch) to inform the program that this is the
end of the data deck.
When a user wants a data deck to be read, you should ensure that
user has allocated the card reader.
If the card reader is
allocated, the system tries to submit the deck as a batch job
subsequently just flushes the deck through the reader, rejecting
job.

the
not
and
the

If the program does not read the exact number of cards, as with the
COPY command, the EOF card (12-11-0-1-6-7-8-9 overpunch) must be the
last card in the deck, to inform the program that this is the end of
the deck. Without this card, the program waits indefinitely for more
cards and the system prints "card reader offline" messages on the
operator's terminal.
If the card deck lacks an EOF card, you can type
an EOF card on a card punch and insert it at the end of the deck.

8.6.2

Card Reader Translation Modes

For the system to read input properly, the card reader must be set to
the correct translation mode. The translation mode used must be the
same as the translation mode of the card punch on which the cards were
punched.
VAX/VMS
supports 026 and 029 card punches.
(These
translation modes are discussed in detail in the VAX/VMS I/O User's
Guide and the VAX/VMS Guide to Using Command Procedures.) ~One of the following two conditions must exist for you to be
set the card reader to the correct translation mode:

able

•

The first card in the deck must be the translation mode card

•

You must know the mode in which the cards were punched

Without the above information, you cannot set the card reader
correct translation mode.

the

To set the translation mode of the card reader for many decks of the
same type,
use the SET CARD READER command.
This command is fully
described in the VAX/VMS Command Language User's Guide.
By default,
when the system is bootstrapped, the translation mode is set to 029.

8.6.3

Tending The Card Reader

The job of tending the card reader includes:
•

Ensuring that the cards in batch jobs and data decks
properly ordered as discussed in the preceding pages

•

Replacing physically defective cards

•

Operating the card reader

are

BATCH AND PRINT JOBS
NOTE
For more information on card reader
batch
jobs
from
a
system user's
viewpoint, refer to the VAX/VMS Guide to
Using Command Procedures.

8.6.3.1 Replacing Physically Defective Cards - Even when the
card
deck contains all the required cards, the card reader may not be able
to read the deck. This usually occurs because one or more cards are
physically defective.
If the deck contains a faulty card, one of the error indicators
located on the front panel of the card reader lights up when the card
is read. The card reader goes offline, and operator intervention is
required to put it back online. Table 8-3 at the end of this chapter
describes the error indicators, reasons why they may light up, and the
operator action required to correct the situation.

8.6.3.2 Operating the Card Reader - This
section
contains
a
step-by-step procedure for processing card decks through the card
reader.
Procedure
This procedure describes how to load and process a card deck through a
card reader.
1.

Remove the card weight from the input hopper.
Place the
cards, face down and with column 1 on the left, in the
hopper.
Ensure that the first card to be read is at the
bottom of the hopper.
Do not pack the input hopper so full that the air from the
blower cannot riffle the cards.
If the cards are packed too
tightly, the vacuum picker cannot operate properly.

Press the RESET button. The HOPPER CHECK error indicator and
the STOP light will go out and the cards will be read.
If the card deck is too large to fit in the input hopper, the
excess cards can be loaded while the reader is operating if
tension is maintained on the front portion of the deck.

Remove the cards from the output stacker when the
CHECK error indicator and the STOP light are lit.

HOPPER

If the STOP button is accidentally pressed while the card
deck is being read, return the last card in the output hopper
to the bottom of the input hopper and press the RESET button.
4.

If the cards are not read properly after the RESET button has
been
pressed,
refer to Table 8-3 below for
recovery
procedures.

BATCH AND PRINT JOBS
Table 8-3:
Error Indicator
READ CHECK

Card Reader Errors: Causes and Corrective Actions
Causes

Corrective Action

Card edges torn
Punch in column O or 81

Remove the faulty card from the
output stacker, duplicate the
card, place it in the input
hopper, and press the RESET
button
If READ CHECK occurs for all
cards, the read logic of the
card reader is malfunctioning

PICK CHECK

Damage to leading edge
Torn webs
Cards stapled together

Remove the card from the input
hopper, duplicate the faulty
card, place the card back in
the input hopper, and press the
RESET button
If there is no evidence of card
damage,
check for excessive
warping of the card deck and/or
a buildup of ink glaze on the
picker face

STACK CHECK

HOPPER CHECK

Badly mutilated card

Correct the jam and/or remove
the mutilated card from the
output stacker, duplicate the
card, place it in the input
hopper, and press the RESET
button

Input hopper empty

Load the input hopper

Output stacker full

Unload the output stacker

Jam in the card track

8-28

CHAPTER 9
ERRORS AND OTHER SYSTEM EVENTS

The system provides several tools for recording and reporting errors
and other system events. These tools include facilities for logging
and reporting system events, logging operator messages, and reporting
problems to DIGITAL.
In the event of a severe system failure, VAX/VMS
automatically shuts down the system and produces a crash dump of the
state of the system at the time the error was detected. You can
analyze the dump to help you determine the cause of the system
failure.
See the VAX/VMS System Dump Analyzer Reference Manual.
In a
few cases, as described in Section 9.3, you may want to forward the
dump to DIGITAL with a Software Performance Report.

9.1

ERROR LOG

The system automatically writes messages to the latest version of
file named SYS$ERRORLOG:ERRLOG.SYS as the following events occur:

•

Errors -- Device errors, machine checks, bus errors, soft
error correcting code (ECC) errors, asynchronous write errors,
hard ECC errors

•

Configuration changes -- Volume mounts and dismounts

•

System events
Cold start-ups, warm start-ups,
start-ups,
messages
from Send Message to Error
($SNDERR) system service, time stamps

crash
Logger

You can display and report the information in the error log by running
the SYE Utility, which is decribed in the VAX-11 Utilities Reference
Manual. Since the system continues to log messages to ERRLOG.SYS and
creates a new version of the file if the current one is locked, you
should either rename the file, copy it, or append it to another file,
before running SYE against the new file.
ERRLOG.OLD is recommended as
the new name since SYE uses this name as a default for the input file.

9.1.1

Operations

The error logging facility consists of three parts:
•

A set of executive routines that detects errors and events and
writes relevant information into error log buffers in memory

•

A process called ERRFMT that periodically empties the error
log buffers, transforms the descriptions of the errors into
standard formats, and stores the formatted information in a
file on the system disk

•

The SYE Utility
Q-1

ERRORS AND OTHER SYSTEM EVENTS
The executive routines and the ERRFMT process operate continuously
without user intervention. The routines fill up the error log buffers
in memory with raw data on every detected error and event.
When one
of the available buffers becomes full,
or when a time allotment
expires,
ERRFMT automatically writes the buffers to ERRLOG.SYS.
Sometimes a burst of errors can cause the buffers to fill up before
ERRFMT can empty them.
In this case, the system merely assigns a
sequence number to the errors and events that occur, but does not save
the data. You can detect this condition by noting a skip in the
sequence numbers of the records reported by SYE. As soon as ERRFMT
frees the buffer space, the executive routines resume preserving error
information in the buffers.
The ERRFMT process displays an error message on the system console and
deletes itself if it encounters excessive errors while writing the
error log file.
You can restart ERRFMT by invoking the STARTUP
command procedure in the
[SYSEXE]
directory and by specifying one
parameter, as in the following example:
$ @SYS$SYSTEM:STARTUP

ERRFMT

The command procedure should be
account {UIC [1,4]).

9.1.2

invoked

from

the

system

manager's

Using Error Reports

The error reports generated by SYE are useful tools in two basic ways:
•

Reports aid preventive maintenance by identifying areas within
the system that show potential for failure.

•

Reports speed the diagnosis of a failure by documenting
errors and events that led up to the failure.

the

The detaile~ contents of the reports are most meaningful to DIGITAL
field service personnel.
However, you can use the reports as an
important indicator of the system's reliability.
For example, when a
report shows that a particular device is producing a relatively high
number of errors, you can consult DIGITAL field service. By running a
diagnostic program to
investigate the device,
field service can
attempt to isolate the source of the errors.
Once identified, the
source of the errors can be eliminated and a failure averted.
In the event that a system component does fail,
a field service
representative can study error reports of system activity leading up
to and including the failure.
For example, if a device fails, you can
generate error reports immediately after the failure.
One report
might describe in detail all the errors associated with the failed
device and occurring within the last 24 hours; another report might
summarize all types of errors that occurred within the same time
period.
The summary report can put the device errors into a
system-wide context. The field service representative can then run
the appropriate diagnostic program for a thorough analysis of the
failed device.
Using the combined error logging and diagnostic
information,
the field service representative can proceed to correct
the device.
The information made available by the error logging facility is
essential to efficient maintenance of a VAX/VMS system.
Error reports
allow you to track system performance and to anticipate failures.
In
turn,
field service personnel rely on the reports as an aid to both
preventive and corrective maintenance.
Overall, effective use of the
error logging facility, in conjunction with diagnostic programs, can
significantly reduce the amount of system downtime.

9-2

ERRORS AND OTHER SYSTEM EVENTS
, Because the file ERRLOG.SYS can be renamed and the renamed error log
file can then be copied to a removable volume, error reports can be
generated either at the site where the errors occurred or at any other
VAX/VMS installation.
For example, a field service representative can
rename and copy the error log file to take back to the field service
office, where another VAX/VMS system can be used to generate error
reports. Alternatively, you can rename and copy to a disk file a
version of the error log file that covers a crucial period of system
activity.
Upon arriving on site, your field service representative
can generate one or more reports from the copied file as well as from
the current version of ERRLOG.SYS.

9.1.3

Maintaining the Error Log Files

While SYE is accessing ERRLOG.SYS,
ERRFMT cannot write any error
information into
it.
Therefore,
if SYE is accessing the highest
version of ERRLOG.SYS when ERRFMT needs to log an error,
ERRFMT
creates a new version of the file.
The new version picks up logging
errors where the previous version left off. All the versions of the
ERRLOG.SYS file
remain on the system disk until a user explicitly
manipulates them in some way.
The fewer the log files, the simpler and more efficient it is to
generate log reports. You can take steps to minimize or control the
number of versions created.
For example, when generating several reports from the current error
log file, you should first rename the error log file to ERRLOG.OLD and
then use the renamed file as input to SYE.
In this way, only one new
error log file
is created, and SYE does not prevent ERRFMT from
accessing the new file.
In addition, you ensure that SYE is accessing
the same error log file for each report.
All versions of the ERRLOG.SYS file
remain on the system disk
(SYS$SYSROOT)
until they are explicitly deleted.
Therefore, you must
devise a plan for regular maintenance of the error log file.
One way to do this is to rename the highest version of ERRLOG.SYS on a
daily basis.
This action causes a new error log file to be created
and allows the old file (which was renamed) to be copied to a back-up
volume where it can be kept as long as needed.
For example, you could
rename the current copy of ERRLOG.SYS every morning at 9:00 o'clock to
ERRLOG.OLD.
To free space on the system disk, you could then back up
the renamed version of the error log file on a different volume and
delete the renamed file from the system disk. Note that caution
should be taken to ensure that error log files are not deleted
inadvertently.
You may also want to consider adopting a naming
convention for your files that incorporates a beginning or ending date
for the data in the file name. A detailed example of this maintenance
procedure is provided in the next section.

9.1.4

Printing The Error Log File

The procedure below describes how to rename a formatted error log file
and obtain a copy of it.
Note that these instructions are for
renaming and printing one version of the error log file at a time.
For a complete description of the SYE Utility, refer to the VAX-11
Utilities Reference Manual.

ERRORS AND OTHER SYSTEM EVENTS
Procedure
1.

Set the default disk and the default directory by typing
following command:

the

$ SET DEFAULT SYS$ERRORLOG
2.

Examine the directory to see which versions of the ERRLOG.SYS
file are on disk by typing:
$ DIRECTORY ERRLOG.SYS

Rename all versions of the ERRLOG.SYS file, one at a time, to
ERRLOG.OLD by issuing the command:
RENAME/LOG ERRLOG.SYS;n

ERRLOG.OLD

To preserve the chronological order of the files after
renaming,
first rename the oldest version of ERRLOG.SYS (the
version with the lowest version number,
n),
then rename
versions n+l, n+2 and so on.
Do not use a wild card character in the version field of the
file specification to
rename more than one version of
ERRLOG.SYS at a time.
Such a RENAME command will attempt to
preserve version numbers and thus chronological order, but
the presence of previously renamed ERRLOG.OLD files will
interfere with that algorithm.
4.

Invoke the SYE Utility to format the error log
readable error log report with the command:

file

into

$ RUN SYS$SYSTEM:SYE
After the above command string is processed, the SYE Utility
prompts for input and output file specifications, options, a
device name, and entry dates.
5.

Respond to the SYE prompt by specifying the name of the error
log file and the type of output desired.
Note that if you
respond to all the SYE Utility prompts by pressing the RETURN
key, the SYE Utility defaults to the specifications contained
i~ the square brackets (as shown in the example below).

Obtain a printed copy of the error log report by entering an
output file name in response to the SYE prompt for an output
file as shown in the example below.
Then· enter the following
command:
$ PRINT file-name
The file name indicates the name of the file
error log report.

Example
$ SET DEFAULT SYS$ERRORLOG
$ DIRECTORY ERRLOG.SYS
Directory SYS$SYSROOT: [SYSERR]
ERRLOG.SYS;l
Total of 1 file.

9-4

containing

the

ERRORS AND OTHER SYSTEM EVENTS

$ RENAME ERRLOG.SYS ERRLOG.OLD
$ RUN SYS$SYSTEM:SYE
SYE VERSION 3.3
INPUT FILE:
[ [SYSERR]ERRLOG.OLD
-OUTPUT FILE:
[SYS$0UTPUT]
-OPTIONS:
[ROLL-UP]
DEVICE NAME:
[<CR>]
-AFTER DATE:
[FIRST ENTRY]
BEFORE DATE:
[LAST ENTRY]

?~
?ERRLOG.LIS~
?~
?~
?~
?~

%SYE-I-SUCCOM,
SUCCESSFUL COMPLETION
$ PRINT ERRLOG.LIS
The SET DEFAULT command sets the operator's default disk and
directory to SYS$SYSROOT:[SYSERR].
The DIRECTORY command
lists all the ERRLOG.SYS files contained in the
[SYSERR]
directory.
In this example,
[SYSERR]
contains only one
version of ERRLOG.SYS.
The RENAME command renames ERRLOG.SYS
to ERRLOG.OLD; a new version number is assigned if a file of
this name already exists.
The operator then invokes the SYE Utility by typing RUN
SYS$SYSTEM:SYE.
The SYE Utility lists the defaults enclosed
in square brackets for each of the following parameters and
prompts for any changes in these:
•

The name of the file to be manipulated (here,
the default input file).

ERRLOG.OLD,

•

The name of the file that is to contain the error log
report.
The error log file in the preceding example is
written to ERROLOG.LIS, which facilitates obtaining a
printed copy of the error log file later. The default
output file, SYS$0UTPUT,
is printed at the operator's
terminal.

•

The type of report that SYE should generate. The type of
report
here
is
a summary ROLL-UP report.
For a
description of other types, see the VAX-11 Utilities
Reference Manual.

•

The devices for which SYE should report errors.
By
pressing the RETURN key, you request error reports for all
devices.

•

The time from which SYE should report errors. By pressing
the RETURN key,
you request that SYE report all errors
that occurred since the error log file was created.

•

The time until which SYE should report errors.
By
pressing the RETURN key, you request that SYE report the
occurrence of errors up to and including the last error in
the error log file.

The SYE Utility creates a readable error log report.
The
operator obtains a hardcopy of this report by pressing the
RETURN key in response to the final SYE prompt, provided the
operator previously had not specified an output file name.
If the operator had chosen an output file name other than the
default SYS$0UTPUT
(as was done in the preceding example by
responding ERRLOG.LIS to the OUTPUT FILE question), an
additional step
(use of the DCL command PRINT) would have
been required to produce a printed copy of the report.

9-5

ERRORS AND OTHER SYSTEM EVENTS
9.2

OPERATOR'S LOG FILE

The operator's log file (SYS$MANAGER:OPERATOR.LOG) is another system
management tool that is useful in anticipating and preventing hardware
and software failures. By regularly examining the operator's log
file, you can often detect tendencies, or trends, toward failures and
can thereby ensure that corrective action is taken before these
failures occur.
You should, therefore, print out copies of the
operator's log file regularly, and retain these copies for reference.
Figure 9-1 illustrates some typical messages found in the operator's
log file.
%0PCOM, 29-JUN-1982 22:28:28.72, message from user NETACP
DECnet shutting down
%0PCOM, 29-JUN-1982 22:33:54.07, operator disabled, operator OPAO
%0PCOM, 29-JUN-1982 22:34:15.47, operator enabled, operator OPAO
%0PCOM, 29-JUN-1982 22:34:15.57, operator status for operator OPAO
PRINTER, TAPES, DISKS, DEVICES
%0PCOM, 29-JUN-1982 22:38:53.21, request 1, from user PUBLIC
Please mount volume KLATU in device MTAO:
Gort, the tape is in cabinet A
%0PCOM, 29-JUN-1982 22:39:54.37, request 1 was satisfied.
%0PCOM, 29-JUN-1982 22:40:23.54, message from user SYSTEM
11
Volume 11 KLATU
mounted, on physical device MTAO:
%0PCOM, 29-JUN-1982 22:40:38.02, request 2, from user PUBLIC
MOUNT new relative volume 2 {) on MTAO:
%0PCOM, 29-JUN-1982 22:41:07.54, message from user SYSTEM
Volume "KLATU
" dismounted, on physical device MTAO:
%0PCOM, 29-JUN-1982 22:41:14.95, device LPAO is offline
%0PCOM, 29-JUN-1982 22:41:50.98, message from user SYSTEM
CURRENT system parameters modified by process ID 001F003C into file SYS$SYSROOT:[SYSEXE]SYS.EXE;l
BERADA
29-JUN-1982 22:42:14.81, request 2 completed by operator OPAO
%0PCOM, 29-JUN-1982 22:42:15.83, request 3, from user PUBLIC
MOUNT new relative volume 3 {) on MTAO:
%0PCOM, 29-JUN-1982 22:42:16.95, device LPAO is offline
%0PCOM, 29-JUN-1982 22:42:44.54, message from user SYSTEM
11
Volume "BERADA
mounted, on physical device MTAO:
%0PCOM, 29-JUN-1982 22:42:44.73, message from user SYSTEM
Volume "BERADA
" dismounted, on physical device MTAO:
I'm sorry, but we are out of tapes.
29-JUN-1982 22:45:11.45, request 3 aborted by operator OPAO
%0PCOM, 29-JUN-1982 22:46:47.96, request 4, from user PUBLIC
TTB5:, This is a sample user request w/ reply expected.
%OPCOM, 29-JUN-1982 22:47:38.50, request 4 was canceled
%0PCOM, 29-JUN-1982 22:48:21.15, message from user PUBLIC
TTB5:, This is a sample user request w/o a reply expected.
%OPCOM, 29-JUN-1982 22:49:07.90, Device DMAO is offline.
Mount verification in progress.
%0PCOM, 29-JUN-1982 22:49:20.22, Mount verification completed for device DMAO
%0PCOM, 29-JUN-1982 22:49:37.64, Device DMAO has been write locked.
Mount verification in progress.
%0PCOM, 29-JUN-1982 22:53:54.52, Device DMAl is offline.
Mount verification in progress.
%0PCOM, 29-JUN-1982 22:54:16.56, Mount verification aborted for device DMAl

Figure 9-1:

Sample Operator's Log File (SYS$MANAGER:OPERATOR.LOG)

9-6

ERRORS AND OTHER SYSTEM EVENTS
The operator's log file records the occurrence of system events.
These messages are produced by the operator's communication process
(OPCOM) and are preceded by the label %0PCOM.
Section 9.2.4 explains
the messages in detail.

9.2.1

Maintaining The

Operato~'s

Log File

The operator's log file
(SYS$MANAGER:OPERATOR.LOG)
resides on the
system disk in the [SYSMGR] directory. This file is in ASCII format
and can be printed as readable text. You should print copies of the
operator's log file regularly, and retain these copies for reference.
Section 9.2.2 describes how to print copies of the operator's log
file.
A new version of the operator's log file
is created each time the
system is rebootstrapped.
The highest version of this file is always
the one in use and is inaccessible. You should devise a plan for
regular maintenance of these files.
One ~ay to maintain these files is to rename the second highest
version of the operator's log file on a daily basis.
For example, you
might rename the current version of OPERATOR.LOG to OPERATOR.OLD every
morning at 9:00.
To free space on the system disk, you then could
back up the renamed version of the file on a different volume and
delete the renamed file from the system disk.
You should not delete
versions of the operator's log file that have not been backed up.
The procedure for renaming the operator's log file is the same as that
described in Section 9.1.4 for renaming the error log file.

9.2.2

Printing The Operator's Log File

The procedure below describes how to produce a printed copy of the
current version of the operator's log file (OPERATOR.LOG). You should
periodically print a copy of this file for review.
Procedure
1.

Close the current log file and open a new one by entering the
following command:
$ REPLY/LOG

Set the default to the system disk by typing:
$ SET DEFAULT SYS$MANAGER

Rename the second highest version of the
OPERATOR.OLD with the following command:

operator's

log

$ RENAME OPERATOR.LOG;-! OPERATOR.OLD
The version number, -1 specifies that the second highest
version of this file is to be printed.
The highest version
number is the current operator's log file.
4.

Obtain a printed copy of the operator's log file
the following command:
$ PRINT OPERATOR.OLD

9-7

issuing

ERRORS AND OTHER SYSTEM EVENTS
Example
$ REPLY/LOG
%0PCOM, 16-JUN-1982 12:29:24.52, logfile initialized by operator TTA2
logfile is SYS$MANAGER:OPERATOR.LOG
$ SET DEFAULT SYS$MANAGER
$DIRECTORY OPERATOR.LOG
Directory SYS$SYSROOT:[SYSMGR]
OPERATOR.LOG;582

OPERATOR.LOG;581

Total of 2 files.
$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD
$ PRINT OPERATOR.OLD

The REPLY/LOG command closes the current log file and opens a
new one;
the response from OPCOM verifies that a new log
file has been opened.
The SET DEFAULT command sets the
operator's default disk to the system disk, thus enabling the
operator to examine the files contained in the directory
[SYSMGR].
The operator renames the second highest version of
the operator's log file to OPERATOR.OLD and then issues the
PRINT command to request that this version of the operator's
log file {OPERATOR.OLD) be printed.

9.2.3

Restarting OPCOM

You can restart OPCOM if for some reason it is deleted or suspended.
Simply invoke the STARTUP command procedure in the [SYSEXE] directory
and specify one parameter, as in the following example:
$

@S~S$SYSTEM:STARTUP

OPCOM

You should invoke the STARTUP
manager's account {UIC [1,4]).

from

the

system

This section describes six of the seven types of message
in the operator's log file:

that

appear

9.2.4

command

procedure

Messages in the Operator's Log File

•

Initialization of the operator's log file

•

Status reports for devices attached to the system

•

Terminals enabled and disabled

•

Volume mounts and dismounts

•

User requests and operator replies

•

Changes to system parameters through the SYSGEN Utility

•

DECnet-VAX status messages

See the DECnet-VAX System Manager's Guide for
seventh type, the DECnet-VAX status messages.

9-8

information

about

the

ERRORS AND OTHER SYSTEM EVENTS
9.2.4.1 Initialization Messages - When you
issue
the
REPLY/LOG
command, the current operator's log file is closed and a new version
of that file is created and opened. All subsequent OPCOM messages are
recorded in this new log file.
When a new log file is created, the first message recorded in it is an
initialization message that tells when and by whom the log file was
initialized. This message appears in the following format:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, logfile initialized' by operator operator-name
logfile is SYS$MANAGER:OPERATOR.LOG

9.2.4.2 Device Status Messages - Some VAX/VMS
I/O
drivers
send
messages to OPCOM concerning changes in the status of the devices they
control. For example, when a line printer goes offline, an OPCOM
message is written into the operator's log file at periodic intervals
until the device is explicitly returned to online status.
The device status message appears in the operator's log
following format:

file

the

%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, device device-name is offline
The devices for which this message can appear are card
printers, and magnetic tapes.

readers,

line

9.2.4.3 Terminal Enable and Disable Messages - You
designate
a
terminal as an operator's terminal by issuing the REPLY/ENABLE command
from the desired terminal.
OPCOM confirms the request by displaying
the following message at the operator's terminal and in the operator's
log file:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, operator enabled, operator terminal-name

This message tells you which terminal has been established
operator's terminal and when it was so established.

If a terminal has been designated as an operator's terminal for a
particular function,
OPCOM displays the name of that function.
For
example, if you issue the command REPLY/ENABLE=TAPES,
OPCOM displays
the following message:
%0PCOM, 14-JUN-1982 10:25:35.74, operator enabled, operator TTEl
$
%0PCOM, 14-JUN-1982 10:25:38.82, operator status for operator TTEl
TAPES
OPCOM confirms that the terminal
is established as an operator's
terminal and indicates that the terminal can only receive and respond
to requests concerning magnetic tape-oriented events, such as the
mounting and dismounting of tapes.
A terminal that has been designated as an operator's terminal
is
automatically returned to nonoperator status when the operator logs
out. To return the terminal to normal
{nonoperator)
status without
logging off, you must issue the REPLY/DISABLE command from the
terminal. OPCOM confirms that the terminal is no longer an operator's
terminal by displaying a message in the following format both at the
operator's terminal and in the operator's log file:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, operator disabled, operator terminal-name

ERRORS AND OTHER SYSTEM EVENTS
This message tells you which terminal has been restored to nonoperator
status and when the transition occurred.
If a terminal is designated as an operator's terminal and only partial
operator status is disabled, OPCOM displays a status message. This
message lists which requests the terminal can still receive and
respond to. This message is displayed at the operator's terminal and
in the operator's log file in the following format:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, operator status for operator terminal-name
status-report

For example, suppose you designate a terminal as an operator's
terminal that receives messages concerning magnetic tapes and disks,
as well as messages intended for the special site-specific operator
class known as OPERlO.
Later, you relinquish the terminal's ability
to receive messages concerning
tapes.
When
you
issue
the
REPLY/DISABLE=TAPES command, OPCOM returns the following message:
%0pcom, 14-JUN-1982 09:23:45.32, operator status for operator TTA3
DISKS, OPERlO
This message tells you that terminal TTA3 still receives and
respond to messages about disks and messages directed to OPERlO.

can

9.2.4.4 Volume Mount and Dismount Messages - Perhaps the widest range
of operator messages occur with volume mounts and dismounts. Chapter
5 discusses mount verification and operator-assisted mounts.
An
appropriate sample of the messages appears in those discussions and
examples.

9.2.4.5 User Request and Operator Reply Messages - To
communicate
with you, the user issues the REQUEST command, specifying either the
/REPLY or /TO qualifier.
If the user issues a REQUEST/REPLY command, the request is recorded in
the operator's log file in the following format:
%0PCOM,dd-mmm-yyyy hh:mm:ss.cc, request request-id from user user-name
_terminal-name:, "message-text"

This message tells you which user sent the message, the time the
message was sent, the request identification number assigned to the
message, the originating terminal, and the message itself.
If the user issues a REQUEST/TO command, the request is recorded in
the operator's log file in the format described above, but without a
request identification number, as follows:
%0PCOM,dd-mmm-yyyy hh:mm:ss.cc, request from user user-name
_terminal-name:, "message-text"
For examples of the OPCOM messages that result from requests to mount
magnetic tapes through the magtape ACP using the REQUEST/BLANK TAPE
and REQUEST/INITIALIZE_TAPE commands, see Chapter 5.
When you respond to a user's request and specify the /TO qualifier,
the response is recorded in the operator's log file in the following
format:
response message
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, request request-id completed by operator operator-name

ERRORS AND OTHER SYSTEM EVENTS
This message indicates how the operator responded to the user's
request, as well as when the response was issued and which operator
responded.
When you respond to a user's request and specify the /ABORT qualifier,
the response is recorded in the operator's log file in the following
format:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, request request-id was cancelled.
When you respond to a user's request using the /PENDING qualifier, the
response is not recorded in the operator's log file because the
request has not yet been completed (that is, the request has not been
fulfilled or aborted) •
When .a user issues a REQUEST/REPLY command and you have disabled all
terminals as operator's terminals, OPCOM records all subsequent user's
requests in the log file in the format shown above, but returns a
message to the user indicating that no operator coverage is available.
All other OPCOM responses to REPLY commands, except
responses
involving the REPLY/ENABLE, REPLY/DISABLE, and REPLY/LOG commands, are
not logged in the operator's log file.

9.2.4.6 Changes to System Parameters Through the SYSGEN Utility Users with the CMKRNL privilege can use the SYSGEN Utility to change
system parameters in the running
(active)
system.
Users with the
SYSPRV
privilege can use the SYSGEN Utility to change system
parameters in the current system.
OPCOM logs all changes made to
system parameters with messages in the following format:
%0PCOM, dd-mmm-yyyy hh:mm:ss.cc, message from user user-name
%SYSGEN-I-WRITExxx, system-mode system parameters modified by process ID n into file y

9.2.4.7 DECnet-VAX Messages - For information on DECnet-VAX
messages, see the DECnet-VAX System Manager's Guide.

9.3

status

REPORTING SOFTWARE PROBLEMS

To inform DIGITAL about problems with the VAX/VMS operating system or
about errors in VAX/VMS software documents, you should use the
Software Performance Report (SPR), which is illustrated in Figure 9-2.
Complete directions for completing the SPR form accompany the form
itself.
A supply of SPR forms is included in the VAX/VMS software distribution
kit; more forms can be obtained from an SPR center. The addresses of
these centers are listed on the backs of the forms.
This section offers advice on how to use this
service
most
effectively, by describing the
information that should be provided
with all SPRs. Depending on the problem, this information will vary
in quantity and content.
Remember that the more information you
include, the easier it will be for DIGITAL to resolve the problem.

a_11

ERRORS AND OTHER SYSTEM EVENTS

395878

SOFTWARE
PERFORMANCE
REPORT

'f TO.SET UP FOR PROPER ALIGNMENT, START AT MARK BELOW.

lSYSTEM PROGRAM OR DOCUMENT TITLE

OPERATING SYSTEM

DEC OFFICE
NAME:
FIRM:

REPORT

TYPE/PRIORITY

CUST. NO.:
SUBMITTED BY:

OF_ __

DATE

YOU HAVE SOURCES?
YESD

ADDRESS:

PAGE - - -

VERSION OR DOCUMENT PART NO.

~HEAVY SYSTEM IMPACT

PROBLEM/ERROR

MODERATE SYSTEM IMPACT

SUGGESTED ENHANCEMENT

MINOR SYSTEM IMPACT

OTHER

NO SIGNIFICANT IMPACT

DOCUMENTATION/SUGGESTION

PHONE:
CAN THE PROBLEM BE REPRODUCED AT WILL?
ATTACHMENTS

MAG TAPED FLOPPY DISKS D
OTHER:
CPU TYPE

ISERIAL NO.

lllffORT NAME

IMNT.

LISTI NGO

COULD THIS SPR HAVE BEEN PREVENTED BY
BETTER OR MORE DOCUMENTATION?
PLEASE EXPLAIN IN PROVIDED SPACE BELOW.

DECTAPED

MEMORY SIZE

lDISTRIBUTION MEDIUM

}SYSTEM DEVICE

loo

YESD

NOD

NOT PUBLISH

ALL SUBMISSIONS BECOME THE PROPERTY OF DIGITAL EQUIPMENT CORPORATION.
I MNT. GRP.

XFER GRP.

OATEi'lECIUVIED (MAii.i

DATE TO MAINTAINER

XFER DATE

LOGGED ON

DATE RCCIUVED (ASG)

DAT.E RECEIVEO·F.ROM MAINTAINER

DATE ANSWERED

LOGGED OFF

CAT.

EN-01044-07-REV. H (35C)

ADMINISTRATIVE SERVICES GROUP, SWS

Figure 9-2:

Software Performance Report (SPR)

9-12

IPR9.TV~E

ERRORS AND OTHER SYSTEM EVENTS
9.3.1

The Problem Environment

You should supply a complete description, usually in. the form of a
batch log or console listing, that shows exactly how the problem was
produced. Merely supplying the output produced by the problem is not
enough.
You must provide a complete scenario depicting what you did.
The problem may be caused by an interaction between various system
events, software packages, devices, SYSGEN parameters, DCL symbols, or
logical names. Consider including some or all of the displays these
commands produce, depending on your problem:
$ SHOW LOGICAL/ALL
$ SHOW SYMBOL/ALL/GLOBAL
$ RUN SYS$SYTEM:SYSGEN
$ SYSGEN> USE ACTIVE
$ SYSGEN> SHOW /ALL
$ SYSGEN> SHOW /SPECIAL

9.3.2

Limiting the Problem Scope

As much as possible, eliminate all extraneous elements from the
scenario you provide. For example, if the execution of a very complex
program causes a problem, strip the program to just the code that
causes the problem or write a small program that reproduces the
problem. This action may help you locate logic errors, and will
enable DIGITAL to isolate the problem more quickly.

9.3.3

Machine-readable Files

Supply any software needed to reproduce the problem,
if possible.
This may include source programs, image files, sample data, command
procedures, and other items. When you submit source programs, be sure
to include any libraries or require files that you reference. These
files should all be provided in machine-readable format.
Console
media or magnetic tape are the best media to include with an SPR.
If the problem involves a
file.
Write the data
ANSI! magnetic tape. The
file to an ANSI! magnetic

system failure, then include the system dump
onto a Files-11 Structure Level 2 disk or an
following commands will copy the system dump
tape:

$ MOUNT/FOREIGN MTAO:
DUMPS
$ BACKUP SYS$SYSTEM:SYSDUMP.DMP
You can copy files to the
commands:

console

MTAO:DUMP/SAVE_SET
medium

using

the

following

DCL

$ RUN SYS$SYSTEM:SYSGEN
CONNECT CONSOLE
(Now remove the console medium and
console device.)

place

scratch

medium

$ INITIALIZE CSAl:
SPRDATA
$ MOUNT CSAl: SPRDATA
$ CREATE/DIRECTORY CSAl: [SPR]
$ BACKUP MYDATA.DAT,MYIMAGE.EXE CSAl: [SPR] DATA/SAVE_SET
$ DISMOUNT CSAl:

9-13

the

ERRORS AND OTHER SYSTEM EVENTS
When you provide machine-readable data, always include the exact
instructions used to write the medium and instructions for reading the
medium.
(Avoid using other media formats, since doing so can cause
unnecessary problems.
For example, using FLX without /IM creates an
~nusable dump file since
FLX eliminates all bytes of zero.)
All
machine-readable media you submit with SPRs will be returned to you.

9.3.4

System Environment

Every site runs a different type of workload.
Some problems only
appear under certain conditions.
For example, some sites give
different classes of users different base priorities. These sites may
encounter
problems
that other sites do not.
Such background
information can be extremely important in resolving the problem,
especially for system hangs or system failures.
You should describe any special software packages that are running,
and mention any unusual hardware devices or user-written drivers on
your system.
Also include the various version numbers of different pieces of
software.
For example,
if a problem occurs while accessing local
symbols during a DEBUG session, specify the version numbers of DEBUG
and all compilers or assemblers used.
Sometimes DIGITAL forwards special patches or prereleases of patches
for problems that are seriously affecting the system.
If you are
using any such patches, mention them in the SPR.

9.3.5

User Analysis (Optional)

Optionally you can 'include an analysis of what you believe is causing
the problem.
Include miscellaneous information such as, "the problem
could only be reproduced when xyz happened," or "the problem does not
occur on Version Vx.y".

9.3.6

Problem-specific Information to Include

DIGITAL requires different kinds of information to resolve different
kinds of problems.
Use Table 9-1 as an initial checklist to begin
collecting the proper information to forward with your SPR.

Q-14

ERRORS AND OTHER SYSTEM EVENTS
Table 9-1:

Typical Information Requirements for SPRs

Problem
System Bugcheck/Failure

Information to Collect
A machine-readable copy
of
the
system dump file.l
(Do NOT send
output from the SDA Utility since it
usually
does not provide enough
information to resolve the problem.
If you send the dump file, DIGITAL
can always run SDA to obtain as much
information and possibly more.)
A copy of the error log at the time
of
the
error
to help DIGITAL
determine if the system problem was
triggered by hardware errors.2

Machine Check

System Hang

A copy of the error log at the
of the error.2

time

A machine-readable
system dump file.l

the

copy

A copy of the system dump file,
obtained after you crash the system
in the manner described in
the
software installation guide for your
VAX-11 processor.
This causes the system to bugcheck
in a manner that is recognizable as
a forced crash.
Include the console
listing and a description of the
currently running work load.

Executive

A listing of the active values of
the system parameters.
(Invoke the
SYSGEN Utility and specify the USE
ACTIVE, SHOW/ALL, and SHOW/SPECIAL
commmands.)
A machine-readable copy
of
the
source program showing the problem.

Devices

A copy of the error log at the
of the problem.2

time

A copy of the error log at the
of the problem.2

time

1. The raw data file
(SYS$SYSTEM:SYSDUMP.DMP), not the formatted
output from the SDA Utility. This provides DIGITAL a chance to run
SDA in enough ways to obtain sufficient information to analyze the
problem.
2. The raw data file
(SYS$ERRORLOG:ERRLOG.SYS), not the formatted
output from the SYE Utility. This provides DIGITAL a chance to run
SYE in enough ways to obtain sufficient information to analyze the
problem.
(continued on next page)

ERRORS AND OTHER SYSTEM EVENTS
Table 9-1 (Cont.):

Typical Information Requirements for SPRs

Problem
Files

Information to Collect
A listing of all the information
available on the file; obtained with
the DCL command DIRECTORY/FULL or a
dump header of the file's directory
obtained with
the
DCL
command
DUMP/HEADER.
A machine-readable copy of the
itself.

file

Intermittent

A copy of the error log at the
of the problem.2

time

Command Language Interpreters

A listing obtained from the DCL
commands SHOW SYMBOL/ALL/GLOBAL and
SHOW LOGICAL/ALL.

Job Controller

A copy of the console printout and a
machine-readable copy of the file
SYS$SYSTEM:SNAPSHOT.DAT
that
is
produced when the job controller
aborts.

Librarian

A machine-readable
library itself.

copy

the

Machine-readable copies of all input
files to the library.
A listing of all the information
the library file,
available
on
DCL
command
obtained from
the
DIRECTORY/FULL.
A listing of the library contents,
obtained
from
the
DCL command
LIBRARY/LIST/FULL.
(If
the
problem
cannot
be
reproduced, describe the scenario
and include any command files used.)
Linker

Machine-readable
copies
of
the
object files and libraries used in
the link.
A full map obtained
command LINK/MAP/FULL.

the

DCL

2.
The raw data file (SYS$ERRORLOG:ERRLOG.SYS), not the formatted
output from the SYE Utility. This provides DIGITAL a chance to run
SYE in enough ways to obtain sufficient information to analyze the
problem.
(continued on next page)

9-16

ERRORS AND OTHER SYSTEM EVENTS
Table 9-1 (Cont.):
Problem

Typical Information Requirements for SPRs
Information to Collect

Network

A description of the configurations
of
the systems involved in the
problem, including the versions of
the
operating
systems
and
DECnet-VAX, the hardware on both
systems, and the patch level of the
DECnet software on the no·n-VAX/VMS
system, if applicable.

Terminals

A list of terminal characteristics
produced by the DCL command SHOW
TERMINAL.
A description
terminal, the
any) ,
any
equipment, and
configuration.

Compiler or Assembler

of
the
type
of
type of modem
(if
special
front-end
any unusual terminal

A machine-readable copy
of
the
source
program
that caused the
problem, including all require files
and libraries that are referenced.
'(Try to limit the scope of the
problem.)
A description of the compiler
(or
assembler)
and operating system,
including the version of each.

C}-17

CHAPTER 10
SYSTEM PARAMETERS

This chapter describes the VAX/VMS system parameters
and
the
importance of each, as well as suggested values for each. Chapter 11
discusses the System Generation Utility (SYSGEN), which you can use to
change the values of system parameters. Chapter 12 describes the
AUTOGEN command procedure, which is the preferred tool for changing
system parameters.
(AUTOGEN uses SYSGEN.) Chapter 12 also describes
how some of the system parameters have significant impact on system
performance and provides some further suggestions on how to modify the
parameters, if necessary.
During system operation you can run SYSGEN (described in the VAX-11
Utilities Reference Manual) to modify the current values or the values
of any parameter file or create a new parameter file,
for use in
subsequent
bootstrap
operations.
SYSGEN also enables you to
dynamically alter the running system configuration by modifying a
subset of the active values.
It is important to understand the terms current and active when they
are used to refer to system parameters. The term active parameters
refers to the parameter values the system is actively running with;
that is, the values that are active at the present time. The only
active parameters that can be changed on a running system are those
that are categorized as dynamic parameters (see Section 10.1). The
term current parameters refers to those values stored on disk
(SYS$SYSTEM:SYS.EXE)
that are used to boot the system. The current
parameters become the active parameters at each bootstrap operation.
When you modify certain active parameters with SYSGEN, you have no
effect on the values of the current parameters; you merely change the
values of these parameters while the system is running. The next time
you bootstrap the system, the old values of the current parameters are
established as the active parameters.
(When you want to change the
values of the current parameters on disk, you must use the SYSGEN
command WRITE CURRENT.
Furthermore, when you want to change the value
of any active parameter that is not in the dynamic category, you must
not only issue the WRITE CURRENT command, but you must also reboot the
system to make it active. Chapter 11 describes how to do this.)

10.1

PARAMETER CATEGORIES

The system parameters fall into eleven general categories:
•

MAJOR -- Parameters most likely to require modification

•

SYS

Parameters that affect overall system operation

JOB

Job control parameters

10-1

SYSTEM PARAMETERS
•

ACP -- Parameters associated with Files-11
processes (ACPs)

ancillary

control

•

TTY

•

SCS
Parameters that control System Communication Services
(SCS)
and port driver operation.
The SCS parameters that
affect SCS operation have the pref ix scs.
Those
SCS
parameters that affect the CI780 port driver have the prefix
PA

•

RMS

PQL
Parameters associated with process creation limits
quotas

•

GEN -- Parameters that affect the creation and
of data structures at bootstrap time

•

SPECIAL

Special parameters used by DIGITAL

DYNAMIC

Parameters whose active values can be modified

Parameters associated with terminal behavior

Parameters associated with VAX-11 RMS
and

initialization

There is also a group of parameters that can be user-defined:
USERDl,
USERD2,
USER3, and USER4.
(USERDl and USERD2 are in the dynamic
category.}
Each parameter has associated with it default, m1n1mum, and maximum
values that define the scope of allowable values. Tables 10-1 through
10-8 briefly describe the parameters in each category.
To determine
the default, minimum, and maximum values you should invoke the System
Generation Utility (see Chapter 11} and issue the appropriate SHOW
command. For example, to display the values for the MAJOR parameters,
you can specify SHOW/MAJOR.
(The SPECIAL parameters
are
not
documented; they should be used only by DIGITAL personnel.}
Table 10-1:
Parameter Name

MAJOR Parameters
Dynamic

Description

PFCDEFAULT

Default page fault cluster size (in
pages}

GBLSECTIONS

Number of global section descriptors

GBLPAGES

Number of global page table entries

MAXPROCESSCNT

Maximum number of processes

SYSMWCNT

Maximum size of system working set
(in pages}

BALSETCNT

Maximum number of resident working
sets

IRPCOUNT

Number of preallocated intermediate
request packets

(continued on next page}

10-2

SYSTEM PARAMETERS
Table 10-1 (Cont.):
Parameter Name

MAJOR Parameters
Dynamic

Description

WSMAX

Maximum size of any working set (in
pages)

NPAGEDYN

Size of nonpaged dynamic pool (in
bytes, but rounded down to an integral number of pages by the system)

PAGEDYN

Size of paged dynamic pool (in bytes,
but rounded down to an integral
number of pages by the system)

VIRTUALPAGECNT

Maximum virtual space per process
(in pages)

LRPCOUNT

Number of preallocated large request
packets

SRPCOUNT

Number of preallocated small request
packets

QUANTUM

Maximum time a process can use at
once and minimum service a process
must receive before being outswapped,
(in lOms uni ts)

PFRATL

Page fault rate low limit (in faults
per 10 seconds of processor time)

PFRATH

Page fault rate high limit (in
faults per 10 seconds of processor
time)

WSINC

Working set increment (in pages)

WSDEC

Working set

decrem~nt

FREE LIM

Minimum size of the free page list

FREEGOAL

Number of pages required on the free
page list after a memory shortage

GROWLIM

Number of pages p-equired on the free
page list to allow process to exceed
working set quota

BORROW LIM

Minimum size of the free page
list before process can grow beyond
process working set quota (in p~ges)

LOCKIDTBL

Number of entries in the system lock
id table

RESHASHTBL

Number of entries in the lock
management resource name hash table

10-3

(in pages)

SYSTEM PARAMETERS

Table 10-2:
Parameter Name
PFCDE.FAULT

SYS Parameters

Description
Default page fault cluster size {in

Dynamic

MAJOR

pages}

KFILSTCNT

Number of known file 1 ist heads.

GBLSECTIONS

Number of global section descriptors

GBLPAGES

Number of global page table entries

GBLPAGFIL

Maximum number of system-wide pages
allowed for global page-file sections

MAXPROCESSCNT

Maximum number of processes

PROCSB:CTCNT

Number of process sections

MINWSCNT

Minimum number of fluid pages in
a.ny wo·rk.ing set

PAGFILCNT

Maximum number of paging files that
can be in.stalled

SWPFILCNT

Maximum number of swapping files that
can be installed

SYSMWCNT

Maximum size of system working, set
(in pages)

INTSTKPAGES

S·i ze of inte.·rrupt stac·k {in pages}

BALSETCNT

Maximum number of resident working
sets

IRPCOUNT

Number of preallocated intermediate
request packets

IRPCOUNTV

Maximum

WSMAX

Maximum
pages)

NPAGEDYN

Size 0 f nonpaged dynamic po;ol (in
bytes, but rounded down to an integral
number of pages by the sys.tern)

NPAGEVIR

Maximum size to which NPAGEDYN can
be incre·ase·d

PAGEDYN

Size of pag:ed dynamic poo I (:in bytes,
but ro unded down ta an integ:ra.l number

size to whi.c:h IRPCOUN'T can be
increased
size of any wo;rking. s·et (in

VIRTUALPA.GECNT

pages by the system·l

Maximum virtual space per process.
(in pages)'

(continued on next page}

10-4

SYSTEM PARAMETERS
Table 10-2 (Cont.):
Parameter Name

SYS Parameters
Dynamic

Description

MAJOR

SPTREQ

Number of additional system
page table entries

LRPCOUNT

Number of preallocated large request
packets

LR PC OUN TV

Maximum value to which LRPCOUNT can
be increased

LRPSIZE

Size of the large request packets
(in bytes)

SRPCOUNT

Number of preallocated small request
packets

SRPCOUNTV

Maximum value to which SRPCOUNT can
be increased

QUANTUM

Maximum time a process can use at
once and minimum service a process
must receive before being outswapped,
(in lOms units)

MPW WRTCLUSTER

Number of pages written per I/O
from the modified page list

MPW HILIMIT

Maximum size of modified page list
(in pages)

MPW LOLIMIT

Minimum size of modified page list
(in pages)

MPW THRESH

Minimum size of the modified page
list requiring swapper action
(in pages)

MPW WAITLIMIT

Number of pages on the modified page
list that forces a process to wait
until the next time the modified page
writer writes the modified page list

PFRATL

Page fault rate low limit (in faults
per 10 seconds of processor time)

PFRATH

Page fault rate high limit (in faults
per 10 seconds of processor time)

WSINC

Working set increment (in pages)

WSDEC

Working set decrement (in pages)

AWSMIN

Automatic working set minimum (in
pages)

AWSTIME

Automatic working set time for
collecting sample (in lOrns units)

(continued on next page)

1 O-r;

SYSTEM PARAMETERS
Table 10-2 (Cont.):
Parameter Name

SYS Parameters
Dynamic

Description

MAJOR

SWPOUTPGCNT

Process size be~ore outswapping
occurs (in pages)

LONGWAIT

Time to elapse before a process
is judged idle by the swapper
(in 6.6ms units)

EXTRACPU

Extra CPU time added to process
after CPU time is expired (in lOms
uni ts)

MAXSYSGROUP

Highest system UIC

MVTIMEOUT

Amount of time allowed for a mount
verification attempt to succeed
before it is cancelled

MAXBUF

Maximum number of bytes that can be
transferred in one buffered I/O

DEFMBXBUFQUO

Default mailbox buffer quota (in
bytes)

DEFMBXMXMSG

Default mailbox maximum message
size (in bytes)

DEFMBXNUMMSG

Not implemented

FREEL IM

Lower limit of free page list (in
bytes)

FREEGOAL

Number of pages required on the free
page list after a memory shortage

GROWLIM

Number of pages required on the free
page list to allow process to exceed
working set quota

BORROW LIM

Minimum size of the free page
list before process can grow beyond
process working set quota (in pages)

XFMAXRATE

Maximum rate of transfer for DR32
devices

LAMAPREGS

Number of map registers allocated to
an LPAll device driver

REALTIME SPTS

Number of system page table entries
reserved for connect-to-interrupt
processes

CLISYMTBL

Size of command interpreter symbol
table (in pages)

LOCKIDTBL

Number of entries in the system lock
id table

(continued on next page)

10-6

SYSTEM PARAMETERS
Table 10-2 (Cont.):
Parameter Name

SYS Parameters

Description

Dynamic

RESHASHTBL

Number of entries in the lock
management resource name hash table

DEADLOCK WAIT

Time that a lock request waits
before deadlock search is
init~ated (in seconds)

TIMEPROMPTWAIT

Time allowed for entry of the system
time during a boot (in microfo rtn ights)

LOGSHASHTBL

Number of entries in the system
logical name hash table

LOGGHASHTBL

Number of entries in the group
logical name hash table

LOGPHASHTBL

Number of entries in the process
logical name hash table

BUGREBOOT

Automatic reboot on fatal bugcheck;
switch

CRDENABLE

Detection and logging of memorycorrected read errors; switch

DUMPBUG

Writing of dump file on fatal
bugcheck; switch

BUGCHECKFATAL

All bugchecks fatal; switch

SETTIME

Time-of-day prompt at boot time; switch

UAFALTERNATE

Use of alternate UAF; switch

MOUNTMSG

Controls OPCOM handling of volume
mount messages; switch

DISMOUMSG

Controls OPCOM handling of volume
dismount messages; switch

DEF PR I

Sets the base default priority for
processes

Table 10-3:
Parameter Name

TTY Parameters

Description

Dynamic

TTY SCANDELTA

Terminal dial-up/hang-up scan
interval (in increments of lOOns)

TTY DIALTYPE
-

Dialup flag bits

TTY SPEED
-

Default speed for terminals; code

MAJOR

(continued on next page)

SYSTEM PARAMETERS
Table 10-3 (Cont.):
Parameter Name

TTY Parameters

Description

TTY RSPEED

Receive speed for terminals

TTY PARITY

Not implemented

TTY BUF

Default line width for termin~l

TTY DEFCHAR

Default terminal characteristics,
longword 1

TTY DEFCHAR2

Default terminal characteristics,
longword 2

TTY TYPAHDSZ

Size of terminal type-ahead
buffer (in bytes)

TTY ALTYPAHD

Size of alternate type-ahead
buffer {in bytes)·

TTY ALTALARM

Size of alternate type-ahead
buffer alarm (in bytes)

TTY DMASIZE

Minimum number of output buffer
characters to invoke OMA transfers

TTY PROT

Terminal protection against
allocation by another process; mask

TTY OWNER

Owner UIC for TTY_PROT specification

TTY CLASSNAME

Terminal class driver name prefix for
booting

TTY SILOTIME

Input silo polling interval for DMF-32
hardware (in milliseconds)
Table 10-4:

Parameter Name

Dynamic

JOB Parameters

Description

Dynamic

JOBQUEUES

Print or batch queue utilization;
switch

REINITQUE

Reinitialization of queue file;
switch

MAXPR INTS YMB

Maximum number of print symbionts

DEF PR I

Default priority

I JOB LIM

Not implemented

BJOBLIM

Not implemented

NJOBLIM

Not implemented

RJOBLIM

Maximum number of remote terminals

SYSTEM PARAMETERS
Table 10-5:
Parameter Name

ACP Param.eters
Dynamic

Description

ACP MULTIPLE

One ACP per disk volume mounted
on different device types; switch

ACP SHARE

Sharing of ACP code; switch

ACP MAPCACHE

Size of bit map cache (in pages)

ACP HDRCACHE

Size of file header cache (in
pages)

ACP DIRCACHE

Size of directory cache (in pages)

ACP WORKSET

Working set default for ACP

ACP FIDCACHE

Size of file identification
cache (in pages)

ACP EXTCACHE

Size of extent cache {in pages)

ACP EXTLIMIT

Ma~imum

amount of free space in
extent cache (in tenths of a percent
of available free space}

ACP_QUOCACHE

Number of entries in quota cache

ACP SYSACC

Size of directory access cache
{in pages)

ACP MAXREAD

Maximum directory blocks to read
(in blocks)

ACP WINDOW

Default number of window pointers

ACP WRITEBACK

Caching of file headers; switch

ACP DATACHECK

Data verification on ACP I/O

ACP BASEPRIO

Base priority for ACP processes

ACP SWAPFLGS

Swapping of ACP working sets;
code

Table 10-6:
Parameter Name

RMS Parameters
Dynamic

Description

RMS DFMBC

Default multiblock count

RMS DFMBFSDK

Default multibuffer count for
sequential disk operations

RMS DFMBFSMT

Default multibuffer count for
magnetic tape operations

(continued on next page)

SYSTEM PARAMETERS

Table 10-6 (Cont.):
Parameter Name

RMS Parameters
Dynamic

Description

RMS DFMBFSUR

Not implemented

RMS DFMBFREL

Default multibuffer count for
relative disk operations

RMS DFMBFIDX

Default multibuffer count for
indexed sequential disk operations

RMS DFMBFHSH

Not implemented

RMS PROLOGUE

Default file structure level for
VAX-11 RMS files; code

RMS EXTEND SIZE

Default file extend size (in
blocks)

RMS FILEPROT

Default file protection; mask
Table 10-7:

Parameter Name

PQL Parameters
Dynamic

Description

PQL_DASTLM

Default number of pending AS Ts

PQL_MASTLM

Minimum number of pending AS Ts

PQL DBIOLM

Default buffered I/O limit

PQL MBIOLM

Minimum buffered I/O limit

PQL_DBYTLM

Default buffered I/O byte limit

PQL_MBYTLM

Minimum buffered I/O byte limit

PQL_DCPULM

Default CPU time limit (in
increments of lOms)

PQL_MCPULM

Minimum CPU time limit (in
increments of lOms)

PQL_DDIOLM

Default direct I/O limit

PQL_MDIOLM

Minimum direct I/O limit

PQL_DFILLM

Default open file limit

PQL_MFILLM

Minimum open file limit

PQL_DPGFLQUOTA

Default paging file quota

PQL_MPGFLQUOTA

Minimum paging file quota

PQL DPRCLM

Default subprocess limit

D
(continued on next page)

, "-1"

SYSTEM PARAMETERS
Table 10-7 (Cont.):
Parameter Name

PQL Parameters
Dynamic

Description

PQL MPRCLM

Minimum subprocess limit

PQL_DTQELM

Default timer queue entries

PQL_MTQELM

Minimum timer queue entries

PQL_DWSDEFAULT

Default working set sizes

PQL_MWSDEFAULT

Minimum default working set size

PQL_DWSQUOTA

Default working set quota

PQL_MWSQUOTA

Minimum working set quota

PQL_DWSEXTENT

Default working set extent

PQL_MWSEXTENT

Minimum working set extent

PQL_DENQLM

Default number of locks queued
at one time

PQL_MENQLM

Minimum number of locks queued
at one time

Table 10-8:
Parameter Name

SCS Parameters
Dynamic

Description

SCSBUFFCNT

Not implemented

SCSCONNCNT

Maximum number of SCS connections
for System Applications

SCSRESPCNT

Maximum number of response descriptor
table entries for System Applications

SCSMAXDG

Maximum amount of application data
in one datagram (in bytes)

SCSMAXMSG

Maximum amount of application data
in one SCS message (in bytes)

SCSFLOWCUSH

Threshold value for notifying
the remote SCS of new receive
buffers

SCSSYSTEMID

Identifier of the system within a
cluster

PASTRETRY

Maximum number of times CI port
driver attempts start datagram
exchange

(continued on next page)

, n _, ,

SYSTEM PARAMETERS
Table 10-8 (Cont.):
Parameter Name

SCS Parameters

Description

Dynamic

PAST IM OUT

Time interval between CI port
driver wakeups for time-based
operations (in seconds)

PASTDGBUF

Maximum number of CI port driver
start handshakes in progress
simultaneously

PAPOLLINTERVAL

Time between CI port driver
polling activations {in seconds)

PAPOOLINTERVAL

Time between wakeups for CI
port driver message buffer allocation requests {in seconds)

UDABURSTRATE

Not implemented

10.2

PARAMETERS

The remaining sections of the chapter describe the parameters in more
detail and provide guidelines to help you decide whether or not to
consider modifying them. The parameters are presented in alphabetical
order for your convenience in referring to them.
Where the descriptions refer to the default value, they mean the value
of the parameter that is contained internally in the SYSGEN Utility as
the default value. The default values allow booting on any supported
VAX/VMS configuration.
(SYSGEN displays these default values under
the heading "default" when you issue the SYSGEN command SHOW for one
of the parameter categories. Also, these are the parameter values you
can establish with the SYSGEN command USE DEFAULT.)
Where the descriptions refer to the computed, installed value, they
mean the value derived by the AUTOGEN commmand procedure. These
values are appropriate for booting on the specific configuration that
initiated the AUTOGEN procedure.

10.2.1

ACP BASEPRIO Parameter

ACP BASEPRIO sets the base priority for all ACPs. The DCL command SET
PROCESS/PRIORITY
can be used to reset the base priorities of
ind iv id ua 1 AC PS •
Normally the default value is adequate.

10.2.2

ACP DATACHECK Parameter

ACP DATACHECK enables verification of reading and/or writing of file
structure data
(for example, directories and file headers):
a
specification of 3 means read and write checks; 2 means write check
only;
1 means read check only; 0 means no checks. On a read check,
the ACP information is read twice and compared. On a write check, the
ACP information is written, then read and compared.
10-12

SYSTEM PARAMETERS
10.2.3

ACP DIRCACHE Parameter

ACP DIRCACHE sets the number of pages for caching directory blocks.
Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the computed; installed value is adequate.

10.2.4

ACP EXTCACHE Parameter

ACP EXTCACHE sets the number of entries in the extent cache.
Each
entry points to one contiguous area of free space ,on disk. A
specification of 0 means no cache.
Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the default value is adequate.

10.2.s

ACP EXTLIMIT Parameter

ACP EXTLIMIT specifies the maximum amount of free space to which the
extent cache can point, expressed in thousandths of the currently
available free blocks on the disk.
For example,
if available free
space on the disk is 20,000 blocks, a specification of 10 limits the
extent cache to 200 blocks. This parameter's purpose is to limit the
amount of free space that might be lost in the event of a system
failure.
However, lost free space on a volume is normally recovered
at mount time.
Normally the default value is adequate.

10.2.6

ACP FIDCACHE Parameter

ACP FIDCACHE sets the number of file identification slots
specification of 1 means no cache.

cached.

Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the default value is adequate.

10.2.7

ACP HDRCACHE Parameter

ACP HDRCACHE sets the number of pages for caching file header blocks.
Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the computed, installed value is adequate.

SYSTEM PARAMETERS
10.2.8

ACP MAPCACHE Parameter

ACP MAPCACHE sets the number of pages for caching bit map blocks.
Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the computed, installed value is adequate.

10.2.9

ACP MAXREAD Parameter

ACP MAXREAD sets the maximum number of directory blocks read
I/0-operation. This parameter does not affect user file I/O.

one

Normally the default value is adequate.

10.2.10

ACP MULTIPLE Parameter

ACP MULTIPLE enables or disables the default creation of a separate
disk ACP process for each volume mounted on a different device type.
Performance on larger disks is better enhanced by increasing cache
sizes than by adding another ACP.
The parameter can be overridden on
an individual-volume basis with the DCL command MOUNT.

10.2.11

ACP_QUOCACHE Parameter

ACP QUOCACHE sets the number of
specification of O means no cache.

quota

file

entries

cached.

Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the computed, installed value is adequate.

10.2.12

ACP SHARE Parameter

ACP SHARE enables or disables the creation of a global section for the
first ACP used, so that succeeding ACPs may share its code. This
parameter should be set off (0) when ACP MULTIPLE is off.

10.2.13

ACP SWAPFLGS Parameter

ACP SWAPFLGS enables or disables swapping for
through the value of a four-bit number:
Bit

0
1
2
3

four

classes

ACPs

Class of ACP
Disks mounted by MOUNT/SYSTEM
Disks mounted by MOUNT/GROUP
Private disks
Magnetic tape ACP

If the value of the bit is 1, the corresponding class of ACPs can be
swapped.
The value of decimal 15
(hexadecimal F -- all bits on)

1n_1 ,..

SYSTEM PARAMETERS
enables swapping for all classes of ACP.
A value of decimal 14
disables swapping for ACPs for volumes mounted with the /SYSTEM
qualifier, but leaves swapping enabled for all other ACPs.

10.2.14

ACP SYSACC Parameter

ACP SYSACC sets the number of directory file control blocks
(FCBs)
that will be cached for disks mounted with the /SYSTEM qualifier.
Each directory FCB contains a 16-byte array containing the first
letter of the last entry in each block of the directory (or group of
blocks if the directory exceeds 16 blocks).
Since entries in a
directory are alphabetical, the cached FCB provides quick access to a
required directory block. This parameter value should be roughly
equivalent
to the number of directories that will be in use
concurrently on each system volume.
It may be overridden on a
per-volume basis with the /ACCESSED qualifier to the DCL command
MOUNT.
The value should be kept low in systems with small physical
memory, as the FCBs require a significant amount of space in the
nonpaged dynamic pool.
Too small a value causes excessive ACP I/O operations, while too large
a value causes excessive physical memory to be consumed by the ACP.
Normally the computed, installed value is adequate.

10.2.15

ACP WINDOW Parameter

ACP WINDOW sets the default number of window pointers to be allocated
in a window for a default file access, for disks mounted with the
/SYSTEM qualifier.
Normally the default value is adequate.

10.2.16

ACP WORKSET Parameter

ACP WORKSET sets the default size of a working set
value of 0 permits the ACP to calculate the size.

for

ACP.

Too small a value causes excessive ACP paging, while too large a value
causes excessive physical memory to be consumed by the ACP.
This
value should be nonzero only on small systems where memory is tight.

10.2.17

ACP WRITEBACK Parameter

ACP WRITEBACK enables the deferred writing of file headers.
A
specification of O causes all modifications of file headers to be
written to disk immediately.

10.2.18

AWSMIN Parameter

AWSMIN establishes the lowest number of pages to which a working
limit can be decreased by automatic working set adjustment.
Normally the default value is adequate.

10-15

set

SYSTEM PARAMETERS
10.2.19

AWSTIME Parameter

AWSTIME specifies the minimum amount of processor time that must
elapse for the system to collect a significant sample of a working
set's page fault rate.
The time is expressed in units of 10
milliseconds.
The
default value of 20, for example,
is 200
milliseconds.

10.2.20

BALSETCNT Parameter

BALSETCNT sets the number of balance set slots in the system page
table.
Each memory-resident working set requires one balance set
slot. Each balance set slot requires 4 bytes of permanently resident
memory per 128 virtual pages (as specified in the VIRTUALPAGECNT
parameter).
You can monitor the active system with the DCL command SHOW MEMORY or
the MONITOR PROCESSES command of the Monitor Utility (see the VAX-11
Utilities Reference Manual) to determine the actual maximum number of
working sets in memory.
If this number is significantly lower than
the value of BALSETCNT, this parameter value may be lowered.
If all
balance set slots are being used, the value of BALSETCNT should be
raised.
BALSETCNT should never be set to a value higher than two less than
MAXPROCESSCNT.
If physical memory is a significant system constraint,
you should consider lowering this value even further.
However,
if
your
system runs with a number of processes nearly equal to
MAXPROCESSCNT, lowering BALSETCNT will force swapping to occur, which
can affect system performance.

10.2.21

BJOBLIM Parameter

BJOBLIM is not currently implemented.

10.2.22

BORROWLIM Parameter

BORROWLIM defines the minimum number of pages required on the free
page list before the system will permit process growth beyond the
working set quota (WSQUOTA) for the process.
This parameter should
always be greater than FREELIM.
With the system's use of automatic working set adjustment, via the
parameters WSINC, PFRATH, and AWSTIME, this parameter allows a process
to grow beyond the value set by the working set quota (WSQUOTA) to the
working set quota extent (WSEXTENT) on a system that has a substantial
memory on the free page list. Such growth attempts to alleviate heavy
page faulting.
To make use of this growth, you must also set the
user's WSEXTENT authorization quota to a larger number than the
WSQUOTA value.

10.2.23

BUGCHECKFATAL Parameter

BUGCHECKFATAL enables or disables the conversion of nonfatal bugchecks
into fatal bugchecks.
The system must be rebooted on a fatal
bugcheck. A nonfatal bugcheck only places an entry in the error log
and deletes the corresponding process.

10-16

SYSTEM PARAMETERS
This parameter should normally be off {0);
(1) when the executive is being debugged.

you should only set it

Normally the default value is adequate.

10.2.24

BUGREBOOT Parameter

BUGREBOOT enables or disables automatic rebooting of the system if a
fatal bugcheck occurs.
This parameter should normally be on {l) and
only off {O) when the executive is being debugged.

10.2.25

CLISYMTBL Parameter

CLISYMTBL sets the size of the command interpreter symbol table, which
controls the number of DCL or MCR symbols that can be created.
Normally the default value is adequate.

10.2.26

CRDENABLE Parameter

CRDENABLE
enables
or
disables
memory-corrected read data
(ECC)
normally be on (1).

10.2.27

detection
and
logging
of
errors.
This parameter should

DEADLOCK WAIT Parameter

DEADLOCK WAIT defines the number of seconds that a lock request must
wait before the system initiates a deadlock search on behalf of that
lock.
Setting DEADLOCK WAIT to O disables deadlock checking.
Setting
DEADLOCK WAIT to a value greater than 0 but still less than the
default setting provides faster detection of deadlocks, but requires
more CPU usage.
Normally the default value is adequate.

10.2.28

DEFMBXBUFQUO Parameter

DEFMBXBUFQUO sets the default for the mailbox buffer quota size
in
bytes when this value is not specified in a Create Mailbox ($CREMBX)
system service call.
Normally the default value is adequate.

10.2.29

DEFMBXMXMSG Parameter

DEFMBXMXMSG sets the default for the mailbox maximum message size in
bytes when this value is not specified in a Create Mailbox ($CREMBX}
system service call.
No,rmally the default value is adequate.

10-17

SYSTEM PARAMETERS
10.2.30

DEFMBXNUMMSG Parameter

DEFMBXNUMMSG is not currently implemented.

10.2.31

DEFPRI Parameter

DEF PR I sets the base default priority for processes .•
Normally the default value is adequate.

10.2.32

DISMOUMSG Parameter

DISMOUMSG controls whether or not the messages that log volume
dismounts appear on the operator's terminal and in the operator's log.
The default value of 0 disables the reporting of these messages.

10.2.33

DUMPBUG Parameter

DUMPBUG enables or disables the writing of error log buffers and
memory contents to SYS$SYSTEM:SYSDUMP.DMP when a fatal bugcheck
occurs. This parameter should be off (0) only when the executive is
being debugged.

10.2.34

EXTRACPU Parameter

EXTRACPU sets the time, in units of 10 milliseconds, allotted to each
of a process's exit handlers (for each access mode) after the process
times out (that is, reaches its CPU time limit).
Normally the default value is adequate.

10.2.35

FREEGOAL Parameter

FREEGOAL establishes the number of pages desired on the free page list
as the result of a system memory shortage. Memory shortages occur
when the system drops below the minimum number of pages required on
the free page list (FREELIM). The value of FREEGOAL must always be
greater than or equal to the value of FREELIM.
Normally the computed, installed value is adequate.

10.2.36

FREELIM Parameter

FREELIM sets the minimum number of pages that must be on the free page
list.
The system will write pages from the modified page list, swap
out working sets, or reduce the size of the working sets to maintain
the minimum count.
While the larger free page list generally means less paging I/O,
it
also means less space for the balance set, which tends to result in
more swapping I/O.
You can monitor the size of the free page list,

10-18

SYSTEM PARAMETERS
the amount of paging, and the amount of swapping with the MONITOR IO
command of the Monitor Utility (see the VAX-11 Utilities Reference
Manual) •
Normally the computed, installed value is adequate.

10.2.37

GBLPAGES Parameter

GBLPAGES sets the number of global page table entries allocated at
bootstrap time.
Each global section requires one global page table
entry per section page, plus two entries, with the total rounded up to
an even number.
Every 128 global page table entries add 4 bytes to
permanently resident memory in the form of a system page table entry.
The default value is more than adequate for the images normally
installed as shared in the system start-up command procedures. Once
the system is running and all global sections are created, you can
examine the actual requirements with the /GLOBAL option of the Install
Utility (see the VAX-11 Utilities Reference Manual)
and reduce the
value of GBLPAGES accordingly. However, the value of this parameter
should not be set too small, since the page table entries are not
expensive in terms of permanently resident memory.
If you plan to
install many user images as shared, or if user programs are likely to
create many global sections, you must increase the value of this
parameter.
Note that as you increase GBLPAGES beyond its default setting, you
must make an adjustment to SYSMWCNT.
For every 128 pages you add to
GBLPAGES, increase SYSMWCNT by 1.

10.2.38

GBLPAGFIL Parameter

GBLPAGFIL defines the maximum number of system-wide pages allowed for
global page-file sections, that is, scratch global sections that can
be used without being mapped to a file.
These global page-file
sections can be temporary, permanent, system, or group and are
allocated from the paging file specified in the system process header
(the paging file specified at boot time). Thus, when you allow pages
for global page-file sections, be sure to increase the size of the
paging file accordingly.
Global page-file sections are created with the Create and Map Section
($CRMPSC)
system service without an explicit disk file.
These
sections are used for the VAX-11 RMS global buffers required for
shared files.
Users of shared files are warned that global page-file
sections cause both global page table and the default system paging
file
(PAGEFILE.SYS)
to be used.
If the value of GBLPAGFIL is too
small, the $CRMPSC system service issues an error message when users
attempt to create global page-file sections.
You need scratch global sections if you use VAX-11 RMS global buffers.
Each file using global buffers requires approximately the following
number of pages in the system paging file:
the file's bucket size
multiplied by the number of global buffers for that file.
Normally the default value for this parameter is adequate for most
systems.
However, if your site uses VAX-11 RMS global buffering to a
significant extent, you will probably need to raise the value of
GBLPAGFIL.
Global buffers are normally enabled with the DCL command
SET FILE/GLOBAL BUFFERS, which is described in the VAX/VMS Command
Language User's-Guide.

SYSTEM PARAMETERS
You can list the global sections with the /GLOBAL qualifier of the
Install Utility.
The sections used by VAX-11 RMS for global buffers
all begin with the prefix RMS$ followed by eight hexadecimal digits
representing the longword address.

10.2.39

GBLSECTIONS Parameter

GBLSECTIONS sets the number of global section descriptors allocated in
the system header at bootstrap time. Each global section requires one
descriptor. Each descriptor takes 32 bytes of permanently resident
memory.
The default value is more than adequate for the images normally
installed as shared in the system start-up command procedures. You
can, once the system is running and all global sections are created,
examine the actual requirements with the /GLOBAL option of the Install
Utility (see the VAX-11 Utilities Reference Manual)
and reduce the
value
of GBLSECTIONS accordingly.
However, the value of this
parameter should not be cut too closely -- each descriptor requires
only 32 bytes. If you plan to install many user images as shared or
if user programs are likely to create many global sections, you must
increase the value of this parameter.
If the value of GBLSECTIONS is too small, you receive a message from
the Install Utility at system start-up time or whenever you install
images manually. On the other hand, too large a value for GBLSECTIONS
wastes physical memory.

10.2.40

GROWLIM Parameter

GROWLIM sets the number of pages that the system must have on the free
page list so that a process can add a page to its working set when it
is above quota. GROWLIM has no effect if the process is below its
working set quota. The effect of GROWLIM is to act as a fast shutoff
to the working set extent mechanism based on the system's free memory.

10.2.41

IJOBLIM Parameter

IJOBLIM is not currently implemented. You
number of concurrent interactive users
command SET LOGINS/INTERACTIVE.

10.2.42

can control the maximum
on the system with the DCL

INTSTKPAGES Parameter

INTSTKPAGES sets the size of the interrupt stack in pages. Each page
on the interrupt stack requires a page of permanently resident memory.
The default value of 2 should be used unless interrupt-stack-not-valid
exceptions occur.
These may be caused by either an unusually large
number of devices or a driver that requires a very large amount of
stack space.

10-20

SYSTEM PARAMETERS
10.2.43

IRPCOUNT Parameter

IRPCOUNT sets the number of preallocated intermediate request packets.
Each packet requires 160 bytes of permanently resident memory.
If
IRPCOUNT is too large, physical memory is wasted.
If IRPCOUNT is too
small, the system increases its value automatically, as needed, to
permit the system to perform properly.
However, the system cannot
increase IRPCOUNT beyond the value of IRPCOUNTV.
Furthermore, there
is a minor physical memory penalty for allowing this growth.
If
IRPCOUNT is underconfigured, the penalty is 4 percent of physical
memory from the configured value to the actual value on the running
system. ,
You can use the
IRPCOUNT usage.

10.2.44

DCL

command

SHOW MEMORY/POOL/FULL

determine

IRPCOUNT

can

IRPCOUNTV Parameter

IRPCOUNTV establishes the upper limit
automatically increased by the system.

which

If this parameter is set too low, system performance can be adversely
affected by preventing the system from using this memory allocation
mechanism for nonpaged pool requests. There is a penalty of 1 percent
of physical memory for any unused growth space (one longword for every
three unused intermediate request packets).
Normally the computed, installed value is appropriate.

10.2.45

JOBQUEUES Parameter

JOBQUEUES determines whether or not print or batch queues can be
defined or used. When JOBQUEUES is set to O, no batch or print queues
can be defined or used. Thus, users with a system UIC would be able
to check for the existence of the file SYS$SYSTEM:JBCSYSQUE.EXE and
delete it, if desired, to save space.

10.2.46

KFILSTCNT Parameter

KFILSCNT sets the number of known file list heads. Each active list
head requires 68 bytes of permanently resident memory. Each extra,
never-used list head requires 4 bytes. The actual known file entries
are allocated from the paged dynamic pool.
One known file head is required for each set of installed images with
a different combination of device name, directory name, and file type.
(See Chapter 6.)
Normally the default value is adequate.

10.2.47

LAMAPREGS Parameter

LAMAPREGS sets the number of UNIBUS map registers allocated to an
LPAll driver when the driver is loaded, and limits the registers for
the driver to that number. A value of 0 permits dynamic allocation of
an unlimited number of registers.

10-21

SYSTEM PARAMETERS
10.2.48

LOCKIDTBL Parameter

LOCKIDTBL establishes the number of entries in the system lock id
table, which limits the number of locks in the system. There must be
one entry for each lock in the system;
each entry requires four
bytes. For simple timesharing systems, the default value is adequate.
However, if your application uses many locks, as in the case of heavy
VAX-11 RMS file sharing or a data base management application, you
should increase this parameter.
(Whenever you change the value of
LOCKIDTBL, you should examine the value of RESHASHTBL and change it,
if necessary.)
The VAX/VMS Lock Management facility is described in the chapter, Lock
Management Services, in the VAX/VMS System Services Reference Manual.
You can monitor locks with the MONITOR LOCK command of the Monitor
Utility, as described in the VAX-11 Utilities Reference Manual.
If you set this parameter value too
following error message:

low,

programs

can

receive

the

%SYSTEM-E-NOLOCKID, no lock id. available

10.2.49

LOGGHASHTBL Parameter

LOGGHASHTBL sets the size of the group logical name hash table.
Logical names are hashed using a function of the name length and
contents. The LOGGHASHTBL parameter determines the number of entries
in the group logical name hash table. The recommended setting is the
average number of group logical names that will be in the table.
Normally the default value is adequate.

10.2.50

LOGPHASHTBL Parameter

LOGPHASHTBL sets the size of the process logical name hash table.
Logical names are hashed using a function of the name length and
contents. The LOGPHASHTBL parameter determines the number of entries
in the process logical name hash table. The recommended setting is
the average number of process logical names that will be in the table.
Normally the default value is adequate.

10.2.51

LOGSHASHTBL Parameter

LOGSHASHTBL sets the size of the system logical name hash table.
Logical names are hashed using a function of the name length and
contents. The LOGSHASHTBL parameter determines the number of entries
in the system logical name hash table. The recommended setting is the
average number of system logical names that will be in the table.
Normally the default value is adequate.

10.2.52

LONGWAIT Parameter

LONGWAIT defines how much real time must elapse before the swapper
considers a process to be temporarily idle. This parameter is applied

10-22

SYSTEM PARAMETERS
to local event flag (LEF) and hibernate (HIB)
conditions as an inactive terminal or ACP.

waits

detect

such

Normally the default value is adequate.

10.2.53

LRPCOUNT Parameter

LRPCOUNT sets the number of preallocated large request packets.
Each
packet requires an amount of permanently resident memory that is equal
to the number of bytes specified by the LRPSIZE parameter.
(Normally
LRPSIZE is 576 bytes.)
If LRPCOUNT is too large, physical memory is
wasted.
If LRPCOUNT is too small, the system increases its value
automatically, as needed, to permit the system to perform properly.
However, the system cannot increase LRPCOUNT beyond the value of
LRPCOUNTV.
If LRPCOUNT is underconfigured, the penalty is 4 percent
of physical memory from the configured value to the actual value on
the running system.
You can use the
LRPCOUNT usage.

10.2.54

DCL

command

SHOW MEMORY/POOL/FULL

determine

LRPCOUNT

can

LRPCOUNTV Parameter

LRPCOUNTV establishes the upper limit
automatically increased by the system.

which

If this parameter is set too low, system performance can be adversely
affected by preventing the system from using this memory allocation
mechanism for nonpaged pool requests.
There is a penalty of 1 percent
of physical memory for any unused growth space (approximately one
longword for every unused large request packet).
Normally the computed, installed value is appropriate.

10.2.55

LRPSIZE Parameter

The
LRPSIZE is the size (in bytes) of the large request packets.
actual
physical memory consumed by a large request packet is
LRPSIZE + 64 bytes.
Normally the default value is adequate. However, for VAX-11 DECnet
use, this parameter should be the same as the DECnet buffer size.

10.2.56

MAXBUF Parameter

MAXBUF sets the maximum size of a buffered I/O transfer (card readers,
console floppy diskettes,
line printers, mailboxes, and terminals).
The space for a buffered I/O operation is allocated from the
permanently resident nonpaged dynamic pool. Note that the system adds
from 16 to 64 bytes (depending on the device driver and the nature of
the
I/O)
to a buffer at allocation time for header information, so
that the largest size transfer possible is reduced by this amount.

SYSTEM PARAMETERS
10.2.57

MAXPRINTSYMB Parameter

MAXPRINTSYMB sets the maximum number of print symbionts that can be
created.
{However, the maximum number of print symbionts is further
restricted by the value of.the PQL DPRCLM parameter
the default
process creation limit.}
-

l0.2.58

MAXPRQCESSCNT Parameter

MAXPROCESSCNT sets the number of process entry slots allocated ~t
bootstrap time.
One slot is required for each concurrent process on
the system.
Each slot requires six bytes of permanently resident
memory.
The default value is normally generously configured to allow you to
create the desired number of processes. If the following message
appears, you may need to adjust MAXPROCESSCNT:
%SYSTEM-F~NOSLOT,

No PCB or swap slot to create process

This message can also be produced if the swapping file is full.
Use
the DCL command SHOW MEMORY to determine which limit is being reached.

10.2.59

MAXSYSGROUP Parameter

MAXSYSGROUP sets the highest value that a group number can have and
still be classified as a system UIC group number. Note that the
specification is not in octal unless preceded by the %0 radix
indicator. This parameter is normally left at 8 {10 octal}.

10.2.60

MINWSCNT Parameter

MINWSCNT sets the minimum number of fluid pages -- that is, pages not
locked in the working set -- required for the execution of a process.
This value plus the size of the process header establishes the minimum
working set size.
The value of MINWSCNT must provide sufficient space to execute any
VAX-11
instruction.
Theoretically,
the worst-case instruction
requires 52 pages; however, all VAX/VMS code can run with 20 fluid
pages.
An insufficient value may inhibit system performance or even
put a process into an infinite loop on some instructions.

10.2.61

MOUNTMSG Parameter

MOUNTMSG controls whether or not the messages that log volume mounts
appear on the operator's terminal and in the operator's log. The
default value of 0 disables the reporting of these messages.
(This
parameter does not control the messages generated by mount assistance
requests.}

10.2.62

MPW HILIMIT Parameter

MPW HILIMIT sets an upper limit for the modified page list. When the
list accumulates the number of pages specified by this limit, writing

SYSTEM PARAMETERS
of the list begins.
(The pages that are written are then
to the tree page list.)

transferred

If MPW_HILIMIT is too low, excessive page faulting can occur from the
paging tile.
If it is too high, too many physical pages can be
consumed by the modified page list.
If you increase MPW_HILIMIT, you may also
need
to
increase
MPW WAITLIMIT. Note that if MPW WAITLIMIT is less than MPW HILIMIT, a
system deadlock will occur. The value for MPW HILIMIT is normally
equal to the value of MPW_WAITLIMIT.
Normally the default value is adequate.

10.2.63

MPW LOLIMIT Parameter

MPW LOLIMIT sets a lower limit for the modified page list.
When
writing of the list causes the number of pages on the list to drop to
or below this limit, writing stops.
MPW LOLIMIT ensures that a certain number of pages will be available
on -the modified page list for page faults.
If it is too small, the
caching effectiveness of the modified page list is reduced.
If it is
too high, less memory is available for processes, so that swapping
(and paging) may increase.
Normally the default value is adequate.

10.2.64

MPW THRESH Parameter

MPW THRESH sets a lower bound of pages that must exist on the modified
page list before the swapper writes this list to acquire free pages.
If this requirement is met, the swapper will try to write the modified
page list rather than take pages away from or swap out a process.
Normally the default value is adequate.

10.2.65

MPW WAITLIMIT Parameter

MPW WAITLIMIT sets the number of pages on the modified page list that
will cause a process to wait until the next time the modified page
writer writes the modified list. This acts to limit the rate at which
any single process can produce modified pages.
If this value is less
than MPW HILIMIT, a system deadlock will occur. The value for this
parameter is normally/equal to MPW HILIMIT.

10.2.66

MPW WRTCLUSTER Parameter

MPW WRTCLUSTER sets the number of pages to be written from the
modified page list during on~ I/O operation to the paging file or a
section file.
(The actual size of the cluster may be limited by the
number of pages available for the I/O operation.) This parameter can
range in value from 16 to 120, in multiples of eight.
Each page in
the cluster requires 6 bytes of permanently resident memory.
If

, 0-? i;

SYSTEM PARAMETERS
MPW WRTCLUSTER is too small, it will take many I/O operations to empty
the- modified page list.
If MPW WRTCLUSTER is too large for the speed
of the disk that holds the page file, other I/O operations will be
held up for the modified page list write.
Normally the default value is adequate.

10.2.67

MVTIMEOUT Parameter

MVTIMEOUT is the time in seconds that a mount verification attempt
will continue on a given disk volume.
If the mount verification does
not recover the volume within that time, the
I/O
operations
outstanding to the volume will terminate abnormally.

10.2.68

NJOBLIM Parameter

NJOBLIM is not currently implemented.

10.2.69

NPAGEDYN Parameter

NPAGEDYN sets the size of the nonpaged dynamic pool
in bytes.
This
figure
is rounded down to an integral number of pages. NPAGEDYN
establishes the initial setting of the nonpaged pool size, but the
pool size can be increased dynamically.
Probably the simplest and best approach to take in setting a value for
this parameter is to initially use the default value, then monitor the
amount
of
space
actually
used
with
the
DCL
command
SHOW MEMORY/POOL/FULL.
There is a minor physical memory penalty for allowing this growth.
If
NPAGEDYN is underconfigured, the penalty is 4 percent of physical
memory from the configured value to the actual value on the running
system. You can decrease the value if much space is being wasted, and
you should increase it if little space is unused.

10.2.70

NPAGEVIR Parameter

NPAGEVIR defines the maximum size to which NPAGEDYN can be increased.
If this value is too small, the system could hang.
If NPAGEVIR is too
large, there is a penalty of 1 percent of physical memory for any
unused growth space (one longword for for each 512 bytes of difference
between the system's actual usage of nonpaged pool and the value of
NPAGEVIR).

10.2.71

PAGEDYN Parameter

PAGEDYN sets the size of the paged dynamic
specified value is rounded down to an integral
512 bytes of paged dynamic pool adds four
resident memory to the system page table; the
no other direct memory requirements.

pool
in bytes.
The
number of pages. Each
bytes of permanently
paged dynamic pool has

The paged dynamic pool is used to allocate storage for system and
group logical names, resident image headers, known file list entries,

10-26

'SYSTEM PARAMETERS
and VAX-11 RMS file sharing structures. Substantial amounts of space
for the pool can be overallocated with little effect on system
performance.
The size of the paged pool can grow dynamically up to the maximum size
this parameter specifies.
Normally the default value is adequate.

10.2.72

PAGFILCNT Parameter

PAGFILCNT defines the maximum number
installed.

10.2.73

paging

files

that

can

PAPOLLINTERVAL Parameter

PAPOLLINTERVAL is the number of seconds between polling activity for
the
computer
interconnect port driver.
Each time the poller
activates, it sends Request IDs to all possible remote ports.
If no computer interconnect device is configured on your system,
parameter is ignored.

this

The default value should always be adequate.

10.2.74

PAPOOLINTERVAL Parameter

PAPOOLINTERVAL is the interval in seconds after which a CI port
driver's suspended request for message buffer allocation from nonpaged
pool is awakened to repeat the request.
If no computer interconnect (CI) device or UDA 50/52 is configured
your system, this parameter is ignored.

The default value should always be adequate.

10.2.75

PASTDGBUF Parameter

PASTDGBUF is the number of datagram receive buffers to queue for the
CI port driver's configuration poller; that is, the maximum number of
start handshakes that can be in progress simultaneously.
If no computer interconnect device is configured on your system,
parameter is ignored.

this

Normally the default value is adequate.

10.2.76

PASTIMOUT Parameter

PASTIMOUT is the basic interval at which the CI port driver wakes up
to perform time-based bookkeeping operations.
It is also the period
after which a start handshake datagram is assumed to have timed out.
Note that the product obtained by multiplying the values of PASTRETRY
and PASTIMOUT must be greater than, or equal to, the value of
PAPOLLINTERVAL.

10-?.7

SYSTEM PARAMETERS
If no computer interconnect device is configured 9n your
parameter is ignored.
The

d~fault

10.2.77

syst~m,

this

vglue should always be adequate.

PASTRETRY Parameter

PASTRETRY is the number of times that the CI port driver's cluster
configuration poller will attempt to exchange start datagrams with a
newly enabled port without receiving a response, before it gives up on
the remote system. Note that the product obtained by multiplying the
values of PASTRETRY and PASTIMOUT must be greater than, or equal to,
the value of PAPOLLINTERVAL.
If no computer interconnect device is configured on your system,
parameter is ignored.

this

The default values should always be adequate.

10.2.78

PFCDEFAULT Parameter

During execution of programs, PFCDEFAULT controls the number of image
pages read from disk per I/O operation when a page fault occurs. The
read I/O operations can take place from an image file or from the
paging file.
The actual size of the cluster can be less than
PFCDEFAULT, depending on the size of image sections and the pattern of
page references.
The value of this parameter should not be less than 16 to ensure
adequate I/O performance, nor greater than one-fourth the default size
of the average working set to prevent a single page fault from
displacing a major portion of a working set. Too large a value for
PFCDEFAULT can hurt system performance. PFCDEFAULT can be overridden
<in an image-by-image basis with the CLUSTER option of the VAX-11
Linker.
Normally the default value is adequate.

10.2.79

PFRATH Parameter

PFRATH specifies the page fault rate above which the limit of a
working set will be automatically increased. The unit of measure is
faults per 10 seconds of processor time. At a setting of 120, for
example, the system will automatically increase the limit of a working
set if it is faulting more than 120 pages per 10 seconds.
Decreasing the value of this parameter tends to increase the limits of
the working sets, while increasing its value tends to decrease their
limits.

10.2.80

PFRATL Parameter

PFRATL specifies the page fault rate below which the limit of a
working set is automatically decreased. The unit of measure is faults
per 10 seconds of processor time. At a setting of 1, for example, the
system automatically decreases the limit of a working set if it is
faulting less than 1 page every 10 seconds.

10-28

SYSTEM PARAMETERS
Increasing the value of this parameter tends to decrease the limits of
the working sets, while decreasing its value tends to incre~se their
limits.

10.2.81

PQL_DASTLM Parameter

PQL_DASTLM sets the default limit on the nurn.ber of pending Asrs for a
process created by the Create Process ($CREPRC) system service or the
DCL command RUN (Process) •
Normally the default value is adequate.

10.2.82

PQL_DBIOLM Parameter

PQL DBIOLM sets the default buffered I/O count limit for the number of
outstanding buffered I/O operations permitted to a process created by
the Create Process ($CREPRC) system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

10.2.83

PQL_DBYTLM Parameter

PQL DBYTLM sets the default buffered I/O byte count limit for the
amount of buffered space available to a process created by the Create
Process {$CREPRC) system service or the DCL command RUN (Process).
Normally the default value is adequate.

10.2.84

PQL_DCPULM Parameter

PQL DCPULM sets the default CPU time limit for a process created by
the- Create Process
($CREPRC)
system service or the DCL command RUN
(Process). PQL DCPULM specifies the time limit in increments of 10
milliseconds. The default value of 0 imposes no limit on CPU
typically the correct value for this parameter.

10.2.85

time

usage

and

PQL_DDIOLM Parameter

PQL DDIOLM sets the default direct I/O limit for a process created by
the- Create Process ($CREPRC)
system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

10.2.86

PQL_DENQLM Parameter

PQL DENQLM sets the default enqueue limit for a process created by the
Create Process
($CREPRC)
system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

SYSTEM PARAMETERS
10.2.87

PQL_DFILLM Parameter

PQL DFILLM sets the default open file limit for a process created by
the- Create Process
($CREPRC)
system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

10.2.88

PQL_DPGFLQUOTA Parameter

PQL DPGFLQUOTA sets the default paging file quota for a process
created by the Create Process
($CREPRC) system service or the DCL
command RUN (Process).
Normally the default value is adequate.

10.2.89

PQL_DPRCLM Parameter

PQL DPRCLM sets the default subprocess limit for a process created by
the- Create Process
($CREPRC)
system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

10.2.90

PQL_DTQELM Parameter

PQL DTQELM sets the default number of timer queue entries for a
process created by the Create Process ($CREPRC) system service or the
DCL command RUN {Process) •
Normally the default value is adequate.

10.2.91

PQL_DWSDEFAULT Parameter

PQL DWSDEFAULT sets the default working set size for a process created
by -the Create Process {$CREPRC) system service or the DCL command RUN
{Process).
Normally the default value is adequate.

10.2.92

PQL_DWSEXTENT

the default working set extent for a process created by the Create
Process ($CREPRC) system service or the DCL command RUN (Process).
Normally the default value is adequate.

10.2.93

PQL_DWSQUOTA Parameter

PQL DWSQUOTA sets the default working set quota for a process created
by -the Create Process ($CREPRC) system service or the DCL command RUN
{Process) •
Normally the default value is adequate.
10-10

SYSTEM PARAMETERS
10.2.94

PQL_MASTLM Parameter

PQL MASTLM sets a default limit on the m1n1mum number of pending ASTs
for- a process created by the Create Process ($CREPRC) system service
or the DCL command RUN (Process) •
Normally the default value is adequate.

10.2.95

PQL_MBIOLM Parameter

PQL MBIOLM sets the minimum buffered I/O limit for a process created
by -the Create Process ($CREPRC) system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

10.2.96

PQL_MBYTLM Parameter

PQL MBYTLM sets the minimum buffered I/O byte limit for a process
created by the Create Process
($CREPRC) system service or the DCL
command RUN (Process).
Normally the default value is adequate.

10.2.97

PQL_MCPULM Parameter

PQL MCPULM sets the minimum CPU time limit in increments of 10
milliseconds for a process created by the Create Process ($CREPRC)
system service or the DCL command RUN (Process) •
Normally the default value is adequate.

10.2.98

PQL_MDIOLM Parameter

PQL MDIOLM sets the minimum direct I/O limit for a process created by
the- Create Process
($CREPRC)
system service or the DCL command RUN
(Process) •
Normally the default value is adequate.

10.2.99

PQL_MENQLM Parameter

PQL MENQLM sets the default limit on the minimum number of locks that
can- be queued at one time by a process created by the Create Process
($CREPRC) system service or the DCL command RUN (Process).
Normally the default value is adequate.

10-31

SYSTEM PARAMETERS
10.2.100

PQL_MFILLM Parameter

PQL MFILLM,sets the minimum open file limit for a process created by
the- Create Process
($CREPRC}
system service or the DCL command RUN
(Process} •
Normally the default value is adequate.

10.2.101

PQL_MPGFLQUOTA Parameter

PQL MPGFLQUOTA sets the minimum paging file quota for a process
created by the Create Process
($CREPRC) system service or the DCL
command RUN (Process).
Normally the default value is adequate.

10.2.102

PQL_MPRCLM Parameter

PQL MPRCLM sets the minimum subprocess limit for a process created by
the- Create Process
($CREPRC)
system service or the DCL command RUN
(Process} •
Normally the default value is adequate.

10.2.103

PQL_MTQELM Parameter

PQL MTQELM sets the minimum number of timer queue entries for a
process created by the Create Process ($CREPRC) system service or the
DCL command RUN (Process) •
Normally the default value is adequate.

10.2.104

PQL_MWSDEFAULT Parameter

PQL MWSDEFAULT sets the minimum default working set size for a process
created by the Create Process
($CREPRC) system service or the DCL
command RUN (Process) •
Normally the default value is adequate.

10.2.105

PQL_MWSEXTENT Parameter

PQL MWSEXTENT sets the m1n1mum working set extent for a process
created by the Create Process
($CREPRC) system service or the DCL
command RUN (Process) •
Normally the default value is adequate.

10-32

SYSTEM PARAMETERS
10.2.106

PQL_MWSQUOTA Parameter

PQL MWSQUOTA sets the minimum working set quota for a process created
by -the Create Process ($CREPRC) system service or the DCL command RUN
(Process).
Normally the default value is adequate.

10.2.107

PROCSECTCNT Parameter

PROCSECTCNT sets the number of section descriptors that a process can
contain.
Each section descriptor increases the fixed portion of the
process header by 32 bytes.
You should set a value greater than the maximum number of image
sections in any section to be run, as indicated by the linkage memory
allocation map for the image.
Normally the default value is adequate.

10.2.108

QUANTUM Parameter

QUANTUM defines:
•

Processor time -- Maximum amount of processor time a process
can receive before control passes to another process of equal
priority that is ready to compute

•

Balance set residency
Minimum amount of
service
a
compute-state process must receive before being swapped out to
secondary storage

Normally the default value is adequate.

10.2.109

REALTIME SPTS Parameter

REALTIME SPTS reserves a number of system page table entries for
mapping -connect-to-interrupt processes into system space. This value
should normally remain at the default (0) in an environment that is
not real-time.
Where connect-to-interrupt processes do use the
system, this value should represent the maximum number of pages all
concurrent connect-to-interrupt processes must map into system space.
See the VAX/VMS Real-Time User's Guide for details.

10.2.110

REINITQUE Parameter

REINITQUE specifies whether or not the job controller should create a
new empty queue file.
Chapter 8 describes how to use this parameter
in the event a queue file becomes corrupted and must be cleared.
Setting the parameter to 1 indicates that you want the queue file
reinitialized to the empty state.

10-33

SYSTEM PARAMETERS
10.2.111

RESHASHTBL Parameter

RESHASHTBL defines the number of entries in the lock management
resource name hash table.
Each entry requires four bytes.
As a
general guideline, there should be one resource hash table entry for
every four locks in the system. Thus, RESHASHTBL should be one-fourth
the value of LOCKIDTBL, rounded up to the closest power of two.

10.2.112

RJOBLIM Parameter

RJOBLIM defines the maximum number of remote terminals allowed in the
system at any one time.
This parameter is sampled when REMACP is
started.

10.2.113

RMS DFMBC Parameter

RMS DFMBC defines the VAX-11 RMS multiblock count for sequentially
organized files.
This value defines the number of 512-byte blocks to
be transferred on each I/O operation.
Normally the default value is adequate.

10.2.114

RMS DFMBFHSH Parameter

RMS DFMBFHSH is not currently implemented.

10.2.115

RMS DFMBFIDX Parameter

RMS DFMBFIDX defines the default VAX-11 RMS multibuffer count for
indexed sequential disk operations. This value defines the number of
I/O buffers that VAX-11 RMS allocates for each indexed file.
For
sequential access, a larger number that allows some of the index
buckets to remain in memory can improve performance.

10.2.116

RMS DFMBFREL Parameter

RMS DFMBFREL defines the default VAX-11 RMS multibuffer count for
relative disk operations.
This value defines the number of I/O
buffers that VAX-11 RMS allocates for each relative file.
Normally the default value is adequate.

10.2.117

RMS DFMBFSDK Parameter

RMS DFMBFSDK defines the default VAX-11 RMS multibuffer count for
sequential disk operations.
This value defines the number of I/O
buffers that VAX-11 RMS allocates for sequential disk files.
Normally the default value is adequate.
write/behind operations are used, a
performance.

10-34

However,
if read/ahead or
improve
larger number will

SYSTEM PARAMETERS
10.2.118

RMS DFMBFSMT Parameter

RMS DFMBFSMT defines the default VAX-11 RMS multibuffer count for
magnetic tape operations.
This value defines the number of I/O
buffers that VAX-11 RMS allocates for magnetic tape files.
Normally the default value is adequate.

10.2.119

RMS DFMBFSUR Parameter

RMS DFMBFSUR is not currently implemented.

10.2.120

RMS EXTEND SIZE

RMS EXTEND SIZE specifies the number of blocks by which to extend
files as -they are written. This number should be chosen to balance
the amount of extra disk space wasted at the ends of each file versus
the
performance
improvement
provided by making large extends
infrequently. When small disk quotas are used, a small number such as
the disk cluster size should be specified to prevent the user's disk
quota from being consumed.
If the value of 0 is used, VAX-11 RMS will
allocate large extents and truncate the file back to its actual usage
when it closes.

10.2.121

RMS FILEPROT Parameter

RMS FILEPROT determines the initial default file protection of all
processes.
Thus,
it determines file protection for all users who do
not execute the DCL command SET PROTECTION/DEFAULT in their login
command
procedure
or later.
This parameter also affects the
protection of files created by system processes, such as those that
create the error log, the operator log, and others. The protection is
expressed as a mask (see Section 3.2 for more information on
specifying protection masks). By default, the mask is 64000 (decimal)
or FAOO (hexadecimal), which represents the following protection:
(S:RWED,O:RWED,G:RE,W:)

10.2.122

RMS PROLOGUE Parameter

RMS_PROLOGUE specifies the default prologue VAX-11 RMS uses to create
indexed files.
The default value 0 specifies that VAX-11 RMS should
determine the prologue based on characteristics of the file,
2
specifies Prologue 2 or Prologue l; and 3 specifies Prologue 3. The
VAX-11 RMS prologues are described in the VAX-11 Record Management
Services Reference Manual.

10.2.123

SCSBUFFCNT Parameter

SCSBUFFCNT is not currently implemented.

10-35

SYSTEM PARAMETERS
10.2.124

SCSCONNCNT Parameter

SCSCONNCNT is the total number of SCS connections that are configured
for use by all System Applications,
including the one used by
directory service listen.
If no computer interconnect device or UDA 50/52 is configured on
system, this parameter is ignored.
The default value is adequate for all
available with VAX/VMS Version 3.0.

10.2.125

CI/UDA

hardware

your

combinations

SCSFLOWCUSH Parameter

SCSFLOWCUSH is an SCS flow control parameter for sequenced messages.
For each connection, SCS tracks the number of receive buffers
available. SCS communicates the number of available receive buffers
to the SCS at the remote end of the connection. However, SCS does not
need to do this for each new receive buffer added.
Instead, SCS
notifies the remote SCS of new receive buffers if the number of
receive buffers already communicated to the remote SCS falls as low as
the value of SCSFLOWCUSH.
If no computer interconnect (CI) device is configured on your
this parameter is ignored.

system,

Normally the default value is adequate.

10.2.126

SCSMAXDG Parameter

SCSMAXDG is the maximum number
datagram.

bytes of

application

data

If no computer interconnect device is configured on your system,
parameter is ignored.
Normally the default value is adequate.
the LRPSIZE parameter.

10.2.127

It should equal the value

one
this
of

SCSMAXMSG Parameter

SCSMAXMSG is the maximum number of bytes of application
message.

data

If no computer interconnect device is configured on your system,
parameter is ignored.

one
this

Do not change the default value.

10.2.128

SCSRESPCNT Parameter

SCSRESPCNT is the total number of response descriptor
(RDTEs) configured for use by all System Applications.

table

entries

If no computer interconnect (CI) device or UDA 50/52 is configured
your system, this parameter is ignored.
Normally the default value is adequate.
10-36

SYSTEM PARAMETERS
10.2.129

SCSS~STEMID

Parameter

SCSSYSTEMID is the unique identifier of each system within a cluster.
It must be equal to the DECnet-VAX node number. For Version 3.0 of
VAX/VMS, this means that although the system identifier is stored as a
six-byte number, the user can specify only the low-order byte. The
high-order five bytes will be zero.
If no computer interconnect (CI) device or UDA 50/52 is configured
your system, this parameter is ignored.

10.2.130

SETTIME Parameter

SETTIME enables or disables solicitation of the time of day each time
the system is booted. This parameter should normally be off (0), so
that the system sets the time of day at boot time to the value of the
processor time-of-day register.
You can reset the time after the
system is up with the DCL command SET TIME (see the VAX/VMS Command
Language User's Guide).

10.2.131

SPTREQ Parameter

SPTREQ sets the number of system page table (SPT) entries required for
mapping the following components:
Component
Executive image
VAX-11 RMS image
SYSMSG.EXE file
Multiport memory structures
Each MASSBUS adapter
Each UNIBUS adapter
Each DR32 adapter
The number of system page table entries required for all other
purposes is automatically computed and added to the value of SPTREQ to
yield the actual size of the system page table.
Normally the default value is adequate.

10.2.132

SRPCOUNT Parameter

SRPCOUNT sets the number of preallocated small request packets.
Each
packet requires 96 bytes of permanently resident memory.
If SRPCOUNT
is too large, physical memory is wasted.
If SRPCOUNT is too small,
the system increases its value automatically, as needed, to permit the
system to perform properly.
However, the system cannot increase
SRPCOUNT beyond the value of SRPCOUNTV.
Furthermore, there is a minor
physical memory penalty for allowing this growth.
If SRPCOUNT is
underconfigured, the penalty is 4 percent of physical memory from the
configured value to the actual value on the running system.
You can use the
SRPCOUNT usage.

DCL

command

SHOW MEMORY/POOL/FULL

10~37

determine

SYSTEM PARAMETERS
10.2.133

SRPCOUNTV Parameter

SRPCOUNTV establishes
increased.

the

upper

limit

which

SRPCOUNT

can

If this parameter is set too low, system performance can be adversely
affected by preventing the system from using this memory allocation
mechanism for nonpaged pool requests.
If SRPCOUNTV is set too high,
there is a penalty of 1 percent of physical memory for any unused
growth space
(one longword for every five unused small request
packets) •
Normally the computed, installed value is appropriate.

10.2.134

SWPFILCNT Parameter

SWPFILCNT defines the maximum number of swapping
installed.

10.2.135

files

that

can

SWPOUTPGCNT Parameter

SWPOUTPGCNT defines the process size in pages (blocks)
to which the
swapper should attempt to reduce a process before attempting to swap
it out. The pages taken from the process are placed into the paging
system.
This parameter allows the swapper an alternative mechanism
before actually performing swaps.
Normally the default value is adequate.

10.2.136

SYSMWCNT Parameter

SYSMWCNT sets the quota for the size of the system working set, which
contains the pageable portions of the system, the paged dynamic pool,
VAX-11 RMS, and the resident portion of the system message file.
While a high value takes space away from user working sets, a low
value may seriously impair system performance. Appropriate values
vary depending on the level of system use. When the system is running
at full
load, check the rate of system faults with the MONITOR PAGE
command of the Monitor Utility (see the VAX-11 Utilities Reference
Manual).
An average system page fault rate of between zero and three
page faults per second is desirable.
If the system page fault rate is
high, and especially if the system seems to be slow, you should
increase the value of SYSMWCNT. However, do not set this parameter so
high that system page faulting never occurs.

10.2.137

TIMEPROMPTWAIT Parameter

TIMEPROMPTWAIT defines the number of seconds that a VAX-11 processor
should wait for the time and date to be entered when a system boot
occurs, if the processor's time-of-year clock does not contain a valid
time.
(The time unit of micro-fortnights is approximated as seconds
in the implementation.)
If the time specified by TIMEPROMPTWAIT
elapses, the system continues the boot operation and the date and time
are set to the last recorded time that the system booted.
For a
VAX-11/730, which does not have a battery back-up clock, the system
time must be supplied whenever power fails.

10-38

SYSTEM PARAMETERS
NOTE
DIGITAL recommends that you set the
system time correctly before allowing
the system to run, so that all functions
employing time-stamping
(such as the
operator log, the error log, accounting
records, file creation dates, and file
expiration dates) will contain correct
time values.
If TIMEPROMPTWAIT is 0, no prompt or wait occurs;
the system boots
immediately, using the time of the last boot as the system time.
If
TIMEPROMPTWAIT is a positive number less than 32768, one prompt is
issued and the value dictates how many seconds you can take to respond
with a time.
If you do not provide a time before TIMEPROMPTWAIT
elapses, the system boots, using the time of the last boot as the
system time.
If TIMEPROMPTWAIT is a number in the range of 32768
through 65535, the prompt for the time is issued at intervals starting
with 2 and doubling until 256 seconds is reached.
If no response is
received, the prompts restart, with the two-second interval. This
prompting process repeats indefinitely, until you specify a time.

10.2.138

TTY ALTALARM Parameter

TTY ALTALARM sets the size of the alternate type-ahead buffer alarm.
This value indicates at what point an XOFF should be sent to terminals
that use the alternate type-ahead buffers with the size specified by
the TTY ALTYPAHD parameter.

10.2.139

TTY ALTYPAHD Parameter

TTY ALTYPAHD sets the size of the alternate type-ahead buffer.
Use
this parameter to allow the block mode terminals and communications
lines to operate more efficiently.

10.2.140

TTY BUF Parameter

TTY BUF sets the default line width for terminals.

10.2.141

TTY CLASSNAME

TTY CLASSNAME provide the two-character pref ix for the terminal class
driver name that is required when booting. Changing the prefix can be
useful when debugging a new terminal driver.

10.2.142

TTY DEFCHAR Parameter

TTY DEFCHAR sets the default characteristics for terminals,
code derived by summing the following hexadecimal values:

10-1Q

using

SYSTEM PARAMETERS
Characteristic
PASSALLl
NOECHO
NOTYPEAHEAD 1
ESCAPE
HOSTSYNC
TTSYNC
LOWERCASE
TAB
WRAP
CRFILLl
LFFILLl
SCOPE
HOLD SCREEN
EIGHT BIT
MBXDSABL
NOBROADCAST
READSYNC
FORM
HALFDUP
MODEM

Function

Value

Passall mode
Noecho mode
No type-ahead buff er
Escape sequence processing
Host can send XON/XOFF
Terminal can send XON/XOFF
Lowercase
Mechanical tabs
Wraparound at end of line
Perform carriage return fill
Perform line feed fill
Terminal is a scope
VT52 holdscreen feature
Eight-bit terminal
Disable mailbox
Prohibit broadcast
XON/XOFF on reads
Mechanical from feeds
Set for half-duplex operation
Set for modem signals

1
2

4
8
10
20

80
100
200
400
800
1000
4000
8000
10000
20000
40000
80000
100000
200000

1. Do not set this characteristic as the default in TTY DEFCHAR
Where a condition is false, the value is O.
The upper byte is the page length. The default characteristics are 24
lines per page, terminal synchronization, wraparound,
lowercase,
scope, and half-duplex.

10.2.143

TTY DEFCHAR2 Parameter

TTY DEFCHAR2
sets
a
second
longword
of
default
terminal
characteristics.
The default characteristics are represented as a
code that is derived by summing the following hexadecimal values:
Characteristic

Function

Value

LOCALECHO

AUTOBAUD
HANGUP
MODHANGUP

2
4

BRDCSTMBX
XON
DMA
ALTYPEAHD
SETS PEED

20
40
80
100

ANSI CRT

1000000

REGIS
2000000
BLOCK MODE
4000000
ADVANCED VIDEO 8000000
EDIT
10000000
DEC CRT
20000000

Enable local echo terminal logic; use
with the NOECHO characteristic in
TTY DEFCHAR
Enable autobaud detection
Hang up on logout
Allow modification of HANGUP without
privileges
Allow sending of broadcasts to mailboxes
(No effect in this parameter)
(No effect in this parameter)
Use the alternate type-ahead parameters
Clear to allow setting of speed without
privileges
Terminal conforms to ANSI CRT
programming standards
Terminal has REGIS CRT capabilities
Block mode terminal
Terminal has advanced video
Terminal has local edit capabilities
Terminal is a DIGITAL CRT

The default is AUTOBAUD.

10-40

SYSTEM PARAMETERS
10.2.144

TTY DIALTYPE Parameter

TTY DIALTYPE provides flag bits for dialups. Bit 0 is 1 for United
Kingdom dialups and 0 for all others.
Bit 1 controls the modem
protocol used. The remaining bits are reserved for future use.
See
the VAX/VMS I/O User's Guide for more information on the flag bits.

10.2.145

TTY DMASIZE Parameter

TTY_DMASIZE specifies the number of characters in the output buffer
below which character transfers are performed, and above which DMA
transfers occur, provided the controller is capable of DMA I/O.

10.2.146

TTY OWNER Parameter

TTY OWNER specifies the owner UIC against which terminal protection is
set.
The specification must represent the value of a standard 32-bit
UIC with the group number in the high-order word and the member number
in the low-order word. You should normally set TTY OWNER to a value
of hexadecimal 10004, which is UIC [1,4].

10.2.147

TTY PARITY Parameter

TTY PARITY is not currently implemented.

10.2.148

TTY PROT Parameter

TTY PROT sets the default protection for all terminals in relation to
the
UIC
specified
for
the
TTY OWNER parameter below.
The
specification must represent the value of a standard 16-bit protection
mask as described in Chapter 3.
However, only read bits are
meaningful. When a read bit is on, that category of user is
prohibited from allocating terminals.
The default {FFFO) provides for system access only on terminals.
You
can change protection on a per-terminal basis with the DCL command SET
PROTECTION/DEVICE to permit user allocation of remote and application
terminals.
Note that this protection does not prevent logging in on the terminal;
it only prevents allocation of the terminal by another process.

10.2.149

TTY RSPEED Parameter

TTY RSPEED defines the receive speed for terminals.
If TTY RSPEED is
O, -TTY SPEED controls .both the transmit and receive speed. This
parameter is only applicable for controllers that support split speed
operations, such as the DZ-32 and the DMF-32.

10.2.150

TTY SCANDELTA Parameter

TTY SCANDELTA sets the interval for polling terminals for dial-up and
hang-up events.
Shorter intervals use more processor time; longer
intervals may result in missing a hang-up event.
10-41

SYSTEM PARAMETERS
10.2.151

TTY SILOTIME Parameter

TTY SILOTIME defines the interval at which the DMF-32 hardware polls
the- input silo for received characters.
The DMF-32 asynchronous
terminal controller can delay the generation of a single input
interrupt until multiple characters have accumulated in the input
silo. TTY SILOTIME specifies the number of milliseconds that the
characters- are allowed to accumulate prior to the generation of an
input interrupt by the hardware.
Normally the default value is

10.2.152

adequate~

TTY SPEED Parameter

TTY SPEED sets the default speed for terminals,
codes:
Code
1
2
3
4
5
6
7

10.2.153

Baud Rate
50
75

using

Code

Baud Rate

9
10

1800
2000
2400
3600
4800
7200
9600
19200

llO

134.5
150
300
600
1200

12
13
14
15
16

the

following

TTY TYPAHDSZ Parameter

TTY TYPAHDSZ sets the size of the terminal type-ahead buffer.

10.2.154

UAFALTERNATE Parameter

UAFALTERNATE enables or disables the assignment of SYSUAF as the
logical name for SYSUAFALT, causing all references to the user
authorization file (SYSUAF) to be translated to SYS$SYSTEM:SYSUAFALT.
Use of the normal user authorization file (SYS$SYSTEM:SYSUAF) can be
restored by deassigning the system logical name SYSUAF.
This
parameter should be on (1) only where the system is being used .. by a
restricted set of users. You must create a user authorization file
named SYSUAFALT prior to its use (see Chapter 2).

10.2.155

UDABURSTRATE Parameter

UDABURSTRATE is not currently implemented.

10.2.156

USERDl Parameter

USERDl is a dynamic parameter that is reserved for definition at the
user's site.
The reserved longword is referenced by the symbol
SGN$GL USERDl in the module SYS$SYSTEM:SYS.STB.

10-42

SYSTEM PARAMETERS
10.2.157

USERD2 Parameter

USERD2 is a dynamic parameter that is reserved for definition at the
user's site.
The reserved longword is referenced by the symbol
SGN$GL_USERD2 in the module SYS$SYSTEM:SYS.STB.

10.2.158

USER3 Parameter

USER3 is a parameter that is reserved for definition at the user's
site.
The reserved longword is referenced by the symbol SGN$GL USER3
in the module SYS$SYSTEM:SYS.STB.

10.2.159

USER4 Parameter

USER4 is a parameter that is reserved for definition at the user's
site. The reserved longword is referenced by the symbol SGN$GL_USER4.

10.2.160

VIRTUALPAGECNT Parameter

VIRTUALPAGECNT sets the maximum number of virtual pages that can be
mapped for any one process.
Every 128 virtual pages requires 4 bytes
of permanently resident memory in the system page table (as discussed
under the BALSETCNT parameter). A program is allowed to divide its
virtual space between the PO and Pl tables in any proportion except
that the Pl table must be large enough to map 320 pages.
When the System Dump Analyzer is used, you must insure that the value
of VIRTUALPAGECNT is at least the size of the dump file plus
approximately 2000 pages.
Normally the computed, installed value is adequate.

10.2.161

WSDEC Parameter

WSDEC specifies the number of pages by which the limit of a working
set is automatically decreased at each adjustment interval (which is
quantum end). At a setting of 35, for example, the system will
decrease the limit of a working set by 35 pages each time a decrease
is required.
In·creasing the value of this parameter tends to
increase the speed
with which working set limits are decreased when the need arises.

10.2.162

WSINC Parameter

WSINC specifies the number of pages by which the limit of a working
set is automatically increased at each adjustment interval (which is
quantum end). At a setting of 150,
for example, the system will
increase the limit of a working set by 150 pages each time an increase
is required.
Decreasing the value of this parameter tends to reduce the speed with
which
working set limits are increased when the need arises.
Normally, you should keep this parameter at a high value because a
rapid increase in limit is often critical to performance.

10-41

SYSTEM PARAMETERS
A value of 0 for WSINC disables the automatic adjustment of working
set limits for all processes.
Limits stay at their base values. You
can disable the automatic adjustment of working set limits on a
per-process basis by using the DCL command SET WORKING SET.

10.2.163

WSMAX Parameter

WSMAX sets the maximum number of pages on a system-wide basis for any
working set.
The value of WSMAX also affects the allocation of
per.manently resident memory for the swapper map and system page table
(and for this reason should not be set at an arbitrarily high number):
•

Swapper map -- 4 bytes for each page of WSMAX

•

System page table -- 4 bytes for
times BALSETCNT

each

128

pages

WSMAX,

Generally, you should use a reasonable value for WSMAX;
that is,
whatever the size of the largest working set will need to be. The
default value is appropriate for normal time-sharing operations, while
significantly larger values should be used for programs with very
large virtual address spaces to reduce page faulting.

10.2.164

XFMAXRATE Parameter

XFMAXRATE limits the data transfer rate that can be set for DR32
devices.
On some hardware configurations (especially those without
interleaved memory) , a high DR32 transfer rate could cause a machine
check
(CPU timeout).
The VAX/VMS I/O User's Guide describes how to
encode this parameter.

10-44

CHAPTER 11
SYSTEM GENERATION

When VAX/VMS is installed for the first time or is upgraded from a
previous version, the system adjusts system parameters for your system
hardware. This is done by setting values in the system via the System
Generation Utility (SYSGEN), and by creating several files on the
system disk to be used in subsequent bootstrap operations.
You can
perform further configurational tuning of the system by editing the
intermediate text files produced by the AUTOGEN.COM command procedure
and reinvoking the procedure
(see Chapter 12). You can also use
SYSGEN to alter system parameters directly.
This chapter describes
the parts of VAX/VMS that you can manipulate with SYSGEN:
•

System parameters -- Create and modify a standard system
parameter file for use in subsequent conversational bootstrap
operations; modify the parameter values in the current system
image
(SYS$SYSTEM:SYS.EXE)
for use in subsequent bootstrap
operations; dynamically modify the parameter values of the
active system {applies only to the dynamic system parameters)

•

DeYices and device drivers -- Connect devices and
device drivers (most of this work is automatic)

•

System files -- Create additional paging and swapping files

•

Start-up command
procedure -- Identify
independent start-up command procedure

•

Multiport (shared) memory -- Initialize multiport memory units

See the VAX-11 Utilities Reference Manual for
System Generation Utility and its commands.

11.1

the

full

load

their

site-

current

details

the

SYSTEM PARAMETERS

The bootstrap process initializes the active system parameter values
in memory from the current system imag~ on disk (that is, the starting
parameter
values
are
those
in
SYS$SYSTEM:SYS.EXE).
In
a
conversational bootstrap operation, you can modify these values by
reinitializing the active parameter values from a parameter file or
the default list, and by setting new parameter values on an individual
basis. At the end of the bootstrap operation, the system image is
modified to conform to the active parameter values.

11-1

SYSTEM GENERATION
WARNING
Many of the system generation parameters
can
affect other parameters or the
performance of the system.
It
is
suggested
that you make changes to
system
parameters
by
editing
the
PARAMS.DAT
file
and reinvoking the
AUTOGEN.COM procedure.
After the system is booted and running, you can run SYSGEN to create
or modify parameter files, modify the current system image, and modify
the dynamic parameter values of the active system.
The following
sequence illustrates a typical procedure for using SYSGEN:
•

Invoke SYSGEN -- Invoking SYSGEN initializes a
the active parameter values.

•

Optionally issue a USE command -- You can reinitialize the
work area to the values of a parameter file, the current
system image, or the default values, if the active values do
not provide a suitable base for subsequent operations.

•

Issue SET commands -- You modify parameters on an individual
basis.
These modifications have no effect outside the SYSGEN
work area.

•

Issue a WRITE command -- You create a parameter file, modify
the current system image on disk, or modify the active system
on disk.

During these operations, you can use the SHOW command to
parameter values in the SYSGEN work area.

11.1.1

work

area

examine

the

CFeating a Parameter File

The creation of a new parameter file does not immediately affect the
system.
At a subsequent conversational bootstrap operation, however,
you can initialize the active system with the values of the new file.
The following example creates a new version of the AUTOGEN.PAR system
parameter file with a new value for the REALTIME SPTS parameter:

$ SET DEFAULT SYS$SYSTEM
$ RUN SYSGEN
SYSGEN> USE AUTOGEN
SYSGEN> SET REALTIME SPTS 10
SYSGEN> WRITE AUTOGEN
SYSGEN> EXIT
The next example creates a user file
using the AUTOGEN.PAR file as a base:

$ SET DEFAULT SYS$SYSTEM
$ RUN SYSGEN
SYSGEN> USE AUTOGEN
SYSGEN> SET REALTIME SPTS 10
SYSGEN> WRITE OURSITE
SYSGEN> EXIT

11-2

named

SYS$SYSTEM:OURSITE.PAR,

SYSTEM GENERATION
11.1.2

Modifying the System Image

The modification of the current system image also does not immediately
affect the system. At subsequent bootstrap operations, however, the
active system is initialized with the new values.
A conversational
bootstrap operation permits you to modify these values further, while
a nonstop bootstrap operation makes the new values the values of the
active system.
The following example modifies the REALTIME SPTS
parameter value in the system image:
$
SYS$SYSTEM:SYSGEN
SYSGEN> USE CURRENT
SYSGEN> SET REALTIME SPTS 10
SYSGEN> WRITE CURRENT
%0PCOM, 25-JUN-1982 16:04:06.30, message from user SYSTEM
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process
ID 00160030 into file SYS.EXE
SYSGEN> EXIT

11.1.3

Modifying the Active System

Modification of the active system immediately affects that subset of
the system parameters called the dynamic parameters by changing their
values in the active system in memory.
Chapter 10 identifies the
dynamic parameters
(as does the SYSGEN command SHOW/DYNAMIC). The
other parameters cannot be changed immediately because they regulate
structures that cannot be changed once the system is running. The
following example modifies the active 'value of the
PFCDEFAULT
parameter:
$
SYS$SYSTEM:SYSGEN
SYSGEN> SET PFCDEFAULT 127
SYSGEN> WRITE ACTIVE
%0PCOM, 25-JUN-1982 16:04:06.30, message from user SYSTEM
%SYSGEN-I-WRITEACT, ACTIVE system parameters modified by process
ID 00160030 into file SYS.EXE
SYSGEN> EXIT
Modification of the active system does not affect the current system
image on disk.
If, for example, you set new active parameter values
(WRITE ACTIVE) and later want to use these values for subsequent
bootstrap operations, the values must be explicitly written to the
current system image on disk:
$
SYS$SYSTEM:SYSGEN
SYSGEN> WRITE CURRENT
%0PCOM, 25-JUN-1982 16:04:06.30, message from user SYSTEM
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process
ID 00160030 into file SYS.EXE
SYSGEN> EXIT

11.2

DEVICES AND DEVICE DRIVERS

Normally, you issue the AUTOCONFIGURE command to automatically connect
all de~ices physically attached to the system and load their device
drivers, saving a great deal of effort and reducing the possibility of
error.
Devices
not attached to the system and devices with
nonstandard names can be connected and their device drivers loaded
with explicit CONNECT (or CONNECT and LOAD) commands. Great care must
be exercised in issuing CONNECT and LOAD commands;
see the VAX/VMS
Guide to Writing ~ Device Driver.

11-3

SYSTEM GENERATION
Devices not connected automatically by AUTOCONFIGURE include the
network communications logical device and the console block storage
device. Connecting the network communications logical device requires
the following explicit CONNECT command:
CONNECT NET/NOADAPTER/DRIVER=NETDRIVER
Connecting the console block storage
explicit CONNECT command:

device

requires

the

following

CONNECT CONSOLE
The following example autoconfigures the devices physically attached
to the system and explicitly connects the network software device and
the console block storage device:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> AUTOCONFIGURE ALL
SYSG.EN> CONNECT NET/NOADAPTER/DRIVER=NETDRIVER
SYSGEN> CONNECT CONSOLE
SYSGEN> EXIT
Normally, the" SYSGEN commands for connecting devices and loading
device drivers are included in the site-independent start-up command
procedure (see Chapter 7).
Another DIGITAL-supplied driver named CONINTERR (which resides in
SYS$SYSTEM:CONINTERR.EXE)
permits real-time processes to connect to
interrupt vectors for quick response to and special handling of
real-time events.
The driver is not associated with any one device
type. See the VAX/VMS Real-Time User's Guide for further information.

11.3

SYSTEM FILES

The system defines appropriate sizes for the paging, swapping, and
dump
files
for
your
hardware configuration.
The full file
specification of each file is SYS$SYSTEM:file-name.type.
The file
names are PAGEFILE.SYS for the paging file, SWAPFILE.SYsl for the
swapping file, and SYSDUMP.DMP for the dump file.
Sizes are expressed
in pages.
The VAX/VMS software distribution kit creates system files suitable
for most systems.
For special workloads or variant configurations,
you must specify the file sizes with the CREATE command of the System
Generation Utility or
(to create primary files only) with a DIGITAL
command procedure called SYS$UPDATE:SWAPFILES.COM.
The following
example illustrates the use of the CREATE command:
$ SET DEFAULT SYS$SYSTEM
$ RUN SYSGEN
SYSGEN> CREATE PAGEFILE.SYS /SIZE=16384
%SYSGEN-I-EXTENDED, SYS$SYSROOT: [SYSEXE]PAGEFILE.SYS;l extended
SYSGEN> CREATE SWAPFILE.SYS /SIZE=7168
%SYSGEN-I-EXTENDED, SYS$SYSROOT: [SYSEXE]SWAPFILE.SYS;l extended
SYSGEN> CREATE SYSDUMP.DMP /SIZE=2052
%SYSGEN-I-EXTENDED, SYS$SYSROOT:[SYSEXE]SYSDUMP.DMP;l extended
SYSGEN> EXIT

1. On any configuration where the system disk space is
25,000 blocks, the swapping file is named SWAPFILEl.SYS.
11-4

less

than

SYSTEM GENERATION
The next example uses the command procedure:
$ @SYS$UPDATE:SWAPFILES
To leave a file size at its current value type a
carriage return in response to its size prompt.
Current file sizes are:
Directory SYS$SYSROOT: [SYSEXE]
PAGEFILE.SYS;l
SYSDUMP.DMP; 1
SWAPFILE.SYS;l

16384
4128
3072

Total of 3 files, 23584 blocks.
There are 128741 available blocks on SYS$SYSDEVICE.
Enter new size for paging file: ffifil)
Enter new size for system dump file: 6052
Enter new size for swapping file: ffifil)
%SYSGEN-I-EXTENDED, SYS$SYSROOT: [SYSEXE]SYSDUMP.DMP;l extended

************************************************************************

*
*

Please reboot in order for the new files to be used by the system.
After rebooting, purge obsolete copies of the files.
DO NOT delete the old files until after the reboot.

*
*
*

************************************************************************
Both the command procedure and the CREATE command automatically extend
the size of a paging or dump file if you specify a size that is larger
than that of an existing file.
(However, if you have explicitly
installed a file with the SYSGEN command INSTALL, the file cannot be
extended;
instead, a new version of the file is created.)
If you
specify a smaller size for any of these types of system file, the
command procedure or the CREATE command creates a new version of the
system file.
If the swapping file does not exist, you are queried and
you can request that it be created.
In any case, an appropriate
message is issued whenever a file is created or extended.
If a new
version was created, you must delete the old version explicitly (but
not until after the next bootstrap operation). In the case of a
primary file (PAGEFILE.SYS, SWAPFILE.SYS, or SYSDUMP.DMP), the new or
extended size file does not become effective until the system is shut
down and restarted.
In the case of a secondary file,
the new file
becomes effective when it is installed.
You can verify the suggested sizes through the following calculations:
•

Paging file -- Size of the average program at your site
(in
pages)
times the maximum number of processes (MAXPROCESSCNT
system parameter) • The system installation sets an initial
size for your primary paging file. You can display statistics
on your paging file usage with the DCL command SHOW MEMORY.
Examine the data pertaining to the paging files. Aim to keep
paging file usage less than half the size of the paging files.
You can limit the usage of paging file space by user programs
with the /PGFLQUOTA qualifier to the ADD and MODIFY commands
in the Authorize Utility (see the VAX-11 Utilities Reference
Manual).
You should not reduce the value of /PGFLQUOTA below
1024. Size requirements of the paging file can vary widely
depending on user applications.
Sufficient space in the
paging file is critical to system performance.
If a paging

11-5

SYSTEM GENERATION
file starts to fill to the point where system performance is
being affected, a message will be printed on the console
terminal. Should this happen, you should increase the size of
your paging file.
•

Dump file -- Size of physical memory in pages {to save the
contents of memory if the system fails) plus four pages {to
provide continuity of the error log when the system is shut
down or if the system fails).

•

Swapping file -- Maximum number of processes {MAXPROCESSCNT
system parameter) times the average of the working set quotas
of processes runnning on the system. The system installation
sets an initial size for SWAPFILE.SYS based on your hardware
configuration. As an alternative to trying to calculate a
more accurate swapping file size, you can monitor the swapping
file usage with the DCL command SHOW MEMORY and watch its
usage under load. You should aim to keep at least one-fourth
of the swapping file space
unused;
otherwise
system
performance can be severely affected.

At bootstrap time, the system activates the latest versions of
SYS$SYSTEM:PAGEFILE.SYS,
SWAPFILE.SYS,
and
SYSDUMP.DMP.
After
bootstrapping, you can replace or augment the primary paging or
swapping file with additional files
{previously created with the
SYSGEN command CREATE) by issuing the SYSGEN command INSTALL.
The
advantages to using secondary files are that they do not have to be on
the system disk and they can span volumes in a volume set.
Where
secondary files are used, you should include SYSGEN INSTALL commands
for the secondary files in the site-specific start-up
command
procedure {see Chapter 7).
If you are using secondary files because
there is a shortage of disk space on the system disk, you can reduce
the size of PAGEFILE.SYS to a value as low as 3000 blocks or
SWAPFILE.SYS to a value as low as 1000 blocks.
All processes created after installation of additional paging files
use the paging file with the most space, while all processes created
before its installation continue to use the paging file to which they
are assigned.
Swapping space is allocated from whichever swapping
file has space.
Installation of additional paging or swapping files requires
dynamic memory for a bit map, just as the primary files do.

11.4

nonpaged

START-UP COMMAND PROCEDURE

Chapter 7 describes the site-independent start-up command procedure
named SYS$SYSTEM:STARTUP.COM that DIGITAL supplies and recommends that
you do not edit it. However, if necessary, you can create alternate
site-independent start-up command procedures; for example, you can
copy STARTUP.COM to other files of type COM and edit those files.
Following a bootstrap operation, the system executes the current
site-independent start-up command procedure.
Initially {that is, as
supplied
in
the
software
distribution
kit),
the
current
site-independent start-up command procedure is STARTUP.COM. You can
name an alternate site-independent start-up command procedure to be
used during subsequent bootstrap operations with the SET/STARTUP
command in SYSGEN. The SHOW/STARTUP command displays the current

11-6

SYSTEM GENERATION
site-independent start-up command procedure.
The following example
displays the current site-independent start-up command procedure, then
specifies an alternate:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> SHOW/STARTUP
Startup command file = SYS$SYSTEM:STARTUP.COM
SYSGEN> SET/STARTUP SYS$SYSTEM:XSTARTUP.COM
SYSGEN> WRITE CURRENT
%0PCOM, 25-JUN-1982 16:04:06.30, message from user SYSTEM
%SYSGEN-I-WRITECUR, CURRENT system parameters modified by process
ID 00160030 into file SYS.EXE
SYSGEN> EXIT

11.5

MULTIPORT (SHARED) MEMORY

A single processor can attach one or. two multiport memory units, each
of which may vary in size from 256KB to 2MB. The front panel of each
multiport memory unit displays the number of that unit.
When you
issue a SHARE (initialize) command, SYSGEN polls the processors with
ports on the specified multiport memory unit.
If no other processors
are using the unit, the unit is initialized.
If another processor is
using the unit, the unit is connected. A SHARE (connect) command for
an uninitialized multiport memory unit results in an error condition.
You should power down a multiport memory unit only after
shutting down and rebooting all systems connected to the unit.
A multiport memory unit managed by VAX/VMS contains
structures, with space requirements as indicated:·

the

first

following

•

Common data page -- Description of VAX/VMS data structure
quotas for the shared memory

and

•

Global section description
(GSD)
table -- Total
global
sections, as specified in the SHARE command, times 100 bytes,
rounded up to the next full page

•

Mailbox table -- Total mailboxes, as specified in the SHARE
command, times 48 bytes, rounded up to the next full page

•

CEF table -- Total common event flag clusters, as specified in
the SHARE command, times 80 bytes, rounded up to the next full
page

•

PRQ pool -- Total interprocess or request
messages,
as
specified in the SHARE command, times 64 bytes, rounded up to
the next full page

•

Dynamic pool -- Number of blocks allocated to the pool, as
specified in the SHARE command, times the size of each block,
as specified in the SHARE command

•

Global section bit map -- One page

•

Global sections -- Size of multiport memory unit minus the sum
of the above preallocated structures (that is, the remaining
space)

Figure 11-1 illustrates the appearance of a multiport memory unit
where the SHARE command specifies the default structure values,
assuming a 256KB unit with four active ports.

11-7

SYSTEM GENERATION
SYSGEN>
SYSGEN>
SYSGEN>
SYSGEN>

SHARE MPMO SHR MEM l/INITIALIZE/GBLSECTIONS=32/MAILBOXES=32/CEFCLUSTERS=32/POOLBCOUNT=l28/POOLBSIZE=l 28/PRQCOUNT=64
1

1 page

PRQ POOL

64 x 64

8 pages

DYNAMIC POOL

128 x 128

32 pages

GSD TABLE

32 x 100

7 pages

MAILBOX TABLE

32 x 48

3 pages

CEF TABLE

32 x 80

5 pages

1 page

COMMON DATA PAGE

GLOBAL SECTION BIT MAP
GLOBAL SECTIONS

512 - 57

= 455 pages

relative·
1

~page

Figure 11-1:

Example of Multiport Memory Structures

The following guidelines are suggested in selecting values for the
SHARE
qualifiers
that regulate the sizes of the preallocated
structures:
e

/CEFCLUSTERS, /GBLSECTIONS, and
/MAILBOXES -- You
should
simply specify the maximum number of each type.of structure
required by all processors at any one time.
The same
structure being used by many processes on one or more
processors counts as just one structure.

/POOLBCOUNT and /POOLBSIZE -- The primary use of the dynamic
pool is to buffer mailbox messages. The size of a message is
28 bytes plus the data in the message. Since space from the
pool is always allocated in whole blocks, the recommended
block size is the median message size plus 28. A block size
that is too small for a message requires extra system overhead
to concatenate the message blocks into the user buff er and
segment them out of the user buffer. The number of blocks
should be sufficient to satisfy all messages that might be
outstanding at once. If a mailbox request cannot be satisfied
due to insufficient pool space, the requesting process enters
a resource wait state or the request fails (if resource wait
mode is not enabled), just as if the nonpaged dynamic pool
were
depleted.
For
this reason, you should tend to
overestimate space requirements in the dynamic pool.

•

/PRQCOUNT -- The system uses interprocessor request blocks
internally to transfer requests among the VAX/VMS executive
routines and mailbox drivers on the different processors.
PRQs are allocated and deallocated rapidly, so that a large
number should not be needed.
The default value normally
suffices.
If an executive or driver request cannot be
satisfied due to depletion of the PRQs, the requesting routine
waits until a PRQ becomes available.

11-8

SYSTEM GENERATION
You should calculate the space rema1n1ng for the global sections and
determine if it is sufficient.
If the space is insufficient, you
might reduce the size of the dynamic pool.
However, this condition
really suggests the need for a larger or additional multiport memory
unit.
Where a multiport memory unit is a normal part of the system
configuration, you should include the SYSGEN commands to initialize
and connect it in the site-specific start-up command procedure (see
Chapter 7).

11-9

CHAPTER 12
TUNING CONSIDERATIONS

Hardware
resources -- mainly
physical
memory
and
secondary
storage -- constitute the primary constraint on system performance.
Adequate hardware resources for the workload generally
provide
adequate performance with little need for tuning.
Inadequate hardware
resources for the workload generally provide inadequate performance
regardless of the tuning effort.
Only in the middle ground of
just-adequate or just-inadequate resources does tuning become a
significant factor.
This resource level normally occurs in situations
where the user is trying to make do with a small system, or where the
user's workload has been increasing over a period of time with no
corresponding addition of resources. For practical purposes, tunable
general-purpose systems can be considered in two categories:
•

Small systems -- Small in this context means a system with
tight resources.
Normally, this would be a system of 2MB or
less, although conceivabiy a large system with an enormous
workload might fit in this category. The primary emphasis in
tuning a small system is in optimizing the use of physical
memory and achieving a balance between the use of physical
memory and disk I/O.

•

Large systems -- Large in this context means a system with
plentiful resources for the workload. Normally, this would be
a system with physical memory in excess of 3MB, although
conceivably a small system with a light workload might fit in
this category. The primary emphasis in tuning a large system
is on decreasing disk I/O.

Before undertaking a major tuning effort, the manager of a small
system should weigh the time and effort involved in the venture
against the alternative solution: the purchase of additional physical
memory or faster disks.

12.1

PRETUNING CONSIDERATIONS

Before starting the tuning effort, you should ensure that hardware
resources are adequate for the workload, that the workload is
distributed as uniformly as possible, and that frequently used code is
shared.

TUNING CONSIDERATIONS
12.1.1

Hardware Resources

VAX-11 hardware configurations are designed to
workloads:
Workload

Memory

1-4 users

.SMB

2-12 users

lMB

8-32 users

2MB

24-48 users

3MB

32-64 users

4MB

handle

the

following

These figures are approximate. The precise number of users for a
memory configuration depends on the size and makeup of the programs
those users are running.
If the processing requirements of all users
consist of editing, compiling, linking, and running small programs,
the system will probably support around the maximum number of
users -- 32 on the 2MB system, for example.
If, on the other hand,
processing consists mainly of developing very large programs and/or
sorting, the system will probably support around the minimum number of
users. For user production programs, you can lean toward the maximum
figure for programs that contain little data or use VAX-11 RMS to
manipulate data on a per-record basis, and toward the m1n1mum figure
for programs that contain very large data structures. The trend for
native VAX/VMS software products (assemblers, compilers, and so on) is
to require larger amounts of memory, mainly through the use of larger
data structures to reduce I/O activity (resulting in shorter response
times and faster throughput).
System throughput is limited primarily by three factors:
physical
memory, processor speed, and disk speed. A properly tuned system
balances the use of these resources so that they reach the saturation
point at the same time.
Disk I/O operations, for example, can be
reduced by using more physical memory for the file system caches.
Such an adjustment makes sense on a system with abundant physical
memory, but will probably decrease throughput on a small system
(because the use of physical memory reaches the saturation point while
the disks can still handle more I/O transfers).
Actual disk capacity is a function of user file requirements.
However, the system should ideally contain at least two disk drives
and two disk drive controllers. You should make an effort to place
the disk drives containing the execution files (system and user image
files, paging £ile, swapping file, and dump file) and the disk drives
containing user data on separate controllers. This procedure will cut
down on the contention between system I/O and user I/O activities.

12.1.2

Workload Distribution

You should distribute the workload as evenly as possible over the time
the computer is running. While scheduling interactive users evenly is
normally not possible due to the weight of convention on standard
working and sleeping hours, either or both of the following techniques
are workable:
1.

Run large jobs as batch jobs -- Force the submission of large
jobs on a batch basis; regulate the number of batch streams

1 ?-?

TUNING CONSIDERATIONS
so that batch usage is high when interactive usage is low.
For example, the Accounting Utility should be run as a batch
job. Chapter 8 discusses batch jobs.
2.

12.1.3

Restrict system use -- Do not permit more users to log in at
one time than the system can support with an adequate
response time. You can restrict the number of interactive
users with the IJOBLIM and RJOBLIM system parameters (see
Chapter 10) and the DCL command SET LOGINS (see the VAX/VMS
Command Language User's Guide). You might also restrict use
of the system by groups of users to certain days and hours of
the day. See the Authorize Utility in Chapter 2.

Sharing of Code

The site-independent start-up command procedure creates permanent
global sections for system programs and subroutines by installing them
as known images with the shared attribute. You should add to these
(in the site-specific start-up command procedure) user programs and
subroutines that have reached a production status or are in general
use.
Users should, of course, be encouraged to write shareable code.
Chapter 7 of this manual covers start-up command procedures, while
Chapter 6 discusses installing known images.

12.2

SYSTEM PERFORMANCE (BACKGROUND DISCUSSION)

Figure 12-1 illustrates the physical memory and secondary
requirements for supporting process on a VAX/VMS system.

~
... ...
~
.. ~
. ..
~
--

RESIDENT
SYSTEM

PAGE
CACHE

BALANCE SET

resident
executive
routines

free
page
list

user working sets

~--------

non paged
dynamic
memory

1-------modified
page
list

1-----------------~

system working set

storage

IMAGE FILES

SECTION FILES

PAGING FILE

SWAPPING FILE

ZK-1009-82

Figure 12-1:

VAX/VMS Memory Configuration

Each active process is associated with a working set that contains the
pages of code and data being used in the execution of that process.
Initially, the working set expands to accommodate clusters of image
and section pages
(that is, code or data explicitly mapped by a
process to its virtual address space) from their disk files as they
are referenced.
The size of the working set (unless altered by a
system service) equals the cumulative number of pages brought in from
the image and section files, until the working set limit is reached.

1 ?-~

TUNING CONSIDERATIONS
At that point, newly referenced pages are accommodated by pushing
current pages out of the working set, on a first-in, first-out (FIFO)
basis.
Whenever a referenced page does not exist in the working set, a page
fault is said to occur. The system automatically adjusts the working
set limit by deducting pages if the rate of page faults is low, and
adding pages if the rate of page faults is high (unless you turn off
the automatic working set adjustment feature) •
If sufficient space exists, working sets reside in real memory.
As
memory fills up, the system attempts to make room for new working sets
by removing pages from existing working sets.
If sufficient space
does not exist for all the working sets after they are reduced in size
as much as possible, one or more of the working sets are moved from
memory to the swapping file. The system determines which working sets
to retain in physical memory and which to swap out to disk according
to each process's state and priority, and the quantum:
•

Current state -- The currently executing
physical memory.

process

resides

•

Compute state -- Processes that can execute immediately if
given processor time ~hould reside in physical memory; they
are the last candidates for outswapping.

•

Waiting state -- Processes that are waiting for a local event
flag, are hibernating, or are suspended constitute the primary
candidate~ for outswapping.

•

Priority -- Among processes in the same state, those with
lowest priorities are outswapped.

•

Quantum -- A process in a com~ute state cannot be
until
it
has
received
services
for
at
SYSGEN-specified period of time called a quantum.

the

outswapped
least one

The system~ reevaluates physical memory
versus
disk
residency
requirements whenever a process's state changes. For example, if a
local event flag is posted changing the state of a swapped-out process
from wait to compute, the system will
(if possible)
place the
process's working set in physical memory, even if this means taking
pages from or outswapping the working set of another process.
One nonswappable working set is reserved for those portions of the
system executive that are pageable. In addition, the system requires
user working sets (these are swappable)
for the system processes
ERRFMT, OPCOM, JOB CONTROL, and the file system ACP. Working sets are
also required for any magnetic tape ACPs and print symbionts in use.
DECnet uses working sets for NETACP, REMACP
(optional), and EVL
(optional).
Pages pushed out of a working set that has reached its limit initially
remain in physical memory by going to the page cache: to the free
page list if they were not written on, or to the modified page list if
they were written on.
The free page list expands to accommodate
additional pages being pushed out of working sets. The free page list
contracts as pages are allocated to processes requesting additional
memory; pages leave the free list on a FIFO basis.
However, the
system cannot reduce the size of the free page list below a
SYSGEN-specified lower limit.
The modified page list expands to accommodate additional pages being
pushed out of working sets, but only to a SYSGEN-specified upper

TUNING CONSIDERATIONS
limit. At that point, pages are written back to their section files
or
{in the case of demand-zero and copy-on-reference pages) to the
paging file, then moved to the free list, until the ·size of the
modified page list drops below a SYSGEN-specified lower limit.
If a page that was pushed out of a working set is referred to again, a
page fault occurs. The system must return the page to the working set
from either:
•

The page cache -- If the page is still in physical memory
{that is, on the free page list or the modified page list), a
fast page fault occurs, as no disk I/0 is required.

•

An image, section, or paging file -- If the page has been
overwritten, a slower page fault occurs, as the page must be
reread from disk.

Although pages move through the working sets and page cache on a FIFO
basis, the return of referred-to-again pages from the page cache to
the working sets produces a net effect of removing from memory the
least frequently used pages and retaining the most frequently used
pages.
When an image terminates, all section pages that were modified are
written back to the section files. All pages associated with the
program in physical memory are released.
{Shared pages, however, are
not released if currently in use by another process.)

12.3

TUNING TOOLS

You control system performance overall with the system parameters, and
on a per-user basis with the entries in the UAF. Certain DCL commands
also aid in evaluating system performance. The effects of tuning can
be monitored with the Monitor Utility {MONITOR) and the DCL command
SHOW MEMORY.

12.3.1

System Parameters and Files

When your system is installed or upgraded, a DIGITAL-supplied command
procedure named SYS$UPDATE:AUTOGEN.COM sets the values of system
parameters, the sizes of the paging, swapping, and dump files, and the
contents of the default installed image list {VMSIMAGES.DAT in
SYS$MANAGER), based on your hardware configuration and estimates
collected from typical workloads.
You can invoke AUTOGEN any time
after installation or upgrade to reset system parameters and system
file sizes for the next time the system is booted. 'Depending on the
adjustments you are making, you may have to invoke AUTOGEN several
times, specifying different parameters.
The format for invoking
AUTOGEN is as follows:
@SYS$UPDATE:AUTOGEN [parameter]
You can enter one parameter value.
parameter values and their effects.

Table

12-1

lists

the

possible

You should use AUTOGEN from the system manager's account, as you
the associated privileges.

1?-~

need

TUNING CONSIDERATIONS
Table 12-1:

AUTOGEN Parameter Values

Parameter

Function

None

Updates the current system parameters and files, and
creates a parameter file named SYS$SYSTEM:AUTOGEN.PAR
using the results of a previous AUTOGEN GENPAR
operation

CONFIG

Defines your hardware configuration in a file named
SYS$SYSTEM:CONFIG.DAT;
Figure 12-2 demonstrates the
appearance of a CONFIG.DAT file

GEN PAR

Generates parameter and files requirements in a file
named SYS$SYSTEM:PARAMS.DAT using the results of a
previous
AUTOGEN
CONFIG
step;
Figure
12-2
demonstrates the appearance of a PARAMS.DAT file

REBOOT

Updates the system parameters and files
the system

SAVE

Saves old
operation

SHUTDOWN

Updates the system parameters
down the system

parameter

values

and

reboots

prior

GEN PAR

and

files

and

shuts

CONFIG.DAT

PARAMS.DAT

VERSION: =V3. 0
CPUTYPE=l
SID=l9923201
MEMSIZE=8192
SYSDISK=4
NUMTERMS=80
NUMTAPES=2
NUMDISKS=2 3
NUMCOMMS=l2
NUMPRINTERS=2
NUMDEVICES=l22

VERSION:=V3.0
CPUTYPE=l
SID=l9923201
MEMSIZE=8192
SYSDISK=4
NUMTERMS=80
NUMTAPES=2
NUMDISKS=23
NUMCOMMS=l2
NUMPRINTERS=2
NUMDEVICES=l22
MAXPROCESSCNT=llO
VIRTUALPAGECNT=l8432
OLD GBLSECTIONS=l24
OLD-GBLPAGES=5192
OLD-WSMAX=3 072
SCSSYSTEMID=l60
MAXPRINTSYMB=32
ACP SWAPFLGS=l4

Figure 12-2:

Sample CONFIG.DAT and PARAMS.DAT Files

If (based on the performance of your system and from the suggestions
in this chapter) you decide to modify some system parameters or change
the size of a system file, you should perform such modifications with
AUTOGEN rather than with the SYSGEN Utility, as AUTOGEN analyzes your
modifications and adjusts any related parameters. The steps for using
AUTOGEN to change system parameter values and system file sizes are as
follows:

, ?-f\

TUNING CONSIDERATIONS
1.

Edit SYS$SYSTEM:PARAMS.DAT -- The system parameters appear as
the full name of the parameter followed by an equal sign and
the value of the parameter. The system files appear as the
keywords PAGEFILE, SWAPFILE, and DUMPFILE followed by an
equal sign and the size of the file in blocks.
You can
change the values of those parameters and files listed in
PARAMS.DAT, add new values, or delete existing entries.
Be
exact in spelling the names of the parameters and files.

Invoke SYS$MANAGER:AUTOGEN.COM -- Invoke AUTOGEN
the following ways:

one

@SYS$UPDATE:AUTOGEN -- Creates a new AUTOGEN.PAR file
updates the current system parameters and files

and

@SYS$UPDATE:AUTOGEN REBOOT -- In addition,
system using the default bootstrap procedure

reboots

the

@SYS$UPDATE:AUTOGEN SHUTDOWN -- In
the system

shuts

down

and

file

A reboot is necessary to apply the
values to the running system.

addition,

new

parameter

You may also want to adjust the parameter and file values if you
change the hardware configuration of your system (for example, add
more physical memory) or transport the operating system from one
hardware configuration to another. If you are moving the system to
another hardware configuration, you should perform the procedures that
follow on the target configuration:
1.

@SYS$UPDATE:AUTOGEN CONFIG
Redefines
configuration in a new CONFIG.DAT file

@SYS$UPDATE:AUTOGEN GENPAR
Generates a new PARAMS.DAT
file, based on the new configuration (at this point, you can
edit any special requirements into the PARAMS.DAT file)

@SYS$UPDATE:AUTOGEN [REBOOTISHUTDOWN]
Creates
a
new
AUTOGEN.PAR file and updates the current system parameters
and files, optionally rebooting or shutting down the system

12.3.2

the

hardware

User Authorization File

You can affect performance
following UAF entries:

per-user

basis

resetting

•

WSEXTENT -- Maximum working set for the
cannot exceed the system parameter WSMAX

user's

•

WSQUOTA -- Maximum guaranteed working
processes; cannot exceed WSEXTENT

for

•

WSDEFAULT -- Working set
cannot exceed WSQUOTA

•

PRIORITY -- Base priority for the user's processes

•

CPUTIME -- CPU time permitted the user's processes

limit

for

set
the

user's

the

process;
the

user's

processes;

Chapter 2 and the description of the Authorize Utility in the VAX-11
Utilities Reference Manual explain these and the other UAF entries.

TUNING CONSIDERATIONS
12.3.3

DCL Commands

The following DCL commands (which are described in the VAX/VMS Command
Language User's Guide) affect system performance:
Commands

Function

SET WORKING SET/EXTENT
RUN /EXTENT-

Reset working set
extent for the
user's processes;
cannot exceed UAF
extent

SET WORKING SET/QUOTA
RUN /MAXIMUM_WORKING_SET

Reset working set
quota for the
user's processes;
cannot exceed
UAF quota

SET WORKING SET/LIMIT
RUN /WORKING_SET

Reset the working set
default for the user's
processes; cannot
exceed UAF quota

INITIALIZE/QUEUE/BATCH/WSEXTENTl
START/QUEUE/BATCH/WSEXTENTl
SUBMIT/WSEXTENT
$JOB/WSEXTENT

Set working set
extent for jobs
submitted to a batch
queue

INITIALIZE/QUEUE/BATCH/WSQUOTAl
START/QUEUE/BATCH/WSQUOTAl
SUBMIT/WSQUOTA
$JOB/WSQUOTA

Set working set
quota for jobs
submitted to a batch
queue

INITLALIZE/QUEUE/BATCH/WSDEFAULTl
START/QUEUE/BATCH/WSDEFAULTl
SUBMIT/WSDEFAULT
$JOB/WSDEFAULT

Set working set limit
for jobs submitted to a
batch queue

INITIALIZE/QUEUE/BATCH/CPUMAXIMUM
/CPUDEFAULT 1
START/QUEUE/BATCH/CPUMAXIMUM
/CPUDEFAULTl
SUBMIT/CPUTIME
$JOB/CPUTIME

Set the CPU time
permitted batch jobs

SET PROCESS/[NO]SWAPPING

Enables or disables the
swapping in and out of
memory of a process's
working set

SET WORKING_SET/[NO]ADJUST

Enables or disables the
adjustment of a
working set's size

SET/PRIORITY
RUN/PRIORITY

Reset the base priority
of a process

SET RMS_DEFAULT/BLOCK_COUNT

Resets the blocking
factor for VAX-11 RMS
I/O operations

1. These commands require the operator user privilege (OPER).

~UNING

12.3.4

CONSIDERATIONS

Monitor Utility

With the Monitor Utility (MONITOR), you can monitor .activities
indicative of system performance.
Useful displays in this regard
include:
•

PROCESSES (processes display) -- For each current process,
lists the currerit state and priority of the process, the
physical memory being used in terms of shareable pages and
total
pages, the cumulative direct I/O operations, the
cumulative page faults, and the cumulative CPU time

•

IO (I/O system rates) -- Provides the sizes,of the free and
modified page lists, plus the following information, expressed
in cumulative units per interval, per second during the
preceding interval, and per second since the start of the
display: direct I/O operations, buffered I/O operations, page
faults, pages read, read I/O operations, pages written, write
I/O operations, and total pages inswapped

•

PAGE (page management statistics) -- Substantially the same as
I/O SYSTEM RATES, plus the page faults accumulated by the
system working set

•

MODES (time in processor modes) -- Percentage of time spent in
each processor mode, plus idle time

•

POOL (nonpaged pool statistics) -- Amount of unused
the nonpaged dynamic pool

•

STATES
state)

space

(number
of
processes
in
each
scheduler
Provides a snapshot of the state of the system

The VAX-11 Utilities Reference Manual provides operating instructions
and detailed descriptions for the Monitor Utility, and examples of its
use.
The following DCL commands complement the Monitor Utility:
•

SHOW MEMORY -- Displays a synopsis of physical memory usage,
the number of processes and how many are swapped out, pool
usage, paging and swapping file usage, and the physical size
of the system

SHOW MEMORY/POOL/FULL -- Displays detailed information about
the nonpaged dynamic pool, the amount of growth space used,
and the amount of physical memory used

•

SHOW SYSTEM -- Displays information on the processes currently
executing, including state, priority, elapsed CPU time, nu~ber
of page faults, and physical memory'occupied

•

SHOW PROCESS/ACCOUNTING -- Displays information
about
the
executing process, including the cumulative ,number of page
faults, the peak working set size, the peak virtual size,
elapsed total time, and elapsed CPU time

SHOW STATUS -- Displays information
about
the
• process,
including the working set limit, the

•

executing
amount of
time, and the

physical memory being used, the
number of page faults

elapsed

CPU

SHOW WORKING SET -- Displays a
quota, and authorized quota

process's

current

12-9

limit

and

TUNING CONSIDERATIONS
•

LOGOUT/FULL -- Displays information about the
terminating
process, including the number of page faults, the peak working
set size, the peak virtual size, elapsed total time, and
elapsed CPU time

.The VAX/VMS Command Language User's Guide provides
of these commands.

12.4

full

explanations

TUNING SMALL SYSTEMS

As the background discussion indicates, the
factors
affecting
efficient performance are interrelated and somewhat complex. The
major factors for small systems include working set size, page cache
characteristics, priority, quantum, compute swapping rate, and system
use of the system.

12.4.1

Working Set .Size

Decreasing working set limits increases the number of working sets
that can occupy real memory at one time,
reducing the need for
swapping, but increasing the need
(in most cases)
for paging.
Normally, excessive paging is preferable to excessive swapping for the
following reasons:
•

Swapping involves the output and input
pages.

large

numbers

•

Paging does not necessarily involve disk I/O operations due to
the page cache.
In fact, the ratio of disk I/O operations to
page faults may be quite low.

A process can, then, show larger and larger numbers of page faults
with little effect upon performance. Nevertheless, a point does occur
where the reduction of the working set limit significantly degrades a
process's performance. The optimal working set limit, then, would be
just above the point where performance drops sharply.
A two-phase
strategy is recommended for setting working sets at their optimal
sizes:
1.

Figure initial working set limits for
processing on a rule-of-thumb basis.

different

types

Adjust working set limits based on observed behavior.

12.4.1.1 Initial Working Set Limits - For processing involving system
components, the following working set limits are suggested:
•

Small (60 to 200 pages) -- For editing, and for compiling
linking small programs ("typical" interactive processing)

and

•

Large (200 to 500 pages) -- For compiling and linking
programs, and for sorting ("typical" batch processing)

large

Working set limits for user programs depend on the code-to-data ratio
of the program and the amount of data in the program.
Programs that
are mostly code -- that include a small or moderate amount of data, or
use VAX-11 RMS to process data on a per-record basis -- should require
only a small working set. The amount of code should not matter as
long as it is reasonably linear.
Programs that manipulate large
amounts of data internally require large working sets.
12-10

TUNING CONSIDERATIONS
The following guidelines are suggested for initially
set limits:

setting

working

highest

•

System generation parameters -- Set WSMAX
number of pages required by any program.

the

•

UAF options -- For each user, set WSQUOTA at the number of
pages
required to achieve acceptable page faulting for
interactive work.
Set WSEXTENT to the number of pages
required to achieve acceptable page faulting for batch work.
Set WSDEFAULT at the median number of pages required by a
program that the user will run interactively.

•

Batch queues -- For each batch queue, set WSQUOTA (using the
DCL commands INITIALIZE/QUEUE or START/QUEUE) at the largest
number of pages required by a job that users will submit. Set
WSDEFAULT at the median number of pages required by a job that
users will submit.

This arrangement effectively forces users to submit large jobs for
batch processing, as the jobs will not run efficiently when entered
interactively. You can further restrict the user who attempts to run
a large job interactively by imposing CPU time limits in the UAF.

12.4.1.2 Adjustments - The system automatically adjusts working set
limits based on observed behavior and the values of the PFRATL,
PFRATH, WSINC, WSDEC, AWSMIN, and AWSTIME system parameters.
You can monitor system performance and change system parameter
in the following instances:

values

•

Initial limit -- If the system
typically
increases
or
decreases a working set by a significant amount immediately
after its process starts, the default working set limit for
affected
users
and
batch
streams
should be chang7d
accordingly. For example, if a user's working set limit is
100 pages, but the user's processes typically show a working
set limit of 200 for the first few minutes of processing, the
user's default working set value in the UAF should be
increased to 200.

•

Excessive paging I/O activity -- If paging appears to be
generatinq excessive I/O activity, you might decrease the
value of PFRATH to make the working set limit more sensitive
to paging activity. Additionally or alternatively, you might
decrease the value of PFRATL, increase the value of WSINC, or
decrease the value of WSDEC.

•

Excessive swapping I/O activity
If swapping I/O operations
appear high, you might increase the value of PFRATH to make
the working set less sensitive to paging activity.
Working
sets will tend to remain at smaller sizes, perhaps increasing
the number of working sets that will fit in the balance set.
Additionally or alternatively, you might increase the value of
PFRATL, decrease the value of WSINC, or increase the value of
WSDEC.

Monitoring aids for adjusting working set limits include the following
Monitor Utility operations:
PROCESSES
Display
The
size
column
(which
displays
• shareable/total
pages being used by each process) indicates

12-11

TUNING CONSIDERATIONS
what portion of its working set each process requires.
The
state column pinpoints processes having scheduling problems:
a repeated state of PAGE FAULT WAIT, or PFW, may mean that the
working set is too small;
repeated states of COMPUTE (OUT OF
BALANCE SET), or COMO, by several processes usually means that
there are too many users for the available resources or that
their working sets are too large.
See the description of
MONITOR PROCESSES in the Monitor Utility chapter of the VAX-11
Utilities Reference Manual.
•

IO and PAGE displays -- As working set sizes are decreased,
the swapping rate should decrease. As working set sizes are
increased, the swapping rate may increase.
A very high
swapping rate is caused by too many users for available
resources or too low a value for the BALSETCNT system
parameter.
Use the DCL command SHOW MEMORY to ensure that
free process entry slots do not exist when no free balance set
slots exist.
This condition forces swapping and can be
remedied by increasing the number of balance set slots.
If
the number of balance set slots is adequate, the problem is
available resources
(primarily physical memory).
See the
description of MONITOR IO in the Monitor Utility chapter of
the VAX-11 Utilities Reference Manual.

Setting the system parameter WSINC to a value of 0 i'nhibits
working set adjustments for all users.

12.4.2

automatic

Page Cache

The page cache, consisting of the free page list and modified page
list, recirculates pages pushed out of the working set when they are
needed again.
Frequently used pages tend to stay in physical
memory -- either in the working sets (unless outswapped) or in the
page cache -- while less frequently used pages tend to be removed from
memory.
S~ze requirements for the free page list depend mainly on the
amount of code being pushed out of the working set. Size requirements
for the modified page list depend mainly on the amount of data being
pushed out of the working sets. The cluster size for pages being read
from disk to the working sets also affects the efficiency of the page
cache.
·

12.4.2.1 Cache Sizes - The FREELIM system parameter sets the minimum
size of the free page list. The list may expand as space permits.
The FREELIM value set by AUTOGEN is normally adequate.
A high
percentage of page faults resulting in read I/O operations (IO and
PAGE displays) indicates that the value of FREELIM might be increased,
while a small percentage indicates that the value of FREELIM is
correct or might be smaller.
If your system employs swapping, a high
swapping rate
(IO and PAGE_ displays)
indicates that the value of
FREELIM might be reduced to give more space to the balance set.
(However, paging and swapping · I/O might be better regulated by
adjusting working set limits; see Section 12.4.1.2 above.)
The following system parameters regulate the size of the modified page
·list:
•

MPW HILIMIT
Largest size the modified page
permitted to reach before pages are written to disk

12-12

list

TUNING CONSIDERATIONS
•

MPW_LOLIMIT -- Point below which writing of pages stops

•

MPW WRTCLUSTER -- Number of pages the system is
write in one I/O operation

permitted

The parameter values set by AUTOGEN are normally adequate.
You can
monitor the effects of the the size of the modified page list by
watching the write I/O operation and swapping rates on the MONITOR IO
display.
Increasing the upper and lower limits on the modified page
list normally lowers the write I/O operation rate, but may increase
the swapping rate.
You can raise the limits in small increments to
determine whether the changes significantly improve the write I/O
operation rate without significantly degrading the swapping rate.
If
you increase MPW HILIMIT, adjust MPW WAITLIMIT appropriately {see
Chapter 10).
You should not assign arbitrarily high values to FREELIM
and
MPW LOLIMIT, as these values reduce the fluid pages in physical
memory. The system calculates fluid pages by subtracting the resident
system, the system working set, and the minimum size of the page cache
from available physical memory. If the value you specify for WSMAX
exceeds the number of fluid pages, the value is decreased and
automatic nonpaged pool growth is disabled.

12.4.2.2 Cluster Size - The system parameter PFCDEFAULT controls the
number of pages being read from disk to the working sets during one
I/O operation. The values set by AUTOGEN are normally adequate. As a
rule of thumb, you can specify a value of 32 where the median working
set size is 100 pages, and a value of 64 or more where the median
working set size exceeds 200 pages.
A potential problem with a large cluster size is that the pages being
transferred into a working set that has reached its limit push out an
equal number of pages, causing large turnovers of pages in the system.
However, the actual cluster size during any one I/O operation is
limited by other factors, such as the size of the image or section
being transferred.
Only in a few instances do large cluster sizes
adversely affect system performance, but these instances are more than
made up for by the savings in disk I/O that the larger cluster sizes
promote.
For special cases, users can adjust cluster sizes on an individual
basis with the PFC parameter of the CLUSTER option in the linker {for
pages being read from image and section files, not the paging file).

12.4.3

Priority, Quantum, and Compute-bound Swapping Rate

Certain workloads may give processes a disproportionate share of
service.
The problem can be alleviated somewhat by adjustments to
base priorities, the quantum, and the swapping rate for compute-bound
processes.

12.4.3.1 Very Large Working Sets - Running several working sets that
are very large for the amount of physical memory often causes serious
performance degradation. An example might be two batch streams using
{on the averag~) 350-page working sets in a 512KB system. Both batch
streams cannot fit in physical memory at the same time, requiring an
inswap and outswap of 350 pages each time one or the other is granted

12-13

TUNING CONSIDERATIONS
control. The high swapping rate not only slows batch throughpu~, but
increases interactive response time, as these users are also held up
by the contention on the system disk.
When this situation exists, you normally notice a high
(MONITOR IO display).

swapping

rate

The obvious solution to the above problem is to run one batch stream.
However, if two batch streams are essential -- or perhaps the problem
revolves around two very large production programs that must run
concurrently -- you
can improve the situation with one of the
following methods:
•

Priority -- Decreasing the base priorities for the batch
streams from 4 to 3 can result in a better interactive
response time, but will slow batch throughput even more.

•

Quantum -- Increasing the quantum in this situation normally
ensures better service all around. You may find that a rather
large quantum -- 1, 2, or even 3 seconds -- is in order.
The
larger quantum means that the large working sets will be
swapped less frequently.
While interactive
users
must
sometimes wait in blocks of several seconds to be serviced,
this may be an improvement over the previous response time.

•

UAF WSQUOTA -- Lowering the value of WSQUOTA for each process
to the point that both fit in memory allows the swapper to
move pages from one process to the other without having to
swap either. This action increases overall page faulting, but
in moderation should provide better performance.

12.4.3.2 Compute-bound Programs - Contention
among
compute-bound
processes can be alleviated by leaving the quantum at its default
setting and increasing the value of the SWPRATE system parameter to as
much as 3 to 5 seconds. The compute-bound swapping rate sets the
minimum interval (in real time, not processor time) between inswaps of
compute-bound processes. (The system defines a compute-bound process
as one whose current priority is the same as the default base
priority.) A high SWPRATE value under such circumstances should reduce
swapping I/O on the system.
Real-time processes are not affected by the value of the SWPRATE
system parameter, and interactive processes rarely are. They will be
inswapped and outswapped according to priority and quantum.
If a
compute-bound process must make way for an interactive process, it
will be outswapped even if the time specified by its SWPRATE value has
not passed {piovided its quantum has passed) •

12.4.4

System Requirements

You can tune system requirements for time and space by adjusting the
nonpaged dynamic pool, system working set, and VAX-11 RMS buffers.

12.4.4.1 Nonpaged Dynamic Pool - System executive code takes up 150
to 200 pages of physical memory. The nonpaged dynamic pool takes up
another 100 to 400 pages, depending a great deal on the size of the
system.
The system parameters
IRPCOUNT,
IRPCOUNTV,
LRPCOUNT,

12-14

TUNING CONSIDERATIONS
LRPCOUNTV, NPAGEDYN, NPAGEVIR, SRPCOUNT, and SRPCOUNTV determine the
size of the nonpaged dynamic pool. See Chapter 10 for explanations of
these parameters.
During the day-to-day running of the system, you should monitor the
nonpaged dynamic pool with the DCL command SHOW MEMORY/POOL/FULL.
If
a large amount of unused space continually exists in the pool, you can
reduce NPAGEDYN or the appropriate xRPCOUNT parameter. If very little
unused growth space exists in the pool, you should increase NPAGEVIR
or the appropriate xRPCOUNTV parameter.
Running out of space in the nonpaged dynamic pool degrades service
more than using some extra space to ensure that this condition does
not occur. If the nonpaged dynamic pool is depleted (the size of the
pool reaches the limit imposed by NPAGEVIR), processes needing space
from the pool will be placed in a miscellaneous resource wait
(MWAIT)
state until sufficient memory is returned to the pool by other
processes or by the completion of I/O services.
If many processes
enter an MWAIT state, you may be forced to reboot the system.

12.4.4.2 System Working Set • The system also requires a working set
for the pageable portions of the executive, the paged dynamic pool,
VAX-11 RMS, and the resident portion of the system message file.
The
SYSMWCNT system parameter controls the upper limit (quota} of this
working set. Although you usually would not reduce the fluid pages
available to the system, SYSMWCNT should be set at a reasonable value.
If programs start waiting for the completion of system services,
performance degradation is likely to be sharp.
During run-time
activities, the system automatically decreases the limit if the page
fault rate is low, depending on the values of the PFRATL, PFRATH,
WSINC, WSDEC, AWSMIN, and AWSTIME system parameters.
An optimal quota for SYSMWCNT varies depending on how the user
programs are using the system.
Factors dictating a larger size
include high use of VAX-11 RMS
(especially ISAM services), a high
number of logical names, and extensive placement of record locks.
You can monitor the system page fault rate by observing the rate of
system page faults on the PAGE MANAGEMENT STATISTICS display with the
MONITOR PAGE command (see the Monitor·Utility chapter in the VAX-11
Utilities Reference Manual).
The system page fault rate should be
kept low (two faults per second or less on average
peaks may be
higher} •

12.4.4.3 VAX-11 RMS Buffers - Where VAX-11 RMS operations are mainly
random accesses of single small records, a process can decrease its
VAX-11 RMS multiblock count to 1 with the DCL command SET RMS DEFAULT.
This action reduces the size of the VAX-11 RMS buffer required in
memory. However, the value of the RMS DEFAULT system parameter should
be left at 16. For more information on tuning systems using VAX-11
RMS, see the VAX-11 Record Management Services Tuning Guide.

12.5

TUNING LARGE SYSTEMS

The major strategy in tuning a large system lies in trading more
memory for less I/O.
On an individual level, programs should either
maintain larger data structures mapped into memory from section files
(in place of per-record processing by means of VAX-11 RMS), or

12-15

TUNING CONSIDERATIONS
increase the multibuffer count and specify read-ahead and write-behind
processing for VAX-11 RMS operations.
You should install as many
programs as possible with the shared and header-resident attributes.
On a system-wide basis, you should allot as much memory as practical
to the Files-11 ACP data structures, primarily the header, directory,
map, file identification, extent, and quota caches. The sections that
follow provide guidelines for setting values for the ACP system
parameters (see also Chapter 10).
The sy~tem parameters, UAF entries, and DCL commands affecting working
set size, the page cache, priority, the quantum, the compute swapping
rate, the nonpaged dynamic pool, the system working set, and the
VAX-11 RMS buffers should, for the most part, be left at their
standard values. Any changes should favor increasing the amount of
physical
memory
available
to system and user processes.
In
particular, you should prov'ide working set default and quota values,
and PFRATL, PFRATH, WSINC, WSDEC, AWSMIN, and AWSTIME system parameter
values that m1n1m1ze paging I/O,
although limit and quota values
should not be set arbitrarily or unreasonably high.
On a large
system, you should be able to minimize paging I/O without increasing
swapping I/O.
(If swapping I/O does increase, however, you should
adjust working set limits as described in Section 12.4.1)

12.5.1

Header Cache

Because a file header, once accessed,
is likely to require more
accesses as the file continues to be processed, maintaining header
blocks (one block per page) in memory can save a significant amount of
I/O. The following system parameters control tne header cache:
•

ACP WRITEBACK -- This switch should be set to a value of 1 to
enable the deferred writing of file header blocks, which
inhibits the write I/O operation for the file header that
otherwise occurs each time a file is extended. The header is
al~ays written when the file is closed.
Headers for relative
and indexed files are always written when the file is
extended. A risk is taken in that the file may be lost if a
header has never been written and the sytem fails.
This loss
is usually not serious, since the file is probably in an
inconsistent state.
The value set by AUTOGEN is normally
adequate.

•

ACP HDRCACHE -- The number of header blocks should equal or
exceed the number of files that are likely to be open
concurrently. You can calculate this value as the product of
the number of concurrent users and the median number of files
each user accesses concurrently.
Reasonable values for a
system configured for 48 to 64 users fall in the range of 80
to 200. The default value of deferred writing is normally
adequate.

Even on a small system, you should try to allot extra pages to the
header cache, as the expenditure in memory is well worth the I/O
operations saved.

12.5.2

Directory Cache

Because a directory block, once accessed, is likely to require more
accesses as files continue to be processed, maintaining directory
blocks (one block per page) in memory can save a significant amount of
I/O.

12-16

TUNING CONSIDERATIONS
The ACP DIRCACHE system parameter specifies the size of the directory
cache. - As with ACP HDRCACHE, you should set a value that equals or
exceeds the number of directories that are likely to be accessed
concurrently. The value set by AUTOGEN is normally adequate.
The size of the directory cache stands next to the size of the
cache in importance in reducing Files-11 ACP I/O activity.

12.5.3

header

Quota Cache

If disk quotas are being enforced, you should cache one quota entry
per active user.
The ACP_QUOCACHE system parameter specifies the
number of entries cached. One page holds 16 quota entries, so that,
for example, a specification of 64 requires 4 pages of storage. The
value set by AUTOGEN is normally adequate.

12.5.4

System Directory Cache

The ACP SYSACC parameter specifies the number of directories for which
to save access data on a volume mounted with the /SYSTEM qualifier.
Its value can be overridden.with the /ACCESS qualifier in the DCL
command MOUNT. It should be set to the number of directories expected
to be in active use on a system volume at one time.
Each unit
requires 96 bytes of nonpaged pool. However, too low an ACP SYSACCESS
or /ACCESS value partially negates the benefit of the ACP DIRCACHE
parameter.

12.5.5

Multiple ACPs

Multiple ACPs (that is, duplicate Files-11 ACPs)
for the same disk
types are almost never worthwhile. The memory spent on the extra ACP
would be better spent on increasing the cache sizes of the first ACP.
However, a separate ACP for slower disks may be worthwhile, as it
prevents operations on the faster disks from being held up by an ACP
clogged with requests for operations on the slower disks.

INDEX

Account,
to create, 2..:.10
to delete, 2-11
to disable, 2-12
username, 2-5
Accounting,
record types, 4-16
system, 4-16
Accounting Utility
(ACCOUNTING), 4-16
ACNT privilege, 4-8
ACP parameters, 10-16
ACP system parameters,
10-13 to 10-16
summary, 10-10
Active system,
modification of, 11-3
Add a new account, 2-4
Allocate access, 3-2
Allocation,
of device, 3-11
ALLSPOOL privilege, 4-8
ALTPRI privilege, 4-8
Announcements,
site specific start-up, 7-16
ASSIGN/QUEUE command, 8-9,
8-11
AST queue limit, 4-2
Authorize Utility (AUTHORIZE),
2-10
default qualifiers, 2-10
AUTOCONFIGURE command, 11-3
AUTOGEN.COM command procedure,
12-5
AUTOGEN.PAR parameter file,
creation of, 11-2
AWSMIN parameter, 10-16
AWSTIME parameter, 10-17

Batch queue (Cont.)
to start, 8-5
to stop, 8-5
BJOBLIM parameter, 10-17
Bootstrap,
system, 7-1
BORROWLIM parameter, 10-17
Buffered I/O byte count limit,
4-2
Buffered I/O count limit, 4-2
BUGCHECKFATAL parameter, 10-17
BUGCHK privilege, 4-9
BUGREBOOT parameter, 10-18
BYPASS privilege, 4-9

Cache,
size,
tuning small systems,
12-12
Card,
decks, 8-26
defective, 8-28
Card reader,
tending, 8-27
to operate, 8-28
translation modes, 8-27
using, 8-25
CLISYMTBL parameter, 10-18
Cluster size,
tuning small systems, 12-13
CMEXEC privilege, 4-9
CMKRNL privilege, 4-9
COBOL-74,
required logical names, 7-13
Command,
summary of queue control,
8-2

BALSETCNT parameter, 10-17
Batch job, 8-1, 8-4
job card, 8-26
output, 8-26
standard, 7-15
to encourage use, 8-6
to terminate, 8-23
Batch queue,
control commands, 8-20
creation of, 8-5
deletion of, 8-6
guidelines, 8-7
multiple, 8-4
procedures for control, 8-21
to remove job, 8-24
Index-1

Command procedure,
login, 2-7
logout, 2-9
start-up, 7-10
Common event flag cluster,
protection of, 3-8
Component,
of operating system, 1-3
Compute-bound program,
tuning small systems, 12-14
Compute-bound swapping rate,
tuning small systems, 12-13
Concealed device, 7-13
CONNECT command, 11-3
CONNECT CONSOLE command, 11-4
Console terminal, 1-3

INDEX

Control,
of other processes, 3-11
CPU time,
limit on, 4-3
CRASH command file, 7-7
CRDENABLE parameter, 10-18
Create access, 3-2
CREATE command, 11-4

Disable user account, 2-12
Disk volume,
public, 7-13
DISMOUMSG parameter, 10-19
Dump file, 11-4
size, 11-6
DUMPBUG parameter, 10-19
DYNAMIC parameters, 11-3

Data card deck, 8-27
DCL (DIGITAL Command
Language) ,
commands,
and system performance,
12-8
system management summary,
1-5
DEADLOCK WAIT parameter, 10-18
Debugger-;
required logical names, 7-11
Default,
directory, 2-6
protection, 3-6
user authorization file, 2-2
DEFAULT account,
initial modifications, 2-4
user authorization file
entry, 2-2
DEFMBXBUFQUO parameter, 10-18
DEFMBXMXMSG parameter, 10-18
DEFMBXNUMMSG parameter, 10-19
DEFPRI parameter, 10-19
Delete access, 3-2
DELETE/ENTRY command, 8-2
Deletion,
of batch queues, 8-6
of known images, 6-4
of user account, 2-11
DETACH privilege, 4-10
Device,
allocation, 3-11
concealed, 7-13
site specific start-up, 7-14
spooled, 8-2
status report, 9-9
Device drivers,
to connect, 11-3
Devour privileges, 4-7
DIAGNOSE privilege, 4-10
Direct I/O count limit, 4-3
Directory,
cache in,
tuning large systems,
12-16
deletion, 3-17
operating system, 1-3
protection, 3-7, 3-16

Enqueue quota limit, 4-3
Equivalence name, 3-13
ERRFMT process, 9-1
Error, 9-1
Error log file, 9-1
maintenance of, 9-3
printing, 9-3
to read, 9-2
Error logger,
required logical names, 7-11
Executable image, 6-1
Execute access, 3-2
EXQUOTA privilege, 4-10
EXTRACPU parameter, 10-19

TnnAY-?

FIELD account,
initial modifications, 2-3
user authorization file
entry, 2-2
File,
default protection, 3-6
Files privileges, 4-7
Files-11 files,
UIC protection, 3-6
Foreign volumes,
protection of, 3-10
Forms control, 8-12
FREEGOAL parameter, 10-19
FREELIM parameter, 10-19

GBLPAGES parameter, 10-20
GBLPAGFIL parameter, 10-20
GBLSECTIONS parameter, 10-21
Group,
protection category, 3-1
UIC, 3-14
GROUP privilege, 4-7, 4-10
and process control, 3-11
GROWLIM parameter, 10-21
GRPNAM privilege, 4-10

INDEX

Hardware problems, 7-2
Hardware resources,
workloads, 12-2
Header cache,
tuning large systems, 12-16
Header resident image, 6-1
Help file,
required logical names, 7-11

IJOBLIM parameter, 10-21
Image,
executable, 6-1
file, 6-4
header resident, 6-1
known, 6-1
shareable, 6-1
Individual login command
procedure, 2-7
Input spooling, 8-3
Install Utility, 6-1
Installation,
of known file lists, 6-3
Interactive account,
add new, 2-4
Interprocess control, 3-11
INTSTKPAGES parameter, 10-21
IRPCOUNT parameter, 10-22
IRPCOUNTV parameter, 10-22

JOB card, 8-26
Job controller,
required logical names, 7-11
restart, 8-25
JOB system parameters,
summary, 10-9
JOBQUEUES parameter, 10-22

KFILSTCNT parameter, 10-22
Known file list, 6-2
privileges, 6-3
startup procedure, 6-3
Known image, 6-1
deletion of, 6-4
dismount volumes of, 6-4
site specific start-up, 7-14

LAMAPREGS parameter, 10-22
Large systems,
tuning, 12-15
Large working sets,
tuning small systems, 12-13

Limit,
AST queue, 4-2
buffered I/O byte count, 4-2
buffered I/O count, 4-2
CPU time, 4-3
direct I/O count, 4-3
enqueue quota, 4-3
on system resource, 4-1
open file, 4-4
paging file, 4-4
subprocess creation, 4-4
summary of system, 4-2
timer queue entry, 4-4
working set default, 4-4
working set extent, 4-5
working set quota, 4-5
Limits,
DEFAULT account, 2-11
Line printer,
characteristics, 8-13
site specific start-up,
7-14
out of paper, 8-22
List,
known file, 6-2
LOAD command, 11-3
LOCKIDTBL parameter, 10-23
Log file,
accounting, 4-16
LOGGHASHTBL parameter, 10-23
Logical I/O,
access, 3-2
Logical name, 3-13
debugger, 7-11
system-wide, 7-13
Login command procedure, 2-7
alternate, 2-13
Login sequence, 2-2
LOGIO privilege, 4-11
Logout command procedure, 2-9
LOGPHASHTBL parameter, 10-23
LOGSHASHTBL parameter, 10-23
LONGWAIT parameter, 10-23
LRPCOUNT parameter, 10-24
LRPCOUNTV parameter, 10-24
LRPSIZE parameter, 10-24

MA780 Multiport memory,
installation of shared
images, 6-5
Machine-readable files,
for software performance
reports, 9-13
Mailbox,
protection of, 3-7
MAJOR system parameters,
summary, 10-2

INDEX

MAXBUF parameter, 10-24
MAXPRINTSYMB parameter, 10-25
MAXPROCESSCNT parameter, 10-25
MAXSYSGROUP parameter, 10-25
Memory management,
figure, 12-3
Merging print queues, 8-21
Message,
operator log file, 9-8
operator reply, 9-10
user request, 9-10
MINWSCNT parameter, 10-25
Monitor Utility (MONITOR),
12-9
MOUNT privilege, 4-11
MOUNTMSG parameter, 10-25
MPW HILIMIT parameter, 10-25
MPW-LOLIMIT parameter, 10-26
MPW-THRESH parameter, 10-26
MPW-WAITLIMIT parameter, 10-26
MPW-WRTCLUSTER parameter,
-10-26
Multiple ACPs,
tuning large systems, 12-17
Multiport memory,
SYSGEN commands, 11-7
MVTIMEOUT parameter, 10-27

NETMBX privilege, 4-11
New account,
authorize, 2-4
NJOBLIM parameter, 10-27
Nonf ile devices,
protection of, 3-11
Nonpaged dynamic pool,
tuning small systems, 12-14
Normal privilege, 4-6
NPAGEDYN parameter, 10-27
NPAGEVIR parameter, 10-27

OPCCRASH, 7-3
OPCOM (Operator Communication
Facility),
restarting, 9-8
system process, 9-7
Open file limit, 4-4
OPER privilege, 4-11
Operating system,
components, 1-3
directories, 1-3
Operator,
terminal,
to enable and disable, 9-9
Operator, system,
reply message, 9-10

Index-4

Operator (Cont.)
tasks, 1-2
terminal, 1-3
Operator log file, 9-6
device status message, 9-9
initialization message, 9-9
maintenance, 9-7
messages, 9-8
printing, 9-7
purge of, 7-15
Output spooling, 8-3
Owner,
protection category, 3-1

Page cache,
tuning small systems, 12-12
Page fault, 12-4
Page size,
print queues, 8-11
PAGEDYN parameter, 10-27
PAGFILCNT parameter, 10-28
Paging file, 11-4
size, 11-5
Paging file limit, 4-4
PAPOLLINTERVAL parameter,
10-28
PAPOOLINTERVAL parameter,
10-28
Parameter file,
creation of, 11-2
Parameters,
system, 10-1, 10-13 to 10-45
PASCAL,
required logical names, 7-14
Password,
authorize, 2-5
PASSWORD card, 8-26
PASTDGBUF parameter, 10-28
PASTIMOUT parameter, 10-28
PASTRETRY parameter, 10-29
Performance,
system, 12-1
Personal Mail Utility (MAIL),
protection, 3-7
PFCDEFAULT parameter, 10-29
PFNMAP privilege, 4-12
PFRATH parameter, 10-29
PFRATL parameter, 10-29
PHY IO privilege, 4-12
Physical I/O,
access, 3-2
PQL parameters, 10-30 to 10-34
PQL system parameters,
summary, 10-11
PRINT command, 8-9
Print job, 8-1
to terminate, 8-24

INDEX

Print queue, 8-9
assignment, 8-11
control commands, 8-20
creation of, 8-10
deassignment, 8-11
deletion of, 8-10
forms control, 8-12
guidelines, 8-13
page length of compatibility
mode listings, 8-12
page length of native mode
listings, 8-11
printer characteristics,
8-13
printer out of paper, 8-22
procedures for control, 8-21
saving data, 8-22
to empty, 8-11
to merge, 8-21
to remove job, 8-24
to start, 8-10
to stop, 8-10
to terminals, 8-9
vertical page size, 8-11
Priority,
base, 4-5
tuning small systems, 12-13
Privilege,
all, 4-7
known file lists, 6-3
process, 4-6
summary, 4-6
system management, 1-4
Privileged image, 6-1
PRMCEB privilege, 4-12
PRMGBL privilege, 4-13
PRMMBX privilege, 4-13

Protection (Cont.)
user categories, 3-3
·pswAPM privilege, 4-13
Public volumes, 7-13

Probl~ms,

hardware, 7-2
software, 7-2
Process,
priority, 4-5
Process privilege, 4-6
PROCSECTCNT parameter, 10-34
Protection, 3-1
access categories, 3-3
and the RENAME command, 3-6
common event flag cluster,
3-8
explicit, 3-6
foreign volumes, 3-10
mail file, 3-7
mailbox, 3-7
mask, 3-1
nonfile devices, 3-11
of directories, 3-7
section, 3-8
specification of, 3-3
structured volume, 3-9

Index-5

QUANTUM parameter, 10-34
tuning small systems, 12-13
Queue, 8-1
control command summary, 8-2
site specific start-up, 7-14
to empty file, 8-6
to remove job, 8-24
Quota cache,
tuning large systems, 12-17

Read access, 3-1
Real-time priority, 4-5
REALTIME SPTS parameter, 10-34
REINITQUE parameter, 10-34
Remove job from queue, 8-24
REPLY/ENABLE command, 9-9
REPLY/LOG command, 9-9
REQUEST command, 9-10
Required logical name, 7-11
COBOL-74, 7-13
PASCAL, 7-14
RSX-llM programs, 7-11
RESHASHTBL parameter, 10-35
Resource,
limit, 4-1
Restart,
job controller, 8-25
OPCOM, 9-8
system, 7-1
RJOBLIM parameter, 10-35
RMS buffers,
tuning small systems, 12-15
RMS parameters, 10-35 to 10-36
RMS system parameters,
summary, 10-10
RSX-llM program,
required logical names, 7-11
Running system,
modification of, 11-3

SCS parameters, 10-36 to 10-38
SCS system parameters,
summary, 10-12
SDA (System Dump Analyzer) ,
site specific startup, 7-15
Section,
protection of, 3-8

INDEX

Security,
system devices, 3-16
security,
system data, 3-15
SET QUEUE command, 8-1
SET/STARTUP command, 11-6
SETPRV privilege, 4-14
SETTIME parameter, 10-38
SHARE command, 11-7
guidelines, 11-8
Shareable image, 6-1
file, 6-4
with MA780 multiport memory,
6-5
Shared memory,
SYSGEN commands, 11-7
SHMEM privilege, 4-14
SHOW QUEUE command, 8-1
SHOW/STARTUP command, 11-6
Shutdown,
by forced system failure,
7-7
emergency, 7-3, 7-6
site-specific, 7-3
system, 7-1, 7-3
SHUTDOWN.COM command
procedure, 7-3
Site specific start-up, 7-12
Small systems,
tuning, 12-10
Software Performance Report
(SPR) ,
See SPR
Software problems, 7-2
reporting, 9-11
Spooled device,
guidelines for line
printers, 8-13
site specific start-up, 7-14
to establish, 8-3
to turn off, 8-4
Spooling, 8-1 to 8-2
input, 8-3
output, 8-3
SPR (Software Performance
Report) , 9-11
classes of problems, 9-15
description of problem
environment, 9-13
what to include, 9-14
SPTREQ parameter, 10-38
SRPCOUNT parameter, 10-38
SRPCOUNTV parameter, 10-39
Start-up,
command procedure, 7-1
Start-up command procedure,
7-10
known file lists, 6-3
SYSGEN commands, 11-6

Tnnov-~

Startup,
alternate command procedure
for, 7-2
site specific, 7-12
system, 7-1
STARTUP.COM command procedure,
7-1, 7-10
Status information, 3-14
STOP/QUEUE command, 8-21
Structured volume,
protection of, 3-9
Subprocess creation limit, 4-4
SWAPFILES.COM coomand
procedure, 11-4
Swapping file, 11-4
size, 11-6
SWPFILCNT parameter, 10-39
SWPOUTPGCNT parameter, 10-39
SYE Utility, 9-1
Symbiont,
description of, 8-3
Symbolic Debugger,
required logical names, 7-11
SYS system parameters,
summary, 10-4
SYS$ANNOUNCE logical name,
7-16
SYS$WELCOME logical name, 7-16
SYSGBL privilege, 4-14
SYSGEN,
See System Generation
Utility
SYSGEN parameters,
See System parameters
SYSHUTDWN.COM command
procedure, 7-3
SYSLCK privilege, 4-14
SYSMWCNT parameter, 10-39
SYSNAM privilege, 4-14
SYSPRV privilege, 4-15
SYSTARTUP.COM command
procedure, 7-12
System,
accounting, 4-16
data protection, 3-15
device protection, 3-16
directories, 1-3
errors, 9-1
files, 11-4, 12-5
generation, 11-1
library logical names, 7-11
modific~tion of image, 11-3
parameter file
(AUTOGEN.PAR), 11-2
parameters, 12-5
performance, 12-1, 12-3
protection category, 3-1
shutdown, 7-1, 7-3
start-up, 7-12

INDEX

System (Cont.)
startup, 7-1
SYSTEM account,
initial modifications, 2-3
user authorization file
entry, 2-2
System directory cache,
tuning large systems, 12-17
System failure,
forced, 7-7
reporting, 9-11
system dump analyzer, 7-15
System files,
size, 11-5
System Generation Utility
{SYSGEN) , 11-1
operator log file, 9-11
System parameter, 10-1
categories, 10-1
to change, 9-11
used at bootstrap time, 11-1
System privilege, 4-7
System processes,
ERRFMT, 9-1
OPCOM, 9-7
System requirements,
tuning small systems, 12-14
System working set,
tuning small systems, 12-15
System-wide,
login command procedure, 2-7
System-wide logical names,
assignment of, 7-13
site specific startup, 7-13
SYSTEST account,
initial modifications, 2-3
user authorization file
entry, 2-2

Terminal,
console, 1-3
operator, 9-9
operator's, 1-3
site specific start-up, 7-14
Throughput, 12-2
TIMEPROMPTWAIT parameter,
10-39
Timer queue entry limit, 4-4
TMPMBX privilege, 4-15
Tools,
tuning, 12-5
Translation modes,
card reader, 8-27
TTY parameters, 10-40 to 10-43
TTY system parameters,
summary, 10-7

Index-7

Tuning, 12.;..l
large systems, 12-15
small systems, 12-10
system throughput, 12-2
tools, 12-5
workload distribution, 12-2
Turnkey account,
add new, 2-4

UAF {User Authorization File),
and system performance, 12-7
contents of, 2-1
general maintenance, 2-3
initial contents, 2-2
initial modifications, 2-3
privileges, 4-6
resource limits, 4-1
user priorities, 4-5
UAFALTERNATE parameter, 10-43
UDABURSTRATE parameter, 10-43
UIC {User Identification
Code) ,
authorize, 2-6
special meaning, 3-3
specification of, 3-2
UIC-based protection, 3-1
User,
request message, 9-10
User account,
authorize, 2-1
to delete, 2-11
to disable, 2-12
User Authorization File,
See UAF
User files,
protection, 3-16
User Identification Code,
See UIC
User privileges,
system management, 1-4
User-specified login command
procedure, 2-7
USER3 parameter, 10-44
USER4 parameter, 10-44
USERDl parameter, 10-43
USERD2 parameter, 10-44
Utility,
system management summary,
1-9

VAX-11 RMS buffers,
tuning small systems, 12-15
VAX/VMS,
memory configuration, 12-3

INDEX

VIRTUALPAGECNT parameter,
10-44
VOLPRO privilege, 4-15

12-10
Workload distribution, 12-2
World,
protection category, 3-1
WORLD privilege, 4-16
and process control, 3-11
Write access, 3-2
WRITE ACTIVE command, 11-3
WSDEC parameter, 10-44
WSINC parameter, 10-44
WSMAX parameter, 10-45

Working set,
default, 4-4
extent, 4-5
limits,
tuning small systems,
12-10
quota, 4-5
size,
tuning small systems,

XFMAXRATE parameter, 10-45

Index-8

VAXNMS System Management
and Operations Guide
AA-M547A-TE
READER'S COMMENTS
NOTE: This form is for document comments only. DIGITAL will use comments submitted on this form at the
company's discretion. If you require a written reply and are eligible to receive one under Software
Performance Report (SPR) service, submit your comments on an SPR form.

Did you find this manual understandable, usable, and well organized? Please make suggestions for improvement.

Did you find errors in this manual? If so, specify the error and the page number.

Please indicate the type of user/reader that you most nearly represent.

D
D
D
D
D
D

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify)

Organization
Street
State ______ Zip Code-----or Country

Do Not Tear- Fold Here and Tape -

mn~nomn

No Postage
Necessary
if Mailed in the
United States

111111

BUSINESS REPLY MAIL
FIRST CLASS PERMIT N0.33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

BSSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03061

Do Not Tear - Fold Here