Digital PDFs

DEC-11-OXDIA-E-D

February 1977

101 pages

Original

3.7MB

Document:	RSX-11D System Generation Reference Manual
Order Number:	DEC-11-OXDIA-E-D
Revision:	0
Pages:	101
Original Filename:	http://bitsavers.org/pdf/dec/pdp11/rsx11d/RSX11D_V6.2_Feb77/DEC-11-OXDIA-E-D_RSX-11D_System_Generation_Manual_197702.pdf

OCR Text

RSX-110
System Generation
Reference Manual
Order No. DEC-11-0XDIA-E-D

I
~n~nomo -

RSX-110
System Gener at ion
Reference Manual
Order No. DEC-11-0XDIA-E-D

RSX-110 Version 6.2

digital equipment corporation • ma"nard, massachusetts

First Printing, June 1975
Revised:
November 1975
February 1977

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.
Digital Equipment Corporation assumes no responsibility for the use
or reliability of its software on equipment that is not supplied by
DIGITAL.

1975, 1977 by Digital Equipment Corporation

The postage prepaid READER'S COMMENTS form on the last page of this
document requests the user's critical evaluation to assist us in preparing future documentation.
The following are trademarks of Digital Equipment Corporation:

DIGITAL
DEC
PDP
DECUS
UNIBUS
COMPUTER LABS
COMTEX
DDT
DECCOMM

DECsystem-10
DECtape
DIBOL
EDUSYSTEM
FLIP CHIP
FOCAL
INDAC
LAB-8
DECsystem-20

2/77-14

MASSBUS
OMNIBUS
OS/8
PHA

RSTS
RSX
TYPESET-8
TYPESET-10
TYPESET-11

CONTENTS

Page
PREFACE

CHAPTER

0.1
0.2
0.3

MANUAL OBJECTIVES AND READER ASSUMPTIONS
STRUCTURE OF THE DOCUMENT
ASSOCIATED DOCUMENTATION

vii
vii
vii
vii

OVERVIEW OF SYSTEM GENERATION

1-1

1.1

CONCEPTS AND TERMINOLOGY

1-2

GETTING ON THE AIR

2-1

2.1
THE DISTRIBUTION SYSTEM
Magnetic Tape Distribution
2 .1.1
2.1.1.1
Procedures for Using the System Tape
Procedures for Using Auxiliary Tapes
2.1.1.2
RK05 Cartridge Distribution
2 .1. 2
RK06 Cartridge Distribution
2.1. 3
2.2
ORGANIZATION OF DIRECTORIES ON THE
DISTRIBUTION MEDIA
System Disk Directories
2.2.1
2.2.2
_ Auxiliary Media Directory Contents
2.3
HARDWARE BOOTSTRAPS
2.3.1
MRll-DB Bootstrap
2.3.2
BM792-YB Bootstrap
2.3.3
BM873-YA Bootstrap
BM873-YB Bootstrap
2.3.4
M9301-YC Bootstrap
2.3.5
2.4
TERMINAL HANDLER GENERATION
2.4.1
Introduction
2.4.2
Editing PARAMS.MAC
Editing CONFIG.MAC
2.4.3
Building the Handler
2.4.4
Terminal Handler Error Messages
2.4.5

2-13
2-13
2-15
2-21

SYSTEM GENERATION PROCEDURES

3-1

3.1
3.2

PHASE 1 OF SYSTEM GENERATION
PHASE 2 OF SYSTEM GENERATION

3-2
3-5

SYSTEM GENERATION DIRECTIVES

4-1

4.1
4.2
4.3
4.4
4.4.1
4.5
4.6
4.6.1
4.7
4.8
4.9

TARGET DIRECTIVE
PDPll DIRECTIVE
EXEC DIRECTIVE
SCOM DIRECTIVE
SCOM Size
PAR DIRECTIVE
DEV DIRECTIVE
Pseudo-Devices
SY DIRECTIVE
DPAR DIRECTIVE
DUIC DIRECTIVE
CKPNT DIRECTIVE
PSWD DIRECTIVE
INS DIRECTIVE
SYSBLD DIRECTIVE

4-2

4 .10
4 .11

4.12
4 .13

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

4-3
4-4
4-5
4-5
4-7
4-8
4-11
4-12
4-13
4-14
4-15
4-16
'4-17
4-18

iii

CHAPTER

APPENDIX

4.14

PHASE 2 DIRECTIVE (*DELAY)

4-18

ADDITIONAL SYSTEM GENERATION INFORMATION

5-1

5.1
5.2
5.2.1
5.2.2
5.2.3
5.2.4
5.2.5
5.2.6
5.2.7
5.2.8
5.3
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.5

EDITING SYSTEM GENERATION FILES
PHASE l OF SYSTEM GENERATION
Target Specification
CPU Specification
Memory Allocation
Device Specifications
System Default Specifications
Required Task Installations
Specification of SYSBLD Command Files
Pool Requirements of SGNl
PHASE 2 OF SYSTEM GENERATION
RSX-llD BOOTSTRAPPING
System Generation Phase 1 (SGNl)
System Generation Phase 2 (SGN2)
Saving a Generated System
Subsequent Rebooting of a Saved Image
MEMORY ALLOCATION AND USAGE

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

TAILORING THE SYSTEM

6-1

6.1
6.2

EXECUTIVE CHANGES
UTILITY PROGRAMS

6-1
6-1

EXAMPLES OF SYSTEM GENERATION FILES

A-1

A.l

TERMINAL AND INTERFACE CONFIGURATION FILE,
[3ll,114]CONFIG.MAC
SYSTEM GENERATION PHASE 1,
[ll,17]RK05L48K.CMD
SYSTEM GENERATION PHASE 2,
[ll,17]SYSBLD.CMD

A.2
A. 3

APPENDIX

DEVICE CHARACTERISTICS WORDS

ERROR MESSAGES

A-1
A-3
A-4
B-1

Messages-I

INDEX

Index-1

FIGURES
Page
FIGURE

5-1

SGNl Pool Usage

5-6

TABLES
Page
TABLE

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

4-1

Contents of System Disk
2-5
Contents of Auxiliary Media
2-6
Device Addresses for the MR11-8DB Bootstrap
2-8
Device Addresses for the BM792-YB Bootstrap
2-9
Device Addresses for BM873-YA Bootstrap
2-10
Device Addresses for BM873-YB Bootstrap
2-11
Device Codes for M9301-YC Bootstrap -- Switches
3 through 6
2-12
Terminal Handler Group 1 Assembly Parameters
2-17
Terminal Handler Group 2 Assembly Parameters
2-18
Parameters Dependent on B$$AW in the Handler
as Distributed
2-2f1
Device Information
4-10

PREFACE

0.1

MANUAL OBJECTIVES AND READER ASSUMPTIONS

This manual describes the procedures to be followed by the system
manager to perform an RSX-llD system generation. Understanding of the
introductory material in the RSX-llD User's Guide and a general
knowledge of RSX-llD is a prerequisite for the use of this document.

0.2

STRUCTURE OF THE DOCUMENT

Chapters 1, 2, and 3 introduce system generation. Chapter 2 describes
the process of transferring the system from the distribution medium to
the system disk.
Chapter 3 contains the basic steps that must be
followed to perform any type of RSX-llD system generation.
Chapter 4 describes the directives
configuration and allocate memory.

used

define

the

hardware

for

tailoring

Chapter 5 contains further system generation information.
Chapters
6
summarizes
the procedures
individual components within the system.

0.3

available

ASSOCIATED DOCUMENTATION

Associated RSX-llD documents are described and their readerships are
defined
in
the
RSX-llD Documentation Directory, Order Number
DEC-11-0XUGA-D-D.

vii

CHAPTER 1
OVERVIEW OF SYSTEM GENERATION

System generation is the process of building a system that is tailored
to both a particular hardware configuration and the requirements of
the application programs that execute in the system.
An RSX-llD
system is distributed to the user on one of the following media:
• Magnetic tape (7-track or 9-track),
• RK05, RK06 cartridge disk.
A magnetic tape distribution is used to form a bootable disk system.
A disk distribution comes as a bootable disk system.
Among the system programs provided by RSX-llD is a system generation
program that executes in two phases to create an expanded or modified
version of the system.
This program is
designed
to
accept
user-provided definitions of the system to be created.
System generation is performed in two phases. The first phase can
execute in a normal production environment without disturbing system
operation.
The second phase must be performed on the target hardware
configuration.
System generation normally is
reasons:

performed

for

one

the

following

Creating a system for task development,
Chapter 2, "Getting on the Air,"

Revising a
system
configuration,

Revising a system to tailor it to its applications in order
to improve performance.

reflect

The information needed for reasons 2 and 3,
Chapters 3, 4 and 5.

1-1

above,

as described in

altered

physical

described

OVERVIEW OF SYSTEM GENERATION
1.1

CONCEPTS AND TERMINOLOGY

RSX-llD is a partitioned multiprogramming system. Partitions are
named, contiguous blocks of memory,
the number of which is fixed
during system generation. All tasks in all partitions can execute in
parallel.
Partitions
can
be
either
user-controlled
or
system-controlled.
A user-controlled partition can accommodate only one task at a time.
A system-controlled partition can accommodate as many tasks as can fit
in the defined physical space.
All tasks in a system-controlled
partition can run in parallel.
System-controlled partitions can
schedule tasks on a priority basis or on a time-slice basis.
An active task is one in main memory that is competing for system
resources.
In a priority-oriented partition, a
task
can
be
checkpointed to make room for a higher priority task to execute in
that partition if the first task is designated as checkpointable.
Likewise,
in a time-scheduled partition, a checkpointable task can be
checkpointed if its time-slice expires.
Before a task can execute, it must be installed. More than one task
can be installed to run in a partition. The main purpose of the
installation procedure is to record disk retrieval pointers in the
Executive's main memory so that the task can be made ready to execute
with minimum delay when a request is issued for it. The task can be
either explicitly installed using the INS command to MCR or implicitly
installed as a result of a RUN command issued by a nonprivileged user.
Tasks installed as a result of RUN are removed automatically when the
task exits. Tasks explicitly installed can be removed using the REM
command.
The system task directory
(STD)
establishes the maximum number of
tasks that can be installed at one time.
Normally the number of
installed tasks is greater than the number of executing tasks. The
number of simultaneously installed tasks is limited by the number of
system task directory entries specified during system generation. The
number of executing tasks is limited by the number of user-controlled
partitions
plus
the
number
of
tasks
that
can
fit into
system-controlled partitions. The number of STD entries for tasks
should be greater than the number of available partitions so that a
maximum number of tasks can execute simultaneously.
Installed tasks
can be removed when no longer needed to free additional STD entries.
In RSX-llD, some of the dynamic memory requirements are satisfied from
a pool of nodes. Nodes are variable-size memory blocks that are a
multiple of 8 words. The size of the node pool is established during
system generation.

1-2

CHAPTER 2
GETTING ON THE AIR

This chapter describes the organization of the media on which RSX-llD
is distributed and the procedures to be followed in preparing these
media for the initial system generation.
Section 2.3 contains the
instructions for use of the various bootstraps available on the
PDP-11. Section 2.4 describes how to use the basic system as
distributed to generate the Terminal Handler task for the desired
configuration. This must be done before the main system generation
described in Chapter 3.

2.1

THE DISTRIBUTION SYSTEM

RSX-llD systems are distributed on three basic media:
(7- or 9-track), RK05 cartridges, and RK06 cartridges.

2.1.1

magnetic tape

Magnetic Tape Distribution

The system distribution tape contains a number of bootable system
images.
These are run in turn to create a single-terminal RSX-llD
system from the files also contained in the system distribution tape.

2.1.1.1
1.

Procedures for Using the System Distribution Tape
Using
the procedures for the particular ROM bootstrap
described in Section 2.3, boot the system tape into memory.
The system prints the following on the console.
RSX-llD V06.2 SYSTEM DISTRIBUTION TAPE
SYSTEM DISK?

Respond with the device name to indicate which device is the
system disk. For example:
RK05 for RK05 system disk
RP06 for RP06 system disk

Once the name of the system device has been typed, the system
prints the following message or its equivalent:
LOAD DISK ON xy0 WRITE ENABLED
TYPE 'CR' WHEN READY
where xy is the device type.

For example, xy is

DK for RK05 system disk
DB for RP04, RP05, or RP06 system disk
2-1

GETTING ON THE AIR
DM for RK06 system disk
DP for RP02 or RP03 system disk
4.

When the disk is ready, type carriage return, and if the disk
can be formatted, the system prints the following:
FORMAT DISK?
NOTE
Formatting
a
volume
destroys
all
information on the disk as does running
BADBLOCKS
(step 6)
and
initializing
(step 8) •

Respond with one of the following:
YES
NO

to format the system disk
if disk formatting is not required.

The system then prints the following message:
RUN 'BADBLOCKS'?

Respond with one of the following:
YES
NO

to run the BAD BLOCKS utility
Guide) on the system disk
if this operation is not required.

