Digital PDFs

AA-Y507B-TE

April 1986

324 pages

Original

35MB

Document:	VMS 4.4 VAX VMS System Managers Reference Manual
Order Number:	AA-Y507B-TE
Revision:
Pages:	324
Original Filename:	https://archive.org/download/stx_AA-Y507B-TE_VMS_4.4_VAX_VMS_System_Managers_Reference_Manual_Apr86/AA-Y507B-TE_VMS_4.4_VAX_VMS_System_Managers_Reference_Manual_Apr86.pdf

OCR Text

VAX/VMS
System Manager's
Reference Manual
Order Number: AA-Y507B-TE

April 1986
This manual is a conceptual and tutorial reference for users responsible for
managing and operating a VAX/VMS system.

Revision/Update Information:

This is a revision of the Version 4.0
manual.

Software Version:

VAX/VMS Version 4.4

digital equipment corporation
maynard, massachusetts

April 1986

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.

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
DEC/MMS
DECnet
DECsystem-10
DECSYSTEM-20
DECUS
DECwriter

DIBOL
EduSystem
IAS
MASSBUS
PDP
PDT
RSTS
RSX

UNIBUS
VAX
VAXcluster
VMS
VT

HBSQQBD
ZK-2813

HOW TO ORDER ADDITIONAL DOCUMENTATION
DIRECT MAIL ORDERS
USA & PUERTO RICO*

CANADA

INTERNATIONAL

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

Digital Equipment
of Canada Ltd.
100 Herzberg Road
Kanata, Ontario K2K 2A6
Attn: Direct Order Desk

Digital Equipment Corporation
PSG Business Manager
c/o Digital's local subsidiary
or approved distributor

In Continental USA and Puerto Rico call 800-258-1710.
In New Hampshire, Alaska, and Hawaii call 603-884-6660.
In Canada call 800-267-6215.
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 (SDC), Digital Equipment
Corporation, Westminster, Massachusetts 01473.
This document was prepared using an in-house documentation production system. All page
composition and make-up was performed by T^X, the typesetting system developed by
Donald E. Knuth at Stanford University. T^X is a registered trademark of the American Mathematical
Society.

Contents
PREFACE

xvii

NEW AND CHANGED FEATURES

xxi

SECTION 1

INTRODUCTION

1-1

1.1 SYSTEM MANAGEMENT TASKS
1.1.1
Operational Tasks _
1.1.2
Tools and Privileges _
1.1.2.1
1.1.2.2
1.1.2.3

1.1.3

PART I

1-1
1-2
1-2

DIGITAL Command Language Commands • 1-2
VAX/VMS Utilities • 1-3
Privileges* 1-3

VAX/VMS Operating System Components

1-3

SETTING UP THE SYSTEM

SECTION 2 CUSTOMIZING THE OPERATING SYSTEM AFTER
INSTALLATION

2-1

2.1 LOGGING IN TO THE SYSTEM

2-2

2.2 STARTUP COMMAND PROCEDURES
2.2.1
Site-Independent Startup Command Procedure _
2.2.2
Device Configuration Command Procedure _
2.2.3
Site-Specific Startup Command Procedure _

2-3
2-4
2-4
2-5

CREATING YOUR SITE-SPECIFIC STARTUP COMMAND
PROCEDURE
2.3.1
Mountina Public Disks
2.3.2
2.3.3
2.3.4
2.3.5
2.3.6
2.3.7
2.3.8

Assigning Systemwide Logical Names
Setting Devine Characteristics
Initializing and Starting Queues
Installing Known Images
Running the System Dump Analyzer
Maintaining the Operator's Log File
Submitting Standard Batch Jobs

2-5
2-6
2-6
2-7
2-7
2-8
2-8
2-8
2-8

iii

Contents

Connecting Devices and Multiport Memory Units
2.3.9
2.3.10 Installing Secondary Page and Swap Files
2.3.11 Providing Announcements
2.3.11.1
SYS$ANNOUNCE • 2-9
2.3.11.2 SYS$WELCOME • 2-10
2.3.12 Redefining the Number of Interactive Users
2.3.13 Terminating SYSTARTUP.COM

2-10
2-10

2.4

SELECTING A DEFAULT BOOTSTRAP COMMAND PROCEDURE

2-11

2.5

MODIFYING A DEFAULT BOOTSTRAP COMMAND
PROCEDURE

2-12

2.6

PERFORMING MODIFICATIONS FOR SPECIAL CONFIGURATIONS
OR WORKLOAD REQUIREMENTS
2.6.1
Modifying Dual-RL02 Systems to Handle Crash
Dumps
2.6.2
Redefining the Line Printer on a VAX-11/730

2-9
2-9
2-9

2-13
2-13
2-13

2.7

REBOOTING TO INSTALL SYSTEM MODIFICATIONS

2-14

2.8

BACKING UP THE SYSTEM
2.8.1
Backing Up the Console Volume _
2.8.1.1
Console Volume Backups for Single-Drive
Console Subsystems • 2-15
2.8.1.2
Console Volume Backups for Dual-Drive Console
Subsystems • 2-17
2.8.2
Backing Up the System Disk _
2.8.2.1
Installing Standalone BACKUP in Alternate
System Root SYSE • 2-19
2.8.2.2
Creating a Command Procedure to Bootstrap
Standalone BACKUP • 2-19
2.8.2.3
Boqtstrapping Standalone BACKUP
from SYSE • 2-20
2.8.2.4
Building a Standalone BACKUP Kit on
Console Media • 2-21
2.8.2.5
Bootstrapping Standalone BACKUP from
Console Media • 2-23
2.8.3
Building and Copying a VAX/VMS System Disk _
2.8.3.1
Building the Operating System on
Another Disk • 2-25
2.8.3.2
Copying the Operating System Files to
Another Disk • 2-26
2.8.3.3
Adding an Operating System to an Existing
System Disk • 2-27

2-15
2-15

2-18

2-24

Contents

SECTION 3 CUSTOMIZING SMALL-DISK SYSTEMS

3-1

3.1

DIGITAL-SUPPLIED FILE GROUPS

3-1

3.2

CREATING SITE-SPECIFIC FILE GROUPS

3-3

3.3

TAILORING COMMANDS

3-4

3.4 SPECIAL OPERATIONS FOR SMALL-DISK SYSTEMS
3.4.1
Preparing to Run the UETP _
3.4.1.1
3.4.1.2

3.4.2
3.4.3

3.4.4
3.4.5

Running the UETP from the Library Disk • 3-11
Running the UETP from the System Disk *3-12

Enabling Job Queues _
Analyzing System Failures _
3.4.3.1
3.4.3.2

3-11
3-11

3-12
3-13

Setting the SAVEDUMP Parameter *3-13
Saving the Dump for Analysis *3-13

Installing Image Files with Privileges _
Copying Images Needed for DCL Commands to the
System Disk _

3-14
3-15

3.5 ERROR AND INFORMATIONAL MESSAGES FROM THE TAILORING
FACILITY
3-20

SECTION 4 SHUTDOWN AND STARTUP
4.1

SHUTTING DOWN THE OPERATING SYSTEM
4.1.1
OrderlyShutdownwithSHUTDOWN.COM _
4.1.2
Emergency Shutdown with OPCCRASH _
4.1.3
Emergency Shutdown with CRASH on VAX-11/730,
VAX-11/780 Systems _
4.1.4
Emergency Shutdown with CRASH on VAX 8600,
VAX 8650 Systems _
4.1.5
Emergency Shutdown with CRASH on VAX—11/750
Systems _

BOOTSTRAPPING THE SYSTEM

4-1

4-1
4-1
4-5
4-6
4-8
4-9

4-9

4.2.1

Default BootstraD

4-10

4.2.2
4.2.3

Alternate Nonstop Bootstrap

4-10

Alternate Conversational Bootstrap

4-11

Contents

4.2.4

Bootstrapping an HSC Disk
4.2.4.1
4.2.4.2
4.2.4.3
4.2.4.4

4.2.5

4-13

Bootstrapping a VAX-11/780 with Interleaved
Memory _

4-18

4.3 RESTARTING PROBLEMS
4.3.1
Hardware Problems _
4.3.2
Software Problems _

4-18
4-18
4-19

SECTION 5
5.1

MANAGING SYSTEM USERS

5-1

USER AUTHORIZATION FILE
5.1.1
System-Supplied UAF Records
5.1.2
General Maintenance of the UAF

5-1
5-3
5-3

5.2 PREPARING TO ADD A USER ACCOUNT
5.2.1
User Name and Password _
5.2.2
User Identification Code _
5.2.3
Disk Quota Entry _
5.2.4
User Directory and Default File Specification _
5.2.5
Login Command Procedures for Interactive Accounts _
5.2.6
Login Command Procedures for Turnkey Accounts _
5.2.7
Logout Command Procedures _

5-4
5-5
5-6
5-6
5-6
5-7
5-10
5-10

5.3 USING AUTHORIZE TO ADD A USER ACCOUNT

5-10

5.4 USING A COMMAND PROCEDURE TO ADD A USER ACCOUNT

5-12

5.5 MAINTAINING THE USER ENVIRONMENT
5.5.1
Creating Additional Default Record Templates _
5.5.2
Deleting a User Account _
5.5.3
Disabling a User Account _
5.5.4
Recovering Lost Files _
5.5.5
Restricting the Use of Accounts _

5-14
5-15
5-15
5-17
5-17
5-18

5.5.5.1
5.5.5.2
5.5.5.3

Bootstrapping an HSC Disk on a VAX-11/780
During an Installation *4-14
Bootstrapping an HSC Disk on a Running
VAX-11/780 • 4-14
Bootstrapping an HSC Disk on a VAX-11 /750
During Installation • 4-16
Bootstrapping an HSC Disk on a Running
VAX-11/750 • 4-16

Setting Day Types • 5-19
Restricting Logins to Specific Times • 5-19
Restricting Login Functions • 5-20

Contents

5.6

UAF LOGIN CHECKS

5-20

5.7

ALTERNATE LOGIN PROCEDURES

5-21

5.8

CREATING PROXY ACCOUNTS
5.8.1
Creatina a Network User Authorization File
Adding
Proxy Accounts
5.8.2
Controlling Proxy Logins
5.8.3

5-22
5-22
5-23
5-24

SECTION 6 RESOURCE CONTROL

6-1

6.1 SETTING LIMITS ON REUSABLE SYSTEM RESOURCES
6.1.1
AST Queue Limit (ASTLM) _
6.1.2
Buffered I/O Count Limit (BIOLM) _
6.1.3
Buffered I/O Byte Count Limit (BYTLM) _
6.1.4
CPU Time Limit (CPU) _
6.1.5
Direct I/O Count Limit (DIOLM) _
6.1.6
Enqueue Quota (ENQLM) _
6.1.7
Open File Limit (FILLM) _
6.1.8
Job Table Quota (JTQUOTA) _
6.1.9
Maximum Account Jobs Limit (MAXACCTJOBS) _
6.1.10 Maximum Detached Processes Limit (MAXDETACH) _
6.1.11 Maximum Process Jobs Limit (MAXJOBS) _
6.1.12 Paging File Limit (PGFLQUO) _
6.1.13 Subprocess Creation Limit (PRCLM) _
6.1.14 Shared Files Limit (SHRFILLM) _
6.1.15 Timer Queue Entry Limit (TQELM) _
6.1.16 Default Working Set Size (WSDEF) _
6.1.17 Working Set Extent (WSEXTENT) _
6.1.18 Working Set Quota (WSQUOTA) _

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

6.2

6-7

SETTING PRIORITIES FOR USER PROCESSES

ASSIGNING PRIVILEGES

6-7

6.3.1

ACNT Privileae (Devour)

6-9

6.3.2

ALLSPOOL Privilege (Devour)

6-9

6.3.3

ALTPRI Privilege (System)

6-9

6.3.4

BUGCHK Privilege (Devour)

6-10

6.3.5

BYPASS Privilege (All)

6-10

6.3.6

CMEXEO Privilege (All)

6-10

6.3.7

CMKRNL Privilege (All)

6-11

6.3.8

DETACH Privilege (All)

6-11
VII

Contents

6.3.9
6.3.10
6.3.11
6.3.12
6.3.13
6.3.14
6.3.15
6.3.16
6.3.17
6.3.18
6.3.19
6.3.20
6.3.21
6.3.22
6.3.23
6.3.24
6.3.25
6.3.26
6.3.27
6.3.28
6.3.29
6.3.30
6.3.31
6.3.32
6.3.33
6.3.34
6.3.35

6.4

PART II

DIAGNOSE Privilege (Files) _
EXQUOTA Privilege (Devour) _
GROUP Privilege (Group) _
GRPNAM Privilege (Devour) _
GRPPRV Privilege (Group) _
LOG-IO Privilege (All) _
MOUNT Privilege (Normal) _
NETMBX Privilege (Normal) _
OPER Privilege (System) _
PFNMAP Privilege (All) _
PHY_IO Privilege (All) _
PRMCEB Privilege (Devour) _
PRMGBL Privilege (Devour) _
PRMMBX Privilege (Devour) _
PSWAPM Privilege (System) _
READALL Privilege (All) _
SECURITY Privilege (All) _
SETPRV Privilege (All) _
SHARE Privilege (System) _
SHMEM Privilege (Devour) _
SYSGBL Privilege (Files) _
SYSLCK Privilege (System) _
SYSNAM Privilege (All) _
SYSPRV Privilege (All) _
TMPMBX Privilege (Normal) _
VOLPRO Privilege (Files) _
WORLD Privilege (System) _

6-11
6-11
6-11
6-12
6-12
6-12
6-13
6-13
6-13
6-13
6-14
6-14
6-14
6-15
6-15
6-15
6-15
6-16
6-16
6-16
6-16
6-16
6-17
6-17
6-17
6-18
6-18

ACCOUNTING FOR THE USE OF SYSTEM RESOURCES
6.4.1
Accounting Records _
6.4.2
Accounting Log File _

6-19
6-19
6-19

MAINTAINING THE SYSTEM

SECTION 7 MAINTAINING PUBLIC FILES AND VOLUMES
7.1

SETTING UP PUBLIC FILE STRUCTURES
7.1.1
Storing User Files _
7.1.2
Using Volume Sets _

7.2 FORMATTING DISKS
viii

7-1

7-1
7-2
7-2

7-3

Contents

7.3

7.4

7.5

7.6

INITIALIZING PUBLIC VOLUMES

7-3

MOUNTING PUBLIC VOLUMES

7-5
7-6
7-7

7.4.1

Prenarina Disk and Maanetic Taoe Volumes

7.4.2

Responding to Mount Requests from Users

MAINTAINING VOLUME INTEGRITY

MOUNT VERIFICATION
7.6.1

Device Offline Mount Verification

7.6.2
7.6.3

Canceling Mount Verification

Devine Write-Lock Mount Verification

7.6.3.1
7.6.3.2
7.6.3.3

7.7

7.7.2.4

Performing Selective Backups _
Performing Incremental Backups _
Performing Daily Backups _
Performing Weekly Backups _
Performing Monthly Backups _
BACKUP Media Security _
Using BACKUP Journal Files _
Backing Up the Console Medium _
Backing Up the System Disk (Using Standalone
BACKUP) _
7.7.12 Restoring Entire Disk Volumes _
7.7.13 Restoring a Volume from Incremental Backups _
7.7.14 Restoring Files and Directories _

7.7.14.2
7.7.14.3
7.7.14.4

7-14
7-15
7-16

Backing Up a Public Disk to Disk • 7-16
Backing Up a Public Disk to Magnetic Tape • 7-18
Backing Up a Disk Volume Set When Drives Are
Limited *7-18
Writing Save Sets on Sequential-Disk
Volumes • 7-19

7.7.3
7.7.4
7.7.5
7.7.6
7.7.7
7.7.8
7.7.9
7.7.10
7.7.11

7.7.14.1

7-9
7-9
7-10
7-11

MVTIMEOUT System Parameter • 7-11
Cancellation Commands • 7-12
Dismounting the Volume • 7-13

BACKING UP PUBLIC VOLUMES
7.7.1
Rotating Backup Sets _
7.7.2
Backing Up Full Volumes and Volume Sets _
7.7.2.1
1.1.2.2
1.1.2.2

7-8

7-21
7-22
7-22
7-23
7-23
7-23
7-24
7-24
7-24
7-25
7-27
7-28

Listing the Contents of a BACKUP
Save Set • 7-28
Restoring Disk Files from Save Sets on Magnetic
Tape • 7-29
Restoring Disk Files from Save Sets on
Sequential Disk • 7-30
Restoring Disk Files from Save Sets on Multiple
Volumes • 7-31

Contents

7.8

MANAGING DISK SPACE
7.8.1
Setting File Expiration Dates _
7.8.2
Establishing Disk Quotas _
7.8.2.1
7.8.2.2

SECTION 8

Disk Quota Operations • 7-33
Restrictions on Other System Operations • 7-33

INSTALLING IMAGES AS KNOWN IMAGES

8-1

8.1 ASSIGNING ATTRIBUTES TO KNOWN IMAGES

8-1

8.2 INSTALLING IMAGES WITH THE SHARED ATTRIBUTE

8-2

8.3 INSTALLING IMAGES WITH PRIVILEGES
8.3.1
Privileged Executable Images _
8.3.2
Privileged Shareable Images _

8-3
8-3
8-3

8.4 INSTALLING EXECUTE-ONLY IMAGES
8.4.1
Execute-Only Main Programs _
8.4.2
Execute-Only Shareable Images _

8-3
8-4
8-4

8.5 DELETING KNOWN IMAGES AND DISMOUNTING VOLUMES

8-4

8.6 DEFINING LOGICAL NAMES FOR SHAREABLE IMAGE FILES

8-4

SECTION 9

USING THE BATCH/PRINT FACILITY

9-1

9.1 TYPES OF QUEUES
9.1.1
Execution Queues _
9.1.2
Generic Queues _
9.1.3
Logical Queues _

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

9.2

9-3

MANAGING THE JOB CONTROLLER

9.3 CONTROLLING THE QUEUE MANAGER
9.3.1
Starting the Queue Manager _
9.3.2
Creating a New Queue File _
9.3.3
Restarting the Queue Manager _

7-31
7-31
7-32

9-3
9-4
9-4
9-5

Contents

9.4

9.5

MANAGING QUEUES

9-5

9.4.1

Initializina and Startina Queues

9-6

9.4.2

Modifying Queues

9-7

9.4.3

Pausing Queues

9-7

9.4.4

Stopping Queues

9-7

9.4.5

Restarting Queues

9-8

9.4.6

Deleting Queues

9-8

9.4.7

Merging Output Queues

9-8

9.4.8

Restricting Access to Queues

9-9

MANAGING JOBS

9-10

9.5.1

Retainina Jobs in a Queue

9-11

9.5.2

Deleting a Job

9-12

Modifying Job Parameters

9-13

9.5.3

9.5.3.1
9.5.3.2
9.5.3.3

9.5.4

Controlling Print Job Position and Alignment
9.5.4.1
9.5.4.2

9.5.5

Holding and Releasing a Job • 9-13
Requeuing a Job • 9-14
Changing the Priority of a Job *9-14

9-14

Specifying the Position of Print *9-15
Aligning Printer Forms • 9-15

Controlling Batch Job Execution

9-16

ESTABLISHING BATCH QUEUES
9.6.1
Settina Ud Batch Queues on Small Svstems
Setting Up Batch Queues on Interactive Systems
9.6.2
Setting Up Batch Queues on Batch Systems
9.6.3
Setting Up Generic Batch Queues
9.6.4

9-18
9-20
9-20
9-21
9-21

9.7 ESTABLISHING OUTPUT QUEUES
9.7.1
Naming an Output Execution Queue _
9.7.2
Using Device Control Libraries _

9-22
9-25
9-25

9.6

9.7.2.1
9.7.2.2

9.7.3
9.7.4
9.7.5

Restricting Jobs by Size _
Restricting Jobs by Characteristics _
Restricting Jobs by Form _
9.7.5.1
9.7.5.2
9.7.5.3

9.7.6
9.7.7
9.7.8
9.7.9

Assigning a Library to an Output Queue • 9-27
Requesting a Library Module • 9-27

9-29
9-29
9-30

Defining a Print Form • 9-31
Changing the Systemwide Default Form • 9-32
Using the PRINT Command to Specify
a Form • 9-32

Specifying Mandatory Queue Attributes _
Specifying Default Queue Attributes _
Controlling Page and Line Overflow _
Setting Up Logical Queues _

9-32
9-37
9-42
9-43

Contents

9.7.10 Setting Up Generic Output Queues
9.7.10.1
9.7.10.2

9.7.11 Setting Up Spooled Devices _
9.7.12 Guidelines for Setting Up Queues for Spooled Line
Printers _
9.7.12.1
9.7.12.2
9.7.12.3

9.8

Setting Card Reader Translation Modes _
Tending the Card Reader _

9-54
9-55

9.8.3.1
9.8.3.2

Batch Job Card Deck • 9-53
Data Card Deck • 9-54

Replacing Physically Defective Cards • 9-55
Operating the Card Reader • 9-55

Running the Input Symbiont Interactively

SECTION 10 ERRORS AND OTHER SYSTEM EVENTS
ERROR LOGGING OPERATIONS

10.3

9-48

9-53
9-53

9.8.1.1
9.8.1.2

9.8.4

9-46

Single-Printer Configuration • 9-48
Two-Printer Configuration • 9-49
Three-Printer Configuration • 9-51

MANAGING THE CARD READER
9.8.1
Distinguishing the Type of Card Deck

9.8.2
9.8.3

9-43

Assigning Generic Output Queues
by Default • 9-45
Assigning Generic Output
Queues Explicitly • 9-45

9-56

10 1
10-1

10.1.1

Using Error Reports

10-2

10.1.2

Maintaining the Error Log Files

10-2

10.1.3

Printing the Error Log Files

10-3

USING THE OPERATOR LOG FILE
10.2.1 Maintainina the Ocierator Loa File
10.2.2 Printing the Operator Log File
10.2.3 Restarting OPCOM

10-3
10-6
10-6
10-7

USING THE OPERATOR TERMINAL TO HANDLE USER
REQUESTS

10-7

10.4 REPORTING SOFTWARE PROBLEMS
10-8
10.4.1 The Problem Environment_10-8
10.4.2 The Problem Scope _
10-8
10.4.3 Machine-Readable Files _
10-10
10.4.4 System Environment _
10-10
10.4.5 User Analysis (Optional) _
10-11

xii

Contents

SECTION 11

SYSTEM GENERATION

11 1

11.1

AUTOGEN FUNCTIONS

11-1

11.2

INVOKING AUTOGEN

11-2

11.3

COLLECTING DATA FOR AUTOGEN CALCULATIONS

11-3

11.4

MODIFYING AUTOGEN CALCULATIONS

11-7

11.5

MANIPULATING SYSTEM FILES

11-8

11.6

SYSGEN FUNCTIONS

11-9

11.7

MODIFYING SYSTEM PARAMETERS

11-9
11-10

11.7.1

Creating a New Parameter File

11 19

Modifying the System Parameter File

11-10

11 7 3

Modifying the Active System

11-11

11.8

CONNECTING DEVICES AND LOADING DEVICE DRIVERS

11-11

11.9

USING THE SET HOST/HSC FACILITY

11-12

11.10

SETTING UP VIRTUAL TERMINALS
11.10.1 Reconnecting to a Disconnected Terminal Process

11-12
11-13

11 10 ? Managing Disconnected Processes

11-13

11 lO S iJsing Dynamic Asynchronous DECnet Lines

11-14

11 1Q 4 Determining the Physical Terminal Type

11-14

11.11

MODIFYING SYSTEM FILES

11-15

11.12

IDENTIFYING A STARTUP COMMAND PROCEDURE FOR
BOOTSTRAP OPERATIONS

11-17

11.13

INITIALIZING MULTIPORT (SHARED) MEMORY UNITS

11-17

11.14

LOADING AND STARTING THE MSCP SERVER

11-19

Contents

11.15

APPENDIX a

SYSGEN PARAMETERS USED IN AUTOGEN CALCULATIONS

11-19

USING BOOT58 ON VAX-11/750 SYSTEMS

A 1

BOOTSTRAP PROCEDURES
"
“
~
A. 1.1
Default Bootstrap_
A.1.2
Conversational Bootstrap_
A. 1.3
Nonstop Bootstrap_

THE WRITEBOOT UTILITY

APPENDIX B

iTi

i^2

A-3
A-3
A-4
A-5

A^6

TECHNICAL NOTE ON VAX/VMS Cl

B-1

Cl PORT AND SYSTEM COMMUNICATIONS SERVICES

OPERATION

B-1

B. 1.1
B.1.2
B.1.3

B-1
B-1
B-2

Cl Port Polling and Virtual Circuits_
System Communications Services Connections _
Failures_

TROUBLE-SHOOTING^
B.2.1
B.2.2

““

“

i^3

Adding Nodes to a VAXcluster_B-3
Crossed Cables and Loopback Datagrams _
B-4

repairing cables

eT?

ANALYZING VAXCLUSTER ERROR LOG ENTRIES

ERROR LOG ENTRY FORMATS
B.5.1
Device-Attention Entries_
B.5.2
Logged-Message Entries _
ERROR LOG ENTRY DESCRIPTIONS

tT?

OPAO ERROIR MESSAGES '

”

"~~ “

iTI
B-8
B-10
B-12

B 18

Contents

INDEX

EXAMPLES
4—1
4—2
4—3
4—4
4— 5
5— 1
5-2
5-3
5-4
5—5
7-1
9- 1
10- 1
11- 1
B—1
B—2

Orderly System Shutdown with SHUTDOWN.COM _
Emergency Shutdown on a VAX—11/780 Using OPCCRASH _
Running CRASH on a VAX—11/780 System _
Running CRASH on a VAX 8600 or VAX 8650 System _
Running CRASH on a VAX—11/750 System _
Sample UAF Record Display _
Sample SYS$MANAGER:SYLOGIN.COM Login Command
Procedure _
Sample LOGIN.COM Login Command Procedure _
Command Procedure for Adding a User _
Command Procedure Template for Deleting an Account's Files
Using BACKUP Journal Files _
Using Device Control Library Modules to Process a Print Job _
Sample Operator Log File (SYS$MANAGER:OPERATOR.LOG) _
Sample AUTOGEN PARAMS.DAT File _
Device-Attention Entry _
Logged-Message Entry _

4-4
4-5
4-7
4-8
4-9
5-2
5-8
5-9
5-13
5-16
7-25
9-28
10-5
11-5
B-9
B-11

Execution Sequence of Startup Command Procedures _
Job Flag and Burst Pages _
Job Trailer Page _
File Flag and Burst Pages _
File Trailer Page _
Generic Output Queue _
Setting Up a Printer Queue on a System with One Printer _
Setting Up Printer Queues on a System with Two Printers _
Setting Up Printer Queues on a System with Three Printers _
Software Performance Report (SPR) _
A Correctly Connected Two-Node Cl VAXcluster _
Crossed Cl Cable Pair _

2-3
9-33
9-34
9-38
9-39
9-44
9-49
9-50
9-52
10-9
B-5
B-5

System Management Utilities _
VMSTAILOR Command Summary _
Library Disk Logical Name Definitions _
Files Requiring Installation with Privileges _
DCL Commands, Activated Images, and File Groups _

1-3
3-5
3-8
3-14
3-15

FIGURES
2-1
9-1
9—2
9—3
9—4
9—5
9—6
9—7
9— 8
10— 1
B—1
B—2

TABLES
1—1
3—1
3—2
3—3
3-4

Contents

4-1
6—1
6—2
9—1
9—2
9—3
9—4
9—5
9— 6
10— 1
11— 1
11-2
11—3
11—4
11-5

11-6

11—7

11-8

11—9
A—1

SYSGEN Commands Used in SYSBOOT _
Process Resource Limits, Suggested Values, Types,
and Descriptions _
VAX/VMS Privileges by Category, with Definitions _
Privilege Restrictions for Queue Operations _
Specifying Attributes for Batch Execution Queues _
Specifying Attributes for Output Execution Queues _
Job Separation Pages _
File Separation Pages _
Card Reader Errors: Causes and Corrective Actions _
Typical Problem-Specific Information for SPRs _
AUTOGEN Phase Parameters _
Execution Types _
Configuration Parameters Specified in Example 11—1
Values for Multiport Memory Structures _
Parameters Collected in OLDSITE1 .DAT and Propagated to New
System if Old Current Value exceeds Autogen's
Calculated Value _
Parameters Collected in OLDSITE2.DAT and Propagated to New
System if Old Current Value Exceeds Old
Default Value _
Parameters Collected in OLDSITE3.DAT and Propagated to New
System if Old Current Value Differs from Old
Default Value _
Version 4.4 Parameters Collected in OLDSITE4.DAT and
Propagated to New System if Old Current Value Differs from
Old Default Value _
Parameters Modified in AUTOGEN Calculations _
BOOT58 Commands _

4-12
6-2
6-8
9-10
9-18
9-22
9-35
9-40
9-56
10-11
11-2
11-3
11-6
11-18

11-19

11 -20

11-21
11 -21
A-1

Preface
The VAX/VMS System Manager's Reference Manual provides system managers
with the concepts and procedures for performing routine system management
operations on VAX/VMS systems. This manual is designed to
•

Describe the tasks involved in managing, operating, and maintaining a
VAX/VMS system

•

Provide general information on day-to-day operating procedures

•

Introduce utilities and commands used to perform specific system
management functions

This manual is not intended to be a complete one-volume reference source
of information. Utilities and commands used to perform specific system
management and operating tasks are described in detail in the individual
VAX/VMS utility reference manuals, and in the VAX/VMS DCL Dictionary.
This manual does not include information on configuring and managing
VAXcluster systems; for that information, refer to the Guide to VAXclusters.

Intended Audience
This manual addresses experienced users of the VAX/VMS system who must
perform the functions of a system manager or operator.

Structure of This Document
The VAX/VMS System Manager's Reference Manual is divided into two parts,
each covering a related group of system management tasks:
•

Part I, Setting Up the System, describes the tasks and tools necessary to
prepare a VAX/VMS operating system for daily operation. This section
includes discussions on making site-specific modifications to VAX/VMS,
performing system startup and shutdown, setting up and maintaining user
accounts, and allocating system resources.

•

Part II, Maintaining the System, describes the tasks and tools necessary
to maintain and routinely operate the system, and builds upon concepts
presented in Part I. This section includes discussions on maintaining
public files and volumes, installing images as known images, maintaining
batch and output queues, using error and operator logging facilities, and
modifying system parameters.

Appendix A describes special operations for the VAX-11/750 processor.
Appendix B provides information about the Computer Interconnect (Cl),
associated error messages, and corrective procedures.

Preface

Associated Documents
For general background information about the system, see the Introduction to
VAX/VMS.
For information on system installation and upgrade procedures, consult the
Guide to VAX/VMS Software Installation and the software installation booklets
for your VAX processor.
For information on creating and maintaining volumes using the volume
shadowing option, refer to the VAX/VMS Volume Shadowing Manual.
For hardware operating instructions, refer to the appropriate hardware
manual.
For managing network operations, refer to the VAX/VMS Networking Manual.
For configuring and managing VAXclusters, refer to the Guide to VAXclusters.
The following documents provide important system management reference
and supplemental information:
•

VAX/VMS DCL Dictionary

•

The VAX/VMS Utility Reference Manuals

•

VAX/VMS System Messages and Recovery Procedures Reference Manual

•

Guide to VAX/VMS Disk and Magnetic Tape Operations

•

Guide to VAX/VMS Performance Management

Conventions Used in This Document
Convention

Meaning

EM]

A symbol with a one- to six-character
abbreviation indicates that you press a key
on the terminal, for example, I RET| .

|CTRL/x|

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

$ SHOW TIME
05-JUN-1986 11:55:22

Command examples show in blackletters all
output lines or prompting characters that the
system prints or displays. All user-entered
commands are shown in red letters.

$ TYPE MYFILE.DAT

A vertical series of periods, or ellipsis, means
either that not all the data that the system
would display in response to the particular
command is shown or that not all the data a
user would enter is shown.

file-spec, . . .

Horizontal ellipsis indicates that additional
parameters, values, or information can be
entered.

Preface

Convention

Meaning

[logical-name]

Square brackets indicate that the enclosed item
is optional. (Square brackets are not, however,
optional in the syntax of a directory name in a
file specification or in the syntax of a substring
specification in an assignment statement.)

quotation marks
apostrophes

The term quotation marks is used to refer
to double quotation marks ("). The term
apostrophe (') is used to refer to a single
quotation mark.

xix

New and Changed Features
The Version 4.4 VAX/VMS System Manager's Reference Manual includes
information on the new and changed features added to the VAX/VMS
operating system since Version 4.0. This manual was previously a handbook
entitled Guide to VAX/VMS System Management and Daily Operations. The
major changes and enhancements to the documentation are found in the
following sections:
•

Section 2—Includes additional information on standalone BACKUP.

•

Section 4—Includes the procedure for performing an emergency shutdown
with CRASH on a VAX 8600 or VAX 8650 system.

•

Section 5—Includes the following new information:
-

Procedure for recovering lost files in the SYSLOST directory

Procedure for adding a secondary password to a UAF record

New Authorize Utility AUTOLOGIN flag for restricting login functions

•

Section 8—New section on installing execute-only images; the image
activator allows execution of images to which the caller has EXECUTE but
not READ access.

•

Section 9—This section has undergone major revision and reorganization
for Version 4.4. The major changes to the batch/print facility are listed as
follows:
-

New /RESTART qualifier for the START/QUEUE/MANAGER
command, which causes the queue manager to automatically restart on
recovery from a job controller abort.

Additional information on holding and releasing jobs including the
new /NOAFTER qualifier of the SET QUEUE/ENTRY command.
Specifying this qualifier immediately releases a job held by previously
specifying the /AFTER qualifier.

New tables listing the qualifiers used to specify queue attributes.

New figures displaying the formats for job and file separation pages.

Additional information and examples on using device control library
modules to set up print devices for special printer functions.

New /[NO]PAGE—SETUP qualifier for the DEFINE/FORM command
specifies one or more device control library modules to set up the print
device to perform special printer functions at the beginning of each
page.

New /FORM_MOUNTED qualifier for the INITIALIZE/QUEUE,
START/QUEUE, and SET QUEUE commands replaces the /FORM
qualifier. This qualifier associates the paper stock of the form with that
of the output queue.

New section describing how to change the systemwide default form.

New /DEFAULT=FORM keyword for the INITIALIZE/QUEUE,
START/QUEUE, and SET QUEUE commands allows you to specify a
queue-specific default form type.

xxi

New and Changed Features

•

Additional documentation on controlling page and line overflow
including the /[NOJPASSALL qualifier. Specifying /PASSALL with
the PRINT command sends I/O to the device driver with formatting
suppressed.

New /[NO]RECORD_BLOCKING qualifier for the START/QUEUE,
INITIALIZE/QUEUE, and SET QUEUE commands determines whether
the symbiont can block together output records for transmission to the
output device.

Section 11—Includes the following new information:
-

New configuration parameters added to SYS$SYSTEM:PARAMS.DAT:
NUM_HOST, NUM —SERVER, and WSTYPE.

New DISKSIZE parameter replaces the SMALLDISK parameter in
SYS$SYSTEM:PARAMS.DAT.

Additional documentation on modifying AUTOGEN calculations.

New section describing the SET HOST/HSC facility. System managers
can now use most HSC commands and utilities from a remote terminal.

New section describing how to use virtual terminals to disconnect from
a physical terminal without terminating a process.

Appendix B—New Cl error log entry descriptions and changes to Cl error
log entry formats.

Introduction

A computer installation exists to provide its users with efficient and
economical service. The challenge of system management is to provide
such service on a day-to-day basis.
Management of a VAX/VMS installation entails two main responsibilities:
system performance and system operation. These responsibilities require that
you
•

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

•

Perform tasks that relate to the overall management and control of the
system

This manual discusses the issues and facts that you must understand to make
decisions, and it provides guidelines for performing system management
functions.
It is nor possible to prescribe a set of formulas for setting up and running a
VAX/VMS system, because you cannot manage a system by rote. Rather,
you must- -by combining an understanding of users' needs with a working
knowledge of system capabilities—work out your own strategy.
System management tasks can be performed by a single individual, or by a
system manager assisted by one or more operators. Since responsibilities vary
from site to site, this manual does not make job distinctions between system
managers and operators. As you read the manual, therefore, it may appear at
times that one person is performing all system management functions. Bear
in mind that this is not always the case.

System Management Tasks
System management tasks typically fall into the following categories:
•

Installing and upgrading the system

•

Making site-specific modifications

•

Controlling system operation

•

Configuring the system for good performance

•

Planning to meet future requirements

The first task is the subject of the Guide to VAX/VMS Software Installation and
the installation booklets for your VAX processor. The next three are described
in this manual. The final task is beyond the scope of this manual.
As system manager, you can perform many of your duties from user
terminals. However, you must perform one of your chief functions,
communicating with other users, at an operator's terminal, which you define
by using the privileged DCL command REPLY/ENABLE (see the VAX/VMS

DCL Dictionary).

1-1

Introduction

Your relationship with users is largely based on messages that pass between
you and them. 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.
You can perform certain system management functions only from the system
console terminal. These functions include bootstrapping the system and
communicating with the VAX processor's console subsystem.

1.1.1

Operational Tasks
The VAX/VMS system normally runs with minimal operator intervention. In
many installations, however, operators keep the system running smoothly by
performing some of the following tasks:
•

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

•

Initializing and mounting system volumes

•

Backing up public files and volumes

•

Sending messages to users

•

Tending line printers and card readers

•

Responding to emergencies

•

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

•

Shutting down and restarting the system

•

Bringing up and shutting down network components

To carry out these tasks effectively, operators usually consult the system
manager for guidance on site-specific policies and procedures.

1.1.2

Tools and Privileges
To manage a VAX/VMS system, you have at your disposal powerful
commands and utilities to monitor and control system operations and
resources. In addition, you receive the privileges necessary to carry out
your management functions.

1.1.2.1

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 DCL

Dictionary.

1-2

Introduction

1.1.2.2

VAX/VMS Utilities
Table 1-1 lists those utilities frequently employed primarily as system
management tools and gives a brief description of their purpose. You can find
further details on each of these utilities, as well as other utilities with which
you will want to become familiar, by referring to the specific VAX/VMS
utility reference manuals.

1.1.2.3

Table 1-1

System Management Utilities

Utility Name

Function

ACCOUNTING

Produces reports and summaries of system usage

ANALYZE/ERROR_LOG

Reports the contents of the system error log file

AUTHORIZE

Adds and modifies records in the existing user
authorization and network authorization files or
creates new files; adds and modifies records in the
rights database

BAD

Analyzes block-addressable devices and records the
location of blocks that cannot reliably store data

DISKQUOTA

Controls the usage of disk volumes

INSTALL

Installs and maintains known images

MONITOR

Monitors systemwide performance

SYSGEN

Performs tasks associated with system generation
such as loading and connecting drivers, creating
or extending page and swap files, displaying or
modifying the values of the system parameters, and
enabling multiport memory units

VERIFY

Checks the validity of Files-11 Structure Level 1 and
Structure Level 2 disk volumes, and reports errors
and inconsistencies

Privileges
System management functions require privileges that are denied to most
users. Section 6 provides more detailed information about the privileges and
who should receive them. Section 5 describes how to set up authorization
records that grant these privileges.

1.1.3

VAX/VMS Operating System Components
To manage a VAX/VMS system effectively, you must be familiar with
its principal components, which are contained in ten directories on the
system distribution medium. The logical names of these directories and brief
descriptions of their contents are as follows:
•

SYS$ERRORLOG—Contains the error log file (ERRLOG.SYS)

•

SYS$EXAMPLES—Contains sample driver programs, user-written system
services, and other source programs

•

SYS$HELP—Contains text files and help libraries for the Help Utility

•

SYS$LIBRARY or SYS$SHARE—Contains various macro and object
libraries and shareable images

•

SYS$MAINTENANCE—Contains system diagnostic programs

1-3

Introduction

•

SYS$MANAGER—Contains files used in managing the operating system

•

SYS$MESSAGE—Contains system message files

•

SYS$SYSTEM—Contains the executable images of most operating system
functions

•

SYS$TEST—Contains files used in testing operating system functions

•

SYS$UPDATE—Contains files used in applying system updates

For a complete list of the files contained on the distribution medium, see the
Guide to VAX/VMS Software Installation.

1-4

PART I Setting Up the System

Customizing the Operating System After
Installation
Your first responsibility as system manager is to get your VAX/VMS
system up and running. At a minimum, you must install and bootstrap
the VAX/VMS operating system supplied by DIGITAL, following procedures
described in the installation documentation for your VAX processor. Refer to
this documentation for information on all installation tasks.
Once your system is installed, you can customize it for your particular
operating environment by performing one or more of the following
operations:
•

Build a site-specific startup command procedure
When you install your system, the site-specific startup command
procedure, SYS$MANAGER:SYSTARTUP.COM, is blank to accommodate
the installation. After you have installed the system, you add commands
to SYSTARTUP.COM to set up an environment specific to your site. For
example, you normally include commands that initialize and start batch
and output queues. Section 2.2 describes startup command procedures;
Section 2.3 shows how to create a typical site-specific startup command
procedure.

•

Select a default bootstrap command procedure
The file DEFBOO.CMD is the bootstrap command procedure invoked
by default to bootstrap your system from the appropriate disk drive, as
explained in Section 2.4. After installation, you must select and copy
to DEFBOO.CMD a default bootstrap command procedure from those
available on your console medium. You can select either a nonstop or a
conversational procedure. You select a nonstop procedure if you want to
bootstrap the system without stopping to change system parameters. A
conversational procedure lets you change parameters in the course of the
boot. Sections 2.4 and 2.5 explain how to select and, if necessary, modify
the procedure appropriate for your site. Appendix A discusses bootstrap
operations peculiar to VAX-11/750 systems.

•

Make site-specific modifications for special configuration or workload
needs
When you bootstrap your system during installation, the AUTOGEN
command procedure generates system parameters that are suitable for
your hardware. However, you may want to modify some of them if you
have an unusual hardware configuration or special workload requirements.
In that case, refer to the discussion of AUTOGEN in Section 11.
If you have a dual-RL02 VAX-11/730 system, you will need to adjust
the sizes of the page and swap files to accommodate crash dumps.
Additionally, if your VAX-11/730 system uses a DMF32 "combo" board,
you must redefine the line printer device names. These modifications are
described in Sections 2.6.1 and 2.6.2.

2-1

Customizing the Operating System After Installation

Once you have made the necessary site-specific modifications to the
operating system, you must shut the system down and reboot it to
ensure that they are installed. For example, most modifications to system
parameters do not take effect until the system is shut down and rebooted.
The procedures for shutting down and rebooting the system are explained
in Sections 2.7 and 4.
•

Back up the system
After installing and customizing your system, you must perform various
backup operations as described in Section 2.8.

The remainder of this chapter discusses the tasks that you as system manager
perform to customize your newly installed VAX/VMS system and prepare it
for daily use.
Section 3 describes procedures for tailoring small-disk systems.

2.1

Logging In to the System
Before you can make site-specific modifications, you must log in to the system
manager's account, SYSTEM. When you bootstrap the system, it announces
itself with the initialization message:
VAX/VMS Version 4.4 <dd-mmm-yyyy hh:mm:ss.s>
mnmm OPCOM, <dd-mmm-yyyy hh:mm:ss.s> im.Um.Vt.
Logfile has been initialized by operator _0PA0:
Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1
%SET-I-INTSET, login interactive limit = 64, Current interactive value = 0
SYSTEM
job terminated at <dd-mmm-yyyy hh:mm:ss.s>

Use the following procedure to log in to the system as system manager:
1

Press the RETURN key on the console terminal.

2 In response to the system's request for your username, type SYSTEM.
3 In response to the system's request for your password, type the SYSTEM
password.
Note: DIGITAL recommends that you change the system manager account
password frequently to maintain system security. Also, the account has
full privileges by default, so you must exercise caution when using it.
Section 6 provides additional information about the SYSTEM account.
When you enter your password, the system prints a welcome message on the
console terminal, followed by the time of your last login:
Welcome to VAX/VMS Version 4.4
Last interactive login at 15-APR-1986 15:13:21.07

When the console terminal prints the command prompt, you can begin
modifying the system using the instructions in the following sections.

2-2

Customizing the Operating System After Installation

2.2

Startup Command Procedures
The software distribution kit includes the following startup command
procedures:
•

SYS$SYSTEM:STARTUP.COM—a file containing commands that must
execute at initialization time in order for the system to run properly. This
procedure is the site-independent startup command procedure supplied by
DIGITAL.

•

SYS$MANAGER:SYCONFIG.COM—an empty file supplied by
DIGITAL to which you can add your own specific device configuration
commands. This command procedure is invoked by STARTUP.COM (see
Sections 2.2.2 and 2.3).

•

SYS$MANAGER:SYSTARTUP.COM—an empty file supplied by
DIGITAL to which you can add specific initialization commands for
your site. This procedure is the site-specific startup command procedure
invoked by STARTUP.COM (see Section 2.2.3).

Caution: Do not modify SYS$SYSTEM:STARTUP.COM. Instead, put site-specific
commands in SYSTARTUP.COM, because new versions of VAX/VMS
delete and replace the STARTUP.COM command file. By modifying
SYSTARTUP.COM, you ensure that commands specific to your site are
kept whenever you upgrade your system to a new version of VAX/VMS.
Also, leaving STARTUP.COM intact prevents you from inadvertently
altering any commands in the file.
Figure 2-1 illustrates the execution sequence of the startup command
procedures.
Figure 2-1

Execution Sequence of Startup Command
Procedures

SYS$SYSTEM:ST ARTUP.COM

SYS$MANAGER:SYCONFIG.COM

ZK-1309-83

2-3

Customizing the Operating System After Installation

2.2.1

Site-Independent Startup Command Procedure
The command procedure SYS$SYSTEM:STARTUP.COM is automatically
executed immediately after the operating system is bootstrapped and includes
commands that
•

Perform various housekeeping chores

•

Define systemwide logical names required for the symbolic debugger,
language processors, linker, image activator, and help processor

•

Start three processes that control error logging, the job controller, and the
operator's log

•

Connect devices that are physically attached to the system and load their
I/O drivers (see Section 2.2.2)

•

Install known images to reduce I/O overhead in activating the most
commonly run images.

Before STARTUP.COM terminates, it invokes the site-specific startup
command procedure, SYS$MANAGER:SYSTARTUP.COM (see Section 2.2.3).
When SYSTARTUP.COM completes, control is returned to STARTUP.COM
and the number of interactive users is set to 64 by default, unless the number
was set in the SYSTARTUP procedure (see Section 2.3.12). After this step,
STARTUP.COM logs off.

2.2.2

Device Configuration Command Procedure
One step in the site-independent startup command procedure
SYS$SYSTEM:STARTUP.COM is to connect the devices that are
physically attached to the system and load their I/O drivers. To
do this, STARTUP.COM first invokes the command procedure
SYS$MANAGER:SYCONFIG.COM. (Remember that this command procedure
comes with the software distribution kit as an empty file.) You can leave the
file empty, or you can add your own specific device configuration commands.
After SYCONFIG.COM executes control is returned to STARTUP.COM, and
the following commands are executed to connect all devices automatically
and load their drivers:
$ RUN SYS$SYSTEM:SYSGEN
$ SYSGEN := $SYSGEN
$ SYSGEN AUTOCONFIGURE ALL

During autoconfiguration, a section of STARTUP.COM called CONFIGURE
runs a program that creates a detached process to detect any devices
connected to an HSC, load their drivers, and make the devices known to
the system. You can suppress autoconfiguration by including the following
command as the last line in SYCONFIG.COM:
$ STARTUP!AUTOCONFIGURE.ALL == 0

Note: If you set STARTUP$AUTOCONFIGURE _ALL to zero in
SYSCONFIG.COM, the CONFIGURE section of STARTUP.COM will
not execute.

2-4

Customizing the Operating System After Installation

To ensure proper configuration of devices connected to an HSC, DIGITAL
recommends adding the following lines to the end of SYCONFIG.COM:
$ STARTUP$AUTOCONFIGURE_ALL == 0
$ ®SYS$SYSTEM:STARTUP CONFIGURE
$ EXIT

This procedure suppresses autoconfiguration and then executes the commands
in STARTUP.COM that start the CONFIGURE process.

2.2.3

Site-Specific Startup Command Procedure
The command procedure SYS$MANAGER:SYSTARTUP.COM is invoked by
STARTUP.COM to execute startup commands that are specific to your site.
DIGITAL recommends that you edit SYSTARTUP.COM to include commands
that will perform the following typical site-specific operations:
•

Mount public disks

•

Assign systemwide logical names

•

Set the characteristics of terminals and other devices

•

Initialize 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

•

Connect devices and multiport memory units

•

Install or start layered products

•

Install secondary page and swap files

•

Announce that the system is up and running

•

Redefine the number of interactive users

•

Terminate the command procedure

To minimize processing overhead when executing SYSTARTUP.COM, you
normally include the DCL command SET NOON at the beginning of the file
to disable error processing.

2.3

Creating Your Site-Specific Startup Command Procedure
The following sections describe how to create a typical site-specific startup
command procedure. Any commands shown are provided as models; do not
copy them line for line.

2-5

Customizing the Operating System After Installation

2.3.1

Mounting Public Disks
You will probably want to include mount commands to mount your
public disks for systemwide access. You should also consider 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

DRA1:

USERFILES

USER

This command produces the logical volume name USER and equates it to the
concealed device name string DRA1:. 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: DISKS 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 displayed on the terminal 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 on which physical drive the volume is mounted. 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 qualifier means that operatorassisted mounts are disabled. If you want to enable this feature during
SYSTARTUP, you must specify /ASSIST with each MOUNT command. See
Section 7 for more information on mounting public disks.

2.3.2

Assigning Systemwide Logical Names
In addition to the logical names assigned in the site-independent startup
command procedure, you can assign systemwide logical names with a
command like the following:
$ DEFINE/SYSTEM SYSDSK SYS$SYSDEVICE:

Note: During VAX/VMS system operations where the integrity of the system
could be compromised by incorrect logical names, such as the activation of
privileged images (LOGINOUT, MAIL, and so forth), only executive-mode
and kernel-mode logical names are used; supervisor-mode and user¬
mode names are ignored. DIGITAL therefore recommends that logical
names for important system components (public disks and directories, for
example,) be defined in executive mode, using the DCL command DEFINE
/SYSTEM/EXECUTIVE.
See the VAX/VMS DCL Concepts Manual for more detailed information on
logical name assignments.

2-6

Customizing the Operating System After Installation

2.3.3

Setting Device Characteristics
To establish the characteristics of the terminals and other devices on the
system, you can use a series of SET commands in a command procedure.
You may want to include comments that give the user names for terminal
owners. For example:
$
$
$
$
$
$

SET
SET
SET
SET
SET
SET

TERMINAL TTC2: /SPEED=300/DEVICE_TYPE=LA36/PERMANENT
TERMINAL TTD1: /SPEED=9600/PERMANENT
TERMINAL TTD4: /SPEED=1200/PERMANENT
TERMINAL TTG4: /SPEED=1200/MODEM/PERMANENT
PRINTER LPAO: /LOWER/NOCR
DEVICE LPAO: /SPOOLED

!JONES
!WRENS
!JRSMITH
SDIALUP1

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. You may want to
include SET TERMINAL commands in a separate file named, for example,
TERMSET.COM, and include a command in SYSTARTUP.COM to invoke the
TERMSET.COM command file. When the command file finishes execution,
control returns to SYSTARTUP.COM.

2.3.4

Initializing and Starting Queues
Include queue commands to start the system job queue manager, establish
spooled devices, and set up print and batch queues.
Initialize and start each queue with a separate INITIALIZE/QUEUE/START
command line. The following commands start the system job queue manager
and initialize and start all queues if they are stopped.
$
$
$
$

!
!Start the system job queue manager
!
START/QUEUE/MANAGER

$ !
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$

!Set printers spooled and establish printer queues
!
SET PRINTER/LOWER LPAO:
SET DEVICE/SPOOLED=SYS$PRINT LPAO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG/NOENABLE_GENERIC LPAO:
!
SET PRINTER/LOWER LPBO:
SET DEVICE/SPOOLED=SYS$PRINT LPBO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG/NOENABLE_GENERIC LPBO:
!
INITIALIZE/QUEUE/START/GENERIC=(LPAO,LPBO) SYS$PRINT
!
!Establish batch queues
!
INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=2/BASE_PRI0RITY=3 SYS$BATCH

Note: You may want to add the /RESTART qualifier to the START/QUEUE
/MANAGER command. This qualifier causes the queue manager
to automatically restart in the event of a job controller abort (see
Section 9.3.3 for more information).
On systems with a large number of queues, you may want to include queue
commands in a separate file named, for example, STARTQ.COM, and
include a command in SYSTARTUP.COM to invoke the queue command
file. When the queue command file finishes execution, control returns to
SYSTARTUP.COM. (Section 9 describes how to set up queues and establish
spooled devices.)
2-7

Customizing the Operating System After Installation

2.3.5 Installing Known Images
It is important to install user and system programs (in addition to the ones
installed in the site-independent startup command procedure) so that they
can be located quickly, shared, or provided privileges:
$ INSTALL = "IINSTALL/COMMAND.MODE"
$ INSTALL
ADD/OPEN/SHARED/HEADER.RESIDENT BLISS32
ADD/OPEN/SHARED MACR032
ADD/OPEN DIRECTORY

For more information on installing images as known images, see Section 8
and the description of the Install Utility in the VAX/VMS Install Utility
Reference Manual.

2.3.6 Running the System Dump Analyzer
Each time the system is bootstrapped, you should run the System Dump
Analyzer (SDA) 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 you require further information, you can invoke the System Dump Analyzer
for an interactive session upon completion of startup. (See the VAX/VMS
System Dump Analyzer Reference Manual.)
Caution: If you use the page file for the crash dump file, you must, when the
system reboots, issue the SDA command COPY to copy the dump from
the page file to another file suitable for analysis. If you fail to perform
the copy operation, pages used to save the crash dump information will
not be released for paging, and your system will hang while executing
STARTUP.COM in the rebooting process.

2.3.7 Maintaining the Operator's Log File
Section 10 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 versions of the operator's log file:
$ PURGE/KEEP=2 SYS$MANAGER:OPERATOR.LOG

2.3.8 Submitting Standard Batch Jobs
Some sites may have batch jobs that are submitted at system startup 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 startup file:
$ SUBMIT SYS$MANAGER:file-spec

(See Section 9.5.5 for more information on submitting batch jobs.)

2-8

Customizing the Operating System After installation

2.3.9 Connecting Devices and Multiport Memory Units
You run the System Generation Utility (SYSGEN) to connect devices not
automatically connected in STARTUP.COM and to initialize or connect
multiport memory units:
$ RUN SYS$SYSTEM:SYSGEN
SHARE MPM1 SHR_MEM_1 /INITIALIZE

For installations that require permanent residence of the console block storage
device, you must explicitly connect the device by issuing the following
SYSGEN command:
CONNECT CONSOLE

See Section 11 and the VAX/VMS System Generation Utility Reference Manual
for a detailed discussion of SYSGEN.
You should also mount the console block storage device by using a command
like the following:
$ MOUNT/FOREIGN/SYSTEM/PROTECTION*(SYSTEM:RWLP) CSA1: 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.

2.3.10 Installing Secondary Page and Swap Files
You run SYSGEN to install secondary page and swap files (previously created
with the SYSGEN command CREATE).
$ RUN SYS$SYSTEM:SYSGEN
INSTALL DISK$SYS2:[SYSTEM]PAGEFILE1.SYS /PAGEFILE
INSTALL DISK$SYS2:[SYSTEM]SWAPFILE1.SYS /SWAPFILE

2.3.11 Providing Announcements
The last command in SYSTARTUP.COM typically announces to all terminals
that the system is up and running:
$ REPLY/ALL/BELL "VAX/VMS at ACME. INC. ready lor use."

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.

2.3.11.1

SYS$ANNOUNCE
SYS$ANNOUNCE defines text to be printed whenever a user begins to log
in; that is, the text is printed immediately after a successful dial-in, CTRL/Y,
or RETURN is received. 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 "ENTER IF YOU DARE"

2-9

Customizing the Operating System After Installation

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.

2.3.11.2

SYSSWELCOME
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.
For example, you could include a command of the following form in your
SYSTARTUP.COM file:
$ DEFINE/SYSTEM SYS$WELCOME "WELCOME TO VAX/VMS LAND"

Or you might prefer to print a file:
$ DEFINE/SYSTEM SYSlWELCOME "®SYS$MANAGER:WELCOME.TXT"

If you do not specifically define SYSSWELCOME, the standard VAX/VMS
welcome message is printed:
Welcome to VAX/VMS Version 4.4

Note that this message may end by specifying the DECnet-VAX node name if
the logical name SYSSNODE is defined.

2.3.12 Redefining the Number of Interactive Users
If the number of interactive users that you permit to log in at one time is not
64, include the following command in SYSTARTUP.COM:
$ STARTUP$INTERACTIVE_LOGINS == n

Specify the appropriate number of users for n.
When SYSTARTUP.COM terminates, control is returned to STARTUP.COM,
which checks whether the number of logins was set by the above command.
If the command was used to specify a value, that value is used. Otherwise,
STARTUP.COM sets the number to 64 by default and then exits.

2.3.13 TerminatingSYSTARTUP.COM
Include the command EXIT as the last command in SYSTARTUP.COM.
The EXIT command terminates the procedure and returns control to
STARTUP.COM.

2—10

Customizing the Operating System After Installation

2.4

Selecting a Default Bootstrap Command Procedure
Default bootstrap command procedures are grouped by types of disk
controller systems: Integrated Disk Controllers (IDC), UNIBUS Disk Adapters
(UDA), UNIBUS controllers. Hierarchical Storage Controllers (HSC), and
MASSBUS controllers. In all cases, the bootstrap command procedures are
stored on your console media: floppy diskettes for VAX-11/780, TU58 tape
cassettes for VAX-11/750 and VAX-11/730, console RL02 disk for VAX 8600.
After your system is installed, you must select a default bootstrap command
procedure from those available on your console volume. To determine which
procedures are available, follow these steps:
1

Be sure your console device is connected. If it is not, invoke SYSGEN and
issue the following command to connect it:
SYSGEN> CONNECT CONSOLE

2 Next, exit from SYSGEN and mount the console volume as foreign (it is
in RT-11 format). In this example, the console volume is assumed to be
physically located in the floppy diskette drive (CSA1) on a VAX-11/780.
$ MOUNT/FOREIGN CSA1:

3 Now invoke the Exchange Utility using the following DCL command:
$ EXCHANGE

4 When the EXCHANGE > prompt appears, enter the following command
to obtain a listing of the files on the console volume:
EXCHANGE> DIRECTORY CSA1:

When the listing is printed, examine it to determine which bootstrap
command procedures are available for bootstrapping system devices.
Generally, these are the files that start with the letter D and end with
either BOO.CMD (nonstop) or GEN. (conversational).
You may also find files that begin with the letters Cl. These are used to
bootstrap from HSC disks (see Section 4.2.4).
You can relate each procedure to a disk device by noting the first two
letters in the file name, which represent the device code. For example,
files beginning with the letters DM are used for bootstrapping RK07 disk
devices. (See the discussion of SYSGEN in the VAX/VMS System Generation
Utility Reference Manual for a list of device codes for the various disk drives.)
The third character in the file name is usually a number identical to the unit
number of the associated disk device. For example, DMlBOO.CMD is used
for bootstrapping the RK07 assigned unit number 1 on the first UNIBUS
controller.
If the third character is a letter (A, B, C, or D), you may use the file to
bootstrap devices assigned to the related controller (A is the first controller,
B the second, and so on). For example, you use DMBBOO.CMD (third
character is B) to bootstrap from RK07 disk drives assigned to the second
UNIBUS controller. When you use this type of procedure, you must provide
the device unit number either by editing the procedure to deposit the selected
number in register R3 (the unit number register), or by using the console
DEPOSIT command to put the selected number in R3.

2-11

Customizing the Operating System After Installation

For example, if you want to bootstrap from the RK07 drive assigned unit
number 3 on the third UNIBUS controller, you would add this line to the
bootstrap file named DMCBOO.CMD:
DEPOSIT R3 00000003

2.5

IDISK DEVICE UNIT NUMBER

Modifying a Default Bootstrap Command Procedure
Once you have selected a default bootstrap command procedure for your site,
you may find it necessary to modify the procedure if
•

You want to bootstrap your system from a disk drive other than your
usual system device.

•

You use CIBOO.CMD or a bootstrap command file that does not specify
the disk drive's unit number (see Section 4.2.4).

You cannot modify a file on your console volume because of the way the
volume is formatted. You must first copy the file to a disk directory, then
modify it, and finally copy it back to the console volume. To perform the
copy operations, use the DXCOPY command procedure as follows:
1

Invoke DXCOPY:
$ <OSYS$UPDATE: DXCOPY

When the command procedure asks whether the console storage medium
is mounted, type the letter Y:
Is the system console storage medium mounted (Y/N)?: Y

3 When DXCOPY asks if you want to copy a file from the console storage
medium (to your default directory), type Y:
Copy from console medium (Y/N)?: Y

4 When DXCOPY prompts you for it, type the name of the file you want to
copy to your default directory:
Name of file to be copied?: file-spec
$

DXCOPY copies the file and returns you to command level.
When the DCL prompt appears, you can edit and rename the default
bootstrap command procedure file while it resides in your default
directory. If you want to make the modified file your default bootstrap
command procedure, rename the file to DEFBOO.CMD using the
following command:
$ RENAME filename DEFBOO.CMD

Invoke DXCOPY to copy the modified procedure back to the console
storage medium:
$ (BSYSIUPDATE: DXCOPY

6 When the command procedure asks whether the console storage medium
is mounted, type the letter Y:
Is the system console storage medium mounted (Y/N)?: Y

When DXCOPY asks whether you want to copy from the console medium,
type N:
Copy from console medium (Y/N)?: N

2-12

Customizing the Operating System After Installation

The negative response tells DXCOPY you want to copy the file from your
default directory to the console storage medium.
8

When the command procedure asks for it, type the name of the file to be
copied from your default directory to the console storage medium. In this
example, you type DEFBOO.CMD:
Name of file to be copied?: DEFBOO.CMD
$

DXCOPY responds by copying the modified file to the console volume
and returning you to command level.
You may now use the file to bootstrap your system disk from the selected
device.

2.6

Performing Modifications for Special Configurations or
Workload Requirements
When you first bootstrap your system, the DIGITAL-supplied command
procedure SYS$UPDATE:AUTOGEN.COM sets the values of the system
parameters, the sizes of the page, swap, and dump files, and the contents of
the default installed image list.
AUTOGEN provides the appropriate values based on your hardware
configuration and on estimates that AUTOGEN makes for typical workloads.
However, you may need to modify the system parameters if you have an
unusual hardware configuration or special workload requirements. Procedures
for making such modifications are described in the discussion of AUTOGEN
in Section 11.

2.6.1

Modifying Dual-RL02 Systems to Handle Crash Dumps
The dual-RL02 system does not provide a dump file for handling crash
dumps. Instead, the page file is used for this purpose. However, a dual-RL02
configuration can utilize the page file for crash dumps only if the page file has
at least 1000 more blocks than the number of physical pages of memory on
the system, and the swap file has at least 1000 blocks.
You may need to enlarge the size of these files in a dual-RL02 system because
AUTOGEN creates page and swap files of minimal size in order to conserve
space. To change the size of these files, refer to the AUTOGEN discussion in
Section 11.

2.6.2

Redefining the Line Printer on a VAX—11 /730
Line printer device names on VAX-11/730 processors that use a DMF32
"combo" board are defined as LC. All other line printer names are defined
as LP. To avoid problems with programs and procedures that use the LP
designation, it is recommended that the line printer device name be redefined
by adding the following commands to your site-specific SYSTARTUP.COM
command procedure:
$
$
$
$

DEFINE
DEFINE
DEFINE
DEFINE

/SYSTEM
/SYSTEM
/SYSTEM
/SYSTEM

LP LCAO:
LPO LCAO:
LPA LCAO:
LPA0 LCAO:

2—13

Customizing the Operating System After Installation

2.7

Rebooting to Install System Modifications
You must shut your system down and then reboot it to ensure that all the
modifications you make are installed in the system. For example, note that
any system parameters that were added by running the AUTOGEN command
procedure do not take effect until you reboot the system.
You can shut down and reboot the system with AUTOGEN commands,
or you can execute SHUTDOWN.COM using the following procedure.
(Section 4 describes SHUTDOWN.COM in more detail.) If your system
controls are set for automatic restart, and your default bootstrap command
procedure is set to bootstrap your system disk, you need only perform the
first step.
Caution: For VAX-11/750 systems, be sure the BOOT DEVICE switch on the
Processor Control Panel is positioned to select the disk drive that contains
the system disk.
1

Type the following command at the DCL prompt:
$ ®SYS$SYSTEM:SHUTDOWN

This shutdown command procedure asks you several questions, such as
the number of minutes until system shutdown and the reason for the
shutdown. The questions pertain to situations where you are doing an
orderly shutdown with users logged in to the system. You may either
provide specific answers to these questions, or simply press the RETURN
key to enter default values.
When you see the following message, the system is ready to shut down:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

Use CTRL/P to halt the system. When the console prompt prints out
(> > > ), the system is shut down.

3 Reboot the system by typing BOOT on the console terminal, or by
activating the BOOT switch on the Processor Control Panel.
Note: For the VAX-11/750, put the POWER ON ACTION switch in the
RESTART/BOOT position.
The system responds with a message in the following format:
VAX/VMS Version 4.4 <dd-mmm-yyyy hh:mm:ss.s>

XXXXXXXXXXX

OPCOM. <dd-mmm-yyyy hh:rm:s8.8> XXXXXXXXXXX
Loglile has been initialized by operator _OPAO:
Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1
y.SET-1-INTSET, login interactive limit = 64, Current interactive value = 0
SYSTEM
job terminated at <dd-mmm-yyyy hh:mm:ss.s>

2-14

Customizing the Operating System After Installation

2.8

Backing Up the System
Once you have installed and customized your system, DIGITAL recommends
that you perform the following operations (in order):
•

Back up the console volume

•

Back up the system disk

•

Build and copy a system disk

Step-by-step procedures are presented in the following sections.

2.8.1

Backing Up the Console Volume
You should make a backup copy of your console volume to protect
against corruption of your original. Sections 2.8.1.1 and 2.8.1.2 describe,
respectively, the procedures for backing up the console volume on VAX
system configurations with a single console storage device (VAX-11/780,
VAX-11/750) and for systems with two console storage devices (VAX-11/730
and VAX-11/725).
The operating system provides a command procedure called
CONSCOPY.COM in SYS$UPDATE that is designed to help you copy
your console volume to a blank one. You may use this procedure with
any member of the VAX family. Section 2.8.1.1 describes the use of
CONSCOPY.COM on VAX-11/780 and VAX-11/750 processors. If you
have a dual-drive console subsystem (currently available only on
VAX-11/730 and VAX-11/725 systems), refer to Section 2.8.1.2.

2.8.1.1

Console Volume Backups for Single-Drive Console Subsystems
The procedure described here applies directly to backing up the console
volume (floppy diskette media) on a VAX-11/780. However, by making
appropriate substitutions, you can also use it to back up the console volume
on other processors; for example, substitute "VAX-11/750" for "VAX-11/780"
and "console TU58" for "console floppy diskette".
This is a two-step procedure. First you save the console floppy diskette files
on a scratch disk directory; then you restore the files in the scratch directory to
an initialized floppy diskette. (You can use the blank floppy diskette included
in your distribution kit.)
To use CONSCOPY, proceed as follows:
1

2 At the DCL prompt, enter the following command:
$ <BSYS$UPDATE: CONSCOPY

CONSCOPY execution begins with this announcement:
SYSIUPDATE : CONSCOPY . COM
Save or restore a VMS console medium.

3 Enter your processor type at the following CONSCOPY prompt:
Which kit do you want to build [780, 750, 730, or 8600, default 780]:

2-15

Customizing the Operating System After Installation

When you enter your response, CONSCOPY processes it, and then
explains its operations:
A SAVE operation involves copying the console medium to
an RT-11 virtual volume, which is a Files-11 file that
is an image of the RT-11 console volume.
A RESTORE operation involves copying the entire contents
of a virtual volume to a console medium.

4 When CONSCOPY asks which operation you want, enter SAVE:
Do you want to SAVE or RESTORE your console floppy?: SAVE

Next, CONSCOPY prompts for the name of the virtual disk (see
explanation above) to which files are to be saved. Press the RETURN
key to select the default (SYS$DISK:CONSOLE.DSK):
Enter file name of virtual disk [default SYS$DISK:CONSOLE:DSK]:

I RET 1

6 To verify the copy operation, press the RETURN key in response to the
following prompt:
Do you want log messages as files are copied? [Y/N, default YES]

1 RET 1

CONSCOPY processes your response, and then prompts for the name of
the console device. Enter CSA1.
Enter console device drive (DDCU:): CSA1:

8 At the following prompt, insert your console volume in the console drive
and press RETURN:
Put your console floppy into drive _CSA1:,
and type <RETURN> when ready: 1 RET|

Note: You probably already have your console volume in the drive; this
request is more appropriate to the restore operation, during which you
must mount a target console volume in the drive.
When you indicate you are ready to continue, CONSCOPY mounts the
console volume, and then invokes the Exchange Utility to begin the save
operation. Several EXCHANGE messages are displayed, followed by file
header information and a list of the files that are being saved.
After completing the save operation, CONSCOPY prompts you to put your
console floppy diskette back into the console drive and press RETURN
when you are ready. (Again, this action is more appropriate to the restore
operation.) CONSCOPY then mounts the console volume with SYSTEM
and NOWRITE protection and returns you to command level.
The second phase of the console backup is the restoration of the console
image from the virtual disk files to RT-11 format on an initialized medium.
1

At the DCL prompt, again invoke CONSCOPY:
$ <DSYS$UPDATE: CONSCOPY

CONSCOPY announces itself and asks:
Which kit do you want to build [780, 760, 730 or 8600, default 780] :

Enter the same response as for the save operation.

3 After CONSCOPY describes its two operations and asks which one you
want, enter RESTORE.

4 WHEN CONSCOPY prompts for the name of the virtual disk, enter the
same response as for the save operation.

2-16

Customizing the Operating System After Installation

5 Next, tell CONSCOPY whether you want to log messages as files are
copied.
6

When CONSCOPY prompts for the name of the console device, again
enter CSA1.

7 At the following prompt, insert the target floppy diskette in the console
drive, and then press RETURN:
Put your console floppy into drive _CSA1:,
and type <RETURN> when ready: I RET 1

CONSCOPY mounts the target floppy diskette, and invokes the Exchange
Utility to execute the restore operation. Several EXCHANGE messages are
displayed, followed by file header information and a list of the files that
are being saved.
When the restore operation is completed, CONSCOPY prompts you to put
your original console floppy diskette back into the console drive and to
indicate when you are ready to continue by pressing RETURN.
After you press RETURN, CONSCOPY mounts the console volume with
SYSTEM and NO WRITE protection and returns you to command level.

2.8.1.2

Console Volume Backups for Dual-Drive Console Subsystems
This section provides a procedure for backing up your console volume if you
have a dual-drive console subsystem. The procedure is simplified because
of the dual-drive capability. First, you insert your original console TU58 in
CSA2, and a scratch TU58 in CSA1. Then, after mounting both devices, you
use the DCL command BACKUP to back up the original console TU58 onto
the scratch TU58.
You may use the blank TU58 included in your distribution kit if it was not
used for another purpose.
1

2 Check that the console TU58 is in CSA2.
3

Place a blank cartridge in CSA1. Be sure that the WRITE PROTECT tab
on the TU58 cartridge is set to permit writing, that is, slid in the direction
of the arrow inscribed on it.

4 Invoke SYSGEN from command level:
$ RUN SYS$SYSTEM:SYSGEN

When the SYSGEN > prompt appears, enter the following command:
SYSGEN> CONNECT CONSOLE

Then exit from SYSGEN:
SYSGEN> EXIT

When SYSGEN terminates, it returns you to command level. Mount CSA1
with this command:
$ MOUNT/FOREIGN CSA1

When the system confirms the mount, mount CSA2:
$ MOUNT/FOREIGN/NOWRITE CSA2

8 When the system confirms the mount, back up the console TU58 to a
blank TU58:
$ BACKUP/PHYSICAL/VERIFY CSA2: CSA1:

2-17

Customizing the Operating System After Installation

9 It takes approximately 30 minutes for BACKUP to complete the operation.
When the command level prompt appears, dismount the two cartridges
with the following commands:
$ DISMOUNT CSA1
$ DISMOUNT CSA2

You should use the newly created console cartridge as your console TU58 to
verify its correctness. Treat the original as the backup copy.

2.8.2

Backing Up the System Disk
To back up your system disk, DIGITAL recommends that you use standalone
BACKUP, which employs a subset of Backup Utility qualifiers. (Refer to
the VAX/VMS Backup Utility Reference Manual for a complete description
of the Backup Utility and its qualifiers.) It is especially important that you
understand the functions of the /IMAGE and /PHYSICAL qualifiers before
using standalone BACKUP.
/IMAGE

Allows you to create a functionally equivalent copy of the entire
volume or volume set.

/PHYSICAL

Copies, saves, restores, or compares the entire volume in terms
of logical blocks, ignoring any file structure.

If your system is distributed on magnetic tape, standalone BACKUP is
provided on the console media. (DIGITAL recommends making a copy of
standalone BACKUP on the console media.)
If your system was not distributed on magnetic tape, you must build a
standalone BACKUP kit either on console media or on disk. You can then
bootstrap standalone BACKUP from the console block storage device or from
the alternate directory root SYSE on a Files-11 disk.
Installing and using standalone BACKUP in an alternate root on your system
disk saves time when you are backing up your system disk, because you do
not have to boot standalone BACKUP from your console volume—a relatively
slow process.
The procedures described here apply to all VAX processors. However, you
should note the following:
•

You can install standalone BACKUP in any available disk directory root
from SYS1 through SYSE; however, DIGITAL has established SYSE as
the standard alternate system directory root for standalone BACKUP. The
discussion in this section assumes you will install standalone BACKUP in
SYSE.

•

You cannot use these procedures to restore your operating system to the
system disk from which standalone BACKUP is booted.

•

There are some limitations with regard to the VAX-11/750, which are
noted within the procedures.

•

The console device is CSA1 on VAX systems with a single console drive
and CSA2 on systems with two console drives.

The following sections explain how to
•

2—18

Install standalone BACKUP in alternate directory root SYSE

Customizing the Operating System After Installation

2.8.2.1

•

Create a command procedure to bootstrap standalone BACKUP from
SYSE.

•

Bootstrap standalone BACKUP from SYSE

•

Build a standalone BACKUP kit on console media

•

Bootstrap standalone BACKUP from console media

Installing Standalone BACKUP in Alternate System Root SYSE
You install standalone BACKUP in SYSE using the STABACKIT command
procedure. First, log in to the SYSTEM account. Then, enter this command:
$ ®SYS$UPDATE:STABACKIT SYS$SYSDEVICE:

Be sure to enter the command exactly as shown.
After you install standalone BACKUP in SYSE, the next step is to create a
command procedure to boot it.

2.8.2.2

Creating a Command Procedure to Bootstrap Standalone BACKUP
The recommended procedure for creating a command procedure to boot
standalone BACKUP from alternate root SYSE is to modify an existing boot
command procedure. Ideally, this should be the default boot command
procedure, DEFBOO.CMD (DEFBOO.COM for VAX 8600 series processors).
First, make a copy of the boot procedure in your default device directory.
Then, edit the copy as instructed. Finally, give the edited copy an appropriate
file name, and store it on the console volume.
You may choose any unique name in the form xxxBOO.CMD (or
xxxBOO.COM for VAX 8600) for the command procedure you create.
However, DIGITAL suggests you use a file name identical to the copied
file, except that the first letter should be an X.
For example, if you use a copy of DEFBOO.CMD, the new file should be
named XEFBOO.CMD.
The following procedure assumes you will use a copy of DEFBOO.CMD and
rename it XEFBOO.CMD.
1

If necessary, use the following command sequence to configure the console
device:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT CONSOLE
SYSGEN> EXIT

2 Insert the console volume into the console device.
3 Invoke the Exchange Utility to make a copy of DEFBOO.CMD in your
default disk directory:
For VAX-11/780 and VAX-11/750:
$ EXCHANGE COPY CS1:DEFBOO.CMD *

For VAX-11/730 and VAX-11/725:
$ EXCHANGE COPY CS2:DEFBOO.CMD *

Rename the copy of DEFBOO.CMD in your default directory.
$ RENAME DEFBOO.CMD XEFBOO.CMD

2-19

Customizing the Operating System After Installation

5 Invoke an editor to modify XEFBOO.CMD. The table below shows how to
determine the line that you must modify for your processor; it shows the
line before and after you change it. Note that you change only the first
digit.
Processor Type

Line to Change

Line After Change

VAX 8650

DEPOSIT R5 XXXXXXXX

DEPOSIT R5
EXXXXXXX

VAX 8600

DEPOSIT R5 XXXXXXXX

DEPOSIT R5
EXXXXXXX

VAX-11/785

DEPOSIT R5 XXXXXXXX

DEPOSIT R5
EXXXXXXX

VAX-11/782

DEPOSIT R5 XXXXXXXX

DEPOSIT R5
EXXXXXXX

VAX-11/780

DEPOSIT R5 XXXXXXXX

DEPOSIT R5
EXXXXXXX

VAX-11/750

D/G 5 XXXXXXXX

D/G 5 EXXXXXXX

VAX-11/730

D/G/L 5 XXXXXXXX

D/G/L 5 EXXXXXXX

VAX-11/725

D/G/L 5 XXXXXXXX

D/G/L 5 EXXXXXXX

6 When you have edited the file, call EXCHANGE to store it on the console
volume:
For VAX-11/780 and VAX-11/750:
$ EXCHANGE COPY XEFBOO.CMD CSA1:

For VAX-11/730 and VAX-11/725:
$ EXCHANGE COPY XEFBOO.CMD CSA2:

2.8.2.3

Bootstrapping Standalone BACKUP from SYSE
To boot standalone BACKUP from SYSE, you must perform the following
operations:
1

Shut the system down.
$ CSYSISYSTEM:SHUTDOWN.COM

2 The procedure asks the following questions. Respond by pressing the
RETURN key.
How many minutes until final shutdown? [0] I RET 1
Reason for shutdown? [Standalone] I RET|
Do you want to spin down the disk volumes? [NO] I RETI

3 As the shutdown continues, the console terminal prints several shutdown
messages. When the console terminal prints the following message,
shutdown is completed:
SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

At this point, halt the processor using CTRL/P.
4

When the processor halts, enter the following command to boot
standalone BACKUP from SYSE:
For VAX-11/750:
»> B/E0000000

2-20

Customizing the Operating System After Installation

For all other processors:
»> B XEF

5 If you are not using a modified version of the default bootstrap command
procedure to boot standalone BACKUP, use the first three characters in the
name of the bootstrap command procedure you created. For example, if
you are using XUOBOO.CMD, type the following command:
»> B XUO

6 When the application volume is booted, standalone BACKUP identifies
itself and displays the dollar sign ($) prompt:
7.BACKUP -1 - IDENT, Standalone BACKUP V4.4; the date is <dd-nunm-yyyy hh:mm>
$

2.8.2.4

Building a Standalone BACKUP Kit on Console Media
To build a standalone BACKUP kit on console media (RX01 diskettes, TU58
cartridges, an RL02 disk, and so forth), use the STABACKIT command
procedure. For the purpose of illustration, the procedure described in this
section assumes RX01 diskettes as the console media.
Note that the procedure may differ slightly for processors that use TU58
cartridges or other console media. For example, if your processor is a VAX
8600, standalone BACKUP is stored on a single RL02 disk, and you are
not prompted to insert additional volumes. If you have a VAX-11/780, the
console media are RX01 diskettes. For most other VAX systems, the console
media are TU58 cartridges. For VAX 8200 processor, the console medium is
an RX50 diskette. (See the specific processor installation guide for detailed
installation procedures.)
To build a standalone BACKUP kit on RX01 diskettes, proceed as follows:
1

Label four blank RX01 floppy diskettes SYSTEM_1, SYSTEM_2,
SYSTEM_3, and BACKUP, respectively.

Note: The number of standalone BACKUP console volumes may vary for
different processors.

2 Log in as system manager and invoke STABACKIT.COM.
3 When STABACKIT prompts you for the name of the target device, enter
CSA1:.

4 After you have identified the target device, STABACKIT tells you that four
blank floppies are needed to build the kit: three for the standalone VMS
files, and the fourth for the BACKUP application image.
STABACKIT also allows you either to build the VMS files as a system
kit without building the application kit (in this case BACKUP), or to
build both the system and application kits. Respond to both questions by
pressing the RETURN key.

5 Next, STABACKIT gives you the option of using the Bad Block Locator
Utility (BAD) to check for bad blocks on the target diskette. BAD requires
approximately 15 additional minutes for each diskette, but it may save
time by finding bad blocks that would otherwise cause problems in
building the kit.
Note: If you are building the kit on TU58 cartridges, allow approximately
two hours to run BAD (40 minutes per tape).

2—21

Customizing the Operating System After Installation

6 When STABACKIT prompts, insert the first system floppy diskette (labeled
SYSTEM _1) in the console drive and enter YES when you are ready to
continue:
Please place the first system floppy diskette in drive _CSA1:.
This volume will receive the volume label SYSTEM_1.
Enter "YES" when ready: YES

If you elect to run BAD, STABACKIT displays the following message:
Analyzing floppy diskette for bad blocks
SYSTEM.1
mounted on _CSA1:

The test takes approximately 15 minutes (40 minutes for each TU58).
Upon completion, BAD reports the number of blocks on the diskette and
the number that are bad. Then STABACKIT mounts the floppy diskette,
creates the directory [SYSO.SYSEXE], and copies to it the set of system files
while displaying appropriate messages.
7

When the last file is copied, STABACKIT prompts you to insert the next
floppy diskette. Replace the floppy diskette labeled SYSTEM_1 with the
floppy diskette labeled SYSTEM_2; then enter YES when you are ready
to continue:
Please place the second system floppy diskette in drive _CSA1:.
This volume will receive the volume label SYSTEM.2.
Enter "YES" when ready: YES

STABACKIT runs BAD (assuming you selected this option), mounts the
floppy diskette, and copies to [SYSO.SYSEXE] the set of system files while
displaying the appropriate messages.

8 When the last file is copied, STABACKIT prompts you to insert the next
floppy diskette. Replace the floppy diskette labeled SYSTEM_2 with the
floppy diskette labeled SYSTEM_3; then enter YES when you are ready
to continue:
Please place the second system floppy diskette in drive _CSAi:.
This volume will receive the volume label SYSTEM.3.
Enter "YES" when ready: YES

STABACKIT runs BAD (assuming you selected this option), mounts the
floppy diskette, and copies to [SYSO.SYSEXE] the set of system files while
displaying the appropriate messages.

9 When the last file is copied, STABACKIT prompts you to insert the fourth
RX01 diskette. Replace the floppy diskette labeled SYSTEM—3 with the
application floppy diskette labeled BACKUP, and enter YES when you are
ready to continue:
Please place the application floppy diskette in drive _CSA1:.
This volume will receive the volume label BACKUP.
Enter "YES" when ready: YES

STABACKIT runs BAD, mounts the floppy diskette, and copies the
executable BACKUP image (STABACKUP.EXE) to [SYSO.SYSEXE].
10 When the next message appears (indicating that the kit is built), replace
the floppy diskette labeled BACKUP with the console floppy diskette; then
enter YES when you are ready to continue:
The console volume will be mounted /NOWRITE for protection.
Please replace the original console floppy diskette.
Enter "YES" when ready: YES

2-22

Customizing the Operating System After Installation

The procedure responds by mounting the console floppy diskette,
reporting the starting and ending times, and then returning you to
command level.

2.8.2.5

Bootstrapping Standalone BACKUP from Console Media
For purposes of illustration, the procedure described in this section assumes
TU58 cartridges as the console media. However, the procedure is also
applicable to other types of console media.

Note: The number of standalone BACKUP console volumes may vary for
different processors.
To bootstrap standalone BACKUP from console media, follow these steps:
1

On VAX-11/780, VAX-11/750, and VAX 8600 systems insert the console
media and go to Step 3. For most other processors, insert the console
TU58 in the CSA2 drive, and insert the standalone volume labeled
SYSTEM_1 in the CSA1 drive. (On UDA- or RA80-based VAX-11/730
systems and VAX-11/725 systems, CSA1 is on the right-hand side of the
processor control panel. On UDA-based VAX-11/730 systems, CSA1 is
the left-hand drive.)

2 If the processor is not in console mode, press CTRL/P.
3 When the console terminal prints the console mode prompt (> > > ),
issue the following command:

For VAX 8600, VAX 8200, VAX-11/780, VAX-11/730, VAX-11/725:
»> B CS1

For VAX-11/750:
»> B DDAO

4 You will be prompted to place successively in the console drive the
volumes containing the standalone BACKUP kit. Note that if your
processor is a VAX 8600, standalone BACKUP is stored on a single RL02
disk, and you will not be prompted to insert additional volumes. The
first prompt directs you to replace the console TU58 with the standalone
volume labeled SYSTEM _1 and to enter YES when you are ready to
continue. (On VAX-11/730 and VAX-11/725 systems, you are prompted
to replace the SYSTEM_1 volume in the console device with the first
standalone volume; ignore the message and just enter YES.) When you
enter YES (or Y), the procedure displays this message:
Resuming load operation on volume 'SYSTEM_1', please stand by...

(Proceed on VAX-11/750 systems as described for VAX-11/730 and
VAX-11/725 systems.)

5 When the first volume is booted, the procedure prompts you to replace it
with the standalone volume labeled SYSTEM_2 and to enter YES when
you are ready to continue. When you enter YES, the procedure displays
the following message:
Resuming load operation on volume 'SYSTEM_2', please stand by...

This procedure is repeated for the volume labeled SYSTEM _3. When
the third volume finishes booting, the standalone system announces itself
and may ask you to enter the date and time, depending on whether your
processor has a time-of-year clock. If a calendar year has ended since
the software was generated, you will be prompted for date and time.

2—23

Customizing the Operating System After Installation

Enter the information in the format displayed by the prompt and press
RETURN.
Note: If applicable, the standalone system configures and lists your HSC and
MSCP-served devices. If you are building your system on an HSC
disk, enter the appropriate device name from this list in place of the
variable system device when you restore the required save set. For
detailed information on restoring the save set, refer to the installation
booklet for your VAX processor.

7 Next, the procedure prompts you to replace the third volume with the
application volume labeled BACKUP and to enter YES when you are
ready to continue.
When you enter YES, the procedure displays this message:
Resuming load operation on volume 'BACKUP', please stand by...

When the application volume is booted, standalone BACKUP identifies
itself and displays the dollar sign ($) prompt:
y,B ACKUP -1 - IDENT, Standalone BACKUP V4.4; the date is <dd-mmm-yyyy hh:mm>
$

Issue the appropriate BACKUP command; for example, this command
format is adequate for most BACKUP operations:
BACKUP/IMAGE/VERIFY/LIST=llcu: ddcu: mmcu:savset.bck/SAVE

where

lieu:
A line printer (for example LPAO) to print a listing of BACKUP save sets.

ddcu:
A system disk (for example DRAO).

mmcu:
A save set destination device (for example MTAO).
See the VAX/VMS Backup Utility Reference Manual for more information
on BACKUP commands and qualifiers.
Note: Do not remove the BACKUP cartridge from the CSA1 drive until
directed to do so.
When your backups are completed, press CTRL/P to halt the processor and
terminate standalone BACKUP.

2.8.3

Building and Copying a VAX/VMS System Disk
At some point, you may want to transport your operating system files to
another disk. For example, assume that your operating system is initially
stored on an RK07 disk together with some of your user files. Assume further
that you have purchased an RP06 disk drive and that you want to move
only the operating system files from the RK07 to the RP06. You can build
the operating system on the RP06 without affecting the user files on the
RK07 by using the VMSKITBLD command procedure. You should note that
the VMSKITBLD BUILD function effectively eliminates any software on the
target disk.

2—24

Customizing the Operating System After Installation

Another way to use VMSKITBLD.COM is illustrated in this situation. Assume
that you are currently using an RK07 to store operating system files and
user files, and that you have an RP06 that you are using for user files. You
decide to purchase additional optional software products that layer onto the
operating system, but you do not have enough space on the RK07 for the
additional software. Here, you would like to move the operating system files
to the RP06 without affecting the user files on the RP06. In this situation,
you can use the COPY capability of VMSKITBLD because the COPY function
does not affect files that are currently on the target disk.

2.8.3.1

Building the Operating System on Another Disk
If you want to build your operating system on another disk, and you are not
concerned about losing anything on the target disk, use the VMSKITBLD
BUILD function as illustrated in the following procedure.
Note: VMSKITBLD.COM, automatically dismounts the target disk when the kit
is completed.
1

Bootstrap the operating system from the source disk, typically an RK07.

2 Log in to the system manager's account.
3 Establish SYS$UPDATE as the default directory:
$ SET DEFAULT SYSlUPDATE

4 Place the target disk (assuming you are using a removable disk) in an
appropriate drive and put it on line.
5

Enter the following command to invoke VMSKITBLD.COM:
$ ©VMSKITBLD

6 In response to VMSKITBLD prompts, supply the requested information
about the source and target disk drives.

7 After you supply the required information, VMSKITBLD asks:
Operation [BUILD.ADD.COPY.COMMON]?

Enter the word BUILD. (If you want your target disk to be built as a
cluster-common system disk, also enter COMMON.)
Caution: The BUILD option destroys all previous information on the target disk
before it builds the operating system.
When the build resumes, you will receive messages that either prompt
you for information needed to complete the operation, or inform you of
the procedure's status.
A typical message sequence might look like this:
Enter mounted source disk name (DDCU:): SYS$SYSDEVICE:
Enter SOURCE disk top level system directory [default = SYSO]:
Enter target disk name (DDCU:): DRAO: I RET 1
Enter the target disk's label [default = VAXVMSRL4]:
|
Enter TARGET disk top level system directory [default = SYSO]:
It will be necessary to initialize the target disk.
Is the target disk, DRAO:, ready to be initialized? (Y/N): Y
_DRAO: allocated

I RET 1

lRETJ

2—25

Customizing the Operating System After Installation

'/.MOUNT-I-MOUNTED, VAXVMSRL4
mounted on _DRAO:
Create directory entries on the target disk.
Copy the system executive files.
Copy the system library files.
Copy the system message files.
Copy the system manager files.
Copy the system update command files.
Copy the system EXE files.
Copy the system help files.
Write a bootblock.
Copy BLISS require files and STARLET DCL library.
Copy coding examples.
Copy the UETP files.

When the system disk is built, VMSKITBLD.COM automatically dismounts
the disk, and then sends the following message to your terminal:
Kit is complete.

At this point, the target disk contains all the required VAX/VMS files for a
complete system. You can configure the system properly by bootstrapping
with the default parameters and then using the AUTOGEN procedure to
configure the target system.
If you have a VAX-11/780, bootstrap the system with the default
parameters, using the GEN version of the bootstrap command file:
»> ©dduGEN

If you have a VAX-11/750, enter:
»> B/l ddcu

9 When the SYSBOOT> prompt appears, enter the following commands:
SYSB00T> USE DEFAULT
SYSB00T> CONTINUE

10 After the system bootstraps, log in as system manager and run the
AUTOGEN procedure described in Section 11.

2.8.3.2

Copying the Operating System Files to Another Disk
You can also use VMSKITBLD.COM to copy the operating system files to a
target disk without affecting the files that are already on it. But first, your
VAX/VMS system must be running and the source disk that you intend to
copy must be mounted.

Note: VMSKITBLD.COM automatically dismounts the target disk when the kit
is completed.
Often, this source disk is the system disk from which the system was
bootstrapped. Proceed as follows to copy the source disk to a target disk:
1

2 Establish SYS$UPDATE as the default directory:
$ SET DEFAULT SYS$UPDATE

3 Place the target disk on an appropriate drive.
4 Enter the following command to invoke VMSKITBLD:
$ ©VMSKITBLD

5 In response to VMSKITBLD prompts, supply the requested information
about the source and target disk drives.

2-26

Customizing the Operating System After Installation

After you supply this information, VMSKITBLD asks:
Operation [BUILD,ADD,COPY.COMMON]?

Enter the word COPY.

7 After you reply, you will receive messages that either prompt you for
information needed to complete the copy operation, or inform you of the
procedure's status.
8

When the copy operation is finished, VMSKITBLD automatically
dismounts the disk and sends you the following message:
Kit is complete.

2.8.3.3

Adding an Operating System to an Existing System Disk
There are cirumstances in which you will find it convenient to add another
operating system to a system disk:
•

You want to test software on a new operating system version. You could,
for example, install the new version on an alternate directory root and
create a bootstrap command procedure to select that version for testing
sessions.

•

You need to conserve disk drives.

Note that you must add the new system on an unused directory root. Use
the ADD function of VMSKITBLD.COM in SYS$UPDATE, as illustrated
in the following prodedure. (Do not confuse this function with the
MAKEROOT.COM command procedure, which creates system directory
roots for VAXcluster member nodes.)
1

2 Establish SYS$UPDATE as the default directory:
$ SET DEFAULT SYS$UPDATE

3 Place the target system disk (assuming you are using a removable disk) in
an appropriate drive and put it on line.
4

Enter the following command to invoke VMSKITBLD.COM:
$ <D VMSKITBLD

5 In response to VMSKITBLD prompts, supply the requested information.
6

After you supply the information, VMSKITBLD asks:
Operation [BUILD.ADD.COPY.COMMON]?

Enter the word ADD.
You will receive messages that either prompt you for information needed
to complete the operation, or inform you of the procedure's status.
When you are prompted for the mounted source disk name, enter
SYS$SYSROOT: if the source is a common root; otherwise, enter
SYS$SYSDEVICE:.
When you are prompted for the source disk top level system directory,
enter the directory from which you wish to copy system files.
When you are prompted for the target disk top level system directory, be
sure to enter a directory root not already in use. (Note that in addition
to roots used by existing systems on the disk, roots SYSE and SYSF are
reserved for other system functions.)

2—27

Customizing the Operating System After Installation

A typical message sequence might look like this:
Enter mounted source disk name (DDCU:): SYS$SYSROOT:
Enter SOURCE disk top level system directory [default = SYSO]: SYS4 I RET|
Enter target disk name (DDCU:): SHEMPlDUAl: I RET|
Enter the target disk's label [default = VAXVMSRL4]: IRET|
Enter TARGET disk top level system directory [default = SYSO]: SYSA I RET|
Allocate and mount target disk.
_SHEMP$DUA1: allocated
‘/.MOUNT-1-MOUNTED, VAXVMSRL4
mounted on _SHEMP$DUA1:
Create directory entries on the target disk.
Copy the system executive files.
Copy the system library files.
Copy the system message files.
Copy the system manager files.
Copy the system update command files.
Copy the system EXE files.
Copy the system help files.
Write a bootblock.
Copy BLISS require files and STARLET DCL library.
Copy coding examples.
Copy the UETP files.

VMSKITBLD.COM informs you when the operation completes by sending
the following message to your terminal:
Kit is complete.

At this point, the target system directory contains all the required
VAX/VMS files for a complete system. (Note that if any layered products
from the source system are needed on the new system, you must reinstall
them.)

7 Create a bootstrap command procedure, as follows, to boot the new
operating system. (Note that for VAX-11/730 and VAX-11/725, the
console device is CSA2:.)

Copy DEFBOO.CMD (DEFBOO.COM for VAX 8600) from the console
medium to your default disk directory, renaming the file SYxBOO.CMD
(or SYxBOO.COM), where x represents the selected root. For example,
if you wish to boot from SYSA, name the file SYABOO.CMD:
$ RUN SYSISYSTEM:SYSGEN
CONNECT CONSOLE
$ MOUNT /FOREIGN CSA1:
$ EXCHANGE COPY /LOG CSA1:DEFBOO.CMD SYABOO.CMD

2-28

Invoke an editor to modify SYABOO.CMD. The table below shows
how to determine the line that you must change for your processor; it
shows the line before and after you change it. Note that you change
only the first digit.
Processor

Line to Change

Line After Change

VAX 8650

DEPOSIT R5 XXXXXXXX

DEPOSIT R5 AXXXXXXX

VAX 8600

DEPOSIT R5 XXXXXXXX

DEPOSIT R5 AXXXXXXX

VAX-1 1/785

DEPOSIT R5 XXXXXXXX

DEPOSIT R5 AXXXXXXX

VAX-1 1/782

DEPOSIT R5 XXXXXXXX

DEPOSIT R5 AXXXXXXX

VAX-11/780

DEPOSIT R5 XXXXXXXX

DEPOSIT R5 AXXXXXXX

VAX-11/750

D/G 5 XXXXXXXX

D/G 5 AXXXXXXX

VAX-11/730

D/G/L 5 XXXXXXXX

D/G/L 5 AXXXXXXX

VAX-11/725

D/G/L 5 XXXXXXXX

D/G/L 5 AXXXXXXX

Customizing the Operating System After Installation

Copy the edited file back to the console medium:
$ EXCHANGE COPY /LOG SYABOO.CMD CSA1:

After shutting down the system and pressing CTRL/P to halt the
processor, you can bootstrap with the procedure you created.
•

For processors other than the VAX-11/750, enter the following
command at the console prompt:
»> B SYA

•

On the VAX-11/750, you can boot in two ways:
a

From unit 0 (DB0:,DM0:,DR0:,DU0:):
»> B/AXXXXXXX

From the console TU58:
»> B DDAO
B00T58> B SYA

When the SYSBOOT> prompt appears, enter the following commands:
SYSB00T> USE DEFAULT
SYSB00T> CONTINUE

If you are running in a VAXcluster, it is important to verify and, if
necessary, reset values (using SHOW and SET commands) for the
following SYSGEN parameters before rebooting:
•

ALLOCLASS

•

DISK-QUORUM

•

QUORUM

•

SCSSYSTEMID

•

SCSSYSTEMIDH

•

SCSNODE

•

VAXCLUSTER

•

VOTES

For more information on these parameters, refer to the VAX/VMS System
Generation Utility Reference Manual or the Guide to VAXclusters.

9 After the system bootstraps, log in as system manager and run the
AUTOGEN procedure described in Section 11.

2-29

Customizing Small-Disk Systems

This chapter discusses the VAX/VMS small-disk environment, including
supported configurations, operating system file groups, the VAX/VMS
Tailoring facility (VMSTAILOR), and operating procedures peculiar to smalldisk systems. Error and informational messages from the facility are also
described.
Currently, DIGITAL supports the following small-disk systems:
•

VAX-11/725 systems

•

Systems with dual-RK07 disk configurations

During an installation or upgrade procedure, you indicate that you want
to generate a tailored system by responding to the appropriate prompts.
You can then use the Tailoring facility to customize your system for specific
applications.
Note: Tailoring is presently supported only on system configurations that have
less than 140,000 blocks of disk space.
In small-disk systems, a library disk supplements the system disk. At any
instant, the system disk need include only those portions of the operating
system that are necessary to perform a particular task. Whenever you want to
tailor your system disk for a certain task, you use tailoring commands to copy
the appropriate operating system files from the library disk to the system disk
and to remove from the system disk any files that are not needed. In this
way, you obtain additional space for user files on the system disk. (Tailoring
commands are described in Section 7.3.)
Note that the size of the library disk must be at least 20,000 blocks.
Moreover, if it is less than 30,000 blocks, there will be insufficient space
for the optional save set, which includes the system map, BLISS require files,
and the SYS$EXAMPLES directory.

3.1

DIGITAL-Supplied File Groups
To facilitate tailoring procedures in small-disk environments, operating
system files are divided into groups. A file group is a file that lists each file in
a particular group in the following format:
[directory]name.type

DIGITAL supplies a standard set of file groups with small-disk systems. For
added flexibility, you can create your own file groups, using the format of the
DIGITAL-supplied file groups. This section describes the file groups provided
by DIGITAL; the next section outlines procedures for creating site-specific file
groups.
Files provided by DIGITAL on the library disk are divided into task-related
groups. For example, the files used to manage queues are collected in a
file group called QUEUES. When you want queue management capability,
you specify QUEUES as the parameter for the tailoring COPY command.

3-1

Customizing Small-Disk Systems

VMSTAILOR then copies all files in the QUEUES file group from the library
disk to the system disk.
Conversely, if you do not need a particular operating system function, you
can remove the related file group from the system disk. For example, after
you run the User Environment Test Package (UETP), you can remove the
operating system files that support this function by specifying UETP as the
parameter in a tailoring DELETE command.
Following is a list with a brief description of the DIGITAL-supplied file
groups. The approximate size of each group, in blocks, is included in the list
to help you make tailoring decisions.
SYSTEM FILE GROUP
•

REQUIRED—files needed to boot the VAX/VMS operating system and
to perform basic file manipulations, such as COPY, RENAME, and
TAILORING, and to provide all the features of the VMS executive.
Support for all standard VAX processors and devices is included. These
files should not be removed from the system disk. (6423 blocks)

LIBRARY FILE GROUPS

3-2

•

BLISSREQ—source files used to generate compile-time libraries during
VAX BLISS language installation. These files may be deleted after the
BLISS language installation is complete. (2816 blocks)

•

DECNET—files that give the system a local networking capability.
However, you must purchase a separate kit and license to gain multinode
networking capability. (1309 blocks)

•

DEVELOP—files used for the development of application programs.
They include the EDT editor, MACRO assembler, VAX/VMS Librarian,
VAX/VMS Linker, VAX/VMS Debugger, and the libraries that they use.
Help text for these utilities is also included. (8098 blocks)

•

EXAMPLES—programming examples for various VAX/VMS applications,
along with the system map. These examples are also reproduced in the
microfiche source listings. (1643 blocks)

•

FILETOOLS—utilities used to analyze and dump files and to create and
modify ISAM files. (610 blocks)

•

HELP—help text displayed by the VMS HELP command and various
system utilities. (4363 blocks)

•

LIBRARY—libraries used during the assembly, linking, and compilation of
programs. (5753 blocks)

•

MANAGER—files used to perform system management functions. They
include accounting, disk quota, volume preparation and maintenance, and
user authorization functions, as well as command procedures used by the
system manager. (1575 blocks)

•

MISCTOOLS—system programming support tools, tools for analyzing
crash dumps, and other miscellaneous tools. (2306 blocks)

•

QUEUES—files that are used to initialize, start, and stop the batch and
device queues, and to submit jobs. (194 blocks)

•

TEXTTOOLS—files used for text editing and text formatting. They include
all editors and DIGITAL Standard Runoff. (580 blocks)

Customizing Small-Disk Systems

•

UETP—User Environment Test Package files, which provide a variety of
tests to ensure that your VMS system is operating properly. (494 blocks)

To obtain a list of files in a file group, invoke the Tailoring facility with the
following DCL command:
$ <BSYS$UPDATE: VMSTAILOR

When the system responds with the Tailor > prompt, you can request, for
example, a list of files in the QUEUES file group:
Tailor> DIRECTORY QUEUES
Contents of QUEUES Group
[SYSEXE]INPSMB.EXE
[SYSEXE]PRTSMB.EXE
[SYSEXE]QUEMAN.EXE
[SYSEXE]SUBMIT.EXE
[SYSEXE]SMBSRVSHR.EXE

3.2

Creating Site-Specific File Groups
You can create file groups for your own site-specific applications by following
the format of the DIGITAL-supplied file groups. Be sure, however, not
to modify the file groups provided by DIGITAL, because they are used
for system updates and upgrades as well as for optional software product
installations.
You may use any text editor to create a file that lists a file group. If you create
a new file group by modifying a copy of a DIGITAL-supplied file group, be
sure to assign a new file name to the file you create, and be careful not to
modify the DIGITAL-supplied file. For example, if you want to create your
own text-processing file group by editing SYS$UPDATE:TEXTTOOLS.TLR
with the EDT editor, the following command will ensure that the new file has
a new name and that the DIGITAL-supplied file is not altered:
$ EDIT /OUTPUT=new_rile_name SYS$UPDATE:TEXTTOOLS.TLR

Since the DIGITAL-supplied system file group files reside in the
SYS$UPDATE directory on the system disk and have the file type TLR,
you need not include the device, directory, or file type when you refer to
them in tailoring commands.
If you want to put the file groups you create in a different directory or
on a different device, you must explicitly specify the files in the tailoring
commands. For example, if you create a file group named SPECIAL.TLR and
store it in directory [USER.JOBS] on device USER$DISK, use the following
command to copy it to the system disk:
Tailor> COPY USER$DISK:[USER.JOBS]SPECIAL

3-3

Customizing Small-Disk Systems

3.3

Tailoring Commands
The Tailoring facility provides a set of commands and qualifiers you use to
tailor your system disk. The key to tailoring is knowing which file groups you
need to support your system operations, and then copying only those groups
to the system disk.
There are two ways to issue tailoring commands. You can either invoke the
facility and enter commands at the tailoring command level, or you can, with
a single DCL command, specify a particular tailoring function.
To work from the tailoring command level, use the following procedure:
1

2 At the DCL prompt, enter the following command:
$ ®SYS$UPDATE:VMSTAILOR

The system responds with the Tailor > prompt to indicate that you are at
the tailoring command level.
To return to DCL level, use the tailoring command EXIT.
If you want to tailor from DCL level, enter a single-line DCL command to
invoke tailoring and specify the tailoring function you want. For example, if
you are at DCL level and you want to copy the TEXTTOOLS file group to the
system disk, first make sure that the library disk has been mounted with the
tailoring command MOUNT, and then enter the following command:
$ ®SYS$UPDATE:VMSTAILOR COPY TEXTTOOLS

DCL invokes the Tailoring facility, which executes the command and returns
you to DCL level.
Table 3-1 summarizes the VMSTAILOR commands. When you use tailoring
commands, observe the following rules:
•

The commands that use file group names as parameters accept any unique
abbreviation of a name. However, if you have created a file group that
resides in a device and directory other than SYS$UPDATE, you will have
to be explicit in identifying the device and directory when you specify the
file group name as a parameter.

•

For the COPY, DELETE, DIRECTORY/SIZE, and RECORD commands
to execute, the library disk must be mounted with the tailoring command
MOUNT.

•

The library disk should be used as a read-only source of VAX/VMS
file groups. In order to support system upgrades and updates, its
contents should not be altered. Mount the library disk with the /WRITE
qualifier only during maintenance updates or layered product installations.
(VMSINSTAL, for example, mounts the library disk /WRITE.)

•

The /LIBRARY qualifier is reserved for use by the command procedures
that are used to do updates and upgrades. You should never use this
qualifier when you are tailoring your system.

Caution: If you alter your library disk, you will produce an unsupported software
configuration that may result in incorrect system operation.

3-4

Customizing Small-Disk Systems

Table 3-1

VMSTAILOR Command Summary

Command

Function

COPY file-group[, . . . ]

Copies the specified file groups from the
library disk to the system disk

DELETE file-group[, . . . ]

Deletes previously copied file groups from
the system disk

DIRECTORY file-group[, . . . ]

Gives a directory of the files in the
specified file groups

DISMOUNT [ddcu:]

Dismounts the library disk from the
specified device

EXIT

Exits from the Tailoring facility

HELP [topic] [subtopic]

Explains the specified tailoring commands
and qualifiers

MOUNT ddcu: [label]

Mounts the library disk on the specified
device

RECORD match [revised]

Creates a file listing all VAX/VMS files
found on the library disk that have a match
on the system disk

SEARCH file-spec

Locates the file groups in which the
specified file resides

COPY Command
Copies file groups or individual files in the specified file groups from the
library disk to the system disk. The copied files replace any older versions.
The COPY command takes the form:
COPY file-group[,...]
/CONFIRM
/FILE
/LIBRARY
/LOG

file-group
Specifies one or more file groups or an individual file to be copied.

/CONFIRM
Asks you to confirm that you want each file in the group copied. If you
respond with N, the associated file is not copied. If you reply Y or press the
RETURN key, the file is copied.

/FILE
Indicates that an individual file is to be copied instead of a file group. You
must use a file specification in place of the file group parameter with this
qualifier. A default device and directory of LIB$SYSROOT:[SYSEXE] and a
default file type of EXE are assumed. When you use the /LIBRARY qualifier
with the /FILE qualifier in update and upgrade command procedures, a
default device and directory of SYS$SPECIFIC:[SYSEXE] and a default file
type of EXE are assumed. You may use wildcards in the file specification, but
not lists of file specifications.

3-5

Customizing Small-Disk Systems

/LIBRARY
This qualifier is reserved for use by update and upgrade command procedures
to copy files from the system disk to the library disk. Do not specify this
qualifier when using tailoring commands interactively.

/LOG
Displays the name of each file that is copied.

Example
The following command copies files in the QUEUES and FILETOOLS groups
from the library disk to the system disk and displays the name of each file at
the terminal.
Tailor> COPY/LOG QUEUES.FILETOOLS

The facility responds by listing the files that are copied.
If the system disk does not have enough space to copy a file group, you
receive the following message:
'/.BACKUP-E-OPENOUT, error opening SYS$SPECIFIC: [SYSEXE] EDF. EXE; 1 as output
-RMS-F-FUL, device lull (insufficient space for allocation)

If this happens, you can use the DELETE command to remove unnecessary
files from the system disk and then try copying again.

DELETE Command
Deletes all versions of each file in the specified file groups from the system
disk. The command checks for a backup copy on the library disk before doing
the deletion. The DELETE command takes the form:
DELETE file-group[....]
/CONFIRM
/FILE
/LIBRARY
/LOG
/OVERRIDE

file-group
Specifies one or more file groups or an individual file to be deleted from
the system disk. The REQUIRED file group cannot be deleted using this
command.

/CONFIRM
Asks for confirmation before deleting each file. If you enter N or press the
RETURN key, the file is not deleted. If you enter Y, the file is deleted.

/FILE
Indicates that an individual file is to be deleted instead of a file group. You
must use a file specification in place of the file group parameter with this
qualifier. A default device and directory of LIB$SYSROOT:[SYSEXE] and a
default file type of EXE are assumed. When you use the /LIBRARY qualifier
with the /FILE qualifier in update and upgrade command procedures, a
default device and directory of SYS$SPECIFIC:[SYSEXE] and a default file
type of EXE are assumed. You may use wildcards in the file specification, but
not lists of file specifications.

3-6

Customizing Small-Disk Systems

/LIBRARY
This qualifier is reserved for use by update and upgrade command procedures
to delete files from the library disk. Do not specify this qualifier when using
tailoring commands interactively.

/LOG
Displays the name of each file that is deleted.

/OVERRIDE
Overrides the check for a backup copy before deleting. This qualifier permits
you to delete files on the system disk without having to mount the library
disk.

Example
The following command deletes the files in the LIBRARY group from the
system disk.
Tailor> DELETE/CONFIRM LIBRARY

The facility then displays the name of each file that you may elect to delete
and asks you to confirm the deletion by entering Y:
SYS$SPECIFIC:[SYSEXE]MP.STB;1 delete? (Y or N) : Y
SYS$SPECIFIC:[SYSEXE]SYS.STB;1 delete? (Y or N) : Y
SYSISPECIFIC:[SYSEXE]SYSDEF.STB;1 delete? (Y or N) : Y
SYS$SPECIFIC:[SYSLIB]FORDEF.FOR;1 delete? (Y or N) : Y
SYS$SPECIFIC:[SYSLIB]FORIOSDEF.FOR;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]IMAGELIB.OLB;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]LIB.MLB;1 delete? (Y or N) : N
SYS$SPECIFIC:[SYSLIB]LIBDEF.FOR;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]MTHDEF.FOR;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]SIGDEF.FOR;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]STARLET.MLB;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]STARLET.OLB;1 delete? (Y or N) : N
SYSISPECIFIC:[SYSLIB]XFDEF.OLB;1 delete? (Y or N) : N

DIRECTORY Command
Lists the contents of the specified file groups. The DIRECTORY command
takes the form:
DIRECTORY file-group [_]
/GROUPS
/OUTPUT=file-spec
/SIZE

file-group
Specifies the file group.

/GROUPS
Lists all the file groups available in the SYS$UPDATE directory. No
parameters are allowed with this qualifier.

/OUTPUT=file-spec
Requests that the output listing be written to the specified file rather than to
the current SYS$OUTPUT device. The default file type is LIS.

/SIZE
Requests that the size of each file be displayed along with its name.

3-7

Customizing Small-Disk Systems

Example
The following command lists the files in the HELP and REQUIRED groups in
an output file called HELREQ.LIS.
Tailor> DIRECTORY/OUTPUT=HELREQ HELP,REQUIRED

DISMOUNT Command
Dismounts the library disk from the specified device and deassigns the logical
names defined by VMSTAILOR when the disk was mounted. Table 3-2 lists
these logical names.
Table 3-2

Library Disk Logical Name Definitions

Logical Name

Definition

LIB$SYSDEVICE

= ddcu:

LIBSTOPSYS

= SYSO

LIBSSYSROOT

= ddcu:[SYSO.]

LIB$ERRORLOG

= LIBSSYSROOT :[SYSERR]

LIBSHELP

= LIBSSYSROOT :[SYSHLP]

LIBSLIBRARY

= LIBSSYSROOT :[SYSLIB]

LIBSMAINTENANCE

= LIBSSYSROOT :[SYSMAINT]

LIB$MANAGER

= LIBSSYSROOT :[SYSMGR]

LIB$MESSAGE

= LIBSSYSROOT :[SYSMSG]

LIB$SHARE

= LIBSSYSROOT :[SYSLIB]

LIBSSYSTEM

= LIBSSYSROOT :[SYSEXE]

LIB$TEST

= LIBSSYSROOT :[SYSTEST]

LIB$UPDATE

= LIBSSYSROOT :[SYSUPD]

The DISMOUNT command takes the form:
DISMOUNT [ddcu:]

ddcu:
Specifies the drive from which you want to dismount the library disk. If you
do not specify a device, the logical name LIB$SYSDEVICE: is used as the
default.

EXIT Command
Exits from the Tailoring facility and returns you to DCL level. The EXIT
command takes the form:
EXIT

HELP Command
Gives detailed descriptions of all the tailoring commands and qualifiers. If
you type only HELP, you will receive an explanation of the HELP command
and a list of other topics described in the Help file. The HELP command
takes the form:
HELP [topic]

3-8

[subtopic]

Customizing Small-Disk Systems

topic
Specifies any of the commands, plus the additional topic of GROUPS.

subtopic
Can be a qualifier when used with a command topic, or a group name when
used with the GROUP topic.

Example
The following command displays information about the DEVELOP file group.
Tailor> HELP GROUPS DEVELOP

The system responds with the following information:
GROUPS
DEVELOP
Develop files are used for the development of application
programs.
They include the EDT editor, MACRO-32 assembler,
VAX/VMS librarian, VAX/VMS linker, VAX/VMS Debugger, and
the libraries they use.
Help text for the mentioned utilities
is also included.

MOUNT Command
Mounts the library disk on the specified disk drive, and defines appropriate
logical names (see Table 3-2). To use the COPY, DELETE, DIRECTORY
/SIZE, and RECORD commands, you must have mounted the library disk
with the MOUNT command. The MOUNT command uses the format:
MOUNT[/WRITE] ddcu:

[label]

/WRITE
Lets you write to the library disk. Use the /WRITE qualifier only if you are
installing optional software or if you want to run the UETP.

ddcu:
Specifies the drive on which you wish to mount the library disk.

label
Specifies the label of the library disk you wish to mount. VAXVMSLB4 is the
default label.
Caution: If you alter your library disk, you will produce an unsupported software
configuration, and you may adversely affect system operation. The library
disk is write protected by default.

Example
The following command mounts the library disk in the DQA1 drive:
Tailor> MOUNT DQA1:

RECORD Command
Creates a file group containing names of all the VMS files on the library disk
that currently match those on the system disk. With this command, you can
save a record of a unique group of files for later use. The RECORD command
takes the form:
RECORD match-file-group [revised-file-group]

3-9

Customizing Small-Disk Systems

match-file-group
Provides a name for the match-file group you want to create. Both the name
and revision date of a file must match on both disks for the file to be listed
in this file group. If multiple versions of a file exist, only the latest version is
compared and listed.

revised-file-group
Provides a name for the revised-file group you want to create. This group
includes the files on the system disk that have a matching name on the library
disk but have a different revision date. If you do not specify a revised-file
group and there are revised files on the system disk, you receive an error
message for each revised file.
A RECORD command is typically followed by a DELETE command to allow
another software configuration to be created on the system disk. Then the file
group created by the RECORD command can be copied back to the system
disk at a later date, restoring the old configuration.

Examples
To list the current tailored software configuration in a file group called
MYCONFIG, invoke VMSTAILOR, mount the library disk using the MOUNT
command, and issue the following RECORD command:
Tailor> RECORD MYCONFIG

Now delete MYCONFIG from the system disk, using the DELETE command.
Tailor> DELETE MYCONFIG

You can then build a new system disk configuration by copying other file
groups to the system disk. For example, if you wish to create an environment
in which system management functions can be performed, you would issue
the following command:
Tailor> COPY MANAGER

Now you can dismount the library disk with the tailoring DISMOUNT
command, and perform system management operations. When you want
to restore the previous configuration, remount the library disk and type the
following commands:
Tailor> DELETE MANAGER
Tailor> COPY MYCONFIG

SEARCH Command
Locates the file group(s) in which a specified file resides. The SEARCH
command takes the form:
SEARCH file-spec

file-spec
Specifies the name of a file to be located. No wildcards are allowed. Output
is written to SYS$OUTPUT.

3-10

Customizing Small-Disk Systems

3.4

Special Operations for Small-Disk Systems
The space limitations of a small-disk system require you to perform certain
operations differently than you would in a large-disk environment. These
operations are
•

Running the UETP

•

Enabling job queues

•

Analyzing system failures

•

Installing image files with privileges

•

Copying to the system disk image files needed for DCL commands

The following sections describe procedures for performing these operations.

3.4.1

Preparing to Run the UETP
The User Environment Test Package (UETP) tests your hardware and software
to verify that your system has been properly installed. If you are running the
UETP on a small-disk system, such as a VAX-11/730, you should be aware
of the disk space limitations. Because of the space limitations, you need to
perform special procedures to prepare for a UETP run. You can run the UETP
in either of two ways on a small-disk system:
•

From the library disk (LIB$SYSROOT)

•

From the system disk, after copying the appropriate files

The methods of preparing a small-disk system for UETP testing are described
in the following sections.

3.4.1.1

Running the UETP from the Library Disk
Running the UETP from the library disk is the easier of the two methods and
leaves more space on your system disk; however, it allows the UETP to write
to your library disk. If you plan to run the UETP from LIB$SYSROOT, use
the following procedure:
1

2 Place the library disk in drive DQA1.
3 Invoke the tailoring procedure and mount the library disk as writeable
with the following command:
$ (DSYSIUPDATE:VMSTAILOR MOUNT/WRITE DQA1:

4 Start the UETP with the following command:
$ <9LIB$TEST: UETP

3-11

Customizing Small-Disk Systems

3.4.1.2

Running the UETP from the System Disk
As an alternative, you can run the UETP from the system disk. This method
of running the UETP allows you to reserve your library disk as read-only, but
it is more complicated and uses more space on your system disk.
If you plan to run the UETP from your system disk, you must first mount the
library disk with the tailoring command MOUNT, then copy the UETP file
group to your system disk. If you want to remove the library disk during a
run of the UETP, you must tailor additional files to the system disk before
you invoke the UETP.
1

2 Place the library disk in drive DQA1.
3 Invoke the tailoring procedure with the following command:
$ <DSYS$UPDATE: VMSTAILOR

4 Enter the following sequence of tailoring commands:
Tailor> MOUNT DQA1:
Tailor> COPY UETP

5 If you want to remove the library disk during the UETP run, enter the
additional tailoring commands:
Tailor>
Tailor>
Tailor>
Tailor>
Tailor>
Tailor>
Tailor>

COPY
COPY
COPY
COPY
COPY
COPY
EXIT

/FILE CONVERT
/FILE [SYSLIB]CONVSHR
/FILE CDU
/FILE DIFF
/FILE SEARCH
/FILE [SYSHLP]HELPLIB.HLP

6 End tailoring with the EXIT command:
Tailor> EXIT

See the Guide to VAX/VMS Software Installation for more information on
running the UETP.

3.4.2

Enabling Job Queues
Job queues are disabled by default. If you wish to create queues, use the
following commands to copy the QUEUES tailoring group to your system
disk:
Tailor> MOUNT ddcu:
Tailor> COPY QUEUE
Tailor> EXIT

Then shut down and reboot as described in Section 2.7.
Approximately 100 blocks are required to create the system queue file
(SYS$SYSTEM:JBCSYSQUE.EXE). See Section 9 for more information about
creating and managing queues.

3-12

Customizing Small-Disk Systems

3.4.3

Analyzing System Failures
The VAX/VMS operating system includes a capability for writing crash
dumps to your system disk when a serious hardware or software problem
occurs. Usually a dump file (SYS$SYSTEM:SYSDUMP.DMP) is required
equal in size to the number of pages of physical memory on your system
plus four blocks. However, in small-disk systems, crash dumps are written
instead to the system paging file (SYS$SYSTEM:PAGEFILE.SYS). Normally
the dumps are overwritten each time you boot your system. To preserve
crash dumps for analysis, you set the SYSGEN parameter SAVEDUMP to 1
and copy the dump to another disk. These operations are described in the
next sections.

3.4.3.1

Setting the SAVEDUMP Parameter
For small-disk systems, the SAVEDUMP parameter is off by default. If you
wish to preserve crash dumps on a routine basis, you set the parameter to 1.
Note, however, that if your system fails and the parameter is set to 0, you
may still preserve the dump by stopping in SYSBOOT when you reboot your
system and setting the SAVEDUMP parameter to 1. (See Section 4.2.3 for
instructions on booting and stopping in SYSBOOT.)
To set the SAVEDUMP parameter while running interactively, invoke
SYSGEN as follows:
$ RUN SYSISYSTEM:SYSGEN

Modify the SAVEDUMP parameter by typing the following commands at the
successive SYSGEN prompts:
SYSGEN>
SYSGEN>
SYSGEN>
SYSGEN>

USE CURRENT
SET SAVEDUMP 1
WRITE CURRENT
EXIT

Shut down and reboot as described in Section 2.7.

3.4.3.2

Saving the Dump for Analysis
Since a large portion of your paging file becomes unavailable when a dump
is saved, it is necessary to free this space as quickly as possible. Your system
may perform very slowly, or even fail again, when only a small amount of
paging file space is available. If less than 1000 blocks of paging file remain,
the SAVEDUMP parameter is ignored, and the dump is deleted immediately.
To ensure that dumps are automatically copied to another disk and that space
is reclaimed in the paging file, place the following commands in your sitespecific startup command procedure (SYS$MANAGER:SYSTARTUP.COM).
(These commands assume the presence of a data disk on device DQA1 with a
volume label USERDISK and a directory of [CRASH].)
MOUNT DQA1: USERDISK
ANALYZE /CRASH SYS$SYSTEM:PAGEFILE.SYS
COPY DQA1:[CRASH]SYSDUMP.DMP;1
EXIT

After the disk is mounted, the System Dump Analyzer (SDA) is invoked.
SDA then acts as follows to manage a crash dump:
1

Exits immediately when invoked from the startup command procedure if
one of the following is true:

The dump file contains no valid dump.

b The dump has been previously analyzed.
3-13

Customizing Small-Disk Systems

The dump is the result of an operator-requested shutdown.

2 Frees the paging file space for immediate use at the successful completion
of a COPY operation.

3 When the dump is copied to an already existing file, replaces that file
rather than creating a new one. By explicitly specifying a version number
of 1, each new crash dump replaces any older crash dump already saved
on the user disk.
If you cannot boot or successfully copy a crash dump, you may boot another
system disk, mount the system disk containing the dump as a data disk, and
then analyze the crash dump.

3.4.4

Installing Image Files with Privileges
The library files listed in Table 3-3 must be installed with privileges on
small-disk systems for proper operation.

Table 3-3

Files Requiring Installation with Privileges

File

File Group

AUTHORIZE.EXE

MANAGER

ANALIMDMP.EXE

DEVELOP

INIT.EXE

MANAGER

SHWCLSTR.EXE

MISCTOOLS

MAIL.EXE

MISCTOOLS

PHONE.EXE

MISCTOOLS

RTPAD.EXE

DECNET

CDU.EXE

MISCTOOLS

MONITOR.EXE

MISCTOOLS

SUBMIT.EXE

QUEUES

DBGSSISHR.EXE

DEVELOP

If you bootstrap your system with these files already tailored to your system
disk, they will be installed automatically. If you tailor them to your system
disk after bootstrapping, you can install them in one of two ways:
•

You may shut your system down, using SYS$SYSTEM:SHUTDOWN, and
reboot as described in Section 2.7.

•

You may invoke the DIGITAL image installation procedure with the
following command:
$ <BSYS$MANAGER:VMSIMAGES INSTALL VMSIMAGES

For further information about installed images, see Section 8.

3-14

Customizing Small-Disk Systems

3.4.5

Copying Images Needed for DCL Commands to the System Disk
Many DCL commands activate a related VAX/VMS image. For example, the
DCL command LIBRARY normally calls the image LIBRARIAN. In a smalldisk environment, you cannot invoke an image that is not already tailored to
your system environment. If you attempt to do so, you will receive one of
the following error messages:
'/.DCL-W-ACTIMAGE, error activating image 'name'
-CLI-E-IMAGEFNF, image file not found 'image name'

Before invoking the image, you must use the tailoring COPY command to
copy the appropriate image file or file group from the library disk to the
system disk.
Table 3-4 lists commands that invoke an image, the image activated, and
the file group in which it is present. The table also shows how command
qualifiers may change the image call.
Note: The relationship between DCL commands and invoked images shown in
the table is specific to Version 4.0 of the VAX/VMS operating system and
is provided only as a guide for tailoring your system disk. You should
avoid writing programs or procedures that depend on this relationship,
because it changes from release to release.
Table 3-4

DCL Commands, Activated Images, and File Groups

Command

Image

File Group

ACCOUNTING

ACC

MANAGER

ANALYZE

ANALYZOBJ

FILETOOLS

/CRASH _DUMP

SDA1

MISCTOOLS

/DISK_STRUCTURE

VERIFY

MANAGER

/ERROR_LOG

ERF

MISCTOOLS

/MEDIA

ANALYZBAD

MANAGER

/PROCESS-DUMP

ANALIMDMP

DEVELOP

/RMS—FILE

ANALYZRMS

FILETOOLS

/SYSTEM

SDA1

MISCTOOLS

APPEND

COPY

REQUIRED

ASSIGN

DCL

REQUIRED

/MERGE

QUEMAN

QUEUES

/QUEUE

QUEMAN

QUEUES

BACKUP

REQUIRED

CHECKSUM

MISCTOOLS

CONVERT

CONVERT, CONVSHR

FILETOOLS

RECLAIM, CONVSHR

FILETOOLS

COPY

REQUIRED

CREATE

REQUIRED

CREATEFDL, CONVSHR

FILETOOLS

DCL

REQUIRED

/RECLAIM

/FDL
DEASSIGN

1 SYS.STB required (LIBRARY file group).
3-15

Customizing Small-Disk Systems

Table 3-4 (Cont.)

DCL Commands, Activated Images, and File Groups

Command

Image

File Group

QUEMAN

QUEUES

DCL

REQUIRED

/CHARACTERISTIC

QUEMAN

QUEUES

/FORM

QUEMAN

QUEUES

/QUEUE
DEFINE

DELETE

REQUIRED

/CHARACTERISTIC

QUEMAN

QUEUES

/ENTRY

QUEMAN

QUEUES

/FORM

QUEMAN

QUEUES

/QUEUE

QUEMAN

QUEUES

DIFFERENCES

DIFF

TEXTTOOLS

DIRECTORY

REQUIRED

DISMOUNT

DISMOUNT, DISMNTSHR

REQUIRED

DUMP

FILETOOLS

EDIT

EDT

TEXTTOOLS

/ACL

ACLEDT

FILETOOLS, MANAGER

/FDL

EDF, FDLSHR

FILETOOLS

/SUM

SUMSLP, SUMSHR

TEXTTOOLS

/TECO

TECO

TEXTTOOLS

EXCHANGE

MANAGER

HELP

HELP2

REQUIRED

INITIALIZE

INIT

MANAGER

DELETE

/BASE_PRIORITY

QUEMAN

QUEUES

/BATCH

QUEMAN

QUEUES

/BLOCK_LIMIT

QUEMAN

QUEUES

/CHARACTERISTICS

QUEMAN

QUEUES

/CPUDEFAULT

QUEMAN

QUEUES

/CPUMAXIMUM

QUEMAN

QUEUES

/DEFAULT

QUEMAN

QUEUES

/DISABLE—SWAPPING

QUEMAN

QUEUES

/ENABLE—GENERIC

QUEMAN

QUEUES

/FORM

QUEMAN

QUEUES

/GENERIC

QUEMAN

QUEUES

/JOB-LIMIT

QUEMAN

QUEUES

/LIBRARY

QUEMAN

QUEUES

/ON

QUEMAN

QUEUES

/PROCESSOR

QUEMAN

QUEUES

/QUEUE

QUEMAN

QUEUES

/RETAIN

QUEMAN

QUEUES

2HELPLIB.LIB required (HELP file group).

3-16

Customizing Small-Disk Systems

Table 3-4 (Cont.)

DCL Commands, Activated Images, and File Groups
Image

File Group

/SEPARATE

QUEMAN

QUEUES

/START

QUEMAN

QUEUES

/TERMINAL

QUEMAN

QUEUES

/WINDOWS

QUEMAN

QUEUES

Command

/WSDEFAULT

QUEMAN

QUEUES

/WSEXTENT

QUEMAN

QUEUES

/WSQUOTA

QUEMAN

QUEUES

LIBRARY

LIBRARIAN

DEVELOP

LINK

LINK3

CRFSHR

MACRO

MACR0324, SUMSHR

DEVELOP

MAIL

MAIL, CONVSHR, EDTSHR

MISCTOOLS

MERGE

MISCTOOLS

MESSAGE

MISCTOOLS

MONITOR

MISCTOOLS

MOUNT

VMOUNT, MOUNTSHR

REQUIRED

PATCH

MISCTOOLS

PHONE

MISCTOOLS

SUBMIT

QUEUES

PURGE

DELETE

REQUIRED

RENAME

REQUIRED

REQUEST

REQUIRED

RUN

DCL

REQUIRED

/ACCOUNTING

RUNDET

REQUIRED

/AST_LIMIT

RUNDET

REQUIRED

/AUTHORIZE

RUNDET

REQUIRED

/BUFFER_LIMIT

RUNDET

REQUIRED

/DELAY

RUNDET

REQUIRED

/DETACHED

RUNDET

REQUIRED

/DUMP

RUNDET

REQUIRED

/ENQUEUE_LIMIT

RUNDET

REQUIRED

/ERROR

RUNDET

REQUIRED

/EXTENT

RUNDET

REQUIRED

/FILE—LIMIT

RUNDET

REQUIRED

/INPUT

RUNDET

REQUIRED

/INTERVAL

RUNDET

REQUIRED

/IO—BUFFERED

RUNDET

REQUIRED

3STARLET.OLB and IMAGELIB.OLB required (LIBRARY file group).
“SYS.STB required (LIBRARY file group).

3-17

Customizing Small-Disk Systems

Table 3-4 (Cont.)

DCL Commands, Activated Images, and File Groups

Command

Image

File Group

/IO_DIRECT

RUNDET

REQUIRED

/JOB_T ABLE_QUOT A

RUNDET

REQUIRED

/MAILBOX

RUNDET

REQUIRED

/MAXIMUM_WORKING_SET

RUNDET

REQUIRED

/OUTPUT

RUNDET

REQUIRED

/PAGE_FILE

RUNDET

REQUIRED

/PRIORITY

RUNDET

REQUIRED

/PRIVILEGES

RUNDET

REQUIRED

/PROCESS

RUNDET

REQUIRED

/QUEUE-LIMIT

RUNDET

REQUIRED

/RESOURCE_WAIT

RUNDET

REQUIRED

/SCHEDULE

RUNDET

REQUIRED

/SERVICE_FAILURE

RUNDET

REQUIRED

/SUBPROCESS—LIMIT

RUNDET

REQUIRED

/SWAPPING

RUNDET

REQUIRED

/UIC

RUNDET

REQUIRED

RUNOFF

TEXTTOOLS

RUNOFF
/CONTENTS

DSRTOC

TEXTTOOLS

/INDEX

DSRINDEX

TEXTTOOLS

SDL/NOPARSE

SDLNPARSE

DEVELOP

TEXTTOOLS

SET

REQUIRED

ACCOUNTING

SET

REQUIRED

ACL

SETSHOACL

FILETOOLS, MANAGER

/EDIT

ACLEDT

FILETOOLS, MANAGER

AUDIT

SET

REQUIRED

BROADCAST

SET

REQUIRED

CARD_READER

SET

REQUIRED

CLUSTER

SET

REQUIRED

COMMAND

CDU

MISCTOOLS

DAY

SET

REQUIRED

DEVICE

SET

REQUIRED

SETSHOACL

FILETOOLS, MANAGER

ACLEDT

FILETOOLS, MANAGER

SET

REQUIRED

/ACL
/EDIT
DIRECTORY
/ACL

SETSHOACL

FILETOOLS, MANAGER

/EDIT

ACLEDT

FILETOOLS, MANAGER

SET

REQUIRED

SETSHOACL

FILETOOLS, MANAGER

FILE
/ACL

3-18

Customizing Small-Disk Systems

Table 3-4 (Cont.)

DCL Commands, Activated Images r and File Groups
Image

File Group

ACLEDT

FILETOOLS, MANAGER

HOST

RTPAD

DECNET

LOGINS

SET

REQUIRED

MAGTAPE

SET

REQUIRED

MESSAGE

SETPO

REQUIRED

PASSWORD

SETPO

REQUIRED

PRINTER

SET

REQUIRED

PROCESS

SET

REQUIRED

PROTECTION

SET

REQUIRED

QUEUE

QUEMAN

QUEUES

REST ART_VALUE

QUEMAN

QUEUES

RMS_DEFAULT

SET

REQUIRED

TERMINAL

SET

REQUIRED

VOLUME

SET

REQUIRED

WORKING-SET

SET

REQUIRED

Command
/EDIT

SHOW

REQUIRED

ACCOUNTING

SHOW

REQUIRED

ACL

SETSHOACL

FILETOOLS, MANAGER

AUDIT

SHOW

REQUIRED

BROADCAST

SHOW

REQUIRED

CLUSTER

SHWCLSTR

MISCTOOLS

CPU

REQUIRED

DEVICES

SHOW

REQUIRED

ERROR

SHOW

REQUIRED

LOGICAL

SHOW

REQUIRED

MAGTAPE

SHOW

REQUIRED

MEMORY

SHOW

REQUIRED

NETWORK

SHOW

REQUIRED

PRINTER

SHOW

REQUIRED

PROCESS

SHOW

REQUIRED

QUEUE

QUEMAN

QUEUES

RMS_DEFAULT

SHOW

REQUIRED

SYSTEM

SHOW

REQUIRED

TERMINAL

SHOW

REQUIRED

USERS

SHOW

REQUIRED

WORKING-SET

SHOW

REQUIRED

SORT

SORTMERGE

MISCTOOLS

START

QUEMAN

QUEUES

REQUIRED

SHOW

/CPU

3-19

Customizing Small-Disk Systems

Table 3-4 (Cont.)

3.5

DCL Commands, Activated Images r and File Groups

Command

Image

STOP

File Group

DCL

REQUIRED

/ABORT

QUEMAN

QUEUES

/CPU

REQUIRED

/ENTRY

QUEMAN

QUEUES

/HOLD

QUEMAN

QUEUES

/MANAGER

QUEMAN

QUEUES

/NEXT

QUEMAN

QUEUES

/PRIORITY

QUEMAN

QUEUES

/QUEUE

QUEMAN

QUEUES

/REQUEUE

QUEMAN

QUEUES

/RESET

QUEMAN

QUEUES

SUBMIT

QUEUES

SYNCHRONIZE

QUEMAN

QUEUES

TYPE

REQUIRED

UNLOCK

FILETOOLS

Error and Informational Messages from the Tailoring Facility
This section lists the error and informational messages issued by the
Tailoring facility. Each message consists of an abbreviation followed by a
text message.
AMBIGRP, 'group name' is an ambiguous group name
Explanation: The group name as entered has too few characters to make it
unique.
User Action: Reenter the command with a unique group name.
AMBIGWRD, 'word' is an ambiguous word
Explanation: The abbreviated command or qualifier is ambiguous.
User Action: Reissue the command specifying a long enough spelling to
resolve the ambiguity.
BADCOMMA, invalid comma in command
Explanation: A comma has been detected preceding the first parameter in a
command.
User Action: Correct the command and reissue.
CTRLY, function aborted by CTRL/Y
Explanation: The function in progress has been interrupted by pressing the
CTRL and Y keys simultaneously.
User Action: None.

3-20

Customizing Small-Disk Systems

DEVICEREQ, device must be specified
Explanation: A device name was not specified with this command.
User Action: Reenter the command specifying a device name.
DISMOUNT, device dismounted
Explanation: The library disk has been dismounted.
User Action: None.
EXPNOTFND, expected file 'filename' not found
Explanation: A file with the specified name could not be found during an
open operation.
User Action: Examine the referenced directory to check for the existence of
the named file. Check the spelling of the file specification.
FILENAMEREQ, a file name must be specified
Explanation: A file name must be specified with this command.
User Action: Reissue the command, specifying a file name.
GROUPREQ, a group must be specified
Explanation: A group name must be specified with this command.
User Action: Reissue the command, specifying a group name.
F1ELPGROUPS, type DIR/GROUPS for a list of tailoring groups
Explanation: This is an informational message issued when an invalid group
name is used.
User Action: Use the DIRECTORY/GROUPS tailoring command to obtain a
list of valid group names.
HELPVERB, type HELP 'command'
Explanation: This is an information message issued when a command is
improperly used.
User Action: Use the HELP command to obtain more information.
HLPMOUNTWRT, type HELP MOUNT/WRITE
Explanation: Issued following a write-lock error.
User Action: Use the indicated HELP command to obtain more information
about mounting disks writeable.
LIBNOTMOUNT, the LIBRARY disk must be mounted
Explanation: A command has been issued that requires the library disk.
User Action: Mount the library disk and reissue the command.

3—21

Customizing Small-Disk Systems

LIBPROTECT, the LIBRARY disk must be writeable
Explanation: A write-lock error message has occurred on the library disk as
the result of a command directing the Tailoring facility to write to the library
disk.
User Action: Check that write protect is disabled, mount the library disk
writeable, and reissue the command.
NOBACKUP, no backup copy on device 'device'
Explanation: A request to delete a file has been ignored because the file has
no backup copy on the library disk (or on the system disk if the /LIBRARY
qualifier has been specified).
User Action: Check that the file exists on the backup disk, and that the file
name is properly spelled.
NOHELP, help not available
Explanation: Either the Help Utility or the Tailoring help library could not
be located on the system disk or, if it is mounted, on the library disk.
User Action: Mount the library disk and reissue the command. If the
library disk is already mounted, then this error indicates that files have
been improperly deleted from one or both disks.
NONZEROREF, open files on device, not dismounted
Explanation: The library disk cannot be dismounted because of open
channels to the device.
User Action: Investigate the list of files displayed, using the process ID field,
to determine what users or batch jobs have files open. Close the files and
reissue the DISMOUNT command.
NOQUAL, no qualifiers allowed on the 'command' command
Explanation: No qualifiers are allowed on the indicated command.
User Action: Check the typing of the command. Type HELP to obtain more
information about the syntax of the command.
NOSEARCH, SEARCH not available
Explanation: The SEARCH.EXE file could not be located on the system disk
or, if it is mounted, on the library disk.
User Action: Mount the library disk and reissue the command. If the library
disk is already mounted, this error indicates that files have been improperly
deleted from one or both disks.
NOSUCHDEV, no such device as 'device'
Explanation: The specified device does not exist.
User Action: Check the spelling of the device name. Use the DCL command
SHOW DEVICES to obtain a list of valid devices.

3-22

Customizing Small-Disk Systems

NOSUCHDIR, expected directory 'directory' not found
Explanation: The specified directory was not found.
User Action: Check the spelling of the file specification used in the
command. If correct, use the DCL command DIRECTORY to check if the
directory exists.
NOSUCHFILE, no files matching the specification 'filename' were found
Explanation: No files could be located that matched the indicated file
specification.
User Action: Check the spelling of the file name. Use the DCL DIRECTORY
command to look for the indicated files.
NOSUCHGROUP, group file 'group name' not found
Explanation: The specified group could not be found.
User Action: Check the spelling of the group name. Use the DIRECTORY
/GROUP tailoring command to obtain a list of groups.
NOTDELETED, 'filename' not deleted
Explanation: The indicated file name was not deleted. This is an
informational message that accompanies an error message explaining the
reason for the delete failure.
User Action: Investigate the associated error message.
NOWILDCARDS, wildcards not allowed in group names
Explanation: Wildcards (* and %) are not allowed in the specification of
group names.
User Action: Reissue the command with an explicit group name.
NO WRITE, device is not write enabled
Explanation: An attempt to mount the library disk /WRITE has failed.
User Action: Check that the disk is not write protected. Retry the command.
OPENIN, error opening 'filename' as input
Explanation: The indicated input file could not be opened.
User Action: Check that the file exists and that you have read access to it.
OPENOUT, error opening 'filename' as output
Explanation: The indicated output file could not be opened.
User Action: Check that the directory exists and that you have write access
to it.
REISSUE, correct the situation and reissue the command
Explanation: This informational message is issued in conjunction with other
error messages.
User Action: Address the problem described by the associated error message
and reissue the command.

3-23

Customizing Small-Disk Systems

REQNOTALLOWED, the REQUIRED file group cannot be deleted
Explanation: An attempt was made to delete the REQUIRED file group.
User Action: None. The REQUIRED file group is needed to boot the system
and cannot be deleted.
TOOMANYPARM, too many parameters
Explanation: More than the maximum number of parameters have been
given on a command line.
User Action: Check the spelling of the command. If correct, then break the
command into several simpler commands having fewer parameters.
UNRECCMC, 'command' is an unrecognized command
Explanation: The indicated command is not a valid command.
User Action: Use the HELP command to obtain a list of valid commands.
UNRECQUAL, 'qualifier' not valid for this command
Explanation: The specified qualifier is not valid for the command issued.
User Action: Check the spelling of the qualifier and the command. Use
the HELP command to obtain the proper spellings. Note that the Tailoring
facility checks the entire spelling of keywords, unlike DCL, which checks only
the first four characters.
USEEXIT, type EXIT to exit
Explanation: An attempt to terminate tailoring is invalid.
User Action: Use the EXIT command to exit.
USEHELP, type HELP for more information
Explanation: This informational message is issued in association with various
error messages.
User Action: Use the HELP command to obtain more information about
the command you are using. For example, if an error occurs on a COPY
command, then type HELP COPY.

3—24

Shutdown and Startup

During the course of system operation, you will need to shut down and
restart your system to perform various maintenance functions. For example,
you may need to modify system parameters or make certain hardware
modifications. Also, if the system fails and does not automatically restart, you
will need to bootstrap the system manually to restart it. DIGITAL provides
several procedures for shutting down and restarting the system. This chapter
describes these procedures.

4.1

Shutting Down the Operating System
You can perform three types of shutdown operations:
1

An orderly shutdown with SYS$SYSTEM:SHUTDOWN.COM. This
procedure shuts down the system while performing housekeeping
functions such as disabling future logins, stopping the batch and printer
queues, dismounting mounted volumes, and stopping user processes.
SHUTDOWN.COM is described in Section 4.1.1.
SHUTDOWN.COM optionally invokes a site-specific command procedure
named SYS$MANAGER:SYSHUTDWN.COM, which you tailor to the
needs of your installation. The SYSHUTDWN.COM file is present in the
VAX/VMS distribution kit but contains no commands.

4.1.1

An emergency shutdown with OPCCRASH. If you cannot shut down
the system with SHUTDOWN.COM, you run the OPCCRASH emergency
shutdown program. OPCCRASH is described in Section 4.1.2.

An emergency shutdown with CRASH. You use this procedure for an
emergency shutdown of the system if OPCCRASH fails. On all VAX
processors except the VAX-11/750, the procedure is supplied on the
system console medium as a console command program named CRASH.
Sections 4.1.3, 4.1.4, and 4.1.5 describe the CRASH procedures for specific
VAX processors.

Orderly Shutdown with SHUTDOWN.COM
This section describes the use of SHUTDOWN.COM to shut down the system
in an orderly fashion. Do not modify SHUTDOWN.COM; instead, you
can add commands to the SYS$MANAGER:SYSHUTDWN.COM command
procedure to perform site-specific housekeeping functions.
To execute SHUTDOWN.COM, you must have either the SETPRV privilege
or all the following privileges: CMKRNL, EXQUOTA, OPER, SYSNAM,
SYSPRV, TMPMBX, and WORLD. If you have the SETPRV privilege, the
procedure will automatically assign you the required privileges.
To perform an orderly shutdown of the system, invoke SHUTDOWN.COM
from any terminal and any account with the following DCL command:
$ ®SYS$SYSTEM:SHUTDOWN

4-1

Shutdown and Startup

The procedure then prompts with a series of questions and messages. These
are shown below, along with directions for appropriate responses.
How many minutes until final shutdown [0]?

Enter an integer. If the system logical name SHUTDOWN$MINIMUM_
MINUTES is defined, its integer value is the minimum value that you can
enter. Therefore, if the logical name is defined as 10, you must specify at
least 10 minutes to final shutdown or an error message is returned. If you do
not enter a value, the logical name value is used. If the logical name is not
defined, and you do not enter a value, 0 minutes is the default.
Reason for shutdown:

Enter a one-line reason for shutting down the system. The default response is
"standalone".
Do you want to spin down the disk volumes [No]?

Enter YES or NO (Y or N). Note, however, that the system disk cannot be
spun down.
Do you want to invoke the site-specific shutdown procedure [Yes]?

Enter YES or NO. This refers to SYS$MANAGER:SYSHUTDWN.COM.
Should an automatic system boot be performed [No]?

By default, the system does not automatically reboot. However, if you
respond with YES, when the shutdown is complete, an attempt is made to
reboot the system automatically. Note that the system can be automatically
rebooted only if the appropriate hardware switch is also set on the processor,
and if the default bootstrap command file is properly set. See Section 2.4 for
a description of how to set the default bootstrap command file.
When will the system be rebooted [later]?

Enter a time in the format you want printed in the message that will be
broadcast to users. For example, you could specify IMMEDIATELY, or IN 10
MINUTES, or a time such as 2 P.M. or 14:00. If you do not know when the
system will be available again, press RETURN to specify "later" as the time
when the system will reboot.
Shutdown options (enter as a comma-separated list):
REM0VE.N0DE
Remaining nodes in the cluster should adjust quorum
CLUSTER.SHUTDOWN
Entire cluster is shutting down
REBOOT.CHECK
Check existence of basic system files
Shutdown options [NONE]

The procedure prompts you to specify one or more shutdown options. If
your system is a VAXcluster member, all three options are listed. (For more
information on cluster shutdown options, see the Guide to VAXclusters.)
Otherwise, only the REBOOT_CHECK option is listed. Enter
REBOOT_CHECK if you wish to verify that a subset of the files necessary to
reboot the system after shutdown is present. (If you are certain that the files
exist, press RETURN.)
If you select the REBOOT_CHECK option, the procedure will check for the
necessary files and notify you if any are missing. (Note, however, that this
check is not exhaustive.) You should replace missing files before proceeding.
If all files are present, this success message appears:
'/.SHUTDOWN -1-CHECK0K, Basic reboot consistency check completed.

4-2

Shutdown and Startup

The following events occur as the shutdown procedure continues, and the
corresponding messages are printed on the terminal:
1

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

The system logical name SHUTDOWN$TIME is defined as the absolute
time of shutdown. For example, if the value 10 is specified at 12:00 in
response to the first question, the logical name is assigned the absolute
time value 12:10 along with the date. By requesting the logical name
definition for SHUTDOWN$TIME (with the SHOW LOGICAL command),
you can see if a shutdown is in progress or determine the actual time of
shutdown. This feature is useful if a user for some reason missed the
shutdown broadcast message.

At six minutes or less until system shutdown, the terminal from
which shutdown was invoked is made an operator's console, all future
nonoperator logins are disabled, and if the DECnet network is running, it
is shut down.

When there is one minute left until system shutdown, batch and device
queues and the system job queue manager are stopped.

At zero minutes, the site-specific command procedure
SYS$MANAGER:SYSHUTDWN.COM is invoked.

All user processes are stopped; however, system processes continue.
ACPs may delete themselves when their mounted volumes are finally
dismounted.

For dual-processor systems, the secondary processor is stopped.

All installed images are removed.

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

10 The operator's log file is closed.
11 The program SYS$SYSTEM:OPCCRASH is invoked to shut down the
system.
12 If you did not request an automatic reboot, the following message appears
on the system console:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

If you requested an automatic reboot, the system reboots, provided the
necessary controls are set.
1 3 If you are not automatically rebooting, you must halt the system after the
above message is printed at the console terminal.
Example 4-1 demonstrates an orderly system shutdown on standalone node
AVALON.

4-3

How many minutes until final shutdown [0]: 10
Reason for shutdown: [Standalone] MONTHLY PREVENTIVE MAINTENANCE.
Do you want to spin down the disk volumes [No]? 1 RET|
_
Do you want to invoke the site-specific shutdown procedure [Yes]? I RE
Should an automatic system boot be performed [No]? 1 RET|
When will the system be rebooted [later]? 12:30
Shutdown options:
REBOOT.CHECK
Check existence of basic system files
Shutdown options [NONE] I RET1

SHUTDOWN message on AVALON, from user SYSTEM at _AVALON$OPAO:
12:00
AVALON will shut down in 10 minutes; back up 12:30. Please log off no
MONTHLY PREVENTIVE MAINTENANCE

'/.SHUTDOWN-1-OPERATOR, This terminal is now an operator's console.
xxxxxxxxxxx opcom , ie-jun-lose 12:01:00. i5 rammn
Operator status for operator _AVAL0N$0PA0:
CENTRAL, PRINTER, TAPES, DISKS, DEVICES, CARDS. NETWORK, 0PER1. 0PER2
0PER3, 0PER4, 0PER5, 0PER6, 0PER7, 0PER8, 0PER9, 0PER10, 0PER11,
0PER12
'/.SHUTDOWN-1-DISLOGINS, Interactive logins will now be disabled.
y.SET-I-INTSET, login interactive limit = 0 current interactive value
'/.SHUTDOWN-1-SHUTNET, The DECnet network will now be shut down.
'/.SHUTDOWN-1-STOPQUEMAN, The queue manager will now be stopped.

SHUTDOWN message on AVALON, from user SYSTEM at _AVALON$OPAO:
12:05
AVALON will shut down in 5 minutes; back up 12:30. Please log off nod
MONTHLY PREVENTIVE MAINTENANCE
17 terminals have been notified on AVALON.

SHUTDOWN message on AVALON from user SYSTEM at _AVAL0N$0PA0:
12:06:
AVALON will shut down in 4 minutes; back up 12:30. Please log off nod
MONTHLY PREVENTIVE MAINTENANCE

mmmxx

OPCOM. 16-JUN-1986 12:07:12.30 XXXXXXXXXXX
Message from user DECnet on AVALON
DECnet event 2.0, local node state change
From node 2.161 (AVALON). 16-JUN-1986 12:07:22.26
Operator command. Old state = On, New state = Shut

SHUTDOWN message on AVALON from user SYSTEM at _AVALON$OPAO:
12:07
AVALON will shut down in 3 minutes; back up 12:30. Please log off nod
MONTHLY PREVENTIVE MAINTENANCE

7.SHUTD0WN-1-STOPQUEMAN, The queue manager will now be stopped.
SHUTDOWN message on AVALON user SYSTEM at _AVAL0N$0PA0:
12:08:12.56
AVALON will shut down in 2 minutes; back up 12:30. Please log off nod
MONTHLY PREVENTIVE MAINTENANCE

XXXXXXXXXXX

OPCOM, 16-JUN-1986 12:08:12:30 XXXXXXXXXXX
Message from user JOB.CONTROL on AVALON
-SYSTEM-S-NORMAL, normal successful completion

XXXXXXXXXXX OPCOM. 16-JUN-1986 12:08:42.30
Message from user DECNET on AVALON
DECnet shutting down

XXXXXXXXXXX

SHUTDOWN message on AVALON from user SYSTEM at _AVAL0N$0PA0:
12:09
AVALON will shut down in 1 minute; back up 12:30. Please log off node
MONTHLY PREVENTIVE MAINTENANCE

(Continued

Shutdown and Startup

Example 4-1

(Cont.)

Orderly System Shutdown with
SHUTDOWN.COM

17 terminals have been notified on AVALON
'/.SHUTDOWN-1-SITESHUT, The site-specific shutdown procedure will now be invoked.
7.SHUTD0WN -1 - STOPUSER, All user processes will now be stopped.
'/.SHUTDOWN-1-REMOVE, All installed images will now be removed.
'/.SHUTDOWN-1-DISMOUNT, All volumes will now be dismounted.
y.'/.'/.'/.y.y.'/.y.y.y.y. opcom, ig-jun-ioso 12:09:42.30
Message from user System on AVALON
_AVALON$OPAO:, AVALON shutdown was requested by the operator.

uunxnn

y.y.y.y.y.*/.y.y.y.y.y.

opcom. i6-jun-i986 12:10:02.44 y.'/.y.y.y.y.y.y.y.y.y.
Logfile was closed by operator _AVALON$OPAO:
Logfile was SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;8

nmnnn

•/.y.y.y.y.y.y.y.y.'/.y.

opcom, i6-jun-i986 12:10:32.20
Operator _AVALON$OPAO: has been disabled, username SYSTEM
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

4.1.2

Emergency Shutdown with OPCCRASH
This section describes how to halt the system immediately without performing
any of the housekeeping functions that ensure an orderly shutdown.
Generally, you should shut down the system by following the orderly
shutdown procedure described in Section 4.1.1, because since OPCCRASH
performs only minimal housekeeping functions, data may be lost.
To perform this procedure, you must have the CMKRNL privilege. You can
enter the commands from any terminal and any account.
1

Enter the following command to force an immediate shutdown of the
system:
$ RUN SYSISYSTEM:OPCCRASH

If the system fails to respond after a few minutes, use the alternate
crash procedure appropriate for your VAX processor, as described in
Sections 4.1.3 and 4.1.5.

At the system console, observe the following message:
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM

Now halt the system. You halt a VAX-11/730, 11/750, or Micro VAX
system by pressing CTRL/P. To halt a VAX-11/780 system or other VAX
processor, press CTRL/P to obtain the console prompt (> > > ), and
then type HALT.

Example 4-2 illustrates an emergency shutdown on a VAX-11/780 using the
OPCCRASH procedure.
Example 4-2

Emergency Shutdown on a VAX-11/780 Using
OPCCRASH

$ RUN SYS$SYSTEM:OPCCRASH
SYSTEM SHUTDOWN COMPLETE - USE CONSOLE TO HALT SYSTEM
| CTRL/P 1
>»HALT
HALTED AT 8000708A

4-5

Shutdown and Startup

4.1.3

Emergency Shutdown with CRASH on VAX—11/730, VAX—11/780
Systems
This section describes the CRASH console program command procedure that
forces a VAX-11/780 or VAX-11/730 system to fail, resulting in immediate
shutdown. Procedures for performing the equivalent operation on
VAX-11/750 and VAX 8600 systems are described in the following sections.
Note: You should use CRASH only if the system will not accept command
input; that is, if the system fails to accept or respond to OPCCRASH.
You must issue all commands that invoke CRASH from the system console
terminal.
To force a VAX-11/780 or a VAX-11/730, system to fail with CRASH,
proceed as follows:
1

Halt the system. You halt a VAX-11/730 system by pressing CTRL/P. To
halt all other VAX processors, press CTRL/P to obtain the console prompt
(> > > ), and then type HALT.

At the console prompt, type
»> (DCRASH

This command invokes the CRASH console program command file.
3

Additional messages and information, such as the fatal bugcheck message,
are printed at the console terminal. A dump of memory is written to the
system dump file on disk.

Example 4-3 illustrates the procedure for a VAX-11/780 system.

4-6

»>HALT
»><BCRASH
! Command file to crash VMS abnormally
j
HALT

! HALT SYSTEM, EXAMINE PC,

HALTED AT 8000702A
EXAMINE PSL
! PSL,
00000000
EXAMINE/INTERN/NEXT:4 0 ! And all stack pointers
00000000
00000001
00000002
00000003
00000004
DEPOSIT PC=-1
DEPOSIT PSL=1F0000

80001D48
00000000
00000000
00000000
8009E600
! Invalidate PC
! Kernel mode, IPL 31

CONTINUE

«DE0F>
«8EXIT>
**** FATAL BUG CHECK, VERSION =4.4 INVEXCEPTN, Exception wh
ASTDEL or on interrupt stack
CURRENT PROCESS = NULL
REGISTER DUMP
RO = 000000IF
R1 = 001F0000
R2 = 00000000
R3 = 00000000
R4 = 00000000
R5 s 00000000
R6 = 00000000
R7 = 00000000
R8 = 00000000
R9 = 00000000
R10= 00000000
00000000
Rll
AP = 00000000
FP = 00000000
SP = 80001D14
PC = 800038C1
PSL= 001F0009
KERNEL/INTERRUPT STACK
80001D1C
80001D20
80001D24
80001D28

00000004
00000000
FFFFFFFD
00000000

HALT INST EXECUTED
HALTED AT 800071B3
»>

Typing @CRASH invokes the CRASH console program
the VAX-11/780 system. This procedure instructs the sy
program counter (PC), the processor status longword (PS
pointers. Values are deposited in the PC and PSL to cau
condition that forces a system dump. The fatal bugcheck
at the console terminal. Finally, the system halts and pr
the program counter. The console system prompt (> >

Shutdown and Startup

If automatic rebooting is enabled, some systems will automatically reboot,
instead of halt. However, if it is not enabled, you must bootstrap the system
manually.
On VAX-11/782 attached processor systems, there may be a delay of up to
two minutes before the system responds to the @CRASH command.

4.1.4

Emergency Shutdown with CRASH on VAX 8600, VAX 8650
Systems
The CRASH procedure described in the previous section differs slightly
for the VAX 8600 series systems. Example 4-4 illustrates the emergency
shutdown CRASH procedure for a VAX 8600 or VAX 8650 system.
Example 4-4

Running CRASH on a VAX 8600 or VAX 8650
System

1 CTRL/P 1
»>
»>
»>
»>

0CRASH
SET QUIET OFF
SET ABORT OFF
HALT

CPU stopped. INVOKED BY CONSOLE (CSM code 11)
PC 80008B1F
»> UNJAM
»> E PSL
U PSL 00000000
»> E/I/N: 4 0
I 00 80000C40
I 01 00000000
I 02 00000000
I 03 00000000
I 04 00000000
»> E SP
G 0E 80000C40
»> E/VIR/NEXT: 40 <0
P 04206840 00000000
P 04206844 00000000

»>
»>
»>
»>

P 0420693C 00000000
P 04206940 00000000
D PC FFFFFFFF
D PSL 1F0000
SET ABORT ON
SET QUIET ON

**** FATAL BUG CHECK. VERSION = X4.4 INVEXCEPTN,
Exception while above ASTDEL or on interrupt stack
CURRENT PROCESS NULL
REGISTER DUMP

4-8

Shutdown and Startup

4.1.5

Emergency Shutdown with CRASH on VAX—11 /750 Systems
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 shown in Example 4-5.
Example 4-5

Running CRASH on a VAX-11/750 System

| CTRL/P 1
80007B06 02
»>E/G F
G
0000000F
80007B06
»>E P
00000000
»>E/I 0
I
00000000
800009D0
»>E/I 1
I
00000001
00000000
»>E/I 2
I
00000002
00000000
>»E/I 3
I
00000003
00000000
»>E/I 4
I
00000004
8013C000
>»D/G F FFFFFFFF
»>D P 1F0000
»»C
**** FATAL BUG CHECK. VERSION =4.4 INVEXCEPTN. Exception while
above ASTDEL or on interrrupt stack
CURRENT PROCESS = NULL
REGISTER DUMP

HALT INST EXECUTED
HALTED AT 800076B2
»>

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 bugcheck message is printed at the console terminal, as are
additional messages and information. (See Example 4-3 for the
VAX-11/780.) 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. Finally, the system halts and prints the contents of the program
counter. The console system prompt (> > > ) returns.

4.2

Bootstrapping the System
You can bootstrap the system using either a default or an alternate bootstrap
command procedure. In both cases, you must bootstrap the system directly
from the system disk. If you are bootstrapping a VAX-11/750, you can
use the standalone BOOT58 program on the console TU58 cartridge. This
procedure is described in Appendix A.

4-9

Shutdown and Startup

Normally you bootstrap using the procedure you have selected as the
default for your site (see Section 2.4). However, if the default procedure
is unavailable, or if you are bootstrapping to create an environment for a
specialized task (such as standalone debugging), you can select an alternate
procedure. The next sections describe default and alternate bootstrap
operations.
Note: In the following sections the bootstrap file type CMD is used. On the
VAX 8600 series processors the file type is COM.

4.2.1

Default Bootstrap
The most direct way to bootstrap your operating system is to activate the
BOOT switch or to enter console mode and type the BOOT command (or
simply B). For example:
»> B

In either case, the console program looks for your default bootstrap command
procedure (DEFBOO.CMD) and executes it.
To bootstrap using the default, proceed as follows:

4.2.2

Halt the system. You halt a VAX-11/730 system by pressing CTRL/P. To
halt all other VAX processors, press CTRL/P to obtain the console prompt
(> > > ), and then type HALT.

Either type BOOT or activate the BOOT switch on the processor control
panel. On most VAX processors, the default bootstrap command
procedure DEFBOO.CMD is used to bootstrap the system. For
VAX-11/750 systems, the processor will attempt to bootstrap from the
device selected by the BOOT DEVICE switch on the front panel. If
the switch is set to position A, the BOOT58 program is invoked (see
Appendix A.)

Alternate Nonstop Bootstrap
You normally use an alternate nonstop bootstrap command procedure when
the default procedure cannot be accessed because of problems with the
device designated in the default procedure. To bootstrap the system using an
alternate nonstop procedure, follow these steps:
1

Halt the processor. You halt a VAX-11/730 system by pressing CTRL/P.
To halt all other VAX processors, press CTRL/P to obtain the console
prompt (> > > ), and then type HALT.

Bootstrap the system, using the command for your particular processor:
•

For the VAX-11/750
»> B ddcu

The code dd is the device type, c is the controller designator, and u is
the unit number.
•

For all other VAX processors
»> B

4-10

ddu

Shutdown and Startup

The code dd is the device type, and u is the unit number. Refer to
the specific processor installation guide for more information on the
specific conversational bootstrap procedure.

4.2.3

Alternate Conversational Bootstrap
A conversational bootstrap is most commonly used in research and
development environments to alter operating conditions for experimentation,
testing, and debugging. This procedure allows the sophisticated user to
•

Select an alternate file as the source of system parameter values

•

Set and show individual parameter values

•

Specify an alternate site-independent startup procedure

•

Specify a minimum startup

To initiate a conversational bootstrap, proceed as follows:
1

Halt the processor. You halt a VAX-11/730 system by pressing CTRL/P.
To halt all other VAX processors, press CTRL/P to obtain the console
prompt (> > > ), and then type the HALT command.

Bootstrap the system, using the command for your particular processor:
•

For the VAX-11/750
»> B/l ddcu

The code dd is the device type, c is the controller designator, and u is
the unit number.
•

For all other VAX processors
»> (SdduGEN

The code dd is the device type, and u is the unit number.
3

When SYSBOOT is ready to accept commands, it prompts as follows:
7.7.
SYSBOOT>

On VAX-11/750 systems, the two percent signs that appear above the
SYSBOOT> prompt indicate a successful verification of the microcode. If
the percent signs do not appear, discontinue the bootstrap operation and
contact your field service representative.
When SYSBOOT prompts, you may use any of the subset of SYSGEN
commands listed in Table 4-1 to examine or modify the system. You can
find more information about these commands in the VAX/VMS System
Generation Utility Reference Manual.

Shutdown and Startup

Table 4-1

SYSGEN Commands Used in SYSBOOT

Command

Description

CONTINUE

Resumes the bootstrap procedure

DISABLE CHECKS

Inhibits checking of parameter values
specified with the SET command

ENABLE CHECKS

Permits checking of parameter values
specified with the SET command

HELP

Displays a summary of the SYSBOOT
commands at your terminal

SET parameter-name

Establishes the value of a system generation
parameter

SET/STARTUP

Sets the name of the system startup
command procedure

SHOW [parameter]

Displays active, current, default, maximum,
and minimum values for specific parameters;
displays, with appropriate qualifiers,
characteristics of parameters grouped by
categories

USE [file-spec]

Optionally specifies a parameter file to be
used as a source of values (you must enter
the entire file specification, including device
and directory)

During a typical conversational bootstrap, you might enter the following
commands to set a new value for the SYSGEN parameter WSMAX and
continue the procedure:
SYSB00T> SET WSMAX 512
SYSBOOT> CONTINUE

In this example, you set WSMAX to 512, and the bootstrap operation
continues. When the VAX/VMS system announces itself, the new parameter
value becomes active.
You can also use the conversational bootstrap operation to specify a minimum
startup. For example, if you want to bootstrap your system and avoid
autoconfiguring all your devices, issue the following command at the
SYSBOOT> prompt:
SYSBOOT> SET STARTUP.Pl "MIN"

This command initiates a minimum startup that performs the following
sequence of operations:
1

Starts the processes that control error logging, the job controller, and the
operator's log

Installs known images

Defines the number of interactive users as eight

Logs off

Note that this minimum procedure does not invoke SYCONFIG.COM or
SYSTARTUP.COM. Therefore, it does not autoconfigure the rest of your
system's peripherals.

4-12

Shutdown and Startup

If you want verification set during the execution of a startup procedure, you
can specify the following command:
SYSB00T> SET STARTUP_P2 "YES"

The STARTUP—Pn parameters are not reset for the next bootstrap operation.

4.2.4

Bootstrapping an HSC Disk
The manner in which you bootstrap an HSC disk is in part dependent
on the type of VAX processor you are using. If you have a VAX-11/750,
you use the BOOT58 utility to bootstrap HSC disks (see Appendix A); for
other processors, use console mode commands. See the processor-specific
installation guides for more information.
In either case, you must alter an appropriate bootstrap command file on your
console volume: CIBOO.CMD if you want to use a nonstop boot, or CIGEN.
if you want to use a conversational boot. If you are installing a new system,
that is, not upgrading your current system, you must use CIBOO.CMD.
The Cl bootstrap command procedures let you bootstrap from an HSC
disk, but first you must add two pieces of information to the file: the unit
number of the disk drive, and the node number of the HSC controlling
it. Furthermore, if you want to bootstrap from a system root other than
[SYSO], you must identify the root. Note, however, that when installing a
system, you bootstrap from [SYSO]. See Section 2.8.2.2 for more information
on bootstrapping from alternate system roots; see the Guide to VAX/VMS
Software Installation for details on creating alternate roots.
There are two ways to provide the information needed by the Cl bootstrap
command procedures, depending on whether you have a running system or
whether you are installing a new system.
If you have a running system, you can copy the Cl bootstrap command file
from the console volume to a disk directory, edit it, and then copy the edited
version back to the console volume. If you want to use the Cl bootstrap
command file as your default bootstrap command procedure, copy the edited
version to DEFBOO.CMD on the console volume.
If you are installing a new system, you will have to use console commands
(BOOT58 commands if you have a VAX-11/750) to deposit the information
needed by the Cl bootstrap command files before bootstrapping your HSC
device. Note that the form of the DEPOSIT command varies for different
VAX processors.
The following sections describe the bootstrapping of HSC disks in four
enviroments:
•

On a VAX-11/780 (and similar processors) during an installation

•

On a running VAX-11/780 (and similar processors)

•

On a VAX-11/750 during an installation

•

On a running VAX-11/750

4-13

Shutdown and Startup

4.2.4.1

Bootstrapping an HSC Disk on a VAX—11/780 During an Installation
The following procedure assumes that you are bootstrapping an HSC disk on
a VAX-11/780 while you are installing a new operating system.
1

Determine the unit number of the HSC disk and the node number of the
HSC controlling it.

Press CTRL/P to put the system in console mode.

Use the console HALT command to stop the processor.

When the console prompt (> > > ) appears, deposit the HSC node
number into register R2 using the following command format:
»> DEPOSIT R2 node_number

Note that all numeric entries are made using hexadecimal notation. For
example, if the HSC is node number 12 on the CI780, you use this
command:
»> DEPOSIT R2 OC

If the disk device is accessible to two HSCs, deposit both node numbers
putting the greater number in hexadecimal digits 3 and 2, and the lesser in
digits 1 and 0. For example, if one HSC is numbered 14 (hex OE) and the
other is numbered 10 (hex 0A), the proper command is
»> DEPOSIT R2 OEOA

Deposit the unit number of the HSC disk into register R3 using the
following command format:
»> DEPOSIT R3 unit_number

For example, if the HSC disk is unit number 21, deposit a hex 15 into R3:
»> DEPOSIT R3 15

Bootstrap the HSC disk with this command:
»> (8CIB00.CMD

(See Appendix A for more information on the BOOT58 program.)
4.2.4.2

Bootstrapping an HSC Disk on a Running VAX-11/780
The following procedure shows how to set up DEFBOO.CMD to do a nonstop
system bootstrap of an HSC disk on a VAX-11/780 system that is up and
running. For purposes of illustration, the HSC device is assumed to be an
RA60 disk drive assigned unit number 03 on an HSC controller assigned node
number 0C. The procedure assumes that you want to bootstrap the system
from alternate root SYS A.
1

Be sure your console drive is connected. If it is not, invoke the System
Generation Utility (SYSGEN) to connect it, as follows:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT CONSOLE

Exit from SYSGEN:
SYSGEN> EXIT

Mount the console volume:
$ MOUNT/FOREIGN CSA1:

4-14

Shutdown and Startup

Copy CIBOO.CMD to your default disk directory with this command:
$ EXCHANGE COPY CSA1:CIBOO.CMD *.*

Edit the disk file in your default directory as shown in the following
example. The first line you add deposits the HSC node number in R2, and
the second line you add deposits the HSC disk's unit number in R3.
To set the system root at [SYSA], you edit the line commented as
DESIGNATED ROOT IS SYSA by changing the most significant digit
in R5 to the letter A. This digit determines the system root for system
disks with multiple systems.
Note that all numeric entries are made using hexadecimal notation.

DEPOSIT
DEPOSIT
DEPOSIT
DEPOSIT
DEPOSIT
DEPOSIT

RO
R1
R2
R3
R4
R5

20
F3E000
OC
03
0
A0004000

!CI PORT DEVICE
!Cl TR=E
!HSC NODE NUMBER
!DEVICE UNIT NUMBER
IBOOT BLOCK LBN (NOT USED)
!DESIGNATED ROOT IS SYSA

6 If the disk is dual-ported (accessible to two HSC controllers), you must
specify the node number of both controllers in register R2. Further, you
must specify the higher-numbered node in bits < 15:8> and the lowernumbered node in bits <7:0>. For example, if the disk is accessible to
the HSC numbered OC and the HSC numbered OA, the line for R2 should
appear like this:
DEPOSIT R2 OCOA

!DUAL-PORTED HSC NODE NUMBERS

Copy the edited bootstrap command file to the default bootstrap command
procedure (DEFBOO.CMD) on your console volume with this command:
$ EXCHANGE COPY CIBOO.CMD CSA1:DEFBOO.CMD

You should provide a spare copy of this file in case DEFBOO.CMD is
overwritten. Use the same command, but provide a distinctive file name
for the spare file.
8

Shut down the system with this command:
$ @SYS$SYSTEM:SHUTDOWN

Press CTRL/P to put the system into console mode.

10 Use the HALT command to stop the processor.
11 Bootstrap the HSC disk by invoking the default bootstrap command
procedure:
»> B

4-15

Shutdown and Startup

4.2.4.3

Bootstrapping an HSC Disk on a VAX—11/750 During Installation
The following procedure shows how to bootstrap an HSC disk on a
VAX-11/750 while installing a new operating system.
1

At the processor control panel, set the BOOT SELECT switch to
position A.

Determine the unit number of the HSC disk and the node number of the
HSC controlling it.

Press CTRL/P to put the system in console mode.

When the console prompt (> > > ) appears, invoke BOOT58 with this
command:
»> B/800 DDAO

Note: If you fail to add the /800 qualifier, the console program will try to
execute DEFBOO.CMD.
5

When the BOOT58> prompt appears, deposit the HSC node number into
register R2 using the following command format:
B00T58> D/G 2 node_number

Note that all numeric entries are made using hexadecimal notation. For
example, if the HSC is node number 12 on the CI750, you use this
command:
B00T58> D/G 2 OC

If the load device is accessible to two HSCs, deposit both node numbers,
putting the greater number in hexadecimal digits 3 and 2, and the lesser in
digits 1 and 0. For example, if one HSC is numbered 14 (hex OE) and the
other is numbered 10 (hex 0A), the proper command is
B00T58> D/G 2 0E0A

Deposit the unit number of the load device into register R3 using the
following command format:
B00T58> D/G 3 unit_number

For example, if the load device is unit number 21, deposit hex 15 into R3:
B00T58> D/G 3 15

Bootstrap the HSC disk with this command:
B00T58> (8CIB00.CMD

4.2.4.4

Bootstrapping an HSC Disk on a Running VAX-11/750
This section describes how to set up DEFBOO.CMD to do a nonstop system
bootstrap of an HSC disk on a VAX-11/750 system that is up and running.
For purposes of illustration, the HSC device is assumed to be an RA60 disk
drive assigned unit number 03 on an HSC controller assigned node number
12 (hexadecimal 0C). It is further assumed that the user wants to bootstrap
the system from alternate root SYSA.
1

Set the BOOT SELECT switch to position A.

Be sure your console drive is connected. If it is not, invoke the System
Generation Utility (SYSGEN) to connect it, as follows:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN> CONNECT CONSOLE

4-16

Shutdown and Startup

Exit from SYSGEN:
SYSGEN> EXIT

Mount the console volume:
$ MOUNT/FOREIGN CSA1:

Use the Exchange Utility (EXCHANGE) to copy CIBOO.CMD to your
default disk directory.
$ EXCHANGE COPY CSAliCIB00.CMD *.*

6 Edit the disk file in your default directory and add the two lines
commented as "HSC NODE NUMBER" and "DEVICE UNIT NUMBER".
The first line deposits the HSC node number in register R2, and the
second line deposits the HSC disk's unit number in register R3.
To set the system root at SYSA, you edit the line commented as
SOFTWARE BOOT CONTROL FLAGS by changing the most significant
digit in register R5 to the letter A. This digit determines the system root
for system disks with multiple systems.
Note that all numeric entries are made using hexadecimal notation.

D/G
D/G
D/G
D/G
D/G
D/G

0
1
2
3
4
5

20
F3E000
OC
03

0
A0004000

If the disk is dual-ported (accessible to two HSC controllers), you must
specify the node numbers of both controllers in register R2. Further, you
must specify the higher-numbered node in bits < 15:8> and the lowernumbered node in bits <7:0>. For example, if the disk is accessible
to the HSC numbered 12 (hexadecimal OC) and the HSC numbered 10
(hexadecimal 0A), the line for register R2 should appear like this:
D/G R2 OCOA

!Cl PORT DEVICE
!Cl TR=E
!HSC NODE NUMBER
!DEVICE UNIT NUMBER
!BOOT BLOCK LBN (NOT USED)
•SOFTWARE BOOT CONTROL FLAGS

!DUAL-PORTED HSC NODE NUMBERS

Copy the edited boot command to the default boot command procedure
(DEFBOO.CMD) on your console volume.
$ EXCHANGE COPY CIBOO.CMD CSA1:DEFB00.CMD

You should provide another copy of this file in case DEFBOO.CMD is
overwritten. Use the same command, but provide a distinctive file name
for the other file.
9

Write the boot block on the TU58 cartridge using the Writeboot Utility,
a

Invoke WRITEBOOT:
$ RUN SYS$SYSTEM:WRITEBOOT

When WRITEBOOT asks for the target device, make the following
entry:
Target system device (and boot file if not VMB.EXE):? CSAi:B00T58.EXE

In response to the following question, enter the number 1:
Enter VBN of boot file code (default is one): 1

4-17

Shutdown and Startup

When you are asked for the address of the primary bootstrap, enter
C000:
Enter load address of primary bootstrap in HEX (default is 200):

C000

I 0 Shut down the system:
$ <0SYS$SYSTEM: SHUTDOWN

II Press CTRL/P to put the system in console mode:
12 When the console prompt appears (> > > ), bootstrap the HSC disk:
»> B

4.2.5

Bootstrapping a VAX—11 /780 with Interleaved Memory
To bootstrap a VAX-11/780 system with interleaved memory, you must
verify that the system conforms to certain requirements, as described in the
VAX Hardware Handbook. If your system meets these requirements, edit
the default bootstrap command procedure (DEFBOO.CMD) and the powerfail
restart command procedure (RESTAR.CMD) to include commands that modify
the memory controller registers.
DEFBOO.CMD and RESTAR.CMD are on the console floppy diskette. Copy
the files from the console floppy diskette, edit them, and return them to
the floppy diskette using the DXCOPY command procedure described in
Section 2.5.

4.3

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.

4.3.1

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

4-18

Consult the appropriate hardware manual for your VAX processor.

Contact the appropriate DIGITAL Field Service representative.

Shutdown and Startup

4.3.2

Software Problems
When the operating system is loaded into memory but the STARTUP.COM
command procedure does not execute, a software malfunction has probably
occurred. You should suspect this condition if the usual message specifying
the number of interactive users does not appear.
You can perform one or both of the following actions to correct the situation:
•

Try again, by repeating the bootstrap procedure to restart (see the software
installation booklet for your VAX processor).

•

Leave the system disk in the original drive. Place a backup copy in
another drive, swap unit plugs in the two drives, and try again.

4-19

Managing System Users

Effective system management depends to a large degree on effective user
management. The control of system functions on a user-by-user basis plays a
vital role in managing system resources and thus enhancing system efficiency
and security.
In order to manage users effectively, you must understand
•

Who needs access to the system

•

What tasks they must perform

•

What system resources they will require

•

What information you should provide them

Once you understand user needs, you can establish controls that will tailor
the system appropriately. VAX/VMS provides several tools to authorize
and control the use of system resources by individual users. This chapter
describes these tools and discusses how and when to use them.

5.1

User Authorization File
You manage VAX/VMS users primarily by creating and maintaining user
accounts, which control who may log in to the system and how individuals
may use it.
User accounts are defined by records in a file (SYS$SYSTEM:SYSUAF.DAT)
called the user authorization file (UAF), which you maintain using the
Authorize Utility (AUTHORIZE). A detailed explanation of how to use
AUTHORIZE is presented in the VAX/VMS Authorize Utility Reference Manual.
Whenever a user logs in, the system uses the information contained in the
UAF to validate the login attempt, establish the account's environment, and
create a process with appropriate attributes. In this way, the system restricts
users to the resources you assign to each account.
The procedures for adding a user account are discussed in detail later in
this chapter. Since, however, the UAF is the prime repository for storing
information about user accounts, it is important to understand its components
before you add accounts.
Using the Authorize Utility, you create and maintain UAF records by
assigning values to various fields within each record. The values you assign
identify the user, define the user's work environment, and control use of
system resources. Example 5-1 presents a typical UAF record for a restricted
user account and describes its fields. To gain access to a specific user record,
you set your default to the SYS$SYSTEM directory, and issue the command
SHOW user-name.

5-1

Managing System Users

Example 5-1

Sample UAF Record Display

Owner:
ROB WELCH
Username: WELCH
UIC:
[21,51] ([INV,WELCH])
Account:
Tables: DCLTABLES
©
CLI:
DCL
Default:
USER3:[WELCH]
LGICMD:
Login Flags:
Diswelcome Disnewmail
Primary days:
Mon Tue Wed Thu Fri
Sat Sun
Secondary days:
Primary
000000000011111111112222 Secondary 000000000011111111112222
Day Hours 012345678901234567890123 Day Hours 012345678901234567890123
- Full access Network:
- No access -XXXXXXXXXBatch:
XXXXXXXXX-XXXXXXX
-XXXXXXXXXLocal:
XXXXXXXXX-XXXXXXX
-No accessDialup:
—
Full access -No accessFull access Remote:
—
Pwdminimum:
6
Login Fails:
0
(none)
Expiration:
Pwdchange:
15-APR-1984 13:58
Pwdlifetime:
(none)
(none) (interactive),
(none) (non-interactive)
Last Login:
8192
20 Bytlm:
Maxjobs:
0 Fillm:
Maxacctjobs:
0
0 Shrfillm:
0 Pbytlm:
1024
Maxdetach:
18 JTquota:
0 BlOlm:
Prclm:
2 DIOlm:
18 WSdef:
150
24 WSquo:
200
Prio:
4 ASTlm:
500
4 TQElm:
10 WSextent:
Queprio:
Enqlm:
30 Pgflquo:
10000
(none)
CPU:
Authorized Privileges:
TMPMBX NETMBX
Default Privileges:
TMPMBX NETMBX

O User identification fields contain information used by the system for both
accounting purposes and user identification.
© Default fields contain the default specifications for
•

The command language interpreter (DCL by default)

•

The name of the command procedure to be executed automatically at
login time. If the field is blank, SYS$LOGIN:LOGIN.COM is executed
by default.

•

The command language interpreter tables (if blank, same as CLI)

•

The device and directory names for file access

Inhibit certain login functions

•

Control the days of the week when various types of logins are
permitted

•

Control the times of day when various types of logins are permitted

Limiting the use of reusable system resources

•

Specifying the base priority used in scheduling the process that the
system creates for the user

5-2

Managing System Users

5.1.1

System-Supplied UAF Records
The software distribution kit provided with a new VAX/VMS system contains
a UAF of four records:
•

DEFAULT—Serves as a template for creating user records in the UAF.
A new user record is assigned the values of the DEFAULT record except
where you explicitly override those values. Thus, whenever you add a
new account, you need only specify values for fields that you want to be
different. For example, the following AUTHORIZE command creates a
new record having the same values as the DEFAULT record, except that
the password, UIC, and default directory fields are changed.
UAF> ADD MARCONI/PASSW0RD=QLP6YT9A/UIC=[033,004]
_UAF> /DIRECTORY=[MARCONI]

Section 5.3 gives an example of how to use AUTHORIZE to add a user
account.
You can also use AUTHORIZE to modify the DEFAULT record to suit
your needs or to create additional default record templates for specific
account types. Section 5.5.1 explains how to create and use additional
default templates.
Note: The default record cannot be renamed or deleted from the UAF.

5.1.2

•

FIELD—Permits DIGITAL Field Service personnel to check out a new
system. The FIELD record can be disabled once the system is installed.

•

SYSTEM—Provides a means for you to log in with full privilege. The
SYSTEM record can be modified but cannot be renamed or deleted
from the UAF. Note that if you change the SYSTEM record, particularly
the default device and directory and the privileges, you could prevent
successful installation of optional software products or future VAX/VMS
maintenance releases.

•

SYSTEST—Provides an appropriate environment for running the User
Environment Test Package (UETP). The SYSTEST record can be disabled
once the system is installed.

General Maintenance of the UAF
Typically, you use the UAF supplied with the distribution kit. (You can,
however, rename the UAF with the DCL command RENAME, and then
create a new UAF with AUTHORIZE.) You should limit any kind of access to
this file to the SYSTEM account (see the Guide to VAX/VMS System Security
for guidelines on protecting system files). Furthermore, each time you modify
the file, you should create a backup copy so that in case of a system failure
you do not lose the modifications. See the VAX/VMS Backup Utility Reference
Manual for guidelines on backing up files.
The UAF is accessed as a shared file, and updates to the UAF are made on
a per-record basis, which eliminates the need for both a temporary UAF
and a new version of the UAF after each AUTHORIZE session. Updates
become effective as soon as AUTHORIZE commands are entered, not after
the termination of AUTHORIZE. (For this reason, you should not enter
temporary values with the intent of fixing them later in the session.)

5-3

Managing System Users

Immediately after installing the system, you should make the following
modifications to the UAF:
•

SYSTEM, FIELD, and SYSTEST accounts—Change the passwords
immediately. Use obscure passwords of six characters or more and
continue to change them on a regular basis. You should not permit
general users access to these accounts.
In addition to changing the password, you can specify
MODIFY/FLAGS=DISUSER with AUTHORIZE, especially if you use the
account infrequently. The login flag DISUSER disables the account and
prevents anyone from logging in on the account. To enable the account
when it is needed, run AUTHORIZE and specify
MODIFY/FLAGS=NODISUSER.

Warning: Be careful not to disable all of your privileged system accounts. If you
inadvertently do so, you can recover by setting the UAF ALTERNATE
SYSGEN parameter during an interactive bootstrap operation. See
Section 5.7 for information on alternate login procedures.
As a general rule, do not make any other changes in the SYSTEM UAF
record; installation of VAX/VMS maintenance releases and optional
software products depends on certain values in this record.
•

DEFAULT account—You may want to change several fields in this
account. For example:
UAF> MODIFY DEFAULT/DEVICE=DISK$USER/WSQU0=750

The default device is set to the name most commonly used for user
accounts that will be added. Likewise the working set value is set to a
value appropriate for most users on the system.
Note that you use the SYSTEM account only for system functions such as
performing backups and installing maintenance updates. The account comes
to you with full privileges, so you must exercise caution in using it. For
example, because you have BYPASS privilege, the system will allow you to
delete any file no matter what its protection. If you type an incorrect name
or spurious asterisk, you may destroy files that you or other users need to
keep. For this reason, you should use another account with fewer privileges
for day-to-day system management activities.
If you want to receive mail on the SYSTEM account, you can define a
systemwide logical name in the site-specific startup command procedure
(see Section 2) to equate SYSTEM to the user name of the system manager's
account. You can also use the MAIL command SET FORWARD to have any
SYSTEM mail forwarded to any other account.

5.2

Preparing to Add a User Account
Set the default to the SYS$SYSTEM directory to invoke the Authorize Utility.
How you set up a user account depends on the needs of the individual user.
In general, there are two types of accounts:
•

5-4

Interactive—A person using an interactive account has access to the
system software and can perform work of a general nature (program
development, text editing, and so on). Normally, such an account is
considered individual; that is, only one person can use it.

Managing System Users

•

Turnkey—A person using a turnkey or captive account has access only
to user software and can only perform strictly limited work. Normally,
such an account is considered functional; that is, anyone who needs to
perform the particular work can use it. As an example, you might develop
an inventory system. Anyone whose job entails inventory control can
access your system, but that person cannot access other systems or the
base software.

The suggested procedures for preparing to add a user account are as follows:
1

Determine a user name and password.

2 Determine a user identification code (UIC).
3 Decide where the account's files will reside (which device and directory)
4 Use the Disk Quota Utility (DISKQUOTA) to add a disk quota entry for
this UIC, if disk quotas are in effect.

5 Create a first-level directory on the appropriate volume.
6

Establish any login/logout command files.

When you have completed these steps, you can invoke the Authorize Utility
as described in Section 5.3 and add the account.
The sections that follow discuss each step in the creation of a user account
and introduce the various management utilities and commands used. Detailed
descriptions of the utilities and commands appear in the individual VAX/VMS
utility reference manuals and in the VAX/VMS DCL Dictionary.

5.2.1

User Name and Password
To determine a user name and password, use naming conventions that take
into consideration the nature of the account. For example, interactive accounts
are usually named after the person using the account. Turnkey accounts, on
the other hand, use a name that describes the function of the account. Thus,
an interactive account for Robert Jones would typically have a user name of
JONES, while a turnkey account for an inventory system would typically be
called INVENTORY. On systems with a large number of users, you should
remember to assign user names that are unique.
For interactive accounts, it is best to let the person using the account control
the password. Initially, you provide a simple password and tell the user to
change the password with the DCL command SET PASSWORD. Only the
person using the account need know the password. You should encourage all
users to set obscure passwords of at least six characters and to change them
frequently.
To provide additional protection to a user account, a secondary password can
be added. The initial setting of the secondary password is controlled by the
system manager using the Authorize Utility. See the VAX/VMS Authorize
Utility Reference Manual for information on adding and modifying secondary
passwords.
For turnkey accounts, the degree of sensitivity of the data used by the account
should determine the type of password. For example, the password for a
payroll application should be obscure, while the password for a suggestions
account might not even be required; it could be null (in which case users
would not be prompted for the password).

5-5

Managing System Users

You should prohibit users from changing the passwords of turnkey accounts,
To do this, specify /FLAGS=LOCKPWD when you add the account with
the Authorize Utility. Change the password whenever you feel it might be
compromised (for example, if a person using the account moves to another
job). You change a user's password by issuing the command
MODIFY/user-name/PASSWORD.

5.2.2 User Identification Code
See the VAX/VMS DCL Concepts Manual for a detailed discussion of the UIC.
In general, you assign each account a unique UIC, and you should assign
accounts the same group number if they perform similar work, access the
same files frequently, and/or use many of the same logical names.

5.2.3 Disk Quota Entry
If disk quotas are in effect for the volume, run the Disk Quota Utility
(DISKQUOTA) to add an entry for the new UIC. Disk quotas limit the
amount of disk space available to individual users on a particular volume.
To add a disk quota entry, run DISKQUOTA as follows:
$ RUN SYStSYSTEM:DISKQUOTA
DISKQ> USE DISKIUSER
DISKQ> ADD [014,006] /PERMQU0TA=2OOO/0VERDRAFT=5OO
DISKQ> EXIT

The commands in this example
•

Invoke DISKQUOTA

•

Specify the disk DISK$USER as the volume on which quotas are set

•

Add a disk quota entry of 2000 blocks for UIC [014,006] and assign the
entry an overdraft of 500 blocks

•

Exit from the utility

The sum of the quota and overdraft values is the absolute maximum number
of blocks allotted to the user, which in this example is 2500 blocks. A
discussion of disk quotas is presented in Section 7.8.2.1. The Disk Quota
Utility is described in detail in the VAX/VMS Disk Quota Utility Reference
Manual.

5.2.4 User Directory and Default File Specification
For each interactive account, you should create a first-level directory (using
the DCL command CREATE/DIRECTORY) under which the interactive user
can create and maintain files and subdirectories. Make the owner of the
directory the UIC you have decided upon for the new account. Typically, you
also use the name of the account for the first-level directory. For example, if
you have decided upon an account name of JONES and a UIC of [014,006],
you would issue the following DCL command to create a first-level directory
for the account on the volume DISK$USER:
$ CREATE/DIRECTORY DISK$USER:[JONES]/0WNER_UIC=[014,006]

The volume on which the directory is established depends on which devices
you reserve for interactive accounts and how much space is available on each.

5-6

Managing System Users

The default file specification you provide the new account (when you run
AUTHORIZE) should be the name of the device and the name of the firstlevel directory you used in the DCL command CREATE/DIRECTORY.
For a turnkey account, whether you create a first-level directory depends
on the nature of the user system. Where the user system uses files
in a particular directory, you should make that directory the default
directory specification. For example, if the inventory system uses the files
DISK$DATA:[INV]STOCKl.DAT and DISK$DATA:[INV]STOCK2.DAT, the
default device specification should be DISK$DATA: and the default directory
specification should be [INV].

5.2.5

Login Command Procedures for Interactive Accounts
For interactive accounts, login command procedures contain commands
commonly executed at the beginning of every user session. These commands
do such things as
•

Define symbols

•

Assign logical names

•

Display messages and the time of day

•

Set terminal characteristics

•

Define keys to perform certain functions

Login command procedures are useful for both saving keystrokes and
standardizing operations. In establishing login command procedures for
interactive accounts, you have the following choices:
•

System—As system manager, you normally create and maintain a
standard login command procedure in the system directory (the file is
typically named SYS$MANAGER:SYLOGIN.COM). You then equate the
logical name SYS$SYLOGIN to the name of the file so that whenever a
user logs in, the procedure is executed.

•

Individual—For any or all accounts, you may specify an additional
login command procedure with the /LGICMD qualifier of AUTHORIZE.
You can give the login command file any valid file specification. Then,
whenever the user logs in, the specified procedure is executed after
SYS$SYLOGIN.

•

User-specified command file—If individual or system login command
procedures are not implemented, the system looks for a command file
called LOGIN in the user's login directory (as defined by the SYS$LOGIN
logical name). If the file is found, the system executes it. This command
file is developed and maintained by the user and should follow these
conventions:
— Device and directory names must take the default file specification for
the account.
— The file name must be LOGIN.
As an aid to new users, you might copy a login command procedure
template into newly created first-level directories. However, to ensure
proper ownership of the file, you must change the owner UIC of the file
to that of the user. You make this change with the DCL command SET
FILE/OWNER _UIC.

5-7

Managing System Users

Examples 5-2 and 5-3 illustrate typical system and user-specified login
command procedures.

Example 5-2

Sample SYS$MANAGER:SYLOGIN.COM Login
Command Procedure

$ V = F$VERIFY(0)
ISTART:
$ !
$ SET N0C0NTR0L=Y
! Do not allow CTRL/Y to exit procedure
$ SET NOON
$ •
$ !
Set default file protection back to the old default
$ !
$ SET PROTECTIONSSY:RWED.OW:RWED,GR:RWED,WO:RE)/DEFAULT

$ !
$
$
$
$
$
$
$
$
$

!
Allow network jobs to start faster
!
IF F$M0DE() .EQS. "NETWORK" THEN GOTO EXIT
!
!
Enable CTRL/T handling by DCL
•
SET C0NTR0L=T
!
!
Define Foreign Commands For Installed Utilities

$ !
==
SDA
"ANALYZE/CRASH.DUMP"
==
USERS
"SHOW USERS"
==
DISPLAY
"MONITOR PROCESSES/TOPCPU1
==
NCP
»$NCP"
==
INFO
"SHOW PROCESS/CONTINUOUS"
==
SUSPEND
"SET PROCESS/SUSPEND"
==
RESUME
"SET PROCESS/RESUME"
==
SETNAME
"SET PROCESS/NAME"
!
!
Define a symbol indicating whether the terminal
!
is on a dialup port
!
TT == F$GETDVI("TT","DEVNAM")
DIALUP == ((TT .GES. "TTGO:" .AND. TT .LES. "TTG4:") .OR. (TT .GES. "TTH1:" .AND. TT .LES. "TTH4:") .OR. (TT .EQS. "TTI5:"))
$ IF DIALUP THEN SET TERMINAL/INQUIRE
$ !
$EXIT:
$ IF V THEN SET VERIFY

$
$
$
$
$
$
$
$
$
$
$
$
$
$

$ SET C0NTR0L=Y
$ EXIT

As Example 5-2 shows, you can disable the CTRL/Y function (which
suspends execution of the current image and invokes the command
interpreter) to force execution of the complete login command procedure
whenever the user logs in. You can do this with the DCL command SET
NOCONTROL=Y. The login command procedure should, at some point, reset
the CTRL/Y function with the DCL command SET CONTROL=Y.

Managing System Users

Example 5-3
$
$
$
$
$
$
$
$
$
$

Sample LOGIN.COM Login Command Procedure

SET NOON
SET PROTECT10N=(S=RD,0=RWED,G=R,W=R)/DEFAULT
!
! Define abbreviations for often used commands
!
DIRECTORY
==
DIRECTORY/DATE/SIZE
PH*ONE
==
PHONE/SCROLL
>
!
! Other useful abbreviations

$ !
$
$
$
$
$
$
$
$
$
$
$
*
*
$
*
♦
$
$
$
$
$

SHP
PRI*NT
SHD
UP
SP
sq
H*OME
SUB*MIT
SPC
SYS
DAY

==
ss

==
==
ss

==
==
==
ss

==
==

"SHOW PROCESS/PRIVILEGES"
"PRINT/NOTIFY"
"SHOW DEFAULT"
"SET DEFAULT [-]"
"SET PROCESS/PRIVILEGES="
"SHOW QUEUE/BATCH/ALL/DEVICE"
"SET DEFAULT SYSlLOGIN"
"SUBMIT/NOTIFY"
"SHOW PROCESS/CONTINUOUS"
"SHOW SYSTEM"
"SHOW TIME"

! Set /LOG for all commands
1
:
-=
BACK*UP
"BACKUP/LOG"
==
DEL*ETE
"DELETE/LOG"
ss
LIB*RARY
"LIBRARY/LOG"
==
PUR*GE
"PURGE/LOG"
ss
REN*AME
"RENAME/LOG"

$ ! End of LOGIN(.COM processing
* i
$ GOTO 'F$MODE()
$NETWORK:
$ EXIT
$INTERACTIVE:
==
$ VN
"SET TERMINAL/WIDTH=80"
==
$ VW
"SET TERMINAL/WIDTH=132"
ss
$ EXPERT
"SET MESSAGE/NOFACIL/NOSEVER/NOIDENT"
$ NOVICE
==
"SET MESSAGE/FACILITY/SEVERITY/IDENTIF'
$ NOVICE
$ !
$ ! Symbols for network users
±
♦ i
$ SYSA
$ SYSB
$ SYSC
$ EXIT
$BATCH:
$ SET VERIFY
$ EXIT

==
==
==

"SET HOST SYSA"
"SET HOST SYSB"
"SET HOST SYSC"
! End of interactive login
! End of batch login

5-9

Managing System Users

5.2.6

Login Command Procedures for Turnkey Accounts
For turnkey accounts, the login command procedure specified by the
/LGICMD qualifier of AUTHORIZE directs the account user into an
application program and logs the user out upon termination of the task.
The login command procedure for the inventory system, for example, might
consist of the following commands:
$ DEFINE SYS$DISK DISK$INVENT
$ RUN INVENTORY
$ LOGOUT

The application program INVENTORY assumes control transparently to
the person logging into the account. You should assign the CAPTIVE
flag to the login flags field of the turnkey account record by specifying
the AUTHORIZE qualifier /FLAGSCAPTIVE. The CAPTIVE flag locks the
user of the turnkey account into the application software. Section 5.3 shows
how to use AUTHORIZE to create a UAF record for a turnkey account.

5.2.7

Logout Command Procedures
The system does not provide for automatic execution of a command procedure
at logout time. However, you can supply one as follows:
1

Create a systemwide logout command procedure that executes
whenever a user logs out (the file is typically named
SYS$MANAGER:SYLOGOUT.COM).

To ensure that this command procedure always executes, include a
command in SYS$MANAGER:SYLOGIN.COM that equates the most
commonly used abbreviation of the LOGOUT command (often LO) to the
execution of the logout command procedure. For example:
$ LO*GOUT: ==<8SYS$MANAGER: SYLOGOUT

The last line of the logout command procedure then uses an alternate form
of the LOGOUT command, such as a LOGOUTNOW command. (You can
create any command name you like beginning with LO.) You cannot use
the same abbreviation as used for the symbol (in this case LO) because it
will start the procedure again. As an alternative, you could make the next
to the last line of the procedure:
$ DELETE/SYMBOL/GLOBAL LOGOUT

5.3

Using AUTHORIZE to Add a User Account
Once you have analyzed the purpose of a user account and decided which
attributes and resources it requires, you can use the Authorize Utility to
create it.
Give yourself the SYSPRV privilege. Then issue the following commands to
set your default device and directory to that of SYS$SYSTEM and invoke the
utility:
$ SET DEFAULT SYS$SYSTEM
$ RUN AUTHORIZE
UAF>

5—10

Managing System Users

When the utility responds with the UAF> prompt, you can add a typical
interactive account as follows:
UAF>
_UAF>
_UAF>
_UAF>

ADD J0NES/PASSW0RD=LPB57WM/UIC=[014,006]
/DEVICE=DISK$USER/DIRECTORY=[JONES] /LGICMD=DISK$USER:[NEWPROD]GRPLOGIN /0WNER="R0BERT JONESn/ACCOUNT=NEWPROD

The /OWNER and /ACCOUNT specifications are primarily for accounting
purposes and can be omitted. The following unspecified qualifiers typically
take their default values from the DEFAULT record:
•

Limits and Quotas (/ASTLM, /BIOLM, /CPUTIME, /DIOLM, /ENQLM,
/FILLM, /JTQUOTA, /MAXACCTJOBS, /MAXDETACH, /MAXJOBS,
/PGFLQUOTA, /PRCLM, /SHRFILLM, /TQELM, /WSDEFAULT,
/WSEXTENT, /WSQUOTA)—These qualifiers impose limits on the use
of reusable system resources. See Section 6 for a discussion of limits and
quotas; the defaults are normally adequate.

•

Priority (/PRIORITY, /QUEPRIORITY)—The default values are normally
adequate for accounts not running real-time processes. See Section 6 for a
discussion of the processor priorities.

•

Privileges (/DEFPRIVILEGES, /PRIVILEGES)—See Section 6 for a
discussion of privileges; the default privileges (TMPMBX, NETMBX) are
normally adequate.

•

Primary and Secondary Login Times; Login Functions (/ACCESS,
/DIALUP, /FLAGS, /INTERACTIVE, /LOCAL, /PRIMEDAYS,
/REMOTE)—By default, users are allowed to log in at any hour of
any day. To override the setting of a particular day, you can use the DCL
command SET DAY. Use this command if a holiday occurs on a day that
would normally be treated as a primary day and you want it treated as a
secondary day. See Section 5.5.5 for a discussion of using these fields to
restrict login times and functions.

•

Command Language Interpreter (DCL)—Specify MCR if running in RSX
compatibility mode.

The following example shows an AUTHORIZE command that adds the record
for a turnkey account:
UAF> ADD INVENT0RY/PASSW0RD=QRC7Y94A/UIC=[033,066] _UAF> /DEVICE=DISK$INVENT/DIRECTORY=[INV]/LGICMD=INVENTORY _UAF> /FLAGS=CAPTIVE/NOACCESS=(PRIMARY. 18-8, SECONDARY, 0-23)

In this example, the /FLAGS and /NOACCESS qualifiers are used to restrict
users from logging in to the turnkey account. The /NOACCESS qualifier
limits logins to specific hours (see Section 5.5.5). The /FLAGS=CAPTIVE
qualifier adds the login flag CAPTIVE to the turnkey account record. The
CAPTIVE flag locks the person using the account into the application
software by
•

Disabling the CTRL/Y function to prevent users from interrupting the
execution of the command procedure and gaining access to the command
interpreter

•

Preventing the user from specifying an alternate command interpreter with
the /CLI qualifier at login time

•

Preventing the user from specifying an alternate default disk device with
the /DISK qualifier at login time

5-11

Managing System Users

You may also want to disable mail and welcome notices with the
/FLAGS=(DISNEWMAIL,DISWELCOME) qualifier.

5.4

Using a Command Procedure to Add a User Account
For consistent results, you can incorporate the steps for adding a user account
(interactive or turnkey) into a command procedure similar to that shown in
Example 5-4.

5-12

;

ADDUSER.COM -- Adds a new user to the system authoriza

USERDISK = "WRKD$:"
! Default disk for new
UAF = "$AUTH0RIZE"
ON C0NTR0LY THEN GOTO CLEANUP
ON WARNING THEN GOTO CLEANUP
OLDDIR = F$ENVIR0NMENT("DEFAULT")
PREVPRIV = F$SETPRV("SYSPRV")
IF .NOT. F$PRIVILEGE("SYSPRV") THEN GOTO NOPRIV
SET DEFAULT SYS$SYSTEM
i

Request account information

INQUIRE USERNAME "Username"
INQUIRE FULLNAME "Full name"
SET TERMINAL/NOECHO
INQUIRE PASSWORD "Password ["Username■]"
SET TERMINAL/ECHO
IF PASSWORD .EQS. "" THEN PASSWORD = USERNAME

GET.GRP:
INQUIRE GRP "UIC Group Number"
IF GRP .EQS. "" THEN GRP =
WRITE SYSSOUTPUT ""
WRITE SYS$OUTPUT "Determine the UIC from the following lis
WRITE SYSIOUTPUT ""
UAF SHOW ['GRP',*]/BRIEF
INQUIRE UIC
IF UIC .EQS. "" THEN GOTO GET.GRP
IF F$L0CATE("[",UIC) .EQ. F$LENGTH(UIC) .AND. F$L0CATE("<",UIC) .EQ. F$LENGTH(UIC) THEN UIC = "[" +
INQUIRE ACCOUNT "Account Name [VMS]"
IF ACCOUNT .EQS. "" THEN ACCOUNT = "VMS"
INQUIRE PRIVS "Privileges [NONE]"
IF PRIVS .NES. "" THEN PRIVS * "/PRIV=(" + PRIVS + ")"
USERDIR = FSEXTRACT(0,9,USERNAME)
INQUIRE TMP "Login Directory ["USERDIR']"
IF TMP .NES. "" THEN USERDIR = TMP
INQUIRE TMP "Login Device ["USERDISK']"
IF TMP .NES. "" THEN USERDISK = TMP
DQUOTA = 0
IF F$SEARCH(" "USERDISK'[0,0]QU0TA.SYS")
DQUOTA = 1

.EQS.

"" THEN GOT

Request disk quota entry information

INQUIRE QUOTA "Disk Quota

[1000]"

IF QUOTA .EQS. "" THEN QUOTA = 1000
INQUIRE OVERDRAFT "Overdraft Quota [100]"
IF OVERDRAFT .EQS. "" THEN OVERDRAFT = 100
OPEN/WRITE FILE SYS$LOGIN:ADDQUOTA.TMP
WRITE FILE "RUN SYS$SYSTEM:DISKQUOTA"

(Co

Managing System Users

Example 5-4

(Cont.)

Command Procedure for Adding a User

* !
$ !Add quota entry
$ !
$ WRITE FILE "USE "USERDISK"'
$ WRITE FILE "ADD ",UIC,"/PERMQUOTA=",QUOTA,"/OVERDRAFT®",OVERDRAFT
$ CLOSE FILE
$ <BSYS$LOGIN: ADDQUOTA. TMP
$ DELETE SYSlLOGIN:ADDQUOTA.TMP;*/N0L0G
$NQO:
$ !
$ !
Create a first-level directory for the account
$ !
$CREATE/DIRECTORY/0WNER_UIC='UIC'/PROTECTION®(S=RWE,0=RWE,G=RE,W)•USERDISK'['USERDIR']/LOG
$ IF F$SEARCH("SYS$MANAGER:LGISAMPL.COM") .EQS. "" THEN GOTO ADDACC
$ !
$ !
Copy the LOGIN.COM template to user account
$ •
$ COPY SYS$MANAGER:LGISAMPL.COM 'USERDISK'['USERDIR']LOGIN.COM
$ SET FILE/OWNER_UIC='UIC' 'USERDISK'['USERDIR']LOGIN.COM;
!Change the UIC
$

$ !
Add the account record to the UAF
$ !
$ADDACC:
$ OPEN/WRITE FILE SYS$L0GIN:ADDUAF.TMP
$ WRITE FILE "RUN SYS$SYSTEM:AUTHORIZE"
$ WRITE FILE "ADD ".USERNAME,"/OWNER®""».FULLNAME,"""/ACCOUNT®".ACCOUNT,"/DEVICE®''USERDISK'/DIRECTORY®[''USERDIR']/UIC®",UIC.PRIVS,"/PASSWORD®".PASSWORD
$ CLOSE FILE
$ «SYS$L0GIN:ADDUAF.TMP
$ DELETE SYS$L0GIN:ADDUAF.TMP;*/N0L0G
$ !
$ !
Restore prior working environment
$ !
SCLEANUP:
$ SET TERMINAL/ECHO
$ PREVPRIV = F$SETPRV(PREVPRIV)
$ SET DEFAULT 'OLDDIR'
$ EXIT

$ !
$ !
In case proper privileges are not set
$ !
$N0PRIV:
$ WRITE SYSIOUTPUT "You need SETPRV or SYSPRV privilege to run this procedure"
$ GOTO CLEANUP

5.5

Maintaining the User Environment
As the work requirements of your system change, you may need to
•

Create additional default records to serve as templates for new categories
of users

•

Delete or disable the accounts of users who leave your site

•

Impose login restrictions to limit system use by certain accounts

With the Authorize Utility, you can perform these maintenance operations by
modifying or deleting records in the UAF.

5-14

Managing System Users

As part of the job of maintaining the user environment, you may also want
to periodically check the disk structure for lost files or files in need of repair.
To perform these operations, you use the Verify Utility, as described in
Section 5.5.4.

5.5.1

Creating Additional Default Record Templates
On systems where all users perform the same type of work, you typically use
the system-supplied default record, DEFAULT, as the template for adding
new user records. You may find, however, that your system supports several
different user categories, each category performing a specific type of work
and requiring unique record attributes. Instead of always using the systemsupplied default record as a template and making numerous changes each
time you add a user record, you can create additional default UAF records to
serve as templates for each user category.
Before you create additional default records, you must first decide
•

What the individual user categories are

•

What attributes are common to each category

•

What to name the default records

Once you define a user category and establish which record attributes are
needed, you can create the default record. For example, the following
command creates a default record for a category of user that requires a
special captive account:
UAF> ADD DEFAULT2/LGICMD=ALT_C0M_PR0C/FLAGS=CAPTIVE _UAF> /DEVICE=USER3:/DIRECTORY=[PRODUCT]

The command in this example uses the system-supplied default record
DEFAULT to create the record DEFAULT2, and changes the LGICMD,
login flags, default device, and default directory fields. The AUTHORIZE
command COPY can then be used to create additional records having the
same attributes as DEFAULT2.
The COPY command creates a new UAF record that duplicates the specified
default record except where you explicitly override field values. For example,
you could use the following command to create a record for a new user that
duplicates the default record DEFAULT2:
UAF> COPY DEFAULT2 PAL00KA/PASSW0RD=W7YA84MI/UIC=[360,114]

This example uses DEFAULT2 as a template to create a duplicate record for
the user PALOOKA. Notice that the only values that are changed are those
for password and UIC.

5.5.2

Deleting a User Account
The main problem in deleting an account, especially an interactive account, is
cleaning up the files used by the account. The following steps are suggested:
1

Copy (or have the outgoing user of the account copy) any files of value
to the ownership of another account. You should be sure to change the
owner UIC of the files to match the owner UIC of the new owner. You
can also use the Backup Utility (BACKUP) to copy the files to a backup
tape or disk.

5-15

Managing System Users

Set your UIC to that of the account to be deleted and remove all
privileges, or else change the password and log in as a user of that
account. This is especially important if you are using a command
procedure similar to the one in Example 5-5.

Delete the account's files and directories from the deepest level up to the
top level, using the following procedure:
a

Locate and examine all subdirectories using the DCL command
DIRECTORY [default . . . ], where default is the name of the account's
default directory.

Delete the files in each subdirectory and then delete the subdirectory.
Note that directory files are protected against owner deletion, therefore,
you must change the protection before deleting directory files.

Delete the account's first-level directory. Example 5-5 illustrates a
command procedure that deletes an account's files from the bottom
level up.

Note: The command procedure in Example 5-5 should not be executed by
a privileged user.
4

Remove the account, using the Authorize Utility.

Remove the user's disk quota entry from the disk quota file, if one existed,
with the Disk Quota Utility.

6 Remove associated VAXmail information.
Example 5-5

Command Procedure Template for Deleting an
Account's Files

$ !
DELTREE.COM - deletes a complete directory tree
$ •
$ !
PI = pathname of root of tree to delete
$ •
$ !
All files and directories in the tree, including
$ !
the named root, are deleted.
$ !
$ IF ""DELTREE'" .EQS. "M THEN DELTREE = "<DSYS$LIBRARY:DELTREE"
$ ON C0NTR0L.Y THEN GOTO DONE
$ ON WARNING THEN GOTO DONE
$ DEFAULT = F$L0GICAL("SYS$DISK") + F$DIRECT0RY()
$10:
$ IF PI .NES. "" THEN GOTO 20
$ INQUIRE PI "Root"
$ GOTO 10
$20:
$ IF F$PARSE(P1) .EQS. "" THEN OPEN FILE ’PI'
$ SET DEFAULT 'PI'
$L00P:
$ FILESPEC * F$SEARCH("*.DIR;1")
$ IF FILESPEC .EQS. "" THEN GOTO L00PEND
$ DELTREE [.'F$PARSE(FILESPEC..,"NAME")']
$ GOTO LOOP
$L00PEND:
$ IF F$SEARCH("*.*;*") .NES. "" THEN DELETE *.*;*
$ DIR = (F$DIRECT0RY()-"]-F$PARSE("[-]" , , , "DIRECTORY")-"] »-">»)-« .
$ SET PR0TECTI0N=W0RLD:RWED [-]'DIR'.DIR;1
$ DELETE [-]'DIR'.DIR;1
$D0NE:
$ SET DEFAULT 'DEFAULT'

5-16

Managing System Users

If you never assign multiple users the same UIC, you can use the Backup
Utility to remove the user's files, even if the files are scattered throughout
the directory structure. See the VAX/VMS Backup Utility Reference Manual
for more information. To remove files using BACKUP, issue the command
shown in this example:
$ BACKUP/DELETE PUBLIC:[...]/0WNER=[21,103] MTAO:PUBLICUIC.SAV

This BACKUP command copies and deletes only those files owned by the
specified UIC on disk PUBLIC. The files are copied into a save set named
PUBLICUIC on device MTAO.

5.5.3

Disabling a User Account
If it becomes necessary to disable an account, but deleting it at present would
be undesirable, use AUTHORIZE to set the disable user flag
(/FLAGS=DISUSER). If the user is logged in, the account is disabled only
after the user logs out.
Disabling a powerful yet infrequently used account provides an extra security
measure by eliminating the risk of guessed or stolen passwords.

5.5.4

Recovering Lost Files
Under normal circumstances, files should not become lost. However, files
occasionally may be lost due to disk corruption, hardware problems, or
user inexperience. For example, in cleaning up files and directories, you
may inadvertently delete directories that still point to files. When you
delete a directory file (a file with the file type DIR) without first deleting
its subordinate files, the files referred to by that directory become lost files—
files that remain on the disk but are not referenced by any directory. Lost
files are often obsolete files that consume disk space and act as debits against
a user's disk quota.
You can recover lost files by issuing the Verify Utility command:
ANALYZE/DISK.STRUCTURE/REPAIR/CONFIRM device-name:

See the VAX/VMS Verify Utility Reference Manual for a detailed description of
the ANALYZE/DISK-STRUCTURE command.
This command, which requires BYPASS privilege, places lost files in a
directory named [SYSLOST]. This directory resides in the disk's master
file directory (000000), and is created by the Verify Utility when a lost file is
recovered.
To restore lost files to the [SYSLOST] directory, issue the command shown in
this example:
$ ANALYZE/DISK.STRUCTURE/REPAIR/CONFIRM DDAO:

5-17

Managing System Users

The Verify Utility returns the following messages and prompts you for the
appropriate action:
'/.VERIFY-1-LOSTHEADER, file (408,39,1) SUB_A.DIR;1
Not found in directory
Delete or Repair this error (D,Y,N):
'/.VERIFY-1-LOSTHEADER, file (429,4,1) ALPHA.DAT;4
Not found in directory
Delete or Repair this error (D,Y,N):
7.VERIFY-1 - LOSTHEADER, file (435,13,1) OMEGA.DAT;2
Not found in directory
Delete or Repair this error (D,Y,N):

To write the lost files to [SYSLOST], specify YES or Y in response to the
prompt Delete or Repair this error QD,Y,N):. You can then copy, rename, or
back up the lost files from [SYSLOST] to another directory. The file owner
requires no special privileges to copy the files from [SYSLOST], as the files
still retain the original owner UIC. A minimum of RE AD ALL privilege is
required, however, to display the contents of the SYSLOST directory.
As system manager, you should periodically use the Verify Utility command
ANALYZE/DISK_STRUCTURE/REPAIR/CONFIRM to check for the
presence of lost files on the disk. Another opportunity to check for lost
files is during a Backup operation. See the VAX/VMS Backup Utility Reference
Manual for complete descriptions of the Backup commands and qualifiers.
The following Backup command returns a formatted listing of the files in the
Backup save set as the operation proceeds:
BACKUP/IMAGE/LIST device.A: device JB:saveset.sav/SAVESET

Lost files appear at the end of the save set listing as files with empty brackets,
indicating that they are not found within any directory. For example:
[ ]SUB_A.DIR;1
[ ]ALPHA.DAT;4
[ ]OMEGA.DAT;2
End of saveset

5.5.5

Restricting the Use of Accounts
Often workload schedules dictate the days and times your system is used to
perform specific operations. Depending on the nature of the work performed
at your site, you may want to control when certain users are allowed to log in.
Using the Authorize Utility, you can place controls in the login characteristics
fields of the UAF record to restrict the days and times a user can log in and to
inhibit certain login functions.
For a detailed description of the qualifiers used to restrict the use of accounts,
see the discussion of the Authorize Utility in the VAX/VMS Authorize Utility
Reference Manual. The next sections discuss some of the most common
restrictions.

5-18

Managing System Users

5.5.5.1

Setting Day Types
You restrict the use of certain accounts by defining the days of the week
as either PRIMARY or SECONDARY, and then assigning login restrictions
to these defined day types. For example, if you define the days Saturday
and Sunday as SECONDARY days, then any restrictions you assign to the
SECONDARY day type apply to both.
There are two types of login restrictions that you can assign to either day
type:
•

Time restrictions—Limit logins to specific hours of the day

•

Function restrictions—Limit types of login

By default, in every user record, the five weekdays (Monday through Friday)
are defined as PRIMARY days, and the two weekend days (Saturday and
Sunday) are defined as SECONDARY days.
The way you define days and assign restrictions depends on your site. For
example, suppose that on weekdays your system supports a large number of
interactive users, but on weekends it is used for certain operations that require
dedicated system resources. By assigning restrictions to the SECONDARY day
type, you can restrict users from accessing the system during the days defined
as SECONDARY. You can change these day type definitions for any account
using the following AUTHORIZE qualifier:
/PRIMEDAYS=([NO]day[,...])

The /PRIMEDAYS qualifier uses a list of day names to define the PRIMARY
and SECONDARY days of the week. To define a day as a SECONDARY day,
use the prefix NO before the day name. Any days that you omit from the list
take their default value.
5.5.5.2

Restricting Logins to Specific Times
By default, there are no restrictions on login hours. You can specify login
time restrictions using the following AUTHORIZE qualifiers:
Qualifier

Meaning

/[NO]ACCESS

Specifies access hours for all modes of logins

/[NOJDIALUP

Specifies access hours for interactive logins via dialup
terminals

/[NOJINTER ACTIVE

Specifies access hours for interactive logins via any
terminal

/[NOjLOCAL

Specifies access hours for interactive logins via local
terminals

/[NOJREMOTE

Specifies access hours for interactive logins via network
remote terminals (SET HOST)

Any user still logged in when the access time has expired, will receive the
following warning message, and have two minutes to log out before their
process is terminated by the job controller.
JBC-W-RESTRICT, UAF restricts access at this time, please log out immediately

5-19

Managing System Users

5.5.5.3

Restricting Login Functions
In addition to specifying hourly login restrictions, you can also assign function
restrictions to an account by using appropriate keywords with the /FLAGS
qualifier in the Authorize Utility. By default, there are no restrictions. Options
are
Keyword

Meaning

[NO]AUDIT

[Do not] audit all security-relevant actions

AUTOLOGIN

Makes account available only by using the autologin
mechanism

[NOJCAPTIVE

[Do not] prevent user from changing any defaults at login

[NO]DEFCLI

[Do not] prevent user from changing default CLI or CLI
tables

[NOJDISCTLY

[Do not] disable CTRL/Y interrupts

[NO]DISNEWMAIL

[Do not] suppress "New Mail ..." announcements

[NOJDISREPORT

[Do not] report login information (last login date, login
failures, and so on)

[NO]DISUSER

[Do not] disable the account completely

[NO]DISWELCOME

[Do not] suppress "Welcome to ...

[NOJGENPWD

[Do not] require user to use generated passwords

[NOJLOCKPWD

[Do not] prevent user from changing password

[NO]DISMAIL

[Do not] prevent mail delivery to the user

[NO]PWD_EXPIRED

[Do not] mark password as expired

[NO]PWD2 EXPIRED

[Do not] mark second password as expired

If the AUTOLOGIN flag is set, the following forms of access are disabled:
•

•

Access by DECnet task using explicit access control

The following forms of access remain enabled:

5.6

•

Interactive login by the autologin mechanism

•

Batch jobs

•

Proxy access by DECnet task

UAF Login Checks
To help you understand the effect of login restrictions, this section explains
how the system checks the login fields of the UAF when a user attempts to
log in.
When a user activates a terminal (by turning it on and pressing RETURN
if directly connected, or by dialing in to a system and observing the remote
connect protocol), and that terminal is not allocated by a user process, the
system prompts for a name and password. The person using the terminal
must type a name and password combination that exists in a UAF record, or
the system denies him further access. If the name and password are accepted,
the system then performs the following operations:
5-20

Managing System Users

Examines the login flags, beginning with DISUSER. If DISUSER is
set, the login attempt fails. Note that setting this flag for powerful,
infrequently used accounts (such as SYSTEM, SYSTEST, and FIELD)
virtually eliminates the risk of guessed passwords for those accounts.

If the DISUSER flag is not set, verifies primary or secondary day
restrictions. After checking the current day type, the system determines
whether hourly login restrictions are in effect (as defined by the /ACCESS,
/DIALUP, /INTERACTIVE, /LOCAL, and /REMOTE qualifiers). If
the current hour is restricted, the login fails immediately. Otherwise it
succeeds.

If the login is successful, passes control to the command interpreter (for
example, DCL) named in the user's UAF record.

Checks whether SYS$SYLOGIN is defined. If so, the logical name
is translated (in most cases to SYS$MANAGER:SYLOGIN.COM) and
that procedure is executed. When the procedure completes, the system
searches for the name of a login command procedure in that user's UAF
record. If a command procedure is specified in the LGICMD field and that
procedure exists, it is executed. Otherwise, if the LGICMD field is blank,
the user's command file named LOGIN is executed automatically (if it
exists).

After a successful login, the command interpreter prompts for user input
(DCL usually displays a dollar sign) and the user responds with commands
acceptable to the command interpreter. (DCL accepts those commands
documented in the VAX/VMS DCL Dictionary.) However, the system prohibits
activities that violate the user's privilege allowance or exceed resource quotas.

5.7

Alternate Login Procedures
There are situations when normal login activities using the UAF are either
impossible or undesirable. The UAF may be inaccessible for some reason, or
you may want to boot for standalone functions using an alternate UAF that
restricts access to the system. This section discusses these two situations.
If the UAF is locked, disabled, or not present, you can log in on the console
terminal with any name and password. The system assigns the following
values to your user account:
•

Name—Your user name

•

UIC—[001,004]

•

Command interpreter—DCL

•

Priority—Value of the system parameter DEFPRI

•

Resources—Values of the PQL system parameters

•

Privileges—All

The process name is normally the name of the device on which you logged
in, that is, _OPAO.

5—21

Managing System Users

If you want to take the system for standalone use, you can select, at bootstrap
time, an alternate UAF named SYS$SYSTEM:SYSUAFALT.DAT by using a
system parameter file in which the UAF ALTERNATE parameter has a value
of 1. You can also change this value to 1 during a conversational bootstrap
operation. (See Section 11 for information on creating system parameter files.)
Note that a file named SYSUAFALT in UAF format must exist at bootstrap
time. (The system initially changes to the alternate UAF by assigning
SYSUAF as a logical name for SYSUAFALT.) If the UAFALTERNATE
parameter is set at bootstrap time and no alternate UAF exists, the system
behaves like an open system.
You can create or modify an alternate UAF with the following commands:
$ SET DEFAULT SYS$SYSTEM
$ DEFINE SYSUAF SYSUAFALT
$ RUN AUTHORIZE

Any time after booting the system with an alternate UAF, you can switch to
the standard UAF (that is, SYS$SYSTEM:SYSUAF.DAT) with the following
DCL command:
$ DEASSIGN SYSUAF/SYSTEM

You can also switch to the alternate UAF after bootstrap time with the
following DCL command:
$ DEFINE/SYSTEM/EXEC SYSUAF SYSUAFALT

(For this mode of operation, the alternate UAF can have any file name.)

5.8

Creating Proxy Accounts
A proxy login account allows users on a remote node in a network to access
data by way of a local account on your system. Proxy accounts are useful
when you want to grant one or more users on a remote node access to specific
files but find it undesirable to provide them with a private account on your
system. You establish and control proxy accounts with the Authorize Utility.
With proxy accounts, you can authorize one or more users on a remote node
to issue DCL commands that access data from a particular account on your
system. Proxy accounts allow remote users to access specific local data (for
example, type and print files) without having to log in to your system or use
an access control string. Remote users assume the same file access rights as
the local account and also receive the default privileges of the local account.
The following sections explain the procedures for setting up proxy accounts.

5.8.1

Creating a Network User Authorization File
Proxy accounts exist as records in a network UAF called
SYS$SYSTEM:NETUAF.DAT and are created and maintained using the
Authorize Utility. Since the network UAF is not provided with the
distribution kit, you must create and initialize it. You use the AUTHORIZE
command CREATE/PROXY for this operation.
Proxy accounts must be associated with a user account in the SYSUAF.DAT
file on your local system. You will probably want to create a "standard
access" account in the UAF for proxy accounts. For example, you could create
an account named REMOTE—MARKET with limited privileges, which allows
access to certain data files on your local system.

5-22

Managing System Users

Suppose you have a group of users on your local system who prepare
marketing reports, and who rely on input from users on other systems. You
would assign the REMOTE—MARKET account in SYUAF.DAT the same
group number and default privileges you assign to the local marketing group.
In this way, the remote contributors could access any data files that are
"owned" by users in your marketing group and that are not protected from
GROUP access.

5.8.2

Adding Proxy Accounts
You create a proxy account by adding records to the network UAF that equate
one or more users on a remote node to users on your home node.
For example, the following command adds a user proxy account:
UAF> ADD/PROXY HAL::WALTER REMOTE.MARKET

Assume that you have created an account named REMOTE—MARKET
on your home node. The record created in this example permits the user
WALTER on remote node HAL to access data by way of the
REMOTE—MARKET account on your home node. With the proxy account,
WALTER can access any data from his node that REMOTE—MARKET can
access locally.
Note: Since the remote user receives the same privileges as the local user, you
should not set up proxy accounts associated with local accounts that have
special privilege. Granting remote users such access powers poses a threat
to the security of your system.
When creating such an account, remember that each user on a remote
node is allowed access to only one account on the local node. So, in the
previous example, HAL::WALTER is allowed access only to the files that
REMOTE—MARKET can access. If you tried to add another proxy account for
HAL::WALTER, you would receive an error message.
A number of your users may have accounts on a remote node and require
ready access to their local files. You can create a network authorization record
that grants access to each of them, provided that the user name on your
system is the same as the user name on the remote node. The following form
of the ADD/PROXY command adds such a record:
UAF> ADD/PROXY HAL::* *

This command authorizes any user on the remote node HAL to access any
account with the same user name on your system.
Similarly, you might want to permit this sort of access for just one user.
UAF> ADD/PROXY HAL::BARBARA *

In this case, the user BARBARA on node HAL can access any files that
BARBARA (and only BARBARA) can access on your system.

5-23

Managing System Users

5.8.3

Controlling Proxy Logins
Whenever a proxy login request occurs, the system verifies that proxy
access on the participating nodes is enabled. (By default, both incoming
and outgoing proxy access is enabled for each node.) If access is enabled,
the system checks account information in your NETUAF.DAT. You can,
however, change proxy access or disable it totally by using the Network
Control Program (NCP). Use of NCP to control proxy access is described in
the VAX/VMS Networking Manual

5-24

Resource Control

This chapter contains detailed descriptions of the resource control attributes
that you can assign to a user process when creating a record in the UAF:
•

Limits on reusable system resources

•

Base priority for scheduling user processes

•

Privileges allowing use of restricted and sensitive system functions

In addition, this chapter discusses the accounting log file as a tool for tracking
resource use.

6.1

Setting Limits on Reusable System Resources
Each user of the system is limited in the consumption of such resources
as system memory. You set limits when you define the user to the system
through the creation of an account in the UAF.
Limits control the way in which a process shares its allotment of a resource
with the subprocesses that it creates. In addition to restricting the number
of processes that a single user or account may have at any given time, the
system uses four types of limits for sharing resources:
•

Pooled—If the limit on the use of a resource is pooled, a process and
created subprocesses share the total limit on a first-come, first-served
basis.

•

Deductible—If the limit on the use of a resource is deductible, a
subprocess is allotted a portion of the total limit; the portion given to
the subprocess is deducted from the total limit.

•

Nondeductible—If the limit is nondeductible, the subprocess is allotted
the total limit of the creating process; there is no deduction from the
allotment of the creating process.

•

systemwide—If the limit is systemwide, a process and all created
subprocesses with the same user name or account share the total limit
on a first-come, first-served basis.

In creating a UAF record, you assign values to the limits shown in Table 6-1.
These limits are described in the following sections. Usually, you simply
assign the default values for these limits. However, see the Guide to
VAX/VMS Performance Management for a discussion of how to evaluate
and adjust the limits in the context of performance optimization strategies.
Table 6-1 summarizes each of these limits, the suggested value, and the type
of limit.

6-1

Resource Control

Table 6-1

Process Resource Limits, Suggested Values, Types,
and Descriptions

Limit

Value

Type1

Description

AST queue limit

BIOLM

Buffered 1/0 count limit

BYTLM

8192

I/O byte count limit

CPU time limit (0 = no limit)

DIOLM

Direct I/O count limit

ENQLM

Enqueue quota

ASTLM

CPU

Open file limit

1024

Initial byte quota for jobwide logical name
table

MAXACCTJOBS

Maximum active processes for a single
account (0 = no limit)

MAXDETACH

Maximum detached processes for a single
user name (0 = no limit)

MAXJOBS

Maximum active processes for a single
user name (0 = no limit)

PGFLQUO

FILLM
JTQUOTA

12800

Paging file limit

PRCLM

Subprocess creation limit

SHRFILLM

Maximum number open shared files
(0 = no limit)

TQELM

Timer queue entry limit

WSDEF

200

Default working set size

WSEXTENT

1000

Working set extent

WSQUO

500

Working set quota

1 D=deductible, N == nondeductible, P== pooled, S=systemwide

6.1.1

AST Queue Limit (ASTLM)
The AST queue limit (ASTLM) limits the sum of the following:
•

The number of asynchronous system trap (AST) requests that a user's
process can have outstanding at one time

•

The number of scheduled wakeup requests that a user's process can have
outstanding at one time

This limit affects not only all system services that accept an AST address as
an argument, but also the Schedule Wakeup ($SCHDWK) system service.
If the deferred write option (DFW) is enabled, the number of ASTs used per
file is equal to 1, plus the number of record streams, plus the multibuffer
count. Otherwise, the number is 1 plus the number of record streams.
ASTLM is a nondeductible limit with a suggested typical value of 24.

6-2

Resource Control

6.1.2 Buffered I/O Count Limit (BIOLM)
The buffered I/O count limit (BIOLM) limits the number of outstanding
buffered I/O operations permitted a user's process.
In a buffered I/O operation, the data transfer takes place from an intermediate
buffer in the system pool, not from a process-specified buffer. Buffered
operations for a user process include terminal I/O, file system and network
I/O, card reader input, and unspooled printer output. During a buffered
I/O operation, the pages containing the process-specified buffer need not be
locked in memory.
BIOLM is a nondeductible limit with a suggested typical value of 18.

6.1.3 Buffered I/O Byte Count Limit (BYTLM)
The buffered I/O byte count limit (BYTLM) limits the amount of buffer space
that a user's process can use.
This buffer space is used for buffered I/O operations and for the creation
of temporary mailboxes. It also limits the number of mapping windows the
user can create as segmented (or cathedral) windows. Cathedral windows are
primarily useful to reduce the overhead required to read large files.
BYTLM is a pooled limit with a suggested typical value of 8192.

6.1.4 CPU Time Limit (CPU)
The CPU time limit (CPU) limits the amount of CPU time that a user's
process can use per interactive session or batch job.
The time must be specified in abbreviated delta format—hh:mm:ss:cc.
CPU is a deductible limit with a suggested typical value of 0 (no limit),
but the value only applies to this instance or other instances of the user's
processes. CPU is not cumulative across separate sessions or batch jobs.

6.1.5 Direct I/O Count Limit (DIOLM)
The direct I/O count limit (DIOLM) limits the number of outstanding direct
I/O operations permitted a user's process.
In a direct I/O operation, the data transfer takes place directly from a processspecified buffer. Direct I/O operations for a user process typically include
disk and tape I/O. The pages containing this buffer are locked in memory by
the operating system during the direct I/O operation.
DIOLM is a nondeductible limit with a suggested typical value of 18.

6-3

Resource Control

6.1.6 Enqueue Quota (ENQLM)
The enqueue quota (ENQLM) limits the number of locks a process (and its
subprocesses) can own. VAX Record Management Services (RMS) uses the
Lock Management Facility to synchronize shared file access, global buffers,
and record locks. Because VAX RMS takes out one lock for every shared
file, local buffer, global buffer section, and outstanding record lock, users
who expect to perform large amounts of VAX RMS file sharing should have
ENQLM set to a large value.
If your process performs extensive VAX RMS file sharing without sufficient
enqueue quota, you could receive the SS$_EXENQLM error message.
Furthermore, if your system performs extensive VAX RMS file sharing
and the value of the LOCKIDTBL system parameter is too low, you could
receive the SS$_NOLOCKID error message. Note that whenever you
increase the value of LOCKIDTBL, you may have to increase the value
of the RESHASHTBL system parameter (see the discussion of the System
Generation Utility (SYSGEN) in the VAX/VMS System Generation Utility
Reference Manual).
For shared files, the value of ENQLM should represent the number of files
open as shared multiplied by the number of locks per process per file. If you
use the default multibuffer counts, you can estimate the number of locks as 4
for indexed sequential files and 3 for relative files. If you use other than the
default value for the multibuffer counts, you can estimate the number of locks
per process per file as one per file plus the multibuffer count for that file plus
the number of records locked (which is usually one). Use the DCL command
SHOW RMS_DEFAULT to display the default multibuffer counts.
ENQLM is a pooled limit with a suggested typical value of 30.

6.1.7 Open File Limit (FILLM)
The open file limit (FILLM) limits the number of files that a user's process
can have open at one time. This limit includes the number of network logical
links that can be active at the same time.
FILLM is a pooled limit with a suggested typical value of 20. Note that each
open file also requires at least 96 bytes of BYTLM.

6.1.8 Job Table Quota (JTQUOTA)
The job table quota (JTQUOTA) specifies the initial byte quota with which the
jobwide logical name table is to be created.
JTQUOTA is a pooled quota with a suggested typical value of 1024.

6.1.9 Maximum Account Jobs Limit (MAXACCTJOBS)
The maximum account jobs limit (MAXACCTJOBS) specifies the maximum
number of batch, interactive, and detached processes that may be active at
one time for all users of a single account.
MAXACCTJOBS is a systemwide limit with a suggested typical value of 0.

6-4

Resource Control

6.1.10 Maximum Detached Processes Limit (MAXDETACH)
The maximum detached processes limit (MAXDETACH) specifies the
maximum number of detached processes that may be active at one time
for a single user name. Processes that exceed this limit are terminated.
MAXDETACH is a systemwide limit with a suggested typical value of 0.

6.1.11 Maximum Process Jobs Limit (MAXJOBS)
The maximum process jobs limit (MAXJOBS) specifies the maximum number
of interactive, batch, and detached processes that can be active at one time for
a user name. Processes that exceed this limit are terminated.
MAXJOBS is a systemwide limit with a suggested typical value of 0.

6.1.12 Paging File Limit (PGFLQUO)
The paging file limit (PGFLQUO) limits the number of pages that the user's
process can use in the system paging file. The paging file provides temporary
disk storage for pages forced out of memory by a memory management
operation. PGFLQUO limits the total virtual address space that can be
created using the Create Virtual Address Space ($CRETVA) or Expand
Program/Control Region ($EXPREG) system services.
PGFLQUO is a pooled limit with a suggested typical value of 12800.

6.1.13 Subprocess Creation Limit (PRCLM)
The subprocess creation limit (PRCLM) limits the number of subprocesses a
user's process can create.
The process that is created when a user logs in to the system can in turn
create subprocesses. These subprocesses are all accountable to the user and
share the resources allotted to the initial process.
PRCLM is a pooled limit with a suggested typical value of 2.

6.1.14 Shared Files Limit (SHRFILLM)
The shared files limit (SHRFILLM) specifies the maximum number of shared
files that an account may have open at one time. The shared files limit is a
pooled limit with a suggested typical value of 0.

6—5

Resource Control

6.1.15 Timer Queue Entry Limit (TQELM)
The timer queue entry limit (TQELM) limits the sum of the following:
•

The number of entries that a user's process can have in the timer queue

•

The number of temporary common event flag clusters that a user's process
can have

This limit does not govern the creation of permanent event flag clusters.
Timer queue entries are used in time-dependent scheduling; common event
flags are used in synchronizing activities among groups of cooperating
processes.
TQELM is a pooled limit with a suggested typical value of 10.

6.1.16 Default Working Set Size (WSDEF)
The default working set size (WSDEF) sets the initial working set size limit
for a user's process.
WSDEFAULT is a nondeductible limit with a suggested typical value of 200
pages. If the value specified exceeds the value of WSQUOTA (see Section
6.1.18), the lesser value is used.

6.1.17 Working Set Extent (WSEXTENT)
The working set extent (WSEXTENT) specifies the maximum size to which
a user's physical memory usage can grow, independent of the system load.
This enlargement of the physical memory for a user is accomplished by the
Adjust Working Set Limit ($ADJWSL) system service, and is normally done
for the user by VAX/VMS in response to heavy page faulting by the user.
WSEXTENT is a nondeductible quota with a suggested typical value of 1000
or more. This value should always be greater than or equal to WSQUOTA.
The value is controlled by the system parameter WSMAX.

6.1.18 Working Set Quota (WSQUOTA)
The user's physical memory usage can grow on a typically loaded system.
That is, this parameter guarantees the user that the number of physical pages
specified will be available. For example, WSQUOTA limits the number of
pages a user can lock in memory.
WSQUOTA is a nondeductible quota with a suggested typical value of 500.
This value should be greater than or equal to WSDEFAULT. The value is
controlled by the system parameter WSMAX.

6-6

Resource Control

6.2

Setting Priorities for User Processes
A user's priority is the base priority used in scheduling the process that the
system creates for the user. There are 32 levels of software priority in the
VAX/VMS system, 0 through 31. The highest priority is 31; the lowest is 0.
The range of priorities for timesharing processes is 1 through 15; the range
for real-time processes is 16 through 31.
Processes with real-time priorities are scheduled strictly according to base
priority; in other words, the executable real-time process with the highest
base priority is executed first. Processes with timesharing priorities are
scheduled according to a slightly different principle, to promote overlapping
of computation and I/O activities.
In the user's account record of the UAF, the default value of a user's priority
is 4; for practical purposes, the minimum value is 1. You should ensure that
the priority for timesharing users remains at the default. Note that if you give
some users an advantage over other users by raising their priorities, ragged
performance will result, because the system reacts sharply to even small
priority differences.
Never specify a value over 31 (system operation will be unpredictable).

6.3

Assigning Privileges
Privileges restrict the performance of certain system activities to certain
users. These restrictions protect the integrity of the operating system's
performance and thus the integrity of service provided to users. You should
grant privileges to each user on the basis of two factors:
•

Whether the user has the skill and experience to use the privilege without
disrupting the system

•

Whether the user has a legitimate need for the privilege

Privileges fall into seven categories according to the damage that the user
possessing them could cause the system:
•

None—No privileges

•

Normal—Minimum privileges to use the system effectively

•

Group—Potential to interfere with members of the same group

•

Devour—Potential to consume noncritical systemwide resources

•

System—Potential to interfere with normal system operation

•

Files—Potential to compromise file security

•

All—Potential to control the system

A user cannot execute an image that requires a privilege he or she does not
possess, unless the image is installed as a known image with the privilege
in question. (See Section 8 for instructions on installing known images.)
Execution of a known image with temporary privileges (for the duration of
the image's execution) grants those privileges to the user process executing
the image. Thus, you should install user images with amplified privileges
only after ensuring that the user needs the access and is unlikely to misuse it.

6-7

Resource Control

A user's privileges are recorded in the user's UAF record in a 64-bit privilege
vector. When a user logs in to the system, the user's privilege vector is
stored in the header of the user's process. In this way, the user's privileges
are passed on to the process created for the user. Users can use the DCL
command SET PROCESS/PRIVILEGES to enable and disable privileges for
which they are authorized, to further control the privileges available to the
images they run. Moreover, any user with the SETPRV privilege can enable
any privilege.
Table 6-2 lists the privileges by category and gives brief, general definitions of
them. The following sections describe each privilege in detail in alphabetical
order and indicate privilege categories.
Table 6-2
Category

Privilege

Activity Permitted

None

None requiring privileges

Normal

MOUNT

Execute mount volume QIO

Group

Devour

System

Files

All

6-8

VAX/VMS Privileges by Category, with Definitions

NETMBX

Create network connections

TMPMBX

Create temporary mailbox

GROUP

Control processes in the same group

GRPPRV

Group access via SYSTEM protection field

ACNT

Disable accounting

ALLSPOOL

Allocate spooled devices

BUGCHK

Make bugcheck error log entries

EXQUOTA

Exceed disk quotas

GRPNAM

Insert group logical names in the name table

PRMCEB

Create/delete permanent common event flag
clusters

PRMGBL

Create permanent global sections

PRMMBX

Create permanent mailboxes

SHMEM

Create/delete structures in shared memory

ALTPRI

Set base priority higher than allotment

OPER

Perform operator functions

PSWAPM

Change process swap mode

Access devices allocated to other users

SYSLCK

Lock systemwide resources

WORLD

Control any process

DIAGNOSE

Diagnose devices

SYSGBL

Create systemwide global sections

VOLPRO

Override volume protection

BYPASS

Disregard protection

CMEXEC

Change to executive mode

CMKRNL

Change to kernel mode

Resource Control

Table 6-2 (Cont.)
Category

VAX/VMS Privileges by Category/ with
Definitions

Privilege

Activity Permitted

DETACH

Create detached processes of arbitrary UIC

LOG—IO

Issue logical I/O requests

PFNMAP

Map to specific physical pages

PHY_IO

Issue physical I/O requests

READALL

Possess read access to everything

SECURITY

Perform security-related functions

SETPRV

Enable any privilege

SYSNAM

Insert/delete system logical names in the name table

SYSPRV

Access objects via SYSTEM protection field

6.3.1 ACNT Privilege (Devour)
The ACNT privilege allows a user to create subprocesses or detached
processes in which accounting is disabled. Thus, only such a privileged user
can issue the DCL command RUN with the /NOACCOUNTING qualifier or
inhibit accounting in the Create Process ($CREPRC) system service.

6.3.2 ALLSPOOL Privilege (Devour)
The ALLSPOOL privilege allows the user's process to allocate a spooled
device by executing the Allocate Device ($ALLOC) system service. This
service lets a process allocate, or reserve, a device for its exclusive use. A
shareable mounted device cannot be allocated. The user may also allocate a
spooled device by using the DCL command ALLOCATE.
You should grant this privilege only to users who need to perform logical
or physical I/O operations to a spooled device. Ordinarily, the privilege of
allocating a spooled device is granted only to symbionts (see Section 9.7.11).

6.3.3 ALTPRI Privilege (System)
The ALTPRI privilege allows the user's process to
•

Increase its own base priority

•

Set the base priority of another process to a value higher than that of the
target process

The base priority is increased by executing the Set Priority ($SETPRI) system
service or the DCL command SET PROCESS/PRIORITY. As a rule, this
system service lets a process set its own base priority or the base priority
of another process. However, one process can set the priority of a second
process if
•

The process calling the $SETPRI system service has the same UIC as the
target process

6—9

Resource Control

•

The calling process has process control privilege (GROUP or WORLD)
over the target process

With ALTPRI, a process can create a process with a priority higher than its
own. It creates such a process by using an optional argument to the Create
Process ($CREPRC) system service or to the DCL command RUN.
You should not grant this privilege widely; if unqualified users have the
unrestricted ability to set base priorities, the fair and orderly scheduling of
processes for execution can easily be disrupted.

6.3.4 BUGCHK Privilege (Devour)
Use of the BUGCHK privilege should be restricted to system software
supplied by DIGITAL that uses the VAX/VMS Bugcheck Facility. This
privilege allows the user process to make bugcheck error log entries.

6.3.5 BYPASS Privilege (All)
The BYPASS privilege allows the user's process read, write, execute, and
delete access to all files, bypassing UIC protection.
You should grant this privilege with extreme caution, as it overrides all file
protection. It should be reserved for experienced users, well-tested, reliable
programs and command procedures, or the system backup operation (see
Section 2 and the Guide to VAX/VMS Disk and Magnetic Tape Operations for a
discussion of backup operations). SYSPRV is adequate for interactive use, as
it ultimately grants access to all files, while still providing access checks.

6.3.6 CMEXEC Privilege (All)
The CMEXEC privilege allows the user's process to execute the Change Mode
to Executive ($CMEXEC) system service.
This system service lets a process change its access mode to executive, execute
a specified routine, and then return to the access mode that was in effect
before the system service was called. While in executive mode, the process is
allowed to execute the Change Mode to Kernel ($CMKRNL) system service.
You should grant this privilege only to users who need to gain access to
protected and sensitive data structures and internal functions of the operating
system. If unqualified users have unrestricted access to sensitive data
structures and functions, the operating system and service to other users
can easily be disrupted. Such disruptions can include failure of the system,
destruction of the database, and exposure of confidential information to
unauthorized persons.

6—10

Resource Control

6.3.7 CMKRNL Privilege (All)
The CMKRNL privilege allows the user's process to execute the Change Mode
to Kernel ($CMKRNL) system service.
This system service lets a process change its access mode to kernel, execute a
specified routine, and then return to the access mode that was in effect before
the system service was called.
In granting this privilege, follow the guidelines for the CMEXEC privilege.

6.3.8 DETACH Privilege (All)
The DETACH privilege allows the user's process to create detached processes
by executing the Create Process ($CREPRC) system service. Detached
processes remain in existence even after the user who created them has
logged off the system.
An example of a detached process is the process created by the system for a
user when the user logs in to the system.
There is no restriction on the UIC that can be specified for a detached process.
Thus, there are no restrictions on the files and directories to which a detached
process can gain access.

6.3.9 DIAGNOSE Privilege (Files)
The DIAGNOSE privilege allows the user to run online diagnostic programs
and to intercept and copy all messages that are written to the error log file.

6.3.10 EXQUOTA Privilege (Devour)
The EXQUOTA privilege allows the space taken by the user's files on given
disk volumes to exceed any usage quotas set for the user (as determined by
UIC) on those volumes.

6.3.11 GROUP Privilege (Group)
The GROUP privilege allows the user's process to affect other processes in its
own group by executing the following process control system services:
•

Cancel Wakeup ($CANWAK)

•

Delete Process ($DELPRC)

•

Force Exit ($FORCEX)

•

Resume Process ($RESUME)

•

Schedule Wakeup (SSCHDWK)

•

Set Priority ($SETPRI)

•

Suspend Process ($SUSPND)

•

Wake ($WAKE)

6-11

Resource Control

The user's process is also allowed to examine other processes in its own group
by executing the Get Job/Process Information ($GETJPI) system service. A
user with the GROUP privilege can issue the SET PROCESS command for
other processes in its group.
The GROUP privilege is not needed for a process to exercise control over, or
to examine, subprocesses that it created. You should grant this privilege to
users who need to exercise control over each other's processes and operations.

6.3.12 GRPNAM Privilege (Devour)
The GRPNAM privilege allows the user's process to insert names in the
logical name table of the group to which the process belongs and to delete
names from that table, using the following logical name system services:
Create Logical Name ($CRELNM) and Delete Logical Name ($DELLNM).
In addition, the privileged user can use the DCL commands ASSIGN and
DEFINE to add names to the group logical name table. The DEASSIGN
command deletes names from the table, and the /GROUP qualifier of the
MOUNT command shares volumes among group members.
This privilege should not be granted to all users of the system because it
allows a user to create an unlimited number of group logical names. When
unqualified users have the unrestricted ability to create group logical names,
excessive use of system dynamic memory can degrade system performance.
In addition, a user with the GRPNAM privilege can interfere with the
activities of other users in the same group by creating definitions of commonly
used logical names, such as SYS$SYSTEM.

6.3.13 GRPPRV Privilege (Group)
The GRPPRV privilege allows a process access to files using the files'
SYSTEM protection field when the process' group matches the group of
the file owner. It also allows a process to change the protection of files whose
owner group matches the process' group.

6.3.14 LOG_IO Privilege (All)
The LOG_JO privilege allows the user's process to execute the Queue I/O
Request ($QIO) system service to perform logical-level I/O operations. This
privilege is also required for certain device control functions, such as setting
permanent terminal characteristics.
Usually, user I/O requests are handled indirectly by use of an I/O package,
such as VAX Record Management Services. However, to increase their control
over I/O operations and to improve the efficiency of I/O operations, skilled
users sometimes prefer to handle directly the interface between their process
and a system I/O driver program. They can do this by executing the Queue
I/O Request system service; in many instances, the operation called for is a
logical-level I/O operation.
You should grant this privilege only to users who need it, because it allows a
process to access data anywhere on the selected volume without the benefit
of any file structuring. If this privilege is given to unqualified users who have
no need for it, the operating system and service to other users can easily be
disrupted. Such disruptions can include the destruction of information on the

6-12

Resource Control

system device, the destruction of user data, and the exposure of confidential
information to unauthorized persons.

6.3.15 MOUNT Privilege (Normal)
The MOUNT privilege allows the user's process to execute the mount volume
QIO function. The use of this function should be restricted to system software
supplied by DIGITAL.

6.3.16 NETMBX Privilege (Normal)
The NETMBX privilege allows the user to perform functions related to a
DECnet computer network. This privilege is normally granted to general
users.

6.3.1 7 OPER Privilege (System)
The OPER privilege allows use of the operator communication process
(OPCOM), as follows:
•

To reply to user requests

•

To broadcast messages to all terminals logged in

•

To designate terminals as operators' terminals and specify the types of
messages to be displayed

•

To initialize and control the operator log file

In addition, this privilege lets the user set devices spooled, create and control
both batch and output queues, and initialize and mount public volumes.
You should grant this privilege only to operators of the system. These
are the users who respond to the requests of ordinary users, who tend to
the needs of the system's peripheral devices (mounting reels of tape and
changing printer forms), and who attend to all the other day-to-day chores of
system operation. (A nonprivileged user can log in on the console terminal to
respond to operator requests, for example, to mount a tape.)

6.3.18 PFNMAP Privilege (All)
The PFNMAP privilege allows the user's process to map to specific pages of
physical memory or I/O device registers, no matter who is using the pages or
registers.
You should exercise caution in granting this privilege. If unqualified users
have unrestricted access to physical memory, the operating system and
service to other users can easily be disrupted. Such disruptions can include
failure of the system, destruction of the database, and exposure of confidential
information to unauthorized persons.

6-13

Resource Control

6.3.19 PHYSIO Privilege (All)
The PHY—IO privilege allows the user's process to execute the Queue I/O
Request ($QIO) system service to perform physical-level I/O operations.
Usually, users' I/O requests are handled indirectly by use of an I/O package
such as VAX Record Management Services. However, to increase their control
over I/O operations and to improve the efficiency of their applications, skilled
users sometimes prefer to handle directly the interface between their process
and a system I/O driver program. They can do this by executing the Queue
I/O Request system service; in many instances, the operation called for is a
physical-level I/O operation.
You should grant the PHY_IO privilege only to users who need it; in fact, this
privilege should be granted even more carefully than the LOG-JO privilege
(see Section 6.3.14). If this privilege is given to unqualified users who have
no need for it, the operating system and service to other users can easily be
disrupted. Such disruptions can include the destruction of information on the
system device, the destruction of user data, and the exposure of confidential
information to unauthorized persons.

6.3.20 PRMCEB Privilege (Devour)
The PRMCEB privilege allows the user's process to create or delete a
permanent common event flag cluster by executing the Associate Common
Event Flag Cluster ($ASCEFC) or Delete Common Event Flag Cluster
($DLCEFC) system service. Common event flag clusters enable cooperating
processes to communicate with each other, thus providing the means of
synchronizing their execution.
This privilege should not be granted to all users of the system, because it
allows the user to create an unlimited number of permanent common event
flag clusters. A permanent cluster remains in the system even after the
creating process has been terminated and continues to use up a portion of
system dynamic memory. When many users have the unrestricted ability to
create permanent common event flag clusters, the excessive use of system
dynamic memory can degrade system performance.

6.3.21 PRMGBL Privilege (Devour)
The PRMGBL privilege allows the user's process to create global sections
by executing the Create and Map Section ($CRMPSC) system service.
In addition, the user with this privilege (plus the CMKRNL and SYSGBL
privileges) can use the Install Utility.
Global sections are shared structures that can be mapped simultaneously in
the virtual address space of many processes. All processes see the same code
or data. Global sections are used for reentrant subroutines or data buffers.
You should grant this privilege with care. If permanent global sections are
not explicitly deleted, they tie up space in the global section and global page
tables, which are limited resources.

6-14

Resource Control

6.3.22 PRMMBX Privilege (Devour)
The PRMMBX privilege allows the user's process to create or delete a
permanent mailbox by executing the Create Mailbox and Assign Channel
($CREMBX) system service or the Delete Mailbox ($DELMBX) system service.
Mailboxes are buffers in virtual memory that are treated as if they were
record-oriented I/O devices. A mailbox is used for general interprocess
communication.
The PRMMBX privilege should not be granted to all users of the system.
Permanent mailboxes are not automatically deleted when the creating
processes are deleted and, thus, continue to use up a portion of system
dynamic memory.

6.3.23 PSWAPM Privilege (System)
The PSWAPM privilege allows the user's process to control whether it can
be swapped out of the balance set by executing the Set Process Swap Mode
($SETSWM) system service. Not only must a process have this privilege to
lock itself in the balance set (that is, to disable swapping), but also to unlock
itself (that is, to enable swapping).
With this privilege, a process can create a process that is locked in the balance
set (process swap mode disabled) by using an optional argument to the Create
Process ($CREPRC) system service or, when the DCL command RUN is used
to create a process, by using a qualifier of the RUN command.
You should grant this privilege only to users who need to lock a process in
memory for performance reasons. Typically, this will be a real-time process.
If unqualified users have the unrestricted ability to lock processes in the
balance set, physical memory can be held unnecessarily, thereby degrading
system performance.

6.3.24 READALL Privilege (All)
The READALL privilege allows the process to bypass existing restrictions that
would otherwise prevent the process from reading a file. However, unlike
the BYPASS privilege, which permits writing and deleting, READALL permits
only reading of the file.
You should grant this privilege only to individuals with appropriate
management responsibilities at your site.

6.3.25 SECURITY Privilege (All)
The SECURITY privilege allows a process to perform security-related
functions such as enabling or disabling security audits or setting the system
password.
You should grant this privilege only to individuals responsible for system
security.

6-15

Resource Control

6.3.26 SETPRV Privilege (All)
The SETPRV privilege allows the user's process to create processes whose
privileges are greater than its own, by executing the Create Process
($CREPRC) system service with an optional argument, or by issuing the
DCL command RUN to create a process. A user with this privilege can
also execute the DCL command SET PROCESS/PRIVILEGES to obtain any
desired privilege.
You should exercise the same caution in granting the SETPRV privilege as in
granting any other privilege in the ALL category, since SETPRV allows the
user to enable any or all privileges.

6.3.27 SHARE Privilege (System)
The SHARE privilege allows the user's process to assign channels to devices
allocated to other users.
Normally you should grant this privilege only to system software such as
symbionts. This privilege would allow an irresponsible user to interfere with
the operation of devices belonging to other users.

6.3.28 SHMEM Privilege (Devour)
The SHMEM privilege allows the user's process to create and delete global
sections and mailboxes (permanent and temporary) in multiport memory, if
the process also has appropriate PRMGBL, PRMMBX, SYSGBL, and TMPMBX
privileges. Just as in local memory, the space required for a multiport memory
temporary mailbox counts against the buffered I/O byte count limit (BYTLM)
of the process.

6.3.29 SYSGBL Privilege (Files)
The SYSGBL privilege allows the user's process to create system global
sections by executing the Create and Map Section ($CRMPSC) system service.
In addition, the user with this privilege (plus the CMKRNL and PRMGBL
privileges) can use the Install Utility.
You should exercise caution in granting this privilege. System global sections
require space in the global section and global page tables, which are limited
resources.

6.3.30 SYSLCK Privilege (System)
The SYSLCK privilege allows the user's process to lock systemwide resources
with the Enqueue Lock Request ($ENQ) system service. You should grant
this privilege to users who need to run programs that lock resources in the
systemwide resource name space. You should exercise caution in granting
this privilege, since users who hold it can interfere with the synchronization
of system and other users' software.

6—16

Resource Control

6.3.31 SYSNAM Privilege (All)
The SYSNAM privilege allows the user's process to insert names in the
system logical name table and to delete names from that table by using the
Create Logical Name ($CRELNM) and Delete Logical Name ($DELLNM)
system services.
In addition, the user with this privilege can use the DCL commands ASSIGN
and DEFINE to add names to the system logical name table, and can use the
DEASSIGN command to delete names from the table.
You should grant this privilege only to the system operators or to system
programmers who need to define system logical names (such as names for
user devices, library directories, and the system directory). For example,
to mount or dismount a system volume, which entails defining a system
logical name, you must have the SYSNAM privilege. Note that a user with
the SYSNAM privilege could redefine such critical system logical names as
SYS$SYSTEM and SYSUAF, thus gaining control of the system.

6.3.32 SYSPRV Privilege (All)
The SYSPRV privilege allows the user to assume the file access rights of a
system user, and to change the owner UIC and protection of a file. Even if a
file is protected against SYSTEM access, the user with the SYSPRV privilege
can simply change the file's protection to gain access to it.
You should exercise caution in granting this privilege. If unqualified users
have SYSTEM access rights, the operating system and service to others can
easily be disrupted. Such disruptions can include failure of the system,
destruction of the database, and exposure of confidential information to
unauthorized persons.

6.3.33 TMPMBX Privilege (Normal)
The TMPMBX privilege allows the user's process to create a temporary
mailbox by executing the Create Mailbox and Assign Channel ($CREMBX)
system service.
Mailboxes are buffers in virtual memory that are treated as if they were
record-oriented I/O devices. A mailbox is used for general interprocess
communication. Unlike a permanent mailbox, which must be explicitly
deleted, a temporary mailbox is deleted automatically when it is no longer
referenced by any process. Note that this privilege is required to use the DCL
commands SUBMIT and PRINT.
You should usually grant this privilege to all users of the system to facilitate
interprocess communication. System performance is not likely to be degraded
by permitting the creation of temporary mailboxes, because their number is
controlled by limits on the use of system dynamic memory (BYTLM quota).

6-17

Resource Control

6.3.34 VOLPRO Privilege (Files)
The VOLPRO privilege allows the user to
•

Initialize a previously used volume with an owner UIC different from the
user's own UIC

•

Override the expiration date on a disk or disk volume he or she does not
own

•

Mount with the /FOREIGN qualifier a Files-11 volume he or she does not
own

•

Override the owner UIC protection of a volume

The VOLPRO privilege permits control only over volumes that the user can
mount or initialize. Volumes mounted with the /SYSTEM qualifier are safe
from the user with the VOLPRO privilege as long as the user does not also
have the SYSNAM privilege.
You should exercise extreme caution in granting the VOLPRO privilege. If
unqualified users can override volume protection, the operating system and
service to others can be disrupted. Such disruptions can include destruction
of the database and exposure of confidential information to unauthorized
persons.

6.3.35 WORLD Privilege (System)
The WORLD privilege allows the user's process to affect other processes both
inside and outside its group by executing the following process control system
services:
•

Cancel Wakeup ($CANWAK)

•

Delete Process ($DELPRC)

•

Force Exit ($FORCEX)

•

Resume Process ($RESUME)

•

Schedule Wakeup ($SCHDWK)

•

Set Priority ($SETPRI)

•

Suspend Process ($SUSPND)

•

Wake ($WAKE)

The user's process is also allowed to examine processes outside its own group
by executing the Get Job/Process Information ($GETJPI) system service. The
user with WORLD privilege can issue the DCL commands SET QUEUE,
DELETE/ENTRY, STOP/ENTRY, and SET PROCESS for all other processes.
To exercise control over subprocesses that it created or to examine these
subprocesses, a process needs no special privilege. To affect or to examine
other processes inside its own group, a process needs only the GROUP
privilege. But to affect or examine processes outside its own group, a process
needs WORLD privilege. You should normally grant this privilege to any
user who needs to affect other processes on a systemwide basis.

6-18

Resource Control

6.4

Accounting for the Use of System Resources
For accounting purposes, the VAX/VMS system keeps records of the use
of system resources. These records are kept in the accounting log file
SYS$MANAGER:ACCOUNTNG.DAT. This file is updated whenever
•

The system is initialized.

•

An accountable process or image terminates.

•

A print job is completed.

•

A login failure occurs.

In addition, users can send messages to be inserted in the accounting log file.
Privilege is required to suppress the accounting function and thus avoid
accounting for the use of system resources. Only a user who has the ACNT
privilege can create subprocesses or detached processes in which accounting
is disabled. The /NOACCOUNTING qualifier of the DCL command RUN
disables all accounting in a created process.
A user with the OPER privilege can selectively disable various kinds of
accounting throughout the system by using the /DISABLE qualifier of the
DCL command SET ACCOUNTING. Usually, this action is considered
a system management task. See the VAX/VMS DCL Dictionary for a full
description of the SET ACCOUNTING command.

6.4.1

Accounting Records
Accounting records contain cumulative accounts of the resources used either
by processes or images set up for users, or by print symbionts that print
out files for users. Each accounting record contains three fields—user
name, UIC, and account name—that identify the user and establish the
connection between the accounting record and a user of the system. These
fields correspond to similar fields of the user's account record in the user
authorization file (UAF).
As system manager, you can use the Accounting Utility to sort, select, and
report the accounting records. The reports can provide valuable system
management tools. (See the VAX/VMS Accounting Utility Reference Manual.)
Alternatively, by using the detailed accounting records provided by the
system, you or perhaps a system programmer can devise programs for
reporting on the use of system resources and for billing for their use.

6.4.2

Accounting Log File
The accounting log file is created and opened automatically when
the operating system is initialized. Accounting records are arranged
chronologically in this file. The following list summarizes the characteristics
of the accounting log file:
•

File name: ACCOUNTNG.DAT (this file is not an ASCII file; hence, it
must be formatted before it is printed)

•

Residence and directory: SYS$MANAGER

•

File organization: sequential

6-19

Resource Control

•

Record length: variable

•

Record types: eight

The eight types of records correspond to the conditions that cause records to
be written to the file. These record types are shown in the list that follows.
Note that their corresponding codes, as defined in the macro $ACRDEF in
SYS$LIBRARY:STARLET.MLB, are shown in parentheses:
•

Records written when processes are deleted (ACR$K_PRCDEL)

•

Records written when an image terminates (ACR$K_IMGDEL)

•

Records written when the system was initialized (ACR$K_SYSINIT)

•

Records written when print jobs are queued (ACR$K_PRINT)

•

Records written when login failures occurred (ACR$K_LOGFAIL)

•

Records written when users' messages are sent to the accounting log file
(ACR$K_USER)

•

Records that point to the next accounting file (ACR$K_FILE_FL)

•

Records that point to the previous accounting file, if any
(ACR$K —FILE _BL)

For more information about the records of the accounting log file, see the
VAX/VMS Accounting Utility Reference Manual.
As records are entered in the accounting log file, all but image termination
records are immediately flushed to disk. This precaution guarantees the
integrity of the file and the completeness of accounting data even if the
system fails.
Normally, the current version of the accounting log file is closed at the end
of a billing period, and a new version is created and opened. As a rule, you
perform this job with the SET ACCOUNTING command.
If an attempt to write to the accounting log file results in an error, the file is
closed automatically and a new copy is created and opened.

6-20

PART II Maintaining the System

Maintaining Public Files and Volumes

This chapter contains guidelines for setting up and maintaining public
files and volumes. It describes routine setup tasks such as initializing and
mounting public volumes. It also describes how to maintain volume integrity
(BACKUP) and manage disk space.
Public volumes, also called system volumes, are file-structured disk volumes
that contain public files. Such files must be available to most, if not all, users.
Public volumes can also contain files that users create for their own private
use or for general use. Thus, as long as UlC-based file protection permits it,
all users have access to public volumes and to the files on them.
Public volumes can contain the following kinds of public files supplied by
DIGITAL:
•

The operating system itself in executable form, and files related to the
operating system

•

Utility programs in executable form

•

Diagnostic and test programs in executable form, and files related to these
programs

•

Various system libraries such as macro libraries, object module libraries,
shared run-time libraries, and error message libraries

•

Text files such as help files

•

Optional software in executable form, plus related libraries and other files

In addition, you can include on public volumes files that are unique to an
installation, which must be accessible to many or all users.
Finally, you can permit any user to create and store files on a public volume.
As a rule, you create a default disk file directory on a public volume for each
user authorized to use the system (see Section 5). Depending on their file
protection, user files may be of general or restricted accessibility. Such use
of a public volume, however, is subject to limitation: a user is free to create,
write, and manipulate files on a public volume only if volume protection
permits, if the user has write access to a directory on the volume, and if disk
quota permits.

7.1

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.

7-1

Maintaining Public Files and Volumes

7.1.1

Storing 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. Secondary paging and swapping files can be placed on other
devices to balance disk activity load (see the SYSGEN commands CREATE
and INSTALL in the VAX/VMS System Generation Utility Reference Manual for
more information. 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 precautions with disk quotas and to ensure
that users' files do not exhaust the free space on the system disk. Note that
issuing the command SET DIRECTORY /VERSION _LIMIT=n is one way to
control the amount of disk space consumed.

7.1.2

Using Volume Sets
A volume set is a collection of disk volumes that have been bound into a
single entity, by the DCL command MOUNT/BIND. A volume set looks like
a single, large volume. Files are automatically allocated anywhere on the
volume set that space is available, disk quotas are enforced over the entire
set, 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.
If you intend to create database files that are larger than any single disk
volume, you must use a volume set. It is worth noting that the file system
attempts to balance the load on the volume set, 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. For example, you might want one
volume for permanent user storage, with carefully limited quotas and careful
backups; 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. Each separate volume or volume set must contain a top-level user file
directory for each user who will keep files on that volume.
An 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.
When a drive holding a single volume is not functioning, only a well-defined
set of files becomes unavailable.
For planning purposes, keep in mind the following:

7-2

•

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 types into the same volume set.

•

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

Maintaining Public Files and Volumes

•

You issue the MOUNT/BIND command only once to effect binding;
thereafter, the volume-set association is recorded on the volumes. (See the
VAX/VMS Mount Utility Reference Manual for more information.)

•

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 the Backup Utility (BACKUP).
(See the VAX/VMS Backup Utility Reference Manual for more information.)

Caution: DIGITAL recommends that you not make the system disk part of a
volume set. While the VAX/VMS system will continue to boot and run
successfully if you do this, optional product installations, maintenance
updates, and system upgrades will not install 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.

7.2

Formatting Disks
Disks that you purchase from DIGITAL are pre-formatted with a field service
diagnostic utility program. 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.

7.3

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 stores it so that the operating system can locate it easily.
When initializing a public volume, you must specify the /SYSTEM qualifier
with the DCL command INITIALIZE. You may also need to use one or more
of the following INITIALIZE qualifiers when initializing a public volume:
•

/ACCESSED=n

•

/CLUSTER_SIZE=n

•

/EXTENSIONS

•

/HEADERSs

•

/INDEX=position

•

/MAXIMUM _FILESs

•

/WINDOWS

As described below, selecting appropriate values for n and selecting the
appropriate position for the index file often involve making tradeoffs. The
following guidelines for initializing public volumes supplement information
presented in the VAX/VMS DCL Dictionary.

7-3

Maintaining Public Files and Volumes

/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
depending on 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 SYSGEN parameter ACP_
DINDXCACHE 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.

/CLUSTER-SIZE Qualifier
The /CLUSTER-SIZE qualifier specifies the fundamental unit of allocation
(expressed in blocks) on a volume. In selecting the cluster size, you trade off
wasted space at the ends of files 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).

/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. However, an overly conservative estimation of file-header space can
also cause excessive disk-head motion.

/INDEX Qualifier
The /INDEX qualifier specifies the location of the index file on a volume.
The default position (MIDDLE) results in minimum 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.

/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.

/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 intervention.

7—4

Maintaining Public Files and Volumes

7.4

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 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 /SYSTEM qualifier to the DCL
command MOUNT), you may need to use one or more of the qualifiers
/ACCESSED, /EXTENSION, and /WINDOW (described in Section 7.3), or
the following additional qualifiers:
•

/[NO]ASSIST

•

/COMMENT=text

•

/[NO]MOUNT_VERIFICATION

•

/CLUSTER

The following guidelines supplement information presented in the VAX/VMS
DCL Dictionary.

/[NO]ASSIST Qualifier
The /[NOJASSIST qualifier enables or disables the operator-assisted mount
feature. By default, this feature is enabled. You should encourage your users
to take advantage of this feature, which repeatedly alerts the operator of your
request until the request is satisfied.
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 is that the absence of some
system volume normally mounted during SYSTARTUP.COM could 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; be prepared for the following consequences,
however, 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.

•

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, reboot the system using a conversational
bootstrap procedure, and enter the following command at the SYSBOOT>
prompt:
SYSBOOT> SET STARTUP.Pl "MIN"

This command initiates a minimum startup procedure as described in
Section 4.

7-5

Maintaining Public Files and Volumes

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

/[NO]MOUNT_VERIFICATION Qualifier
The /[NO]MOUNT_VERIFICATION qualifier enables or disables the mount
verification feature on Files-11 disks. By default, the mount verification
feature is enabled. If a device goes offline, mount verification will not abort
requests, but instead will retain pending requests in a queue. However, note
that this feature has no effect on foreign disks or magnetic tapes. This feature
is explained in Section 7.6.

/CLUSTER Qualifier
The /CLUSTER qualifier specifies that after the volume is successfully
mounted on the local node, or if it is already mounted /SYSTEM on the local
node, it is to be mounted on every other node in the existing VAXcluster. See
the Guide to VAXclusters for more information on mounting clusterwide disk
volumes.
Note: You can monitor Files-11 ACP performance with the MONITOR FCP
command of the Monitor Utility. (See the VAX/VMS Monitor Utility
Reference Manual.) The information MONITOR provides can help you
determine how to configure your file system.

7.4.1

Preparing Disk and Magnetic Tape 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 or
an operator may be called upon to assist them. (In most cases, an operator
performs the tasks described in this section and Section 7.4.2.) The following
are some of the reasons why users may require assistance:
•

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

•

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

•

A system or public disk needs to be mounted by the operator or system
manager, because most users do not have sufficient privileges.

Users normally communicate with an operator to gain access to volumes, and
the operator performs one or more of the following tasks:
•

Physically mounts the volume on the device. Physically mounting a
volume means placing it on a specific drive and starting the drive. For
tape drives, the operator loads the tape into the drive and then presses the
LOAD button to start the drive. For disk drives, the operator places the
disk in the disk drive and then presses the START or RUN button to start
the drive.
Initializes new volumes, using the INITIALIZE command.
Mounts the volume, using the MOUNT command.

7-6

Maintaining Public Files and Volumes

If it is not necessary to initialize the disk, users can issue a single MOUNT
command to allocate the device and request assistance as necessary. For
example, a user might enter the DCL command MOUNT to issue the mount
request; or MOUNT/COMMENT to also send to the operator's terminal
a message specifying the name of the device allocated, the volume to be
mounted, the physical identification on the outside of the volume, and
its location. (For a complete description of the MOUNT command and
qualifiers, refer to the description of the Mount Utility (MOUNT) in the
VAX/VMS Mount Utility Reference Manual.) The user then waits until the
system responds with a message indicating that the volume is mounted.
Examples of allocating devices and initializing and mounting volumes
are provided in the VAX/VMS DCL Dictionary under the ALLOCATE,
INITIALIZE, and MOUNT commands.
For more information on handling magnetic tape volumes, see the Guide to
VAX/VMS Disk and Magnetic Tape Operations. You should also consult that
manual for information on requests and notifications concerning the mounting
and dismounting of disk and magnetic tape volumes.

7.4.2

Responding to Mount Requests from Users
When a user requests that a specific disk or magnetic tape be mounted
on a device, the following message format is displayed by the operator
communication process (OPCOM) on the operator terminal:
xmxxmxx OPCOM, dd: mmm: y y y y: hh: mm: s s : c c
request 'request-ia,' from user 'USERNAME'

yX/X/X/X/M

For example, a user requesting that the volume TEST-FILES be mounted on
the device DMA2: could issue the following command:
$ MOUNT DMA2: TEST_FILES/COMMENT="Shelf slot 6B"

This command notifies the operator by displaying at the operator terminal a
message similar to the following:

yx/x/x/xm

OPCOM, 15-APR-19S6 15:47:50.26
request 5, from user MALCOLM
Please mount volume TEST.FILES in aevice _DMA2:
Shelf slot 6B

The user receives a message indicating that the operator has received the
request:
'/.MOUNT-I-OPRQST, Please mount volume TEST.FILES in aevice _DMA2:
Shelf slot 6B

Besides requesting a specific device for mounting a volume, the user can make
a generic MOUNT request by specifying a device type. To mount the volume
CITIES on a magnetic tape drive whose name begins with MT, for example,
the user would issue the following command:
$ MOUNT MT:

CITIES/COMMENT="Slot 12c"

If the user has already allocated a drive whose name begins with MT, the
Mount Utility will request that CITIES be mounted on that particular drive.
If the user has not allocated a drive whose name begins with MT, the utility
will allocate the first available TE16, TU45, or TU77 tape drive it finds, and
issue a request to mount CITIES on that drive.

7—7

Maintaining Public Files and Volumes

To respond to user requests for mounting volumes, the operator proceeds as
follows:
1

Places the volume on the specified device. After the operator has located
the physical volume and placed it on the device, the user receives
messages similar to the following:
•/.MOUNT-1-MOUNTED, TEST.FILES mounted on _DMA2:
AMOUNT-I-RQSTDON, operator request canceled.

Performs the necessary startup procedure. On disk drives, the startup
procedure requires pressing the START or RUN button; on magnetic tape
drives, it requires pressing the LOAD button.

If the user intends to write to a magnetic tape volume to be mounted, the
operator verifies that the magnetic tape contains a write ring before loading
the volume on the drive. A volume that does not contain a write ring is
write-locked and thus cannot be accessed for write operations.
If the user wants a particular disk to be checked for bad blocks, the operator
verifies that the volume has been mounted with the /FOREIGN qualifier. For
information on how to invoke and use the Bad Block Locator Utility (BAD),
see the VAX/VMS Bad Block Locator Utility Reference Manual.
For more information on the user's role in mounting volumes, see the Guide
to VAX/VMS Disk and Magnetic Tape Operations.

7.5

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 the discussion of SYSGEN in the VAX/VMS System Generation
Utility Reference Manual). Individual users can alter cache sizes on their
volumes with qualifiers of the DCL command MOUNT (see the VAX/VMS
DCL Dictionary). 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, neither you nor the individual user
should
•

Write lock a volume while it is mounted

•

Remove a volume from a drive until it has been dismounted

•

Halt the system without performing an orderly shutdown procedure (see
Section 4)

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 7.6.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.)

7-8

Maintaining Public Files and Volumes

At mount time, if the system detects that the caches were not written back
the last time the volume was used, the system automatically rebuilds the file
information by scanning the contents of the volume. However, file headers
for files open at the time of the improper dismount may be partially or wholly
lost.

7.6

Mount Verification
The mount verification feature of Files-11 disk handling generally leaves
users unaware that a mounted disk has gone off line and returned on line
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 OP AO. For example, if the system disk undergoes
a mount verification or if OPCOM 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.

7.6.1

Device Offline Mount Verification
Mount verification is initiated under the following conditions:
•

A disk volume is taken off line (for example, it might be spun down)
because of a hardware or user error. Most disk drives generate a special
interrupt when the volume comes back on line, which causes the software
to mark the volume as invalid. However, some disk drives (such as the
RX01, RX02, RL02) 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 then issues a message to the operators enabled for DISKS and
DEVICES to announce the disk's unavailability, in the following format:

nmnun OPCOM. dd-mmm-yyyy hh:mm: ss .cc
Device 'device-name' is offline.
Mount verification in progress.

If a mounted disk volume goes offline while mount verification is enabled,
you can act as follows to resume operations:
1

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 7.6.3. These techniques cause any pending or future I/O
operations to the volume to fail.

7-9

Maintaining Public Files and Volumes

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.

When the disk comes back on line, and is detected by the mount verification
software that polls the disk drive, the system verifies that the disk's home
block matches the one in the database of mounted volumes, thus confirming
that this is the same disk as previously mounted.
If the drive contains the wrong volume, OPCOM issues a message in the
following format:
XXXXXXXXXXX OPCOM, dd-mmin-yyyy hh:mm:ss.cc XXXXXXXXXXX
Device 'device-name' contains the wrong volume.
Mount verification in progress.

After the mount verification succeeds, the disk is marked as valid. OPCOM
issues the following message:
XXXXXXXXXXX OPCOM, dd-mmm-yyyy hh:mm:ss.cc XXXXXXXXXXX
Mount verification completed for device 'device-name.'

At this point I/O operations to the disk are allowed to proceed, as shown in
the following example:
XXXXXXXXXXX OPCOM,

15-APR-i986 11:54:54.12
Device DMAO: is offline.
Mount verification in progress.

XXXXXXXXXXX

XXXXXXXXXXX OPCOM.

lS-APR-lQSe 11:57:34.22 XXXXXXXXXXX
Mount verification completed for device DMAO:.

In this example, the message from OPCOM informs the operator that device
DMAO has gone offline and mount verification has been initiated. The
operator finds that 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 on line
again), and all I/O operations to the volume resume.

7.6.2

Device Write-Lock Mount Verification
Devices may become write locked under the following conditions:
•

A hardware or user error occurs while a Files-11 disk volume is mounted
for writing (the /WRITE qualifier is the default).

•

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:
XXXXXXXXXXXX OPCOM. dd-mmm-yyyy hh:mm:ss.cc %%%%%%%%%%%
Device 'device-name' has been write locked.
Mount verification in progress.
If for some reason a mounted disk volume becomes write locked while mount
verification is enabled, you can act as follows to resume operations:
1

7—10

Take the disk out of the verification pending state by shutting down
mount verification with one of the techniques described in Section 7.6.3.
These techniques cause the pending and future I/O operations to the
volume to fail.

Maintaining Public Files and Volumes

Enable the drive for writing by toggling the drive's hardware WRITE
LOCK switch.

3 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. Once that completes, the
write-lock mount verification continues.)
When the mount verification software that polls the disk drive determines
that the volume is in a writeable state, 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. Instead, OPCOM issues a
message in the following format to alert the operator that the device is write
locked:
%%%%%%%%%%% OPCOM, dd-mmm-yyyy hh:mm: ss . cc ’/.'/.'/.'/.'/.*/.'/.'/.'/.'/.*/.
Device 'device-name' has been write locked.
Mount verification in progress.

You can toggle the WRITE LOCK switch on the drive to eliminate the write
lock condition. I/O operations to the disk resume, with no further messages.

7.6.3

Canceling Mount Verification
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 canceling routine from the console terminal.

3 Dismount the volume with the DCL command DISMOUNT from a process
that is not hung.
These methods are discussed in the following sections.

7.6.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
canceled (see the discussion of SYSGEN in the VAX/VMS System Generation
Utility Reference Manual). This dynamic parameter should always be set to a
reasonable value for the typical operations at your site. (See Section 11 for
instructions on how to display and modify dynamic system parameters with
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 canceled by timing out, OPCOM prints
a message in the following format:
mmmn OPCOM, dd-mmm-yyyy hh:mm:ss.cc ’/.'/.7.’/.'/.'/.'/.'/.'/.7.7.
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, the disk must be dismounted and remounted
before it can be accessed again.

7-11

Maintaining Public Files and Volumes

Note that a write-lock mount verification will not time out.

7.6.3.2

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 processor:
[CTRLVP]
»>HALT
»>D/I 14 C
»>CONT
IPO

While you are at the IPO prompt, all system operation is suspended. (Press
CTRL/Z when you are ready to exit.)
Note the following special characteristics of the mount verification canceling
routine:
•

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; that is, all space
characters after the first are ignored.

There are four commands you can enter in response to the IPO prompt:
IPC> C device-name

This command cancels any pending mount verification on the device
specified. (A warning is given if no mount verification was in progress for
that device.)
IPC> x

This command transfers control to the debugging tool XDELTA (provided
it was loaded with the system by setting the appropriate value in the
bootstrap file). If XDELTA has not been loaded, the prompt IPO is
reissued. XDELTA, which is described in the VAX/VMS Delta/XDelta
Utility Reference Manual, may prove especially useful if you are debugging
privileged software on a VAX-11/782 attached processor system.
IPO q

This command recalculates the quorum on a cluster (applies to cluster
environment only).
IPO CTRL/Z

Press CTRL/Z to exit from the mount verification canceling routine and
resume system operation.
When a pending mount verification is canceled, OPCOM prints a message in
the following format:
mmnm OPCOM, dd-mmm-yyyy hh:mm:ss.cc VX/X/X/X/X/.
Mount verification aborted for device 'device-name.'

7-12

Maintaining Public Files and Volumes

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, as shown in the following example:
mnmm OPCOM, 15-JUN-1986 10:54:54.12
Device DBAO: is offline.
Mount verification in progress.
1 CTRL/P 1
»>HALT
>»D/I 14 C
»>C0NT
IPC>C DBAO
IPC>~Z
’/.SYSTEM-1-MOUNTVER, _DBA0: has aborted mount verification,
mmmn OPCOM, 15-JUN-1986 10:56:26.13
Mount verification aborted for device DBAO:

In this example, you observe that device DBAO is off line, but are 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. You also
reject the possibility of issuing a DISMOUNT command for the disk, because
it was mounted as a private volume.
Rather than wait ten minutes for the mount verification to time out, you
can invoke the cancellation commands at the console terminal. Observe that
the %SYSTEM-I-MOUNTVER message also appears here because this is the
console terminal.

7.6.3.3

Dismounting the Volume
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. To do so, follow these steps:
1

2 Enter the DISMOUNT/ABORT command for the volume.
3 When you cancel a pending mount verification by dismounting the
volume, OPCOM issues a message in the following format:

%%%%%%%%%%%

mmmm OPCOM. dd-mmm-yyyy hh:mm: as .cc .
Mount verification aborted for device 'device-name.'

If you do not have access to the volume, 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, and you
cannot use this technique to cancel mount verification.

4 Once the cancellation succeeds, remove the volume from the drive.

7-13

Maintaining Public Files and Volumes

7.7

Backing Up Public Volumes
This section provides system management procedures and considerations for
backing up public files and volumes. Backing up a volume means copying
the contents of the volume to another volume or set of volumes (for example,
another disk or magnetic tape). It 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.
It is just as desirable to back up private volumes as public. However,
responsibility for backing up the files on private volumes usually is left to
the individual owners of those files and volumes. The Guide to VAX/VMS
Disk and Magnetic Tape Operations provides a comprehensive introduction to
the use of the Backup Utility, including detailed information about backup
media and tasks.
There are two kinds of backups for public disk files and volumes:
•

Incremental (or partial). Rather than save all the files on a volume every
time a save is performed, it is more time efficient to save only those files
that were created or modified since the last save operation. This type of
selective backup is termed an incremental backup. Incremental backups are
described in Section 7.7.4.

•

Full (or all-inclusive).

The backup medium, in either case, can be disk or magnetic tape. Incremental
backups efficiently capture only those files that have been modified since the
last full backup. Periodic full backups are necessary to provide the basis for
reconstruction of a lost volume.
As a rule, incremental backups are performed more frequently than full
backups. You should decide, after consulting with users of the system, how
frequently to back up files and volumes and how long to retain backup media.
Generally, you are responsible for setting up a schedule for backing up files
and volumes and for maintaining this schedule.
The following schedule for backing up public disk volumes on magnetic tape
affords adequate protection of data for many installations:
•

Daily—An incremental backup retained for 7 days. This schedule requires
7 daily magnetic tape-sets that are rotated on a weekly basis.

•

Weekly—An incremental backup retained for 4 weeks. This schedule
requires 4 weekly sets of magnetic tapes that are rotated every 4 weeks.

•

Monthly—An all-inclusive backup retained for a year. This schedule
requires 12 monthly sets of magnetic tapes that are rotated annually.

Despite all precautions, there is always the risk of losing a file. Frequent
backups and longer retention periods reduce this risk.
You can perform full backups either to magnetic tape or to another disk.
Each has its advantages and disadvantages. The advantage of using magnetic
tape for backups is the much lower media cost. The lower cost may in turn
permit you to retain backups longer than you would if you were keeping full
backups on disk.

7—14

Maintaining Public Files and Volumes

There are several advantages to keeping backups on disk, which in some
cases outweigh the higher cost of disk media:
•

Disks exhibit better data reliability.

•

Disks tend to degrade more slowly in storage.

•

If you have to restore data from its backup medium, a disk backup volume
can be ready for immediate use, whereas you must first restore a magnetic
tape to disk.

•

If you use disks for your backups, you can make use of a "rotating backup
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.

The remainder of this section describes backup tasks that are oriented toward
system management; it is intended as a guide to aid system managers in
maintaining the integrity of public files and volumes in a typical operating
system environment. It does not, however, include standalone BACKUP.
For specific instructions on running standalone BACKUP (including steps for
backing up and restoring the system disk), see Section 2.
You should refer to the VAX/VMS Backup Utility Reference Manual for
complete information on the VAX/VMS Backup Utility and its qualifiers.
For a detailed approach to the use of BACKUP media and tasks, refer to the
Guide to VAX/VMS Disk and Magnetic Tape Operations.

7.7.1

Rotating Backup Sets
A rotating backup set on disk offers two major advantages:
1

Your backup 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 backup 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.

The disadvantages to a rotating backup set are as follows:
1

Rotating backup 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.

Files created with explicit placement lose their placement when the
volume is copied. You should therefore not use a rotating backup set
if the volume's primary contents are a set of database files that were
carefully placed for optimized performance.

Rotating backup sets are expensive to apply to fixed-media disks (as
opposed to removable media).

7-15

Maintaining Public Files and Volumes

7.7.2

Backing Up Full Volumes and Volume Sets
If you want to back up an entire disk volume or volume set, you should
use the /IMAGE qualifier of the Backup Utility. You can perform an image
backup in a copy operation (disk to disk) or in a save operation (to disk or
magnetic tape). When you use the /IMAGE qualifier in a save operation,
BACKUP creates a save set that contains data necessary for reinitializing the
disk volume. (The attribute record that contains this information is called the
save-volume summary record.)
When you use the /IMAGE qualifier in a copy or restore operation, the output
volume is reinitialized; the restored volume is a functionally equivalent copy
of the original volume. If the output volume has already been initialized as a
Files-11 volume, you can use the /NOINITIALIZE qualifier to reinitialize the
volume using the volume initialization parameters found on the volume.
You cannot use other file selection qualifiers with the /IMAGE command
qualifier. All files on the disk are saved, including reserved files and lost files
(files that have no directory entry).
You should specify the /RECORD qualifier if you are performing the full
volume backup in conjunction with incremental backups that use the
/RECORD qualifier. This is because the /RECORD qualifier causes the
Backup Utility to write the date and time of the backup into the file header.
Subsequently, if you specify the /SINCE=BACKUP qualifier the next BACKUP
will only copy those files created or modified since the recorded date and
time.
You can back up an entire volume set by following the same procedures
outlined in the next section for backing up a disk volume. Simply name the
device on which the root volume (volume number 1) is mounted.

7.7.2.1

Backing Up a Public Disk to Disk
The procedure below describes how to copy the contents of a public disk
to another disk. (A public disk is a disk that has been mounted with the
/SYSTEM qualifier.)
You should make certain that your target volume has sufficient free space.
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.
1

Issue the following command to warn all users that the disk will be
dismounted and write-locked for backup:
$ REPLY/ALL/BELL "message-text"

This message should include the name of the source disk being writelocked 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; then broadcast messages to users who have open
files, as necessary.

3 At the time indicated by the message, issue the DISMOUNT
/NOUNLOAD command to logically dismount the source disk as follows:
* DISMOUNT/NOUNLOAD device-name:

7-16

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.

Maintaining Public Files and Volumes

5 Mount the source disk again as follows:
$ MOUNT/SYSTEM device-name: volume-label

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

7 Mount the target volume as follows:
$ MOUNT/FOREIGN device-name:

Invoke the Backup Utility as follows:
$ BACKUP/IMAGE/VERIFY input-device:

output-device:

If BACKUP returns any error messages, refer to the VAX/VMS System
Messages and Recovery Procedures Reference Manual.
9

Dismount the target volume with the following command:
$ DISMOUNT device-name:

10 Remove the target volume from the drive and place a label on the outside
of the volume; the label should include the volume label and current date.
11 Dismount the source disk by issuing the DISMOUNT/NOUNLOAD
command as follows:
$ DISMOUNT/NOUNLOAD device-name:

1 2 Write enable the source disk by pressing the WRITE PROTECT switch to
the OFF position.
1 3 Remount the source disk with the MOUNT command as follows:
$ MOUNT/SYSTEM device-name: volume-label

14 Inform all users that the source disk is no longer write-locked by issuing
the following command:
$ REPLY/ALL/BELL "message-text"

The following example illustrates these procedures:
$ REPLY/ALL/BELL "DMA2: WILL BE WRITE-LOCKED IN 5 MINS. FOR BACKUP."
Reply received on N0DE1 from SYSTEM at N0DE1.0PA0: 06:31:29
DMA2:
WILL BE WRITE-LOCKED IN 5 MINS. FOR BACKUP.
$ SHOW DEVICE/FILES DMA2:

$ DISMOUNT/NOUNLOAD DMA2:
$ MOUNT/SYSTEM DMA2: PUBLIC
7.M0UNT-I-WRITEL0CK, volume is write-locked
‘/.MOUNT-1-MOUNTED, PUBLIC
mounted on _DMA2 :
$ MOUNT/FOREIGN DMA1:
‘/.MOUNT-1-MOUNTED, PUBLIC
mounted on _DMA1:
$ BACKUP/IMAGE/VERIFY DMA2: DMA1:
•/.BACKUP-1-STARTVERIFY, starting verification pass
$ DISMOUNT DMA1:
$ DISMOUNT/NOUNLOAD DMA2:
$ MOUNT/SYSTEM DMA2: PUBLIC
‘/.MOUNT-1-MOUNTED, PUBLIC
mounted on _DMA2:
$ REPLY/ALL/BELL "DMA2: IS NO LONGER WRITE-LOCKED."
Reply received on N0DE1 from SYSTEM at NODEl.OPAO: 06:46:44
DMA2: IS NO LONGER WRITE-LOCKED.

7-17

Maintaining Public Files and Volumes

You can use BACKUP either to copy files to the new disk or to create a save
set on the new disk. If you create a save set on the new disk, you must first
create a directory to which the save set will be written and you must use the
/SAVE_SET output qualifier. The directory must be included in the save-set
name or it must be the default directory.
For example:
$ SHOW DEFAULT
DMA1:[SYSTEM]
$ BACKUP/IMAGE DMA1: DB4: [BACKUPS]21JANDMA1.BCK/SAVE.SET

7.7.2.2

Backing Up a Public Disk to Magnetic Tape
If you use magnetic tape as the backup medium, you may need to mount
additional magnetic tapes. The number depends on the size of the disk being
saved and the amount of space in use on the disk.
An image backup operation to magnetic tape always creates a save set;
therefore, you need not include the /SAVE—SET output qualifier. To perform
the operation, you should follow the steps given in Section 7.7.2.1 for backing
up to disk. However, if you are using a fresh magnetic tape, you should
initialize it by including the /REWIND qualifier with the BACKUP command.
For example:
$ BACKUP/IMAGE/VERIFY/REWIND DRA1:

7.7.2.3

MTAO:1JUN.BCK

Backing Up a Disk Volume Set When Drives Are Limited
When you use BACKUP with a volume set, you must mount all volumes
of the set. Therefore, 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.
For example:
$ REPLY/ALL/BELL "DRAO:, DRA1:, AND DRA2: VOLUME SET WILL BE _$ WRITE-LOCKED IN 5 MINS. FOR BACKUP."
Reply received on N0DE1 from SYSTEM at N0DE1.0PA0: 06:31:29
DRAO:, DRA1:, AND DRA2: VOLUME SET WILL BE WRITE-LOCKED IN 5 MINS. FOR BACKUP.
$ DISMOUNT/NOUNLOAD DRAO:
$ MOUNT/SYSTEM/NOWRITE DRAO:.DRA1:,DRA2: PUBLIC01,PUBLIC02,PUBLIC03
AMOUNT-I-MOUNTED, PUBLIC01 mounted on .DRAO:
‘/.MOUNT-I-MOUNTED, PUBLIC02 mounted on _DRA1:
AMOUNT-I-MOUNTED. PUBLIC03 mounted on _DRA2:
$ MOUNT/FOREIGN DRA3:
•/.MOUNT-1-MOUNTED. SCRATCH01 mounted on _DRA3:
$ BACKUP/IMAGE/V0LUME=1 DRAO: DRA3:
$ DISMOUNT DRA3:
$ MOUNT/FOREIGN DRA3:
%M0UNT-I-MOUNTED, SCRATCH02 mounted on _DRA3:
$ BACKUP/IMAGE/VOLUMES DRAO: DRA3:
$ DISMOUNT DRA3:
$ MOUNT/FOREIGN DRA3:
AMOUNT-I-MOUNTED. SCRATCH03 mounted on _DRA3:
$ BACKUP/IMAGE/V0LUME=3 DRAO: DRA3:
$ DISMOUNT DRA3:
$ DISMOUNT/NOUNLOAD DRAO:

7-18

Maintaining Public Files and Volumes

$ MOUNT/SYSTEM DRAO:,DRA1:,DRA2: PUBLICOl,PUBLIC02,PUBLIC03
‘/.MOUNT-1-MOUNTED, PUBLICOl mounted on _DRAO:
'/MOUNT -1 -MOUNTED, PUBLIC02 mounted on _DRA1:
•/.MOUNT-1-MOUNTED, PUBLIC03 mounted on _DRA2:
$ REPLY/ALL/BELL "DRAO:, DRA1:, AND DRA2: VOLUME SET IS NO LONGER _$ WRITE-LOCKED "
Reply received on N0DE1 from SYSTEM at NODEl.OPAO: 06:46:44
DRAO:, DRA1:, AND DRA2: VOLUME SET IS NO LONGER WRITE-LOCKED.

In this example, the operator needs to back up a three-volume set. Thus,
at least four drives are required. The operator warns the users that drives
DRAO, DRA1, and DRA2 are about to be write-locked for backups. Next the
operator issues MOUNT commands for the volumes PUBLICOl, PUBLIC02,
and PUBLIC03 on drives DRAO, DRA1, 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 writing on the volume set again, the operator dismounts (but does not
unload) DRAO, and 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.
Note: Dismounting the public volume set, remounting write-locked, and so
forth, are critical to the success of the operation. Do not simply write lock
a mounted volume; doing so is likely to cause errors and/or suspension of
system activity.

7.7.2.4

Writing Save Sets on Sequential-Disk Volumes
As an alternative to standard Files-11 structure, you can write save sets to
disk sequentially, as they would be written on magnetic tape. The primary
advantage in using sequential-disk save sets is that you can treat the disk
volume as you would a magnetic tape save set; this flexibility allows you to
mount multivolume save sets one volume at a time.
To save data to a sequential-disk save set, make certain that the output
specifier includes a device name for a disk device, a save-set name, and the
qualifier /SAVE_SET; do not include a directory name.
To write sequential-disk save sets, you must mount the output disk with the
/FOREIGN qualifier. Although the volume is mounted foreign, BACKUP
manages the disk using Files-11 structure.
Volumes that are to be used for sequential-disk save sets either should be
freshly initialized or should contain only save sets. Volumes that have been
used for general file processing are usually unsuitable for sequential-disk use.
You can initialize the volume by using the BACKUP qualifier /INITIALIZE.
Note that unless you use the /INITIALIZE qualifier, the following restrictions
apply to the output volume:
•

The disk must be Files-11 Structure Level 2.

•

The disk must not be part of a normal Files-11 volume set.

•

The cluster factor of the disk must be 1.

•

The free space on the disk cannot be fragmented into more than 100
contiguous extents.

•

The index file cannot be extended.

7-19

Maintaining Public Files and Volumes

•

The master file directory (MFD) cannot be extended.

For example, you can use the following commands to mount and initialize
a sequential disk on drive DMAO and write the file CONTRACTS.DAT to a
save set named CONTRACTS.BCK:
$ MOUNT/FOREIGN DMAO:
$ BACKUP/LOG CONTRACTS.DAT DMAO:CONTRACTS.BCK _$ /SAVE_SET/INITIALIZE/LABEL=SAVEWORK
y.BACKUP-S-COPIED, copied DBA2 : [USER] CONTRACTS . DAT; 1

The MOUNT/FOREIGN command tells BACKUP to write to the output
volume sequentially. The /SAVE_SET qualifier on the BACKUP command
output specifier is necessary for writing the output file in BACKUP format.
The /INITIALIZE qualifier destroys any previous structure information on
the disk, enables the volume to be overwritten, and assigns the volume label
SAVEWORK.
When you initialize the volume, the volume label you specify is permanent;
that is, the label remains in effect until either of the following takes place:
•

You change it with the DCL command SET VOLUME/LABEL.

•

The volume is reinitialized.

See the VAX/VMS Backup Utility Reference Manual for more information
on BACKUP/INITIALIZE. See the VAX/VMS DCL Dictionary for more
information on SET VOLUME.

Writing Multivolume Sequential-Disk Save Sets
You may find the multi volume option particularly useful if your system has
no tape drive but does have a large fixed-media disk and a small removable
disk. When one sequential disk is full, BACKUP prompts you for another
disk, as it would for save sets on magnetic tape. The following example
demonstrates how you can use more than one disk device at a time to save or
restore data:
$ BACKUP DLAO:[000000]SAVE.BCK/SAVE,DLA2: DRA2:

In this example, processing is continued on disk DLA2:, while disk DLAO:
is spinning down. Note that you need the user privilege LOG—IO to read
or write a multivolume sequential-disk save set. See the VAX/VMS Backup
Utility Reference Manual for more information.
BACKUP normally does not initialize the first sequential-disk volume, as
the default is /NOINITIALIZE; however, continuation volumes are always
initialized. You can initialize the first volume of a sequential-disk save set by
specifying the /INITIALIZE qualifier.
Note: A set of disks written with BACKUP'S sequential-disk handling is
referred to as a loosely coupled volume set. That is, it lacks 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.

7-20

Maintaining Public Files and Volumes

7.7.3

Performing Selective Backups
You may find selective backups necessary for certain groups of files that
require special treatment. Generally, if files must be backed up regularly,
you should create a command procedure that contains the required backup
commands. (For more information on creating command procedures, see the
Guide to Using DCL and Command Procedures on VAX/VMS.)
One way to perform selective backups is through the use of wildcards. You
can use the asterisk wildcard (*) to select files by file name, file type, or
version number. The command in the following example selects files by
version number and copies them to the directory [SAVE] on a specified RK07
drive:
$ BACKUP/LOG * . * ; 3
•/.BACKUP-S-CREATED,
•/.BACKUP-S-CREATED,
•/.BACKUP-S-CREATED,
7.BACKUP-S-CREATED,

DMA1:[SAVE]
created DMA1: [SAVE] CHARTS .DAT;3
created DMA1: [SAVE] FIGURES . DAT; 3
created DMA1: [SAVE]LISTS.DAT;3
created DMA 1: [SAVE] TABLES . DAT; 3

The commands in the next example copy files from a directory and a directory
tree on DMAO: to newly created directories on DMA1:. All files in the
[GEORGE] directory and its subdirectories on the source disk are copied to
directories with the same names on the target volume; the
/OWNER_UIC=ORIGINAL qualifier ensures that the output files retain the
owner UICs of the input files. All files with the file name DUNGEON in the
[SYSEXE] directory on the source disk are copied to the [SYSEXE] directory on
the target volume.
$ BACKUP DMAO:[GEORGE...]
DMA1:[*...]/OWNER_UIC=ORIGINAL
$ BACKUP DMAO:[SYSEXE]DUNGEON.*;* DMA1:[SYSEXE]

BACKUP has qualifiers that allow you to select files according to criteria such
as UIC, creation date, expiration date, and modification date. For example,
you can select files according to UIC by using the /OWNER_UIC qualifier as
follows:
$ BACKUP/LOG [.MEM]/0WNER_UIC=[300, 16] $1$DLA2:[USER]
•/.BACKUP■ S-CREATED, created $1$DLA2 [USER]ASSIGN.LIS;1
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]BBALL.DIS;19
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]BBLEAGUE.FISTATEMENT;1
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]BRULES.LIS;1
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]GYM.MAI;1
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]INF0.DAT;2
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]MEMO.MAI;1
'/.BACKUP- S-CREATED, created $1$DLA2 [USER]NEWS.MAI;1
•/.BACKUP- S-CREATED, created $1$DLA2 [USER]TEAM.LIS;19

In this example, all files residing in the subdirectory [.MEM] with an owner
UIC of [300,16] are processed. Note that the brackets are required when you
specify the UIC code. You can specify the UIC of the current default process
by simply entering the /OWNER_UIC qualifier without a code.
If you want to select your input files according to their date of creation, you
can use the /CREATED qualifier with /BEFORE or /SINCE. The following
command copies all files in the directory [TRUBBLE] that were created on or
since April 3, 1986:
$ BACKUP DMAl:[TRUBBLE]*/SINCEss03-APR-1986/CREATED DBA2:[SPRS]

You can use the /EXPIRED qualifier with /SINCE or /BEFORE to select files
according to the expiration date recorded in the file header:
$ BACKUP *.COB;*/BEF0RE=2O-JUL-1986:/EXPIRED MFAO:JUL20SAVE.BCK

7-21

Maintaining Public Files and Volumes

In this example, all versions of all files in the current default directory that
have a file type of COB and an expiration date earlier than July 20, 1986, will
be saved to JUL20SAVE.BCK on MFAO:.
In some cases, you may find it more practical to exclude certain files from a
backup operation. You can do this as in the following example:
$ BACKUP DBA2:[OSCAR...]/EXCLUDE*(*.LOG;*,NOTES.*;*) MTA1:SAVE.BCK

This command directs BACKUP to save all the files in the directory [OSCAR]
and its subdirectories, except for those with a file type of LOG and those
with the file name NOTES, regardless of file type or version number.
The parentheses are required when a list is specified with the /EXCLUDE
qualifier.

7.7.4

Performing Incremental Backups
To perform incremental backups, 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 backup date field of each file's
header.
For example:
$ BACKUP/RECORD DB2:[*...]/SINCE=BACKUP MTAO:190CT.BCK

To use the /RECORD command qualifier, you must own the files or have the
user privilege SYSPRV.
Note: If you use the /RECORD command qualifier to perform incremental
backups on disk volumes, it is a good idea to discourage its use by other
users. Incomplete backups will occur if other users perform backups
using the /RECORD command qualifier.
The drawback to performing incremental backups is that you accumulate a
large number of magnetic tape or disk volumes containing the incremental
save sets.

7.7.5

Performing Daily Backups
In performing daily backups, you should follow the suggestions in
Section 7.7.4 for incremental backups, but you may want to include
the /IGNORE=INTERLOCK qualifier. This qualifier instructs BACKUP
to copy files even if they are open for writing; this means that you
may produce a copy of a file in its partial state. If you do not use the
/IGNORE=INTERLOCK qualifier, an open file will generate an error
message and will not be backed up. The file will not be saved until the
next incremental backup.
You may find the /IGNORE=INTERLOCK qualifier especially useful if you
have files that are always open (and would never be backed up otherwise).
For example:
$ MOUNT/FOREIGN MTAO:
‘/.MOUNT-1-MOUNTED. INCD5J mounted on _MTA0:
$ BACKUP/IGN0RE=INTERLOCK/RECORD/SINCE=BACKUP _$ PUBLIC: [*...] MTAO:INCD12JUN
$ DISMOUNT MTAO:

7-22

Maintaining Public Files and Volumes

Note that the /IGNORE=INTERLOCK qualifier requires the user privilege
SYSPRV, a system UIC, or ownership of the volume.

7.7.6 Performing Weekly Backups
You can perform weekly backups in much the same manner as daily backups.
However, the /SINCE qualifier specifies the date of the last weekly backup,
normally one week earlier.
The following example assumes that the current date is 14-OCT-1986:
$ MOUNT/FOREIGN MTAO:
‘/.MOUNT-1-MOUNTED, INCW7J mounted on _MTAO:
$ BACKUP/IGN0RE=INTERL0CK/REC0RD/SINCE=7-0CT-1986 _$ PUBLIC:[*...]MTAO:INCW14JUN
$ DISMOUNT MTAO:

7.7.7 Performing Monthly Backups
Monthly backups should be all-inclusive; that is, they should be full backups.
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.
For example:
$ MOUNT/FOREIGN MTAO:
•/.MOUNT-1-MOUNTED, FULLMA mounted on _MTAO:
$ MOUNT/FOREIGN MTA1:
•/.MOUNT-1-MOUNTED, FULL02 mounted on _MTA1:
$ BACKUP/IMAGE/IGNORE=INTERLOCK/RECORD PUBLIC:
_$ MTAO:FULLJUN82.MTA1
‘/.BACKUP-1-RESUME, resuming operation on volume
'/.BACKUP-1-RESUME, resuming operation on volume
•/.BACKUP-1-RESUME, resuming operation on volume

2
3
4

$ DISMOUNT MTAO:
$ DISMOUNT MTA1:

7.7.8 BACKUP Media Security
The file system treats a BACKUP save set, whether it is stored on disk or
on magnetic tape, as a single file. BACKUP does not check protection on
individual files within the save set except when restored to the original
structure. Therefore, it is crucial to the system's file security to protect save
sets adequately. You should assign save-set files a restrictive file protection.
You can use the /OWNER_UIC and /PROTECTION qualifiers of the
BACKUP command, as described in the VAX/VMS Backup Utility Reference
Manual. Provide physical security for save sets that you keep offline (for
example, magnetic tapes and sequential disks); if possible, you should lock
them up.
If a user comes to you wanting to restore a particular file, you should not lend
the backup volume because you could give away access to all the files on the
volume. The safest way to restore a particular file is for you to mount the
volume and restore the file with a command such as the following:
$ BACKUP MTAO:SAVESET/SELECT=[JONES.TEXTPROC]LASTMONTH.DAT [*...]
_$ /OWNER_UIC=ORIGINAL

7-23

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.

7.7.9 Using BACKUP Journal Files
A BACKUP journal file contains a record 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 magnetic tape volume that contains the file.
Use the /JOURNAL qualifier to create, or append information to, a
BACKUP journal file. If no file specification 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 the contents of a BACKUP journal file, enter a command in this format:
$ BACKUP/LISTOfile-spec]/JOURNAL[=file-spec]

You must not specify an input- or output-specifier with a BACKUP
/JOURNAL/LIST command. If the file specification is omitted from the
/LIST qualifier, output is directed to SYS$OUTPUT; if the 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. They allow 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 October 5, 1986, listed in the BACKUP journal file ARCH.BJL:
$ BACKUP/JOURNAL/LIST=ARCH.BJL/SELECT=[SMITH.PROGS]/SINCE=5-0CT-1986

Example 7-1 shows the use of BACKUP journal files:

7.7.10 Backing Up the Console Medium
The procedures for backing up and restoring the console medium are
processor dependent. You can find descriptions of the procedures for specific
VAX processors in Section 2.

7.7.11 Backing Up the System Disk (Using Standalone BACKUP)
To back up and restore the system disk, you should use standalone BACKUP
as described for your VAX processor in Section 2.

7-24

Maintaining Public Files and Volumes

Example 7-1

Using BACKUP Journal Files

$ BACKUP/JOURNAL/LOG/IMAGE DRA2: MTAO:30CT.FUL
'/.BACKUP-S-COPIED, copied DRA2: [COLLINS] ALPHA. DAT; 4
'/.BACKUP-S-COPIED, copied DRA2 : [COLLINS] EDTINI. EDT; 5

'/.BACKUP-I-RESUME, resuming operation on volume 2
'/.BACKUP-I-READYWRITE, mount volume 2 on _MTAO: for writing
Press return when ready: I RET|
'/.BACKUP-S-COPIED, copied DRA2: [LANE]MAIL.MAI; 1
'/.BACKUP-S-COPIED, copied DRA2: [LANE]MEMO.RNO;5

$ BACKUP/JOURNAL/LIST
Listing of BACKUP journal
Journal file _DB2: [SYSMGR]BACKUP.BJL;1 on 3-0CT-1986 00:40:56.36
Save set 30CT.FUL created on 3-0CT-1986 00:40:56.36
Volume number 1, volume label 30CT01
[COLLINS]ALPHA.DAT;4
[COLLINS]EDTINI.EDT;5
[COLLINS]LOGIN.COM;46
[COLLINS]LOGIN.COM;45
[COLLINS]MAIL.MAI;1
[COLLINS]MAR.DIR;1
[COLLINS.MAR]GETJPI.EXE;9
[COLLINS.MAR]GETJPI.LIS;14

[LANE]LES.MAI;1

Save set 30CT.FUL created on 3-0CT-1986 00:40:56.36
Volume number 2, volume label 30CT02
[LANE]MAIL.MAI;1
[LANE]MEMO.RNO;5
[LANE]MEMO.RNO;4

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

7.7.12 Restoring Entire Disk Volumes
The command format for restoring from a save set is as follows:
BACKUP save-set-specifier[/SAVE_SET] output-specifier

You must use the /SAVE_SET qualifier when the save-set specifier refers to
a disk volume. For tape volumes, the /SAVE_SET qualifier is the default.
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.

7—25

Maintaining Public Files and Volumes

For example:
$ MOUNT/FOREIGN DRA1:
‘/.MOUNT-1-MOUNTED, 24JUND mounted on _DRA1:
$ BACKUP/IMAGE MTAO:24JUNDMA1.BCK DRA1:

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.
Note: All previously stored information on the output disk is lost.
To restore a volume set in image mode, you must mount all the volumes
of the set as foreign volumes. You must also, in the output-specifier of the
BACKUP command, include the list of devices on which the volumes are
mounted.
For example:
$ MOUNT/FOREIGN DRAO:
7.M0UNT-1-MOUNTED. PUBLIC01 mounted on _DRAO:
$ MOUNT/FOREIGN DRA1:
AMOUNT-I-MOUNTED, PUBLIC02 mounted on _DRA1:
$ MOUNT/FOREIGN DRA2:
AMOUNT-I-MOUNTED, PUBLIC03 mounted on _DRA2:
$ BACKUP/IMAGE MTAO: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, DRA1, and DRA2 become
volumes 1, 2, and 3, respectively.

Changing Volume Initialization Parameters Before Restoring
If you wish to change the volume initialization parameters for a volume, you
need to perform the following steps:
1

Initialize the new volume using the new initialization parameters.

Mount the new volume using the /FOREIGN qualifier.

3 Restore the volume with BACKUP, using the /NOINITIALIZE command
qualifier.
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:
7.DCL-I-ALL0C, _DRA2: allocated
$ INITIALIZE/CLUSTER_SIZE=3 DRA2: TEST.PROGS
$ MOUNT/FOREIGN DRA2:
7.M0UNT-1-MOUNTED. TEST.PROGS mounted on _DRA2:
$ BACKUP/IMAGE/NOINITIALIZE/TRUNCATE MTAO:1JUN.BCK

DRA2:

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 a good practice to include the /TRUNCATE qualifier, particularly if you
reduce the cluster factor.

7-26

Maintaining Public Files and Volumes

7.7.13 Restoring a Volume from Incremental Backups
If you have been performing a combination of full and incremental backups
on a public volume, you must use the following procedure to recover the
volume from its backups, should the volume be lost, corrupted, or destroyed.
First, restore the volume from the last full backup, using an image restore
operation as shown in the following example (the /RECORD qualifier is
required for the correct operation of this procedure):
$ MOUNT/FOREIGN DRAO:
•/.MOUNT-1-MOUNTED, SCRATCH mounted on _DRAO:
$ MOUNT/FOREIGN MTAO:
‘/.MOUNT-1-MOUNTED, FULLMA mounted on _MTAO:
$ MOUNT/FOREIGN MTA1:
•/.MOUNT-1-MOUNTED, FULL02 mounted on _MTA1:
$ BACKUP/IMAGE/RECORD MTAO:FULLJUN84.MTA1 DRAO:
•/.BACKUP-1-RESUME, resuming operation on volume 2
'/.BACKUP-1-RESUME, resuming operation on volume 3
'/.BACKUP-1-RESUME, resuming operation on volume 4

$ DISMOUNT MTAO:
$ DISMOUNT MTA1:
$ DISMOUNT/NOUNLOAD DRAO:

Now mount the disk as a file-structured volume and apply the incremental
backups in reverse chronological order. Start with the last daily backup;
then apply the preceding daily backups, and finally the weekly backups, as
follows:
$ MOUNT DRAO: PUBLIC
•/.MOUNT-1-MOUNTED, PUBLIC mounted on _DRAO:
$ MOUNT/FOREIGN MTAO: INCD17
•/.MOUNT-1-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-1-MOUNTED, INCD15 mounted on _MTAO:
$ BACKUP/INCREMENTAL MTAO:INCD15JUN DRAO:
$ DISMOUNT MTAO:

$ MOUNT/FOREIGN MTAO: INCW14
•/.MOUNT-1-MOUNTED, INCW14 mounted on _MTAO:
$ BACKUP/INCREMENTAL MTAO:INCW14JUN DRAO:
$ DISMOUNT MTAO:

$ MOUNT/FOREIGN MTAO: INCW7J
•/.MOUNT-1-MOUNTED, INCW7J mounted on _MTAO:
$ BACKUP/INCREMENTAL MTAO:INCW7JUN DRAO:
$ DISMOUNT MTAO:

7-27

Maintaining Public Files and Volumes

In this example, applying the latest incremental backup using the
/INCREMENTAL qualifier causes the volume's directories to be restored
to their state at the time the backup 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 listed in the most recent directory
structure from the incremental backup, are deleted. (These files were
deleted by users during the time period between the full backup and the
last incremental backup.)
In applying the earlier incremental backups, 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 backup, and were still present
when the last incremental backup was taken.
Note: BACKUP will restore the volume correctly regardless of the order in
which the incremental backups are applied; using reverse chronological
order is most efficient.
The /RECORD and /INCREMENTAL qualifiers must be used where shown
in the above example to obtain the correct operation.
If you choose to selectively exclude certain files in your incremental backups
(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 VAX/VMS Verify
Utility (VERIFY). For more information on VERIFY, see the VAX/VMS Verify
Utility Reference Manual.
Note that if directory files were renamed during the time period covered by
the incremental backups, these directories will appear on the reconstructed
volume under both their old and new names. The files that were written
since the directory was renamed will appear under the new name; the other
files, written before the directory was renamed, appear under the old name.
You must merge the old and new directories manually.

7.7.14 Restoring Files and Directories
You can restore individual files in large save sets by using the BACKUP/LIST
/JOURNAL command to find the volume that contains the files. You can
then mount the volume and use BACKUP to select and restore the desired
files. If the volume is not the first volume in a multivolume save set, you will
receive the following warning message:
'/«BACKUP-W-N0T1STV0L, tape 'name' is not the start of a save set

7.7.14.1

Listing the Contents of a BACKUP Save Set
You can use the /LIST command qualifier to list information about files in
a save set, either at the terminal or in a specified output file. BACKUP can
perform this operation in conjunction with any other BACKUP operation, or
by itself.
The following command will list save-set information at the terminal:
$ BACKUP/LIST 2MAR1986.BCK/SAVE.SET

To list the same information in a file named INFO.LIS, enter the following
command:
$ BACKUP/LIST=INFO.LIS 2MAR1986.BCK/SAVE.SET

7-28

Maintaining Public Files and Volumes

If you do not know the save-set names on a magnetic tape volume, you can
specify the device alone. Note, however, that BACKUP then performs the
list operation as it would a restore operation with only a device specification:
It reads the first save set it encounters on the magnetic tape and stops
processing when it reaches the end of that save set. BACKUP does not
automatically rewind until it reaches the end-of-tape (EOT) (unless you have
specified the /REWIND qualifier); therefore, you can proceed to the next save
set (if any exists) by repeating the command.
By including an asterisk (*) with the device specification, you can direct
BACKUP to list all of the save sets (including file names) on the volume:
$ BACKUP/LIST MTAO:*

If you want to list only the names of the save sets on a volume, without the
names of the files in the save sets, you can mount the magnetic tape volume
as Files-11; then use the DCL command DIRECTORY. For example:
$ MOUNT MTAO: SAVEWORK TAPE
•/.MOUNT-1-MOUNTED, SAVEWORK mounted on _MTAO:
$ DIRECTORY/SIZE/DATE/PROTECTION TAPE:
Directory MTAO:[]
CONTRACTS.BCK;1
JUL20SAVE.BCK;1
MYPHILE.BCK;1
Total of 3 files,

5
3
2

13-JUN-1986 12:11
20-JUL-1986 23:59
28-SEP-1986 12:00

(RWED,RWED,RE,)
(RWED,RWED,RE,)
(RWED,RWED,RE,)

10 blocks.

Note: Although you can use the DIRECTORY command to list the save sets on
a volume, the VMS file system will not necessarily be able to process save
sets as files.

7.7.14.2

Restoring Disk Files from Save Sets on Magnetic Tape
You can restore all files in the save set to the current default directory as in
the following example:
$ BACKUP TAPE:N0V12SAVE.BCK []

The following command restores files to a directory tree:
$ BACKUP TAPE:N0V12SAVE.BCK [LYKINS.

If you want to restore a specific file from a save set, you can use the /SELECT
qualifier. For example:
$ SET DEFAULT [LYKINS.GLENDO]
$ MOUNT/FOREIGN MTAO:
‘/.MOUNT-1-MOUNTED, N0V25A mounted on _MTA0:
$ BACKUP
.From: MTAO:N0V2SAVE.BCK/SELECT=[LYKINS.GLENDO]STRATI.DAT;5
.To:
STRATI.DAT;5
$ DIRECTORY STRATI.DAT
Directory [LYKINS.GLENDO]
STRATI.DAT;5
Total of 1 file.

In this example, the file STRAT1.DAT in the subdirectory [LYKINS.GLENDO]
has been accidentally deleted. The user had previously saved the file in the
save set NOV2SAVE.BCK, and now restores it to its original directory by
using the /SELECT qualifier.
If you omit a save-set name for an input magnetic tape, BACKUP reads the
first save set it encounters on the magnetic tape and stops processing when
it reaches the end of that save set. Since BACKUP does not automatically
rewind until it reaches the EOT, you can proceed to the next save set (if any
exists) by repeating the command. As an alternative, you can include an

7-29

Maintaining Public Files and Volumes

asterisk (*) with the device specification, which directs BACKUP to read all
of the save sets on the magnetic tape volume.

7.7.14.3

Restoring Disk Files from Save Sets on Sequential Disk
You can read a sequential-disk save set either sequentially or as a normal
Files-11 save set.
If you choose to read the save set as sequential, you can mount one volume
at a time (as you can do when you create a sequential-disk save set). The
default directory for the save-set file specification is the directory [000000],
which is the master file directory (MFD) on the disk; therefore, you do not
need to include the directory in the input specification. For example:
$ MOUNT/FOREIGN DMAO:
$ BACKUP/LOG DMAO:CONTRACTS.BCK/SAVE_SET CONTRACTS.DAT
'/.BACKUP - S - CREATED, created DBA2 : [USER] CONTRACTS. DAT; 1

Since the volume is mounted foreign, the DCL command DIRECTORY would
fail to list the files on the disk. However, BACKUP recognizes the format and
expects to find the save set CONTRACTS.BCK in the MFD directory. The
/SAVE_SET qualifier is required on any operation that restores from disk.
As an alternative, you can read the save set as a normal Files-11 volume:
$ MOUNT DMAO: SAVEW0RK
$ BACKUP/LOG DMAO:[OOOOOO]CONTRACTS.BCK/SAVE.SET CONTRACTS.DAT
'/.BACKUP-S-CREATED, created DBA2: [USER] CONTRACTS. DAT; 1

The default directory is your process default directory, so you must specify
the directory [000000]. The SAVE—SET qualifier is necessary for restoring the
file to its original structure; without the /SAVE—SET qualifier, the save set
would simply be copied.
Save-set files written to disk using the file system can also be read in
sequential mode; you may find this mode of operation useful if you use
standalone BACKUP. You must specify the directory from which the save set
is to be read. If the save set was written to a volume set using Files-11 disk
structure, you must observe the following rules:
•

All volumes of the volume set must be mounted. You must mount the
volumes with the /FOREIGN qualifier. (If you are using standalone
BACKUP, the volumes are implicitly mounted.)

•

When you specify the volumes in the input specifier, you must specify
the names of the devices in the same order as the relative volume number
of the volumes mounted on those devices. For example, the volumes
named USER01 and USER02 in a volume set are mounted on two drives,
DRA3: and DRA5:. The save-set specifier for the volume set must be in
the following format:
DRA3:[directory]save-set-name.ext;v, DRAB:

7-30

Maintaining Public Files and Volumes

7.7.14.4

Restoring Disk Files from Save Sets on Multiple Volumes
If your save set encompasses more than one magnetic tape or sequential disk
volume, it is possible to begin restore operations without mounting the first
volume of the save set. However, if you use the /IMAGE qualifier, processing
must begin with the first volume. If the tape that you mount is not the first
volume in the save set, you will receive the warning message:
%BACKUP-W-N0T1STV0L, tape 'name' is not the start of a save set

If you restore a small number of files from a large save set, it is a good idea
to use the /LOG qualifier. This enables you to monitor the files as they are
restored. BACKUP will continue processing until it reaches the end of the
save set. Once the files you need have been restored, you can press CTRL/Y
to terminate processing.

7.8

Managing Disk Space
Parkinson's Law, as applied to public disk storage, states that user files will
expand to exceed the available disk storage space. To combat this problem,
you can

7.8.1

•

Set file expiration dates

•

Establish disk quotas

Setting File Expiration Dates
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 DCL command SET
VOLUME:
$ SET VOLUME device-name:

/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(15-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 current date plus the minimum 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 the minimum plus 7 days, whichever is
less.

7-31

Maintaining Public Files and Volumes

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

Users may not always be aware of file expiration dates. Plan to retain the
tape for a substantial period of time unless you are unperturbed by user ire.
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.

7.8.2

Establishing 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 the user's files can
take up

The absolute maximum number of blocks permitted a user on a volume is 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/VMS Disk Quota
Utility Reference Manual). Usage counts are maintained automatically by the
system during normal file activities.
The name of the quota file is [OOOOOOJQUOTA.SYS on the applicable volume.
A quota file requires one block of disk storage for each 16 entries.
A quota file is initialized with an entry for UIC [0,0]. 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.

7-32

Maintaining Public Files and Volumes

7.8.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.

Exceeding the Quota
To create new files, a user's usage must be below quota (not overdraft). 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 an error
message.
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 prohibits further extensions to the file.
Quota restrictions are not enforced for users with the EXQUOTA privilege.
However, their usage counts are maintained.

Suspending Quotas
The DISABLE command of the Disk Quota Utility suspends quota operations
on a volume; the ENABLE command 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 can correct the usage values
with the REBUILD command of the Disk Quota Utility or with the Verify
Utility. (See the VAX/VMS Disk Quota Utility Reference Manual and the
VAX/VMS Verify Utility Reference Manual for more information.
To discontinue quota operations on a volume, execute the DISABLE
command, exit from DISKQUOTA, and delete the QUOTA.SYS file.

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, should any of the following occur:

7.8.2.2

•

The system failed.

•

The volume was physically removed before being dismounted.

•

The WRITE PROTECT button was pushed.

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

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 must be on line at all times.

7-33

Installing Images as Known Images

You can 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/VMS Install Utility Reference Manual.
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 filename DISK$VOLUME:[MAIN]filename.EXE would
be on one known file list, while all known images with the filename
DISK$VOLUME:[TEST]filename.EXE would be on another known file list.
Known file lists only last while the system is up. If the system is shut
down or fails for any reason, you must reinstall all known images after the
system is rebooted. For this reason, the site-independent startup command
procedure, SYS$SYSTEM:STARTUP.COM, includes a series of INSTALL
commands that install certain system programs as known images. You
are encouraged to include in the site-specific startup command procedure,
SYS$MANAGER:SYSTARTUP.COM, additional INSTALL commands to
install any images that
•

Are run frequently

•

Are usually run concurrently by several processes

•

Require special privileges

(See Section 2 for information on the startup command procedures.)

8.1

Assigning Attributes to Known Images
By specifying appropriate INSTALL qualifiers, you can assign known images
the following attributes:
•

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
approximately one page of nonpaged dynamic memory per file.

•

Fleader resident—The header of the image file (native images only)
remains permanently resident, saving one disk I/O operation per file
access. For images with single-block file headers, the cost is less than
one page of paged dynamic memory per file; for images with multiblock
headers, the cost varies according to the header block count. The images
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, users with normal privileges can run programs that require
higher-than-normal privileges.

8—1

Installing Images as Known Images

8.2

•

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. Protected images must be declared shared.

•

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

•

Writeable—When a shared non-copy-on-reference 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 processes mapped to the section, therefore, are preserved
(while the initial values are lost). The image must also be declared shared.

Installing Images with the Shared Attribute
Before you install an image with the shared attribute (using the /SHARED
qualifier of the Install Utility), you should understand the distinction between
executable and shareable images:
•

An executable image is one linked with the /EXECUTABLE qualifier
(or without the /SHAREABLE qualifier) of the VAX/VMS Linker. (For
information on the VAX/VMS Linker, refer to the VAX/VMS Linker
Reference Manual.)

•

A shareable image is one linked with the /SHAREABLE qualifier of the
VAX/VMS Linker; it must subsequently be linked into an executable
image to be used. (Shareable images are sometimes referred to as linkable
images, because they can be specified—implicitly or explicitly—as input
files to the link of another file.) 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.

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-copy-on-reference section must be installed as a
known image with the shared and writeable attributes.)
When you install an image with the shared attribute, permanent system
global sections are created. Execution of non-copy-on-reference 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.
The number of images that you can install with the /SHARED qualifier is
restricted by the GBLPAGES and GBLSECTIONS system parameters (see
the description of the System Generation Utility in the VAX/VMS System
Generation Utility Reference Manual).

8-2

Installing Images as Known (mages

8.3

Installing Images with Privileges
VAX/VMS allows images to execute in an enhanced privilege environment
through two mechanisms:

8.3.1

•

You can install existing executable images with extra privileges to allow a
nonprivileged process to perform the privileged functions of the image.

•

You can install privileged shareable images. Privileged shareable images
are used to implement user-written system services, thereby allowing
nonprivileged images to execute select portions of privileged code, without
enhancing the privileges of each image that uses the privileged portion of
code.

Privileged Executable Images
You install executable images with enhanced privileges through use of the
/PRIVILEGED qualifier of the Install Utility. Only images that are linked
with the VAX/VMS Linker qualifiers /NODEBUG and /NOTRACE should
be installed with enhanced privilege. Installing other images with enhanced
privilege can compromise system security.

8.3.2

Privileged Shareable Images
VAX/VMS supports user-written system services through a mechanism called
privileged shareable images. (See the VAX/VMS System Services Reference
Manual for a description of how to create privileged shareable images.)
You must link a privileged shareable image with the /PROTECT command
qualifier or the /OPTIONS positional qualifier of the VAX/VMS Linker, so
that the image acquires its particular form of enhanced privileges:
•

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

•

Use the /OPTIONS positional qualifier when only part of a privileged
shareable image requires protection.

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.

8.4

Installing Execute-Only Images
The image activator allows execution of images to which the caller has
EXECUTE but not READ access. The support differs slightly for main
programs and shareable images.
The Install Utility /EXECUTE _ONLY qualifier has meaning only for main
programs. However, a main program installed with this qualifier is capable
of activating shareable images to which the process has EXECUTE but not
READ access. The image activator ignores this qualifier when it is used on
images other than main programs.

8-3

Installing Images as Known Images

8.4.1

Execute-Only Main Programs
When a process runs a main program to which it has EXECUTE but not READ
access, the image activator enters a restricted mode of operation similar to
that entered when a privileged program is run. That is, all shareable images
activated during the life of the execute-only program must be installed. In
addition, the image activator directs RMS to use only "trusted" logical names
when opening image files. Logical names associated with EXEC or KERNEL
mode are trusted. User-mode and supervisor-mode names are not.

8.4.2

Execute-Only Shareable Images
Execute-only shareable images can be executed only in the restricted
environment established when a main program that references them is
run. The main program must be marked as capable of mapping executeonly shareable images (it must be installed with the INSTALL qualifier
/EXECUTE—ONLY), and all shareable images the program references must
be installed.
When an installed execute-only shareable image is run, the image activator
enters the same restricted mode of operation that it enters when it detects an
execute-only main program. That is, only "trusted" logical names are used by
RMS.

8.5

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 any known file lists
associated with it contain entries.

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.

8.6

Defining Logical Names for Shareable Image Files
At execution time, either a shareable image must reside in the directory
SYS$SHARE (which is normally equivalent to SYS$LIBRARY), or you must
define a logical name for the file. The logical name must be that used as
the input file specification for the shareable image when it was linked. The
equivalence string is the current file specification. That is, if a shareable
image called STATSHR.EXE does not reside in SYS$SHARE, you must, before
running an executable image that calls STATSHR, define the logical name
STATSHR. For example:
$ DEFINE STATSHR SYS$SYSDEVICE:[TEST]STATSHR

The default file type is EXE. If the file specification for STATSHR were
SYS$SHARE:STATSHR.EXE, no DEFINE command would be necessary.

8-4

Installing Images as Known Images

Likewise, one shareable image can be substituted for another without
requiring the calling executable image to relink. The user simply
defines the filename of the old shareable image as the logical name of
the file specification of the new one. The following statement defines
the filename 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 default file type is EXE. (Logical name redirection in the process
or group logical name table is ignored when you run a privileged executable
image. Only logical names that can be redirected by privileged users are
allowed.)
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 previous examples, 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.

A Note on Installing Shared Images in 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) to create a logical name of the form:
GBL$filename shrmem-name:filename

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 SHRMEM1:
$ DEFINE GBL$STATSHR SHRMEM1:STATSHR
$ INSTALL = "$INSTALL/COMMAND_MODE"
$ INSTALL
INSTALL> ADD/OPEN/SHARED STATSHR

8-5

Using the Batch/Print Facility

The batch and print jobs that run on a system each day often constitute a
large part of the workload. As system manager, you must become familiar
with the number and types of jobs that run on your system and develop
ways to submit, schedule, and execute them efficiently. You can manage job
workloads and improve system performance by
•

Establishing and controlling queues

•

Establishing and controlling spooled devices

•

Controlling batch and print jobs

This chapter provides the concepts and procedures required to carry out these
management tasks.

9.1

Types of Queues
The VAX/VMS batch/print facility supports several types of queues for
processing batch and print jobs. Queues can be divided into three major
categories: execution, generic, and logical. Execution queues schedule jobs
for execution; generic and logical queues transfer jobs to execution queues.
Queue type is further defined by the kinds of jobs the queue can accept for
processing. Some execution and generic queues accept batch jobs; others
accept print jobs. Logical queues are restricted to print jobs. The various
types of execution, generic, and logical queues are defined in the sections that
follow.

9.1.1

Execution Queues
An execution queue schedules jobs for processing. In a VAXcluster
environment, jobs are directed to execution queues on specific nodes within
the cluster. The two types of execution queue, batch queue and output queue,
are described as follows:
•

Batch execution queue - A batch execution queue can schedule only
batch jobs for execution. A batch job executes as a detached process that
sequentially runs one or more command procedures. You define the list of
command procedures when you submit the job. Section 9.6 describes how
to establish a batch execution queue.

•

Output execution queue - An output execution queue schedules print
jobs for processing by an independent process called a symbiont. The job
controller sends the symbiont a list of files to process. You define this list
of files when you submit the job. An output symbiont transfers data from
disks to an output device. As the symbiont processes each file, it produces
output for the device it controls, such as a printer or a terminal.
The standard print symbiont image provided by VAX/VMS is designed to
print files on hardcopy devices. User-modified or user-written symbionts
can also be designed for this or any other file processing activity managed
by the VAX/VMS batch/print facility (see the VAX/VMS Utility Routines

9-1

Using the Batch/Print Facility

Reference Manual for more information). The three types of output
execution queues are described below:
-

Printer execution queue - Typically uses a symbiont to direct output
to a line printer.

Terminal execution queue - Typically uses a print symbiont to direct
output to a terminal printer.

Server execution queue - Uses a user-modified or user-written
symbiont to process the files that belong to jobs in the queue. You
cannot mark an output execution queue as a server execution queue
when you create it. Only the user-written symbiont can specify that
the associated queue be marked as a server execution queue.

When you create an output execution queue you can initially mark it as
either a printer or terminal execution queue. However, when the queue
is started, the symbiont process associated with the queue can change the
queue type from the type designated at its creation to a printer, terminal,
or server execution queue, as described below:
-

When an output execution queue that is associated with the standard
VAX/VMS print symbiont is started, the symbiont determines
whether it is controlling a printer or a terminal. It communicates
this information to the job controller. If necessary, the job controller
then changes the type designation of the output execution queue.

When an output execution queue that is associated with a usermodified or user-written symbiont is started, the symbiont has the
option of identifying the queue to the job controller as a server queue.
If the user-written or user-modified symbiont does not notify the job
controller that it wants to change the queue type, the output execution
queue retains the queue type it received when it was created. That is,
it remains marked as either a printer or terminal execution queue, even
though it is associated with a nonstandard symbiont.

Section 9.7 describes how to establish output execution queues.

9.1.2

Generic Queues
A generic queue holds a job until an appropriate execution queue becomes
available to initiate the job. The job controller then requeues the job to the
available execution queue. In a VAXcluster environment, a generic queue
can direct jobs to execution queues that are located on other nodes in the
VAXcluster. The two types of generic queues, generic batch queue and
generic output queue, are described as follows:

9-2

•

Generic batch queue - A generic batch queue can direct jobs only to batch
execution queues. Generic batch queues are used on VAXcluster systems,
and are described in detail in the Guide to VAXclusters. Section 9.6.4
briefly describes generic batch queues.

•

Generic output queue - A generic output queue can direct jobs to any
of the three types of output execution queues: print, terminal, or server.
It is possible to create a generic output queue that directs jobs to any
combination of the three types of output execution queues. Typically,
however, when you create a generic output queue, you specify a list of
type-specific target queues. In this way, the generic output queue directs
jobs to a single type of output execution queue. Thus, you can control
whether the jobs submitted to a generic output queue are output on a line

Using the Batch/Print Facility

printer or a terminal printer, or are sent to a user-written symbiont for
processing. Generic output queues are described in Section 9.7.10.

9.1.3

Logical Queues
A logical queue performs the same function as a generic output queue, except
that a logical queue can direct jobs only to a single printer, terminal, or server
execution queue. A logical queue is an output queue that has been assigned
to transfer its jobs to one execution queue. Jobs sent to a logical queue cannot
execute until you first assign the logical queue to an output execution queue,
and then start both the output execution queue and the logical queue. Logical
queues are described in Section 9.7.9.

9.2

Managing the Job Controller
The system job controller is automatically started when the system is booted;
the command procedure resides in SYS$SYSTEM:STARTUP.COM. If the job
controller encounters a fatal error while trying to perform an operation on
the system job queue file, it displays an error message on the system console,
aborts, and then automatically restarts itself.
If for some reason you must manually restart the JOB-CONTROL process,
follow this procedure:
1

Issue the SHOW SYSTEM command, to determine the identification
numbers of all symbiont processes.

2 Identify all symbiont processes that have a UIC of [1,4] and a name of the
following format:
process.id name SYMBI0NT_nnnn

Note that user-written symbiont processes may have a process name other
than SYMBIONT.

3 Stop symbiont processes by using the following command format:
STOP/ID^symbiont.process.id

4 Invoke the STARTUP.COM procedure as follows:
$ <DSYS$SYSTEM: STARTUP JOBCTL

9.3

Controlling the Queue Manager
The system queue manager controls the scheduling of batch and print jobs.
The following sections describe how to start the queue manager and how to
handle abnormal conditions.

9-3

Using the Batch/Print Facility

9.3.1

Starting the Queue Manager
You start the queue manager and open the queue file with the DCL command
START/QUEUE/MANAGER. A new queue file is created if one does not
already exist, or if the /NEW_VERSION qualifier is specified. The START
/QUEUE/MANAGER command is restricted to users with both OPER
and SYSNAM privileges. You must include this command before any
other queue commands in your site-specific startup command procedure,
SYS$MANAGER:SYSTARTUP.COM (see Section 2 for more information on
SYSTARTUP.COM).
You can specify the name of a queue file as a command parameter. If you
omit this parameter, the job controller uses the default file specification
SYS$SYSTEM:JBCSYSQUE.DAT. In a VAXcluster, you must include the file
specification parameter to cause each system to access the same job queue
manager file on a shared disk volume. The disk must be mounted before
you issue the command. The following example includes a file specification
parameter:
$ START/QUEUE/MANAGER DUA2:[SYSQUE]JBCSYSQUE.DAT

In this example, the queue file JBCSYSQUE.DAT is opened in the directory
DUA2:[SYSQUE].
You can control the initial allocation and extension size of the queue file with
the /EXTEND—QUANTITY qualifier. Specify a positive integer in the range
of 10 through 65535, or 0. If 0 is specified, the default value is 100 disk
blocks.
The /BUFFER__COUNT qualifier allows you to specify the number of buffers
in a local buffer cache to allocate for performing I/O operations to the system
job file. The default value is 50. (See the VAX/VMS DCL Dictionary for more
information on the START/QUEUE/MANAGER command.)

9.3.2

Creating a New Queue File
In the unlikely event that the queue file (SYS$SYSTEM:JBCSYSQUE.DAT)
becomes corrupted, it will be necessary to create a new queue file. The
following conditions may indicate a corrupted queue file:
•

Irregularities in the display produced by the DCL command SHOW
QUEUE

•

Jobs do not process

•

Jobs seem to disappear

Before you can create a new queue file, you must stop all execution queues
on the system by issuing the DCL command STOP/QUEUE/MANAGER.
This command performs an orderly shutdown of the system job queue
manager, stops all execution queues, terminates all executing jobs, and
denies any further queue requests. Once all queue processes are terminated,
the queue file is closed. The STOP/QUEUE/MANAGER command
is contained in the site-independent shutdown command procedure,
SYS$SYSTEM:SHUTDOWN.COM. (See Section 2 for more information
on shutdown procedures.)
To create a new version of the queue file, issue the DCL command START
/QUEUE/MANAGER/NEW—VERSION.

9-4

Using the Batch/Print Facility

The STOP/QUEUE/MANAGER and START/QUEUE/MANAGER
commands are restricted to users with both OPER and SYSNAM privileges.

9.3.3

Restarting the Queue Manager
By default, the queue manager does not automatically restart in the event
of a job controller failure. However, if you specify the /RESTART qualifier
with the START/QUEUE/MANAGER command, the queue manager is
automatically restarted on recovery from a job controller abort.
All batch and output queues are restored to the states that existed prior to the
interruption of service. The job queue manager file that is opened is the same
file that was open before the abort. Upon restarting, the job controller uses
the default values for the /EXTEND—QUANTITY and /BUFFER-COUNT
qualifiers. Previously set values are lost.
Note: In order to prevent a looping condition, the job controller will not restart
the queue manager if it detects an error within two minutes of starting
the queue manager.

9.4

Managing Queues
As a system manager, you are responsible for creating and controlling queues.
This section introduces the basic DCL commands used to manage queues and
discusses several queue management operations.
The basic commands for creating and controlling queues include:
Command

Description

INITIALIZE/QUEUE

Creates a queue

START/QUEUE

Starts a queue

SET QUEUE

Modifies a queue

STOP/QUEUE

Stops a queue

Using specific qualifiers with these DCL commands allows you to perform the
following queue management operations discussed in this section:
•

Initializing and starting queues

•

Modifying queues

•

Pausing queues

•

Stopping queues

•

Restarting queue processing

•

Deleting queues

•

Merging output queues

•

Restricting access to queues

9-5

Using the Batch/Print Facility

9.4.1

Initializing and Starting Queues
To set up a queue, you first create or initialize the queue, and then start it.
You use the following commands to initialize and start a queue:
Command

Description

INITIALIZE/QUEUE

Initializes a queue. If the queue is already
running, this command has no effect.

INITIALIZE/QUEUE/START

Initializes and starts a queue. Include
this command for each queue in your
SYSTARTUP.COM file.

START/QUEUE

Starts an initialized queue. If a queue is in a
paused state, you can use this command to
resume job execution. If a queue is stopped,
you can use this command to modify job
processing parameters. Jobs listed in the
queue and new jobs will execute under the new
parameters.

The INITIALIZE/QUEUE and INITIALIZE/QUEUE/START commands are
restricted to users with OPER privilege. The START/QUEUE command
requires OPER privilege or EXECUTE (E) access to the queue.
With the INITIALIZE/QUEUE/START command, you initialize and start a
queue using a single command. This method is recommended in command
procedures (for example, the site-specific startup command procedure
SYS$MANAGER:SYSTARTUP.COM) where it is necessary to initialize and
immediately start a queue if it is stopped. The following example shows the
commands entered in a startup command procedure to initialize and start the
batch queue SYS$BATCH and the printer queues LPAO and LPBO:
$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=2/BASE_PRI0RITYss3
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO:
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO:

SYS$BATCH

If the commands are executed when the queue is stopped, the INITIALIZE
/QUEUE/START command initializes and starts the queue. Otherwise, if the
queue is already running, the command is ignored and no operation occurs.
(See Section 2 for a description of startup command procedures.)
Setting up queues is not restricted to startup time. In the course of normal
operation, you can create queues as needs dictate. Typically, you use
the INITIALIZE/QUEUE/START command to create and start a queue.
However, separate INITIALIZE/QUEUE and START/QUEUE commands
are useful when you want to initialize a queue but start it at a later time.
For example, suppose you want to initialize a printer queue and make sure
that it is set up correctly to process print jobs before you start the queue.
By specifying appropriate qualifiers to the INITIALIZE/QUEUE command,
you can assign specific processing attributes to the queue. Once a queue
is created, you can also specify additional processing attributes when the
queue is started. See Section 9.5.4 for the qualifiers to the START/QUEUE
command.

9—6

Using the Batch/Print Facility

9.4.2 Modifying Queues
Once you initialize a queue, you can change many of its attributes with the
DCL command SET QUEUE. This command is restricted to users with OPER
privilege or E access to the queue.
The SET QUEUE command allows you to change many queue attributes
without having to stop the queue, initialize it, and restart it. For example, the
following command modifies the running batch queue, SYS$BATCH:
$ SET QUEUE/J0B_LIMIT=4/DISABLE_SWAPPING

SYS$BATCH

The command in this example changes the job limit for the queue and
disables swapping for all jobs processed in SYS$BATCH. All other attributes
of the queue remain the same. The changed attributes do not affect the
execution of current jobs; however, all subsequent jobs are executed with the
new attributes in effect. See Tables 9-2 and 9-3 for a list of the attributes
that can be modified for batch and output queues.

9.4.3 Pausing Queues
The DCL command STOP/QUEUE (without any qualifiers) temporarily
halts the execution of all current jobs in the queue and places the queue
in a paused state. This command is restricted to users with OPER privilege
or E access to the queue. Pausing an output queue allows you to issue
print job positioning and alignment commands to the print symbiont. (See
Section 9.5.4 for more information on using the STOP/QUEUE command to
control print jobs.)
The DCL command START/QUEUE is used to resume the execution of a
paused queue, as described in Section 9.4.5.

9.4.4 Stopping Queues
To stop a queue, issue one of the following STOP/QUEUE commands,
according to the desired stop queue operation:
Command

Description

STOP/QUEUE/NEXT

Stops a queue after all executing jobs have completed
processing

STOP/QUEUE/RESET

Abruptly stops a queue and aborts processing of all
executing jobs

The DCL command STOP/QUEUE/NEXT allows all currently executing jobs
to complete and then stops the queue. Once you issue this command, all new
jobs are prevented from executing. This command is restricted to users with
OPER privilege or E access to the queue.
The DCL command STOP/QUEUE/RESET abruptly stops the queue and
returns control to the system. Any jobs that are currently executing are
stopped immediately. This command is restricted to users with OPER
privilege or E access to the queue.

9—7

Using the Batch/Print Facility

9.4.5 Restarting Queues
To resume the processing of jobs in a paused or stopped queue, issue the
START/QUEUE command in the following format:
START/QUEUE queue-name[:]

This command is restricted to users with OPER privilege or E access to the
queue.
Note: If the STOP/QUEUE/RESET command was issued to halt the queue, you
may have to resubmit the job that was executing at the time that the
queue was stopped.
Jobs that are restartable by default, such as print jobs, are requeued for
processing. Jobs that are not restartable by default must be resubmitted. To
make batch jobs restartable, use the SUBMIT/RESTART command discussed
in Section 9.5.5. Also, see Section 9.5.1 for information on how to retain a
processed job in a queue.

9.4.6 Deleting Queues
You can delete a queue by issuing the DCL command DELETE/QUEUE.
You must first stop the queue by issuing the DCL command STOP/QUEUE
/NEXT. (Use STOP/QUEUE/RESET if you want to abort all executing jobs.)
This command is restricted to users with OPER privilege.
To delete a queue, proceed as follows:
1

Stop the queue by issuing the STOP/QUEUE/NEXT command.

2 Wait for executing jobs to complete.
3 Delete or requeue the entries still pending in the queue.
4 Delete the queue by issuing the DELETE/QUEUE command.
The commands in the following example stop the printer queue ALTFORM,
check the contents of the queue, and delete the empty queue:
$ STOP/QUEUE/NEXT ALTFORM
$ SHOW QUEUE/ALL ALTFORM
$ DELETE/QUEUE ALTFORM

9.4.7 Merging Output Queues
When a problem occurs with a print device, you can reroute the queue
associated with that device to another queue associated with a functioning
device. Use the following procedure to merge two printers that are not
associated with a generic queue. Note that all commands shown are restricted
to users with the OPER privilege or E access to the queues.
1

Stop the queue associated with the malfunctioning print device by using
the following command format:
STOP/QUEUE/NEXT bad.queue

This command inhibits further queuing but allows the current job to
finish processing, unless the print device is inoperable. If the device is
inoperable, use the STOP/QUEUE/RESET command to halt the queue
and immediately cancel all output to the device.

9-8

Using the Batch/Print Facility

2 Requeue the current job by using the following command format:
STOP/QUEUE/REQUEUE=good_queue bad_queue

Note: If the current print job was originally submitted to a generic queue,
the print job is automatically requeued to another device.
By requeuing the current job, you ensure that it will be printed from
its last checkpoint. Other jobs in the queue will not be scheduled for
processing because the queue is stopped.

3 Take the device offline.
4 Reroute existing jobs queued to the malfunctioning print device to another
print device by entering the command
ASSIGN/MERGE good.queue bad_queue

Check to be sure that the attributes of the new print device are appropriate
for processing the new jobs.

5 To prevent any subsequent print jobs from entering the bad queue, you
can assign the name of the bad queue to the good queue, thus causing any
new print jobs directed to the bad queue to enter the good queue.
ASSIGN/SYSTEM bad_queue good_queue

The following example summarizes the procedure for merging two printer
queues that are not associated with a generic queue:
$ STOP/QUEUE/NEXT BAD.QUE
$ STOP/REQUEUE=GOOD_QUE BAD.QUE
$ ASSIGN/MERGE G00D_QUE BAD_QUE
$ ASSIGN/SYSTEM BAD.QUE GOOD.QUE

9.4.8

Restricting Access to Queues
Operations that apply to a queue or to specific jobs in a queue are controlled
by UlC-based protection in the same way access to other system objects, such
as files, is controlled. (See the discussion of protection in the VAX/VMS DCL
Concepts Manual). The ability to control queue operations through UlC-based
protection allows you to restrict the types of jobs and users for a particular
queue.
When you initialize a queue, the queue is assigned an owner UIC and a
protection mask. Jobs are assigned an owner UIC equal to the UIC of the
process that submitted the job. Each operation that is performed in a queue
or job in a queue is checked against the owner UIC, protection of the queue
and the job, and the privileges of the requester.
All operations are checked as follows:
•

Operations that apply to jobs are checked against the READ (R) and
DELETE (D) protection specified for the queue and the owner UIC of the
job. In general, R access to a job allows a user to see the attributes of a
job, and D access allows the user to delete the job.

•

Operations that apply to queues are checked against the WRITE (W)
and EXECUTE (E) protection specified for the queue and the owner UIC
of the queue. A user with W access to a queue can submit jobs to that
queue. Users with E access to a queue may act as the operator for that
queue, with the ability to affect any jobs in the queue. Users with operator

9-9

Using the Batch/Print Facility

(OPER) privilege have E access to all queues. OPER privilege also enables
users to establish queues and affect accounting.
The default protection for a queue is (System^Owner.D^roup^WorkhW).
To find out the protection specified for a particular queue use the DCL
command SHOW QUEUE/FULL, as shown in the following example:
$

SHOW QUEUE/FULL SYS$PRINT

Generic printer queue SYS$PRINT
/GENERIC=(ALPHA_LPAO,

ALPHA.LPBO,

/PROTECTION*(S:E,0:D,G:R,W:W)

COSMO.LPAO)

/OWNER=[1,4]

/RETAIN=ERROR

The system displays the protection code and other characteristics associated
with the queue. Table 9-1 summarizes the privileges required for various
queue operations.
Table 9-1

9.5

Privilege Restrictions for Queue Operations

Required Privilege

Commands

OPER and SYSNAM

START/QUEUE/MANAGER
STOP/QUEUE/MANAGER

OPER

DEFINE/CHARACTERISTIC
DEFINE/FORM
DELETE/CHARACTERISTIC
DELETE/FORM
DELETE/QUEUE
INITIALIZE/QUEUE

OPER, E access to
the queue, or R
access to the job

SHOW QUEUE
SYNCHRONIZE

OPER, E access to
the queue, or W
access to the queue

PRINT
SUBMIT

OPER or E access
to the queue

ASSIGN/MERGE
ASSIGN/QUEUE
DEASSIGN/QUEUE
SET QUEUE
START/QUEUE
STOP/QUEUE
STOP/QUEUE/NEXT
STOP/QUEUE/RESET

OPER, E access to
the queue, or D
access to the job

DELETE/ENTRY
SET QUEUE/ENTRY
STOP/QUEUE/ABORT

No privilege

SET RESTART_VALUE

Managing Jobs
This section describes operations for controlling batch and print jobs. Some
of the operations commonly performed by a system manager include:

9-10

•

Retaining jobs in a queue

•

Terminating an executing job

•

Modifying job parameters

Using the Batch/Print Facility

•

Controlling print job position and alignment

•

Controlling batch job execution

For certain operations, the DCL command used for a batch job may differ
from that used for a print job. The following table shows a few cases in
which a similar operation requires a different command.
Batch Command

Print Command

Function

SUBMIT

Sends a job to a
queue

STOP/ABORT/ENTRY=
entry-number

STOP/ABORT

Terminates an
executing job

STOP/QUEUE/ENTRY=
entry-number/REQUEUE

STOP/QUEUE/REQUEUE

Stops and
requeues an
executing job

These and other DCL commands for controlling batch and print jobs
are discussed in the following sections. (For detailed descriptions of the
commands, see the VAX/VMS DCL Dictionary.)

9.5.1

Retaining Jobs in a Queue
To retain a job in a queue after it has been processed, specify the /RETAIN
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE
command. The /RETAIN qualifier has the following format:
/[NO]RETAIN[^option]

You indicate the type of job that the queue is to retain by specifying one of
the following options:
Option

Description

ALL

Specifies that jobs be retained in the queue in a
completed status after they are executed

ERROR

Specifies that jobs be retained only if they
completed unsuccessfully (the completion status
has the low bit clear)

By default, jobs are NOT retained.
The following command specifies that the queue retain all jobs that complete
with a "nonsuccess" (low bit clear) status:
$ SET QUEUE/RETAIN=ERROR

BATCH.QUE

9-11

Using the Batch/Print Facility

9.5.2

Deleting a Job
Under certain circumstances, it is necessary to terminate an executing batch
or print job. For example, you may need to terminate a program that has
entered an endless loop or a job that is executing on a faulty print device.
Follow this procedure to delete either a pending or an executing job:
1

Determine the entry number of the job and the name of the queue by
issuing the command
$ SHOW QUEUE/BATCH/ALL

2 Delete the job by issuing the command
DELETE/ENTRY=entry-number

queue-name

The DELETE/ENTRY command is restricted to users with either OPER
privilege, E access to the queue, or D access to the specified job.
You can also use the STOP/ENTRY command to delete an executing job.
Issue the command in the format
STOP/ENTRY=entry-number

queue-name

The following example shows how to terminate an executing batch job:
$ SHOW QUEUE/BATCH/ALL
Batch queue SYS$BATCH
Jobname

Username

Entry

MAILER
ASSEM.JOBCTL

DECNET
JONES

1701
1152

Status
Holding until 8-JUL-1986 10:33
Holding until 12-JUL-1986 00:00

Batch queue SPECIAL
Batch queue TEXT._PROC
Jobname

Username

2307SMRCL
2307SMRDS

MARCO
MARCO

$ ST0P/ENTRY=1719

Entry
1719
1720

Status
Executing
Pending

TEXT_PROC

Assume a user has observed that job 1719 is a runaway job. The user is not
the owner of the job, and lacks sufficient privilege to stop it. The user enlists
your aid as the system manager. You issue the SHOW QUEUE/BATCH/ALL
command to determine the queue in which the job has been entered. The
display shows that job 1719 is in the TEXT—PROC queue. You then delete
the job by issuing the STOP/ENTRY command.
A third option for terminating an executing job is to issue the STOP/ABORT
command in the following format:
STOP/ABORT queue-name

Note: If you use the STOP/ABORT command to terminate an executing batch
job, you must include the /ENTRY qualifier to identify the specific job
entry.
The STOP/ABORT command is restricted to users with either OPER
privilege, E access to the queue, or D access to the current job. In the
following example, the executing print job in queue LPAO is terminated, and
the next job is immediately scheduled for printing.
$ STOP/ABORT

9—12

LPAO

Using the Batch/Print Facility

9.5.3

Modifying Job Parameters
You can modify certain job processing attributes by specifying the following
qualifiers with the SET QUEUE/ENTRY command:
Qualifier

Description

/[NOJAFTER

Controls whether a job is held until after a specified time.

/[NOJHOLD

Controls whether a job is available for immediate processing
or held until it is released for processing.

/[NOJPASSALL

Specifies whether the symbiont bypasses all formatting and
sends the output QIO to the driver with format suppressed.
See Section 9.7.8 for information on the /[NOjPASSALL
qualifier.

/PRIORITY

Specifies the queue scheduling priority of the job.

/RELEASE

Releases a previously held job.

/REQUEUE

Requests that the job be moved from the original queue to
the specified queue. This qualifier can also be used with the
STOP/QUEUE/ENTRY command.

/SETUP

Calls for the specified modules from the device control
library. See Section 9.7.2 for information on device control
libraries.

(See the VAX/VMS DCL Dictionary for complete descriptions of these
qualifiers.)

9.5.3.1

Holding and Releasing a Job
The /HOLD qualifier of the command SET QUEUE/ENTRY controls whether
a job is to be made available for immediate processing. You release a held
job by using either the /NOHOLD or the /RELEASE qualifier.
To request that the job be held until after a specified time, use the /AFTER
qualifier with the command SET QUEUE/ENTRY. The job is queued for
immediate processing when the specified time arrives. The /AFTER=time
qualifier accepts either absolute or delta time values in the format
[dd-mmm-yyyy] [hh:mm:ss.cc]. You can also specify the keywords:
TODAY
YESTERDAY
TOMORROW
The following command holds a print job until it is queued for processing at
the specified date and time:
$ SET QUEUE/ENTRY=1121/AFTER=12-JUL-1986:17:30 SYS$PRINT

You can use the /NOAFTER qualifier to immediately release a job that is
being held until after a specified time.
The /RELEASE qualifier releases a job that is being held for any of the
following reasons:
•

A job was submitted with the /HOLD qualifier

•

A completed job was held in a queue by the /RETAIN qualifier

•

A user-written symbiont has refused a job

9-13

Using the Batch/Print Facility

•

A job was submitted with the /AFTER qualifier

This example shows how to hold and release a batch job:
$ STOP/QUEUE/ENTRY-1234/HOLD SYS$BATCH
$ SET QUEUE/ENTRY=1234/RELEASE SYS$BATCH

9.5.3.2

Requeuing a Job
To stop and requeue the executing print job, enter the STOP/QUEUE
/REQUEUE command to suspend the currently executing job and requeue it
to the specified queue, for example:
$ STOP/QUEUE/REQUEUE=ALPHA_LPAO ALPHA.LPBO

This command causes the executing print job on ALPHA_LPB0 to be stopped
and requeued to ALPHA_LPAO. The queue does not stop; only the currently
executing job is affected. Other jobs remain pending in the queue until they
are processed.
You can further qualify the STOP/QUEUE/REQUEUE command with the
/HOLD qualifier. To hold an aborted print job, enter the STOP/QUEUE
/REQUEUE/HOLD command in the following format:
STOP/QUEUE/REQUEUE/HOLD [queue-name]

When you specify /HOLD, the aborted job is placed in a hold state for later
release with the SET QUEUE/ENTRY/RELEASE command. If you do not
need to process a job that is being held in a queue, you can delete the job
with the DELETE/ENTRY command.
Note: If you are requeuing a job on a batch queue, you must include the
/ENTRY=n qualifier, for example:
$ STOP/QUEUE/ENTRY=1251/REQUEUE=FRED.BATCH SYS$BATCH

9.5.3.3

Changing the Priority of a Job
You can change the priority of a job by using the /PRIORITY=n qualifier
with the SET QUEUE/ENTRY command. The priority value must be in a
range of 0 through 255, where 0 is the lowest priority and 255 is the highest.
The default value for /PRIORITY is the value of the SYSGEN parameter
DEFQUEPRI. You must have either OPER or ALTPRI privilege to raise the
priority value above the value of the SYSGEN parameter MAXQUEPRI.
No privilege is needed to set the priority of your own job lower than the
MAXQUEPRI value. The following example changes the priority of a
job to 3:
$ SET QUEUE/ENTRY=1131/PRI0RITY=3 SYS$BATCH

9.5.4

Controlling Print Job Position and Alignment
Pausing an output queue allows you to communicate with the print symbiont
interactively. You pause a queue by issuing the STOP/QUEUE command
(without any qualifiers). You can perform the following operations while a
queue is paused:
•

Specify the position at which a suspended job is to resume printing

•

Specify the number of pages and the type of data for aligning printer
forms

These operations are described in the sections that follow.

9-14

Using the Batch/Print Facility

9.5.4.1

Specifying the Position of Print
You specify the position at which the current job is to resume printing by
pausing the queue, then entering the START/QUEUE command with any of
the following qualifiers:
Qualifier

Description

/[NO]BACKWARD[=pages]

Specifies the number of pages the file is to be
backspaced before printing is resumed. A value
of 1 indicates that printing is to resume at the top
of the current page. If you omit the page value,
the file is backspaced one page.

/[NO]FORWARD[=pages]

Specifies the number of pages the file is to be
forward-spaced before printing is resumed. A
value of 1 indicates that printing is to resume at
the top of the next page. If you omit the page
value, the file is forward-spaced one page.

/[NO]SEARCH=string

Specifies that printing is to resume at the page
containing a particular search string. The search
for the string moves forward, beginning on the
page following the current page. During the
search, consecutive tabs and spaces are treated
as a single space, and character case is ignored.

/TOP_OF_FILE

Specifies that printing is to resume at the
beginning of the file.

When you must use more than one positioning qualifier with the same
START/QUEUE command, file positioning is performed in the following
order:
/TOP
/FORWARD
/BACKWARD
/SEARCH
The command in the following example resumes output on LPAO after
advancing 15 pages from the beginning of the file.
$ START/QUEUE/T0P/F0RWARD=i5 LPAO:

9.5.4.2

Aligning Printer Forms
To print alignment data to aid in aligning printer forms, enter the
START/QUEUE command along with the /ALIGN qualifier:
/ALIGN=(optionl[,option2])

The following options control the number of alignment pages and type of
alignment data:

9—1 5

Using the Batch/Print Facility

Option

Description

MASK

Specifies that input data is masked by replacing alphabetic
characters with the character X and numeric characters with the
number 9. Mask characters allow you to prevent the printing
of sensitive information. If you omit the MASK option, data is
printed unaltered.

A decimal number in the range 1 through 20 that specifies the
number of alignment pages to print. By default, one page of
alignment data is printed.

You can use the /ALIGN qualifier along with any of the file positioning
qualifiers described in the previous section. File positioning is performed
before alignment data is printed. After the alignment is complete, the queue
enters a paused state until you restart it by reissuing the START/QUEUE
command. Printing resumes from the point that alignment data started; that
is, the task is backspaced over the pages printed for alignment.
The command in the following example requests masked alignment for four
pages of output.
$ START/QUEUE/BACKWARD*2/ALIGN=(MASK,4) LPAO:

In this example, the file for the job that was being printed when the queue
was paused is backspaced two pages before alignment is performed. Four
pages of alignment mask characters are printed. Then the output for the
current job is positioned backward four pages, and the queue pauses.

9.5.5

Controlling Batch Job Execution
You submit batch jobs to the VAX/VMS system and queue them for execution
in two ways:
•

As command procedure files submitted by issuing the DCL command
SUBMIT. These files are placed in a batch queue and selected for execution
according to their relative priority in the queue. By default, the name of
this batch queue is SYS$BATCH.

•

As batch job files submitted by issuing the DCL command JOB from a
card reader. These batch job files are spooled onto a disk and placed in a
batch queue. Unless the JOB command specifies otherwise, the name of
this batch queue is SYS$BATCH.

When a job executes on a batch queue, the job is assigned the attributes of
the queue. Users, however, can explicitly override some queue attributes
for a particular job by specifying qualifiers to the DCL command SUBMIT.
The following qualifiers are useful for balancing the system resources for
processing batch jobs:

9-16

Using the Batch/Print Facility

Qualifier

Description

/AFTER=time

Specifies that the job will be held until after a designated
time. If the designated time has passed or the /NOAFTER
qualifier is specified, the job is queued for immediate
processing.

/CLI

Enables you to specify a different command language
interpreter (CLI) to use in processing the job.

/CPUTIME

Defines a CPU time limit for the batch job. When a job
needs less CPU time than authorized, use the /CPUTIME
qualifier to override the base value established for the
queue or authorized in your UAF.

/PRIORITY

Specifies the job scheduling priority for a job. You must
have either OPER or ALTPRI privilege to raise the priority
above the value of the SYSGEN parameter MAXQUEPRI.
No privilege is needed to set the priority lower than the
MAXQUEPRI value. The default priority of a queue is
determined by the SYSGEN parameter, DEFQUEPRI.

/WSDEFAULT

Defines a working set default for a batch job. Use this
qualifier to override the base value established for the
queue.

/WSEXTENT

Defines a working set extent for a batch job. You cannot
request a higher value than your default.

See the VAX/VMS DCL Dictionary for complete descriptions of the SUBMIT
command qualifiers.
You can also control certain attributes of batch jobs that are submitted as
command procedure files by issuing the following SET commands:
Command

Description

SET OUTPUT_RATE=time

Controls the rate at which output is
written to a batch job log file. By
default the contents of the buffer is
written to a log file once per minute.

SET RESTART—VALUE=string

Defines the value of the symbol
BATCHSRESTART. This symbol can
be used to control the point at which
a command procedure will restart after
encountering a system interruption.
BATCH$RESTART is the value of the
most recently executed SET RESTART—
VALUE command. The SRESTART
symbol is a Boolean value which is true
if a system interruption has occurred.

SET QUEUE/ENTRY/NOCHECKPOINT

Erases the value established by
the most recently executed SET
RESTART_VALUE command by
clearing BATCHSRESTART.

See the VAX/VMS DCL Dictionary for detailed descriptions of these SET
commands.

9-17

Using the Batch/Print Facility

9.6

Establishing Batch Queues
A batch execution queue controls the execution of batch jobs, and defines
default system resources for jobs that execute on it. Typically, you must
decide on the number of batch queues for your installation and determine
attributes such as the following:
•

Job limit

•

Base priority

•

Swap mode

•

CPU limits

•

Working set quotas and limits

(See Section 6 for a discussion of limits, quotas, and priorities.)
You control the attributes of a batch queue by issuing specific qualifiers to the
INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command. Table 9-2
gives a summary of the attributes that can be associated with a batch queue.
See the VAX/VMS DCL Dictionary for complete details on the qualifiers
described in Table 9-2.
Table 9-2

9-18

Specifying Attributes for Batch Execution Queues

Qualifier

Description

/[NOJBATCH

Indicates that you are initializing a batch
queue. The default is /NOBATCH. For an
existing queue, you can use the /BATCH
qualifier only if the queue is already a batch
queue.

/BASE_PRIORITY

Specifies the base process priority at which
jobs in the queue are processed.

/[NOJCHARACTERISTICS

Specifies one or more characteristics for
processing jobs in a queue. The default is
/NOCHARACTERISTICS. A characteristic can
be either a value from 0 through 127 or a
characteristic name that has been defined by
the DEFINE/CHARACTERISTIC command.

/CPUDEFAULT

Defines the base queue value for the default
CPU time limit for batch jobs executed in this
queue. The time cannot exceed the CPU time
limit set by the /CPUMAXIMUM qualifier.

/CPUMAXIMUM

Defines the maximum CPU time for batch
jobs. Use this qualifier to override the CPU
time limit specified in the UAF file.

/[NOJDIS ABLE—SWAPPING

Controls whether batch jobs executed from
a queue can be swapped in and out of
memory. The default is /NODISABLE —
SWAPPING.

/[NO]EN ABLE—GENERIC

Specifies whether jobs queued to a generic
queue can be placed in this queue for
processing. The default is /ENABLEGENERIC.

Using the Batch/Print Facility

Table 9-2 (Cont.)

Specifying Attributes for Batch Execution
Queues

Qualifier

Description

/JOB_LIMIT

Indicates the number of batch jobs that can
be executed concurrently from a batch queue.

/ON=node::

Specifies the node on which this batch
execution queue is located. The node name
is used only in VAXcluster environments;
it must match the node name specified by
the SYSGEN parameter SCSNODE for the
processor on which the queue executes.
See Section 9.7.1 for information on naming
queues.

/OWNER_UIC

Enables you to change the user identification
code (UIC) for the queue.

/PROTECTION

Specifies the protection of the queue. By
default, the queue protection is (SYSTEM:E,
OWNER:D, GROUP:R, WORLD:W)

/[NOjRETAIN

Specifies that jobs be retained in the queue in
a completed status after they have executed.
The default is /NORETAIN.

/WSDEFAULT

Defines the base queue value for the working
set default for batch jobs executed in this
queue. The value set by this qualifier
overrides the value defined in the UAF of
any user submitting a job to the queue.

/WSEXTENT

Defines the base queue value for the working
set extent for batch jobs executed in this
queue. The value set by this qualifier
overrides the value defined in the UAF of
any user submitting a job to the queue.

/WSQUOTA

Defines the base queue value for the working
set page size for batch jobs executed in
this queue. The value set by this qualifier
overrides the value defined in the UAF of any
user submitting a job to the queue.

Before users can submit batch jobs, the system manager must create at least
one batch queue. Jobs will not begin processing until the system manager
starts the batch queue. (Section 9.4.1 discusses how to create and start a
queue.) More than one batch job can execute at the same time from a single
batch queue. The number of jobs that can execute simultaneously depends
on the job limit that you establish for the queue.
After a batch queue has been started, the job with the highest relative priority
is the first candidate for execution. For jobs having the same priority, the
earliest submitted job is the first candidate for execution.
You should normally encourage users to submit large jobs (such as compiling
and linking large programs) as batch jobs, and to reserve interactive use of
the system for jobs that do not require extensive resources. Toward this end,
you may do the following:
•

Restrict the working set size of interactive jobs by providing a small (for
example, 300) WSEXTENT value in the UAF records (see Section 6).

9-19

Using the Batch/Print Facility

•

Expand the working set size of batch jobs by providing a large (for
example, 500) WSEXTENT value when you create the batch queue.

You can likewise restrict and expand time limits on jobs by setting the CPU
values. The following sections provide some guidelines for setting up batch
execution queues in different environments.

9.6.1

Setting Up Batch Queues on Small Systems
On small systems (under 1MB), you should add up the pages required for
the batch working sets and ensure that enough fluid memory remains for
interactive jobs. Fluid memory 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. To obtain these values, issue the DCL
command SHOW MEMORY.)
If fluid memory drops below the value of the WSMAX system parameter,
you must reduce the number of batch jobs or make the FAST and SLOW
jobs swappable. Otherwise, a deadlock could result. (See Section 9.6.3 for
information on setting up FAST and SLOW queues.)

9.6.2

Setting Up Batch Queues on Interactive Systems
This section provides guidelines for setting up a batch queue for a system
that is predominantly interactive. The following values are typical for a
VAX11-780 system:
1

Set up one batch queue named SYS$BATCH, the name of the default
batch queue.

2 Give SYS$BATCH the following characteristics:
•

Job limit—1 to 4

•

Base priority—3 or 4

•

Swapping mode—swapping enabled (default)

•

Working set default—300

•

Working set quota—200 to 500

•

Working set extent—400 or more

•

CPU default—infinite (default)

•

CPU maximum—infinite (default)

Normally, you would include the following command in your site-specific
startup command procedure to create and start this queue (see Section 2):
$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=2/BASE_PRI0RITY=3 /WSDEFAULT=3OO/WSQU0TA=5OO/WSEXTENT=2OOO SYS$BATCH

9-20

Using the Batch/Print Facility

9.6.3

Setting Up Batch Queues on Batch Systems
The following guidelines are useful for 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:
•

SYS$BATCH—the default batch queue with swapping enabled.

•

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

•

SLOW—a "background" queue for processing low-priority jobs.
Typically, these are large jobs with large requirements for physical
memory. Usually, it is uneconomical 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:
•

Job limit—6 to 10

•

Base priority—4 (by default)

•

Swapping mode—swapping enabled (by default)

Give FAST the following characteristics:
•

Job limit—1 (by default)

•

Base priority—4 (by default)

•

Swapping mode—swapping disabled

Give SLOW the following characteristics:
•

Job limit—1 (by default)

•

Base priority—low (3, for example)

•

Swapping mode—swapping disabled

Normally, you would include the following commands in your site-specific
startup command procedure to create and start these queues (see Section 2):
$ INITIALIZE/QUEUE/START/BATCH/J0B_LIMIT=6 SYS$BATCH
$ INITIALIZE/QUEUE/START/BATCH/DISABLE.SWAPPING FAST
$ INITIALIZE/QUEUE/START/BATCH/BASE_PRI0RITY=3/DISABLE_SWAPPING SLOW

9.6.4

Setting Up Generic Batch Queues
Unlike an output queue, a batch queue can execute more than one job at a
time. For this reason, it is often not necessary on a single-node system to
create more than one batch queue of the same type and assign them to a
generic batch queue. In a VAXcluster environment, where you have multiple
processors, generic batch queues are useful for distributing batch jobs to batch
execution queues that are located on other nodes in the cluster. The use of
generic batch queues in clustered environments is described in detail in the

Guide to VAXclusters.

9-21

Using the Batch/Print Facility

9.7

Establishing Output Queues
An output execution queue controls the processing of print jobs by an
independent symbiont process that is associated with the queue. As described
in Section 9.1, there are three types of output execution queues:
•

Printer execution queue—A queue that typically uses the standard print
symbiont to direct output to a line printer.

•

Terminal execution queue—A queue that typically uses the standard
print symbiont to direct output to a terminal printer. (Terminal queues are
created and controlled by the same commands as printer queues.)

•

Server execution queue—A queue that uses a user-modified or userwritten symbiont to process the files that belong to jobs in the queue.
(Server queues are created and controlled by the same commands as
printer queues.)

You control the attributes of an output queue by issuing specific qualifiers
to the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command.
Table 9-3 gives a summary of the attributes that can be associated with
output queues. See the VAX/VMS DCL Dictionary for complete details on the
qualifiers described in Table 9-3.
Table 9-3

9-22

Specifying Attributes for Output Execution Queues

Qualifier

Description

/BASE-PRIORITY

Specifies the base process priority at which
the symbiont serving this queue will execute.
You must stop and restart all output queues
sharing the symbiont to change the symbiont
base process priority.

/[NO]BLOCK_LIMIT

Limits the size of print jobs that can be
executed on an output queue. The default is
/NOBLOCK_LIMIT. You can use this qualifier
to reserve certain printers for certain size
jobs.

/[NOjCHARACTERISTICS

/[NOjDEFAULT

Establishes defaults for certain options
of the PRINT command. The default is
/NODEFAULT. /DEFAULT options include
FLAG, BURST, TRAILER, FEED, and
FORM=type. Once an option is set for the
queue by the /DEFAULT qualifier, users do
not have to specify that option in their PRINT
commands. However, users may override
these options by including them on the DCL
PRINT command line.

Using the Batch/Print Facility

Table 9-3 (Cont.)

Specifying Attributes for Output Execution
Queues

Qualifier

Description

/[NO]EN ABLE—GENERIC

Specifies whether files queued to a generic
queue can be placed in this queue for
processing. The default is /ENABLE—
GENERIC.

/FORM-MOUNTED

Specifies the form type mounted on the
output queue. You specify the form type
by using a numeric value or a form name
that has been defined by the DEFINE
/FORM command. If the stock of the form
associated with the job is not identical to the
stock of the form mounted on the queue, the
job will enter a pending state.

/[NO]LIBRARY

Specifies the file name for the device control
library. When you are initializing an output
queue, you can use this qualifier to specify an
alternate device control library. The default
library is SYS$LIBRARY:SYSDEVCTL.TLB.

/ON=device[:]

Specifies the node and/or device on which
this execution queue is located.

/OWNER_UIC

Enables you to change the user identification
code (UIC) for the queue.

/[NO]PROCESSOR

Allows users to specify their own print
symbiont image. The file name specifier
can be any valid file name. It specifies
that the symbiont image to be executed is
SYS$SYSTEM:file-name.EXE. By default,
SYS$SYSTEM:PRTSMB.EXE is executed.
The /NOPROCESSOR qualifier cancels the
effect of a previous /PROCESSOR setting.

/PROTECTION

Specifies the protection of the queue. By
default, the queue protection is (SYSTEM:E,
OWNER:D, GROUP:R, WORLD:W)

/[NO]RECORD_BLOCKING

Determines whether the symbiont can block
together output records for transmission to
the output device. The default is /RECORDBLOCKING.

/[NO]RETAIN

Specifies that jobs be retained in the queue in
a completed status after they have executed.
The default is /NORETAIN.

/SCHEDULE=[NO]SIZE

Specifies whether pending jobs in a printer,
terminal, or server queue are scheduled for
printing based on the size of the job. When
the default /SCHEDULE=SIZE is in effect,
smaller jobs will print before larger ones.

9-23

Using the Batch/Print Facility

Table 9-3 (Cont.)

Specifying Attributes for Output Execution
Queues

Qualifier

Description

/[NOjSEPARATE

Specifies the job separation attributes for
a printer or terminal queue. Users cannot
override these options. The default is
/NOSEPARATE. Job separation options
include BURST, FLAG, TRAILER, and
RESET=module. The selected options
establish mandatory attributes for all jobs
processed in the queue.

/WSDEFAULT

Defines a working set default for the
symbiont process. You must stop and
restart all output queues to change the
symbiont base process priority.

/WSEXTENT

Defines a working set extent for the symbiont
process. You must stop and restart all
output queues to change the symbiont base
process priority.

/WSQUOTA

Defines the working set page size for the
symbiont process. You must stop and
restart all output queues to change the
symbiont base process priority.

Before users can submit print jobs, the system manager must initialize at least
one output queue. Jobs will not begin processing until the system manager
starts the queue. (Section 9.4.1 describes how to initialize and start a queue.)
Print jobs are queued for processing in one of two ways:
•

Implicitly—without the direct intervention of a user

•

Explicitly—with the direct intervention of a user

Implicit Printing
Print jobs are queued implicitly when a process directs its output to a spooled
device. The output is then placed in a temporary file. When the file is closed,
it is submitted to an output queue. Both the spooling of the output file to
an intermediate device and the subsequent queuing of a job consisting of
this file occur without the direct intervention of a user. Implicit printing uses
default attributes, and bypasses the user's ability to specify job attributes on
the command line. Section 9.7.11 discusses spooled devices in detail.
Explicit printing
Print jobs are queued explicitly when users issue the PRINT command.
Users can explicitly queue one or more files (from a disk) for printing. (The
VAX/VMS DCL Dictionary describes the PRINT command and available
qualifiers in detail.) The files specified in the PRINT command are queued as
a print job; if several files make up a print job, they are printed together.
Unlike batch execution queues, an output execution queue can print only
one job at a time. Print jobs are scheduled for printing according to their
priority; the highest-priority job is the first selected for printing. If several
jobs have the same priority, the smallest job is printed first, unless the queue
is initialized with the /SCHEDULE=NOSIZE qualifier. Jobs of equal size
9-24

Using the Batch/Print Facility

having the same priority are selected according to their submission time; the
job submitted earliest is printed first.
By default, print jobs queued by issuing the PRINT command are placed
in the queue named SYS$PRINT. Thus, to use the default version of the
PRINT command on a system with only one printer, name the printer queue
SYS$PRINT in your site-specific startup command procedure as follows:
$ INITIALIZE/QUEUE/START/ON=LPAO:

SYS$PRINT

Note: To use the default version of the PRINT command on a system with
several line printers of matching characteristics, you would normally
establish SYS$PRINT as the name of a generic queue. Section 9.7.10
describes how to establish generic output queues.

9.7.1

Naming an Output Execution Queue
By default, when you initialize an output execution queue for a particular
printer, the queue is assigned the name of the physical device. For example,
the following command initializes and starts the queue for the line printer
LPAO and assigns the queue the name LPAO.
$ INITIALIZE/QUEUE/START

LPAO:

To create an output execution queue and assign it a name that is different
from the printer's physical device name, specify the /ON qualifier of the
INITIALIZE/QUEUE command:
/0N=device[:]

The /ON qualifier allows you to assign a queue name that describes the
printer's function. For example, you could assign the name LETTER to the
queue for a letter quality printer. Users wanting letter-quality printing could
simply queue their jobs to the queue LETTER.
The following command sequence initializes and starts a queue named
LETTER, assigns it to the printer LPCO, and then sends a print job
(MY_LETTER.TXT) to the queue.
$ INITIALIZE/QUEUE/START/ON=LPCO:
LETTER
$ PRINT/QUEUE=LETTER MY_LETTER.TXT

9.7.2

Using Device Control Libraries
A device control library is a text library that contains user-written modules for
setting up printers to perform special printer functions. Device control library
modules can be used for the following purposes:
•

To insert device-dependent escape sequences that set up programmable
printers for selected print options such as point size, character set, and
bold or italic print

•

To insert text at specific points in the processing of a print job such as at
the beginning of a file, the beginning of each page, or at the end of each
job (modules designed for this purpose can be used on both programmable
and non-programmable printers)

9-25

Using the Batch/Print Facility

You use the following DCL commands to set up device control library
modules for processing print jobs:
Command

Description

DEFINE/FORM/SETUP

Specifies one or more modules
that set up the device when
the form is mounted before
each file.

DEFINE/FORM/[NO]PAGE_SETUP

Specifies one or more modules
that set up the device before
each page.

INITIALIZE/QUEUE/LIBRARY
START/QUEUE/LIBRARY

Specifies the file name
of the device control li¬
brary. The default library is
SYS$LIBRARY:SYSDEVCTL.TLB
This parameter must contain
a file name only, without an
extension or a directory.

INITIALIZE/QUEUE/SEPARATE=[NO]RESET
ST ART/QUEUE/SEPARATE=[NO]RESET
SET QUEUE/SEPARATE=[NO]RESET

Specifies one or more modules
to be extracted from the device
control library and copied to
the device at the end of each
job. This module can be used
to restore the device to a
known state at the end of each
job. The default is NORESET.

PRINT/SETUP

Calls for the specified modules
to be extracted from the device
control library and copied to
the printer before a file is
printed.

To use a device control library module, perform the following steps:
1

Create a device control library by issuing the command:
$ LIBRARY/CREATE/TEXT SYS$LIBRARY:SYSDEVCTL.TLB

Determine the contents of the module—either the text to be inserted, or
the escape sequences needed for the desired printer setup. You determine
the proper escape sequences for a printer option by referring to the
operation guide for the specific printer.

Create a module file and enter the appropriate escape sequences, carriage
control characters, and/or text. You create and edit a module file as you
would any other text file.

Insert the module into the device control library by issuing the command:
LIBRARY/INSERT/TEXT library-file module-file

Assign the device control library to a queue by issuing the command:
INITIALIZE/QUEUE/LIBRARY=filename queue-name

Note that this step is not necessary if you use the default library
SYSDEVCTL.TLB.

9-26

Using the Batch/Print Facility

Request a device control library module by issuing either the
PRINT/FORM or PRINT/SETUP command, for example:
$ PRINT/SETUP=M0DULE1 TEST1.TXT/QUEUE=ELF_QUE

(See the VAX/VMS Librarian Reference Manual for more information on
creating libraries and inserting modules.)

9.7.2.1

Assigning a Library to an Output Queue
You assign a device control library to an output queue by specifying the
/LIBRARY qualifier with the INITIALIZE/QUEUE or START/QUEUE
command in the following format:
INITIALIZE/QUEUE/START/LIBRARY=filename queue-name

The file name is the name of the library file that contains the desired
modules. Libraries must be in SYSSLIBRARY and have the default file
type TLB. If you do not specify a file name, by default the file name is
SYS$LIBRARY:SYSDEVCTL.TLB; 1. You can use the /LIBRARY qualifier to
specify an alternate device control library, for example:
$ INITIALIZE/QUEUE/LIBRARY=MYDEVCTL ELF.QUE

Note: If you specify a file name in this parameter, do NOT include the directory,
file extension, or version number. The system assumes that the file is in
SYS$LIBRARY and has the extension TLB. If you copy a library file from
another node, be sure that the new library has a unique file name.
Operations that request a particular device control library module (by issuing
the PRINT/SETUP or PRINT/FORM command) use the module from the
library specified for the queue. If you have a small configuration of printers,
and normally use only a few modules, you typically store all modules in a
single library and assign that same library to each printer queue.
For sites with a large number of different printers, you typically create and
assign a separate device control library for each printer queue. By using
separate libraries for each printer queue, you can create modules that have
the same name and perform the same functions, but contain escape sequences
unique to the specific type of printer. If you use a single library to store
modules for different types of printers, you must make sure that each module
has a unique name.
You use the following command format to display a listing of all modules
contained within a specified library:
LIBRARY/LIST/FULL SYS$LIBRARY:library-name.TLB

Note: To add or delete a module from a library, you must stop all output queues
assigned to that library.

9.7.2.2

Requesting a Library Module
The system manager can control the printer setups available to users by
defining forms that are associated with one or more device control library
modules for a particular queue. The DCL command DEFINE/FORM/SETUP
associates a form with a device control library module that sets up the printer
before each file of a job is printed. The command DEFINE/FORM/PAGE_
SETUP associates a form with a module that sets up the printer before each
page is printed.
By issuing the appropriate PRINT/FORM or PRINT/SETUP command users
can request a device control module to set up a specific printer option, or to
insert text at the beginning of each file or at the beginning of each page.

9-27

Using the Batch/Print Facility

The PRINT/FORM command has certain advantages over the PRINT/SETUP
command. The form name specified with the PRINT/FORM command is
checked for validity when the command is issued. However, the module
names are not checked until the file is printed, because the name of the
device control library is not determined until that time. If a user makes an
error while entering the module name in the PRINT/SETUP command, the
job may not print. To reduce the chance of user errors occurring when the
PRINT/SETUP command is entered, DIGITAL recommends that system
managers use the DEFINE/FORM/SETUP command to assign a library
module to a specified form. Once a form is properly defined, then use
the PRINT/FORM command to set up the printer for the specified printer
function.
Warning: If you enter an erroneous module name while issuing the PRINT/SETUP
command, the print symbiont writes an error message to the output
device stating that the module does not exist, and the print job fails to
print and may be lost. By default, jobs are NOT retained in an output
queue. (See Section 9.5.1 for information on retaining jobs.)
To reset the printer device to a known state at the end of each job, you use
the /SEPARATE=RESET qualifier when the queue is initialized, for example:
$ INITIALIZE/QUEUE/LIBRARY=MYDEVCTL/SEPARATE=RESET=M0DULE2 ELF.QUE

The RESET keyword sets up the printer according to the reset sequence
contained in the specified device control module. You can use the
/SEPARATE=RESET qualifier with the INITIALIZE/QUEUE, START/QUEUE
or SET QUEUE command. In addition to outputting the RESET sequence at
the end of each job, the RESET modules are also output when the queue is
started. This ensures that the first job will be correctly printed.
Example 9-1 shows a sample session in which device control library modules
are used to process a print job. In this session, two device control modules
are created and inserted into the library file MYDEVCTL.TLB, a print job
(REPORT.TXT) is processed using the MODULE 1 setup, and at the end of the
job, the printer is reset to the MODULE2 setup.
Example 9-1

Using Device Control Library Modules to Process
a Print Job

$ LIBRARY/CREATE/TEXT SYS$LIBRARY:MYDEVCTL.TLB
$ CREATE MODULE1.TXT
tenter printer escape sequences or text for modulel
ttype CTRL/Z to EXIT
$ CREATE M0DULE2.TXT
tenter printer escape sequences or text for module2
ttype CTRL/Z to EXIT
$
$
$
$
$

LIBRARY/INSERT SYS$LIBRARY:MYDEVCLT.TLB/TEXT M0DULE1
LIBRARY/INSERT SYS$LIBRARY:MYDEVCLT.TLB/TEXT M0DULE2
INITIALIZE/QUEUE/START/0N=TTA9/LIBRARY=MYDEVCTL ELF.QUE
SET QUEUE/SEPARATE=RESET=M0DULE2 ELF.QUE
SHOW QUEUE/FULL ELF.QUE

Terminal queue ELF.QUE, on TOAD::TTA9
/BASE_PRI0RITY=4 /DEFAULT*(FEED) /FORM*DEFAULT /LIBRARY=MYDEVCTL
/OWNER*[1,4] /PROTECTION*(S:E,0:D,G:R,W:W) /SEPARATE=RESET=(M0DULE2)
$ DEFINE/F0RM/SETUP=M0DULE1 F0RM1 1
$ PRINT/F0RM=F0RM1 REPORT.TXT/QUEUE=ELF_QUE
Job REPORT (Queue ELF.QUE, entry 619) started on ELF.QUE
$

9-28

Using the Batch/Print Facility

9.7.3

Restricting Jobs by Size
In some cases you may want to restrict print job processing to jobs of a certain
size. You can impose limits on the size of jobs that can be printed on a queue
by specifying the /BLOCK_LIMIT qualifier with the INITIALIZE/QUEUE,
START/QUEUE, or SET QUEUE command. The /BLOCK_LIMIT qualifier
has the following format:
/ [NO]BLOCK_LIMIT=([lower][.upper])

To impose block size limits, you must specify at least one of the following
parameters:
Parameter

Description

lowlim

A decimal number referring to the minimum number of blocks

that can be scheduled for processing by the queue. If a print job
is submitted that contains fewer blocks than the lowlim value,
the job remains pending until the block limit for the queue is
changed. By default there is no lower limit on job size.
uplim

A decimal number referring to the maximum number of blocks
that can be scheduled for processing by the queue. If a print job
is submitted that exceeds this value, the job remains pending
until the block limit for the queue is changed. By default there is
no upper limit on job size.

The /BLOCK_LIMIT qualifier is useful when you want to limit processing on
a queue to either small or large jobs. By default, there are no limits on file
size for a queue. (For a complete description of the /BLOCK —LIMIT qualifier,
see the VAX/VMS DCL Dictionary.)
In the following example, processing on a printer queue LPBO is limited to
large jobs:
$ INITIALIZE/QUEUE/ON=LPBO/BLOCK_JLIMIT*(500.M M) LARGE

Jobs smaller than 500 blocks will not execute from queue LPBO. It is reserved
for jobs larger than 500 blocks.
Warning: If you specify a single value for n in the qualifier /BLOCK_LIMIT=n, the
value is interpreted as the upper limit for that queue.

9.7.4

Restricting Jobs by Characteristics
You can restrict job processing on a queue by assigning specific characteristics
to the queue. You specify the printer characteristics of an output execution
queue with the /CHARACTERISTIC qualifier of the INITIALIZE/QUEUE,
START/QUEUE, or SET QUEUE command. This qualifier can also be used to
assign characteristics to batch queues.
When users include the /CHARACTERISTICS qualifier with a PRINT or
SUBMIT command, the characteristics must by identical or a subset of those
specified for the queue. However, a queue with no characteristics defined
will still execute a job that has characteristics specified on the command
line. For example, if a job is associated with characteristic 25, it can execute
either in a queue with characteristic 25 or in a queue with no characteristics
defined. If the characteristics for a job do not match the characteristics
defined for a queue, the job remains pending until a queue with matching or
no characteristics becomes available.
9-29

Using the Batch/Print Facility

Note: Users need not specify every characteristic of a queue when they issue a
PRINT or SUBMIT command, as long as the characteristics specified are a
subset of those set for the queue.
To specify the printer characteristics of an output execution queue, use the
/CHARACTERISTIC qualifier of the INITIALIZE/QUEUE, START/QUEUE,
or SET QUEUE command in the following format:
/[NO]CHARACTERISTIC-(characteristic[,...])

A characteristic can be a number, a name, or both. You define a characteristic
name and assign it a corresponding number with the DCL command DEFINE
/CHARACTERISTIC. This command is restricted to users with OPER
privilege. Issue the DEFINE/CHARACTERISTIC command in the following
format:
DEFINE/CHARACTERISTIC name number

The following example defines the characteristic name RED_INK and the
corresponding number 3:
$ DEFINE/CHARACTERISTIC RED_INK 3

Subsequent INITIALIZE/QUEUE, START/QUEUE, SET QUEUE, and PRINT
commands can use the number 3 or the name RED_INK to describe one
printer characteristic.
To delete a defined characteristic, issue the DCL command DELETE
/CHARACTERISTIC, for example:
$ DELETE/CHARACTERISTIC RED_INK 3

By default, a queue or job has no characteristics defined. To find out if the
queues on your system have characteristics defined, issue the DCL command
SHOW QUEUE/CHARACTERISTICS.

9.7.5

Restricting Jobs by Form
A more versatile method of restricting print job processing is by form. A form
may be defined with the following attributes: width, length, truncate, wrap,
margin, page setup, form setup, sheet feed, stock, and description. To find
out what forms are available on your system, issue the DCL command SHOW
QUEUE/FORM, as shown in this example:
$ SHOW QUEUE/FORM/FULL
Form name
DEFAULT
/LENGTH=66

Number

Description

0
System-defined default
/MARGIN*(B0TT0M=6) /STOCK=DEFAULT /TRUNCATE /WIDTH*132

LN01.P0RTRAIT
(stock=DEFAULT) 106
80 by 60 (portrait)
/LENGTH=60
/SETUP*(LN01_P0RTRAIT) /ST0CK=DEFAULT /WIDTH*80
LETTER (stock=DEFAULT)
110
LN03 indented memo format
/LENGTH*64 /MARGIN*(T0P=2,LEFT=5) /STOCK=DEFAULT /TRUNCATE /WIDTH=80

This command produces a listing of all of the forms available on your system,
their names, numbers, and associated attributes.
To restrict print jobs by form, you use the /FORM-MOUNTED qualifier of
the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE command, in the
following format:
/F0RM_M0UNTED=type

9-30

Using the Batch/Print Facility

Mounting a form on a queue associates the stock of the form with the output
queue. Before you mount a form on a queue, you must first define the form,
using the DEFINE/FORM command.
9.7.5.1

Defining a Print Form
You define a form by issuing the DCL command DEFINE/FORM. This
command is restricted to users with OPER privilege. A form definition can
include a name, a corresponding number, and optional form characteristics.
The DEFINE/FORM command uses this format:
DEFINE/FORM name number [/qualifiers]

The command in the following example defines the form name CHECKS as
the number 3 and defines the margins for the form:
$ DEFINE/FORM=CHECKS 3/ST0CK=DEFAULT _$ /MARGIN=(B0TT0M=3.T0P=3.LEFT=6,RIGHT=6)

In this example, /FORM=CHECKS is interpreted to be the same as /FORM=3.
Note that you cannot abbreviate the form name.
By specifying additional qualifiers with the DEFINE/FORM command, you
can define the following characteristics for a particular form type:
•

A specific image area for the form

•

A type of paper stock

•

Specific device control modules

•

Print job processing attributes

The /STOCK qualifier of the DEFINE/FORM command allows you to
associate a type of paper stock with a particular form. This qualifier is
useful when you have several forms that use the same paper stock, but differ
in other ways, such as margin specifications, wrapping, or page dimensions.
If you do not specify a stock name with the DEFINE/FORM command, the
form name becomes the default value of the /STOCK qualifier.
Note: A print job can execute on a queue only if the stock of the form associated
with the job is identical to the stock of the form mounted on the output
queue. If the stocks do not match, the job remains pending until they are
made identical.
In the following example, the print job would remain pending, because the
stocks of the two forms are not identical:
$
$
$
$

DEFINE/FORM=LETTER 5/ST0CK=LQR_36
DEFINE/FORM=MEMO 6/ST0CK=LTH_2
SET QUEUE/FORM_MOUNTED=MEMO PRINT.QUE
PRINT/QUEUE=PRINT_QUE/F0RM=5 MYJ0B.DAT

In this example, the command PRINT/FORM=5 associates the form type 5,
with the print job MYJOB.DAT. The stock of the form mounted on the queue
(form type 6) does not match the stock of the form associated with the job
(form type 5), therefore the job remains pending until the stock of the two
forms are made identical.
To delete a defined form, issue the DCL command DELETE/FORM in the
format:
DELETE/FORM form_name

For a detailed description of the DEFINE/FORM command and its qualifiers,
see the VAX/VMS DCL Dictionary.
9—31

Using the Batch/Print Facility

9.7.5.2

Changing the Systemwide Default Form
The VAX/VMS system supplies a systemwide default form named DEFAULT,
which corresponds to the form number 0. The DEFAULT form has the
following attributes:
Form name

Number

Description

DEFAULT
0
System-defined default
/MARGIN®(B0TT0M=6) /STOCK=DEFAULT /TRUNCATE /WIDTH=132

The default form for both queues and print jobs is form number 0. The stock
is the system-supplied default stock. To change the systemwide default, issue
the following command:
DEFINE/FORM DEFAULT 0 attribute.qualifier[s]

For example, to change the systemwide default form's bottom margin from 6
to 4, and the page length from 66 to 55, issue this command:
$ DEFINE/FORM DEFAULT 0 /MARGIN®(B0TT0M=4) /LENGTH®55

A queue initialized without a specific /FORM—MOUNTED or
/DEFAULT=FORM=type qualifier uses the systemwide default form to process
print jobs not explicitly associated with a form definition. See Section 9.7.7
for information on how to change the default form for a specific output queue.

9.7.5.3

Using the PRINT Command to Specify a Form
In addition to associating forms with specific queues, you can also use the
PRINT/FORM command to associate a form with a specific job. You must
define the form type using the DEFINE/FORM command prior to issuing the
PRINT command.
When you issue the DCL command PRINT/FORM=type, the print job is
processed according to the attributes associated with that form.

Note: The PRINT/FORM=type command overrides the default form established
for the queue.
A job submitted without an explicit form definition (that is, the PRINT
command is issued without the /FORM qualifier) is processed with the
default form for the queue. (See Section 9.7.7 for information on specifying a
default form for a queue.)

9.7.6

Specifying Mandatory Queue Attributes
You can control certain print job processing attributes by assigning job
separation features to the queue. Unlike default print control features
(discussed in Section 9.7.7), job separation features cannot be overridden
by the PRINT command.
The three mandatory separation pages include: job burst, job flag, and job
trailer pages. Most sites will use only a subset of the available separation
pages at a given time. Figure 9-1 shows the output of typical job flag and job
burst pages. Figure 9-2 shows the output of a typical trailer page.
You assign job separation features to a queue by specifying the /SEPARATE
qualifier with the INITIALIZE/QUEUE, START/QUEUE, or SET QUEUE
command. The /SEPARATE qualifier has the following format:
/[NO]SEPARATE®(option [,...])

9-32

Using the Batch/Print Facility

Figure 9-2

Job Trailer Page

FILE TRAILER PAGE
(IF SET FOR QUEUE)
OR LAST PAGE OF
JOB CONTENT

JOB SEPARATOR
TRAILER PAGE

You assign job separation features by specifying one or more of the following
options of the /SEPARATE=(option[, . . . ]) qualifier:

9-34

Option

Description

[NOjFLAG

Specifies that a job flag page is printed
at the beginning of each job.

[NOjBURST

Specifies that a job burst page and a job
flag page are printed at the beginning of
each job.

[NO]RESET=(module[, . . . ])

Specifies one or more device control
library modules that contain the job
reset sequence for the queue. The
specified modules from the queue's
device control library (by default
SYS$LIBRARY:SYSDEVCTL) are used
to reset the device each time a job reset
occurs. The RESET sequence occurs
after any file trailer and before any job
trailer. Thus, all job separation pages
will be printed when the device is in its
RESET state.

Using the Batch/Print Facility

Option

Description

You should assign the RESET job
separation feature to queues for printers
that support characteristics changeable
by the DCL command PRINT/SETUP. The
RESET feature ensures that any SETUP
features specified for a particular job are
not assigned to the next job.
[NOjTRAILER

Specifies that a job trailer page is printed
at the end of each job.

By default, no job separation features are assigned to the queue. For more
information on the /SEPARATE options, see the VAX/VMS DCL Dictionary.
Widths greater than 40 characters and less than 200 characters, and lengths of
any size greater than 40 characters are supported for file and job separation
pages. Pages requested for widths greater than 200 characters are formatted
and printed at 200-character widths. Lengths less than 40 characters are
extended by that form length until the 40-character threshold is exceeded.
Margins are not taken into account when formatting separation pages.
Note: All separation pages format information to the width and length of a
VAX/VMS default form size of 80 characters by 51 lines. Information,
therefore, may be truncated, depending on the form sizes you specify. See
Section 9.7.8 for information on controlling line and page overflow.
Table 9-4 gives a detailed description of the characteristics of job separation
pages.
Table 9-4

Job Separation Pages

Page

Characteristics

Job Flag/Burst

Indicates that a new job follows; the job may include one
or more files. Items include:
•

Header bar: single-segment bar composed of the
following elements:
-

Rows of a repeated numeral indicating the
sequence of the job in the printer queue

An embedded text string specified by defining
the PSM$ANNOUNCE system logical name. The
length of the string is limited to one form width. If
PSMSANNOUNCE is not defined, the default text
string is "Digital Equipment Corporation" followed
by the system version number. ("Digital Equipment
Corporation" is abbreviated to "DEC" for shorter
form widths.)

9-35

Using the Batch/Print Facility

Table 9-4 (Cont.)

Job Separation Pages

Page

Characteristics
•

Note: Users may specify a string up to 255 characters
in length with the /NOTE qualifier of the DCL command
PRINT

•

Identification banner for the process submitting the
job; includes user name, job name, and job number

•

Job sentence indicating the following information:

•

Job Trailer

Job name and number

Name of queue to which job was submitted

Submission date and time

Process username, UIC, and account

Job priority

Print device name

Job start time

Execution queue name

Footer bar: identical to the header bar with the
exception that the definition of the system logical
name (PSM$ANNOUNCE) is not used as the embedded
string. The default text is always used as the
embedded string.

Indicates the end of a print job; items include:
•

Header bar: three-segment bar composed of the
following elements:
-

Central segment with "END OF JOB" banner

Flanking segments with job-sequence numeral

•

Identification banner for the process submitting the
job; includes job name and job number

•

Receipt box with the signoff fields: Received;, Date:,
and Operator:

•

Job sentence

•

Ruler

Note: If you request job burst and file burst pages, a separation burst bar (with
the characters VAX/VMS) is printed over the page crease between the job
flag and job burst pages, and between the file flag and file burst pages,
respectively. This facilitates the separation of job and file printouts.

9-36

Using the Batch/Print Facility

9.7.7

Specifying Default Queue Attributes
You can control the default processing attributes of a queue by specifying the
/DEFAULT qualifier of the INITIALIZE/QUEUE, START/QUEUE, or SET
QUEUE command. For example, you can establish a default form type for a
specific queue, and specify the default file separation pages. The /DEFAULT
qualifier has the following format:
/[NO]DEFAULT=(option[,...])

The following default options are available:
Option

Description

[NO]BURST[=value]

Controls whether a file flag and burst page is
printed preceding output. If you specify the value
ONE, a flag and burst page is printed once with the
first file in the job. If you specify the value ALL, a
flag and burst page is printed with each file in the
job.

[NO]FEED

Controls whether a form feed is automatically
inserted at the end of a page.

[NO]FLAG[=value]

Controls whether a file flag page is printed
preceding output. If you specify the value ONE, a
flag page is printed once with the first file in the
job. If you specify the value ALL, a flag page is
printed with each file in the job.

FORM=type

Specifies the default form for a printer, terminal,
or server queue. If a job is not submitted with an
explicit form definition, then this form will be used
to process the job. The systemwide default form
(DEFAULT,0) is the default value for this keyword.

[NO]TRAILER[=value]

Controls whether a file trailer page is printed
following output. If you specify the value ONE, a
trailer page is printed once with the last file in the
job. If you specify the value ALL, a trailer page is
printed with each file in the job.

The value ALL is the default value for options that require a value of ALL
or ONE. Figure 9-3 shows the output of typical file flag and file burst pages.
Figure 9-4 shows the output of a typical file trailer page.

9-37

9-38

Using the Batch/Print Facility

Figure 9—4

File Trailer Page

FILE SEPARATOR
TRAILER PAGE

JOB CHARACTERISTICS
FILE AND JOB
INFORMATION

Table 9-5 gives a detailed description of the characteristics of file separation
pages.

9—39

Using the Batch/Print Facility

Table 9-5

File Separation Pages

Page

Characteristics

File Flag/Burst

Indicates that a print file follows. The file may include one
or more of the following items:
•

9-40

Header bar: three-segment bar composed of the
following elements:
-

A central segment identical to the job header bar

Flanking segments with rows of a repeated
character indicating the sequence of the file in
the job

•

Note: Users may specify a string up to 255 characters
in length using the /NOTE qualifier of the DCL
command PRINT

•

Identification banner for the process submitting the
job: user name, file name

•

File sentence: indicates the following information:
-

Full file specification, including device and
directory, file name, type, version, and revision
time and date

File size in blocks

File organization

File owner's UIC

File record characteristics: record type, carriage
control, size of longest record

•

Job sentence

•

Footer bar: identical to header bar except that the
embedded text string is "Digital Equipment Corporation
- Version Vn.n"

Using the Batch/Print Facility

Table 9-5 (Cont.)

File Separation Pages

Page

Characteristics

File Trailer

Indicates the end of a print file. Items include:
•

Header bar: five-segment bar composed of the
following elements:
-

Central segment with "END OF FILE" banner

Inner flanking segments with job-sequence numeral

Outer flanking segments with file-sequence
character

•

Identification banner for the process submitting the
job; includes user name, file name

•

Qualifier phrase: indicates the print, queue, and
form qualifiers active when the job was submitted;
nonactive qualifiers (except /NORECORD_BLOCKING
and /NOFEED) are not included

•

File sentence

•

Job sentence

•

Footer bar identical to file flag/file burst footer bar

•

Ruler: a sequence of numbers counting to the end of
the form

You can change the default form type for a specific output queue by using the
/DEFAULT=FORM=type option of the DCL command INITIALIZE/QUEUE,
START/QUEUE, or SET QUEUE. The new default form must first be defined
using the DEFINE/FORM=type command. The stock of the default form must
be identical to the stock of the mounted form, or any job submitted without
an explicit form will enter a pending state until they are made identical.
To find out the default form for a particular queue, issue the DCL command
SFiOW QUEUE/FULL, as shown in this example:
$ SHOW QUEUE/FULL LN01.PRINT
Printer queue LN01.PRINT, on ALPHA::ALPHA_LCAO, mounted form STANDARD (stock=8xll)
/BASE_PRI0RITY=4 /DEFAULT3(FEED.FLAG.FORM=REPORT(stock38xl1).TRAILER=ONE)
/NOENABLE.GENERIC Lowercase /OWNER3[1,4] /PROTECTION3(S:E,0:D.G:R,W:W)

In this example, the default form is named REPORT and the stock is named
8x11. The stock of the default form matches the stock of the mounted form.
All jobs not associated with an explicit form definition will be associated with
the form named REPORT by default. Since the stock of the form STANDARD
matches the stock of the default form REPORT, all jobs submitted to this
queue without an explicit form definition will be processed.

9—41

Using the Batch/Print Facility

9.7.8

Controlling Page and Line Overflow
You can use form definitions to control page and line overflow. Different
forms may have different right, left, top, and bottom margin settings. By
using forms to control page and line overflow, users can switch from one
form to another without requiring operators to stop the queue, alter the
device setup, and restart the queue. Forms with the same value for the
/STOCK qualifier are automatically mountable without operator assistance.
You control line overflow by using the following qualifiers to the DCL
command DEFINE/FORM:
Qualifier

Function

/[NOJTRUNCATE

Specifies that data in the right margin be discarded. The
default is /TRUNCATE. If you specify /TRUNCATE, you
cannot specify /WRAP; the /TRUNCATE qualifier forces
/NOWRAP.

/[NOJWRAP

Specifies that a carriage return and line feed be inserted
when the right margin is exceeded. The default is
/NOWRAP. If you specify /WRAP, you cannot specify
/NOTRUNCATE.

Page overflow errors are handled by the /DEFAULT=FEED option of the
following commands:
INITIALIZE/QUEUE
START/QUEUE
SET QUEUE
PRINT/[NO]FEED
This qualifier controls whether a formfeed character is automatically inserted
when the symbiont detects entry into the bottom margin area.
DIGITAL recommends that you control line and page overflow by using form
definitions. To do this, you must set terminals and printers to avoid wrapping
or truncating the print line at the physical limits of the device.
Note: The device driver operates on settings for the /TRUNCATE and /WRAP
qualifiers specified with the DCL commands SET PRINTER and SET
TERMINAL only after the print symbiont has finished formatting data.
You can use the /PASSALL qualifier with the PRINT command to bypass all
formatting performed by the print symbiont. The default is /NOP ASS ALL.
You should use this qualifier in cases where the print symbiont formatting
may interfere with the desired formatting of the file. The /PASSALL qualifier
sends I/O to the device driver with all formatting suppressed, and behaves as
follows:

9-42

•

Does not interpret FORTRAN or print carriage control characters

•

Does not perform line or page overflow error handling

•

Does not interpret escape sequences

Using the Batch/Print Facility

9.7.9

Setting Up Logical Queues
A logical queue performs the same function as a generic output queue, except
that a logical queue can direct jobs only to a single printer, terminal, or server
execution queue. Jobs sent to a logical queue are held until the logical queue
is assigned to an output execution queue and both queues are started. Logical
queues can be used, for example, to hold print jobs of low-priority users for
printing during off-peak hours.
You assign a logical queue to an output execution queue with the DCL
command ASSIGN/QUEUE. This command is restricted to users with OPER
privilege or E access to the queues.
Inserted in a command procedure, the following commands initialize and start
the printer queue LPAO and initialize the logical queue named HOLD_QUE:
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG
$ INITIALIZE/QUEUE HOLD_QUE

LPAO:

Jobs sent to the printer queue LPAO are queued for printing. However, any
jobs sent to the logical queue HOLD_QUE are held until HOLD_QUE is
assigned to LPAO and started (normally from command level) as follows:
$ ASSIGN/QUEUE LPAO:
HOLD.QUE
$ START/QUEUE HOLD.QUE

To deassign the logical queue in the example above, use the following
procedure:
1

Stop the logical queue by specifying the STOP/QUEUE/NEXT command.

Deassign the logical queue by specifying the DCL command
DEASSIGN/QUEUE.

The following commands deassign the logical queue HOLD_QUE:
$ STOP/QUEUE/NEXT H0LD_QUE
$ DEASSIGN/QUEUE HOLD.QUE

The VAX/VMS DCL Dictionary describes the DEASSIGN/QUEUE command
in detail.

9.7.10 Setting Up Generic Output Queues
When print jobs are sent to a generic output queue, they are held there until
one of the assigned printer or terminal queues becomes available. Generic
output queues are useful because they distribute the processing of print jobs
among devices that are of the same type. Figure 9-5 illustrates a generic
output queue.

9-43

Using the Batch/Print Facility

Figure 9-5

Generic Output Queue

JOB
225
/
JOB
250

JOB
249

JOB
240

/ PRINTER QUEUE LPAO

/
/
/

GENERIC PRINTER
QUEUE SYS$PRINT

<
\
\

ZK-1308-83

If your system has more than one line printer of the same type, you should
create at least one generic output queue. Since print jobs submitted with the
PRINT command are sent to the queue SYS$PRINT by default, you should
establish SYS$PRINT as a generic queue, assigning to it printers that perform
basic print operations.
You establish a generic queue by specifying the /GENERIC qualifier with
either the INITIALIZE/QUEUE or START/QUEUE command. See the
VAX/VMS DCL Dictionary for a description of how the /GENERIC qualifier is
used with these commands.
Note: The /DEFAULT, /FORM-MOUNTED, and /SEPARATE qualifiers
are not meaningful for generic output queues. Consequently, the DCL
commands INITIALIZE/QUEUE and START/QUEUE will reject these
qualifiers if /GENERIC is also specified. If the attributes of an established
generic output queue are modified, these three qualifiers may be accepted.
However, they have no effect on the operation of the generic queue.
With the /GENERIC qualifier, you can assign a printer queue to a generic
output queue by one of the following methods:

9-44

•

Default—Using this method, you do not specify a queue name parameter.
Instead, any output execution queue that has generic printing enabled and
is of the same type (either printer, terminal, or server) is assigned to the
generic output queue by default.

•

Explicit—With this method, you specify the name of an output execution
queue (either printer or terminal) as a parameter.

Using the Batch/Print Facility

9.7.10.1

Assigning Generic Output Queues by Default
On systems with a small number of printers, you should use the default
function of the /GENERIC qualifier to establish a generic output queue. With
this method, you specify the /GENERIC qualifier without specifying any
queue name parameters, and all output execution queues that are enabled for
generic printing are assigned to the generic output queue.
Output execution queues are enabled for generic printing by default when
they are initialized.

Note: Output execution queues for line printers that are in remote locations,
that use special forms, or that possess unique printer characteristics
should be set up with generic printing DISABLED, to exclude them from
accepting jobs from a generic output queue.
The qualifier /NOENABLE—GENERIC, when used with the INITIALIZE
/QUEUE, START/QUEUE, or SET QUEUE commands, disables generic
printing on an output execution queue.
The following command procedure creates four different printer queues,
including a generic output queue:
$
$
$
$

INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO:
INITIALIZE/QUEUE/START/NOENABLE.GENERIC LPCO:
INITIALIZE/QUEUE/START/GENERIC SYS$PRINT

In this procedure, since no queue names were specified with the /GENERIC
qualifier, only the queues that have generic printing enabled by default, LPAO
and LPBO, are assigned to the generic queue SYS$PRINT. The queue LPCO is
not assigned to the generic output queue because generic printing is explicitly
disabled.
There is no advantage to creating more than one generic output queue by
using the default method, since all printer queues with generic printing
enabled are assigned to the generic queue. Again, on systems with only a
few printers that are of the same type, the default method is adequate. On
larger systems with many different types of printers, the default method is
not recommended.
Using the default method, you can assign to a generic queue only one type of
output execution queue, either printer queues or terminal queues, not both.
To establish a generic terminal queue, specify the /TERMINAL qualifier
along with the /GENERIC qualifier. If you want to set up a generic output
queue that serves both printer and terminal queues, you must use the explicit
assignment method described in the next section.

9.7.10.2

Assigning Generic Output Queues Explicitly
On systems with a large number of printers of many different types, you
should explicitly assign printer queues to a generic output queue using the
/GENERIC qualifier. The /GENERIC qualifier accepts a list of the queues.
The following command procedure creates four different printer queues,
including a generic output queue:
$
$
$
$

INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO:
INITIALIZE/QUEUE/START/DEFAULT=(FLAG.TRAILER.NOFEED)
LPCO:
INITIALIZE/QUEUE/START/GENERIC=(LPAO:.LPBO:)
SYSIPRINT

9-45

Using the Batch/Print Facility

In this procedure, the printer queues LPAO and LPBO are assigned to the
generic output queue SYS$PRINT. The printer assigned to LPCO uses special
forms and is not suited for general printing. Therefore, it is not assigned
to the generic output queue SYS$PRINT. Print files queued by default to
SYS$PRINT are printed on whichever assigned printer (either LPAO or LPBO)
is free.
By specifying a list of queue names with the /GENERIC qualifier, you can
assign printer queues, terminal queues, or both to a generic output queue.
This method also allows you to create more than one generic output queue.
For example, you may want to create a separate generic output queue for each
set of printers having similar characteristics:
$
$
$
$
$
$

INITIALIZE/QUEUE/START/DEFAULT=FLAG LPAO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG LPBO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG LPCO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG TTD5
INITIALIZE/QUEUE/START/GENERIC=(LPAO:.LPBO:)
SYS$PRINT
INITIALIZE/QUEUE/START/GENERIC-(LPCO:,TTD5)
SMALLFORM

This command procedure creates two generic output queues, SYS$PRINT
for routine print jobs, and SMALLFORM for print jobs requiring special size
forms. Here it is assumed that printer queues LPCO and TTD5 are set up for
special form jobs.

9.7.11 Setting Up Spooled Devices
Spooling is the technique of using an intermediate storage device (such as a
disk) to buffer data passing between low-speed I/O devices and high-speed
memory. Establishing spooled devices is useful for increasing throughput and
balancing the I/O demands of a system. As a rule, programs demand input
and produce output at irregular intervals during their execution. If programs
were allowed to read directly from fast devices and to write directly to slow
devices, the throughput would be limited by the speed of the slow devices. If
a process were to output data directly to a printer, the process would be tied
up for the time it took to print the listing. Also, other processes needing the
printer would have to wait until the current process completed.
Output spooling makes output from the processor available for transmission
to a spooled device (such as a line printer) by placing the output into files
on an intermediate device (such as a disk). Output spooling is used to create
temporary files on disk. After they are spooled to disk, these files are queued
for printing.
Note: 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 spooled output.
You establish a printer as a spooled device by using the DCL command SET
DEVICE/SPOOLED in the following format:
SET DEVICE/SPOOLED[=(queue-name[:].intermediate-disk-name[:])]

This command is restricted to users with the OPER privilege. The VAX/VMS
DCL Dictionary describes the SET DEVICE command in detail. For each
output spooled device, you can use the SET DEVICE command to specify
both the printer queue to which spooled files are queued and an intermediate
device to which spooled files are written. By default, the queue name is
the same as the printer device name. The intermediate device name is the
translation of the logical name SYS$DISK. The name is translated when you
issue the command SET DEVICE/SPOOLED.
9—46

Using the Batch/Print Facility

You should always specify the intermediate disk and queue explicitly.
Whenever a file is copied to a spooled device, it is queued for printing on
the queue specified by the SET DEVICE command when the file is closed. If
you assign a spooled device to a generic queue, a job output to that device is
sent to the generic queue, which in turn places the job in one of its assigned
queues. As a result, a job copied to LPAO, for example, may not necessarily
print on the printer LPAO, but instead may print on one of the other devices
assigned to the generic queue.
Note: 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.
The following example gives the steps for setting up a typical spooled device
configuration for a system with one line printer:
$ SET PRINTER/LOWER LPAO:
$ SET DEVICE/SPOOLED=SYS$PRINT LPAO:
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPAO: SYS$PRINT

(See Section 9.7.12.1 for more information on setting up a single-printer
configuration.)
Caution: After establishing a device as spooled, you should test the device,
since errors in disk or queue names are not detected until spooling is
attempted. To test a spooled device, use a command procedure similar to
the following:
j
*****testing spooled device***
$ SET DEVICE/SPOOLED=(SYSlPRINT,SYS$SYSDEVICE:) LPAO:
$ CREATE TEST.LIS
!Add the first test record here.
!CTRL/Z to exit the file
$ COPY TEST.LIS LPAO:
$ EXIT

You set up devices for spooling by entering the appropriate commands in
your site-specific command procedure (SYSTARTUP.COM). At a minimum,
you should see that at least one line printer is set spooled when the system
is booted. In a system with only one line printer, the spooled printer will
be the default system printer. Depending on system configuration and
anticipated operational needs, more spooled devices can be established at
startup. Moreover, in the course of operations (to meet special 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, as necessary, use the SET DEVICE command with the
/NOSPOOLING qualifier to disable spooling to spooled printers and
terminals; however, you must stop the corresponding queues before you
can change the spooling status.

9-47

Using the Batch/Print Facility

9.7.12 Guidelines for Setting Up Queues for Spooled Line Printers
The guidelines in this section apply to line printers in a single-node
environment. In a cluster environment, clusterwide queues are established
to control print job processing. The Guide to VAXclusters provides a detailed
description of how to set up printer queues for line printers in a cluster
environment.
The following guidelines are useful in setting up printer queues for spooled
line printers and terminals used as printers:
•

Specify the proper characteristics for each printer with the DCL command
SET PRINTER. (The VAX/VMS DCL Dictionary describes the SET
PRINTER command in detail.)

•

Control line overflow with the /TRUNCATE and /WRAP qualifiers of
the DCL command DEFINE/FORM. The form controls the line and page
overflow, therefore, set the printer or terminal width and length to the
physical limits of the device. (See Section 9.7.8 for more information on
these qualifiers.)

•

Spool the device with the DCL command SET DEVICE/SPOOLED.

•

To produce output on a spooled line printer, initialize a printer queue with
the same name as the spooled printer and start that queue. You can also
assign a queue a name that is different from the printer's physical device
name by using the /ON qualifier with the INITIALIZE command (see
Section 9.7.1).

•

Assign one printer queue the name SYS$PRINT. For systems with one
printer, assign that printer's queue the name SYS$PRINT. If more than
one line printer is on the system, make at least one printer queue a generic
queue and assign it the name SYS$PRINT. Section 9.7.10 describes how
to establish generic output queues.

The next three sections illustrate some of the most common arrangements of
output execution queues and spooled line printers.

9.7.12.1

Single-Printer Configuration
Figure 9-6 illustrates a typical spooling and queuing configuration for a
system with one line printer. The following commands in your site-specific
SYSTARTUP.COM procedure produce the results listed below:
$ SET PRINTER/LOWER LPAO:
$ SET DEVICE/SPOOLED=SYS$PRINT LPAO:
$ INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPAO: SYSlPRINT

The characteristics of LPAO are set.

2 The line printer LPAO is set spooled.
3 A printer queue for LPAO is initialized, started, and assigned the name
SYS$PRINT.

4 All print jobs are placed by default in a queue named SYS$PRINT and are
printed from that queue.

9-48

Using the Batch/Print Facility

Figure 9-6

Setting Up a Printer Queue on a System with One
Printer

COMMANDS
$ SET DEKf ICE/SPOGLED::::LPA0 LPAO
$ A S SIG N / S Y S T E M L P A 0
S Y S * P RIN T
$ INITIA LIZ E / GIJ E U E / F L A G
I... P A 0
$ START/QUEUE
LPAO

Queue

Line Printer

SYSSPRINT
Default Print
Queue

LPAO
ZK-1005-82

9.7.12.2

Two-Printer Configuration
Figure 9-7 illustrates a typical spooling and queuing configuration for
a system with two line printers that have the same characteristics. The
following commands produce the results listed below:
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$

!
! Set printer characteristics, set LPAO spooled,
! and set up queue PRINT.A.
!
SET PRINTER/LOWER LPAO:
SET DEVICE/SPOOLED=SYS$PRINT LPAO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPAO: PRINT.A
!
! Set printer characteristics, set LPBO spooled,
! and set up queue PRINT_B.
!
SET PRINTER/LOWER LPBO:
SET DEVICE/SPOOLED=SYS$PRINT LPBO:
INITIALIZE/QUEUE/START/DEFAULT=FLAG/ON=LPBO: PRINT.B
!
! Set up the generic queue SYS$PRINT
!
INITIALIZE/QUEUE/START/GENERIC SYS$PRINT

The characteristics of device LPAO are set.

2 The line printer LPAO is set spooled.
3

The printer queue PRINT__A is initialized and started.

The characteristics of device LPBO are set.

The line printer LPBO is set spooled.

The printer queue PRINT—B is initialized and started.

7 The generic queue SYS$PRINT is initialized and started and assigned the
printer queues PRINT_A and PRINT_B by default (see Section 9.7.10.1).
9-49

Using the Batch/Print Facility

Print jobs sent with an explicit queue name entered in the PRINT
command line are placed in the queue for the specific printer.

Print jobs sent without specifying a queue name in the PRINT command
are placed by default in the generic queue SYS$PRINT. Jobs are then
scheduled for processing in PRINT_A or PRINT_B, depending on which
print device is available.

1 0 Spooled print files destined for either device LPAO or LPBO are placed
in the generic queue SYS$PRINT, which is associated with both printers.
From the generic queue, these jobs are printed on whichever printer is
available. (Alternatively, you could set the devices spooled and assign
each device the queue name that is associated with that device, thus
ensuring that jobs will print on the same printer to which the file was
spooled.)
Figure 9-7

Setting Up Printer Queues on a System with Two
Printers

COMMANDS
$
$
$
$
$
$
$
$

SET DEMICE/SPOOLED=SYS$PRINT LPAO
SET DEUICE/SPOOLED=SYS$PRINT LPBO
INITIALIZE/QUEUE/FLAG/GENERIC SYS$PRINT
START/QUEUE SYS$PRINT
INITIALIZE/QUEUE/FLAG LPAO
START/QUEUE LPAO
INITIALIZE/QUEUE/FLAG LPBO
START/QUEUE LPBO

Queues

9-50

Line Printers

Using the Batch/Print Facility

9.7.12.3

Three-Printer Configuration
Figure 9-8 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 9-8 is basically the same
as the one in Figure 9-7, except that the spooled printer LPCO has been
added and queue PRINT—C has been initialized and started. Because of the
special forms, unique characteristics, or the remote location, printer LPCO is
not suited for general printing. Thus, the following commands produce the
same results as those listed in Figure 9-7, with noted exceptions:
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$
$

•
! Set printer characteristics, set LPAO spooled,
! and set up queue PRINT_A.
!
SET PRINTER/LOWER LPAO:
SET DEVICE/SPOOLED=SYS$PRINT LPAO:
INITIALIZE/QUEUE/DEFAULT=FLAG/START/ON*LPAO: PRINT_A
!
! Set printer characteristics, set LPBO spooled,
! and set up queue PRINT_B.
!
SET PRINTER/LOWER LPBO:
SET DEVICE/SPOOLED=SYS$PRINT LPBO:
INITIALIZE/QUEUE/DEFAULT=FLAG/START/ON=LPBO: PRINT.B
!
! Set printer characteristics, set LPCO spooled,
! and set up queue PRINT.C with generic queuing disabled.
!
SET PRINTER/L0WER/PAGE=32 LPCO:
SET DEVICE/SPOOLED=LPCO LPCO:
INITIALIZE/QUEUE/DEFAULT=FLAG/NOENABLE_GENERIC/START/ON-LPCO: PRINT.C
!
! Set up the generic printer queue SYS$PRINT
•
INITIALIZE/QUEUE/GENERIC/START SYS$PRINT

The characteristics for LPCO are set.

2 The line printer LPCO is set spooled.
3 The printer queue PRINT_C is initialized and started with generic printing
disabled.
4

Only print jobs explicitly directed to the printer LPCO or queue PRINT_C
are placed in PRINT_C. No print jobs are directed to PRINT_C from the
generic queue SYS$PRINT.

9-51

COMMANDS
$ SET DEUICE/SPOOLED=SYS$PRINT LPAO
$ SET DEUICE/SPOOLED=SYS$PRINT LPBO
$ SET DEUICE/SPOOLED=LPCO LPCO
$ INITIALIZE/QUEUE/FLAG/GENERIC SYS$PRINT
$ START/'QUEUE SYS$PRINT
$ INITIALIZE/QUEUE/FLAG LPAO
$ START/QUEUE LPAO
$ INITIALIZE/QUEUE/FLAG LPBO
$ START/QUEUE LPBO
$ INITIALIZE/QUE LI E/FLAG/NOENABLE._GENERIC_PRINTING LPCO
$ START/QUEUE LPCO

Queues

Line Printers

SYSSPRINT
Generic Print
Queue

LPAO
Generic Printing
Enabled

LPAO

LPBO
Generic Printing
Enabled

LPBO
LPCO
No Generic
Printing

LPCO

ZK-1007

9-52

Using the Batch/Print Facility

9.8

Managing the Card Reader
Information in this section applies to the DIGITAL CR-11 card reader. Note
that other card readers may function differently. The card reader is used to
read card decks. Users may submit the two following types of card decks for
processing:
•

Batch job card decks

•

Data card decks

To ensure that card decks are processed efficiently, you must understand their
characteristics and the use of the card reader. The following sections describe
which cards you should check before processing a deck through a card reader
and how to determine which cards are damaged. Section 9.8.3.2 outlines a
procedure for processing a card deck through the card reader.

9.8.1

Distinguishing the Type of Card Deck
Before loading a card deck into the card reader, you should determine:
•

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

•

Whether the card reader is set to the correct translation mode

The following sections describe how to make these determinations.

9.8.1.1

Batch Job Card Deck
A batch job card deck consists of three segments:
•

The initial cards

•

The program cards

•

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 ($EOJ) card or an end-of-file (EOF) card. Either of these cards tells
the system that this is the end of the job.
Note: For more information on card reader batch jobs from a system user's
viewpoint, refer to the Guide to Using DCL and Command Procedures on
VAX/VMS.

Checking Input
The system cannot execute the job without $JOB and $PASSWORD cards. If
you are given a card deck with these cards omitted, you should return the
deck so that the user can insert them.
Since the card deck contains the user's password, you must ensure that it is
always handled with care to preserve the security of the user's account.
The last card in the deck must be either an $EOJ or an EOF card.

9—53

Using the Batch/Print Facility

If the last card is not one of these end cards, you can type an end card on the
card punch (12-11-0-1-6-7-8-9 overpunch in column 1) and place it at the end
of the deck.

Checking Output
The log file produced by a card reader batch job is queued for printing to
the default system printer queue, SYS$PRINT. To have the log file queued to
a different queue, the user can specify the /PRINTER qualifier on the $JOB
card.
If an error occurs while the system is attempting to validate the $JOB and
$PASSWORD cards, OPCOM sends to the card operator an error message
that reports the job card and the error.

9.8.1.2

Data Card Deck
A data deck contains data that will be either read by a program or copied
to a file for later use. The process that will read the data deck is usually
associated with an interactive user at a terminal, or else with 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. Then, either the program must read the exact number of cards
supplied, or the last card should be an EOF card 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 the user
has allocated the card reader. If the card reader is not allocated, the system
tries to submit the deck as a batch job and subsequently just flushes the deck
through the reader, rejecting the job.
If the program does not read the exact number of cards (as with the COPY
command), the EOF card 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 one on a card punch and insert it at the end of the deck.

9.8.2

Setting Card Reader Translation Modes
For the system to read input properly, the card reader must be set to the
correct translation mode—the same as the translation mode of the card punch
used to prepare the deck. The VAX/VMS system supports 026 and 029 card
punches. (Translation modes are discussed in detail in the VAX/VMS I/O
Reference Volume and the Guide to Using DCL and Command Procedures on
VAX/VMS.)
Therefore, these conditions must exist for you to be able to set the card reader
to the correct translation mode:
•

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

•

You must know the mode in which the cards were punched.

To set the translation mode of the card reader for many decks of the same
type, use the SET CARD-READER command. See the VAX/VMS DCL
Dictionary for more information on the SET CARD—READER command. By
default, when the system is bootstrapped, the translation mode is set to 029.

9-54

Using the Batch/Print Facility

9.8.3

Tending the Card Reader
This section describes how to tend the DIGITAL CR-11 card reader. The job
of tending the card reader includes:

9.8.3.1

•

Replacing physically defective cards

•

Operating the card reader

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 problem is usually caused by one or more
physically defective cards.
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 9-6 lists the error indicators, the reasons why they may light up, and
the operator action required to correct the situation.

9.8.3.2

Operating the Card Reader
The following steps describe 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.

2 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, you can load the
excess cards while the reader is operating if you maintain tension on the
front portion of the deck.

3 Remove the cards from the output stacker when either the HOPPER
CHECK error indicator or the STOP light is lit.
If you accidentally press the STOP button 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 9-6 for recovery procedures.

9-55

Using the Batch/Print Facility

Table 9-6

Card Reader Errors: Causes and Corrective Actions

Error

Causes

Corrective Action

READ CHECK

Card edges torn
Punch in column 0 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.

9.8.4

STACK CHECK

Jam in the card track
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.

HOPPER CHECK

Input hopper empty
Output stacker full

Load the input hopper.
Unload the output stacker.

Running the Input Symbiont Interactively
You can run the input symbiont interactively, taking card image input from a
VAX RMS file by issuing the following commands:
$ DEFINE/USER SYSSINPUT filename
$ RUN SYS$SYSTEM:INPSMB

Running the input symbiont interactively requires the following:
•

CMKRNL privilege

•

Read access to the UAF

•

Write access to the default directory of the user

All messages are issued to the terminal instead of the card operator.

9-56

10 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

•

Handling user requests

•

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. (For more information, see the VAX/VMS System
Dump Analyzer Reference Manual.) In a few cases, as described in Section 10.4,
you may want to forward the dump to DIGITAL with a Software Performance
Report.

10.1

Error Logging Operations
The system automatically writes error messages to the latest version of a file
named SYS$ERRORLOG:ERRLOG.SYS. You can display the information
in this file by issuing the DCL command ANALYZE/ERROR—LOG. This
command is described in the VAX/VMS DCL Dictionary.
The Error Logging Facility consists of three parts:
1

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

2 A process called ERRFMT, which 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

3 The Analyze/Error_Log Utility, activated by the DCL command
ANALYZE/ERROR_LOG, which you use to report selectively the
contents of an error log file (see the VAX/VMS Error Log Utility Reference
Manual)
The executive routines and the ERRFMT process operate continuously without
user intervention. The routines fill 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 buffer to fill up before ERRFMT
can empty them. You can detect this condition by noting a skip in the error
sequence number of the records reported in the error log reports. As soon
as ERRFMT frees the buffer space, the executive routines resume preserving
error information in the buffers.

10-1

Errors and Other System Events

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 (you must have the DETACH privilege) by invoking
the startup command procedure in the [SYSEXE] directory and by specifying
the parameter ERRFMT as follows:
$ <DSYS$SYSTEM: STARTUP ERRFMT

Invoke the command procedure from tne system manager's account.

10.1.1 Using Error Reports
The error reports generated by the Analyze/Error_Log Utility are useful in
two basic ways:
1

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

2 They aid the diagnosis of a failure by documenting the errors and events
that led up to it.
The detailed 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, using the DCL command SHOW
ERROR, you may see that a particular device is producing a relatively
high number of errors. You can then use the Error_Log Utility to obtain
a more detailed report and decide whether you should consult DIGITAL Field
Service. In that case, field service personnel can run diagnostic programs to
investigate the device and attempt to isolate the source of the errors.
In the event a system component does fail, a Field Service representative
can study the error reports of the 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 errors
associated with the device that occurred within the last 24 hours; another
report might summarize all types of errors for all devices that occurred within
the same time period. The summary report can put the device errors into
a systemwide 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.
Error reports allow you to anticipate potential 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 Log Utility in conjunction
with diagnostic programs can significantly reduce the amount of system
downtime.

10.1.2 Maintaining the Error Log Files
Since the error log file, SYS$ERRORLOG:ERRLOG.SYS, is a shared file,
ERRFMT can write new error log entries while other entries in the same file
are being read and reported by the Error Log Utility.
ERRLOG.SYS will increase in size and remain on the system disk until it is
explicitly renamed or deleted. Therefore, you must devise a plan for regular
maintenance of the error log file.

10-2

Errors and Other System Events

One method is to rename 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 backup volume where it can be kept as long
as needed. For example, you could rename the current copy of ERRLOG.SYS
to ERRLOG.OLD every morning at 9:00 o'clock. 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 file from the system disk. Note that
you should exercise caution to ensure that error log files are not deleted
inadvertently. You may also want to adopt a naming convention for your
files that incorporates in the file name a beginning or ending date for the
data.

10.1.3 Printing the Error Log Files
The following steps describe how to generate an error log report for all entries
in the error log file and how to print the report:
1

Ensure that you have the SYSPRV privilege. You need this privilege to
access the error log file.

2 Set your default disk and directory to SYS$ERRORLOG.
3 Examine the error log directory to see which error log file you wish to
analyze.
4

To obtain a full report of the current error log file, issue the command:
$ ANALYZE/ERR0E_L0G/0UTPUT=ERR0RS.LIS

5 Print a copy of the report, using the file name specified with the
/OUTPUT qualifier:
$ PRINT ERRORS.LIS

Example
$ SET PROCESS/PRIV=SYSPRV
$ SET DEFAULT SYS$ERR0RL0G
$ DIRECTORY
Directory SYSlSYSROOT:[SYSERR]
ERRLOG.OLD;2

ERRLOG.OLD;i

ERRLOG.SYS;1

Total of 3 files.
$ ANALYZE/ERR0R_L0G/0UTPUT=ERR0RS.LIS ERRLOG.OLD
$ PRINT ERRORS.LIS

10.2

Using the Operator Log File
The operator log file (SYS$MANAGER:OPERATOR.LOG) is a system
management tool you can use to
•

Anticipate and prevent hardware and software failures

•

Monitor user requests for disk and magnetic tape operations

The log file records system events and user requests sent to the operator
terminal by the operator communication process (OPCOM), even when all
operator terminals have been disabled. The following message types appear
in the operator's log file:
•

Initialization of the operator's log file

10-3

Errors and Other System Events

•

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 System Generation Utility

•

Security alarm messages

•

DECnet-VAX status messages

By regularly examining the operator log file, you can often detect tendencies
toward problems and can thereby ensure that preventive action is taken.
Example 10-1 illustrates some typical messages found in the operator log file.

10-4

XXXXXXXXXXX

OPCOM. 15-APR-1986 22:33:54.07 XXXXXXXXXXX
Operator '_node-name$terminal-name:' has been disabled, user
XXXXXXXXXXX OPCOM, 15-APR-1986 22:34:15.47 XXXXXXXXXXX
Operator '_node-name$terminal-name:' has been enabled, user
opcom, ib-apr-iqso 22:34:15.57
operator status for '_node-name$terminal-name:'
PRINTER, TAPES. DISKS. DEVICES
y.y.mmm opcom, is-apr-iqsb 22:38:53.21
request 1, from user PUBLIC
Please mount volume KLATU in device MTAO:
Gort, the tape is in cabinet A
XXXXXXXXXXX OPCOM. 15-APR-1986 22:39:54.37 XXXXXXXXXXX
request 1 was satisfied.
opcom, is-apr-1986 22:40:23.54
message from user SYSTEM
Volume "KLATU
" mounted, on physical device MTAO:
XXXXXXiXXXXX OPCOM, 15-APR-1986 22:40:38.02 XXXXXXXXXXX
request 2, from user PUBLIC
MOUNT new relative volume 2 () on MTAO:
opcom, ib-apr-1986 22:41:07.54
message from user SYSTEM
Volume "KLATU
" dismounted, on physical device MTAO:
15-APR-1986 22:42:14.81, request 2 completed by operator OPA
XXXXXXXXXXX OPCOM, 15-APR-1986 22:42:15.83 XXXXXXXXXXX
request 3, from user PUBLIC
MOUNT new relative volume 3 () on MTAO:
XXXXXXXXXXX OPCOM, 15-APR-1986 22:42:44.54 XXXXXXXXXXX
message from user SYSTEM
Volume "BERADA
" mounted, on physical device MTAO:
opcom, ib-apr-1986 22:42:44.73
message from user SYSTEM
Volume "BERADA
" dismounted, on physical device MTAO:
I'm sorry, but we are out of tapes.
\\XXXXXXXXXX OPCOM. 15-APR-1986 22:45:11.45 XXXXXXXXXXX
request 3 aborted by operator OPAO
XXXXXXXXXXX OPCOM, 15-APR-1986 22:45:40.54 XXXXXXXXXXX
message from user SYSTEM
Volume "BERADA
" dismounted, on physical device M
XXXXXXXXXXX OPCOM, 15-APR-1986 22:46:47.96 XXXXXXXXXXX
request 4, from user PUBLIC
_TTB5:, This is a sample user request w/ reply expected.
XXXXXXXXXXX OPCOM. 15-APR-1986 22:47:38.50 XXXXXXXXXXX
request 4 was canceled
XXXXXXXXXXX OPCOM, 15-APR-1986 22:48:21.15 XXXXXXXXXXX
message from user PUBLIC
_TTB5:, This is a sample user request w/o a reply expected.
XXXXXXXXXXX OPCOM. 15-APR-1986 22:49:07.90 XXXXXXXXXXX
Device DMAO: is offline.
Mount verification in progress.
XXXXXXXXXXX OPCOM. 15-APR-1986 22:49:20.22 XXXXXXXXXXX
Mount verification completed for device DMAO:
XXXXXXXXXXX OPCOM, 15-APR-1986 22:49:37.64 XXXXXXXXXXX
Device DMAO: has been write locked.
Mount verification in progress.
XXXXXXXXXXX OPCOM, 15-APR-1986 22:53:54.52 XXXXXXXXXXX
Device DMA1: is offline.
Mount verification in progress.
XXXXXXXXXXX OPCOM, 15-APR-1986 22:54:16.56 XXXXXXXXXXX
Mount verification aborted for device DMA1:
XXXXXXXXXXX OPCOM, 15-APR-1986 23:33:54.07 XXXXXXXXXXX
message from user NETACP
DECnet shutting down

xxxxxxxxxxx

Errors and Other System Events

10.2.1 Maintaining the Operator Log File
The operator log file normally resides on the system disk in the [SYSMGR]
directory. Because this file is in ASCII format, you can print it. You should
print copies regularly and retain these copies for reference. The next section
describes how to print copies of the operator log file.
A new version of OPERATOR.LOG is created each time the system is
rebooted. (You can also use the DCL command REPLY/LOG to create a
new version of the file.) The highest version is always the one in use and is
inaccessible.
You should devise a plan for regular maintenance of these files. One way
is to rename the second-highest version on a daily basis. The procedure for
renaming the operator log file is the same as that described in Section 10.1.2
for renaming the error log file. Do not delete versions that have not been
backed up.

10.2.2 Printing the Operator Log File
The following steps illustrate how you can produce a printed copy of the
most recent version of the operator log file.
1

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

2 Set the default to SYS$MANAGER and issue the following command to
list all versions of the file:
$ DIRECTORY OPERATOR.LOG

3 Rename the second-highest version to OPERATOR.OLD:
$ RENAME OPERATOR.LOG;-1 OPERATOR.OLD

The version number, -1, specifies that the second-highest version of this
file is to be renamed. The highest version number is the current operator
log file.
4

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

Example
$ REPLY/LOG

nnnmn

opcom. is-apr-iqso 12:29:24.52
log!lie initialized by operator _MARS$VTA2:
logfile is SYStMANAGER:OPERATOR.LOG

$ SET DEFAULT SYS$MANAGER
$ DIRECTORY OPERATOR.LOG
Directory SYSISYSROOT:[SYSMGR]
OPERATOR.LOG;582

OPERATOR.LOG;581

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

10-6

nxnnnn

Errors and Other System Events

10.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:
$ <BSYS$SYSTEM: STARTUP OPCOM

Invoke the STARTUP command procedure from the system manager's
account.

10.3

Using the Operator Terminal to Handle User Requests
One of the chief operator functions, communicating with users in handling
requests, must be performed at terminals that have been defined as operator
terminals. You can set up an operator terminal by issuing the DCL command
REPLY/ENABLE at the desired terminal. When you enter this command, an
OPCOM message in the following format will be displayed at the terminal
and written to the operator's log file:
XXXXXXXXXXX

OPCOM, dd-mmm-yyyy hh:mm:ss.cc, XXXXXXXXXXX
Operator '_nodename$terminal-name:' has been enabled, username 'USERNAME'

This message tells you which terminal has been established as an operator
terminal and when it was established.

Request Message Formats
To communicate with you, users can issue the DCL command REQUEST,
specifying either the /REPLY or /TO qualifier.
If the user issues a REQUEST/REPLY command, the request is displayed at
the operator terminal in the following format:
y.mmm OPCOM, dd-mmm-yyyy hh:mm: ss . cc XXXXXXXXXXX
request 'request-id' from user 'USERNAME' '_terminal-name:',

"message-text"

This message tells you which user sent the request, the time it was sent, the
request identification number, the originating terminal, and the request itself.
If the user issues a REQUEST/TO command, the request is displayed at the
operator terminal in a format similar to the one above, but without a request
identification number. The message will have the following format:
XXXXXXXXXXX

OPCOM. dd-mmm-yyyy hh:mm:ss.cc XXXXXXXXXXX
request from user 'USERNAME' '_terminal-name:', "message-text"

When a user issues a REQUEST/REPLY command and you have disabled
all operator terminals with the appropriate REPLY/DISABLE commands,
OPCOM returns a message to the user indicating that no operator coverage is
available. However, all subsequent user requests are recorded in the operator
log file.
To respond to user requests, issue the REPLY command with one of the
following qualifiers:
•

/ABORT=identification-number "message-text"

•

/PENDING=identification-number "message-text"

•

/TO=identification-number "message-text"

10-7

Errors and Other System Events

The /ABORT qualifier indicates that the user request has been canceled.
The /PENDING qualifier places the request in a waiting state until it can be
fulfilled or aborted. The /TO qualifier indicates that the request has been
fulfilled.
For more information on the REPLY command, including all the command
qualifiers, see the VAX/VMS DCL Dictionary.

10.4

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 reproduced as Figure 10-1. Directions
for completing the SPR form accompany the form itself.
A supply of SPR forms is included in the VAX/VMS Software Distribution
Kit; you can obtain more forms 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.

10.4.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 evolved. Merely
supplying erroneous output or paraphrases of the session 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:
$ SHOW LOGICAL/FULL/ALL
$ SHOW SYMBOL/ALL/GLOBAL
$ RUN SYStSYSTEM:SYSGEN
SYSGEN> USE ACTIVE
SYSGEN> SHOW /ALL
SYSGEN> SHOW /SPECIAL

10.4.2 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 involved or write a small program
that reproduces the problem. This action may help you locate logic errors,
and will enable DIGITAL to isolate the difficulty more quickly.

10-8

Errors and Other System Events

Figure 10-1

Software Performance Report (SPR)

SOFTWARE
PERFORMANCE
REPORT

FIELD NO.!

CORPORATE SPR NO.:

279086

)

ADMINISTRATIVE SERVICES GROUP, SWS
ZK-794-82

10-9

Errors and Other System Events

10.4.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. It is best to include console or magnetic tape
media with an SPR.
If a system failure has occurred, then include the system dump file. Write the
data onto a Files-11 Structure Level 2 disk or an ANSI magnetic tape. The
following commands will copy the system dump file to an ANSI magnetic
tape:
$ MOUNT/FOREIGN MTAO: DUMPS
$ BACKUP SYS$SYSTEM:SYSDUMP.DMP/IGNORE=NOBACKUP

MTAO:DUMP/SAVE_SET

You can copy files to the console medium after invoking SYSGEN and issuing
the following command:
SYSGEN> CONNECT CONSOLE

Now remove the console medium and place a scratch medium in the console
device.
$
$
$
$
$

INITIALIZE CSA1: SPRDATA
MOUNT CSA1: SPRDATA
CREATE/DIRECTORY CSA1:[SPR]
BACKUP MYDATA.DAT,MYIMAGE.EXE/IGNORE=NOBACKUP CSA1:[SPR] DATA/SAVE.SET
DISMOUNT CSA1:

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
unusable dump file since FLX eliminates all bytes of zero.)
Note: All machine-readable media you submit with SPRs will be returned to
you.

10.4.4 System Environment
Every site runs a different type of workload. Some problems appear only
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.

10-10

Errors and Other System Events

10.4.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 x.y."
DIGITAL requires different kinds of information to resolve different kinds of
problems. Use Table 10-1 as an initial checklist to begin collecting the proper
information to forward with your SPR.
Table 10-1

Typical Problem-Specific Information for SPRs

Problem

Information to Collect

Command language interpreters

A listing obtained from the DCL
commands SHOW SYMBOL/ALL
/GLOBAL and SHOW LOGICAL/FULL
/ALL.

Compiler or assembler

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.

Devices

A copy of the error log at the time of the
problem.

Executive

A listing of the active values of the
system parameters. (Invoke SYSGEN
and specify the USE ACTIVE, SHOW
/ALL, and SHOW/SPECIAL commands.)
A machine-readable copy of the source
program showing the problem.
A copy of the error log at the time of the
problem.

Files

A listing of all the information available
on the file, obtained with the DCL
command DIRECTORY/FULL; or a dump
with the header of the file's directory,
obtained with the DCL command DUMP
/HEADER.
A machine-readable copy of the file
itself.

Intermittent

A copy of the error log at the time of the
problem.

Job controller

A copy of the console printout and
a machine-readable copy of the file
SYS$SYSTEM:JOBCTL.DMP, which is
produced when the job controller aborts.

10-11

Errors and Other System Events

Table 10-1 (Cont.)

Typical Problem-Specific Information for
SPRs

Problem

Information to Collect

Librarian

A machine-readable copy of the library
itself.
Machine-readable copies of all input files
to the library.
A listing of all the information available
on the library file, obtained from the DCL
command 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 by the DCL
command LINK/MAP/FULL.

Machine check

A copy of the error log at the time of the
error.
A machine-readable copy of the system
dump file.

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 nonVAX/VMS system, if applicable.

System bugcheck/Failure

A machine-readable copy of the system
dump file. (Do not send output from the
System Dump Analyzer, 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.

10-12

Errors and Other System Events

Table 10-1 (Cont.)

Typical Problem-Specific Information for
SPRs

Problem

Information to Collect

System hang

A copy of the system dump file, obtained
after you crash the system in the manner
described in the software installation
card for your VAX 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
workload.

Terminals

A list of terminal characteristics produced
by the DCL command SHOW TERMINAL.
A description of the type of terminal,
the type of modem (if any), any special
front-end equipment, and any unusual
terminal configuration.

10-13

1 1

System Generation

When your system is installed or upgraded, a DIGITAL-supplied command
procedure, AUTOGEN.COM in SYS$UPDATE, automatically sets the values
of system parameters, the sizes of the primary page, swap, and dump files,
and the contents of the default installed image list (VMSIMAGES.DAT in
SYS$MANAGER). AUTOGEN makes these adjustments after evaluating your
hardware configuration and estimating typical workloads.
In many cases, AUTOGEN optimizes your new system when it is invoked
during routine installation or upgrade procedures. You may therefore wish to
monitor performance for a period of time before making further adjustments.
If (based on system performance and suggestions in the Guide to VAX/VMS
Performance Management) 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 SYSGEN, because AUTOGEN analyzes your
modifications and adjusts any related parameters. Sections 11.1 through 11.5
describe AUTOGEN functions and usage.
There are, however, certain system modifications that you must perform using
SYSGEN. These are described in Sections 11.6 through 11.14.

AUTOGEN Functions
AUTOGEN performs one or more of the following operations on an upgraded
or newly installed system:
•

Collects two types of data:
1

Hardware configuration characteristics.

2 Current values of SYSGEN parameters. Four sets of values (listed in
Tables 11-5 through 11-8 at the end of this chapter) are collected in
the files OLDSITEl.DAT through OLDSITE4.DAT in SYS$SYSTEM
and conditionally written to SYS$SYSTEM:PARAMS.DAT. (For
detailed descriptions of SYSGEN parameters, refer to the VAX/VMS
System Generation Utility Reference Manual.)
•

Calculates appropriate new values for significant SYSGEN parameters
(listed in Table 11-9) and sizes for the system page, swap, and dump files

•

Resets system parameter values and file sizes if necessary

•

Optionally shuts down and reboots the system

You should carefully examine the PARAMS.DAT file that AUTOGEN creates
at your site during routine installation or upgrade procedures to determine
whether
•

AUTOGEN has drawn the correct conclusions about your hardware
configuration.

•

The system parameter values shown are appropriate for your workload
requirements.
11-1

System Generation

If you are satisfied with the data in PARAMS.DAT, further adjustments are
probably unnecessary.
If, on the other hand, you need to correct configuration data or modify
system parameters to accommodate special conditions at your site, invoke
AUTOGEN as described in the next section and follow the procedures
outlined in Sections 11.3 and 11.4.

11.2

Invoking AUTOGEN
You can invoke AUTOGEN any time after an installation or an upgrade to
reset parameter values and system file sizes. The new values and file sizes
take effect the next time the system is bootstrapped.
To ensure that you have the required privileges, invoke AUTOGEN from the
system manager's account. The format is:
$ ©SYS$UPDATE:AUTOGEN [start-phase]

[end-phase]

[execution-type]

You can enter up to three parameters to designate the AUTOGEN operation
you desire. All parameters are optional; however, missing leading parameters
must be replaced by null arguments (that is, "").
Table 11-1 lists the phase parameters and their effects, including the files
needed as input and the files created or changed for output. Table 11-2
summarizes execution types.
All files except VMSIMAGES.DAT reside in the directory specified by the
SYS$SYSTEM logical name. VMSIMAGES.DAT resides in SYS$MANAGER.
The start phase must either precede or be identical to the end phase according
to the sequence shown in Table 11-1 (the end phase defaults to the same
value as the start phase). GENPARAMS is the default start phase; GENFILES
may not be specified as the start phase.
Table 11-1

AUTOGEN Phase Parameters

Phase

Input Files

Output Files

Function

SAVPARAMS

None

OLDSITE*.DAT

Save significant old parameters for
propagation and update.

GETDATA

OLDSITEvDAT
MODPARAMS.DAT

PARAMS.DAT

Collect all data that will be required
by the GENPARAMS and GENFILES
phases, including configuration data, old
parameters, and site-specific items.

GENPARAMS

PARAMS.DAT

SETPARAMS.DAT
VMSIMAGES.DAT

Generate new system parameters; create
the installed image list.

TESTFILES

PARAMS.DAT

SYSSOUTPUT

Display the system page, swap, and dump
file sizes calculated by AUTOGEN. (See
Section 11.4 if you wish to specify sizes.)

GENFILES

PARAMS.DAT

PAGEFILE.SYS
SWAPFILE.SYS
SYSDUMP.DMP

Generate new system page, swap, and
dump files if appropriate. Cannot be
specified as the start phase.

11-2

System Generation

Table 11-1 (Cont.)

AUTOGEN Phase Parameters

Phase

Input Files

Output Files

Function

SETPARAMS

SETPARAMS.DAT

VAXVMSSYS.PAR
AUTOGEN.PAR

Run SYSGEN to set system parameters
specified by the SETPARAMS.DAT and to
generate a new AUTOGEN.PAR file.

SHUTDOWN

None

Prepare the system to await a manual
reboot.

REBOOT

None

Automatically reboot the system.

Table 11-2

Execution Types

Type

Meaning

INITIAL

Specifies that AUTOGEN is being executed as part of an initial
system installation. The SAVPARAMS phase is never executed
in this case.

V4UPGRADE

Specifies that AUTOGEN is being executed as part of an upgrade
from a Version 4.n system or that interactive tuning is being
performed. V4UPGRADE is the default execution type.

V3UPGRADE

Specifies that AUTOGEN is being executed as part of an upgrade
from a Version 3.n system to a Version 4.n system.

The commands and examples in the next sections illustrate AUTOGEN
procedures you would use to adjust a typical Version 4.4 system after an
upgrade.

11.3

Collecting Data for AUTOGEN Calculations
To collect the data AUTOGEN needs to perform its calculations, issue the
following command:
$ ©SYSIUPDATE:AUTOGEN SAVPARAMS GETDATA

This command instructs AUTOGEN to
•

Create OLDSITE*.DAT files that store system parameter data from the
current system

•

Collect system version, identification, and hardware configuration data

•

Collect user-specified data, if any, from MODPARAMS.DAT (see
Section 11.4)

•

Write data to a PARAMS.DAT file for use in subsequent calculations or
propagation to the new system

Example 11-1 shows a typical PARAMS.DAT file. The first group of items
is a list of AUTOGEN's conclusions about the system version, system ID,
and hardware components. (Table 11-3 defines these items.) You should
scrutinize the Boolean items to verify that AUTOGEN has drawn the correct
conclusions about your hardware configuration.

11-3

System Generation

The next items are system parameter values collected in OLDSITE*.DAT
files or specified in MODPARAMS.DAT. Parameters preceded by an OLD_
prefix will be used within calculations. Other parameters will be written to
SETPARAMS.DAT and propagated to the new system.
Note: Values displayed in PARAMS.DAT as input from MODPARAMS.DAT
override corresponding configuration values and values from
OLDSITE*.DAT files.

11-4

VERSI0N="V4.2
CPUTYPE=1
SID=20455546
QVSS="false"
MEMSIZE=16384
DISKSPEED=4
DISKSIZE=340670
NUM_DISK=77
NUM_TAPE=5
NUM_SC0M=10
NUM_CARD=0
NUM_TERM=74
NUM_LP=4
NUM_REALTIME=0
NUM_BUS=2
NUM_MAILB0X=0
NUM_J0URNAL=0
NUM_MISC=0
NUM_CI=1
NUM_ETHERNET=3
NUM_SERVER=2
NUM_H0ST=1
DRIVER_NPAGEDYN=188226
DECNET="true"
CLUSTERS true"
JOURNALING="false"
PEDRIVER_LOADED="false"
!

Parameters specified in SYS$SYSTEM:0LDSITE1.DAT

OLD_GBLPAGES=20240
0LD_GBLSECTI0NS=2OO
0LD_GBLPAGFIL=512O
0LD_MAXBUF=2100
0LD_MAXPR0CESSCNT=96
OLD_VIRTUALPAGECNT=48000
!

Parameters specified in SYS$SYSTEM:OLDSITE2.DAT

CLISYMTBL=80
PQL_DWSDEFAULT=458
PQL_DWSQU0TA=458
PQL_MWSDEFAULT=458
PQL_MWSQU0TA=458
!

Parameters specified in SYS$SYSTEM:0LDSITE3.DAT

ACP_SWAPFLGS=14
DEADL0CK_WAIT=1
MVTIMEOUT=1200
PAGFILCNT=5
REALTIME_SPTS=40
SCSSYSTEMID=2217
SWPFILCNT=3
TIMEPR0MPTWAIT=65535
TTY_ALTYPAHD=2048
USERD1=1
!

Parameters specified in SYS$SYSTEM:0LDSITE4.DAT

ACP_REBLDSYSD=0
DISK_QU0RUM="$255$DUA5
QU0RUM=3
SCSN0DE="CURLEY

TTY_DEFCHAR2=135178

System Generation

Example 11-1

(Cont.)

Sample AUTOGEN PARAMS.DAT File

! Parameters specified in SYS$SYSTEM:MODPARAMS.DAT
! MODPARAMS.DAT for CURLEY
i

! All Bite-specific SYSGEN parameters not computed correctly or
! propagated by AUTOGEN should be defined here.
i

PAGEFILE = 10000
SWAPFILE = 0
ADD.SPTREQ * 400
GBLPAGES = 20240
NUM.HOST * 6
NUM.SERVER = 8

! for MA780
! 10240 + 10000 for MA780

end of MODPARAMS.DAT for CURLEY

This data file should NOT be modified.
Users wishing to alter the
data in this file should modify SYS$SYSTEM:MODPARAMS.DAT instead.

Table 11-3

11-6

Configuration Parameters Specified in
Example 11-1

Parameter

Specifies

VERSION

Version number of VAX/VMS used to create this file

CPUTYPE

Code for the VAX processor model number as specified
by the $GETSYI system service

SID

System identification number

MEMSIZE

Physical memory size, in pages

DISKSPEED

Code for speed of system disk; values are 1, 2, or 4,
where 4 is the fastest category of disks

DISKSIZE

System disk size in blocks

NUM_DISK

Total number of disk devices

NUM_TAPE

Total number of magnetic tape devices

NUM_SCOM

Total number of system communication devices

NUM_CARD

Total number of card readers

NUM_TERM

Total number of terminal lines available

NUM_LP

Total number of printers

NUM_REALTIME

Total number of real-time devices

NUM_BUS

Total number of buses

NUM_MAILBOX

Total number of mailboxes

NUM_MISC

Total number of miscellaneous devices

NUM_JOURNAL

Reserved for future use

NUM_CI

Total number of computer interconnects

NUM_ETHERNET

Number of Ethernet connections

NUM_SERVER

Number of disk or tape servers that use the MSCP
protocol (HSC50, UDA50, VAX systems running the
MSCP server software)

System Generation

Configuration Parameters Specified in
Example 11-1

Table 11-3 (Cont.)

11.4

Parameter

Specifies

NUM_HOST

Number of VAX/VMS systems that are members of a
VAXcluster

DRIVER_NPAGEDYN

Bytes of nonpaged pool taken up by drivers

DECNET

Whether DECnet is installed

CLUSTER

Whether node is member of a VAXcluster

JOURNALING

Reserved for future use

PEDRIVER_LOADED

Whether PEDRIVER is loaded

WSTYPE

Whether VAXstation is present on the system

Modifying AUTOGEN Calculations
If, after examining the PARAMS.DAT file, you decide you wish to correct
hardware configuration data, modify system parameter values, or explicitly
specify sizes for the system page, swap, or dump files (that is, override the
sizes calculated by AUTOGEN), follow the steps outlined in this section.
Depending on the adjustments you are making, you may want to invoke
AUTOGEN several times, specifying different parameters.
1

Edit the file SYS$SYSTEM:MODPARAMS.DAT as follows:
•

To specify new parameter values, use DCL assignment statements of
the form:
parameter = parameter-value

! comment

Using the exact parameter name will override the AUTOGEN
calculation. You can also use an ADD_ prefix with the SYSGEN
parameters listed in Table 11-9 to increment their values in subsequent
AUTOGEN calculations during the GENPARAMS phase. For example:
ADD_MAXPROCESSCNT=10
ADD_NPAGEDYN=10000

The ADD_ parameter value can be negative in order to lower
AUTOGEN's calculated value by the specified amount (for example
-10).
•

To specify system file sizes explicitly, use the keywords PAGEFILE,
SWAPFILE, and DUMPFILE followed by an equal sign and the size
of the file in blocks. The values you specify (which are set during the
GENFILES phase) will override AUTOGEN's calculations until you
remove the lines from MODPARAMS.DAT.

Note: AUTOGEN will not change file sizes if you specify a value of 0, or
a value that is within ten percent of the current size.
To determine the current sizes of page and swap files, issue the DCL
command SHOW MEMORY/FILE.
The parameter values and file sizes specified in MODPARAMS.DAT will
be copied into PARAMS.DAT during the next GETDATA phase, and
AUTOGEN will make appropriate adjustments in its calculations.

11—7

System Generation

Verify the modifications you have made in MODPARAMS.DAT. Issue the
command
$ OSYS$UPDATE:AUTOGEN GETDATA

and examine the resulting PARAMS.DAT file (see Example 11-1).
If you wish to make further modifications to the data in PARAMS.DAT,
edit MODPARAMS.DAT and repeat the GETDATA phase.
Caution: Under no circumstances should you attempt to edit PARAMS.DAT. All
modifications to this file must be made by editing MODPARAMS.DAT
and executing AUTOGEN's GETDATA phase.
3

When you are satisfied with the data in PARAMS.DAT, issue the following
command:
$ <8SYS$UPDATE: AUTOGEN GENPARAMS SETPARAMS

AUTOGEN will generate the known image file list, VMSIMAGES.DAT,
and it will create SETPARAMS.DAT, using in its calculations the
parameter values you specified in MODPARAMS.DAT. It will
then run SYSGEN to set values for your upgraded system in
SYS$SYSTEM:VAXVMSSYS.PAR. The new values are also propagated
to SYS$SYSTEM:AUTOGEN.PAR.
4

Finally, when you are ready to reboot the system, issue the command
$ <BSYS$UPDATE: AUTOGEN REBOOT

Note that you can define the logical name AGEN$SHUTDOWN_TIME
(using the DCL command DEFINE) to specify the number of minutes
before shutdown occurs in this operation.
Once you complete the AUTOGEN REBOOT operation, you can verify the
parameter changes. Invoke SYSGEN and display the parameters with the
SYSGEN command SHOW/ALL.

11.5

Manipulating System Files
As described in the previous section, you can use AUTOGEN to adjust the
sizes of the primary page and swap files, and the system dump file. However,
you cannot use AUTOGEN to perform any operations on secondary page
and swap files. To create, install, or modify secondary files, you must use
SYSGEN (see the VAX/VMS System Generation Utility Reference Manual).
Note: If you have created secondary page or swap files, specify a value of 0
for the keywords PAGEFILE and SWAPFILE in MODPARAMS.DAT.
This instructs AUTOGEN not to create new primary files. AUTOGEN
will issue a warning message if it determines that secondary files exist
and a value of 0 has not been specified for the above keywords. See the
Guide to VAX /VMS Performance Management for more information on
secondary system files.
By following the procedures in the previous section, you can use AUTOGEN
to create a page, swap, or dump file that is smaller than the current version
of the file. After you have booted and begun using the new file, remember to
use the DCL command PURGE to reclaim the disk space from the old version
of the file.

11-8

System Generation

11.6

SYSGEN Functions
Using SYSGEN, you can manipulate the following parts of the VAX/VMS
operating system:
•

System parameters—Create and/or modify a standard system parameter
file for use in subsequent bootstrap operations; dynamically modify the
parameter values of the active system (applies only to the dynamic system
parameters)

•

Devices and device drivers—Connect devices and load their device drivers
(most of this work is automatic)

•

System files—Create additional page and swap files

•

Startup command procedure—Identify the current site-independent startup
command procedure

•

Multiport (shared) memory—Initialize and connect to multiport memory
units

•

MSCP server—Load and start the MSCP server (see the Guide to
VAXclusters).

See the VAX/VMS System Generation Utility Reference Manual for full details
of the System Generation Utility and its commands.

11.7

Modifying System Parameters
The bootstrap process initializes the active system parameter values in
memory from the current system parameter file on disk (that is, the
starting parameter values are those in SYS$SYSTEM:VAXVMSSYS.PAR).
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 parameter file is modified to conform
to the active parameter values.
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 file SYS$SYSTEM:MODPARAMS.DAT
and reinvoking AUTOGEN.
After the system is booted and running, you can run SYSGEN to create or
modify parameter files, including the current system parameter file, and to
modify the dynamic parameter values of the active system. Follow these
steps:
1

Invoke SYSGEN—Invoking SYSGEN initializes a work area for the active
parameter values.

Optionally issue a USE command—You can reinitialize the work area to
include the values of a new parameter file, the current system parameter
file, 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.

11-9

System Generation

Issue a WRITE command—You create a parameter file, modify the current
system parameter file on disk, or modify the active system in memory.

During these operations, you can use the SHOW command to examine the
parameter values in the SYSGEN work area.

11.7.1

Creating a New Parameter File
The creation of a new parameter file does not affect the system. During 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 named SYS$SYSTEM:OURSITE.PAR,
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.7.2

Modifying the System Parameter File
Modification of the current system parameter file also does not immediately
affect the system. During 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 parameter file:
$ SET DEFAULT SYS$SYSTEM
$ RUN SYSSSYSTEM:SYSGEN
SYSGEN> USE CURRENT
SYSGEN>
SET REALTIME.SPTS 10
SYSGEN> WRITE CURRENT
'/.0PC0M, 15-APR-1986 16:04:06.30, message from user SYSTEM
'/.SYSGEN-1-WRITECUR, CURRENT system parameters modified by process
ID 00160030
SYSGEN>
EXIT

11-10

System Generation

11.7.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
memory. The discussion of the System Generation Utility in the VAX/VMS
System Generation Utility Reference Manual identifies the dynamic parameters
(as does the SYSGEN command SHOW/DYNAMIC). The other parameters
regulate structures that cannot be changed while the system is running.
The following example illustrates how you modify the active value of the
PFCDEFAULT parameter:
$ RUN SYSSSYSTEM:SYSGEN
SYSGEN>
SET PFCDEFAULT 127
SYSGEN>
WRITE ACTIVE
•/.OPCOM, 15-APR-1986 16:04:06.30, message from user SYSTEM
’/.SYSGEN-1-WRITEACT, ACTIVE system parameters modified by process
ID 00160030
SYSGEN>
EXIT

Modification of the active system does not affect the current system parameter
file on disk. If, for example, you set new active parameter values (WRITE
ACTIVE) and later want to use them for subsequent bootstrap operations, the
values must be explicitly written to the current system parameter file on disk:
$ RUN SYS$SYSTEM:SYSGEN
SYSGEN>
WRITE CURRENT
*/,0PC0M, 15-APR-1986 16:04:06.30, message from user SYSTEM
•/.SYSGEN-1-WRITECUR, CURRENT system parameters modified by process
ID 00160030 into file VAXVMSSYS.PAR
SYSGEN>
EXIT

11.8

Connecting Devices and Loading Device Drivers
Normally, you issue the AUTOCONFIGURE command to connect
automatically all devices physically attached to the system and to 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. You must exercise
great care in issuing CONNECT and LOAD commands. (See the discussion
of the System Generation Utility in the VAX/VMS System Generation Utility
Reference Manual and the Writing a Device Driver for VAX/VMS.)
Devices not connected automatically by AUTOCONFIGURE include the
network communications logical device and the console block storage device.
To connect the network communications logical device, use the following
explicit CONNECT command:
SYSGEN> CONNECT NET/NOADAPTER/DRIVER=NETDRIVER

To connect the console block storage device, use the following explicit
CONNECT command:
SYSGEN> CONNECT CONSOLE

The commands in the following example autoconfigure the devices physically
attached to the system and explicitly connect the network software device and
the console block storage device:
SYSGEN>
SYSGEN>
SYSGEN>
SYSGEN>

AUTOCONFIGURE ALL
CONNECT NET/NOADAPTER/DRIVER=NETDRIVER
CONNECT CONSOLE
EXIT

11-11

System Generation

Normally, the SYSGEN commands for connecting devices and loading device
drivers are included in the site-independent startup command procedure (see
Section 2).
Note that there is a DIGITAL-supplied driver named CONINTERR
(SYS$SYSTEM:CONINTERR.EXE), which 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 I/O User's Reference Manual: Part I for further information.

11.9

Using the SET HOST/HSC Facility
The SET HOST/HSC facility allows system managers to use most HSC
commands and utilities from a remote terminal. This facility is useful for
performing management operations such as obtaining the status of disks and
tapes, and running the HSC backup and restore utilities.
To activate the facility, you must first install and load FYDRIVER,
the diagnostic and utilities protocol (DUP) driver associated with
the computer interconnect (Cl). The preferred method is to add
the following command lines to your site-specific startup procedure
(SYS$MANAGER:SYSTARTUP.COM):
$ RUN SYS$SYSTEM:SYSGEN
CONNECT FYAO/NOADAPTER

After SYSTARTUP.COM executes, you can use the DCL command
SET HOST/HSC to connect to an HSC by way of the Cl bus. For a complete
description of this command, refer to the VAX/VMS DCL Dictionary.
Once connection is made, you are attached to the local HSC terminal, and
you may perform operations (with the exception of access to the Octal
Debugging Tool (ODT) and offline diagnostics). For a description of HSC
commands and utilities, see the HSC User's Guide.

11.10

Setting Up Virtual Terminals
Virtual terminals allow you to disconnect from a physical terminal
without terminating a process; the process remains active on a virtual
or "disconnectable" terminal. Virtual terminals are used for the following
purposes:
•

To reconnect to a process when a modem line connection is lost

•

To maintain sessions on more than one disconnectable terminal.

•

To use dynamic asynchronous DECnet communication

You set up virtual terminals by issuing the following SYSGEN command,
which allows physical terminals to become disconnectable:
SYSGEN> CONNECT VTAO/N0ADDAPTER/DRIVER=TTDRIVER

Virtual terminals are identified by the device name VTAn. After the above
SYSGEN command is issued, any terminal with the TT2$M_DISCONNECT
characteristic set is treated as a virtual terminal.
Note: LAT terminals (LTAn) are disconnectable if the TT2$M_DISCONNECT
characteristic is set, but remote terminals (RTAn) are not disconnectable.

11—12

System Generation

There are two ways to set the TT2$M_DISCONNECT characteristic. You
can enable the feature on a systemwide basis by setting the appropriate bit in
the SYSGEN parameter TTY_DEFCHAR2, or you can enable the feature on a
per-terminal basis by using the DCL command SET
TERMINAL/DISCONNECT. Consult the VAX/VMS DCL Dictionary for more
information on the CONNECT and DISCONNECT commands.

11.10.1 Reconnecting to a Disconnected Terminal Process
If virtual terminals are enabled, and a modem line connection is lost, the
process remains active on the system as a disconnected virtual terminal
process. You must reconnect to the process within the time period specified
by the SYSGEN parameter TTY_TIMEOUT (the default value is 900 seconds
or 15 minutes). If you fail to reconnect to the process before this time expires,
the process is deleted.
Note: You can connect only to virtual terminal processes associated with your
user identification code (UIC).
There are four ways in which a terminal can become disconnected:
•

You lose the modem signal between the host and the terminal.

•

You press the BREAK key on a terminal with the TT2$M_SECURE
characteristic set.

•

You issue the DCL command DISCONNECT.

•

You issue the DCL command CONNECT/CONTINUE.

To reconnect to a disconnected terminal, use one of the following methods:
•

Allow the system login process (SYS$LOGIN) to make the connection
using a command procedure.

•

Issue the DCL command, CONNECT VTAn.

11.10.2 Managing Disconnected Processes
Virtual terminals allow you to maintain more than one disconnected process
at a time. You must keep in mind, however, that while you are logged
in to a virtual terminal the physical terminal is disconnected. Any I/O
requests directed to a device other than the physical terminal associated
with your current virtual terminal process will enter a waiting state. The
pending process will terminate when the timeout period expires. If, however,
you reconnect to the physical terminal that is to receive the I/O request,
the process continues from the point at which it entered the waiting state.
Naming each process with a name that relates to its context makes it easier to
reconnect to the desired process.
A system manager may want to restrict the use of virtual terminals. For
example, if your system is close to exhausting nonpaged pool, you may not
want to enable this feature on a systemwide basis. Each virtual terminal
requires an additional data structure, a logical unit control block (UCB), in
addition to the data structure for each physical terminal. You can control the
number of virtual terminal sessions by the value specified in the SYSGEN
parameter MAXDETACH, or restrict the use of virtual terminals by enabling
them on a per-terminal basis.

11-13

System Generation

11.10.3 Using Dynamic Asynchronous DECnet Lines
Virtual terminals are required for dynamic asynchronous DECnet
communication. A dynamic asynchronous line differs from a static
asynchronous line or other DECnet-VAX line in that it is normally switched
on for network use only for the duration of a dialup connection between two
nodes. Dynamic switching of terminal lines to asynchronous DDCMP lines
can occur provided the following requirements are met:
•

Both nodes have DECnet-VAX licenses installed.

•

The system manager at each node has loaded the asynchronous DDCMP
driver NODRIVER.

•

The system manager at each node has installed the privileged shareable
image DYNSWITCH.

•

The system manager at the remote node has virtual terminals enabled.

See the VAX/VMS Networking Manual for a detailed description of the
procedure for setting up dynamic asynchronous DECnet lines.

11.10.4 Determining the Physical Terminal Type
You may want to determine the physical terminal associated with a virtual
terminal. For instance, both direct connect and LAT lines may be virtual, but
you may not know the terminal characteristics of a LAT terminal at system
startup time. You can set the characteristics of direct connect lines at system
startup; however, you must issue a SET TERMINAL/INQUIRE command to
determine the characteristics of a LAT line.
Note: Using the command SET TERMINAL/INQUIRE clears the type-ahead
buffer.
The following command procedure determines the physical terminal
characteristics of both direct and LAT lines at system startup. Insert the
following lines in your systemwide login procedure (SYLOGIN.COM). (This
procedure assumes that your startup procedure has set all switched and LAT
lines to "unknown".)
$ DEVCLASS = 'F$GETDVI ("SYS$COMMAND","DEVCLASS")'
$ IF DEVCLASS .ne. 66 then goto alldone
!Not a terminal
$ DEVTYPE = 1F$GETDVI ("SYS$COMMAND","DEVTYPE")'
$ IF DEVTYPE .ne. 0 then goto got_devtype
$ SET TERMINAL/INQUIRE
!Try to determine the device type
$ DEVTYPE = 'F$GETDVI ("SYS$COMMAND","DEVTYPE")'
$ got.devtype:
$! Can now dispatch on 'devtype' to do different things depending
$! on the type of terminal.
$ alldone:

11-14

System Generation

11.11

Modifying System Files
When your system is installed or upgraded, AUTOGEN defines sizes for the
primary page and swap files appropriate for your hardware configuration,
and for the system dump file. The full file specification of each file is
SYS$SYSTEM:filename.type. The file names are PAGEFILE.SYS for the
page file, SWAPFILE.SYS for the swap file, and SYSDUMP.DMP for the
dump file. Sizes are expressed in blocks.
AUTOGEN creates system files suitable for most systems. For special
workloads or variant configurations, however, you must specify the
file sizes with the SYSGEN command CREATE. (Or—to create primary
files only—you can invoke a DIGITAL command procedure called
SYS$UPDATE:SWAPFILES.COM and enter file sizes when the procedure
prompts you for them.) The following example illustrates the use of the
CREATE command (assume that smaller versions of each file already exist):
SYSGEN>
CREATE PAGEFILE.SYS /SIZE=16384
‘/.SYSGEN-I-EXTENDED. SYS$SYSROOT: [SYSEXE] PAGEFILE. SYS ; 1 extended
SYSGEN>
CREATE SWAPFILE.SYS /SIZE=7168
'/.SYSGEN-1-EXTENDED, SYS$SYSROOT: [SYSEXE] SWAPFILE. SYS; 1 extended
SYSGEN>
CREATE SYSDUMP.DMP /SIZE=2052
'/S Y SGEN -1 - EXTENDED, SYS$SYSR00T: [SYSEXE] SYSDUMP. DMP; 1 extended
SYSGEN>
EXIT

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$SYSR00T:[SYSEXE]
PAGEFILE.SYS;1
SYSDUMP.DMP;1
SWAPFILE.SYS;1

16384
4128
3072

Total of 3 files, 23584 blocks.
There are 128741 available blocks on SYS$SYSDEVICE.
Enter new size for page file: jRET 1
Enter new size for system dump file:
Enter new size for swap file: |RET|

6052

'/.SYSGEN-1-EXTENDED, SYS$SYSR00T: [SYSEXE] SYSDUMP . DMP; 1 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 page 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 a system
page or dump file, a new version of the file is created. If the swap file does
not exist, you can create it using the SYSGEN command CREATE, or by
responding to the appropriate prompt from the SWAPFILES procedure.
Frequent file creation and deletion can cause the free space on a disk to
become severely fragmented. Eventually, this can reach a state such that
extensions to a file require more than one header block to map all the extents
of the file. The bootstrap process requires that SWAPFILE.SYS (the primary
swap file, if present) and PAGEFILE.SYS (the primary page file) be mapped
by a single file header.

11-15

System Generation

Note: SYSGEN issues a warning message if it determines that the creation or
extension of a system file would cause that file to become fragmented
enough to render the system unbootable. If this occurs, DIGITAL
recommends that you back up and restore your system volume, in order
to consolidate the free space on the volume into one contiguous area,
and then retry the SYSGEN operation. In cases where SYSGEN issues a
warning message, the file will be somewhat larger, but not as large as the
value specified in the CREATE command.
If you create a new version of a system file, 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 calculate appropriate sizes for your system files as follows:
•

Page 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 page file. You
can display statistics on your page file usage with the DCL command
SHOW MEMORY/FILE. Examine the data pertaining to the page files.
Aim to keep page file usage less than half the size of the page files.
You can limit the usage of page file space by user programs with
the /PGFLQUOTA qualifier of the ADD and MODIFY commands in
the Authorize Utility (see the VAX/VMS Authorize Utility Reference
Manual). You should not reduce the value of /PGFLQUOTA below
1024. Size requirements of the page file can vary widely depending on
user applications. Sufficient space in the page file is critical to system
performance. If a page 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 page
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).

•

Swap file—Maximum number of processes (MAXPROCESSCNT system
parameter) times the average of the working set quotas of processes
running 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 swap file size, you can monitor the
swap file usage with the DCL command SHOW MEMORY/FILE and
watch its usage under load. You should aim to keep at least one-fourth of
the swap 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 augment the primary page or swap file with additional
files (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 that 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 startup command procedure (see
Section 2). 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
11-16

System Generation

a value as low as 4600 blocks, or SWAPFILE.SYS to a value as low as 1000
blocks.
All processes created after installation of additional page files use the page
file with the most space, while all processes created before their installation
continue to use the page file to which they are assigned. Swap space is
allocated from whichever swap file has space.
Installation of additional page or swap files requires nonpaged dynamic
memory for a bit map, just as the primary files do.

11.12

Identifying a Startup Command Procedure for Bootstrap Operations
Section 2 describes the site-independent startup command procedure named
SYS$SYSTEM:STARTUP.COM, which DIGITAL supplies and recommends
that you do not edit. Following a bootstrap operation, the system executes
the current site-independent startup command procedure. Initially (that is, as
supplied in the software distribution kit), the procedure is STARTUP.COM.
However, if necessary, you can create alternate site-independent startup
command procedures; for example, you can copy STARTUP.COM to other
files of type COM and edit those files. You can then name an alternate siteindependent command procedure to be invoked during subsequent bootstrap
operations, using the SYSGEN command SET/STARTUP. You can use the
SHOW/STARTUP command to display the current site-independent startup
command procedure.
The SYSGEN commands in the following example display the current siteindependent startup command procedure and specify an alternate:
SYSGEN> SHOW/STARTUP
Startup command file = SYS$SYSTEM:STARTUP.COM
SYSGEN> SET/STARTUP SYS$SYSTEM:XSTARTUP.COM
SYSGEN> WRITE CURRENT
'/.0PC0M, 15-APR-1986 16:04:06.30, message from user SYSTEM
'/.SYSGEN-1-WRITECUR, CURRENT system parameters modified by process
ID 00160030 into file VAXVMSSYS.PAR
SYSGEN> EXIT

11.13

Initializing Multiport (Shared) Memory Units
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 the
SYSGEN command SHARE/INITIALIZE 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 command without the /INITIALIZE qualifier, for an
uninitialized multiport memory unit, results in an error condition.
You should power down a multiport memory unit only after first shutting
down and rebooting all systems connected to the unit.
A multiport memory unit managed by VAX/VMS contains the following
preallocated structures, with space requirements as indicated:
•

Common data page—Description of VAX/VMS data structure and quotas
for the shared memory

11-17

System Generation

•

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)

The following SYSGEN command SHARE specifies the default structure
values for a 256KB multiport memory unit with four active ports. The
resulting values are shown in Table 11-4.
SYSGEN>

SHARE MPMO SHR_MEM_1/INITIALIZE-

SYSGEN>

/GBLSECTI0NS=32/MAILB0XES=32-

SYSGEN>

/CEFCLUSTERS=32/P00LBC0UNTss128-

SYSGEN>

/P00LBSIZE=128/PRQC0UNT=64

Table 11-4

Values for Multiport Memory Structures

Structure

Value

CEF TABLE

32 x 80

= 5 pages

COMMON DATA PAGE

= 1 page

DYNAMIC POOL

128 x 128

= 32 pages

GLOBAL SECTIONS

512 - 57

GLOBAL SECTION BIT MAP

= 455 pages
= 1 page

GSD TABLE

32 x 100

= 7 pages

MAILBOX TABLE

32 x 48

= 3 pages

PRQ POOL

64 x 64

= 8 pages

The following guidelines are suggested in selecting values for the SHARE
qualifiers that regulate the sizes of the preallocated structures:

11-18

•

/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 buffer
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.

System Generation

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 a large number should not be needed. The default value
normally suffices. If an executive or driver request cannot be satisfied
because PRQs are depleted, the requesting routine waits until a PRQ
becomes available.

You should calculate the space remaining for the global sections and
determine whether 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 startup command procedure (see Section 2).

11.14

Loading and Starting the MSCP Server
The Mass Storage Control Protocol (MSCP) is used to communicate between
a VAX host and a DIGITAL Storage Architecture (DSA) controller. The
MSCP server enables a VAX processor to make locally connected MASSBUS
and UNIBUS disks available to all other users of a VAXcluster. (As system
manager, however, you must decide which disks should be that widely
available.)
You use the SYSGEN command MSCP to load and start the MSCP server.
You then specify the served devices using the DCL command SET
DEVICE/SERVED. For more information on the MSCP server and its
functions, refer to the Guide to VAXclusters.

11.15

SYSGEN Parameters Used in AUTOGEN Calculations
The following tables list the SYSGEN parameters whose values AUTOGEN
collects and (re)calculates in various operation phases.
Table 11-5

Parameters Collected in OLDSITE1.DAT and
Propagated to New System if Old Current Value
exceeds Autogen's Calculated Value

GBLPAGES

GBLPAGFIL

GBLSECTIONS

MAXBUF

MAXPROCESSCNT

VIRTU ALP AGECNT

11-19

System Generation

Table 11-6

ACFLEXTCACHE

ACP—EXTLIMIT

ACP_FIDCACHE

CLISYMTBL

DEFMBXBUFQUO

DEFMBXMXMSG

DEFMBXNUMMSG

LRPSIZE

PQL_DASTLM

PQL—BDIOLM

PQL_DBYTLM

PQL_DDIOLM

PQL_DFILLM

PQL—DWSDEF AULT

PQL —DWSEXTENT

PQI_DWSQUOT A

PQL_MASTLM

PQL_MBIOLM

PQL_MBYTLM

PQL_MDIOLM

PQL_MFILLM

PQL _MWSDEF AULT

PQL—MWSEXTENT

PQL_MWSQUOTA

PROCSECTCNT

SRPSIZE

Table 11-7

Parameters Collected in OLDSITE3.DAT and
Propagated to New System if Old Current Value
Differs from Old Default Value

ACP—BASEPRIO

ACP—DAT ACHECK

ACP_SWAPFLGS

ACP_WRITEBACK

BUGCHECKFATAL

BUGREBOOT

CRDENABLE

DEADLOCK_WAIT

DEFPRI

DISMOUMSG

DUMPBUG

EXTRACPU

LAMAPREGS

MAXSYSGROUP

MOUNTMSG

MVTIMEOUT

PAGFILCNT

PQL_DCPULM
PQL_MCPULM

PQL_DPRCLM

PQL_DTQELM

PQL_MPRCLM

PQL—MTQELM

REALTIME _SPTS

SAVEDUMP

SCSSYSTEMID

SWPFILCNT

TIMEPROMPTWAIT

TTY_ALT ALARM

TTY—ALTYPAHD

TTY_BUF

TTY_DIALTYPE

TTY_OWNER

TTY_PARITY

TTY_PROT

TTY_RSPEED

TTY_SC ANDELT A

TTY_SILOTIME

TTY_SPEED

TTY_TYPAHDSZ

UAFALTERNATE

USER3

USER4

USERD1

USERD2

XFMAXRATE

11-20

Parameters Collected in OLDSITE2.DAT and
Propagated to New System if Old Current Value
Exceeds Old Default Value

System Generation

Table 11-8

Version 4.4 Parameters Collected in OLDSITE4.DAT
and Propagated to New System if Old Current Value
Differs from Old Default Value

DISK_QUORUM

ALLOCLASS

LNMPHASHTBL

LNMSHASHTBL

LOCKDIRWT

PRCPOLINTERVAL

QDSKINTERVAL

QDSKVOTES

QUORUM

RECNXINTERVAL

SCSNODE

SCSSYSTEMIDH

TAILORED

TTY_DEFCHAR

TTY_DEFCHAR2

VOTES

Table 11-9

Parameters Modified in AUTOGEN Calculations

ACR—DIRCACHE

ACP_HDRCACHE

ACP—MULTIPLE

ACP_QUOCACHE

ACP_SWAPFLGS

ACP—SYSACC

BALSETCNT

BORROWLIM

FREEGOAL

FREELIM

GBLPAGES

GBLPAGFIL

GBLSECTIONS

GROWLIM

IRPCOUNT

IRPCOUNTV

LOCKIDTBL
LRPCOUNTV

ACP_MAPCACHE

LOCKIDTBL_MAX

LRPCOUNT

MAXPROCESSCNT

MPW_HILIMIT

MPW_LOLIMIT

MPW—WAITLIMIT

NPAGEDYN

NPAGEVIR

PAGEDYN

PFCDEFAULT

PFRATL

RESHASHTBL

SCSCONNCNT

SPTREQ

SRPCOUNT

SRPCOUNTV

SCSMWCNT

VAXCLUSTER

VIRTU ALP AGECNT

WSMAX

WS_OPAO

11-21

Using BOOT58 on VAX-11 / 750 Systems

This appendix explains how to bootstrap VAX-11/750 systems using the
standalone BOOT58 program stored on the TU58 tape cartridge.
In most cases it is quicker, easier, and the recommended procedure to
bootstrap the system directly from a system disk. When you do this, however,
the bootblock program must read and execute the boot block (block 0). If this
block is corrupted, and the rest of the disk is intact, the only way to boot a
VAX-11/750 system safely is to use standalone BOOT58. Later, you can use
the Writeboot Utility (WRITEBOOT), described in Section A.2, to replace the
bad boot block.
The standalone BOOT58 program resides on the console TU58 tape cartridge
and is used to supplement the console subsystem's bootstrapping functions.
When you request a boot from the console TU58 tape cartridge (device
DDAO), the console subsystem microcode reads the TU58 boot block (block
0) into memory and executes it. The effect of executing the TU58 boot block
is to load and transfer control to standalone BOOT58.
Using standalone BOOT58, you can boot the system either in a conversational
or nonstop mode. In a conversational boot, you are allowed to intervene with
system parameter changes as the boot is progressing. The nonstop boot does
not allow you this flexibility.
The console TU58 tape cartridge contains two sets of bootstrap command
procedures—a set of conversational procedures, and a set of nonstop
procedures. To determine which procedures are available on your console
volume, refer to Section 2.4.
Table A-l summarizes BOOT58 commands.
Table A-1

BOOT58 Commands

Command

Function

BOOT [device-name]

Bootstraps the system from the specified
device. If you omit the device name,
the system is bootstrapped using the
default bootstrap command procedure
(DEFBOO.CMD). Note that you cannot
specify this command within a command
procedure, and that you cannot use the
name of a command procedure as a
command qualifier.

A-1

Using BOOT58 on VAX—11/750 Systems

Table A-1 (Cont.)

BOOT58 Commands

Command

Function

DEPOSIT [loc-qual,
size-qual] location value

Deposits a value in the specified location.
The location is interpreted according to the
location and size qualifiers. The location
qualifier can be expressed as follows:
/G
general register
/I

internal processor register

physical memory

The size qualifier can be expressed as
follows:
/B
byte
/W

word

longword

If you do not specify the location and size
qualifiers, the default values established by
a previous command are used.
EXAMINE [loc-qual,
size-qual] location

Displays the contents of the specified
location. The location is interpreted
according to the location and size qualifiers.
The location qualifier can be expressed as
follows:
/G
general register
/I

internal processor register

physical memory

The size qualifier can be expressed as
follows:
/B
byte
/W

word

longword

If you do not specify the location and size
qualifiers, the default values established by
a previous command are used.

A—2

HELP

Displays the BOOT58 help file at the
console terminal. You cannot specify this
command within a command procedure.

LOAD file-spec
[/ST ART :address]

Loads a file from the bootstrap device into
memory, starting at the address specified
with the /START qualifier. If you omit the
/START qualifier, the file is loaded into
memory beginning at the first free address.

Using BOOT58 on VAX-11/750 Systems

Table A-1 (Cont.)

A.1

BOOT58 Commands

Command

Function

START value

Transfers control to the value specified.
You generally use this command with the
LOAD command.

@file-spec

Executes the name of the command
procedure specified. You cannot specify
a command procedure file specification
of more than six characters, nor can you
specify nested command procedures.

Bootstrap Procedures
You can select one of the following procedures to bootstrap your
VAX-11/750 system using BOOT58:
•

Default

•

Conversational

•

Nonstop

These procedures are described in the next sections.

A. 1.1

Default Bootstrap
To bootstrap the system using the default command procedure that you
copied to the file DEFBOO.CMD, follow these steps:
1

Shut down the system by executing the SHUTDOWN command
procedure:
$ <DSYS$SYSTEM: SHUTDOWN

The command procedure prompts for the number of minutes until system
shutdown, the reason for the shutdown, and whether to spin down the
disks.
2

In response to the statement, "SYSTEM SHUTDOWN COMPLETE - USE
CONSOLE TO HALT THE SYSTEM," halt the processor by pressing
CTRL/P.

In response to the console prompt (> > > ), enter the following
command:
»> B DDAO

Note: To prevent an automatic default booting, in cases where DEFBOO.CMD
is already included on the TU58, use the command B/800 DDAO.

A—3

Using BOOT58 on VAX—11/750 Systems

A.1.2

Conversational Bootstrap
To do a conversational bootstrap using the standalone BOOT58 program,
proceed as follows:
1

Insert the console TU58 tape cartridge (part description: BE-T204F-ME
TU58#1 VAX-11/750 Local Console) into the console drive.

See that the rotary key switch on the processor control panel is set to
LOCAL.

Set the POWER-ON-ACTION switch to HALT.

Press CTRL/P to obtain the console program prompt (> > > ).

At the prompt, enter the following console BOOT command to boot the
TU58 tape cartridge:
»> B/800 DDAO

Note: If you fail to add the /800 qualifier, the console program tries to
execute DEFBOO.CMD.
6

In response to the BOOT58> prompt, enter the name of a conversational
bootstrap command procedure:
B00T58> GDxyGEN

Indicates that the rest of the line contains the name of a command
procedure located on the console TU58 tape cartridge.

Indicates the device type of the desired bootstrap volume:
B—RM03, RM80, RP05, RP06, RP07
L—RL02
M—RK07
U—UDA

Indicates the unit number of the desired bootstrap device volume.
Specify a number in the range of 0 through 7.

When SYSBOOT is ready to accept commands, it prompts as follows:
%y.
SYSB00T>

The two percent signs (%%) that appear above the SYSBOOT > prompt
indicate a successful verification of the microcode. You can now issue any of
the commands listed in Table 4-1.
If your system will not boot, you can enter the following sequence of
SYSBOOT commands after the SYSBOOT > prompt to boot using default
system parameter values:
SYSB00T> USE DEFAULT
SYSB00T> CONTINUE

The following example shows a conversational bootstrap procedure on a
VAX-11/750 system using the standalone BOOT58 program. During the
procedure, the user sets the value of the system parameter WSMAX to
512. Note that before displaying the BOOT58> prompt, the VAX-11/750
responds with a double percent sign to indicate successful verification of the
microcode.

A-4

Using BOOT58 on VAX-11/750 Systems

»> B/800 DDAO

n
B00T58> ODMOGEN
DMO CONVERSATIONAL BOOT COMMAND FILE - DMOGEN
BOOT FROM DMO AND STOP IN SYSBOOT TO ALTER PARAMETER VALUES
D/G 0 1

! CARTRIDGE DISK

D/G 1 FFEOOO

! BASE OF UNIBUS I/O PAGE

D/G 2 3FF20

! CSR ADDRESS OFFSET

D/G 3 0

! CONTROLLER UNIT = 0

D/G 4 0

! BOOT BLOCK LBN

D/G 5 1

! SOFTWARE BOOT FLAGS

D/G E 200

! ADDRESS OF WORKING MEMORY + ~X200

LOAD VMB.EXE/START:200

! LOAD PRIMARY BOOTSTRAP

START 200

! START PRIMARY BOOTSTRAP

(UNUSED)
(CONVERSATIONAL)

SYSBOOT> SET WSMAX 512
SYSBOOT> CONTINUE
VAX/VMS Version 4.4 15-APR-1986-14:20:50.15
7.7.y.7.7.y.7.7.7.7.y. OPCOM, 15-APR-1986-14:20:50.15 VWWWIXVL
Logfile has been initialized by operator _OPAO:
Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1
7.SET-I-INTSET, login interactive limit = 64, Current interactive value = 0
SYSTEM
job terminated at 15-APR-1986-14:20:50.15

A. 1.3

Nonstop Bootstrap
If you want to bootstrap the system without stopping to change parameters,
follow steps 1 through 5 for the conversational bootstrap procedure described
in the previous section. Then, in response to the BOOT58> prompt, enter
the name of a nonstop bootstrap command procedure in the following format:
B00T58> ODxyBOO.CMD

Indicates that the rest of the line contains the name of a command
procedure located on the console TU58 cartridge.

Indicates the device type of the desired bootstrap device volume:
B—RM03, RM80, or RP06
M—RK07

Indicates the unit number of the desired bootstrap volume. Specify a
number in the range of 0 through 7.

If you use this form (that is, @DxyBOO.CMD), the contents of the command
procedure are displayed on the console terminal.
The following example shows a nonstop bootstrap procedure on a
VAX-11/750 system using the standalone BOOT58 program. Note that
before displaying the BOOT58> prompt, the VAX-11/750 responds with a
double percent sign to indicate successful verification of the microcode.

A—5

Using BOOT58 on VAX-11/750 Systems

»> B DDAO

n
B00T58> QDM0B00.CMD

DM0 BOOT COMMAND FILE - DMOBOO.CMD
D/G 0 1

CARTRIDGE DISK

D/G 1 FFEOOO

BASE OF UNIBUS I/O PAGE

D/G 2 3FF20

CSR ADDRESS OFFSET

D/G 3 0

CONTROLLER UNIT = 0

D/G 4 0

BOOT BLOCK LBN

D/G 5 0

SOFTWARE BOOT FLAGS

D/G E 200

ADDRESS OF WORKING MEMORY + ~X200

(UNUSED)

LOAD VMB.EXE/START:200 ! LOAD PRIMARY BOOTSTRAP
START 200

START PRIMARY BOOTSTRAP

VAX/VMS Version 4.4 15-APR-i986-14:20:50.15

mxmuu

OPCOM, 15-APR-1986-14: 20: 50.15 XXXXXXltm
Logfile has been initialized by operator _OPAO:
Logfile is SYS$SYSROOT:[SYSMGR]OPERATOR.LOG;1
'/.SET-I-INTSET, login interactive limit = 64, Current interactive value = 0
SYSTEM
job terminated at 15-APR-1986-14:20:50.15

A. 2

The Writeboot Utility
This section discusses the Writeboot Utility (WRITEBOOT), which writes a
boot block on a bootable disk.
The normal bootstrap operation on the VAX-11/750 is done from the boot
block (block 0) of the system disk. If this block is corrupted, the system can
only be bootstrapped from the TU58. Once the system is running again, the
bad boot block can be rewritten by using WRITEBOOT.
Note: The L0G_I/0 privilege is required to use WRITEBOOT.
To invoke WRITEBOOT, type the following command at the DCL prompt:
$ RUN SYS$SYSTEM:WRITEBOOT

WRITEBOOT will prompt for input. Prompts and recommended responses
follow.
Target system device (and boot file if not VMB.EXE):?

Enter the name of the device on which you want to rewrite the boot block
(DMAO for example).
Note: The boot file must be on the target disk.
The target system device should be specified like any VAX/VMS disk device
(ddcu):
dd is the code name for the device type
c is the controller designation
u is the unit number
For example, DMAO would be an RK07 on RK611 controller A, device
number 0. If you want to use a boot file other than SYS$SYSTEM:VMB.EXE,
you must provide the full file specification, including device and directory.
Enter VBN of boot file code (default is one):

A—6

Using BOOT58 on VAX-11/750 Systems

If you are rewriting the boot block, press RETURN.
Enter load address of primary bootstrap in HEX (default is 200):

Again, if you are rewriting the boot block, press RETURN.
WRITEBOOT will then write the boot file that you specified in the first line,
to the address that you entered in the third line.
The Writeboot Utility may issue one or more of the following error
messages:
You lack LOG—IO privilege
Explanation: This message means you do not have the correct privilege to
use WRITEBOOT.
You lack READ and/or WRITE access to TARGET DEVICE. DISMOUNT and
REMOUNT
Explanation: This message means that access to the target device is limited.
Check the WRITE PROTECT button.
VBN must be > = 1
Explanation: This message means you cannot specify a zero as the virtual
block number (VBN).

A—7

Technical Note on VAX/VMS Cl

This appendix describes the Computer Interconnect (Cl) and System
Communications Services (SCS) including information on trouble-shooting
and repairs. Information on Cl entries in the system error log and on
corrective actions to take when errors occur is also provided.

B.1

Cl Port and System Communications Services Operation
The following sections describe the Cl port and the operation of System
Communications Services (SCS).

B. 1.1

Cl Port Polling and Virtual Circuits
Shortly after VAX/VMS boots, the Cl port driver begins configuration polling
in order to discover other active ports on the Cl. Normally the poller runs
every five seconds (the default value of SYSGEN parameter PAPOLLINT.) In
the first polling pass, port numbers 0 through 15 are probed over cable path
A; on the second pass port numbers 0 through 15 are probed over path B; on
the third pass path A is probed again, and so on.
The poller probes by sending request id (REQID) packets to all possible port
numbers, including itself. Active ports receiving the REQIDs return id packets
(IDREC) to the port issuing the REQID. A port may respond to a REQID
whether or not the system attached to the pirt is running.
Once a pair of ports and port drivers has successfully exchanged id packets,
the port drivers perform a start handshake. They exchange datagrams
containing information about the systems such as the type of CPU (for
example, V780, V750, HSC) and the operating system version. If this
exchange is successful, then each system declares a virtual circuit (VC)
open. An open VC is prerequisite to all other activity. Each port supports up
to 16 VCs.

B. 1.2

System Communications Services Connections
System services such as the disk class driver, the VAXcluster connection
manager, and the MSCP disk server communicate between systems with a
protocol called System Communications Services (SCS). Primarily, SCS is
responsible for the formation and breaking of intersystem process connections
and for flow control of message traffic over those connections. In VAX/VMS
Version 4.4, SCS is implemented in the Cl port driver and in a loadable piece
of the system called SCSLOA.EXE (loaded automatically during initialization).
When a VC has been opened, a VAX/VMS system periodically probes a
remote system for system services that it may be offering. The SCS directory
service, which makes known other services that its system is offering, is
always present on both VAX/VMS and HSC systems. As system services
discover their counterparts on other systems, they establish SCS connections
to each other. These connections are full duplex and are associated with a
B—1

Technical Note on VAX/VMS Cl

particular VC. Multiple connections are typically associated with a virtual
circuit.

B.1.3

Failures
Taken together, SCS, the Cl port driver, and the Cl port itself support a
hierarchy of communications paths. Working up from the most fundamental
level there are:
•

The physical wires (two pairs of transmit and receive) Path A transmit
and receive and Path B transmit and receive. Normally, traffic is sent by
VAX/VMS in automatic path select mode and the port chooses the free
path or, if both are free, an arbitrary path (implemented in the cables, star
coupler, and managed by the port).

•

The port-to-port virtual circuit (implemented partly in the Cl port and
partly in system software).

•

The connections (implemented in system software).

Failures can occur at each communications level and in each component.
Failures at one level translate into failures at lower levels as follows:
•

Wires. One of Path A or B can fail and the VC remains intact. All traffic
is directed over the remaining good path. If the wire is repaired, the repair
is detected automatically by port polling, and done to all ports.

•

Virtual circuit. If neither Path A nor B works between a pair of ports, then
the VC fails and is closed. Path failures are discovered either by
— Attempting to send normal traffic with the port reporting that neither
path yielded transmit success
— The poller sending REQIDs over Path A and B periodically when both
paths are nonfunctional
When a whole VC fails, every SCS connection on it fails. The software
automatically reestablishes connections when the VC is reestablished.
Normally, reopening a VC takes about 10 seconds after the source of the
problem disappears.

•

Port. If a port fails, then all the VCs to that port fail and all SCS
connections on those VCs fail. If the port is successfully reinitialized,
VCs and connections will be reestablished automatically. Normally,
reinitialization and connection reestablishment takes about 10 seconds.

•

Connection. When the software protocols fail in some way or, in some
instances, when the software thinks it detects a hardware malfunction, a
connection is disconnected. Other connections are normally unaffected, as
is the VC.

•

System. If a whole system fails by operator shutdown, bugcheck, or halt
and reboot, then its port fails and all other systems on the Cl note this as
failures of their VCs to the port on this system.

One interesting situation is the case where a system halts, but no INIT
(11/750) or UNJAM (11/780) is done. The port remains running and
other systems on the Cl cannot detect the failed system. The VAXcluster
services on the failed system appear simply to be hung, because the port is
an independent processor and continues to handle incoming traffic and to
respond to REQIDs. (The same effect is achieved if the failed system is hung
B—2

Technical Note on VAX/VMS Cl

at IPL 8 or above.) VAX Cl ports normally run with a sanity timer enabled,
which puts the port into an uninitialized state detectable by other nodes as a
failed VC if the host appears to be hung for 100 seconds. This interval will
be reduced with the next release of Cl port microcode.

B.2

Trouble-Shooting
This section contains advice on how to determine which system in the
VAXcluster and which component in that system is causing errors. These
determinations can often be made without interrupting timesharing activity
on systems in the VAXcluster.

B.2.1

Adding Nodes to a VAXcluster
Before you bring up as a part of a VAXcluster a system that is new, just
repaired, or suspected of having a problem, you should verify that the system
runs correctly on its own. Although this precaution cannot guarantee that
VAXcluster software will run correctly over the Cl, it can help track down
errors if they should occur.
If only an HSC disk is available for booting, you will be unable to verify the
system on its own and you can proceed to step 2. If a local MASSBUS or
UNIBUS disk is available for booting, you can use step 1 to boot your system
almost entirely in isolation from Cl activity.
1

Perform a conversational boot. While running SYSBOOT, suppress port
activity with the following commands:
SYSB00T> SET PAN0P0LL 1
SYSB00T> SET VAXCLUSTER 0

Having booted in this way, you can run any desired tests to verify the
system, independent of the CL
Also, since the above SYSGEN parameters still permit the Cl port to be
autoconfigured and initialized, you can verify minimal Cl port capabilities.
Use the following command to check that the port is initialized and is on
line:
$ SHOW DEVICE PAAO

The device should be on line and have zero errors. If it has errors and/or
is off line, check the error log. If the port failed to initialize because of
device errors, read the section of the VAX/VMS Release Notes Version 4.4
concerning Cl port microcode revision levels. Corrupted port microcode
files and incompatible microcode files and proms are two reasons for
continuous port errors upon initialization.
2

When the system has been verified (or if no local boot device is
available), boot the system in a VAXcluster from its normal boot device.
Remember to do a conversational boot the first time and specify a unique
SCSSYSTEMID and SCSNODE for the system. Also, if necessary, restore
PANOPOLL to its default value of 0 and set VAXCLUSTER =1 (if the
system will be joining a VAXcluster).
As the system boots, watch the OP AO terminal for %CNXMAN messages
that indicate that this system is discovering other systems and forming
connections to their connection managers. (See the Guide to VAXclusters,
Appendix B, for detailed descriptions of these messages.) Also, note any

B—3

Technical Note on VAX/VMS Cl

Cl port error messages on OP AO. These are documented in section B.7 of
this appendix.
If the system fails to come all the way up so that you can log in and
use it, but no obvious error information is on device OPAO, then check
the status of the failing system from other VMS nodes using the SHOW
CLUSTER/CONTINUOUS command of the Show Cluster Utility. See the
VAX/VMS Show Cluster Utility Reference Manual for more detail.
3

B.2.2

In diagnosing these problems, it is useful to tailor the SHOW CLUSTER
report by the command ADD CIRCUIT CABLE_ST. This command adds
a class of information about all the virtual circuits as seen from the system
on which you are running SHOW CLUSTER. Primarily, you are checking
whether there is a virtual circuit in the OPEN state to the failing system.
Common causes of failure to open a VC and keep it open are:
•

Port errors on one side or the other

•

Some cabling errors

•

A port set off line due to software problems

•

Insufficient nonpaged pool available on both sides

•

Failure to set the SYSGEN parameters SCSNODE, SCSSYSTEMID,
PAMAXPORT, PANOPOLL, PASTIMOUT, and PAPOLLINT correctly

If no VC is open to the failing system, check the bottom of the SHOW
CLUSTER display for circuit information to the port of the failing system.
VCs in partially open states are placed at the bottom of the display. If the
circuit is there in a state other than OPEN, communications between the
local port and remote port are taking place and the failure is probably at
a higher level in the communications than in port or cable hardware.
Secondarily, check that both Paths A and B are good to the failing
port, although the loss of one path should not prevent a system from
participating in a VAXcluster.

Run SHOW CLUSTER from each running system in the VAXcluster to see
that each system's view of the failing system is consistent with every other
system's view. If all the running systems have a consistent view of the
failing system, chances are the problem is in the failing system. If, on the
other hand, only one of several running systems thinks the newcomer is
failing, then perhaps the problem is in that one running system.

Crossed Cables and Loopback Datagrams
Whenever the configuration poller finds that no port-to-port virtual circuits
are open and that no handshake procedures are currently opening virtual
circuits, the poller analyzes its environment. It does so by using the sendloopback-datagram facility of the Cl port.
The send-loopback-datagram facility tests the connections between the Cl
port and the Star coupler by routing a message across them. The messages
are called loopback datagrams. (The port processes other self-directed
messages without using the Star coupler or external cables.)
The configuration poller makes entries in the error log whenever it detects
a change in the state of a circuit. Note, however, that it is possible for
two changed-to-failed-state messages to be entered in the log without an
intervening changed-to-succeeded-state message. Such a series of entries
means that the circuit state continues to be faulty.
B—4

Technical Note on VAX/VMS Cl

The following paragraphs discuss various incorrect Cl cabling configurations
and the entries made in the error log when these configurations exist.
Figure B-l shows a two-node configuration with all cables correctly
connected.
Figure B-1

A Correctly Connected Two-Node Cl VAXcluster

ZK-1924-84

Figure B-2

Crossed Cl Cable Pair

ZK-1925-84

Figure B-2 shows a Cl VAXcluster with a pair of crossed cables. If a pair of
transmitting cables or a pair of receiving cables is crossed, a message sent on
TA is received on RB, and a message sent on TB is received on RA. This is
a hardware error condition from which the port cannot recover. An entry is
made in the error log to say that a single pair of crossed cables exists. The
entry contains the lines
DATA CABLE(S) CHANGE OF STATE
PATH 1.
LOOPBACK HAS GONE FROM GOOD TO BAD

If this situation exists, you can correct it by reconnecting the cables properly.
The cables could be misconnected in several places. The coaxial cables that
connect the port boards to the bulkhead cable connectors can be crossed,
or the Ethernet cables can be misconnected to the bulkhead or the STAR
coupler.
The information in Figure B-2 can be represented more simply. Configuration
1 shows the cables positioned as in Figure B-2, but it does not show the
star coupler or the nodes. The letters LOC and REM indicate the pairs of
transmitting (T) and receiving (R) cables on the local and remote nodes,
respectively.

B—5

Technical Note on VAX/VMS Cl

Configuration 1
T x

= R

R =

= T

LOC

REM

The pair of crossed cables causes loopback datagrams to fail on the local
node, but succeed on the remote node. Crossed pairs of transmitting cables
and crossed pairs of receiving cables cause the same behavior.
Note that only an odd number of crossed-cable pairs causes these problems.
If an even number of cable pairs is crossed, communications succeed. An
error log entry is made in some cases, however, and the contents of the entry
depends on which pairs of cables are crossed.
Configuration 2 shows two-node VAXclusters with the combinations of two
pairs of crossed-cable pairs. These crossed pairs cause the following entry to
be made in the error log of the node that has the cables crossed:
DATA CABLE(S) CHANGE OF STATE
CABLES HAVE GONE FROM UNCROSSED TO CROSSED

Loopback datagrams succeed on both nodes, and communications are
possible.

Configuration 2
T x

= R

T =

x R

R x

= T

R =

x T

LOC

REM

LOC

REM

Configuration 3 shows the possible combinations of two pairs of crossed
cables that cause loopback datagrams to fail on both nodes in the cluster.
Communications can take place between the nodes nevertheless. An entry
stating that cables are crossed is made in the error log of each node.

Configuration 3
T x

= R

T =

R *

x T

R x

x R
= T

LOC

REM

LOC

REM

Configuration 4 shows the possible combinations of two pairs of crossed
cables that cause loopback datagrams to fail on both nodes in the cluster, but
allow communications. No entry stating that cables are crossed is made in
the error log of either node.

Configuration 4
T x

x R

T =

= R

R =

= T

R x

x T

LOC

REM

LOC

REM

Configuration 5 shows the possible combinations of three pairs of crossed
cables. In each case, loopback datagrams fail on the node that has only one
crossed pair of cables. Loopback datagrams succeed on the node with both
pairs crossed. No communications are possible.

B—6

Technical Note on VAX/VMS Cl

Configuration 5
T x

x R

T x

= R

T =

x R

T x

x R

R x

= T

R x

x T

R x

x T

R =

x T

LOC

REM

LOC

REM

LOC

REM

LOC

REM

If all four cable pairs between two nodes are crossed, communications
succeed, loopback datagrams succeed, and no crossed-cable message entries
are made in the error log. Such a condition might be detected by noting error
log entries made by a third system in the VAXcluster, but only if the third
node has one of the crossed-cable cases described above.

B.3

Repairing Cables
This section describes some ways in which DIGITAL Field Service can make
repairs on a running system. This information is provided to aid system
managers in scheduling repairs.
In order for the software to survive cable-checking activities or cablereplacement activities, you must be sure that at least Path A or Path B is
intact at all times between each port and every other port in the VAXcluster.
You can, for example, remove Path A and Path B in turn from a particular
port to the Star coupler. To make sure that the configuration poller finds a
path that was previously faulty but is now without fault, you must time your
operations as follows:
1

Remove Path B.

2 After the poller has discovered that Path B is faulty, reconnect Path B.
3 Wait two poller intervals (or run SHOW CLUSTER) to make sure
that the poller has reestablished Path B. Or, run SHOW CLUSTER
/CONTINUOUS and ADD CIRCUITS, CABLE _ST; wait until SHOW
CLUSTER tells you that Path B has been regained.

4 Remove Path A.
5 After the poller has discovered that Path A is faulty, reconnect Path A.
6 Wait two poller intervals to make sure that the poller has reestablished
Path A.
If both paths are lost at the same time, then the port-to-port virtual circuits
are lost between the port with the broken cables and all other ports in the
VAXcluster. This will in turn result in loss of SCS connections over the
broken virtual circuits. However, recovery from this situation is automatic
after an interruption in service on the affected node. The length of the
interruption varies but is usually about two poller intervals or 10 seconds at
the default SYSGEN parameter settings.

B—7

Technical Note on VAX/VMS Cl

B.4

Analyzing VAXcluster Error Log Entries
Part of anticipating and avoiding problems is to monitor the activities of the
system; important events are recorded in the error log. From the total error
count, displayed by the DCL command SHOW DEVICE PA, you can tell if
errors have been increasing. If so, you should examine the error log.
The ANALYZE/ERROR—LOG command invokes the Error Log Utility
to report the contents of an error log file. For more information, see the
VAX/VMS Error Log Utility Reference Manual.
Note: Some error log entries are informational only, and require no action.
If you shut down a system in the VAXcluster, for example, all other
systems in the cluster that have open port-to-port virtual circuits between
themselves and the shut down system make entries in their error logs.
Such systems record up to three errors for the event: Path A got no
response. Path B got no response, the virtual circuit is being closed. These
messages are normal and reflect the change of state in the circuits to the
shut down system.
On the other hand, some error log entries are made for problems that degrade
operation, or for nonfatal hardware problems. VMS might continue to run
satisfactorily under these conditions. The purpose of detecting these problems
early is to prevent nonfatal problems (such as loss of a single path) from
becoming serious problems (such as loss of both paths).

B.5

Error Log Entry Formats
Errors and other events on the Cl cause the port driver to enter information
into the system error log. The two formats used for Cl error log entries are
the device-attention format and the logged-message format. This section
describes those formats.
Device-attention entries record events that, in general, are indicated by the
setting of a bit in a hardware register. Logged-message entries record the
receipt of a message packet that contains erroneous data or that signals an
error condition.

B.5.1

Device-Attention Entries
Example B-l shows a device-attention entry. The left column gives the
name of a device register or a memory location, the center column gives the
value contained in that register or location, and the right column gives an
interpretation of that value.

B—8

****************************

ENTRY

83.

*******************

ERROR SEQUENCE 10.
DEVICE ATTENTION,

Cl SUB-SYSTEM,

LOGGED ON SID
17-MAY-1986 17:11:33.99
KA780 REV #10. SERIAL #10.

STAR$PAA0:

CNFGR

MFG PLANT 0.

- PORT POWER DOWN

00800038
ADAPTER IS Cl
ADAPTER POWER-DOWN

PMCSR

OOOOOOCE

MAINTENANCE TIMER DISAB
MAINTENANCE INTERRUPT
MAINTENANCE INTERRUPT
PROGRAMMABLE STARTING
UNINITIALIZED STATE
PSR

80000001

RESPONSE QUEUE AVAILAB
MAINTENANCE ERROR
PFAR
PESR
PPR

00000000
00000000
03F80001

UCB$B_ERTCNT

UCB$B_ERTMAX

UCB$L_CHAR

50.

RETRIES REMAINING

50.

RETRIES ALLOWABLE

0C450000
SHAREABLE
AVAILABLE
ERROR LOGGING
CAPABLE OF INPUT
CAPABLE OF OUTPUT

UCB$W_STS

0010

UCB$W_ERRCNT

000B

ONLINE
11.

ERRORS THIS UNIT

O The first two lines are the entry heading. These lines
of the entry in this error log file, the sequence numb
the identification number (SID) of this system's CPU
log file contains such a heading.

0 The next line contains the entry type, the date, and t

© The next line contains the processor type (KA780), th
number of the CPU (REV #10), the serial number of
#10), and the plant number (0).

O The line Cl SUB-SYSTEM, STAR$PAA0: - PORT PO
contains the name of the subsystem and the device
entry, and the reason for the entry. The Cl subsyste
node STAR was powered down.

The next 15 lines contain the names of hardware reg
their contents, and interpretations of those contents.
User's Guide for a description of all the Cl port regist

The Cl port can recover from many errors, but not a
occurs from which the Cl cannot recover, the port no
The port driver logs the error and attempts to reiniti
the port fails after 50 such initialization attempts, the
line unless the system disk is connected to the failing
is supposed to be a VAXcluster member. If the Cl p

Technical Note on VAX/VMS Cl

system disk access or VAXcluster participation and all 50 reinitialization
attempts have been used, then the system bugchecks with a CIPORT-type
bugcheck. Once a Cl port is off line, you can put the port back on line
only by rebooting the system.
© The UCB$B_ERTCNT field contains the number of reinitializations that
the port driver can still attempt. The difference between this value and
UCB$B_ERTMAX is the number of reinitializations already attempted.
© The UCB$B_ERTMAX field contains the maximum number of times the
port can be reinitialized by the port driver.
© The UCB$W_ERRCNT field contains the total number of errors that have
occurred on this port since it was booted. This total includes both errors
that caused reinitialization of the port and errors that did not.

B.5.2

Logged-Message Entries
Logged-message entries are made when the Cl port receives a response that
contains either data that the port driver cannot interpret, or an error code in
the status field of the response.
Example B-2 shows a logged-message entry with an error code in the status
field PPD$B_STATUS.

B—10

******************* ********* ENTRY
ERROR SEQUENCE 3.

3. ******************
LOGGED ON SID 01

ERL$LOGMESSAGE, 17-MAY-1986 13:40:25.13
KA780 REV #3. SERIAL #1346.

MFG PLANT 15.

Cl SUB-SYSTEM, STAR$PAA0:
DATA CABLE(S) STATE CHANGE - PATH #0. WENT FROM GOOD TO BAD
LOCAL STATION ADDRESS, 000000000002 (HEX)
LOCAL SYSTEM ID. 000000000001 (HEX)
REMOTE STATION ADDRESS. 000000000004 (HEX)
REMOTE SYSTEM ID, 0000000000A9 (HEX)
UCB$B_ERTCNT

UCB$B_ERTMAX

UCB$W_ERRCNT

0001

PPD$B_P0RT

PPD$B_STATUS

50. RETRIES REMAINING
50. RETRIES ALLOWABLE
1. ERRORS THIS UNIT
REMOTE NODE #4.
FAIL
PATH #0., NO RESPONSE
PATH #1., "ACK" OR NOT
NO PATH
PPD$B_0PC

PPD$B_FLAGS

IDREQ
RESPONSE QUEUE BIT
SELECT PATH #0.
"Cl" MESSAGE
00000000
00000000
80000004
0000FE15
4F503000
00000507
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000
00000000

© The first two lines are the entry heading. These lines
of the entry in this error log file, the sequence numb
the identification number (SID) of the system's CPU.
file contains a heading.

© The next line contains the processor type (KA780), th
number of the CPU (REV #3), the serial number of t
#1346), and the plant number (15).

Technical Note on VAX/VMS Cl

© The next line gives the reason for the entry (one or more data cables have
changed state), and a more detailed reason for the entry. Path 0, which
the port used successfully before, cannot be used now.
Note: ANALYZE/ERROR—LOG uses the notation path 0 and path 1; cable
labels use the notation path A (=0) and path B (=1).
© The local © and remote © station addresses are the port numbers (range
0-15) of the local and remote ports. The port numbers are set in hardware
switches by field service. The local © and remote © system IDs are the
SCS system IDs set by the SYSGEN parameter SCSSYSTEMID for the
local and remote VAX systems. For HSCs, the system ID is set with the
HSC console.
© The rest of the entry, which consists of the entry fields that begin with
UCB$, gives information on the contents of the unit control block (UCB)
for this Cl device.
The following fields, which begin with PPD$, are fields in the message
packet that the local port has received.
® PPD$B_PORT contains the station address of the remote port. In a
loopback datagram, however, this field contains the local station address.
© The PPD$B_STATUS field contains information on the nature of the
failure that occurred during the current operation. When the operation
completes without error, ERF prints the word NORMAL beside this field;
otherwise, ERF decodes the error information contained in
PPD$B_STATUS. Here a NO PATH error occurred because of a lack of
response on path 0, the selected path.
© The PPD$B_OPC field contains the code for the operation that the port
was attempting when the error occurred. The port was trying to send a
request-for-id message.
© The PPD$B_FLAGS field contains bits that indicate, among other things,
the path that was selected for the operation.
© The "Cl" MESSAGE is a hexadecimal listing of bytes 16 through 83
(decimal) of the response (message or datagram). Since responses are of
variable length depending upon the port opcode, bytes 16 through 83 may
contain either more or fewer bytes than actually belong to the message.
Here the request-for-id contains no information in bytes 16 through 83.

B.6

Error Log Entry Descriptions
This section describes error log entries. Each entry below is followed by a
brief description of what the Cl port driver does, and the suggested action a
system manager should take. In cases where Software Performance Reports
with crash dumps are requested, it is important to capture the crash dumps
as soon as possible after the error. Note that path A and path 0 are the same
path, and that path B and path 1 are the same path.
BIIC FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device offline.
User Action: Call DIGITAL Field Service.

B—12

Technical Note on VAX/VMS Cl

CI PORT TIMEOUT
The CI port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device offline.
User Action: First, increase the SYSGEN parameter PAPOLLINTERVAL.
If the problem disappears and you are not running privileged user-written
software, submit an SPR. Otherwise, call DIGITAL Field Service.
11/750 CPU MICROCODE NOT ADEQUATE FOR PORT
The CI port driver: Sets the port off line with no retries attempted. In
addition, if this port is needed because the system is booted from an HSC or
is participating in a VAXcluster, the system bugchecks with a UCODEREV
code bugcheck.
User Action: Read the VAX/VMS Release Notes Version 4.4 section on the CI
port driver for information on required CPU microcode revisions. Call Field
Service if necessary.
PORT MICROCODE REV NOT CURRENT, BUT SUPPORTED
The CI port driver: Detected that the microcode is not at the current level,
but will continue normally. This error is logged as a warning only.
User Action: Contact Field Service when convenient to have the microcode
updated.
PORT MICROCODE REV NOT SUPPORTED
The CI port driver: Sets the port off line without attempting any retries.
User Action: Read the VAX/VMS Release Notes Version 4.4 for information on
the required CI port microcode revisions. Contact Field Service if necessary.
DATA CABLE(S) STATE CHANGE
CABLES HAVE GONE FROM CROSSED TO UNCROSSED
The CI port driver: Logs this event.
User Action: No action needed.
DATA CABLE(S) STATE CHANGE
CABLES HAVE GONE FROM UNCROSSED TO CROSSED
The CI port driver: Logs this event.
User Action: Check for crossed-cable pairs. See Section B.2.
DATA CABLE(S) STATE CHANGE
PATH 0. WENT FROM BAD TO GOOD
The CI port driver: Logs this event.
User Action: No action needed.
DATA CABLE(S) STATE CHANGE
PATH 0. WENT FROM GOOD TO BAD
The CI port driver: Logs this event.
User Action: Check path A cables to see that they are not broken or
improperly connected.

B—13

Technical Note on VAX/VMS Cl

DATA CABLE(S) STATE CHANGE
PATH 0. LOOPBACK IS NOW GOOD, UNCROSSED
The Cl port driver: Logs this event.
User Action: No action needed.
DATA CABLE(S) STATE CHANGE
PATH 0. LOOPBACK WENT FROM GOOD TO BAD
The Cl port driver: Logs this event.
User Action: Check for crossed-cable pairs or faulty Cl hardware. See
Section B.2.
DATA CABLE(S) STATE CHANGE
PATH 1. WENT FROM BAD TO GOOD
The Cl port driver: Logs this event.
User Action: No action needed.
DATA CABLE(S) STATE CHANGE
PATH 1. WENT FROM GOOD TO BAD
The Cl port driver: Logs this event.
User Action: Check path B cables to see that they are not broken or
improperly connected.
DATA CABLE(S) STATE CHANGE
PATH 1. LOOPBACK IS NOW GOOD, UNCROSSED
The Cl port driver: Logs this event.
User Action: No action needed.
DATA CABLE(S) STATE CHANGE
PATH 1. LOOPBACK WENT FROM GOOD TO BAD
The Cl port driver: Logs this event.
User Action: Check for crossed-cable pairs or faulty Cl hardware. See
Section B.2.
DATAGRAM FREE QUEUE INSERT FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
and 8800) contention.
DATAGRAM FREE QUEUE REMOVE FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures, or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
and 8800) contention.

B—14

Technical Note on VAX/VMS Cl

FAILED TO LOCATE PORT MICRO-CODE IMAGE
The Cl port driver: Marks device off line and makes no retries.
User Action: Make sure console volume contains the microcode file
CI780.BIN, and then reboot the system.
HIGH PRIORITY COMMAND QUEUE INSERT FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
8800) contention.
MSCP ERROR LOGGING DATAGRAM RECEIVED
The Cl port driver: Upon receipt of an error message from the HSC, the
port driver logs the error and takes no other action. It is recommended that
you disable the sending of HSC informational error log datagrams with the
appropriate HSC console command. Informational error log datagrams take
considerable space in the error log data file.
User Action: They are useful to read only if they are not captured on the
HSC console for some reason (for example, the HSC console ran out of
paper.) This logged information is a duplicate of the messages logged on the
HSC console.
INAPPROPRIATE "SCA" CONTROL MESSAGE
The Cl port driver: Closes the port-to-port virtual circuit to the remote port.
User Action: Submit a Software Performance Report to DIGITAL including
the error logs and the crash dumps from the local and remote systems.
INSUFFICIENT NON-PAGED POOL FOR INITIALIZATION
The Cl port driver: Marks device off line and makes no retries.
User Action: Reboot the system with a larger value for NPAGEDYN or
NPAGEVIR.
LOW PRIORITY CMD QUEUE INSERT FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
and 8800) contention.
MESSAGE FREE QUEUE INSERT FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
and 8800) contention.

B—1 5

Technical Note on VAX/VMS Cl

MESSAGE FREE QUEUE REMOVE FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
and 8800) contention.
MICRO-CODE VERIFICATION ERROR
The Cl port driver: Detected an error while reading the microcode that it
just loaded into the port. The driver attempts to reinitialize the port; after 50
failing attempts, it marks the device off line.
User Action: Call DIGITAL Field Service.
NO PATH-BLOCK DURING "VIRTUAL CIRCUIT" CLOSE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Submit a Software Performance Report to DIGITAL including
the error log and a crash dump from the local system.
NO TRANSITION FROM UNINITIALIZED TO DISABLED
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service.
PORT ERROR BIT(S) SET
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: For Cl microcode version 7 or later, a maintenance timer
expiration bit may mean that the PASTIMOUT SYSGEN parameter is set too
low, especially if the local node is running privileged user-written software.
For all other bits, call DIGITAL Field Service.
PORT HAS CLOSED "VIRTUAL CIRCUIT"
The Cl port: Closes the virtual circuit that the local Cl port opened to the
remote port.
User Action: Check the PPD$B_STATUS field of the error log entry for the
reason the virtual circuit was closed. This error is normal if the remote system
crashed or was shut down.
PORT POWER DOWN
The Cl port driver: Halts port operations, and then waits for power to return
to the port hardware.
User Action: Restore power to the port hardware.
Note: Powering the Cl port down from the port's power supply box and then up
while there is any traffic in transit through the port is not supported in
VAX/VMS Version 4.4; however, CPU and whole system power failures
are fully supported.

B-16

Technical Note on VAX/VMS Cl

PORT POWER UP
The Cl port driver: Reinitializes the port and restarts port operations.
User Action: No action needed.
RECEIVED "CONNECT" WITHOUT PATH-BLOCK
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Submit a Software Performance Report to DIGITAL including
the error log and a crash dump from the local system.
REMOTE SYSTEM CONFLICTS WITH KNOWN SYSTEM
The Cl port driver: The configuration poller discovered a remote system
with SCSSYSTEMID and/or SCSNODE equal to that of another system to
which a virtual circuit is already open.
User Action: Shut the new system down as soon as possible. Reboot it with
a unique SCSYSTEMID and SCSNODE. Do not leave the new system up any
longer than necessary. If you are running a VAXcluster and two systems with
conflicting identity are polling when any other virtual circuit failure takes
place in the VAXcluster, then systems in the VAXcluster may crash with a
CLUEXIT bugcheck.
Note: VAX/VMS Version 3.0 systems are exempt from the SCSNODE
uniqueness requirement since they all have built-in node names of
all blanks. Neither can Version 3.0 systems participate in Version 4.4
style VAXclusters. The purpose of the exemption is to allow customers to
phase over from Version 3.0 to Version 4.4 style clusters.
RESPONSE QUEUE REMOVE FAILURE
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service. This error is caused by a failure to
obtain access to an interlocked queue. Possible sources of the problem are Cl
hardware failures or memory, SBI (11/780), CMI (11/750), or BI (8200, 8300,
and 8800) contention.
SCSSYSTEMID MUST BE SET TO NON-ZERO VALUE
The Cl port driver: Sets the port off line without attempting any retries.
User Action: Reboot the system with a conversational boot and set the
SCSSYSTEMID to the correct value. At the same time, check that SCSNODE
has been set to the correct nonblank value.
SOFTWARE IS CLOSING "VIRTUAL CIRCUIT"
The Cl port driver: Closes the virtual circuit to the remote port.
User Action: Check error log entries for the cause of the virtual circuit
closure. Faulty transmission or reception on both paths, for example, causes
this error and may be detected from the one or two previous error log entries
noting bad paths to this remote node.

B—17

Technical Note on VAX/VMS Cl

SOFTWARE SHUTTING DOWN PORT
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Check other error log entries for the possible cause of the port
reinitialization failure.
UNEXPECTED INTERRUPT
The Cl port driver: Attempts to reinitialize the port; after 50 failing attempts,
it marks the device off line.
User Action: Call DIGITAL Field Service.
UNRECOGNIZED "SCA" PACKET
The Cl port driver: Closes the port-to-port virtual circuit to the remote
port. If the virtual circuit is already closed, the port driver inhibits datagram
reception from the remote port.
User Action: Submit a Software Performance Report to DIGITAL, including
the error log file that contains this entry and the crash dumps from both the
local and remote systems.
VIRTUAL CIRCUIT TIMEOUT
The Cl port driver: Closes the virtual circuit that the local Cl port opened
to the remote port. This closure occurs if the remote node is running Cl
microcode version 7 or later, and the remote node has failed to respond to
any messages sent by the local node.
User Action: This error is normal if the remote system halted, crashed, or
was shut down. This error may mean that the local node's PASTIMOUT
SYSGEN parameter is set too low, especially if the remote node is running
privileged user-written software.

B.7

OPAO Error Messages
There are a number of error conditions detected by the Cl port driver
(PADRIVER) which result in an attempt by the driver to log the error
condition. Under a certain set of circumstances, the attempt to log the error
to the error logging device will fail. Such failures often happen because the
error logging device is not accessible, for one reason or another, at the time
the attempt is made to log the error condition. Because of the central role the
Cl plays in VAXclusters, the loss of error logged information in such cases
makes it quite difficult to diagnose and fix problems.
A second, redundant method of error logging captures at least some of the
information about Cl error conditions which would otherwise be lost. This
second method consists of broadcasting selected information about the error
condition to OPAO, in addition to the port driver's attempt to log the error
condition to the error logging device. The Cl port driver attempts both OPAO
error broadcasting and standard error logging under any of the following
circumstances:

B-18

•

The system disk has not yet been mounted.

•

The system disk is undergoing mount verification.

•

During mount verification, it is discovered that the system disk drive
contains the wrong volume.

Technical Note on VAX/VMS Cl

•

The system disk has timed out.

•

The local system is participating in a VAXcluster and quorum has been
lost.

Note the implicit assumption that the system and error logging devices are
one and the same.
This second method of reporting errors is also not entirely foolproof. Because
of the manner in which the OPAO error broadcasting must be performed, it is
possible that some error conditions may not be reported. This situation will
occur whenever a second error condition is detected before the Cl port driver
has had a chance to broadcast the first error condition to OPAO. In such a
case, only the first error condition is reported to OPAO, since it is deemed to
be the more important one.
Certain error conditions are always broadcast to OPAO, regardless of whether
the error logging device is accessible. In general, these are errors that cause
the port to shut down either permanently or temporarily.
There is one OPAO error message for each error condition also subjected
to standard error logging. The text of each error message is similar to
the summary which would otherwise by displayed by formatting the
corresponding standard error log entry using Error Log Utility. See
Section B.6 for a list of the Error Log Utility summary messages and their
explanations.
Many of the OPAO error messages contain some optional information such
as the remote port number. Cl packet information (flags, port operation code,
response status, and port number fields), or specific Cl port registers.
Following is a list of each of the OPAO error messages, subdivided by error
type. The C1780/CI750 User's Guide contains a detailed description of the Cl
port registers (CNF = Configuration Register; PMC = Port Maintenance and
Control Register; PSR = Port Status Register), which are optionally displayed
for certain of the error conditions. The codes, always file accessible, specify
whether the message is always logged on OPAO or only when the system
device is inaccessible.
Software Errors During Initialization (Always Logged on OPAO)
'/.PAxO, Insufficient Non-Paged Pool for Initialization
'/.PAxO, Failed to Locate Port Micro-code Image
'/.PAxO, SCSSYSTEMID has NOT been set to a Non-Zero Value

Hardware Error (Always Logged on OPAO)
'/.PAxO, BIIC failure - BICSR/BER/CNF

xxxxxxxx/xxxxxxxx/xxxxxxxx

'/.PAxO, Micro-code Verification Error
'/.PAxO, Port Transition Failure - CNF/PMC/PSR
'/.PAxO, Port Error Bit(s) Set - CNF/PMC/PSR

xxxxxxxx/xxxxxxxx/xxxxxxxx
xxxxxxxx/xxxxxxxx/xxxxxxxx

'/.PAxO, Port Power Down
'/.PAxO, Port Power Up
'/.PAxO, Unexpected Interrupt - CNF/PMC/PSR

xxxxxxxx/xxxxxxxx/xxxxxxxx

'/.PAxO, Cl Port Timeout
'/.PAxO, Cl port ucode not at required rev level.

RAM/PROM rev is xxxx/xxxx

'/.PAxO, Cl port ucode not at current rev level.

RAM/PROM rev is xxxx/xxxx

'/.PAxO, CPU ucode not at required rev level for Cl activity

B—19

'/.PAxO,

Datagram Free Queue Remove Failure

'/.PAxO, Response Queue Remove Failure
‘/.PAxO, High Priority Command Queue Insert Failure
'/.PAxO,

Low Priority Command Queue Insert Failure

'/.PAxO, Message Free Queue Insert Failure
'/.PAxO, Datagram Free Queue Insert Failure

Errors Signaled with a Cl Packet
'/.PAxO, Unrecognized SCA Packet - FLAGS/OPC/STATUS/PORT
(ALWAYS)

xx/xx/xx/xx

'/.PAxO, Port has Closed Virtual Circuit - REMOTE PORT xxx
(ALWAYS)
'/.PAxO, Software Shutting Down Port
(ALWAYS)
'/.PAxO, Software is Closing Virtual Circuit - REMOTE PORT xxx
(ALWAYS)
'/.PAxO, Received Connect Without Path-Block - FLAGS/OPC/STATUS/PORT
(ALWAYS)
'/.PAxO, Inappropriate SCA Control Message - FLAGS/OPC/STATUS/PORT
(ALWAYS)

xx/x

xx/xx/x

'/.PAxO, No Path-Block During Virtual Circuit Close - REMOTE PORT xxx
(ALWAYS)
'/.PAxO, HSC error Logging Datagram Received - REMOTE PORT xxx
(INACCESSIBLE)
'/.PAxO, Remote System Conflicts with Known System - REMOTE PORT xxx
(ALWAYS)
'/.PAxO, Virtual Circuit Timeout - REMOTE PORT xxx
(ALWAYS)

Cable Change-of-State Notification
'/.PAxO, Path #0. Has gone from GOOD to BAD - REMOTE PORT xxx
(INACCESSIBLE)
'/.PAxO, Path #1. Has gone from GOOD to BAD - REMOTE PORT xxx
(INACCESSIBLE)
'/.PAxO, Path #0. Has gone from BAD to GOOD - REMOTE PORT xxx
(INACCESSIBLE)
'/.PAxO, Path #1. Has gone from BAD to GOOD - REMOTE PORT xxx
(INACCESSIBLE)
'/.PAxO, Cables have gone from UNCROSSED to CROSSED - REMOTE PORT xxx
(INACCESSIBLE)
'/.PAxO, Cables have gone from CROSSED to UNCROSSED - REMOTE PORT xxx
(INACCESSIBLE)

B—20

'/.PAxO, Path #0.
(ALWAYS)

Loopback has gone from GOOD to BAD - REMOTE PORT xxx

'/.PAxO, Path #1.
(ALWAYS)

Loopback has gone from GOOD to BAD - REMOTE PORT xxx

'/.PAxO, Path #0.
(ALWAYS)

Loopback has gone from BAD to GOOD - REMOTE PORT xxx

'/.PAxO, Path #1.
(ALWAYS)

Loopback has gone from BAD to GOOD - REMOTE PORT xxx

'/.PAxO, Path #0. Has become working but CROSSED to Path #1.
(INACCESSIBLE)

- REMOTE PORT

'/.PAxO, Path #1. Has become working but CROSSED to Path #0.
(INACCESSIBLE)

- REMOTE PORT

Technical Note on VAX/VMS Cl

Two other messages concerning the Cl port appear on OPAO. They are:
%PAxO, CI port is reinitializing (xxx retries left.)
'/.PAxO, CI port is going off line.

The first message indicates that a previous error requiring the port to shut
down is recoverable and that the port will be reinitialized. The 'xxx retries
left' is how many more reinitializations are allowed before the port must be
left permanently off line. Each reinitialization of the port (for reasons other
than power fail recovery) causes approximately 2K bytes of nonpaged pool to
be lost.
The second message indicates that a previous error is not recoverable and the
port will be left off line. The only way to recover the port in this case is to
reboot the system.

B-21

Index
Backup operation (cont'd.)

A
Account
adding proxy logins *5-23
creating • 5-10
deleting • 5-15
disabling • 5-17
maintaining* 5-14
restricting use*5-18
Accounting Utility (ACCOUNTING) • 6-19
record types *6-20
system *6-19
ACNT privilege*6-9
Active system
modifying *11-11
Alignment
data *9-15
forms* 9-15
ALLSPOOL privilege • 6-9
ALTPRI privilege • 6-9
Analyzing system failure
small disk systems *3-13
AST queue limit *6-2
Asynchronous DECnet* 11-14
using virtual terminals* 11-12
Authorize Utility (AUTHORIZE) • 5-10
AUTOCONFIGURE command* 1 1-11
AUTOGEN
calculations* 11-21
description* 11-1
execution type parameters* 1 1-3
functions* 11-1
invoking *11-2
modifying calculations* 1 1-7
parameters in OLDSITE*.DAT files* 11-19
phase parameters* 1 1-2
AUTOGEN.PAR parameter file
creating* 11-10
modifying* 11-10
AUTOGEN command procedure*2-1, 2-13, 2-14

B
Backup operation
disk volume set *7-18

image* 7-16
restore *7-25 to 7-31
saving to sequential disk *7-19
multivolume • 7-20
system disk *2-18
volume-by-volume *7-18
Backup Utility (BACKUP)
daily backup*7-22
full-volume save *7-16
image operation • 7-23
incremental backup *7-22 to 7-23
journal files* 7-24
listing files*7-28
loosely coupled volume set *7-20
monthly backup *7-23
public volume *7-14
rotating backup set *7-15
selective backup *7-21 to 7-22
sequential-disk save set*7-19, 7-20
/EXCLUDE qualifier *7-22
/IGNOREHNTERLOCK qualifier • 7-22
/IMAGE qualifier* 7-16, 7-23, 7-25
/INCREMENTAL qualifier• 7-28
/INITIALIZE qualifier *7-19
/JOURNAL qualifier* 7-24
/LIST qualifier *7-24, 7-28
/OWNER_UIC qualifier *7-21
/RECORD qualifier • 7-22
/SINCE qualifier*7-22, 7-23
weekly backup *7-23
Batch job *9-1
controlling *9-10
deleting *9-12
executing • 9-1, 9-16
job card • 9-53
specifying attributes • 9-16
submitting • 2-8, 9-16
Batch queue *9-18
control commands *9-5
deleting • 9-8
for batch systems *9-21
for interactive systems *9-20
for small systems *9-20
pausing • 9-7
stopping • 9-7
BOOT58
bootstrap procedures • A-3

Index-1

Index

BOOT58 (corn'd.)
command summary*A-1
Bootstrap command procedure
conversational • 4-9
copying *4-14
editing *4-15, 4-17
HSC disk*4-13, 4-14, 4-16
modifying *2-12
nonstop *4-9
selecting *2-11
system *4-9
VAX-1 1/780 with interleaved memory *4-18
Buffered I/O byte count limit *6-3
Buffered I/O count limit *6-3
BUGCHK privilege *6-10
Burst bar*9-36
Burst page*9-32
BYPASS privilege *6-10

c
Cable
repairing • B-7
Cache
disk volume information • 7-8
Card
decks *9-53
defective* 9-55
Card reader
operating • 9-53, 9-55
tending • 9-55
translation modes *9-54
Cl (computer interconnect)
communication path
failure* B-2
hierarchy • B-2
error log entry *B-8, B-12
port • B-1
loopback datagram facility • B-4
polling* B-1
CMEXEC privilege *6-10
CMKRNL privilege *6-1 1
Command procedure
copying *4-17
for booting standalone BACKUP *2-19
logout* 5-10
Computer interconnect
See Cl
CONNECT command* 11-11
CONNECT CONSOLE command* 1 1-11

Index—2

CONSCOPY.COM procedure *2-15
Console terminal* 1-2
Console volume
connecting *4-14, 4-16
Copy operation (BACKUP)
copying full volumes and volume sets *7-16
CPU time limit • 6-3
CRASH procedure *4-6
CREATE command* 11-15
Crossed cable*B-4

D
Daily backup*7-22
Data card deck *9-54
DEFAULT account
initial modification • 5-4
user authorization file *5-3
Default bootstrap command procedure
modifying *2-19
renaming *2-19
selecting *2-11
Default directory • 5-6
Default form
systemwide *9-32
DEFB00.CMD procedure
setting up for HSC bootstrap *4-14, 4-16
DEFINE/CHARACTERISTIC command • 9-30
DEFINE/FORM command *9-30
DELETE/QUEUE command *9-8
DETACH privilege*6-11
Device
concealed • 2-6
configuring • 2-4
site-specific startup *2-7
spooled • 9-24, 9-46
Device control library *9-25 to 9-28, 9-34
assigning • 9-27
creating module *9-26
setting up *9-25
Device driver
connecting *11-11
DIAGNOSE privilege*6-1 1
Direct I/O count limit *6-3
Directory
operating system* 1-3
restoring • 7-28
Disabling user account *5-17
Disk
system • 7-3

Index

Disk fragmentation* 11-15
Disk quota *5-6, 7-32
exceeding • 7-33
operation • 7-33
suspension • 7-33
Disk Quota Utility (DISKQUOTA) • 7-32
Disk space management • 7-31 to 7-33
Disk volume
accessing • 7-6
formatting • 7-3
initializing • 7-3
integrity* 7-8
mounting public *2-6
public* 7-1
DISMOUNT command
mount verification cancellation • 7-13
Dual-RL02
customizing *2-1
Dump file* 11-15
size* 11-16
DXCOPY command procedure*2-12

FIELD account (cont'd.)
user authorization file entry *5-3
File
expiration date *7-31
fragmentation *11-15
public* 7-1
recovering lost *5-17
restoring • 7-28
system *11-8, 11-15
File group
creating site-specific • 3-3
File separation pages *9-37 to 9-41
File structure
maintenance* 7-1
Flag page *9-32
Form
aligning printer forms *9-15
defining • 9-31
mounting • 9-30
queue-specific • 9-41
systemwide default *9-32

E
Enqueue quota limit *6-4
ERRFMT process* 10-1
Error log *10-1
maintaining file* 10-2
printing file* 10-3
Error Log Utility* 10-1
Error report* 10-2
Exchange Utility (EXCHANGE)
copying command procedure • 4-14, 4-17
copying the default bootstrap command
procedure* 2-19
Executable image *8-2
See also Image
Execution queue *9-1
Expiration date
file *7-31
Explicit
printing • 9-24
EXQUOTA privilege *6-1 1

FIELD account
initial modification • 5-4

Generic queue *9-2
GROUP privilege*6-8, 6-11
GRPNAM privilege *6-12
GRPPRV privilege *6-12

Hardware problem
reporting *4-18
Header resident image *8-1

i
Image
attributes* 8-1
executable• 8-2, 8-3
execute-only • 8-3
file *8-4
header resident *8-1
known • 8-1
linkable* 8-2
privileged • 8-3
shareable*8-2, 8-3

Index—3

Index

Image operation*7-16, 7-23
copy• 7-16
restore *7-16
save* 7-18
Implicit
printing • 9-24
Incremental backup *7-22 to 7-23
INITIALIZE/QUEUE command *9-6
INITIALIZE command *7-3
Install Utility (INSTALL) • 8-1

JBCSYSQUE.DAT *9-4
JOB card • 9-53
Job controller*9-3
Job queue
small-disk systems *3-12
Job queue manager
restarting • 9-5
starting *9-4
Job separation pages *9-32 to 9-36
Job table quota *6-4
Journal file*7-24

K
Known file list*8-1
privileges* 8-3
startup procedure*8-1
Known image*8-1
deleting *8-4
dismounting volume *8-4
site-specific startup *2-8

Limit (cont'd.)
direct I/O count *6-3
enqueue quota *6-4
open file *6-4
paging file *6-5
process jobs *6-5
shared file*6-5
subprocess creation *6-5
system resources*6-1
timer queue entry *6-6
working set default size *6-6
working set extent *6-6
working set quota • 6-6
Limits and quotas *6-1 to 6-6
Linkable image *8-2
List operation (BACKUP)
using wildcard • 7-29
LOAD command* 11-11
Log file
accounting *6-19
Logical name
assigning systemwide*2-6
Logical queue *9-3, 9-43
assigning *9-43
deassigning *9-43
Login
restricting by function • 5-20
restricting by time *5-19
setting AUTOLOGIN flag *5-20
Login command procedure*5-7
alternate* 5-21
individual *5-7
systemwide* 5-7
user-specified* 5-7
Login procedure
system manager's account *2-2
Login sequence*5-20
LOGIO privilege *6-12
Logout command procedure • 5-10
Lost file
recovering* 5-17

LAT terminal* 11-14
Library
See Device control library
Limit
account jobs*6-4
AST queue *6-2
CPU time*6-3
DEFAULT account *5-1 1
detached process *6-5

Index—4

MA780 multiport memory
installing shared images *8-5
Machine-readable file
for software performance report* 10-10
Magnetic tape
restoring save set
•7-25

Index

Magnetic tape (cont'd.)

OPCOM message (cont'd.)

write ring • 7-8
Maximum account jobs limit *6-4
Maximum detached process limit *6-5
Maximum process jobs limit *6-5
Media security
Backup Utility • 7-23
Merge
output queues*9-8
Message
operator log file* 10-3
Module
device control library *9-25
Monthly backup *7-23
MOUNT/BIND command *7-2
MOUNT/SYSTEM command *7-5
Mounting volume
operator assistance*7-6
MOUNT privilege *6-13
Mount verification • 7-9
abort by dismount • 7-13
canceling • 7-11, 7-12
device offline*7-9
device write lock *7-10
MSCP server
loading and starting* 11-19
Multiport memory
SYSGEN commands* 11-17
MVTIMEOUT system parameter*7-11

mount request *7-7
request display* 10-7
Open file limit *6-4
Operating system
adding to an existing system disk *2-27
building on another disk *2-25
components* 1-3
copying files to another disk *2-26
directories* 1-3
Operator
tasks* 1-2
terminal* 1-1
Operator function* 10-3 to 10-6
handling user request *7-6, 7-7, 10-7
Operator log file* 10-3
example* 10-4
maintaining • 10-6
message* 10-3
printing • 10-6
purging • 2-8
Operator terminal
setting up* 10-7
user request* 10-7
OPER privilege *6-13
Output queue
control commands *9-5
defining form *9-30
deleting • 9-8
establishing* 9-22
merging • 9-8
pausing *9-7
stopping *9-7
Output spooling • 9-46

N
NETMBX privilege *6-13
Network Control Program (NCP)*5-24
Network UAF
creating • 5-22
Node name
for dual-ported disks *4-15, 4-17
Node number
specifying for HSC boot *4-13
Normal privilege • 6-8

o
OPCOM (operator communication facility)* 10-3,
10-5
restarting • 10-7
OPCOM message
enabling an operator terminal* 10-7

p
Paging file* 11-15, 11-16
use in small-disk dump *3-13
Paging file limit • 6-5
Paper stock
specifying • 9-30, 9-41
Parameter file
creating* 11-10
Password
modifying system • 5-4
modifying user *5-5
secondary • 5-5
PASSWORD card *9-53
PFNMAP privilege *6-13
PHY_IO privilege *6-14

Index—5

Index

PRIMARY day
defining *5-19
PRINT command • 9-24, 9-32, 9-42
Print control features
assigning • 9-32
Printer
controlling functions • 9-25
setting characteristics • 2-7
spooled • 9-24
Print job *9-1
aligning forms *9-15
controlling • 9-10
deleting *9-12
explicit printing • 9-24
implicit printing • 9-24
requeuing *9-13
retaining* 9-13
Priority
base* 6-7
Privilege
all *6-8
devour* 6-8
file *6-8
known file lists*8-3
process* 6-7
summary • 6-8
system • 6-8
system management* 1-3
Privileged image *8-1
PRMCEB privilege*6-14
PRMGBL privilege • 6-14
PRMMBX privilege *6-15
Process priority *6-7
Process privilege*6-7
Proxy
adding accounts*5-23
controlling system use *5-24
PSWAPM privilege *6-15
Public disk
copying with Backup Utility *7-16
Public files and volumes *7-1
Public file structure • 7-1
Public volume
backing up* 7-14
mounting • 2-6, 7-5

Queue* 9-1
assigning device control libraries • 9-27

Index—6

Queue (cont'd.)
batch *9-18
command
DEFINE/FORM *9-31, 9-42
DELETE/QUEUE *9-8
INITIALIZE/QUEUE *9-6, 9-42
SET QUEUE *9-7, 9-42
START/QUEUE *9-6, 9-42
START/QUEUE/MANAGER *9-3, 9-5
STOP/QUEUE *9-7
STOP/QUEUE/MANAGER • 9-4
STOP/QUEUE/NEXT • 9-7
STOP/QUEUE/RESET • 9-7
creating • 9-6
creating new queue file *9-5
defining forms *9-30
deleting a job *9-12
deleting a queue *9-8
execution • 9-1
generic batch *9-2
generic output *9-2
initializing • 2-7, 9-6
job queue manager *9-3
logical • 9-3
merging *9-8
modifying • 9-7
output • 9-22
pausing • 9-7
protecting *9-9
restarting • 9-8
specifying attributes*9-32, 9-37
specifying characteristics • 9-29
starting *9-6
stopping *9-7
types *9-1
Queue file
creating new *9-4
Queue Manager
See Job queue manager
Quota
disk *7-32
jobwide logical name table *6-4

R
READALL privilege • 6-15
Real-time priority *6-7
REPLY command
/DISABLE qualifier* 10-7
/ENABLE qualifier* 10-7

Index

Reporting problem *4-18, 4-19
REQUEST command
/REPLY qualifier* 10-7
/TO qualifier* 10-7
Reset sequence *9-34
Resource
limit *6-1
Restart
job controller*9-3
Restore operation • 7-25 to 7-31
Rotating backup set *7-15
Running system
modifying *11-11

s
Save operation (BACKUP)
saving full volumes and volume sets *7-16
Save set
listing contents* 7-28
restoring • 7-25
sequential-disk *7-19
writing multivolume* 7-20
SCS (system communications services) • B-1
SECONDARY day
defining* 5-19
SECURITY privilege *6-15
Selective backup *7-21 to 7-22
using creation date *7-21
using expiration date *7-21
using the /EXCLUDE qualifier*7-22
using UIC*7-21
using wildcards* 7-21
Separation pages
file *9-37 to 9-41
job*9-32 to 9-36
SET/STARTUP command* 1 1-17
SET HOST/HSC command* 11-12
SETPRV privilege *6-16
SET QUEUE command *9-7
Shareable image *8-2
See also Image
file *8-4
with MA780 multiport memory *8-5
SHARE command* 11-17
guidelines* 11-18
Shared files limit *6-5
Shared memory
SYSGEN commands* 11-17
SHARE privilege • 6-16

SHMEM privilege*6-16
SHOW/STARTUP command* 11-17
Shutdown
by forced system failure *4-6
emergency *4-5
site-specific *4-1
system • 4-1
SHUTDOWN.COM procedure*2-14
Shutdown procedure • 2-20
Site-specific startup *2-5
announcements • 2-9
assigning logical names *2-6
installing known images *2-8
setting up queues *2-7
setting up spooled devices *2-7
Small-disk system • 3-1
analyzing system failure *3-13
enabling job queue *3-12
installed file *3-14
Software performance report
See SPR
Software problem
reporting *4-19, 10-8
Spooled device *9-24, 9-46 to 9-52
SPR (software performance report)* 10-8
classes of problems* 10-11
describing problem environment* 10-8
what to include* 10-11
STABACKIT.COM procedure • 2-19
Standalone BACKUP *2-18
alternate disk directory root *2-19
backing up the system disk *2-18
booting from alternate root SYSE*2-19
building on console media *2-21
building on floppy diskettes*2-21
installing in SYSE*2-19
START/QUEUE/MANAGER command *9-3, 9-5
START/QUEUE command *9-6
STARTUP.COM procedure • 2-3
Startup command procedure • 2-3
known file lists • 8-1
site-specific* 2-5
SYSGEN commands* 11-17
system *4-1
STOP/QUEUE/MANAGER command *9-4
STOP/QUEUE/NEXT command *9-7
STOP/QUEUE command *9-7
Subprocess creation limit *6-5
Swap file* 11-15, 11-16
SWAPFILES.COM procedure* 11-15
Symbiont *9-1 to 9-2, 9-7
identifying process *9-3

Index—7

Index

SYS$ANNOUNCE logical name*2-9
SYS$WELCOME logical name *2-10
SYSBOOT program
alternate conversational bootstrap*4-11
alternate nonstop bootstrap *4-10
commands *4-11
default bootstrap *4-10
SYSE
booting standalone BACKUP *2-19
SYSGBL privilege *6-16
SYSGEN
AUTOCONFIGURE command *2-4
invoking *4-16
SYSHUTDWN.COM procedure *4-1
SYSLCK privilege *6-16
SYSNAM privilege *6-17
SYSPRV privilege *6-17
SYSTARTUP.COM procedure • 2-5
operator-assisted mount *7-5
System
accounting *6-19
directories* 1-3
disk fragmentation* 11-15
errors* 10-1
events* 10-1
shutdown *4-1
startup *4-1
SYSTEM account
initial modification • 5-4
user authorization file entry *5-3
System communications services
See SCS
System disk*7-3
System Dump Analyzer (SDA)
site-specific startup • 2-8
System failure
forced • 4-6
reporting • 10-8
system dump analyzer *2-8
System file
manipulating* 11-8
size* 11-15
System generation* 11-1
System Generation Utility (SYSGEN)* 11-9
invoking *4-14
WRITE ACTIVE command* 11-11
System parameter
dynamic* 11-11
modifying • 11-9, 11-10
MVTIMEOUT *7-1 1
used at bootstrap time* 11-9

\ndex—8

System process
OPCOM* 10-5
System security
backup media *7-23
System shutdown procedure • 2-20
SYSTEST account
initial modification • 5-4
user authorization file entry *5-3

T
Tailored system
preparing for UETP*3-11
Tailoring command *3-4
COPY *3-5
DELETE *3-6
DIRECTORY *3-7
DISMOUNT *3-8
EXIT *3-8
HELP *3-8
MOUNT *3-9
RECORD *3-9
SEARCH *3-10
Tailoring facility
creating site-specific file group *3-3
file group description • 3-1
issuing commands *3-4
Tape volume
accessing • 7-6
Terminal
console* 1-2
determining type* 11-14
LAT* 11-14
operator* 1-1
setting characteristics*2-7
site-specific startup *2-7
virtual
See also Virtual terminal
Timer queue entry limit *6-6
TMPMBX privilege *6-17
Trailer page*9-32
Translation modes
card reader *9-54
TU58 cartridge
write protection *2-17

Index

UAF (user authorization file)
creating network *5-22
general maintenance*5-3
initial contents*5-3
initial modification • 5-4
login check*5-20
privileges* 6-8
resource limits *6-1
user priorities*6-7
UAF record
creating multiple default *5-15
UETP (User Environment Test Package)
preparation in tailored system *3-11
UIC (user identification code)
in selective backups *7-21
Unit address
specifying for HSC boot *4-13
User account
deleting *5-15
disabling *5-17
maintaining* 5-14
restricting use *5-18
setting up*5-3
User authorization file
See UAF
User file
placement • 7-2
User resources *6-1
Utility
system management summary* 1-3

Volume
backing up full volumes and volume set *7-16
mounting* 7-6
Volume integrity • 7-8
Volume set *7-2, 7-3, 7-20

w
Weekly backup *7-23
Wildcard character
in selective backup operation • 7-21
Working set
default size • 6-6
extent *6-6
quota *6-6
WORLD privilege*6-18
Writeboot Utility (WRITEBOOT) • A-6
Write lock
mount verification • 7-10

Verification
mount* 7-9
Verify Utility (VERIFY)
Recovering lost files *5-17
Virtual circuit*B-1
Virtual terminal *11-12
VMSKITBLD.COM procedure • 2-24, 2-25, 2-26,
2-27
VMSTAILOR facility
See Tailoring facility
VOLPRO privilege *6-18

Index-9

VAX/VMS
System Manager's
Reference Manual
AA-Y507B-TE

READER'S
r*mMIIUICIM-re

UUIVIIVIbN *

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:
□
□
□
□
□
□

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify) _

Name _Date_
Organization __
Street___
City -State_Zip Code_
or Country

Do Not Tear - Fold Here and Tape

No Postage
Necessary
if Mailed in the
United States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT N0.33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

SSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03062-2698

III.II.II....II....I.II.I..I.I..I.I..II.Ml
Do Not Tear - Fold Here

Cut Along Dotted Line

—

VAX/VMS
System Manager's
Reference Manual
AA-Y507B-TE

READER'S
IMIIMICIMTO

l#UmlVIClll I O

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
ancj 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:
□
□
□
□
□
□

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify) _

Name _Date_
Organization _
StreetCity _State_Zip Code_
or Country

—

Do Not Tear - Fold Here and Tape

mmi

No Postage
Necessary
if Mailed in the
United States

BUSINESS REPLY MAIL
FIRST CLASS PERMIT N0.33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

SSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03062-2698

in
—

—

111

.II....I.II.I..I.I..I.I..II.Ml

Do Not Tear - Fold Here

Cut Along Dotted Line

—