Digital PDFs

AA-2600E-TC

November 1981

230 pages

Original

8.5MB

Document:	RSX-11M Guide to Writing an I/O Driver Version 4.0
Order Number:	AA-2600E-TC
Revision:	0
Pages:	230
Original Filename:	http://bitsavers.org/pdf/dec/pdp11/rsx11m_s/RSX11M_V4.1_Apr83/5_IOdrivers/AA-2600E-TC_ioDrvWrit_198111.pdf

OCR Text

RSX-11M
Guide to Writing an 1/0 Driver
Order No. AA-2600E-TC

RSX-11M Version 4.0

digital equipment corporation . maynard, massachusetts

First Printing, April
Revised, September
Revised, November
Revised, December
Updated, May
Revised, November

1975
1975
1976
1977
1979
1981

The information in this document is subject to change without notice
and should not be construed as a commitment by Digital Equipment
Corporation.
Digital Equipment Corporation assumes no responsibility
for any errors that may appear in this document.
The software described in this document is furnished under a
license
and may be used or copied only in accordance with the terms of such
license.
No responsibility is assumed for the use or reliability of software on
equipment that is not supplied by Digital Equipment Corporation or its
affiliated companies.

CS) 1975,1976,1977,1979,1981 Digital Equipment Corporation
All Rights Reserved.

Printed in U.S.A.

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

EduSystem
!AS
MASSBUS

PDP

WC~

PDT
RSTS

DECwriter
DIBOL

RSX
UNIBUS
~x

~n~noma
ZK2048

CONTENTS

Page
PREFACE

vii

SUMMARY OF TECHNICAL CHANGES

CHAPTER 1
1.1
1. 2
CHAPTER 2

INTRODUCTION TO I/O DRIVERS
RESIDENT AND LOADABLE DRIVERS
• • • •
FUNCTION OF AN I/O DRIVER • • • •

• 1-1
• 1-2

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

2.1
2.2
2.2.1
2.2.1.1
2.2.1.2
2.2.1.3
2.2.2
2.2.2.1
2.2.2.2
2.2.2.3
2.2.2.4
2.2.2.5
2.2.2.6
2.3
2.3.1
2.3.2
2.3.3
2.3.3.1
2.3.4
2.3.5
2.3.6
2.3.7
2.4
2.4.1
2.4.2
2.4.2.1
2.4.2.2
2.4.2.3
2.4.2.4
2.5
2.5.l
2.5.2
2.5.3
2.5.3.1

I/O PHILOSOPHY • •
• • • •
• 2-1
STRUCTURE
• • • • • 2-1
I/O Hierarchy • • • • • • • • • • • • • •
• 2-1
FCS/RMS
• • • • • • • •
• • • •
2-2
QIO • • • • • •
• 2-2
Executive I/O Processing •
• • • • • • 2-3
Role of I/0 Driver in RSX-llM
• 2-3
Device Interrupt •
2-4
I/O Initiator
• • • •
• 2-4
Device Time-out
2-4
Cancel I/O • • • • • • • •
2-4
Power Failure
• • • •
• 2-4
Summary--Role of an I/O Driver •
2-5
DATA STRUCTURES
• • • • • • •
• • • • • 2-5
The Device Control Block (DCB)
• 2-6
The Unit Control Block (UCB) • •
• 2-6
The Status Control Block (SCB) • • • • • •
• 2-6
Interrelation of the
I/O Control
Blocks 2-6
The I/O Packet • •
• • • •
• 2-8
The I/O Queue
• • • • • • • • • • 2-9
The Fork List
• • • • • • •
• 2-9
The Device Interrupt Vector
• • • •
2-10
EXECUTIVE SERVICES • • • • • •
2-10
Pre-Driver Initiation Processing • • • • •
2-11
Post-Driver Initiation Services
• • • •
2-11
Interrupt Save ($INTSV)
• • • •
2-12
Get Packet ($GTPKT)
• • • •
2-12
Create Fork Process ($FORK)
2-12
I/O Done ($IODON or $IOALT)
• • • • • • • •
2-13
PROGRAMMING STANDARDS
• • • •
• • • •
2-13
2-13
Process-Like Characteristics of a Driver
2-13
Programming Conventions
2-14
Programming Protocol • • • •
Processing at Priority 7 with Interrupts
2-14
Locked Out • • • • • • • •
2.5.3.2
Processing at the Priority of the
Interrupting Source • • •
2-14
iii

CONTENTS
Page
2.5.3.3
Processing at Fork Level • • • • • • • •
2.5.3.4
Programming Protocol Summary • • • • • • • •
2.6
FLOW OF AN I/O REQUEST • • • • • • • • • • •
DATA STRUCTURES AND THEIR INTERRELATIONSHIPS
2.7
2.7.1
Data Structures Summary

CHAPTER 3

2-15
2-16
2-16
2-18
2-20

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

OVERVIEW OF INCORPORATING USER-WRITTEN DRIVERS • • 3-1
System Generation Support for User-Written
Drivers • • • • • • • • • • • • • •
• 3-1
3.1. 2
Overview of User-Written Driver Code • • • • • • 3-4
3.1. 3
Overview of User-Written Driver Data Bases • • • 3-5
3.2
USER-WRITTEN LOADABLE DRIVERS • • • • • • •
3-8
3.2.1
Creating the Loadable Data Base and Driver
Modules
• • • • • • • • • • • • • •
• 3-8
3.2.2
Task-Building a Loadable Driver
3-10
3.2.2.1
Task-Building a Loadable Driver on a
Mapped System • • • • • • • • • •
3-10
3.2.2.2
Task-Building a Loadable Driver on an
Unmapped System • • • • • • • • • •
3-11
3.2.3
Loading a User-Written Loadable Driver
3-12
3.2.4
Creating the Loadable Driver and Resident Data
Base Modules • • • • • • •
• • • • • • 3-12
3.2.5
Building a Loadable Driver and Its Resident
Data Base
• • • • • • • • •
• • • • • • • 3-12
USER-WRITTEN RESIDENT DRIVERS
3.3
3-13
3.4
DRIVER DEBUGGING • •
3-15
3.4.1
Debugging Aids • • • • • • • •
3-16
3.4.1.l
Executive Stack and Register
Dump
Routine
• • • • • • • • • • • •
• • • • 3-16
XDT - The Executive Debugging Tool • • •
3.4.1.2
3-17
Panic Dump • • • • • • • • • • • • • • •
3.4.1.3
3-19
3.4.1.4
Using the Panic Dump Routine on Processors
with Console Switch Registers • • • • • • •
3-19
Using the Panic Dump Routine on Processors
3.4.1.5
Without Console Switch Registers • •
3-19
3.4.1.6
Sample Output from Panic Dump
3-20
3.4.1.7
Crash Dump Analyzer Support Routine
3-21
3.4.2
Fault Isolation • • • • • • • •
3-21
3.4.2.l
Immediate Servicing
••••••••••••
3-21
3.4.2.2
Pertinent Fault Isolation Data • •
3-23
3.4.3
Fault Tracing
• • • •
• •••••••••
3-23
3.4.3.1
Tracing Faults Using the Executive Stack and
Register Dump
••••••••••
3-25
3.4.3.2
Tracing Faults When the Processor Halts
Without Display
•••••
3-27
3.4.3.3
Tracing Faults After an Unintended Loop
3-28
3.4.3.4
Additional Hints for Tracing Faults
3-28
3.4.4
Rebuilding and Reincorporating a Driver
3-29
3.4.4.1
Rebuilding and Reincorporating
a
Resident
Driver
• • • • • • • • • • •
3-29
3.4.4.2
Rebuilding and Reincorporating a Loadable
Driver . . . . . . . • . . . . . . • . . . . 3-30
3.1
3.1.1

CHAPTER 4

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

4.1
DATA STRUCTURES
4.1. l
The I/O Packet
4.1.1.1
I/O Packet Details •
4.1.1.2
The QIO Directive Parameter Block (DPB)

•
•
•
•

4-1
4-2
4-2
4-6

CONTENTS
Page
4.1. 2
The Device Control Block (DCB) • • • • • • • • • 4-7
4.1.2.1
DCB Details
• • • • • • • • • • • • • • • 4-8
4.1.2.2
Establishing I/O Function Masks
4-15
4.1. 3
The Status Control Block (SCB)
4-19
4.1.3.1
SCB Details
• • • • • • • • •
4-20
4.1. 4
The Unit Control Block (UCB)
• • • •
4-23
UCB Details
• • • • • • • • • • • • • • • • 4-24
4.1.4.1
The Device Interrupt Vector
• • • • • •
4-33
4.1. 5
MULTICONTROLLER DRIVERS • • • • • • • • • • • •
4-33
4.2
THE INTSV$ MACRO •
• • • • •
4-35
4.3
Format .. • .. .. .. .. • • ..
4. 3 .. 1
"
"
e
=
4-35
CHAPTER 5
5.1
5.2
5.3
CHAPTER 6

6.1
6.2
6.2.1
6. 2 •. 2
6.3
APPENDIX A
A.l
A.2
APPENDIX B
B.l
B .1.1
B .1. 2
B .1. 3
B.2
B.3

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS
SYSTEM STATE REGISTER CONVENTIONS
CONDITIONAL ROUTINES • • • • • • • •
SERVICE CALLS
• • • • • • • • • •

• • • 5-1
• • 5-1
• 5-1

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
DEVICE DESCRIPTION •
DATA BASE AND DRIVER SOURCE
The Data Base
• • • • .
Driver Code
••••
HANDLING SPECIAL USER BUFFERS

.
. . .
. .
. . .

•
.
.
.

.
.
.
.

DEVELOPMENT OF THE ADDRESS DOUBLEWORD
INTRODUCTION •
• • • • • • • • • • • • A-1
CREATING THE ADDRESS DOUBLEWORD • • • •
• • A-1
DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY
CALLING $STMAP AND $MPUBM OR $STMP1 AND $MPUB1 • •
Allocating a Mapping Register Assignment Block •
Calling $STMAP or $STMP1 • • • • •
• •
Calling $MPUBM or $MPUB1 • • • • • • • •
• •
CALLING $ASUMR AND $DEUMR • • • • • • •
•
STATICALLY ALLOCATING UMRS DURING SYSTEM
GENERATION • • • • • • • • • • • • • • •
•

APPENDIX C

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

APPENDIX D

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

D.l
D.2
D.2.1
D.2.2
D.2.3
D.3
D.3.1
D.3.2
D.3.3
D.3.4

• 6-1
•
. 6-2
. . . . 6-2
. . . . 6-4
. . . . 6-9

OVERVIEW OF THE RSX-llM I/O SYSTEM • • • • •
TYPES OF ANCILLARY CONTROL PROCESSORS
ACPs Which Manage Files Structures • • • •
ACPs Which Manage Intertask or Interprocessor
Communication
• • • • • • • • • • •
ACPs Which Perform Privileged Operations for
Unprivileged Tasks
•••••••• •
THE ATTRIBUTES OF AN ACP •

ACP as a Task

B-1
B-2
B-2
B-3
B-3
B-4

D-1
• D-2
• D-3
D-3
• D-3
• D-4

. . . • . . • .

D~4

Class of Devices •
• • • • •
• • D-4
Extension of Executive • • • • • • •
• D-5
Enabling Capability and Disabling Capability • • D-5

CONTENTS
Page
D.3.5
D.4
D.5
D.5.1
D.5.2
D.5.3
D.6

Shareability • • • • • •
• • • • • • • • D-5
THE FLOW OF AN I/O REQUEST •
• • • • • • • • • D-5
SYSTEM DATA STRUCTURES •
• • • •
• D-7
• • • • • • • • •
• D-7
The I/O Packet •
The DCB
• • • •
• D-9
The UCB
• • • • • • • • • D-9
AN EXAMPLE OF AN ACP-I/O DRIVER COMBINATION
D-11

INDEX

EXAMPLES
EXAMPLE D-1

D-11

An ACP-I/O Driver Combination

FIGURES
FIGURE

2-1
2-2
2-3
2-4
2-5
3-1
3-2
3-3
3-4
3-5
4-1
4-2
4-3
4-4
4-5
4-6
B-1
D-1
D-2

I/O Control Flow • • • • • • • • • • • • • •
DHll Terminal I/O Data Structure • • •
RKll Disk I/O Data Structure • • • •
• • •
I/O Data Structure for Two RKll Disk Controllers
I/O Data Structure • • • • • • • • • • • • • • •
Task Header on an Unmapped System
• • • •
Task Header on a Mapped System
Stack Structure:
Internal SST Fault •
Stack Structure: Abnormal SST Fault • •
Stack Structure: Data Items on Stack
I/O Packet Format
• • • • • • • • •
• • • •
QIO Directive Parameter Block (DPB)
• • • •
Device Control Block
• • • • •
• • • •
Status Control Block • • • • • • • •
Unit Control Block • • • • • • • • •
Conditional Code for a Multicontroller Driver
Mapping Register Assignment Block • • • •
The RSX-llM I/O System •
• • • • • • • •
I/O Packet • • • • • • • • • • • • • •

•
•
•
•

2-2
2-7
2-8
2-8
2-19
3-24
3-25
3-26
3-27
3-28
• 4-3
• 4-6
• 4-8
4-19
4-26
4-34
• B-3
• D-2
• D-9

TABLES
TABLE

3-1
3-2
3-3
4-1
4-2
4-3
4-4
4-5
C-1

Required DCB Fields
• • • • • • • • • • • • 3-6
Required UCB Fields • • • •
• • • •
• • • 3-7
Required SCB Fields
• • • • • • • • 3-7
D. PCB and D. DSP Bit Definitions • • • • • •
4-14
Mask Values for Standard I/O Functions •
4-15
Mask Word Bit Settings for Disk Drives •
4-16
Mask Word Bit Settings for Magnetic Tape Drives
4-17
Mask Word Bit Settings for Unit Record Devices • 4-18
Summary of System Data Structure Macros • • • • • C-2

PREFACE

MANUAL OBJECTIVES
The goal of this manual is to provide information necessary to prepare
a conventional I/O driver for RSX-llM and subsequently incorporate it
into an operational user-tailored system. A "conventional" driver is
best explained by example.
Disks and unit record devices are
considered conventional; the LPS-11, UDC-11, and TMll are considered
unconventional.
Complexity of device servicing requirements sets the
dividing line, which is not easily established in black-and-white
terms.

INTENDED AUDIENCE
The manual assumes that you understand the device for which you are
writing a driver, and that you are familiar with the PDP-11 processor,
its peripheral devices, and the software supplied with an RSX-llM
system.
Although this manual is organized tutorially, the intended
audience is assumed to be at a system programmer level of expertise;
thus, the manual does not contain definitions of data processing terms
and concepts familiar to senior-level professionals.

STRUCTURE OF THIS DOCUMENT
This document proceeds from chapter
detailed levels of implementation.

Chapter 1 is a general introduction to
system.

chapter
I/O

toward

drivers

increasingly
the

RSX-llM

Chapter 2 is a functional description of the RSX-llM device-level
system. It discusses both data structure and code requirements.

I/C

Chapter 3 details how to incorporate a user-written
system.

the

driver

into

Together, Chapters 1, 2, and 3 provide a complete description of the
requirements that must be met in creating a system that contains a
user-written driver.
Chapter 4 provides programming-level details on I/O
and on drivers that service several controllers.

data

Chapter 5 discusses all the I/0-related Executive services~

Chapter 6 gives two examples of user-written drivers.
Appendix A describes the address doubleword.

vii

structures

Appendix B outlines special considerations
device drivers.

for

extended

memory

NPR

Appendix C lists system macros that supply symbolic offsets for system
data structures.
Appendix D is a guide for the user in developing an Ancillary
Processor (ACP).

Control

ASSOCIATED DOCUMENTS

Familiarity with the
following manuals:

system

implies

in-depth

exposure

the

Guide
• RSX-llM System Generation and Installation -• RSX-llM/M-PLUS I/O Drivers Reference Manual
• RSX-llM/M-PLUS Executive Reference Manual
• RSX-llM/M-PLUS Utilities Manual

• IAS/RSX-ll I/O Operations Reference Manual
As adjuncts to this manual, you are advised to study existing I/O
drivers. The RL-11 disk driver is a good example of an NPR device and
the TA-11 (cassette) is illustrative of a programmed I/O device.
In
addition,
a perusal of Executive source code contained in the files
IOSUB, SYSXT, DRQIO, BFCTL, and DRDSP (stored in UFD
[11,10]
on the
Executive source disk) is recommended.
Other manuals closely allied to the purposes of this document are
described briefly in the RSX-llM/RSX-llS Information Directory and
Index. The Information Directory defines the intended readership of
each manual
in the RSX-llM/RSX-llS set and provides a brief synopsis
of each manual's contents.

viii

SUMMARY OF TECHNICAL CHANGES

This revision of the RSX-llM Guide to Writing an I/O
incorporates the following technical changes and additions:

Driver

Tables have been added to aid the user in establishing I/O
function bit masks for disk drives, magtape drives, and unit
record devices (see Tables 4-3, 4-4, and 4-5).

Error logging offsets have been added to the SCB and UCB.
See the descriptions of the SCB and the UCB in Chapter 4.

Other additions have been made to various UCB offsets:

•

New symbolic name U.MUP has been
U.CLI; see Chapter 4).

•

Symbolic names for magtape density bit masks have
added to the description of U.CW3 (see Chapter 4).

•

The DV.MBC offset to U.CWl has been renamed to DV.EXT (see
Chapter 4).

(redefinition

of
been

Some Executive routines listed in Chapter 5 have been moved
to new Executive modules.
The following is a list of the
affected modules and subroutines:

Routine

Old Module

New Module

$ACHKB/$ACHCK
$ASUMR
$DEUMR
$DVMSG
$MPUBM
$MPUB1
$RELOC
$STMAP
$STMP1

IOSUB
IOSUB
IOSUB
IOSUB
IOSUB
IOSUB
IOSUB
IOSUB
IOSUB

EXE SB
MEMAP
MEMAP
EXE SB
MEMAP
MEMAP
MEMAP
MEMAP
MEMAP

In addition, the inputs to $MPUB1
Chapter 5).
5.

added

have

been

modified

(see

Three additional routines have been documented in Chapter 5:
$EXRQP, $QRMVF, and $SWSTK.

An appendix intended to aid the user in writing an Ancillary
Control Processor (ACP) has been added (see Appendix D).

CHAPTER 1
INTRODUCTION TO I/O DRIVERS

The software supplied by DIGITAL for an RSX-llM system includes I/O
drivers for a number of standard I/O devices.
An I/O driver is a part
of the RSX-llM Executive that services one type of I/O device.
A
driver may handle one or several controllers, each with one or several
device-units attached.

1. 1

RESIPENT AND LOADABLE DRIVERS

A driver can be resident or loadable.
A resident driver
is a
permanent part of the Executive, incorporated at system generation. A
loadable driver, while also part of the Executive, can be added to or
unloaded from a system almost at will by means of MCR or VMR commands.
During the system generation dialog, you can specify that you want
this facility.
Making drivers loadable can result in less Executive code, and thus
permits an increase in available dynamic storage region (pool) space
or increased space for user tasks.
You can unload from the system any
driver that is not needed for a period of time.
For example, assume
your system has both a paper tape reader and a card reader.
If only
one of them is connected to the system at any one time, you could load
the driver for the on-line device and unload the other driver,
thus
reducing the size of the Executive.
A loadable user-written driver is easier to incorporate into a system
and easier to debug than a
resident one.
You can incorporate a
resident driver into a system only during system generation;
the
Executive must be rebuilt and the system bootstrapped each time it is
incorporated after debugging.
In contrast, you can incorporate a
loadable
driver
into
a
system
with a single MCR command.
Incorporating and debugging user-written drivers are discussed
in
Chapter 3.

1-1

INTRODUCTION TO I/O DRIVERS
1.2

FUNCTION OF AN I/O DRIVER

An I/O driver is an asynchronous process (not a task) that calls and
is called by the Executive to service an external I/O device or
devices. The role of an I/O driver in the RSX-llM I/O structure is
specific and limited. A driver performs the following functions:
•

Receives and services interrupts from its I/O device(s)

•

Initiates I/O operations when
Executive

•

Cancels in-progress I/O operations

•

Performs other (device-specific) functions upon power failure
and device time-out

requested

the

As an integral part of the Executive, a driver possesses its own
context, allows or disallows interrupts, and synchronizes its access
to shared data bases with that of other Executive processes.
It may
also synchronize with itself:
A driver can handle several device
controllers
(each with several device-units)
all
operating
in
parallel.
A user-written driver must adhere to RSX-llM programming
c6nventions in order to ensure the
integrity of the Executive.
Section 2.5 and Chapter 4 discuss these conventions.

1-2

CHAPTER 2
THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

2.1

I/O PHILOSOPHY

Memory constraints and compatibility requirements dominated the design
philosophy and strategy used in creating RSX-llM.
To meet its
performance and space goals, the RSX-llM I/O system attempts to
centralize
common functions, thus eliminating the inclusion of
repetitive code in each and every driver in the system.
To achieve
this centralization, a substantial effort has been expended in
designing the RSX-llM data structures, which are used to drive the
centralized routines. The effect is to reduce substantially the size
of individual I/O drivers. The table structures require space and
must
be
considered
with the total size of the I/O system.
Nevertheless, the size reduction effected by centralizing functions,
combined with table-driven design, enables RSX-llM to meet its
intended memory and performance goals.

2.2

STRUCTURE

The following sections:

2.2.1

Place an I/O driver in the context of the overall RSX-llM I/O
system

Establish the responsibilities of an I/O driver

Functionally describe the driver's interface to the Executive
subroutines and the I/O data structures

I/O Hierarchy

The RSX-llM I/O system is structured as a loose hierarchy.
The term
"loose" indicates that you can enter the hierarchy at any of its
levels; this characteristic is contrasted to "tight" hierarchies that
permit entry only from the top level.
Tight hierarchies exist
principally for security and protection, but consume
equipment
resources. Figure 2-1 shows the loose RSX-llM I/O system hierarchy.

2-1

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.2.1.1 FCS/RMS - At the top of the hierarchy are File Control
Services (FCS) and Record Management Services (RMS), which provide
device-independent access to devices included in a given system
configuration.
The user task has two levels with which to interface
with FCS or RMS: Get/Put and Read/Write.
Get/Put facilitates the
movement of data records, whereas Read/Write provides a more basic
level of access affording more direct control over data movement
between a task and peripheral devices.
Non-privileged

Privileged

User 1/0
request

FCS

FCP

Deviceindependent
Devicedependent
010
directive

010
directive

User state
System state
OIO
directive
service

Executive
1/0 subroutines

Device interrupt
1/0
driver
ZK-210-81

Figure 2-1

I/O Control Flow

The discussion of FCS and RMS is brief because their existence is
completely transparent to the driver and rarely concerns the writer of
a conventional driver. FdS or RMS accepts a user request, interprets
it, and translates it into a series of low-level system directives
known as QIOs.

2.2.1.2 QIO - The QIO directive is the lowest level of task I/O. Any
task can issue a QIO directive which allows direct control over
devices that are connected to a system and that have an I/O driver.
The QIO directive forces all I/O requests from user tasks to go
through the Executive. The Executive works to prevent tasks from
destructively interfering with each other and with the Executive
itself5

2-2

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.2.1.3 Executive I/O Processing - The
requests using the following:

Executive

processes

An Ancillary Control Processor (ACP)

A collection of Executive components consisting of:
a.

QIO directive processing

I/O-related subroutines

The I/O drivers

I/O

An ACP is responsible for maintaining the structure and
integrity of
data stored on file-structured volumes.
It maps virtual I/O functions
to logical I/O functions, and makes volume-protection checks.
The
driver converts a logical block number into a physical address on a
file-structured device. No direct connection normally exists between
the ACP and a driver.
An ACP is a privileged task, and requires a
execute.
Drivers,
on the other hand,
processes, not tasks.

partition in which to
are specialized system

The Executive provides QIO directive processing.
It also provides a
collection of subroutines that are used by drivers to obtain I/O
requests, to facilitate interrupt handling, and to return directive
status codes.
Actual control of the device is performed by the
driver.
These subroutines are examined
in detail
in Chapter 5.
Executive subroutine services and QIO directive processing are shown
as distinct components but are, in fact, both part of the Executive.
These subroutines centralize common driver functions, thus eliminating
duplicate code sequences among drivers.

2.2.2

Role of I/O Driver in RSX-llM

Every I/O driver in the RSX-llM system has the
points:

following

five

entry

• Device interruptl
• I/O initiator
• Device time-out
• Cancel I/O
• Power failure
The first entry point is entered by a hardware interrupt;
the other
four are entered by calls from the Executive.
Functional details
regarding these entry points follow.

1. A device may trigger more than one distinct interrupt
example, a full-duplex device would have two.
2-3

entry.

For

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.2.2.1 Device Interrupt - Control passes to this entry point when a
device previously initiated by the driver completes an I/O operation
anq causes an interrupt in the central processor.
The connection
beuween the device and
the driver in this instance is direct; the
Executive is not involved.

2.~.2.2

I/O Initiator - The Executive calls this entry point to
the driver that work for it is waiting to be done.
In effect,
this is a wake-up signal for the driver.
in~orm

2.~.2.3
Device Time-out - When a driver initiates an I/O operation,
it can establish a time-out count.
If the function then fails to
com!Plete within the specified time interval, the Executive notes the
tim~ lapse and calls the driver at this entry point.

2.2~2.4
Cancel I/O - A number of circumstances arise within the
system
that require a driver to terminate an in-progress
I/O
operation. When such a termination becomes necessary, a task so
informs the Executive, which then relays the request to the driver by
cal~ing it at the cancel I/O entry point.

2.2.2.5 Power Failure - The Executive calls the driver's
failure entry point in three different circumstances:
•

When power is restored after a failure

•

When the system is bootstrapped

•

When the driver is loaded
a resident, driver)

power-

(if it is a loadable, as opposed

Power Restore - Two conditions can initiate a call to the driver when
power
is restored
following
a power failure.
First, the Executive
automatically calls the power-failure entry point when power
is
restored any time the controller is busy (that is, when I/O is in
progress).
Second, a driver has the option to be called regardless of
the existence of an outstanding I/O operation at the time the power is
restored (See the description of the UC.PWF bit symbol
in Section
4.1. 4. 1).
Frequently, a driver's response to a power failure or to an
I/O failure is identical to that when its device times out;
in such a
case,
the
power-failure
entry point may simply be a RETURN
instruction, because the driver will
recover eventually via the
time-out entry point.
1

Bootstrap - When the system is bootstrapped, a power-failure interrupt
is simulated. This simulation gives drivers the opportunity to carry
out any appropriate preoperational initialization.
Load - The MCR LOA command calls a
loadable
driver
at
its
power-failure entry point if the device is on line and UC.PWF is set
(see Section 4.1.4.l).

2-4

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

2.2.2.6 Summary--Role of an I/O Driver - Functionally,
RSX-llM is responsible for:

•

Servicing device interrupts

•

Initiating I/O operations

•

Cancelling in-progress I/O operations

•

Performing device-related functions when a time-out
failure occurs

driver

power

A driver exists as an integral part of the Executive~
it can call,
and be called by, the Executive. The driver initiates device I/O
operations directly and receives device interrupts directly.
All
other entry points are entered by means of Executive calls. A driver
never receives a QIO request directly, and has no direct interaction
with the ACP.

2.3

DATA STRUCTURES

An I/O driver interacts with the following data structures:
•

Device Control Blocks (DCBs)

•

Unit Control Blocks (UCBs)

•

Status Control Blocks (SCBs)

•

The I/O packet

•

The I/O queue

•

The fork list

•

Device interrupt vector

The first four of these data structures are especially important to
the driver, because it is by means of these data structures that all
I/O operations are effected. They also serve as communication and
coordination vehicles between the Executive and individual drivers.
The I/O queue and the fork list are actually Executive
data
structures, but are discussed here to illustrate all facets of the
interaction of an I/O driver with the Executive. The I/O queue is a
list of I/O packets built by the QIO directive, principally from
information in the caller's Directive Parameter Block (DPB). The fork
list synchronizes access to shared Executive data structures.
Entry to a driver following a device interrupt is accomplished through
the appropriate hardware device interrupt vector. As will be seen,
writers of resident drivers are responsible for properly initializing
this vector. It is discussed in conjunction with the data structures
associated with a driver.

2-5

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.3.1

The Device Control Block (DCB)

At least one DCB exists for each type of device appearing in a system
(device type should not be equated with device-unit). The function of
the DCB is to describe the static characteristics
(rather than
execution-time information)
of both the device controller and the
units attached to the controller. All the DCBs in a system form a
forward-linked list, with the last DCB having a link of zero. Most of
the data in the DCB is established in the assembly source for the
driver data structure.
The DCB is used by the QIO directive
processing code in the Executive and not by the driver.

2.3.2

The Unit Control Block (UCB)

One UCB exists for each device-unit attached to a system. Much of the
information in the UCB is static, though a few dynamic parameters
exist.l For example, the redirect pointer, which reflects the results
of the MCR RED command is updated dynamically. As with the DCB, most
of the UCB is established
in the assembly source;
however,
its
contents are used and modified by both the Executive and the driver.
Usually, either the Executive or the driver -- but not both -- modify
a datum.

2.3.3

The Status Control Block (SCB)

One SCB exists for each device controller in the system.
This is true
even if the controller handles more than one device-unit (like the
RLll Controller).
Line multiplexers such as the DHll and DJll are
considered to have one controller for each line because all lines can
transfer in parallel. Most of the information in the SCB is dynamic.
Both the Executive and the driver use the SCB.

2.3.3.1 Interrelation of the I/O Control
Blocks - This section
discusses the interrelationship among the DCB, UCB, and SCB without
entering into the detailed contents of the control blocks, which are
discussed in Chapter 4.
Figure 2-2 shows the data structure that would result for three LA36
DECwriters interfaced by means of a DHll multiplexer. The structure
requires one DCB, three UCBs, and three SCBs, because the activity on
all three units can proceed in parallel.
Figure 2-3 depicts the internal data structure for an RKll disk
controller with three units attached. Note that only one SCB exists,
because only one of the three units can be active at any given time.

1. From the UCB, however, it is possible to access most of the other
structures in the I/O data base (see Figure 2-5).
In this sense the
UCB gives access to a large amount of dynamic data.
2-6

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

Figure 2-4 shows the data structure for two RKll disk controllers,
each of which has two drives attached.
Here there are two SCBs,
because both of the disk controllers can operate in parallel.
Taken together, Figures 2-2, 2-3, and 2-4 illustrate the strategy
underlying the existence of three basic I/O control blocks. There
need be only one DCB for each device type. There may be one or more
SCBs, depending on the degree of parallelism that is desired or
possible: one for each device-unit, or one for each controller
serv1c1ng several device-units.
The number of UCBs and SCBs, and
their interrelationships, are uniquely determined by the hardware
these data structures describe.
This data structure provides considerable flexibility in configuring
I/O devices, and, because of the information density in the structures
themselves, substantially reduces the code requirements of
the
associated drivers.

DCB

UCB

SCB

UCB

SCB

ZK-211-81

Figure 2-2

DHll Terminal I/O Data Structure

2-7

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

DCB

UCB

SCB

ZK-212-81

Figure 2-3

RKll Disk I/O Data Structure

DCB

!
UCB

UCB

I
SCB

1
--

SCB

ZK-213-81

Figure 2-4

2.3.4

I/O Data Structure for Two RKll Disk Controllers

The I/O ,Packet

An I/O packet contains information extracted from the QIO DPB, as well

as other information needed to initiate and terminate I/O

2-8

requests~

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

2.3.S

The I/O Queue

(" ....

Each time a task makes an I/O request, the Executive performs a series
of validity checks on the DPB parameters.
If these checks prove
successful, the Executive generates a data structure called an I/O
packet. The Executive then inserts the packet into a device-specific,
priority-ordered list of packets called the I/O queue.
Each I/O
queue's listhead is located
in the SCB to which the I/O requests
apply.
When a device driver needs work, it requests the Executive to dequeue
the next I/O packet and deliver it to the requesting driver.
Normally, the driver does not directly manipulate the I/O queue.l

2.3.6

The Fork List

The fork list is a mechanism by which RSX-llM splits off processes
that require access to shared data bases, or that require more CPU
time to process an interrupt than is compatible with fast,
real-time
response of the overall systema
A process that calls $FORK requests the Executive to transform it into
a
"fork process" and place it on the fork list. What this means is
that a call to $FORK saves a "snapshot" of the process (registers R4,
RS,
and the PC)
in a fork block.
This fork block is queued on the
fork list in first-in-first-out (FIFO) order.
When a fork process has worked its way to the front of the fork list,
R4 and RS are restored and execution restarts at the statement after
CALL $FORK. The process is unaware that a pause of indeterminate
length has occurred.
A fork process exists in a status intermediate between an interrupting
routine and an ordinary task requesting system resources.
Routines in
the system stack--requests for interrupt processing--are run first.
They can be interrupted only by higher-priority requests.
Routines in
the fork list are run when the system stack is empty--that is, they
are completely interruptable.
Finally, other tasks are run only when
both the system stack and the fork list are empty.
Driver interrupts are processed at priority 7
and
are
thus
noninterruptable.
By system convention, no process should run in a
noninterruptable mode for more than 100 microseconds.
This convention
ensures prompt attention to interrupting real-time events.
In practice, drivers servicing interrupts drop from priority 7 to a
lower priority (namely, that of the interrupting source) after issuing
a few instructions. Another system convention states that processing

1. An exception is the case in which a driver needs to examine an I/O
packet before it is queued, or in place of having it queued.
For the
driver to accomplish this examination, you must set the bit UC.QUE in
the control byte (U.CTL) of the UCB (described in Section 4.1.4).
The most common reason for a driver to examine a packet before queuin~
is that the driver employs a special user buffer, other than the

normal buffer used in a transfer request.

Within the context

the

requesting task, the driver must address-check and relocate such a
special buffer.
See Section 6.3 for an example of a driver that does
this.
2-9

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
at this partially interruptable level should
not
exceed
500
microseconds.
Often, more time than this is required to process an
interrupt. The fork list mechanism provides a secondary interrupt
stack whose members are processed first-in-first-out whenever the
system stack is empty.
A process can also call $FORK to access a shared data base--a system
table, for example.
You must strictly control ~uch access in order to
avoid conflicts. Under RSX-llM, many drivers can run in parallel;
a
multicontroller driver can run in parallel with itself.
In these
circumstances access to common data bases must be controlled.
Of the two available methods of controlling such access--interrupt
lockout and priority queuing--RSX-llM uses priority queuing. The fork
list is the queue of requests for such access.
Fork processes are
granted FIFO access to common data bases.
Once granted such access, a
process is guaranteed control of the data base until it exits.

2.3.7

The Device Interrupt Vector

The device interrupt vector consists of two consecutive words giving
the address of the interrupt-service routine and the priority at which
it is to run (always set to PR7). The low four bits of the second
word of the interrupt vector must contain the number of the controller
that interrupts through the vector. This requirement enables a driver
to service several controllers with few code changes (see Sections 4.2
and 4.3 for an example and discussion of multicontroller driver
coding). Generally, these bits are set to O.

2.4

EXECUTIVE SERVICES

The Executive provides services related to I/O drivers that can be
categorized as pre- and post-driver initiation. The preinitiation
services are those performed by the Executive during its processing of
a QIO directive; these services are not available as Executive calls.
The goal of pre-driver initiation processing is to extract from the
QIO directive all
I/O support functions not directly related to the
actual issuance of a function request to a device.
If the outcome of
pre-driver initiation processing does not result in the queuing of an
I/O packet to a driver, the driver is unaware that a QIO directive was
issued. Many QIO directives do not result in the initiation of an I/O
operation.
The post initiation services are those available to the driver after
it has been given control, either by the Executive or as the result of
an interrupt. They are available as needed by means of Executive
calls.
An important concept used in this section and in Section 2.5 is
"state" of a process.
In RSX-llM, a process can run in one of
states: user or system.
Drivers operate almost entirely in
system state;
the programming standards described in Section
apply to system-state processes.

2-10

the
two
the
2.5

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.4.l

Pre-Driver Initiation Processing

In processing a QIO directive, the Executive module DRQIO performs the
following pre-driver initiation services:
1.

Checks to verify whether the supplied logical unit
(LUN) is legal.
If not, the directive is rejected.

If the LUN is valid, checks to verify whether a valid UCB
pointer exists in the Logical Unit Table
(LUT) for the
specified LUN.
This test determines if the LUN is assigned.
If the test fails, the directive is rejected.

If steps l and 2 are successful, traces down the redirect
chain to locate the correct UCB to which the I/O operation
will actually be directed.

Checks the event flag number (EFN) and the address of the I/O
Status Block (IOSB}.
If either is illegal, the directiv~ is
rejected.
Immediately following validation, the Executive
resets the subject event flag and clears the IOSB.

Obtains 18 words of dynamic storage
and
device-independent portion of an I/O packet.
If steps l
through 5
directive status to +l.

succeed,

the

number

builds

Executive

sets

the
the

Note that directive rejections in any of the above steps are
completely transparent to the driver.
Such rejections cause
a return of carry bit set.
6.

Checks the validity of the function being requested and,
if
appropriate, checks the buffer address, byte count, and
alignment requirements for the specified device.
If any of these checks fails, the Executive calls the I/O
Finish routine
($IOFIN).
$IOFIN sets the I/O status and
clears the QIO request from the system.

2.4.2

If the requested function does not require a call to the
driver, the Executive takes the appropriate actions and calls
$IOFIN.

If all I/O packet checks are positive, the Executive places
the I/O packet in the driver queue according to the priority
of the requesting task, or gives the packet to the driver (if
bit UC.QUE is set--see Section 4.1.4.1).

Post-Driver Initiation Services

Once a driver is given control following an I/O interrupt or by the
Executive itself, a number of Executive services are available to the
driver.
These services are discussed in detail in Chapter 5.

2-11

THE RSX-llM I/0 SYSTEM--PHILOSOPHY AND STRUCTURE
However, four
Executive services merit special
virtually every driver in the system uses them:
•

Interrupt Save ($INTSV)

Get Packet ($GTPKT)

•

Create Fork Process ($FORK)

I/O Done ($IODON or $IOALT)

emphasis

because

2.4.2.1 Interrupt Save ($INTSV)l - Interrupts from a
device
are
fielded by the driver.
Immediately following
the interrupt, the
driver operates at hardware priority level 7 and is, therefore,
noninterruptable.
If the driver needs a lengthy processin~ cycle
(greater than 100 microseconds) to process the interrupt, or if it
requires the use of any general-purpose registers, it calls $INTSV.
This call queues external interrupts, alters the hardware priority,
and provides the calling routine with two free registers to use in
processing the interrupt.
$INTSV is discussed
in more detail
in
Section 2.5.

2.4.2.2 Get Packet ($GTPKT) - The Executive, after it has queued an
I/O packet, calls the appropriate driver at its I/0-initiato~ entry
point. The driver then immediately calls the Executive routine $GTPKT
to obtain work.2
If work is available, $GTPKT delivers to the driver
the highest-priority, executable I/O packet in the driver's I/O queue,
and sets the SCB status to "busy." If the driver's I/O queue is empty,
$GTPKT returns a no-work indication.
If the SCB related to the device
is already busy,
$GTPKT so informs the driver, and the driver
immediately returns control to the Executive.
Note that, from the driver's point of view, no distinction exists
between no-work and SCB busy, because an I/O operation cannot be
initiated in either case.

2.4.2.3 Create Fork Process ($FORK) - You can synchronize access to
shared data bases by creating a fork process. When a driver needs to
access a shared data base, it must do so as a
fork process;
the
driver becomes a fork process by calling $FORK.
The SCB contains
preallocated storage for a 4- or 5-word "fork block." See Section
4.1.3.1 for a description of the fork block. Section 5.3 contains
details on $FORK.

1. A loadable driver on a mapped system cannot call
See Section 4.3.

$INTSV

directly.

2. An exception is a driver that handles special user buffers.
Such a
driver must call certain other Executive routines before calling
$GTPKT.
See Section 6.3 for an example.
2-12

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
An interrupt routine cannot call $FORK directly;
the routine must
first switch to system state by using the INTSV$ macro or calling
$INTSV (as described
in
Section
2.4.2.1).
Furthermore,
the
interrupting routine's priority is lowered to that of the requesting
source.
After calling $FORK, a routine is fully interruptable
(priority
and its access to shared system data bases is strictly linear.

0),

2.4.2.4 I/O Done ($IODON or $IOALT) - At the completion of an I/O
request, the subroutines $IODON or $IOALT perform a number of
centralized checks and additional functions:
•

Store status if an IOSB address was specified

•

Set an event flag, if one was requested

•

Determine if a checkpoint request can now be honored

•

Determine if an AST should be queued

$IODON and $IOALT also declare a significant event, reset the SCB and
device unit status to "idle," and release the dynamic storage used by
the completed I/O operation.

2.5

PROGRAMMING STANDARDS

RSX-llM I/O drivers function as integral components of the RSX-llM
Executive.
They must follow the same conventions and protocol as the
Executive itself if they are to avoid complete disruption of system
service.
This manual has been written to enable you to incorporate
I/O drivers into your system.
Failing to observe the internal
conventions and protocol can result in poor service and a reduction in
system efficiency.

2.5.1

Process-Like Characteristics of a Driver

A driver is an asynchronous Executive process.
As a process,
it
possesses its own context, allows or disallows interrupts, and
synchronizes functions within itself (all drivers can be parallel,
multiunit,
multicontroller)
and with other Executive processes
executing in parallel.
Most RSX-llM drivers are small. Their small size is made possible by
a comprehensive complement of centralized services available by calls
to the Executive, and by the availability of an information-dense,
highly formalized I/O data structure.

2.5.2

Programming Conventions

Appendix E of the PDP-11 MACR0-11 Language Reference Manual describes
program coding standards.
DIGITAL recommends that users refer to
these ·Standards to assist in preparing standards for their own
installations.

2-13

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.5.3

Programming Protocol

Because an I/O driver accepts interrupts directly from the devices it
controls, the central Executive relies on the driver to follow strict
programming protocol so that system performance is not degraded.
Furthermore, the protocol ensures that the driver properly distributes
shared resources according to user-specified priorities9 The protocol
is summarized in Section 2.5.3.4.
When a device interrupts, an I/O driver is entered.
The driver
usually calls $INTSV or issues the INTSV$ macrol for common save and
state-switching services. At the completion of the services provided
by INTSV$ or $INTSV, the interrupt routine is again given control to
complete the interrupt service. The exit routine $INTXT restores the
state prior to switching to the system state, controls the unnesting
of interrupts, and makes checks on the state of the system (for
example, it checks to determine whether it is necessary to switch
stacks) • The fork processor causes access to shared system data bases
to be linear. The details of all these routines are given in Chapter
5.
The interrupt vectors for each controller type in low memory contain a
program counter (PC)
unique to each interrupting source and a
Processor Status Word (PSW) set with a priority of 7. It is a system
software convention to use the low-order four bits of the PSW to
encode the controller number for multicontroller drivers.
When a
device interrupt occurs, the hardware pushes the current PSW and PC
onto the current stack and loads the new PC and PSW (set at priority 7
with the controller number in the condition-code bits) from the
appropriate interrupt vector. The driver then starts executing with
interrupts locked out.
A driver itself may be executing at one of
three levels of interrupt sensitivity:
1.

At priority 7 with interrupts locked out.

At the priority of the interrupting source; thus, interrupt
levels greater than the priority of the interrupting source
are permitted.

At fork level, which is at priority O.

2.5.3.1 Processing at Priority 7 with Interrupts Locked Out - By
internal convention, processing at this level is limited to 100
microseconds. If processing can be completed in this time, either
without using general-purpose registers or by saving and restoring the
registers used, then the driver simply dismisses the interrupt by
executing
an RT! instruction.
The interrupt is processed and
dismissed with minimal overhead.

2.5.3.2 Processing at the Priority of the Interrupting Source - If
the driver requires additional processing time or requires the use of
general-purpose registers, it calls the $INTSV routine.
Loadable
drivers on mapped systems must use the INTSV$ macro. All other
drivers can use the INTSV$ macro or call the $INTSV routine directly.
The priority at which the caller is to run is included in the call to
the $INTSV routine. The driver sets this priority level to that of
the interrupting source.

1. The system macro INTSV$ simplifies the
interrupt-entry processing (see Section 4.3).
2-14

coding

standard

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
The $INTSV routine sets up the interrupt routine so that it can be
interrupted by devices with priorities higher than that of the
interrupting source, and switches to system state if the processor is
not already in system state.
The $INTSV routine also saves registers R4 and RS to
free
these
registers for
the driver.
(A standard practice is for the driver to
set R4 to the address of the interrupting device's SCB, and RS to
its
UCB address.)
An internal programming convention assumes that the
driver will not require more than these two registers during interrupt
processing.
If
it does,
the driver must save ·and
restore any
additional registers it uses.
Processing time following
the return
from the $INTSV routine should hot exceed SOO microseconds.l
NOTE
In actual practice, every driver in the
system calls the $INTSV routine on every
interrupt, due to three factors:
1.

It
is difficult to
service
an
interrupt without using one or two
registers.

Most interrupt code can safely be
executed at the priority of the
interrupting source.
Executing at
that priority is more desirable in
terms of
system
response
than
continuing to execute at the highest
priority.

The $INTSV routine
is an integral
part of the interrupt mechanism for
loadable drivers.

2.S.3.3 Processing at Fork Level - A driver calls $FORK to become
fully
interruptable
(so that it conforms to the SOO-microsecond time
limit), or to access the shared system data base.
The
INTSV$ macro
must be issued or the $INTSV routine must be called prior to calling
$FORK.
By calling $FORK, the routine becomes fully interruptable and
its
access to system data bases is strictly linear.
At fork level, all
registers are available to the process,
and
R4 and RS retain the
contents they had on entrance to $FORK.

1. The SOO-microsecond period is a guideline.
The longer the period
of time a
real-time executive spends at an elevated priority level,
the less responsive is the system to devices of equal or lower
priority.
This guideline is especially important if the device being
serviced is at the same or higher priority than a character-interrupt
device such as the DUll,
which is vulnerable to data loss due to
interrupt lockout.
2-lS

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE

2.5.3.4 Programming Protocol Summary - Drivers are required to adhere
to
the
following
internal conventions when processing device
interrupts:

2.6

No registers are available for use unless $INTSV has been
called or the driver explicitly performs save and restore
operations.
If $INTSV is calied, registers R4 and R5 are
available; any other registers must be saved and restored.

Noninterruptable
processing
must
not
exceed
twenty
instructions,
and
processing
at the priority of the
interrupting source must not exceed 500 microseconds.

You must use a fork process for all modifications
data bases.

system

FLOW OF AN I/O REQUEST

Following an I/O request through the system a~ the functional
level
(the level at which this chapter is directed) requires that limiting
assumptions be made about the state of the system when a task issues a
QIO directive.
The following assumptions apply:
•

The system is up and ready to accept an I/O request.
All
required data structures for supporting devices attached to
the system are intact.

•

The only I/O request in the
under discussion.

•

The example progresses without encountering any errors that
would prematurely terminate its data transfer; thus, no
error paths are discussed.

system

the

sample

request

The I/O flow proceeds as follows:
1.

[Task issues QIO directive]
All Executive directives are called by means of EMT 377. The
EMT causes the processor to push the PSW and PC on the stack
and to pass control to the Executive's directive processor.
a.

First-level validity checks
The QIO directive processor validates the LUN and UCB
pointer.

Redirect algorithm
Because the UCB may have been dynamically redirected
by an MCR Redirect command, QIO directive processing
traces the redirect linkage until the target UCB is
found.

Additional validity checks
The EFN and the address of the I/O status block
(IOSB)
are validated.
The event flag is reset and
the I/O status block is cleared.

2-16

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
2.

[Executive obtains storage for and creates an I/O packet]
The QIO directive processor now acquires an 18-word block of
dynamic storage for use as an I/O packet.
It inserts into
the packet data items that are used subsequently by both the
Executive and the driver in fulfilling the I/O request. Most
items originate in the requesting task's Directive Parameter
Block (DPB) •

[Executive validates the function requested]
The function is one of four possible types:
•

Control

•

No-op

ACP

•

Transfer

Control functions are queued to the driver.
If the function
is IO.KIL, the driver is called at its cancel I/O entry
point. The IO.KIL request is then completed successfully.
No-op functions do not result in data transfers.
The
Executive "performs" them without calling the driver. No-ops
return a status of rs.sue in the I/O status block.
ACP functions may require processing by the file system.
More typically, the request is a read or write virtual
function that is transformed into a read or write logical
function without requiring file system intervention. When
transformed into a read or write logical, the function
becomes a transfer function (by definition).
See Appendix D
for more information on ACP functions.
Transfer functions are address checked and queued to the
proper driver.
Then the driver is called at its initiator
entry point.
4.

[Driver processing]
a.

Request work
To obtain work, the driver calls the $GTPKT routine.
$GTPKT either provides work, if it exists, or informs the
driver that no work is available, or that the SCB is
busy.
If no work exists, the driver returns to its
caller.
If work is available,
$GTPKT sets the device
controller and unit to "busy," dequeues an I/O request
packet, and returns to the driver.
If the I/O request is
IO.ATT or IO.DET,
the request is processed by the
Executive without returning the packet to the driver,
unless UC.QUE is set.
If UC.QUE is set, the packet is passed to the driver
after the IO.ATT or IO.DET processing is completed.
If
the request is to be processed by an ACP, the packet is
queued to the ACP.
In either case, $GTPKT will look for
another request for the driver.

2-17.

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
b.

Issue I/O
From the available data structures, the driver initiates
the required I/O operation and returns to its caller. A
subsequent interrupt may inform the driver that the
initiated function is complete, assuming the device is
interrupt driven.

[Interrupt processing]
When a previously issued I/O operation interrupts, the
interrupt causes a direct entry into the driver, which
processes the interrupt according to the programming protocol
described
in Section 2.5.
According to the protocol, the
driver may process the interrupt at priority 7,
at the
priority of the interrupting device, or at fork level.
If
the processing of the I/O request associated with the
interrupt is still incomplete, the driver initiates further
I/O on the device (step 4b). When the processing of an I/O
request is complete, the driver calls $IODON.

[I/O Done processing]
$IODON removes the "busy" status from the device unit and
controller, queues an AST, if required, and determines if a
checkpoint request pending for the issuing task can now be
effected.
The IOSB and event flag,
if specified, are
updated, and $IODON returns to the driver.
The driver
branches to its initiator entry point and looks for more work
(step 4a). This procedure is followed until the driver finds
the queue empty, whereupon the driver returns to its caller.
Eventually, the processor is granted to another ready-to-run
task that issues a QIO directive, starting the I/O flow anew.

2.7

DATA STRUCTURES AND THEIR INTERRELATIONSHIPS

This section introduces all the individual control blocks, as well as
their linkages and use within the system.
The following data
structures comprise the complete set for I/O processing:
1.

Task header

Window Block (WB)

File Control Block (FCB)

$DEVHD word, the Device Control Block (DCB), and
Dispatch Table (DDT)

Unit Control Block (UCB)

Status Control Block (SCB)

Volume Control Block (VCB)

the

Driver

Figure 2-5, which provides the structure for the following discussion,
shows all the individual data structures and the important link fields
within them.
The numbers on the figure are keyed to the text to
simplify the discussion and to guide the reader through the data
structures.

2-18

THE RSX-llM I/O SYSTEM--PBILOSOPBY AND STRUCTURE
1.

The task header is constructed during
the
task-build
process.l
(It is one of two independent entries in the I/O
data structure, the other being $DEVHD.)
The task header
entry of interest, the Logical Unit Table (LUT), is allocated
by the Task Builder and filled in at task installation.
The
number of LUT entries is established by the UNITS= keyword
option; this number is an upper limit on the number of
device units a task may have active simultaneously.
Each LUT
entry contains a pointer to an associated UCB, and a pointer
to a Window Block if a file is accessed by that logical unit
number (LUN).

SYSCM

$DEV HD:

._________.h~I
I
/11
·n
~
LJ
\::J

oc'

----

DCB

-o/07f_/ ...
1/0 Queue

'DDT

SCB

UCB's

0
TCB

~
~

FCB (index)

volume

"""WB (volume)

j
ZK-214-81

Figure 2-5

I/O Data Structure

A Window Block (WB) exists for each active access to files on
a mounted volume.
It contains the context for the virtual
patch used for validating I/O requests and converting virtual
functions to logical functions.
For disks, the WB consists
of pointers to contiguous areas on the device.

An FCP is a data structure specific to the Files-11 disk
(FllACP).

ACP

It is used to control access to the file.

1. In mapped systems, a copy of the task header (located in the task's
par ti ti on)
is made in the Executive's dynamic storage reg ion.
The
Executive then uses this copy.
To access the current information in
this copy, a task must be privileged and have mapping to the
Executive.

2-19

THE RSX-llM I/O SYSTEM--PHILOSOPHY AND STRUCTURE
4.

$DEVHD is a word located in system common (SYSCM) and is the
other independent entry in the I/O data structure. $DEVHD
points to a singly linked, unidirectional list of Device
Control Blocks
(DCBs). Each device type in a system has at
least one associated DCB. The DCB list is terminated by a
zero in the link word.
Linked to each DCB is a Driver Dispatch Table (DDT), which is
part of the driver. The DDT contains the addresses of the
driver's four entry points that the Executive can call.

A key data structure is the Unit Control Block (UCB).
All
the UCBs associated with a DCB appear in consecutive memory
locations. During internal processing of an I/O request,
most drivers set RS to the address of the related UCB.
It is
by means of pointers in the UCB that other control blocks in
the data structure are accessed.
In particular, the UCB
contains pointers to the DCB, SCB, VCB, and to the UCB to
which it may have been redirected.
If a Redirect command has
not been issued for the device-unit, the UCB redirect pointer
points to the UCB itself. When servicing a request for one
of its UCBs, the driver is unaware of whether I/O was issued
directly to its own UCB or to a UCB that had been redirected
to its UCB.

One Status Control Block (SCB) exists for each controller in
a
system.
A
unique
SCB
must
exist
for
each
controller/device-unit capable of performing parallel I/O.
The SCB contains the fork-block storage required when a
driver calls $FORK to transfer itself to the fork-processing
level.
The I/O request queue listhead is also contained in
the SCB. Generally, register R4 contains the address of the
SCB during processing of an I/O request.

One Volume Control Block (VCB) exists for each mounted volume
in a system.
The VCB maintains volume-dependent control
information.
For Fi]es-11 disks, the VCB contains pointers to the File
Control Definition Block (FCB) and Window Block (WB), which
control access to the volume's index file.
(The index file
is a file of file headers.) The WB for the index file serves
the same function as the WB for a user file.
(See the
IAS/RSX-11
I/O
Operations
Reference
Manual for more
information ol1the index file.} All unique FCBs for a volume
form a linked list emanating from the index file FCB. This
linkage aids in keeping file access time short.
Further,
since the window that contains the mapping pointers is
variable in length, the user can increase file access speed
by adding more access pointers (greater speed requires more
main memory) to whatever extent the application requires.

2.7.1

Data Structures Summary

As the writer of a conventional driver, you do not manipulate the
entire I/O data structure.
In fact, you are usually involved only
with the I/O packet, the UCB, and the SCB. The entire structure has
been presented to add depth to your understanding of the I/O system,
to emphasize the relationships among individual control blocks, and to
clarify further the role a given driver fulfills in the processing of
an I/O request.

2-20

CHAPTER 3
INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

If you want to support an I/O device for which DIGITAL has not
supplied a driver, you can write your own driver.
Although this
manual has not yet presented explicit details for writing such a
driver,
you now have enough conceptual
information to consider
incorporating one of your own drivers into your system.
As will be
seen, many considerations for writing a driver are best presented in a
discussion of incorporating one.
NOTE
An alternative approach to writing your
own device driver may be the CINT$
(Connect to Interrupt Vector) directive.
Refer to the description of the CINT$
directive
in
the
RSX-llM/M-PLUS
Executive
Reference
Manual.
For
examples of the use of CINT$,
examine
the
task-level support routines for
K-series laboratory peripheral modules,
as
described
in Chapter 22 of the
RSX-llM/M-PLUS I/O Drivers
Reference
Manual.
~-

3.1

OVERVIEW OF INCORPORATING USER-WRITTEN DRIVERS

How you incorporate a user-written driver
into the system depends
mainly on whether you make your driver loadable or resident.
If your
driver is loadable, its data base can be either loadable or resident.
If your driver
is resident, both its data base and its code are
resident. Thus, because you build the Executive image during system
generation, you must include all
resident driver elements in the
Executive image during system generation.
If your driver is loadable
and has a loadable data base, you can incorporate it at any time after
you build the ·Executive under which the driver runs.

3.1.1

System Generation Support for User-Written Drivers

During system generation, you answer questions concerning the types
and quantity of peripheral devices on your system. Based on your
answers,
SYSGEN creates a single source
file
SYSTB.MAC
that
constitutes the data base definitions for DIGITAL-supplied devices on
the system. Also created are the object modules of driver code to
support
the devices;
Assembling
SYSTB.MAC creates vuc module,

3-1

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
SYSTB.OBJ, which becomes the system device tables for the Executive
and the data base for the system drivers.
This module is linked into
and becomes a permanent part of the Executive.
A privileged system task invoked with the MCR/VMR LOA command
is
responsible for loading
into memory a driver that is not resident.
The LOA function creates the necessary interrupt control blocks
(ICB)
for accessing a driver in a mapped system, and establishes the linkage
between the data base structures in the system device tables and the
driver code being loaded. Another privileged system task invoked with
the MCR/VMR UNL command can remove a loadable driver from memory.
(Although the UNL function removes a loadable driver, it does not
remove a loadable data base.)
SYSGEN asks questions concerning the necessary driver support features
in the Executive, to allow you to add user-written drivers.
During the Target Configuration section of SYSGEN Phase I, answer the
following question with the highest vector your system will use with
the addition of your user-written driver:
14. Highest interrupt vector [O R:0-774 D:O]:
SYSGEN uses the specified address or 400, whichever is greater, to
allocate sufficient vector space in the Executive to avoid run-time
destruction of the system stack and to avoid hardware trapping
(which
occurs when the SP goes below 400}.
If any user-written driver is to be built loadable, SYSGEN must be
notified of this fact.
Loadable drivers require extra Executive
features to support them
(for example, the MCR/VMR LOA and UNL
commands).
You can choose support for loadable drivers by answering
the following question in the Executive Options section of SYSGEN
Phase I:
15. Loadable device drivers?

[Y/N]:

The answer to the following question determines whether SYSGEN
you to include a user~written driver in the system:
25. Do you intend to include a user-written driver?

allows

[Y/N]:

If you answer Yes, the next two questions are also asked (see
5.3 of this manual}:

Section

26. Include routine $GTWRD? [Y/N]:
27. Include routine $PTWRD? [Y/N]:
NOTE
If an LPAll device (LA:} is included in
your
system, the $GTWRD routine is
automatically included and Question 26
is not asked.
If an ADOl A/D controller
device or an AFCll A/D controller device
(AF:}
is included in your system, the
$PTWRD routine is automatically included
and Question 27 is not asked.
The
$GTWRD and $PTWRD routines are described
in Chapter 5 of this manual.
To incorporate a user-written driver into RSX-llM, you first create
two modules, one in which you define the data base and the other in
which you include the driver code itself. You then must link your

3-2

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
driver data base and driver code modules into the system de¥ice
tables in the Executive. The linkage that your data base module must
satisfy is the link of the Device Control Block
(DCB)
list.
The
linkage for the driver code connects the DCB for the device that your
driver supports to the Driver Dispatch Table (DDT). Moreover, if your
driver is loadable, you must supply in your driver code symbols and
labels that the LOA command needs.
If your driver is loadable and has a loadable data base, you build (1)
a loadable image containing the driver code module follow~d by the
driver data base module, and (2) a symbol definition file on which the
LOA command depends to find critical data base and driver locations.
You build the driver image with the symbol definition file of the
Executive under which the driver runs.
However, the driver image is
separate from the Executive image. The LOA command is responsible for
loading both your driver data base and driver code, for connecting the
data base to the system device tables, and for connecting your driver
code to the data base.
If your driver is loadable but has a resident data base, you must
perform SYSGEN and build the Executive under which the driver runs to
link your driver data base module(s) into the system device tables.
This operation makes your driver data base resident with the system
device tables. You also build (1) a loadable image containing the
driver code, and
(2) a symbol definition file which the LOA command
uses to locate the driver dispatch table.
The LOA command
is
responsible for loading your driver code and for connecting your
driver code to the data base that is resident with the system device
tables.
If your driver is resident, you must perform a system generation and
build the Executive to link the driver data base into the system
device tables and to include the driver code in the Executive image.
Because the LOA command provides consistency and validity checks on a
data base being loaded, DIGITAL recommends that you make your driver
and its data base loadable.
Furthermore, with a loadable driver and
loadable data base, you can more easily modify your driver and its
data base.
You need not rebuild your Executive and privileged tasks.
To change the driver code, you need only build a new driver image,
unload the current version, and reload the new version. To change the
driver
data
base, you must build a new driver image
(which
incorporates the data base module), rebootstrap your system, and load
the new driver to load the modified data base.
(You must bootstrap
your system to change the data base because the UNL command does not
unload a data base, and because the LOA command does not load a data
base for a driver if one is currently loaded for that driver.)
NOTE
If you use VMR to load the data base
into the system image,
rebooting the
system will always load the data base.
Using a loadable driver with a loadable data base may make more work
in the short term but saves work in the long term.
During debugging,
data base inconsistencies are likely to be caught by the LOAD command.

Thus,

you

prevent

many

such

errors

from

later

creating

system

problems. The procedure to make your driver operational
is more
complex because both the driver (and its data base) must be loaded
each time the system starts up.

3-3

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
A resident driver or a loadable driver with a resident data base is
easier to incorporate into the system but more difficult to debug and
to modify. The LOA command does not perform consistency and validity
checks on a resident data base.
Thus, a debugging aid is not
available. Moreover, to modify such drivers, you must rebuild the
Executive, which generally implies rebuilding the privileged tasks.
The capability to incorporate a user-written driver into your system
is a supported feature of RSX-llM. Because a user-written driver is
considered a system modification, DIGITAL may not support the system
that results after you incorporate your driver. Being a part of the
Executive, your driver can subtly corrupt it.
Therefore, DIGITAL
cannot guarantee support which entails debugging user-written drivers.
Fixing a problem in a system is largely a matter of being able to
reproduce the problem reliably. If a problem on your system can be
shown to have no relation to your driver, and DIGITAL will reproduce
the problem, SPR support can be provided. A good reason for using a
loadable driver with a loadable data base is that you can more easily
test an unmodified system by not loadirig your driver and its data
base. You can then reproduce a suspected problem in an unmodified
system and can submit an SPR that DIGITAL will answer. Therefore,
attempting to re-create a suspected problem on your system without
your driver and its data base saves both you and DIGITAL time in
answering the SPR.

3.1.2

Overview of User-Written Driver Code

To create the
following:

source

code

drive

device,

you

must

the

device

and

Thoroughly read and understand this manual.

Familiarize yourself in detail with the physical
its operational characteristics.

Determine the level of support required for the device.

Create the data base source code for the device.

Determine actions to
points:
•

Initiator

•

Cancel I/O

•

Time-out

•

Powerfail

•

Interrupt

taken

3-4

the

five

driver

entry

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

Create the driver source code. This code will contain the
following
global symbols
(where xx is the 2-character
alphabetic device mnemonic):
$xxTBL::

Address of the driver
Section 4.1.2.1)

$xxINT::

Address of the driver interrupt entry point

$xxINP::
$xxOUT::

Addresses of input and output
interrupt
entry points (for full-duplex devices)

dispatch

table

(see

If a loadable driver's loadable data base is to include the
interrupt vector(s) for the case when the driver is resident,
the conditional assembly symbol LD$xx must be included in the
source code for the -loadable data base.
In addition, the
code in the data base which includes the interrupt vector(s)
must be enclosed in a conditional assembly block and defined
as an ASECT.
Loadable drivers have an additional requirement.
Either
within the driver source code itself or in file RSXMC.MAC,
the conditional assembly symbol LD$xx must be defined.
The
INTSV$ macro
(see Section 4.3) uses this symbol (and others
in RSXMC.MAC) to determine whether the call to $INTSV should
be omitted from the driver.
The symbols used to name interrupt entries are different for
devices that employ error logging. See the RSX-llM/M-PLUS
Error Logging Reference Manual for information on modifying
device drivers for error logging. Note that the error logger
must be modified to log errors for a device that uses a
user-written driver.
The DIGITAL-supplied terminal driver {TTDRV) is treated as a
special case by the LOA command in terms of the naming of its
interrupt entries.

3.1.3

Overview of User-Written Driver Data Bases

Of the data structures associated with an
assembly source code:
e

The DCB

The UCB(s)

•

The SCB(s)

•

The device interrupt vector
resident drivers only)

3-5

I/O

driver,

four

require

(assembly

source

required

for

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
A single DCB can service multiple UCBs and SCBs.
The existence of
multiple UCBs and SCBs is determined by the actual device subsystem
being supported by a given driver in your hardware configuration.
Figures 2-2,
2-3, and 2-4 illustrate possible DCB, UCB, and SCB
structural relationships.
Within the DCB, UCBs, and SCBs, only those fields that are static or
that need initialization must be supplied in your assembly source.
Tables 3-1, 3-2, and 3-3 list these required fields.
See Chapter 4
for detailed figures and descriptions of these and other data
structures.
Table 3-1
Required DCB Fields
Off set

Description

D. LNK

Link to next DCB. This field is zero if this is the
last
(or only)
DCB.
If you are incorporating more
than one user-written driver at one time, then this
field should point to another DCB in a DCB chain.

D.UCB

Address of the first word (U.DCB) of
associated with this DCB.

D.NAM

Two-character ASCII generic device name.

D.UNIT

Highest and lowest logical unit numbers controlled by
this DCB.

D. UCBL

Length of the UCB (including prefix words,
if any).
If a given DCB has multiple UCBs, all UCBs must be of
the same length.

D.DSP

Address of the driver dispatch table.
The dispatch
table is located within the driver code. This field
contains a global reference to the label associated
with this table. The field is zero if the driver is
loadable.

D.MSK

I/O function masks.
You must supply bit-by-bit
mapping for these four I/O function masks. Note that
the format of the mask words is split into two groups
of four words.
Functions 0-15. are covered by the
first group, and functions 16.-31. by the second.

D.PCB

Address of driver Partition Control Block
(PCB).
This field
is required only if loadable driver
support is included in the system.
It must be
initialized to zero.

3-6

the

first

UCB

INCORPORATING USER-WRITTEN DRIVERS INTO RSX=llM

Table 3-2
Required UCB Fields
Offset

Description

U.DCB

Backpointer to the associated DCB

U.RED

Redirect pointer--initially contains the
this UCB

address

U.CTL

Control bits that must be established by
writer with the UCB source

the

U.STS

Unit status byte

U.UNIT

Physical unit number serviced by this UCB

U.ST2

Unit status byte extension

U.CWl

Characteristics word l;
Section 4.1.4.1) applies

U.CW2

Driver-dependent

U.CW3

Driver-dependent

U.CW4

Default buffer size

U.SCB

Address of the SCB for this UCB

U.ATT

TCB address of attached task

standard

description

driver
I

(see

Table 3-3
Required SCB Fields
Offset

Description

S. LHD

I/O queue listhead

S. PRI

Priority of interrupting source

S. VCT

Interrupt vector address divided by 4

S.ITM

Initial timeout count

S.CON

Controller index
multiplied by 2)

S.STS

Controller status

S.CSR

Address of control and status register

S.FRK

Fork block

S.MPR

Mapping register block; needed only by UNIBUS NPR
devices running on a PDP-11 processor that employs
extended-addressing {22=bit) mode

(that

3-7

is,

controller

number

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
3.2

USER-WRITTEN LOADABLE DRIVERS

In deciding whether the data base for your loadable driver should
resident or loadable, consider the following characteristics
loadable data bases:
•

be
of

When you load a driver, the MCR/VMR LOA command checks to see
whether a data base is resident for the type of device whose
driver is being loaded. If a data base is not resident, the
LOA command reads the driver symbol definition file to find
the start and end of the data base in the driver image.
(Thus, if your driver data base is to be loadable, you must
have defined its start and end in the data base source code.)
Knowing the start and end, the LOA command reads the data base
from the driver image. The LOA command places the data base
in the system pool so that it resides in Executive address
space, accordingly relocates pointers and links within the
data base to be valid Executive addresses, and also connects
DCB(s)
in the data base to the system device
tables.
Moreover, ·the LOA command performs many consistency and
validity checks on the data base being loaded so as to prevent
the system device tables from being corrupted by an incorrect
data base.

loadable data base is only loaded once; thereafter, it is
• Aresident
until the system is bootstrapped again. The UNL
command do~s not remove a data base from memory
the data base was loaded with the LOA command.
•

even

though

The LOA command relocates certain known pointers within the
control blocks.l If the data base requires relocation of
additional address pointers beyond the standard ones, it
cannot
be
loaded
with the LOA command.
It must be
incorporated into the system as a resident data base during
system generation.

During debugging of a loadable driver (with loadable data base), you
can correct errors in the coding of the driver itself by unloading,
modifying, assembling, task-building, and reloading the
driver.
However, if the data base must be replaced, the system must be
bootstrapped to remove it.
You can then modify, assemble, and
task-build the data base, and reload it along with the {corrected)
driver.
The subsections below describe
user-written loadable driver.

3.2.1

the

procedure

for

incorporating

Creating the Loadable Data Base and Driver Modules

The general procedure for incorporating
loadable data base is as follows:
1.

loadable

driver

with

Complete SYSGEN Phase I and answer the appropriate questions
that include the necessary driver support features in the
Executive. Edit the assembly prefix file RSXMC.MAC and
define a conditional symbol LD$xx for each loadable driver.
See Section 3.1.1 for a discussion of system generation
support.

1. The pointers are:
(DCB) D.LNK, D.UCB;
(UCB) U.DCB, U.RED, U.SCB.
(SCB) S.LHD+2.
Chapter 4 gives details on these and other fields in
the data base.
3-8

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

Complete SYSGEN Phase II.
During Phase II you must edit
RSXBLD.CMD,
the Executive build command file (see Section
3.3), and add the following line:
GB LDEF=$USRTB: 0
(The symbol $USRTB in the file [11,lO]SYSTB.MAC defines the
link word to a user-written driver's resident DCB. Adding
this line forces the link word to be zero.) If you do not add
this line when you do not have a resident data base, the Task
Builder generates an undefined symbol error when it builds
the Executive.
However, you can disregard that error because
the Task Builder sets the contents of the link word to zero.

After SYSGEN Phase II completes, you can manually
driver.

After completing these steps, you can assemble
base at any time.

the

driver

build

the

and

data

While both the loadable driver and
its data base can be
contained
in the same source module, it is recommended that
you create separate sources for your driver and its data base
and place them in UFO [11,10].
If, however, you place both
the data base and the driver in the same module, you must
ensure that, when linked, the data base follows the driver
code.
You can do this by physically placing the data base
code after the driver code or by using .PSECT names to force
proper allocation.

A useful convention is to name your data base source xxTAB
and your driver source xxDRV, where xx is the 2-character
(alphabetic) device mnemonic.

You must place the DCB first in the assembly source code df
the driver data base module.
In a multiuser protection
system, the DCB must be followed
first by the associated
UCB(s)
and then by the SCB(s). All UCB(s) associated with a
particular DCB must be contiguous.
DIGITAL-supplied drivers
use this ordering scheme;
see the file [11,lO]SYSTB.MAC,
created by Phase I of SYSGEN, for examples.
Since you are
creating a loadable data base for a single driver, your
source code will contain a single DCB with associated
UCB(s)
and SCB ( s) •

The global label $xxDAT:: marks the start of your driver's
data base
(the DCB). The global label $xxEND:: marks the
end of the data base
(that is,
immediately following
the
final word of the data base).
These labels are absolutely
required.
The letters xx represent the
2-character device
mnemonic.

To assemble your driver, set the default UIC to [ll,2x]
assembler as follows (user input underlined):

and

run

>SET /UIC=[ll,2x]~
>MAC~

MAC>xxDRV,xxDRV=LB: [l,l]EXEMC/ML,LB: [11,lO]RSXMC,xxDRVIBIT)
To assemble the data base, use the following input to MAC:
MAC>xxTAB,xxTAB=LB: [l, l]EXEMC/ML,LB: [11, lO]RSXMCl,xxTAB ~

3-9

the

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
Next, you use the following command to add both the
data base to the Executive object module library:

driver

and

its

LBR>LB: [l,2x]RSXllM/RP=[ll,2x]xxDRV,xxTAB~

3.2.2

Task-Building a Loadable Driver

In this section, two examples of task-building a loadable driver with
a loadable data base are presented: one for a mapped system and one
for an unmapped system.

3.2.2.1 Task-Building a Loadable Driver on a Mapped System - The
following seven requirements apply to task-building any loadable
driver, whether user-written or DIGITAL-supplied.
1.

You must specify a task image file name and a symbol
definition file name as TKB output.
Both files must be
placed in the UFO corresponding to the system UIC that will
be in effect when the command is issued. The file names must
both be xxDRV, where xx is the device mnemonic.
The Task
Builder produces output files named xxDRV.TSK and xxDRV.STB.
For example, the beginning of input to TKB to build a
paper-tape reader driver for a mapped system might appear as
follows (user input underlined):
>TKB~
TKB>[l,54]PRDRV/-HD/-MM,,[l,54]PRDRV=~

Task image. Switches: see
items 2 & 3
below.

Symbol
definition.

You must not have a task header. Use the switch /-HD, as in
the example above.
A driver is not really a task but an
extension of the Executive, and as such needs no task header.

You must use the /-MM switch, whether in fact the
destined for a mapped or an unmapped system.

driver

You must link to the system symbol definition
contains definitions of Executive global symbols.
the paper-tape reader driver example referred
further TKB input might look like this:

file that
Continuing
to above,

TKB>LB: [l,24]RSX11M/LB:PRDRV:PRTAB~
TKB>[l,54]RSX11M.STB/SS~

The first line above specifies the library file (/LB)
in
which the input driver object module and the object file for
the loadable data base can be found.
The object module
specification
for
the driver must always precede the
specification for the data base in the TKB command line.,
You omit the data-base file specifier when task-building any
DIGITAL-supplied driver or one of your own drivers if it has
a resident data base. All DIGITAL-supplied drivers that are
declared loadable at system generation use resident data
bases.

3-10

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
The second line in item 4 above indicates that the symbol
table file RSXllM.STB is to be searched selectively (/SS) for
definitions of Executive global symbols. Note that the /SS
switch must appear in this context. It cannot be omitted.
You must link to the system library file that defines masks
and offsets used in the Executive. Continuing the example:

TKB >LB: [ 1, 1] EXEL IB/LB (6TI)
TKB> / (6TI)
The single slash begins the option phase of the Task Builder.
The driver code will execute as a part of the Executive, and
thus the driver will use the Executive stack. Therefore, you
must direct the Task Builder not to allocate space for a
stack within the driver, as follows:

TKB >STACK=O ~
You must specify a partition
for
the
driver.
The
specification
differs for mapped and unmapped systems.
Continuing the mapped-system example:

TKB>PAR=DRVPAR:l20000:4000(BTI)
T KB >I I (6TI)

On mapped systems, the starting address of the partition must
be 120000 octal. That is, the loadable driver must be mapped
to kernel APR 5.
On unmapped systems, the second parameter
physical starting address of the partition.

must

the

On either mapped or unmapped systems, the length of
partition may not exceed 4K words (20000 octal bytes).

the

The double slash terminates the Task Builder's input.

3.2.2.2 Task-Building a Loadable Driver on an Unmapped System - In
the example below, we build a magtape driver for an unmapped system.
The only differences from the mapped-system example are the partition
starting address and the UFD of some of the files ([1,50] and [1,20]
instead of [l, 54] and [l, 24], respectively).
>TKB~

TKB > [ 1, 50] MTDRV/-HD/-MM,, [ 1, 50] MTDRV= tBTIJ
TKB>LB: [l,20]RSX11M/LB:MTDRV:MTTAB(BTI)
TKB > [ 1, 50] RSXllM. STB/SS ~
TKB>LB: [l, l] EXE LIB/LB~
TKB>/ ffi)
ENTER OPTIONS:~
TKB>STACK=O ffiJ
TKB>PAR=DRVPAR:34000:4000ffil
TKB>//~

3-11

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
3.2.3

Loading a User-Written Loadable Driver

Loading is done by using the privileged MCR command LOA.

Its form is:

LOA xx: [/PAR=partition]
where xx is the 2-character device mnemonic.
Specifying a partition
is optional.
If none is specified, the partition input to the Task
Builder is used.
The LOA command requires that the two files xxDRV.TSK and xxDRV.STB
reside under
the system UFD {that is, the UFD established by the SET
/SYSUIC command).
Typically, this UFD is [l,50] for unmapped systems
and [1,54] for mapped systems.
LOA searches first for a resident data base for
the driver being
loaded.
If none is found, LOA looks for the following global symbols
in the symbol definition file xxDRV.STB:

3.2.4

$xxDAT::

Address of the start of the data
associated with the driver

$xxEND::

Address+2 of the last word
associated with the driver

base

(the

DCB)

the

data

base

Creating the Loadable Driver and Resident Data Base Modules

If you decide upon a resident data base, you create the data base
object module during
SYSGEN Phase I.
You use the same procedure as
that for a resident driver.
To create the resident data base, follow the procedure described
in
Section 3.3 with the exception of initializing the device interrupt
vector.
Since there is only one resident data base module
(USRTB,
which contains all the resident data bases), you assemble the resident
data bases for loadable drivers with the
resident data bases for
resident drivers.
To assemble the loadable driver, use the following command to MAC:
MAC>xxDRV,xxDRV=LB: [l, l]EXEMC/ML,LB: [11, lO]RSXMC,xxDRV@

3.2.5

Building a Loadable Driver and Its Resident Data Base

You build all resident data bases into the Executive as described
in
Section 3.3.
You build the loadable drivers after the Executive is
built. When SYSGEN asks the following question during Phase II:
5. Driver 2-character device mnemonic [S]:
enter the characters xx, where xx is the driver name.
After your system is built, you can load your driver as
Section 3.2.3.

3-12

described

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
3.3

USER-WRITTEN RESIDENT DRIVERS

This section describes
drivers.

specific

details

for

user-written

resident

Create the assembly source file for the resident data base in
UFD [11, 10].
Use USRTB.MAC as the file specification.
USRTB
as the file name is not actually required.
It is, however, a
useful convention -- as reflected
in the sample dialogue
described below.

There is no mandatory ordering of the different control
blocks in the data base. for your resident driver.
It is
suggested that you follow the convention of placing the DCB
firstt
followed by the UCB(s), followed by the SCB(s).
However, it is required that all
UCB{s)
associated with a
particular DCB must be contiguous.
DIGITAL-supplied RSX-llM
drivers use this ordering scheme;
see the file
[11,10]
SYSTB.MAC,
created by Phase I of SYSGEN, for examples~
If
you are incorporating multiple resident drivers into your
system, you will have more than one instance of a DCB with
UCB ( s) and SCB ( s) •

Initialize the device interrupt vector
4.1.5 for a description of this process).

Use the global label $USRTB:: as the address of
(or only) DCB. This is absolutely required.

{refer

Section

your

first

During Phase I, SYSGEN asks:
25. Do you intend to include a user-written driver? [Y/N]
If you answer Yes, then subsequent questions guide you through the
process of adding the driver to the generated system.
Refer to
Section 3.1.1 for a discussion of system generation support and the
questions asked.
Operations performed include assembling the driver
and its data structure, and editing the RSX-llM task-build command
file.
The following sample dialogue illustrates the addition of a
resident
driver for a PK: device. All user responses are underlined. After
SYSGEN assembles the DIGITAL-supplied drivers,
it
prints
some
instructions, then pauses to allow you to assemble your driver(s), as
follows:

>; Assemble user-written driver(s)
>;
>;
The following instructions apply to resident drivers and
loadable drivers with resident data bases.
>;
>;
For loadable drivers, you must ensure that a symbol definition
>;
>;
of the format:
>;
LD$xx=O
(where xx is the device name) appears in the assembly prefix
>;
>;
file [11,lO]RSXMC.MAC for each loadable driver xxDRV.

3-13

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

>;
>;
>;
>;
>;
>;

>;
>;

SYSGEN will now pause to allow you to assemble your drivers(s)
and USRTB module. Using a driver name xxDRV (where xx is
the device name; for example, DK), you can type commands
in the following format to assemble the driver and USRTB
modules.

>;
>;
>;

MAC
MAC>xxDRV=LB: [l,l]EXEMC/ML,SY: [11,lO]RSXMC,xxDRV
MAC>USRTB=LB: [l, l]EXEMC/ML,SY: [11, lO]RSXMC,USRTB
MAC>"Z

AT.

PAUSING. TO CONTINUE TYPE "RES ••• AT."

>MAC 00)
MAC>PKDRV=LB: [l,l]EXEMC/ML,SY: [11,lO]RSXMC,PKDRV fil!)
MAC>USRTB=LB :. [ 1, 1] EXEMC/ML, SY: [11, 10] RSXMC, USRTB fil!)
MAC>~

>RES ••• AT.00)
AT. -- CONTINUING

>
After you exit from MACR0-11 and type the command
finishes Phase I.

resume,

SYSGEN

When you start Phase II, SYSGEN asks a
few questions, prints some
instructions, and pauses for you to build the driver(s) as follows:

>;
>; Build user-written driver(s)

>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;
>;

You must now edit the Executive build command file RSXBLD.CMD
to include your user-written driver and data base in your system.
If you are including a resident data base, locate the line
in which the module SYSTB is referenced and add :USRTB
immediately after it, for example:
LB: [l,24]RSX11M/LB:SYSTB:USRTB:SYTAB:INITL,LB: [l,l]EXELIB/LB/SS
If you are not including a resident data base, add the line
GB LDEF=$USRTB: 0
to the file instead.
For each resident driver, add a line of the form:
LB: [l,24]RSXllM/LB:xxDRV
where other drivers are referenced (where xx is the device name,
for example DK).
NOTE:
For each loadable driver, do not add a corresponding
line to the build command file

>;
>;
>;
>;

SYSGEN will now pause to allow you to edit RSXBLD.CMD.
After you exit from the editor and resume, SYSGEN builds the
Executive and drivers.

AT.

PAUSING. TO CONTINUE TYPE "RES ••• AT."

>EDI RSXBLD.CMDfil!l
[00028 LINES READ IN]
[PAGE
1]
*L SYSTBfil!)
LB: [l,24]RSX11M/LB:SYSTB:SYTAB:INITL,LB: [l,l]EXELIB/LB/SS
*C /SYSTB:/SYSTB:USRTB:/~
3-14

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
LB: [l,24]RSX11M/LB:SYSTB:USRTB:SYTAB:INITL,LB: [l,l]EXELIB/LB/SS
*L DYDRVID
[ *EOB*]
*T lBITJ
*L DYDRV lBIT)
LB: [l,24]RSX11M/LB:DYDRV
*1..ID
LB: [l,24]RSX11M/LB:PKDRV
*EX lBIT)
[EXIT]
>RES ••• AT.lBIT)
AT. -- CONTINUING
After you perform the indicated operations and type the command to
continue with SYSGEN, the Executive is built and you are given a
chance to build any loadable drivers as follows:
>; Build Loadable drivers

>;
>*

4. Build all selected loadable drivers into DRVPAR? [Y/N]:Y

>;
>; You can now build your user-written driver (if it is a loadable
>; driver). If you choose not to build it now, or it is not loadable
>; strike carriage return in response to the next question.

>;
>; When all drivers are built, strike carriage return

>;
>* 5. Driver 2-character device mnemonic [S]:
When Phase II completes, your resident driver is incorporated
Executive and is ready to run.

3.4

the

DRIVER DEBUGGING

Because the protection checks provided for user programs are not
available to system modules, driver errors are more difficult to
isolate than user-program errors. But conventional drivers, because
they are modular and short, probably can be easily debugged. This
debugging process requires that you understand the following topics,
each of which is discussed in a separate subsection:
•

Debugging aids and tools

•

Fault isolation

•

Fault tracing

•

Rebuilding and reincorporating a driver

3-15

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
3.4.1

Debugging Aids

Adding a user-written driver carries with it the risk of introducing
obscure bugs into an RSX-llM system.
Since the driver runs as part of
the Executive, special debugging tools are both desirable
and
necessary.
RSX-llM
provides several such aids, which can be
incorporated into your system during system generation:
•

Executive stack and register dump

XDT

•

Panic dump

•

Crash Dump Analyzer {CDA) support routine.

You need not select any of this software during system generation.
If, however, you do require the facilities they offer, you can select
from one to three of them for incorporation in your system {panic dump
and the CDA support routine are mutually exclusive). The following
subsections describe the features and use of each debugging aid.

3.4.1.1 Executive Stack and Register
Dump Routine - At
system
generation, you can indicate that you want a dump of the Executive
stack and the registers when a crash occurs.
If you choose this
option, the system will perform as follows:
1.

A system error, or the XDT X command {described in the next
section), or operator manipulation of the switch register
following a CPU halt, will cause processing to resume at
location 40{octal).

Location 40(octal) contains a JMP instruction that causes the
Executive to execute the code beginning at location $CRASH.

$CRASH invokes the routine that dumps the Executive stack and
registers as shown below:
SYSTEM CRASH AT.LOCATION 047622
REGISTERS
R0=000340 Rl=l77753 R2=000353 R3=000000
R4=000004 R5=046712 SP=000472 PS=000340
SYSTEM STACK DUMP
LOCATION CONTENTS
000472
000474
000476
000500
000502
000504
000506
000510
000512

000004
000000
001514
000340
177753
000353
000000
000000
057750

3-16

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
000514
000516
000520
000522
000524
000526
000530
000532
000534
000536
000540
000542

002504
030011
100340
000340
056446
000000
102144
000000
1013 76
101372
102022
170000

Following this display, either the CDA support r.outine or panic dump
is invoked, depending on wn1ch (if either) is present in the system.
Otherwise, the system halts.

3.4.1.2 XDT - The Executive Debugging Tool - An interactive debugging
tool has been developed for RSX-llM to aid in debugging Executive
modules, I/O drivers, and interrupt service routines.
This debugging
aid,
called XDT,
is a version of the RSX-11 Octal Debugging Tool
(ODT).
XDT does not contain the following
features and commands
available on ODT:
No $M

- (Mask) register

No $X -

(Entry Flag)

registers

No $V -

(SST vector)

registers

No $D -

(I/O LUN) registers

No $E

- (SST data) registers

No $W -

(Di rec ti ve Status Word) $DSW word

No E

- (Effective Address Search) command

No F

- (Fill Memory) command

No N

- (Not word search) command

v -

(Restore SST vectors) command

w -

(Memory word search) command

In addition, the X (Exit) ODT command has been changed for XDT.
command causes a jump to the crash-reporting routine.

The X

Except for the omitted features and the change in ~e x __c..ommand,
XDT
is command-compatible with RSX-11 ODT; consequently, the IAS/RSX-11
ODT Reference Manual c_~.~ be 1:1sed as a guide to XDT o~e~ation.
XDT may be included in a system
following question is asked:

during

Phase

*30. Executive Debugging Tool (XDT)? [Y/N]:

3-17

SYSGEN.

The

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

If you answer Yes, then XDT is automatically included in the generated
system.
When the resultant system is bootstrapped, XDT takes control
and types on the console terminal:
XDT:

followed by the prompting symbol
XDT>
You can set breakpoints at this time, and then type the G command,
passing
control
to the RSX-llM Executive initialization code.
Whenever control reaches a breakpoint, a printout similar to that
produced by RSX-11 ODT occurs.
You can initiate a forced entry to XDT at any time from a privileged
terminal by means of the MCR BRK (breakpoint) command. Thus, the
normal procedure is to type G when the system is bootstrapped without
setting any breakpoints.
When it becomes necessary to use XDT, the
MCR BRK command is executed, causing a forced breakpoint.
XDT then
prints on the console terminal:
BE:xxxxxx
followed by the prompting symbol
XDT>
You can then set breakpoints and/or issue other XDT commands.
Continue system operation by typing the P (proceed) command to XDT.
Note that XDT runs entirely at priority level 7 and does not interfere
with user-level RSX-11 ODT.
In other words, user-level RSX-11 ODT can
be in use with several tasks, while XDT is being used to debug
Executive modules.
All XDT command I/O goes to and from the console terminal, and the L
(List Memory)
command can list on either the console or the line
printer.
Using XDT to debug a loadable driver on a mapped system
pitfalls.
One problem that can arise is a T-bit error:

has

special

TE:xxxxxx
XDT>
This error results when control reaches a breakpoint that you have
set, using XDT,
in a loaded driver on a mapped system. The T-bit
error, rather than the expected BE:
error, occurs unless register
APRS is mapped to the driver at the time XDT sets the breakpoint.
To avoid this T-bit error, assemble the driver with an embedded BPT
instruction, or use either the ZAP utility or the MCR OPE command to
set the breakpoint by replacing a word of code with the BPT
instruction.
When control reaches a breakpoint set in this manner,
XDT prints:
BE:xxxxxx
XDT>

3-18

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
Recover as follows:
Using XDT, replace the BPT instruction with the
desired instruction.
Decrement the PC by subtracting 2 from the
contents of register R7.
Then proceed by using the P or S commands.
NOTE
You should not set breakpoints in more
than one module that maps into the
Executive through APR 5 or APR 6.
In
particular, do not set breakpoints in
more than one loadable driver at a time
or XDT will overwrite words of main
memory when it attempts to restore the
contents of breakpoints.

3.4.1.3 Panic Dump - The Panic Dump routine saves registers
through R6 and then halts, awaiting dump limits to be entered.

The procedure for entering dump limits depends on whether your
processor has a console switch register.
The subsections that follow
describe the procedure in each instance.
3.4.1.4 Using the Panic Dump Routine on Processors with Console
Switch Registers - For processors with console switch registers, you
can obtain dumps of selected blocks of memory by using the following
procedure:
1.

Enter the low dump limit in the console switch register
press CONT.
The processor will immediately halt again.

and

Enter the high dump limit in the console switch register and
press CONT.
The dump .will begin on the device whose CSR
address is D$$BUG
(usually 177514, which is the
line
printer).
The actual value of D$$BUG is determined during
system generation when answering the panic dump question. At
the end of the dump, the processor will again halt, awaiting
the input of another set of dump limits.
If your system does not have the Executive routine stack and
register dump, enter the dump limits 0-520(octal) when the
Panic Dump routine first halts.
This causes dump of the
system stack and the general registers.
The limit 520(octal)
changes if the highest interrupt vector is above 400(octal).
The actual upper limit is always the value of the global
symbol $STACK and can be obtained from the global symbol
listing in the Executive memory allocation map.

3.4.1.5 Using the Panic Dump Routine on Processors Without Console
Switch Registers - A number of PDP-11 processors are being delivered
without a console switch register; they are configured with the M9301
Console Emulator and Bootstrap.
This presents no problem for the
normal operation of RSX-llM, because it does not require a switch
register.
However, the Panic Dump Routine usually reads its arguments
from the switch register.
In systems that have been generated for
processors that have no switch register, the panic dump module has

3-19

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
been altered to read its arguments from location O.
The following
instructions are designed to allow you to enter the proper information
to the Panic Dump Routine on processors equipped with the M9301
Console Emulator.
1.

When the Panic Dump Routine halts, the RUN light will go out.
At this time press and release the BOOT switch.
The Console Emulator should display:
XXXXXX XXXXXX XXXXXX nnnnnn
$

where nnnnnn is the address+2 of the HALT instruction.
2.

You should enter the following:
$L orui
$i)Tow-address~
$L nnnnnn~
$~ ~

The processor should again halt.
switch.

Press and release the

BOOT

The Console Emulator should display:
XXXXXX XXXXXX XXXXXX mmmmmm
$

You should then enter:
$L O~
$'Dhigh-addressrui
$L mmmmmm~
$_§_ rui

At this time the dump should commence.
When it
processor will halt and wait for additional input.

finished,

the

3.4.1.6 Sample Output from Panic Dump - A portion of the output from
Panic Dump is shown below.
Output is in 3-line groupings.
In the
left-hand column, two addresses are shown. The first address is the
absolute address;
the second address is the dump relative address.
The first line in a 3-line group gives the octal word value;
the
second line gives the two octal byte values of the word;
the third
line contains the ASCII representation of the bytes.
The ASCII
representations in each word are reversed to improve readability. The
first output grouping from Panic Dump shows, proceeding from left to
right,
the address/absolute address, PS, RO, Rl, R2, R3, R4, RS, and
the SP.
000544 000000 046076 000066 000000 000000 000000 000000 045316
000000 000 000 114 076 000 066 000 000 000 000 000 000 000 000 112 316
"@ "@
6 "@ "@ "@ "@ "@ "@ "@ "@ "@
N
J
> L
000000 022646 000340 045770 000340 045770 000340 045770 000340
000000 045 246 000 340 113 370 000 340 113 3 70 000 340 113 3 70 000 340
"@
"@
"@
"@
&
%
K
K
K

3-20

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
000020 045776 000340 011124 000340 045770 000340 0 50500 000340
000020 113 376 000 340 022 124 000 340 113 370 000 340 121 100 000 340
"@
"'@
"@
K
"@
T "R
Q
K
@
000040 000167 000543 000001
000001
000000 000000 000000 000353
000040 000 167 001 143 000 001 000 001 000 000 000 000 000 000 000 353
"@
"A "A "@ "A "@ "@ "@ "@ "@ "@ "@
"@
000060 035444 000340 034034 000340 032776 000340 032402 000340
000060 07 3 04 4 000 340 070 034 000 340 065 376 000 340 065 002 000 340
"@ "\
"@
"@ "B
"@
$
8
5
5

3.4.1.7 Crash Dump Analyzer Support Routine - The Crash Dump Analyzer
(CDA) support routine, when entered, prints the following message on a
notification device specified at SYSGEN:
CRASH - CONT WITH SCRATCH MEDIA ON device mnemonic
You can then put the secondary crash dump device on line and depress
the CONT switch on the operator's console.
The Executive Crash Dump
routine will dump memory to the crash dump device and halt the
processor upon completion.
The procedure for subsequently invoking the Crash Dump Analyzer, which
reads and formats the memory dump, is fully documented in the RSX-llM
Crash Dump Analyzer Reference Manual.

3.4.2

Fault Isolation

Four causes can be identified when the system faults:
•

A user-state task has faulted in such a way that it causes the
system to fault.

•

The user-written driver has faulted in
causes the system to fault.

•

The RSX-llM system software itself has faulted.

•

The host hardware has faulted.

such

way

that

When the system faults, you must immediately determine which of these
four causes is responsible.
This section presents some procedures
that can help you isolate the source of the fault.
Correcting the
fault itself is your responsibility.

3.4.2.1 Immediate Servicing - Faults manifest themselves in roughly
four ways
(they are listed here in order of increasing difficulty of
isolation):
1.

If XDT is included, an unintended trap to XDT occurs.

The system displays text indicating a crash has occurred
halts.

3-21

and

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
3.

The system halts but displays nothing.

The system is in an unintended loop.

The immediate aim, regardless of the fault manifestation, is to get to
a point where you can obtain pertinent fault isolation data.
The following discusssions assume the existence of a system built with
at least one of the debugging aids described in Section 3. 4.1.
(Note
that the minimal system does not have space for these routines.)
Case 1--The system has trapped to XDT:
The trap may or may not be intended (for example, a previously set
breakpoint).
If it is not intended, type the X command, causing XDT
to exit to location 40(octal), from which the Executive stack and
register dump routine (if present), followed by either Panic Dump or
the CDA support routine (if present) , wil 1 be invo,ked.
If, however,
you have some idea of the source of the problem (for example, a recent
coding change), then you can use XDT to examine pertinent data
structures and code.
Case 2--The system has displayed text indicating a crash has occurred:
If the text consists of output from the Executive stack and register
dump routine
(refer to Section 3.4.1.1), all the basic information
describing the state of the system has been displayed.
If the text
has been produced by the CDA support routine, follow the procedure for
obtaining and formatting a memory dump as outlined in the RSX-11 Crash
Dump Analyzer Reference Manual.
Case 3--The system has halted but displays no information:
Before taking any action, preserve the current PS and PC and the
pertinent
device
registers
(that is, examine and record the
information these registers contain). The procedure depends on the
particular PDP-11 processor.
Consult the PDP-11 Processor Handbook
for details.
After preserving the PS and PC, invoke your resident debugging aid:
enter 40(octal)
in the switch register, press LOAD ADDR, and then
press START.
The contents of 40(octal)
cause
the
successive
invocation of:
1.

The Executive stack and register dump routine (if present)

Either Panic Dump or CDA support routine (if present)

Case 4--The system is in an unintended loop:
Proceed as follows:
1.

Halt the processor.

Record the PC, the PS, and any pertinent device registers, as
in case 3 above.

You may then want to step through a number of instructions in an
attempt to locate the loop.
For this attempt to be meaningful you
must first disable the system clock. Proceed as follows:
Examine the
contents of word 777546 (if your system has a line-frequency clock) or
word 772540 (if it has a programmable clock). Clear bit 6 in this
word and redeposit the word.

3-22

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

NOTE
The system will not run until
reenabled the clock.

you

have

After trying to locate the loop and reenabling the clock, transfer
location 40(octal), as in case 3.

3.4.2.2 Pertinent Fault Isolation Data - Before you attempt to locate
the fault, you should dump system common (SYSCM). SYSCM contains a
number of critical pointers and listheads.
Find the appropriate
limits for the module SYSCM by examining the Executive memory
allocation map. ~n~er these limits to the Panic Dump routine or
specify them in the command line used to invoke the Crash Dump
Analyzer.
In addition, you should dump the dynamic storage region and the device
tables.
The dynamic storage region is the module INITL and any
additional space gained from the SET /POOL command and the device
tables are in SYSTB.
At this point, you have the following data:

• Processor Status Word (PSW)
• Program counter (PC)
• Stack
• RO through R6

• Pertinent device registers
• Dynamic storage region (pool)
• Device tables
• System common
These data are the minimum required for effectively tracing the fault.

3.4.3

Fault Tracing

Three pointers in SYSCM are critical in fault tracing.
are described below:

These pointers

$STKDP - Stack Depth Indicator
This data item indicates which stack was being used at the time
of the crash. $STKDP plays an important role in determining the
origin of a fault. The following values apply:
+1--User (task-state) stack
0 or less--System stack

3-23

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
If the stack depth is +l, then the user has crashed the system.
In a system with "brickwall" protection (for example, the mapped
RSX-llM system), the nonprivileged user should not be able to
crash the system.
$TKTCB - Pointer to the current Task Control Block (TCB)
This is the TCB of the user-level task in control of the CPU.
$HEADR - Pointer to the current task header.
The $HEADR word points to the header of the task currently
running.
The task header provides additional data to help
isolate a fault.
Figures 3-1 and 3-2 show the layout of task
headers for unmapped and mapped systems, respectively.
The first word in the header is the user's stack pointer (SP) the
last time it was saved.
If the user branches wildly into the
Executive, the Executive terminates the user task, but the system
continues to function (possibly erroneously).
Knowing the user's
stack pointer provides one more link in the chain that may lead
to the resolution of the fault.
The header (as pointed to by $HEADR) also contains the last-saved
register set, just before the header guard word (the last word in
the header--pointed to by H.GARD).
~

0
RO
R1
R2
R3

.
N

H.NLUN

I------'

H.GARD

...
H.HDLN

PC
RS

Length in bytes

R4
ZK-215-81

Figure 3-1

Task Header on an Unmapped System

3-24

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

R5
PC

H.NLUN
H.GARD

~N--w

H.HDLN

Length in bytes

SP
ZK-216-81

Figure 3-2

Task Header on a Mapped System

3.4.3.1 Tracing Faults Using the Executive Stack and Register Dump To trace a fault after a display of the Executive stack and register
contents, first examine the system stack pointer.
Usually
an
Executive failure is the result of an SST-type trap within the
Executive.
If an SST does occur within the Executive, then the origin
of the call on the crash-reporting routine is in the SST service
module.
(The crash call is initiated by issuing an IOT at a stack
depth of zero or less.)
A call to crash also occurs in the Directive Dispatcher when an EMT is
issued at a stack depth of zero or less, or a trap instruction is
executed at a stack depth of less than zero. The stack structure in
the case of an internal SST fault is shown in Figure 3-3.

3-25

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

PS
PC

RS
R4
R3
R2
R1
RO
Return to system exit
Zero or more SST parameters
SST fault code
Number of bytes

~------SP

ZK-217-81

Figure 3-3

Stack Structure:

Internal SST Fault

The fault codes are:
0
2

4
6
10
12
14
16
20
22
24
26

30
32
34

;ODD ADDRESS AND TRAPS TO 4
;MEMORY PROTECT VIOLATION
;BREAK POINT OR TRACE TRAP
; IOT INSTRUCTION
;ILLEGAL OR RESERVED INSTRUCTION
;NON RSX EMT INSTRUCTION
;TRAP INSTRUCTION
;11/40 FLOATING POINT EXCEPTION
;SST ABORT-BAD STACK
;AST ABORT-BAD STACK
;ABORT VIA DIRECTIVE
;TASK LOAD READ FAILURE
;TASK CHECKPOINT READ FAILURE
;TASK EXIT WITH OUTSTANDING I/0
;TASK MEMORY PARITY ERROR

The PC points to the instruction following the one that caused the SST
failure.
The number of bytes is the number normally transferred to
the user stack when the particular type of SST occurs.
If the number
is 4, then a non-normal SST fault occurred, and only the PSW and PC
are transferred.
There are no SST parameters.
If the failure is detected in $DRDSP, the stack is the same as that
shown in Figure 3-3, except that the number of bytes, the SST fault
code (the fault codes are listed above), and the SST parameters are
not present.
The crash report message, however, will indicate that
the failure occurred in $DRDSP.

3-26

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
One SST-type failure, stack underflow, does not result in the stack
structure of Figure 3-3. To determine where the crash occurred, first
establish the stack structure; this can be deduced by the value of
the SP and the contents of the top word on the stack.
If the stack
structure is that of Figure 3-3, then the failure occurred in $DRDSP,
or was a normal SST crash.
If the stack structure is that of Figure
3-4, then an abnormal SST crash has occurred.
~------SP

PC
ZK-218-81

Figure 3-4

Stack Structure:

Abnormal SST Fault

Abnormal SST failures occur when it is not possible to
push
information onto the stack without forcing another SST fault. When
this situation occurs, a direct jump to the crash-reporting routine is
made,
rather than an IOT crash. The PS and PC on the stack are those
of the actual crash, and the
address
printed
out
by
the
crash-reporting routine is the address of the fault rather than the
address of the IOT that crashes the system.
Note
that
the
crash-reporting routine removes the PC and PSW of the !OT instruction
from the stack, which in this case is incorrect. Thus, the SP appears
to be four bytes greater than it really is (as in Figure 3-4).
You now have all the information needed to isolate the cause of the
failure.
From this point on,
rely on personal experience and a
knowledge of the interaction between the driver and the services
provided by the Executive.

3.4.3.2 Tracing Faults When the Processor Halts Without Display - To
trace a
fault when the processor halts but displays no information
(case 3 in Section 3.4.2.1 above), first examine $STKDP,
$TKTCB, and
$HEADR.
The difficulty in tracing failures in this case is that the
system stack is not directly associated with the cause of a failure.
By examining $STKDP, you can determine the system state at the time of
failure.
If it was in user state, the next step is to examine the
user's stack. The examination focuses on scanning the stack for
addresses that may be subroutine links that can ultimately lead to a
thread of events isolating the fault.
This is essentially the aim of
looking at the system stack if $STKDP is zero or less.
Frequently, a fault can occur that causes the SP to point to the top
of the stack plus 4.
This fault results from issuing an RTI
instruction. The top two items on the stack are data.
The result is
a wild branch and then, most probably, a halt.
Figure 3-5 shows a
case in which two data
items are on the stack when the program
executes an RT! instruction. The top of the stack points to a word
containing 40100(octal).
If location
40100(octal)
contains a HALT
instruction, the original SP is four bytes below the final SP, and
fault tracing should begin from the original SP.

3-27

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM

-------SP
5
40100

--------SP
ZK-219-81

Figure 3-5

Stack Structure:

Data Items on Stack

This type of fault also occurs when an RTS instruction is executed
with an inconsistent stack.
However, in that case, SP points to
TOS+2.
A scan of the contents of the general registers may give some hint as
to the neighborhood in which a fault (or the sequence of events
leading up to the fault) occurred.
If the fault occurred in a new driver, a frequent source of clues is
the buffer address and count words in the UCB (U.BUF, U.BUF+2, U.CNT),
as are the activity flags (US.BSY and S.STS). Other locations in both
the UCB and SCB may also provide information that may help locate the
source of the fault.

3.4.3.3 Tracing Faults After an Unintended Loop - To trace a
when an unintended loop has occurred, first halt the processor.

fault

After you halt the processor, the same state exists as was discussed
in Section 3.4.3.2.
Follow the same tracing procedure described
there. A specific suggestion is to check for a stack overflow loop.
Patterns of data successively duplicated on the stack indicate a stack
looping failure.

3.4.3.4 Additional Hints for Tracing Faults - Another item to check
is the current (or last) I/O packet, the address of which is found in
S.PKT of the SCB.
The packet function
(I.FCN) defines the last
activity performed on the unit.
If trouble occurred in terminating an I/O request, a scan of the
system dynamic memory region may provide some insight. This region
starts at the address contained in $CRAVL, a cell in SYSCM.
Because
all I/O packets are built in system dynamic memory, their memory is
returned to the dynamic memory region when they are successfully
terminated.
Following the link pointers in this region may reveal
whether I/O completion proceeded to that point. In systems with QIO
optimization, $PKAVL (SYSCM) points to a list of I/O packet-sized
blocks of dynamic memory that are not linked into the $CRAVL chain.
A frequent error for an interrupt-driven device is to terminate an I/O
packet twice when the device is not properly disabled on I/O
completion and an unexpected interrupt occurs. This action ultimately
produces a double deallocation of the same packet of dynamic memory.
Double deallocation of a dynamic buffer in RSX-llM causes a loop in

3-28

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
the module $DEACB on the next deallocation
(of a block of higher
address)
after the second deallocation of the same block. At that
time, R2 and R3 both contain the address of the I/O packet memory that
has been doubly deallocated.
If XDT has been included in the system,
the deallocation routine checks for bad deallocation and crashes the
system if it occurs.

3.4.4

Rebuilding and Reincorporating a Driver

The procedure for rebuilding and reincorporating a driver into your
system depends on whether the driver is resident or loadable. The two
subsections that follow describe the procedure for each kind of
driver.

3.4.4.l Rebuilding and Reincorporating
a Resident
Driver - The
procedure
for rebuilding and
reincorporating a resident driver
involves four steps:
NOTE
In the examples that follow:

•

x (as in [11, 2x] is equal to 0
for unmapped systems and 4 for
mapped systems

•

xxDRV is the name of the driver
you
are
rebuilding
or
reincorporating

Correct and
structures.

assemble

the

driver

and/or

device

data

Assuming that the object system has been bootstrapped,
appropriate volumes have been mounted, and the source code
for the user driver and/or device data base has been updated,
then the following commands effect the reassembly of both the
driver and the data base:
>SET /UIC=[ll,2x](BIT).
>RUN $MAC(@)
MAC>xxDRV=LB: [l,l]EXEMC/ML,SY: [11,lO]RSXMC,xxDRVIB@
MAC>USRTB=LB: [l,l]EXEMC/ML,SY: [11,lO]RSXMC,USRTB~
MAC>~

Update the Executive object module library.
After reassembling the user driver and/or data base, you must
update the Executive object module library. The following
commands will accomplish this:
>SET /UIC=[l,2x]IBIT)
>RUN $LBR~
.
LBR>LB:RSXllM/RP=[ll,2X]xxDRV,USRTBIB@
LBR>~

3-29

INCORPORATING USER-WRITTEN DRIVERS INTO RSX-llM
3.

Do Phase II
Executive.

SYSGEN

Bootstrap the new system.

rebuild

the

driver

with

the

The new system can now be bootstrapped with the MCR BOO
command.
If you are using the baseline system, first issue
the following command:
>INS B00;-1~
Then issue the following command:
>BOO [l,5x]RSXllMIBrn

3.4.4.2 Rebuilding and Reincorporating a Loadable Driver - A loadable
driver is easier to reincorporate during debugging than a resident
driver. After correcting and assembling the driver source, simply
unload the old version, using the MCR UNL command, task-build the new
one, and load it using the LOA command.
The data structure, once loaded, becomes a permanent part of the
Executive.
It is not removed by the UNL command. If the data
structure is in error and cannot be patched, correct its source,
Then bootstrap the system before
reassemble, and task-build it.
loading the corrected driver.

3-30

CHAPTER 4
WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

In Chapter 2, overviews were given for:
•

Data structures

•

Executive services

•

Programming protocol

This chapter gives details for the data structures, and in addition
discusses specifics of multicontroller drivers and the INTSV$ macro.
Executive services are covered in Chapter 5. The protocol coverage in
the discussion of programming protocol in Chapter 2 is detailed enough
to make further elaboration unnecessary.

4.1

DATA STRUCTURES

The following elements in the I/O data structure are of concern to the
programmer writing a driver:
•

I/O packet

DCB

UCB

SCB

•

Device interrupt vector

The I/O data structure, and the first four control blocks listed above
in particular, contain an abundance of data pertaining to input/output
operations. Drivers themselves are involved with only a subset of the
data.
In the detailed descriptions of the I/O packet, the DCB, the UCB, and
the SCB that follow, most data fields (words or bytes) are classified
by one of five descriptions. Two items in each description indicate:
•

Whether the field is initialized in the data structure source

•

What sort of access
execution

the

driver

4-1

has

the

field

during

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
The five descriptions are:
<initialized, not referenced>
Field is supplied in the data structure source code,
not referenced by the driver during execution.

and

<initialized, read-only>
Field is supplied in the data structure source code, and
be read by the driver.

may

<not initialized, read-only>
Either an agent other than the driver establishes this field,
or the driver sets it up once and thereafter references it
read-only.
<not initialized, read-write>
Either the driver or some other agent establishes this field,
and the driver may read it or write over it.
<not initialized, not referenced>
Field does not involve the driver in any way.
These five descriptions cover most of the fields in the four control
blocks described in this section.
Exceptions are noted in the text.
The final discussion in this section deals with the
vector.

4.1.1

device

interrupt

The I/O Packet

Figure 4-1 shows the layout of the 18-word I/O packet, which is
constructed and placed
in the driver
I/O queue by QIO directive
processing, and is subsequently delivered to the driver by a call to
$GTPKT.
The DPB from which the I/O packet is generated is illustrated
in Figure 4-2 (see Section 4.1.1.2).

4.1.1.1 I/O Packet Details - The I/O packet is built dynamically by
QIO directive processing. Thus, no static fields exist with respect
to a driver.
I/O packets are created dynamically, and therefore the
first two descriptions in Section 4.1 (<initialized, not referenced>
and <initialized, read-only>} do not apply.
Fields in the I/O packet
(described below)
are classified as not referenced, read-only, or
read-write.
I.LNK
Driver access:
Not referenced.
Description:
Links I/O packets queued for a driver.
A
chain.
The listhead is in the SCB {S.LHD}.

4-2

zero

ends

the

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
I.EFN
Driver access:
Not referenced.
Description:
Contains the event flag number as copied
processing from the requester's DPB.

Lini< lv nex.+ 1/n
11v pac"e.

l.LNK
1.PRI
1.EFN

}

EFN

QIO

0
PRI

!.TCB

TCB address of requester

l.LN2

Address of second LUT word

I.UCB

Address of redirect UCB

Modifier

Virtual address of 1/0 status block

Relocation bias of IOSB

Real address of IOSB

Virtual address of AST service routine

1.FCN

Function code

l.IOSB

I.AST

1.PRM

1--I---

1---

Device
parameters

1---

I---

ZK-220-81

Figure 4-1

I/O Packet Format

I. PRI

Driver access:
Not referenced.

Description:
Priority copied from the TCB of the requesting task.

4-3

directive

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
I.TCB
Driver access:
Read-only.
Description:
TCB address of the requesting task.
I. LN2
Driver access:
Not referenced.
Description:
Contains the address of the second word of the LUT entry in
the task header to which the I/O request is directed. For
open files on file-structured devices, this word contains the
address of the window block; otherwise, it is zero.
I. UCB
Driver access:
Read-only.
Description:
Contains the address of the unit to which I/O is to be
directed.
I.UCB is the address of the Redirect UCB if the
starting UCB has been subject to an MCR RED command. Used in
cancel I/O routine to determine if the I/O request is from
the task that is issuing the $IOKIL routine.
I.FCN
Driver access:
Read-only.
De sc r i pt ion :
Contains the function code (see Table 4-1, Section 4.1.2.2)
for the I/O request.
The modifier byte is one or more
subfunction bits that may be set.
I. IOSB

Driver access:
Not referenced.
Description:
I.IOSB contains the virtual address of the I/O Status Block
(IOSB), if one is specified, or zero if one is not specified.
I.IOSB+2 and I.IOSB+4 contain the address doubleword for the
IOSB (see Appendix A for a detailed description of the
address doubleword). On an unmapped system, the first word
is zero; the second word is the real address of the IOSB.

4-4

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
In a mapped system, the first word contains the relocation
bias of the IOSB; the bias is, in effect, the number of the
32-word block in which the IOSB starts.
This block number is
derived by viewing available real memory as a collection of
32-word blocks numbered consecutively, starting with O.
Thus,
if the
IOSB starts at physical location 3210(octal),
its block number is 32(octal).
The second word is formatted as follows:
Bits 0-5
Displacement in block
Bits 6-12 All zeros
Bits 13-15
6

(DIB)

The displacement in block is the offset from the block base.
In
the
above
example,
in which the
IOSB starts at
3210(octal), the DIB is equal to lO(octal).
The value 6 in bits 13-15 is constant.
It is used to cause
an address reference through Kernel Address Page Register 6
{APR6). Again, see Appendix A for details.
Discussion of the address doubleword
is deferred to an
appendix because you seldom have to be concerned with its
contents or format in writing a conventional driver.
Its
construction
and
subsequent
manipulation are normally
external to the driver.
Subroutines are
provided
as
Executive
services
for
programmed
I/O to render the
manipulations of I/O transfers transparent to the driver
itself.
I.AST
Driver access:
Not referenced.
Description:
Contains the virtual address of the AST service routine to be
executed at I/O completion.
If no address is specified, the
field contains zero.
I.PRM
Driver access:
Not initialized, read-only.
Description:
Device-dependent parameters constructed
from the last six
words of the DPB.
Note that if the
I/O function is a
transfer (refer to the description of D.MSK in Section
4.1.2.1),
the buffer address
(first DPB device-dependent
parameter) is translated to an equivalent address doubleword.
Therefore, device-dependent parameter n is copied to I.PRM
+(2*(n-1))+2, where n is the number of the parameter and the
first parameter is numbered Pl.

4-5

WRITING AH I/O DRIVER--PROGRAMMING SPECIFICS
4.1.1.2 The QIO Directive Parameter Block (DPB) - The
constructed as shown in Figure 4-2.

DPB

directive

QIO

The parameters in the DPB have the following meanings.
Length (required):
The length of the DPB, which for the
always fixed at 12(decimal) words.

RSX-llM

QIO

·DIC (required) :
Directive Identification Code.
is 1.
For QI OW i t is 3.

For the QIO directive, this value

Function Code (required):
The code of the requested I/O function {O through 31.).

Length

DIC

Function code

Modifier

Reserved

LUN

Priority

EFN

1/0 status block address

AST address

12
14

Devicedependent
parameters

ZK-221-81

Figure 4-2

QIO Directive Parameter Block (DPB)

Modifier:
Device-dependent modifier bits.
Reserved:
Reserved byte;

must not be used.

L UN ( re qui red ) :
Logical Unit Number.
Priority:
Request priority.

Ignored by RSX-llM.

4-6

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
EFN (optional):
Event flag number. Zero indicates no event flag.
If you specify
no event flag, QIOW$ directives are converted to QIO$ directives.
I/O Status Block Address {optional):
This word contains a pointer to the I/O status block, which is a
2-word, device-dependent,
I/0-completion data packet formatted
as:
Byte 0
I/O status byte.
Byte 1
Augmented data supplied by the driver.
Bytes 2 and 3
The contents of these bytes depend on the value of byte O.
If byte 0 equals 1, then these bytes usually contain the
processed byte count.
If byte 0 does not equal O, then the
contents are device-dependent.
AST Address (optional):
Address of an AST service routine.
Device Dependent Parameters:
Up to six parameters specific to the device and I/O function to
be performed.
Typicallyf for data transfer functions,
the
following four are used:
•

Buffer address

•

Byte count

•

Carriage control type

•

Logical block number

The fields for any optional parameters not specified
with zeros.

4.1.2

will

filled

The Device Control Block (DCB)

Figure 4-3 is a schematic layout of the DCB.
The DCB describes the
static characteristics of a device controller and the units attached
to the controller. All fields must be specified except D.PCB, which
is required only if you selected the loadable-driver option.

4-7

WRITING AH I/O DRIVER--PROGRAMMING SPECIFICS
4.1.2.1

DCB Details - The fields in the DCB are described below:

D.LNK (link to next DCB)l
Driver access:
Initialized, not referencede
Description:
Address link to the next DCB. A zero in this field indicates
the last (or only) DCB in the chain.
D.UCB (pointer to first UCB)
Driver access:
Initialized, not referenced.

D.LNK

Link to next DCB (O=last)

D.UCB

Link to first UCB

D.NAM

Generic device name

D.UNIT

Highest unit no.

Lowest unit no.

D.UCBL

Length of UCB

D.DSP

Address of driver dispatch table

D.MSK

Legal function mask bits 0 - 15.

Control function mask bits 0 - 15.

No-op function mask bits 0 · 15.

ACP function mask bits 0 · 15.

Legal function mask bits 16. · 31.

Control function mask bits 16. - 31.

No-op function mask bits 16. · 31.

ACP function mask bits 16. - 31.

D.PCB

..
Address of part1t1on control block

L-----------------------J

ZK-222-81

Figure 4-3

Device Control Block

1. Parenthesized phrases indicate value to be initialized in the
base source code.
4-8

data

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

Description:
Address link to the U.DCB field of the first, and possibly
the only, UCB associated with the DCB. For a given DCB, all
UCBs are in contiguous memory locations and must all have the
same 1 eng th.
D.NAM (ASCII device name)
Driver access:
Initialized, not referenced.
Description:
Generic device name in ASCII
mnemonically referenced.

which

device

units

are

D.UNIT (unit number range)
Driver access:
Initialized, not referenced.
Description:
Unit number range for the device.
This range covers those
logical units available to the user for device assignment.
Typically, the lowest number is zero, and the highest is n-1,
where n is the number of device-units described by the DCB.
D.UCBL (UCB length)
Driver access:
Initialized, not referenced.
Description:
The UCB can have any length to meet the needs of the driver
for variable storage.
However, all UCBs for a given DCB must
have the same length. The specified length must include the
following prefix words if any or all are present:

•

U. IOC

• U.ERHL
•

U. ERHC

• U. ERSL
•
•
•
•
•

U.ERSC
U.LUIC
U.OWN
U. CLI
U.MUP

4-9

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
D.DSP (dispatch table pointer)
Driver access:
Initialized, not referenced.
Description:
Address of the driver dispatch table.
When the Executive wishes to enter the driver at any of the
four entry points contained in the driver dispatch table, it
accesses D.DSP, 16cates the appropriate address in the table,
and calls the driver at that address. A zero table address
indicates that the {loadable) driver is not in memory.
For a
loadable driver, then,
this field must be initialized to
zero.
If the driver does not process a given function,
then
this address points to a
return instruction within the
driver's code.
You must provide a driver dispatch table in the driver
source.
The label on this table is of the form $xxTBL; it
must be a global label.
The designation xx
is
the
2-character generic device name for the device.
Thus, $TTTBL
is the global label on the driver dispatch table for the
generic device name TT.
This table is an ordered, 4-word
table containing the following entry points:
•

I/O initiator

•

Cancel I/O

•

Device timeout

•

Power failure

When a driver is entered at one of these entry points,
conditions are as follows:

entry

At initiator:
If UC. QUE=l
RS
UCB address
R4
SCB address
Rl
Address of the I/O packet
If UC. QUE=O
RS = UCB address

Interrupts are allowed.
{UC.QUE is a bit
UCB.
See Section 4.1.4.1.)

U.CTL

At cancel I/O:
RS
R4
R3
Rl
RO

UCB address
SCB address
Controller index
Address of TCB of current task
Address of active I/O packet

Device interrupts at or below the priority of the
requesting device are locked out.

4-10

the

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
At device time-out:
RS
R4
R3
R2
RO

UCB address
SCB address
Controller index
Address of device CSR
I/O status code IE.DNR (Device Not Ready)

Device interrupts at or below the priority of the
requesting device are locked out.
At power failure:
RS

UCB address
SCB address
Controller index

Interrupts are allowed. The power failure entry point of
a loadable driver is called by LOA only for units that are
on line and have UC.PWF set.
D.MSK (function masks)
Driver access:
Initialized, not referenced.
Description:
There are eight words, beginning at D.MSK, that are critical
to the proper functioning of a device driver. The Executive
uses these words to validate and dispatch the I/O request
specified by a QIO directive. Four masks, with two words per
mask, are described by the bit configurations that you
establish for these words:
•

Legal function mask

•

Control function mask

•

No-op function mask

•

ACP function mask

The QIO directive allows for 32 possible I/O functions.
The
masks, as stated, are filters to determine validity and I/O
requirements for the subject driver.
The Executive filters the function code in the I/O request
through the four masks.
The I/O function code is the
high-order byte of the function parameter issued with the QIO
directive.
The decimal representation of that high-order
byte is equivalent to the decimal bit number of the mask. If
you want the function to be true in one of the four masks,
you must set the bit in that mask in the position that
numerically corresponds to the function code. For example,
the code for IO.RVB is 21
(octal)
and
its
decimal
representation is 17.
If you want IO.RVB to be true for a
mask, you must set bit number 17(decimal) in the mask.
The masks are laid out in memory in two 4-word groups.
Each
4-word group covers 16 function codes. The first 4 words
cover the function codes 0-15;
the second 4 words covar
codes 16-31. Below is the layout used for the driver example
in Section 6.2.2.

4-11

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
• WORD
• WORD
• WORD
• WORD
.WORD
• WORD
.WORD
.WORD

140033
30
140000
0
5
0
1
4

;LEGAL FUNCTION MASK CODES 0-15 •
;CONTROL FUNCTION MASK CODES 0-15 •
;NO-OP FUNCTION MASK CODES 0-15 •
;ACP FUNCTION MASK CODES 0-15 •
;LEGAL FUNCTION MASK CODES 16.-31.
;CONTROL FUNCTION MASK CODES 16.-31 •
;NO-OP FUNCTION MASK CODES 16.-31.
;ACP FUNCTION MASK CODES 16.-31.

The mask words filter sequentially as follows:
Legal Function Mask:
Legal function values have the corresponding bit position in
this word set to 1.
Function codes that are not legal are
rejected by QIO directive processing, which returns IE.IFC in
the I/O status block, provided an IOSB address was specified.
Control Function Mask:
If any device-dependent data exists in the DPB, and this data
does not require further checking by the QIO directive
processor, the function is considered to be a control
function.
Such a function allows QIO directive processing to
copy the DPB device-dependent data directly into the I/O
Packet.
No-op Function Mask:
A no-op function is any function that
is
considered
successful as soon as it is issued.
If the function is a
no-op, QIO directive processing immediately marks the request
successful; no additional filtering occurs.
ACP Function Mask:
If a function code is legal but specifies neither a control
function nor a no-op, then it specifies either an ACP
function or a transfer function.
If a function code requires
intervention of an Ancillary Control Processor (ACP), the
corresponding bit in the ACP function mask must be set.
ACP
function codes must have a value greater than 7.
In the specific case of read-write virtual functions, you
have the option to set the corresponding mask bits.
If the
corresponding mask bits for a read-write virtual function are
set, QIO directive processing recognizes that a file-oriented
function is being requested to a non-file-structured device
and converts the request to a read-write logical function.
This conversion is
particularly
useful.
Consider
read-write virtual function to a specific device:
1.

If the device is file structured and a file is open
on the specified LUN, the block number specified is
converted from a virtual block number in the file to
a logical block number on the medium, and the request
is queued to the driver as a read-write logical
function.

4-12

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
2.

If the device is file structured and no file is open
on the specified LUN, then an error is returned and
no further action is taken.

If the device is not file structured, then the
request is simply transformed to a read-write logical
function and is queued to the driver.
(Specified
block number is unchanged.)

Transfer Function Processing:
Finally, if the function is not an ACP function,
then by
default it is a transfer function.
All transfer functions
cause the QIO directive processor to check the specified
buffer for legality
(that is, inclusion within the address
space of the requesting task) and proper alignment
(word or
byte).
In addition, the processor checks the number of bytes
being transferred for proper modulus (that is, nonzero and a
proper multiple) e
Creating Mask Words:
Creating function mask words involves five steps:
1.

Establish the I/O functions available on the
for which driver support is to be provided.

device

Build the legal function mask:
Check the standard
RSX-llM
function mask values in Table 4-1 for
equivalencies.
Only
the
IO.KIL
function
is
mandatory.
IO.ATT and
IO.DET functions, if used,
must have the RSX-llM system interpretation.
DIGITAL
suggests that functions having an RSX-llM system
counterpart use the RSX-llM code, but this
is
required only when the device is to be used in
conjunction with an ACP.
From the supported function
list in Table 4-1,
you can build the two legal
function mask words.

Build the control function mask by asking:
Does this function carry a standard buffer address
and byte count in the first two device-dependent
parameter words?
If it does not, then either it qualifies as a control
function,
or the driver
itself must effect the
checking and conversion of any addresses to the
format required by the driver.
See Section 6.3 for
an example of a driver that does this.
(Buffer
addresses
in
standard format are automatically
converted to address doubleword format.)
Control functions are essentially those functions
whose DPBs do not contain buffer addresses or counts.

4-13

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
4.

Create the no-op function mask by deciding which
legal functions are to be set as no-ops. Typically,
for compatibility with File Control Services (FCS) or
Record
Management
Services
(RMS)
on
non-file-structured devices, the file access/deaccess
functions are selected as legal functions, even
though no specific action is required to access or
deaccess a non-file-structured device;
thus, the
access/deaccess functions are set to be no-ops.

Finally, include the ACP functions Write Virtual
Block and Read Virtual Block for those drivers that
support both read and write.
{Include only one
related ACP function if the driver supports only read
or write.)

D.PCB {Partition Control Block)
Driver access:
Initialized, not referenced.
Description:
Address of the driver's Partition Control Block {PCB).
This
word is present in the DCB if and only if the loadable-driver
SYSGEN option has been selected. It must be initialized to
zero. You can extend the DCB by adding words after D.PCB.
A PCB exists for every partition in a system. MCR creates a
PCB when the SET /MAIN or SET /SUB commands are given. If a
driver is loadable, its PCB describes the partition in which
it resides.
The Executive uses D.PCB together with D.DSP (the address of
the driver dispatch table) to determine whether a driver is
loadable or resident, and, if loadable, whether it is in
memory.
Zero and nonzero values for these two pointers have
the meanings shown in Table 4-1.
Table 4-1
D.PCB and D.DSP Bit Definitions

:#0

Loadable
driver,
not in
memory

Resident
driver

(not
possible)

Loadable
driver,
in memory

ZK-223-81

4-14

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
4.1.2.2 Establishing I/O Function Masks - Table 4-2 is supplied to
assist you in determining the proper values to set in the function
masks. The mask values are given for each I/O function used by
DIGITAL-supplied drivers.
The bit number allows you to determine
which mask group to use: for bits numbered 0 through 15, use the mask
value for a word in the first 4-word group; for bits numbered 16
through 31, use the mask value for a word in the second 4-word group.
Table 4-2
Mask Values for Standard I/O Functions
Bit

l
r

Mask
va 1 ue

2
3
4
5
6
7
8
9
10
11
12
13
14
15

1
2
4
10
20
40
100
200
400
1000
2000
4000
10000
20000
40000
100000

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

1
2
4
10
20
40
100
200
400
1000
2000
4000
10000
20000
40000
100000

0
l

Related
Sy ffi1.10.L
i...
, .; ,..
.1...._

IO. KIL

TI Cancel I/O

IO.WLB

IO. RLB
IO. ATT
IO. DET

I
IO. FNA
IO. ULK
IO. RNA
IO. ENA
IO.ACR
IO. ACW
IO.ACE
IO.DAC
IO. RVB
IO.WVB
IO. EXT
IO.CRE
IO. DEL
IO. RAT
IO.WAT
IO.APC

I/O

..l<'un'"" t; """
• v

~VJ.l

Write Logical Block
Read Logical Block
Attach Device
Detach Device
I General Device Control
General Device Control
General Device Control
Diagnostics
Find File in Directory
Unlock Block
Remove File from Directory
Enter File in Directory
Access File for Read
Access File for Read/Write
Access File for Read/Write/Extend
Deaccess File
Read Virtual Block
Write Virtual Block
Extend File
Create File
Mark File for Delete
Read File Attributes
Write File Attributes
ACP Control
Unused
Unused
Unused
Unused
Unused
Unused
Unused

Of the function mask values listed in Table 4-2, only IO.KIL is
mandatory and has a fixed
interpretation.
However, if IO.ATT and
IO.DET are used, they must have the standard meaning.
{Refer to the
RSX-llM/M-PLUS I/O Drivers Reference Manual for a description of
standard I/O functions.) If QIO directive processing encounters a
function code of 3 or 4 and the code is not set to be a no-op, QIO$
assumes that these codes represent Attach Device and Detach Device,
respectively.
The other codes are suggested but not mandatory. You
are free
to
establish
all
other
function-code
values
on
non-file-structured devices~
The mask words must reflect the proper
filtering process.

4-15

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

If a driver is being written for a file-structured device,
standard function mask values of Table 4-2 must be established.

the

Tables 4-3, 4-4, and 4-5 are guides to determining the proper bit
masks for disks, tapes, and unit record devices (such as terminals,
card readers, line printers, and paper tape punches/readers).
Table 4-3
Mask Word Bit Settings for Disk Drives
Bit
#

ACP

RSX-llM
non-ACP

0
1
2
3
4
5
6

c
t

c
c

sa
sd
a
a
a
a

8
9

10
11
12
13
14
15
16

17
18
19
20
21

n
n

a
a
a
a
a
a

n
a
a

IO.WLB
IO. RLB
IO. ATT
IO. DET
IO.STC

IO. ULK

a
a

IO. KIL

IO.CLN
Diagnostic
IO. FNA

Related
Symbolic

IO. RNA
IO. ENA
IO. ACR
IO. ACW
IO. ACE
IO. DAC
IO. RVB
IO.WVB

IO. EXT
IO.CRE
IO. DEL
IO. RAT
IO.WAT
IO. APC

26
27

28
29
30
31

- transfer function, bit

set only in legal
function mask
c - control function, bit set in legal and
control function masks
n - no-op function, bit set in legal
and no-op
function masks
a - ACP function, bit set in legal and ACP
function masks
sa - special case, bit set only in ACP function
mask, but not legal
sd - special case, bit set only if diagnostic
support in system and driver
t

4-16

I
I

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

Table 4-4
Mask Word Bit Settings for Magnetic Tape Drives
Bit
#
0
1
2
3

4
5
6
7
8
9
10
11
12
13
14
15

16
17
18
19
20
21
22
23
24

ACP

RSX-llM
non-ACP

c
t

c
c
c
c

sa
sd
a

a
a
a

a
a
a
a

n
a
a

n
n

a
a

Relatea·
Symbolic
IO. KIL
IO.WLB
IO. RLB
IO. ATT
IO. DET
IO. STC
IO. CLN
Diagnostic
IO. FNA
IO.ULK
IO. RNA
IO. ENA
IO. ACR
IO. ACW
IO. ACE
IO. DAC
IO. RVB
IO.WVB
IO. EXT
IO. CRE
IO.DEL
IO.RAT
IO.WAT
IO.APC

25
26
27
28
29
30

t - transfer function, bit set only in legal function
mask
c - control function, bit set in legal and control
function masks
n - no-op function, bit set in legal and no-op
function masks
a - ACP function, bit set in legal and ACP function
masks
sa - special case, bit set only in ACP function mask,
but not legal
sd - special case, bit set only if diagnostic support
in system and driver

4-17

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

Table 4-5
Mask Word Bit Settings for Unit Record Devices
Bit
#

0
1
2
3
4
5
6
7
8
9
10
11

12
13

14
15

16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

ACP
c
t
t
c
c
sa
sd
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a
a

RSX-llM
non-ACP

Related
Symbolic
IO. KIL
IO.WLB
IO. RLB
IO.ATT
IO. DET
IO.STC

c
t
t
c
c

IO.CLN
Diagnostic
IO. FNA
IO. ULK
IO.RNA
IO. ENA
IO. ACR
IO.ACW
IO. ACE

n
n
n

IO. DAC
IO. RVB
IO.WVB
IO.EXT
IO. CRE
IO. DEL
IO. RAT
IO.WAT
IO. APC

n
a
a

t - transfer function, bit set only in legal function

I c - mask
control function, bit set in
function masks
I
I
I

legal

and

control

n - no-op function, bit set in legal and no-op
function masks
II a - ACP
function, bit set in legal and ACP function
masks
I
Isa - special case, bit set only in ACP function mask,
but not 1 egal
- special case, bit set only if diagnostic support
in system and driver

4-18

WRITING AH I/O DRIVER--PROGRAMMING SPECIFICS
4.1.3

The Status Control Block {SCB)

Figure 4-4 is a layout of the SCB. The SCB describes the status of
control unit that can run in parallel with all other control units.

S.RCNT }
S.ROFF1
S.BMSV 1
S.BMSK 1

r------------r-----------1
Offset to 1st
1 Number of registers 1
1
1
device register
I
to copy on error
1
I-·- - - - - - - - - - _J - - - - - - - - - - - -I
1
Saved 110 active bit map
1
'
pointer to Error Message Block
1

~----------------~------!
1
:
Device 1/0 active bit mask

S.LHD

S.PRI
S.VCT
S.CTM
S.ITM
S.CON
S.STS

}
}
}

uevice 1'/O queue
listhead

t---

Vector address74

2
4

Device priority

Time-out count:

Initial

Current

Controller status

Controller index

S.CSR

Address of control status register

S.PKT

Address of current 1/0 packet

S.FRK

Fork link word

Fork PC

Fork R5

Fork R4

Relocation base of driver's partition

I
I

S.MPR

L-----------------------J 30
I
I

1- - I

'---

Storage required for
NPR UNIBUS devices
with 22-bit addressing

- - -1
1

----'

I, _______________________ J I

I
I

,-----------------------~
I
I

'- - - - - - - - - - - - - - - - - - - - - - - -:
I

L-----------------------J

1. These offsets exist for mass storage devices only, and only in systems
incorporating error logging.
ZK-224-81

Figure 4-4

Status Control Block

4-19

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
4.1.3.1

SCB Details - The fields in the SCB are described below:

S.RCNT {used for error logging)
Driver Access:
Not initialized, not referenced.
Description:
The number of registers to copy on error. This offset exists
for mass storage devices only (that is, when DV.MSD is set),
and only in systems incorporating error logging.
S.ROFF {used for error logging)
Driver Access:
Not initialized, not referenced.
Description:
Offet to first device register. This offset exists for mass
storage devices only {that is, when DV.MSD is set), and only
in systems incorporating error logging.
S.BMSV (used for error logging)
Driver access:
Not initialized, not referenced.
Description:
Saved I/O active bit map and pointer to Error Message Block.
This offset exists for mass storage devices only {that is,
when DV.MSD is set), and only in systems incorporating error
logging.
S.BMSK (used for error logging)
Driver access:
Not initialized, not referenced.
Description:
Device I/O active bit mask.
This offset exists for mass
storage devices only {that is, when DV.MSD is set), and only
in systems incorporating error logging.
S.LHD (first word equals zero; second word points to first) 1
Driver access:
Initialized, not referenced.

1. Parenthesized contents indicate values to
data base source code.

4-20

initialized

the

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
Description:
Two words forming the I/O queue listhead.
The first word
points to the first I/O packet in the queue, and the second
word points to the last I/O packet in the queue.
If the
queue is empty, the first word is zero, and the second word
points to the first word.
S.PRI (device priority)
Driver access:
Initialized, read-only.
Description:
Contains the priority at which the device interrupts.
Use
symbolic values
(for example, PR4) to initialize this field
in your data base source= You define these symbolic values
by issuing the HWDDF$ macro (refer to the sample data base in
Section 6.2.1 and the listing of the HWDDF$ macro in Appendix
C) •

S.VCT (interrupt vector divided by 4)
Driver access:
Initialized, not referenced.
Description:
Interrupt vector address divided by 4.
For loadable drivers,
the MCR/VMR LOA function uses this field and the existence of
driver symbol(s) $xxINT, $xxINP, and $xxOUT to initialize the
device interrupt vector.
S.CTM (initialize to zero)
Driver access:
Not initialized, read-write.
Description:
RSX-llM supports device time-out, which enables a driver to
limit the time that elapses between the issuing of an I/O
operation and its termination.
The current time-out count
(in seconds) is initialized by moving S.ITM (initial time-out
count) into S.CTM.
The Executive clock service
(in module
TDSCH)
examines active times, decrements them, and, if they
reach zero, calls the driver at its device time-out entry
po int.
The internal clock count is kept in I-second increments.
Thus, a time count of 1 is not precise because the internal
clocking mechanism is operating asynchronously with driver
execution. The minimum meaningful clock interval is 2 if you
intend to treat time-out as a consistently detectable error
condition. Note, if the count is O, that no time-out occurs;
a zero value is, in fact, an indication that time-out is not
operative.
The maximum count is 255.
You are responsible
for setting this field.
Resetting occurs at actual
time-out
or within $FORK.

4-21

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

S.ITM (set to initial time-out count}
Driver access:
Initialized, read-only.
Description:
Contains the initial time-out value.
S.CON (controller number times 2)
Driver access:
Initialized, read-only.
Description:
Controller number multiplied by 2.
Drivers that are written
to support more than one controller use this field.
A driver
may use S.CON to index into a controller table created and
maintained
internally by the driver itself. By indexing the
controller table, the driver can service
the
correct
controller when a device interrupts.
See Section 4.2 for an
example.
S.STS (initialize to zero}
Driver access:
Initialized, not referenced.
Description:
Establishes the controller as busy/not busy
(nonzero/zero).
This byte is the interlock mechanism for marking a driver as
busy for a specific controller. The byte is tested and set
by $GTPKT and reset by $IODON.
S.CSR (Control Status Register address)
Driver access:
Initialized, read-only.
Description:
Contains the address of the Control Status Register (CSR) for
the device controller.
The driver uses S.CSR to initiate I/O
operations and to access, by indexing, other registers
related to the device that are located in the I/O page. This
address need not be a CSR;
it need only be a member of the
device's register set.
It is accessed at system bootstrap
time to determine if the interface exists on the system
hosting the Executive.
The Executive uses S.CSR to set the
off-line bit at bootstrap so that system software can be
interchanged between systems without an intervening system
generation. The MCR LOA function also references S.CSR when
it processes a loadable data base.
Otherwise, only the
driver itself accesses S.CSR.

4-22

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
S.PKT {reserve one word of storage)
Driver access:
Not initialized, read-only.
Description:
Address of the current I/O packet established by $GTPKT.
The
Executive uses this field to retrieve the I/O packet address
upon the completion of an I/O request.
S.PKT is not zeroed
after the packet is completed.
S.FRK (reserve four or five words of storage)
Driver access:
Not initialized, not referenced.
Description:
The four words starting at S.FRK are used for
fork block
storage if and when the driver deems it necessary to
establish itself as a
fork process.
Fork block storage
preserves the state of the driver, which is restored when the
driver regains control at fork level.
This
area
is
automatically used if the driver calls $FORK.
The fork block is five words long
conditions are met:
1.

Loadable drivers
option.

have

The system is mapped.

instead

been

selected

four
as

if
a

two

SYSGEN

If these conditions are met, and the fork block is five words
long, you must not use the fork block for any other purpose.
In other words, you cannot share the space reserved for the
fork block;
if you attempt to do so, you will destroy the
loadable driver's relocation base.
In addition, the 5-word
fork block should always be part of the SCB if the two
conditions above are met.
S.MPR {reserve six words of storage)
Driver access:
Initialized, read-only.
Description:
Drivers use the six words starting at S.MPR for non-processor
request
{NPR) devices attached to a processor with 22-bit
addressing.
See Appendix B for details on initializing
S. MPR.

4.1.4

The Unit Control Block {UCB)

Figure 4-5 is a layout of the UCB (a variable-length control
One UCB exists for each physical device-unit generated into
configuration.
For user-added drivers, this control block is
as part of the source code for the driver data structure.

4-23

block) •
::i

c::uc:: i-om
-.z...
~~

defined

WRITING AN 1/0 DRIVER--PROGRAMMING SPECIFICS
4.1.4.1 UCB Details - The fields in the UCB are described below.
Note that the fields drawn with dotted outlines are not present in
every UCB; their existence depends on physical device type, whether
the system is generated with error logging, and whether you are
running on a multiuser system. Refer to the individual descriptions
of the offsets for details.

u.roc
Driver access:
Not initialized, not referenced.
Description:
For mass storage devices only (that is, when DV.MSD is set),
and only in systems incorporating error logging: the total
number of QIOs issued to the device.
(Initialized to zero
when device is mounted.)
U.ERSL
Device access:
Not initialized, not referenced.
Description:
For mass storage devices only (that is, when DV.MSD is set),
and only in systems incorporating error logging: the maximum
number of soft errors that the error logger will log for the
device.
Note that error logging will stop if either of the
limits specified (in U.ERHL or in U.ERSL) is exceeded.
U.ERHL
Driver access:
Not initialized, not referenced.
Description:
For mass storage devices only (that is, when DV.MSD is set),
and only in systems incorporating error logging: the maximum
number of hard errors that the error logger will log for the
device.
Note that error logging will stop if either of the
limits specified (in U.ERHL or in U.ERSL) is exceeded.
U.ERSC
Driver access:
Not initialized, not referenced.
Description:
For mass storage devices only (that is, when DV.MSD is set),
and only in systems incorporating error logging: the total
number of soft errors logged on the device.
{Initialized to
zero when device is mounted.)

4-24

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
U.ERHC
Driver access:
Not initialized, not referenced.
Des c r i pt ion :
For mass storage devices only (that is, when DV.MSD is set),
and only in systems incorporating error logging:
the total
number of hard errors logged on the device.
(Initialized to
zero when device is mounted.)
NOTE
The following two symbolic names,
U.MUP
and
U.CLI,
both refer to the same
absolute offset; use of the offset is
dependent
on
system
software
configuration.
Details regarding the
use of each symbolic name are contained
in the descriptions of U.MUP and U.CLI.
U.MUP
Driver access:
Not initialized, not referenced.
Description:
For terminal UCBs only, and only in multiuser systems that
include alternate CLI support: bits 1 to 4 contain an index
to a table which contains the address of CLI
Parser Block
(CPB)
for the current CLI; the remaining bits are used for
other terminal-specific features, and defined as follows:
UM. OVR
UM. CLI
UM. DSB
UM. NBR

Override CLI indicator
C LI indicator
Terminal disabled because CLI eliminated
No broadcast

U.CLI
Driver· access:
Not initialized, not referenced.
Description:
For systems without alternate CLI support, but which do
include multiuser protection:
multiuser protection flag
word.
U.LUIC
Driver access:
Not initialized, not referenced.
Description:
For terminal UCBs only, and only in multiuser systems:
login UIC of the user at the particular terminal.

4-25

the

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

-·---,

r
4

U.ERSL }
U.ERHL4
4

U.ERSC }
U.ERHC 4
U.MUP 3

----~

1/0 count

J-

U.IOC 4

- - ~

- - - - T
~ - Hard
error limit

Soft error limit

Hard error count

Soft error count

- -

r- - - - - t - - - - - 1

- - - -

..1.

- -

Multiuser flags and CLI pointer

~
Login UIC

U.OWN 1

i
1

U.LUIC 2

See note 5

- - - - - - - - - - Owning terminal UCB address

U.DCB

Back pointer to DCB

U.RED

Redirect UCB pointer

U.CTL
U.STS
U.UNIT
U.ST2

}
}

Unit status

Control flags

Unit status

Physical unit no.

U.CW1

Characteristics word 1

U.CW2

Characteristics word 2

U.CW3

Characteristics word 3

U.CW4

Characteristics word 4

All
devices

Pointer to SCB

TCB address of attached task

U.BUF

Buffer relocation bias

U.BUF+2

Buffer address

U.CNT

Byte count

U.SCB
U.ATT

1----

Devicedependent

---

,____

storage

1. This offset appears only in multiuser systems.
2. These offsets appear only for terminal devices (that is, those devices that have DV.TTY
set) in multiuser systems.
3. This offset appears only for terminal devices in ,,multiuser systems that include alternate
CLI support. In multiuser systems without alternate CLI support, this offset has a symbolic
name of U.CLI. See descriptions and note in text.
4. These offsets appear only for mass storage devices (those devices that have DV.MSD set)
in systems that employ error-logging.
5. These offsets are device-dependent.
ZK-225-81

Figure 4-5

Unit Control Block

4-26

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
U.OWN (initialize to zero)
Driver access:
Initialized, not referenced.
Description:
In multiuser systems only: the UCB
terminal for allocated devices.

address

the

owning

U.DCB (pointer to associated DCB)
Driver access:
Initialized, not referenced.
Description:
Backpointer to the corresponding DCB. Because the UCB is a
key control block in the I/O data structure, access to other
control blocks usually occurs by means of links implanted in
the UCB.
U.RED (redirect pointer--initialized to point to U.DCB of the UCB)
Driver

acce~s:

Initialized, not referenced.
Description:
Contains a pointer to the UCB to which this device-unit has
peen redirected.
This field is updated as the result of an
MCR Redirect command. The redirect chain ends when this word
points to the beginning of the UCB itself (U.DCB of the UCB
to be precise).
U.CTL (set by you)
Driver access:
Initialized, not referenced.
Description:
U.CTL and the function mask words in the DCB drive QIO
directive processing.
You are responsible for setting up
this bit pattern. Any inaccuracy in the bit setting of U.CTL
produces erroneous I/O processing.
Bit symbols and their
meanings are as follows:
UC.ALG - Alignment bit.
If this bit equals O, then byte alignment of data buffers
is allowed.
If UC.ALG equals 1, then buffers must be
aligned on word boundaries.
UC.ATT - Attach/Detach notification.
If this bit is set, then the driver is called when $GTPKT
processes an Attach/Detach I/O function.
Typically, the
driver does not need to obtain control for Attach/Detach
requests, and the Executive performs the entire function
without any assistance from the driver.

4-27

WRITING AH I/O DRIVER--PROGRAMMING SPECIFICS

UC.KIL - Unconditional Cancel I/O call bit.
If set, the driver is called on a Cancel
I/O request,
even if the unit specified is not busy. Typically, the
driver is called on Cancel I/O only if an I/O operation
is in progress.
UC.QUE - Queue bypass bit.
If set, the QIO directive processor calls the driver
prior to queuing the I/O packet. After the processor
makes this call, the driver is responsible for the
disposition of the I/O packet. Typically, the processor
queues an I/O packet prior to calling the driver, which
later retrieves it by a call to $GTPKT.
UC.PWF - Unconditional call on power failure bit.
If set and the unit is on line, the driver is always to
be called when the system is bootstrapped or power is
restored after a power failure occurs.
Typically, the
driver is called on power restoration only when an I/O
operation is in progress.
Additionally, for loadable
drivers, the driver is called when loaded if the unit is
on line and UC.PWF is set.
UC • NPR - N PR d ev ice b it •
If set, the device is an NPR device.
This bit determines
the format of the 2-word address in U.BUF (details given
in the discussion of U.BUF below).
UC.LGH - Buffer size mask bits (2 bits).
These two bits are used to check whether the byte count
specified
in an I/O request is a legal buffer modulus.
You select one of the values below by ORing into the byte
a 0, 1, or 3.
00
01
10
11

Any buffer modulus valid
Must have word alignment modulus
Combination invalid
Must have doubleword alignment modulus

UC.ALG and UC.LGH are independent settings.
UC.ATT,
UC.KIL,
UC.QUE, and UC.PWF are
usually
zero,
especially for conventional drivers.
Every driver, however,
must be concerned with its particular values for UC.ALG,
UC.NPR, and UC.LGH.
You are totally responsible for the
values in these bits, and erroneous values are likely to
produce unpredictable results.
U.STS (initialize to zero)
Driver access:
Initialized, not referenced.

4-28

WRITING AH I/O DRIVER--PROGRAMMING SPECIFICS
Description:
This byte contains device-independent
The bit meanings are as follows:
US.BSY - If set,

device-uni~

status

information.

is busy.

US.MNT - If set, volume is not mounted.
US.FOR - If set, volume is foreign.
US.MOM - If set, device is marked for dismount.
The unused bits in U.STS are reserved for system
expansion.
US.MDM,
US.MNT,
and US.FOR apply
mountable devices.

use and
only to

U.UNIT (unit number)
Driver access:
Initialized, read-only.
Description:
This byte contains the physical unit
number
of
the
device-unit
(that is, the value required for the hardware to
access the specified drive unit).
If the controller for the
device supports only a single unit, the unit number is always
zero.
U.ST2

(set by you)
Driver access:
Initialized, not referenced.
Description:
This byte contains additional device-independent
information.
The bit meanings are as follows:

status

US.OFL - If set, the device is off line (that is, not
the configuration) •

US.RED - If set, the device cannot be redirected.
US.PUB - If set, the device is a public device.
US.UMD - If set, the device is attached for diagnostics.
The remaining bits are reserved for system use and expansion.
U.CWl (set by you)
Driver access:
Initialized, not referenced.

4-29

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

Description:
The first of a 4-word contiguous
cluster
of
device
characteristics information.
U.CWl and U.CW4 are device
independent. U.CW2 and U.CW3 are device dependent. The four
characteristics words are retrieved from the UCB and placed
in the requesteres buffer on issuance of a
Get
LUN
information
{GLUN$)
Executive
directive.
It is your
responsibility to supply the contents of these four words in
the assembly source code of the driver's data structure.
u.CWl is defined as follows {If a bit is set to 1,
corresponding characteristic is true for the device.):
DV.REC
DV. CCL
DV. TTY
DV.DIR
DV. SDI
DV. SQD
DV.MSD
DV. UMD
DV. EXT

Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit

DV. SWL
DV. ISP
DV. OSP
DV. PSE
DV. COM
DV. Fll
DV.MNT

Bit
Bit
Bit
Bit
Bit
Bit
Bit

the

0--Record-oriented device
1--Carriage-control device
2--Terminal device
3--Directory device
4--Single directory device
5--Sequential device
6--Mass storage device
7--Device supports user-mode diagnostics
8--Device attached to a 22-bit direct addressing
controller
9--Unit is software write-locked
10--Input spooled device
11--0utput spooled device
12--Pseudo device
13--Device mountable as a communications channel
14--Device mountable as a Files-11 device
15--Device mountable

u.cw2 (initialize to zero)
Driver access:
Initialized, read-write.
Description:
Specific to a given device
storage or constants) .1

driver

{available

for

working

driver

{available

for

working

U.CW3 (initialize to zero)
Driver access:
Initialized, read-write.
Description:
Specific to a given device
storage or constants) .1

1. Exception: for block-structured devices, U.CW2 and U.CW3 cannot be
used for working storage.
In drivers for block-structured devices
(disks and DECtape), these two words must be initialized to a
double-precision number giving the total number of blocks on the
device. Place the high-order bits in the low-order byte of U.CW2 and
the low-order bits in U.CW3.
4-30

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

For tape UCBs, the high and low bytes of this word specify
the highest and lowest densities, respectively, supported by
the device. Symbolic names for U.CW3 are defined as follows
for tape UCBs:
UN. UNS

UD. 200
UD. 556
UD.800
UD. 160
UD. 62 5

Unsupported/unspecified
200 bits/in, 7-track
556 bits/in, 7-track
800 bits/in, 7- or 9-track
1600 bits/in, 9-track
6250 bits/in, 9-track

For example, a TE16 tape drive supports densities of both 800
and 1600 bits/in. For a TE16 drive, U.CW3 would be coded as
follows:
.BYTE

UD. 800, UD.160

U.CW4 (set by you)
Driver access:
Initialized, read-only.
Description:
Default buffer size.
SET /BUF.

This word is changed by the MCR command

U.SCB (SCB pointer)
Driver access:
Initialized, read-only.
Description:
This field contains a pointer to the SCB for this UCB.
In
general, R4 contains the value in this word when the driver
is entered by way of the driver dispatch table, because
service routines frequently reference the SCB.
U.ATT {initialize to zero)
Driver access:
Initialized, not referenced.
Description:
If a task has attached itself to the device-unit, this
contains its TCB address.

field

U.BUF (reserve two words of storage)
Driver access:
Not initialized, read-write.
De script ion:
serve
as
U.BUF labels two consecutive words that
a
communication region between $GTPKT and the driver. U.BUFi
U.BUF+2, and U.CNT receive the first three words from the I/O
packet.

4-31

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
For transfer operations, the format of these two words
depends on the setting of UC.NPR in U.CTL. The driver does
not format the words; all formatting is completed before the
driver receives control.
For unmapped systems, the first
word is zero, and the second word is the physical address of
the buffer. For mapped systems, the format is determined by
the UC.NPR bit, which is set for an NPR device and reset for
a program transfer device.
The format for program transfer devices is identical to that
for the second two words of I.IOSB in the I/O packet. See
Section 4.1.1.1.
In general, the driver does not manipulate these words when
performing I/O to a program transfer device. Instead, it
uses the Executive routines Get Byte, Get Word, Put Byte, and
Put Word to effect data transfers between the device and the
user's buffer.
For NPR device drivers, the word layout is as follows:
Word 1
Bit 0
Bits 1-3
Bits 4,5
Bits 6
Bits 7-15

Go bit initially set to zero
Function code--set to zeros
Memory extension bits
Interrupt enable--set to zero
Zero

Word 2
Bits 0-15

Low-order 16-bits of physical address

It is your responsibility to set the function code, interrupt
enable, and go bits. This action must be accomplished by a
Bit Set (BIS) instruction so that the extension bits are not
disturbed.
The driver must move these words into the device
control registers to initiate the I/O operation.
Note that when the system is unmapped, bits 4 and 5 are
always zero, but this fact is transparent to the driver.
Thus, NPR device drivers are not cognizant of the mapping
state in the system.
The construction of U.BUF, U.BUF+2, and U.CNT occurs only if
the requested function is a transfer function; if it is not,
these three words contain the first three words of the I/O
packet.
The details of the construction
appear in Appendix A.

the

address

doubleword

U.CNT (reserve 1 word of storage)
Driver access:
Not initialized, read-write.
Description:
Contains the byte count of the buffer described by U.BUF.
The driver uses this field in constructing the actual device
request.

4-32

WRITING AN 1/0 DRIVER--PROGRAMMING SPECIFICS
U.BUF and U.CNT keep track of the current data item in the
buffer for the current transfer (except for NPR transfers).
Because this field is being altered dynamically, the I/O
packet may be needed
to reissue an I/O operation, for
instance, after a powerfail or error retry.
Device-Dependent Words:
Driver access:
Not initialized, read-write.
Description:
You establish this variable-length block
device-specific requirements.

4.1.5

words

suit

The Device Interrupt Vector

For resident drivers only, the device interrupt vector must be
initialized when defining data structures, and must not be altered
dynamically. This practice makes the driver code independent of
device register address assignments and of the actual location of the
interrupt vector.
The driver data structure must include a storage
assignment and
initialization for the
interrupt vector with the
priority set to PR7.
See lines 81 through 85 in Section 6.2.1
(Section 6.2.1 contains the source code for the data structure of a
sample resident driver).
Writers of loadable drivers do not initialize the device interrupt
vector.
The vector is dynamically established by the MCR LOA command
when the driver is loaded. When a driver is unloaded,
the MCR UNL
command sets the vector to the system nonsense interrupt entry point.

4.2

MULTICONTROLLER DRIVERS

This section discusses the conditional code needed at the
interrupt
entry point of a driver that may handle one or several device
controllers. This discussion leads to a description in the next
INTSV$ contains multicontroller
section of the system macro INTSV$.
conditionals and other features to simplify interrupt entry coding.
Figure 4-6 shows the interrupt entry coding from the paper-tape-punch
driver.
This is an earlier version of the driver presented in its
entirety in Section 6.2.2.
The coding
is conditionalized on P$$Pll-l.
The symbol
represents the number of controllers and is set at SYSGEN.

P$$P 11

In a multicontroller device configuration, the controllers
are
numbered starting with O.
The code for a multicontroller driver
contains a table (called CNTBL in the example in Figure 4-6)
whose
length in words is equal to the number of controllers. A number
called the controller index--equal to the controller number times
2--is stored in the SCB for each controller, in byte S.CON.
When an I/O request occurs, and the driver is called at its initiator
entry point, the driver first calls $GTPKT to obtain an I/O packet to
process. Among the values returned by $GTPKT are the controller index
(obtained from S.CON in the SCB) and the address of the UCB for the
unit requesting I/O service.

4-33

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS

The driver stores the requesting unit's UCB address in the controller
table
(CNTBl)
at an offset equal to the controller index. Thus, for
the driver at its interrupt entry point to access the requesting UCB,
it needs simply to obtain the controller index.
The controller index is obtained from the controller number, which is
encoded in the lowest four bits of the PS word in the device's
interrupt vector. At its interrupt entry point the driver first saves
the PS
(line 9.
in Figure 4-6), which was set from the device's
interrupt vector upon interrupt. The PS must be saved with the first
instruction of interrupt code because its lower four bits are the
processor condition code bits, which generally change after each
instruction is issued.
Later, after the call to $INTSV, the driver
constructs the controller index from the saved PS (lines 17.-19.). It
then uses this index to obtain the UCB address (line 20.).
For single-controller devices, CNTBL is one word, TEMP is not needed
to store the PS, and the UCB address is always the first (and only)
entry in CNTBL.
NOTE
The code sequence used in the following
example is not valid for a loadable
driver.

1
2
3
4
5
6
7
8
9

10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

; **-$PPINT-PC11 PAPER TAPE PUNCH CONTROLLER INTERRUPTS
;-

$PPINT: :

;;;REF LABEL

• IF GT P$$P 11-1
MOV

PS, TEMP

;;;SAVE CONTROLLER NUMBER

$INTSV, PR4

; ;;SAVE REGISTERS AND SET PRIORITY

TEMP,R4
U77760,R4
R4
CNTBL(R4) ,RS

;;;RETRIEVE CONTROLLER NUMBER
;;;CLEAR ALL BUT CONTROLLER NUMBER
;;;CONVERT TO CONTROLLER INDEX
;;;RETRIEVE ADDRESS OF UCB

CNTBL, RS

;;;RETRIEVE ADDRESS OF UCB

.IFTF
CALL
.IFT
MOV
BIC
ASL
MOV
.IFF
MOV
• ENDC
Figure 4-6

Conditional Code for a Multicontroller Driver

4-34

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
4.3

THE INTSV$ MACRO

INTSV$ is a system macro that minimizes coding differences between
loadable
and
resident
drivers.
INTSV$ contains conditionaily
assembled code to handle:
•

Single or multiple controllers

•

Loadable or resident drivers

•

Mapped or unmapped systems

You can replace all the code in Figure 4-6 between lines 7 and 26 with
the INTSV$ macro (as is done in the sample driver illustrated in
Section 6.2.2). This is required for loaaao1e drivers on mapped
systems, because interrupts from hardware devices must be processed in
kernel address space. In particular, the decoding of the PS word and
the call to $INTSV must be done before entering the driver. Thus, a
call to the Executive routine $INTSV within a loadable driver is
illegal, and the MCR LOA function returns an error if loading is
attempted.
When the INTSV$ macro is used for a loadable driver in a mapped
system, the code from lines 9 to 19 inclusive (Figure 4-6) is not
assembled as part of the driver. Instead, the LOA function allocates
a block of dynamic memory in kernel address space to contain the
interrupt coding. This block, called the Interrupt Control Block
(ICB), also contains coding to perform the following:
1.

Save the kernel mapping (APRS)

Load APRS to map the driver

Transfer to the driver

Restore the mapping after return

The LOA function also sets up the controller's
that hardware interrupts point to the ICB.

interrupt

vector

Finally, using the INTSV$ macro in a loadable driver on a mapped
system requires that the symbol LD$xx (where xx is the 2-character
device mnemonic) be defined either in the driver source or the
assembly prefix file RSXMC.MAC.

4.3.1

Format

The format of the INTSV$ macro is:
INTSV$

xx,pri,nctlr[,pssave,ucbsave]

xx
The 2-character device mnemonic.
pri
The priority of the device (the priority that would be used in
call to $INTSV).

4-35

WRITING AN I/O DRIVER--PROGRAMMING SPECIFICS
nctlr
The number of controllers the driver services.
pssave
An optional argument specifying a variable in which to
PS word. If omitted, a variable named TEMP is used.

save

the

An optional argument specifying a block of contiguous words
which to retrieve the interrupting device's UCB address.
omitted, a block of contiguous words named CNTBL is used.

in
If

ucbsave

Outputs: R4

is the controller index, only if nctlr is

greater

than

is the UCB address.

Example:
INTSV$

PP,PR4,P$$Pll

This usage of INTSV$ would effectively replace lines 7 through 26
Figure
4-6.
(P$$Pll
is a symbol equated to the number
controllers.)

4-36

in
of

CHAPTER S
EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

This section contains the Executive routines typically used by I/O
drivers. They are listed in alphabetical order. The descriptions are
taken directly from the source code for the associated services.
We describe only the most widely used subroutines.
Many other
Executive service subroutines are available in modules IOSUB.MAC,
EXESB.MAC, MEMAP.MAC, SYSXT.MAC, QUEUE.MAC, CORAL.MAC,
and REQSB.MAC
in UFD [11,10].

S.l

SYSTEM STATE REGISTER CONVENTIONS

In system state, RS and R4 are, by convention, nonvolatile registers.
This means that an internally called routine is required to save and
restore these two registers if the routine destroys their contents.
R3,
R2, Rl, and RO are volatile registers and may be used by a called
routine without save and restore responsibilities.
When a driver is entered directly from an interrupt, it is operating
at interrupt level, not at system state.
At interrupt level, any
register the driver uses must be saved and restored.
INTSV$ preserves
RS and R4 for the driver's use.
A routine may violate these conventions as long as an explicit
statement exists in the program preface detailing the departure from
conventions.
Such departures should generally be avoided;
they
should be employed only when you can demonstrate that a departure from
convention can improve overall system performance.
See D.DSP in Section 4.1.2.1 for the
driver is entered.

S.2

contents

registers

when

CONDITIONAL ROUTINES

Two of the routines ($GTWRD and $PTWRD)
discussed
in this chapter
normally are assembled conditionally out of the Executive code.
If a
user-written driver requires either of these routines, the appropriate
question must be answered affirmatively in the system generation
dialog.
See the descriptions of $GTWRD and $PTWRD below.

S.3

SERVICE CALLS

In the following descriptions! the file names mentioned are source
modules found on the Executive source disk as [11,lO]filnam.MAC.

S-1

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$ACHKB~ACHCK

ADDRESS CHECK
These routines are in the file EXESB.
A driver may call either
routine to address-check a task buffer while the task is the current
task. The $ACHKB and $ACHCK routines are normally used only by
drivers setting UC.QUE in U.CTL.
See Section 6.3 for an example.
Calling sequences:
CALL $ACHKB
or
CALL $ACHCK
Description:
;+
**-$ACHKB-ADDRESS CHECK BYTE ALIGNED
**-$ACHCK-ADDRESS CHECK WORD ALIGNED
THIS ROUTINE IS CALLED TO ADDRESS CHECK A BLOCK OF MEMORY TO SEE
WHETHER IT LIES WITHIN THE ADDRESS SPACE OF THE CURRENT TASK.
INPUTS:
RO=STARTING ADDRESS OF THE BLOCK TO BE CHECKED.
Rl=LENGTH OF THE BLOCK TO BE CHECKED IN BYTES.
OUTPUTS:
C=l IF ADDRESS CHECK FAILED.
C=O IF ADDRESS CHECK SUCCEEDED.
RO AND R3 ARE PRESERVED ACROSS CALL.
;-

5-2

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$ALOCB

ALLOCATE CORE BUFFER
This routine is in the file CORAL.
Calling sequences:
CALL $ALOCB
or
CALL $ALOC1
;+

**-$ALOCB-ALLOCATE CORE BUFFER
**-$ALOC1-ALLOCATE CORE BUFFER (ALTERNATE ENTRY)
THIS ROUTINE IS CALLED TO ALLOCATE AN EXEC CORE BUFFER. THE
ALLOCATION ALGORITHM IS FIRST FIT AND BLOCKS ARE ALLOCATED IN
MULTIPLES OF FOUR BYTES.
INPUTS:
RO=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT $ALOC1.
Rl=SIZE OF THE CORE BUFFER TO ALLOCATE IN BYTES.
OUTPUTS:
C=l IF INSUFFICIENT CORE IS AVAILABLE TO ALLOCATE THE BLOCK.
C=O IF THE BLOCK IS ALLOCATED.
RO=ADDRESS OF THE ALLOCATED BLOCK.
Rl=LENGTH OF BLOCK ALLOCATED.
;-

5-3

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$ASUMR

ASSIGN UNIBUS MAPPING REGISTERS
This routine is in the file MEMAP.
It is used only for NPR devices
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is
enabled. Normally, it is not called directly by an I/O driver.
Rather,
it is called from within the $STMAP routine.
Refer to
Appendix B for a discussion.
Calling sequence:
CALL $ASUMR
Description:

;+
**-$$ASUMR-ASSIGN UNIBUS MAPPING REGISTERS
THIS ROUTINE IS CALLED TO ASSIGN A CONTIGUOUS SET OF UMR'S. NOTE THAT
FOR THE SAKE OF SPEED, THE LINK WORD OF EACH MAPPING ASSIGNMENT BLOCK
POINTS TO THE UMR ADDRESS (2ND) WORD OF THE BLOCK, NOT THE FIRST WORD.
THE CURRENT STATE OF UMR ASSIGNMENT IS REPRESENTED BY A LINKED LIST OF
MAPPING ASSIGNMENT BLOCKS, EACH BLOCK CONTAINING THE ADDRESS OF THE
FIRST UMR ASSIGNED AND THE NUMBER OF UMR'S ASSIGNED TIMES 4. THE
BLOCKS ARE LINKED IN THE ORDER OF INCREASING FIRST UMR ADDRESS.
INPUTS:
RO=POINTER TO A MAPPING REGISTER ASSIGNMENT BLOCK.
M.UMRN(RO)=NUMBER OF UMR'S REQUIRED * 4.
OUTPUTS:
ALL REGISTERS ARE PRESERVED.
C=O IF THE UMR'S WERE SUCCESSFULLY ASSIGNED.
ALL FIELDS OF THE MAPPING REGISTER ASSIGNMENT BLOCK
ARE INITIALIZED AND THE BLOCK IS LINKED INTO
THE ASSIGNMENT LIST.
C=l IF THE UMR'S COULD NOT BE ASSIGNED.
;-

5-4

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$CLINS

CLOCK QUEUE INSERTION
This routine is in the file QUEUE.
Calling sequence:
CALL $CLINS
Description:
;+
**-$CLINS-CLOCK QUEUE INSERTION
THIS ROUTINE IS CALLED TO MAKE AN ENTRY IN THE CLOCK QUEUE. THE ENTRY
IS INSERTED SUCH THAT THE CLOCK QUEUE IS ORDERED IN ASCENDING TIME.
THUS THE FRONT ENTRIES ARE MOST IMMINENT AND THE BACK LEAST.
INPUTS:
RO=ADDRESS OF THE CLOCK QUEUE ENTRY CORE BLOCK.
Rl=HIGH ORDER HALF OF DELTA TIME.
R2=LOW ORDER HALF OF DELTA TIME.
R4=REQUEST TYPE.
R5=ADDRESS OF REQUESTING TCB OR REQUEST IDENTIFIER.
OUTPUTS:
THE CLOCK QUEUE ENTRY IS INSERTED IN THE CLOCK QUEUE ACCORDING
TO THE TIME THAT IT WILL COME DUE.
~-

5-5

EXECUTIVE SERVICES AVAILABLE TO I/0 DRIVERS

$DEACB

DEALLOCATE CORE BUFFER
This routine is in the file CORAL.
Calling sequences:
CALL $DEACB
or
CALL $DEAC1

;+
**-$DEACB-DEALLOCATE CORE BUFFER
**-$DEAC1-DEALLOCATE CORE BUFFER (ALTERNATE ENTRY)
THIS ROUTINE IS CALLED TO DEALLOCATE AN EXEC CORE BUFFER.
THE BLOCK
IS INSERTED INTO THE FREE_ BLOCK CHAIN BY CORE ADDRESS.
IF AN
ADJACENT BLOCK IS CURRENTLY FREE, THEN THE TWO BLOCKS ARE MERGED
AND INSERTED IN THE FREE BLOCK CHAIN.
INPUTS:
RO=ADDRESS OF THE CORE BUFFER TO BE DEALLOCATED.
Rl=SIZE OF THE CORE BUFFER TO DEALLOCATE IN BYTES.
R3=ADDRESS OF CORE ALLOCATION LISTHEAD-2 IF ENTRY AT $DEAC1.
OUTPUTS:
THE CORE BLOCK IS MERGED INTO THE FREE CORE CHAIN BY CORE
ADDRESS AND IS MERGED IF NECESSARY WITH ADJACENT BLOCKS.
;-

5-6

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$DEUMR

DEASSIGN UNIBUS MAPPING REGISTERS
This routine is in the file MEMAP.
It is used only for NPR devices
requiring UNIBUS Mapping Registers, when. 22-bit memory addressing is
enabled. Normally, it is not called directly by an I/O driver.
Rather, it is called from within the $IODON routine. Refer to
Appendix B for a discussion.,
Calling sequence:
CALL $DEUMR
Description:
;+
**-$DEUMR-DEASSIGN UNIBUS MAPPING REGISTERS
THIS ROUTINE IS CALLED TO DEASSIGN A CONTIGUOUS BLOCK OF UMR'S. IF
THE MAPPING ASSIGNMENT BLOCK IS NOT IN THE LIST, NO ACTION IS TAKEN.
NOTE THAT FOR THE SAKE OF ASSIGNMENT SPEED, THE LINK WORD POINTS TO
THE UMR ADDRESS (2ND) WORD OF THE ASSIGNMENT BLOCK.
INPUTS:
R2=POINTER TO ASSIGNMENT BLOCK.
OUTPUTS:
RO AND Rl ARE PRESERVED.
;-

5-7

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$DVMSG

DEVICE MESSAGE OUTPUT
This routine is in file EXESB.
Calling sequence:
CALL

$DVMSG

Description:
;+

**-$DVMSG-DEVICE MESSAGE OUTPUT
THIS ROUTINE IS CALLED TO SUBMIT A MESSAGE TO THE TASK TERMINATION
NOTIFICATION TASK. MESSAGES ARE EITHER DEVICE RELATED OR A
CHECKPOINT WRITE FAILURE FROM THE LOADER.
INPUTS:
RO=MESSAGE NUMBER.
RS=ADDRESS OF THE UCB OR TCB THAT THE MESSAGE APPLIES TO.
OUTPUTS:
A FOUR WORD PACKET IS ALLOCATED, RO AND RS ARE STORED IN THE
SECOND AND THIRD WORDS, RESPECTIVELY, AND THE PACKET IS
THREADED INTO THE TASK TERMINATION NOTIFICATION TASK MESSAGE
QUEUE.
NOTE:

IF THE TASK TERMINATION NOTIFICATION TASK IS NOT
INSTALLED OR NO STORAGE CAN BE OBTAINED, THEN THE
MESSAGE REQUEST IS IGNORED.

Note:
Drivers use only two codes in calling $DVMSG:
T.NDNR (device not
ready), and T.NDSE
{select error).
$DVMSG can be set up and
called as follows:
MOV

#T.NDNR,RO

or
MOV
CALL

#T.NDSE,RO
$DVMSG

5-8

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$EXRQP

EXECUTIVE REQUEST WITH QUEUE INSERT BY PRIORITY
This routine is in the file REQSB.
$EXRQP requests the execution of a
task after inserting a packet into the receive list of the task.
Calling sequence:
CALL $EXRQP
Description:

;+
**-$EXRQP-EXECUTIVE
**-$EXRQF-EXECUTIVE
**-$EXRQN-EXECUTIVE
**-$EXRQU-EXECUTIVE
**-$EXRQS-EXECUTIVE

REQUEST WITH QUEUE INSERT BY PRIORITY
REQUEST WITH QUEUE INSERT FIFO
REQUEST WITH NO QUEUE INSERTION
UNSTOP AND REQUEST WITH NO QUEUE INSERTION
REQUEST WITH NO CONDITIONAL SCHEDULE REQUEST

THESE ROUTINES PROVIDE A STANDARD INTERFACE TO ALL TASKS REQUESTED BY
THE EXECUTIVE
INPUTS:
RO=TCB ADDRESS OF TASK TO REQUEST
Rl=ADDR OF PACKET TO QUEUE TO TASK (IF ENTRY AT $EXRQP/$EXRQF)
OUTPUTS:
C=O IF THE REQUEST WAS SUCCESSFULLY COMPLETED.
C=l IF THE TASK WAS NOT SUCCESSFULLY REQUESTED.
Z=O IF PCB ALLOCATION FAILURE.
Z=l IF TASK ACTIVE, BEING REMOVED, OR BEING FIXED.
;-

5-9

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$FORK

FORK
This routine is in the file SYSXT.
A driver calls $FORK to switch
from a
partially interruptable level (its state following a call on
$INTSV) to a fully interruptable level.
Ca~ling

sequence:

CALL $FORK
Description:

;+
**-$FORK-FORK AND CREATE SYSTEM PROCESS
THIS ROUTINE IS CALLED FROM AN I/O DRIVER TO CREATE A SYSTEM PROCESS THAT
WILL RETURN TO THE DRIVER AT STACK DEPTH ZERO TO FINISH PROCESSING.
INPUTS:
RS=ADDRESS OF THE UCB FOR THE UNIT BEING PROCESSED.
OUTPUTS:
REGISTERS RS AND R4 ARE SAVED IN THE CONTROLLER FORK BLOCK AND
A SYSTEM PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK
QUEUE AND A JUMP TO $INTXT IS EXECUTED.
;-

Notes:
1.

$FORK cannot be called unless $INTSV has been previously
called.
The fork-processing routine assumes that $INTSV has
set up entry conditions.

A driver's current time-out count is cleared
in calls to
$FORK.
This
protects the driver from synchronization
problems that can occur when an I/O request and the time-out
for that request happen at the same time.
After a return
from a call to $FORK, a driver's time-out code will not be
entered.
If the clearing of the time-out
driver has two alternatives:

count

not

desired,

Perform time-out operations
by
directly
inserting
elements in the clock queue (refer to the description of
the $CLINS routine).

Perform necessary initialization,
including
clearing
S.STS in the SCB to zero (establishing the controller as
not busy), and call the $FORK1 routine rather than $FORK.
Calling $FORK1 bypasses the clearing of the current
time-out count.

The driver must not have any information on
$FORK is called.

5-10

the

stack

when

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$FORK1

FOR Kl
This routine is in the file SYSXT.
A driver calls $FORK1 to bypass
the clearing of its time-out count when it switches from a partially
interruptable level to a fully interruptable level (refer also to the
description of the $FORK routine).
Calling sequence:
CALL $FORK1
Description:

;+
**-$FORK1-FORK AND CREATE SYSTEM PROCESS
THIS ROUTINE IS AN ALTERNATE ENTRY TO CREATE A SYSTEM PROCESS AND
SAVE REGISTER RS.
INPUTS:
R4=ADDRESS OF THE LAST WORD OF A 3 WORD FORK BLOCK PLUS 2.
RS=REGISTER TO BE SAVED IN THE FORK BLOCK.
OUTPUTS:
REGISTER RS IS SAVED IN THE SPECIFIED FORK BLOCK AND A SYST'EM
PROCESS IS CREATED. THE PROCESS IS LINKED TO THE FORK QUEUE
AND A JUMP TO $INTXT IS EXECUTED.
;-

Notes:
1.

For mapped systems with loadable driver support,
fork block is required for calls to $FORK1.

When a S-word fork block is used, the driver must initialize
the fifth word with the base address (in 32-word blocks) of
the driver partition. This address can be obtained from the
fifth word of the standard fork block in the SCB.

The driver must not have any information on
$FORK1 is called.

S-11

the

stack

S-word

when

EXECUTIVE SERVICES AVAI-LABLE TO I/O DRIVERS

$GTBYT

GET BYTE
This routine is in the file BFCTL.
U.BUF+2 in the UCB.

$GTBYT manipulates words U.BUF and

Calling sequence:
CALL

$GTBYT

Description:

;+
**-$GTBYT-GET NEXT BYTE FROM USER BUFFER
THIS ROUTINE IS CALLED TO GET THE NEXT BYTE FROM THE USER BUFFER
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE BYTE HAS BEEN
FETCHED, THE NEXT BYTE ADDRESS IS INCREMENTED.
INPUTS:
RS=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS.
OUTPUTS:
THE NEXT BYTE IS FETCHED FROM THE USER BUFFER AND RETURNED
TO THE CALLER ON THE STACK. THE NEXT BYTE ADDRESS IS
INCREMENTED.
ALL REGISTERS ARE PRESERVED ACROSS CALL.
;-

5-12

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$GTPKT

GET PACKET
This routine is in the file IOSUB.
Calling sequence:
CALL

$GT PKT

Description:

;+
**-$GTPKT-GET I/O PACKET FROM REQUEST QUEUE
THIS ROUTINE IS CALLED BY DEVICE DRIVERS TO DEQUEUE THE NEXT I/O
REQUEST TO PROCESS. IF THE DEVICE CONTROLLER IS BUSY, THEN A CARRY
SET INDICATION IS RETURNED TO THE CALLER. ELSE AN ATTEMPT IS MADE TO
DEQUEUE THE NEXT REQUEST FROM THE CONTROLLER QUEUE. IF NO REQUEST
CAN BE DEQUEUED, THEN A CARRY SET INDICATION IS RETURNED TO THE
CALLER. ELSE THE CONTROLLER IS SET BUSY AND A CARRY CLEAR
INDICATION IS RETURNED TO THE CALLER.
INPUTS:
RS=ADDRESS OF THE UCB OF THE CONTROLLER TO GET A PACKET FOR.
OUTPUTS:
C=l IF CONTROLLER IS BUSY OR NO REQUEST CAN BE DEQUEUED.
C=O IF A REQUEST WAS SUCCESSFULLY DEQUEUED.
Rl=ADDRESS OF THE I/O PACKET.
R2=PHYSICAL UNIT NUMBER.
R3=CONTROLLER INDEX.
R4=ADDRESS OF THE STATUS CONTROL BLOCK.
RS=ADDRESS OF THE UNIT CONTROL BLOCK.
NOTE: R4 AND RS ARE DESTROYED BY THIS ROUTINE.
;-

5-13

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$GTWRD

GET WORD
This routine is in the file BFCTL.
$GTWRD manipulates words U.BUF and
U.BUF+2
in the UCB, and
is conditionally assembled.
If your
user-written driver requires this routine, answer Yes during Phase I
of SYSGEN when the following question is asked:
*26. Include routine $GTWRD? [Y/N]:
If an LPAll device (LA:)
is included
in your system, the $GTWRD
rotitine is automatically included and Question 26 is not asked.
Calling sequence:
CALL

$GTWRD

Description:

;+
**-$GTWRD-GET NEXT WORD FROM USER BUFFER
THIS ROUTINE IS CALLED TO GET THE NEXT WORD FROM THE USER BUFFER
AND RETURN IT TO THE CALLER ON THE STACK. AFTER THE WORD HAS BEEN
FETCHED, THE NEXT WORD ADDRESS IS CALCULATED.
INPUTS:
RS=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS.
OUTPUTS:
THE NEXT WORD IS FETCHED FROM THE USER BUFFER AND RETURNED
TO THE CALLER ON THE STACK. THE NEXT WORD ADDRESS IS CALCULATED.
ALL REGISTERS ARE PRESERVED ACROSS CALL.
;-

5-14

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$1NTSV

INTERRUPT SAVE
This routine is in the file SYSXT.
Calling sequence:
CALL

$INTSV,PRn

n has a range of

0~7.

Description:

,.......
**-$INTSV-INTERRUPT SAVE
THIS ROUTINE IS CALLED FROM AN INTERRUPT SERVICE ROUTINE WHEN AN
INTERRUPT IS NOT GOING TO BE IMMEDIATELY DISMISSED. A SWITCH TO
THE SYSTEM STACK IS EXECUTED IF THE CURRENT STACK DEPTH IS +l. WHEN
THE INTERRUPT SERVICE ROUTINE FINISHES ITS PROCESSING, IT EITHER FORKS,
JUMPS TO $INTXT, OR EXECUTES A RETURN.
INPUTS:
4(SP)=PS WORD PUSHED BY INTERRUPT.
2(SP)=PC WORD PUSHED BY INTERRUPT.
O(SP)=SAVED RS PUSHED BY 'JSR R5,$INTSV'.
O(RS)=NEW PROCESSOR PRIORITY.
OUTPUTS:
REGISTER R4 IS PUSHED ONTO THE CURRENT STACK AND THE CURRENT
STACK DEPTH IS DECREMENTED. IF THE RESULT IS ZERO, THEN
A SWITCH TO THE SYSTEM STACK IS EXECUTED. THE NEW PROCESSOR
STATUS IS SET AND A CO-ROUTINE CALL TO THE CALLER IS EXECUTED.
;Note:
A system macro, INTSV$, is provided to simplify the coding
standard interrupt entry processing. See Section 4.3.

5-15

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$1NTXT

INTERRUPT EXIT
This routine is in the file SYSXT.
Calling sequence:
JMP

$INTXT

or
RETURN (if a call to $INTSV has been executed)
Description:

;+
**-$INTXT-INTERRUPT EXIT
THIS ROUTINE IS CALLED VIA A RETURN TO EXIT FROM AN INTERRUPT. IF THE
STACK DEPTH IS NOT EQUAL TO ZERO, THEN REGISTERS R4 AND RS ARE
RESTORED AND AN RTI IS EXECUTED. ELSE A CHECK IS MADE TO SEE
IF THERE ARE ANY ENTRIES IN THE FORK QUEUE. IF NONE, THEN R4 AND
RS ARE RESTORED AND AN RTI IS EXECUTED. ELSE REGISTERS R3 THRU
RO ARE SAVED ON THE CURRENT STACK AND A DIRECTIVE EXIT IS EXECUTED.
INPUTS:

(MAPPED SYSTEM)
06(SP)=PS WORD PUSHED BY INTERRUPT.
04(SP)=PC WORD PUSHED BY INTERRUPT.
02(SP)=SAVED RS.
OO(SP)=SAVED R4.

INPUTS:

(REAL MEMORY SYSTEM)
NONE.

5-16

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$10AL T/$10DON

I/O DONE ALTERNATE ENTRY and I/O DONE
These routines are in the file IOSUB.
Calling sequences:
CALL
CALL

$IOALT
$IODON

Description:
;+
**-$IOALT-I/O DONE (ALTERNATE ENTRY)
**-$IODON-I/O DONE
THIS ROUTINE IS CALLED BY DEVICE DRIVERS AT THE COMPLETION OF AN I/O REQUEST
TO DO FINAL PROCESSING. THE UNIT AND CONTROLLER ARE SET IDLE AND $IOFIN IS
ENTERED TO FINISH THE PROCESSING.
INPUTS:
RO=FIRST I/O STATUS WORD.
Rl=SECOND I/O STATUS WORD.
R2=STARTING AND FINAL ERROR RETRY COUNTS IF ERROR LOGGING DEVICE.
RS=ADDRESS OF THE UNIT CONTROL BLOCK OF THE UNIT BEING COMPLETED.
NOTE: IF ENTRY IS AT $IOALT, THEN Rl IS CLEARED TO SIGNIFY THAT THE
SECOND STATUS WORD IS ZERO.
OUTPUTS:
THE UNIT AND CONTROLLER ARE SET IDLE.
R3=ADDRESS OF THE CURRENT I/O PACKET.
;NOTE
R4 is destroyed when either of these
routines is called. The routines call
$IOFIN, which destroys R4.
These routines push the address
of
routine $DQUMR onto the stack before
returning to the driver.
This precludes
the use of the stack for temporary data
storage by drivers when calling these
routines.

5-17

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$10FIN

I/O FINISH
This routine is in the file IOSUB. Most drivers do not call $IOFIN,
but you should be aware that this routine is executed when a driver
calls $IOALT or $IODON. A driver that references an I/O packet before
it is queued
(bit UC.QUE set--see Section 6.3 for an example) calls
$IOFIN if the driver finds an error while preprocessing the I/O
packet.
Calling sequence:
CALL

$IOFIN

Description:

;+
**-$IOFIN-I/O FINISH
THIS ROUTINE IS CALLED TO FINISH I/O PROCESSING IN CASES WHERE THE UNIT AND
CONTROLLER ARE NOT TO BE DECLARED IDLE.
INPUTS:
RO=FIRST I/O STATUS WORD.
Rl=SECOND I/O STATUS WORD.
R3=ADDRESS OF THE I/O REQUEST PACKET.
R5=ADDRESS OF THE UNIT CONTROL BLOCK.
OUTPUTS:
THE FOLLOWING ACTIONS ARE PERFORMED:
1-THE FINAL I/O STATUS VALUES ARE STORED IN THE I/O STATUS BLOCK IF
ONE WAS SPECIFIED.

2-THE I/O REQUEST COUNT IS DECREMENTED. IF THE RESULTANT COUNT IS
ZERO, THEN 'TS.RON' IS CLEARED IN CASE THE TASK WAS
STOPPED FOR I/O RUNDOWN.
3-IF 'TS.CKR' IS SET; THEN IT IS CLEARED AND CHECKPOINTING OF THE
TASK IS INITIATED.
4-IF AN AST SERVICE ROUTINE WAS SPECIFIED, THEN AN AST IS QUEUED
FOR THE TASK. ELSE THE I/O PACKET rs DEALLOCATED.
5-A SIGNIFICANT EVENT OR EQUIVALENT IS DECLARED.
NOTE: R4 rs DESTROYED BY THIS ROUTINE.

5-18

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$MPUBM

MAP UNIBUS TO MEMORY
This routine is in the file MEMAP.
$MPUBM is used only for NPR
devices
requ1r1ng UNIBUS Mapping Registers, when 22-bit memory
addressing is enabled. See Appendix B for a discussion.
Calling sequence:
CALL

$MPUBM

Description:

;+
**-$MPUBM-MAP UNIBUS TO MEMORY
THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN MEMORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY.
INPUTS:
R4=ADDRESS OF DEVICE SCB.
RS=ADDRESS OF DEVICE UCB.
OUTPUTS:
THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE
ARE LOADED.
NOTE: REGISTER R3 IS PRESERVED ACROSS CALL.
;-

5-19

TRANSFER

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$MPUB1

MAP UNIBUS TO MEMORY {ALTERNATE ENTRY)
This routine is in file MEMAP.
It is used only for NPR devices that
require UNIBUS Mapping Registers, support parallel operations, and
have 22-bit memory addressing enabled.
See Appendix B for
a
discussion of using this routine.
Calling sequence:
CALL

$MPUB1

Description:

;+
**-$MPUB1-MAP UNIBUS TO MEMORY {ALTERNATE ENTRY)
THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO LOAD THE
NECESSARY UNIBUS MAP REGISTERS TO EFFECT A TRANSFER TO MAIN
MEMORY ON PDP-11 PROCESSORS WITH EXTENDED MEMORY. THIS ALTERNATE
ENTRY POINT ALLOWS THE DRIVER TO SPECIFY A NON-STANDARD UMR MAPPING
ASSIGNMENT BLOCK.
INPUTS:
RO=ADDRESS OF A UMR MAPPING ASSIGNMENT BLOCK
R4=ADDRESS OF DEVICE SCB
RS=ADDRESS OF DEVICE UCB
OUTPUTS:
THE UNIBUS MAP REGISTERS NECESSARY TO EFFECT THE
TRANSFER ARE LOADED
NOTE: REGISTER R3 IS PRESERVED ACROSS CALL.
;-

5-20

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$PTBVT

PUT BYTE
This routine is in the file BFCTL.
U.BUF+2 in the UCB.

$PTBYT manipulates words U.BUF and

Calling sequence:
CALL

$PTBYT

Description:

;+
**-$PTBYT-PUT NEXT BYTE IN USER BUFFER
THIS ROUTINE IS CALLED TO PUT A BYTE IN THE NEXT LOCATION IN
USER BUFFER. AFTER THE BYTE HAS BEEN STORED, THE NEXT BYTE ADDRESS
IS INCREMENTED.
INPUTS:
RS=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS.
2(SP)=BYTE TO BE STORED IN THE NEXT LOCATION OF THE USER BUFFER.
OUTPUTS:
THE BYTE IS STORED IN THE USER BUFFER AND REMOVED FROM
THE STACK. THE NEXT BYTE ADDRESS IS INCREMENTED.
ALL REGISTERS ARE PRESERVED ACROSS CALL.

5-21

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$PTWRD

PUT WORD
This routine
U.BUF+2 in
user-written
of SYSGEN to

is in the file BFCTL.
$PTWRD manipulates words U.BUF and
the UCB.
$PTWRD is conditionally assembled.
If your
driver requires this routine, answer Yes during Phase I
the following question:

*27. Include routine $PTWRD? [Y/N]:
If an ADOl A/D controller device (AF:)
or an AFCll A/D controller
device
(AF:)
is included in your system, the $PTWRD routine is
automatically included and Question 27 is not asked.
Do you intend to include a user written driver? (Y/N]:
Calling sequence:
CALL

$PTWRD

Description:

;+
**-$PTWRD-PUT NEXT WORD IN USER BUFFER
THIS ROUTINE IS CALLED TO PUT A WORD IN THE NEXT LOCATION IN
USER BUFFER. AFTER THE WORD HAS BEEN STORED, THE NEXT WORD ADDRESS
IS CALCULATED.
INPUTS:
RS=ADDRESS OF THE UCB THAT CONTAINS THE BUFFER POINTERS.
2(SP)=WORD TO BE STORED IN THE NEXT LOCATION OF THE BUFFER.
OUTPUTS:
THE WORD IS STORED IN THE USER BUFFER AND REMOVED FROM
THE STACK. THE NEXT WORD ADDRESS IS CALCULATED.
ALL REGISTERS ARE PRESERVED ACROSS CALL.
;-

5-22

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$QINSP

QUEUE INSERTION BY PRIORITY
This routine is in the file QUEUE.
A driver may call $QINSP to insert
into the I/O queue an I/O packet that the Executive has not already
placed in the queue.
$QINSP is used only by drivers setting UC.QUE in
U.CTL. See Section 6.3 for an example.
Calling sequence:
CALL

$QINSP

Description:

;+
**-$QINSP-QUEUE INSERTION BY PRIORITY
THIS ROUTINE IS CALLED TO INSERT AN ENTRY IN A PRIORITY ORDERED
LIST. THE LIST IS SEARCHED UNTIL AN ENTRY IS FOUND THAT HAS A
LOWER PRIORITY OR THE END OF THE LIST IS REACHED. THE NEW
ENTRY IS THEN LINKED INTO THE LIST AT THE APPROPRIATE POINT.
INPUTS:
RO=ADDRESS OF THE TWO WORD LISTHEAD.
Rl=ADDRESS OF THE ENTRY TO BE INSERTED.
OUTPUTS:
THE ENTRY IS LINKED INTO THE LIST BY PRIORITY.
RO AND Rl ARE PRESERVED ACROSS CALL.
;-

5-23

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$QRMVF

QUEUE REMOVAL FROM FRONT OF LIST
This routine is in the file QUEUE.
Calling sequence:
CALL $QRMVF
Description:

;+
**-$QRMVG-QUEUE REMOVAL FROM FRONT OF LIST
THIS ROUTINE IS CALLED TO REMOVE THE NEXT (FRONT) ENTRY FROM A
LIST.
THE LIST ORGANIZATION MAY BE EITHER FIFO OR BY PRIORITY.
INPUTS:
RO=ADDRESS OF THE TWO WORD LISTHEAD.
OUTPUTS:
C=l IF THERE ARE NO ENTRIES IN THE LIST.
C=O IF THE NEXT ENTRY IS REMOVED FROM THE LIST.
Rl=ADDRESS OF THE ENTRY REMOVED.
RO IS PRESERVED ACROSS CALL.
;-

5-24

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$RELOC

RELOCATE
Relocate is in the file MEMAP.
A driver may call $RELOC to relocate a
task virtual address while the task is the current task.
Relocate is
normally used only by drivers setting UC.QUE in U.CTL.
See Section
6.3 for an example.
Calling Sequence:
CALL

$RELOC

Description:

;+
**-$RELOC-RELOCATE USER VIRTUAL ADDRESS
THIS ROUTINE IS CALLED TO TRANSFORM A 16 BIT USER VIRTUAL ADDRESS
INTO A RELOCATION BIAS AND DISPLACEMENT IN BLOCK REIATIVE TO APR6.
INPUTS:
RO=USER VIRTUAL ADDRESS TO RELOCATE.
OUTPUTS:
Rl=RELOCATION BIAS TO BE LOADED INTO PAR6.
R2=DISPLACEMENT IN BLOCK PLUS 140000 (PAR6 BIAS).
RO AND R3 ARE PRESERVED ACROSS CALL.
;-

5-25

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$STMAP

SET UP UNIBUS MAPPING ADDRESS
This routine is in the file MEMAP.
It is used only for NPR devices
requiring UNIBUS Mapping Registers, when 22-bit memory addressing is
enabled.
See Appendix B for a discussion.
Calling sequence:
CALL

$STMAP

Description:

;+
**-$STMAP-SET UP UNIBUS MAPPING ADDRESS
THIS ROUTINE IS CALLED BY UNIBUS NPR DEVICE DRIVERS TO SET UP THE
UNIBUS MAPPING ADDRESS, FIRST ASSIGNING THE UMR'S. IF THE UMR'S
CANNOT BE ALLOCATED, THE DRIVER'S MAPPING ASSIGNMENT BLOCK IS PLACED
IN A WAIT QUEUE AND A RETURN TO THE DRIVER'S CALLER IS EXECUTED. THE
ASSIGNMENT BLOCK WILL EVENTUALLY BE DEQUEUED WHEN THE UMR'S ARE
AVAILABLE AND THE DRIVER WILL BE REMAPPED AND RETURNED TO WITH Rl-RS
PRESERVED AND THE NORMAL OUTPUTS OF THIS ROUTINE. THE DRIVER'S
CONTEXT IS STORED IN THE ASSIGNMENT BLOCK AND FORK BLOCK WHILE IT IS
BLOCKED AND IN THE WAIT QUEUE. ONCE A DRIVER'S MAPPING ASSIGNMENT
BLOCK IS PLACED IN THE UMR WAIT QUEUE, IT IS NOT REMOVED FROM THE
QUEUE UNTIL THE UMR'S ARE SUCCESSFULLY ASSIGNED. THIS STRATEGY
ASSURES THAT WAITING DRIVERS WILL BE SERVICED FIFO AND THAT DRIVER'S
WITH LARGE REQUESTS FOR UMR'S WILL NOT WAIT INDEFINITELY.
INPUTS:
R4=ADDRESS OF DEVICE SCB.
RS=ADDRESS OF DEVICE UCB.
(SP)=RETURN TO DRIVER'S CALLER.
OUTPUTS:
UNIBUS MAP ADDRESSES ARE SET UP IN THE DEVICE UCB AND THE
ACTUAL PHYSICAL ADDRESS IS MOVED TO THE SCB.
NOTE: REGISTERS Rl, R2, AND R3 ARE PRESERVED ACROSS CALL.
;-

NOTE
This routine pushes the address
of
routine $DQUMR+2 onto the stack before
returning to the caller.
A driver,
therefore, should not use the stack for
temporary data storage when calling this
routine.

5-26

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$STMP1

SET UP UNIBUS MAPPING ADDRESS

(ALTERNATE ENTRY)

This routine is in file MEMAP.
It is used only for NPR devices that
require UNIBUS Mapping Registers, support parallel operations, and
have enabled 22-bit memory addressing.
See Appendix B for
a
discussion of using this routine.
Calling sequence:
CALL

$STMP1

Description:
;+
**-$STMP1-SET UP UNIBUS MAPPING ADDRESS (ALTERNATE ENTRY)
THIS ENTRY CODE SETS UP AN ALTERNATE DATA STRUCTURE USED AS
A UMR MAPPING ASSIGNMENT BLOCK AND CONTEXT STORAGE BLOCK, IN
THE SAME MANNER AS $STMAP USES THE FORK BLOCK AND MAPPING
BLOCK IN THE SCB. THE FORMAT OF THE STRUCTURE IS AS FOLLOWS:
4 WORDS USED FOR SAVING
DRIVER'S CONTEXT IN CASE
UMR'S CAN'T BE MAPPED
IMMEDIATELY.

6 WORDS USED AS A UMR
MAPPING ASSIGNMENT BLOCK.

INPUTS:
RO=ADDRESS OF THE DATA STRUCTURE DEPICTED ABOVE
R4=ADDRESS OF DEVICE SCB
R5=ADDRESS OF DEVICE UCB
OUTPUTS:
DATA STRUCTURE POINTERS SET UP FOR ENTRY TO $STMP2 IN $STMAP
;NOTE
This routine pushes the address
of
routine $DQUMR+2 onto the stack before
returning to the caller.
A driver,
therefore, should not use the stack for
temporary data storage when calling this
routine.

5-27

EXECUTIVE SERVICES AVAILABLE TO I/O DRIVERS

$SWSTK

SWITCH STACKS
This routine is in the file SYSXT.
Calling sequence:
SWSTK$ 1 ab el
The special macro in RSXMC.MAC must be used.
Description:

;+
**$SWSTK-SWITCH STACKS
THIS ROUTINE IS CALLED FROM TASK LEVEL TO SWITCH TO THE SYSTEM
STACK THUS INHIBITING TASK SWITCHING.
THE CALLING TASK MUST BE
PRIVILEGED IF RUNNING IN A MAPPED SYSTEM AND MAPPED TO THE EXEC.
CONTROL IS PASSED HERE FROM DRDSP AFTER THE TRAP HAS OCCURRED AND
$DIRSV HAS BEEN CALLED.
CALLING SEQUENCE:
EMT 376 ;TRAP TO $EMSST IN DRDSP
.WORD ADDR ;ADDRESS FOR RETURN TO USER STATE
INPUTS AT THIS POINT:
R3=ADDRESS OF PC WORD OF TRAP ON STACK + 2
MAPPED SYSTEM :
22(SP}=PS PUSHED BY TRAP
20(SP}=PC PUSHED BY TRAP
16 (SP} =SAVED RS
14 (SP)=SAVED R4
12(SP)=SAVED R3
lO(SP)=SAVED R2
06(SP)=SAVED Rl
04(SP)=SAVED RO
02(SP)=RETURN ADDRESS FOR SYSTEM EXIT
00 (SP)=l04376
UNMAPPED SYSTEM:
10 (SP} =SAVED R3
06(SP)=SAVED R2
04(SP)=SAVED Rl
02(SP)=SAVED RO
OO(SP)=RETURN ADDRESS FOR SYSTEM EXIT
OUTPUTS:
THE USER IS CALLED BACK ON THE SYSTEM STACK WITH ALL REGISTERS
PRESERVED.
TO RETURN TO TASK LEVEL THE CALLER MERELY EXECUTES
A RETURN.
;-

Note:

Task registers are not modified.

5-28

CHAPTER 6

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES

The first example that follows illustrates the procedures required to
add a resident driver and resident data base to an RSX-llM system so
that they can run on a system without support for loadable drivers and
without multiuser protection.
The driver in the example supports the
punch capability of the PCll Paper Tape Reader/Punch.
Section 6.3 gives a coding example from a resident driver that
inhibits the automatic packet queuing in QIO processing in order to
address-check and relocate a special user buffer.
In addition to the examples shown in this chapter, you should review
the source code for one or more standard DIGITAL-supplied drivers.
Also, examine file SYSTB.MAC, which contains data structures created
by SYSGEN.

6.1

DEVICE DESCRIPTION

The PCll Paper Tape Reader/Punch is capable of reading 8-hole,
unoiled, perforated paper tape at 300 char/s, and punching tape at 50
char/s.
The system consists of a
paper tape reader/punch and
controller.
A unit containing only a reader (PRll) is also available.
In reading tape, a set of photodiodes translates the presence or
absence of holes in the tape to logic levels representing ones and
zeroes.
In punching tape, a mechanism translates logic levels
representing ones and zeroes to the presence or absence, respectively,
of holes in the tape.
Any information read
or
punched
is
parallel-transferred through the controller.
When an address is
placed on the UNIBUS,
the controller decodes the address · and
determines if the reader or punch has been selected.
If one of the
four qevice register addresses has been selected, the controller
determines
whether an input or an output operation should be
performed. An input operation from the reader is initiated when the
processor transmits a command to the paper tape reader status
register.
An output operation is initiated when the processor
transfers a byte to the paper tape punch buffer register.
The controller enables the PDP-11 system to control the reading or
punching of paper tape
in a
flexible manner.
The reader can be
operated independently of the punch;
either device can be under
direct program control or can operate without direct supervision
(through the use of interrupts)
so as to maintain
continuous
operation.

6-1

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
6.2

DATA BASE AND DRIVER SOURCE

The simplicity of writing a conventional driver for RSX-llM is
obscured by the volume of explanation required to cover the universal
case. As you will see below, building a conventional driver is a
straightforward and modest undertaking.

6.2.1

The Data Base

The resident data base source shown below is self-explanatory.
Take
special note of the legal function mask words, starting at line 45.
The standard function codes listed in Table 4-1 were used in creating
the mask. Thus, the punch driver accepts the following I/O functions:

• Cancel I/O {CAN)
• Write Logical Block (WLB)
• Attach Device (ATT)
• Detach Device (DET)
• Access File For Read/Write {ACW)
• Access File For Read/Write/Extend (ACE)
• Deaccess File {DAC)
• Write Virtual Block (WVB)
The CAN function is mandatory.
function actually supported.

The WLB function is the only

transfer

The ATT and DET functions are control functions.
The three ATT/DET
functions are legal for FCS and RMS compatibility, but are set to be
no-ops. The WVB function is legal but is converted to WLB by QIO
directive processing.
The bit mask for each function is as follows:
Function
CAN
WLB
ATT
DET
ACW
ACE
DAC
WVB

Function Code(octal) Mask(octal) Bit Range(decimal}
000001
000002
000010
000020
040000
100000
000001
000004

0
1
3
4
16
17
20
22

0-15.
0-15.
0-15.
0-15.
0-15.
0-15.
16.-31.
16.-31.

The legal masks result from adding the 0-15(decimal) bit-range words
to form a mask and all the 16-3l(decimal) bit-range words to form the
second mask.
The control, no-op, and ACP masks are created in an analogous fashion,
matching bit positions with legal function code meanings.
The complete set of mask words appears on lines 45 through 52
data structure source.

6-2

the

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
The function code selections for record-oriented devices are intended
to match FCS and RMS requirements for file-structured devices. When
FCS or RMS executes an Access For Write, it is simply marked as a
no-op.
This tends to minimize FCS and RMS device-dependent logic.
Note also on line 84 that the controller number, which is encoded
in
the low byte of the interrupt vector PS word in RSX-llM, is set to
zero.
Finally, since the code represents a resident data base, note
that lines 78 through 85 would be omitted for a loadable data base •
1
2
3

• TITLE USRTB

• IDENT /01/

4
5

COPYRIGHT 1976, DIGITAL EQUIPMENT CORP., MAYNARD, MASS.
6
THIS SOF'IWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE
7
ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION
8
OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT
9
AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC.
10
11
THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT
12
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL
13
EQUIPMENT CORPORATION.
14
15
DEC ASSUMES NO RESPONSIBILITY FOR THE USE OR RELIABILITY
16
OF ITS SOF'IWARE ON EQUIPMENT WHICH IS NOT SUPPLIED BY DEC.
17
18
VERSION 01
19
20
21
T. J. PASCUSNIK 25-NOV-74
22
CONTROL BLOCKS FOR PAPER TAPE PUNCH DRIVER
23
24
MACRO LIBRARY CALLS
25
26
27
.MCALL DCBDF$,HWDDF$
28
;DEFINE DEVICE CONTROL BLOCK OFFSETSl
DCBDF$
29
;DEFINE HARDWARE REGISTERS
HWDDF$
30
31
32
33
PAPER TAPE PUNCH DEVICE DATA BASE
34
PAPER TAPE PUNCH DEVICE CONTROL BLOCK
35
36 ;
37 $USRTB::
; LINK TO NEXT DCB
38 PPDCB:
.WORD
0
;POINTER TO FIRST UCB
39
.WORD
• PPO
40
• ASCII /PP/
; DEVICE NAME
;LOWEST AND HIGHEST UNIT NUMBERS COVERED
o,o
41
.BYTE
42
;
BY THIS DCB
43
PPND-PPST
;LENGTH OF EACH UCB IN BYTES
.WORD
44
$PPTBL
;POINTER TO DRIVER .DISPATCH TABLE
.WORD
45
• WORD
;LEGAL FUNCTION MASK CODES 0-15 •
140033
46.
.WORD
;CONTROL FUNCTION MASK CODES 0-15.
30

1. Appendix C lists all macros
control block offsets.

that

6-3

exist

RSX-llM

generate

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
47
.WORD
140000
;NO-P'ED FUNCTION MASK CODES 0-15.
.WORD
;ACP FUNCTION MASK CODES 0-15.
48
0
49
.WORD
;LEGAL FUNCTION MASK CODES 16.-31.
5
50
.WORD
;CONTROL FUNCTION MASK CODES 16.-31.
0
51
.WORD
;NO-OP'ED FUNCTION MASK CODES 16.-31.
1
52
;ACP FUNCTION MASK CODES 16.-31.
.WORD
4
53
PAPER TAPE PUNCH UNIT CONTROL BLOCK
54
55 ;
56 .PPO::
57 PPST=.
PP DCB
;BACK POINTER TO DCB
.WORD
58
• -2
.WORD
;POINTER TO REDIRECT UNIT UCB
59
;CONTROL PROCESSING FLAG (PASS CONTROL
UC. ATT, 0
60
.BYTE
;
ON ATTACH/DETACH), UNIT STATUS
61
.BYTE
;PHYSICAL UNIT NUMBER, UNIT STATUS EXTENSION
62
0,0
.WORD
DV. REC
;FIRST DEVICE CHARACTERISTICS WORD
63
;
(RECORD-ORIENTED DEVICE)
64
65
.WORD
;SECOND DEVICE CHARACTERISTICS WORD
0
66
;
(FOR INTERNAL USE BY DRIVER)
.WORD
;THIRD DEVICE CHARACTERISTICS WORD
67
0
;
(FOR INTERNAL USE BY DRIVER)
68
;FOURTH DEVICE CHARACTERISTICS WORD
• WORD
64 •
69
;
(DEFAULT BUFFER SIZE IN BYTES)
70
PPS CB
; PO INTER TO SCB
.WORD
71
;TCB ADDRESS OF ATTACHED TASK
.WORD
72
0
;RELOCATION BIAS OF BUFFER OF CURRENT
.BLKW
1
73
74
;
I/O REQUEST
;ADDRESS OF BUFFER OF CURRENT I/O REQUEST
.BLKW
1
75
;BYTE COUNT OF CURRENT I/O REQUEST
76
.BLKW
1
77 PPND=.
78 ;
79 ; PAPER TAPE PUNCH INTERRUPT VECTOR
80
• ASECT
81
82 • =74
;ADDRESS OF INTERRUPT ROUTINE
.WORD
$PPINT
83
;INTERRUPT AT PRIORITY 7 (CONTROLLER=O)
84
.WORD
PR7 ! 0
• PSECT
85
86
PAPER TAPE PUNCH STATUS CONTROL BLOCK
87
88 ;
;CONTROLLER I/O QUEUE LISTHEAD
.WORD
89 PPSCB:
0
(POINTER TO FIRST ENTRY)
90
;
(POINTER TO LAST ENTRY)
.WORD
91
• -2
.BYTE
;DEVICE PRI, INTERRUPT VECTOR ADDRESS/4
92
PR4, 74/4
;CURRENT AND INITIAL TIMEOUT COUNTS
.BYTE
0,4
93
;CONTROLLER INDEX AND STATUS
94
.BYTE
0,0
;
(O=IDLE, l=BUSY)
95
;ADDRESS OF CONTROL STATUS REGISTER
.WORD
1 77554
96
;ADDRESS OF CURRENT I/O PACKET
.BLKW
97
1
.BLKW
;FORK BLOCK ALLOCATION
4
98
99
• END
100

6.2.2

Driver Code

The code shown below for the punch capability of the PCll is typical
for
a conventional driver.
In fact, many of the descriptive comments
can be used as a template and easily tailored to a driver for another
device.

6-4

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES

The structure of the driver follows the standard RSX-llM
separated into processing code for the following:
•

Initiator

•

Power failure

•

Interrupt

•

Time-out

•

Cancel I/O

form,

being

The driver itself services only Write Logical, Attach, and Detach I/O
functions.
Attach and ve~ach resuit in the punching of 170. nulls
each for header and trailer.
Power failure and cancel I/O are handled by means of device
as is the device-not-ready condition.

time-out,

The driver uses the following Executive services:
$INTXT
$GT PKT
$GTBYT
$DVMSG
$INTSV is used indirectly;
Section 4. 3.

it is called by INTSV$

(line

Comments beginning with ';;;' indicate that the instruction
executed at a priority level greater than or equal to 4.

165).

See

being

The code contained in lines 139-1~1 is used to inhibit the punching of
a trailer on ATT/DET if the task is being aborted. This is especially
desirable when the device is not ready (for example, out of paper
tape)
and the system has generated the DET function for the aborting
process.
1.

2.
3.

• TITLE
• !DENT

PPDRV
/02/

4.
5.
6.

1976,

DIGITAL

EQUIPMENT

CORP.,

MAYNARD,

MASS.

7.
8.
9.
10.

THIS SOF'IWARE IS FURNISHED TO PURCHASER UNDER A LICENSE FOR USE
ON A SINGLE COMPUTER SYSTEM AND CAN BE COPIED (WITH INCLUSION
OF DEC'S COPYRIGHT NOTICE) ONLY FOR USE IN SUCH SYSTEM, EXCEPT
AS MAY OTHERWISE BE PROVIDED IN WRITING BY DEC.

11.

12.
13.

14.
15.
16.
17.

THE INFORMATION IN THIS DOCUMENT IS SUBJECT TO CHANGE WITHOUT
NOTICE AND SHOULD NOT BE CONSTRUED AS A COMMITMENT BY DIGITAL
EQUIPMENT CORPORATION.
DEC ASSUMES NO RESPONSIBILITY FOR
OF ITS SOF'IWARE ON EQUIPMENT WHICH

18.

19.

VERSION 02

20.
21.

T. J. PASCUSNIK 25-NOV-74

22.
2 3.

MODIFIED BY:

24.

6-5

THE USE OR RELIABILITY
IS NOT SUPPLIED BY DEC.

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
25.
2 6.
27.

C. A. ANDERS 15-MAR-76
CAOOl -- ADDITION OF LOADABLE DRIVER SUPPORT.

28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
4 7.
48.
49.

T. J. PASCUSNIK 4-APR-76

51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.

WAIT=l 00000
ABORT=40000
TRAIL=200

TP031 -- EXECUTIVE DATA STRUCTURE CHANGES.
PCll PAPER TAPE PUNCH DRIVER
MACRO LIBRARY CALLS
.MCALL
ABODF$
HWDDF$
PKTDF$
TCBDF$

ABODF$,HWDDF$,PKTDF$,TCBDF$
;DEFINE TASK ABORT CODES
;DEFINE HARDWARE REGISTER SYMBOLS
;DEFINE I/O PACKET OFFSETS
;DEFINE TASK CONTROL BLOCK OFFSETS

EQUATED SYMBOLS
PAPER TAPE PUNCH STATUS WORD BIT DEFINITIONS

so.

(U.CW2)

;WAITING FOR DEVICE TO COME ON-LINE (l=YES)
;ABORT CURRENT I/O REQUEST (l=YES)
;CURRENTLY PUNCHING TRAILER (l=YES)

LOCAL DATA
CONTROLLER IMPURE DATA TABLES (INDEXED BY CONTROLLER NUMBER)
CNTBL:

TEMP:

• BLKW

P$$P 11

.IF GT

P$$P 11-1

• BLKW

• ENDC
68.
69.
70.
71.
DRIVER DISPATCH TABLE
72.
73.
74.
PPINI
75. $PPTBL::
.WORD
PPCAN
.WORD
76.
PPOUT
.WORD
77.
PPPWF
.WORD
78.

;ADDRESS OF UNIT CONTROL BLOCK

;TEMPORARY STORAGE FOR CONTROLLER NUMBER
; CAOOJ
; CAOOl

;DEVICE INITIATOR ENTRY POINT
;CANCEL I/O OPERATION ENTRY POINT
;DEVICE TIMEOUT ENTRY POINT
;POWERFAIL ENTRY POINT

79.
80.
81.
82.

83.
84.
85.
86.

87.
88.

;+
**-PPINI-PCll PAPER TAPE PUNCH CONTROLLER INITIATOR
THIS ROUTINE IS ENTERED FRCM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST
IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECUTION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT
IS MADE TO DEQUEUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPERATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED.

6-6

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
89.
INPUTS:
90.
91.
R5=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED.
92.
93.
OUTPUTS:
94.
95.
IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT96.
ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPER97.
ATION IS INITIATED.
98.
99. ;100.
• ENABL LSB
101.
CALL
;GET AN I/O PACKET TO PROCESS
PPINI:
$GT PKT
102.
BCS
;IF CS CONTROLLER BUSY OR NO REQUEST
PPPWF
103.
104.
105.
THE FOLLOWING ARGUMENTS ARE RETURNED BY $GTPKT:
106.
107.
Rl=ADDRESS OF THE I/O REQUEST PACKET.
108.
R2=PHYSICAL UNIT NUMBER OF THE REQUEST UCB.
109.
R3=CONTROLLER INDEX.
llO.
R4=ADDRESS OF THE STATUS CONTROL BLOCK.
111.
RS=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED.
112.
ll3.
PAPER TAPE PUNCH I/O REQUEST PACKET FORMAT:
114.
115.
WD. 00 -- I/O QUEUE THREAD WORD.
116.
WD. 01 -- REQUEST PRIORITY, EVENT FLAG NUMBER.
ll 7.
WD. 02 -- ADDRESS OF THE TCB OF THE REQUESTER TASK.
ll8.
119.
WD. 03 -- POINTER TO SECOND LUN WORD IN REQUESTER TASK HEADER.
120.
WD. 04 -- CONTENTS OF THE FIRST LUN WORD IN REQUESTER TASK HEADER (UCB).
121.
WD. 05
I/O FUNCTION CODE (IO.WLB, IO.ATT OR IO.DET).
122.
WD. 06 -- VIRTUAL ADDRESS OF I/0 STATUS BLOCK.
123.
WD. 07 -- RELOCATION BIAS OF I/O STATUS BLOCK.
124.
WD. 10 -- I/O STATUS BLOCK ADDRESS {REAL OR DISPLACEMENT + 140000).
125.
WD. 11
VIRTUAL ADDRESS OF AST SERVICE ROUTINE.
126.
WD. 12 -- RELOCATION BIAS OF I/O BUFFER.
127.
WD. 13 -- BUFFER ADDRESS OF I/O TRANSFER.
128.
WD. 14 -- NUMBER OF BYTES TO BE TRANSFERED.
NOT USED.
129.
WD. 15
NOT USED.
WD. 16
130.
131.
NOT USED.
WD. 17
NOT USED.
132.
WD. 20
133.
134.
MOV
R5,CNTBL(R3)
;SAVE UCB POINTER FOR INTERRUPT ROUTINE
135.
CLR
136.
U.CW2(R5)
;CLEAR ALL SWITCHES
CMPB
137.
I.FCN+l{Rl),#IO.WLB/256. ;WRITE LOGICAL BLOCK FUNCTION?
BEQ
10$
;IF EQ YES
138.
MOV
139.
I.TCB(Rl),RO
;GET REQUESTOR TCB ADDRESS
14 o.
BIT
#T2.ABO,T.ST2(RO) ;TASK BEING ABORTED?
; TP031
BNE
141.
65$
;IF NE YES - DON'T PUNCH TRAILER
BIS
142.
#TRAIL,U.CW2(R5) ;OTHERWISE FUNCTION IS ATTACH OR DETACH
14 3.
;
SET FLAG TO PUNCH TRAILER
MOV
14 4.
#170.,U.CNT(RS) ;SET COUNT FOR 170 NULLS
BIS
145. 10$:
#WAIT,U.CW2(R5) ;ASSUME WAIT FOR DEVICE OFF LINE
146.
TST
@S.CSR(R4)
;DEVICE OFF LINE?
BMI
147.
80$
;IF MI YES
#WAIT,U.CW2(R5) ;DEVICE ON LINE, CLEAR WAIT CONDITION
148. 20$:
BIC
S.ITM(R4),S.CTM(R4) ;SET TIMEOUT COUNT
149.
MOVB
#100,@S.CSR(R4) ;ENABLE INTERRUPTS
MOV
150.
151.

6-7

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.

POWERFAIL IS HANDLED VIA THE DEVICE TIMEOUT FACILITY AND THEREFORE CAUSES
NO IMMEDIATE ACTION ON THE DEVICE. THIS IS DONE TO AVOID A RACE CONDITION
THAT COULD EXIST IN RESTARTING THE I/O OPERATION

PPPWF:
;+

; **-$PPINT-PC11 PAPER TAPE PUNCH CONTROLLER INTERUPTS
;$PPINT::
INTSV$
MOV
MOVB
MOV
MOV
BMI

171.
172.

173.
1 74.
l 7S.
176.
177.
178.
179.
180.
181.

RETURN

SUB

30$:
40$:
SO$:
60$:

182.

183.
184.

18S.

BCS
TSTB
BPL
CLRB
BR
CALL
MOVB
.;JMP
INC
CLR
CALL
MOV
MOV
MOV

186.

SUB

187.

MOV
TST
BPL
MOV
CALL
BR

188.
189.
190. 6S$:
191. 70$:
192.
193.
194.

19S.
196.
197.

;;;REF LABEL
PP,PR4,P$$Pll
;;;GENERATE INTERRUPT SAVE CODE ; CAOOl
U.SCB(RS),R4
;;;GET ADDRESS OF STATUS CONTROL BLOCK
S.ITM(R4),S.CTM(R4) ;;;RESET TIMEOUT COUNT
S.CSR(R4),R4
;;;POINT R4 TO CONTROL STATUS REGISTER
(R4)+,U.CW3(RS) ; ; ;SAVE STATUS
;;;IF MI, ERROR
60$
;;;DECREMENT CHARACTER COUNT
t1, U. CNT {RS)
SO$
;;;IF CS, THEN DONE
; ; ;CURRENTLY PUNCHING TRAILER?
u.cw2 (RS)
30$
; ; ; IF PL NO
{R4)
;;;LOAD NULL INTO OUTPUT REGISTER
40$
;;;BRANCH TO LOAD IT
$GTBYT
;;;GET NEXT BYTE FROM USER BUFFER
{SP)+, (R4)
;;;LOAD BYTE INTO OUTPUT REGISTER
$INTXT
;;;EXIT FROM INTERRUPT
U.CNT {RS)
;;;RESET BYTE COUNT
-(R4)
;;;DISABLE PUNCH INTERRUPTS
$FORK
;;;CREATE SYSTEM PROCESS
U • SC B { R 5) , R 4
; POINT R4 TO SCB
S.PKT(R4),Rl
;POINT Rl TO I/O PACKET
I. PRM+4 (Rl), Rl ;
AND PICK UP CHARACTER COUNT
;CALCULATE CHARACTERS TRANSFERRED
U.CNT{RS),Rl
US. SUC&3 77, RO ;ASSUME SUCCESSFUL TRANSFER
U.CW3 (RS)
; DEVICE ERROR?
70$
; IF PL NO
#IE. VER&377, RO ;UNRECOVERABLE HARIMARE ERROR CODE
$!ODON
;INITIATE I/O COMPLETION
PPINI
;BRANCH BACK FOR NEXT REQUEST

DEVICE TIMEOUT RESULTS IN A NOT READY MESSAGE BEING PUT OUT 4 TIMES A
MINUTE. TIMEOUTS ARE CAUSED BY POWERFAILURE AND PUNCH FAULT CONDITIONS.

198.
199. PPOUT:
200.
201. 80$:
202.
203.

204.
20S.
206.

207.
208.
209.

210.
211.
212.
213.
214.

215.

CLRB
CLRB
MOV
MOV
BPL
MOV
ASL
BMI
TST
BPL
MOV
MOVB
DECB
BNE
MOVB
CALLR
• DSABL

;;;DISABLE PUNCH INTERRUPT
;;;ALLOW INTERRUPTS
;ASSUME DEVICE NOT READY ERROR
;ARE WE WAITING FOR DEVICE READY?
;IF PL NO, TERMINATE I/O REQUEST
70$
#IE. AB0&3 77, RO ;ASSUME REQUEST IS TO BE ABORTED
Rl
;ABORT REQUEST?
70$
;IF MI YES
@S.CSR(R4)
; PUNCH READY?
; IF PL YES
20$
;SET FOR NOT READY MESSAGE
#:T.NDNR,RO
;SET TIMEOUT FOR 1 SECOND
U,S.C™(R4)
S.STS{R4)
;TIME TO OUTPUT' MESSAGE?
PPPWF
;IF NE NO
U 5., S. STS (R4) ;SET TO OUTPUT NEXT MESSAGE IN 15. SECONDS
;OUTPUT MESSAGE AND RETURN
$DVMSG
LSB
@S.CSR(R4)
PS
#IE. DNR&3 77, RO
U.CW2(R5) ,Rl

6-8

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
216.
21 7.
CANCEL I/O OPERATION-FORCE I/O TO COMPLETE IF DEVICE IS NOT READY
218.
219.
220.
221. PPCAN:
CMP
Rl,I.TCB(RO)
;;;REQUEST FOR CURRENT TASK?
BNE
222.
10$
;;;IF NE NO
BIS
#ABORT,U.CW2(R5) ;;;SET FOR ABORT IF DEVICE NOT READY
223.
RETURN
224. 10$:
i ; ;
225.
• END
226.

u • ..)

HANDLING SPECIAL USER BUFFERS

Some drivers need to handle user buffers in addition to the buffer
that the Executive address-checks and relocates in a normal transfer
request.
Address checking and relocation operations must take place
in the context of the task issuing the I/O request, because the
mapping registers are set for the issuing task.
However,
in the
normal driver interface, the task context after the call to $GTPKT is
not, in general, that of the issuing task.
Thus, drivers that need to handle special buffers must be able to
reference the I/O packet before it is queued, while the context of the
issuing task is still intact.
The following coding excerpts from a standard RSX-llM driver
AFCll driver)
illustrate the handling of a special user buffer.
key points are:

(the
The

•

The UC.QUE bit has been set in the control byte (U.CTL) of the
UCB for each device/unit.
(This is not shown in the coding
excerpts below.)

•

The routine that is referenced as the initiator entry point in
the driver dispatch table performs the following actions:

•

Picks up the user
address-checks it.

virtual

address

and

conditionally

Relocates the virtual address, storing
i n to the pa c k et •

the

Inserts the packet into the I/O queue and falls
to the entry point AFINI, which calls $GTPKT.

result

The driver propagates its own execution by branching
AFINI to call $GTPKT.

through
back

DRIVER DISPATCH TABLE
$AFTB L: : • WORD
.WORD
.WORD
.WORD

AFC HK
AF CAN
AFOUT
AFPWF

;DEVICE INITIATOR ENTRY POINT
;CANCEL I/O OPERATION ENTRY POINT
;DEVICE TIMEOUT ENTRY POINT
;POWERFAIL ENTRY POINT

6-9

back

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
;+

**-AFCHK-AFCll ANALOG TO DIGITAL CONVERTER CONTROLLER PARAMETER CHECKING
THIS ROUTINE IS ENTERED FRCM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST
IS RECEIVED FOR THE AFCll ANALOG TO DIGITAL CONVERTOR. AFCll I/O REQUESTS
CONTAIN DEVICE DEPENDENT INFORMATION THAT MUST BE CHECKED IN THE CONTEXT
OF THE ISSUING TASK. THEREFORE THE I/O REQUEST IS NOT QUEUED BEFORE CALLING
THE DRIVER.
;

INPUTS:
Rl=ADDRESS OF THE I/O REQUEST PACKET.
R4=ADDRESS OF THE STATUS CONTROL BLOCK.
RS=ADDRESS OF THE UCB OF THE CONTROLER TO BE INITIATED.
OUTPUTS:
THE CONTROL BUFFER IS ADDRESS CHECKED TO DETERMINE WHETHER IT LIES
WITHIN THE ISSUING TASK'S ADDRESS SPACE. IF THE ADDRESS CHECK
SUCCEEDS, THEN THE CONTROL BUFFER ADDRESS IS RELOCATED AND STORED
IN THE I/O PACKET, THE I/O PACKET IS INSERTED IN THE CONTROLLER
QUEUE, AND THE DEVICE INITIATOR IS ENTERED TO START THE CONTROLLER.
ELSE AN ILLEGAL BUFFER STATUS IS RETURNED AS THE FINAL I/O STATUS
OF THE REQUEST.
;-

AFCHK: MOV
MOV

Rl,R3
I.PRM+6(R3),RO

;COPY ADDRESS OF I/O PACKET
;GET VIRTUAL ADDRESS OF CONTROL BUFFER

• IF DF

A$$CHK! M$$MGE

MOV
CALL
BCC
MOV
CALLR

I. PRM+4 (R3), Rl
$ACHCK
10.$
UE. SPC&3 77, RO
$IOFIN

;SET LENGTH OF BUFFER TO CHECK
;ADDRESS CHECK CONTROL BUFFER
;IF CC ADDRESS OKAY
;SET ILLEGAL BUFFER STATUS
;FINISH I/O OPERATION

$RELOC
R1, I. PRM +6 (R 3)
R2 , I • PRM +1 0 (R3 )
R3, Rl
R4,RO
$QIN SP

;RELOCATE CONTROL BUFFER ADDRESS
;SET RELOCATION BIAS OF CONTROL BUFFER
;SET ADDRESS OF CONTROL BUFFER
;SET ADDRESS OF I/O PACKET
;SET ADDRESS OF I/O-QUEUE LISTHEAD
;INSERT I/O PACKET IN REQUEST QUEUE

• ENDC
10$:

CALL
MOV
MOV
MOV
MOV
CALL

6-10

INCLUDING A USER-WRITTEN DRIVER--TWO EXAMPLES
;+

**-AFINI-AFCll ANALOG TO DIGITAL CONVERTOR CONTROLLER INITIATOR
THIS R0t1l'INE IS ENTERED FRCM THE QUEUE I/O DIRECTIVE WHEN AN I/O REQUEST
IS QUEUED AND AT THE END OF A PREVIOUS I/O OPERATION TO PROPAGATE THE EXECUTION OF THE DRIVER. IF THE SPECIFIED CONTROLLER IS NOT BUSY, THEN AN ATTEMPT
IS MADE TO DEQUE THE NEXT I/O REQUEST. ELSE A RETURN TO THE CALLER IS
EXECUTED. IF THE DEQUEUE ATTEMPT IS SUCCESSFUL, THEN THE NEXT I/O OPERATION IS INITIATED. A RETURN TO THE CALLER IS THEN EXECUTED.
INPUTS:
RS=ADDRESS OF THE UCB OF THE CONTROLLER TO BE INITIATED.
OUTPUTS:
IF THE SPECIFIED CONTROLLER IS NOT BUSY AND AN I/O REQUEST IS WAIT
ING TO BE PROCESSED, THEN THE REQUEST IS DEQUEUED AND THE I/O OPERATION IS INITIATED.
;-

.ENABL
AFINI: CALL
BCS

CALL
BR

LSB
$GT PKT
AFCAN

$!ODON
AFINI

;GET AN I/O PACKET TO PROCESS
;IF CS CONTROLLER BUSY OR NO REQUEST
;I/O CANCEL (AFCAN) IS A NO-OP FOR AFCll

;FINISH I/O OPERATION
;GO AGAIN

6-11

APPENDIX A
DEVELOPMENT OF THE ADDRESS DOUBLEWORD

A.l

INTRODUCTION

You can generate an RSX-llM system as a mapped or an unmapped system.
Mapped systems can accommodate configurations whose maximum physical
memory is 4096K bytes.
Individual tasks, however, are limited to 64K
bytes.
The addressing in a mapped system uses virtual addresses and
memory mapping hardware.
I/O transfers, however, use
physical
addresses 18 bits in length.
Since the PDP-11 word size is 16 bits,
some scheme is necessary to represent an address internally until
it
is actually used in an I/O operation. The choice was made to encode
two words as the internal representation of a physical address, and to
transform virtual addresses for
I/O operations into the internal
doubleword format.

A.2

CREATING THE ADDRESS DOUBLEWORD

For unmapped systems, the doubleword
is simply
followed by a word containing the real address.

word

zeros

On receipt of a QIO directive for mapped systems, the buffer address
in the DPB, which contains a task virtual address, is converted to
address doubleword format.
The virtual address in the DPB is structured as follows:
Bits 0-5

Displacement in terms of 32-word blocks

Bits 6-12.

Block number

Bits 13.-15.

Page Address Register (PAR) number

A-1

DEVELOPMENT OF THE ADDRESS DOUBLEWORD
The internal RSX-llM translation restructures
into an address doubleword as follows:

this

virtual

address

The relocation base contained in the PAR specified by the PAR
number in the virtual address in the DPB is added to the
block number in the virtual address. The result becomes the
first word of the address doubleword. It represents the nth
32-word block in a memory viewed as a collection of 32-word
blocks.
Note that at the time the address doubleword is
computed, the user issuing the QIO directive is mapped into
the processor's memory management registers.

The
second
word
is
formed
by
placing
the
displacement-in-block (bits 0-5 of virtual address) into bits
0-5. The block number field was accommodated in the first
word and bits 6-12. are cleared. Finally, a 6 is placed in
bits 13.-15. to enable use of PAR #6, which the Executive
uses to service I/O for program transfer devices.
For non-processor request
(NPR)
devices,
the
driver
requirements for manipulating the address doubleword are
direct and are discussed with the description of U.BUF in
Section 4.1.4.1.

A-2

APPENDIX B
DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY

You must build special features into drivers for nonextended memory
NPR devices attached to a
PDP-11 processor with extended-memory
support (22-bit addressing).
Nonextended memory N~ devices on the PDP-11 processor must perform
I/O transfers by means of UNIBUS Mapping Registers
(UMRs), as
described in the PDP-11 Processor Handbook.
One UMR is required for
each 4K words involved in the transfer--as specified by the contents
of U.CNT in the UCB. When multiple UMRs are required for a transfer,
they must be contiguous.
A driver can be assigned UMRs through one of three procedures.
procedures involve the following:
1.

Dynamically allocating UMRs for
transfer

the

duration

Dynamically allocating UMRs for longer periods of time

Statically allocating UMRs during system generation

These

the

data

NOTE
In large systems, using the second and
third procedures above to hold UMRs for
longer periods than necessary can result
in the blocking of other drivers and a
reduction in system throughput.

B.l

CALLING $STMAP AND $MPUBM OR $STMP1 AND $MPUB1

To obtain UMRs through use of the $STMAP
$MPUB1 routines, a driver must:

and

$MPUBM

$STMP1

and

If it uses $STMAP and $MPUBM or $STMP1 and $MPUB1,
allocate
six additional words for a mapping register assignment block
at the end of the device's SCB (at S.MPR).
If it uses $STMP1
and $MPUB1, also provide a 10-word block.

Call the routine $STMAP or $STMP1
(set
address) after getting the I/O packet.

Call the routine $MPUBM or $MPUB1
before initiating a transfer.

UNIBUS

B-1

(map

UNIBUS
to

mapping
memory)

DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY
These requirements are detailed in the following three subsections.
Note that these routines are
performing a data transfer.

B.1.1

only

required

when

the

driver

Allocating a Mapping Register Assignment Block

The status control block (SCB) of an NPR device requires an additional
six words.
This 6-word mapping register assignment block is located
at S.MPR, at the end of the SCB.
It does not have to be initialized.
Any initial contents are simply overwritten.
The following example shows the allocation of a mapping
register
assignment block.
The code is conditional on the result of an AND
operation on the two symbols M$$EXT and M$$MGE (representing extended
memory support and memory management unit support, respectively).
.IF DF
.BLKW

M$$EXT&M$$MGE
6
; UMR WORK AREA

• ENDC
If the driver does not support parallel NPR operations requiring
UMR
mapping,
it calls $STMAP and $MPUBM.
If the driver supports parallel
NPR operations requiring UMR mapping, it must call $STMP1 and $MPUB1.
In the latter situation, the six additional words starting at S.MPR in
the SCB are not used but must still be present.
In addition, the
driver must provide a 10-word mapping register assignment block for
each data transfer to be mapped, as specified in the description of
$STMP1 in Chapter 5.

B.1.2

Calling $STMAP or $STMP1

In the coding at the initiator entry point, after the call to $GTPKT,
the NPR device driver must call the routine $STMAP or $STMP1.
These
routines dynamically allocate required
UMRs.
If
UMRs are
not
available immediately, the driver is blocked. Such blocking, if it
occurs, is completely transparent to the driver.
The driver resumes
processing at fork level when the UMRs have been allocated. The
register returns are absolutely identical whether or not blocking has
occurred.
$STMAP or $STMP1 stores into U.BUF and U.BUF+2 (in the UCB)
a UNIBUS
address that causes the appropriate UMR to be selected for mapping the
transfer.
The call to $STMAP or $STMP1 must be conditional on M$$EXT
and M$$MGE.
Because $STMAP and $STMP1 push the address of routine $DQUMR+2 onto
the stack before returning to the caller, the driver should not use
the stack for temporary data storage when it calls $STMAP or $STMP1.

B-2

DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY
B.1.3

Calling $MPUBM or $MPUB1

Before executing the transfer, the driver must call $MPUBM or $MPUB1.
These routines get the bufferis 22-bit physical address, and load the
UNIBUS mapping registers so that transfers are mapped directly to the
task's space.
The call to $MPUBM or $MPUB1 must be conditional on
M$$EXT and M$$MGE.
If the driver calls $STMAP and $MPUBM, the UMRs allocated to
it are
deallocated during the call to $!ODON or $IOALT.
If the driver calls
$STMP1 and $MPUB1, it must call $DEUMR to deallocate any allocated
UMRs before calling $!ODON or $IOALT.

B.2

CALLING $ASUMR AND $DEUMR

Some drivers may not require UMRs to be allocated all of the time, and
yet require UMRs for periods of time longer than the normal time frame
between $GTPKT and $!ODON (or $IOALT).
In such cases, there is a
second procedure for allocating UMRs.
By using the Executive routines $ASUMR and $DEUMR, a driver can
dynamically allocate, retain over a desired time frame, and deallocate
UMRs. Refer to Section 5.3 for a description of the $ASUMR and $DEUMR
routines.
Similar to the $STMAP/$MPUBM procedure, using $ASUMR and $DEUMR also
requires the allocation of a 6-word mapping register assignment block.
In this instance, however, the block must not be located at offset
S.MPR in the SCB.
$!ODON or $IOALT, when called, will attempt to
deallocate the UMRs of a block found at location S.MPR.
To avoid
this, the mapping register assignment block could, for convenience, be
located at S.MPR+2. Alternatively, it could be dynamically allocated
from the pool~
Figure B-1 details the format of the 6-word block.

M.LNK

Link Word

M.UMRA

Address of first assigned UMR

M.UMRN

Number of assigned UM Rs * 4

M.UMVL

Low 16 bits mapped by first assigned UMR

M.UMVH
M.BFVH
M.BFVL

High 6 bits of
physical buffer address

High 2 bits mapped by
UMR (in bits 4 and 5)

Low 16 bits of physical buffer address
ZK-226-81

Figure B-1

Mapping Register Assignment Block

B-3

DRIVERS FOR NPR DEVICES USING EXTENDED MEMORY

B.3

STATICALLY ALLOCATING UMRS DURING SYSTEM GENERATION

You can statically assign UMRs during system generation.
For systems
with extended memory support and memory management unit support, the
system generation procedure defines the symbol N$$UMR equal to a fixed
number of UMRs, multiplied by 4, that are statically assigned to the
system. Before assembling the Executive, you can cause the static
allocation of an additional number of UMRs by editing file RSXMC.MAC.
The value of the symbol N$$'UMR can then be increased to represent the
additional number of desired UMRs multiplied by 4.
RSXMC.MAC further defines the following three symbols, which
the first UMR statically allocated during system generation:

describe

U$$MRN

is the I/O page address of the first
available for allocation to the user.

UMR

U$$MLO

represents the low-order 16 bits of the
address mapped by this UMR.

18-bit

UNIBUS

U$$MHI

represents the high-order two bits of the 18-bit UNIBUS
address.
These two bits are in bit positions 4 and 5.

These three symbols are not used by the
available for the user's information.

B-4

system

itself.

They

are

APPENDIX C
SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

This appendix describes the system data

structures

listed

Table

C-1.

The data structures are defined by macros in the Executive macro
library.
To reference any of the data structure offsets from your
code, include the macro name in an .MCALL directive and invoke the
macro. For example:
.MCALL
DCBDF$

DCBDF$
;Define DCB offsets
NOTE
All physical offsets and bit definitions
are subject to change in future releases
of the operating system.
Code that
accesses system data structures should
always use the symbolic offsets rather
than the physical offsets.

The first two arguments, <:>and <=>, make all definitions global. If
they are left blank, the definitions will be local. The SYSDEF
argument causes the variable part of a data structure to be defined.
All of these
macros
are
in
the
Executive
LB: [l,l]EXEMC.MLB.
All except ITBDF$ and MTADF$
Executive definition library LB: [l,l]EXELIB.OLB.

C-1

macro
library
are also in the

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

Table C-1
Summary of System Data Structure Macros
Macro

Data Structures

Arguments

ABODF$

<:>,<=>

Task
abort
and
termination
notification message codes

CLKDF$

<:>,<=>

Clock queue control block

DCBDF$

<:>,<=>

Device Control Block

EPKDF$

<:>,<=>

Error message block

FllDF$

<:>,<=>,SYSDEF

Files-11 data structures
(volume
control block, mount list entry,
file control block, file window
block, locked block list node)

HDRDF$

<:>,<=>

Task header and window block

HWDDF$

<:>,<=>

Hardware register addresses
feature mask definitions

ITBDF$

<:>,<=>,SYSDEF

Interrupt transfer block

LCBDF$

<:>,<=>

Logical assignment control block

MTADF$

<:>,<=>

ANSI
mag tape
data
structures
(volume set control block)

PCBDF$

<:>,<=>,SYSDEF

Partition
control
block
attachment descriptor

PKTDF$

<:>,<=>

I/0 packet, AST control block,
offspring
control block, group
global event flag control block,
and CLI parser block

SCBDF$

<:>,<=>,SYSDEF

Task Control Block

UCBDF$

<:>,<=>,TTDEF,SYSDEF

Unit Control Block

C-2

and

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

ABODF$
ABODF$
TASK ABORT CODES
NOTE: S.COAD-S.CFLT ARE ALSO SST VECTOR OFFSETS
;

S.CACT=-4.
S. CEXT=-2.
S. COAD=O.
S.CSGF=2.
S. CBPT=4.
S .CIOT=6 ..
S.CILI=8.
S. CEMT=l 0.
S.CTRP=l2.
S. CFLT=l4.
S. CSST=l 6.
S.CAST=l8.
S.CAB0=20.
S. CLRF=22.
S.CCRF=24.
S. IOMG=26.
S. PRTY=2 8.
S. CPMD=30.
S.CINS=32.

;TASK STILL ACTIVE
;TASK EXITTED NORMALLY
;ODD ADDRESS AND TRAPS TO 4
;SEGMENT FAULT

;BREAK POINT OR TRACE TRAP
;IOT INSTRUCTION
;ILLEGAL OR RESERVED INSTRUCTION
;NON RSX EMT INSTRUCTION
;TRAP INSTRUCTION
;11/40 FLOATING POINT EXCEPTION
;SST ABORT-BAD STACK
;AST ABORT-BAD STACK
;ABORT VIA DIRECTIVE
;TASK LOAD REQUEST FAILURE
;TASK CHECKPOINT READ FAILURE
;TASK EXIT WITH OUTSTANDING I/O
;TASK MEMORY PARITY ERROR
;TASK ABORTED WITH PMD REQUEST
;TASK INSTALLED IN TWO SYSTEMS

TASK TERMINATION NOTIFICATION MESSAGE CODES
;

T.NDNR=O
T.NDSE=2
T. NCWF=4
T.NCRE=6
T. NDM0=8.
T.NUER=lO.
T.NLDN=l2.
T.NLUP=l4.
T. NCFI=l 6.
T. NUDE=l8.
T.NMPE=20.
T.NKLF=22.
T. NDEB=24.
T. NRCT=26.
T. NWBL=2 8.

;DEVICE NOT READY
;DEVICE SELECT ERROR
;CHECKPOINT WRITE FAILURE
;CARD READER HARDWARE ERROR
;DISMOUNT COMPLETE
;UNRECOVERABLE ERROR
;LINK DOWN (NETWORKS)
;LINK UP (NETWORKS)
;CHECKPOINT FILE INACTIVE
;UNRECOVERABLE DEVICE ERROR
;MEMORY PARITY ERROR
;UCODE LOADER NOT INSTALLED
;TASK HAS NO DEBUGGING AID
;REPLACEMENT CONTROL TASK NOT INSTALLED
;WRITE BACK CACHING DATA LOST
;UNIT WRITE LOCKED

C-3

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

CLKDF$
CLKDF$
CLOCK QUEUE CONTROL BLOCK OFFSET DEFINITIONS
CLOCK QUEUE CONTROL BLOCK
THERE ARE SIX TYPES OF CLOCK QUEUE CONTROL BLOCKS. EACH CONTROL
BLOCK HAS THE SAME FORMAT IN THE FIRST FIVE WORDS AND DIFFERS IN
THE REMAINING THREE.
THE FOLLOWING CONTROL BLOCK TYPES ARE DEFINED:
;

;MARK TIME REQUEST
;TASK REQUEST WITH PERIODIC RESCHEDULING
;SINGLE SHOT TASK REQUEST
;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (IDENT)
;SINGLE SHOT INTERNAL SYSTEM SUBROUTINE (TASK)
;CLEAR STOP BIT (CONDITIONALIZED ON SHUFFLING)

C .MRKT=O
C.SCHD=2
C. S~HT=4
C. SYST=6
C.SYTK=8.
C.CSTP=lO.

CLOCK QUEUE CONTROL BLOCK TYPE INDEPENDENT OFFSET DEFINITIONS
• ASECT
000000
000002
000003
000004
000006

• =O
C. LNK:
C. RQT:
C. EFN:
C. TCB:
C. TIM:

.BLKW
.BLKB
.BLKB
.BLKW
.BLKW

1
1
1
1
2

;CLOCK QUEUE THREAD WORD
;REQUEST TYPE
;EVENT FLAG NUMBER (MARK TIME ONLY)
;TCB ADDR OR SYSTEM SUBROUTINE IDENTIFICATION
;ABSOLUTE TIME WHEN REQUEST COMES DUE

CLOCK QUEUE CONTROL BLOCK-MARK TIME DEPENDENT OFFSET DEFINITIONS
;

000012
000014
000016

• =C. TIM+4
C • AST :
• BL KW
C. SRC:
• BLKW
C. DST:
• BLKW

1
1
1

;START OF DEPENDENT AREA
;AST ADDRESS
;FLAG MASK WORD FOR 'BIS' SOURCE
;ADDRESS OF 'BIS' DESTINATION

CLOCK QUEUE CONTROL BLOCK-PERIODIC RESCHEDULING DEPENDENT OFFSET
DEFINITIONS
;

000012
000016

• =C. TIM+4
C.RSI:
.BLKW
C.UIC:
.BLKW

2
1

;START OF DEPENDENT AREA
;RESCHEDULE INTERVAL IN CLOCK TICKS
;SCHEDULING UIC

CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT DEPENDENT OFFSET DEFINITIONS
;

000012
000016

• =C. TIM+4
.BLKW
.BLKW

2
1

;START OF DEPENDENT AREA
;TWO UNUSED WORDS
;SCHEDULING UIC

C-4

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

CLOCK QUEUE CONTROL BLOCK-SINGLE SHOT INTERNAL SUBROUTINE OFFSET
DEFINITIONS
THERE ARE TWO TYPE CODES FOR THIS TYPE OF REQUEST:
TYPE 6 = SINGLE SHOT INTERNAL SUBROUTINE WITH A 16 BIT VALUE
AS AN IDENTIFIER.
TYPE 8 = SINGLE SHOT INTERNAL SUBROUTINE WITH A TCB ADDRESS
AS AN IDENTIFIER.
i

000012
000014
000016

• =C. TIM+4
C.SUB:
.BLKW
C. ARS:
• BLKW
.BLKW

000020

C. LGTH= •

1
1
l

;START OF DEPENDENT AREA
;SUBROUTINE ADDRESS
;RELOCATION BASE (FOR LOADABLE DRIVERS)
;ONE UNUSED WORD
;LENGTH OF CLOCK QUEUE CONTROL BLOCK

• PSECT

C-5

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

DCBDF$
DCBDF$
DEVICE CONTROL BLOCK
THE DEVICE CONTROL BLOCK (DCB) DEFINES GENERIC INFORMATION ABOUT
A DEVICE TYPE AND THE LOWEST AND HIGHEST UNIT NUMBERS. THERE IS
AT LEAST ONE DCB FOR EACH DEVICE TYPE IN A SYSTEM. FOR EXAMPLE,
IF THERE ARE TELETYPES IN A SYSTEM, THEN THERE IS AT LEAST ONE
DCB WITH THE DEVICE NAME 'TT'. IF PART OF THE TELETYPES WERE
INTERFACED VIA DLll-A'S AND THE REST VIA A DHll, THEN THERE
WOULD BE TWO DCB'S. ONE FOR ALL DLll-A INTERFACED TELETYPES,
AND ONE FOR ALL DHll INTERFACED TELETYPES •
• ASECT
000000
000002
000004
000006
000007
000010
000012
000014
000016
000020
000022
000024
000026
000030
000032
000034

• =O
D. LNK:
D. UCB:
D.NAM:
D.UNIT:

.BLKW
.BLKW
.BLKW
.BLKB
.BLKB
D. UCBL: .BLKW
• BLKW
D. DSP:
D.MSK:
.BLKW
• BLKW
.BLKW
.BLKW
.BLKW
• BLKW
• BLKW
• BLKW
D. PCB:
.BLKW

1
1
1
1
1
1
1
1
1
1
1
1
1
1
1
1

; LINK TO NEXT DCB
;POINTER TO FIRST UNIT CONTROL BLOCK
;GENERIC DEVICE NAME
;LOWEST UNIT NUMBER COVERED BY THIS DCB
;HIGHEST UNIT NUMBER COVERED BY THIS DCB
;LENGTH OF EACH UNIT CONTROL BLOCK IN BYTES
;POINTER TO DRIVER DISPATCH TABLE
;LEGAL FUNCTION MASK . CODES 0-15.
;CONTROL FUNCTION MASK CODES 0-15 •
;NOP'ED FUNCTION MASK CODES 0-15.
;ACP FUNCTION MASK CODES 0-15.
;LEGAL FUNCTION MASK CODES 16.-31.
;CONTROL FUNCTION MASK CODES 16.-31 •
;NOP'ED FUNCTION MASK CODES 16.-31 •
;ACP FUNCTION MASK CODES 16.-31 •
;LOADABLE DRIVER PCB ADDRESS

• PSECT

DRIVER DISPATCH TABLE OFFSET DEFINITIONS
;

D. VDEB=l 77776
D. VINI=O
D. VCAN=2
D. VOUT=4
D. VPWF=6

;DEALLOCATE INTERNAL BUFFERS (FD TTDRV)
;DEVICE INITIATOR
;CANCEL CURRENT I/O FUNCTION
;DEVICE TIMEOUT
;POWERFAIL RECOVERY

C-6

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

EPKDF$
EPKDF$

ERROR MESSAGE BLOCK DEFINITIONS
• ASECT

HEADER SUBPACKET

+-----------------------------------------------+
I S UBPACKET LENGTH IN BYTES
I
+-----------------------------------------------+
I S UBPACKET FLAGS
I
+-----------------------+-----------------------+
I FORMAT IDENTIFICATION I OPERATING SYSTEM CODE I
+-----------------------+-----------------------+
I OPERATING SYSTEM IDENTIFICATION
I
I

I
I

+-----------------------+-----------------------+
I FLAGS
I CONTEXT CODE
I
+-----------------------+-----------------------+
I ENTRY SEQUENCE
I
+-----------------------------------------------+
I ERROR SEQUENCE
I
+-----------------------+-----------------------+
I ENTRY TYPE SUBCODE
I ENTRY TYPE CODE
I
+-----------------------+-----------------------+
I TIME STAMP
I

;

+-----------------------+-----------------------+
I RESERVED
I PROCESSOR TYPE
I
+-----------------------+-----------------------+
I PROCESSOR IDENTIFICATION (URM)
I
+-----------------------------------------------+

• =O

000000
000002
000004
000005
000006
000012
000013
000014
000016
000020
000020
000021
000022
000030
000031
000032

E $HLGH:
E $HSBF:
E$HSYS:
E$HIDN:
E $HSID:
E$HCTX:
E$HFLG:
E$HENS:
E$HERS:
E$HENC:
E $HTYC:
E$HTYS:
E$HTIM:
E$HPTY:

.BLKW
.BLKW
.BLKB
.BLKB
.BLKB
.BLKB
.BLKB
.BLKW
.BLKW

1
1
1
1
4
1
1
1
1

.BLKB
.BLKB
.BLKB
.BLKB
.BLKB

1
1
6
1
1

E$HURM:

.BLKW

000034

E $HLEN:

SUBPACKET LENGTH IN BYTES
SUBPACKET FLAGS
OPERATING SYSTEM CODE
FORMAT IDENTIFICATION
OPERATING SYSTEM IDENTIFICATION
CONTEXT CODE
FLAGS
ENTRY SEQUENCE NUMBER
ERROR SEQUENCE NUMBER
ENTRY CODE
ENTRY TYPE CODE
ENTRY TYPE SUBCODE
TIME STAMP
PROCESSOR TYPE
RESERVED
PROCESSOR IDENTIFICATION (URM)

• EVEN
LENGTH

C-7

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

SUBPACKET FLAGS FOR ESHSBF
SM.ERR
SM. HDR
SM.TSK
SM.DID
SM. DOP
SM.DAC
SM. DAT
SM.MBC
SM.CMD
SM. ZER

1
1
2

10
20
40
20000
40000
=100000

ERROR PACKET
HEADER SUBPACKET
TASK S UBPACKET
DEVICE IDENTIFICATION SUBPACKET
DEVICE OPERATION SUBPACKET
DEVICE ACTIVITY SUBPACKET
DATA SUBPACKET
22-BIT MASSBUS CONTROLLER PRESENT
ERROR LOG Ca-1.MAND PACKET
ZERO I/O COUNTS

CODES FOR FIELD E$HIDN
EH$FOR

1 ; CURRENT PACKET FORMAT

FLAGS FOR THE ERROR LOG FLAGS BYTE ($ERFLA) IN THE EXEC
ES. INI
ES. DAT
ES. LIM
ES.LOG

1
2
4
10

ERROR
ERROR
ERROR
ERROR

LOG INITIALIZED
LOG RECEIVING DATA PACKETS
LIMITING ENABLED
LOGGING ENABLED

TYPE AND SUBTYPE CODES FOR FIELDS E$HTYC AND E$HTYS
SYMBOLS WITH NAMES E$CXXX ARE TYPE CODES FOR FIELD E$HTYC,
SYMBOLS WITH NAMES E$SXXX ARE SUBTYPE CODES FOR FIELD E$HTYS.
E$CCMD
E $SSTA
E$SSWI
E$SAPP
E$SBAC
E$SSHO
E$SCHL

1
1
2
3
4
5
6

ERROR LOG CONTROL
ERROR LOG STATUS CHANGE
SWITCH LOGGING FILES
APPEND FILE
DECLARE BACKUP FILE
SHOW
CHANGE LIMITS

E$CERR
E$SDVH
E$SDVS
E$STMO
E$SUNS

2
1
2
3
4

DEVICE ERRORS
DEVICE HARD ERROR
DEVICE SOFT ERROR
DEVICE INTERRUPT TIMEOUT
DEVICE UNSOLICITED INTERRUPT

E$CDVI
E$SDVI

3
1

DEVICE INFORMATION
DEVICE INFORMATION MESSAGE

E$CDCI
E$SMOU
E$SDMO
E$SRES
E$SRCT

4
1
2
3
4

DEVICE CONTROL INFORMATION
DEVICE MOUNT
DEVICE DISMOUNT
DEVICE COUNT RESET
BLOCK REPLACEMENT

E$CCPU
E$SMEM
E$S INT

5
1
2

CPU DETECTED ERRORS
MEMORY ERROR
UNEXPECTED INTERRUPT

E$CSYS
E$SPWR

6
1

SYSTEM CONTROL INFORMATION
POWER RECOVERY

C-8

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
E$CCTL
E$STIM
E$SCRS
E$SLOA
E$SUNL
E $SHRC
E$SMES

CONTROL INFORMATION
TIME CHANGE
SYSTEM CRASH
DEVICE DRIVER LOAD
DEVICE DRIVER UNLOAD
RECONFIGURATION STATUS CHANGE
MESSAGE

E$CSDE
E$SABO

10
1

SOF'IWARE DETECTED EVENTS
TASK ABORT

1
2

3
4
5

CODES FOR CONTEXT CODE ENTRY E$HCTX
EH$NOR

NORMAL ENTRY

EH$STA
EH$CRS

START ENTRY
CRASH ENTRY

CODES FOR FLAGS ENTRY E$HFLG
1
2
4

EH$VIR
EH$EXT
EH$COU

ADDRESSES ARE VIRTUAL
ADDRESSES ARE EXTENDED
ERROR COUNTS SUPPLIED

TASK S UBPACKET

+-----------------------------------------------+
I TASK SUBPACKET LENGTH
I
+-----------------------------------------------+
I TASK NAME IN RAD50
I
I

+-----------------------------------------------+
I TASK UIC
I
+-----------------------------------------------+
I TASK TI: DEVICE NAME
I

+-----------------------+-----------------------+
I FLAGS
I TASK TI: UNIT NUMBER I
+-----------------------+-----------------------+

;

• =O

000000
000002
000006
000010
000012
000013

E $TLGH:
E$TTSK:
E $TUIC:
E $TTID:
E$TTIU:
E$TFLG:

000014

E $T LEN:

.BLKW
.BLKW
.BLKW
.BLKB
.BLKB
.BLKB
• EVEN

TASK SUBPACKET LENGTH
TASK NAME IN RAD50
TASK UIC
TASK TI: DEVICE NAME
TASK TI: UNIT
FLAGS

1
2
1
2
1
1

FLAGS FOR ENTRY E$TFLG
ET$PRV
ET$PRI

1
2

TASK IS PRIVILEGED
TERMINAL IS PRIVILEGED

C-9

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

DEVICE IDENTIFICATION SUBPACKET

+-----------------------------------------------+
I DEVICE IDENTIFICATION SUBPACKET LENGTH
I
+-----------------------------------------------+
i DEVICE MNEMONIC NAME
I
+-----------------------+-----------------------+
I CONTROLLER NUMBER
I DEVICE UNIT NUMBER
I
+-----------------------+-----------------------+
I PHYSICAL SUBUNIT #
I PHYSICAL UNIT #
I
+-----------------------+-----------------------+
I PHYSICAL DEVICE MNEMONIC (RSX-llM-PLUS ONLY)
I
+-----------------------+-----------------------+
I RESERVED
I FLAGS
I
+-----------------------+-----------------------+
I VOLUME NAME OF MOUNTED VOLUME
I
I
I
I
I
I

I
I
I
I
I

+-----------------------------------------------+
I PACK IDENTIFICATION
I
+-----------------------------------------------+
I DEVICE TYPE CLASS
I
+-----------------------------------------------+
I DEVICE TYPE
I
+-----------------------------------------------+
I I/O OPERATION COUNT LONGWORD
I
+-----------------------+-----------------------+
I HARD ERROR COUNT
I SOFT ERROR COUNT
I
+-----------------------+-----------------------+
I BLOCKS TRANSFERRED COUNT (RSX-llM-PLUS ONLY)
I
+-----------------------------------------------+
I CYLINDERS CROSSED COUNT (RSX-llM-PLUS ONLY)
I
;
• =O

000000
000002
000004
000005
000006
000007

E $I LGH:
E$I LDV:
E$ILUN:
E$IPCO:
E $I PUN:
E$IPSU:

+-----------------------------------------------+
• BLKW
.BLKW
• BLKB
.BLKB
.BLKB
.BLKB

1
1
1
1
1
1

DEVICE IDENTIFICATION SUBPACKET LENGTH
DEVICE MNEMONIC NAME
DEVICE UNIT NUMBER
CONTROLLER NUMBER
PHYSICAL UNIT NUMBER
PHYSICAL SUBUNIT NUMBER

.IF DF R$$MPL
E $I PDV: • BLKW
• ENDC

PHYSICAL DEVICE MNEMONIC

R$$MPL

C-10

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

000010
000011
000012
000026
000032
000032
000034
000040
000044
000045

E$IFLG:
E$IVOL:
E $I PAK:
E $!DEV:
E$IDCL:
E $IDTY:
E$IOPR:
E$IERS:
E$IERH:

.BLKB
.BLKB
.BLKB
.BLKB

1
1
12.

.BLKW
.BLKW
.BLKW
.BLKB
.BLKB

1
2
2
1
1

FLAGS
RESERVED
VOLUME NAME
PACK IDENTIFICATION
DEVICE TYPE
DEVICE TYPE CLASS
DEVICE TYPE
I/O OPERATION COUNT LONGWORD
SOFT ERROR COUNT
HARD ERROR COUNT

• IF DF R$$MPL
E $IBLK:

.BLKW

ti' CTf"'VT •

• BLK'/J

• ENDC

R$$MPL

.u Y..L.'-' ~ J...i •

000046

BLOCKS TRANSFERRED COUNT
CYLINDERS CROSSED COUNT

EVEN

E $I LEN:

S UBPACKET LENGTH

FLAGS FOR FIELD E $IFLG

1 ; S UBC ONTROLLER DEVICE

EI$SUB

DEVICE OPERATION SUBPACKET

+-----------------------------------------------+
I DEVICE OPERATION SUBPACKET LENGTH
I
+-----------------------------------------------+
I TASK NAME IN RADSO
I
I

+-----------------------------------------------+
I TASK UIC
I
+-----------------------------------------------+
I TASK TI: LOGICAL DEVICE MNEMONIC
I
+-----------------------+-----------------------+
I RESERVED
I TASK TI: DEVICE UNIT I
+-----------------------+-----------------------+
I I/O FUNCTION CODE
I
+-----------------------+-----------------------+
I RESERVED
I OPERATION FLAGS
I
+-----------------------+-----------------------+
I TRANSFER OPERATION ADDRESS
I

000000
000002
000006
000010
000012
000013
000014
000016
000017

;
• =O
E $0LGN:
E$0TSK:
E$0UIC:
E$0TID:

E$0TIU:
E$0FNC:
E $0FLG:

+-----------------------------------------------+
I TRANSFER OPERATION BYTE COUNT
I
+-----------------------------------------------+
I CURRENT OPERATION RETRY COUNT
I
+-----------------------------------------------+
.BLKW
.BLKW
.BLKW
.BLKB
.BLKB
.BLKB
.BLKW
.BLKB
.BLKB

1
2
1
2
l

1
1
1
1

SUBPACKET LENGTH
TASK NAME IN RADSO
TASK UIC
TASK TI: LOGICAL DEVICE MNEMONIC
TASK TI: LOGICAL DEVICE UNIT
RESERVED
I/O FUNCTION CODE
OPERATION FLAGS
RESERVED

C-11

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
000020
000024
000026
000030

E$0ADD: .BLKW
E $0SIZ: .BLKW
E $0RTY: .BLKW
• EVEN
E$0LEN:

TRANSFER OPERATION ADDRESS
TRANSFER OPERATION BYTE COUNT
CURRENT OPERATION RETRY COUNT

1
1

DEVICE OPERATION SUBPACKET LENGTH

FLAGS FOR FIELD E$0FLG
EO$TRA
EO$DMA
EO$EXT
EO$PI P

1
2

TRANSFER OPERATION
DMA DEVICE
EXTENDED ADDRESS ING DEVICE
DEVICE IS POSITIONING

I/O ACTIVITY SUBPACKET

+-----------------------------------------------+
I I/O ACTIVITY SUBPACKET LENGTH
I
+-----------------------------------------------+

;

000000

• =O
E $A LG H :

• BL KW

SUBPACKET LENGTH

I/O ACTIVITY SUBPACKET ENTRY

+-----------------------------------------------+
I LOGICAL DEVICE NAME MNEMONIC
I
+-----------------------+-----------------------+
I CONTROLLER NUMBER
I LOGICAL DEVICE UNIT
I
+-----------------------+-----------------------+
I PHYS !CAL SUBUNIT #
I PHYS !CAL UNIT NUMBER I
+-----------------------+-----------------------+
I PHYSICAL DEVICE MNEMONIC (RSX-llM-PLUS ONLY)
I
+-----------------------+-----------------------+
I TASK TI: LOGICAL UNIT I DEVICE FLAGS
I
+-----------------------+-----------------------+
I REQUESTING TASK NAME IN RADSO
I
I

+-----------------------------------------------+
I REQUESTING TASK UIC
I
+-----------------------------------------------+
I TASK TI: LOGICAL DEVICE NAME
I
+----------------~------------------------------+

I I/O FUNCTION CObE

+-----------------------+-----------------------+
I RESERVED
I FLAGS
I
+-----------------------+-----------------------+
I TRANSFER OPERATION ADDRESS
I
+-----------------------------------------------+
I TRANSFER OPERATION BYTE COUNT
I
+---------~-------------------------------------+

C-12

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

000000
000002
000003
000004
000005

• =O
E$ALDV:
E$ALUN:
E $APCO:
E$APUN:
E $APSU:

.BLKW
.BLKB
.BLKB
.BLKB
.BLKB

1
1
1
1
1

LOGICAL DEVICE NAME MNEMONIC
LOGICAL DEVICE UNIT
CONTROLLER NUMBER
PHYSICAL UNIT NUMBER
PHYSICAL SUBUNIT NUMBER

• IF DF R$$MPL
E$APDV:

000006
000007
000010
000014
000016
000020
000022
000023
000024
000030

E$AADD:
E$ASIZ:

000032

E$ALEN:

E $ADFG:
E$ATIU:
E $ATSK:
E$AUIC:
E $ATID:
E$AFNC:
E $AFLG:

.BLKW

• ENDC

R$$MPL

.BLKB
.BLKB
.BLKW
.BLKW
.BLKW
.BLKW
.BLKB
• BLKB
.BLKW
.BLKW
• EVEN

1
1
2
1
1
1
1
1
2
1

PHYSICAL DEVICE MNEMONIC

DEVICE FLAGS
TASK TI: LOGICAL UN IT
REQUESTING TASK NAME IN RAD SO
REQUESTING TASK UIC
TASK TI: LOGICAL DEVICE NAME
I/O FUNCTION CODE
FLAGS
RESERVED
TRANSFER OPERATION ADDRESS
TRANSFER OPERATION BYTE COUNT
SUBPACKET ENTRY LENGTH

FLAGS FOR FIELD E $ADFG
EA$SUB

1 ; S UBCONTROLLER DEVICE

FLAGS FOR FIELD E $AFLG
EA$TRA
EA$DMA
EA$EXT
EA$PIP

1
2
4

TRANSFER OPERATION
DMA DEVICE
DEVICE HAS EXTENDED ADDRESSING
DEVICE IS POSITIONING

• PSECT

C-13

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

F11DF$
FllDF$

,,SYSDEF

VOLUME CONTROL BLOCK

000000

• ASECT
• =O
V.TRCT: .BLKW

TRANSACTION COUNT

.IF DF R$$11M
000002

000004
000020

V.TYPE: .BLKB
VT.SLl= 1
VT.ANS= 10
VT.UNL= 11
V. VCHA: • BLKB
VC. SLK= 1
VC. HLK= 2
VC. DEA= 4
VC. PUB= 10
V.LABL: .BLKB
V.PKSR: .BLKW

000024

V. SLEN:

000003

14
2

VOLUME TYPE DESCRIPTOR
FILES-11 STRUCTURE LEVEL 1
ANSI LABELED TAPE
UNLABELED TAPE
VOLUME CHARACTERISTICS
CLEAR VOLUME VALID ON DISMOUNT
UNLOAD THE VOLUME ON DISMOUNT
DEALLOCATE THE VOLUME ON DISMOUNT
SET (CLEAR) US.PUB ON DISMOUNT
VOLUME LABEL (ASCII)
PACK SERIAL NUMBER FOR ERROR LOGGING
LENGTH OF SHORT VCB

• ENDC ;R$$11M
000024

V.IFWI: .BLKW

INDEX FILE WINDOW

• IF DF R$$11D
V. STD:

• BLKW

STD OF TASK CHARGED WITH NODE

• ENDC ;R$$11D
000026
000032
000033
000034
000036
000040

V.FCB:
• BLKW
V. IBLB: • BLKB
V. IBSZ: • BLKB
.BLKW
V. FMAX: .BLKW
V.WISZ: • BLKB

000041
000042
000044
000045
000046

V. SBC L:
V. SB SZ :
V. SB LB:
V.FIEX:

• BL KB
• BLKW
• B LKB
.BLKB
• BLKW

1
1
1
1
1
1
l

1
1

FILE CONTROL BLOCK LIST HEAD
INDEX BIT MAP lST LBN HIGH BYTE
INDEX BIT MAP SIZE IN BLOCKS
INDEX BITMAP lST LBN LOW BITS
MAX NO. OF FILES ON VOLUME
DEFAULT SIZE OF WINDOW IN RTRV PTRS
VALUE IS < 128.
STORAGE BIT MAP CLUSTER FACTOR
STORAGE BIT MAP SIZE IN BLOCKS
STORAGE BIT MAP lST LBN HIGH BYTE
DEFAULT FILE EXTEND SIZE
STORAGE BIT MAP lST LBN LOW BITS

.IF DF R$$11M
000050
000052

V.VOWN:
V.VPRO:

.BLKW
.BLKW

1
1

VOLUME OWNER'S UIC
VOLUME PROTECTION

• ENDC ;R$$11M
000054
000056
000057
000060
000062

V. FPRO: • BLKW
V. FRBK: • BLKB
V. LRUC: .BLKB
.BLKW
V.STS:
• BLKB
VS. IFW= 1
VS.BMW= 2

l
l
l
l
l

VOLUME DEFAULT FILE PROTECTION
NUMBER OF FREE BLOCKS ON VOLUME HIGH BYTE
COUNT OF AVAILABLE LRU SLOTS IN FCB LIST
NUMBER OF FREE BLOCKS ON VOLUME LOW BITS
VOLUME STATUS BYTE, CONTAINING THE FOLLOWING
INDEX FILE IS WRITE ACCESSED
STORAGE BITMAP FILE IS WRITE ACCESSED

C-14

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
000063
000064

V.FFNU: .BLKB
V. EXT:
• BLKW

000066

V.LGTH:

1
1

FIRST FREE INDEX FILE BITMAP BLOCK
POINTER TO VCB EXTENSION
SIZE IN BYTES OF VCB

MOUNT LIST ENTRY
EACH ENTRY ALLOWS ACCESS TO A SPECIFIED USER FOR A NON-PUBLIC DEVICE
TO ALLOW EXPANSION, ONLY THE ONLY TYPE CODE DEFINED IS "l" FOR
DEVICE ACCESS BLOCKS
• ASECT

000003
000004
000006

• =O
M. LNK:
M.TYPE:
MT.MLS=
M. ACC:
M. DEV:
M. TI:

000010

M. LEN:

000000
000002

.BLKW
.BLKB
1
.BLKB
.BLKW
.BLKW

1
1
l

1
1

LINK WORD
TYPE OF ENTRY
MOUNTED VOLUME USER ACCESS LIST
NUMBER OF ACCESSES
DEVICE UCB
ACCESSOR TI: UCB
LENGTH OF ENTRY

FILE CONTROL BLOCK

000000

• ASECT
• =O
F.LINK: .BLKW

FCB CHAIN POINTER

• IF DF R$$11D
F.FEXT: .BLKW
F. STD:
• BLKW

1
1

POINTER TO EXTENSION.FCB
STD OF TASK CHARGED WITH NODE

• ENDC ;R$$11D
000002
000004
000006
000007
000010
000012
000014
000015
000016

F.FNUM: .BLKW
F. FSEQ: .BLKW
.BLKB
F.FSQN: • BLKB
F.FOWN: .BLKW
F. FPRO: .BLKW
F. UCHA: .BLKB
F. SCHA: • BLKB
F.HDLB: .BLKW

1
1
1
1
1
1
1
1
2

000022

F. LBN:

• BLKW

000026
000032
000033

F.SIZE: .BLKW
F.NACS: • BLKB
F. NLCK: .BLKB

2
1
1

FILE NUMBER
FILE SEQUENCE NUMBER
NOT USED
FILE SEGMENT NUMBER
FILE OWNER'S UIC
FILE PROTECTION CODE
USER CONTROLLED CHARACTERISTICS
SYSTEM CONTROLLED CHARACTERISTICS
FILE HEADER LOGICAL BLOCK NUMBER
BEGINNING OF STATISTICS BLOCK
LBN OF VIRTUAL BLOCK 1 IF CONTIGUOUS
0 IF NON CONTIGUOUS
SIZE OF FILE IN BLOCKS
NO. OF ACCESSES
NO. OF LOCKS

C-15

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
000012

S. STBK=. -F. LBN

000034
000034
000035

F. STAT:
F.NWAC: .BLKB
.BLKB
FC.WAC= 100000
FC.DIR= 40000
FC.CEF= 20000
FC.FCO= 10000
F.DREF: .BLKW
F. DRNM: .BLKW

000036
000040

SIZE OF STATISTICS BLOCK
1
1

1
1

FCB STATUS WORD
NUMBER OF WRITE ACCESSORS
STATUS BITS FOR FCB CONSISTING OF
SET IF FILE ACCESSED FOR WRITE
SET IF FCB IS IN DIRECTORY LRU
SET IF DIRECTORY EOF NEEDS UPDATING
SET IF TRYING TO FORCE DIRECTORY CONTIG
DIRECTORY EOF BLOCK NUMBER
lST WORD OF DIRECTORY NAME

.IF DF R$$11M
000042

F.FEXT: .BLKW

POINTER TO EXTENSION FCB

.ENDC ;R$$11M
000044
000050
000052

F. FVBN: .BLKW
F. LKL:
.BLKW
F. WIN:
.BLKW

000054

F. LGTH:

2
1
1

STARTING VBN OF THIS FILE SEGMENT
POINTER TO LOCKED BLOCK LIST FOR FILE
WINDOW BLOCK LIST FOR THIS FILE
SIZE IN BYTES OF FCB

WINDOW
• ASECT
000 000

• =O
W• ACT:

000000

W.BLKS:

000000

W.CTL:

.BLKW

WI. RDV=
WI. WRV=
WI. EXT=
WI. LCK=
WI.DLK=

400
1000
2000
4 000
10000

NUMBER OF ACTIVE MAPPING POINTERS
WHEN NO SECONDARY POOL
BLOCK SIZE OF SECONDARY POOL SEGMENT
WHEN SECONDARY POOL
LOW BYTE = # OF MAP ENTRIES ACTIVE
HIGH BYTE CONSISTS OF CONTROL BITS
READ VIRTUAL BLOCK ALLOWED IF SET
WRITE VIRTUAL BLOCK ALLOWED IF SET
EXTEND ALLOWED IF SET
SET IF LOCKED AGAINST SHARED ACCESS
SET IF DEACCESS LOCK ENABLED

.IF DF R$$11M
WI. PND= 2 0000

WINDOW TURN PENDING BIT

• ENDC ;R$$11M
SET IF MANUAL UNLOCK DESIRED
DATA CHECK ALL WRITES TO FILE

WI. EXL= 40000
WI. WCK= 100000

W.FCB:
W. STD:
W. VBN:
W.WISZ:
W. LKL:
W. WIN:
W.RTRV:

• IF NDF R$$11M

IF NOT RSX-11

.BLKW
.BLKW
.BLKB
• BLKB
.BLKW

FILE CONTROL BLOCK ADDRESS
STD OF TASK CHARGED WITH WIDOW NODE
HIGH BYTE OF lST VBN MAPPED BY WINDOW
SIZE IN RTRV PTRS OF WINDOW (7 BITS)
LOW ORDER WORD OF lST VBN MAPPED
POINTER TO LIST OF USERS LOCKED BLOCKS
WINDOW BLOCK LIST LINK WORD
OFFSET TO lST RETRIEVAL POINTER IN WINDOW

.BLKW

1
1
1
1
1
1
1

C-16

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
.IFF
000002
000003
000004
000006
000010

w. roe:
W.FCB:
W. LKL:
W.WIN:

• BLKB
.BLKB
.BLKW
.BLKW
.BLKW

IF RSX-11
1
1
1
1
1

COUNT OF I/O THROUGH THIS WINDOW
RESERVED
FILE CONTROL BLOCK ADDRESS
POINTER TO LIST OF USERS LOCKED BLOCKS
WINDOW BLOCK LIST LINK WORD

.IF NB SYS DEF

IF SYSDEF SPECIFIED IN CALL

• IF NDF P$$WND

IF SECONDARY POOL WINDOWS NOT ALLOWED

NON-SECONDARY POOL WINDOW BLOCK
IF SECONDARY POOL WINDOWS ARE NOT ENABLED, THE WINDOW BLOCK
CONTAINS THE CONTROL INFORMATION AND RETRIEVAL POINTERS.
;

000012
000013
000013
000014
000016

W.VBN:
.BLKB
W.MAP:
W.WISZ: .BLKB
.BLKW
W. RTRV:

1
l

HIGH BYTE OF lST VBN MAPPED BY WINDOW
DEFINE LABEL WITH ODD ADDR TO CATCH BAD REFS
SIZE IN RTRV PTRS OF WINDOW (7 BITS)
LOW ORDER WORD OF lST VBN MAPPED
OFFSET TO lST RETRIEVAL POINTER IN WINDOW
IF WINDOWS IN SECONDARY POOL

.IFF

SECONDARY POOL WINDOW CONTROL AND MAPPING BLOCK
IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, LUTN2 POINTS
TO A CONTROL BLOCK IN SYSTEM POOL WHICH CONTAINS THE
FOLLOWING CONTROL FIELDS AND THE MAPPING INFORMATION
FOR THE SECONDARY POOL WINDOW.
;

W.MAP:

.BLKW

ADDR TO THE MAPPING PTRS IN SECONDARY POOL

SECONDARY POOL WINDOW
IF SECONDARY POOL WINDOW BLOCKS ARE ENABLED, THE RETRIEVAL
POINTERS ARE MAINTAINED IN SECONDARY POOL IN THE FOLLOWING
FORMAT.
;

• =O

ASSUME
• BLKB
W. USE:
• BLKB
W. VBN:
• BLKB
w.wisz: • BLKB
.BLKW
W. RTRV:

W.CTL,O
1
1
1
1
1

.ENDC ;P$$WND

NUMBER OF ACTIVE MAPPING POINTERS
STATUS OF BLOCK
HIGH BYTE OF lST VBN MAPPED BY WINDOW
SIZE IN RTRV PTRS OF WINDOW ( 7 BITS)
LOW ORDER WORD OF lST VBN MAPPED
OFFSET TO lST RETRIEVAL POINTER IN WINDOW
;- END SECONDARY POOL WINDOW CONDITIONAL

• ENDC ;SYS DEF

END SYSDEF CONDITIONAL

• ENDC ;R $$1 lM

END RSX-llM CONDITIONAL

LOCKED BLOCK LIST NODE
. ASECT
• =O

000000
000002

L. LN K:
L.Wil:

• B LKW
.BLKW

1
1

LINK TO NEXT NODE IN LIST
POINTER TO WINDOW FOR FIRST ENTRY

C-17

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
• IF DF R$$11D
L. STD:
L. VBl:
L. VB2:
L.CNT:

.BLKW
• BLKW
.BLKW
.BLKB
.BLKB

1
2
2
1
1

POINTER TO STD OF TASK NODE CHARGED TO
STARTING VBN OF FIRST ENTRY
STARTING VBN OF SECOND ENTRY
COUNT FOR FIRST ENTRY
COUNT FOR SECOND ENTRY

1
1
1

HIGH ORDER VBN BYTE
COUNT FOR ENTRY
LOW ORDER VBN

.IFF
000004
000005
000006

L. VBl:
L.CNT:

.BLKB
.BLKB
.BLKW
• ENDC

000010

;R$$11D

L. LKSZ:
• PSECT

C-18

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

HDRDF$
HDRDF$
TASK HEADER OFFSET DEFINITIONS
• ASECT
• =O

000000
000002
000004
000010
000012
000014
000016
000020
000022
000024
000026
000030
000032
000034
000036
000040
000042
000044
000046
000050
000052
000054
000056
000060
000061
000062
000064
000065
000066
000072
000074
000076

H. CSP:
H.HDLN:
H. EFLM:
H.CUIC:
H.DUIC:
H.IPS:
H.IPC:
H. ISP:
H. ODVA:
H. ODVL:
H.TKVA:
H.TKVL:
H. PFVA:
H.FPVA:
H. RCVA:
H. EFSV:
H.FPSA:
H.WND:
H.DSW:
H.FCS:
H.FORT:
H.OVLY:
H. VEXT:
H. SPRI:
H. NML:
H. RRVA:
H.X25:

.BLKW
.BLKW
.BLKW
. BLKW
.BLKW
.BLKW
• BLKW
• BLKW
• BLKW
.BLKW
.BLKW
• BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
• BLKW
.BLKW
• BLKW
.BLKW
.BLKW
.BLKW
• BLKB
• BLKB
.BLKW
• BLKB
• BLKB
.BLKW
H. GARD: .BLKW
H.NLUN: .BLKW
H.LUN:
• BLKW

1
1

;CURRENT STACK POINTER
;HEADER LENGTH IN BYTES
;EVENT FLAG MASK WORD AND ADDRESS
;CURRENT TASK UIC
;DEFAULT TASK UIC
; INITIAL PROCESSOR STATUS WORD (PS)
;INITIAL PROGRAM COUNTER (PC)
;INITIAL STACK POINTER (SP)
;ODT SST VECTOR ADDRESS
;ODT SST VECTOR LENGTH
;TASK SST VECTOR ADDRESS
;TASK SST VECTOR LENGTH
;POWER FAIL AST CONTROL BLOCK ADDRESS
;FLOATING POINT AST CONTROL BLOCK ADDRESS
;RECIEVE AST CONTROL BLOCK ADDRESS
;EVENT FLAG ADDRESS SAVE ADDRESS
;POINTER TO FLOATING POINT/EAE SAVE AREA
;POINTER TO NUMBER OF WINDOW BLOCKS
;TASK DIRECTIVE STATUS WORD
;FCS IMPURE POINTER
;FORTRAN IMPURE POINTER
;OVERLAY IMPURE POINTER
;WORK AREA EXTENSION VECTOR POINTER
;PRIORITY DIFFERENCE FOR SWAPPING
;NETWORK MAILBOX LUN
;RECEIVE BY REFERENCE AST CONTROL BLOCK ADDRESS
;FOR USE BY X.25 SOF'IWARE
; FIVE RESERVED BYTES

;

1
1
2

;'POINTER TO HEADER GUARD WORD
;NUMBER OF LUN Is
;START OF LOGICAL UNIT TABLE

1
1
2
1

1
1
1
1
1

1
1
1
1

1
1

1
1
1
1

1
1

1
1
1

C-19

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

LENGTH OF FLOATING POINT SAVE AREA
;

H.FPSL=25.*2

WINDOW BLOCK OFFSETS
;

000000
000002
000004
000006
000010
000012
000014
000015
000016

• =O
W.BPCB:
W.BLVR:
W• BHVR :
W.BATT:
W.BSIZ:
W• BOFF :
W.BFPD:
W• BNPD :
W• BL PD :

000020

W.BLGH:

.BLKW
.BLKW
• BL KW
• BLKW
.BLKW
• BL KW
.BLKB
• BL KB
• BL KW

1
1
1
1
1
1
1
1
1

;PARTITION CONTROL BLOCK ADDRESS
;LOW VIRTUAL ADDRESS LIMIT
;HIGH VIRTUAL ADDRESS LIMIT
;ADDRESS OF ATTACHMENT DESCRIPTOR
;SIZE OF WINDOW IN 32W BLOCKS
;PHYSICAL MEMORY OFFSET IN 32W BLOCKS
;FIRST PDR ADDRESS
;NUMBER OF PDR'S TO MAP
;CONTENTS OF LAST PDR
;LENGTH OF WINDOW DESCRIPTOR

• PSECT

C-20

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

HWDDF$
HWDDF$

HARDWARE REGISTER ADDRESSES AND STATUS CODES
;
MPCSR=l 77746
;ADDRESS OF PDP-11/70 MEMORY PARITY REGISTER
;ADDRESS OF FIRST MEMORY PARITY REGISTER
MPAR=l 72100
;PROGRAMMED INTERRUPT REQUEST REGISTER
PIRQ=l 77772
PRO=O
; PROCESSOR PRIORITY 0
PR1=40
;PROCESSOR PRIORITY 1
PR4=200
;PROCESSOR PRIORITY 4
PR5=240
;PROCESSOR PRIORITY 5
;PROCESSOR PRIORITY 6
PR6=300
PR 7=3 40
;PROCESSOR PRIORITY 7
PS=i 77776
;PROCESSOR STATUS WORD
;CONSOLE SWITCH AND DISPLAY REGISTER
SWR=l 77570
;CONSOLE TERMINAL PRINTER STATUS REGISTER
TPS=l 77564

EXTENDED ARITHMETIC ELEMENT REGISTERS
• IF DF E$$EAE
;ACCUMULATOR
;MULTIPLIER-QUOTIENT
; SHIFT COUNT

AC=l 773 02
MQ=l 77304
SC=l77310
• ENDC

; E $$EAE

MEMORY MANAGEMENT HARDWARE REGISTERS AND STATUS CODES
.IF DF M$$MGE
KDSARO=l 72 360
KDSDRO=l 72320
KISARO=l 72 340
KINARO=KISARO
KISAR5=172352
KINAR5=KISAR5
KISAR6=172354
KINAR6=KISAR6
KISAR7=172356
K!NAR7=KISAR7
KISDRO=l 72 300
KISDR6=172314
KI SDR 7=172316
S IS DR 0=1 72 2 0 0
UDSARO=l 77660
UDSDRO=l 77620
UISARO=l 77640
UISAR4=1 77650
UISAR5=1 77652
UISAR6=1 77654
UISAR 7=1 77656
UIS DR O=l 77600

; KERNEL D PAR
; KERNEL D PDR
; KERNEL I PAR
; KERNEL I PAR
;KERNEL I PAR
; KERNEL I PAR
; KERNEL I PAR
;KERNEL I PAR
; KERNEL I PAR
; KERNEL I PAR
; KERNEL I PDR
; KERNEL I PDR
; KERNEL I PAR
; SUPERVISOR I
; USER D PAR 0
;USER D PDR 0
;USER I PAR 0
; US.ER I PAR 4
;USER I PAR 5
;USER I PAR 6
;USER I PAR 7
;USER I PDR 0

C-21

0
0
0
0
5
5
6
6
7
7
0
6
7
PDR 0

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
UISDR4=177610
UISDR5=1 77612
UISDR6=1 77614
UIS DR 7=1 77616
UBMPR=l 70200
CMODE=l40000
PMODE=30000
SRO=l 77572
SR3=1 72516

; USER I PDR 4
;USER I PDR 5
;USER I PDR 6
;USER I PDR 7
;UNIBUS MAPPING REGISTER 0
;CURRENT MODE FIELD OF PS WORD
;PREVIOUS MODE FIELD OF PS WORD
;SEGMENT STATUS REGISTER 0
;SEGMENT STATUS REGISTER 3

• ENDC ;M$$MGE

FEATURE SYMBOL DEFINITIONS
;

FE. EXT=l
FE.MUP=2
FE. EXV=4
FE.DRV=lO
FE. PLA=20
FE. CAL=4 0
FE. PKT=l 00
FE. EXP=2 00
FE. LS I=4 00
FE.OFF=lOOO
FE. FDT=2000
FE.X25=4000
FE.DYM=lOOOO
FE.CEX=20000
FE. MXT=4 0000
F E. NLG= 1 0 0 0 0 0

;22-BIT EXTENDED MEMORY SUPPORT
;MULTI-USER PROTECTION SUPPORT
;EXECUTIVE IS SUPPORTED TO 20K
;LOADABLE DRIVER SUPPORT
;PLAS SUPPORT
;DYNAMIC CHECKPOINT SPACE ALLOCATION
;PREALLOCATION OF I/O PACKETS
;EXTEND TASK DIRECTIVE SUPPORTED
;PROCESSOR IS AN LSI-11
;PARENT OFFSPRING TASKING SUPPORTED
;FULL DUPLEX TERMINAL DRIVER
; X. 25 COM EXECUTIVE LOADED (l=YES)
;DYNAMIC MEMORY ALLOCATION SUPPORTED
; COM EXEC IS LOADED
;MCR EXIT AFTER EACH COMMAND MODE
;LOGINS DISABLED - MULTI-USER SUPPORT

SECOND FEATURE MASK SYMBOL DEFINITIONS
;

F2.DAS=l
F2. LIB=2
F2.MP=4
F2. EVT=lO
F2.ACN=20
F2.SIM=40
F2. POL=lOO
F2. WND=200
F2.DPR=400
F 2. IRR=l 00 0
F2.GGF=2000
F2.RAS=4000
F2.AHR=l0000
F 2. RBN=2 0000
F 2. SWP=40000
F2. STP=lOOOOO

;KERNEL DATA SPACE
(M-PLUS ONLY)
II
;SUPERVISOR MODE LIBRARIES
II
;MULTIPROCESSING SUPPORT
II
;EVENT TRACE SUPPORT
II
; CPU ACCOUNTING
II
; SHADOW RECORDING
II
; SECONDARY POOLS
II
;SECONDARY POOL FILE WINDOWS
;DIRECTIVE PARTITION SUPPORT
;INSTALL, REQUEST AND REMOVE SUPPORT
;GROUP GLOBAL EVENT FLAG SUPPORT
;RECEIVE/SEND DATA PACKET SUPPORT
;ALT. HEADER REFRESH AREAS SUPPORTED
;ROUND ROBIN SCHEDULING SUPPORT
;EXECUTIVE LEVEL DISK SWAPPING SUPPORT
;EVENT FLAG MASK IS IN THE TCB {l=YES)

C-22

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

THIRD FEATURE MASK SYMBOL DEFINITIONS
;

F 3. CRA=l
F3.NWK=2
F 3. EIS=4
F 3. STM=l 0
F 3. UDS=20
F3. PR0=40
F3.XHR=l00
F3.AST=200
F3.11S=400
F 3. CLI =l 000
F 3. TCM=2000
F3. PMN=4000
F3.WAT=l0000
F3.RLK=20000

;SPONTANEOUS CRASH (l=YES)
;SYSTEM HAS NETWORK SUPPORT
;SYSTEM REQUIRES THE EXTENDED INST. SET
;SYSTEM HAS SET SYSTEM TIME DIRECTIVE
;USER DATA SPACE (M-PLUS ONLY)
11
; PROTO TCBS OUT OF POOL
11
; EXTERNAL HEADER SUPPORT
;SYSTEM HAS AST SUPPORT
;SYSTEM IS RSX-llS
;SYSTEM HAS MULTIPLE CLI SUPPORT
;TERMINAL COMMON (M-PLUS ONLY)
;POOL MONITORING SUPPORT
;WATCHDOG TIMER SUPPORT
; 'RMS' RECORD LOCKING SUPPORT

HARDWARE FEATURE MASK SYMBOL DEFINITIONS
;

HF. UBM=l
HF. EIS=2
HF. CIS=2 00
HF.FPP=lOOOOO

;SYSTEM
;SYSTEM
;SYSTEM
;SYSTEM

HAS A UNIBUS MAP (l=YES)
HAS EXTENDED INSTRUCTION SET
HAS COMMERCIAL INSTRUCTION SET
SUPPORTS FLOATING POINT (l=NO)

C-23

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

ITBDF$
ITBDF$

, , SYS DEF

INTERRUPT TRANSFER BLOCK (ITB} OFFSET DEFINITIONS
• IF DF A$$TRP
.MCALL
PKTDF$

PKTDF$
DEFINE AST BLOCK OFFSETS

• ENDC ;A$$TRP
• ASECT
000000
000002
000006
000007
000010
000012
000012
000014
000016
000020

• =O
X. LNK:
X. JSR:
X. PSW:

X. !SR:
X. FORK:

.BLKW
JSR
.BLKB
.BLKB
.BLKW

1
RS,@#0
1
1
1

.BLKW
.BLKW
.BLKW
.BLKW

1
1
1
1

LINK WORD FOR !TB LIST STARTING IN TCB
CALL $INTSC
LOW BYTE OF PSW FOR !SR
UNUSED
!SR ENTRY POINT (APRS MAPPING}
FORK BLOCK
THREAD WORD
FORK PC
SAVED RS
SAVED R4

• IF DF M$$MGE
X. REL:

.BLKW

RELOCATION BASE FOR AFRS

• ENDC ;M$$MGE
X. DS I:
X.TCB:

.BLKW
.BLKW

1
1

ADDRESS OF DIS.INT. ROUTINE
TCB ADDRESS OF OWNING TASK

.IF NB SYS DEF
• IF DF A$$TRP
X.AST:

.BLKW
.BLKB

1
A.PRM

A.DQSR FOR AS! BLOCK
AST BLOCK

• ENDC ;A$$TRP
X. VEC:

.BLKW

X. VPC:
X.LEN:

.BLKW

VECTOR ADDRESS (IF AST SUPPORT,
THIS IS FIRST AND ONLY AST PARAMETER}
SAVED VECTOR PC
LENGTH IN BYTES OF !TB

.ENDC ;SYS DEF
• PSECT

C-24

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

LCBDF$
LCBDF$
LOGICAL ASSIGNMENT CONTROL BLOCK
THE LOGICAL ASSIGNMENT CONTROL BLOCK (LCB) IS USED TO ASSOCIATE A
LOGICAL NAME WITH A PHYSICAL DEVICE UNIT.
LCB'S ARE LINKED TOGETHER
TO FORM THE LOGICAL ASSIGNMENTS OF A SYSTEM.
ASSIGNMENTS MAY BE ON
A SYSTEM WIDE OR LOCAL (TERMINAL) BASIS •
• ASECT
000000
000002
000004
000005
000006
000010

• =O
L. LNK:
L.NAM:
L.UNIT:
L.TYPE:
L. UCB:
L.ASG:

000012

L. LGTH=. -L. LNK

.BLKW
.BLKW
.BLKB
.BLKB
.BLKW
• BLKW

1
1
1

.l.

1
1

;LINK TO NEXT LCB
;LOGICAL NAME OF DEVICE
;LOGICAL UNIT NUMBER
;TYPE OF ENTRY (O=SYSTEM WIDE)
;TI UCB ADDRESS
;ASSIGNMENT UCB ADDRESS
;LENGTH OF LCB

• PSECT

C-25

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

MTADF$
MTADF$
ANSI MAGTAPE SPECIFIC DATA STRUCTURES
VOLUME SET CONTROL BLOCK OFFSET DEFININTIONS

(VSCB)

VOLUME SET AND PROCESS CONTROL SECTION
• ASECT
• =O

000000
000002
000003
000004
000020
000022
000024
000026
000030
000032
000033
000034
000036
000040
000042
000043
000044
000046
000054
000055

V. TCNT:
V.TYPE:
V. VCHA:
V. LABL:
V. NXT:
V.MVL:
V. UVL:
V .ATL:
V.UCB:
V. RVOL:
V.MOU:
V.TCHR:
V.SEQN:
V. SECN:
V. TPOS:
V.PSTA:
V. TIMO:
V. STAT:
V.TRTB:
V. EFTV:

.BLKW
.BLKB
.BLKB
.BLKB
.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKB
.BLKB
.BLKW
.BLKW
.BLKW
.BLKB
.BLKB
.BLKW
.BLKW
.BLKB
.BLKB

1
1
1
12.
1
1
1
1
1
1
1
1
1
1
1
1
1
3
1
1

;TRANSACTION COUNT
;VOLUME TYPE DESCRIPTOR
;VOLUME CHARACTERISTICS
;FILE SET ID (FIRST SIX BYTES)
;PTR TO NEXT VSCB NODE
;PTR TO MOUNTED VOL LIST
;PTR TO UNMOUNTED VOL LIST
;ATL ADDR OF ACCESSING TASK TCB IN RSXl lM
;ADDR OF CURRENT UCB OR PUD
;CURRENT RELATIVE VOL #
;MOUNT MODE BYTE
;UINT CHAR. FOR ALL UNITS USED FOR VOL SET
;CURRENT FILE SEQUENCE #
;CURRENT FILE SECTION #
;POSITION OF TAPE IN TM Is TO NXT HDRl
;PROCESS STATUS BYTE
;BLOCKED PROCESS TIMEOUT COUNTER
; STATUS WORDS USED BY CCMMAND EXECUTION MODULES
;TRANSLATION CONTROL BYTE
;FOR MAG TO RETURN IE.EOF, EOT, EOV

LABEL DATA SECTION
i

000056
000060
000062
000070
000072
000074
000100
000104
000110
000111
000112

V. BLKL:
V. RECL:
V. FNAM:
V.FTYP:
V.FVER:
V. CDAT:
V. EDAT
V. BLKC:
V. RTYP:
V.FATT:
0

.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
.BLKW
• BLKW
• BLKW
• BLKB
• BLKB
• BLKB

1
1
3
1
1
2
2
2
1

1
30.

; BLOCK LENGTH
;RECORD LENGTH
; FILE NAME
;FILE TYPE
; FILE VERSION #
;CREATION DATE
; EXPRIATION DATE
;BLOCK COUNT FOR FILE SECTION
; RECORD TYPE
;FILE ATTRIBUTES FOR CARRIAGE CONTROL
;REMAINDER OF FILE ATTRIBUTES

C-26

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

NULL WINDOW SECTION
;

000150 V.WIND:
000160 V. MST2:
000162 V.FABY:
000163
000164 V. ANSN:
000205 V. BOFF:
000206 V. DENS:
000207 . V. DRAT:
000210 V. DBLK:
000212 V. DREC:
000214

• BLKW
.BLKW
.BLKB
.BLKB
.BLKB
.BLKB
.BLKB
.BLKB
.BLKW
.BLKW

4•
1
1
1
1 7.
1.
1.

1.
1.
1.

;NULL WINDOW
;MAGTAPE STATUS BITS
;FILE ACCESSIBILITY BYTE {HDRl)
;SPARE
;ANSI 1 7 CHARACTER FILE NAME
;BUFFER OFFSET
;REQUESTED UNIT DENSITY
;DEFAULT RECORD ATTRIBUTES
;DEFAULT BLOCK SIZE
;DEFAULT RECORD SIZE
;SIZE OF VSCB

S. VSCB=.
• PSECT

DEFINE OFFSETS INTO NULL WINDOW SECTION
• ASECT
• =O

000000

W.CTL: .BLKW
1
V.WINC=V.WIND+w.CTL

;CONTROL WORD IN WINDOW
;CNTRL WORD IN NULL WINDOW
;RELATIVE TO THE VSCB

• PSECT
MOUNTED VOLUME LIST OFFSET DEFININTIONS {MVL)
• ASECT
• =O

• IF DF R$$11M
000000

M. NXT:

.BLKW

;PTR TO NXT MVL NODE {llM)

• ENDC ;R$$11M
000002
000004
000006

M. UIC: .BLKW
M. CH:
.BLKW
M. PROT: .BLKW

1
1
1

;OWNER UIC FROM RVOL #1
; U. CH/U. VP {l lD)
;PROTECTION U.AR IN llD

.IF NDF R$$11M
M. NXT:

.BLKW
.BLKW

2
1

;ACP WORDS llD
;PTR TO NEXT MVL NODE {llD)

• ENDC ;R$$11M
000010
000011
000012
000014

M. RVOL:
M. STAT:
M. VIDP:
M. UCB:

000016

S.MVL=.

.BLKB
.BLKB
.BLKW
.BLKW

1
1
1
1

;RELATIVE VOL # OF MOUNTED VOLUME
;VOLUME STATUS
;VOLUME ID POINTER
;ADDR OF ASSOC UCB OR PUD
;SIZE OF MVL NODE

• PSECT

C-27

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

UNMOUNTED VOLUME AND VOLUME

LIST OFFSET DEFINITIONS (UVL)

• ASECT

000003
000004
000012

• =O
L. NXT:
L. VOLl:
L. VOL2:
L. VIDl:
L. VID2:

000020

S. UVL=.

000000
000002

.BLKW

.BLKB

.BLKB
.BLKB
.BLKB

1
6
6

;PTR TO NXT UVL NODE
;REL VOL # OF l 'ST VOL IN NODE
;REL VOL # OF 2 'ND VOL IN NODE
;VOL ID OF l 'ST VOL IN NODE
;VOL ID OF 2'ND VOL IN NODE
;SIZE OF UVL NODE

• PSECT
SYSTEM DATA STRUCTURE CONTENT VALUES

VSCB VALUES
V. MOU VALUES
;

VM.OLD
VM. BYP
VM. ULB
VM. FSC
VM. EXC

200
100
40
20
10

;OLD .FL300 VOLUME -- VM.BYP WILL ALSO BE SET
;BYPASS LABEL PROCESSING
; UNLABELED TAPE
;OVERRIDE FILE SET ID CHECK
; OVERRIDE EXPRIATION DA.TE CHECK

;MAG WANTS US TO INITIALIZE NEXT OUTPUT
;THIS FILE HAS NO HDR2, DON'T WRITE EOF2
;THIS FILE HAS NO HDR3, DON'T WRITE EOF3
;DON'T WRITE HDR3/EOX3 LABELS
;OVERRIDE FILE/VOLUME ACCESSIBILITY

V.MST2 VALUES
;

V2. INI
V2. XH2
V2. XH3
V2. NH3
V2. OAC

10
20

V.PSTA VALUES - UNBLOCKED TRANSITION STATE
;

VP. RM
VP.WM
VP.UCM
VP.SM
VP.MOU
VP. RWD
VP., VFY
VP. POS

2
4
6

10
20
40
VP. RWD
100

;READ DATA MODE
;WRITE DATA MODE
;UNLABELLED CREATE POSITIONING MODE
; SEARCH MODE
;MOUNT MODE
;REWIND OR VOL VERIFICATION WAIT
;PROCESS IN POSITIONING MODE
; (MULTI-SECTION FILE)

BLOCKED STATE = -(UNBLOCKED TRANSITION STATE VALUES)
PROCESS TIMED OUT BIT 0 = 1
;

VP.TO=l

C-28

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

NULL WINDOW CONTROL BIT DEFINITIONS
;

WI. RDV
WI.WRV
WI. EXT
WI. LCK

400
1000
2000
4000

;ACCESSED FOR READ
;ACCESSED FOR WRITE
;ACCESSED FOR EXTEND
; LOCKED

MVL VALUES IN THE M.STAT FIELD
;

MS. VER
MS. RID
MS. NMO
MS. TMO
MS. EXP

200
1
2
4

;VOL ID NOT VERIFIED
;VOL ID TO BE READ NOT CHECKED
;MOUNT MESSAGE NOT GIVEN YET
;ONE TIMEOUT ALREADY EXPRIED
;EXPIRATION DATE MESSAGE GIVEN

MISC BITS USED IN MOUNT (STORED IN V. STS)
i

MO. OVR
MO. UIC
MO. PRO
MO. 160

1
2
4
10

;OVER RIDE VOL NAME SWITCH
;EXPLICIT UIC GIVEN
;EXPLICIT PROTECTION GIVEN
;1600 BPI SPECIFIED

C-29

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

PCBDF$
PCBDF$

, , SYSDEF

PARTITION CONTROL BLOCK OFFSET DEFINITIONS

000000
000002
000003
000004
000010
000012

• ASECT
• =O
P. LNK:
.BLKW
P. PR!:
• BLKB
.BLKB
P. roe:
P.NAM:
.BLKW
P. SUB:
.BLKW
P.MAIN: .BLKW
• IF NB

1
1
2
1

; LINK TO NEXT PARTITION PCB
;PRIORITY OF PARTITION
;I/O + I/O STATUS BLOCK COUNT
;PARTITION NAME IN, RAD50
;POINTER TO NEXT SUBPARTITION
;POINTER TO MAIN PARTITION

SYSDEF

.IF NDF M$$MGE
P.HDR:

;POINTER TO HEADER CONTROL BLOCK
• ENDC

;M$$MGE

.IFTF
000014
000016
000016

P • RE L:
• BL KW
P. BLKS:
P.SIZE: .BLKW

;STARTING PHYSICAL ADDRESS OF PARTITION

000020
000022
000024
000026
000026
000030

P.WAIT:
P.SWSZ:
P. BUSY:
P. OWN:
P.TCB:
P. STAT:

.BLKW
.BLKW
• BL KB

1
1
2

;SIZE OF PARTITION IN:
UNMAPPED SYSTEMS - BYTES
;
MAPPED SYSTEMS
- 32 WORD BLOCKS
;PARTITION WAIT QUEUE LISTHEAD (2 WORDS)
;PARTITION SWAP SIZE (SYSTEM ONLY)
;PARTITION BUSY FLAGS

.BLKW
• BLKW

1
1

;TCB ADDRESS OF OWNER TASK
;PARTITION STATUS FLAGS

.IFT

P. HDR:

P. PRO:
P.ATT:

.IF DF

M$$MGE

• BLKW

• ENDC

;M$$MGE

• BLKW
.BLKW

1
2

;POINTER TO HEADER CONTROL BLOCK

;PROTECTION WORD [DEWR,DEWR,DEWR,DEWR]
;ATTACHMENT DESCRIPTOR LISTHEAD

.IF NDF P$$LAS
P. LGTH=P. PRO

;LENGTH OF PARTITION CONTROL BLOCK

C-30

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
.IFF
P.LGTH=.

;LENGTH OF PARTITION CONTROL BLOCK
.ENDC

;P$$LAS

.IFF
• PSECT
PARTITION STATUS WORD BIT DEFINITIONS
;

PS.OUT=lOOOOO
PS.CKP=40000
PS.CKR=20000
PS.CHK=lOOOO
PS. FXD=4 000
PS. PER=2000
PS.LIO=lOOO
PS. NSF=4 00
PS.COM=200
PS. PIC=lOO
PS. SYS=4 0
PS.DRV=20
PS. DEL=lO

;PARTITION IS OUT OF MEMORY(l=YES)
;PARTITION CHECKPOINT IN PROGRESS {l=YES)
;PARTITION CHECKPOINT IS REQUESTED (l=YES)
;PARTITION IS NOT CHECKPOINTABLE (l=YES)
;PARTITION IS FIXED (l=YES)
;PARITY ERROR IN PARTITION (l=YES)
;MARKED BY SHUFFLER FOR LONG I/O (l=YES)
;PARTITION IS NOT SHUFFLEABLE (l=YES)
;LIBRARY OR COMMON BLOCK (l=YES)
;POSITION INDEPENDENT LIBRARY OR COMMON (l=YES)
;SYSTEM CONTROLLED PARTITION (l=YES)
;DRIVER IS LOADED IN PARTITION {l=YES)
;PARTITION SHOULD BE DELETED WHEN NOT ATTACHED
; (l=YES)
;STARTING APR NUMBER MASK

PS.APR=?

ATTACHMENT DESCRIPTOR OFFSETS
• ASECT
000000
000002
000003
000004
000006
000010
000011
000012
000014

• =O
A. PCBL:
A. PRI:
A. IOC:
A. TCB:
A. TCBL:
A.STAT:
A.MPCT:
A. PCB:

.BLKW
• BLKB
• BLKB
• BLKW
• BLKW
• BLKB
• BLKB
• BLKW

1
1
1
1
1
1
1
1

A.LGTH=.

;PCB ATTACHMENT QUEUE THREAD WORD
;PRIORITY OF ATTACHED TASK
; I/O COUNT THROUGH THIS DESCRIPTOR
;TCB ADDRESS OF ATTACHED TASK
;TCB ATTACHMENT QUEUE THREAD WORD
; STATUS BYTE
;MAPPING COUNT OF TASK THRU THIS DESCRIPTOR
;PCB ADDRESS OF ATTACHED TASK
;LENGTH OF ATTACHMENT DESCRIPTOR

ATTACHMENT DESCRIPTOR STATUS BYTE BIT DEFINITIONS
• PSECT
AS. DEL=l 0
AS.EXT=4
AS.WRT=2
AS. RED=l
• ENDC

;TASK HAS DELETE ACCESS (l=YES)
;TASK HAS EXTEND ACCESS (l=YES)
;TASK HAS WRITE ACCESS (l=YES)
;TASK HAS READ ACCESS (l=YES)
; SYS DEF

C-31

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

PKTDF$
PKTDF$
ASYNCHRONOUS SYSTEM TRAP CONTROL BLOCK OFFSET DEFINITIONS
SOME POSITIONAL DEPENDENCIES BETWEEN THE OCB AND THE AST CONTROL
BLOCK ARE RELIED UPON IN THE ROUTINE $FINXT IN THE MODULE SYSXT •
• ASECT
.=177774
1 77774
1 77776
000000
000002

A • KS R 5: • BL KW
A.DQSR: .BLKW
.BLKW
A. CBL:
• BLKW

000004
000006
000010
000012

A.BYT:
A.AST:
A. NPR:
A. PRM:

1
1

.BLKW
• BLKW
.BLKW
.BLKW

1
1

;SUBROUTINE KISARS BIAS {A.CBL=O)
;DEQUEUE SUBROUTINE ADDRESS {A.CBL=O)
;AST QUEUE THREAD WORD
;LENGTH OF CONTROL BLOCK IN BYTES
;IF A.CBL = 0, THE AST CONTROL BLOCK IS
;TO BE DEALLOCATED BY THE DEQUEUE SUBROUTINE
;POINTED TO BY A.DQSR MAPPED VIA APR 5
;VALUE A.KSRS. THIS IS CURRENTLY USED ONLY
;BY THE FULL DUPLEX TERMINAL DRIVER FOR
;UNSOLICITED CHARACTER ASTS.
;IF THE LOW BYTE OF A.CBL = O, AND THE
;HIGH BYTE IS NOT = 0, THE AST CONTROL BLOCK
;IS A SPECIFIABLE AST, WITH LENGTH, C.LGTH.
;IF THE HIGH BYTE OF A.CBL = 0 AND THE LOW
;BYTE > O, THEN THE LOW BYTE IS THE LENGTH
;OF THE AST CONTROL BLOCK.
IF THE HIGH BYTE
;OF A.CBL = 0 AND THE LOW BYTE IS NEGATIVE,
;THIS IS A KERNEL AST. SEE BELOW FOR
;A DESCRIPTION OF A.CBL FOR KERNEL ASTS.
;NUMBER OF BYTES TO ALLOCATE ON TASK STACK
;AST TRAP ADDRESS
;NUMBER OF AST PARAMETERS
;FIRST AST PARAMETER

THE SPECIFIABLE AST CODES MUST NOT BE O.
;

AS. FPA=l
AS. RCA=2
AS. RRA=3
AS. PFA=4
AS. REA=S
AS.CAA=6

;CODE
;CODE
;CODE
;CODE
;CODE
;CODE

FOR FLOATING POINT AST
FOR RECEIVE DATA AST
FOR RECEIVE BY REFERENCE AST
FOR POWERFAIL AST
FOR REQUESTED EXIT {ABORT) AST
FOR COMMAND ARRIVAL AST FOR CLIS

ABORTER SUBCODES FOR ABORT AST {AS.REA) TO BE RETURNED ON USER'S
STACK

AB.NPV=l
AB.TYP=2

;ABORTER IS NONPRIVILEGED {l=YES)
;ABORT FROM DIRECTIVE {O=YES)
;ABORT FROM CLI COMMAND {l=YES)

C-32

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

KERNEL AST CONTROL BLOCK DEFINITIONS
THE LOW BYTE OF A.CBL FOR A KERNEL AST HAS THE FOLLOWING FORMAT:
BIT #200 ALWAYS EQUALS 1
BIT #100 IS ZERO IF $SGFIN MUST BE CALLED DURING AST PROCESSING
THE REMAINING SIX BITS ARE USED AS THE KERNEL AST TYPE FIELD
BECAUSE THERE ARE ONLY 6 BITS AVAILABLE TO THE KERNEL AST
INDEX FIELD, ONLY (2**6)-1 KERNEL AST TYPES ARE POSSIBLE.
;

AK. BUF=200
AK. OCB=201
AK. GB I=202
AK. TBT=203
AK. DI0=204

;BUFFERED I/O COMPLETION AST
;OFFSPRING EXIT
;GENERAL BUFFERED I/O AST
;TASK FORCED T-BIT TRAP AST
;DELAYED I/O (M-PLUS COMPATIBLE)

OFFSPRING CONTROL BLOCK DEFINITIONS
SOME POSITIONAL DEPENDENCIES EXIST BE'IWEEN THE OCB AND THE AST
CONTROL BLOCK IN ROUTINE $FINXT IN MODULE SYSXT
;

000000
000002
000004
000006
000010
000012
000014

• =O
O. LNK:
O.MCRL:
O. PTCB:
O.AST:
O. EFN:
O. ESB:
O. STAT:

000034

O. LGTH=.

• BLKW
• BLKW
.BLKW
.BLKW
.BLKW
• BLKW
• BLKW

1
1
1
1
1
1
8.

;OCB LINK WORD
;ADDRESS OF MCR COMMAND LINE
;PARENT TCB ADDRESS
;EXIT AST ADDRESS
;EXIT EVENT FLAG
;EXIT STATUS BLOCK VIRTUAL ADDRESS
;EXIT STATUS BUFFER
;LENGTH OF OCB

I/O PACKET OFFSET DEFINITIONS
• ASECT
000000
000002
000003
000004
000006
000010
000012
000014
000016
000020
000022
000024
000026
000042

• =O
I. LNK:
I. PRI:
I. EFN:
I. TCB:
I. LN 2:
I. UCB:
I. FCN:
I. IOSB:
I. AST:
I. PRM:

000044

I. ATTL=.

000044

I. LGTH=.

• BLKW
• BLKB
• BLKB
• BLKW
• BLKW
• BLKW
• BLKW
.BLKW
• BLKW
• BLKW
• BLKW
• BLKW
• BLKW
• BLKW

1
1
1
1
1

1
1
1
1
1
1
6
1

; I/O QUEUE THREAD WORD
;REQUEST PRIORITY
;EVENT FLAG NUMBER
;TCB ADDRESS OF REQUESTOR
;POINTER TO SECOND LUN WORD
;POINTER TO UNIT CONTROL BLOCK
;I/O FUNCTION CODE
;VIRTUAL ADDRESS OF I/O STATUS BLOCK
; I/O STATUS BLOCK RELOCATON BIAS
;I/O STATUS BLOCK ADDRESS
;AST SERVICE ROUTINE ADDRESS
;RESERVED FOR MAPPING PARAMETER #1
;PARAMETERS 1 TO 6
;USER MODE DIAGNOSTIC PARAMETER WORD
;MINIMUM LENGTH OF I/O PACKET (USED BY
;FILE SYSTEM TO CALCULATE MAXIMUM
;NUMBER OF ATTRIBUTES)
;LENGTH OF I/O REQUEST CONTROL BLOCK

C-33

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

GROUP GLOBAL EVENT FLAG CONTROL BLOCK OFFSETS
;

000000
000002
000003
000004
000006

• =O
G. LNK:
G .GRP:
G. STAT:
G.CNT:
G. EFLG:

000012

G. LGTH=.

.BLKW
• BLKB
• BLKB
.BLKW
.BLKW

1
1
1
1
2

;LINK WORD
;GROUP NUMBER
;STATUS BYTE
;ACCESS COUNT
; EVENT FLAGS
;LENGTH OF GROUP GLOBAL CONTROL BLOCK

STATUS BYTE DEFINITIONS
;

;GROUP MARKED FOR DELETE

GS.• DEL=l

EXECUTIVE POOL MONITOR CONTROL FLAGS

$POLST IS THE SYNCHRONIZATION WORD BE'IWEEN THE EXEC AND POOL MONITOR
;

PC. HIH=l
PC. LOW=2
PC. ALF=4
PC.NRM=PC.HIH*400
PC.ALM=PC.LOW*400

;HIGH POOL LIMIT CROSSED (l=YES)
;LOW POOL LIMIT CROSSED (l=YES)
;POOL ALLOCATION FAILURE (l=YES)
;POOL TASK INHIBIT BIT FOR HIGH POOL
;POOL TASK INHIBIT BIT FOR LOW POOL

;

; $POLFL IS THE POOL USAGE CONTROL WORD
;

PF.INS=40
PF.LOG=lOO
PF. REQ=200
PF. ALL=l 77777

;REJECT NONPRIVILEGED INS/RUN/REM
;LOGINS ARE DISABLED
;STALL REQUEST OF NONPRIV. TASKS
;TAKE ALL POSSIBLE ACTIONS TO SAVE POOL

CLI PARSER BLOCK (CPB) DEFINITIONS
;

000000
000002
000006
000010
000011
000012

• =O
C. PTCB:
C. PNAM:
C. PSTS:
C. PDPL:
C. PCPL:
C. PRMT:

.BLKW
.BLKW
• BLKW
• BLKB
• BLKB

1
2
1
l

;ADDRESS OF CLI'S TCB
;CLI NAME
;STATUS MASK
;LENGTH OF DEFAULT PROMPT
;LENGTH OF CNTRL/C PROMPT
;START OF ASCII PROMPT STRINGS
;THE DEFAULT STRING IS CONCANTENATED
;WITH THE Ac STRING

C-34

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

STATUS BIT DEFINITIONS
;

CP. NUL=l
CP.MSG=2
CP. LG0=4
CP.DSB=lO
CP. PRV=20
CP.SGL=40
CP. NIO=lOO

;PASS EMPTY COMMAND LINES TO CLI
;CLI DESIRES SYSTEM MESSAGES
;CLI WANTS COMMANDS FROM LOGGED OFF TTYS
; CLI IS DISABLED
;USER MUST BE PRIV TO SET TTY TO THIS CLI
;DON'T HANDLE CONTINUATIONS (M-PLUS ONLY)
;MCR ••• , HEL, BYE DO NO I/OTO TTY
;HEL, BYE ALSO DO NOT SET CLI ETC.
;ABILITY TO SET TO THIS CLI IS RESTRICTED
;TO THE CLI ITSELF
; PASS TASK EXIT PROMPT REQUESTS TO C LI

CP.RST=200
CP. EXT=400

IDENTIFIER CODES FOR SYSTEM TO CLI MESSAGES.
CODES 0 - 127. ARE RESERVED FOR USE BY DIGITAL,
CODES 128. - 255. ARE RESERVED FOR USE BY CUSTOMERS
;

; CLI INIT IA LIZ ED ENABLED
;CLI INITIALIZED DISABLED
; CLI ENABLED
;CLI DISABLED
;CLI BEING ELIMINATED
;CLI MUST EXIT IMMEDIATELY
;NEW TERMINAL LINKED TO CLI
;TERMINAL REMOVED FRC14 CLI
1;GENERAL MESSAGE TO C LI

CM. INE=l
CM. IND=2
CM.CEN=3
CM. CDS=4
CM. ELM=5
CM. EXT=6
CM. LKT=7
CM. RMT=8.
CM.MSG=9.

ANCILLARY CONTROL BLOCK (ACB) DEFINITIONS
;

• =O
A. REL:
A.DIS:
A.MAS:
A.NUM:

000000
000002
000004
000006
000007
000010
000012
000013

A.LIN:
A. ACC:
A.STA:

000014

A.LENl=.
• =A. LIN
A. IMAP:
A. IBUF:
A. ILEN:
A. SMAP:
A. SBUF:
A. SLEN:

000010
000012
000014
000016
000020
000022
000024
000030

A. RES:

000032

A.LEN2=.

A. IOS:

• BLKW
.BLKW
.BLKW
.BLKB
.BLKB
.BLKW
• BLKB
.BLKB

1
1
1
1
1
1
1
1

;ACD RELOCATION BIAS
;ACD DISPATCH TABLE POINTER
;ACD FUNCTION MASK
;ACD IDENTIFICATION NUMBER
;RESERVED
;ACD LINK WORD
;ACD ACCESS COUNT
;ACD STATUS BYTE
;LENGTH OF PROTOTYPE ACB

.BLKW
.BLKW
• BLKW
.BLKW
.BLKW
• BLKW
.BLKW
.BLKW

1
1
1
1

1
1
2
1

;FULL ACB OVERLAPS PROTOTYPE ACB
;ACD INTERRUPT BUFFER RELOCATION BIAS
;ACD INTERRUPT BUFFER ADDRESS
;ACD INTERRUPT BUFFER LENGTH
;ACD SYSTEM STATE BUFFER RELOCATION BIAS
;ACD SYSTEM STATE BUFFER ADDRESS
;ACD SYSTEM STATE BUFFER LENGTH
;ACD I/O STATUS
;RESERVED FOR USE BY THE ACD
;LENGTH OF FULL ACB

C-35

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

DEFINE THE FLAG VALUES IN THE OFFSET U.AFLG
;

UA.ACC=l
UA. PR0=2
UA. ECH=4
UA .. TYP=lO
UA. SPE=20
UA. PUT=40
UA. CAL=lOO
UA. COM=200
UA. ALL=4 00
UA. TRA=lOOO

;ACCEPT THIS CHARACTER
;PROCESS THIS CHARACTER
;ECHO THIS CHARACTER
;FORCE THIS CHARACTER INTO TYPEAHEAD
;THIS CHARACTER HAS A SPECIAL ECHO
;PUT THIS CHARACTER IN THE INPUT BUFFER
;CALL THE ACD BACK AFTER THE TRANSFER
;COMPLETE THE INPUT REQUEST
;ALLOW PROCESSING OF THIS I/O REQUEST
;TRANSFER CHARS. WHEN I/O COMPLETES

DEFINE THE ACD ENTRY POINTS (OFFSETS INTO THE DISPATCH TABLE)
;

000000
000002
000004
000006
000010
000012
000014
000016
000020
000022

• =O
A.ACCE:
A. DEQU:
A. POWE:
A. IN PU:
A. OUTP:
A. CONN :
A. DISC:
A. RECE:
A. PROC:
A. CALL:

.BLKW
• BLKW
• BLKW
• BLKW
• BLKW
• BL KW
• BLKW
• BLKW
• BLKW
• BLKW

1
1
1
1
1
1
1
1
1
1

;I/O REQUEST ACCEPTANCE ENTRY POINT
;I/O REQUEST DEQUEUE ENTRY POIN_T
;POWER FAILURE ENTRY POINT
;INPUT COMPLETION ENTRY POINT
;OUTPUT COMPLETION ENTRY POINT
;CONNECTION ENTRY POINT
;DISCONNECTION ENTRY POINT
;INPUT CHARACTER RECEPTION ENTRY POINT
;INPUT CHARACTER PROCESSING ENTRY POINT
;CALL ACD BACK AFTER TRANSFER ENTRY POINT

DEFINE THE STATUS BITS IN A.STA OF THE PROTOTYPE ACB
;

;ACD IS MARKED FOR DELETE
;ACD IS DISABLED

AS. DE L=l
AS. DIS=2
• PSECT

C-36

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

SCBDF$
SCBDF$

, , SYS DEF

STATUS CONTROL BLOCK
THE STATUS CONTROL BLOCK {SCB) DEFINES THE STATUS OF A DEVICE
CONTROLLER.
THERE IS ONE SCB FOR EACH CONTROLLER IN A SYSTEM.
THE SCB IS POINTED TO BY UNIT CONTROL BLOCKS. TO EXPAND ON THE
TELETYPE EXAMPLE ABOVE, EACH TELETYPE INTERFACED VIA A DLll-A
WOULD HAVE A SCB SINCE EACH DLll-A IS AN INDEPENDENT INTERFACE
UNIT.
THE TELETYPES INTERFACED VIA THE DHll WOULD ALSO EACH HAVE
AN SCB SINCE THE DHll IS A SINGLE CONTROLLER BUT MULTIPLEXES MANY
UNITS IN PARALLEL •

1 77772
177773
1 77774
1 77776
000000
000004
000005
000006
000007
000010
000011
000012
000014
000016
000020
000020
000022
000024

• ASECT
• =l 77772
S. RCNT: • BLKB
S. ROFF: ~ BLKB
S.BMSV: .BLKW
S.BMSK: .BLKW
S. LHD:
• BLKW
S • PR I :
• BL KB
S. VCT:
• BLKB
S • CTM :
• BL KB
S. ITM:
• BLKB
S • CON :
• BL KB
S.STS:
.BLKB
S.CSR:
.BLKW
S.PKT:
.BLKW
S.FRK:
.BLKW
S.DMCS:
• BLKW
• BLKW
.BLKW

1
1
1
2

1
1
1

1
1

1
1
1
1
1
1
1

;NUMBER OF REGISTERS TO COPY ON ERROR
;OFFSET TO FIRST DEVICE REGISTER
;SAVED I/O ACTIVE BITMAP AND POINTER TO EMB
;DEVICE I/O ACTIVE BIT MASK
;CONTROLLER I/O QUEUE LISTHEAD
;DEVICE PRIORITY
;INTERRUPT VECTOR ADDRESS /4
;CURRENT TIMEOUT COUNT
;INITIAL TIMEOUT COUNT
;CONTROLLER INDEX
;CONTROLLER STATUS {O=IDLE,l=BUSY)
;ADDRESS OF CONTROL STATUS REGISTER
;ADDRESS OF CURRENT I/O PACKET
; FORK BLOCK LINK WORD
;DMll-BB CSR FOR FDX TTDRV
;FORK-PC
;FORK-RS
; FORK-R 4

• IF NB

SYS DEF

.IF DF

L$$DRV & M$$MGE

.BLKW

.ENDC

;L$$DRV & M$$MGE

S.CCB:
S • MPR :

• BL KW
.BLKW
S. UMHD: • BLKW
S. UMCT: .BLKW

6
1
2

;FORK-DRIVER RELOCATION BASE

;MIXED MASSBUS CHANNEL CONTROL BLOCK
; 11/70 EXTENDED MEMORY UNIBUS DEVICE C-BLOCK
;BUFFER WORD
;LIST HEAD FOR UMR ASSIGNMENT BLOCK{S)
;COUNT OF AVAILABLE UMR ASSIGNMENT BLOCK{S)

.IFF
• PSECT

C-37

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

STATUS CONTROL BLOCK PRIORITY BYTE CONDITION CODE STATUS BIT
DEFINITIONS
;

SP. EIP=l
SP. ENB=2
SPe LOG=4
SPARE=lO

;ERROR IN PROGRESS (l=YES)
;ERROR LOGGING ENABLED (O=YES)
;ERROR LOGGING AVAILABLE {l=YES)
; SPARE BIT

MAPPING ASSIGNMENT BLOCK (FOR UNIBUS MAPPING REGISTER ASSIGNMENT)
• ASECT
000000
000002
000004
000006
000010
000011
000012

• =O
M. LNK:
M.UMRA:
M. UMRN:
M. UMVL:
M. UMVH:
M. BFVH:
M.BFVL:

000014

M. LGTH= •

.BLKW
.BLKW
.BLKW
.BLKW
.BLKB
• BLKB
.BLKW

1
1
1
1
1
1
1

;LINK WORD
;ADDRESS OF FIRST ASSIGNED UMR
;NUMBER OF UMR'S ASSIGNED * 4
;LOW 16 BITS MAPPED BY lST ASSIGNED UMR
;HIGH 2 BITS MAPPED IN BITS 4 AND 5
;HIGH 6 BITS OF PHYSICAL BUFFER ADDRESS
;LOW 16 BITS OF PHYSICAL BUFFER ADDRESS
;LENGTH OF MAPPING ASSIGNMENT BLOCK

• ENDC

;SYS DEF

• PSECT

C-38

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

TCBDF$
TCBDF$·

, , SYS DEF

TASK CONTROL BLOCK OFFSET AND STATUS DEFINITIONS
TASK CONTROL BLOCK
• ASECT
• =O
000000

000002
000003
000004
000006
000012
000016
000022
000026
000030
000032
000034
000036
000040
000041
000044
000046
000050
000052
000054
000056
000057
000060

T. LNK:
T. PRI:

.BLKW
.BLKB
.BLKB
T. IOC:
T. CPCB: • BLKW
T.NAM:
.BLKW
T. RCVL: .BLKW
T. ASTL: .·BLKW
T. EFLG: .BLKW
T. UCB:
.BLKW
T. TCBL: .BLKW
T.STAT: .BLKW
T.ST2:
.BLKW
T. ST3:
.BLKW
T. DPRI: .BLKB
T. LBN:
.BLKB
T. LDV:
• BLKW
T. PCB:
.BLKW
T .MXSZ: .BLKW
T.ACTL: .BLKW
T.SAST: .BLKW
• BLKB
T.TIO:
• BLKB
T. TKSZ: .BLKW

$$$=.
T.ATT:
T.OFF:

;UTILITY LINK WORD

;TASK PRIORITY

1
1
2

; I/O PENDING COUNT
;POINTER TO CHECKPOINT PCB
;TASK NAME IN RAD50
;RECEIVE QUEUE LISTHEAD
;AST QUEUE LISTHEAD
;TASK LOCAL EVENT FLAGS 1-32
;UCB ADDRESS FOR PSEUDO DEVICE 'TI'
;TASK LIST THREAD WORD
;FIRST STATUS WORD (BLOCKING BITS)
;SECOND STATUS WORD (STATE BITS)
;THIRD STATUS WORD (ATTRIBUTE BITS)
;TASK'S DEFAULT PRIORITY
;LBN OF TASK LOAD IMAGE
;UCB ADDRESS OF LOAD DEVICE
;PCB ADDRESS OF TASK PARTITION
;MAXIMUM SIZE OF TASK IMAGE (MAPPED ONLY)
;ADDRESS OF NEXT TASK IN ACTIVE LIST
;SPECIFIED AST LISTHEAD
;UNUSED BYTE
;BUFFERED I/O COUNT
;TASK SIZE (FROM L$BLDZ IN LABEL BLK) IN:
UNMAPPED SYSTEMS - BYTES
;
MAPPED SYSTEMS
- 32 WORD BLOCKS
;TASK SIZE (FROM L$BMXZ IN LABEL BLK)
;FOR RSXllS SYSTEMS ONLY
MAPPED SYSTEMS
- 32 WORD BLOCKS
UNMAPPED SYSTEMS - BYTES

2
2
1
1
1
1
1
1
3
1

1
1
1
1
1
1

.BLKW
.BLKW

.BLKB
T.SRCT: .BLKB
T. RRFL: • BLKW

1
1
2

;MARK START OF PLAS AREA
;ATTACHMENT DESCRIPTOR LISTHEAD
;OFFSET TO TASK IMAGE IN PARTITION
;IF A$$HDR IS DEFINED, THIS WORD ALSO
;INCLUDES THE LENGTH OF THE ALTERNATE
;HEADER REFRESH AREA STORED IN T.HDLN
;RESERVED
;SREF WITH EFN COUNT IN ALL RECEIVE QUEUES
;RECEIVE BY REFERENCE LISTHEAD

.IF NDF P$$LAS
.=$$$

;POINT TO START OF PLAS AREA
• ENDC

; P$$LAS

C-39

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
.IF NB SYS DEF
$$$=.
T.OCBH: .BLKW
T. RDCT: .BLKW

;MARK START OF PARENT OFFSPRING TASKING AREA
;OFFSPRING CONTROL BLOCK LISTHEAD
;OUTSTANDING OFFSPRING COUNT

2
1

.IF NDF P$$0FF
;POINT TO START OF PARENT OFFSPRING AREA

.=$$$
• ENDC
$$$=.
T. EFLM: .BLKW

;P$$0FF

.IF NDF S$$TOP
• ENDC

T$$BUF
; POINT TO START OF EVENT FLAG MASK AREA
;S$$TOP & T$$BUF

• BLKB

.=$$$

$$$=.
T.HDLN:

;MARK START OF EVENT FLAG MASK AREA
; EVENT FLAG MASK WORD
; EVENT FLAG MASK ADDRESS

2
&

;TASK HEADER LENGTH IN 32-WORD BLOCKS

.IF NDF A$$HDR
• =$$$

$$$=.
T.GGF:

;NOT SUPPORTED IF NDF
• ENDC

;A$$HDR

• BLKB

;GROUP GLOBAL USE COUNT FOR TASK

.IF NDF G$$EFN

R$$SND

• ENDC

R$$SND

.=$$$
;G$$EFN

• EVEN
T. LGTH=.
T. EXT=O

;LENGTH OF TASK CONTROL BLOCK
;LENGTH OF TCB EXTENSION
.IFF

TASK STATUS DEFINITIONS
FIRST STATUS WORD {BLOCKING BITS)
;

TS.EXE=lOOOOO
TS. RDN=4 0000
TS.MSG=20000
TS.NRP=lOOOO
TS • RUN =4 0 0 0
TS.HLD='.2000
TS.STP=lOOO
TS. OUT=4 00
TS.CKP=200
TS.CKR=lOO

;TASK NOT IN EXECUTION (l=YES)
; I/O RUN DOWN IN PROGRESS (l=YES}
;ABORT MESSAGE BEING OUTPUT (l=YES}
;TASK MAPPED TO NONRESIDENT PARTITION (l=YES)
;TASK IS RUNNING ON ANOTHER PROCESSOR (l=YES}
; TASK HALF-LOADED BY TASK LOADER
;TASK EXTERNALLY BLOCKED VIA CLI COMMAND
;TASK IS OUT OF MEMORY (l=YES}
;TASK IS BEING CHECKPOINTED (l=YES}
;TASK CHECKPOINT REQUESTED (l=YES)

C-40

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

TASK BLOCKING STATUS MASK
;

TS.BLK=TS.CKP!TS.CKR!TS.EXE!TS.MSG!TS.NRP!TS.OUT!TS.RDN!TS.STP

SECOND STATUS WORD (STATE BITS)
;

T2.AST=l00000
T2. DST=40000
T2. CHK=20000
T 2. CKD =10 0 0 0
T2.SEF=4000
T2. FXD=2000
T2.REX=l000
T2. CAF=4 00
T2. HLT=200
T2. ABO=lOO
T2. STP=40
T2.STP=20
T2. SPN=lO
T2. SPN=4
T2.WFR=2
T2. WFR=l

;AST IN PROGRESS (l=YES)
;AST RECOGNITION DISABLED {l=YES)
;TASK NOT CHECKPOINTABLE (l=YES)
;CHECKPOINTING DISABLED (l=YES)
;TASK STOPPED FOR EVENT FLAGS {l=YES)
;TASK FIXED IN MEMORY (l=YES}
;ABORT AST EFFECTED OR IN PROGRESS (l=YES)
;DYN CHECKPOINT SPACE ALLOCATION FAILURE
;TASK IS BEING HALTED {l=YES)
;TASK MARKED FOR ABORT (l=YES)
; SAVED T 2. STP ON AST IN PROGRESS
;TASK STOPPED {l=YES)
; SA VE D T 2. SPN ON AST IN PROGRESS
;TASK SUSPENDED (l=YES)
;SAVED T2.WFR ON AST IN PROGRESS
;TASK IN WAITFOR STATE (l=YES)

THIRD STATUS WORD (ATTRIBUTE BITS)
;

T 3·. ACP=l 00000
T3. PMD=40000
T 3. REM=20000
T3.PRV=l0000
T3.MCR=4000
T3.SLV=2000
T3. CLI=lOOO
T3. RST=400
T 3. NSD=200
T3.CAL=l00
T3.ROV=40
T3.NET=20
T3.GFL=l0
;
=4
T3. SWS=2
=l
• ENDC

;ANCILLARY CONTROL PROCESSOR {l=YES)
;DUMP TASK ON SYNCHRONOUS ABORT (O=YES)
;REMOVE TASK ON EXIT {l=YES)
;TASK IS PRIVILEGED (l=YES)
;TASK REQUESTED AS EXTERNAL MCR FUNCTION(l=YES)
;TASK IS A SLAVE TASK (l=YES)
;TASK IS A COMMAND LINE INTERPRETER {l=YES)
;TASK IS RESTRICTED (l=YES)
;TASK DOES NOT ALLOW SEND DATA
;TASK HAS CHECKPOINT SPACE IN TASK IMAGE
;TASK HAS RESIDENT OVERLAYS
;NETWORK PROTOCOL LEVEL
;TASK HAS ITS GRP GBL EVENT FLAGS LOCKED
; RESERVED FOR FUTURE USE
;RESERVED FOR USE BY SOF'IWARE SERVICES
;RESERVED FOR FUTURE USE
;SYS DEF

• PSECT

C-41

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

UCBDF$
UCBDF$

,,TTDEF,SYSDEF

UNIT CONTROL BLOCK
THE UNIT CONTROL BLOCK (UCB) DEFINES THE STATUS OF AN INDIVIDUAL
DEVICE UNIT AND IS THE CONTROL BLOCK THAT IS POINTED TO BY THE
FIRST WORD OF AN ASSIGNED LUN. THERE IS ONE UCB FOR EACH DEVICE
UNIT OF EACH DCB. THE UCB'S ASSOCIATED WITH A PARTICULAR DCB ARE
CONTIGUOUS IN MEMORY AND ARE POINTED TO BY THE DCB. UCB'S ARE
VARIABLE LENGTH BETWEEN DCB'S BUT ARE OF THE SAME LENGTH FOR A
SPECIFIC DCB. TO FINISH THE TELETYPE EXAMPLE ABOVE, EACH UNIT ON
BOTH INTERFACES WOULD HAVE A UCB •
• ASECT
• IF NB

SYS DEF

• IF DF

E$$DVC

.IF DF

M$$MUP

;IS U.OWN THERE?

.=177766
.IFF
• =l 77770
U• I QC :
U. ERSL:
U. ERHL:
U. ERSC:
U. ERHC:

1 77772
1 77772
1 77774
177776
000000
000002
000004
000005
000006
000007
000010
000012
000014
000016
000020
000022
000024
000026
000030

• ENDC

;M$$MUP

• BL KW
• BLKB
• BLKB
• BLKB
• BLKB

2
1
1
1
1

• ENDC

; E $$DVC

• ENDC

; SYS DEF

• =l 77772
U .MUP:
U. CLI:
.BLKW
U.LUIC: .BLKW
U.OWN:
.BLKW
U. DCB:
.BLKW
U. RED:
.BLKW
U. CTL:
.BLKB
U.STS:
.BLKB
U. UNIT: .BLKB
U .. ST2:
.BLKB
U.CWl:
.BLKW
U.CW2:
.BLKW
U.CW3:
.BLKW
U.CW4:
.BLKW
U.SCB:
.BLKW
U.ATT:
.BLKW
U.BUF:
.BLKW
.BLKW
U.CNT:
.BLKW

1
1
1
1
1
1
1

1
1
1
1
1
1

1
1
1
l

;I/O COUNT SINCE MOUNT
;SOFT ERROR LIMIT
;HARD ERROR LIMIT
;SOFT ERROR COUNT
; HARD ERROR COUNT

(ERROR LOG DEVS ONLY)

;MULTIUSER PROTECTION FLAG WORD
;TCB OF COMMAND LINE INTERPRETER
;LOGIN UIC - MULTI USER SYSTEMS ONLY
;OWNING TERMINAL - MULTI USER SYSTEMS ONLY
;BACK POINTER TO DCB
;POINTER TO REDIRECT UNIT UCB
;CONTROL PROCESSING FLAGS
;UNIT STATUS
;PHYSICAL UNIT NUMBER
;UNIT STATUS EXTENSION
;FIRST DEVICE CHARACTERISTICS WORD
;SECOND DEVICE CHARACTERISTICS WORD
;THIRD DEVICE CHARACTERISTICS WORD
;FOURTH DEVICE CHARACTERISTICS WORD
; POINTER TO SCB
;TCB ADDRESS OF ATTACHED TASK
;RELOCATION BIAS OF CURRENT I/O REQUEST
;BUFFER ADDRESS OF CURRENT I/O REQUEST
;BYTE COUNT OF CURRENT I/O REQUEST

C-42

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
000032
000034
000032
000032
000034

U. ACP=U. CNT+2
U. VCB=U .CNT+4
U. CBF=U. CNT+2
U. KCSR=U. CNT+2
U. KCS6=U. KCSR+2

000036
000036
000040
000042

MAGTAPE DRIVER DEFINITIONS
;
; SPACING COUNT
U. SPC=U .CNT+6
U. SUB=U .CNT+6
;SUBCONTROLLER, PHYSICAL UNIT
U. FNUM=U. CNT+l 0
;FORMATTER NUMBER
U. FCDE =U. CNT+l 2
;FUNCTION CODE AND INDEX

000036
000040
000044

MSCP DISK DRIVER UCB OFFSETS
;
;UNIT COMMAND TIME OUT
U. UTMO=U. VCB+2
U. LHD=U. VCB+4
;UNIT OUTSTANDING I/O PACKET LISTHEAD
U. BPKT=U. VCB+l 0
;UNIT BAD BLOCK PACKET WAITING LIST

000050
000052
000054
000060
000070
000074
000076
000100
000102
000104
000110
000112
000113

CHARACTERISTICS OBTAINED FROM "GET UNIT STATUS"
;
U. MLUN=U. VCB+l 4
;MULTI-UNIT CODE
U. UNFL=U. VCB+l6
; UNIT FLAGS
U. HSTI=U. VCB+2 0
; HOST IDENTIFIER
U. UNTI=U. VCB+24
;UNIT IDENTIFIER
U. MEDI=U. VCB+34
;MEDIA IDENTIFIER
U. SHUN=U. VCB+40
; SHADOW UNIT
; SHADOW UN IT STATUS
U. SHST=U. VCB+42
U. TRCK=U. VCB+44
; UN IT TRACK SIZE
U. GRP=U. VCB+46
;UNIT GROUP SIZE
U. CYL=U. VCB+5 0
;UNIT CYLINDER SIZE
U. RCTS=U. VCB+54
;UNIT RCT TABLE SIZE
U. RBNS=U. VCB+56
;UNIT RBN 'S / TRACK
U.RCTC=U. VCB+57
;UNIT RCT COPIES

;ADDRESS OF TCB OF MOUNTED ACP
;ADDRESS OF VOLUME CONTROL BLOCK
;CONTROL BUFFER RELOCATION AND ADDRESS
;CSR ADDRESS OF KMC-11
;CSR+6 OF KMC-11

CHARACTERISTICS OBTAINED FROM "ONLINE"
END PACKETS
000114
000120

000024
000026
000034

;
U.UNSZ=U.VCB+60
U.VSER=U.VCB+64

END PACKETS

OR "SET UNIT CHARACTERISTICS"

; UNIT SIZE
; VOLUME SERIAL NUMBER

TERMINAL DRIVER DEFINITIONS
;
• =U. BUF
U. TUX:
.BLKW
1
;POINTER TO UCB EXTENSION (UCBX)
U.TSTA: .BLKW
3
; STATUS TRIPLE-WORD
U.TTAB: .BLKW
1
;IF 0: U.TTAB+l IS SINGLE-CHARACTER TYPE-AHEAD
;
BUFFER, CURRENTLY EMPTY
;IF ODD: U.TTAB+l IS SINGLE-CHARACTER
TYPE-AHEAD BUFFER AND HOLDS A
;
CHARACTER
; IF NON-0 AND EVEN: POINTER TO MULTI-CHARACTER
TYPE-AHEAD BUFFER

C-43

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

000036
000037
000040
000042
000043
000044
000046
000047
000050
000052
000054
000056

U.TLPP:
U. TFRQ:
U. TFLK:
U.TCHP:
U. TCVP:
U.UIC:
U. TTYP:
U.TMTI:
U.CTYP:
U.ACB:
U.AFLG:
U. ADMA:

.BLKB
.BLKB
.BLKW
.BLKB
.BLKB
.BLKW
.BLKB
.BLKB
.BLKW
.BLKW
.BLKW
.BLKW

1
1
1
1
1
1
1

1
1
1
1
1

; LINES PER PAGE
;FORK REQUEST BYTE
;FORK LIST LINK WORD
;CURRENT HORIZONTAL POSITION
;CURRENT VERTICAL POSITION
;TERMINAL UIC
;TERMINAL TYPE
;MODEM TIMER
;CONTROLLER TYPE
;ANCILLARY CONTROL DRIVER BLOCK ADDR
;ANCILLARY CONTROL DRIVER FLAGS WORD
;ANCILLARY CONTROL DRIVER DMA BUFFER

CONSOLE DRIVER DEFINITIONS
;

000030
000032
000036

• =U .CNT
U.CTCB: .BLKW
U. COTQ: .BLKW
U. RED2: .BLKW

1
2
1

;ADDRESS OF CONSOLE LOGGER TCB
;I/0 PACKET LIST QUEUE
;REDIRECT UCB ADDRESS

DEFINE BITS IN STATUS WORD 1 (U.TSTA)
;

Sl. RST=l
Sl. RUB=2
Sl. ESC=4
Sl.RAL=lO
Sl. RNE=20
Sl. CT0=40
Sl. OBY=lOO
Sl.IBY=200
Sl.BEL=400
S 1 • DPR= 10 0 0
Sl. DEC=2000
S 1. DS I =4 0 0 0
S 1. CTS=l 0000
Sl. USI=20000
S 1. OBF=4 0000
Sl. IBF=lOOOOO

;READ WITH SPECIAL TERMINATORS IN PROGRESS
; RUBOUT SEQUENCE IN PROGRESS {NON-SCOPE)
;ESCAPE SEQUENCE IN PROGRESS
; READ ALL IN PROGRESS
;ECHO SUPPRESSED
; OUTPUT STOPPED BY CTRL-0
; OUTPUT BUSY
; INPUT BUSY
; BELL PENDING
;DEFER PROCESSING OF CHAR. IN U.TECB
;DEFER ECHO OF CHAR. IN U.TECB
; INPUT PROCESSING DISABLED
; OUTPUT STOPPED BY CTRL-S
;UNSOLICITED INPUT IN PROGRESS
;BIT 14 RESERVED FOR NON-BUFFERED OUTPUT
;BUFFERED OUTPUT IN PROGRESS
; BUFFERED INPUT IN PROGRESS

DEFINE BITS IN STATUS WORD 2 {U.TSTA+2)
;

S 2. ACR=l
S2.WRA=6
S 2. WRB=2
S 2. CR=lO
S2.BRQ=20
S 2. SRQ=4 0
S2.0RQ=l00
S2. IRQ=200
S2. HFL=3400
S2. VFL=4000
S2.HHT=l0000
S2.HFF=20000
S 2. FLF=4 0000
S2.FDX=l00000

;WRAP-AROUND {AUTOMATIC' CR-LF) REQUIRED
;CONTEXT FOR WRAP-AROUND
;LOW BIT IN S2.WRA BIT PATTERN
;TRAILING CR REQUIRED ON OUTPUT
; BREAK-THROUGH-WRITE REQUEST IN QUEUE
;SPECIAL REQUEST IN QUEUE
; (IO.ATT, IO.DET, SF.SMC)
;OUTPUT REQUEST IN QUEUE {MUST= Sl.OBY)
;INPUT REQUEST IN QUEUE (MUST = Sl.IBY)
;HORIZONTAL FILL REQUIREMENT
;VERTICAL FILL REQUIREMENT
;HARDWARE HORIZONTAL TAB PRESENT
;HARDWARE FORM-FEED PRESENT
;FORCE LINE FEED BEFORE NEXT ECHO
;LINE IS IN FULL DUPLEX MODE

C-44

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

DEFINE BITS IN STATUS WORD 3 (U.TSTA+4)
i

S 3. RAL=l 0
S 3. RP0=20
S3.WES=40
S3.TAB=l00
S3. 8BC=200
S3. RCU=400
S3.ABD=l000
S 3. ABP=2 000
S3.WAL=4000
S3. VER=lOOOO
S3.BCC=20000
S3. DA0=40000

S3. PCU=lOOOOO

;TERMINAL IS IN READ-PASS-ALL MODE
; (S3.RAL MUST = Sl.RAL)
;READ W/PROMPT OUTPUT IN PROGRESS
;TASK WANTS ESCAPE SEQUENCES
;TYPE-AHEAD BUFFER ALLOCATION REQUESTED
;PASS 8 BITS ON INPUT
;RESTORE CURSOR (MUST = TF.RCU*400)
;AUTO-BAUD SPEED DETECTION ENABLED
; AUTO-BAUD SPEED DETECTION IN PROGRESS
;WRITE-PASS-ALL (MUST = TF.WAL*400)
; LAST CHAR. IN TYPE-AHEAD BUFFER
;HAS PARITY ERROR
;LAST CHAR. IN TYPE-AHEAD BUFFER
;HAS FRAMING ERROR
; LAST CHAR. IN TYPE-AHEAD BUFFER
;HAS DATA OVERRUN ERROR
;NOTE - THE 3 BITS ABOVE MUST CORRESPOND
;TO THE RESPECTIVE ERROR FLAGS IN THE
;HARI:WARE RECEIVE BUFFER
;POSITION CURSOR {MUST = TF.PCU*400)

• PSECT
DEVICE TABLE STATUS DEFINITIONS
DEVICE CHARACTERISTICS WORD 1 (U.CWl) DEVICE TYPE DEFINITION BITS.
;

DV. REC=l
DV. CCL=2
DV. TTY=4
DV. DIR=lO
DV. SDI=20
DV. SQD=40
DV. MSD=l 00
DV. UMD=200
DV.MBC=400
DV. EXT=400
DV.SWL=lOOO
DV. ISP=2000
DV. OSP=4000
DV. PSE=lOOOO
DV. COM=20000
DV. Fll=40000
DV. MNT= 1 0 0 0 0 0

;RECORD ORIENTED DEVICE (l=YES)
;CARRIAGE CONTROL DEVICE (l=YES)
;TERMINAL DEVICE (l=YES)
;FILE STRUCTURED DEVICE (l=YES)
;SINGLE DIRECTORY DEVICE (l=YES)
;SEQUENTIAL DEVICE (l=YES)
;MASS STORAGE DEVICE {l=YES)
;USER MODE DIAGNOSTICS SUPPORTED (l=YES)
;DEVICE IS ON MASSBUS CONTROLLER (l=YES)
;DEVICE ON EXTENDED ADDRESSING CONTROLLER
;UNIT SOF'IWARE WRITE LOCKED (l=YES)
;INPUT SPOOLED DEVICE {l=YES)
; OUTPUT SPOOLED DEVICE {l=YES)
;PSEUDO DEVICE {l=YES)
;DEVICE IS MOUNTABLE AS COM CHANNEL (l=YES)
;DEVICE IS MOUNTABLE AS Fll DEVICE (l=YES)
;DEVICE IS MOUNTABLE (l=YES)

TERMINAL DEPENDENT CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS
i

U2. DH 1=1 0 0 0 0 0
U2. DJ1=4 0000
U2. RMT=20000
U2. HFF=l 0000
U2. L8S=l0000
U2. NEC=4000
U2.CRT=2000

U2.ESC=l000
U2. LOG=400
U2. SLV=200
U2.DZ1=100

;UNIT IS A MULTIPLEXER (l=YES)
;UNIT IS A DJll {l=YES)
;UNIT IS REMOTE (l=YES)
;UNIT HANDLES HARDWARE FORM FEEDS {l=YES)
;OLD NAME FOR U2.HFF
;DON'T ECHO SOLICITED INPUT (l=YES)
;UNIT IS A CRT (l=YES)
;UNIT GENERATES ESCAPE SEQUENCES (l=YES)
;USER LOGGED ON TERMINAL (O=YES)
;UNIT IS A SLAVE TERMINAL (l=YES)
;UNIT IS A DZll (l=YES)

C-45

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS
U2.HLD=40
U2.AT. =20
U2.PRV=l0
U 2. L3S=4
U 2. SCS=4
U2.VT5=2
U2. LWC=l

;TERMINAL IS IN HOLD SCREEN MODE (l=YES)
;MCR COMMAND AT. BEING PROCESSED (l=YES)
;UNIT IS A PRIVILEGED TERMINAL (l=YES)
;UNIT IS A LA30S TERMINAL (l=YES)
;SCS-11 COMMAND TERMINAL (l=YES)
;UNIT IS A VTOSB TERMINAL (l=YES)
;LOWER CASE TO UPPER CASE CONVERSION (O=YES)

BIT DEFINITIONS FOR U.MUP (SYSTEMS WITH ALTERNATE CL! SUPPORT ONLY)
;

UM. OVR=l
UM.CLI=36
UM. DSB=200
UM.NBR=400

;OVERRIDE CL! INDICATOR
;CL! INDICATOR BITS
;TERMINAL DISABLED SINCE CL! ELIMINATED
; NO BROADCAST

RH11-RS03/RS04 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS
;

U 2. R04=100000

;UNIT IS A RS04

(l=YES)

RH11-TU16 CHARACTERISTICS WORD 2 (U.CW2) BIT DEFINITIONS
;

U 2. 7CH=l0000

;UNIT IS A 7 CHANNEL DRIVE {l=YES)

TERMINAL DEPENDENT CHARACTERISTICS WORD 3 (U.CW3) BIT DEFINITIONS
;

U 3. UPC=20000

;UPCASE OUTPUT FLAG

UNIT CONTROL PROCESSING FLAG DEFINITIONS
;

UC.ALG=200
UC. NPR=l 00
UC.QUE=40
UC. PWF=20
UC.ATT=lO
UC. KIL=4
UC.LGH=3

;BYTE ALIGNMENT ALLOWED (l=NO)
;DEVICE IS AN NPR DEVICE (l=YES)
;CALL DRIVER BEFORE QUEUING (l=YES)
;CALL DRIVER AT POWERFAIL ALWAYS (l=YES)
;CALL DRIVER ON ATTACH/DETACH {l=YES)
;CALL DRIVER AT I/O KILL ALWAYS (l=YES)
;TRANSFER LENGTH MASK BITS

UNIT STATUS BIT DEFINITIONS
;

US.BSY=200
US.MNT=lOO
US.FOR=40
US.MDM=20
US.PWF=lO

;UNIT IS BUSY (l=YES)
;UNIT IS MOUNTED (O=YES)
;UNIT IS MOUNTED AS FOREIGN VOLUME (l=YES)
;UNIT IS MARKED FOR DISMOUNT (l=YES)
;POWERFAIL OCCURRED (l=YES)

CARD READER DEPENDENT UNIT STATUS BIT DEFINITIONS
;

US.ABO=l
US.MDE=2

;UNIT IS MARKED FOR ABORT IF NOT READY {l=YES)
;UNIT IS IN 029 TRANSLATION NODE (l=YES)

C-46

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

FILES-11 DEPENDENT UNIT STATUS BITS
;

US.WCK=lO
US. SPU=2
US.VV=l

;WRITE CHECK ENABLED (l=YES)
;UNIT IS SPINNING UP (l=YES)
;VOLUME VALID IS SET (l=YES)

KMC-11-LP DEPDENDENT UNIT STATUS BITS
;

US. KPF=l

;KMC-11 POWERFAIL INTERLOCK

TERMINAL DEPENDENT UNIT STATUS BIT DEFINITIONS
• IF NB

TTDEF

• IF DF T$$CPW
US. CRW=4
US.DSB=2
US. OIU=l

;UNIT IS WAITING FOR CARRIER (l=YES)
;UNIT IS DISABLED (l=YES)
;OUTPUT INTERRUPT IS UNEXPECTED ON UNIT (l=YES)
.IFF

;T$$CPW

US. DSB=l 0
US. CRW=4
US. ECH=2
US. OUT=l

;UNIT IS DISABLED (l=YES)
;UNIT IS WAITING FOR CARRIER (l=YES)
;UNIT HAS ECHO IN PROGRESS (l=YES)
;UNIT IS EXPECTING OUTPUT INTERRUPT (l=YES)

• ENDC

;T$$CPW

.ENDC

;TT DEF

LPSll DEPENDENT UNIT STATUS BIT DEFINITIONS
;

US.FRK=2
US.SHR=l

;FORK IN PROGRESS (l=YES)
;SHAREABLE FUNCTION IN PROGRESS (O=YES)

MAGTAPE DEPENDANT UNIT STATUS BITS
;

US. LAB=4
US.BSP=2

;UNIT HAS LABELED TAPE ON IT (l=YES)
;INTERNAL BACKSPACE IN PROGRESS (l=YES)

C-47

SYSTEM DATA STRUCTURES AND SYMBOLIC OFFSETS

UNIT STATUS EXTENSION (U.ST2) BIT DEFINITIONS
;

US. OFL=l
US. RED=2
US. PUB=4
US. UMD=lO

;UNIT
;UNIT
; UN IT
;UNIT

OFFLINE (l=YES)
REDIRECTABLE (O=YES)
IS PUBLIC DEVICE ( 1 =YES)
ATTACHED FOR DIAGNOSTICS (l=YES)

MAG TAPE DENS SUPPORT IDENT IN CHAR WORD 3 (U.CW3) DEFENITION
ASSIGNMENTS PER NUMERICAL SEQUENCE 0 - 255.
;

UD. UNS=O
UD.200=1
UD.556=2
UD.800=3
UD. 160=4
UD.625=5

; UNSUPPORTED
; 200BPI, 7 TRACK
; 556BPI, 7 TRACK
; 800BPI, 7 OR 9 TRACK
;1600BPI, 9 TRACK
; 62 SOB PI, 9 TRACK

C-48

APPENDIX D
USER-WRITTEN ANCILLARY CONTROL PROCESSORS

This chapter is intended as a guide for
the user
in developing an
Ancillary Control Processor {ACP).
It is not a tutorial and it is not
a description of the logic of any DIGITAL-supplied ACP.
You should be
thoroughly familiar with the RSX-llM Guide to Writing an I/O Driver.
This chapter provides the following information:

D.l

•

An overview of the RSX-llM I/O system

•

Descriptions of the types of ACPs

•

The attributes of an ACP

•

A description of the
flow of
emphasizing the role of the ACP

•

System data structures used by the ACPs

•

Examples of an ACP and an I/O driver

input/output

request,

OVERVIEW OF THE RSX-llM I/O SYSTEM

An Ancillary Control Processor {ACP) is one component of the
system.
The other major components are
•

File Control Services
{RMS)

(FCS)

Record

•

QIO$ directive processing in the Executive

•

Device drivers

Management

RSX

I/O

Services

Figure D-1 shows how an ACP fits into the overall structure.
The philosophy and structure of the RSX-llM I/O system are described
in detail
in Chapter 2 of this manual.
QIO$ directive processing is
described in the RSX-llM/M-PLUS Executive Reference Manual.

D-1

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

User Task

-tFCS

Executive

r
I
I

ACP

Device Driver

Device

ZK-227-81

Figure D-1

D.2

The RSX-llM I/O System

TYPES OF ANCILLARY CONTROL PROCESSORS

An Ancillary Control processor (ACP) is a task that provides extended
functions
(complex operations requiring either multiple I/O requests
or special privileged operations) for a class of I/O devices.
ACPs may be divided into three types:
•

Those that manage file structures, such as FllACP and MTAACP

•

Those that manage intertask or interprocessor
such as the network ACP (NETACP)

•

Those that perform special privileged operations on behalf
nonprivileged user tasks.

D-2

communication,
of

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
Some of the purposes of a user-written ACP are:

• To implement a foreign file system
• To extend the ca pa b il it i es o f a DIGITAL-supplied device driver
• To extend the services of the operating system
• To implement a communications protocol
User-written ACPs extend functionality, not performance.
If your
application is performance-oriented, you should consider writing a
special driver rather than an ACP.

D.2.1

ACPs Which Manage Files Structures

DIGITAL supplies FllACP for Files-11 disk structure and MTAACP for
ANSI magnetic tapes. You may write an ACP to implement a foreign file
system or tape format.
Changes to the Executive, the I/O driver, or
the data structures are not necessary if there are DIGITAL-supplied
I/O operations that correspond to operations for the foreign format.
The user-written ACP can use the built-in Executive Services (such as
QIO$ directive processing) without change.
Note that a user-written ACP is necessary only to support a file
structure other than Files-11.
To use the Files-11 structure with a
foreign device, you need to write a device driver, and you may need to
modify or extend disk initialization, management, or backup utilities.

D.2.2

ACPs Which Manage Intertask or Interprocessor Communication

DECnet/M and DECnet/M-PLUS both contain an example of an ACP that
manages interprocessor communications: NETACP, used for management of
the Digital Network Architecture Com~unications protocol.
You may
write an ACP to manage a foreign communications protocol.

D.2.3

ACPs Which Perform Privileged Operations for Unprivileged Tasks

You may write an ACP to support extended capabilities for a class of
devices
(such as line printer spooling or associative name searching
for data base devices).
This requires special support in the
Executive I/O processing,
in the I/O driver, and in the associated
data structures. This type of ACP requires a user-written I/O driver
that contains special code to support the ACP.
An ACP may use the I/O driver interface to extend the services of the
operating system
(as in the case of a data base management system),
rather than to extend the services of an I/O device.
RSX-llM contains no DIGITAL-supplied examples of the. types just
described.
Both RSX-llM and RSX-llM-PLUS, however, contain COT and
CODRV, which are used to perform console logging.
The COT task
behaves in the fashion of an ACP, in that it receives I/O packets in
its queue from user tasks.
COT is not declared to the system as an
ACP,
though;
it has no VCB or MOU interface. COT is enabled and
disabled using MCR commands.

D-3

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

D.3

THE ATTRIBUTES OF AN ACP

The classes of ACPs described above have the following
common, which further define an ACP:
An ACP is an asynchronous privileged
• RSX-llM/M-PLUS
Task Builder Manual

task.
for a
privileged task mapping and Executive access.

attributes

Refer to the
discussion of

•

An ACP implements a protocol (or set of services) for a class
of devices (for example, file-structured devices or sequential
devices) •

•

An ACP can be enabled or disabled for a particular device.

•

An ACP is shareable among several device drivers and units.

D.3.1

ACP functions as an extension of the
frequently operates with Executive privilege.

Executive

and

ACP as a Task

An ACP is a task.

It has all the attributes of a task, including:

•

A stack

•

A task name

•

Priority

•

Scheduling by the Executive

An ACP, in contrast to a driver, operates as a task. While a driver
handles
interrupts,
manipulates
CSRs,
and
performs
other
device-specific operations, an ACP is not device bound and can take
advantage of the services and control mechanisms available to tasks.
ACPs can also use overlays, and can therefore be larger and have
greater functionality than drivers.
Because the ACP task is privileged, it has access
data structures and can use Executive facilities.

the

Executive

Unlike other privileged tasks, an ACP has the capacity to receive I/O
packets from other tasks by means of the QIO$ directive. This permits
the ACP to act as an I/O handler, which can compete with user tasks
for system resources more equitably than an I/O driver could. Also,
unlike an I/O driver, an ACP can perform I/O to other devices during
the processing of an I/O request.

D.3.2

Class of Devices

An ACP can easily implement functions for a class of devices because
it
communicates
via
the QIO$ directive, which is relatively
device-independent.
(Drivers, in contrast, are written to suit the
minute peculiarities of particular devices.)
FllACP, for example,
implements the Files-11 structure for all types of disks and DECtapes.
MTAACP implements ANSI magnetic tape format for all DIGITAL-supported
9-track magnetic tape drives.

D-4

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

Extension of Executive

D.3.3

An ACP extends the functionality of both the Executive and the
drivers in several ways:

device

•

By removing the burden of device managment (assigning space on
a volume, locating the desired data area, and so on) from the
programmer.

•

By handling the manipulation of devicedata.

•

By permitting a device to be treated as a logical rather
a physical entity.

•

By allowing a device to be shared for simultaneous access.
Each process that accesses a device is protected from other
processes by the ACP and its protocol.
The ACP
also
synchronizes access to the physical device.

and

protocol-related
than

Enabling Capability and Disabling Capability

D.3.4

An ACP can be enabled or disabled for a given device.
When enabled,
the device is available for use in the context of the protocol
provided by the ACP.

Shareability

D.3.5

An ACP is shareable among several device drivers and units.

D.4

THE FLOW OF AN I/O REQUEST

This section describes the system interactions of an ACP during the
flow of an I/O request. On the assumption that you have read Section
2.6 of this manual, only those items relevant to ACPs are treated in
detail.
The structure of this section is similar to that of Section
2.6.
The I/O flow proceeds as described below:
1.

[Task issues a QIO$ directive]
The Executive performs the following:
a.

First-level validity checks

Redirect algorithm

Additional validity checks

[Executive obtains storage for and creates I/O packet]

[Executive validates the function requested]
If the function is an ACP function, the
validation depends on the type of ACP.

D-5

type

function

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

Standard DIGITAL-supplied ACP
If the device is mounted with an ACP, the function
code is validated to determine that it is an ACP
function.
The parameters are verified by code in the
QIO processing module.
The request is checked for
proper order (for example, OPEN before CLOSE) and for
valid buffers. The task that issues the I/O request
must validate any additional parameter block required
by the ACP.
For some functions,
an additional
parameter buffer is allocated and filled in.
Sometimes the I/O request can be transformed
into a
transfer function and queued to the proper driver.
If the request cannot be queued to the driver or
cannot be completed immediately, it is queued to the
ACP.
The request packet is inserted in the ACP's
receive data queue and the ACP is unstopped or
requested to run
(depending on whether it
was
active).

Nonstandard ACPs and ACPs requiring special Executive
or driver support
The QIO$ directive processing cannot validate the ACP
function request parameters.
The I/O driver must do
the validation. The UC.QUE bit in the driver must be
set so that the QIO processing routine calls the
driver directly, without queuing the I/O packet to
the driver or to the ACP.
The driver must perform the same functions for the
ACP as the QIO processing code does for standard and
replacement ACPs.

[Driver processing]
If the driver calls $GTPKT and the next request in the queue
is an ACP function request, $GTPKT will queue the request to
the ACP and activate the ACP.

[ACP processing]
Obtain Work
As soon as the ACP is activated, it attempts to remove an I/O
request packet from its receive data queue.
To do this, the
ACP switches to system state and calls $QRMVF to obtain the
address of the I/O packet.
(Note that the ACP does not use
the RCVD$ directive to remove the packet from its receive
queue.)
When the ACP has obtained the address of the I/O
packet, it returns to task state.
Process I/O Request
The ACP either completes the I/O request or translates it
into a standard I/O driver request.
The decision is based
on:
•

Information in the data structures

•

Computation

•

Additional I/O

D-6

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
The ACP may do its own QIO requests to the driver; the ACP then
calls
$IOFIN
with
the
I/O packet and the I/O status.
Alternatively, when the I/O request is translated into a driver
request, the ACP modifies the I/O packet to put it into the
correct form for a driver request and passes it to the driver by
calling $DRQRQ.
If the I/O request has been completed, the ACP
calls $IOFIN with the I/O packet and the I/O status.
For example, MTAACP always deals with the driver through
requests, and finishes I/O itself by calling $IOFIN.

QIO

The ACP then attempts to remove another request from its queue.
If there are no more requests in the queue, the ACP stops itself
by calling $STPCT.

D.5

SYSTEM DATA STRUCTURES

An ACP interfaces to the system through use of system data structures
and through calls to Executive routines.
This section describes
ACP-specific information for the various data structures.
Detailed
information on the data structures and their interrelationships is
contained in Section 2.7 and Chapter 4 of this manual.
The following data
processing:

structures

comprise

the

complete

•

Task header

•

Window Block (WB)

•

File Control Block (FCB)

•

$DEVHD word, the Device Control Block (DCB),
Dispatch Table (DDT)

•

Unit Control Block (UCB)

•

Status Control Block (SCB)

•

Volume Control Block (VCB)

•

I/O packet

and

set

the

for

I/O

Driver

When you write an ACP, you are usually concerned only with the I/O
packet, the DCB, the UCB, and the SCB.
There are ACP-specific
additions to and variations in the I/O packet, the DCB, and the UCB.
The SCB is the same as that for an I/O driver.

D.5.1

The I/O Packet

Figure D-2 shows the layout of the 18-word I/O packet, which is
constructed by QIO$ directive processing.
The fields in the I/O
packet are described in detail in Section 4.1.1 of this manual.
The
following additions and variations exist for ACPs:
I.FCN
Contains the function code for the I/O request.
The function
code and modifier comprise a 16-bit field. Bits 13,14, and 15
are reserved for ACP interface use. You must not assume that
these bits are zero.

D-7

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
If the function code field is referenced,
masked with 160000(8) for example:
MOV
BIC

I.FCN(Rl) ,RO
U60000,RO

the

value

should

GET FUNCTION CODE FIELD
CLEAR OFF EXTRANEOUS BITS

Although these bits are not currently in use, they should not be
assumed to be zero in order to ensure future compatibility.
If
an I/O packet is requeued to the device driver, these bits must
be cleared.
I.PRM
Contains the device-dependent
last six words in the DPB.
The following
operations:

fields

• ASECT
• =I. PRM
I.FIDP: .BLKW

I. RWAT: • BLKW

I.EXTD:
I. RTRV:
I.ACTL:
I. FNBP:

2
1
1
2

.BLKW
• BLKB
.BLKB
• BLKW

are

parameters
defined

for

constructed
Files-11

from

the

nontransfer

File ID address (Add,ress double
word format)
Attribute block pointer (This field
points to a buffer containing the
attribute list and associated address
doublewords)
Extend control from parameter list
Retrieval pointers desired
Access control
File name block pointer

The following fields are defined for Files-11 transfer operations:
• ASECT
• =I. PRM
I. RWAD: • BLKW
I. RWCT: .BLKW
.BLKW
I. RWVB
.BLKW
.BLKW
I. LCKB: .BLKW

2
1
1
1
1
1

Transfer address doubleword
Transfer count
Unused
Virtual block number
Unused
Address of lock block

The above fields are set up by routines in the Executive.
Only I.LCKB is referenced by $IOFIN;
greater than 140000.

D-8

must

either

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

l.LNK

Link to next 110 packet

EFN

1.EFN, I.PAI

PRI

l.TCB

TCB address of requestor

l.LN2

Address of second LUT word

Address of redirect UCB

I.UCB
l.FCN

Function code

l.IOSB

Virtual address of 110 status block

Relocation bias of 1/0 status block

Rea! address of !/O status block

Virtual address of AST service routine

I.AST

Modifier

I.PAM
Device
parameters

ZK-228-81

Figure D-2

D. 5. 2

I/O Packet

The DCB

The DCB is described in detail in Section 4.1.2 of this
following additional information applies to ACPs:

manual.

The

D.MSK
In general, I/O requests marked as ACP functions are passed to
the ACP;
all others are passed to the device driver when it
calls $GTPKT.

D.5.3

The UCB

The UCB is described in detail in Section 4.1.4 of this
following additional information applies to ACPs:

manual.

The

U.CTL
UC.QUE - Queue bypass bit
If UC.QUE is set, all I/O requests are passed to the
driver without being queued first, regardless of any
ACP-related processing in DRQIO. A driver that makes
use of this option may alter the behavior of the file
system, since some functions are
normally
passed
directly to the ACP, bypassing the driver queue.

D-9

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
If UC.QUE and US.FOR are set, all DIGITAL-specific ACP
processing is bypassed.
In this case, the driver must
do all address checking and relocation.
The UC.QUE option allows user-written ACPs to validate
the ACP function parameters.
Each I/O driver supported
by the user-written ACP must contain code to do the
validation.
The validation must be done at this point
in the I/O processing, because the routines that do
address checking and relocation assume that the memory
management registers are in use by the tasks issuing the
I/O.
(Refer to the DRQIO module for examples of the
techniques used to validate and save parameters.)
UC.KIL - Unconditional cancel I/O call bit
If UC.KIL is set, the I/O driver is called on a cancel
I/O request even if the unit specified is not busy.
Since ACP functions are dependent on sequencing,
function is normally turned into a no-op.

this

An IO.KIL request has no effect on a mounted unit since
the I/O queue is not flushed on the IO.KIL request when
the DV.MNT (mountable) and US.MNT (mounted) bits are set
for the unit.
U.STS
US.MNT
US.MNT

If US.MNT is set, the unit is not mounted.
cleared when the volume is mounted.

US.FOR
If US.FOR is set, the volume is mounted
US.FOR is set when the volume is mounted.

foreign.

US.MOM
If US.MOM is set, the volume is marked for dismount.
An ACP normally checks the US.MOM bit when it processes
a new I/O request.
The ACP refuses operations that
create a channel for processing
(such as OPEN) · when
US.MOM is set.
After operations that terminate a
channel (such as CLOSE), the ACP checks the current
count of active channels to see if all ACP-related
processing has been completed.
If it is, the ACP
completes the dismount.
US.MOM is set when the volume is to be dismounted.
U.CWl
This characteristics word is returned to the user task by the
GLUN$ directive.
U.CWl is checked during validation of I/O
request.
The following bits are important to ACPs:
DV.MNT
If DV.MNT is set, the device is mountable.
If a device
is mountable, ACP functions can only be performed when
it is mounted.

D-10

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
DV. Fll
If DV.Fll is set, the device is a Files-11 device.
DV.Fll is set for both disks and tapes.
If the device
is Files-11, the DV.SQD bit determines whether the
device is random or sequential.
DV. CG'!
If DV.CG'I is set, the device is mountable as
communications channel. This is used for DECnet.

DV.SQD
If DV.SQD is set, the device is sequential.
is reset, the device is random access.

DV. SQD

If DV.SDI is set, the
directory.

single

DV. SDI
device

supports

only

DV.DIR
If DV.DIR is set, the device is a directory device.

D.6

AN EXAMPLE OF AN ACP-I/O DRIVER COMBINATION

The following is an example of an ACP, including a special driver used
by the ACP.
This ACP, supplied for demonstration purposes only,
~ounts the number of QIOs to a terminal.
The modules supplied and their respective functions are:
QDPRE.MAC
QDDAT.MAC
QDDRV.MAC
QDACP.MAC
QDCON.MAC

Prefix file for assembly
Driver database
Driver for ACP
The ACP itself
The task for enabling and disabling the ACP

Example D-1 An ACP-I/O Driver Combination
• TITLE
• IDENT

QDPRE
/01/

.ENABL

This structure is purely for purposes of example.
It is not intended to
be useful nor is it supported in any way.
It is, however,
functional, complete, and representative of a val~d interface.

D-11

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-QDPRE-QD: driver prefix file
EXECUTIVE DEPENDENCIES
The following is a list of the recognized Executive dependencies for the
the QD: driver. If the implementation or functionality of the following
features change, this driver and ACP may not function properly.

1. The Executive I/O processing as described in RSX-llM Guide to Writing an I/O

Driver remains unchanged.
2. The following Executive routines remain unchanged:

~11

$SWSTK {SWSTK$)
$BLXIO
$EXRQP
of the routines documented in the RSX-llM Guide to Writing an I/O Driver

System Macro Calls
.MCALL
UCBDF$

UCBDF$

QD driver-specific offsets
• ASECT
• =U. VCB+2
U. QACP::. BLKW
U.QCTL:: .BLKW
U.QLUN:: .BLKW
U. QTRN::. BLKW

End of UCB
1
1
1
1

Address of QD ACP TCB
ACP control and status word
LUN used by ACP when doing I/O for this unit
Count of transactions outstanding to ACP
Stop requested for ACP on this unit
This unit onlne

UQ.STP==lOOOOO
UQ.ONL==40000
• PSECT
Q$$Dll=3
LD$QD=O

Number of units
Driver loadable

• TITLE
• !DENT

QDDAT
/01/

.ENABL

D-12

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

This structure is purely for purposes of example.
It is not intended to
be useful nor is it supported in any way.
It is, however,
functional, complete, and representative of a valid interface.

**-QDDAT-QD: driver device tables
The following data structure is designed with two things in mind:
1. Providing the minimum structures to look like a disk
2. Providing the minimum structures to satisfy the Executive
and the MCR LOA commands.
$QDDAT::
QDDCB:

Start of QDDRV device tables
.WORD
.WORD
.ASCII
.BYTE
.WORD
.WORD

• QDO
/QD/
O, Q$$Dll-l
QDND-QDST
0

Link to next DCB
1
Pointer to first UCB
Device name
Lowest and highest unit number
Length of UCB
Pointer to driver dispatch table, set by LOA

The following table defines the initial processing of I/O functions in the
Executive QIO directive processing. The legal functions selected are those
of the standard disk drivers.
. WORD
.WORD
.WORD
.WORD
.WORD
• WORD
• WORD
.WORD
.WORD

l 7703 7
000030
000000
177000
000777
000000
000000
000777
0

.NLIST
• LIST

MD
ME

• REPT

Q$$Dll

• IRP

XX,\<$$$>

Legal functions 0.-15 •
Control functions 0.-15.
No-op functions 0.-15.
ACP functions 0.-15.
Legal functions 16.-31.
Control functions 16.-31 •
No-op functions 16.-31 •
ACP functions 16.-31.
PCB address of driver partition

$$$=0

QDST=.

Start of UCB
.IF DF

M$$MUP

.WORD
.WORD

0
0

• ENDC

D-13

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
.QD'XX':.WORD
.WORD
.BYTE
.BYTE
.BYTE
.BYTE
.WORD
.WORD
.WORD
.WORD
.WORD
.WORD
.BLKW
.BLKW
.WORD
.WORD
.WORD
.WORD
.WORD

QDDCB
• QD 'XX
UC. PWF ! UC. ALG ! 3

Back pointer to DCB
Redirect pointer
Control flags byte, call on powerfail
to allow proper setting of on-line/off-line bit
US.MNT
Status byte
O
Physical unit number, does not apply
O
; Second status word
DV.MNT!DV.Fll!DV.SDI!DV.DIR ; Characteristic word 1
0
Characteristic word 2, size of device
0
Characteristic word 3
512.
Characteristic word 4, buffer size
$QDO
Pointer to SCB
0
Attached task TCB address
2
User buffer pointer
1
and byte count
0
Address of file system ACP TCB
0
Address of VCB for file system
0
U.QACP-QDACP TCB address
0
U.QCTL-QDACP Control word
'XX'+l
U.QLUN-QDACP LUN for I/O

QDND=.

End of UCB
.ENDR

$$$=$$$+1
• ENDR

$QDO::

• NLIST
• LIST

ME
MD

.WORD
.BYTE
.BYTE
.BYTE
.WORD
.WORD
.BLKW

0,.-2
0,0
0,0
0,0
0
0
5

$QDEND::

Device I/O queue
Device priority and vector
Current and initial device timeout count
Controller index and device status
CSR address
Address of I/O packet
Fork block
End of QDDRV device tables

• END

• TITLE
• !DENT

QDDRV
/01/

.ENABL

This driver is purely for purposes of example.
It is not intended to
be a useful driver nor is it supported in any way.
It is, however,
functional, complete, and representative of a valid interface.

**-QDDRV-QD: driver

D-14

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

MACRO LIBRARY CALLS

DRIVER DISPATCH TABLE
$QDTBL::aWORD
.WORD
.WORD
.WORD

QDINI
QDCAN
~o~

QDPWF

Initiator entry point
Cancel I/O entry point
Device timeout entry point
Powerfail entry point

LOCAL DATA
.IF DF
ACPTNM: .RAD50

AUTOST
/QDACP /

Default ACP task name

.ENDC
**-QDINI - "Disk" Driver
This driver, in conjunction with its Ancillary Control Processor (ACP)
appears to be a disk, but its operational characteristics are
unusual. The actual storage medium may be any of a number of devices
including memory, disk, or DECnet link. No driver queue is maintained;
all I/O packets are queued directly to the ACP. The cancel I/O, device
timeout, and powerfail entry points are all set to be no-ops. The actual
processing of the request is left to the ACP.
Remember, this driver is an example and demonstrates multiple features
of the driver/ACF/Executive interface.
Inputs:
R5=UCB address
The buffer address and count for IO.RLB and IO.WLB have been validated
by DRQIO processing code. IO.KIL, IO.ATT, and IO.DET are processed by
the Executive's standard I/O processing routines. IO.CTL is queued directly
to QDACP •
• ENABL
QDINI:

LSB
Driver initiation entry point

CALL
BCS
CillB
MOV
BIT
BEQ
MOVB
CMPB
BEQ
CMPB
BNE

$GTPKT
Get I/O packet
EXIT
If CS none to get
S.STS{R4)
Unbusy controller since ACP does all work
Rl,R3
; Copy I/O packet address
#UQ.ONL,U.QCTL(R5} ; Unit online?
20$
If EQ no
I.FCN+l(R3),RO
Get function code
#IO.RLB/400,RO
Read logical block?
QPRLB
If EQ yes
#IO.WLB/400,RO
Write logical block?
ERRIFC
If NE no

D-15

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

Function specific validation routines.
The checks here could
be made later in the ACP, but they are easily made here and have
the added benefit of saving of two context switches (to and from
the ACP) to return an error.
QPWLB:

MOV
BIT
BNE

#IE.WLK&377,RO
Assume write locked
#DV.SWL,U.CWl(R5) ; Unit software wr.ite locked?
IOFIN
If NE yes
Join common code

QPRLB:

CALL

$BLKCK

Check for valid logical blocks

MOV

R3,Rl

Restore the I/O packet address to Rl

MOV

U. QACP (R5), RO

Get address of ACP's TCB. The offset U.ACP
can NOT be used since file system ACP uses
that location.
The UCB is used for TCB
because it is easy for the ACP to access
(as opposed to some location within the
driver).

BNE

10$

If NE the ACP has been started.
The next few lines of code may be used as
an alternate method of starting the ACP.
They allow the ACP to be started
automatically if it is installed.
They can't be used in this application
since ACP needs some initialization info

• IF DF

AUT OST

If defined, auto start ACP

MOV
CALL
BCS
BIT
BEQ
MOV

#ACPTNM, R3
$SRSTD
20$
#T3.ACP,T.ST3(RO)
20$
R 0 , U. QA CP (R 5)

Get address of ACP task name
See if our ACP is installed
I f CS no
; Built as an ACP?
I f EQ no
Save address of ACP

INC
JMP

U. QTRN (R5)
$EXRQP

Increment count of transactions in ACP queue
Queue to the ACP by priority and activate
it.
This request will unstop the ACP if
is stopped or run it if its not active.

MOV
BR

#IE. OFL&3 77, RO
IOFIN

ERRIFC: MOV

#IE. IFC&3 77, RO

I/O status of illegal function code
Finish I/O request

IOFIN:

CLR
JMP

Rl
$IOFIN

Second I/O status word
Finish I/O request

.DSABL

LSB

• ENDC
10$:

20$:

Reference label
I/O status of device not ready
Finish I/O request

D-16

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-QDPWF-Powerfail, Mark offline units offline
QDPWF:

BIT
BNE
BISB

10$:

#UQ.ONL,
QCTL(R5) ; Unit offline?
10$
If NE no
#US.OFL,U.S .. 2(R5) ; Set offline
Refrrence label

**-QDCAN-Cancel I/O in progress, ignored
**-QDOUT-Device timeout, does not ~pply
QDCAN:
QDOUT:
EXIT:

RETURN

These functions are no-ops

• END

• TITLE
• IDENT

QDACP
/01/

.ENABL

This ACP is purely for purposes of example.
It is not intended to
be a useful ACP nor is it supported in any way.
It is, however,
functional, complete, and representative of a valid interface.

**-QDACP-QD: driver ACP

MACRO LIBRARY CALLS
.MCALL

ALUN$S,DIR$,QIO$,WTSE$,WSIG$S

LOCAL DATA
• QIO::

QIO$

,1,1,,IOSB,,<,,,,,> ; My own QIO DPB

• !OST: : • B LKW
• IOPKT::. BLKW
• ACT UN: : • WORD

1
0

I/O status to return to user
Address of current I/O packet
Count of active units

WTSE:

WTSE$

Wait for I/O completion

IOSB:

• BLKW

I/O status block for my I/O

FID:

.BLKW

File ID of work file

D-17

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-.START-ACP starting entry point
.START: :CALL

• !NIT

Do one-time initialization

**-.GTPKT-Get the next I/O packet from ACP queue and dispatch function
• GT PKT : : CLR
SWSTK$

• IOPKT
30$

MOV

$TKTCB, RO

ADD
CALL
BCC
TST
BNE
MOV
JMP

:fl:T.RCVL,RO
$QRMVF
20$
• ACTUN
10$
$TKTCB,RS
$DR EXT

10$:

JMP

$ST PCT

20$:

MOV

Rl,. IOPKT

RETURN
30$:

MOV
BEQ

• IO PKT, R3
• GT PKT

MOV

I.UCB(R3),RS

i No I/O packet yet
,, Switch to system state to synchronize with
;; Executive. This prevents context switching
ii and makes Executive routines accessable.
ii On return from system state, execution will
ii resume at 30$.
This call also saves all
ii registers.
, , Address of my TCB (must be my TCB since
,, can't execute in context of any other task
ii Point to receive queue listhead
,, Attempt to dequeue I/O packet from queue
ii If CC I/O packet removed from queue
ii Is this ACP still active for any units?
ii I f NE yes
ii RS must be our TCB address
ii No I/O requests in our queue and no active
ii units, perform a task exit without any
ii possibility of a race between QDCON
ii inserting an I/O request in our queue
ii and our task exit.
ii Stop current task (us) and return to task
,, state. Once back in task state the PC will
ii be at 30$, since once we are unstopped we will
ii resume execution at 30$, not the next line.
;; Save I/O packet address.
(Return to task
ii state restores all registers.)
ii Return to task state.
Complementary to
, , SWSTK$.
Get I/O packet address
If EQ none found in queue, try again since
someone unstopped us.
Get UCB address for request

Process I/O request
Do any initialization required

40$:

MOV
CLR
MOV
MOV
CLR
DEC
BNE

MOV

us. sue,. rosT
• IOST+2
:fl:. QIO+Q. IOPL, RO
:fl:6, Rl
(RO)+
Rl

Initial status of success

Point to parameter list are of our QIO DPB
Number of words to clear
Clear them
Done?
I f NE no
40$
U.QLUN(RS),.QIO+Q.IOLU i Setup LUN in DPB

D-18

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

Dispatch function
I/O function is dispatched with the following registers
RS=UCB Address
R3=I/O Packet
And .QIO has the correct LUN plugged into the DPB

100$:
ll0$:

MOVB
CMPB
BNE

I. FCN+l (R3) I RO

#IO. RLB/400, RO
100$

JMP

FCRLB

CMPB
BNE
JMP
CMPB
BEQ

#IO. WLB/ 4 00 I RO
ll0$
FCWLB
#IO.CTL/400,RO
FCC TL

Get I/O function code
Read logical block?
I f NE no
Process read
Write logical block?
I f NE no
Process write
ACP control function?
I f EQ yes

Illegal function code
IEIFC:

MOV

#IE.IFC&377,.IOST

I/O status of illegal function code

**-.IOFIN-Finish I/O request returning status to user.
INPUTS:
.IOST=I/O status of current request
.IOPKT=Address of I/O packet
.IOFIN: MOV
MOV
MOV
MOV
SWSTK$
CLR
DEC
BNE
BIT
BEQ
BITB
BEQ
TST
BNE
BIC

10$:

BISB
CLR
INC
JMP

20$:

ASR
BCC
CALL

30$:

JMP

DEC

.IOST,RO
.IOST+2,Rl
• IO PKT I R3
I.UCB(R3),R5
20$
• IO PKT
U.QTRN(RS)

Get I/O status

• IO PKT
30$
• CLOSE
• ACTUN
• GT PKT

Unit go to offline state?
I f CC no
Close up shop on this unit
Decrement count of active units
Get next I/O request

Get address of I/O packet
Get UCB address
;; Switch to system state
i i No I/O packet anymore
, , Decrement count of outstanding I/O queued
;; to ACP
10$
i i If NE more requests in queue
#UQ.STP,U.QCTL(RS) ii Has a request to stop processing on
ii this unit been received?
10$
,, If EQ no
#US.MNT,U.STS(RS) ii Unit still mounted?
10$
; i I f EQ yes
U.ATT(RS)
; ; Unit attached?
10$
; ; I f NE yes
#UQ.STP!UQ.ONL,U.QCTL{RS) i Clear our on-line bit and stop
; ; request flag
#US.OFL,U.ST2(R5) ;; Mark unit offline
U.QACP(RS)
ii No ACP active on unit
.IOPKT
;; Flag to indicate unit went to off-line state
$IOFIN
;; Finish I/O request and return to task state

D-19

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-.DOIO-Do I/O for user to real device
This routine maps to the users buffer(s) and issues an I/O request that
will use the requesting task's buffers. This occurs because the QIO
processing uses the logical mapping, not the virtual mapping, to determine
where buffers are located. By logical mapping, I mean the physical mapping
contained in the memory management registers. Because we are privileged,
no validity checking is made on the buffers, so it is possible to do I/O
to buffers larger than the windows through which they are mapped, that is, greater
than about 4KB. This routine will function properly if the ACP overmaps
the I/0 page because it switches to the system stack, hence to kernel mode.
Therefore, this routine must not be mapped by APR 7.
INPUTS:
RO=Buffer 1 mapping for user APR 1
Rl=Buffer 2 mapping for user APR 2
OUTPUTS:
I/O issued and completed
If CC then IOSB is I/O status
If CS then $DSW is directive error
• DOIO:

SWSTK$
MOV
MOV
MOV
MOV
INCB
RETURN

10$
UISAR0+2, 2 (SP)
UISAR0+4, 4 (SP)
RO, UISAR0+2
Rl, UISAR0+4
$CXDBL

10$:

Switch to system state
Save user APR 1 value in saved RO
And user APR 2 value in saved Rl
Map to user's first buffer
Map to user's second buffer
Disable context switching
Return to task state
Reference label

Issue the QIO directive, context switching is disabled so we don't have
to worry about user APRs 1 and 2 being modified. However, we can't wait
for the I/O to complete at this point.
DIR$
ROR

#. QIO
-(SP)

Issue I/O request
Save carry state

Buffers have been "validated" and relocated so we can restore original
mapping and enable context switching.
SWSTK$
MOV
MOV
DECB
RETURN

20$
RO, UISAR0+2
Rl, UISAR0+4
$CXDBL

20$:

Switch to system state
Restore user APR 1
Restore user APR 2
Enable context switching
Return to user state
Reference label

Context switching is now enabled, check directive status and if successful
wait for completion

30$:

ROL
BCS
DIR$
RETURN

(SP)+
30$
#WTSE

Restore carry, was directive successful?
If CS no
Wait for I/O to complete
Return to caller

D-20

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-.BLXI-Transfer data into our buffer
INPUTS:
RO=Byte count to transfer
Rl=Address mapping base
R2=APR 6 displacement
R3=Address of our buffer
OUTPUTS:
Data in our buffer

• BLXI:

• ENABL

LSB

SWSTK$
MOV
MOV
MOV

20$
RO,RS
Rl,-(SP)
R2,-{SP)
R3,RO
$RELOC
Rl,R3
R2,R4
(SP)+,R2
{SP)+,Rl
10$

MOV

CALL
MOV
MOV
MOV
MOV
BR

Switch to system :;tate
Save RS
Save Rl
And R2
Set virtual address of our buffer
Convert to address double word
Copy Rl and
R2 to proper place for $BLXIO
Restore R2
and Rl
Join common code

**-.BLXO-Transfer out of our buffer into user's buffer
INPUTS:
RO=Byte count to transfer
Rl=Address mapping base
R2=APR 6 displacement
R3=Address of our buffer
OUTPUTS:
Data in user buffer
• BLXO:

10$:
20 $:

SWSTK$
MOV
MOV
MOV
MOV
CALL
MOV
ADD
JMP
RETURN

20$
Switch to system state
RO,RS
Save RO
R3,RO
Set RO to address of our buffer for $RELOC
Rl,R3
Copy Rl and
R2,R4
R2 into proper place for $BLXIO
$RELOC
Convert to address doubleword
RS, RO
Restore byte count
#120000-140000,R2 ; Convert to APR S displacement
Transfer data and return to task state
$BLXIO
Return to caller

.DSABL

LSB

D-21

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-FCCTL-ACP control functions
Two control functions are supported, start-up and shut-down.
We check the request for validity and then set up various fields in the
drivers UCB.
FCCTL:

MOV
BIT
BEQ
CMPB
BEQ
CMPB
BEQ
BR

I.TCB(R3),RO
;
#T3.PRV,T.ST3(RO)
IEIFC
#1, I. FCN (R3)
10$
#2,I.FCN(R3)
30$
IEIFC

Get TCB address of issuing task
; Task privileged?
I f EQ no
Startup request?
I f EQ yes
Stop request?
I f EQ yes
Illegal function

Process start request
10$:

TST
BNE
CALL
BCS
INC

20$:

MOV
BIS
BICB
BR
MOV
BR

U.QACP(R5)
Already got an ACP?
20$
I f NE yes
.OPEN
Open up shop for unit
100$
If CS failed to open channel to "device"
.ACTUN
; Increment count of units active
$TKTCB,U.QACP(R5) ; Set ACP TCB address in UCB
#UQ.ONL,U.QCTL(R5) ; Set unit online
#US.OFL,U.ST2(R5) ; And for the operating system
100$
; Join common code
#IE.RSU&377,.IOST; ACP already started for unit error
100$
Join common code

Process stop request
30$:

CMP
BNE
BIT
BNE
CALL
BITB
BEQ
TST
BNE
CMP
BNE
BISB
BIS
RETURN
MOV
RETURN

$TKTCB,U.QACP(R5) ; Unit online with correct ACP?
50$
; I f NE no
#UQ.STP,U.QCTL(R5) ; Stop requested?
60$
; I f NE yes
$SWSTK,100$
;; Go to system state to prevent a race problem
#US.MNT,U.STS(RS) ;; Unit still mounted?
40$
; ; I f EQ yes
U.ATT(RS)
;; Unit attached?
40$
; ; I f NE yes
#l,U.QTRN(R5)
;; Is this this the only transaction queued?
40 $
, , If NE no
#US.OFL,U.ST2(R5) ;; Mark unit off line to prevent further I/O
#UQ.STP,U.QCTL(R5) ;; Request unit be stopped
;; Return to task state at statement 100$
#IE.NFW&377,.IOST ;; Unit busy, attached, or mounted
;; Return to task state at statement 100$

50$:

MOV
BR

#IE.OFL&377,.IOST; Unit offline
100$
Join common code

60$:

MOV

#IE.FLN&377,.IOGT; Already being stopped; error

100$:

JMP

• IOFIN

40$:

Finish I/O request

D-22

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

WARNING
The above code must be in the first 8K of the ACP because
a switch to system state uses the kernel mode mapping which
allows only 8K for task mapping. (The I/O page is mapped in
thru APR 7 in system state, but may be overlaid by the task
in task state.)

**-FCRLB-Read logical block function

FCRLB:

• ENABL

LSB

CALL
BCS
MOV
MOV
MOV
MOV
MOV
CALL
BR

• READ
10$
I. PRM +4 ( R 3) , R0
RO,. IOST+2
I. PRM ( R 3 ) , R1
I. PRM + 2 (R 3 ) , R2
R4,R3
.BLXO
30$

Data in memory already?
I f CS no
Get byte count
Set return status byte count
APR mapping
APR6 displacement
Address of our buffer
Transfer to user buffer
Join common exit code

**-FCWLB-Write logical block function
FCWLB:

CALL
BCS
MOV
MOV
MOV
MOV
CALL
MOV

.WRITE
10$
I. PRM+4 (R3), RO
I. PRM ( R 3 ) I R1
I. PRM +2 (R 3) I R2
R4,R3
.BLXI
• IO PKT I R3

Transfer data to our buffer first?
I f CS no
Get byte count
APR mapping
APR6 displacement
Address of our buffer
Transfer to our buffer
Restore I/O packet address

Do I/O from user buffer

10$:

20$:
30$:

MOV
MOV
SUB
MOV
CALL
BCC
MOV
BR
MOV
MOV
JMP

I.PRM(R3),RO
; Get mapping value for APR 1
I.PRM+2(R3),Rl
; Get displacement biased for APR6
#140000-20000,Rl ; Adjust to an APRl bias
Rl,.QIO+Q.IOPL
Insert virtual address of buffer when mapped
·via APR 1
• DOIO
Issue I/O request
20$
; If CC successful
#IE.AB0&377,.IOST ; Return error to user
30$
Join common code
IOSB,.IOST
Return status to user
IOSB+2,. IOST+2
• IOFIN
Finish I/O request and dispatch next request

• DSABL

LSB

D-23

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-.INIT-One time initializations on startup
.INIT:

None
RETURN

**-.OPEN-Open up I/O path for unit
Inputs:
RS=UCB address
R3=I/O packet address
• OPEN:

10$:
20$:

ALUN$S
BCS
MOV
MOV
MOV
MOV
CALL
MOVB
BMI
CLR
CLR
MOV
MOV
CALL
MOVB
BMI
CLR
MOV
CALL
MOV
RETURN
SEC
RETURN

U.QLUN(RS),l"SY,#0; Assign LUN to work file device
20$
; If CS error
IIO.CRE,.QIO+Q.IOFN; Setup for create file
IFID,.QIO+Q.IOPL ; Insert address to receive file ID
#100000,.QIO+Q.IOPL+4 ; Enable extend
I.PRM(R3),.QIO+Q.IOPL+6 ; Allocate file of size requested
XIO
Create and extend file
IOSB,.IOST
Copy I/O status
10$
If MI error
.QIO+Q.IOPL+4
Reset parameter
.QIO+Q.IOPL+6
; Ditto
#IO.ACW,.QIO+Q.IOFN ; Set up to access the file
#100000,.QIO+Q.IOPL+lO; Enable access
XIO
; Access file
IOSB,.IOST
; Copy I/O status
10$
; If MI error
.QIO+Q.IOPL+lO ; Reset parameter
#IO.DEL,.QIO+Q.IOFN ; Set up to mark file for delete
XIO
; Mark file for delete
I.PRM(R3) ,U.CW3(R5) ; Set up device size
Successful exit with carry clear
Error exit with carry set

CRASH

Internal error

**-.CLOSE-Close channel to device
• CLOSE: MOV
MOV
10$:
CLR
DEC
BNE
MOV
JMP

#6,RO
#.QIO+Q.IOPL,Rl
(Rl)+
RO
10$
;

Number of parameters to clear
Address of parameter list
Reset parameters
Done?
If NE no
#IO:DAC,~QIO+Q.IOFN ; Set to deaccess file
XIO
; Deaccess file

**-.READ-Determine method of performing read
Inputs:
RS=UCB Address
R3=I/O Packet

D-24

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

Outputs:
If CS then do I/O directly into user buffer
.QIO DPB setup with I/O function code
If CC then do I/O to our buffer, then copy to user buffer
R4=Address of buffer
• READ:

MOV
MOV
MOV
MOV
ADD
ADC

10$:

CMP
BNE
MOV
MOV
CALL
TSTB
BMI
CLC
RETURN
SEC
RETURN

#IO.RVB,.QIO+Q.IOFN ; Set up to read
I.PRM+4(R3),.QIO+Q.IOPL+2 ; Insert byte count into DPB
I.PRM+l0(R3),.QIO+Q.IOPL+6; And block number to start transfer
I.PRM+l2(R3),.QIO+Q.IOPL+l0;
#1,.QIO+Q.IOPL+lO; Convert from "logical" to "virtual"
.QIO+Q.IO~L+6
;
#1000,I.PRM+4(R3) ; Do I/Oto our buffer first?
If NE no
10$
#.BUF,R4
Set address of buffer
R4,. QIO+Q. IOPL
Set up buffer address
XIO
Read data into our buffer
IOSB
On error go directly to user buffer; error?
10$
I f MI yes
Copy to user buffer
Do I/O directly to user buffer

**-.WRITE-Determine method of performing write
Inputs:
RS=UCB Address
R3=I/O Packet
Outputs:

If CS then do I/O directly from user buffer
.QIO DPB setup with I/O function code
If CC then copy data to our buffer, then do I/O from user buffer
R4=Address of buffer
.WRITE: MOV
MOV
MOV
MOV
ADD
ADC

10$:

CMP
BNE
MOV
CLC
RETURN
SEC
RETURN

#IO.WVB,.QIO+Q.IOFN ; Set up to write
I.PRM+4(R3),.QIO+Q.IOPL+2; Insert byte count into DPB
I.PRM+l0(R3),.QIO+Q.IOPL+6; And block number on device
I.PRM+l2(R3),.QIO+Q.IOPL+l0;
#1,.QIO+Q.IOPL+lO ; Convert from "logical" to "virtual"
• QIO+Q. IOPL+6
;
#1000,I.PRM+4(R3) ; Copy to our buffer first?
If NE no
10$
#.BUF,R4
Address of buffer for data
Copy from user buffer
Do I/O directly from user buffer

D-25

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-XIO-Execute QIO request
XIO:

10$:

20$:

DIR$
BCC
CMP
BNE
WSIG$S
BR
DIR$
BCS
RETURN

#. QIO
10$
#IE. UPN, $DSW
20$

xro
#WTSE
20$

CRASH

Issue I/O request.
If CC successfully issued
No dynamic storage available?
I f NE no
Hope
••• hope
Wait for I/O to complete
If CS error
Internal error

I/O buff er
.BUF:

.BLKB

1000

.END

.START

• TITLE
• IDENT

QDCON
/01/

.ENABL

One block long

This control task is purely for purposes of example.
It is not intended to
be a useful task nor is it supported in any way.
It is, however,
functional, complete, and representative of a valid interface.

**-QDCON-QD: driver and ACP control task

MACRO LIBRARY CALLS
.MCALL
.MCALL

ALUN$,GLUN$,DIR$,GMCR$,WTSE$S,QIOW$S,EXST$S
ISTAT$,STATE$,TRAN$

DEFINE PARSER STATE TABLE
The following commands are supported:
>QDC START QDn:/SIZE:n
where
START is the subcommand to startup the ACP specifying the "disk size"
>QDC STOP QDn:
where
STOP is the subcommand to stop the ACP at the earliest opportunity

D-26

USER-WRITTEN ANCILLARY CONTROL PROCESSORS
ISTAT$

QDCSTB,QDCKTB

Skip command name
STATE$
TRAN$

INITL
$STRNG

Determine subcommand
STATE$
TRAN$
TRAN$

"START" ,START,, $START, $DIS PT
"STOP" ,STOP,, $STOP, $DIS PT

Process START command, get device name
STATE$
TRAN$

START
!DEVICE

STATE$
TRAN$
TRAN$

OPTION
I I, SWITCH
$EOS,$EXIT

STATE$
TRAN$

SWITCH
"SIZE" ,SIZE

STATE$
TRAN$

SIZE

STATE$
TRAN$

'=
$NUMBR,OPTION,SETSIZ

Process STOP command
STATE$
TRAN$

STOP
! DEVICE

STATE$
TRAN$

$EOS,$EXIT

Process device name
STATE$
TRAN$

DEVICE
$ALPHA,, SETDVl

STATE$
TRAN$

$ALPHA,, SETDV2

STATE$
TRAN$
TRAN$

$NUMBR,DEV1,SETUNT
$LAMDA

STATE$
TRAN$

DEVI
':,$EXIT

Terminate state table
STATE$

D-27

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

PARSER ACTION ROUTINES
Set first character of device name
SETDVl: MOVB
RETURN

.PCHAR,$DEV

Save first character of device name

; Set second character of device name
SETDV2: MOVB
RETURN

.PCHAR,$DEV+l

Save second character

; Set device unit number
SETUNT: MOV
RETURN

.PNUMB,$UNIT

Save converted unit number

; Set device size
SETSIZ: MOV
RETURN

• PNUMB, $SIZE

Save converted size

LOCAL DATA
ALUN:
$DEV=
$UNIT=

ALUN$
1, '
ALUN+A.LUNA
ALUN+A. LUNU

Assign LUN to QDn:
Address of device name
Address of device unit number

GLUN:

GLUN$

Get LUN information for QD: device

l,GLUBUF

GLUBUF: • BLKW
6
$PDEV= GLUBUF+G. LUNA
$PUNIT= GLUBUF+G. LUNU
$CHAR= GLUBUF+G. LUCW

LUN information buffer
Actual device name
Actual device unit
Device characteristics word

GMCR:

GMCR$

$SIZE:

.WORD

Device size to create

$DIS PT: .WORD

Address of service routine

ACPNAM: • RAD50

/QDACP I

Name of ACP

PRMLST: • BLKW

8•

Parameter list for I/O packet

$IOST:

I/O status

.BLKW

Get MCR command line

Error messages
.MACRO

ERM

ERN,STS,TEXT
• PSECT $$ERMG

$$$1=.
.ASCII

<l S>nTEXT 11

• PSECT
.WORD
.WORD

STS
$$$1,$$$2-$$$1

$$$2=.
ERN:
• ENDM

D-28

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

.MACRO

ERRX
MOV
JMP

ERN
#ERN,RO
$ERRXT

FTLX
MOV
JMP

ERN
#ERN,RO
$SUCXT

sucx

ERN
#ERN,RO
$SUCXT

• ENDM
.MACRO
• ENDM
.MACRO

MOV
JMP
• ENDM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM
ERM

ERRCML,14,<%QDC-F-GETCOMFAIL, Failed to get command line>
ERRSYN,24,<%QDC-F-SYNERR, Syntax error in command>
ERRNQD,34,<%QDC-F-NOQDDEV, Failed to assign LUN to QD:>
ERRBDV,44,<%QDC-F-BADDEVICE, Invalid device specified>
ERRNOD, 54, <%QDC,-F-NOPOOL, No dynamic memory for I/O request>
ERRNAC,64,<%QDC-F-NOACP,QDACP not installed in system>
ERRREQ,74,<%QDC-F-REQFAIL, Failed to request QDACP>
ERRUSE,104,<%QDC-F-DEVINUSE, Specified unit already in use>
ERRINT,114,<%QDC-F-INTERNAL, Internal error>
ERRFLN,124,<%QDC-F-OFFLINREQ, Unit already requested to offline>
ERRNOL, 134, <%QDC-F-NOTONLINE, Unit not onl ine>
ERRNDS, 144, <%QDC-F-NODISSPAC, Failed to al locate disk space>
ERRBSY,154,<%QDC-F-DEVICEBUSY, Device busy, mounted, or attached>
ERRFTL,O,<-QDC-F-ONLFAIL, Failed to bring unit online>
SUCCOM,161,<%QDC-S-ONLINE, Specified unit brought online>
REQOFF,171,<%QDC-S-REQOFFLINE, Unit requested to offline>

**-.QDCON-QD device control program
$QDCON: CLR
CLR
DIR$
BCC
FTLX

$DIS PT
$UNIT
#GMCR
10$
ERRCML

Reset service routine dispatch address
Clean out unit number
Get the command line
If CC successful

10$:

CLR
MOV
MOV
MOV
MOV
CALL
BCC
FTLX

Rl
#QDCKTB,R2
$DSW,R3
#GMCR+G.MCRB,R4
#INITL, R5
• TPARS
20$
ERRSYN

Suppress blanks
Get keyword table address
Get length of command line
Get address of command line
Get address of initial parser state
Parse command line
If CC good command line

20$:

DIR$
BCC
FTLX

#ALUN
30$
ERRNQD

Assign LUN to QD:
If CC good device

30$:

DIR$

#GLUN

Get device information

JMP

@$DIS PT

Dispatch to START or STOP service

D-29

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

**-$START-Start up ACP and specify size
$START: CMP
BEQ
FTLX

#"QD,$PDEV
10$
ERRBDV

Really QD:?
If EQ yes

10$:

MOV
MOV
MOV
MOV

$SIZE, PRMLST
#PRMLST, R4
#ACPNAM,R3
#IO. CTL! 1, R2

CALL
BCC
CMP
BNE
ERRX
CMP
BEQ
CMP
BNE
ERRX
ERRX

• QUE IO
100$
#IE. UPN, $DSW
20$
ERRNOD
#IE. INS, $DSW
30$
#IE • PR I, $DSW
40$
ERRNAC
ERRREQ

Address of parameter
Get address of parameter list
Get address of ACP task name
Set function code of ACP control
and subfunction of START (1)
Queue an I/O request to the ACP
If CC successfully queued
No pool?
If NE no

CMPB
BNE
sucx

110$
SUCCOM

CMPB
BNE
ERRX
CMPB
BNE
ERRX
FTLX

#IE. RSU, $!OST
120$
ERRUSE
#IE.DFU, $!OST
130$
ERRNDS
ERR INT

20$:

30$:
40$:
100$:

ll0$:
120 $:
130$:

us. sue, $IOST

ACP not installed?
If EQ yes
Not an ACP?
If NE no
Catchall error message
Success?
If NE no
Successful completion
Already got an ACP or already started?
If NE no
Device full?
If NE no
Catchall error message

**-$STOP-Stop ACP operation
$STOP:

CMP
BEQ
FTLX

#"QD,$PDEV
10$
ERRBDV

Really QD:?
If EQ yes

10$:

MOV
MOV
MOV

#PRMLST, R4
#ACPNAM, R3
#IO. CTL! 2, R2

CALL
BCC
CMP
BNE
FTLX

• QUE IO
100$
#IE. UPN, $DSW
140$
ERRNOD

Get address of parameter list
Get address of ACP task name
Set function code for ACP control
and subfunction of STOP (2)
Queue an I/O request to the ACP
If CC successfully queued
No pool?
If NE no

CMPB
BNE
sucx

ll0$
REQOFF

CMPB
BNE
FTLX

#IE. FLN, $!OST
120$
ERRFLN

100$:

ll0$:

us. sue, $IOST

Success?
If NE no
Successful completion
Already being off-lined?
If NE no

D-30

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

120$:
130$:
140$:

CMPB
BNE
FTLX
CMPB
BEQ
FTLX
FTLX

#IE.NFW,$IOST
130$
ERRBSY
#IE.OFL,$IOST
140$
ERR INT
ERRNOL

Unit busy?
If NE no
Device not on line?
I f EQ yes
Catchall error message
Not on line

**-.QUEIO-Create and queue an I/O packet directly to an ACP
This routine builds an I/O packet and queues it directly to an
ACP bypassing the Executive QIO directive processing. The primary
reason for doing this is the fact that under some circumstances
the ACP cannot be reached by going through the driver, such as when the
ACP has not been started. The parameter list is copied into the I/O packet
without modification. Consequently, a buffer address cannot be passed
as a parameter; it must first be relocated and the address double word
placed in the parameter list; this routine is not designed to do that.
INPUTS:
R4=Parameter list address
R3=Address of ACP task name
R2=I/O function code
LUN 1 assigned to device associated with ACP
OUTPUTS:
If CC ACP requested and I/O complete
$IOST is I/O status block containing return from ACP
If CS ACP not requested
$DSW is error status
IE.UPN - No dynamic memory for I/O packet
IE.INS - ACP not installed
IE.PRI - Task not an ACP
If entry at .QUEIO, all registers preserved
• ENABL
• QUEIO: SWSTK$
CLR
CLR
MOV
MOV
MOV
CALL
BCS
MOV
BIT
BEQ
MOV
MOV
MOV
MOV
CALL
BCS
MOV
MOV
ASR
10$:
CLR
DEC
BNE
MOV

LSB
40$
;; Switch to system state
$IOST
;; Clear I/O status block
$IOST+2
;; Indicating I/O pending
$HEADR,R5
;; Get address of our task header
H.LUN(R5),R5
ii Get device UCB address
#IE.INS,$DSW
;; Assume task not found
$SRSTD
;; Search for task
30$
ii If CS failure
#IE.PRI,$DSW
,, Assume task not an ACP
#T3.ACP,T.ST3(RO) ;; Task an ACP?
30$
; ; I f EQ no
R 0 , - (S P)
; ; Save TC B add res s
R2,-(SP)
;; Save I/O function code
#IE.UPN,$DSW
;; Assume buffer allocation failure
#I.LGTH,Rl
;; Length of I/O packet
$ALOCB
;; Allocate buffer from pool
30$
;; If CS failure
(SP)+,R3
;; Restore R3
RO,-(SP)
:; Save address of I/O packet
Rl
;; Convert size in bytes to words
(RO)+
;; Zero I/O packet
Rl
;; Done?
10$
ii If NE no
#$IOST,RO
;; Get I/O status block address

D-31

USER-WRITTEN ANCILLARY CONTROL PROCESSORS

20$:

30$:
4 0$:

50 $:

CALL
MOV
MOV
MOV
MOV
MOV
MOVB
MOVB
MOV
MOV
MOV
ADD
MOV
MOV
DEC
BNE
MOV
INC
CALL
MOV
INCB
CLR
MOV
RETURN
TST
SEC
BLE
WTSE$S
RETURN

$RELOC
;; Relocate it
(SP)+,RO
i; Restore packet address
#$IOST,I.IOSB(RO) ;; Insert virtual address of status block
Rl,I.IOSB+2(RO) ;; Insert relocation bias and
R2,I.IOSB+4(RO) ;; Offset of I/O status block
$TKTCB,I.TCB(RO) ii Insert our TCB
#1,I.EFN(RO)
ii Insert event flag number
#251.,I.PRI(RO) ;; Insert priority
R5,I.UCB(RO)
; ; Insert device UCB
R3,I.FCN(RO)
;; Insert function code
RO,Rl
;; Copy address of packet
#~.PRM,RO
i; Point to parameter area
#B.,R2
;; Set parameter count
(R4)+,(RO)+
;; Copy parameter list into packet
R2
;; Done?
20$
; ; If NE no
{SP)+,RO
;; Get ACP TCB address
U.QTRN(R5)
;; Bump count of transactions queued to unit
$EXRQP
ii ,Queue I/O packet to ACP by priority and
ii ensure ACP is active
$TKTCB, RO
;; Get our TCB address
T. roe {RO)
ii Bump our I/O count
T. EFLG {RO)
ii Clear event flag 1
ii Indicate success
#IS. sue' $DSW
ii Return to task state
QIO successful?
$DSW
Assume error
If LE no
50$
Wait for I/O to finish
#1
Return to caller

.DSABL

LSB

**-$ERRXT-Error exit
**-$SUCXT-Success exit
Inputs:
RO=Error table entry
Outputs:
Message and task exit
• ENABL
$ERRXT: MOV
MOV
MOV
QIOW$S
BCC

LSB
(RO)+,R5
Get exit status
(RO)+,Rl
Get address of error text
{RO)+,R2
; Get size of text
#IO.WVB,#5,#5,,,,<Rl,R2, 40> i Write message
10$

IOT

MOV
BR
$SUCXT: MOV
20$:
MOV
MOV
QIOW$S
BCC
10$:

#ERRFTL+2,RO
Get address of fatal error message
20$
Join common code
{RO)+,R5
Get exit status
{RO)+,Rl
Get address of final message
(RO)+,R2
; Get size of message
#IO.WVB,#5,#5,,,,<Rl,R2, 40> ; Write message
30$

IOT

30$:

EXST$S

.DSABL

LSB

• END

$QDCON

Exit with status

D-32

INDEX

$ACHCK routine, 5-2
$ACHKB routine, 5-2
ACP,
See Ancillary Contr~l
Processor
ACP I/O function mask, 4-12
Address doubleword, A-1
$ALOCB routine, 5-3
Alternate CLI support,
UCB field, 4-25
Ancillary Control Processor
{ACP), D-1
as extension of Executive,
D-5
as task, D-4
attributes, D-4
enabling and disabling
capacity, D-5
example, D-11
for class of devices, D-4
I/O request flow, D-5
processing, D-6
role of, in I/O processing,
2-3
shareability, D-5
type, D-2 to D-3
$ASUMR routine, 5-4, B-3

Buffer,
special, 6-9

Cancel I/O entry point, 2-4
DDT conditions, 4-10
CDA,
See Crash Dump Analyzer
CINT$ directive, 3-1
CLI Parser Block {CPB),
address in UCB, 4-25
$CLINS routine, 5-5
Conditional assembly symbol,
LD$xx, 3-5
Conditional routine, 5-1
Control and status register
{CSR),
address in SCB, 4-22
Control I/O function mask,
4-12
Controller number, 2-14
CPB,
See CLI Parser Block
Crash Dump Analyzer {CDA),
debugging driver code, 3-20

$CRAVL symbol,
use of, in fault tracing,
3-28
CSR,
See Control and status
register

Data base, driver,
accessing shared, 2-9
changing, 3-3
controlling access to
shared, 2-10
example, 6-2 to 6-4
loadable,
See Loadable data base
overview, 3-5
resident,
See Resident data base
Data structure, 2-7
See also System data
structure macro
definition
ACP interface, D-7
DHll terminal multiplexer,
2-7
figure, 2-19
interaction with driver, 2-5
interrelationship, 2-18
~aero definition,
overview, 4-1
RLll disk, 2-8
summary, 2-20
D$$BUG label, 3-19
DCB,
See Device Control Block
DDT,
See Driver Dispatch Table
$DEACB routine, 5-6
Debugging,
CDA, 3-20
Executive stack and register
dump routine, 3-16
fault code, 3-26
fault isolation,
3-20 to 3-23
fault tracing, 3-23 to 3-28
Panic Dump routine,
3~19 to 3-20
XDT, 3-15, 3-17 to 3-18
Debugging aid, 3-16
$DEUMR routine, 5-7, B-3
$DEVHD word, 2-19
role of, in I/O data
structure, 2-20

Index-1

INDEX

Device Control Block (DCB) ,
description, 4-7
relationship of, with I/O
control blocks, 2-6
required field, 3-6
role of, in I/O data
structure, 2-20
with ACP, D-9
Device Control Block (DCB)
field,
D.DSP, 3-6, 4-10, 4-14
D.LNK, 3-6, 3-8, 4-8
D.MSK, 3-6, 4-11
D.NAM, 3-6, 4-9
D.PCB, 3-6, 4-14
D.UCB, 3-6, 3-8, 4-8
D.UCBL, 3-6, 4-9
D.UNIT, 3-6, 4-9
Device interrupt entry point,
2-4
Device interrupt vector, 4-33
definition, 2-10
Device time-out entry point,
2-4
DDT conditions, 4-11
Directive Parameter Block
(DPB) , 2-5
description, 4-6
source of I/O packet
information, 2-9
DPB,
See Directive Parameter Block
Driver,
changing code,
debugging,
See Debugging
function, 1-2
loadable,
See Loadable driver
multicontroller, 2-10
Non-MASSBUS NPR, B-1
postinitiation service, 2-11
preinitiation processing of,
2-11
process-like characteristic,
2-13
property, 1-2
rebuilding and
reincorporating, after
debugging, 3-29 to 3-30
resident,
See Resident driver
role of, in RSX-llM, 2-5
Software Performance Report
(SPR) support, 3-4
SYSGEN support, 3-1
type, 1-1

Driver code,
changing, 3-3
example, 6-4 to 6-9
overview, 3-4
Driver data base,
See Data base, driver
Driver Dispatch Table (DDT),
address, 3-5
role of, in I/O data
structure, 2-20
Driver entry point,
cancel I/O, 2-4, 4-10
device interrupti2-4
device time-out, 2-4,
4-11
I/O initiator, 2-4, 2-12,
4-10
power failure, 2-4, 4-11
Driver global symbol,
$xxINP, 3-5
$xxINT, 3-5
$xx OUT, 3-5
$xxTBL, 3-5
DRQIO module,
service performed in
processing QIO, 2-11
$DVMSG routine, 5-8

Error logging,
modifying driver to
incorporate, 3-5
SCB field, 4-20
UCB field, 4-24 to 4-25
Executive Crash Dump routine,
3-20
Executive Debugging Tool
(XDT) ,
debugging driver code,
3-17 to 3-18
ODT features and commands
not included, 3-17
Executive service,
driver processing, 2-10
postinitiation, 2-11
preinitiation, 2-11
Executive service calls,
5-1 to 5-28
Executive stack and register
dump routine, 3-17
debugging driver code,
3-16
use of, in fault tracing,
3-25
$EXRQP routine, 5-9

Index-2

INDEX

FllACP,
role of, in I/O data
structure, 2-19
Fault code, 3-26
Fault isolation, 3-20 to 3-23
Fault tracing, 3-23 to 3-24
after unintended loop, 3-28
Executive stack and register
dump, 3-25 to 3-27
hints, 3-28 to 3-29
in new driver, 3-28
when processor halts without
display, 3-27
FCP,
See File Control Processor
FCS,
See File Control Services
File Control Block (FCB),
role of, in I/O data
structure, 2-20
File Control Processor (FCP),
role of, in I/O data
structure, 2-19
File Control Services (FCS),
positidn of, in I/O
hierarchy, 2-2
Fork block,
storage words in SCB, 4-23
Fork level processing, 2-15
Fork list, 2-9
Fork process, 2-9
creating with $FORK, 2-12
$FORK routine, 5-10
accessing shared driver data
base, 2-10
initiating fork process, 2-9
$FORK1 routine, 5-11
Function mask word,
See I/O function mask

Global label,
$USRTB, 3-13
$xxDAT, 3-9
$xxEND, 3-9
$xxTBL, 4-10
$GTBYT routine, 5-12
$GTPKT routine, 2-12, 5-13
in driver processing, 2-17
use of, with ACP, D-6
$GTWRD routine, 5-14
conditional assembly, 5-1
inclusion of, by SYSGEN, 3-2

$HEADR

pointer,

use of, in fault tracing,

$HEADR pointer (Cont.)
3-24

ICB,
See Interrupt Control Block
Interrupt Control Block (ICB) ,
3-2, 4-35
Interrupt entry point,
address, 3-5
Interrupt processing,
fork level, 2-9, 2-15
priority 7, 2-14
priority of interrupting
source, 2-14
INTSV$ macro,
description, 4-35
format, 4-35
$INTSV routine, 2-12, 5-15
calling with INTSV$ macro,
4-35
processing at priority of
interrupting source,
2-15
$INTXT routine, 5-16
I/O control blocks,
interrelationship, 2-6
I/O data structure,
See also System data
structure macro
definition
See Data structure
I/O driver,
See Driver
I/O function mask,
ACP, 4-12
control, 4-12
creating, 4-13
legal, 4-12
no-op, 4-12
values for disk drive, 4-16
values for magtape drive,
4-17
values for standard
functions, 4-15
values for unit record
device, 4-18
I/O hierarchy, 2-1
I/O initiator entry point,
2-4, 2-12
DDT conditions, 4-10
I/O packet, 2-8
description, 4-2
format-, 4-3
pointer in SCB, 4-21
with ACP, D-7
I/O packet field,
I.AST, 4-5

Index-3

INDEX

!/O packet field (Cont.)
I. EFN, 4-3
I.FCN, 4-4
I. IOSB, 4-4
I. LNK, 4-2
I.PR!, 4-3
I. PRM, 4-5
I. TCB, 4-4
I.UCB, 4-4
I/O philosophy, 2-1
I/O processing,
ACP, 2-3
QIO directive, 2-3
I/O queue, 2-9
I/O request,
flow, 2-16 to 2-17
$IOALT routine, 2-13, 5-17
$!ODON routine, 2-13, 5-17
$IOFIN routine, 5-18
use of, by ACP, D-7

Loadable driver (Cont.)
task-building, with resident
data base, 3-12
Logical unit number (LUN),
2-19
preinitiation processing of,
2-11
Logical Unit Table (LUT), 2-19
LUN,
See Logical unit number
LUT,
See Logical Unit Table

LD$xx symbol, 3-5
required by INTSV$ macro,
4-35
Legal I/O function mask, 4-12
LOA command, 4-35
action if UC.PWF set, 2-4
effect of, when loading
driver, 3-8
loading driver, 3-2, 3-12
Loadable data base,
advantage, 3-8
assembling, 3-9
characteristics, 3-8
Loadable driver,
assembling, 3-9
benefit, 1-1
combination with data base,
3-1
debugging, 3-8
definition, 1-1
incorporating, with data
base, 3-8
linking, with loadable data
base, 3-3
linking, with resident data
base, 3-3
loading, into memory, 3-2,
3-12
rebuilding and
reincorporating, after
debugging, 3-30
removing, from memory, 3-2
task-building,
mapped system, 3-10
unmapped system, 3-11

Mapping register assignment
block,
allocating, B-2
figure, B-3
$MPUB1 routine, 5-20, B-3
use of, to obtain UMRs, B-1
$MPUBM routine, 5-19, B-3
use of, to obtain UMRs, B-1
Multicontroller driver, 2-10
conditional code
description, 4-33
conditional code example,
4-34

No-op I/O function mask, 4-12
NPR device driver, B-1
use of SCB field S.MPR, 4-23
N$$UMR symbol, B-4

Panic Dump routine, 3-19
sample output, 3-20
Partition Control Block (PCB),
addres~ in DCB, 4-14
$PKAVL symbol,
use of, in fault tracing,
3-28
Power failure entry point, 2-4
DDT cemditions, 4-11
Process,
state, 2-10
Programming convention, 2-13
Programming protocol, 2-14
summary, 2-16
$PTBYT routine, 5-21
$PTWRD routine, 5-22
conditional assembly, 5-1
inclusion of, by SYSGEN, 3-2

Index-4

INDEX

$QINSP routine, 5-23
QIO directive,
position of, in I/O
hierarchy, 2-2
preinitiation processing of,
2-11
role of, in I/O processing,
2-3
QIO Directive Parameter Block,
4-6
$QRMVF routine, 5-24
use of, with ACP, D-6

Record Management Services
(RMS),
position of, in I/O
hierarchy, 2-2
RED command, 2-6
$RELOC routine, 5-25
Resident data base,
assembling, 3-12
example, 6-1
Resident driver,
assembling, 3-13
combination with data base,
3-1
definition, 1-1
example, 6-1
incorporating, 3-13
linking data base, 3-3
rebuilding and
reincorporating, after
debugging, 3-29
task-building, 3-14
RMS,
See Record Management
Services

SCB,
See Status Control Block
Special buffer handling, 6-9
example, 6-9 to 6-11
SST fault,
abnormal, 3-27
internal, 3-26
Stack structure,
abnormal SST fault, 3-27
data items on stack, 3-28
internal SST fault, 3-26
Status Control Block {SCB) ,
description, 4-19
relationship of, with I/O
control blocks, 2-6
required field, 3-7
role of, in I/O data

Status Control Block (SCB)
(Cont.)
structure, 2-20
Status Control Block (SCB)
field,
S.BMSK, 4-20
S.BMSV, 4-20
S.CON, 3-7, 4-22
S;>CSR, 3-7, 4-22
S. CTM, 4-21
S.FRK, 3-7, 4-23
S.ITM, 3-7, 4-21 to 4-22
S.LHD, 3-7 to 3-8, 4-2, 4-20
S.MPR, 3-7, 4-23, B-1 to B-2
S.PKT, 4-23
S • PR I , 3-7 , 4- 21
S.RCNT, 4-20
S.ROFF, 4-20
S.STS, 3-7, 4-22
S.VCT, 3-7, 4-21
$STKDP pointer,
use of, in fault tracing,
3-23
$STMAP routine, 5-26,
B-2 to B-3
use of, to obtain UMRs, B-1
$STMP1 routine, 5-27,
B-2 to B-3
use of, to obtain UMRs, B-1
$STPCT routine,
use of, by ACP, D-7
$SWSTK routine, 5-28
Symbolic offsets,
for system data structures,
C-1
SYSCM,
See System common
SYSTB file,
creation of, by SYSGEN, 3-1
System common (SYSCM) ,
use of, in fault isolation,
3-23
System common (SYSCM) pointer,
$CRAVL, 3-28
$HEADR, 3-24, 3-27
$PKAVL, 3-28
$STKDP, 3-23, 3-27
$TKTCB, 3-24, 3-27
System data structure macro
definition, C-1
ABODF$, C-3
CLKDF$, C-4
DCBDF$, C-6

Index-5

EPKDF$,

C~7

FllDF$,
HDRDF$,
HWDDF$,
ITBDF$,
LCBDF$,

C-14
C-19
C-21
C-24
C-25

INDEX

System data structure macro
(Cont.}
MTADF$, C-26
PCBDF$, C-30
PKTDF$, C-32
SCBDF$, C-37
TCBDF$, C-39
UCBDF$, C-42
System generation,
incorporating driver, 3-1
System state register
convention, 5-1

U.CTL, 2-9, 3-7, 4-10, 4-27
U.CWl, 3-7, 4-29
u.cw2, 3-7, 4-30
U.CW3, 3-7, 4-30
U.CW4, 3-7, 4-31
U.DCB, 3-6 to 3-8, 4-9, 4-27
U.ERHC, 4-25
U.ERHL, 4-24
U.ERSC, 4-24
U.ERSL, 4-24
u. roe, 4-24
U.LUIC, 4f-25
U.MUP, 4-25
U.OWN, 4-27
U.RED, 3-7 to 3-8, 4-27
U.SCB, 3-7 to 3-8, 4-31
U.ST2, 3-7, 4-29
U.STS, 3-7, 4-28
U.UNIT, 3-7, 4-29
UNL command,
unloading driver, 3-2
USRTB file,
content, 3-12
$USRTB label, 3-13

Task header,
mapped system, 3-25
role of, in I/O data
structure, 2-19
unmapped system, 3-24
$TKTCB pointer,
use of, in fault tracing,
3-24
Transfer function,
processing, 4-13
TTDRV,
LOA special case, 3-5

Volume Control Block (VCB),
role of, in I/O data
structure, 2-20
1

UCB,
See Unit Control Block
UNIBUS Mapping Register,
static allocation of, during
system generation, B-4
Unit Control Block (UCB),
description, 4-23
figure, 4-26
negative offset, 4-9
relationship of, with I/O
control blocks, 2-6
required field, 3-7
role of, in I/O data
structure, 2-20
with ACP, D-9
Unit Control Block (UCB) field,
U.ATT, 3-7, 4-31
U.BUF, 4-31
U.CLI, 4-25
U.CNT, 4-32, B-1

Window Block (WB) ,
role of, in I/O data
structure, 2-19 to 2-20

XDT,
See Executive Debugging Tool
$xxDAT label, 3-9
$xxEND label, 3-9
$xxINP symbol, 3-5
$xxINT symbol, 3-5
$xxOUT symbol, 3-5
$xxTBL label,
on driver dispatch table
(DDT), 4-10
$xxTBL symbol, 3-5

Index-6

RSX-llM
Guide to Writing
an I/0 Driver
Order No. AA-2600E-TC

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

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

Did you find errors in this manual? If so, specify the error and the page number.

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

D
D
D
D
D
D

Assembly language programmer
Higher-level language programmer
Occasional programmer (experienced)
User with little programming experience
Student programmer
Other (please specify)

Organization
Street
State _ _ _ _ _ _ Zip Code _ _ _ _ __
or Country

Do Not Tear- Fold Here and Tape
No Postage
Necessary
if Mai led in the
United States

11111

BUSINESS REPLY MAIL
FIRST CLASS PERMIT N0.33 MAYNARD MASS.
POSTAGE WILL BE PAID BY ADDRESSEE

BSSG PUBLICATIONS ZK1-3/J35
DIGITAL EQUIPMENT CORPORATION
110 SPIT BROOK ROAD
NASHUA, NEW HAMPSHIRE 03061

- -

Do Not Tear - Fold Here

....