(see RSX-llD User's

The system then prints the following message:
INITIALIZE SYSTEM DISK?

Respond with one of the following:
YES
NO

to initialize the disk
if the disk does not require initialization.
NOTE

This question will not be asked
if
either or both of the previous two
replies were YES.
Initialization is
mandatory in these circumstances.
If initialization is not required then the system continues
from step 12 onwards.
10.

if the disk requires initialization, the system types:
STANDARD VOLUME INITIALIZATION?

11.

Respond with one of the following:
YES
NO

if standard volume initialization required
to make the initialization task prompt
initialization parameters.

for

the

See the RSX-llD User's Guide for a description of the MCR
Standard volume initialization
command INITIALIZE VOLUME.
2-2

GETTING ON THE" AIR
gives the volume a label of

RSXSYS

With standard volume initialization, if the reply to the
BADBLOCKS question was YES, the volume will be initialized
with the /BAD=[AUTO] option, otherwise without.
12.

The system is then created.
The system prints the
creation on the console.

command

file

used

during

system

During this process, all of the files required on an RSX-llD
system disk are loaded from the tape and a complete basic
system is generated on the target disk. If all the replies
to the three questions in 4,_6, 8 above were YES, the process
will take approximately 15 minutes for an RK05 system or
approximately 30 minutes for an RP04 system. When finished,
the system prints the following.
*** END OF SYSTEM GENERATION PHASE 2 ***
13.

Enter the time and date, dismount the system
the new system as follows:
Press CTRL/C to obtain MCR
MCR>TIM dd-mmrn-yy hh:mm:ss
MCR>DMO SY:
MCR>FIX FllACP
MCR>SAV

14.

disk

and

save

NOTE
In' this manual, all command
lines are terminated by pressing the
RETURN key unless
otherwise specified.

The system then responds with a sign-on message giving the
actual memory size and the version of the RSX-llD Executive
that is in use.
All of the system memory is available.
If the hardware has
more than 48K, a message in the following format is printed
on the terminal.
SAV -- PARTITION GEN EXPANDED BY nnnn*32 (DEC) WORD BLOCKS
In addition, if the central processor is a PDP-11/70, it has
been
enabled as such, thereby overriding any previous
specification.

15.

2.1.1.2

The new system disk is now usable as a base for tailoring the
desired RSX-llD system. Every time this disk is booted, the
message in step 14 above is printed. If, however, the system
is saved again, the size of the expanded partition will be
recorded and the amount of expansion will not be printed.

Procedures for Using Auxiliary Tapes

The directory organization of RSX-llD is described in Section 2.2.
This section describes the procedure for obtaining files from the
object tapes, which are the other two tapes in the magnetic tape kit.
The files are written on tape in DOS format. The file interchange
utility (FLX) is used to obtain files from the tape. The FLX commands
are described in the RSX-llD Utility Programs Procedures Manual.

2-3

GETTING ON THE AIR
2.1.2

RK05 Cartridge Distribution

The first of the three RK05 cartridges is a single-user 48K RSX-llD
system. The other two cartridges contain object files and command
files for rebuildi~g system components.
All three are Files-11
volumes with a directory organization that is described in Section
2.2.
It is advised that all three disks be copied for backup purposes
before any other use is made of them. Preserve (PRE) is the utility
to be used for this operation. Refer to the Preserve Manual.
To use the system disk, it need only be bootstrapped from device 0.
See Section 2.3 for the appropriate bootstrap operation.
When the
disk is booted, the system displays the sign-on message for this
version of the RSX-llD Executive. All of the system memory is made
available.
If the hardware has more than 48K, a message in the
following format is printed on the terminal.
SAV -- PARTITION GEN EXPANDED BY nnnn*32 (DEC) WORD BLOCKS
In addition, if the central processor is a PDP-11/70, it has
enabled as such, thereby overriding any previous specification.

2.1.3

been

RK06 Cartridge Distribution

The RK06 distribution cartridge contains a single-user 48K RSX-llD
system, object files and command files for
rebuilding
system
components.
The directory organization is as described in Section
2.2.
It is advised that the disk be copied for backup purposes before any
other use is made of it. Disk Save and Compress (DSC) is the utility
to be used for this operation. Refer to the Disk Save and Compress
Manual.
To use the system disk, it need only be bootstrapped from
device 0. When the disk is booted, the system displays the sign-on
message for this version of the Executive. All of the system memory
is made available. If the hardware has more than 48K, a message in
the following format is printed on the terminal.
SAV -- PARTITION GEN EXPANDED BY nnnn*32(DEC) WORD BLOCKS
In addition, if the central processor is a PDP-11/70, it has been
enabled as such, thereby overriding any previous specification.

2.2

ORGANIZATION OF DIRECTORIES ON THE DISTRIBUTION MEDIA

Whether the system distribution is on magnetic tape
cartridges, the organization of directories is the same:

RK05

[311,n]

contain source files, and assembly command files,

[211,n]

contain listing files,

[111,n]

contain task map listings,

[11,n],

(excluding
[11,1]) contain all object files, build
(overlay description) command files, and command files
for the librarian, PIP and system generation.

2-4

GETTING ON THE AIR
2.2.l

System Disk Directories

An RSX-110 system disk has the directories listed in Table 2-1.
Table 2-1
Contents of System Disk
UFO

CONTENTS

[1,1]

Executive symbol table
System macro library
System resident and relocatable object library

[1,2]

Error message files

[1,3]

Temporary files used and created by the
Files-11 verify utility -- initially empty

[1,4]

Output spooler queue and spooled
files -- initially empty

[1,5]

Task accounting data files -- initially empty

[1,6]

Error logging data files -- initially empty

[11,1]

All system task images

[11,17]

System generation command files
Bootstraps
System,generation phase 2 task
Executive task image

2-5

GETTING ON THE AIR
2.2.2

Auxiliary Media Directory Contents

The auxiliary media contain the directories listed in Table 2-2.
Table 2-2
Contents of Auxiliary Media
CONTENTS

UFD
[11,2]

All modules that compose SYSLIB, SYSRES, and
the Files-11 system

[11,4]

FLX object modules

[11,5]

Object modules of PIP, DMP, VFY, ZAP and PAT

[11,6]

SLP object modules

[11,7]

Librarian object modules

[11,10]

MACR0-11
Assembler
(cross-reference version)

[11,11]

Task builder object modules

[11,12]

Spooler object modules

[11,13]

Object modules for all the MCR functions except
BOO and SAV

[11,14]

Handler object modules

[11,15]

Executive and SCOM

[11,16]

File control primitives
and
file
utilities such as UFD and INITVOL.

[11,17]

System generation
Bootstraps,
BOO and SAV MCR functions
Virtual install INV build command files

[11,20]

EDI object modules

[11,21] and
[11,22]

System test tasks

[11,23]

Batch

[11,25]

Unsupported software

[ .11, 26]

Accounting system

[11,27]

Error logging and diagnostics modules

[11,30]

Online Preserve, Disk Save and Compress (DSC)

[11,32]

Cross Reference

[11,41]

FORTRAN IV compiler

[11,42]

FORTRAN IV OTS

2-6

object

modules

system

GETTING ON THE AIR

Table 2-2 (Cont.)
Contents of Auxiliary Media
UFD

CONTENTS

[11,114]

Terminal Handler

[311,13]

Sources for DEMO

[311,25]

Sources for unsupported modules

[311,114]

Terminal handler sources

2-7

GETTING ON THE AIR
2.3

HARDWARE BOOTSTRAPS

Five models of hardware bootstraps are available on systems used for
RSX-llD: MRll-DB and BM792-YB and the Massbus bootstraps BM873-YA,
BM873-YB, and M9301-YC. The type of bootstrap for a particular PDP-11
can be determined by consulting the equipment order.
Whenever a request to bootstrap the
following text, refer to one of
perform the appropriate bootstrap.

2.3.1

system is encountered in the
the five sections that follow to

MRll-DB Bootstrap

Perform the following steps to use an MRll-DB Bootstrap.
1.

On the console switches, set HALT.

Set ENABLE.

Enter the address of the device from which the bootstrap is
to occur into the console switches. Table 2-3 provides the
device addresses.

Press LOAD ADDR.

Press START.
Table 2-3
Device Addresses for the MRll-DB Bootstrap
DEVICE

ADDRESS

RP03 Disk

173154

RK Disk

173110

RF Disk

173100

TU10 Magnetic Tape

173136 (7 or 9 Channel)

DECtape

173120

2-8

GETTING ON THE AIR
2.3.2

BM792-YB Bootstrap

Perform the following steps to use a BM792-YB Bootstrap.
1.

On the console switches, set HALT.

Set ENABLE

Enter 173100 into the display switches.

Press LOAD ADDR.

Enter the address of the device from which the bootstrap is
to occur into the console switches. Table 2-4 provides the
device addresses.

Press START.
Table 2-4
Device Addresses for the BM792-YB Bootstrap
DEVICE

ADDRESS

RP03 Disk

176716

RK Disk

177406

RF Disk

177462

DECtape

177344
NOTE

Magnetic tape cannot be booted with the
BM792-YB Bootstrap.

2-9

GETTING ON THE AIR
2.3.3

BM873-YA Bootstrap

Perform the following steps to use the BM873-YA Bootstrap.
I.

On the console switches, set HALT.

Set ENABLE.

Enter the address of the device from which the bootstrap is
to occur into the console switches. Table 2-5 provides the
device addresses.

Press LOAD ADDR.
NOTE
If a unit other than 0 contains the
device to be booted, set the switch
register to the unit number of the
device to be booted before pressing
START.

Press START.
Table 2-5
Device Addresses for BM873-YA Bootstrap
DEVICE

ADDRESS

RFll

(RFn disk)

773000

RPll

(RP03 disk)

773100

RKll

(RK05 disk)

-- Unit 0

773010

Unit specified in switch register

773020

TCll

(DECtape)

773030

TMll

(TU10 magnetic tape)

773050

2-10

GETTING ON THE AIR
2.3.4

BM873-YB Bootstrap

Perform the following steps to use the BM873-YB bootstrap.
1.

On the console switches, set HALT.

Set ENABLE.

Enter the address of the device from which the bootstrap is
to occur into the console switches. Table 2-6 provides the
device addresses.

Press LOAD ADDR.
NOTE
If a unit other than 0 contains the
device to be booted, set the switch
register to the unit number of the
device to be booted before pressing
START.

Press START.
Table 2-6
Device Addresses for BM873-YB Bootstrap
DEVICE

RHll

{RS03,4 disk)

ADDRESS

-- unit 0

773000

Unit specified in switch register

773002

-- unit 0

773030

Unit specified in switch register

773032

-- unit 0

773320

Unit specified in switch register

773322

-- unit 0

773350

Unit specified in switch register

773352

RFll

{RSll disk)

773136

TCll

{DECtape)

773070

TMll

{TU10 magnetic tape)

773110

RHll

{TU16/TM02 magnetic tape)

773150

RKll

RHll

RPll

{RK05 disk)

(RP04 disk)

(RP03 disk)

2-11

GETTING ON THE AIR
2.3.5

M9301-YC Bootstrap (PDP-11/70 Only)

The M9301-YC bootstrap operates only on
following steps to use this bootstrap.

the

PDP-11/70.

Perform

the

Press the HALT switch and set back to the ENABLE position.

Set the start address of 177765000 in the console switches.

Press LOAD ADDR.

Set the device unit number in switches 0 through 2.

Set the device code in switches 3 through 6. Refer to Table
2-7 for device codes.

Ensure that switches 7 through 21 are off (down).

Press START.
NOTE
Before the M9301-YC bootstrap actually
boots the system, it performs CPU tests,
instruction and addressing tests, and
memory and -cache tests.
If a hardware
failure is detected,
the
diagnostic
program halts.
The lights contain the
ROM address of the halt.
If
this
occurs, call the DIGITAL field service
engineer.
It may, however, be possible to continue
with the bootstrap operation if the
lights contain the address 17773764,
which indicates a cache failure.
To
continue in this case, press CONT. This
is the ONLY case in which it is possible
to continue bootstrapping after
the
diagnostic detects an error.

Table 2-7
Device codes for M9301-YC Bootstrap -- Switches 3 through 6
DEVICE

CODE

TM11/TU10

Magnetic Tape

TC11/TU56

DECtape

RK11/RK05

DECpack Disk Cartridge

RP11/RP03

Disk Pack

RH70/TU16

Magnetic Tape

RH70/RP04

Disk Pack

RH70/RS04/RS03 Fixed Head Disk

NOTE
The M93~1-YC bootstrap is capable of relocating its input
to various banks of memory. However, it is not possible
to do this with RSX-llD. An RSX-llD system must be located
as defined during system generation.
2-12

GETTING ON THE AIR
2.4

TERMINAL HANDLER GENERATION

2.4.1

Introduction

Before phase 1 of system generation is performed it is necessary to
build the terminal handler to reflect the configuration of terminals
in the system, unless the single terminal handler
(TT01)
is to be
used.
There
are two files which must be edited.
Of these
[311,114]PARAMS.MAC, describes in general terms
the
facilities
required,
the number of each type of interface in the system etc.
[311,114]CONFIG.MAC describes each interface in detail and how every
terminal is connected. Once these files have been set up the handler
must be assembled and built as described in Section 2.4.4.

2.4.2

Editing PARAMS.MAC

This file is divided into three parts:

2.4.3

Assembly parameters which must be set up
(see Table 2-8).

for

every

system

Assembly parameters which will not normally need to be
changed. The values in the second column of Table 2-9 are
those in the software distributed by DIGITAL. They may need
to be changed to suit the particular needs of
some
installations.

Assembly parameters whose definitions must not be changed.

Editing CONFIG.MAC

This file is in two parts, the interface descriptions and the terminal
descriptions.
Each interface is described by a line of the forro:
INTF

number,type,epa,vec[,extra]

number

is the interface number. The first interface must
be number 0,
and the remainder must follow in
consecutive ascending order.
Interface 0 must be
the console DLll.

type

is the interface type, selected from DC, DH, DJ,
DL, DM, DZ.

epa

is the external page address of the first register
of the interface; e.g., 17756~ for the console.

vec

is the address of the first interrupt vector

extra

may be absent.
It is used to contain interface
dependent information, as follows:
DC

indicates the type of DCll
0
DCllAX
1
DCllAA
2
DCllAB
3
DCllAC
4
DCllAD
5
DCllAE
6
DCllAG
7
DCllAH

2-13

GETTING ON THE AIR
DH

if the DHll has a corresponding DMll for
dialup line control,
this must be the
number of the DMll interface. The DMll
must precede the DHll in this file.

If
'extra' is present and non-zero, the
interface is a DLllE.

Each terminal is described by a line of the form:
TERM

number,intnum,subline,type,speed,dialup,char

number

is the terminal number. The first terminal must
be
number 0, and the remainder must be in
consecutive ascending order.

intnum

is the number of the interface
{in the previous
section) to which this terminal is connected.

subline

for terminals connected to multiplexor interfaces
this is the subline number on the interface.
For
single-line interfaces it may be left blank.

type

is the type of the terminal, selected from:
AS33
(ASR33) , KS33
{KSR33) , AS35 {ASR35) , L30S
(LA30S), L30P {LA30P), LA36, VT05, VT50, VT52,
VT55, VT61.
If the terminal is not one of these
DEC-supported models, the type should be given as
'USR0' and the
'char' parameter {below) used to
describe its characteristics.

speed

If the default speed for the terminal is to be
used
(see Device Handlers Reference Manual, Table
2-3), this may be left blank.
Otherwise, it
should be a number which is the baud rate of
terminal or, for a split-speed line, two numbers
separated
by a comma and enclosed in angle
brackets, with the keyboard {lower)
speed first,
e.g. <150,2400>.

dial up

if the terminal is connected to a dialup line this
parameter must be the string 'DIALUP' otherwise it
should be blank.

char

If any of the terminal characteristics are to be
non-standard they may be specified here.
The
parameter is a list of pairs of characteristic
names and values; e.g., <<chl,0>,<ch2,3>, <ch3,l>>.
The names are those specified in the Device
Handlers Reference Manual, Chapter 2, Table 2-2.
The value may be any acceptable value as specified
in that table. The number of pairs allowed in
this list is limited only by the length of the
line.
If still more are needed an alternative
form of the TERM macro may be used:
TERMBG
SETFLD

number,intnum,subline,type,speed,dialup
chl,vall

SETFLD
TERMED

chn,valn

2-14

GETTING ON THE AIR
A separate
line
characteristic.

must

used

for

each

An example CONFIG file is given as Appendix A.l. This example applies
to a system with:
1.

LA36 as a console.

DHll interface with five VT50s and three

DHll interface with associated DMll for dialup lines, with
six dialup lines set up as ASR33s and two local VT0Ss, one
running at a non-standard low speed.

A DLllE dialup line set up as a LA36.

A DJll with two low
high-speed terminals,
sublines.

A DLll line with a special, non-standard terminal running at
150/1200 baud, split-speed.

2.4.4

LA3~Ss.

speed hardcopy terminals and two
connected to different four-group

Building the Handler

The following commands should be used to build the handler:
MCR>SET /UIC=[l,l]
MCR>MAC @[311,114]TTMAC.CMD
MCR>TKB @[ll,114]TTTKB.CMD
NOTE
The TKB operation will result in four
'undefined symbols' message$,
for the
segments TT, !NIT, IDLE and LINES. The
exact number of undefined symbols in
each message will depend on the assembly
parameter files.
If the assembly parameter files have been set up incorrectly it is
possible that some assembly errors will be reported. It is possible
to check for these first, to minimise wasted time, using the command
file [311,114]TTMACCHK.CMD. This will assemble only the modules which
can produce errors. If the CONFIG file is changed but not PARAMS, for
example because some interfaces have been relocated in the external
page,
CONFIG
may
be
assembled
using
the
command
file
[311,114]CONFIGMAC.CMD.
The normal version of the terminal handler is overlaid, one overlay
segment containing the code to deal with I/O requests and the other
containing the initialization and powerfail code. This means that the
handler has to access the disk on which it is resident when the system
is booted or during powerfail recovery. For some applications this
may not be practical in which case it is possible to build a
non-overlaid version. This is used, for example, in the distribution
kit where there is no system disk to read overlays from.
The
non-overlaid
handler may be built using the TKB command file
[ll,114]TTUNOVR.CMD. In this case the symbol 0$$VR in PARAMS.MAC must
be 0. It is recommended that !$$ERM also be 0 so that space is not
used to store the initialization error messages.
2-15

GETTING ON THE AIR

Table 2-8
Terminal Handler Group 1 Assembly Parameters (2.4.2)
See section 2.4.2
Name

B if

Meaning

Binary
U$$NTS

Maximum number of terminals to be serviced.

B$$22

=l if 22-bit support reouired; must be set on
PDP-11/70 configurations with more than 124K
words of memory.

B$$AW

'Bells and Whistles'. This should =l unless
space is at a premium.
If it =0 the features
in Table 2-10 will all be omitted.

B$$LCK

=l for Block-Mode terminal support.

D$$Cll
D$$CDU

Number of DCll single-line
configuration.
B

D$$Hll
D$$IAL

interfaces

the

=l if any DCll interfaces
modems for dial-up support.

are connected to

Number of
interfaces.

NPR

DHll

16-line

Dial up
Support.
=l
required in the system.
ignore dialup lines.

if
=0

multiplexor

any dialup lines
causes system to

D$$Jll

Number
of DJll
configuration.

16-line

interfaces

the

D$$Lll

Number of DLll single-line
configuration.

interfaces

the

D$$LDU

=l if any DLll(DLllE) interfaces are connected
to modems for dialup support.

D$$Mll

Number of
DMllBB
16-line
modem
control
interfaces
in
the
configuration.
These
interfaces provide dialup support for lines
interfaced throuah DHlls.

D$$Zll

Number
of
DZll
configuration.

8-line

interfaces

the

connected

D$$ZDU

=l if any DZll
interfaces
modems for dialup support.

E$$EQ

=l if handler is to recognize and parse escape
sequences.
(see IAS/RSX-llD Device Handlers
Reference Manual, Section 2.6).

H$$RTZ
T$$APE

are

Clock frequency
(50., 60. or 100.). The • is
necessary and indicates a decimal number.
B

=l if low speed paper tape is required.
=0 if no low paper tape is required.

2-16

GETTING ON THE AIR

Table 2-9
Terminal Handler Group 2 Assembly Parameters
See Section 2.4.2.
Name

Normal
Setting

Meaning

B$$SCN

=B$$AW

=l to allow typeahead CTRL/R and Backspace Over
Tab.

B$$SP

=B$$AW

=l for support of terminals with hardware
backspace.
If it = 0, backspace will be output
but the handler will lose track of terminal's
horizontal position.

D$$HSF

=B$$AW&D$$Hll&B$$LCK
=l If support of DHll Silo Fill is required.
This should be used if block mode terminals are
present to reduce the number of interrupts.

D$$KIL

=0 for notification of termination of
by IO.KIL.

D$$RAT

Default Read-ahead Processing Type, viz.

requests

Type-ahead is illegal and will be ignored.

1
'Deferred Processing' Mode. Characters
typed ahead will only be processed when they
are read.
Thus RUBOUT, CTRL/U etc. will
not be seen until a read is performed.

'Immediate Processing, Deferred Echo' Mode.
Characters are processed as they are typed
but not echoed till they are read. Echo is
therefore a clean copy'.

'Immediate Echo' Mode. Characters will be
echoed as they are typed,
and not echoed
when they are read. See also the IAS/RSX
Device Handlers Reference Manual, Section
2.2.2
NOTE
Read-ahead type can be changed in the
configuration file for particular lines.

E$$ALT

=l if ALTMODE is to be echoed as '$' followed
by carriage return, =0 if ALTMODE is not to be
echoed.

H$$0LD

=B$$AW

=l for support of VTSx hold-screen mode. This
support is provided automatically if E$$EQ=l.

I$$ERM

=B$$AW

=l to generate initialization
(see Section 2.4.5).

L$$30S

=l to support LA30S Serial DECwriters.

2-17

Error

Messages

GETTING ON THE AIR

Name

Table 2-9 (Cont.)
Terminal Handler Group 2 Assembly Parameters
Meaning
Normal
Setting

M$$ANS

Time, in seconds, to wait after sensing first
ring
before
answering
the
phone.
The
parameters M$$ANS through M$$WCR are described
more fully in the IAS/RSX-llD Device Handlers
Reference Manual, Table 2-5.

M$$CAR

Time in seconds,
to wait after answering the
telephone before applying carrier.

M$$RNG

Time, in seconds, to wait for a confirming ring
signal.
If a ring signal is not detected in
this interval the caller is assumed to have
hung up.
This time rnust be greater than the
period of the ring cycle (3 seconds in USA).

M$$UK

=l if UK-type Short Modem Timeouts required.
Some countries, including the UK, require a
line to be dropped within a very short time
after detecting carrier loss, because their
modems and some acoustic couplers do
not
distinguish
carrier from dial tone.
This
facility is not available for modems interfaced
via a DZll.

M$$WIC

=20.

Time,
in seconds, to wait for caller to apply
carrier after the system has applied carrier.
This allows the caller time to place the phone
in its bed on an acoustic coupler, without
tying up the line for too long when a wrong
number is dialled and then cancelled.

M$$WCR

Time to wait after carrier loss before assuming
caller has hung up.
If M$$UK (above) =0, this
time is M$$WCR seconds.
It should allow for
the phone being disturbed on the bed of an
acoustic coupler or for dropouts on the line.
If M$$UK =l, this time is M$$WCR clock ticks.
It should be such that the line is guaranteed
to be dropped in the required time.

M$$PRI

Priority of Interrupt Service Routines.
=5
unless there are no multiplexor interfaces in
the system, in which case it can =4. It may be
useful for configurations with no block-mode
terminals to use a BR4 Jumper in DHll/DJll/DZll
interfaces to improve the service to disks etc,
when M$$PRI should be changed accordingly.

N$$L

=B$$SAW

'Newline'
terminal
support should =l for
support of terminals which treat code
12
(octal)
as
'Newline' rather than 'Line Feed'
and have a 'newline' key instead of
'carriage
return'.

N$$0DS

(see

Total number of 16-word
internal node pool.

text)

nodes in handler's

Nodes are picked from the pool for all internal
buffering.
This includes type-ahead, reads,

2-18

GETTING ON THE AIR

Table 2-9 (Cont.)
Terminal Handler Group 2 Assembly Parameters
Name

Normal
Setting

Meaning
writes and the saving of default values
terminal characteristics are reset.

when

The distributed handler calculates the value
from U$$NTS (Table 2-8) thus:
For U$$NTS from 0 to 5 allow 5 nodes per
terminal. For each terminal from 6 to 32 allow
3 more nodes.
For each terminal beyond 32
allow 2 more nodes.
0$$VR

=l to build overlaid version of handler.
handler should normally be
overlaid
section 2.4.4).

S$$CHR

=B$$AW

=l to enable
'set characteristics' function
(see IAS/RSX-llD Device Handlers
Reference
Manual). The MCR TER command relies on this
function. The function uses over l/2K words of
memory and may be omitted for small systems.

G$$CHR

=S$$CHR

=l to enable 'get characteristics' subfunctions
of 'set characteristics' (SF.GSC, SF.GMC, see
Device
Handlers Reference Manual, Sections
2.4.3.5, 2.4.3.6). Allows applications programs
to determine characteristics of terminal on
which they are running.

D$$CHR

=S$$CHR

=l to enable dump characteristics subfunction
(SF.GAC, SF.SAC in IAS/RSX-llD Device Handlers
Reference Manual, Sections 2.4.3.7, 2.4.3.8).
Allows application programs to change terminal
characteristics and restore them on exit.

R$$BTB

=B$$AW&B$$SCN

The
(see

=l to enable scope tab rubout. Rubout over tab
then moves cursor to where it was before tab
was typed.
=0 saves about 60 words but rubout over
then echoes as backspace-space-backspace.

tab

S$$FF

=B$$AW

=l for software simulation of form feed and
vertical
tab.
On
terminals
with
characteristics set correctly this will replace
a token output of a fixed number of line feeds.
Used for example when a slow high-quality
printer is connected via a terminal interface.

V$$FIL

=l sets VT05-type vertical fill (see Device
Handlers Reference Manual) • =l is required if
any VT05 is configured in the system.

2-19

GETTING ON THE AIR
Table 2-1~
Parameters Dependent on B$$AW in the Handler as Distributed
Parameter

Meaning

Parameter

B$$SCN

Meaning

H$$0LD

B$$SP

see

!$$ERM

see

D$$CHR

Table

N$$L

Table

D$$HSF

2-9

R$$BTB

2-9

G$$CHR

S$$CHR
S$$FF

2-20

GETTING ON THE AIR
2.4.5

Terminal Handler Error Messages

The terminal handler performs some checking of the consistency and
sense of the parameters used to build it. Some of these errors are
detected at assembly time,
as described above.
Others cannot be
detected until the handler becomes active, at the beginning of System
Generation Phase 2. These are printed when the system is first
bootstrapped, and have the form:
TT .•.• *FATAL* error message
If the error is related to a particular terminal or interface, its
number is printed after the message. After this message, SGN2 will
print:
UNABLE TO FIND ATL FOR TERMINAL HANDLER(TT ..•. )
The system is not usable, and the terminal handler must be rebuilt
correctly and System Generation repeated.
The handler abandons initialization as soon as an error is found.
For
this reason if more than one error condition is present, only the
first is reported.
Exceptionally, the messaqe 'FAILED TO ALLOCATE UNIBUS MAP REGISTER'
may be output when a system is booted after System Generation, if it
is moved to a system with more than 124K of memory after running on a
smaller system.
Error message texts:
DHll MODEM IN'I'ERFACE IS NOT A DMll
The interface
not a DMll.

specified

as the 'extra' parameter for a DHll is

DHll MUST FOLLOW CORRESPONDING DMll
The interface specified as the 'extra' parameter for a DHll has a
number greater than that of the DHll. It is essential that the
DMll precede the DHll so that initialization can be performed in
the right order.
FAILED TO ALLOCATE UNIBUS-MAP REGISTER
On a PDPll-70 with more than 124K of memory, the handler needs to
allocate a Unibus Map Register (UMR) to serbice DHll lines.
If
all of the 31 available registers are in use by other handlers,
this messate will occur. Normally, this will only occur if the
system is moved forma small (<124K) machine to a larger one, if a
large number of Unibus NPR devices (e.g. RK, TU10, RP03)
are on
the system.
FAILED TO CONNECT TO INTERRUPT VECTOR
Two conditions may cause this error:
1.

There is an error in the CONFIG file such that more than one
interface is specified as having the same interrupt vector
address.

2-21

GETTING ON THE AIR
2.

Another handler is connected to one of the interrupt vectors
specified in the CONFIG file. Htis indicates an error either
in CONFIG or in the parameters supplied to Sysgen 1.

The message indicates an error either in CONFIG
parameters supplied to phase 1 of system generation.

or in the

FAILED TO DECLARE HANDLER
Another version of the handler, or another terminal
already active.

handler,

FAILED TO DECLARE POWER FAIL AST
This error should not occur.
It may do if the terminal handler
build file is changed to reduce the node pool limit of the
handler.
ILLEGAL DCll SPEED TYPE
The speed type of a DCll interface, specified as the 'extra'
parameter, is not in the range 0-7.
LINE SPEED NOT VALID FOR THIS INTERFACE
The speed specified for a terminal, either implicitly by the
terminal type or explicitly as the 'speed' paramerer to the TERM
macro, is not available on the specified interface.
This will
occur, for example, if a VT50 is connected to a DCll without an
explicit speed specification suitable for the interface.
MORE THAN ONE DHll REFERS TO ONE DMll
More than one DHll interface has specified
specification suitable for the interface.

the

same

speed

MORE THAN ONE DHll REFERS TO ONE DMll
More than one DHll interface has specified the same DMll modem
control interface as the 'extra' parameter.
MORE THAN ONE TERMINAL ON SINGLE-LINE INTERFACE
More than
interface.

one

terminal

has

specified

the

same

single-line

NO MODEM INTERFACE FOR DIALUP LINE
A terminal has the 'dialup' parameter set but the interface to
which it is connected has no dialup capability.
SLAVE INTERFACE USED AS PRIMARY INTERFACE
The interface specified for a terminal in the
DMll.

TERM

macro

TWO TERMINALS ON SAME SUBLINE
More than one terminal has specified the same subline of the same
multiplexor interface.

2-22

CHAPTER 3
SYSTEM GENERATION PROCEDURES

RSX-llD provides a system generation capability that consists of two
tasks (phase 1 and phase 2) and a set of command files. The first
phase can be performed online independently of the target hardware or
software configuration. Its purpose is to create a file on disk that
is an RSX-llD system capable of running on the target hardware
configuration.
Phase 2 of system generation is designed to perform those functions
that require the target configuration. Phase 2 is a task that is
activated in the system created by phase 1.
If the generated system is being written onto the current system disk,
i.e., if a target disk is not being used, system generation must not
be performed online with other system operations.
Both phases accept input from command files. Phase 1 also accepts
input from a terminal. Chapter 5 details the procedures for phase 1
input from a terminal. The distributed system includes several system
generation command files under UFD [11,17]. The command files that can
be used as input to phase 1 all have the following format for the
filename and type.
diskznnK.CMD
disk indicates the disk that is to be the system
RK05, RK06, RP02, RP03, RP04, RP05, RP06.

device,

i.e.,

indicates the
clock (L) •

programmable clock (P) or the line frequency

indicates the size of the save image in units of lK words

Any one of these files can be used as input to phase 1.
Appendix A provides a sample listing of the files.
The phase 2 input file is SYSBLD.CMD unless an alternative is
specified by the SYSBLD directive in phase 1. It is located under UFD
[11,17]. Phase 2 automatically uses this file to create a running
system on the target hardware.
SYSBLD.CMD can be edited prior to
running phase 2 to reflect local requirements. Appendix A contains a
listing of SYSBLD.CMD.

3-1

SYSTEM GENERATION PROCEDURES
NOTE
SYSBLD.CMD contains numerous comments
that provide the user with information
about the functions of that file.
The
user is advised to read these comments.

3.1

PHASE 1 OF SYSTEM GENERATION

Phase 1 of system generation can be run by a privileged user from any
Like system utility programs, it
terminal on the host RSX-llD system.
uses the defaults of the system under which it is runninq and
communicates with the user on the terminal from which the -user
requested it.
The purpose of phase 1 is to create a file on a disk.
Once the file is created, the disk is called the target system disk.
It is preferable that the target system disk be a disk other than the
host system disk {SY0). When a separate disk is used, phase 1 becomes
an online procedure that does not affect the running system.
If the target system disk and the host system disk are the same, phase
1 should not be performed online with any other operation because
several tasks are installed in the target system during phase 1 that
also are installed in the host system.
Since task headers are
modified by the install function, a task installed in one operating
system cannot be used in another even though it was installed there
previously. Device assignments, for example, may be different.
NOTE
Throughout the RSX-llD document set, the
use of lower case letters in command
strings indicates that the user is to
supply the appropriate variables at that
point in the command.
For example, in
the following MCR command, the user is
to specify the device type and unit of
the target disk.
MCR>MOU target disk
could be typed as
MCR>MOU DKl:
The procedures for executing phase 1 of system generation on a running
RSX-llD system follow.
1.

Install system generation phase 1
function as follows.
MCR>INS [11,l]SGNl
MCR>INS [11,l]INV

3-2

and

the

virtual

install

SYSTEM GENERATION PROCEDURES
2.

If the target disk is the current system disk, go to step 5.
If steps 2 through 4 have been done previously, go to step 5.
Otherwise,
initialize and mount the target disk, as follows.
MCR>INI

target disk

Use any
options.

MCR>MOU

target disk

Use
any
options.

Create the required
following commands.

UFOs

MCR>UFD target disk

[ 1, 1]

the

appropr is.te

target

INITVOL

appropriate
disk

MOUNT

using

the

(some system files and
libraries}

MCR>UFD target disk [1,2]

(error message files}

MCR>UFD target disk [1,3]

(for Verify}

MCR>UFD target disk [1,4]/PRO=[RWED,RWED,RWED,RWED]
(to allow spooling)
MCR>UFD target disk [1,5]/PRO=[R,RWED,R,R]
(for accounting}
MCR>UFD target disk [1,6]/PRO=[RWED,RWED,RWED,RWED]
(for error logging)
MCR>UFD target disk [11,1]

(system tasks)

MCR>UFD target disk [11,17]

(system generation files)

MCR>UFD target disk [200,200]
4.

(an optional user UFD)

Transfer all files required for the target system.
Both the
target disk and the current system disk must be write
enabled.
MCR>SET /UIC=[l,l]
MCR>PIP target disk=*.*
MCR>SET /UIC=[l,2]
MCR>PIP target disk=*.*
MCR>SET /UIC=[ll,l]
MCR>PIP target disk=*.*
MCR>SET /UIC=[ll,17]
MCR>PIP target disk=*.TSK,*.CMD,*.STB

3-3

SYSTEM GENERATION PROCEDURES
5.

Prepare the required phase 1 input command file.
files are provided with the distributed system.

Several

Depending on the available pool size of the host system,
it
may be necessary to remove some tasks from the host system.
Section 5.2.7 provides guidelines for calculating node pool
usage during system generation.
A file under
[11,17] called SYSGENREM.CMD can be used
remove tasks.
It is advisable to use this file. However,
others are using the system, care should be taken not
remove tasks they require. Enter the following command
remove installed tasks using SYSGENREM.CMD.

to
if
to
to

MCR>REM @[ll,17]SYSGENREM
7.

Run phase 1 ensuring
pressing ALTMODE.
MCR>RUN SGNl

that

the

command

is terminated by

Depress ALTMODE.

The system responds as follows.
SYSGEN PHASE 1
SPECIFY TARGET DEVICE AND FILENAME
SGN>

At this point, the user has the option of naming the device,
UFO, and filename to be assigned to the file produced by
phase 1. The directive has the following format.
SGN>TARGET=td: [ufd]filename
td

indicates the target disk.
SY is used by default.

If it is omitted,

[ufd]

is the UFD of the system image file.
is omitted [11,17] is used.

filename

is the name to be assigned to the file.
it is omitted, RSX.SAV is used.

If it
If

If the TARGET directive is not specified, the default is
SY: [ll,17]RSX.SAV. This directive may have been included in
the command file to phase 1. In this case, proceed to the
next step.

3-4

SYSTEM GENERATION PROCEDURES
10.

Name the command file to be processed by phase 1 of system
generation
(SGNl) • The command file can be any one of those
provided with the system, e.g., RP03L48K.CMD, or it can be a
user-created file.
The following command to SGNl is used.
SGN>@command file specification
All of the commands read from the command file are printed on
the terminal. Upon successful completion of the processing
of the command file,
the following message appears on the
terminal.
SGN>END OF PHASE 1
Depress CTRL C to obtain MCR.
The host system remains usable in the normal way
fatal errors occurred during execution of phase 1.

11.

even

If any errors occurred during phase 1, correct them (consult
the Messages Appendix) and repeat steps 7 through 10.
NOTE
Fatal errors must be corrected,
diagnostic
messages
imply that
resulting system may be usable.

12.

but
the

Phase 1 of system generation does not produce a target system
that is hardware bootable; i.e., it does not write physical
block 0 of the disk.
Do not log off the host system. Consult step 1 of the phase
2 procedures
(Section 3.2)
to be able to boot the target
system.

3.2

PHASE 2 OF SYSTEM GENERATION

Phase 1 of system generation has created a file on the target system
disk.
This file contains a memory image of a running RSX-llD system.
In this system, two tasks are active. One is the system disk handler,
and the other is phase 2 of system generation. Bootstrapping this
file into memory causes phase 2 to run.
NOTE
For phase 2 to execute successfully, it
must be booted on a machine with as much
or more memory than that
specified
during phase 1.
Phase 2 of system generation processes by default a command file named
[ll,17]SYSBLD.CMD. If any modifications need to be made to this file
or its equivalent to reflect system requirements, they must be made
prior to execution of phase 2.
If an alternative file has been
specified by the SYSBLD directive in phase 1 this file will be used in
place of SYSBLD.CMD.

3-5

SYSTEM GENERATION PROCEDURES
The steps necessary to run phase 2 follow.
1.

Bootstrap phase 2. There are two ways to bootstrap phase 2
into memory on the target system. Whichever way is used, it
must be booted from the unit specified as SY during phase 1.
Methods a and b follow.
a.

Create a bootstrap block 0 on the target disk and use the
hardware bootstrap. Issue the following command on the
host system to create bootstrap block 0.
MCR>BOO target disk:filename/WB
filename

is the name previously
TARGET directive.

specified

the

This command takes virtual block 1 of the file created by
phase 1 and writes it on physical block 0 of the target
device. The disk is now hardware bootable (see Section
2.1). It can be taken to the target hardware and booted.
b.

use the software BOOT function.
The MCR
software
bootstrap function is described in the RSX-llD User's
Guide. The software bootstrap boots the file created by
phase 1 into memory in the host system. Block 0 of the
target system is not modified.

When the software bootstrap function without the /WB switch
is executed, no other users should be online to the host
system. The host system is overlaid in memory by the target
system. The host system disk remains unaltered.
Before issuing the BOOT command, ensure that the target
system disk is mounted on the unit specified as SY during
phase 1. Then issue the following command to the host system.
MCR>BOO target disk:filename
Notice that the MCR BOOT command can be used either to create
the bootstrap block on a system disk by including the /WB
switch or to perform the bootstrapping from any disk by
omitting the /WB switch.
The two functions are mutually
exclusive.
If the bootstrap is currently written for a system image on
the disk (by means of a previous /WB) it is often advisable
not to write the bootstrap at this point.
Not doing so
retains the ability to obtain the old system on hardware
booting.
Writing the bootstrap here means that such a hardware boot
would initiate the System Generation Phase 2 image. This can
be useful if Phase 2 fails for any reason.
The function BOO is discussed in the privileged user section
of the RSX-llD User's Guide.
Chapter 5 of this manual
contains a detailed dicussion of bootstrapping.

3-6

SYSTEM GENERATION PROCEDURES
2.

Once the system has been bootstrapped,
following message.

phase

prints

the

*** SYSTEM GENERATION PHASE 2 ***
Phase 2 proceeds to mount the new system disk and then open
and read the file SYSBLD.CMD. All commands encountered in
SYSBLD.CMD are executed and echoed on the terminal.
NOTE
If the terminal handler has been built
incorrectly it may print
an
error
message at this point.
In this case
System Generation phase 2 will fail and
the system will not be usable. See
Section 2.4.5 for a list of these error
messages and their meanings.

Upon successful
message.

completion,

phase

prints the following

*** END OF SYSTEM GENERATION PHASE 2 ***
4.

Set the time and date, redirect the console logging device
(CL), load the message output handler, and perform any other
similar functions; e.g., loading other handlers.
MCR>TIM hh:mm:ss dd-mmm-yy
MCR>RED LP:=CL:
MCR>LOA MO
Additionally,
to prevent
partition,
fix the file
procedure.

the fragmentation of
primitives using the

the
GEN
following

MCR>DMO SY:
Also dismount any other mounted volumes.
MCR>FIX FllACP
MCR>MOU SY:/OVR
5.

If you are satisfied at this point that the system generation
was successful, dismount any mounted devices and perform a
save using the MCR SAV command. The following is an example.
MCR>DMO SY:
MCR>SAV
Once the system is saved, the following message is printed on
the console.
nnK WORDS RSX-110 Vxxxx
where:
nn is the memory size.
xxxx is the Executive version number.
At this point, SAV may issue messages describing memory size
adjustments1
see Section 5.5 and the discussion of SAV in
the RSX-110 User's Guide.
The MCR prompt follows
the
messages.

3-7

SYSTEM GENERATION PROCEDURES

NOTE
If at any time before performing the
SAV, a reboot of the new system disk is
performed, as described in step 1 above,
phase 2 of system generation is executed
again.
A reboot after a SAV causes the same
response as seen after performing the
SAV above, i.e., nnK WORDS RSX-llD. The
SAV
function
is
discussed in the
privileged user seqtion of the RSX-llD
User's Guide.
6.

If the user is satisfied with the system generation and wants
the disk to be hardware bootable, the functions of step la in
this section should be performed if they have not been done
already.
NOTE
It may be desirable to have the system
automatically mount the system disk and
request the time whenever it is booted.
This can be done using type ahead after
dismounting
all
volumes.
It
is
recommended
that
the
type
ahead
procedure be used after a test run of
Step 6 above.
The following is an
example.
MCR>DMO SY:
MCR>..Jor@)
SAV
MOU SY:/OVR
TIM

Also dismount any other mounted
volumes.
Type either RETURN or ALTMODE
Type ahead
Type ahead
Type ahead

At this point, press CTRL/C to cause the save, the
sign-on messages, and the execution of those functions
typed ahead. Typing only a single space after TIM leaves
MCR ready for the operator to insert the current time and
date followed by RETURN. The type ahead feature also can
be used for comments by prefixing the comment with a
semicolon
(;)
or an exclamation mark (!), to a maximum
total of 80 characters.
Type ahead is available only on the multiterminal
handler, not on the single-terminal handler TT01.

3-8

teletype

CHAPTER 4
SYSTEM GENERATION DIRECTIVES

Phase 1 and phase 2 of system generation are accomplished by issuing a
series of commands to the system. The commands issued during phase 1
are called directives and are described in this chapter.
Most
commands issued during phase 2 are MCR commands. One non-MCR phase 2
directive *DELAY also is described in this chapter.
Many system generation directives can have multiple parameter sets for
a single occurrence of the directive name.
Multiple sets are
separated from each other by backslash (\) characters.
The examples
below illustrate two PAR directives first and then the same two
directives using the convention for multiple parameter sets.
PAR=JIM,,,U
PAR=JOHN,,,U
or
PAR=JIM,,,U\JOHN,,,U
The method used to specify these directives to system generation is
detailed in Chapter 5. Examples of the directives are provided in
Appendix A. These examples should be used as guidelines in tailoring
individual systems.

4-1

SYSTEM GENERATION DIRECTIVES
4.1

TARGET DIRECTIVE

The TARGET directive is used to define the target device, i.e., the
device on which phase 1 is to create its output file and obtain all
required tasks for installation.
The TARGET directive has the
following format.
TARGET=xyn: [ufd]filename.ext
xyn:

is the device mnemonic
default is SY0.

[ufd]

is the UFO
system file.

filename.ext
If the TARGET
specification.

and

unit

number.

The

under which phase 1 is to store the
The default is [11,17].

is the filename and extension used to name the
file created by phase 1. The default is RSX.SAV.
directive is omitted, phase 1 uses the following file

SY0:[11,17]RSX.SAV
Only one target specified is permitted.

4-2

SYSTEM GENERATION DIRECTIVES
4.2

PDPll DIRECTIVE

The PDPll directive is required to define the target system processor
configuration to system generation. The directive has the following
format
PDPll=cpu-type,[mem-size] ,[fpt-optn] ,[clock-freq]
cpu-type

= nn to
specify
34,35,40,45,50,55
accepted values.

a
or

nn
is
PDP-11/nn
where
70. These are the only

mem-size

physical memory size
(to be saved and booted)
specified as nnnnK words. nnnn must be a decimal
integer. If this parameter is omitted, 32K is
used as the memory size. The mem-size specified
must be equal to or less than the amount of memory
on the target hardware. The maximum memory size
permitted is 124K for a PDP-11/34,35,40,45,50 or
55 and 1920K for a PDP-11/70. (See Section 5.5.)

f pt-optn

= FP to indicate that the PDP-11/34,45,50,55 or 70
floating point processor option is to be used;
otherwise, the parameter is omitted. This option
is illegal for a PDP-11/35 or 40.

clock-freq

system clock ticks per second for the standard
clock,
or
interrupts
per
second,
clock
identification, and clock ticks per interrupt for
the programmable clock.
For the standard clock, specify a decimal number
that is used as the line frequency (normally 50 or
60). The system runs with the line frequency clock
at the specified frequency.
If the parameter is
omitted, 60 Hz is used.
For a programmable
are specified.

clock, three decimal numbers

Frequency of
e.g., 1000.

clock

Clock identification

interrupts

per

second;

0
100 KHz
1
10 KHz
2
line frequency
3 = external

Number of clock ticks per interrupt

The three numbers must be enclosed in angle
brackets and separated by commas as in
the
following example:
<100,0,1000>
The above example indicates that the programmable
clock is to be used as the system clock.
It is
interrupting 100 times per second using the 100
KHz clock with a count of 1000 loaded into the
count register.

4-3

SYSTEM GENERATION DIRECTIVES
4.3

EXEC DIRECTIVE

The EXEC directive is used to load the RSX-llD Executive into memory
starting at a specified 32-word boundary. An address higher than the
bootstrap program must be used.
See Section 5.4.1 for bootstrap
sizes.
The EXEC directive has the following format.
EXEC=base
base

a 32-word boundary at which the Executive is to
start.
The octal number specified in the EXEC
directive is multiplied by 100 (octal)
by system
generation to determine the starting address. For
example, if base is specified as 540, the starting
address is memory location 54000 (octal).

The EXEC directive is optional.
If the EXEC directive is not
included, the Executive starts at the next 32-word boundary after the
bootstrap
program
and
base addresses specified in subsequent
directives are ignored.
If the EXEC directive is included, a base address must also be
specified in every directive that contains base as an optional
parameter.
If a PDP-11/70 system in excess of 124K is being generated, the
Executive,
SCOM, and system disk partition must be positioned
completely below the 124K boundary. Furthermore, the partition into
which SGN2 is installed must have sufficient space below the 124K
boundary for SGN2 to fit completely. Phase 1 checks for all the above
conditions and issues an error message if any is violated.

4-4

SYSTEM GENERATION DIRECTIVES
4.4

SCOM DIRECTIVE

The SCOM directive allocates space for the system common area. The
system common area comprises the system subroutines; a communication
region;
the system tables, including the system task directory; and
the node pool. The system common area cannot exceed 12K words.
The SCOM directive has the following format:
SCOM=[base] ,size,std-entries
base

starting address for the system common area. This
location is specified using the same conventions
as for the base address in the EXEC directive. If
the
EXEC
directive
is
included in system
generation, the base parameter must be part of the
SCOM directive.
If this parameter and the EXEC
directive are omitted, the system common area
follows the Executive in memory.

size

total length of the system common area. The size
can be specified as an octal number of 32-word
blocks or as nnK. When the form nnK is used, the
number
(nn}
is multiplied by 1024 words
to
determine the desired size. The factors involved
in determining the size of SCOM are detailed below
in Section 4.4.1.

std-entries

decimal number of system task directory entries.
This parameter establishes the maximum number of
simultaneously-installed tasks
(user and system
tasks} that the system is to support.

One SCOM directive is required.

4.4.1

SCOM Size

The size of the system common area (see Section 4.4) is the sum of the
following elements:
1.

The length in words of the system subroutines
communication area. This is calculated as follows:
Subroutines Size = (160000 -

and the

.CRTSK)/2 words (octal}

The number of tasks installed at any given time multiplied by
16 words,

3 •.

The number of system task directory (STD) entries specified
by std-size, above,

The number of DEV directives multiplied by 25 words,

The number of PAR directives multiplied by 10 words,

Size of the variable-length node pool.

To determine the approximate amount of remaining space in the pool,
subtract items 1 through 5 from the SCOM size parameter as follows.
Pool size = SCOM size -

(sum of items 1 through 5)

4-5

SYSTEM GENERATION DIRECTIVES
The node pool is used by the Executive and many of the system
utilities as dynamic storage. Each node consists of a variable number
If the system runs out of pool space, its
of 8-word blocks.
performance degrades and results may be
unpredictable.
Until
experience is gained with the system, leave as much space as possible
for the pool.

4-6

SYSTEM GENERATION DIRECTIVES
4.5

PAR DIRECTIVE

The partition directive establishes the name, base address, size, and
type of every partition in the target system. Every partition in the
system must be defined during system generation.
The PAR directive has the following format.
PAR=par-name,[base] ,size,[par-type], [par-pri]
par-name

up to 6 character ASCII name for the partition.
It is converted to a radix 50 name by the system.

base

an optional starting address for the partition.
This parameter is specified only if a base address
is included in the EXEC directive and follows the
same rules as those for the EXEC directive.
If
base
is omitted, the system
partition optimally in memory.

size

places

the

the size of the partition specified as an octal
number of 32-word blocks or as nnK. When nnK is
used, nn is multiplied by 1024 to determine the
desired size.
One
partition in the PAR specifications can
contain an asterisk (*) instead of an actual size.
The size of that partition is the remainder of
memory after the bootstrap, Executive, SCOM, and
all specified partition sizes have been subtracted
from the memory size stated
in
the
PDPll
directive.

par-type

= partition type.
U indicates user-controlled;
S
indicates system-controlled; and T indicates that
the time-based scheduler is to operate in this
partition. This algorithm is described in the
RSX-llD System Manager's Guide. If par-type is
omitted, the partition is user-controlled.

par-pri

is the priority at or above which the time-based
scheduler declares a task to be runnable.
It is a
decimal value in the range 2 through 200 (PR.A for
the
minimum
and
PR.C
for
the
maximum,
respectively). This parameter is valid only for
T-type partitions.
If par-pri is not specified
for T-type partitions, a default value specified
by the Executive global symbol PR.DFL is used.
PR.A, PR.C and PR.DFL are described in the RSX-llD
System Manager's Guide.

Multiple parameter sets are allowed.
Unless base addresses are specified, the partitions are placed in
memory in the order specified by the set of PAR directives.
If PDP-11/70 generation is being performed, the system disk handler
and SGN2 must be completely below the 124K boundary.
Refer to Section
5.5 for a discussion of partitioning under RSX-llD.
Only one partition can use the asterisk (*) size specification.
Any
number of U, S,
and T partitions is permitted.
At least two
partitions are required:
one for the system disk handler and one for
system generation phase 2.
4-7

SYSTEM ~ENERATION DIRECTIVES
4.6

DEV DIRECTIVE

The DEV directive is used to characterize completely each device to be
controlled. Each use of DEV creates an entry in the system's Physical
Unit Directory
(PUD). Any device not defined by a DEV directive does
not exist as far as RSX-llD is concerned.
Often with DEV it is enough to specify the device mnemonic
number and the device type. See Appendix A.2 for examples.

with

its

If a device is to have non-standard characteristics, the latter can be
specified in place of a standard type. See below under
'type' and
Appendix B for details of device characteristics.
A device's interrupt trap vector, software priority and external page
address may also be taken· by default. The default values are listed
in Table 4-1.
With a device there can be associated a file primitives task or
ancillary control processor task. See below under 'devacp'.
The format of the DEV directive is as follows.
DEV=xyn,type[, [vect], [pri], [ext-page] [,devacp]]
xy

a 2-character ASCII mnemonic to be used
to the device.

refer

a 1-or 2-digit octal unit number.

type

either
a device type that phase 1 uses to
determine the device characteristics or the actual
device
characteristics.
Table 4-1 lists the
device types recognized by phase 1. Appendix B
lists the associated characteristics.
If the four device characteristics are to be
specified they must appear between angle brackets
as in the following example.
DEV=XY0,<3,17,21,1000>,210,5,177000

vect

the device interrupt trap vector.
for the default values.

See Table 4-1

pri

the software priority at
which
the
device
interrupts are to be serviced. The user should
ensure that the software priority is equal to or
higher than the hardware level at which the device
interrupts unless the interrupt service routine of
the handler is re-entrant. See Table 4-1 for the
default values.

ext-page

the external
page
address
of
the
device
controller.
In most cases, ext-page is the lowest
address when a device uses several external page
addresses.
See Table 4-1 for the default values.

devacp

is an optional file primitives task
name for file-oriented devices.

name

ACP

Ari ACP
(ancillary control processor) is a task
that assists a device handler in managing a
file-structured volume.
An ACP also is referred
to as a file primitives task under RSX-llD.

4-8

SYSTEM GENERATION DIRECTIVES
If an ACP is not specified, ·phase 1 defaults to
FllACP
for directory devices and MTAACP for
magnetic tape.
If an ACP task is specified, its name must be 6
characters
ending
in ACP.
The first three
characters are stored in the PUD and used at mount
time.
The ACP task must be installed before the
device can be mounted.
If the vector, priority and external page address are not
they will be defaulted to the values shown in Table 4-1.
For examples of the DEV directive see Appendix A.2.

4-9

specified,

SYSTEM GENERATION DIRECTIVES
Table 4-1
Device Information

Mnemonic

Type

DK
OF
DP
OS
OS
DB
OM

RK03
RK05 ( 5)
RFn(l)
RP03B,RP02
RS03
RS04 ( 2)
RP04,RP05,RP06(2)
RK06

RX01

TT
TT
LP
LP
LP
CR
CR
MT
MM
PR
pp
OT
CT
AF

CONSOL(3)
TERM
LPllA ( 80Col)
LPllB (132Col)
Lxllyz ( 4)
CRll
CDll
TU10,TS03
TU16
PTR
PTP
DTll
TAll
AFll

AD01

LS
UD
MO

LPSll
UDCll
None

Normal
Vector

Priority

External
Page Address

220

177400

5
5
5
5
5

177460
176710
172040
172040
176700
177440
177170
177560
Float
177514
177514
177514
177160
172460
172520
172440
177550
177554
177340
177500
172570
176770
170400
171000
None

204
254
204
204
254
210
264
60
Float
200
200
200
230
230
224
224
70
74
214
260
134
130
Float(6)
234
None

5
5
4
4
4
4
4

4
5
5
4
4

6
6
4
6
5
6

None

(1) n = number of RFll platters
(2) These are disks on the RH Massbus controller.
The DB unit number must correspond to the number assigned
physical connection to the RH.

(3) CONSOL must be used for the console terminal TT0. All other
terminals must be specified as TERM.
(4) The line printer type is Lxllyz where

= p for LPll line printer
= s for LP05 and LSll type printers
y = w for wide (132 column) printers
= N for narrow (80 column) printers
z = u translate lower case characters to upper case
x

(ASCII codes 140-176 are converted to 100-136)

= L for no translation of characters.
(5) An RK05F disk is specified as two RK05 units.
The unit
numbers must be paired as follows for each RK05F unit:
(DK0
and DKl), (DK2 and DK3), (DK4 and DK5) and (DK& and DK7).
(6) For an LPSll the vector, priority and external
must all be specified.

4-10

page

address

SYSTEM GENERATION DIRECTIVES
NOTE
For various combinations of the above
devices, vector addresses and external
page addresses may differ from those in
Table 4-1. The correct
vector
and
external
page
address
for
any
configuration can be determined by Field
Service Engineers.
Useful information
can also be found in PDP-11 Peripherals
Handbook.

4.6.l

Pseudo-Devices

The following pseudo
RSX-llD User's Guide):
SY
TI
CI
CO
CL
MO
BP
SP

devices

are used in RSX-llD (see Chapter 3 of

system disk
terminal interface
console input
console output
console log
message output
batch
spooling output

SY, TI, CI, CO, CL are automatically provided.
MO, BP and SP
reguired must be declared in phase 1 by the DEV directive, thus

DEV = MO
DEV
SP
DEV
BP
and can not be added at a later stage.
All except BP may be
redirected to particular physical devices after phase 2 by the
MCR>RED[IRECT] command, for example
MCR>RED DPl:=SP:
Both BP and SP are required for BATCH processing.
SP must be
redirected to a disk. BP is automati6ally redirected to the terminal
invoking batch.
This invoking terminal is the one from which batch
commands are submitted or, in the case of card input, the one from
which the card-reader handler was loaded.
See the RSX-llD BATCH
Reference Manual, Chapter 4.

4-11

SYSTEM GENERATION DIRECTIVES
4.7

SY DIRECTIVE

The system directive establishes the initial SY of the target system,
i.e., the system disk to be used when phase 2 of system generation
runs. The SY directive has the following format.
SY

xyn

the 2-character mnemonic of the device.

n = the unit number of the device.
The default is DK0.
Phase 1 of system generation checks that
device designated as SY is installed.
the system device, the user must install
phase 1 of system generation.

the handler task for the
For example, if DP0 is to be
the handler DP •••• during

Care must be taken to ensure that the correct device is assigned to
SY. Phase 1 of system generation assumes that all tasks that phase 1
installs are to be resident on the SY of the target system and creates
STDs accordingly.
Since some of these tasks are required during execution of Phase 2, it
is necessary to bootstrap phase 2 from the target SY device. See
Section 5.4 on software bootstrapping of RSX-llD.

4-12

SYSTEM GENERATION DIRECTIVES
4.8

DPAR DIRECTIVE

The default partition directive specifies the partition to be used
when a partition is not indicated for a task during task building or
when the /PAR portion of an MCR command is omitted.
The DPAR directive has the following format.
DPAR=par-name
par-name

the name of the default partition.
name used in a PAR directive.

The DPAR directive is required.

4-13

It must

SYSTEM GENERATION DIRECTIVES
4.9

DUIC DIRECTIVE

RSX-llD provides the user with an MCR function referred to as RUN $.
The purpose of this function is to allow a nonprivileged user to run
any of a set of multiuser tasks that reside under the same UFD on the
system disk. The DUIC directive is used to designate the UFD that is
to contain these multiuser tasks; normally, the nonprivileged user
would not have access to the designated UFD.
The DUIC directive has the following format.
DUIC=g,m
g

the group number

the member number

For example, if the directive DUIC=200,201 is issued during system
generation, any user can run a task having the file specification
SY: [200,20l]task.tsk by entering the following command.
MCR>RUN

$task

If the DUIC directive is omitted, UFD [11,l] is used by default when a
RUN $ command is issued.
It is the system manager's responsibility to ensure that all tasks
that are to be available to the nonprivileged user by means of RUN $
are stored under the UFD designated by the DUIC directive.

4-14

SYSTEM GENERATION DIRECTIVES
4.10

CKPNT DIRECTIVE

The checkpoint directive indicates that checkpointing is to be enabled
in the system and specifies the disk and disk storage area to be
allocated for checkpoiting.
The CKPNT directive has the following format.
CKPNT=dev,size
dev

name of the device on which the checkpoint area is
to reside. The device must be named in a DEV
directive.

size

size of the checkpoint area on the disk 'dev'. The
size can be specified either as nnK (i.e. words),
with nn in decimal, or as an octal number of
32-word blocks.

For example:
CKPNT=DK1,50K
specifies 50K words on DKl, and
CKPNT=DKl,1600
specifies 1600(octal) 32-word blocks on DKl, that
bytes.

160000

(octal)

The device named for checkpointing must contain a Files-11 structured
volume and be mounted during phase 2 of system generation.
It may
also be necessary to install and load the appropriate disk handler
before creating the checkpoint file.
To create a Files-11 structured
volume, use the INI command to MCR in the SYSBLD.CMD command file that
is executed during phase 2 of system generation or have a previously
created volume on the device. Allocation of the checkpoint file is
the last function perfomed by SGN2 after processing SYSBLD.
The use of checkpointing is optional. However, if it is used,
real
memory space is allocated to support it. The amount of memory used
depends on the checkpoint area of the disk. The relationship is one
32-word memory block for every 512K words of disk space specified for
checkpointing. The checkpoint bitmap is at the end of the Executive.
This memory allocation must be taken into account when specifying the
size of partitions.

4-15

SYSTEM-GENERATION DIRECTIVES
4.11

PSWD DIRECTIVE

The password directive specifies a password that may be used in
generated system. The PSWD directive has the following format.
PSWD = password of up to 6 alphanumeric characters
NOTE
None
of the software provided with
RSX-llD uses this password.
Passwords
are assigned to UICs by the system
manager using the PWD command to MCR.
This directive is provided so that a
user password facility can be developed
independently
of the RSX-llD log-on
procedure. The 6 characters specified
in a PSWD directive are stored in the
system communication area at location
'.MCRPW'.

4-16

the

SYSTEM GENERATION DIRECTIVES
4.12

INS DIRECTIVE

The install directive installs the system tasks needed to provide the
target system with the capability to do useful work.
The INS
directive has the following format.
INS=par-name,file-specifier,file-specifier, ••• ,file-specifier
par-name

partition name.

file-specifier

An RSX-llD file containing a task to be
installed in the named partition. Up to five
files can be specified in one INS directive.
The file specifier must not include a device
mnemonic and must be fewer than 32 (decimal)
characters.

Minimally, the disk driver (DK •••• , DP •••• , DF •••• , DB •••• or DM •••• ),
the terminal handler, FllACP, and phase 2 of system generation (SGN2)
must be installed. See the INS directives in the system generation
command files in Appendix A for examples. Refer to the PAR directive
(Section 4.6).
To obtain a list of system tasks that can be installed,
print a
directory of UFD [11,1]. Further discussion can be found in Sections
5.2.6 and 5.5.
All tasks installed during phase 1 are assumed to be on the device
specified in the TARGET directive.
It is further assumed that they
are to be on the target SY when phase 2 executes.
The following limitations apply to phase 1 installation of
Shareable Global Areas (SGAs)
•

No more than 15 tasks can be installed in phase 1.

•

No more than
partition.

•

The system disk handler and System Generation
bind to an SGA or have a read-only segment.

tasks

and

tasks and SGAs can be installed into a single

4-17

phase-2

can

not

SYSTEM GENERATION DIRECTIVES
4.13

SYSBLD DIRECTIVE

The SYSBLD directive is used to define the file that will be read by
SGN2 in processing MCR commands.
The SYSBLD directive has the
following format.
SYSBLD=[ufd]filename.ext
where:
[ufd]

is the UFD containing
default is [11,17]

file.

The

filename.ext

is the filename and extension used to name
file to be read.
The default is SYSBLD.CMD.

the

command

If the SYSBLD directive is omitted Sysgen Phase 2 will read the file
[ll,17]SYSBLD.CMD. Only one SYSBLD directive is permitted. A device
specification is not allowed.
The file should exist on the system
disk by the time it is booted to perform phase 2 of Sysgen.

4.14

PHASE 2 DIRECTIVE (*DELAY)

The *DELAY directive causes a I-second delay in the processing of
Phase 2 commands.
Phase 2 sequentially retrieves and executes MCR
commands from the file named by the SYSBLD directive, or, if none was
specified, from [11,17] SYSBLD.CMD. Each command is allowed to finish
before the next command is executed.
The *DELAY directive does not have any parameters.

4-18

CHAPTER 5
ADDITIONAL SYSTEM GENERATION INFORMATION

Once the system is placed on disk from the distribution medium as
explained in Chapter 2, system generation can begin.
RSX-llD system
generation proceeds in two phases.
Phase 1 defines the hardware configuration, specifies system defaults,
and installs the system tasks required for execution of phase 2.
System generation directives are used to supply
the
required
information.
Phase 2 performs a series of actions requested in the indirect file
specified by the SYSBLD directive, or, if none was specified,
[ll,17]SYSBLD.CMD. Phase 2 information cannot be typed at a terminal.
Once all the requests in the SYSBLD file are performed,
the
newly-generated system is operational.

5.1

EDITING SYSTEM GENERATION FILES

Several
indirect
RSX-110.

command files for system generation are provided in

They can be used to define the system to phase 1 instead of typing
directives in response to phase 1 requests. A SYSBLD file is always
used to perform phase 2. If the user wishes to tailor the system to a
particular installation, he can either edit the existing files or
create new ones. See the RSX-110 Utility Programs Procedures Manual
for a description of the editor.
All commands files are stored under UFO [11,17]. Type the following
command to request the editor for modification of existing generation
files or the creation of new ones.
MCR>SET /UIC=[ll,17]
MCR>EDI command file

5-1

ADDITIONAL SYSTEM GENERATION INFORMATION
5.2

PHASE 1 OF SYSTEM GENERATION

Phase
1
system
categories:

generation

directives

are

divided

into

seven

The TARGET directive that defines the target system device.

The PDPll directive that defines the computer to be used.

The EXEC, SCOM, and PAR, directives that divide the computer
memory into the Executive, the system communication area, and
partitions, respectively.

The DEV directives that define the system peripherals.

The DPAR, DUIC, ciPNT, PSWD, and SY
system default information.

The INS directives that install tasks needed for phase 2.

The SYSBLD directive
processed by Phase 2.

directives

that

supply

which defines the file which is to be

Regardless of whether the directives are to be typed in response to
system generation requests or an indirect file is to be used, each
category of directives is separated from the preceding category by a
record containing only a slash (/) • The end of input to phase 1 is
indicated by a record containing two slashes (//). See the examples in
Appendix A.
To reach the point where the directives are entered, perform the
appropriate steps as detailed in Chapter 3 through step 8 of Section
3.1. At this point, the following message is printed on the terminal.
SYSGEN PHASEl
SPECIFY TARGET DEVICE AND FILENAME

5.2.1

Target Specification

When the message SPECIFY TARGET DEVICE AND FILENAME is printed on the
console, the user can type the TARGET directive or the name of the
indirect command file to be used. Alternatively, the user can type
both; see Section 3.1, steps 9 and 10.
If the TARGET directive is used, it establishes a complete description
of where the output file of SGNl is to be created and with what name.
The following example creates a file named 48KV62.SAV on DKl under UFD
[11,17].
SGN>TARGET=DKl: [ll,17]48KV62.SAV
As with any other directive, the TARGET directive can be included in
the command file,
in which case the procedure is as described in
Section 3 .1.

5-2

ADDITIONAL SYSTEM GENERATION INFORMATION
After entering the TARGET directive, SGNl again prompts. The response
at this point is either a command file name or a slash (/) to cause
the CPU specification prompt as in the following example.
SGN>TARGET=DKl: [ll,17]48KV62
SGN>/
ENTER CPU SPECIFICATION
SGN>

5.2.2

CPU Specification

When the message ENTER CPU SPECIFICATION is printed on the console,
the user types the PDPll directive.
Enter the PDPll directive
followed by a record containing only a slash (/) as in this example.
SGN>PDP11=40,48K
SGN>/

5.2.3

Memory Allocation

The memory allocation directives make it possible for the user to
place the Executive and system common area in memory and to establish
partitions and shared regions.
The allocation
of
memory
is
accomplished using the following directives:
•
•
•

EXEC (optional) ,
SCOM (required),
PAR (required).

These directives can be entered in any order in response to the
following request that is printed on the console. The order of the
PAR directives specifies the order of partitions in memory, unless
base addresses are specified.
SPECIFY DIVISION OF MEMORY
The memory allocation directives
containing only a slash (/)

5.2.4

must

followed

record

Device Specifications

Type the DEV directives in response to the following message.
SPECIFY DEVICES
When all directives are entered, type a record containing a slash (/).

5.2.5

System Default Specifications

Once the device specifications are entered, the
default directives as follows.
SPECIFY DEFAULTS

5-3

system

requests

the

ADDITIONAL SYSTEM GENERATION INFORMATION
Any of the following directives can be typed at this point:

e
e
e
e
e

DPAR,
DUIC
CKPNT,
PSWD,
SY.

The directives can be in any order.
The last directive must be
followed by a record containing a slash (/) •

5.2.6

Required Task Installations

At the completion of phase 1, a target system exists that can operate
as an independent RSX-110 system.
It must contain an RSX-110
Executive that can either satisfy its intended end-use requirements or
be capable of expanding itself to do so. Therefore, the final portion
of phase 1 installs the tasks required to accomplish this end.
When a task is installed, it is given an entry in the system task
directory (STD). This entry allows the system to load the task without
making use of the file system.
Selection of tasks for
factors:

installation

depends

the

following

two

The capabilities defined for the target system,

The procedures to be used in creating the operational target
system.

If the target system is to operate as an independent RSX-110 system
following bootstrap, it must have tasks installed in it that are
capable of doing the required work.
While processing the INS directives, phase 1 of system generation
checks for the names of two system tasks:
the disk handler for the
system disk and phase 2 of system generation.
These tasks are
installed and, upon bootstrap, are running. The device handler is
either DK •••• , DP •••• , DF •••• , DB •••• , OM •••• or OS •••• depending on
the unit assigned SY. Phase 2 of system generation is called SGN2. If
these tasks are not named in the INS directive, the system is not
operational when bootstrapped.
Normally other tasks must be installed in addition to the disk handler
and SGN2. Typically the following additional tasks are installed:
e
e

•
•
e

Install (INS),
Mount (MOU) ,
File system primitives,
Terminal handler (TT) ,
MCR.

A critical decision centers on the inclusion of the INS MCR function.
Unless INS is installed during phase 1, the target system is unable to
install tasks. Such systems may not be uncommon;
for example, a
remote data collector involves few tasks, is rigidly defined, and is
generated to occupy minimum core, thus having no need for INS.
Since phase 2 of system generation automatically mounts the system
device,
the appropriate file primitive tasks must be installed curing
phase 1. Two versions of the directory device file primitives are
5-4

ADDITIONAL SYSTEM GENERATION INFORMATION
provided.
Both have the task name FllACP. One has the filename
FCP.TSK.
It is a small, heavily overlaid version of the task.
The
other is named BIGFCP.TSK and is minimally overlaid.
If the user has his own file primitives, he should set the default ACP
name in the DEV directive and install that task ~uring phase 1.
With the minimum number of required tasks installed, the installation
of any additional tasks can occur during phase 2. The decision to
install additional tasks during phase 2 is partly procedural and
partly due to the 15-task installation limitation of phase 1.
The system prints the following message to request the INS directives.
SPECIFY INSTALLS
THE INS directives should be followed by a record containing one
slash(/) or if no SYSBLD directive is to be specified then two slashes
{//).

5.2.7

Specification of SYSBLD Command Files

The system will request the SYSBLD command file by typing
SPECIFY SYSBLD COMMAND FILE SPECIFICATION
The name of the appropriate command file should be entered. After the
SYSBLD directive has been typed enter a record consisting of two
slashes (/ /) •

5.2.8

Pool Requirements of SGNl

Phase l of system generation uses the dynamic pool for storage of
input data and for communication with the version of install ( ••. INV)
that it requests. SGNl returns nodes to the pool as soon as it has
finished with them.
If a fatal error occurs, it returns all nodes
using its own internal accounting system.
As a result, pool usage
is
quite
dynamic.
The
important
consideration, however, is the maximum usage at any time. To compute
the maximum pool usage consider the phase 1 command input while
referring to Figure 5-1.

5-5

ADDITIONAL SYSTEM GENERATION INFORMATION

NODE USAGE
1 node

16 contiguous words.

This graph does not include MCR buffers or nodes
used by the file system.
1

TARGET
PAR

1 node only if UIC and/or filename is specified
PAR
DEV

DEV

task and 1 for each partition for which installs
are specified
Calculate system mapping
Create target system image file
Exec, null task, pool written out
PUDs created and written out
3 nodes picked for control of ••• INV
(2 further nodes if SYSBLD specified)

INS

SYSBLD
Loop repeats
once for
each task

task description data
I Return
Request ••• INV
••. INV creates an STD
and/or GCD

All tasks installed in target system
Return 1 ••• INV control node
Return all device information nodes - 1 per DEV
Write alpha table
Write STDs
Return STDs
1 per task
Create ATL entries
Write partitions
Return PAR data
1 per PAR

Create bootstrap on virtual block 1
Write SCOM to memory
Close files
Return all outstanding nodes -- 3 if SGNl is successful
Exit

~All fatal SGNl errors enter here

Figure 5-1

SGNl Pool Usage

5-6

ADDITIONAL SYSTEM GENERATION INFORMATION
5.3

PHASE 2 OF SYSTEM GENERATION

Phase 2 of system generation is installed during phase 1. On bootstrap
from a phase 1 target disk as described in Section 2.3, phase 2 is
activated and proceeds as follows:
1.

Loads the terminal handler,

Issues a MOUNT command for the system device (SY),

Opens the file SY: [ll,17]SYSBLD.CMD, or other user specified
file and if the open is successful, begins to process the
file and print it on the console.

The file SYSBLD.CMD is provided in the RSX-110 system. If the user
wishes to modify it, he should do so before bootstrapping phase 2.
SYSBLD.CMD can contain the phase 2 directive described in
*DELAY, and any MCR request except SAVE or BOOT.

Chapter

A task must be installed before it can be used. The task can be
installed either during phase 2 of system generation or by the INS MCR
request.
If the task refers to a shared region, the region referred
to-must be installed before the task is installed.
When phase 2 is complete, it
console.

prints

the

following

message

the

END OF SYSTEM GENERATION PHASE 2
At this point, perform the steps in Section 3.2 starting with step 4.
This process properly saves the system for continued use.

5.4

RSX-llD BOOTSTRAPPING

The PDP-11 family of computers is supplied
with
a
hardware.
bootstrapping program in read only memory.
The function of this
program is to read one block (physical block 0) of a specified device
into main memory starting at real location zero. On successful
completion of the read, the processor jumps to real location zero with
memory management disabled and starts to execute the contents.
Under RSX-llD, block zero of the booted device must contain a program
to read in the whole operating system and user-defined partitions,
enable memory management, and start the Executive.
During the generation and subsequent management of an RSX-110 system,
the operations related to the bootstrap go through several phases.
Although these operations are relatively transparent to the user, the
system manager should be aware of the actions taken and their
implications.
The operations can be divided into the following four
categories.
1.

Phase 1 of system generation

Phase 2 of system generation

Saving the generated system

Subsequent bootstrapping and saving of a stable system

5-7

ADDITIONAL SYSTEM GENERATION INFORMATION
5.4.1

System Generation Phase 1 (SGNl)

The purpose of the first phase of system generation is to create a
file;
e.g., RSX.SAV, on a
target disk.
This file is a bootable
RSX-llD system image configured for the target hardware;
i.e.,
the
contents of RSX.SAV ofi completion of phase 1 are independent of the
hardware configuration on which
it
was
created.
The
only
bootstrap-related function performed by SGNl is to include the
bootstrap at the beginning of the RSX-llD image file.
Due to differences among mass storage device controllers,
the
bootstraps
for various devices differ in their control
logic.
Therefore, RSX-llD provides a bootstrap program for each different
device supported as a system device.
The bootstrap programs are named
using the convention xxxxBOOT.TSK. xxxx is the commonly-used name for
the device. At present, bootstraps are supplied for RK05, RK06, RFll,
RP03, RP04, RS04 disk devices.
The RK03 uses RK05BOOT, the RS03 uses RS04BOOT, the RP02 uses RP03BOOT
and the RP05 and RP06 use RP04BOOT.
Using the SY directive and the related device specification, SGNI
determines which bootstrap task is to be written into the beginning of
the memory image file that it is creating.
Before it writes this task into the image file, however, SGNl must
insert the following information into the program.
1.

The amount of memory to be filled

(upper limit 124K words).

The disk address of the RSX.SAV file.

The real base address of the Executive (to load
when memory management is enabled} .

The external page address of the disk controller as specified
by the corresponding DEV directive.

The kernel virtual address of the power recovery routine
within the Executive.
This routine is used to start the
Executive as well as to recover from a power failure.

kernel

APR0

The first four items are available to SGNl. The last
(power
recovery
routine address}
is obtained by building the appropriate bootstrap
task with the Executive symbol table,
EXEC.STE.
SGNl,
therefore,
inserts items one through five above into the bootstrap task before
writing it to the RSX.SAV file.
To insert the required information,
SGNl must have access to the
symbol
table of the bootstrap task.
Consequently, SGNl also reads
xxxxBOOT.STB to determine the bootstrap program's data locations.
Since the bootstrap is linked with the EXEC.STE, SGNl is able to
locate all other symbols for the target Executive from the bootstrap
task symbol file.
During phase 1 of system generation,
the user has the option of
defining base addresses for the Executive,
the system communication
area,
and partitions.
If base addresses are not specified, SGNl
performs a memory allocation and places the Executive on the next 32
word boundary after the bootstrap program.
SGNl determines the length
of each bootstrap from the corresponding .STB file.

5-8

ADDITIONAL SYSTEM GENERATION INFORMATION
If the user specifies the base address, he must take care to leave
sufficient space for the bootstrap program. The user can determine
the bootstrap size by obtaining a task builder listing of the
appropriate xxxxBOOT.STB. The following command is used.
TKB>,LP:=[ll,17]xxxxBOOT.STB
The value of .BO.ND (end bootstrap) rounded up to the next 32 word
(100 octal) boundary provides the lowest real address at which the
Executive can be placed.
Whenever the executive is rebuilt using the [11,lS]TKBlS.CMD command
file the bobtstraps must also be rebuilt using the command file
[ll,17]BOOTSBLD.CMD.
This is because system generation phase 1
obtains all executive symbols from the apporpriate xxxxBOOT.STB symbol
table file.
It is important to note that unlike earlier versions of RSX-llD,
version 6.2 and subsequent versions do not write block 0 of the target
system device. Rather, it places the bootstrap task at the beginning
of the memory image file created by phase 1.

5.4.2

System Generation Phase 2 (SGN2)

Some of the functions necessary for a complete system generation must
be performed on the target hardware configuration (e.g., creation of
the checkpoint file) • Others are more conveniently performed under the
target software configuration (e.g., installation of a large number of
tasks). Therefore, phase 1 of system generation creates a runnable
RSX-llD system with SGN2 installed and loaded into its partition.
When the Executive starts, it activates SGN2.
SGN2 makes no modifications to the bootstrap program either in memory
or on disk. The only bootstrap-related aspect of SGN2 is the initial
bootstrapping of the output file from SGNl. This bootstrapping causes
the system disk handler to be activated on the first ATL scan and SGN2
to be activated on the second ATL scan.
There are two methods of booting the output of SGNl:
1.

By using the MCR BOOT function,

By using a combination of
hardware bootstrap (ROM) •

the

MCR

BOOT

function

and

the

Whichever method is used, the output of SGNl always must be booted
from the device that was specified as SY during phase 1.
When the first method is used, all devices except the bootstrap device
must be dismounted to ensure that all activity within the system is
stopped. Then the MCR BOOT function is requested and given the file
specifier of the image file to be booted. The BOOT task reads the
first block·of the image file into memory starting at real zero and
begins to execute it. This process simulates the ROM bootstrap. BOOT
does not require block zero of the device to have any special content.
It uses the first virtual block of the image file specified.
With the second method, BOOT is used to create a bootstrap block 0 on
the device. Then the device can be booted with the appropriate
hardware ROM.
BOOT accepts the switch /WB following the file
specifier for the RSX-llD image file to be booted. If this switch is
present, the first block of the file is copied to block 0 of the same
volume. This procedure does not perform a system reload, but does
5-9

ADDITIONAL SYSTEM GENERATION INFORMATION
make the volume hardware bootable.
The inclusion of the BOOT MCR function allows the complete generation
and testing of a new RSX-llD system without changing the target device
substantially.
The only modification to the target device is the
creation of a new memory image file and installation of tasks into
that system.
Note that task headers are impure, i.e., they are
modified when a task is installed.
Therefore, even though it is
possible to reboot a disk on which a new RSX-110 image file has been
created, care must be taken with such tasks as INS, MOU,
and FllACP,
if they are not fixed,
because their headers will reflect the new
system. This problem can be circumvented by making separate copies of
such tasks before running SGNl.
It is possible to have more than one complete running system on the
same disk. However very great care is needed. All systems must have
the same number of partitions and devices. Devices which are common
to one or more systems must be in the same relative position in the
list of DEV directives.
This is because the task headers contain
pointers to system data structures.
If these precautions are not
observed a system crash will almost certainly occur whenever any of
the systems is booted.
For further information about BOOT, refer to the RSX-llD User's Guide.

5.4.3

Saving a Generated System

When SGN2 runs successfully, all the facilities of the generated
RSX-110 system are available. Once the user is satisfied that the
system does perform as intended,
it is necessary to dismount all
devices and save the updated memory-resident system on the bootstrap
device.
If extensive testing - of the new system is intended, it is
advisable to save the system first.
The purpose of the SAVE MCR function is to rewrite the file that was
originally
booted.
SAVE
uses the bootstrap program that is
permanently resident in low memory to perform this function.
This
approach insures the following:
1.

Only as much memory as specified during SGNl is written,

Memory is saved at the disk address (i.e., in the image file)
from which it is to be booted.
NOTE
The booting of a previous save image should only be done if
the system environment is known to be the same as it was when
the save image was created. Serious errors can occur if, for
example, tasks which were installed at the time the image was
created have been moved or deleted.

The device on which the file is saved is independent of any
redirection of SY or other devices. That is, the save takes
place on the device from which it was booted.

5-10

ADDI'l'IONAL SYSTEM GENERATION INFORMATION
Because the output of SAVE is an exact replica of memory, the RSX-110
image file appears as a system with the SAVE task running. In order
for SAVE to exit, it makes several modifications to the bootstrap in
low memory after copying it into its own buffer to perform the disk
write and before performing the actual save. These modifications are
as follows.
1.

Store the content of user APR0.

Store
APR0.

Modify an internal branch within the bootstrap so that a
sequence of instructions to return to SAVE in user mode is
executed after memory management is enabled.

the re-entry address in SAVE which is relative to user

At this point, two versions of the bootstrap program exist in memory:
the original within SAVE and a modified version beginning at real
location 0.
SAVE now changes the I/O function code of its version from a read to a
write,
inhibits task switching and interrupts (processor priority 7),
and executes its version of the bootstrap.
Upon completion of the
save to disk, SAVE executes the same code that it executes when
rebooting the saved memory image, as described in the next section.
Before a save of the system can be attempted, the system must be
quiescent.
The SAV function ensures that no activity is taking place
by searching the system data base for any of the following conditions:
1.

Mounted devices,

A user logged onto any terminal except the one from which SAV
was initiated,

Tasks with I/O in progress,

Tasks being loaded or checkpointed,

Shareable global areas being loaded or,
in the
read/write common areas, being written to disk,

Tasks loaded or fixed
file;
that is, the SAV
memory PDP-11/70).

Shareable global areas, including the read-only portion of a
multiuser task, loaded beyond the end of the save file
(possible only on extended memory PDP-11/70) •

Tasks with send/receive data queued.

Tasks
disk.

SGAs

case

beyond the end of the system image
file
(possible only on extended

installed from devices other than the system

If any of these conditions is
message and exits.

detected,

SAV

prints

appropriate

Before writing the system to disk, SAV translates the absplute disk
addresses if task image files,
shareable global areas and the
checkpoint file into the corresponding file-id.
Since this is
independent of absolute disk addresses these files may be relocated on
the disk,
for example by the DSC utility. When the system is booted
the file-ids are translated back into absolute disk address using the
file structure on the disk, as described in the next section.
5-11

ADDITIONAL SYSTEM GENERATION INFORMATION
5.4.4

Subsequent Rebooting of a Saved Image

Regardless of which method is used to boot a saved RSX-llD system, the
bootstrap program that performs the read originally came from virtual
block 1 of the file being booted.
This bootstrap overlays itself with
the beginning of the file it is reading. Since the only differences
between bootstraps is in data, the instructions continue to execute.
On completion of the read of memory, which is performed in lK
increments, the overlay copy of the bootstrap executes a sequence of
instructions that returns to SAVE in user mode with task switching and
interrupts inhibited.
SAVE then restores all volatile registers,
restores the power recovery vector which was used to direct the
bootstrap to SAVE, and performs a number of other functions not
related to the bootstrap.
Upon completion,
task switching and
interrupts are enabled and the Executive is started by simulating a
power fail AST.
Finally, SAVE prints the RSX-110 sign-on message and
exits.
One of the other functions performed by SAVE is to check the existence
of the system clock.
Since RSX-110 can use either a KWll-L or a
KWll-P clock, SAVE first checks for the clock for which the system was
generated.
If this test fails, SAVE attempts to start the other type
of clock.
Therefore, it is possible to boot an RSX-110 system that
was generated and saved on a configuration with a different type of
clock.
As described in the next section, SAVE performs a number of
memory size checks and adjustments before it exits. This checking can
be inhibited by applying the /NOXT switch to the SAVE command.
As mentioned in section 5.4.3, when the system is booted SAV has to
translate the file-id stored in the saved image for each installed
task and shareable global area and the checkpoint file
into an
absolute disk address. Normally this process is not apparent to the
user, except that it may take up to several minutes.
If hardware
errors are detected while reading the disk or if task files have been
deleted SAV recovers the system as far as possible.
Unless the offending block or file is one of a small number of
The error messages
critical ones the system will still be runnable.
which may be produced are described in Appendix A of the RSX-llD
User's Guide.

5.5

MEMORY ALLOCATION AND USAGE

This section provides additional information about the way in which
RSX-llD allocates and uses memory.
It also provide~ some guidelines~
for the choice of partitions and their sizes.
The initial memory size is specified to phase 1 of system generation
by means of the PDPll directive. This quantity establishes the size
of the save file and, consequently, the amount of system memory that
can be saved and booted.
The maximum length of the save file is 124K words.
If the hardware is
a PDP-11/70, the system can be generated for up to 1920K words.
Phase
1 of system generation accounts for the fact that the hardware is a
POP-11/70 with more than 124K. Regardless of the hardware, however,
the save file cannot exceed 124K words.
The size of the system components
{bootstrap, Executive,
SCOM
communication region and SCOM subroutines) is determined by phase 1 of
system generation from the bootstrap symbol table file on the target
disk.
The STB file contains all global symbols of the Executive and
5-12

ADDITIONAL SYSTEM GENERATION INFORMATION
the bootstrap. If the user intends to specify base addresses for all
partitions, this STB file should be examined by obtaining a task build
map with only the STB file as input. The following symbols provide
the necessary sizes.
.BO.ND

Bootstrap size

.SG.EX

Size of Executive

.SG.BE

minus

.SG.BC

Total size of SCOM communication region
and subroutines excluding the node pool

Once these sizes are obtained, base addresses can be assigned
wasting memory.

without

If the user does not specify base addresses, phase 1 performs all size
calculations and positions all components optimally to avoid wasting
memory. Memory is allocated from location zero upward. The amount of
memory available for partitions is the initial specification in the
PDPll directive minus the total lengths of the bootstrap, Executive,
and SCOM. The length of SCOM is user-defined and consists of the node
pool, communications region, and subroutines.
When base addresses are not specified, the partitions are allocated by
phase 1 in the order that they are specified to phase 1. The size of
all partitions except one must be specified. One partition can be
given a partition size of asterisk
(*).
Phase 1 computes that
partition's size from the memory remaining after memory for all other
partitions is allocated. The asterisk has no effect on the base
address of the partition. It only affects its size and, consequently,
the base address of all succeeding partitions.
The asterisk can be used with the specification of
The resulting partition size is the difference
address of this partition and the next.

base addresses.
between the base

During phase 1, the bootstrap, Executive, SCOM, system disk handler,
and phase 2 of system generation are written into the save file on the
target disk. Since the save file has a maximum length of 124K words,
phase 1 ensures that all are positioned below the 124K boundary when
generating a PDP-11/70 system with more memory.
RSX-llD requires a
minimum of two partitions: one for the system disk handler and one
for the phase 2 task. Depending upon the application for which the
user has chosen RSX-llD, these two partitions may be sufficient. Then
the system consists of a user-controlled system disk partition and a
system-controlled general
(GEN)
partition using all the remaining
memory.
Partitions are used to provide areas of memory that can guarantee an
acceptable
response time to requests for tasks.
However,
the
existence of too many infrequently-used partitions can result in the
wasting of memory for long periods of time. Partition design involves
trade-offs among the following desirable goals:
•

Fast response to task initialization,

•

Maintaining a high level of memory usage,

•

Minimizing memory fragmentation in multitask partitions,

•

Minimizing the possibility of frequent checkpointing of low
priority tasks that are compute bound in a partition where
high priority tasks must run,

5-13

ADDITIONAL SYSTEM GENERATION INFORMATION
•

Maintaining a fast response for all terminals,

•

Maintaining high throughput for all file activity.

The choice of relative partition sizes depends on the application
environment.
In particular, different partition sizes are chosen in a
system with many terminals than in one with a predominantly process
control environment.
After an RSX-llD system generation, the system is saved in the image
file as described in Section 5.4.3. SAVE is the task that is resident
in a saved system and is the task that initiates a system restart.
SAVE has the capability of adapting the system size to match that of
the machine on which the system is run.
If the machine is a
PDP-11/70, SAVE interrogates a register that defines the amount of
memory available. On all other machines SAVE determines the system
size by actually testing memory in lK increments, starting at 32K.
SAVE attempts to expand or truncate one or more partitions to reflect
the available memory.
Automatic expansion and truncation can be
inhibited by using the /NOXT switch in the SAVE command.
Memory expansion is the simpler process.
In this case, the size of
the
last partition in memory,
that is,
the highest addressed
partition, is increased by the value of the expansion. If the highest
partition is a system-controlled partition, the last hole pointer in
that partition is updated to re~lect the new size of that hole.
To make effective use of the expansion facility,
the last partition
should be a system-controlled partition.
If the expanded partition is
a user-controlled partition, only one task can be active in it at a
time regardless of the expanded size.
If the memory size has decreased, SAVE attempts to truncate one or
more partitions starting from the highest end of memory.
It is
impossible for this process to be successful in the following
circumstances:
1.

Any occupied partition reduces to zero size,

Any truncation
partition,

The truncation of an occupied system-controlled partition is
so extensive that a previously allocated area of memory no
longer exists.

occurs

occupied

user-controlled

In summary, any amount of truncation can occur in the unoccupied part
of a system-controlled partition and in an unoccupied user-controlled
partition, including truncation of the whole partition.

5-14

CHAPTER 6
TAILORING THE SYSTEM

Several system components can be modified to suit the particular nee6s
of an installation. The tasks which can be modified, and the ways of
modifyinq them, vary from release to release and are described in the
Release Notes. This chapter provides an outline to the subject.

6.1

EXECUTIVE CHANGES

In addition to the tailoring implicit in the system generation
process, it is possible to build the executive task EXEC.TSK in
different ways:
1.

A crash dump module may be included, to dump all of the
memory to a scratch device automatically if it crashes.
The
dump may be analyzed using the Core Dump Analyzer (CDA) ,
which is documented in Chapter 6 of the RSX-llD System
Manager's Guide.

Some executive modules may be replaced by null modules if
their function is not required.

These changes are described in the file
[ll,15]TKB15.CMD,
appears as an appendix to the RSX-llD System Manager's Guide.

6.2

which

UTILITY PROGRAMS

Many utility programs use the /INC facility of INSTALL to increase the
available space for symbol tables, buffer areas, etc.
In general
giving a larger value for the /INC option will make the utility run
faster or provide more space for data structures. There is a list in
the Release Notes of the tasks affected.

6-1

APPENDIX A
EXAMPLES OF SYSTEM GENERATION FILES

A.l

TERMINAL AND INTERFACE CONFIGURATION FILE,

[311,114]CONFIG.MAC

See Sections 2.4.1, 2.4.3

,.
1

S8TTL

TERMINAL AND INTERFACE CONFIGURATION FILf

I THIS FILE CONTAINS THE MACRO CALLS TO OlFINt iHE TERMINALS AND
I INTERFACES PRESENT IN THIS SYSTE~,
J•

J•

'
,''
'
,,''

''
,.''

AUTHOR

JOHN HARPER

uAT~

~o·JUL-76

FIRST DEFINE EACH INTERFACf PRESENT IN THE SYSTEM, IN THE FORMS
INTF

NUM8ER1TYPE,A00RfSS 1 VECTORC,EXTRAJ

NUMBER

INT~RFACE NU~BER, STARTING AT ZERO,
INTERFACE ZERO ~UST
ALWAYS BE T~E CONSOLE DL11,
Ty PE
IS THE INTERFACE TYPE <E,G, 1 0L•, 1 0~'>
AOORf SS IS THE EXTERNAL PAGE ADDRESS OF THE INTlRf ACf
VECTOR IS TME INTERRUPT VECTOR ADDRESS
EXTRA
IF PRESENT CONTAINS INTERFACE DEPENDENT INFORMATION:
DL
NON•ZERO If OL11E
OH • INTERFACE NUMBER OF ASSOCIATED OH11, IF ANY, OlHtRwISE
BLANK, THE OM MUST PRECEDE THE OH, ANO MUST ~OT
NOT BE INTERFACE ZERO,
DC
1 FOR DC11AA, 2 FOR DC11AB, ETC, 0 FOR DC11AX

INTf
lNTF
lNTF

l~Tf
I~TF

lNTF
INTF

e,o~,177560,060

l1DH1160020,340
2,DM,170500,310
J,DH,160040,350,2
4,DL,17~610,l20,1

5,0J,160010,JJ0

6,0~,176500 1 300

A-1

EXAMPLE OF SYSTEM GENERATION FILES

A.2

SYSTEM GENERATION PHASE 1

See Chapter 3.1

,.
I

'
'''
'''
''
'
''
'
''
''
',.'

NOW DEFINE fACH TERMINAL IN THE SYSTEM, USING:

TERM

NUMBER,1NTNUM 1 SUBLINE,TYPE,<SPEED>,<01ALUP> 1 <<CHAR>>

NUMBER
lNTNUM

IS THE TERMINAL NUMBER STARTING AT ZERO
IS THE ~UMBER OF TH~ INTERFACE TO WHICH IT IS l.ON~ECT~D
SUBLI~E IS THE SUBLINE ON THE INTERFACE (BLANK fOR NON•MULTIP~E~CR
JNTE~FACES, E,G, OL11)
TyPl
IS TME TERMINAL TYPE, OUT OF1 ASJJ, KS33, ASJ5, LJ0S,
L30P, LA36, VT05, VT50, VT52, VT55, VT61,
SPEED
(MUST BE IN BRACKETS IF PRESENT) IS EITHER ONE VALUE FOR
SINGLE•SPEED TERMINALS OR <KEYROARO SPEED, PRINTER SP~ED>
fQR SPLIT•SPEEO TERMINALS,
DIALUP IS EITHER BLANK FOR NON•DIALUP LINES QR '<DIALUP>' FOk
DIALUP LINES
<<CHAR>> IS A LIST OF CHARACTERISTICS (BRACKETTED PAIRS THEMSlLVES
ENCLOSED IN BRACKETS) WHICH ARE NOT STANDARD FOR THIS
TERMINAL TYPE, FOR A LIST OF THESE CHARACT~RISTICS St~
DEVICE HANDLER REF MANUAL CHAPTER 2 OR THE f ILE
[J11,114JTBLS,MAC
TERM
TERM
T~RM

TERM
TtRM
TERM
TERM
TE~M

TERM
TERM
TtRM
TERM
TERM
TERM
TE~M

TERM
TERM
TERM
TERM
TERM
TERM
TERM
TERM

0 1 0,,L4J6
1,1,0 1 VT50

2 1 11l1VT50

J,t,2 1 VT50

4 1 1 1 J 1 VT50
5,1,4 1 VT50
6,1,5 1 LJ0S
7,t,6,L30S
10,1,11L30S
11,J,0,AS33,,c01ALUP>
12,J,1,ASJJ,,cDIALUP>
13,J,2,ASJJ,,cOIALuP>
14,3,3,ASJJ,,cOIALUP>
15,J,4,ASJJ,,<DIALUP>
161J,5,A533,,co1ALUP>
11 1 J,6,VT50 1 J00
20,3,7,VT05
21 1 4,,LA36
22,5,01LJ0S
2J,5 1 11LAJ6

2415141VT50

25,5,5,VT50
26,6, 1 USR0,c150,1200>,,<cSCP,1>,cSMP,1>>

A-2

EXAMPLE OF -SYSTEM GENERATION FILES

A.3

SYSTEM GENERATION PHASE 2

See the beginning
[ll,17]SYSBLD.CMD.

Chapter

and

Chapters

4.13,

l11,11]RK05L.48tc.,CM0

COMMAND FILE FOR GENERATING A 48K RSX110 SYSTEM ON AN 11140
wITH A LINE CLOCK, WITH DK~: AS SYSTEM DISK

P0Pll•ti0148K
I

SCOMs,300 1 96

PARsSYOISK, 1 37,U
PAR•~CR11411S

PAR•GEN11•1S

DEV•DK0,RK05
OEV•OK1,RK05
DEVaOP0,RP0JB
DEV•OB0,RP04
OEVaOM0,RK06
OEV•TT0,CONSOL.
OEVaLPB1LP11B

DEV•OT0,DT11
Df V•DTl 1 DT11
DEVOT01 Tu1e
·0Ev11MM0, Tu 16

DEV•MO
DE Va SP
I

DPAR•GEN
ShD1<a
I

lNS.SYDISI<, t1l11l DI<

INS.GEN, [ 11 1 l SVSRES/L JI ACC•RO

JNSaGE~o t11ll TTLIBA/Ll

!NS.GEN, [1,1JTTLIBB/Ll
lNS.GEN1t1111l TT
JNSaGE~, t11, 171 SGN2, r11, tJ ~ou, c11, 1 J INS1u1c• tl, 1 J, r11, ll FCP

A-3

5.3

EXAMPLE OF SYSTEM GENERATION FILES

[11,17JSVSBLO,CMD

--------------·····-·~·---~--~···
INPUT FILE TO SVSGEN PHASE 2,
ANY MCR FUNCTION IS ALLOWED
EXCEPT SAV ANO BOO,
CA~E MUST BE TAKEN THAT A~Y TAS~
REQUIRED BY SG2 HAS BEEN INSTALLED BEFORE SG2 TRIES TO
USE IT,
NOTE1
........

'
'

SYSTEM GENE~ATION PHASE2 C"SGN2") IS INSTALLED AND
LOADED BY SYSTEM GENERATION PHASE 1 C"SGN1"l SUCM THAT
BOOTING THE NEW SYSTEM DISK RESULTS IN THE RUNNING OF
SGN2,
.
SGN2 PERFORMS THE

FOLLO~ING

~UNCTIONS

AUTO"ATICALLYI

(1), CHECK THERE IS SUFFICIENT MEMORY

(2), CHECK THAT SYSTEM DISK HANDLER IS ACTIVE

,
1

CJ),

(4), REQUEST THE TERMINAL HANDLER C"TT,,,,")

PIC~

THE SPECIFIED NODES FOR TERMINAL ISR

(5), CHECK THAT TT,,,, BECOMES ACTIVE

'
J'
'II

(6), MOUNT THE SYSTEM DISK

I
I
I
1

0'), OPEN FOR READ (THIS) FILE, SVat11'17JSYSBLO,CMD

SGN2 ASSUMES THAT THE FILES•l1 ANCILIARV CONTROL PROClSSCR

("FllACP") MAS BEEN INSTALLED AS WELL AS TT,,,., MOUNT C" 1 , 1 MOU")
I~STALL

THE TASK

TER~lNATlON

NOTIFIER C".TKTN,")

INS t11r1JTKTN
J

1
I

1
I
1

INSTALL

~CR,

THE COMBINED MCR FUNCTION TASK C",,,MFT"l
ANO THE MCR ERROR TASK
fQR SYSTEMS WHICH RUN THE LARGE TERMINAL HANDLER (TTl INSTEAD
OF TT01, MCR SHOULD BE INSTALLED USING1
INS [11,1JTTMCR/U1C•t1,1]

INS fl111JMCR/UlC•t111l

INS r11,1JMrT
INS

'
''
''

I
I

[11,1JMCRE~R

......
NOTE I

ALL THE ABOVE FUNCTIONS MUST BE PERFORMED AS SHOWN, ANY
MODIFICATIONS S~OULD BE MADE BELOw,

I
1

THE TASK ACCOUNTING UTILITY TASKS

INS t 111 1 J AC CLOG
INS r111 1 J ACCRPT

INS [111 l] ACCOFf
C1111JALCA8T

INS

A-4

EXAMPLE OF SYSTEM GENERATION FILES

'
MCR FUNCTION TO OUTPUT THE ACTIVE TASK LIST
' r1l11JACT
INS

1
J
J

THE BAD BLOCK DETECTION UTILITY ".,,BAD"

'INS r111lJBAO
'J
'INS f1l11JBAT

NOW ThE BATCM SYSTEM

INS Ul11JBPR

MCR FUNCTION FOR BOOTING SYSTEMS
BLOCKS

A~D

WRITING BOOTSTR•P

'INS r1l11JBOO
THE LOGGING OFF MCR FUNCTION
'J
'INS r1111JBYE
'J
THE CRASH
ANALYSER
DU~P

INS r111lJCOA

THE FILE COMPARE UTILITY

'INS [1111JCHP
'IJ
THE GLOBAL CROSS REFERENCE TASK C"CRF,,,") REQUESTED BV
,,,TKB WHENEVER /CR IS SPECIFIED ON A MAP
,,,MAC WMENEYER /CR IS SPECIFIED ON A LISTING

THERE ARE TWO VERSIONS OF CROSS RE~ERENCE •w
1) OVERLAVED
INSTALLED BY
INS t11 1 llCRF
2) UNOVERLAYEO THIS HAS TO BE BUlLT USING COMMANU
FILES SUPPLIED ON THE AUXILIARY MtDlA
UNDER UFO [11 1 23] 1 wl-IEN BUU.T, IT IS
INSTALLED BV
INS [1l,1lUNOVRCRF

J
I
J
I
I

'I
'I

BOTH VERSIONS

~AVE

TASK NAME "CRF,,,"

THE EXECUTION TIME OF THE BOTH VERSIONS MAV BE
DECREASED BY ALLOCATING MORE CORE SPACE AT INSTALL
TI~E USING T~E IINC•NNNNN SWITCH. NNNNN MAY B~ ANY VALUE
FROM 0 TO 19000 APPROX FOR t11,1JCRF
(DEFAULT•~)
FROM 0 TO 20000 APPROX FOR c11,11uNOVRCRF COEFAULT•16000)
~IGHER VALUES GIVE FASTER EXECUTION

J
I

,
I

INS r11,1JCRF
I

THE

ME~ORY

USAGE DISPLAY CVT05

O~LY)

TAS~

",,,O(M"

'INS r11,1lDEMO
'
1
THE AVA1LA8LE DISK HANDLERS ARE 4S FOl..LOWS1
'INS
FOR RK•11 (RK03, fH<05) DEVICES
' [1111JDK
FOR RK•tl
OVERLAPPED SEEKS ON
'
HUL.TIPLE nRIVES1
I

~ITH

INS t1111JOKOVL
1~S

f 11 , 1 l OF

FOR RF•11 MULTI PLATTER FIXED HEAD DIS!<SI
FOR RP•tlC

CRP!a~1RP03)

A-5

DEVICt:S1

EXAMPLE OF SYSTEM GENERATION FILES
1
I
1
I
I

,
''
,'
,''
''
'''
'''

1
I

J
1
I

1
I

l~S

C11,1JDP

INS Cl111lDB

FOR RP04

~ASSBUS

OISKSa

FOR RS03, RS04 MASSBUS FIXED MEAO OISKSI

l NS r1 l ,1 J DS
FOR RK611

(R1<06) OISl<S

INS (11,1]0M
ANO THE DIAGNOSTIC ECIUIVAL.ENTSI

INS [11121]01<0

INS

£11,211 OPO

lNS C11,27J OFC
INS

01127] DBD

lNS

u1,211oso

INS

Ul,21JD~D

ONE O~ THESE WILL BE TME SYSTEM DISK H~NOLER ALREADY INSTALLED

A~O LOADED BY SYSGEN PHASE i. IT IS INAPPROPRIATE TO
ASSUME HERE WHICH IS THE SVSTEM DISK OR WHICM ADDITIONAL DIS~
DEVICES A USER WISHES TO USE. THEREFORE SELECTION OF FURTHER
OlSK H4NOLERS 'OR lNSTA~LATlO~ IS LEFT TO THE USER.

AN~ OF THE ABOVE MAY BE INSTALLED SIMPLY BY EDITING THIS FILE TO
DELETING THE "J" ANO TAS PRECEDING THE FILE SPECIFICATION,

''J
THE DISMOUNT VOLUME MCR FUNCTION
' U11lJDMO
INS
'
THE 'lLE OUMP MCR UTILITY
J

'INS U1,1JDMP

'I
'I

'
'

THE F~OPPV OISK HANDLER
INS

(11,lJDX

THE DECTAPE HANDLER

ALTERNATE a
·---····-~

LINE TEXT EDITOR CLETTER) ",.,EDI"

'J
THE DlAGNOSTIC MANDLERI
'
1
INS flt121JDTD
,'INS f11,lJDT
'1
ADOl!IONALI
'
·-·~--·-···
'1
FOR THE SLIPR £D!TORI
1
INS [11,1JSLP
'INS Cll11JEOI/PRI•60
THE
ERROR LOGGING TASK USED IN CONJUNCTION
'
WITH ERROR LOGGING
HARO~ARE

~A~DLERS.

A-6

EXAMPLE OF SYSTEM GENERATION FILES

'INS r1111 JERRLOG

THE FILE INTERCHANGE UTILITY (TO ANO FROM Dos,

RT~11,

~STS

SYSTE~S)

'INS r1111JfLX/PRI•55

'
I

FlLlS•11

~ESSAGE

OUTPUTTING

TAS~

' (11,1Jf'11MSG
,INS
I

THE LOG ON MCR FUNCTION

INS U111JHEL

I
I

'lL~l•11

VOLUME INITIALIZATION MCR fUNCTION

?NS rU,lJlNI
I
I

THE LIBRARIAN (RELOCATABLE OJECTS AND RANDOM ACCESS MACROS>

'
'I

LINE PRINTER HANDLER

INS U111lLBR
I

INS rU,1JLP
I
I

INS
I
I

THE LOQICAL UNIT INFORMATION MCR FUNCTION

ru, 1JLUN
THE MESSAGE OUTPUT (PSEUDO) MANDLER MO,,,,

INS Ul11lMO
I
I

THE MEMORY EXAMINATION AND PATCH UTILITY

'I NS r 111 1J OPE
I

THE OPERATOR'S SPOOLER CONTROL MCA FUNCTION

'I NS U 1, 1 JQPR
I
I

INS

TH£ 'lLES•ll PERIPHERAL AND FILE INTERCHANGE FUNCTION
r1t11JPIP/PRI~55

'I
THE POOL USAGE DISPLAYING UTILITY
' t1 t, lJ POOL
INS
THf ONLINE PRESERVE UTILITY ",,,PRE"
'
I' NS r 111 1J PRE
'
THE VERSIONS 0' THE MACR0•11
I

AS~EMBLER

I
I
I

INS [1l 1 1JMAC

ARE AS FOLLOWS1

FOR SMALL1 HEAVILY OVeRLAYEO TAS~I

I
I

FOR THE LARGE, UNOVERLAYEO ASSEMBLER TASKS,
TASK BUlLO COMMAND FILES ARE PROVIDED ON TME AUXILIARY MEDIA
UNDER UFO t11 1 10J TO BUILD Tl-'Erii,

'
I

E11110lMACBLD,CHD BUILDS t1111JMAC,TSK, THE OVERLAVEO VERSION,

[11,101PuPMACBLD.CMO BUILDS r1t,tJ?URMAC.TSK, THE UNOvERLAV~D

A-7

EXAMPLE OF SYSTEM GENERATION FILES
I

'I
'I
1
I
I
I

'
I
I

VERSION.
ALL HAVE THE TASK NAME ",,,MAC"
TME EXECUTION TIME OF TMESE ASSEMBLERS MAY
BE DECREASED CONSIDEAABLV WHEN T~E NUMBER OF SYMBOLS IS LARGE
By ALLOCATING THE ASSEMBLER MORE CORE RESIDENT ~ORK SPACE,
THIS MAV BE ACHIEVED BY INSTALLING T~E TASK USING THE
"IINC•NNNNN" SWITCH O~ THE COMMAND TO INSTALL,
TMIS IS
RECOMMENDED If IT IS NECESSARY TO ~E•BUILO THE TERMINAL MANDLER
TASK (TT,,,,), THE VALUE FOR 1 NNNNN' MAY BE
0 TO 15000 'APPROX) FOR Cll,1J~AC
CDEFAULT•8192)
8 TO 12000 (APPROX) 'OR Cll,tJPURMAC
CDEFAULT•12000)

I
'INS
r1lr1JMAC

FOR THE SMALL, OVERLAVEO TASKS

FOR A LARGER, FASTER, OVERLAYED TASKI

•INS t11,1JMACIINC•15000

'OR THE FAST, LARGE, UNOVERLAYEO TASK:
JINS tllr1JPURMAC/INC14000
J
FOR THE FASTEST, LARGE, UNOVERLAYEO TASKI
IINS t11,1JPURMAC
J

'I
THE MCR FUNCTION FOR INSERTING PASSWORDS INTO SPECIFIED UF0 S
ON
SVSTEM DISK,
'INS U 1,l J PWD
'I
THE MCR FUNCTION TO QUEUE A FILE FOR OUTPUT
' Ul1llQUE
INS
'I
THE LOGICAL
REASSIGNMENT FUNCTION
1

T~E

U~IT

INS UlrlJREA

'I
THE DEVICE REDIRECTION MCR FUNCTION
'INS U 1r1 J
'I
THE MCR FUNCTION FOR REMOVING TASKS AND SGA•S
~ED

INS U 111 l RE~

THE TASK RUNNING MCR FUNCTION

'
'
THE SYSTEM SAVING AND RESTARTING MCR FUNCTION
' fl111JSAV
INS
THf SYSTEM PARAMETER SETTING MCR FUNCTION
,'I
INS f 11r1J RUN

INS r1111JSET

'
'

THE SPOOLER TASK "SPA,,,"

INS fl 1. ll SPR
I
I

?N~

THE OESPOOLER TASK "SPR2,," SET FOR 1 DEVICE, INCREMENTS OF
463 WORDS SUPPORT ONE MORE DEVICE
t1111JSFR2/INC•460

A-8

EXAMPLE OF SYSTEM GENERATION FILES

THE SYSTEM INFORMATION MCR FUNCTION

INS

Ul1llSYS

THE ON•LINE TERMINAL CHARACTERISTIC CHANGING FUNCTION

' f11,1JTER
THE TIME SETTING ANO ENQUIRING FUNCTION
'I
' f1111JTIM
INS
THE LINKER (TASK BUILDER)
'I
'II
THERE ARE TWO
OF TASK BUILDER ••
1) OVERLAYEO
INSTALLED BY
INS

VE~SIONS

I~S

2) UNOVERLAYED

I
I
I
J

'J
'J

BOTH VERSIONS HAVE TASK NAME ",,,TKB" ,
THE EXECUTION TIME OF THE OVERLAVEO VERSION MAY BE
DECREASED BY ALLOCATING IT MORE CORE SPACE AT INSTALL
TI~l USING THE /INC•NNNNN SWITCH, NNN~N MAY BE ANY
VALUE FROM 0 TO 120~0 APPROX, MIGHER VALUES GIVE
FASTER EXECUTION,

J
J
J

' r11 1JTKB
'J
THE MAGTAPE HANDLER,
'J
ALTERNATES&
'
··--·--···
'
INS ru,1JTU16
INS

"M~••••"

FOR TJU16 MASSBUS CONTROLLER;

ANO THE DIAGNOSTIC VERSIONS

[ll1lJT~B

HAS TO BE BUILT USING COMMAND
FlllS SUPPLIED ON THE AU~IlIARY MEDIA
UNDER UFO U 1, 111, wHEN BUILT 1 IT IS
tNST ALL ED BY
INS t 11 d J UNOVRTKB
T~IS

INS t11r21JTU16D

"MT,,,," FOR TM•ll TU10 DEVICESt

INS cu,lJTUteJ

'J
AND ITS DIAGNOSTIC VERSIONS
INS C11127lTUUD
I'
THE USER fILE DIRECTORY CREATION MCR FUNCTION
' f1l11lUFO
INS
'1
THE Of VICE HANDLER UNLOADING FUNCTION
I

INS f1111JUNL

THE FILES•ll SYSTEM VERIFICATION MCR FUNCTION

INS f1l1lJVFY

THE TERMINALS IN USE O?SP~AY UTILITY " 1 ,,WMO"

INS f1111JWHO
J

J
J

INS

THE FILE PATCH UTILITY ",,,ZAP"
fl11llZAP

A-9

EXAMPLE OF SYSTEM GENERATION FILES

'
I
I

THE SPOOLER USES A PSEUDO DEVICE SP; FOR QUEUING AND
6UFFERING, THIS DEVICE MUST BE REOIRECTEO TO SOME RANDOM
ACCESS FILES•ll DEVICf WITM A UFO [1,4l/PRO•[RWE0 1 RWE01R~E01RWEOJ

ASSUME HERE THAT IT IS
'
RED
' sv•SP
I

•I

SYSTEM DEVICE.

AfTER SGN2 HAS PROCESSED ALL THE COMMANDS IN THIS FILE
IT WILL THE~ PROCEED TO ALLOCATE THE CHECKPOINT FILE CtF
AND AS) SPECIFIED DURING PHASE la

I
J

T~E

NOTE 1.1

···----~ THE DEVICE TO WHICH CHECKPOlNTEO TASKS A~E TO BE WRlTT£N
MUST HAVE ITS HANDLER RESIOENTJ MUST SE INITIALIZED AS A

'
I
I
I
I
I
J
I

'
I
I

I
I

I
1
I
I

I
I
J

'II
'

FILES~11 VOLUME AND MUST 8E MOUNTED FOR SGN2 TO CREATE THE
CHECKPOINT FILE1
THEREFORE IF IT IS A VOLUME OTHER THAN THE SYSTEM DEVICE
INSERT THE APPROPRIATE INSTALL1 LOAD AND MOUNT COMMANDS IN
THIS FILE,
DIRECTIVE,

NOTE 2,1

·-:----~ AFTER SGN2 COMPLETES, TME USER SHOULD LOG ON TO TME SYSTEM,

PERrORM THOSE FUNCTIONS DEEMED DESIRABLE AND T~EN SAVE THE SYSTEM 1

TYPICAL POST SGN2 FUNCTIONS AREi
LOA ~O
I LOAD MO HANDLER
LOA LP
I LOAD THE LINE PRINTER HANDLER
RED LP•CL
I LINE PRINTER IS CONSOLE LISTING DEVICE
REA ,,,TKB 8 OS
1 REASSIGN THE WORKFILE LUNS OF
REA CRF,,, 1 DI
I TKB, MAC ANO CR' TO
RtA ,,,MAC 8 DI
1 A 'lXED HEAD DIS~,
TIM HHIMMISS DD•MMM•YY 1 !NTER TlMf ANO DATE
RUN ACCLOG
I RUN THE ACCOUNT LOGGER
ALTERNATIVELY, TH18 'ILE MAY 8[ EDITED TO

INCORPORATE THESE COMMANDS,

A-10

APPENDIX B
DEVICE CHARACTERISTICS WORDS

1
J
I

THIS MODULE CONTAINS&

1 ~· CODE fOR DVSCH,

,PAGE

,'
,,'
,,,
,,
J

1SBTTL

MACRO TO GFNERATf AN ENTRY IN THE DEVICE CHARACTERISTICS
TABl.E,
MACRO FOFH1A TI

DEVCH

NA~~1AC11AC2,AC3,AC4,ACP,BNAM,VSIZH 1 VSIZL 1 VECT,PRI,CSR

WHERE1

NAME

ACt
AC2
AC3
AC4

''
,''
,,'
,'
''
''
''
',''

OVSCH •~ THE DEVICE CHARACTERISTICS MACRO

• DEVICE NAM£ STORED AS TW0 RA050
WORDS,
(DEV, lNDEP,)
• PUD CMARACTEAISTICS WORD
DEPEN,)
COEV,
2
•
" J
"
CDEVeDEPENe)
•
" 4
"
(TXFR, SIZE)
•
"
"

CFOR DEFINITION 0, THE ABOVE1 SEE EXECUTIVE AND APPROPA IA TE
DEVICE MANDL.ER)
ACP
BNAM

VSIZ~

VSIZL

VECT
PRI
CSR

• DEFAULT ACP 'OA THIS DEVICE
FOUR ASCII CHARACTERS WHICH
IDENTIFY TME BOOTSTRAP
PROGRAM,
C2 ZERO WORDS FOR NON•BOOTABLE
DEVICES)
• HIGH ORDER PART OF VOLUME SIZE
FOR DIRECTORY DEVICES,
(ZERO FOR OTMERS)
• LO~ ORDER VOL, SIZE
• DE,AULT VECTOR ADDRESS
• DE,U4LT ~RIORITY
• DE,UALT CONTROL/STATUS REGISTE~ ADDMESS

,MACAO

DEvtH

ANAME,AC1,AC2,ACJ,AC4,ACP,BNAM,ySIZH,vSIZL1VECT,PRI,CSR,tZ

t fUDS0

I ANAM~/

1WORD
1WORO

AC2

,•Z••

.~ORO
.~ORO

1lIF
1 lif
elif
elif
1IIF

1IIF
eIIF

1Ilf

ACl

ACJ

AC4
~B

OCP•

dCP•

NB cBNAM>
B dtdM>
NB -cVSIZM>
e cVSIZM>
NB cVSIZL>
B ~VSlZL.>

,RAD50
,WORD

IACPI
0

, ASCII
, BLK\11

,WORD

IBNAM/

\ISIZM

,tiORO
I liwORO

.wo~o

\ISIZL
B-1

DEVICE CHARACTERISTICS WORDS
.XIF
1IIF
1 lIF
1IIF
• IIF
, IIF

LNG

NB <eVEC: T>
B

NB cF'RI>
B cPRb
NB <CSRll
8 <CSR>

.... z

It.ENG TM

, SBTTL.

DVSCH •• STANDARO

Of.FINE THE DEVICE

DEVCH
DEVCH
OEVCH
DEVCH
OEVCH
DEVCH
Of VCH
DEVCH
DEVCH
Df;VCH
DEVCH
DEVCH
DEVCH
D~VCH

DEVCH
DEVCH
DEV CH
DE.VCH
DEVCH
DEVCH
DEVCH
OE.VCM
DEVCH
DEV CH
DEVCH
DEVCH
DEVCH
DtVCH
DtVCH
DtVCH
DEVCH
OEVCH
DEVCH
DtVCH
OtVCH
DEYCH
Df VCH
DEV CH
DEVCH
DEVCH
DEVCH

,IF OF IAS
DEVCM
DEVCH
,ENOC

DCHENI

VECT
0

PRI
0
CSR
Pl

CHARACTERISTICS TABLE

1ENO~

.P4GE

DCHSTI

,WORO
,wORO
,WORO
,WORD
,WORD
,WORD

cVECh

DEVCH
DEVCH
DEVCH
OtVCH
DEVCH

SUPPO~TED

CHARACTE~lSTICS

DEVICE CHARACTERISTICS

TABLE

PTR,40,0 1 0 1 1000,,,,,70,4,117~50

PTP,40,0,0,1000,,,,,14,4,111554
RK03,140010,21000 1 1014,512, 1F11 1RK05, 14800, 1220,5 1 177400
LP114 1l,0 10 180,,,,,,200,4 1 111514
LP11B 1 J,0 1 0 1 1J2 1 ,,,,,200,4,111~14

LP11wu,J,0,0,1J2,,,,,,200,4,t775t4
LP11WL1J1l101132,,,,,,200,4,t77514
LP11NU,J,0,0,a0,,,,,,200,4,111s14
LP11NL 1 J,1,0,e0 1 ,,,,,200,4,177514
Ls11wu,J,2,0,132,,,,,,200,4,1775t•
LSllwL,J,J,e,1J2,,,,,,200,4,171514
LS11NU,J,2,0,a0,,,,,,200,4,111514
LS11~L,J,J,0,a0,,,,,,200,4,t77514

DT111140010 1 4060,401,5t2,,F1111 1 !78,,214 1 6,171J40
AF11,0,102J,,0,0,,,,,t34,4 1 172570
A001 1 01100,0,0,,,,,1J0,6,176710
LPSl 110, 16,, 0 1 0
uoc11,0,0,e,0,,,,,2J4,6,111000
RK05114001011060110141512,,F111RK05114800 1 1220151177400
RK05F 1 140015,41060,10141512,,F11 1 RK05,,4S00,,220,~,177400

RP02,140010 1 41460,12012 1 512,,Ft1,RP03,,40000,,254 1 5 1 176710

RP0JA 1 1400101101460,120121512,,Fl11R~03 1 1 1 34200 1 254,51t76710

RP0JB 1 140010,141460,t2012 1 512,,F11 1 RP0l,1 1 34200,254,51116110
RF11140010r4001101512 1 1Fll1RF11111024,,204,51171460
RF211400101204001101~12,,F111RF11 1 ,2048, 1 204,51177460

RF3 1 140010,40400 1 10 1!12,,F111R,11 1 ,3072,,204 15,177460

RF411400l0160400,101512,,F111RF11 1 ,4096,,204151117460
RF5,140010,100400,t0,5t2,,,11,RF11115120,,204,e,1114e0
RF6 1 140010, 120400, U,512, ,F 11 1 RFU, 1 6144, 1 204 1 '5 1 171460
RF711400101140400,t015t2,,,111RFll111168,,204,'5,t71460
RF8,t4001011604ee,10,e12,,F1t,RF11118192,,204,5,11146B
CR11,1,~,0,80 1 ,,,,,2J0,6,177l60

co11,1,0,0,e0,,,,,,2J0,4,112•60
RP04,140010,2060,ll426,512, 1 F11 1 RP04,2,t17426,254 1 5,176700
RP0S,140010 122060 1 11426,512 1 rF11 1RP04 12,117426,254,5,176700
RP061140010,42060rl14261512 1 1Fll1RP04,51030434125•,5,116100
RS03,140010 1 2400,l00,512,,,t1 1 RS04 11 l024~ 1 204 1 5,t72040

RS04,140010,22400,100,s12.,F11,Rs04,,204a,,204,5,112040
TU10r14~070,0,01512,,MTA,,,,224,~,172520

TU16,140010 1 100000,0,512,,MTA 1 ,,,224,5,112440
T4ll1100010,0 1 0,128,,,,,,260,6 1 111500

BATCH,J,0,0,132,
PsEuoo,10000,0,0,0
RK06,140010 1 J160,1426 1 512,,F11 1 RK06,,27126,,210,5 1 177440
TERM,1,0101512,
CONSOL 1 7,0,0,512,,,,,,60,4,117560
RX011140010,2430,41515l2 1 ,F11,, 1494,,264,5 1 117170
,0,0,0,0

B-2

ERROR MESSAGES

During system generation, errors detected cause a message to be
printed on the console.
Phase 1 messages are preceded by a SGNl;
phase 2 messages are preceded by SGN2. System generation produces
three types of error messages.

Diagnostic messages -- These messages are informative and do
not result in termination of system generation.
The user
should not force termination if a diagnostic message is
printed. Diagnostic messages are prefixed as follows.
SGn -- *DIAG*

Diagnostic message dependent on
console
input -- These
message are nonfatal if console intervention is possible.
If
input is from an indirect file, the error is declared fatal.

Fatal error messages -- These errors are not recoverable.
System generation terminates the current attempt to build the
system. Fatal error messages are prefixed as follows.
SGn -- *FATAL*

Error messages in this appendix are divided into one section for phase
1 messages and another for phase 2 messages.
Within each section,
messages are presented in alphabetic order.
For terminal handler configuration error messages see Section 2.4.5.

PHASE 1 ERROR MESSAGES

In the following section, the number associated with each message is
the internal message number within SGNl.
CANNOT REQUEST ••• INV

Failure of the REQUEST directive or corruption of the
communication data sent by SGNl to ••. INV (the special
version of INSTALL) has occurred.
If the latter is
true,
remove
and reinstall ••• INV and then try
rerunning phase 1.

DUPLICATE NAME
A device name or partition name has appeared more
once.

than

ERROR IN READING TASK IMAGE

An attempt to read a task has failed. The failure is
probably due to hardware errors on the device.

Messages-1

ERROR IN STD TABLE CONSTRUCTION

SGNl has failed internally.
ERROR ON COMMAND INPUT

A hardware failure has occurred on attempting
command input

read

EXECUTIVE CROSSES 124K BOUNDARY

The base address assigned to the Executive is such that
it does not reside completely within the save file on
PDP-11/70.
The Executive must be below the 124K
boundary to fit in the save file.
Reassign the base
addresses.
FAILED TO PICK VIRTUAL SCOM NODE

No more nodes available from node pool of system being
generated. Specify a larger SCOM size so that more
nodes are available.
FAILED TO REMAP GCD NODE ADDRESS

Indicates
an
internal
error
within SGNl while
converting the GCD nodes of the present system to the
addresses of the new system.
FP OPTION ILLEGAL FOR 11/35 AND 11/40

The FP field of the PDPll directive specifies the
presence of the FPll floating point processor.
This
option is not available on a PDP-11/35 OR 11/40.
To perform floating point calculations on a PDP-11/35
or PDP-11/40, the floating point instruction set
(FIS)
must be present.
The presence of the floating point
instruction set is not
specified
during
system
generation.
I-0 ERROR ON FILE filename

I/O error has occurred on reading or writing the named
file.
For example, the volume may be write-locked
during a write operation.
ILLEGAL CHECKPOINT DEVICE
The
checkpoint
DEV=directive.

device

was

defined

not

ILLEGAL ERROR -- SEVERITY number

SGNl has failed internally.
45

ILLEGAL MACHINE TYPE
The only CPU
types
supported
PDP-11/34,35,40,45,50,55 and 70.

RSX-llD

are

ILLEGAL MEMORY SIZE OR BASE ADDRESS

A system or partition size specification is larger than
that allowed on the specified CPU;

Messages-2

that

is,

greater

than 124K for a PDP-11/34,35,40,45,50,55 or greater
than 1920K on a PDP-11/70. Alternatively, a base
address specified is beyond the usable memory of a
system with the specified CPU type.
ILLEGAL MULTI-PARAMETER SETS

Muliple parameter sets have occurred
that permits only one parameter set.

directive

ILLEGAL 'sy' INPUT

This message can be caused by any one of the following
conditions.
Undefined device (no DEV command associated with it)
Invalid mnemonic
Device for which no bootstrap program exists (see
Section 5.4)
IMPROPER "@" FILE SPECIFICATION

File syntax specification incorrect.
INSUFFICIENT PARAMETERS

All the parameters required by the directive
been submitted.

have

not

INVALID ACP TASKNAME

The specified name of the file primitve tasks for this
device was not nnnACP;
i.e., the last three characters
are erroneous.
INVALID DEVICE TYPE <type>

Device type not recognizable. The device type is not
defined internally in system generation.
INVALID KEYWORD IDENTIFIER

Keyword in a directive cannot be recognized.'
INVALID PARTITION NAME

An attempt has been made
nonexistent partition.

install

task

INVALID PARTITION PRIORITY

The priority of a T partition must be between 2 and 200
(decimal).
INVALID PARTITION TYPE

Only user-controller (U) , system-controlled
time scheduled (T) partitions are acceptable.

(S) ,

and

INVALID SYSBLD DIRECTIVE

SYSBLD directive file specification contained device
name or was more than 31 characters in length.

Messages-3

INVALID TARGET DEVICE SPECIFICATION

A syntax error was made in specifying the target device
and filename.
INVALID TASK HEADER

Bad data was found
installed.
Possibly
Start phase 1 again.

in the header of a task INV has
a task has become corrupted.

MARK TIME OR WAIT FOR DIRECTIVE FAILURE
SGNl
failed
successfully.

issue

one

these

directives

MORE THAN 15 INSTALLS TO A PARTITION

No more than 15 tasks and/or Shareable Global Areas can
be installed in a partition during phase 1. This
message shows this limit has been exceeded.
MULTIPLE PARTITIONS WITH

* SIZE SPECIFICATION NOT PERMITTED

Only one partition can use the wild card memory size
specification.
Specify a partition size for all
partitions except one and retry.
MULTIPLE SYSBLD DIRECTIVES NOT PERMITTED
Only one SYSBLD directive is permitted.
additional SYSBLD directives and retry.

Delete

any

MULTIPLE TARGET DIRECTIVES NOT PERMITTED

Only one target device and filename specification can
be used. Delete any extra target specifications and
retry.
NO DYNAMIC STORAGE AVAILABLE

No
more
nodes
are available.
Indicates nested
generations may be required.
Thus, the user must
generate successively larger systems until he reaches
his target system. Alternatively, some running on or
installed tasks should be removed;
then try again.
NON-EXISTENT "@" FILE SPECIFIED

The indirect file specified cannot be found.

NO SPACE FOR POOL
SCOM size insufficient to provide for any pool.
NO TELETYPE HANDLER (TT •••• ) INSTALLED

After all the installs for phase 1 were processed, SGNl
found that no task with the name TT •••• was installed.
Insert the directive to install TT •••• in the phase 1
command file.
This message is a warning;
the system
is operable.
NO TELETYPE ZERO DEFINED CI, CO, AND CL NOT REDIRECTED

Messages-4

TT0 was not assign. CI, CO, and CL have no assignments
and should be redirected when the target system is
initiated.
OPEN FAILURE ON FILE filename

File cannot be opened.
The failure has occurred in
attempting to open EXEC.TSK, one of the bootstrap .TSK
or .STB files, or the system image output file.
Usually either the file does not exist, or no room
exists on the disk to create the output file.
OPTION LINE SYNTAX ERROR

A syntax error exists in a directive line.
OUTPUT I-0 ERROR ON FILE filename

An I/O error has occurred when writing the save file.
OVERLAP IN REAL ADDRESS SPACE

The base specifications and size specifications result
in a space allocation conflict.

POSITIONING ERROR ON FILE filename
This message indicates an internal
Contact local software support.

system

failure.

REAL MEMORY SIZE EXCEEDED
After summing memory requests, those requests are found
to exceed the amount specified by the PDPll directive.
SCOM CROSSES 124K BOUNDARY

The base addresses and sizes specified for the system
are such that SCOM cannot be contained completely
within the save file on a PDP-11/70. SCOM must be below
Reassign
the 124K boundary to fit in the save file.
the base addresses and/or adjust the sizes of the
components.
44

SGN2 CROSSES 124K BOUNDARY
Because SGl writes the system generation phase 2 task
out to the save file, which has a maximum length of
124K, SGN2 must reside below the 124K boundary in a
PDP-11/70.
Adjust the partitions or install SGN2 in
another partition.
STD/GCD ENTRY NOT FOUND FOR A TASK/SGA AFTER INSTALL

INSTALL has failed to create an STD or GCD entry.
INSTALL may issue a message in addition to the one
issued by SGNl. Alternatively, INV may not have run to
completion.
SY DISK HANDLER CROSSES 124K BOUNDARY
Since SGl writes the system disk handler into the save
file, which has a maximum length of 124K, the system
disk handler must reside below that boundary on a
PDP-11/70. Adjust the partitions or install the disk

Messages-5

handler in another partition.
SYMBOL NOT FOUND symbol

A symbol needed by SGNl cannot be found
in
appropriate bootstrap .STB file.
The file either
not been built or has been built incorrectly.

the
has

SYSGEN PHASE 2 NOT INSTALLED

After
all phase 1 installs were processed,
determined that SGN2 was not installed.

SGNl

SYSTEM DISK HANDLER NOT INSTALLED

No task with the name xy •••• was installed.
xy is the
device specified in the SY directive, which was valid.
See Section 4.2.5.
SYSTEM DISK NOT DEFINED,

'sy' NOT REDIRECTED

SY has not been defined explicitly.
Therefore, SGNl is
attempting,
by
default,
to redirect SY to DK0.
However, no such device has been defined by a DEV
directive; SY cannot be redirected.
TASK ••• INV NOT IN SYSTEM

SGNl requires the task ••• INV to operate but the task
cannot be found.
TOO MANY PARAMETERS

More than the allowable number
appeared in the directive.

parameters

have

VIRTUAL ADDRESS SPACE OF SCOM OUT OF RANGE
The size specified for SCOM makes the virtual starting
address less than 1000000; Administrator must reduce
the size of SCOM. The maximum size of SCOM is 12K.

Messages-6

PHASE 2 ERROR MESSAGES

ALL MEMORY SPECIFIED DOES NOT RESPOND
SGN2 attempts to initialize hole pointers in partitions
whose base addresses are beyond 124K on a PDP-11/70.
Memory access at one of these base addresses produced a
memory system timeout.
ASSIGN LUN ERROR
SGN2 cannot assign a LUN to SY.
CHECKPOINT FILE ALLOCATION ERROR
There is not sufficient contiguous space on the disk to
allocate the checkpoint file, the device has not been
mounted, or its handler is not loaded.
ERROR ON LOGGING DEVICE
Could not successfully log.
ILLEGAL FUNCTION FOR NON PRIVILEGED TERMINAL
The user must be privileged to run phase 2 of system
generation.
In fact, phasa 2 should only be run
automatically by performing the phase 1 procedures.
IO ERROR
An I/O error has occurred probably due to hardware
failure during creation of the checkpoint file.
MARK TIME ERROR
SGN2

has attempted a MARK TIME and the request failed.

OPEN ERROR ON SYSBLD.CMD
[ll,17]SYSBLD.CMD could not be opened.
OPTION LINE SYNTAX ERROR
A syntax error exists in an SGN2 directive.
READ ERROR ON COMMAND FILE
Command file cannot be read.
hardware errors.
REQUEST ERROR

This is probably

due

SGN2 has attempted to REQUEST a task and the request
failed for a reason other than not being installed.
TASK NOT INSTALLED
The task ••• MFT, which performs some of the MCR
functions,
is not installed.
It may be possible to
perform the installation after SGN2 completes.
UNABLE TO FIND ATL FOR SYSTEM DISK HANDLER
SGN2 searches the active task list expecting to find an
entry for the system disk. No entry is found which

Messages-7

suggests that the system disk handler has terminated
abnormally.
Progress beyond this point is impossible.
UNABLE TO FIND ATL FOR TERMINAL HANDLER (TT •••• )
SGN2 searches the active task list for an entry for the
task TT •.•• , but did not find one. It is possible for
phase 2 to complete, but no errors can be reported and
no communication can be established with the system
until a terminal handler is resident.
WAITFOR ERROR
A WAITFOR request has failed.

Messages-a

INDEX

Hardware bootstrap, 2-8
Host system, 3-1, 3-6

ACP, 4-8, 4-9

Bad blocks, 2-2
Bootstrap, hardware, 2-8, ·3-6
Bootstrap, software, 3-6
Bootstrapping, 2-1, 2-4, 5-7,
5-12
BP device, 4-11

/INC, INSTALL switch, 6-1
INS directive, 4-17
Installation of required tasks,
5-4

Memory allocation, 4-3, 5-12
MO device, 4-11

CI device, 4-11
CKPNT directive, 4-15, 5-4
CL device, 3-7, 4-11
Clock, 4-3, 5-12
CO device, 4-11
Communication interfaces, 2-13
CONFIG.MAC, 2-13, A-1
CPU specification, 4-3, 5-3
Crash dump module, 6-1

Node pool requirement for SGNl,
1-2, 4-5, 4-6

PAR directive, 4-5, 4-7, 5-3
Parameters, directive, 4-1
PARAMS.MAC, 2-13
Partitions, 4-7
PDPll directive, 4-3, 5-3
Phases 1 and 2, 1-1, 3-1, 4-1
Procedures,
Phase 1, 3-2, 5-2
Phase 2, 3-5
Pseudo-devices, 4-11
PSWD directive, 4-16, 5-4

*DELAY directive, 4-18
DEV directive, 4-8, 5-3
Device addresses,
BM792-YB, 2-9
BM873-YA, 2-10
BM8 7 3-YB, 2-11
M9301-YC, 2-12
MRll-DB, 2-8
Device information, 4-10, B-1
Device priority, 4-8
Directives, system generation,
4-1, 4-5
Directories, 2-4
Distribution disks, 2-1, 2-4
Distribution tapes, 2-1

RED, ~CR command, 3-7, 4-11
Required task installation, 5-4
RSXSYS, 2-3
RUN $, 4-14

Editing system generation files,
5-1
Error messages,
Phase 1, Messages-1
Phase 2, Messages-7
terminal handler, 2-21
EXEC directive, 4-4, 5-3

FllACP, 3-7, 4-17
Floating point option, 4-3

Sample system generation files,
A-1, A-2
Saving a generated system, 3-7,
5-10
SCOM directive, 4-5, 5-3
SCOM size, 4-5
SGAs, 4-17
SGNl task, 5-8
SGN2 task, 4-4, 5-9
SP device, 4-11
SY device, 3-7, 4-11
SY directive, 4-12, 5-4

Index-1

INDEX (CONT. )

SYSBLD.CMD file, 5-5, A-4
SYSBLD directive, 4-18
System defaults specification,
5-3

TARGET directive, 4-2, 5-2
Target specification, 5-2
Target system, 1-1, 3-1

Terminal handler, 2-1,- 2-13,
3-7, A-1
error messages at system
generation, 2-21, 3-7
Terminology, 1-2
TI device, 4-11

xxxxBOOT.TSK, 5-8

Index-2

RSX-llD System
Generation Reference
Manual
DEC-11-0XDIA-E-D

READER'S COMMENTS
NOTE:

This form is for document comments only. DIGITAL will
use comments submitted on this form at the.company's
discretion. Problems with software should be reported
on a Software Performance Report (SPR) form. If you
require a written reply and are eligible to receive
one under SPR service, submit your comments on an SPR
form.

Did you find errors in this manual?

•

If so, specify by page.

Did you find this manual understandable, usable, and well-organized?
Please make suggestions for improvement.

I!:
I.~

1-:E
I g>
1..2

,o....

IB
I a>

IQ:

Is there sufficient documentation on associated system programs
required for use of the software described in this manual? If not,
what material is missing and where should it be placed?

Please indicate the type of user/reader that you most nearly represent.

0
0

0
0
0

Assembly language programmer
Higher-level language prograirimer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Non-programmer interested in computer concepts and capabilities

Organization--------~----------------------------------------------------Street--------------------------------------------------------------------~

City ___________________________ state _____________ zip Code __
or

~~----~~

·------------------------------------------------------------Fold llere------------------------------------------------------------

·----------------------------------------------- Do Not Tear - Fold Here and Staple -----------------------------------------------

FIRST CLASS
PERMIT NO. 33
MAYNARD, MASS.
BUSINESS REPLY MAIL
NO POSTAGE STAMP NECESSARY IF MAILED IN THE UNITED STATES

Postage will be paid by:

mamaomn
Software Documentation
146 Main Street ML5-5/E39
Maynard, Massachusetts 01754

digital equipment corporation

Printed in U.S.A.