2270512B_DNOS_System_Design__Nov83 2270512B DNOS System Design Nov83

2270512B_DNOS_System_Design__Nov83 2270512B_DNOS_System_Design__Nov83

User Manual: 2270512B_DNOS_System_Design__Nov83

Open the PDF directly: View PDF .
Page Count: 694

Download
Open PDF In Browser	View PDF

DNOS

System
Design Document
Part No. 2270512·9701 *8
15 November 1983

TEXAS INSTRUMENTS

All Rights Reserved, Printed in U.S.A.
The information and/or drawings set forth in this document and all rights in and to inventions disclosed
herein and patents which might be granted thereon disclosing or employing the materials, methods,
techniques or apparatus described herein, are the exclusive property of Texas Instruments
Incorporated.

MANUAL REVISION HISTORY
DNOS System Design Document (2270512-9701)

Original Issue .................................. . 1 August 1981
Revision . ....................................... 1 October 1982
Revision . ....................................... 15 November 1983

The total number of pages in this publication is 706.

The computers offered in this agreement, as well as the programs that TI has created to use
with them, are tools that can help people better manage the information used in their business; but tools-including TI computers-cannot replace sound judgment nor make the
manager's business decisions.
Consequently, TI cannot warrant that its systems are suitable for any specific customer
application. The manager must rely on judgment of what is best for his or her business.

DNOS Software Manuals
N
N

.......

This diagram shows the manuals supporting ONOS, arranged according to user type. Refer to the block identified by your user
group and all blocks above that set to determine which manuals are most beneficial to your needs .

~
N

to
.......

All DNOS Users:

~
ONOS Concepts and Facilities
2270501·9701

ONOS System Command
Interpreter (SCI) Reference Manual
2270503-9701

ONOS Messages and
Codes Reference Manual
2270506·9701

ONOS Operations Guide
2270502·9701

ONOS Text Editor
Reference Manual
2270504·9701

ONOS Reference Handbook
2270505·9701

High-Level
Language Users:
COBOL Reference Manual
2270518·9701
ONOSCOBOL
Programmer's Guide
2270516·9701
ONOS Performance
Package Documentation
2272109·9701
TI Pascal Reference Manual
2270519·9701
ONOS TI Pascal
Programmer's Guide
2270517·9701
FORTRAN·78 Reference
Manual
2268681·9701

. Assembly
Language Users:
990/99000 Assembly

Language Reference
Manual
2270509·9701
ONOS Assembly
Language
Programmer's Guide
2270508·9701
ONOS Link Editor
Reference Manual
2270522·9701
ONOS Supervisor Call
(SVC) Reference
Manual
2270507·9701

Productivity
Tools Users:

ONOS ONCS/SNA
User's Guide
2302663·9701

ONOS System Generation
Reference Manual
2270511·9701

ONOSTIFORM
Reference Manual
2276573·9701

ONOSONCS
Operations Guide
2302662·9701

ONOS Systems
Programmer's Guide
2270510·9701

ONOS Query-990
User's Guide
2276554·9701

ONOS ONCS 914A
User's Guide
2302664·9701

ONOS Data Base
Management System
Programmer's Guide
2272058·9701

ONOS 3270 Interactive
Communications Software
(ICS) User's Guide
2302670·9701

ONOS Online Diagnostics
and System Log Analysis
Tasks User's Guide
2270532·9701

ONOS Data Base
Administndor User's
Guide
2272059·9701

ONOS 3780/2780
Emulator User's Guide
2270520·9701

Data Dictionary
User's Guide
2276582·9701

MATHSTAT·78
Programmer's Reference
Manual
2268687·9701

ONOSTIPE
Reference Manual
2308786·9701

TI BASIC Reference Manual
2308769·9701
RPG II Programmer's
Guide
939524·9701

Security
Managers:
ONOS Security
Manager's Guide
2308954·9701

Systems
Programmers:

ONOS Sort/Merge
User's Guide
2272060·9701

ONOS FORTRAN·78
Pr3rammer's Guide
22 680·9701

FORTRAN·78 ISA
Extensions Manual
2268696·9701

Communications
Software Users:

ONOS Master Index to
Operating System Manuals
2270500·9701

ONOSTIPE
Exercise Guide
2308787·9701
ONOS COBOL Program
Generator User's Guide
2234375·9701

ROM Loader User's Guide
2270534·9701

ONOS ONCS System
Generation Reference
Manual
2302648·9701
ONOS ONCS X.25
Remote File Transfer
(RFn User's Guide
2302640·9701
ONOS Remote Terminal
Subsystem (RTS)
User's Guide
2302676·9701

Source
Code Users:
ONOSSystem
Design Document
2270512·9701
ONOS SCI and Utilities
Design Document
2270513-9701

DNOS Software Manuals Summary
Concepts and Facilities
Presents an overview of DNOS with topics grouped by operating system functions. All new users (or
evaluators) of DNOS should read this manual.
ONOS Operations Guide
Explains fundamental operations for a DNOS system. Includes detailed instructions on how to use each
device supported by DNOS.
System Command Interpreter (SCI) Reference Manual
Describes how to use SCI in both interactive and batch jobs. Describes command procedures and gives
a detailed presentation of all SCI commands in alphabetical order for easy reference.
Text Editor Reference Manual
Explains how to use the Text Editor on DNOS and describes each of the editing commands.
Messages and Codes Reference Manual
Lists the error messages, informative messages, and error codes reported by DNOS.
ONOS Reference Handbook
Provides a summary of commonly used information for quick reference.
Mastor Index to Operating System Manuals
Contains a composite index to topics in the DNOS operating system manuals.
Programmer's Guides and Reference Manuals for Languages
Contain information about the languages supported by DNOS. Each programmer's guide covers operating system information relevant to the use of that language on DNOS. Each reference manual covers
details of the language itself, including language syntax and programming considerations.
Performance Package Documentation
Describes the enhanced capabilities that the DNOS Performance Package provides on the Model 990/12
Computer and Business System 800.
Link Editor Reference Manual
I Describes how to use the Link Editor on DNOS to combine separately generated object modules to
form a single linked output.
Supervisor Call (SVC) Reference Manual
Presents detailed information about each DNOS supervisor call and DNOS services.
DNOS System Generation Reference Manual
Explains how to generate a DNOS system for your particular configuration and environment.
User's Guides for Productivity Tools
Describe the features, functions, and use of each productivity tool supported by DNOS.
User's Guides for Communications Software
Describe the features, functions, and use of the communications software available for execution
under DNOS.
Systems Programmer's Guide
Discusses the DNOS subsystems and how to modify the system for specific application environments.
Online Diagnostics and System log Analysis Tasks User's Guide
Explains how to execute the online diagnostic tasks and the system log analysis task and how to interpret the results.
ROM loader User's Guide
Explains how to load the operating system using the ROM loader and describes the error conditions.
DNOS Design Documents
Contain design information about the DNOS system, SCI, and the utilities.
ONOS Security Manager's Guide
Describes the file access security features available with DNOS.

2270512·9701

DNOS System Design Document

PREFACE
This DNOS system design document contains the information that is
needed to understand the operation
of
the
system
but
is
not
provided
in other DNOS manuals.
The document describes the flow
of control of the operating system in general and of each of
its
subsystems
in
particular.
It
also
includes
data
structure
pictures,
link
streams,
and
directory
information
for
DNOS
modules.
Revisions made to this manual since DNOS 1.1 are marked
with revision bars in the margins.
This manual is divided into the following sections:
Section
1

How to Use the Design Document -- Explains how to use
this manual.

Overview of DNOS -- Discusses
the DNOS system.

Naming
and
Coding
Conventions
Explains
conventions used in writing DNOS modules.

DNOS Structure and Nucleus Functions -- Discusses the
overall structure of DNOS, COmmon interface routines,
map
file
usage,
major
data
structures, and queue
server structures.

IPL and System Loaders
Describes
the
Initial
Program Load and the structures
system loading.

SVC Processing -- Discusses the preprocessing done by
the system, the
several
paths
of
control
through
supervisor
call
(SVC)
processing,
and how new SVC
processors can be added to DNOS.

Segment
Management
Explains
the
structures,
function, and use of segment management facilities of
DNOS.

Job Management -- Discusses the job
management
flow
of
control
and the data structures that support job
management.

Program Management -- Describes the flow
of
control
and
the
data structures used by DNOS in controlling
bidding, loading, and synchronizing tasks.

2270512-9701

the general

features

of
the

process
of
that support

DNOS System Design Document

I/O Subsystem -* Reviews the overall
I/O
processing
structure
and the details of handling of device I/O,
I/O utility calls, interprocess communication
(IPC),
file security, and name management.

Disk Structures and File I/O ** Includes an
overview
of
file
management,
a
description of disk and inmemory file structures, and a detailed description of
key indexed file management.

DNOS System Tasks -- Discusses the
conventions
used
in
writing
DNOS
system tasks and provides detailed
descriptions of many system tasks provided with DNOS.

System Generation Utility -- Provides an overview
of
the system generation utility and the data structures
used.

Logging and Accounting
the
flow
of
control
accounting functions.

DNOS Performance Package -- Discusses the conventions
used in system source code to enable the
performance
package
and
describes
the
routines
executed
in
microcode.

DNOS Development
and
Analysis
Tools
Describes
several tools available' to Texas Instruments internal
users for development purposes only and several tools
and' command procedures available for general access.

Analyzing a
System
Crash -~
Describes
the
ANALZ
utility
functions and how to use them in analyzing a
system crash file or in studying a running system.

XOP Processing .- Describes
the
XOP
processors
DNOS and how to add a new XOP processor.

Special SVCs -Describes
operating system.

Linking Information for DNOS -~ Explains how to
link
DNOS
and
provides examples of link streams and link
maps from building a DSR link, a
link
of
a
system
task, and the link of the DNOS root.

DNOS
Source
Describes
the
Disk
Structure
-*
with a DNOS source
directories
and
files
provided
kit.

Texas Instruments

Describes the functions and
for
the
system
log and job

SVCs

used

only

in
the

2270512*9701

DNOS System Design Document

Data Structure Pictures
Provides
data
structure
pictures
for DNOS data structures commonly needed to
understand the system.

Keycap Cross-Reference - Discusses the generic
keycap
names
that
apply
to all terminals that are used for
keys on keyboards through out this manual.

For further information related to the use of DNOS, refer
following document and those shown in the frontispiece.
Title

Part Number

DNOS Source Installation Guide

2270512-9701

vii/viii

2270515-9701

the

DNOS System Design Document

TABLE of CONTENTS

TABLE of CONTENTS
Paragraph

Title

SECTION 1

HOW TO USE THE DESIGN DOCUMENT

SECTION 2

2•1
2.2
2.3
2.4

3•1

3.2
3.3
3.4
3.5
3.6

4.3

4.4
4.5
4 .5 • 1
4 .5 .2
4 .5 .3
4 .5 .4
4 .5 .5
'+.5.6
1+.5.7
1+ .6

4 .6. 1
4 .6 • 2
j~.6.3

•

......

2-2

NAMING AND CODING CONVENTIONS
3-1

3-4
3-6
3-10
3-13
3-13

DNOS STRUCTURE AND NUCLEUS FUNCTIONS

OVERVIEW
• • • • • • • •
• • •
SYSTEM MEMORY MAPPING
SYSTEM DATA STRUCTURES
• • • • • • •
SYSTEM FILES
•••••••••••
NUCLEUS SUPPORT FUNCTIONS
••••
Linkage Support
••••
• •••••••••
Queuing Support
•••
• • • • • • •
Synchronization and Coordination
Inhibiting Scheduling
•••
Map File Changing
•••••••••
Table Area Management
•••••••••••
System Crash Routine
• ••
• ••••••
NUCLEUS FUNCTIONS FOR TASK SCHEDULING AND
EXECUTION
Data Structures
Execution Priorities
Time Slicing
•• • •

2270512-9701

2-1
2-1

2-4

NAMES OF ROUTINES
•••••••••••
GLOBAL DATA AND STRUCTURE TEMPLATES
ASSEMBLY LANGUAGE CODING CONVENTIONS
PASCAL CODING CONVENTIONS
ERROR HANDLING
•• • • • •
GENERATING NEW ERROR CODES

SECTION 4

4•1
4.2

OVERVIEW OF DNOS

INTRODUCTION
•• • • •
GENERAL STRUCTURE
FLOW OF CONTROL OF DNOS
DXIO COMPATIBILITY

SECTION 3

Page

......

.......

...

4-1
4-1

4-3
4-4
4-6
4-6
4-7
4-8
4-8
4-9
4-9
4-12
4-12
4-13

4-14
4-16

TABLE of CONTENTS

4.6.4
4.6.5
4.6.6
4.7
4.7.1
4 .7 .2
4 .7 .3

4.8
4.9
4.10

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

Task Bid
Task Activation
Table Area Scheduling
INTERRUPT PROCESSING
Clock Interru~t Processor
Internal Interrupt Processor
••
Power-Up and Power-Down Interrupt Processors
SVC PROCESSING
••••••••••
TASK TERMINATION
• • • • • • • •
SPECIAL COpy ROUTINE

. . .. . .

SECTION 5

5.1
5.2
5.3
5 .3. 1

5.3.2
5.3.3
5.3.4
5.4
5.4.1
5.4.2
5.4.3
5.4.4
5.4.5
5.4.6
5.4.7
5.4.8
5.4.9
5.4.10
5.4.11
5.4.12
5.4.13

6.1
6.2
6 .3

6.4
6.5
6 .5 • 1
6 .5 .2
6 .5 .3

6.5.4
6.5.5
6.6
6 .6. 1
6 .6 .2

IPL AND SYSTEM LOADERS

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

IPL SEQUENCE
• • • • • •
•• •
SYSTEM LOADER OVERVIEW
SYSTEM LOADER DATA STRUCTURES
Disk Volume Information
••••••••••••
WCS File
••••••••••••••••••
Kernel Program File
•••••••••
System Loader Internal Working Storage
FLOW OF CONTROL THROUGH THE SYSTEM LOADER
Relocating ~he Loader
• ••
•• • •
Load Device Initialization
•••••••••
Opening a File for I/O
•••••••• ~
Loading the System Root
••••••••••••
Loading a Module
•••
••••••
•••
Initializing the Crash File
•••
• ••••
CPU Type Dependent Initialization
Loading the Special Table Areas
••••••
Loading the JCAs
••••••••••••••••
Loading the DSRs
••••••••••••••••
Loading Memory-Resident Tasks
• • • • •
Disk System Initialization
•••••••••
Installing Disk Volumes
•••••
• ••

...

SECTION 6

4-16
4-16
4-16
4-19
4-19
4-19
4-20
4-20
4-20
4-21

• • • • • •

5-1
5-2
5-5
5-5
5-6
5-6
5-7
5-7
5-8
5-10
5-10
5-11
5-11
5-13
5-13
5-13
5-14
5-14
5-15
5-15
5-16

SVC REQUEST PROCESSING

OVERVIEW OF SVC PROCESSING
•• • • • • • • • • • •
MODULES USED FOR REQUEST PROCESSING
• • • • •
••••••••••••••••
MAPPING STRUCTURE
DATA STRUCTURES USED FOR SVC PROCESSING
• • •
DETAILS OF SVC PROCESSING
• • •
• • •
Decoding Routine (RPROOT)
•••••••••
SVC Buffering Routine (RPBUF)
•••••••
Dequeuing and Unbuffering Routine (RPDQUE)
•••
Other Request Processor Support Routines
DNOS SVCs and Processors
•••
•••••••
USER-WRITTEN SVC PROCESSORS
• • • • • • •
User SVC Table
Processors for User-Written SVCs

......

6-1
6-3
6-5
6-5
6-8
6-8
6-10
6-10
6-11
6-11
6-14
6-14
6-18

2270512-9701

DNOS System Design Document

TABLE of CONTENTS

SECTION 7
7 •1
7 .2
7 .3
7 .4
7 .4 • 1
7 .4 .2
7 .4 .3
7 .4 .4
7 .4 .5
7 .4 .6
7 .4 .7
7 .4.8
7 .4.9
7.4.10
7.4.11
7.4.12
7.4.13
7.4.14
7 .5

SEGMENT MANAGEMENT

OVERVIEW
• • • • • • • • • • • • •
••••••••
ARCHITECTURE OF SEGMENT MANAGEMENT
SEGMENT MANAGEMENT DATA STRUCTURES
•••
SEGMENT MANAGEMENT ROUTINES
SVC Preprocessor (SMPREP)
•••
• •••
Change Segment Processor (SMCHGS)
•••••
Create Segment Processor (SMCRES)
•••••••
Reserve Segment Processor (SMRSVE)
•••••••
Release Reserved Segment Processor (SMRLSE)
Check Segment Status Processor (SMCHKS)
••
Forced Write Segment Processor (SMFWRS)
Release Job Segments Processor (SMJRLS)
••••
Set/Reset Modified and Releasable (SMMDFY)
•••
Bias Segment Address Within Task (SMBIAS)
•••
Set Exclusive Use of a Segment (SMEXCU)
••
Reset Exclusive Use of a Segment (SMREXC)
•••
Load a Segment (SMLOAD)
••••••••••
Unload a Segment (SMUNLD)
• ••
• •••
SEGMENT MANAGEMENT TABLE AREA
• • • • • •

SECTION 8

8.1
8.2
8.3
8.4
8.5
8.6
8.6.1
8.6.2
8.6.3
8.6.4
8.6.5
8.6.6
8 .6 • 7

8.6.8
8.6.9
8.6.10
8.6.11
8.7

9 •1

9.2
9.3
9 .3 • 1
9 .3 • 2

7-12

7-12
7-12
7-13

7-13
7-13
7-14

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

PROGRAM MANAGEMENT

OVERVIEW
• • • • • • • • • • • • • • • • • • • • •
DATA STRUCTURES USED BY PROGRAM MANAGEMENT
DETAILS OF PROGRAM MANAGEMENT ROUTINES
• • • •
Task Bid Processor (PMTBID)
• • • • • • • •
Task Loader (PMTLDR)
••••••••••••••

2270512-9701

7-2
7-3
7-3
7-4
7-7
7-9
7-9
7-10
7-10
7-11

JOB MANAGEMENT

JOB CONSTRUCT
• • • • • ••
•••••••
OVERVIEW OF JOB MANAGEMENT
••••••••
ARCHITECTURE OF JOB MANAGEMENT
••••••••
JOB MANAGEMENT DATA STRUCTURES
• ••
• ••
JOB STATES
••••••••••••••••••••
DETAILS OF JOB MANAGER ROUTINES
• • • • •
Job Manager Preprocessor (JMPREP)
•••••••
Job Manager Request Processing Task (JMMAIN)
••
Create Job Processor (JMC$)
••••••••••
Halt Job Processor (JMHALT)
•••
• ••
Resume Job Processor (JMRESU)
• • • • •
Modify Job Priority Processor (JMPRIO)
•••
Map Job Name Processor (JMMAP)
••••
• ••
Get Job Information Processor (JMINFO)
•••••
Kill Job Processor (JMKILL)
• • • • • • • •
Job Clean-Up Routine (JMD$)
••••••
Verify Job ID Routine (JMVRFY)
•••
IMPLICATIONS OF JOB BOUNDARIES
• • • •

SECTION 9

7-1
7-1

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

TABLE of CONTENTS

9 .3 .3
9.4
9 .4 • 1

9.4.2
9.4.3

Task Termination Processor (PMTERM)
TASK SYNCHRONIZATION
• • • •
Semaphores
•••••
Lo c k s
••••••••
Event Synchronization

.........

SECTION 10
10.1
10.2
10.3
10.3.1

I/O SUBSYSTEM

OVERVIEW.....
• ••
• ••••
DEVICE I/O DATA STRUCTURES
••
• • ••
••
DEVICE I/O HANDLING
•••••••••
• •••
Details of I/O System Routines
••
• ••
10.3~2
I/O Processing by the DSR
•••••••••••
10.3.3
Returning Information to the Requester
•••••
10.3.4
Bidding a Task from a DSR
•••••••••••
10.3.5
Handling Large I/O Buffers
•••••••••
10.3.6
Converting a DXI0 DSR for DNOS
•••
10.4
TELEPRINTER TERMINAL DSR
•••••••••
10.4.1
DSRTPD Structures
•••
• •••••
10.4.2
PDT Structures
•••••••
10.4.3
DSRTPD Functions
• • •
• ••
10.4.4
DSRTPD Details
• • • ••
• •••••••
10.4.5
DSRTPD Defaults
.••••••••••
10.5
ASYNCHRONOUS DSR STRUCTURE
••
• •••••••
10.5.1
Data Structures Linkage
•••
• ••••••
10.5.2
Data Structure Allocation
••
• ••••
10.5.3
PDT Extension Definitions
•••••••••
10.5.3.1
Asynchronous Local PDT Extension
•••••••
10.5.3.2
Asynchronous Long-Distance Device Extension
10.5.3.3
CI401 HSR Local Extension
••••••••••
10.5.3.4
CI401 HSR Long-Distance Extension
••
10.5.3.5
CI403/CI404 HSR Local Extension
•••••
10.5.3.6
CI403/CI404 HSR Long-Distance Extension
•••
10.5.3.7
9902/9903 HSR Local Extension
••••••••
10.5.3.8
9902/9903 HSR Long-Distance Extension
••••
10.5.3.9
931/940 TSR/ISR Local Extension
•••••••
10.5.3.10
931/940 TSR/ISR Long-Distance Extension
•••
10.5.3.11
Serial Printer HSR Local Extension
••••••
10.5.3.12
Serial Printer HSR Long-Distance Extension
••
10.6
I/O UTILITY (IOU)
••••••••••
10.6.1
Configurability
• • • •
• •••
10.6.2
Memory Layout
••••••••
• ••••
10.6.3
Structures Maintained by IOU
••
10.6.3.1
Directory Tree Construction
••
• ••
10.6.3.2
LDT Structure
••••••••••••••••
10.6.4
Details of IOU Processing
•••••••••
10.6.4.1
IOU Preprocessor (IUPREP)
••••••••
10.6.4.2
Initial Processing in
the IOU Task
•••••
10.6.4.3
Channel Operations
••••••••••••••
10.6.4.4
Concatenated Files and Multifile Sets
10.6.4.5
Temporary Files
••••••••
• ••
10.6.5
Operating System Support SVCs
•••••••
xii

9-6
9-7
9-7
9-8
9-9

10-1
10-2
10-4
10-4
10-8
10-11
10-13
10-14
10-16
10-22
10-23
10-22
10-25
10-25
10-27
10-27
10-31
10-31
10-31
10-32
10-35
10-37
10-39
10-41
10-43
10-44
10-46
10-48
10-51
10-54
10-56
10-57
10-58
10-58
10-58
10-60
10-61
10-64
10-64
10-66
10-66
10-68
10-69
10-70

2270512-9701

DNOS System Design Document

TABLE of CONTENTS

10.7
DEVICE I/O UTILITY (DIOU)
••••••••••
10.7.1
DIOU Functions
•••••
• •••••••
10.7.2
DIOU Data Base
•• ••
•••
• •••••
10.7.3
Data Structures Used by DIOU
•••
• ••••
10.8
FILE ACCESS SECURITY
•••••••••••••
10.8.1
Establishing a Job's Security Environment
•••
10.8.2
Enforcing Security
••• • • • • ••
••
10.8.2.1
File Manager
• • •
• •••••
10.8.2.2
Program Manager
•••
• •••••••
10.8.2.3
Segment Manager
•••
• •••••••••
10.8.2.4
Sysgen...
• ••••••••
10.8.3
Volume Security
• • •
• ••
10.8.4
Networking......
• ••••••••••
10.8.4.1
Manipulation of the Access Control List
•••
10.9
INTERPROCESS COMMUNICATION (IPC)
•••
10.9.1
IPC SVC Interface
•••••
• •••••••
10.9.2
Channel Characteristics
••••••••••
10.9.2.1
Symmetric Channel Activity
••••••
10.9.2.2
Master/Slave Channel Activity
••••••
10.9.3
Details of IPC Processing
••
• ••••
10.9.3.1
Structures Used for IPC Processing
••••
10.9.4
Detailed Operation of IPC Routines
•••
10.9.4.1
IPC Preprocessor (IPCPRE)
••••
10.9.4.2
IPC Queue Server (IPCTSK)
10.9.4.3
IPC XOP level request processor (IPCXOP)
10.9.4.4
IPC request processors (IPCPRO, IPCMRD and
IPCMWT)
•••••••••••
10.9.4.5
IPC Support Routines
•••••
10.10
NAME MANAGEMENT
••••••••••
10.10.1
Architecture of the Name Manager
•••
10.10.2
Data Structures Used by the Name Manager
10.10.3
Name Manager SVC Preprocessing
10.10.4
Details of Name Manager Modules
10.10.5
Stage Scope Rules
••••••

........

SECTION 11

10-90
10-92
10-94
10-95
10-95
10-99
10-100
10-105

DISK STRUCTURES AND FILE I/O

....

11. 1
OVERVIEW OF FILE MANAGEMENT
11 .2
STRUCTURE OF A NEW DISK
DISK DATA STRUCTURES
11 .3
•••
Volume Information
11.3.1
Allocation Bit Map
11.3.2
11 .4
FILE STRUCTURES
11.4.1
Relative Record Files
Unblocked Relative Record Files
11.4.1.1
Blocked Relative Record Files
11.4.1.2
11.4.2
Sequential Files
••••••••
11.4.3
Key Indexed Files
• • • • • • •
11.4.4
Program Files
• • • • • • •
11.4.5
Directory Files
• • • •
11.4.6
Image Files
••••••••••
11 .5
ALLOCATION OF SPACE FOR EXPANDABLE FILES

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

2270512-9701

10-70
10-71
10-71
10-72
10-76
10-76
10-78
10-78
10-79
10-79
10-80
10-80
10-80
10-80
10-82
10-83
10-83
10-83
10-86
10-87
10-87
10-88
10-88
10-89
10-90

xiii

•
•
•
•

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

11-1
11-1
11-2
11-4
11-4
11-5
11-5
11-5
11-6
11-7
11-10
11-13
11-21
11-23
11-23

TABLE of CONTENTS

11 .6
IN-MEMORY DATA STRUCTURES
XOP-Level Preprocessing
11.6.1
Task-Level Processing
11.6.2
Flow of Control in File Management
11.6.3
Overlay Management
• • • • • •
11.6.4
Buffer Management
••••••••
11.6.5
Details of I/O Sub-Opcode Processors
11.6.6
Read
11.6.6.1
11.6.6.2
Write
•••••••••••
Clo se
••••••••••••••••••
11.6.6.3
Multiple-Record Read
11.6.6.4
Multiple-Record Write
11.6.6.5
Lower Level Support Routines
11.6.7
Concatenated Files and Multifile Sets
11.6.7.1
Unblocked Relative Record Files
Blocked Relative Record Files
Sequential Files
Multifile KIF Sets
Closing Blocked Files
Unblocked Relative Record Files
11.6.7.2
Blocked Files
•••••••
11.6.7.3
Record Transfers
Relative Record Files
Sequential Files
Blank Adjustment
KIF MANAGEMENT
•• • •
11 .7
KIF Data Structures
11.7.1
KIF Management Code Structure
11.7.2
Details of KIF Operations
11.7.3
Close
••••••••••
11.7.3.1
Open Random
••••••••
•••
11.7.3.2
Rea~ Greater and Read Greater or Equal
••
11.7.3.3
Read by Key, Read Current, and Read by Primary
11.7.3.4

·.
·.

.....

....

Ke y

••••••

•••

. . . . . ·. .. . .

•

Read Next
•••••••••••••
11.7.3.5
Read Previous
• • • • • • • • ••
11.7.3.6
Insert
•••
• ••••••••
11.7.3.7
Rewrite
•••••••••••••••
11.7.3.8
Delete by Key and Delete by Current
11.7.3.9
Set Currency Equal, Greater, Equal or Greater
11.7.3.10
Forward Space, Backspace, Read ASCII, Rewind
11.7.3.11
Details of KIF Subroutines
•••••••••
11.7.4

SECTION 12
12 • 1
12.2
12.3
12.3.1
12.3.2
12.3.3
12.3.4

11-50
11-51
11-51
11-51
11-52
11-52
11-53
11-53
11-54

DNOS SYSTEM TASKS

SYSTEH TASK ENVIRONMENT AND CONVENTIONS
•••••
WRITING AND LINKING AN ASSEMBLY LANGUAGE TASK
USING OVERLAYS IN ASSEMBLY LANGUAGE SYSTEM TASKS
Overlay Data Structures
••••••
System Support Routines for Overlays
Size of Overlay Areas
•••••
Coding Overlays
•••
• ••••
xiv

11-26
11-30
11-32
11-32
11-36
11-39
11-40
11-40
11-41
11-41
11-41
11-42
11-42
11-42
11-42
11-42
11-43
11-43
11-43
11-43
11-43
11-43
11-44
11-44
11-44
11-44
11-45
11-48
11-49
11-50
11-50
11-50

12-1
12-1
12-2
12-2
12-3
12-4
12-4

2270512-9701

DNOS System Design Document

12.3.5
12.3.6
12.4
12.5
12.5.1
12.5.2
12.5.3
12.5.4

TABLE of CONTENTS

Calling Routines in an Overlay
Internal Design Considerations
WRITING AND LINKING A PASCAL SYSTEM TASK
DETAILS OF DNOS SYSTEM TASKS
Log-On Task (LOGON)
System Initialization Tasks (RESTART and
RESTART2)
RPRCP
IOBREAK

SECTION 13

14.1
14.2
14.2.1
14.2.2
14.3

13-1
13-1
13-3
13-3
13-3
13-5
13-5
13-5
13-6
13-6
13-6
13-6
13-7
13-7
13-7
13-9
13-11
13-12
13-12
13-13
13-15
13-15
13-16
13-17
13-17
13-18
13-19
13-19
13-20
13-21

LOGGING AND ACCOUNTING

LOGGING AND ACCOUNTING FUNCTIONS
LOGGING AND ACCOUNTING TASKS
LGFORM
LGACCT
SUPPORT ROUTINES

2270512-9701

12-13
12-13
12-15

SYSTEM GENERATION UTILITY

13.1
OVERVIEW
SYSJEN STRUCTURE
13.2
DETAILS OF THE SYSJEN ROOT PHASE
13.3
STOPRT
13.3.1
Support Routines
13.3.2
13.4
DETAILS OF THE INITIALIZATION PHASE
13.4.1
INIT
13.4.2
INITAL
13.4.3
INITCN
13.4.4
INITDB
INITHD
13.4.5
13.4.6
INITOP
DETAILS OF THE INTERACTIVE PHASE
13 .5
General Support Routines
13.5.1
Asking System Questions
13.5.2
Defining Structures
13.5.3
Changing Structures
13.5.4
Deleting Structures
13.5.5
Listing
Structures
13.5.6
DETAILS OF THE BUILDING PHASE
13.6
JENDAT FILE
13.7
Interactive Use of the JENDAT File
13.7.1
Number Questions
13.7.1.1
Name Questions
13.7.1.2
Element Questions
13 .. 7 • 1 .3
Pathname Questions
13.7.1.4
Yes/No Questions
13.7.1.5
BUILD Use of the JENDAT File
13.7.2
Sample Copy Module
13.7.3
JENDAT EDITOR
13.8

SECTION 14

12-6
12-6
12-7
12-9
12-11

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

TABLE of CONTENTS

14.4

SECTION 15

15.1
15.2
15.3
15.4
15.4.1
15.4.2
15.4.3
15.4.4
15.4.5

17 • 1

1 7 .4

15-1
15-1
15-2
15-3
15-3
15-3
15-4
15-4
15-4

DEVELOPMENT AND ANALYSIS TOOLS

OVERVIEW
• • • • • • • • • • •
• • • •
SHOW RELATIVE TO FILE INTERACTIVELY UTILITY (SRF1)
THE TIGRESS TEST FACILITY
• • ••
• •
Details of Tigress Commands
••
Directives of Tigress
•••
User Defined Commands For Tigress
THE SYSTEM DEBUG UTILITY
•• • • •
Details of Debug Commands
•••••••••••
Establishing the Debug Environment
THE PICT UTILITY
•• • • • • • • • • • • • • • • •
Assembly Language Output
• • • • • • • • • •
Pascal Template Output
• ••
••• • • •
PICT Picture Output
••••••••••
• •
Input Format
••••••••••••••••••
THE JENDAT EDITOR
••••••••••••••
XJENED Command Procedure
JENED Commands
EDIT Command
PRINT Command
QUIT Command
REMOVE Command
SHOW Command
VERSION Command
MOVE Command

. . .. ..

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

... .. ..
. . · . .. .. ..
. . . . .· .. .. . .
·....

SECTION 17

17 .2
17 .3

14-3

DNOS PERFORMANCE PACKAGE

OV E RV I EW
• • ••
•••••••• • • •
DNOS SOURCE CONVENTIONS
• • • • • • • • • • •
••••••••••••
MICROCODE CHARACTERISTICS
MICROCODE CODING CONVENTIONS
• • • • • • •
Standard Syntax For Microcode States
••••
Labeling Conventions
• • • • • • • • ••
Commenting Conventions
• • • • • • • • • • •
Common Routines
• • ••
••••••
Debugging
••••••
• ••••••••

SECTION 16

16.1
16.2
16.3
16.3.1
16.3.2
16.3.3
16.4
16.4.1
16.4.2
16.5
16.5.1
16.5.2
16.5.3
16.5.4
16.6
16.7
16.8
16.8.1
16.8.2
16.8.3
16.8.4
16.8.5
16.8.6
16.8.7

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

MISCELLANEOUS MODULES

16-1
16-1
16-2
16-4
16-12
16-13
16-13
16-14
16-19
16-22
16-25
16-27
16-30
16-33
16-35
16-35
16-36
16-37
16-40
16-40
16-40
16-41
16-41
16-41

ANALYZING A SYSTEM CRASH

OVERVIEW
• • • • • • • • •
DETAILS OF CRASH ANALYSIS COMMANDS
GUIDELINES FOR CRASH ANALYSIS
HARDWARE TRACE INFORMATION
•• • •

xvi

......

17-1
17-3
17-12
17-14

2270512-9701

DNOS System Design Document

SECTION IB

IB.l
18.2
18.3

IB.3.1
18.3.2

TABLE of CONTENTS

INTERRUPTS AND XOP PROCESSING

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

OVERVIEW OF INTERRUPT PROCESSING
OVERVIEW OF XOP PROCESSING
•••
BUILDING AN XOP PROCESSOR
•••
System Generation Requirements for User XOPs
XOP Processor Details
•••••••••••

SECTION 19

•••••••••

•

••

•••

19.2.7.1
Write UART Registers
•••••••••••
19.2.7.2
Read UART Registers
•••••••••••
19.2.B
TILINE Diagnostic Port (Subopcode )16)
•••
19.2.9
Read with Initial Value (Subopcode )17)
••
19.2.10
Assign Diagnostic Device (Subopcode )94)
••
19.2.11
Attach File (Subopcode)AO)
••••
19.2.12
Detach File (Subopcode )Al)
••••••••
19.2.13
Detach File by Number (Subopcode )A3)
•••
19.2.14
Modify FDR Bit (Subopcode )A4)
•••••.••
19.2.15
Release LUNO in Another Job (Subopcode )A5)
19.2.16
Assign System LUNO FF (Subopcode )A6)
•••••
19.2.17
Release File Structures (Subopcode )A7)
••
19.2.1B
DIOU Operations (Subopcodes )C2, )C3, )C6, )C7)
19.2.18.1
)C2 - Get Selected Device Parameters
•••
19.2.18.2
)C3 - Set Selected Device Parameters
•••
19.2.18.3
)C6 - Get CDE From CDT
•• • ••
• ••
19.2.18.4
)C7 - Process Device Task Bid
••••••
19.3
SPECIAL FEATURE OF EXECUTE TASK SVC
•••
19.4
SEGMENT MANAGEMENT
•••••••••
• ••
19.5
NAME MANAGEMENT
•••••••
• •••••
2270512-9701

xvii

IB- 2
1B-3

SPECIAL SVCs

OVERVIEW
•• • • • • • • • • • • • • • • • • •
19.1
I/O SVCs
•••••
• •••••••••••
19.2
DSRTPD
Diagnostics
Control
(Subopcode )OB)
•••
19.2.1
Write Interface Image
••••••••••••
19.2.1.1
Read Interface Image
•• • • • • • • •
19.2.1.2
Communications DSR Diagnostics Control
19.2.2
(Subopcode )OB)
••••••••••
Open Unblocked (Subopcode )13)
••••
• ••
19.2.3
Close Without Updating FDR (Subopcode )14)
•••
19.2.4
DSRTPD Communications Control - (Subopcode )15)
19.2.5
Set File Transfer Parameters )lC
•••••
19.2.5.1
Modify Timing Characteristics )16
••
19.2.5.2
Modify Line Chara~teristics )17
•••
••
19.2.5.3
Modify Terminal Type )18
••
• ••••••
19.2.5.4
Modify Special Characters )19
••••••••
19.2.5.5
Connect )IA
•••••••••••••••••
19.2.5.6
Flush Character Queue )lB
••••
19.2.5.7
Set Exclusive Access )lD
•••••••••
19.2.5.B
Set Shared Access )lE
••••••••••
19.2.5.9
VDT Extended Edit Flags (Subopcode )15)
••
19.2.6
Asynchronous Multiplexor Operation (Subopcode
19.2.7
) 15 )

1B-1
1B-2
1B-2

19-1
19-1
19-1
19-2
19-3
19-4
19-5
19-5
19-6
19-7
19-7
19-B
19-8
19-9
19-9
19-10
19-10
19-10
19-10
19-11
19-12
19-14
19-16
19-20
19-21
19-22
19-23
19-24
19-25
19-26
19-27
19-2B
19-2B
19-31
19-32
19-33
19-34
19-34
19-35
19-35

TABLE of CONTENTS

··

Determine Next Pathname (Subopcode >01)
19.5.1
(Subopcode > 03)
Append Pathname to Name
19.5.2
(Subopcode
Return Next Name
>05)
19.5.3
Purge Names
(Subopcode >06)
19.5.4
(Subopcode >07)
Enter New Stage
19.5.5
Return to Previous Stage
(Subopcode >08)
19.5.6
19.5.7
Return Next Error Entry (Subopcode >09)
Determine Segment Size (Subopcode >OA)
19.5.8
Copy Name s to New Segment (Subopcode >OB)
19.5.9
Creating an Empty Name Segment (Subopcode >OD)
19.5.10
Saving a Name Segment (Subopcode >OE)
19.5.11
MODIFY BTA OR JCA SIZE
19.6
HALT/RESUME TASK
19.7
•
EXPAND JCA
19.8

·· ··
·
·
·
· · ·· ·· ·· ··

··
·· ··
·· · ·· ·
·

··
·
·
·
·
·
·
...
. . . . . . . . ·· ·· · · ·· ·· · ·· ·· ·· ·· ··

SECTION 20
20.1
20.2
20.3
20.4
20.5

LINKING INFORMATION FOR DNOS

OVERVIEW
• • • • ••
•••••••••
LINKING A SYSTEM TASK
• • • •
LINKING A DSR
••••••••••
LINKING THE DNOS SEED
••
LINK CONTROL FILES BUILT DURING SYSTEM GENERATION

SECTION 21
21 • 1
21.2
21.3
21.4

DIRECTORY STRUCTURE
••••••
COMPONENTS USED IN BUILDING DNOS
THE PROCEDURE FOR BUILDING DNOS
DNOS PROGRAM FILES
••••••••

OV ERV I E W

·.....

21-1
21-3
21-8
21-8

DATA STRUCTURE PICTURES

OVERVIEW
•• • • • • • • • • • •
STRUCTURES FROM THE COMMON DIRECTORY
STRUCTURES FROM THE ATABLE DIRECTORY

APPENDIX A
A. 1

·.

20-1
20-2
20-3
20-4
20-6

DNOS SOURCE DISK STRUCTURE

SECTION 22
22.1
22.2
22.3

19-41
19-42
19-43
19-44
19-45
19-45
19-47
19-47
19-48
19-48
19-49
19-50
19-51
19-52

·....

22-1
22-6
22-27

KEYCAP CROSS-REFERENCE

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

xv iii

A-I

2270512-9701

DNOS System Design Document

LIST of FIGURES

LIST of FIGURES
Figure
2-1
4-1
4-2
5-1
6-1
6-2
6-3
7-1
7-2
7-3
7-4
7-5
7-6
7-7
9-1
10-1
10-2
10-3
10-4
10-5
10-6
10-7
10-8
10-9
10-10
10-11
10-12
10-13
10-14
11-1
11-2
11-3
11- 4
11-5
11-6
11-7
11-8
11-9
11-10
11-11
11-12
11-13
11-14
11-15
11-16
11-17
11-18

Page

Title
Flow of Control in DNOS
DNOS Nap Files •
Flow of Control in Task Scheduling •
System Loader Subroutine Calls •
SVC Entry Form in RPSTAB •
Examples of RDB and RIB Structures
Format of RPUDAT Module
Flow of Control in Segment Manager
Flow of Control in Change Segment
Flow of Control During Initial Load
Flow of Control in Create Segment
Flow of Control in Forced Write
Flow of Control in Release Job Segments
Segment Manager Table Organization •
Flow of Control in Task Loader •
Overview of Device I/O Handling
Beginning Device Request Processing
DSR Control Paths
Returning Information to the Requester •
Device I/O Buffering •
DSR Link Control Stream
DSR Structure
Asynchronous Data Structure Linkages •
Asynchronous Local PDT Extension •
Asynchronous Long-Distance PDT Extension
LDT Chains •
Symmetric Channel States •
Owner SVCs for Master/Slave Channels •
Name Segment Structure •
Sequential File Format •
Blank-Suppressed Record
Key Indexed File B-Tree
Program File Format
Program File Available Space List
Task Description Entry •
Procedure/Segment Description Entry
Overlay Description Entry
Directory File Structure •
Computing a Hash Key •
Dump of Directory File •
In-Memory File Representation
Flow of Control in File Management •
Overlay Area Structure •
Buffered KIF Request •
KIF Currency Block •
Example of Root Node Split •
Example of Regular B-Tree Node Split

2270512-9701

xix

•

2-3
4-3
4-18
5-8
6-6
6-7
6-17
7-4
7-6
7-7
7-8
7-11
7-12
7-15
9-6
10-4
10-5
10-11
10-13
10-16
10-21
10- 28
10-33
10-34
10-36
10-63
10-85
10-87
10-96
11-8
11-10
11-12
11-14
11-16
11-17
11-19
11-20
11-22
11-22
11-25
11-27
11-33
11-38
11-45
11-47
11-55
11-56

LIST

12-1
16-1
16-2
16-3
18-1
19-1
19-2

Example of Link Control for System Task
PCKREC Input Format
• •
DORG Input Format
• •
Template Picture Format
XOP Processor
•
Write UART Register Format
•
Read DART Registers Format

···
..
·· ·· ··
.....
.. · · ·
···

FIGURES

· · ·•

·
···
· ·· ·· ·· ·· ·· ·· ·· ·•
·· ·· ·· · ·· · · · ·

12-2
16-34
16-34
16-35
18-4
19-13
19-15

2270512-9701

DNOS System Design Document

LIST of TABLES

LIST of TABLES
Table

1-1
3-1
3-2
3-3
5-1
6-1
6-2
6-3
6-4
10-1
10-2
10-3
10-4
10-5
11-1
11-2
11-3
11-4
11-5
12-1
12-2
15-1
16-1
16-2
16-3
16-4
16-5
16-6
17-1
17-2
18-1
21-1
21-2
21-3
22-1
22-2

Title

Page

Acronyms Used in this Manual
DNOS Subsystem Abbreviations
Major Directories of DNOS
Macros from DSC.MACROS.FUNC
System Loader Phases
• • • ••
• •
Major Request Processor Routines
••••••
SVC Processors and Modules
• ••
•• •
Request Definition Block (RDB) Format
Return Information Block (RIB) Format
••••
Location of Support Subroutines for DSRs
•••
Asynchronous DSR Module Functions
• • •
DSR/TSR Entry Points
••••••••••
• ••
Asynchronous Local PDT Extension Template
•••••
Asynchronous Long-Distance PDT Extension Template
Format Information for Available Disks
••••
Capabilities of Available Disks
••••
File Management Mod~les
••
••• • • •
KIF Main Routines
• ••
••••••
KIF Subroutines
• • • • • • • • • • •
DNOS System Tasks
•••••••
System Tasks to Support SCI and Utilities
Location of the Microaddress Bus
•••
Types of Arguments for Tigress Commands
•••
Predefined Labels for Tigress Commands
••••
Tigress Commands
•••••••••••••••
Parameter Types for Debug Commands
••••••
Commands for System Debug Program
•• • • • • • • •
Verbs Used in Generating Structures
••
• •••
Crash Analysis Commands
• • • • • • • • • • • •
Format of Hardware Trace Information
•••••
System Generation Prompts for XOPs
DNOS Batch Stream Files
•••
Map of Utility Program File
••••••
Map of System Program File
• • ••
••••
Template Acronyms
• • • • • • • ••
• •
Templates Described in SCI and Utilities Document

2270512-9701

xxi/xxii

1-2
3-2
3-3
3-10
5-3
6-4
6-12
6-15
6-16
10-21
10-29
10-30
10-35
10-36
11-3
11-3
11-28
11-48
11-49
12-10
12-11
15-5
16-5
16-5
16-7
16-14
16-15
16-24
17-3
17-15
18-3
21-6
21-9
21-11
22-3
22-5

DNOS System Design Document

SECTION 1
HOW TO USE THE DESIGN DOCUMENT
The description of DNOS design is divided into sections according
to
major
operating
system functions.
The nucleus routines are
described first, along with their data structures and the overall
operating system structure.
This section is followed by separate
sections describing each of the major subsystems in DNOS.
For an
overview of all subsystems, skim through this
document,
reading
carefully
the
overview
portion of each subsystem section.
For
details on a particular subsystem or module within
a
subsystem,
consult
the
detailed
diagrams
and
discussion that follow the
overview.
Section 3 details naming conventions for the DNOS modules.
When
searching
for
details about a particular module, use the module
name to determine which subsystem description is
relevant.
For
details
about particular data structures being used, consult the
section on data structure pictures.
The section on linking information provides example link
control
streams used to build pieces of the operating system.
To build a
device service routine (DSR) or a new system task, use these link
examples
as a guide in building the required link streams.
Link
streams are also shown for several other parts of
the
operating
system
to
show how these pieces are structured.
The DNOS link
streams should be considered the primary
source
of
information
about
the
modules
included
to
support
a
particular task or
subsystem.
The link streams are also the primary source for full
pathnames for modules in DNOS.
Most data structure pictures in this document are built
directly
from the templates copied into operating system source code.
The
structures
are
shown
with
hexadecimal
byte
counts,
special
comments, flags, and a diagram.
Most of the special terms used to describe DNOS can be
found
in
the
glossary
in the DNOS Concepts and Facilities manual.
Other
terms are defined in this document as they are needed.
Acronyms'
for system structures and routine names are introduced at various
points
throughout
the
manual.
If you read a section from the
manual without reading all preceding sections, an acronym may
be
encountered
without
an
explanation
of its meaning.
Table 1-1
lists most of the acronyms used in the
manual.
Refer
to
this
list
in conjunction with the glossary for a complete description
of the term.

2270512-9701

1-1

How to Use

DNOS System Design Document

Table 1-1
Acronym
ACC
ADR
ADU
BRB
BRO
BTA
BTB
CCB
CDE
CDR
CDT
DIA
DIB
DOR
DPO
DPR
DSR
FCB
FOB
FDR
FlO
FIR
FMT
FSC
IOU
IPC
IRB
JCA
JIT
JMR
JSB
KCB
KDB
KDR
KIB
KIT
KSB
LDT
LFD
LPO
LSE
MRB
NOB
NDS

How to Use

Acronyms Used in this Manual
Meaning

Accounting record contents
Alias descriptor record
Allocatable disk unit
Buffered request block
Buffered request overhead
Buffer table area
B-tree block
Channel control block
Command definition entry
Channel descriptor record
Command definition table
Diagnostic status
Device information block
Directory overhead record
Disk PDT extension data
DIOU Device Parameters
Device Service Routine
File control block
File directory block
File descriptor record
File identification
File information record
File management task area
File structure common
I/O utility task
Interprocess Communication
I/O request block
Job communication area
Job information table
Job manager request block
Job status block
KIF currency block
KIF descriptor block
Key descriptor record
KIF information block
KIF task area
Keyboard status block
Logical device table
Log file definition
Line printer PDT extension
Load segment entry
Master Read/Master Write buffer
Name definition block
Name definition segment

1- 2

2270512-9701

DNOS System Design Document

Table 1-1 Acronyms Used in this Manual (Continued)
Acronym
NRB
OAD
OAW
OSE
OVB
OVT
PBM
PDT
PFI
PFZ
PRM
QHR
RDB
RIB
RLT
ROB
ROM
RPB
RST
SAT
SCO
SCI
SDB
SGB
SLB
SMT
SOB
SSB
STA
STE
TDL
TOL
TPCS
TSB
UDR
WCS
WOM
XTK

2270512-9701

Meaning
Name manager request block
Overlay area description
Overlay area wait block
Owned Segment Entry
Overhead beet
Overlay table entry
Partial bit map
Physical device table
Program file directory index
Program file record zero
DIOU/IOU Parameters
Queue header
Request definition block
Return information block
Record lock table
Resource ownership block
Read-only memory
Resource privilege block
Reserve segment table
Secondary allocation table'
Track 0, sector 0 format
System Command Interpreter
Stage descriptor block
Segment group block
System log block formats
Segment manager table
Segment Owner block
Segment status block
System table area
Swap table entry
Time delay list entry
Time-ordered list
TILINE peripheral control space
Task status block
User descriptor record
Writable control store
Waiting for memory queue
Extension for a terminal with keyboard

1-3/1-4

How to Use

DNOS System Design Document

SECTION 2
OVERVIEW OF DNOS

2.1

INTRODUCTION

DNOS, a general purpose operating system for the 990 computer, is
designed to meet
a
variety
of
computing
needs.
DNOS
is
a
configurable
operating
system, allowing users to generate small
systems with minimal
software
development
capability;
medium~
range systems with a limited number of options; and large systems
with a wide variety of system options.
Among
the
special
features
available for DNOS are program and
overlay loading, program swapping, key indexed files, dynamic job
creation,
output
spooling,
dynamic
system
configuration,
interprocess
communication (IPC), multiprogramming support, file
access security, and a wide variety of utilities.
A performance package is available for DNOS.
It
uses
microcode
implementations
of
a
number
of
DNOS
routines to enhance the
processing speed of DNOS.

2.2

GENERAL STRUCTURE

DNOS is composed of memory-resident and disk-resident code.
portion includes the following:

The

memory~resident

*
*
*
*
*

Many supervisor call (SVC) processors

Task scheduler

*
*

Nucleus support functions

Device service routines
Interrupt processors
Extended operation (XOP) processors
System tables and device buffers

Memory-resident tasks

2270512-9701

2-1

Overview

DNOS System Design Document

These
parts
are
~inked
when
DNOS
is generated, and they are
loaded into memory
during
initial
program
load
(IPL).
This
memory-resident
portion
is
referred
to as the kernel of DNOS.
The first portion of the kernel is referred to as
the
root;
it
forms
the
first
segment
of
the
mapping structure for kernel
activities and for system tasks.
Disk-resident parts of DNOS include system tasks and overlays for
some system tasks.
These tasks include the I/O Utility, the
Job
Manager,
and
a
number
of miscellaneous SVC processors.
These
tasks
are
loaded
into
memory
whenever
their
services
are
required.
Most
of
the DNOS functions are performed by routines that serve
queues of requests.
A queue is a
f~rst-in,
first·out
list
of
data
to
be
processed.
Each queue consists of a queue anchor,
from which blocks of data are linked.
Most
queue
anchors
are
located
in the system root; those for file management are in the
job communication area of the user job.
The
queues
are
singly
linked,
and the anchor points to the first data block, the first
block points to the second, and so on.
The anchor also points to
the last block in the queue to enable efficient
queue
handling.
The
queue
header
format
is
displayed
in the section of data
structure pictures as the QHR.

2.3

FLOW OF CONTROL OF DNOS

While DNOS is running user jobs, the
control
paths
vary.
The
diagram
in
Figure 2-1 shows an overview of DNOS initialization,
functioning, and termination.
Detailed
paths
for
the
various
subsystems are described in the following sections.

Overview

2-2

2270512-9701

DNOS System Design Document

Halt-Load Sequence
on 990 Front Panel
I
V

Initial Program Load
(loads kernel and memory~resident
tasks, installs disk volumes, etc.)
I
V

System Restart Task
(sets up system log and accounting log,
bids required system tasks, etc.)
I
V

Serve a Request of the
Functioning System
I
V

Execute
Task
Code
I

Process
SVC
Request
I

*-410- ...........

/
\

Time Slice
Expired

Process
Hardware
Interrupt
or
XOP
I
I
I

Provide Op~rating System
Support for Memory
Management, Timing,
Performance, etc.
I
I
I
I

yes
error path only
I
I Forced error condition, error in
I a system task, error in DNOS, or
I error in hardware
V

DNOS Crash Routine
I
V

System Halt
Figure 2-1

2270512-9701

Flow of Control in DNOS

2-3

Overview

DNOS System Design Document

2.4

DXIO COMPATIBILITY

For a number of users, DNOS is an upgrade from the DXIO operating
system.
Most software that executes under DXIO executes without
source change under DNOS.
It needs only to be relinked with DNOS
run·time support.
The notable exceptions are user·written
DSRs,
XOP
processors,
system tasks and utilities, and SVC processors.
Several sections of this document describe the changes needed
to
make these pieces of software function under DNOS.
Several
system
for use in DNOSj
a new SVC.

Overview

SVCs
that were used with DX10 are not available
in most cases, their functions are performed
by

2- 4

2270512-9701

DNOS System Design Document

SECTION 3
NAMING AND CODING CONVENTIONS

3.1

NAMES OF ROUTINES

DNOS
modules
are written in either assembly language or Pascal.
In most cases, a module consists of one
routine.
When
several
small
routines
perform related functions, those routines appear
in a single module.
Each routine and module is named
using
the
form
aabbbb
where
aa
is
an abbreviation for the subsystem in
which the routine fits and bbbb
is
a
set
of
characters
that
describe the function of the routine.
For example, JMHALT is the
job management routine that processes the Halt Job SVC.
Abbreviations
for
subsystems
in
utilities are shown in Table 3·1.

the

DNOS

kernel

and

major

Modules are organized into directories that
correspond
to
DNOS
subsystems.
Table 3-2 lists the major directories that comprise
DNOS and
indicates
the
section
in
which
each
directory
is
described.
Other
directories
include
modules for the various
utilities of
DNOS.
The
major
directories
labeled
DNOS
are
detailed
in
this
document;
those
labeled
SCI, UTILITIES are
detailed in the DNOS SCI and Utilities Design Document.
The source library for DNOS has one
or
more
subdirectories for each of the directories:

the

following

PSOURCE for Pascal source

*
*
*
*
*
*
*

MSOURCE for /12 microcode

UTILITY for
code

FSOURCE for Fortran source
SOURCE for Assembly language source

MOBJECT for assembled microcode
MLIST for Microcode assembly listing
TSOURCE
for
Link
Editor
modules
needing
to
transliterated from POPs code to assembly language

2270512-9701

the

transliteration

3-1

utilities

for

linker

Coding Conventions

·DNOS System Design Document

Table 3-1
Abbreviation

D$
DM
DS
DU
E$
FM
10
IP
IU
JM
KM
LG
MB
NF
NM
01

PL
PM
RP
SE
SL
SM
SO
SP
TP
UT
aaa

Coding Conventions

DNOS Subsystem Abbreviations
Subsystem or Utility

Debugger
Disk management
Device service routines (DSRs)
Device I/O Utility
Text Editor
File management
I/O routines
Interprocess communication (IPC)
I/O utilities
Job management
Key indexed file (KIF) management
System log and accounting log
Mailbox
Nucleus functions
Name management
Operator Interface
Pasca1·to*assemb1y*language interface
Program and memory management
Request processing • SVC support
Security
System loaders
Segment management
System overlay management
Output spooler
Teleprinter device utilities
Subroutines common to several utilities
SCI utilities * aa or aaa is the SCI command

2270512-9701

DNOS System Design Document

Table 3"'2

-Directory
.......... .........
.,..

ANALZ
BATCH
DEBUG
DEBUGGER
DEVDSR
DIOU
DISKMGR
EDITOR
FILEMGR
IOMGR
IOU
IPC
JOBMGR
KIFMGR
LINK
LOADERS
LOG
LOGON
MACROS
MAILBOX
MESSAGES
NAMMGR
NUCLEUS
OPERATOR
PASASM
PERFORM
PROGMGR
REQPROC
RESTART
S$
SCI990
SECURITY
SEGMGR
SPOOLER
SYSJEN
SYSOVLY
TEMPLATE
TIGRESS
TPCALANS
UTCOMN

2270512-9701

Major Directories of DNOS
Location of Documentation
.... * •• * .....
••• * ......
..~~

~..,.~~

DNOS
DNOS
DNOS
SCI,
DNOS
DNOS
DNOS
SCI,
DNOS
DNOS
DNOS
DNOS
DNOS
DNOS
DNOS
DNOS
DNOS
DNOS
DNOS
SC I,
SC I,
DNOS
DNOS
SCI,
DNOS
DNOS
DNOS
DNOS
DNOS
SC I,
SCI,
DNOS
DNOS
SCI,
DNOS
DNOS
DNOS
DNOS
SCI,
SCI,

3-3

...

Section
Section
... Section
UTILITIES
.... Section
.... Section
... Section
UTILITIES
... Section
..;. Section
Section
... Section
... Section
Section
Section
... Section
... Section
Section
.... Section
UTILITIES
UTILITIES
Section
Section
UTILITIES
Section
Section
... Section
... Section
Section
UTILITIES
UTILITIES
Section
... Section
UTILITIES
... Section
Section
... Section
... Section
UTILITIES
UTILITIES

...

17
21
16
10
10
12
11
10
10
10
8
11
20
5
14
12
3
10
4

3
15
9
6
12
10
7
13
12
3,22
16

Coding Conventions

DNOS System Design Document

3.2

GLOBAL DATA AND STRUCTURE TEMPLATES

Names
of
system
tables and data structures are generally three
characters long,
with
the
characters
chosen
to
reflect
the
structure
name.
Fields within the structure have six~character
names (whether part of Pascal records or assembly language code);
the first three characters are the same as the
structure
label.
Flag fields within the structure are detailed using equates, with
each
flag
bit
(or
set
of bits) identified by aaFbbb where aa
represents the first two characters
of
the
structure
name,
F
indicates
a
flag, and bbb describes the flag.
For example, the
task status block is thi TSB.
TSBPRI is the name a field
within
the
TSB
that carries the task priority.
TSFSYS names a flag in
the TSB that indicates whether a task is a system task.
Global constants and error equates are named using these
WDaaaa
ERRaa
BYTEaa

DATA
BYTE
EQU

formats:

>aaaa
>aa
ERRaa

where a is a hexadecimal digit and
hexadecimal value.

used

represent

The
TEMPLATE
directory
contains
the
global
constants
and
variables used by DNOS source code.
In
the
following
list
of
subdirectories
of
the
TEMPLATE directory, DSC is a synonym for
the entire DNOS source
directory.
All
of
these
directories,
except
the PREAMBLE directory, also appear in the linkable parts
directory .S$OSLINK on an installed DNOS system.
DSC.TEMPLATE.ATABLE
DSC.TEMPLATE.COMMON
DSC.TEMPLATE.DECLARE
DSC.TEMPLATE.PREAMBLE
DSC.TEMPLATE.PTABLE

The DSC.TEMPLATE.ATABLE directory
contains
templates
for
DNOS
data
structures
that
are
used
by assembly language routines.
Files in this directory are
copied
into
an
assembly
language
module
to reference fields within the data structures.
A module
accesses a particular field in a structure by
using
a
template
offset
with
a pointer.
The pointer can be passed to the module
or retrieved from some other DNOS structure.
This directory also
includes a template of system crash codes (NFCRSH) and a template
of task states (NFSTAT).
Files from this directory are shown
in
detail in the section on data structure pictures.
They are built
using
the
picture
macros
described
in
the
section
on DNOS
Development and Analysis Tools.
Coding Conventions

2270512-9701

DNOS System Design Document

The DSC.TEMPLATE.COMMON directory contains the Common
data
used
by
assembly
language
routines.
It
consists of files of CSEG
blocks, including the following major files:

DSC.TEMPLATE.COMMON.NFDATA •
current state of the system

DSC.TEMPLATE.COMMON.NFERnO - Byte constants (>nO through
>nF)
and
equates
for
system
error
codes
(16
such
templates)

DSC.TEMPLATE.COMMON.NFPTR lists and structures

DSC.TEMPLATE.COMMON.NFWORD - Word constants

Global data values for

System

pointers

the

global

Any assembly language module that makes use of a byte constant or
a
word
constant copies the appropriate common template and uses
the constant in that module.
Similarly,
NFPTR
an~
NFDATA
are
copied
into
a
module
to
allow access to a system pointer or
global data item.
Use of the templates provides documentation of
all
uses
of
a
particular
error
code,
constant,
or
system
variable.
NFPTR
includes pointers to system queues, pointers to beginnings
of structure
lists,
addresses
of
segment
management
tables,
pointers
to
device
information,
and
several
miscellaneous
pointers.
Full details on NFPTR appear in the
section
on
data
structure pictures.
NFDATA
includes
anchors
for
several
system data structures,
counts for jobs and tasks in the system,
parameters
for
system
time
units,
sizes
of
the
system and system files, scheduling
data, a word of flags
which
define
system options
chosen
at
system
generation,
and
several other items.
Details of NFDATA
are shown in the section on data structure pictures.
The DSC.TEMPLATE.DECLARE directory is used
by
Pascal
routines.
It
consists of files of procedure declarations, which are copied
into Pascal modules.
Each subsystem or utility written in Pascal
has a file of declarations for its own
set
of
modules.
Also,
declarations are included for run-time routines and for interface
routines from Pascal code to assembly language modules.
The
DSC.TEMPLATE.PREAMBLE
directory
has
documentation preambles to assembly language
modules.

2270512-9701

3-5

the
and

templates
for
Pascal
source

Coding Conventions

DNOS System Design Document

The
DSC.TEMPLATE.PTABLE
directory
has data structure templates
and common
segment
templates
for
use
by
Pascal
code.
The
directory
includes
files
corresponding to each of those in the
DSC.TEMPLATE.ATABLE and DSC.TEMPLATE.COMMON
directories.
Also,
it
has
a number of files that have no counterparts in the other
directories but are needed by Pascal routines.

3.3

ASSEMBLY LANGUAGE CODING CONVENTIONS

Each
assembly
language
module
begins
with
a
preamble
that
describes
that module.
Fields in the preamble template that are
not used for a particular module are omitted in that module.
In
the assembler template, the following are required sections:
copyright statement
routine name
abstract
entry
exit

errors
revision
environment
IDT name
PSKG, code, and END

When
more than one routine is included in a module, each routine
is preceded by a description that includes abstract, entry, exit,
and error information.
The abstract gives a brief English
description
of
the
general
purpose
of the module, while the algorithm section describes how
the routine works.
The environment section points out what table
areas are used by the module.
Revision information
is
provided
in the format shown below.
Other entries are self·explanatory.

*
*
*

REVISION: - - -
repeated, with latest revision last

where:
is a pair of decimal digits, beginning
with 01.

is the form mm/dd/yy, where each field
is decimal.

is description of the change, including
the number of any STR on design request
being satisfied by this revision.
is the release for which this revision
was prepared.

Coding Conventions

2270512~970l

DNOS System Design Document

To
keep
track of
which
lines
of
code
were
revisions, each added line is flagged.
In columns
of
the line added to an assembly language module,
Rmn are inserted, where is the
revision
ID
this revision in the preamble.

added for what
58 through
60
the characters
specified
for

Templates
copied
into
assembly language programs with the COpy
statement are by default UNListed.
(Data
templates
and
other
structures
are
surrounded
by
UNL and LIST.
To see the copied
items, the program may be assembled with the FUNLST (F) option of
the assembler enabled.)
For the most part, assembly language code uses tab settings of 1,
8, 13, 31, and a right margin of 60 to make the assembly
listing
as
legible
as
possible.
Comments are included in the preamble
and in atoms within each routine.
An atom is
several
lines
of
comments, set off from the code it describes.
Labels
used
within an assembly language routine are composed of
three characters followed by three digits
(for
example,
OPNI00
for
a
label
in
a
routine
performing
open processing).
The
characters are chosen from the routine name unless another set of
characters is clearly more useful.
The numeric portion
ends
in
zero
to
allow
room
for
inserted labels, and labels appear in
ascending numeric order from beginning to end of a module.
The format of the assembly language preamble is as follows:

2270512-9701

Coding Conventions

DNOS System Design Document

TITL

*
*
*
*
*
*
*
**
**
**
*
**
**
*
*
**
**
*
*

*
*
*
*
*
*
*
*
*
*
*
*
**
*
**
*
**

'(MODULE ID -

SHORT DESCRIPTION)'

(C) COPYRIGHT, TEXAS INSTRUMENTS INCORPORATED, 1983.
ALL RIGHTS RESERVED.
PROPERTY OF TEXAS INSTRUMENTS
RESTRICTED RIGHTS • USE, DUPLICATION
INCORPORATED.
OR DISCLOSURE IS SUBJECT TO RESTRICTIONS SET FORTH
IN TI'S PROGRAM LICENSE AGREEMENT AND ASSOCIATED
DOCUMENTATION.
ROUTINE NAME: (NAME OF ROUTINE(S)
ABSTRACT: (DESCRIBE THE GENERAL PURPOSE OF THIS ROUTINE)
ENTRY:

(INSTRUCTION/STATEMENT/INTERRUPT USED TO ENTER)
«RN»)
(DESCRIPTION)

EXIT:

«RN»)

ERRORS:

(ACTION OR CODE) IF (CONDITION)

STACK REQUIREMENTS:

(N) WORDS

(DESCRIPTION OF ALGORITHM IF NECESSARY)

ALGORITHM:
REVISION:

(VALUE) IF (CONDITION)

(CREATION DATE IN MM/DD/YY) - ORIGINAL
(REVISION DATE; LATEST LAST) - (NATURE)

ENVIRONMENT: 990/10 ASSEMBLER
CALLABLE FROM (assembler,Pascal)
TABLE SEGMENTS MAPPED IN WHEN ENTERED:
(LIST)
TABLE SEGMENTS MAPPED IN DURING ROUTINE:
(LIST)
NOTES:

(SPECIAL CONDITIONS/ASSUMPTIONS OR OTHER
SPECIAL INFORMATION)

SUBROUTINE REFS:
REF
(NAME)

(DESCRIPTION)

CONDITIONAL ASSEMBLY:
(VARIABLE)

(DESCRIPTION)

MACROS TO BE USED:
LIBIN DSC.MACROS.TEMPLATE
LIBIN DSC.(MACRO LIBRARY PATHNAME)

EQUATES:
(NAME) EQU (VALUE)
(DESCRIPTION)
* (INSERT COPIES OF EQUATE FILES IF ANY)

GLOBAL DATA

(TO SHARE AND ACCESS DATA IN COMMON AREAS)

Coding Conventions

3-8

DNOS System Design Document

41)
It
returns
space

Otherwise,

all

cannot be

initiated

event

results directly to the requester task

the SVC request

is buffered into the STA.

While a task is having an SVC decoded, that task cannot lose
its
time slice or be preempted by the scheduler.
When the SVC issued

2270512-9701

6-1

SVC Processing

DNOS System Design Document

is
one
that
finishes
quickly,
the
request is decoded and is
processed, and control
returns to the requester task before the
scheduler can schedule another task for execution.
Essentially,
the sequence of events is as follows:

Decoding routine is entered from the XOP interface
determines
finishes quickly

that

this

4. Decoder copies

some
or
all
processor routine registers

5. Decoder transfers control

is
of

XOP

@block,l~

Requester task issues
(or equivalent)

3. Decoder

the SVC

using

request

which

block

into

to processor

6. Processor
performs
requested
information to requester task

service

and

returns

7. Processor returns control to requester task

If
the SVC request issued is not a fast request, the SVC decoder
copies the request block into a buffer in STA and
then
follows
one
of
two possible paths.
For requests that require much time
and effort, usually the request is queued to a processor task and
the requester task is
suspended
until
the
request
completes.
Processors
that
are disk-resident tasks follow this path.
Such
processors are either seldom used or very large in size.
Certain special
processors,
such
as
those
for
I/O
and
job
management
use
an
alternate
path
for
processing
buffered
requests.
Some preprocessing is required before control goes
to
a
processing task.
When following this path, the decoder copies
the request block into a buffer
in
STA
or
JCA
and
transfers
control
to
the
preprocessor.
The
preprocessor
examines the
buffered request and performs whatever processing
it
can.
For
some subopcodes, all processing is completed in the preprocessor.
In
these
cases,
control is returned to the requester task.
In
other cases, the preprocessor queues the request to the processor
task and suspends the requester task.
When the requester task is
suspended
while
the
SVC
is
being
processed,
the requester task may be removed from memory to make
room for another task.
When the SVC
request
is
finished,
the
buffered request must be returned to the requester task; then the
requester
task
can
again be scheduled for execution.
To allow
this, the SVC processor
queues
the
finished
buffered
request
block
to
the
requester task's TSB (or to the task's JSB if the
TSB is not in memory).
When ready for a new task, the
scheduler
examines
these blocks, ensures that the task is in memory, calls
SVC Processing

6-2

2270512-9701

DNOS System Design Document

a routine to return information to the task,
task for execution.

and

schedules

the

The
decoding
routine
examines
the
SVC
request
not
only to
determine whether processing will be fast or slow,
but
also
to
verify
several other characteristics.
Some SVC requests must be
aligned on a word boundary in order to execute properly.
This is
the first characteristic the decoder checks for.
If the
request
block
is
not
aligned
but
should
be, an error code of )Fl is
returned in the return code field of the request block,
and
the
requesting task resumes control.
Another
characteristic
to
be checked is the privilege level of
the request.
Some SVC requests can only be issued
by
operating
system
tasks.
If this requirement is not met, an error code of
)F2 is returned in the return code field of
the
request
block,
and
the
requesting
task
resumes
control.
Some SVC requests
require
that
the
requesting
task
be
installed
as
software
privileged.
If this requirement is not met, the task receives an
error code of )F3, and the requesting task resumes control.
Since
some
of
the
SVC
requests
(and
their
processors) are
configurable when a DNOS system is generated, it is possible
for
a task to issue an SVC that is not supported on a particular DNOS
system.
When
this
occurs, an error code of )FO is returned to
the request block, and control returns to
the
requesting
task.
This
error code is also returned when a request specifies an SVC
code that is not defined in the DNOS set.
Some DNOS users extend the capabilities of the
operating
system
by
adding
their
own
SVC
codes
and processors during sysgen.
(Such user-defined SVCs have operation
codes
)80 or greater.)
The same checks are performed on user-defined SVCs as on the DNOS
SVCs, and the same set of error codes is used for these checks.

6.2

MODULES USED FOR REQUEST PROCESSING

Most
of
the routines for processing SVC requests are written in
990 assembly
language;
several
are
written
in
Pascal.
The
routines
are found in modules either in the subsystems that they
directly support, or in the DSC.REQPROC
directory.
Modules
in
REQPROC
support
the
decoding,
buffering,
and
unbuffering of
requests and also process some of the requests that do not belong
in any other DNOS subsystem.
Table 6-1 lists and describes
some
of the request processor modules found in the REQPROC directory.

2270512-9701

6-3

SVC Processing

DNOS System Design Document

Table 6-1
Name

RPBUF
RPCONV
RPDQUE
RPGSVC
RPIDSC
RPINV
RPINVI
RPINV2
RPINV3
RPINV4
RPIOR
RPIV
RPPRCK
RPPEVT
RPPSVC
RPRCDA
RPRCP
RPRETR
RPROOT
RPSDAT

RPSGCK
RPUDAT
RPUTIL
RPVOL
RPWAIT
RPWTIO

Major Request Processor Routines
Description

Routine that copies request blocks to buffers in
STA
Processors for SVC OA,OB,OC,OD (data conversion)
Routine that dequeues and unbuffers SVC requests
to requester tasks
Processors for SVC 02,03,06,07,09,OE,11,2E,2F,3S,
3B,3E (miscellaneous general-support SVCs)
Processor for SVC 38 (Initialize New Disk Volume)
Main driver for the initialize new task volume
Routines used to support the ini~ialize volume
process
Same as RPINV1
Routines used to initialize disc process
Utility routines for the initialize new volume
process
Utility routines for the IV, UV, and INV SVC
handlers
Handles the main portion of installation of a
disc volume
Routine that checks for memory protection
violations
Processor for SVC )4F (Post Event)
Processors for SVC 04,10,lB,24,2B,2C,33
(miscellaneous) (program-support SVCs)
Data base for SVC 4C (Return Code Processor)
Processor for SVC 4C (Return Code Processor )
Processor for SVC 3F (Retrieve System Data )
Decoder for SVC requests
Module that includes the system static buffer
and a table (RPSTAB) built during sysgen,
.
showing characteristics and processors for DNOS
SVCs
Routine that checks for mapping violations
Includes the table RPUTAB built during sysgen,
showing characteristics and processors for
user-defined SVCs
Utility routines and data areas for the IV, UV,
and INV SVC handlers
Processors for SVC 20,34 (Install Disk and
Unload Disk)
Processor for SVC 42 (Wait for Event)
Processors for SVC 01,36 (Wait for I/O)

Other
modules
that
process
SVC
requests
are
found
in
the
subsystems for I/O,
name
management,
job management,
program
management,
and
segment
management.
Short descriptions of the

SVC Processing

6-4

2270S12-9701

DNOS System Design Document

routines that process SVCs can be found in the relevant subsystem
descriptions.

6.3

MAPPING STRUCTURE

Due to the large number of SVC processors, one map
file
segment
cannot
contain
all of them.
Therefore, two arrangements of map
file 0 are set up during sysgen.
One arrangement has these three
segments mapped in:
system root, requester JCA,
scheduler/first
SVC
segment.
The
other
arrangement
has these three,segments
mapped in:
system
root,
requester
JCA,
second
set
of
SVC
processors.
A flag
in the RPSTAB entry shows which of the map
arrangements is needed for processing a particular
SVC.
Before
passing control to the processor, the decoding routine makes sure
that
the
correct
map
file
is being used.
When the processor
terminates, the return routines ensure that the map file with the
scheduler segment is restored.

6.4

DATA STRUCTURES USED FOR SVC PROCESSING

The primary structure used by the SVC decoding routine is the SVC
definition table built during sysgen.
This
table,
RPSTAB,
is
created
to
define
completely
all
DNOS
SVCs
included in the
current system configuration.
Users who supply any of their
own
SVCs
must build a similar table, RPUTAB, to describe those SVCs.
The RPSTAB table is located in a module named
RPSDAT;
the
user
defined table is placed into a file named .S$SGU$.USERSVC.RPUDAT.
Each
DNOS-supported SVC code has a two-word description field in
RPSTAB.
For
codes
that
are
undefined
in
a
particular
configuration,
both
words
are zero.
Figure 6-1 shows the twoword description format.

2270512-9701

6-5

SVC Processing

DNOS System Design Document

BYTE 0 -

FLAG
BIT 0
1
2

BYTE
- 0= Do not check alignment; l=check alignment
- 0= Use registers to buffer; 1=use table area
- 0= Use first SVC segment of processors;
1= Use second SVC segment of processors
3,4 - Reserved
5-7 - Length to buffer, if going to registers;
otherwise 0
BYTE 1 - LENGTH BYTE
)00 if buffering in table area
Length of whole call block if buffering in registers
BYTES 2,3 - ADDRESS WORD
Address of request definition block (RDB) if
buffering in STA
Address of processor if buffering in registers
Figure 6-1

SVC Entry Form in RPSTAB

SVC
processors
that
execute
quickly
and
require
little
information from the SVC call block have the required information
buffered
in
registers.
Upon
entry
to the SVC processor, the
following registers are set:

*
*
*
*
*
*

bytes 0,1 of call block (or zero if unused)

bytes 2,3 of call block (or zero if unused)

bytes 4,5 of call block (or zero if unused)

R3
R4
R5

requester call block address
requester TSB address
requester map file

pointer in TSB

When using a buffer
in
STA,
a
structure
called
the
request
definition
block (RDB) is used to tell how much and which fields
to buffer.
The RDB is defined in the
module
with
the
memoryresident
processor
or
preprocessor,
if one is used.
For SVCs
processed by tasks with no preprocessors or
for
SVCs
that
are
configurable
options
of
DNOS, the RDB is defined in the RPSDAT
module.
The RDB is labeled RDBSxx for system SVC opcode
xx.
A
template
for
the
RDB is shown in the section on data structure
pictures.
Figure 6-2 shows examples of RDBs.
For
many
of
the
requests
buffered
according
to
an
RDB,
information
must be returned from the processed buffered request
to the requesting
task.
The
structure
used
to
govern
this
transfer is the return information block (RIB) built for the SVC.
A RIB
is
needed
if information in addition to the return code
SVC Processing

6-6

2270512-9701

DNOS System Design Document

must be passed back to the requester task.
The
RIB
for
system
opcode xx is RIBSxx and is shown in detail in the section on data
structure pictures.
Figure 6-2 shows an example of an RIB.
RDBS14 EQU
DATA
DATA
DATA
DATA
BYTE
BYTE
DATA

$
)0800
OVYQUE

)0007
)07

o
o

LOAD OVERLAY RDB'
USE DYNAMIC BUFFER IN STA
OVERLAY QUEUE SERVER HEAD
NO RIB NEEDED
MAX BUFFER SIZE
BASIC BLOCK LENGTH
ACCOUNTING FACTOR
RESERVED

RDBS48 EQU $
DATA )1800
DATA JMPREP
DATA RIBS48
DATA )0010
BYTE )10
BYTE 0
DATA 0

JOB MANAGER RDB
PREPROCESSOR, DYNAMIC BUFFER
ADDRESS OF PREPROCESSOR
RIB ADDRESS
MAX BUFFER NEEDED IS 16 BYTES
BUFFER 16 BYTES
ACCOUNTING FACTOR
RESERVED

RIBS48 EQU
$
DATA o
BYTE o
BYTE )10
DATA o

NO POST PROCESSOR "NEEDED
START UNBUFFERING AT BYTE 0
UNBUFFER 16 BYTES
END OF RIB

Figure 6-2

Examples of RDB and RIB Structures

The
job management
SVC
is
one example of an SVC that must be
rebuffered for certain sub-opcodes.
The flags defined in the RDB
for expansion govern that rebuffering.
This
technique
is
used
because request blocks for sub-opcodes within the SVC opcode vary
in
size.
The preprocessor of the SVC must make a call to RPBUF
with a revised RDB to rebuffer special cases.
SVC processing uses several data structures in
addition
to
the
RDB,
RIB, and RPSDAT.
Among these are the queue headers for the
queue
server
SVC processing
tasks.
The
queue
headers 'are
described
in
the section on nucleus functions.
The SVC decoder
uses the queue header pointer in the
RDB
to
queue
a
buffered
request to a queue server.
SVC
processing
uses
TSBs of the requesting tasks to
file information and to return completed requests.
It
to
return
completed
requests
if
the
TSBs are not
Other structures are used by particular SVC processors
the decoder or buffering routines.

2270512-9701

6-7

access map
uses
JSBs
available.
but not by

SVC Processing

DNOS System Design Document

6.5

DETAILS OF SVC PROCESSING

SVC processing
begins
in
the
routine
RPROOT.
This
routine
accesses
tables
to
locate
the
appropriate
processor
and to
determine buffering details.
The routine RPBUF is used
to
copy
(buffer) the SVC request into a temporary work area.
The routine
RPDQUE is used to return the finished request to the task issuing
the
SVC.
A set
of
miscellaneous routines is used throughout
processing.

6.5.1

Decoding Routine (RPROOT).

When an SVC is executed, the hardware transfers control
via
the
interrupt processing routines to the SVC decoding routine RPROOT.
RPROOT first checks for a special SVC (XOP 15,15) used by the SCI
Debugger.
If this special call was issued, a flag is set in the
requesting task's TSB.

A check is then made for the Initiate Event SVC.
If that SVC
is
specified,
it
is
now
processed
in
RPROOT.
The
SVC
being
initiated is checked to ensure that it is a legal opcode and
can
be
initiated.
(In
the
current
version of DNOS, only I/O and
semaphore operations can be initiated.)
If no errors occur,
the
initiated SVC is processed like any other request.
At
this
point
I/O
and
Segment
Manager
SVCs are checked for
alignment and then routed directly to their preprocessors.
This
is done to speed up the processing of those SVCs.
RPROOT then examines the RPSTAB entry for the requested SVC.
The
first
check
verifies
that
the
opcode
is
defined
in
this
configuration.
If there is no RPSTAB entry and no RPUTAB
entry,
error
code
)FO
is
returned,
SVC
processing
terminates, and
control returns to the requester task.
If the SVC is defined, the next check is for alignment.
If
the
RPSTAB
or RPUTAB entry shows that the request must be aligned on
a word boundary, the address of the request is checked.
If it is
not legal,
error
code
)Fl
is
returned,
and
SVC
processing
terminates.
The
RPSTAB
entry
for the requested operation is checked to see
whether buffering occurs in registers or in STA.
If the
request
is to be buffered in registers, RPROOT performs the follOWing:
the
1. Checks
violations

call

block

for

mapping

and

protection

2. Transfers the required amount of information
from
requester call block to registers RO, Rl, and R2
3. Ensures

SVC Processing

that

the correct map file

6-8

the

is in use

2270512-9701

DNOS System Design Document

4. Transfers control to the processor.
When the processor
completes
its
work,
it transfers control back to the
requester task

If the RPSTAB entry for the SVC shows
that
the
buffered into STA, RPROOT performs the following:
1. Accesses

SVC

the RDB

Checks
the
violations

Calls
the
buffering
routine
RPBUF
to
transfer
information
from
the
requester
call
block
to
STA
according to the RDB, creating a BRB (Buffered
Request
Block)

call

block

for

mapping

and

protection

4. Checks whether the request is to be queued to
a
queue
header for a task or sent on to a processor in memory
a.

If the request is to be queued, RPROOT queues the
buffered
block
to the queue header and suspends
the requester task

If the request is to
be
sent
to
a
processor,
RPROOT
transfers control to the processor, which
either returns to the
requester
or
queues
the
buffered request to a task

After
RPROOT
transfers
control
to
an
SVC
processor,
that
processor may return control to the
scheduler
by
branching
to
NFSRTN
or NFTRTN.
It may also return to RPROOT in case an error
occurs in
the
processing
logic.
The
return
points
are
as
follows:

RPRTNE - an error completion.
RPROOT must check whether
this
was
an
initiated event and return only the error
byte to the requester task.

RPRTNF - a task error in
the
requester
task.
RPROOT
must
check whether
this
was
an
initiated event and
terminate the requester task with the task error
passed
from
the
SVC
processor.
If the SVC processor itself
encounters
a
logic
error,
RPROOT
terminates
the
requester
task
with
task
error
)04
to
show an SVC
processor error. ~

2270512-9701

6-9

SVC Processing

DNOS System Design Document

6.5.2

SVC Buffering Routine (RPBUF).

RPBUF is a general request buffering routine called by RPROOT and
by several SVC preprocessors that have received a partially
buffered block from RPROOT.
RPBUF uses the RDB provided
by
the
caller to determine how to buffer the information.
RPBUF
first
checks the RDB flags to see if this buffering is to
use the single system static buffer
(provided
as
part
of
the
RPSTAB module) or a dynamic buffer.
If a dynamic buffer is to be
used,
a flag is checked to see whether the buffer COmes from STA
or from
the
requester
JCA.
A dynamic
buffer
of
the
size
specified
in
the
RDBMAX field of the RDB is then allocated via
the nucleus routine NFGTA.
If RPROOT called for
this
buffering,
RPBUF
now
sets
up
the
buffered
request by first building the buffered request overhead
(BRO).
The BRO
is
shown
in
the
section
of
data
structure
pictures.
It
includes
a pointer to the requester TSB and JSB,
the address of the call block in the requester
task,
a
set
of
flags, and several fields filled during SVC processing.
After
the
BRO
is completed, RPBUF includes as much of the call
block as indicated in the RDBBAS field of the
RDB.
RPBUF
then
checks
to
see
if
expansions
to
this
basic
block are to be
included.
If so, the next several
words
of
the
RDB
indicate
where
to buffer the information (table area or JCA), how much to
buffer, and at which offset
into
the
buffered
information
to
place the new information.
If
the buffering request is for revision of a partially buffered
block, RPBUF copies the BRO and the basic request block from
the
partially
buffered
block
to the newly acquired block.
The old
block of memory is released via the nucleus function
NFRTA,
and
expansions are treated like those in buffering for RPROOT.
6.5.3

Dequeuing and Unbuffering Routine

(RPDQUE).

When
a
task
is
to
be
scheduled for execution, the scheduler
examines the TSB to see if any SVC requests are to be
unbuffered
to
the
requester
task.
If so, RPDQUE is called to remove all
queued SVC requests.
RPDQUE
works
with
each
queued
request,
returning
information
from
the
buffered
request block to the
requester task.
It passes back the return
code
byte
and
then
uses
an
RIB
to
pass back any other information, if the RIB is
defined.
RPDQUE returns the number of bytes specified in
RIBLEN
from
the
offset
RIBOFF
in the BRB to the offset RIBOFF in the
requester call block.
Several sets of paired specifications
may
be
present,
terminated
by pair of zeros.
When these pairs are
completed, a postprocessor is called, if one is specified in
the
SVC Processing

6-10

2270512-9701

DNOS System Design Document

RIBPRO
field.
When unbuffering is complete, RPDQUE releases the
buffer via the nucleus routine NFRTA and returns to its caller.
A Wait for Event SVC requires special handling by
RPDQUE,
which
checks
the
requester
task
TSB
to
see which event flags have
completed.
The flags being tested in the Wait
for
Event
block
are
then matched against those in the TSB to generate a correct
reply in the requester task area.
6.5.4

Other Request Processor Support Routines.

RPMAP2
This routine is part of the DNOS root.
It is used by RPROOT
to access a processor in the second SVC map
file.
RPMAP2
adjusts
global
pointer
CURMAP, loads the second map file,
and transfers control to
the
processor
routine.
If
the
processor
returns to RPROOT, it passes back through RPMAP2,
restoring the original map file.
RPPRCK
This routine checks the memory-protection
attributes
of
a
portion
of memory.
It first examines the protection bit in
the status word of the
task.
If
protection
is
enabled,
RPPRCK
then
checks
to
see
if
the
map" regi ster
limi t
indicates write protection.
If so, an
error
is
returned.
To
allow
unbuffering
of
SVC
request
results,
write
protection must not be enabled; thus, the error
causes
the
task to terminate.
RPSGCK
The
requester call block must be mapped in by a single base
and limit register
pair
to
simplify
processing.
RPSGCK
verifies
this
condition.
Given
any
address and length,
RPSGCK uses the relevant map file to ensure that
the
block
addressed
is
correctly
mapped.
If
not,
an
error
is
returned, which may cause the task to terminate.
6.5.5

DNOS SVCs and Processors.

Table 6-2 shows the processors for each of the system-defined SVC
opcodes for DNOS.
In Some cases, a preprocessor is shown,
since
that
module is the one accessed from RPROOT; it may in turn call
one of several processors.
Some small
processors
that
perform
related
functions
have been collected into a single module; the
listing shows both the module name and
the
processor
name
for
these processors.

2270512-9701

6-11

SVC Processing

DNOS System Design Document

Table 6-2
NOTATION:

A
I

(Not Supported)
(pre)
P
(P)
S
(S)

(task)
[nn]
SVC /I

00
01
02
03
04
05
06
07
08
09
OA
OB
OC
OD
OE
OF
10
11
12
13
14
15
16
17
18
19
lA

SVC Processors and Modules
MEANING

Alignment on word boundary required
May be initiated with SVC 41
This SVC code is intentionally omitted.
This is a preprocessor
Software privileged task required
Some of the set require software privilege
System task required
Some of the set require a system task
This processor runs as a task
Name of module containing processor

Name

Notes

I/O Operations
A,I,(P)
Wait for I/O
A
Time Delay
A
Get Date and Time
A
End of Task
(Not Supported)
Suspend Task
Activate Suspended Task
(Not Supported)
Extend Time Slice
Convert Binary to Decimal
Convert Decimal to Binary
Convert Binary to Hexadecimal
Convert Hexadecimal to Binary
Activate Time-Delayed Task
Abort I/O Request by LUNO
Get Common Data Address
Change Task Priority
Get Memory
A
A
Release Memory
Load Overlay
A
(Not Supported)
(Not Supported)
Get Task Bid Parameters
A
(Not Supported)
(Not Supported)
(Not Supported)

SVC Processing

6-12

Processor/Preprocessor
[Module if Different]

lOP REP
RPWTOI
RPTDLY
RPGDT
RPENDT

(pre)
[RPWTIO]
[RPGSV C]
[RPGSVC]
[RPPSVC]

RPUNCW [RPGSVC]
RPAST
[RPGSVC]
RPETS
RPCBDA
RPCDAB
RPCBHA
RPCHAB
RPATDL
IOABRT
PMGRCM
RPCTP
PMGRMM
PMGRMM
PMOVYL

[RPGSVC]
[RPCONV]
[RPCONV]
[RPCONV]
[RPCONV]
[RPGSVC]

(task)

RPGTBP

[ RP G SV C]

[RPGSVC]

2270512-9701

DNOS System Design Document

Table 6-2 SVC Processors and Modules (Continued)
SVC II
IB

lC
ID
IE
IF
20
21
22
23
24
25
26
27
28

29
2A
2B
2C
2D
2E
2F
30
31
32
33
34

35
36
37
38
39
3A
3B
3C
3D
3E
3F

40
41
42
43

44
45

47
48

Name

Notes

Return Common Data Address
Put Data
Get Data
(Not Supported)
Scheduled Bid Task
Install Disk Volume
System Log Queue Request
Disk Management
(Not Supported)
Suspend for Queue Input
Install Task
Install Procedure/Segment
Install Overlay
Delete Task
Delete Procedure/Segment
Delete Overlay
Bid Task
Read/Write TSB
Read/Write Task
Self Identification
Get End Action Status
(Not Supported)
Map Program Name to ID
(Not Supported)
Kill Task
Unload Disk Volume
Poll Status of Task
Wait for Multiple I/O
Assign Program File Space
Initialize New Disk Volume
(Not Supported)
(Not Supported)
Set Date and Time
(Not Supported)
Semaphore Operations
Reset End Action Status
Retrieve System Data
Segment Management
Initiate Event
Wait for Event
Name Management
Reserved
Get Encrypted Value
Get Decrypted Value
Log Accounting Entry
Job Management

2270512-9701

6-13

A
A

A
A,P
A

A,S

[Module if Different]
PMGRCM
PMGDAT
PMGDAT
RPXSBT [RPPSVC]
RPVOL
(task)
LGSVC
DMTASK (task)

A
A

RPQSUS
PMPINS
PMPINS
PMPINS
PMPDEL
PMPDEL
PMPDEL
RPXTSK
PMRWTB
PMRWTK
RPGSID
RPGEAS

PMPMAP (task)

A,P
A,P

RPKILT
RPVOL
RPPTS
RPWT36
PMPASP
RPINV

[RPP SV C]
(task)
[RPGSVC]
[RPWTIO]
(task)
(task)

RPIDT

[RPGSVC]

A,P
A,P
A,P
A,P
A,P
A,P
A

A,P
A,P

A,P

[RPPSVC]
(task)
(task)
(task)
(task)
(task)
(task)
[RPP SVC]
(task)
[RPGSVC]
[RPGSVC]

A,I

PMSEMA
RPREA
[RPGSVC]
RPRETR
A
A, (S) SMPREP (pre)
RPROOT
A
RPWAIT
A
A
NMPREP (pre)
A
A
A

SECRYP
SECRYP
PMACCT
JMPREP (pre)

SVC Processing

DNOS System Design Document

Table 6-2 SVC Processors and Modules (Continued)
SVC #

Name

Notes

-----

49
4A
4B
4C
4D
4E
4F
50

Get Accounting Info from TSB
Modify BTA or JCA Size
Halt/Resume Task
Return Code Processor
(Not Supported)
Comm I/O
Post Event
DNOS Performance Functions

80+

User-defined SVCs

6.6

USER-WRITTEN SVC PROCESSORS

[Module if Different]

---------------------

PMACCT
PMSBUF (task)
PMHALT
RPRCP
(task)

RPPEVT

A
A,P
A,P

The
standard set of SVCs uses operation codes that range from )0
through )7F.
The user may implement SVCs using
codes
from
)80
through )FF.
One or more codes may be specified, using any codes
within
the
user-defined
range.
The
user must design- the SVC
block, build an RDB
to
describe
buffering,
build
an
RIB
if
information
is
to
be
unbuffered,
and
set
up
a
module
of
information with the IDT name RPUDAT.
During
sysgen,
the
user
supplies
a file name for the module containing RPUDAT object and
ensures that object modules for the SVC processor(s) are
in
the
directory .S$SGU$.USERSVC of the data disk.

6.6.1

User SVC Table.

The
user specifies the RDB and RIB information, as well as a set
of general information about all SVCs being defined, in a
module
of tables that contains the following:

*
*
*
*

An IDT name of RPUDAT
DEF statements for RPUMAX and RPUTAB
REF statements for each SVC processor entry point
A byte
named
RPUMAX with a value of the largest userdefined SVC code

A table named RPUTAB with a two-word entry for
code in the range )80 through RPUMAX

An RDB for each user-defined SVC code

SVC Processing

6-14

each

SVC

2270512-9701

DNOS System Design Document

An
RIB
for
each
user-defined
information to the caller

SVC

that

must

return

The entries in the table RPUTAB consist of two words
each.
The
first
word is the value )EOOO and the second word is the address
of the RDB for the SVC code being defined.
The
first
entry
in
the
table is for SVC code )80.
Each successive entry is for the
next sequential SVC code.
If a particular code is not defined in
the system being generated, the entry in RPUTAB must
consist
of
two words of zero.
Figure 6-3 includes the format of RPUTAB when
the user is defining several SVCs.
An
RDB
for
a
user-defined SVC includes the address of the SVC
processor,
flags
showing
how
to
copy
the
call
block
for
processing,· and the address of an RIB used to return information
to the calling task.
Table 6-3 shows the format of an RDB.
Table 6-3

Request Definition Block (RDB) Format

Field Size

Contents

Word
Word
Word

Flags, )1000 for user-defin~d SVCs
Address of the SVC processor
Address of the RIB fbr thi~ SVC
(zero if no RIB is defined)
Size of the call block in bytes
Number of bytes of call block to
be copied by the operating system
Zero
Zero

Word
Byte
Byte
Word

Figure 6-3 shows several RDB definitions for user-defined SVCs.
An RIB is used by the operating system to return
data
from
the
system
copy
of
the call block to the task that issued the SVC.
If only the error byte of the call block must be returned, no RIB
is needed.
If any other information is to be
returned,
an
RIB
must
be
specified
in
the
RPUDAT module.
Table 6-4 shows the
format of an RIB for a user-defined SVC.
The pair of byte fields
may be repeated if information is to
be
returned
from
several
noncontiguous areas in the call block.

2270512-9701

6-15

SVC Processing

DNOS System Design Document

Table 6-4

Return Information Block (RIB)

Field Size
Word
Byte
Byte
Word

Format

Contents
Zero
Offset in the call block from which the
return of data should begin
Number of bytes to return
Zero

The
RPUDAT module
must
be
assembled
and
its
object module
pathname must be
supplied
during
sysgen
in
response
to
the
question
about
the
user
SVC table.
Figure 6-3 shows a source
module for defining two user SVCs, using SVC opcodes >80 and >82.
Assume that there is Some legitimate reason to omit opcode >81.

SVC Processing

6-16

2270512-9701

DNOS System Design Document

*-----* THIS MODULE HAS THE DATA TABLES TO ENABLE PROCESSING OF
* USER-DEFINED SVCS. RPUTAB IS THE TABLE OF RDB AND PROCESSOR
* ADDRESSES FOR THE SVCS. THE SET OF RDB DEFINITIONS FOLLOWS,
* AND RIB DEFINITIONS ARE INCLUDED FOR RELEVANT CASES. IN
* ADDITION, RPUMAX IS DEFINED TO BE THE MAXIMUM USER-DEFINED
* SVC CODE.

*------

IDT
DEF
REF
RPUTAB DATA
DATA
DATA
DATA
DATA
DATA
RPUMAX BYTE

*RDBU80

DATA
DATA
DATA
DATA
BYTE
BYTE
DATA
RDBU82 DATA
DATA
DATA
DATA
BYTE
BYTE
DATA
RIBU80 DATA
BYTE
DATA
RIBU82 DATA
BYTE
BYTE
DATA
END

'RPUDAT'
RPUMAX,RPUTAB
L~BELS TO ACCESS USER DATA
SVC080,SVC082
LABELS OF ENTRY POINTS
)EOOO
SVC80 - FIN~ CPU TIME
RDBU80
i
SKIP SVC81
0
0
)EOOO
SVC82 - SPECIAL ADD
RDBU82
)82
MAXIMUM USER-DEFINED CODE
)1000
SVC080
RIBU80
6
2
0
0
)1000
SVC082
RIBU82
16
16
0
0
0
2,4
0
0
2 ,6
12,4
0
Figure 6-3

2270512-9701

FLAGS
PROCESSOR
RETURN INFORMATION BLOCK
MAXIMUM CALL BLOCK SIZE
COpy ONLY TWO BYTES
RESERVED
RESERVED
FLAGS
PROCESSOR
RETURN INFORMATION BLOCK
MAXIMUM CALL BLOCK SIZE
COpy ALL
RESERVED
RESERVED
RESERVED
START AT OFFSET 2 , RETURN 4 BYTES
RESERVED
RESERVED
START AT OFFSET 2, RETURN 6 BYTES
AND AT OFFSET 12, RETURN 4 BYTES

Forma t

6-17

of RPUDAT Module

SVC Processing

DNOS System Design Document

6.6.2

Processors for User-Written SVCs.

The SVC processor must define (DEF)
its
own
entry
point.
It
needs
to use SPUSH 1 on entry to save Rl and SPOP 1 to return to
the OS.
The processor runs
as
part
of
the
operating
system
kernel,
making use of an operating system workspace.
Upon entry
to the processor, the following registers are set:

Rl - Points to the system copy of
block

*
*
*

the

requesting

Points to the requester TSB
Points to the requester saved map file

R13

The requesting task workspace pointer (WP)

R14

The requesting task program counter ( PC)

R15

- The

RIO

call

Points to an internal operating system stack

requesting task status register (ST)

The
SVC
processor
must
not
alter
registers
13, 14, and 15.
Register 10 should be used only for pushing and popping items
on
the stack.
Register
1
points
to
the
system copy of the requester's call
block.
The processor usually gathers all of the
information
it
needs from this copy.
The processor alters the copied call block
to
pass information back to the requesting task; the second byte
of the call block should always be used for
returning
a
status
code.
If necessary, the processor can also access the requester
task
area
to
get
or
return
data
by
using
long
distance
instructions with register 5 as the map file pointer.
The
call block as received by the processor has several words of
overhead as detailed
in
the
buffered
request
overhead
(BRO)
template.
This
overhead
includes the requester's TSB address,
JSB address, call block address,
and
several
other
pieces
of
information.
Each of these is accessible using negative offsets
from the buffered call block pointer in register 1.

When the processor finishes its
work,
it
must
return
to
the
operating
system
by
issuing
the
instruction
SPOP 1.
The
operating system returns information as specified in the RIB
for
the
SVC performed.
Control is then passed back to the task that
yssued the SVC.
The DNOS Systems Programmer's Guide includes
an
example of a user-written SVC processor.

SVC Processing

6-18

2270512-9701

DNOS System Design Document

SECTION 7
SEGMENT MANAGEMENT

7.1

OVERVIEW

The
segment
management
subsystem enables tasks to dynamically
change the segment~set mapped by the
task.
Segment
management
also enables a task to guarantee accessibility to a segment until
it
is
no
longer needed.
Finally, segment management enables a
task to write segments to disk if
their
attributes
allow
this
function.
Segment
management
also
provides
the
operating
system with
mechanisms to manipulate data structures even when they
are
not
contained
in
the
same
address
space.
Since
DNOS is a joboriented operating system, system data
structures
whose
scopes
are
contained
within
a
job
are located in separate segments.
Thus, the operating system is able to service job-level
requests
by mapping only the job-level system data structures.
Segment
management
enables
the
file
management
subsystem to
manage file buffers.
By treating file buffers as segments,
file
management
is able to access any buffer, whether in memory or on
disk.

7.2

ARCHITECTURE OF SEGMENT MANAGEMENT

The Segment Manager is im~lemented as three
distinct
levels
of
support.
The
first
level
contains
routines
for mapping the
various table areas
(JCAs
and
special
table
areas),
finding
Segment
Status
Blocks (SSB) for specific segments, creatin~ and
deleting
SSBs
and
Segment
Group
Blocks
(SGB),
and
causing
segments
to be loaded into memory.
These routines reside in the
system
root
and
are
described
in
the
section
on
nucleus
functions.
The
second
level
of
segment
management
consists
of
SVC
processors.
These processors reside in the second SVC
processor
segment
of
map
file
O.
This
level
consists
of
an
SVC
preprocessor and several SVC processors.
These processors enable
user and system tasks to dynamically change the address spaces of
their tasks.

2270512-9701

7-1

Segment Management

DNOS System Design Document

The third level of segment management is task-level support
that
enables
the
Segment
Manager
to
read a program file directory
entry for a segment.
This
support
is
needed
when
a
Change
Segment
SVC
is
executed on a program file segment whose SSB is
not in memory.
The program file directory is
read
to
get
the
segment
attributes,
length,
load address, image record number,
and attached procedure
IDs
(task
segment).
The
task
loader
contains
this
support.
A special interface is used between the
task loader and the segment management SVC processors to
perform
the segment change after the directory is read.

7.3

SEGMENT MANAGEMENT DATA STRUCTURES

Program
files are used to support segment management.
A program
segment entry is located in the procedure section of the
program
file,
thus
limiting
the total number of procedures and program
segments in a program file to 255.
The Install
Program
Segment
SVC
builds
a segment entry.
The format is shown as the program
file directory index entry (PFI) in the section on data structure
details.
The SGB is the in-memory anchor for a set of segments.
The
SGB
resides
in the segment management table area.
The FCB points to
the SGB for a file.
If
all
segments
of
a
group
cannot
be
contained in the same table area, an overflow SGB is created in a
different table area and the SGB points to it.
Each
segment
group
consists
of
one
or
more segments.
Each
segment is described by an SSB, which is allocated in the segment
management table area.
Special table area SSB's are in STA.
An
SSB
is created by Segment Manager when a task requests a segment
that does not currently exist.
The overhead beet (OVB) is used to contain
information
about
a
segment when it is in memory.
The OVB is located in the beet (32
bytes) preceding the segment.
The
reserved
segment
table
(RST)
contains a list of segments
reserved by a job.
The job information table
(JIT)
contains
a
pointer
to
the RST chain, which resides in the JCA.
The RST is
built when the first Reserve Segment SVC
is
done
or
when
the
current
RST
overflows.
The RST is deleted when it contains no
more segment entries or when the job terminates (after
releasing
all
of
the
segments).
The
format of the RST is shown in the
section on data structure pictures.
A Set Exclusive Use operation
creates
an
Owned
Segment
Entry
(OSE)
which
points "to the owned segment.
The SSB points to an
Segment Owner Block (SOB) which points back to
the
TSB
of
the
task
that
has
exclusive
use
of it.
A Load Segment operation
creates a Load Segment Entry (LSE) which points to the segment to
Segment Management

7-2

2270512-9701

DNOS System Design Document

be loaded.
OSEs and LSEs are chained off the
TSB
in
the
SOBs are allocated in the segment management table area.

JCA.

The
segment management SVC block is shown in the section on data
structure pictures as the SMR structure.

7.4

SEGMENT MANAGEMENT ROUTINES

Segment management SVC
processing
begins
in
the
preprocessor
routine
SMPREP.
Depending
on
which
subopcode
is specified,
control
then
is
transferred
to
the
appropriate
subopcode
processor.
7.4.1

SVC Preprocessor (SMPREP).

SMPREP
receives
control
from the SVC decoder, RPROOT, with the
pointer to the SVC call block
in
the
task
as
input.
SMPREP
verifies that the following conditions are met:

*
*
*

All of the call block is within the

task.

The subopcode is within range.
If
the operation is a Change or Create Segment, the I/O
count and the initiate count
for
the
task
are
zero,
unless the task is software privileged.
NOTE
The
OS
does not provide general support for
proper completion of I/O when the call
block
or
buffer
is
mapped out of the task.
When
DNOS unbuffers the data of an
IPC
read-type
operation, it does not use the task map file,
so
mapping
out
IPC
read
or
master
read
buffers is supported.

If a LUNO is specified, it is assigned to a
valid type and in certain cases, is open.

file

SMPREP
uses
a pointer in the Logical Device Table (LDT) for the
specified LUNO to determine the File Descriptor Packet (FDP) that
contains
the
File- Management
Table
and
File
Control
Block
(FMT,FCB)
pair.
The FMT,FCB addresses are saved in the segment
management SVC block.
If
the
memory-based
segment
group
is
specified,
an FMT,FCB address of zero is used.
The FMT,FCB pair
is used to identify the segment
group
in
which
the
requested

2270512-9701

7-3

Segment Management

DNOS System Design Document

segment
resides.
If
the
operation
is
not
change or create
segment t the SMT,SSB pair for the specified segment is
obtained.
If
it
cannot
be found, an error is returned.
Figure 7-1 shows
the overall flow of control to and from SMPREP.

XOP

+-----------+
1 REQUESTER 1

-----------1
I
V

TASK

+-----------+

+--------+
I RPROOT I
+--------+
I
V

+--------+
I SMPREP I
+--------+
I (BL)
V

+----------+
I
SVC
I
IPROCESSORSI

+----------+
I
I
I
I
I

SMLOAD-Load a Segment
SMUNLD-Unload a Segment
SMEXCU-Set Exclusive Use of a Segment
SMREXC-Reset Exclusive Use of a Segment
SMCHGS-Change Segment
SMCRES-Create Segment
SMRSVE-Reserve Segment
SMRLSE-Release a Reserved Segment
SMCHKS-Check Segment Status
SMFWRS-Forced Write Segment
SMJRLS-Job Manager Release Segment
SMMDFY-Set/Reset Modified and Releasable
5MBIAS-Bias Segment Address Within Task

See SVC Processing Description
for interface to return to user.
Figure 7-1

7.4.2

Flow of Control in Segment Manager

Change Segment Processor (SMCHGS).

The Change Segment operation enables a task to change the segment
set
that
comprises
its
logical
address
space.
The
caller
specifies
either
the
LUNO
for
the
file in which the segment
resides or a flag to
signify
a
memory-based
segment.
An
ID
(installed or run-time) uniquely identifies the new segment.
The
segment
to be mapped out of the task is identified by a run-time
ID or a map position number.
The Change Segment processor first decides whether the caller
is
adding t
removing,
or
changing
a
segment.
If
the caller is
removing a segment, the last segment
of
the
task
is
unmapped
unless
it
is
a
task
segment.
(This
removal constitutes an
error.)
The routine SMRMVE is called to decrement the
count
of
tasks
that
currently
require
the segment to be in memory (the
Segment Management

7-4

2270512-9701

DNOS System Design Document

task-in-memory count).
When this count goes to zero, the segment
can be swapped or released
from
memory;
therefore,
SMRMVE
is
responsible
for either caching or releasing the segment.
(Refer
to the program management section for more details.)
Add Segment and Change Segment
processing
are
essentially
the
same
except
that
during
an
add there is no old segment to be
removed from the task.
The routine SMSRCH is
called
to
search
for
the
requested new segment.
If it is found, SMSRCH verifies
that it may be used by the requesting task.
SMSRCH
first
calls
SMFSID to see if the segment is defined.
SMFSID uses the FDP and
ID
to
uniquely
identify the segment.
If the segment is found,
the SSB address is returned.
SMSRCH then validates
the
segment
attributes
for
the
task.
If
a
non-task
segment
is
share
protected, SMCHUC is called to verify that it is used only by the
requesting task before SMCHGS is allowed to map it.
If a segment
is owned but not by this task, mapping is not
allowed.
If
the
segment
is
replicatable
and in use, SMSRCH duplicates the SSB.
If SMFSID does not find the segment
defined
in memory,
SMSRCH
calls
5MBLDS
to
build
an
SSB.
If
the
segment
is
a file
management buffer or is memory-based,
the
SSB
can
be
defined
completely.
However,
if the segment is a program file segment,
the program file directory on disk must be
read
to
obtain
the
segment
information.
Thus,
5MBLDS will
place
program
file
segments in the initial load state to be processed
by
the
task
loader.
Control
is
received in SMCHGS with the new SSB address.
If the
new segment
is
an
initial
load
segment,
control
is
passed
immediately to the routine SMEXIT.
Otherwise, certain conditions
are
checked before the segment change is allowed.
The task must
fit into user memory with the new segment, and the task must
not
map
more
than
64K bytes.
Also, if any segment other than the
last one in the task is being changed, the new
segment
must
be
the
same
size as the old segment.
An exception to this rule is
made for
system
tasks,
which
may
change
in
different-sized
segments;
however,
the
segments' logical starting addresses do
not change.
If these conditions are
met,
the
old
segment
is
removed
from
the
task
address
space.
SMRMVE disposes of it
accordingly (not required when adding a segment).
SMEXIT is' then
called to map the new segment.
The routine SMEXIT is responsible for incrementing the use
count
in the SSB, updating the WCS bit in the status register., building
the
limit
register
for
the
new
segment,
and
updating
the
protection bits in the limit register.
SMEXIT decides
whether
the
new
segment
is
in memory.
If
not, the calling task is
deactivated and suspended while waiting for memory.
If
the
new
segment
is
in memory, its task-in-memory count is incremented,
the map base value is calculated, and the calling task is
placed
into execution with the new segment in its address space.

2270512-9701

7-5

Segment Management

DNOS System Design Document

When
an
initial
load segment is processed, SMEXIT suspends the
task on the WOM list.
This places the task loader into execution
and determines that an initial l~ad segment
is
being
requested
(TSBSBN
is nonzero).
The task loader then tests the SSBs to see
if the task is in the initial load state.
If so the program file
directory entry for the segment is read and the
SSB
fields
are
initialized.
Now that a segment SSB with the specified ID exists
in memory, the task loader calls SMCHGS via an interface routine,
PMSMIR.
SMCHGS processes the Change Segment as usual except that
control
is
returned
to the task loader from SMEXIT (instead of
suspending the calling task or placing it into
execution).
The
task
loader
then loads the task as usual.
Figure 7-2 shows the.
flow of control through the Change Segment processor.

+----------+
1
SMCHGS
1
+----------+
(BL)
+-----------------------------+
V
V
+----------+
+----------+
SMSRCH
I
SMRMVE
I
+----------+
+----------+
(BL)
I
(B)
+--------------+
V
V
V
+----------+
+----------+
1+----------+
1
SMFSID
I II
5MBLDS
I
I
SMEXIT
I
+----------+ V1+----------+ +----------+
I
+-------------+
+----------+
(B)
(B)
I
SMCHUC
I
+----------+
+----------+
+----------+
I
NFTRTN
I
I
NFSRTN
I
+----------+ +----------+
1

Figure 7-2

Flow of Control in Change Segment

Figure 7-3 shows the flow of control if an initial
is being accessed.

Segment Management

7,-6

load

segment

2270512-9701

DNOS System Design Document

+----------+
I
SMCHGS
I
+----------+
(BL)
+-----------------------------+
I

(B)

+----------+
I
SMSRCH
I
+----------+
(BL)
+--------------+
V
V
+----------+ +----------+
I
SMFSID
I
5MBLDS
I
I
+----------+ +----------+

+----------+
I
SMEXIT
I
+----------+
I
(B)
V

+----------+
I
NFSRTN
I
+----------+

TASK LOADER ACTIVATED WHEN ENTRY PLACED ON
ITS QUEUE BY SMEXIT

+----------+
I
I

TASK
LOADER

I
I

+----------+
(BLWP)
+--------------V
V
+----------+ +----------+
I
NFMAPO
I
I
LOAD
I
+----------+ I TASK I
(BL)
+----------+
V
+----------+
I
PMSMIR
I
+----------+
(BL)
V

EXECUTE SMCHGS EXCEPT THAT
SMEXIT WILL RETURN TO PMSMIR
Figure 7-3

7.4.3

Flow of Control During Initial Load

Create Segment Processor (SMCRES).

The
Create
Segment
operation enables a task to create an empty
segment of a certain size with specific attributes.
Two types of
segments may be created:
relative record
segments
and
memorybased segments.

2270512-9701

7-7

Segment Management

DNOS System Design Document

When
relative record segments are created, the segment length is
the physical record size of the file
(obtained
from
the
FCB).
The
length and attributes for memory-based segments are defined
in the call block.
Default attributes are
readable,
nonsystem,
disk
resident,
nonreplicatable,
non-WCS,
reusable,
and
noncopyable, though the user may set or reset the execute-protect
and share-protect attributes through the call block.
The
writeprotect
and
updatable
attributes
are
set
based
on the file
protection flags.
The Create Segment processor first decides whether the request is
to add an empty segment or to
change
one.
Much
of
the
same
validation
is
required here as in Change Segment to ensure that
the new segment can be
mapped
by
the
calling
task.
If
the
specified
conditions
are met, 5MBLDS is called to build the SSB
for the empty segment.
An empty segment flag is set in
the
SSB
to
inform
the
task
loader that the segment does not reside on
disk.
If a segment is not
being
added,
SMRMVE
is
called
to
dispose
of
the
old
segment.
SMEXIT
is
called
to
fin~sh
processing before returning control to
the
calling
task.
The
task
is
suspended
by
SMEXIT since the empty segment is not in
memory at this time.
Special processing is required by
Create
Segment
for
relative
record
segments.
Before a new SSB is built, a check is made to
see if a segment with the same ID already exists in memory.
If
so',
an
error is returned.
Figure 7-4 shows the flow of control
through the Create Segment processor.

+----------+
I
SMCRES
I
+----------+
(BL)
+------------+------------+------------+
I
I
I
(B)
V

+----------+
+----------+
+----------+
+----------+
I
SMFSID
I I
5MBLDS
I I
SMRMVE
I I
SMEXIT
I
+----------+
+----------+
+----------+
+----------+
(FILE
(B)
BUFFERS
ONLY)

+
I
V

+----------+
I
NFSRTN
I
+----------+
Figure 7-4

Segment Management

Flow of Control in Create Segment

7-8

2270512-9701

DNOS System Design Document

7.4.4

Reserve Segment Processor (SMRSVE).

The Reserve Segment operation enables a task to maintain
access
to a nonupdatable segment when needed, even though the segment is
not
in
any
task's address space.
Since segments which are not
memory-resident may be released from memory when
they
are
no
longer in use, this operation is needed to retain access to these
segments.
The
segment
is
reserved
at
the job level until a
Release
Reserved
Segment
operation
is
executed
or
the
job
terminates.
All
segments
reserved
by
tasks within a job are
contained in the RST to
which
the
JIT
points.
Segments
are
removed
from
the
RST whenever
a
Release
Reserved
Segment
operation is done.
When the job terminates and the
RST
is
not
empty,
the job management subsystem is responsible for releasing
the remaining segments.
Reserved segments are swapped
if
their
memory
is
needed.
The SSB for the reserved segment remains in
memory as long as the segment is reserved.
SMRSVE searches the RST chain for
segment's
run-time
ID.
If no
built.
The reserve count in the
then
returned
to
the
calling
subsystem.
7.4.5

a free entry
to
contain
this
free entries exist, a new RST is
SSB is incremented.
Control
is
task via the Request Processing

Release Reserved Segment Processor (SMRLSE).

The Release Reserved Segment
operation
is
used
to
release
a
segment
that
has
previously been reserved within the job.
The
RST includes an entry for the segment if it was reserved
in
the
job.
The processor returns an error if an entry is not found; in
effect, a job cannot release segments it has not reserved.
SMRLSE first decides if the requested segment was reserved by the
job.
If
so,
the entry is deleted from the RST.
If the RST is
empty, it is delinked from the RST chain and deleted.
The
SMT,
SSB pair is used to find the segment that is being released.
The
reserve count is decremented.
If the segment is no longer in use
or
reserved,
the
segment
is
left
cached
or is deleted from
memory.
SMDSSB does the following processing.
If the segment is
in memory and is reusable, the segment remains cached
in memory
(unless
the releasable flag is set in the SSB, in which case the
segment is deleted).
If the segment is
in memory
but
is
not
reusable,
the segment is queued for deleting by the task loader,
and the 8SB is deleted.
If the segment is
not
in memory,
the
swap
table
entry for the segment is deleted along with the SSB.
Control
then
returns
to
the
calling
task via
the
request
processing subsystem.

2270512-9701

7-9

Segment Management

DNOS System Design Document

7.4.6

Check Segment Status Processor (SMCHKS).

The
Check
Segment
Status processor returns information about a
certain segment.
Such information includes the segment
run-time
and
installed
IDs, length, attributes, whether the segment is a
task and whether the segment is memory-based.
If the segment
is
mapped
by
the
task,
the
logical
address
of
the segment is
returned.
The segment need not be mapped or reserved by the task
requesting the status.
If the segment is mapped by the task, the status
information
returned
along
with the logical address.
If the segment is
found in the
task,
the
segment
group
is
searched.
If
specified
ID is found, the status information for the segment
returned.
7.4.7

is
not
the
is

Forced Write Segment Processor (SMFWRS).

The Forced Write Segment processor writes a segment to
its
home
file
position
(if
updatable
and
modified).
The
segment is
represented by an SMT and SSB.
The task requesting the write
is
suspended
until
completion
of
the
write.
The
disk
I/O is
accomplished by a dedicated queue
server
of
the
write
queue,
PMWRIT.
If
the
segment
does
not
exist, an error is returned.
If the
segment exists, a check is made to determine if it is updateable.
If not, an error is returned.
If it is updateable, is in memory,
and is modified, the write will occur.
The OVB for
the
segment
is queued to the write queue.
The calling task is then suspended
until completion of the write.
PMWRIT
is
activated
whenever
an
entry is placed on the write
queue.
PMWRIT calls the file management routine
FMIO
to
write
the
segment to its home file.
It determines whether the segment
is a program file or data file segment.
If it is a program
file
segment, the home file wecord number is contained in the SSB word
SSBREC.
For a data file segment, this record number is contained
in
the
installed
ID field of the SSB.
After FMIO is called to
perform the disk I/O, SMDSSB is called.
Finally, if
a
task
is
suspended
for
the
write
(that
is, the OVB points to a forced
write call block through the OVBBRB field), the
task
is
placed
back
into
execution via NFEOBR.
Figure 7-5 is a diagram of the
flow of control through the Forced Write proce~sor and task.

Segment Management

7-10

2270512-9701

DNOS System Design Document

+----------+
I
SMFWRS
I
+----------+
(BL)
+-----------------------------+
I
(B)
V

+----------+
I
NFQOVB
I
+----------+

+----------+
I
NFSRTN
I
+----------+

FORCED WRITE TASK(PMWRIT) ACTIVATED WHEN ENTRY PLACED ON
ON ITS QUEUE BY SMFWRS

+----------+
I
PMWRIT
I
+----------+
(BL)
+--------------V
I
V (THROUGH NFMAPO INTERFACE)
+----------+
I +----------+
I
FMIO
I I I
NFEOBR
I
+----------+ II +----------+
I
+--------+
> PLACES CALLING TASK BACK
I SMDSSB I
INTO EXECUTION
+--------+
Figure 7-5

7.4.8

Flow of Control in Forced Write

Release Job Segments Processor (SMJRLS).

This operation is used by
job management
to
release
reserved
segments
in
a specified job when the Job Manager is terminating
that job.
This operation may be executed only by a
system
task
(specifically Job Manager).
SMJRLS
is
called
with
the
SMT,SSB address and the JSB of the
terminating job.
The JCA of the terminating job is mapped in for
the segment to be released.
SMRLSE
is
called
to
process
the
Release
Segment operation as usual.
SMRLSE then returns control
to SMJRLS, which returns control to the caller
via
the
request
processing
subsystem.
Figure
7-6
shows
the
flow of control
through the Release Job Segments processor.

2270512-9701

7-11

Segment Management

DNOS System Design Document

+----------+
I
SMJRLS
I
+----------+
(BL)
+------------+-----------------------------+
I
I
V
V
V
RETURN TO TASK VIA
+----------+
+----------+
REQUEST PROCESSING
I
SMMJCA
I I
SMRLSE
I
SUBSYSTEM
+----------+ +----------+
Figure 7-6

7.4.9

Flow of Control in Release Job Segments

Set/Reset Modified and Releasable (SMMDFY).

The Set/Reset Modified and Releasable operation is used to mark a
segment of a task as releasable or nonreleasable and to
mark
an
updatable
segment
as
modified
or
not
modified.
The default
conditions for segments are nonreleasable and not modified.
The SSB of
releasable
request.
7.4.10

the
and

segment
is
located,
states
are
modified

and
set

the
flags
for
the
according to the SVC

Bias Segment Address Within Task (SMBIAS).

The Bias
Segment
Address
Within
Task
operation
is
used
to
position segment two or three of a task at a new logical address.
This is used primarily by the System Configuration Utility.
This
subopcode (>08) is not available to users.
7.4.11

Set Exclusive Use of a Segment (SMEXCU).

The
Set
Exclusive
Use of a Segment operation is used to extend
the share-protection attribute to segments not
currently
mapped
in
by a task.
A segment which has had exclusive use set is said
to be an owned segment.
Other users who try to map in the
owned
segment
will
get a shared segment violation error (unless it is
replicatable, in which case a replicated copy
will
be
mapped).
The set operation also has the functionality of a reserve segment
operation.
That is, even if an owned segment has use and reserve
counts of zero, the segment will not be deallocated.

Segment Management

7-12

2270512-9701

DNOS System Design Document

If
the operation is to succeed,
met:

the following conditions must be

The segment must not currently be owned
task issuing the SVC or another task.

The
segment
must
issuing task.

not

either

the

use by any task but the

SMEXCU calls SMCHUC
(Segment
Management
Check
Use
Count)
to
perform
this
function.
Exclusive
use
of special table areas
(SMTs, FMTs, PBMs) is not allowed.
Once it
is
determined
that
the
preceding conditions are met, a segment owner block (SOB) is
linked to the SSB, indicating which task owns this
segment.
An
owned
segment
entry
(OSE) is linked to the issuing task's TSB,
indicating which segments the task owns.
7.4.12

Reset Exclusive Use of a Segment (SMREXC).

The Reset Exclusive Use of a
Segment
operation
relinquishes
a
task's
ownership
of a segment.
The operation will succeed only
if the segment is currently owned by the task
issuing
the
SVC.
The
SOB is
delinked from the SSB and its memory released.
The
OSE is removed from the list of owned segments linked to the
TSB
and
its
memory
released.
If
the
segment
is
not in use or
reserved, it is deleted.
7.4.13

Load a Segment (SMLOAD).

The Load Segment operation assures the user
that
the
specified
segment
will
be in memory while the task that issued the SVC is
executing.
The segment will not be mapped into the task
address
space.
A segment may be loaded by more than one task regardless
of its attributes.
When loading a segment, a load segment
entry
(LSE) is built and attached to the loading task's TSB.
SMLOAD
is
not
only
an SVC processor but is accessed with a BL
interface by nucleus routines.
It executes in Map O.
7.4.14

Unload a Segment (SMUNLD).

The Unload Segment operation detaches the segment from
the
task
so
the segment does not need to be in memory when the task is in
memory.
An error is returned if the segment was
not
loaded
by
the task.
The LSE is delinked from the TSB.
If the reserve, use
and
exclusive
use counts are zero, the segment may be cached or
deleted.
SMUNLD is not only an SVC processor but is
accessed
with
interface by nucleus routines.
It executes in Map O.
2270512-9701

7-13

Segment Management

DNOS System Design Document

7.5

SEGMENT MANAGEMENT TABLE AREA

Segment Manager maintains its internal data structures in special
table areas that are separate from the STA.
These blocks contain
SSBs and SGBs.
During sysgen, a variable number (one or more) of
these
areas
are
defined
to fit into the second segment of the
system mapping scheme (replaces JCA segment).
Sysgen creates an SSB in the
STA for
each
segment
management
table area.
These SSBs are used by the Segment Manager to access
each
table
area.
The tables reside in the memory-based segment
group; thus, a memory-based SGB resides in the STA.
Each
table
area
has
the
standard
memory management overhead along with a
pointer to the first SGB in the table and information required to
generate run-time IDs for SSBs.
The Get and Release
table
area
routines
(NFGTA and
NFRTA,
respectively) are used to allocate
memory in the special table areas.
Whenever a new segment group is being
created,
Segment
Manager
decides which table area has the most unused memory and allocates
the
segment
group into this area.
Segment Manager will attempt
to allocate all segments of a group within the same
table
area.
If
this
is
not
possible,
an
overflow
SGB
is
created in a
different
table
area.
The
overflow
SGB
contains
the
same
information as the SGB (which points to the overflow 8GB).
Thus,
Segment
Manager
can search all segments of a group by searching
the segments that reside in the table, then search
the
segments
that
reside in a table to which the overflow SGB points.
Figure
7-7 is a general diagram of
the
Segment
Manager
table
scheme
(given two tabl~ areas).

Segment Management

7-14

2270512-9701

DNOS System Design Document

+-------------------------------------------+
Contains Memory-based SGB and SSBs
1
for special table areas, ROOT and
1
11 +-----+
COMMON.
1
STA
1 SGB 1--+
1
1

+-----+
+-----+
1
1 +-----+ 1
1
1
+--) 1 S S B 1- -) 1 S S B 1- ••• --) 0
1
1
1
+-----+
+-----+
1
+-----1-------------------------------------+
1
1 Overflow SGB pointer

+-----1-------------------------------------+
1
V
1
1
1

1
1
1

+-----+
1 SGB 1--+ +-----+
+-----+
+-----+ +-)1 SSB 1--)1 SSB 1- ••• --)0
+-----+
+-----+

+-----+
1 SGB 1--+

1
ISpecial table #1

1
1

1
+-----+
+-----+
1
1
1 +-----+ +-)1 SSB 1--)1 SSB 1- ••• --)0
1
1
+-----+
+-----+
1
+-----1-------------------------------------+
1
1 overflow SGB pointer
+-----I-------------------~-----------------+

1
1

+-----+
1 SGB 1--+
+-----+

+-----+
+-----+
+-)1 SSB 1--)1 SSB 1- ••• --)0
+-----+
+-----+

11
ISpecial table #2

ETC.

+-------------------------------------------+
Figure 7-7

2270512-9701

Segment Manager Table Organization

7-15/7-16

Segment Management

DNOS System Design Document

SECTION 8
JOB MANAGEMENT

8.1

JOB CONSTRUCT

A job
is
the
fundamental
work
unit
to
which
DNOS logical
resources are allocated.
These resources include files, devices,
IPC channels, and environments of names.
The goals of the

job construct in DNOS are the following:

To provide a structure for the information about a group
of related
tasks
(for
example,
r~sources
allocated,
security level, and accounting information)

To
provide
the
capability
active physical terminal

To provide a vehicle for easy migration of
applications
between
DNOS configurations by isolating a set of tasks
from all others in a system

of divorcing tasks from an

A job
consists
of
one
or
more
tasks,
a
set
of
job-local
variables,
a
set
of resources, a set of job-local LUNOs, and a
job ID.
The operating system constitutes a job in that
it
owns
files,
devices,
and
channels
and
consists
of
a
group
of
cooperating tasks.
A job has an associated priority.
This
priority
is
used
for
scheduling
various
system
services.
Such
as disk events and
positioning requests into the spooler queue.
Management of resource allocation by
jobs
in
DNOS
provides
a
level
of
isolation between different jobs.
Once resources have
been allocated to
a
job,
the
execution
of
the
job
can
be
independent
of
the
existence
of other jobs.
Hence, jobs also
provide a
migration
vehicle
from
a
singleto
a
multipleapplication environment.

8.2

OVERVIEW OF JOB MANAGEMENT

The
Job
Manager assigns and manages job identifiers, limits the
number
of
jobs
in
the
system,
and
provides
system
access
To support these functions, the Job Manager processes
security.
2270512-9701

8-1

Job Management

DNOS System Design Document

the following SVCs:

*
*
*
*
*
*
*

Create Job
Halt Job
Resume Job
Modify Job Priority
Map Job Name
Get Job Information
Kill Job

A task requests creation of a job via the Create Job operation of
the Job Management SVC ()48).
The Job Manager performs
security
checks
to
validate the integrity of the request and generates a
unique job ID.
The job is created and is set into
execution
if
it will not exceed the system job limit.
If this is a batch job,
it
must
not
exceed
the
background job limit also.
If either
limit will be exceeded, the job is placed on a queue, waiting for
some other job to terminate.
Security on the Halt, Resume, Kill,
Get Job
Information,
and
Modify
Job
Priority
oper«tions
is
provided
so
that only a user with the same user ID or a part of
the system job may perform these operations.
A job
determines
its
own
job
ID
through the use of the Self Identification SVC
()2E).
Status
information
on
jobs
is
obtained
via
system
utilities.

8.3

ARCHITECTURE OF JOB MANAGEMENT

Job Manager is a system task that executes in the system job.
It
is
coded
in Pascal with minimal run-time support and is a diskresident
queue
server.
It
has
an
assembly
language
initialization
routine,
which
contains the stack space for the
Pascal routines.
Like other system tasks written in Pascal,
Job
Manager uses routines in DSC.PASASM to call nucleus functions.
Job
Manager
serves
a
singly
linked list of entries.
The Job
Manager logical address space consists of the system root, a
JCA
segment, and task code.
Any task requesting a Job Management SVC
is suspended until the request has completed.

8.4

JOB MANAGEMENT DATA STRUCTURES

Among
the
structures

data
structures
used
by
Job
Manager
are several
particular
to
segment
management
and
nuclens

Job Management

8-2

2270512-9701

DNOS System Design Document

functions.
These include SSBs, BRBs, and TSBs.
structures ~rimarily used by Job Manager include
and JIT.

The
the

job-related
JCA,
JSB,

The
JCA
contains all data structures local to a given job.
The
JCA is allocated from free memory and can be swapped when all the
tasks in a job are
swapped
out
of
memory.
The
JCA may
be
expanded,
as
necessary, up to the maximum size specified during
sysgen.
The JSB carries all global data
about
the
address
of
the
JCA,
job
ID,
job
name,
allocated from the STA.
The job management SVC request

block is

job,
including
the
and priority.
It is

the JMR.

The JIT contains the list headers for structures
is allocated as the first portion of the JCA.

in the

JCA

and

Details
of
each of these structures are shown in the section on
data structure pictures.

8.5

JOB STATES

The state of a job is maintained in its JSB and changes
only
in
response to SVCs initiated by the user.
The following states are
possible:

Creating
A job
is
in
this
state only during the
execution of the SVC that creates
that
job,
or
while
waiting
for
the active or background job count to drop
below this limit.

Halted - A job is in this state when halted
by
a
Halt
Job
SVC.
Only
queue
server
tasks
in
this job can
continue to execute.
Any other tasks
that
attempt
to
become
active
while
the
job
is
in
this
state are
suspended.

Executable - A job in the executable state can have
tasks scheduled for memory and CPU.

Terminating
A job is placed in this state when it is
killed or after its last task has terminated.
At
this
point,
no
more
tasks
may
be bid in the job, and Job
Manager
begins
releasing
all
resources
and
data
structures within the job.

2270512-9701

8-3

its

Job Management

DNOS System Design Document

JCA being expanded - A job is placed in this state while
its
job communication area is being expanded due to job
requirements for more data structures than
the
current
JCA can accommodate.

In
addition
to
these
job states, Job Manager can also cause a
task to enter the job suspended state.
This state is
used
when
halting a job.

8.6

DETAILS OF JOB MANAGER ROUTINES

Job
management
SVC
processing
begins
in
the routine JMPREP.
Depending on
which
operation
is
requested,
control
then
is
transferred to the appropriate operation processor.

8.6.1

Job Manager Preprocessor (JMPREP).

JMPREP
is
a small a~sembly language routine that resides in the
scheduler segment of map file O.
It causes the BRBs for
certain
sub-opcodes
to
be
rebuffered
to include more information than
originally buffered by the
SVC
decoder.
To
rebuffer;
JMPREP
builds
an
RDB
showing what
to rebuffer and calls the request
processor buffering routine, RPBUF, to perform the data movement.
JMPREP
then
queues
the
BRB
to
the
Job
Manager
queue
for
processing
and returns to the scheduler to suspend the requester
task.
8.6.2

Job Manager Request Processing Task (JMMAIN).

JMMAIN is the main module
for
Job
Manager.
It
acquires
and
releases
segments
as necessary and initializes local variables.
It also provides all functions COmmon to the SVC processors, such
as retrieving the BRB and getting the proper JCA.
At the end
of
SVC
processing,
it
will
start
any jobs on the waiting queue,
provided that the job limit and batch job limit are not exceeded.
8.6.3

Create Job Processor (JMC$).

JMC$ must map in the caller's JCA area and retrieve some
of
the
values
stored
in the JIT.
When the new user ID flag is not set
in the flag word of the BRB, then the user ID, passcode,
account
number,
and
privilege
level are copied out of the caller's JCA
into the BRB for use at a later time.

Job Management

8-4

2270512-9701

DNOS System Design Document

Once the call block is buffered, a JSB is built in
the
STA.
A
unique
job ID is generated and is used to identify the job while
it remains in the operating system.
This ID is placed in the JSB
and is returned to the caller in the BRB.
The
job
priority
is
checked
to
see
if it is in the range of 0 through 31.
If not,
the request is returned with an error status.
Otherwise, the JSB
state is set to indicate that it is being created.
Next, Job Manager obtains memory for the JCA area by executing
a
Create
Segment
SVC.
This
segment is placed in the second map
segment of Job Manager, replacing the system
JCA
segment.
The
size
of this JCA area is specified in the call block as 1, 2, or
3.
The code 1 is for the smallest JCA size; the code
3
is
the
maximum JCA size.
The logon default is the medium JCA size.
All
of
the memory management overhead is initialized in the JCA, and
segment manager SSB addresses for the JCA are stored in the
JSB.
The
queue
headers
for
the
job
level
queue
servers
are
initialized, and the JCA segment is reserved.
The station ID of the job being bid is next verified to
be
sure
that
the
station specified exists and is available for use.
If
an illegal station is specified,
the
job
creation
request
is
denied
and
an
error
is
returned.
If
the station is legal,
creation continues, with Job Manager assigning a
job-local
LUNO
to DUMY.
The
requester
may specify a logical name and synonym segment in
the SVC block.
(The function of this segment is detailed in
the
section
on
I/O.)
When this field is zero, no action is taken.
Otherwise, the segment is checked to see if it is a
memory-based
segment.
When
it is located, the segment manager SSB addresses
are stored in the JIT, and the segment is
included
in
the
job
reserved
segment
list.
If
the segment is not found or is not
memory based, the request to bid the job is aborted and an
error
is returned to the user.
After
the synonym segment is processed, the user ID and passcode
are verified.
When the new user ID flag is set, all
information
must be verified before it can be used.
The user ID and passcode
are
k e p t o n dis kin a p re d e fin e d s y s t emf i Ie.
A sea r chi s' ma de
for this user ID in
this
file.
Once
the
ID
is
found,
the
passcode
specified
is
encrypted
and
compared
against
the
encrypted passcode on disk.
Any error in this process aborts job
creation.
If the
file
.S$ACCVAL
exists,
the
account
ID
is
verified
against the file entries.
If a match is not found, the
job is aborted.
If
the
file
.S$ACCVAL
does
not
exist,
no
checking is done.
The
final
step
in
creating
a job is to bid the initial task.
First, the JSB is linked into the
system
JSB
list.
Then
the
parameters
for
the task are built into a Bid Task SVC, which is
issued from Job Manager.
{Note
that
because
Job
Manager
is
issuing
the
SVC, the specified program file LUNO must be global
2270512-9701

8-5

Job Management

DNOS System Design Document

so that it appears in the new job's LUND hierarchy.)
Any
error
returned
from
the
Bid Task SVC is placed in the BRB and aborts
the Create Job SVC.
The new task is initially bid in a halted state.
After
the
bid
has
been
completed, a job initialization entry is placed on the
accounting queue and the job is put on a wait queue.
Whenever the Create Job SVC has been aborted,
the
JCA and
JSB
must
be
returned
to free memory.
The BRB for the call is sent
back to the caller, along with the error.
A temporary
BRB
is
created
to
indicate
job
termination
and is placed on the Job.
Manager queue.
This entry is processed by
JMD$,
releasing
all
the resources the job had and returning them to the system.

8.6.4

Halt Job Processor (JMHALT).

JMHALT
calls
the
verify
routine,
JMVRFY,
to verify that the
specified job ID exists and
that
the
requesting
job
has
the
authnrity
to perform the halt.
The job state is then checked to
ensure that the job is active.
If it is not active, an error
is
returned.
Otherwise,
the
job state is changed to halted.
The
TSB list for the job is
then
searched
for
all
active
tasks.
During
this
search,
the scheduler must be inhibited to prevent
any change in the list.
When active tasks are found, if they are
not queue server tasks they are delinked from the job active list
and the task state
is
changed
to
indicate
that
the
job
is
suspended.
After
all
of
the
active
tasks
are
found,
the
scheduler is enabled and the BRB is returned to the caller with a
successful completion code.
While the job is in a halted state, only queue
server
tasks
in
the
job
can
be made active.
If any other task tries to become
active, the nucleus function NFPACT places the task
in
the
job
suspended state.
8.6.5

Resume Job Processor (JMRESU).

After
JMRESU
calls JMVRFY, if no error was found, it checks the
job state to see if it is halted.
If it is not halted, an
error
is
returned
to the caller.
If the job is halted, the job state
is changed to executable, and the TSB list is searched for
tasks
in
the
job
suspended
state.
When
such a task is found, Job
Manager calls NFPACT to place the task back on the
active
list.
The scheduler must be inhibited during the TSB search so that the
TSB
list
is
not
altered.
After
the
search,
a
successful
completion code is placed in the BRB, and the BRB is returned
to
the requester.

Job Management

8-6

2270512-9701

DNOS System. Design Document

8.6.6

Modify Job Priority Processor (JMPRIO).

JMPRIO
calls
JMVRFY
and, if no error was found, it checks that
the caller is the system operator.
If not, an error is returned.
The new job priority is checked to see if it is within the
valid
priority
range.
If not, the request is aborted.
Otherwise, the
tasks within the job are updated to
reflect
the
new
priority.
Job
Manager
calls
a
nucleus
routine
to
obtain the new task
priorities.
During this time, the scheduler must
be
inhibited.
After all of the priorities are modified, Job Manager delinks the
first
active
task in the job and then relinks it.
This inserts
the JSB in the right position for the scheduling queue.
The
new
priorities
take
effect
when
Job
Manager
completes
its
SVC
requests.
Job Manager then enables the scheduler and returns the
BRB with a successful completion code.

8.6.7

Map Job Name Processor (JMMAP).

The Map Job Name processor searches the JSB list for the job name
specified in the BRB block.
It returns the job ID of
the
first
job
that
it
finds
with
the same user ID as the calling task.
Jobs in terminating
state
are
not
considered.
An
error
is
returned
if no matching job name is found under that user ID, or
if the job name is duplicated.
In the latter case, the job ID of
the first matching job is returned.
The user ID and job names of
each job are kept in the JSB (which is memory resident) to
avoid
excessive swapping during this operation.
8.6.8

Get Job Information Processor (JMINFO).

The
Get
Job Information processor returns information about the
job identified by the job ID in the requestor call block.
If
an
ID
of
zero
is specified, information about the caller's job is
returned.
JMVRFY is called, and if no error
is
returned,
this
processor
returns
the
job name, priority, user ID, account ID,
privilege level, and the run ID of the calling task.
8.6.9

Kill Job Processor (JMKILL).

The Kill Job processor terminates jobs within the system.
JMKILL
verifies that the user has access to the specified job and
that
the
job exists.
The job state is then checked to see if the job
is already in a
terminating
state.
If
it
is,
an
error
is
returned
in the BRB to indicate this condition.
When the job is
in the create state, it must
be
deleted
from
the
waiting-toexecute
job
queue.
At this point, the job state is changed to
terminating so that no new
tasks
are
bid
in
this
job.
The
scheduler
is
then
inhibited
during
the kill process for each
task.

2270512-9701

8-7

Job Management

DNOS System Design Document

Job Manager kills each
task
by
calling
the
nucleus
function
NFTERM.
The
TSB contains a flag to indicate whether end action
is allowed on a kill request.
If it is not
set,
the
task
may
take
end action but will not be able to reset its own end action
bit.
A time-out value for end
action
prevents
the
task
from
executing
indefinitely.
Job
Manager
returns
a
successful
completion code in the BRB when
all
of
the
tasks
have
been
processed through NFTERM.
Job
Manager
suspends
(awaiting
queue
input) at this point to
allow all of the tasks to terminate.
The termination
processor,
PMTERM,
places
an
entry on the Job Manager queue to notify Job
Manager that the
last
task
has
terminated.
When
the
entry
arrives, control is given to JMD$ to complete the job termination
process.

8.6.10

Job Clean-Up Routine (JMD$).

JMD$
is
a
support
routine
that
can
be activated only by an
aborted Create Job SVC or by PMTERM.
The call is made
when
the
last
task
of
a
job has
terminated.
JMD$ is responsible for
releasing any attached resources and all memory blocks associated
with the job.
JMD$ may be called during the
create
process
to
clean
up
an
aborted
Create
Job
SVC.
JMD$ first determines if the JCA area
for the job exists.
Job manager releases the JSB if the JCA was
not created.
The
first
set
of operations required for the JCA is to release
any job-local
LUNas
still
assigned.
The
I/O
sub-opcode
to
Release LUNa in Another Job is used for this purpose.
The entire
list
of
LUNas
is
searched, and a call block for each of these
LUNas is created and passed on to the I/O Utility (IOU).
After all of the LUNas have been
released,
all
resources
that
have
been
attached by the job are released via calls to IOU for
each resource found.
The resource list is searched, and for each
entry found a Detach by Number SVC sub-opcode is issued.
The next structure to be deleted is the
reserved
segment
list.
For
each reserved segment, a call is made to the Segment Manager
to cancel the reserve.
This includes
the
reserve
on
the
JCA
segment.
The JCA segment is mapped into Job Manager during this
release process and is not released from memory until Job Manager
changes its second map segment.
All
other
segments,
such
as
logical
name
and
synonym
segments,
are
released
and become
eligible for deletion if no other job has
reserved
them.
All
clean-up
of
memory-based
segments
is
accomplished by Segment
Manager when Job Manager releases
the
reserved
segments.
The
table
memory
for
the reserved blocks is also released from the
JCA by Segment Manager during this process.
Job Management

8-8

2270512-9701

DNOS System Design Document

not
should
have
At this point in the clean-up process, the JCA
allocations
no other job has
any
dynamic memory
in
it.
If
put
the
before
the
job
in
this
JCA
segment
was
reserved
state,
this
JCA
is
deleted as soon as Job Manager
terminated
releases it from its address space.
The last step in JMD$ is to release the JSB from
the
STA.
The
JSB
is deleted from the JSB list, and the memory is returned.
A
job termination entry is placed on the accounting queue
and
the
active job count is decremented.
8.6.11

Verify Job ID Routine (JMVRFY).

The verify routine is used by JMKILL, JMINFO, JMRESU, JMHALT, and
JMPRIO
to
determine if the caller is allowed to execute the SVC
in question.
This routine searches the JSB
chain
to
find
the
appropriate
job
ID.
Jobs
in
terminating
state
are
not
considered.
If the job ID is not found, an error
is
placed
in
the
BRB and the request is aborted.
Otherwise, JMVRFY checks to
see if the operation is being executed on the
system
job.
Any
attempt
to
perform one of these SVCs on the system job receives
an error.
The last check made is to verify that
the
requesting
task
has the privilege to perform the SVC.
Valid requesters are
the system operator, tasks whose jobs have a flag set
to
bypass
ownership tests, and tasks whose jobs have the same user ID.
All
other
requesters
receive
errors.
On
successful
completion,
JMVRFY returns to
the
calling
routine
with
the
JCA
of
the
requested
job mapped
into
the
second map file segment of Job
Manager and with the JSB address of the job requested.

8.7

IMPLICATIONS OF JOB BOUNDARIES

In theory, a task running in a job is not aware of any other job.
It may interact with the system job by issuing an SVC or
it
may
interact
with
another job by using a global IPC channel, but it
theoretically is independent of and unaware of any other job.
In
reality, it may be necessary for two tasks in different
jobs
to
communicate with each other.
There
are
two
major mechanisms supported by DNOS for cross-j~b
communication:
global IPC channels, and event SVCs.
The
major
difficulty
with
global
channels is that the owner task must be
the first task to assign a LUNO to the channel, but,
aside
from
that,
they
have
all
the
power
that
the
various
channel
configurations
provide.
Events
provide
a
more
limited
capability,
being
mainly
a
synchronization feature.
Any task
which knows another task's job ID and task run-time ID can
issue
a
Post-Event
SVC which causes a specified event to complete for
the task specified by the job ID and run-time ID.
The
specified
task must issue a Wait for Event SVC for the event number of the
2270512-9701

8-9

Job Management

DNOS System Design Document

expected event.
SVC is issued.

Job Management

It will then be activated when

8-10

the

Post

Event

2270512-9701

DNOS System Design Document

SECTION 9
PROGRAM MANAGEMENT

9.1

OVERVIEW

Program management supports task-level requests to execute tasks,
load overlays, and terminate tasks.
Support is also available to
perform
sychronization operations, to read and write task memory
or TSBs, to get and release user memory, and to get
and
release
system
common.
Program management includes processors for the
full set of SVCs to support program files.
Program management is implemented in three distinct levels.
The
first
level includes support routines that reside in the root of
the operating system.
These routines
are
callable
by
various
program management routines and perform specific functions.
The
second level is the set of processors for the program management
SVCs
which
execute
at
XOP
level.
The
third
level
is the
processors for program management
SVCs
that
execute
as
queue
serving
tasks.
Many program management SVCs are implemented in
the second level only,
but
some
require
a
third
level
(for
example, disk I/O may be performed only at the third level).

9.2

DATA STRUCTURES USED BY PROGRAM MANAGEMENT

In addition to JSBs, TSBs, various segment management structures,
and the JCA, program management uses a number of lists and queues
to
coordinate
the
efforts of its components.
These structures
include the following:
Waiting-on-Memory (WOM) list
A list of JSBs anchored by the NFPTR field WOMJSB, with each
JSB having one or more TSBs for tasks that must
be
loaded.
The
TSBs
of
each job are linked from the JITWOM anchor in
the JIT of the JCA.
The JSBs are
ordered
by
JSB
waiting
priority as carried in the JSBWPR field.
Loader Queue
A linked
list
of
OVBs, each representing a block of user
memory to be released.
The queue is anchored at
LDRQUE
in
NFQHDR.

2270512-9701

9-1

Program Management

DNOS System Design Document

Cache List
A linked
list of OVBs for segments currently
not currently used by any active task.
(These
recently
used
segments,
and
they
may
be
deallocated.)
This list is anchored at CHELST

in memory but
are the
most
used later or
in NFDATA.

Active List
A list of JSBs for jobs with tasks ready to
execute.
This
list
is
anchored
in
the NFPTR field ACTJSB, organized by
priority JSBAPR.
The TSBs for the active tasks
are
linked
from the JITACT anchor in the JCA.
Time-ordered List (TOL)
A list of task segments (OVBs) representing all tasks in the
system eligible
for
the
active
list,
ordered
by
most
recently loaded.
Time Delay List
the
NFPTR
A linked list of time delay entries, anchored by
list
header
TDLHDR.
The
entries
reside
in the STA and
consist of task identification information
and
time
delay
values.
Wait for Event SVC's are also linked on this list.
Swap Table
A linked
list
of swap table entries used to keep track of
allocated space and segments on the swap file.
Whenever
a
segment
is
swapped to the swap file, a swap table entry is
built for that segment in the system JCA, and a
pointer
to
it
is placed in the SSB.
This table is used by the segment
swapper task to keep track of which records are allocated in
the swap file.
The
anchor
for
this
list
is
ROLDIR
in
PMDATA.

9.3

DETAILS OF PROGRAM MANAGEMENT ROUTINES

Program management
routines
perform the functions of bidding a
task, loading a task for execution,
and
deallocating
resources
when a task terminates.
9.3.1

Task Bid Processor (PMTBID).

When
a
Bid
Task
SVC
()2B)
is executed, the nucleus function
NFTBID attempts to add the task to the active list.
If NFTBID is
unable to bid the task, the SVC block is placed on the
task
bid
queue that places the queue server PMTBID into execution.
PMTBID
performs
the
initial setup for a task.
It ensures that
the task exists by locating the task
segment
in
memory
or
by
reading the program file directory.
Then, the procedure segments
Program Management

9-2

2270512-9701

DNOS System Design Document

(if
any)
are
located
in
memory,
or
they are built from the
program file directory.
The map file limit registers
are
built
for
the
task and the TSB for the task is placed on the WOM list
so that its segments will be loaded by the task loader.
Execution of PMTBID proceeds as follows.
The routine
PMGSSB
is
called to find or build an SSB for the task segment.
The routine
SMSRCH is called to search the program file segment group for the
requested
segment.
If
found, it is used by the task being bid
(assuming the segment attributes allow this).
If the segment
is
not
found, 5MBLDS is called to build an initial load SSB for the
segment.
(For
details
see
the
description
of
segment
management.)
When
control is returned to PMGSSB and if the SSB
returned is in the initial load state (that is, the program
file
directory has not been read for the segment), PMRDIR is called to
read the program file directory entry for the segment.
PMMPRI is
then
called
to
calculate
the initial runtime priority.
Next,
PMTBID
calls
PMITSB which
calls
PMGSSB
for
the
attached
procedures,
sets
up
the
map
file
limit registers (including
protection), determines the total mapped length and memory
used,
and initializes the task status.
A loaded segment entry (LSE) is
built
for
the
JCA
of the task, so that the JCA will be loaded
into memory when the task is
loaded.
PMTBID
calls
PMNMGR
to
inform
the
name manager that a new task exists in the job, then
links the TSB into the TSB tree and activates the task.
The task
is now ready to be loaded
by
the
task
loader.
Finally,
the
calling
task,
if
any, is killed or suspended if such action is
requested in the SVC block.
9.3.2

Task Loader

(PMTLDR).

PMTLDR loads tasks into memory when they are initially bid,
when
they
have been swapped out of memory and are rescheduled to run,
and when a Change Segment or Create Segment operation is done for
a segment that is not in memory.
The
task
loader
serves
the
loader
queue and the WOM list.
Included in the task loader task
are the get
and
release
user
memory
routines
and
the
task
swapping routine.
PMTLDR
begins
to
execute
whenever
an
entry is placed on the
loader queue or WOM list.
The loader queue is
processed
first.
It
contains a list of segments whose memory must be deallocated.
The return
user
memory
(PMRUM)
routine
is
called
for
each
segment.
After processing the loader queue, PMTLDR checks the WOM list for
a
task
to
be loaded.
If one is found, PMTLDR attempts to load
the task into memory.
PMTLDR first ch~cks to see if the task
is
doing a Change Segment operation which requires initialization of
an
SSB.
If so, PMRDIR and PMSMIR is called to allow the segment
manager to complete its processing.
PMTLDR
calls
the
routine
PMALSG
to
allocate memory for the task's JCA and later for each
2270512-9701

9-3

Program Management

DNOS System Design Document

segment of the task.
The JCA must be in memory before
the
task
can
be
loaded,
since
the
JCA contains the TSB.
PMALSG first
checks to see if the segment is already in memory.
If
so,
the
segment
is
removed
from
the
cache list if the task-in-memory
count is zero.
If the segment is not in
memory,
the
get
user
memory
(PMGUM)
routine is called to allocate memory.
If memory
is available, PMALSG
increments
the
task-in-memory
count
and
returns
the
segment
to
PMTLDR.
If
memory is not available,
PMROLL is called to attempt to obtain memory for the segment.

After memory is allocated for all of the task segments, PMLDSG is
called to load each segment
into
memory.
If
the
segment
is
already
in
memory or is empty, the load is skipped.
Otherwise,
the segment is loaded from its
home
file
or
roll
file.
The
record
number
for
the
segment
is
computed,
and
the
file
management routine FMIO is called to load the segment
from
disk
into memory.
After the load is completed, the OVB is initialized
and control is returned to PMTLDR.
After
all
of
the
task
segments are loaded, the map file bias
registers are calculated and. the task segment is
placed
on
the
TOL
by
calling NFATOL.
The task is put on the active list, and
PMTLDR continues processing the loader queue and the WOM list.
If insufficient memory is available to
load
a
task,
the
task
loader
calls
a
swapping
routine
(PMROLL)
to attempt to free
memory by temporarily writing segments to
the
swap
file.
The
swapping
routine includes two phases.
The first phase processes
the cache list (segments in memory
that
are
reusable
but
not
currently
in
use),
freeing any available memory.
If the first
phase does not yield
enough
memory,
the
second
phase
begins
processing
the
TOL
to
find a task that can be deactivated and
swapped.

Processing the cache list involves searching the
list,
last
to
first,
for
available segments.
A segment on the cache list can
be swapped if its TILINE I/O count is zero.
A maximum count
for
buffer segments and program file segments is maintained to ensure
that
memory
does
not become too fragmented by cached segments.
(See the roll parameters shown in
the
NFDATA
template
in
the
section on data structure pictur~s.)
PMROLL tries to prevent the
rolling
of JCAs and, in an attempt to improve performance, tasks
doing file I/O and file buffer segments.
When a swap candidate is found, it is queued to the
write
queue
to
be
written
to
its
home file, written to the swap file, or
released, based on its attributes, use count, and whether it
was
modified.
PMROLL
returns a code of zero if it was able to free
enough memory
before
returning.
However,
PMROLL
might
have
queued
an entry on the write queue, in which case PMROLL returns
a code of 2 to the task loader, indicating that memory
will
not
be
available
until
I/O completes.
If PMROLL finds an eligible
segment doing file I/O, it returns a code of 4,
indicating
that

Program Management

9-4

2270512-9701

DNOS System Design Document

task loader should serve the file

I/O request first.

If
none
of
these
conditions arises after processing the cache
list, PMROLL processes the TaL.
The TaL
is
searched,
last
to
first,
to
find
the
most
eligible
task
for deactivation and
swapping.
The following are three categories
of
tasks
on
the
TaL,
listed
in the order of most eligible to least eligible for
swapping:
1. tasks suspended for more than a minimum amount of
time
or
suspended
while
waiting for coroutine activation.
The
longer
the
suspension,
the
more
eligible
for
swapping.
2. Tasks of lower priority than the task being
loaded
by
the
task
loader.
The
lower
the priority, the more
eligible the tasks are for swapping.
3. Tasks that have the same priority
as
the
task
being
loaded
by the task loader and that have executed for a
minimum amount of time since
they
were
last
loaded.
The
longer
the
execution time, the more eligible the
tasks are for swapping.
After an eligible task entry is found on the
TaL,
the
task
is
deactivated and its segments are placed on the cache list if they
are not being used by other active tasks.
The cache list is then
processed
again
before
returning
to
the task loader with the
return code from
the
cache
list
processor.
If
no
eligible
entries
are found on the TaL, a return code of 3 is given to the
task lo~der, indicating that no memory was found to release.
Figure 9-1 shows the flow of control through the task loader.

2270512-9701

9-5

Program Management

DNOS System Design Document

ENTRY PLACED ON LOADER QUEUE OR WOM LIST
I
V

+----------+
I
PMTLDR
I
+----------+
(BL)
I
V

+--------------------+
I
I
I
I
I
I
I
I

+----------+
I
PMRUM
I
+----------+
Loader
Queue

+-----------------+----------------------+
I
for JCA and
I
I
Veach segment

+----------+
I
PMALSG
I
+----------+
(BL)

+----------+
I
PMLDSG
I
+----------+
(BL)

+------+-----+
(BL)
V

+----------+
I
NFPACT
I
+----.:;.-----+
I

I
I
I
I
I

(BL)
I

ACTIVATES
TASK

+----------+
+---------+
+----------+
I
PMGUM
I I
PMROLL I I
FMIO
I
+----------+ +---------+ +----------+
Figure 9-1

9.3.3

Flow of Control in Task Loader

Task Termination Processor (PMTERM).

When a task terminates by issuing an End Task SVC or is killed by
another task or by the operating system, the
initial
processing
is
done
by NFTERM (see the section on nucleus functions).
That
processing includes placing an
entry
on
the
task
termination
queue,
which
is
served by PMTERM.
PMTERM cleans up the memory
structures associated with the task (TSB).
If there is no end-action and the task was a task- or
job-local
channel
owner, PMTERM notifies IPC.
For each LUNO on the TSBLDT
chain PMTERM issues
an
abort
request.
If
no
end-action
is
specified,
PMTERM closes the LUNO and waits for I/O to complete.
Program Management

9-6

2270512-9701

DNOS System Design Document

Then PMTERM either waits for
or
causes
all
other
outstanding
requests
to complete and if end-action is specified, the task is
activated.
Otherwise, PMTERM releases all
LUNOs,
logs
a
task
error
(if
necessary),
informs
the name manager that a task is
terminating, and delinks the TSH from the
TSB
tree.
This
may
involve killing descendant tasks or activating a parent task.
If
there
is
only
one
task
left in the job (file manager), it is
killed.
If
there
are
no
more
tasks
left,
job
manager
is
activated to terminate the job.

9.4

TASK SYNCHRONIZATION

DNOS
provides
synchronization
on
several
functional
levels.
These levels correspond to the assumed
commonality
between
the
tasks
requiring
synchronization.
The
synchronization
tools
involved
are
interprocess
communication
(IPC)
messages,
semaphores,
locks,
and events.
IPC is discussed in the section
on I/O.
9.4. 1

Semaphores.

Semaphores enable
two
tasks
to
exchange
timing
signals.
A
semaphore
is
implemented
as an integer variable and a queue of
waiting tasks.
The integer
variable
indicates
the
number
of
unconsumed
timing
signals.
If
no
signals
are
present,the
integer indicates the
number
of
tasks
waiting
for
a
timing
signal.
Semaphore
operations are provided on job-local variables via SVC
)3D.
The subopcodes in this SVC have the following meanings:
Subopcode 0 :
SIGNAL
The value of the semaphore specified by byte 3
of
the
SVC
call
block
is
incremented.
The oldest task queued on the
semaphore queue is activated.
Subopcode 1
WAIT
The value of the semaphore specified by byte 3
the
SVC
of
call block is decremented.
If the resulting semaphore value
is
negative,
the
task
is
suspended
and
queued
to the
specified semaphore.
Subopcode 2
TEST
The value of the semaphore specified by byte 3
of
the
SVC
call block is returned in bytes 4 and 5 of the SVC block.
Subopcode 3 :
INITIALIZE
The
semaphore
specified by byte 3 of the SVC call block is
initialized to the value specified in bytes 4 and 5
of
the
SVG block.
If
any
tasks
are
queued
waiting
for this

2270512-9701

9-7

Program Management

DNOS System Design Document

semaphore, the action taken depends on the new value of
semaphore as follows:

If the new value is greater than or equal
all suspended tasks.

Given
that
n· is
(new value - old value), if the new
value is less than
and n is greater than 0, activate n
tasks, starting with the oldest queued task.

the

to 0, activate

Subopcode 4:
MODIFY
The semaphore specified by byte 3 is set to the sum
of
its
old
value
and
the
two's
complement
(negative)
value
furnished in bytes 4 and 5 of the SVC block.
If
any
tasks
are
queued
waiting
for
the
semaphore,
the action taken
depends on the new value of the semaphore, as
described
in
the initialize operation.
The modify operation combines the
test
and
initialize operations so that correct results are
obtained, even if other tasks are using that semaphore.
Semaphore values are represented as signed integers ranging
from
the
negative
value
of
-128
to
a
positive
value of 127.
A
positive value indicates the
number
of
signals
sent
but
not
received.
A negative
value represents the number of receivers
waiting for signals unless the semaphore has been negative
since
the
last
time
it
was
changed
in
a
negative direction to a
negative value by an initialize or modify operation.

9.4.2

Locks.

The synchronization tool available to tasks that share
the
same
task
address space is the lock.
Locks enable tasks to implement
mutual exclusion on critical sections
of
their
code
or
data.
Locks
are
represented as boolean data items, which indicate the
state of the lock.
Locks can be implemented in assembly language by
using
the
ABS
and
SETO
instructions
on
a
data
variable.
If
tasks spend
relatively little time executing in locked regions, the following
code will achieve the desired mutual exclusion:
INITLK SETO LOCK
AGAIN

ABS
JLT
SVC
JMP
GOTLOK •

LOCK
GOTLOK
TDELAY
AGAIN

SETa LOCK

Program Management

9-8

initialize the lock
test the lock
* got the lock, use it
* no, delay and retry

*
free

the

lock
2270512-9701

DNOS System Design Document

The higher-level synchronization primitives (SVC
semaphores
and
IPC messages)
are
available to tasks at this level that do not
meet the general assumptions about locks.
9.4.3

Event Synchronization.

To improve throughput, DNOS allows the execution of some SVCs
in
parallel
with
the task execution.
The Initiate Event SVC ()41)
provides this concurrency.
It also eliminates polling
in
those
situations
where
polling might
be used because concurrency is
unavailable.
A set of 32 event flags is maintained in each
TSB,
showing
which of the allowed 32 events is currently initiated or
completed for the task.
The Initiate Event SVC points to an
SVC
to
be
initiated.
An
event
number is generated by DNOS to identify this event.
Event
numbers range from 0 through decimal 31.
In the current
release
of
DNOS,
I/O
SVCs and semaphore SVCs can be initiated.
If the
operating system permits
the
specified
SVC
to
be
initiated,
control is returned to the task after that request block has been
buffered.
If
not,
an error is returned to the user.
The user
must exercise caution, since
the
operating
system may
return
information to the initiated SVC block at any time.
The
Wait
for Event SVC ()42) allows a task to wait for any of a
set of events to occur.
This SVC waits
until
one
of
several
events
has completed or until the maximum wait time is exceeded.
The events to be waited for are specified by an event mask.
The
leftmost
bit
of the first word of the event mask corresponds to
event O.
If this bit is set in the mask, the task
is
activated
when
event 0 is completed.
The event flags returned to the call
block indicate
which
(one
or
more)
of
the
32
events
have
completed.
The
Post
Event
SVC ()4F) permits the user to post any event in
any task in any job but the system job.
This means that any Wait
For Event may be aborted before its event
is
completed
or
its
wait
time has expired.
The Post Event SVC should not be used to
abort a wait for a valid initiated event; it should
be
used
to
provide
a cross-job synchronization mechanism.
If task A in job
ONE executes a Wait For Event with a
large
time
delay
without
initiating
an
event,
then
it will delay until either its time
delay expires or it is
posted,
either
from
job
ONE
or
from
another job.
This provides a method to deactivate and reactivate
user-written
queue
server
tasks,
across
job
boundaries.
To
facilitate this operation,
issuing
a
Wait
For
Event
with
a
maximum
time
delay
of
-1
()FFFF) is special cased to cause a
virtually infinite maximum delay time.

2270512-9701

9-9/9-10

Program Management

DNOS System Design Document

SECTION 10
I/O SUBSYSTEM

10.1

OVERVIEW

The I/O subsystem moves data between any combination
of
logical
and
physical I/O resources and programs (tasks) that process the
data.
The logical resources are the files
located
on
disk
or
magnetic
tape
and
the channels between programs.
The physical
resources are the devices attached to the computer.
An I/O request enters the I/O system via the SVC interface.
This
interface provides resource-independent,
resource-specific,
and
utility
paths
through a single SVC opcode, SVC 00.
Most I/O is
achieved via the resource-independent
call
because
programmers
usually
want
only to obtain data, process that data, and output
the processed data without knowledge of special features
of
the
I/O resource.
However,
some
special-purpose programs require knowledge of the
I/O resource.
They must use specific techniques and
formats
to
obtain,
process,
and output data.
These programs use resourcedependent I/O.
The utility path
allows
for
dynamic
management
of
resources
without
intervention from outside the computer.
Actions such as
reserving a resource, specifying access privileges, and releasing
access are performed via the utility path.
The general form of the I/O SVC request block (IRB) is
shown
in
the
section
on
data structure pictures.
The basic block is 12
bytes
long,
while
the
full
IRB
for
complex
requests
is
considerably longer.
An
I/O
request
enters
the
I/O subsystem from RPROOT, the SVC
decoder.
The I/O system screens out the utility requests via the
subopcode and passes them to the
I/O
Utility
(IOU).
The
I/O
system
then finds the request routing information for those that
are not utility requests.
The routing information
provides
for
checking
on
the operations allowed to the requester.
A copy of
the request call block is made in the STA so that the requester's
memory space may be free for other tasks
while
the
request
is
being processed.
The
routing
information
correct resource handler.
2270512-9701

is
used
to
move
the request to the
Channel requests are handed to the IPC

10-1

I/O Subsystem

DNOS System Design Document

processor.
File requests are given to the file
management
(FM)
processor.
Device
requests
are
handed to the device manager.
The device manager is responsible for setting up the data buffer.
The request data buffer is moved to the buffer table
area
(BTA)
if
the
destination
resource
transfers data relatively slowly.
This copy of the request data buffer is made
so
that
the
task
memory
space
may
be
released
while
the
request
is
being
processed.
Resources that move data quickly need
not
have
the
data
buffer
copied;
they
access
the
data
directly from the
requester task memory
space.
The
device
manager
passes
the
buffered
request copies to the physical device handler, the DSR,
for processing.
The DSR moves the data between computer memory and
the
physical
device.
This transfer usually occurs at the maximum rate of the
device.
During
this
transfer,
the
scheduler
selects
other
programs to execute.
When
the
transfer
has
completed, the hardware causes a device
interrupt to signal the DSR,
indicating
that
the
request
has
completed.
The
DSR
sets up conditions such that the next time
the scheduler selects a program to execute,
it
finds
that
the
request
has
finished
processing.
The scheduler then activates
the requesting task.
Also, any request waiting to
be
processed
by that DSR is passed to the DSR.
When
a
program
is
activated by the scheduler, a check is made
before the program is allowed to execute to see if
any
buffered
SVC
requests
are
to be returned to the program.
For I/O SVCs,
status information and buffered data are returned.

10.2

DEVICE I/O DATA STRUCTURES

Data structures used for handling device I/O are
of
two
types.
One
set
describes
the
devices
and
is
built
by
the system
generation utility.
The other type of structure is built by
the
I/O
and
I/O
Utility
subsystems
when requests are made to use
devices.
The
following
structures
are
built
during
system
generation:

Physical
device
table
(PDT)
Memory-resident
data
structure, one built for each
device
defined
for
the
system.
Contains
information
about
the device name,
characteristics, and workspace for
the
device
service
routine.

Alternate
subdevices
of an ASR
identifies

I/O Subsystem

PDT
A short
version of a PDT, built for
of a device.
An example is the cassette unit
terminal.
The DSFAiD flag in the field PDTDSF
the PDT as an alternate.
The
field
PDTDIB

10- 2

2270512-9701

DNOS System Design Document

points
to
the
master
PDT, that is, the PDT for which
this represents a
subdevice.
The
byte
PDTTYP
is
a
binary indicator of the subdevice.
There can be no more
than
256
subdevices
per
master PDT.
Note that these
structures must be carefully avoided by Some processors;
power-up must bypass all alternate
PDTs,
for
example,
and abort processing must also avoid them.

Disk PDT extension (DPD) - Structure appended to the PDT
for
a
disk
device.
Used as a work area by the device
service routine and the Disk Manager.

Keyboard status block (KSB) - Structure appended to
the
PDT
for
a device with a keyboard.
Used as a workspace
by
the
device
service
routine
when
handling
the
keyboard.

Line printer PDT extension (LPD) - Structure appended to
the
PDT
for
a line printer device.
Carries flags and
pointers for use by the device service routine.

Magnetic tape PDT extension (MTX) Structure
appended
to
the
PDT
for
a mag tape device.
Carries flags and
counters for use by the DSR.

Extension
Structure
keyboard.

Extension
for
a
940
or
931
terminal
Structures
appended
to
the
KSB for a 940 or 931 terminal.
These
are described in the paragraph on asynchronous DSRs.

for
a
terminal
with
appended
to
the
KSB

The following structures are built when a
device:

a
keyboard
(XTK)
for
a
device with a

request

is issued to

Logical device table (LDT) - Built by the I/O utility to
carry
the
logical unit number to be used for requests,
characteristics
of
the
device,
and
the
current
processing state.

I/O
request block (IRB) - Built by the I/O preprocessor
as a
buffered
copy
of
the
I/O
SVC
issued
by
the
requester.

Buffered
request
overhead (BRO) - Built by the request
processing root and by the I/O subsystem to describe the
originator of the IRB
and
the
current
state
of
the
request, this is appended to the front of the IRB.

2270512-9701

10-3

I/O Subsystem

DNOS System Design Document

10.3

DEVICE I/O HANDLING

Figure
10-1
and
Figure
10-2
show the flow of control through
device handling.
Figure 10-1 is an overall
view,
while
Figure
10-2 details the entrance to device processing.
The figures show
the
major I/O modules involved, as well as support routines from
the nucleus and SVC request processing systems.
+----------+
+------------(XOP)-IREQUESTER
1
1
TASK
1
V
+----------+
+----------+
1
RPROOT
1
+----------+
I
V I I
1
+----------+
1
V
-)--------1
1
lOP REP
1
1
+----------+
1
V
+----------+
1
1
NFSRTN
1
1
+----------+
1
1
+----------+
1
1 NFTRTN
1
V I I
1
+----------+
1
V I I
1 IODEVR
1
1
+----------+
1
V-----)---+----------+
1
1
NFSCHD
1
1
+----------+
1
1
+----------+
1
1 RPDQUE
1
.--------)--1
1
+----------+

1<---------------------

+-------)-----)----------------

+----------+

...

... ----)----

Figure 10-1

10.3.1

...

Overview of Device I/O Handling

Details of I/O System Routines.

When the requester task issues an I/O SVC, control is
passed
to
the
SVC decoder, RPROOT.
After determining that request is for
the I/O system, RPROOT passes it
directly
to
the
I/O
request
preparation routine, IOPREP.
IOPREP
functions
as
a
preprocessor that is a uniform entrance
into the
I/O
system and
prepares
the
I/O
request
for
the
destination
resource.
If
any error is detected by IOPREP, the
error bit is set in the user call block flags, and
IOPREP
exits
to
RPRTNE
in RPROOT.
RPRTNE returns the error byte to the user
call block and checks flags for initiated events.

I/O Subsystem

10-4

2270512-9701

DNOS System Design Document

+----------+
+------------(XOP)-IREQUESTER I
1
TASK
1
I
V
+----------+
+----------+
1
RPROOT
1
+----------+
(B)
1
V

+----------+
1
IOPREP
1
+----------+
(B)
1

+----------+
1
IOCHKX 1
+----------+
(B)

1----------------+----------------+-----------------+
V
V
V
V
+----------+
+----------+
+----------+
+----------+
1 IODEVR 1
1
IUPREP
1
1
IPCPRE
1
1
FMPREP
1
+----------+
+----------+
+----------+
+----------+
(BL)
I--(B)------------------+-----------------------+
V
V
V
+----------+
+----------+
+----------+
1
IOPEL
1
1
NFSRTN
1
1
NFTRTN
1
+----------+
+----------+
+----------+
(BL)
1-----------------------+-----------------------+
V
V
V
+-.---------+
+----------+
+----------+
1
IODBGN 1
1
LGDEV
1
1
NFEOBR
1
+----------+
+----------+
+----------+
(BLWP)
1
V

+----------+
1
DSR
1
+----------+
(BL)
1-----------------------+
V
V
+----------+
+----------+
OTHER DSR SUPPORT ROUTINES
1
IONRCD
1
+----------+
+----------+
Figure 10-2

2270512-9701

Beginning Device Request Processing

10-5

I/O Subsystem

DNOS System Design Document

IOPREP passes the request and control to IUPREP if the request is
a utility request.
Otherwise it builds a copy of the request
in
the
STA
static
buffer,
SYSBUF,
including
buffered
request
overhead (BRO) and the entire
call
block.
IOPREP
then
calls
IOFLDT to locate the LDT.
The LDT contains information about the
destination
resource
as
a
logical unit number (LUNO).
If the
resource pointer in the LDT is zero, the request is for the dummy
device (DUMY); consequently, the request is
simply
returned
as
complete via RPRTNE.
For
a
device other than DUMY, the LDT is examined to see if the
device has been opened, that is, some task has issued an I/O
SVC
with
the Open subopcode.
If the device is open, the LDT carries
the TSB and JSB addresses of the task that opened it.
The
task
attempting
to
use the resource must be the task that opened the
LUNO.
If the LUNO is open to the requester task, various subopcodes
in
the
I/O
requests
are
treated
differently.
The Modify Access
Privilege subopcode is treated as an Open.
Otherwise, control is
transferred
around
the
open
process.
Read
Characteristics
subopcode requests are allowed to bypass the requirement that the
LUNO be open.

If
the LUNO is not open, the subopcode is checked to see that it
is an Open.
The open process checks
for
a
Resource
Privilege
Block
(RPB) to see if the Open is allowed.
If it is, the LDT is
opened and the access privileges are placed into the LDT and RPB.
Requests of all subopcodes are channeled through the next part of
IOPREP, which tests again to determine if the request is
allowed
with
the
current
access
privileges.
If the request is legal,
control is passed to IOCHKX for further processing.
IOCHKX buffers the remaining portion of the request
into
SYSBUF
according
to
the
device type specified in the LDT.
The STA is
used since it is available to devices and
file
management
when
the
JCA
is
not in memory.
The data buffer is not allocated or
buffered at this time.
Using
more
information
from
the
LDT,
control
transfers
to
the
IPC
processor,
IPCPR2; to the file
management processor, FMPREP; or to the device processor, IODEVR.
IODEVR functions as
It has an alternate
system
tasks
that
primary entry point
from
the
BTA and
decisions are made,
together.

a uniform I/O entrance to
device
resources.
entry point (IODDIO) for direct device I/O of
must bypass checks on general requests.
The
determines if a buffer
should
be
allocated
if
data
should
be
buffered.
After these
the paths from
the
two
entry
points
come

IODEVR
now
checks to see if the device in use is represented by
an alternate PDT, that is, is a subdevice of Some master
device.
If so, the flag BRFAPI is set in the field BROOF2 of the buffered
request
overhead of the I/O request block.
The binary ID of the

I/O Subsystem

10-6

2270512-9701

DNOS System Design Document

device is copied from the alternate PDT to the field BROAID.
master PDT pointer is retrieved from PDTDIB of the alternate
and now used as the PDT pointer for processing.

The
PDT

The request is then inserted on the PDT waiting queue, PDTWQ, and
control
is
given to the PDT end-of-record logic routine, 10PEL.
When control returns from 10PEL, the request is checked to see if
it is complete in 10RTN.
If so, control passes
to
the
nucleus
return routine, NFTRTN.
If the request is not complete and it is
not
an initiate mode request, the task state is set to suspended
for I/O, and control is given to
the
nucleus
suspend
routine,
NFSRTN.
If
the request is an initiate mode request, control is
given to NFTRTN.
IOPEL functions as a device control module
outside
of
hardware
interrupts, setting up requests to devices and returning requests
to tasks.
The loop for processing begins by calling a system log
routine,
LGDEV,
to
log any errors stored in the PDT.
Requests
are set up for the device if the PDT saved request block address,
PDTSRB, is zero and PDTWQ is not zero.
Before
any
processing,
IOPEL sets the hardware interrupt level in the status register to
prevent interrupts.
The first request is removed from PDTWQ, the
device map file is changed to map in the request, the data buffer
address
in
the
BRB
is
adjusted,
and control is given to the
device begin routine, IODBGN.
When control returns from IODBGN or if PDTSRB is nonzero, the PDT
spent request queue, PDTSRQ, is examined.
If PDTSRQ is
nonzero,
a
request is removed from it, and NFEOBR is called to insert the
request on the TSBEOR queue.
This then loops back to the logging
process.
If the device is busy or
there
are
no
more
waiting
requests
and
no more completed requests, control returns to the
calling routine.
IODBGN is an interface routine that changes the map file from the
current state to a state in which the DSR is mapped with its data
buffer.
IODBGN must be in the first of the three segments of map
file 0 in order to perform this function.
After the new map file
has been set up, the DSR is entered at the
request
entry
point
(one
of several entry points).
Alternate entry points in IODBGN
correspond to some of the other entry points in the
DSR.
These
alternate
entry
points
are
IODREE for system interrupt entry,
IODABT for request abort, and
IODTO
for
time-out,
IODPDS
for
priority
scheduling,
and
IODPU
for
power-up.
Before giving
control to the DSR, IODBGN saves the address of the PDT workspace
for power failure.

2270512-9701

10-7

I/O Subsystem

DNOS System Design Document

10.3.2

I/O Processing by the DSR.

A DSR is the request processor
for
a
physical
resource.
The
first, five
instructions beginning at relative location 0 of the
DSR must
be
branch
instructions.
These
branch
instructions
correspond
to
five
alternate entry points in the DSR.
A sixth
branch instruction must be included if the DSR uses priority
DSR
scheduling.
The branch instructions correspond to the following
alternate entry points.

Hardware interrupt, the routine that handles
from the device

System
interrupt,
the routine that handles the request
for
the
system
to
reenter
at
approximately
50
milliseconds later.

*
*

Power up, the routine that

interrupts

initializes the device.

Request
abort,
the routine that handles
request that the DSR is processing

the abort of a

Request
time-out,
the
routine
that
processes·· the
condition
in
which
the
device has not responded in a
certain length of time.

Initial request processing.
If priority DSR
scheduling
is
used
then
this must be a branch instruction to the
routine that handles
initial
request
processing.
If
priority
DSR
scheduling
is
not
used,
then
initial
request processing code begins here.

Priority DSR scheduler (optional)

If priority DSR scheduling is used, the instruction folloWing the
initial
request
processing
entry
point
is
the
routine
for
processing
requests
for
priority DSR scheduling.
Priority DSR
scheduling is used by DSRs which need to be reentered but do
not
want
to
wait
the 50 milliseconds for a system interrupt.
This
mechanism reenters the DSR after all interrupt processing to
the
system
is
complete
but before the task scheduler initiates any
task execution.
DSRs which use priority
scheduling
must
link
in
the
routine
IOPDSQ.
The
DSR requests priority scheduling by issuing a BLWP
@IOPDSQ instruction.
The routine IOPDSQ will queue
the
PDT
to
the
priority scheduling queue.
NFSCHD and NFTRTN check for PDTs
on this queue and reenter the DSR at
the
earliest
opportunity.
This
is
intended
for
use
only
by
high
priority
interrupt
processing.
Using this mechanism arbitrarily may interfere
with
other devices that use this entry point.
I/O Subsystem

10-8

2270512-9701

DNOS System Design Document

When
a
hardware
interrupt
occurs, the interrupt vector tables
(initialized
during
sysgen)
are
used
to
transfer
to
the
appropriate
interrupt decoder.
There are four decoders provided
with DNOS, each serving a class of devices:

*
*
*

A single device at a unique interrupt level
MUltiple devices at a single interrupt level
An expansion chassis at a single
interrupt
level
with
multiple
devices,
each
at
a
unique
interrupt level
within the chassis or multiple devices sharing a
unique
interrupt level within the chassis.

Single
device
or
device controller

Each interrupt
decoder
process the interrupt:

multiple

goes

devices

through

Save the current system map file
CURMAP).

Set
CURMAP
to
appropriate DSR.

the

a multiplexed

following

steps

pointer (accessed

via

for

the

5. When the DSR completes, restore CURMAP to point to
previous system map file.

the

DSR

map

file

pointer

3. Load the map file using CURMAP.

4. Enter the DSR at the hardware interrupt entry.

6. Load the map file using CURMAP.
7. Exit via NFTRTN.
The
text of the interrupt decoder can be found in the section on
writing a DSR in the DNOS Systems Programmer's Guide.
Whether handling hardware interrupts or entering the DSR at other
points, the DSR uses the PDT for the device as a reference point.
The section on data structure pictures includes
details
on
the
PDT.
A queue
header
in
the
PDT
allows the DSR to accept multiple
requests for
the
device
and
to
call
the
DSR end-of-record
routine,
ENDRCD,
as
many
times
as
necessary
to
dispose of
completed requests.
(ENDRCD is one of several
routines
in
the
module
IONRCD.)
To
handle the multiple requests, the DSR must
remove the request from PDTSRB (clearing PDTSRB) and
insert
the
request
on
the
PDT
hidden request queue, PDTHRQ.
By clearing

2270512-9701

10-9

I/O Subsystem

DNOS System Design Document

PDTSRB, the DSR appears to be not busy.
PDTHRQ
is
used
as
an
internal
queue
anchor for the DSR; the operating system can use
PDTHRQ to abort requests
or
to
allow
the
task
to
wait
for
requests.
ENDRCD
is
the
first step in returning the request to the task.
Not much can be done at this level because of the time spent with
hardware interrupts masked to the interrupt level of the
device.
ENDRCD
expects PDTSRB to contain the address of the request that
has just completed.
If PDTSRB is zero,
ENDRCD
returns
to
the
DSR.
If
PDTSRB
is
nonzero,
ENDRCD
removes the request from
PDTSRB, clears PDTSRB, and inserts the
request
at
the
end
of
PDTSRQ.
If the PDT end-of-record queue (PDTERQ) is zero, the PDT
is
inserted
at
the
end
of the list of PDTs that need end-ofrecord processing.
This list is anchored
by
EORNKR,
found
in
NFPTR, and has PDTs queued via their PDTERQ fields.
The priority
of
the
executing
task
is
compared
with the priority for the
requesting task.
If the request priority is higher,
the
global
forced
reschedule
flag,
RESCHD
(found
in
NFDATA), is set to
preempt the running task.
Control then returns to the DSR.
Figure 10-3 shows timing, system interrupt,
hardware
interrupt,
and
end-of-record
support for DSRs.
The figure highlights only
the main modules or routines.
The task scheduler, NFSCHD, interacts
with
the
I/O
system
to
handle
system
interrupt
and
end-of-record
functions.
When a
system time unit (SO milliseconds) has elapsed, NFSCHD calls
the
device
timer
routine,
IODTMR.
IODTMR traverses the PDT list,
examining it for flags set to reenter
a
DSR
and
to
wait
for
request
time-out.
When the reenter me flag is on, it is turned
off and IODREE· is called.
If the PDT is busy, the time-out
flag
is
on,
and the PDT times out, an error code for device time-out
is placed in the active request and IODTO is called.
(IODREE and
IODTO are alternate entry points to module IODBGN.)
NFSCHD
determines
that
device
end-of-record
processing
is
required
by
finding a nonzero value in the global queue anchor,
EORNKR.
When this occurs, the end-of-request routine
for
PDTs,
IOEOR, is called.
IOEOR removes the first PDT on EORNKR and then
calls IOPEL to process the end-of-record.
IOEOR removes each PDT
from
the
list
until
it
is
empty.
IOEOR then returns to the
scheduler.

I/O Subsystem

10-10

2270512-9701

DNOS System Design Document

+----~-----+

NFSCHD

+----------+
(BL)
I

------------------------+
I
I
V

+----------+
I
IODTMR
I
+----------+
(BL)
I
I
I
I
I
I
I

+----------+I
IOEOR
I
+----------+
(BL)
I
V

+----------+
I
IOPEL
I
+----------+
(BL)
I

+---------------------+-----------------------+
V V
V
V
+----------+
+----------+
+----------+
I
IODBGN
I
LGDEV
I
I
I
NFEOBR
I
+----------+
+----------+
+----------+
( BLWP)
(BLWP)
+----------+
I
V------(------------I hardware I
+----------+
I interrupti
I
DSR
I
I
decoder I
+----------+
+----------+
( BL)
1-----------------------+V
V
+----------+
+--------------------------+
10THER DSR SUPPORT ROUTINESI
I
IONRCD
I
+----------+
+--------------------------+
I

Figure 10-3

10.3.3

DSR Control Paths

Returning Information to the Requester.

Figure 10-4 shows how information is returned
to
the
requester
task.
After
a task is scheduled and prior to execution, NFTRTN
is called.
(NFTRTN is also the exit point for nonsuspending
SVC
processors.)
Before
NFTRTN
returns
control
to the requester
task, the TSBEOR field of its
TSB
is
examined
for
a
nonzero
value.
When TSBEOR is zero, control drops through for the other
checks.
Otherwise, RPDQUE is called.

2270512-9701

10-11

I/O Subsystem

DNOS System Design Document

NFSRTN is similar in nature to NFTRTN except that it is the
exit
for
SVCs that suspend task scheduling.
Before suspending
the task, NFTRTN examines TSBEOR for a nonzero value.
When it is
zero~
control
drops
through
and
the
task
is
suspended.
Otherwise, RPDQUE is called.

~oint

RPDQUE
removes the first entry from TSBEOR.
RPDQUE examines the
SVC code in the BRB, unbuffers the error code, and calls the
SVC
post
processor
if
one
exists.
The post processor for I/O is
IOPOST.
When control returns from IOPOST,
RPDQUE
releases
the
BRB,
checks
for
another
entry on the queue and processes any.
When no entries remain, it returns to its caller.
IOPOST examines the subopcode
to
determine
if
it
is
an
I/O
utility
opcode.
If so, parameter buffers are released and other
information is unbuffered to the task.
If the request
was
made
through
IODDIO
in
IODEVR, the LDT address is zero and requests
are not unbuffered.
Otherwise, the system flags are
unbuffered.
For
relative
record files, the record number is returned to the
task.
For
VDT
requests,
the
extended
user
information
is
unbuffered.
The SVC subopcode is then used to index into a table
to unbuffer Open, Read, and Write information.
For
Open
subopcodes, the resource type is returned to the task.
If an error code is in the BRB for an Open or a Close,
both
the
LDT
and
the
RPB
are
closed.
For a Read subopcode, the data
buffer is move'd to the
task
data
buffer
if
the
buffer
beet
address
in
the
BRO,
BROBBA, is a nonzero value.
If BROBBA is
zero, the buffer has already been moved by Some other
processor.
Control then passes back to the caller, RPDQUE.

I/O Subsystem

10-12

2270512-9701

DNOS System Design Document

+----------+
IREQUESTER 1<-------------------------+
1
TASK
I
1
+----------+
I
I
+----------+
+-----------+
I
I

+----------+
I
+----------+
I
+----------+
J
J
NFSRTN
J
1
I
NFSCHD
1
I
I
NFTRTN
J
1
+----------+
I
+----------+
J
+----------+
J
(BL)
I
(B)
I
(BL)
I
I-(B)--------+
+-----------+
J
1
I
I--(RTWP)+
1 +---------------------------------------------+

V V
+----------+
I
RPDQUE
I
+----------+
(BL)
1-----------------------+

+----------+
I
IOPOST
I
+----------+
Figure 10-4

10.3.4

+-------------------------+
10THER SVC POST PROCESSORSI
+-------------------------+
Returning Information to the Requester

Bidding a Task from a DSR.

DNOS
provides a means to bid a task from a DSR.
A two character
sequence must be entered to initiate the
task
bid.
The- first
character entered is the arming character, Attention.
The second
character
entered
is
used to identify the task to be bid.
For
example, the sequence Attention!
can be used to
bid
SCI.
In
addition
to the task bid sequences, DNOS processes the following
character pairs as indicated:
Attention Attention - halt current output to screen,
resume output
Attention Return - abort I/O to the screen
Attention Control-X - break - terminate current task
Attention N - bid the network logon task
These can be redefined or more character sequences can be defined
by the user.
For each task
to
bid,
the
user
must
supply
a
Command
Definition
Entry (CDE).
The CDE is associated with the
type of device at which the bid can be made.
During IPL, a
file
of
CDE
tables is initialized for each type of device that might
be used for
task
bidding.
This
file
is
assumed
to
be
in
VOL.S$CDT.xxx,
where
VOL is a synonym for the disk volume being
2270512-9701

10-13

I/O Subsystem

DNOS System Design Document

used as a data disk and xxx is

the name of

the generated system.

The format of a CDE is shown in the
section
on
data
structure
pictures.
Each
CDE
includes
a task ID for a logon task to be
bid, as well as a task ID for the task to be
bid
by
the
logon
task,
flags,
and parameters for the task to be bid by the logon
task.
The logon task is either the task supplied
with
DNOS
or
some
user-written
substitute.
The supplied logon task solicits
user ID and passcode, verifies their accuracy, and bids the
task
specified
in
byte 3 of the CDE.
(More detail on the logon task
can be found in the section on system tasks.)
When a keystroke defined by a CDE is used at a terminal, the
DSR
makes
several
entries
to
system data structures.
If no other
task is currently awaiting bid for the terminal in question,
the
PDTCHR field of the terminal PDT is set to the character entered.
The
PDT
is linked to the global list of PDTs with pending bids,
using the PDTBQ field as
a
link
field.
The
global
list
is
anchored at BIDREQ, located in NFPTR.
When
the
scheduler
is
scanning
lists
to find an activity to
begin, it examines the BIDREQ anchor to see if any
PDT
needs
a
task
bid.
If
the
anchor
is
nonzero, the scheduler bids the
system task IOTBID to serve the queue of requests.
IOTBID takes the first request from the queue and examines it for
validity.
It first ensures that
the
terminal
is
on-line
and
available for use.
IOTBID
then
issues a Bid Task from a DSR ()C7) subopcode of the
I/O SVC to bid the appropriate task as defined by the CDE.
Refer
to the section on the device I/O utility (DIOU) for more
details
of that bid process.

10.3.5

Handling Large I/O Buffers.

The
use
of
full-duplex operations for communication requires a
strategy to handle many large data buffers.
DNOS
uses
the
BTA
for
large
buffers rather than allocating them from STA.
Figure
10-5 shows in general how buffers are mapped with I/O processing.
The BTA was designed to accommodate transient buffers; therefore,
the BTA dynamically expands and contracts.
During sysgen, static
allocation limits are set.
By using
the
Static
Buffer
Forced
Roll SVC ()4A), the system can interrogate, increase, or decrease
the size of the BTA.
The BTA immediately precedes available user
memory;
when
increased, the BTA causes user memory to decrease.
This may cause forced swap of user segments
that
are
occupying
the
requested
area.
SVC
)4A
is
detailed
in the section on
special SVC support.

I/O Subsystem

10-14

2270512-9701

DNOS System Design Document

Since the buffers are not in STA, it is possible
to
dynamically
get and release BTA buffers from a DSR.
Subroutines are provided
for
the DSR to get BTA (IOGBLK) or release BTA (IORBLK).
To use
IOGBLK, BL to the subroutine with
workspace
register
10
(RIO)
containing the size of the buffer (bytes).
On returning from the
subroutine, workspace register 0 contains the status code for the
request.
It
will be 0 if no errors occurred while getting BTA.
RIO will contain the beet address of the allocated
memory.
The
value
returned
in
RIO
should
be
stored in the buffered beet
address field (BROBBA) of the BRB that
will
be
receiving
this
buffer.
The I/O system uses BROBBA as a beet address within the
BTA to release the buffer.
The first usable address relative
to
the
start
of
the
allocated
BTA buffer is the value of BBAOFF
found in the CSEG NFWORD.
The BTA can be addressed locally by the DSR if the BTA is
mapped
in.
Before
mapping
in the BTA, it is necessary to map out the
buffer currently mapped in (if
one
is
present
and
if
it
is
different
from
the new one).
This is accomplished by a call to
the subroutine IOMPOT, which uses RI as
a
pointer
to
the
BRB
containing
the
pointer to the buffer to be mapped out.
Mapping
in the new buffer is achieved by pointing RI and
PDTSRB
to
the
desired
BRB
and
by
placing
the value of BBAOFF in the IRBDBA
field of the BRB.
Then the DSR calls the
subroutine
IOMPIN
to
map in the BTA.
This causes the IRBDBA field to contain a buffer
address within the logical address space of the DSR.
To
release
BTA,
the
DSR calls the subroutine IORBLK, with RIO
containing the beet address in the BTA of the buffer to
release.
On returning from the subroutine, RO contains the status code for
the
request.
RO will be zero if no error was detected.
After a
buffer in the BTA is released, BROBBA in
the
corresponding
BRB
must be set to zero.
Control
of
buffering
for
a
DSR
is
specified by information
contained in the PDT of each device.
PDTDSF
contains
the
two
flags, DSFBI and DSFBO.
DSFBI controls the input.
When it is 1,
a
buffer is allocated in the BTA for a read request.
When it is
0, a buffer is not allocated for read requests.
DSFBO
controls
the output.
When it is 1, a buffer is allocated in the BTA for a
write
request,
and the output data is copied to the buffer from
the task address space.
When
DSFBO
is
0,
a
buffer
is
not
allocated and not copied for write requests.

2270512-9701

10-15

I/O Subsystem

DNOS System Design Document

Physical memory

+----------------------------------------------------------+
1 DNOSIMemory-Resident 1
1 Root 1

DNOS Code

IMemory-Resident 1 Buffer
DNOS Code
1
Table
1
1
Area

1 DSRI

User
1
Task
1
1 Memory 1

+-1--------------------1------------------1---------1------+
1

+---------------1

1 +----------------------1

+--1--1------+

+-----------------+
1 1
1
+--1-----1--1------1---+
1 DNOS
1 Root

1
Data
1 Buffer

1
1

DSR 1

+----------------------+

6000
DSR Logical Memory

Figure 10-5

10.3.6

Device I/O Buffering

Converting a DX10 DSR for DNOS.

Because
of
different
internal
operating system structures and
because of some added functions, DNOS DSRs are slightly different
from their DXIO counterparts.
A user who has his
own
DXIO
DSR
must change his DSR to meet DNOS standards.
Before
making
any
code
changes,
the
user
should
study the
relevant data structure templates used in DNOS:
the
PDT,
IRB,
BRO,
and any other templates whose counterparts were used in the
DXIO DSR.
Within the DSR code itself, the set
of
definitions
(DEFs)
and
references
(REFs)
must be changed.
The DNOS I/O system uses no
DEFs supplied by the DSR.
The only DEFs that
must
be
supplied
are
those required by modules used by the user's DSR.
Any other
DEFs may be deleted.
Several DXIO REFs are not used by the DNOS DSR.
Delete the
REFs
to
the subroutines SETWPS, BZYCHK, and MAPCHK.
Replacements for
these references are discussed in the following paragraphs.
The
REF for KEYFUN should be replaced by IOFCDT, and the template for
NFPTR,
DSC.TEMPLATE.COMMON.NFPTR, should be copied into the DSR.
The REF for BRCALL or JMCALL should be replaced by BRSTAT.
REFs
to
byte
and/or word constants should be deleted and replaced by
copying in the appropriate template:

I/O Subsystem

10-16

2270512-9701

DNOS System Design Document

BYTEOO
BYTEIO
BYTE20
BYTE30
BYTE40
BYTE50
BYTE60
BYTE70
BYTE80
BYTE90
BYTEAO
BYTEBO
BYTECO
BYTEDO
BYTEEO
BYTEFO
WDOOOI

- BYTEOF
- BYTE1F
- BYTE2F
- BYTE3F
- BYTE4F
- BYTE5F
- BYTE6F
- BYTE7F
- BYTE8F
- BYTE9F
- BYTEAF
- BYTEBF
- BYTECF
- BYTEDF
- BYTEEF
- BYTEFF
- WD8000

DSC.TEMPLATE.COMMON.NFEROO
DSC.TEMPLATE.COMMON.NFERIO
DSC.TEMPLATE.COMMON.NFER20
DSC.TEMPLATE.COMMON.NFER30
DSC.TEMPLATE.COMMON.NFER40
DSC.TEMPLATE.COMMON.NFER50
DSC.TEMPLATE.COMMON.NFER60
DSC.TEMPLATE.COMMON.NFER70
DSC.TEMPLATE.COMMON.NFER80
DSC.TEMPLATE.COMMON.NFER90
DSC.TEMPLATE.COMMON.NFERAO
DSC.TEMPLATE.COMMON.NFERBO
DSC.TEMPLATE.COMMON.NFERCO
DSC.TEMPLATE.COMMON.NFERDO
DSC.TEMP~ATE.COMMON.NFEREO

DSC.TEMPLATE.COMMON.NFERFO
DSC.TEMPLATE.COMMON.NFWORD

To allow for the addition of new
devices
at
IPL
and
for
the
reinstallation
of
a
new,
modified,
or
corrected DSR without
linking the entire system, the first addresses of the DSR must be
the following instructions:
B
B
B
B
B
B ••
B

@Hardware interrupt entry address
@System reenter me entry address
@Power up entry address
@Abort entry address
@Time-out entry address
@Request entry address
@Priority DSR scheduler

No data or subroutine code can precede these instructions.
replace the following DX10 entry points:
DATA power-up entry address
DATA abort entry address
DSR executable code for
In DXIO, the following is the first

They

request entry
DSR executable code:

LIMI 0
BL
@SETWPS
This
code is not required and should be deleted for DNOS because
the I/O system performs this function prior to entering the DSR.
Two differences in the data structures affect code
in
the
DSR.
They
involve
the
pointers
in Rl and R4 of the PDT.
Rl is the
pointer to the BRB.
The BRB, a concatenation of the BRO and
the
IRB,
is
called the UCB in DX10.
The relevant change in DNOS is
the position to which Rl points in the BRB.
In DXIO, Rl
pointed
2270512-9701

10-17

I/O Subsystem

DNOS System Design Document

to
the
word
containing
the subopcode and LUNO of the BRB.
In
DNOS, Rl points to the word containing the
SVC
code
and
error
byte.
PDTSRB
points
to
the same place.
The DSR code must be
changed to reflect the new pointer.
Any references to
the
DXIO
structures
named
PRB
and UCB must be changed to the equivalent
references to the DNOS structure named IRB.
R4 points to the device information block (DIB) of the PDT.
(The
device information block is the PDT and any PDT extensions.)
In
DXIO, R4 pointed to the word beyond the end of the PDT.
In DNOS,
R4 points to the first word of the PDT, the PDT link word PDTPDT.
The
DSR
must
be
changed
to reflect the new pointer location.
References to DXIO PDT offsets
must
be
changed
to
equivalent
references
to
PDT
template offsets.
PDT labels should be used
rather than hard-coded offset values.
The subopcode processor, BRCALL or JMCALL, has been
enhanced
to
collect information for on-line diagnostics.
BRCALL can still be
called,
but
note
that
RIO
will be modified.
The replacement
subroutine call is to BRSTAT.
It uses RIO as a pointer to a byte
table that contains relative offsets into the
PDT.
If
RIO
is
zero,
it
is
not
used
as
a pointer.
The table is built with
entries for each subopcode.
The on-line diagnostics code
counts
types
of
requests
for
physical
I/O.
The entries in the byte
table are chosen from 0, PDTRC, PDTWC, or PDTMC; these correspond
to the null request counter, the read request counter, the
write
request
counter,
and
the
miscellaneous
request
counter,
respectively.
Build the diagnostics table appropriately for
the
physical device if this function is chosen.
The table for BRSTAT
is the same as for BRCALL.
One
of the subroutines for keyboard devices has a different name
in DNOS and DXIO.
The subroutine KEYFUN in DXIO is named
IOFCDT
in
DNOS.
IOFCDT
performs the same function as KEYFUN; it also
performs a new function, bidding a task from
a
DSR.
(See
the
paragraphs
describing
bidding
a
task from a DSR for details.)
All task bids
in
a
DX10
DSR must
be
removed
in
the
DNOS
equivalent.
IOFCDT
controls processing of all bids, including the bid of SCI
at the terminal.
(SCI may be
bid
with
or
without
the
logon
task.)
IOFCDT also
processes the hard break sequence, bidding
the IOBREAK task.
The keys used to bid SCI and
the
hard
break
sequence are defined in the CDE for the terminal type during IPL.

I/O Subsystem

10-18

2270512-9701

DNOS System Design Document

For
devices
with
no
KSB associated with the PDT, a bid can be
accomplished by direct queue manipulation in place of a
call
to
IOFCDT.
To place the entry on the queue, first examine the byte
field PDTCHR.
If the field is nonzero, a task is waiting
to
be
bid
and
another entry is not allowed.
If PDTCHR is zero, place
the character in the PDTCHR field.
Mask interrupts
to
level
2
and
find
the
end of the queue whose anchor is BIDREQ (found in
NFPTR).
Link the PDT to the last one
on
the
queue
using
the
field
PDTBQ.
Clear PDTBQ in this PDT, and enable interrupts to
the proper level.
The REFs for BZYCHK, SETWPS, and MAPCHK must be deleted.
the call to BZYCHK with code like the following:

Replace

MOV
@PDTSRB(R4),R7
device busy code
JNE
RTWP
The function previously performed by MAPCHK is now
performed
by
the
I/O
system
prior to entering the DSR.
Therefore, any code
that references MAPCHK must be removed from the DXI0 DSR for
use
with DNOS.
In
addition
to
the features already mentioned, some others are
provided by the I/O system.
The error code is
placed
into
the
BRB in power-up and abort situations.
The error flag for the IRB
is
set
in the BRB whenever a nonzero value is detected in the error
byte of the BRB.
For processing an end-of-record for a DSR, the subroutine
ENDRCD
has
been
enhanced
to
accommodate
successive calls to perform
mUltiple end-of-record
requests.
To
take
advantage
of
this
feature,
correctly
set
up
the
pointer
PDTSRB before calling
ENDRCD.
PDTSRB is the point~r to the
saved
request
block
and
must
point
to
the SVC and error byte of the BRB.
If PDTSRB is
zero, nothing occurs in the subroutine ENDRCD.
For a DSR that must multiplex
its
input
and
output,
a
queue
anchor
for
this
purpose
is
included
in the PDT.
When a DSR
wishes to receive a second request, it must
appear
to
the
I/O
system
to be not busy.
The DSR achieves this by mapping out the
current request and clearing PDTSRB.
It must then keep the first
request available by queuing it
to
the
hidden
request
queue,
PDTHRQ,
using the link word BROBRO in the BRB.
In this way, the
I/O system can find a request ?eing aborted and
flag
the
error
byte
with a )10 error code.
During an abort, the DSR is entered
at the abort entry and must examine PDTHRQ and abort the requests
marked with an error code of )10.
If the DSR multiplexes two or more requests at the same time,
it
must be careful when accessing a buffer.
The buffer for only the
request
given
to
the DSR is mapped into the DSR address space.

2270512-9701

10-19

I/O Subsystem

DNOS System Design Document

The mapping information for the other request
remains
with
the
request.
Therefore, the subroutine lOMPOT must be called to map
out a request buffer before inserting the request
on
the
queue
anchor
PDTHRQ.
R1 must point to the SVC and error code byte of
the BRB.
To map the request buffer into the DSR address
space,
the
subroutine lOMPlN must be called.
R1 must point to the word
of the BRB that contains the SVC code and error byte.
Neither of
these subroutines modifies PDTSRB.
While it should cause no code changes,
DNOS is larger than that in DX10.

the size

the

PDT

Special
problems
that
will cause some re-design of the DSR are
the inaccessibility of the LDT and the
TSB.
Although
pointers
exist
in the BRO portion of the BRB, the segments containing the
structures may
be
swapped
out
of
memory.
No
mechanism
is
provided
to the DSR to place one of these structures into memory
or to map the structure into the logical
address
space
of
the
DSR.
Typical
problems
encountered
while debugging the converted DSR
are attempts to access flags contained in the PDT
registers
and
improper use of the pointers in R1 and R4.
Check the PDT flags
used
by
the
DSR
to
make
certain
that
they
exist
and are
referenced by label.
The problems associated with R1 and R4 usually result from
using
the
same
method
of
reference
in
DNOS as in DX10.
Since the
values in R1 and R4 are pointers to the
start
of
a
structure,
referencing
must
be
via
the
appropriate
template
fields as
follows:
DX10 ••
MOV
MOV
ABS

*R 1 , •••
*R4, •••
*R4

MOV
MOV

••• , *R 1
••• , *R4

DNO S ••••••••
@lRBSOC(R1) , •••
MOV
MOV
@PDTSIZ(R4), •••
ABS
@PDTSIZ(R4)
or
MOV
MOV

••• ,@IRBSOC(R1)
••• ,@PDTSIZ(R4)

After assembling the DSR, it must
be
linked
with
all
of
the
required
support
subroutines.
This
must
be
done
with each
release of the operatLng system, not
with
each
sysgen
between
releases.
Figure
10-6 shows a typical link control stream used
to link a DSR.

I/O Subsystem

10- 20

2270512-9701

DNOS System Design Document

NOPAGE
ERROR
FORMAT COMPRESSED
PROCEDURE DUMROOT
DUHMY
INCLUDE
VOL.S$SGU$.DUMROOT
PHASE O,DUMROOT
DUMMY
PHASE I,DSRname,PROG )COOO
INCLUDE
VOL.DSRobject pathname
INCLUDE
VOL.IOMGR.OBJECT.IONRCD
(include any other support routines)
END
Figure 10-6

DSR Link Control Stream

The
linked
object
should
be
placed
in
the
file
VOL.S$SGU$.DSRname.
VOL is a synonym for the volume name of the
data disk being used for sysgen.
Table 10-1 shows the modules required for the support subroutines
and the registers altered by each of the subroutines.
Table 10-1

Location of Support Subroutines for DSRs

Module Name

Subroutine

Registers
Changed

VOL.IOMGR.OBJECT.IOBMGT

IOMPIN
10MPOT
IOGBLK
IORBLK

RO
RO
RO,RI0
RO

VOL.IOMGR.OBJECT.IOKB

10FCDT
CMODE
PUTEBF
PUTCBF
GETC
ASCCHK
ASCCK2

R6
R5,R7,R9,RIO

VOL.IOMGR.OBJECT.IONRCD

BRSTAT
BRCALL
ENDRCD

RO,RIO
RO,RI0
RO,RIO

VOL.IOMGR.OBJECT.IOTILN

GTADDR
XFERM
TILERR

2270512-9701

10-21

R9
RIO
RIO

R9,RI0
R6,R9,RI0
R8,R9

I/O Subsystem

DNOS System Design Document

10.4

TELEPRINTER TERMINAL DSR

DNOS contains several hardcopy terminal-driver DSR's:
DSR

TERMINALS

DSRTPD

FUNCTIONALITY

703,707,743,745,763,765,
78X,820,825
713, 742, 782

DSRKSR

Local,

remote

KSR

Local,

remote KSR

This section describes details about DSRTPD as a detailed example
of a DNOS DSR.
Direct connection for teleprinter terminals
the following cable combinations:
TERMINALSI

supported

using

CON T R 0 L L E R S

-------+---------------------------------------------------------I
I

743/745

TTY/EIA

COMMIF

/10A 9902 PORT S300 AUX 2 PORT
CI402
CI422

+---------------------------------------------------------0948968-0001

763/765

2265151-0001
+2263351-0001
+2200051-0001
78X/820
2262093-0001

0946117-0001
+2263351-0001
+0983848-0001
0946117-0001
+2263351-0001
+2200051-0001
0946117-0001
+2263351-0001
+2207634-0001
or0946117
+0993210-0001

703/707

2303077-0001

2230504

2303077-0001

2230504

Full-duplex modems compatible with Bell 103, 212a, 113, and Vadic
VA3400
series
are
supported,
with cable 2265151-0001 from the
TTY/EIA board, cable
946117-0001
from
the
COMM
board,
cable
2303070-0001
from
non
S300
9902 ports, and cable 2532883-0001
from S300 9902 ports.
Half-duplex operation is not available
to
these
terminals through the TTY/EIA interface module.
Auto-call
support is provided through the Teleprinter Device
Utilities
of
SCI.
DNOS
has
each kind
interface
dedicated
approach,
terminals
hardware
operating

adopted a philosophy of generat.ing a dedicated DSR for
of I/O device supported,
and
of
limiting
access
to
cards
(within
a given configuration) to one of these
DSRs.
DSRTPD is to some extent a departure
from
this
as
it
allows a number of different kinds of computer
to be serviced from one DSR and one piece of
interface
at
different
times
without
re-generation
of
the
system.
SCI functions with DSRTPD and the DNOS
sysgen

I/O Subsystem

10-22

2270512-9701

DNOS System Design Document

processor
comprehends
by DSRTPD.

10.4.1

the parameters and PDT structure required

DSRTPD Structures.

The teleprinter device family (designated KSR) is
identified
by
sysgen
to
include a wide variety of teleprinter terminals.
The
teleprinter device type code returned by
an
open
operation
is
)0001
for
this device family.
The resource type returned on an
assign luno for the teleprinter device family is )0902.

10.4.2

PDT Structures.

The TPD PDT is structured as follows:

+------------------------+
PDT (built by SYSGEN)
non-interrupt WS
DNOS flags
xxxxxxxxxxxxxxxxxxxxxxxx
KSB (built by SYSGEN)
interrupt WS
DNOS flags
xxxxxxxxxxxxxxxxxxxxxxxx

<---+I
I

----+
----+

DIB (built by SYSGEN)
working parameter set
scratch area
default parameter set
error counters
KSBCBF
input character buffer
(built by SYSGEN)

I
I
I
I
I
I
I
I
I

<---+

The Device Information Block (DIB) is a data
structure
appended
to the PDT which contains information about the current status of
the
device
as
well
as information about how it was configured
during system generation.
The
DSRTPD
DIB
has
the
following
structure:
'*' DENOTES FIELDS INITIALIZED BY SYSGEN
DIBACR DATA 0
DIBHWR BYTE 0

*
*
2270512-9701

*ACU CRU ADDRESS()FFFF
*INTERFACE TYPE
I=COMM/IF
2=FCCC

10-23

IF NONE)

I/O Subsystem

DNOS System Design Document

*
*
*
*
DIBRTO
DIBWTO
DIBDTI
DIBDT2
DIBGFL

BYTE 0
DATA 0
DATA 0
D'ATA 0
DATA 0
FLAGS 8
FLAG GFLECO
BITS 1
FLAG GFLXPE
BITS 2

*
*
*
*

FLAG GFLRPE
BITS 2
DIBSTF FLAGS 8
FLAG STFONL
FLAG STFCIP
FLAG STFOP N
FLAG STFDLE
FLAG STFHDX
FLAG STFRSD

DIBLNF FLAGS 8
FLAG LNFHDX
FLAG LNFSWT
FLAG LNFRCL
FLAG LNFADE
FLAG LNFDLE
FLAG LNFSCF
FLAG LNFEXC
FLAG LNFHDL
DIBTFL FLAGS 8
FLAG TFLECO
BITS 1
FLAG TFLXPE
BITS 2
FLAG TFLRPE
DIBSPD BYTE a

*
*
*
*
*
*
*
*
I/O Subsystem

3=BCAIM
4=HSCC
5=TTY/EIA
6= 9902
RESERVED
*READ TIMEOUT (IN 1/4 SECONDS)
*WRITE TIMEOUT(IN 1/4 SECONDS)
*FIRST DIRECT TIMEOUT (IN 1/4 SEC)
*SECOND DIRECT TIMEOUT (IN 1/4 SEC)
*SYSGEN FLAGS (SAME AS DIBTFL)
ECHO (I=NO ECHO)
UNUSED
XMIT PARITY ENABLED(I=ENABLED)
XMIT PARITY TYPE
OO=EVEN
01=ODD
10=HARK
II=SPACE
RECEIVE PARITY ENABLED
RECEIVE PARITY TYPE
STATE FLAGS
O=ONLINE
I=CONNECT IN PROGRESS
2=OPEN
3= DLE RE CE I VED
4=HDUX LINE BELONGS TO REMOTE
5=RESEND FLAG
6=UNUSED
7-8=BIT DATA QUEUEING
*LINE FLAGS
*HALF DUPLEX (I=HALF DUPLEX)
*SWITCHED LINE (l=SWITCHED)
REFUSE CALL
AUTO-DISCONNECT ENABLED
DLE/EOT FOR DISCONNECT
SCF READY/BUSY MONITOR
FILE XFER EXCLUSIVE ACCESS
HALF DUPLEX LTA ENABLE
TEMPORARY ACCESS FLAGS
ECHO (l=NO ECHO)
UNUSED
XMIT PARITY ENABLED
UNUSED
RECEIVE PARITY ENABLED
*BAUD RATE (SPEED)
-1=300 OR 1200 SELECTED
BY 212 MODEM
0= 11 0
1=300
2=600
3=1200
4=2400
5=4800
10-24

2270512-9701

DNOS System Design Document

*DIBEOR
DIBEOF
DIBLTA
DIBSUB
DIBDLA
DIBPCR
DIBPSR
DIBMXC
DIBTRM
DIBLCR
DIBXFL
DIBSVE
DIBGSP
DIBISR
DIBGTO
DIBPEC
DIBLCC
DIBSIZ
10.4.3

BYTE 0
BYTE 0
BYTE 0
BYTE 0
BYTE 0
DATA 0
DATA 0
DATA 0
BYTE 0
BYTE 0
FLAGS 16
BYTE 0
BYTE 0
DATA 0
DATA 0
DATA 0
DATA 0
EQU
$-DIBBGN

6=9600
*END OF RECORD (=CR)
*END OF MEDIUM (=EM)
*LINE TURNAROUND (=EOT)
*PARITY ERROR SUBSTITUTE (='?')
CARRIAGE RETURN DELAY INTERVAL
PARITY CHECK ROUTINE ADDRESS
PARITY SET ROUTINE ADDRESS
MAXIMUM CHARACTERS BUFFERED
*TERMINAL TYPE (=TYPE-700)
LAST CHARACTER RECEIVED
SAVED EXTENDED FLAGS
SAVED ERROR CODE FROM DSR
*CURRENT SPEED (SAME AS DIBSPD)
RESERVED
*GENNED TIMEOUT(IN 1/4 SECONDS)
NUMBER OF PARITY ERRORS
NUMBER OF LOST CHARACTERS
SIZE OF DIB

DSRTPD Functions.

The
DSR has
a
power
up
entry point labelled PWRON.
Powerup
processing consists of copying default
paramete~s
to
the
DIB,
setting
the
state
of
the
interface
module
accordingly, and
setting values for the EIA lines which
are
appropriate
to
the
line mode:
1. For switched lines, all lines are forced low until Ring
Indicate
is
sensed or until the modem's online signal
is detected:
Data Carrier Detect for full duplex, Data
Set Ready for half-duplex.
Because DCD is not
present
for the 9902 port on the /lOA controller, switched line
is nDt supported for that configuration.
2. For unswitched lines, Data Terminal Ready
is
asserted
and
the
DSR
looks
for
Data
Set
Ready before each
character is transmitted.
Abort
The DSR has an abort I/O entry point labelled ABORT.
I/O
processing
consists
of terminating any I/O in progress with ~he
abort error code ()10) and returning the DSR to the
idle
state.
Timeouts
appear
to
DNOS
to
be
disabled, but the DSR handles
timeouts internally.
10.4.4

DSRTPD Details.

DSRTPD is built of five
modules:
DSRTPD,
DSCOMISR,
DSTTYISR,
DSISR402,
and
DSTPDCOM.
The DSR uses a vector table to access
various hardware-related functions.
2270512-9701

10-25

I/O Subsystem

DNOS System Design Document

DSRTPD
This module is the request processor interface.
Its code is
completely hardware independent.
When a
hardware-dependent
function
needs
to
be
performed, it goes through a vector
table and enters the appropriate hardware-dependent
module.
This
module
uses
the
PDT workspace
exclusively.
It
maintains a set of state tables that
are
used
to
control
interrupt-driven functions.
DSCOMISR
The COMM board driver module is named DSCOMISR.
It contains
code that is executed from both the PDT and KSB workspaces.
DSTTYISR
Th~

TTY/EIA driver is

called DSTTYISR.

DSISR402
All
9902
controllers (CI402, CI421, CI422, 110A 9902 port)
use this hardware driver.
It contains code that is executed
frum both PDT and KSB workspaces.
DSTPDCOM
This module
performs
character
processing
for
DSTTYISR,
DSCOMISR
and
DSISR402.
It is entered when read interrupts
are detected.
This module places characters in the KSB fifo
in such
a
way
that
event
and
Katakana
characters
are
recognizeable
to
DNOS.
When reads are outstanding to the
port, it enters DSRTPD at the interrupt level via a BLWP for
processing the Read request.
Vector Table
The vector table contains
entries
for
discrete
hardwarerelated
functions.
A subroutine
call
to
a fixed table
offset
indexed
by
the
table
address
is
sufficient
to
transfer into hardware-dependent code.
Vector table entries
are provided for the following functions:
1.

Initialize power up

2. Disconnect

3. Control half-duplex Modem
4.

Select speed

5. Output 8-bit characters

6. Report carrier and Data Set Ready status
7. Read interface image

8. Write interface image

I/O Subsystem

10-26

2270512-9701

DNOS System Design Document

Start

timer and schedule completion processor

10. Decode interrupt and service
11. Monito~ line for

through state table

incoming call

12. Establish connection
13. Abort without waiting to drop RTS

10.4.5

DSRTPD Defaults.

The
defaults
maintained by DSRTPD correspond to the current 990
operating parameters for the terminal family and to the
mode
of
operation used by DNOS utilities (such as SCI).
Parameters
pertaining
to
communication
line management and to
modem operation default to the following set:
1. Accept incoming call.
2. Disconnect on receipt of DLE EOT.
3. Transmit even parity
4.

Set receive parity bit

to O.

5. End of record character
6.

End of file

character

7. LTA character

CR
EM

EOT

8. Parity error substitute character = ?

10.5

ASYNCHRONOUS DSR STRUCTURE

A unique DSR structure has been designed for asynchronous
device
support.
Information about this structure and the routines used
to write
a
custom
DSR
can
be
found
in
the
DNOS System
Programmer's
Guide.
The
material
in
this
manual
is
implementation detail about the asynchrous DSRs.
The information
in the DNOS System Programmer's Guide should be read before
this
section.

2270512-9701

10-27

I/O Subsystem

DNOS System Design Document

OPERATING SYSTEM

/1\
I
I

\1/

+-------------+
I
I
I
I
I

TSR
Terminal
Service
Routine

I
I
I

I
I

+-------------+
/1\
I

I TSR
ISchedule
I

+-------------+
ISR
I Interrupt
I Service
I Routine
I

I
I

I
I
I

+-------------+
I

BLI
I

\ /

\ 1/

+-------------+
I HSR

I Controller
I Service
I Routine

I
I
I

Controller
Interrupt

+-------------+
/1\
I
I

\1/

+---------------------+
I

CONTROLLER

+---------------------+
Figure 10-7

I/O Subsystem

DSR Structure

10- 28

2270512-9701

DNOS System Design Document

The
asynchronus
DSR
design
separates
controller
and
device
support into different software modules.
The
DSR
consists
of
three
basic
modules.
The controller support is provided by the
HSR (Hardware controller Service
Routine)
module.
The
device
support is provided by the TSR (Terminal Service Routine) module.
The
ISR
(Interrupt
Service
Routine)
has
interrupt
and high
priority processing responsibility.
Table 10-2 lists
the
basic
functions
of the DSR components.
The functions are discussed in
detail in the DNOS Systems Programmer's Guide.
Table 10-2
TSR - TERMINAL
SERVICE ROUTINE

Asynchronous DSR Module Functions

*
*
*
*

All DSR entry points
(Request/Initial, Power up, Abort/Timeout,
Delayed Reentry, and Interrupt Entry)
Request and completion reporting I/F to DNOS
Runs in PDT workspace
Provides software interface to device
Contains device-dependent logic

ISR - INTERRUPT
SERVICE ROUTINE

*
*
*

Interface to HSR for interrupt processing
High priority receive character processing
Runs in DSR interrupt workspace

HSR - CONTROLLER
SERVICE ROUTINE

Generic (subroutine) software interface
to the controller hardware
Contains all controller-dependent logic
Contains all direct access to controller
Emulation of buffered controller
- Hardware/Software FIFOs

*
*
*

There are two mechanisms for scheduling the TSR from an ISR:

*
*

Reenter-me
DSR priority schedule

Both of these mechanisms enter the DSR in the PDT workspace.
The
DSR is reentered when the next system clock interval
expires
if
the reenter-me mechanism is invoked.
Refer to the description of
the
reenter-me
mechanism
in the section on device I/O handling
for further details.
Another mechanism for scheduling
DSR
noninterrupt processing (TSR) from DSR interrupt processing (ISR) is
the DSR priority schedule mechanism.
This mechanism reenters the
DSR
after
all
interrupt processing for the system is complete,
but before the
operating
system
task
scheduler
or
any
task
executes.
This is a more direct reentry path to the DSR.
It is
intended
only
for
the
highest
priority
(non-interrupt)
processing.
If
this
mechanism
is
used
arbitrarily,
it can

2270512-9701

10-29

I/O Subsystem

DNOS System Design Document

interfere with high

priority processing of other DSRs.

Table 10-3 describes the requirements for DSR (TSR) entry
points
when
the
DSR
priority
schedule
mechanism
is
used.
The DSR
priority schedule entry point is at relative address )14.
Table 10-3
0000
0004
0008
OOOC
0010
0014
0018

B
B
B
B
B
B
B

@HINT
@SINT
@PWRUP
@ABORT
@TIMOUT
@REQUEST
@PRISCH

DSR/TSR Entry Points

Hardware interrupt entry
System interrupt entry
Power-up entry
I/O abort entry
Timeout entry
Request processing
Priority scheduler entry

Refer to the description of the DSR priority
schedule
mechanism
in the section on Device I/O Handling for further details.
Other
interface
mechanisms
between
the TSR and ISR can be defined by
the user within the constraints of
the
operating
system.
The
interface to the HSR will be defined in a separate section.
Each
class
contains
several
subroutines.
These subroutines provide
one or more HSR functions.
The other subroutines are
documented
in
the
DNOS Systems Programmer's Guide.
A list
of
the
HSR
subroutine classes are as follows:

*
*
*
*
*
*
*

Power-up initialization.
Write output signal or function.
Read input signal or function.
Enable/disable status change notification.
Transmit a character.
Write operational parameters.
Read operational parameters.

Request

*
*

Controller interrupt decoding.

timer interval notification.

CI403/CI404 UART direct access.

The HSR consists of a set of subroutines.
All
HSR
subroutines
are
called
via branch and link (BL) instructions, and thus, use
the caller's workspace during execution.
Parameters required
by
the
subroutines
are
passed
to the HSR in workspace registers.
Information is returned to the caller in one of two
ways.
Data
is
returned
to
the
caller
in
workspace
registers.
Status

I/O Subsystem

10-30

2270512-9701

DNOS System Design Document

information is returned via alternate
subroutine
returns.
The
caller
specifies
alternate return addresses as operands of DATA
assembler directives
immediately
following
the
BL
subroutine
call.
BL
@HSRSUB
DATA ALT1
DATA ALT2

****

Subroutine Call
First Alternate Return
Second Alternate Return
Normal Return (Code)

The
caller
execution
resumes
at
one
of the alternate return
addresses or
at
the
normal
return
address
(the
instruction
following
all
alternate return DATA statements).
The number of
alternate returns varies for different HSR subroutines.
Some
general
register
conventions
are
followed
by
HSR
subroutines.
In
general,
RO
and
RIO
are
used
as
working
registers by HSR subroutines.
In general,
these
two
registers
are
used
when
parameters
are
passed
to
or
from
the
HSR.
Exceptions will be noted for some HSR subroutines.
R7,
in
most
cases, is used as a pointer to the PDT.

10.5.1
Figure
DSRs.

10.5.2

Data Structures Linkage.
10-10 illustrates data structure linkages for asynchronous

Data Structure Allocation.

The
PDT
extension is divided into two segments.
One segment is
physically contiguous to the PDT, and it contains data
requiring
the
most
efficient access.
The other segment contains data for
which the increased
access
time
is
not
as
great
a
penalty
relative
to
overall
performance.
The
second segment must be
accessed using long-distance instructions.
Other data structures
included in the long-distance extension are VDT screen images for
screen image DSRs.
All
the
data
structures
not
accessed
via
long-distance
instructions
are allocated during system generation.
These data
structures are available when the operating system is loaded into
memory from disk.
The
long-distance
data
structures
must
be
allocated
during
initial
powerup
code by the DSR.
The method
used for this allocation is described in the next section.

10.5.3

PDT Extension Definitions.

The section documents PDT extensions used by the asynchronous DSR
to support specific devices and
controllers.
Software
use
of
these
data
structures
for
a
set of specific hardware is also

2270512-9701

10- 31

I/O Subsystem

DNOS System Design Document

for

discussed.
Controller
information
is
documented
following set of asynchronous controllers:

*
*
*

CI403/CI404
CI401
9902/9903

Extensions
are
also
peripheral devices:

*
*
10.5.3.1

the

Four channel multiplexers
Communications Interface Module
TMS9902 and TMS9903 based controllers:
- S300 Base Station
- CI421
- CI422
- 990/10A 9902 port
- CI402
documented

for

the

following

set

931 and 940 VDTs
Serial Printers
Asynchronous Local PDT Extension.

The asynchronous
DSR
structure
requires
a
PDT
extension
as
defined
in Figure 10-11.
Table 10-4 contains a template used by
source code to reference the local PDT extension.
The' pathname
for
this
template
is
DSALLLEX.
It
is available in the DNOS
directory (vol>.S$OSLINK.TEMPLATE.ATABLE with
the
other
system
data
structure templates.
Notice that the detailed descriptions
indicate a zero based
index
for
the
extension.
However,
in
reality
the
extension
entries
will be accessed using an index
relative to the beginning of the PDT as is indicated by the
DORG
directive of the template in Table 10-4.
This
extension
starts immediately after the KSB.
The first two
words of this extension are used to
access
a
second
DSR
data
structure
(PDT extension) outside the local address space of the
DSR.
The next five words, PDXFLG through
PDXCP3,
are
reserved
for
HSR use.
The
remaining local PDT extension words are for
TSR/ISR use.
Detailed
descriptions
of
asynchronous
PDT
extensions
are
presented
in separate sections.
There are descriptions for each
controller type and each device type.

I/O Subsystem

10-32

2270512-9701

N
-......J

CIl

o
V1

.....
N

931 940
ATTACHED PRINTER
DATA STRUCTURE

931940 PDT
DATA STRUCTURE

SERIAL PRINTER
ON CI403
DATA STRUCTURE

CIl

'14

10.5.3.5

EXTPER

This word is used as a
counter by the HSR.

receive

'parity

error

CI403/CI404 HSR Local Extension.

Hex.
Byte

Field
Name

>00

PDXSMB

This word contains the inverted value of
the
byte
count
requested
for the long distance
buffer.
The DSR initializes this word during
the power-u~ sequence.

)02

PDXSMP

address
This word contains the beet bias
of
the long distance buffer requested by the DSR
the
sequence.
DSR
The
during
power-up
the
system
requests the buffer
by
calling
routine IOGUB.

>04

PDXFLG

contains
the
This
byte
bit
flags
for
HSR.
CI403/CI404
The
flags are defined as
follows:

Bit 0

Transmit in hold.
This flag is
set
to
one
whenever
one
or
both
of
the
following
conditions exists:
the common transmit
FIFO
is
near
full,
or
the
channel-specific
transmit FIFO is full.
This flag
bit
0
is
reset
whenever
all
holding conditions have
been satisfied.
See
the
explanation
below
for bits 2 and 3.

Bi t

Reserved.

Bi t

Controller
transmit
hold.
Whenever
the
common
transmit
FIFO
is
near
full,
the
controller issues the
halt
transfer
status
(status
4, substatus 1) to the HSR; this bit
is set to one, and bit 0 is set to one.
'Bit
2
is
reset when the Common transmit FIFO is
empty and the controller
issues
the
resume
transfer
status
(status
4, substatus 2) to
the HSR.

Bit 3

FIFO exhausted transmit hold.
the
Whenever
HSR
FIFO
count
goes
to zero, the HSR sets
this bit to one,
sets
bit
one,
and
to
0
enables
transmit
FIFO empty interrupt.
The
HSR resets
the
controller
bit
whenever
3
the
HSR
that the channel specific
notifies
FIFO is empty.

2270512-9701

Description

10-41

I/O Subsystem

DNOS System Design Document

Bit 4

Data
Character
Detect
(DCD)
notification
flag.
This
bit
is
set
to
one
when the
TSR/ISR calls the HSR
subroutine
HESDCD
to
enable
notification
of
DCD status changes.
This bit is
set
to
zero
when
the
HDSnCD
subroutine
is called to disable notification
of DCD status changes.

Bit 5

Ring Indicator (RI) change notification flag.
This bit is set to one when the TSR/ISR calls
the
HSR
subroutine
HESRI
to
enable
notification
of RI status changes.
This bit
is set to zero when the HDSRI
subroutine
is
called
to
disable notification of RI status
changes.

Bit 6

Data
Set
Ready
(DSR)
change
notification
flag.
This
bit
is
set
to
one
when the
TSR/ISR calls the HSR
subroutine
HESDSR
to
enable
notification
of
DSR status changes.
This bit is
set
to
zero
when
the
HDSDSR
subroutine
is called to disable notification
of DSR status changes.

Bit

Clear To Send (CTS) change notification flag.
This bit is set to one when the TSR/ISR calls
the
HSR
subroutine
HESCTS
to
enable
notification of CTS status changes.
This bit
is
set to zero when the HDSCTS subroutine is
called to disable notification of CTS
status
changes.

)05

PDXCHN

This byte contains the channel number of
the
CI403/CI404.
It
is specified during system
generation
and
initialized
by
the
system
generation program.

)06

PDXFCT

This word contains
the
byte
count
of
the
available
CI403/CI404
channel-specific
transmit FIFO as maintained by the HSR.
This
word
is
not
necessarily
an
accurate
representation
of
the
actual
state of the
controller FIFOs.

)08

PDXCP1

This
word
contains
bit
flags
for
the
HSR.
The
CI403/CI404
flags are defined as
follows:

Bit 0

I/O Subsystem

Reset mode.
This flag is set to one when
TSR/ISR calls the
HSR
subroutine
HSTCR
reset
a
particular channel.
While this
is set to one, all controller interrupts
ignored.
This bit is reset to zero when

10-42

the
to
bit
are
the

2270512-9701

DNOS System Design Document

TSR/ISR calls the
HSR
subroutine
allow controller interrupts.
Bit 1

HRTCR

Secondary Data Character Detect (SDCD) change
notification
flag.
This
bit is set to one
when the TSR/ISR
calls
the
HSR
subroutine
HESSDC
to enable notification of SDCD status
changes.
This bit is set to
zero
when
the
HDSSDC
subroutine
is
called
to
disable
notification of SDCD status changes.

Bit 2-r Reserved.
)OA

PDXCP2

Reserved.

)OC

PDXCP3

Reserved.

)OE-)24

PDXCP4

Reserved for TSR/ISR usage.

10.5.3.6

CI403/CI404 HSR Long-Distance Extension.

Hex.
Byte

Field
Name

)00

EXTTMR

HSR
timer
duration
value.
This
word
is
decremented once every 250 milliseconds until
it
reaches zero.
The TSR/ISR is notified of
timer
expiration
when
this
value
is
decremented
to zero.
The timer count is set
by calling the HSR subroutine HTIMER.

)02

EXTRG3

This word contains a copy of the ACE register
3 contents for the specified channel.

)04

EXTRG4

This word contains a copy of the ACE register
4 contents for the specified channel.

)06

EXTRG7

This word contains a copy of the ACE register
7 contents for the specified channel.

)08

EXTSPD

This byte contains a copy of the
speed
code
that
is currently programmed in the ACE.
If
the TSR/ISR specified an illegal
speed
then
this
byte
contains an )FF.
The second byte
of the word is reserved.

)OA

EXTRO

This word contains a copy
of
the
TSR's
RO
whenever the HSR is delaying after a write to
an ACE register.

)OC

EXTR7

This word contains a copy
of
the
TSR's
whenever the HSR is delaying after a write
an ACE register.

2270512-9701

Description

10-43

R7
to

I/O Subsystem

DNOS System Design Document

)OE

10.5.3.7

EXTRII

This word contains a copy of
the
TSR's
Rl1
whenever the HSR is delaying after a write to
an ACE register.

9902/9903 HSR Local Extension.

Hex.
Byte

Field
Name

)00

PDXSNB

This word contains the inverted value of
the
byte
count
requested
for the long distance
buffer.
The DSR initializes this word during
the power-up sequence.

)02

PDXSMP

address
This word contains the beet bias
of
the long distance buffer requested by the DSR
the
sequence.
The
DSR
during
power-up
requests the buffer
the
system
by
calling
routine IOGUB.

)04

PDXFLG

byte
contains
bit
This
flags
are
HSR.
The
flags
9902/9903
follows:

Description

the
for
defined as

Bit 0

Data Carrier Detect (DCD) State.
~his
flag
is
set
to one when the current state of the
DCD signal is on (logic 1),
and
is
set
to
zero when the current state of the DCD signal
is off (logic 0).

Bit 1

Ring Indicator (RI)
to
one
when
the
signal is on (logic
when
the cur- rent
off (logic 0).

Bi t

Da t a Set Re ad y (D S R) S tat e
to one when the
current
signal
is
on
(logic 1),
when the current state of
off (logic 0).

Clear To Send (CTS) State.
This flag is
set
to
one
when
the
current
state of the CTS
signal is on (logic 1), and is
set
to
zero
when
the
current state of the CTS signal is
off (logic 0).

Bit 4

Data
Character
Detect
(DCD)
Notify
Flag.
This flag indicates if notification of status
change
has been requested.
This flag is set
to one when
the ~ESDCD
HSR
subroutine
is
called
to
enable
notification
of
status

I/O Subsystem

10-44

State.
This flag is
set
current
state
of the RI
1), and is
set
to
zero
state of the RI signal is•
Th is f lag i s s e t
state
of
the
DSR
and is set to zero
the DSR
signal
is

2270512-9701

DNOS System Design Document

chan~e.
This flag is set to
zero
when
the
HnSDCD
subroutine
is
called
to
disable
notification of status change.

)05

Bit 5

Ring Indicator(RI) Notify
Flag.
This
flag
indicates
if
notification
of status change
has be~n requested.
This flag is set to
one
when
the
HESRI
HSR subroutine is called to
enable notification of status
change.
This
flag is set to zero when the HDSRI subroutine
is
called
to disable notification of status
change.

Bit 6

Data Set Ready (DSR) Notify Flag.
This
flag
indicates
if. notification
of status change
has been requested.
This flag is set to
one
when
the
HESDSR HSR subroutine is called to
enable notification of status
change.
This
flag
is
set
to
zero
when
the
HDSDSR
subroutine is called to disable
notification
of status change.

Bit 7

Clear To Send (CTS) Notify Flag.
This
flag
indicates
if
notification
of status change
has been requested.
This flag is set to
one
when
the
HESCTS HSR subroutine is called to
enable notification of status
change.
This
flag
is
set
to
zero
when
the
HDSCTS
subroutine is called to disable
notification
of status change.

PDXCHN

This

byte

9902/9903

contains
bit
flags
flags
are
HSR.
The

for
the
defined as

follows:
Bit 0

Reserved.

Bit 1

Secondary Data Carrier Detect
(SDCD)
State.
This
flag
is
set
to
one when the current
state of the SDCD signal is on (logic 1)~ and
is set to zero when the current state of
the
SDCD signal is off (logic 0).

Bit 2

Transmit Shift Register Empty
(TSRE)
State.
This
flag
is
set
to
one when the current
state of the TSRE signal is on (logic 1), and
is set to zero when the current state of
the
TSRE signal is off (logic 0).

Bit 3

Reserved.

Bit 4

Reserved.

2270512-9701

10-45

I/O Subsystem

DNOS System Design Document

Bit 5

Secondary Data Character Detect Notify
Flag.
This flag indicates if notification of status
c han g e
has bee n r e que s ted.
Thi s f I a g i s s e t
to one when
the
HESSDC
HSR
subroutine
is
called
to
enable
notification
of
status
change.
This flag is set to
zero
when
the
HDSSDC
subroutine
is
called
to
disable
notification of status change.

Bi t

Transmit Shift Register Empty
(TSRE)
Notify
Flag.
This flag indicates if notification of
status
change has been requested.
This flag
is set to one when the HESTSR HSR
subroutine
is called.
This flag is set to zero when the
HDSTSR subroutine is called.

Bi t

Reserved.

)06

PDXFCT

This word contains the entry byte count for a
software transmit FIFO maintained by the HSR.

)08

PDXCP1

This word contains the insertion pointer
for
the
software FIFO maintained by the HSR.
It
contains
the
address
of
the
next
FIFO
location
in
which
to
store
a
transmit
character.

)OA

PDXCP2

This word contains the
removal
pointer
for
the
software transmit FIFO maintained by the
HSR.
It contains the
address
of
the
next
transmit FIFO entry to be removed.

)OC

PDXCP3

This word is used by the HSR
as
a
transmit
state
vector.
It contains an address of an
HSR transmit routine.
The HSR
changes
this
address as the HSR transmit state changes.

)OE-)27

PDXCP4

Reserved for

10.5.3.8

TSR/ISR usage.

9902/9903 HSR Long-Distance Extension.

Hex.
Byte

Field
Name

)00

EXTTMR

HSR timer word.
This
word
is
decremented
once
every 250 milliseconds until it reaches
zero.'
The
ISR
is
notified
of
timer
expiration
when this value is decremented to
zero.
The timer count is set by calling
the
HSR routine HTIMER.

)02

EXTCDY

HSR timer word.
approximately

I/O Subsystem

Description

10-46

This
word
once
every

is
decremented
16
milliseconds

2270512-9701

DNOS System Design Document

until it reaches zero.
The
EXTTMR
word
is
then
decremented,
and this word is restored
from EXTCST.

)04

EXTCST

HSR timer
word.
This
word
is
loaded
at
initial
DSR
power-up
entry
to
be used to
determine how many 9902/9903 timer interrupts
are required to time 250 milliseconds.

)06

EXTFLG

This word is used as a bit flag word
by
the
HSR.
The flag definitions are as follows:

Bit 0

Channel transmit halt flag.
When
this
flag
is
set
to one the HSR accepts transmit data
from the
TSR/ISR
until
the
software
FIFO
fills,
but
does
not
transmit
data on the
communication line.
This flag is set to
one
by
a
call to the HSTCTH HSR subroutine.
It
is set to zero by a call to
the
HRTCTH
HSR
subroutine.

the
HSR.
the
This flag indicates
mode
of
thi s
When
flag is set to one the channel is
in a channel reset mode.
A call to the HSTCR
HSR subroutine sets this flag to
one.
Once
the
channel
reset
a call to the
in
mode,
HSR
HRTCR
reset
(Reset
channel
mode)
set the flag to
subroutine
is
required
to
zero and restore the HSR to normal operation.
When in the channel reset mode, no
9902/9903
interrupts are enabled.

Bit 2

UART Internal Loopback
Enabled
Flag.
This
flag is set to one when the TSR requests that
the 9902/9903 chip be placed in UART loop back
mode.
This
bit
is set to one by a call to
the HSTUIL HSR subroutine.
It is set to zero
by a call to the HRTUIL HSR subroutine.

Bit 3

Transmit Break Enabled Flag.
This
flag
is
set
to
one
when
the TSR requests that the
9902/9903 chip transmit
a
break
condition.
This bit is set to one by a call to the HSTTB
HSR
subroutine.
It is set to zero by a call
to the HRTTB HSR subroutine.

Bit

Bit 4-F Reserved.

)08

EXTTMP

This word is
by the HSR.

used as a

temporary storage word

)OA

EXTTHI

This word is used as a
by the HSR.

temporary storage word

2270512-9701

10-47

I/O Subsystem

DNOS System Design Document

)OC

EXTSPD

This word contains the speed selection
code.
It
contains
the value passed as a parameter
to the HSPSPD subroutine.
The
contents
of
this
word are returned by the HSR subroutine
HRPSPD.

)OE

EXTPSL

This
word
contains
the
data
format
parameters.
It
contains
the
value of the
parameters
passed
to
the
HSR
subroutine
HSPPSL.
The
contents
of
this
word
are
returned to the caller of the HSR
subroutine
HRPPSL.

)10

EXTLDC

This
word
contains
the
CRD
instruction
required
to
load
the
9902/9903
DART with
transmit data for the communications line.

)12

EXTTYP

This word is set up at initial DSR entry
on
power-up,
to
define
the hardware interface
type as follows:
Value

o
2
4
6
8
)A

)14 to )BF
10.5.3.9

Port
990/10A 9902
CI402 9902
CI4219902
CI422 9902
S300 Base Station 9902
CI421 9903

These
words
development.

are

reserved

for

Device Type
)0007
)0008
)0009
)OOOA
)0006
)0030
future

HSR

931/940 TSR/ISR Local Extension.

Hex.
Byte

Field
Name

)00

PDXSMB

This word contains the inverted value of
the
byte
count
requested
for the long distance
buffer.
The DSR initializes this word during
the power-up sequence.

)02

PDXSMP

This word contains the beet bias
address
of
the long distance buffer requested by the DSR
during
the
power-up
sequence.
The
DSR
requests the buffer
by
calling
the
system
routine IOGUB.

)04-)OD
)OE

Description

HSR Information.
PDXCP4

I/O Subsystem

System generation
puts
in
this
word
the
location of RO of the attached printer if one
is
present.
At power-up time, this is moved
10-48

2270512-9701

DNOS System Design Document

to the remote extension, and the word is used
user
as the TSR's copy of the
IRB
extended
flags.

>10

PDXCP5

System -generation puts in this word the speed
of
the
communication
line
and
a
flag
indicating if the line is a dial-in line.
At
power-up time, this is moved
to
the
remote
extension,
and
the
word
is
used
as
the
current cursor position by the TSR.

>12

PDXCP6

This word is

a TSR flag word.

Bit 0

Terminal Type.
the
terminal
is a 940.

Bi t

Re adS c he d u Ie.
Th i s f I a g i s s e t to _0 n e
wh en
the
TSR
requests
to
be
resecheduled upon
receipt of a read character.

Printer Has Channel.
when the printer has

This flag is set
to
one
if
is a 931 and set to zero if it

This flag is set to one
control of the channel.

Bit 3

Printer Wants Channel.
This flag is
set
to
one
when the printer requests control of the
channel, and the CRT currently has control of
the channel.

Bit 4

CRT Has Channel.
This flag
when the CRT has control of

is
set
to
the channel.

one

Bi t

CRT Wants Channel.
This flag is set
to
one
when the CRT requests control of the channel,
and
a
printer
currently has control of the
channel.

Bi t

Cursor Is On.
This flag
the cursor is on.

Bi t

Cursor Not Eeen Moved.
This
flag
indicates
that
the
cursor
is
not
physically at the
location that the internal pointer says it is
located.
This
is
to
avoid
sending
unnecessary commands.

Bit 8

Graphics Flag.
This flag indicates that
the
command
has
been made to the terminal to be
in graphics mode.

Bit 9

Graphics Input
Flag.
This
flag
indicates
that
the t~rminal has notified the host that
input from the terminal will be
in
graphics

2270512-9701

10-49

set

one

when

I/O Subsystem

DNOS System Design Document

mode.
Bit 10

Reserved.

Bit 11

Clear Flag.
This
flag
indicates
that
the
screen
has
been cleared and nothing has yet
been sent to it.
This is
to
avoid
sending
unnecessary commands.

Bit 12

Cursor is Blinking.
This flag
when the cursor is blinking.

Bit 13

Initialized Flag.
This flag
indicates
the terminal has been initialized.

Bi t

indicates
that
the
Extent Flag.
This flag
command
has
been
made
to
the terminal to
define the
end
of
the
current
field
for
insert and delete.

Bit 15

is set

Insert Flag.
This flag
TSR is in insert mode.

indicates

This word
is
used
address by the TSR.

one

that

tha t

the

)14

PDXCP7

)16-)IA

PDXCP7-A These words are temporary save
the TSR.

)IC

PDXCPB

This word contains
to the terminal.

)IE

PDXCPC

This
word
contains
optimization routine.

)20

PDXCPD

This word contains an internal TSR counter.

)22

PDXCPE

This word is an opcode 15 flag.

internal

buffer

locations

for

the current attribute sent

the

counter

for

the

Bit 0

Pass Through.
This flag is set to
one
when
the
data
is to be sent and received with no
conversion.
The
only
characters
that
are
acted upon are DCI and DC3 (ready/busy).

ETX Flag.
Terminate a Pass Through
receipt of an "ETX" character.

Read

ESC Flag.
Terminate a Pass Through
Read
receipt of an "ESC )" character string.

Extended Event Flag.
This
flag
allows
extra 940 characters to be entered.

I/O Subsystem

10-50

the

2270512-9701

DNOS System Design Document

Bit 4

Reserved.

Bit 5

Special Attribute Flag.
This flag is set
to
one
when
the the TSR will allow "SI" , "SO",
or "ESC 4" to be sent to the terminal from
a
user buffer.

Bit 6

Disable Attributes.
This flag means that
no
attributes
are to be sent to the terminal by
the TSR.

Bit

Reserved.

Bit 8

Modified Flag.
This flag indicates
that
any
data
has
been modified in a field,
task should be notified.

Bit 9

Extended
Character
Validation.
This
flag
indicates that the character validation is to
be handled before the character is echoed.

Bit

Null Truncation flag.

Bits 11-15
)24

PDXCPF

Reserved.
This word contains the current state of
as follows:

Hex.
Byte

input

Meaning
Ignore input and do not produce output.

Accept input and produce output.

Value

10.5.3.10

if
the

931/940 TSR/ISR Long-Distance Extension.
Field
Name

Description
HSR Words.

)00-)8F

contains

the

current

fill

character

that

)90

VDTFIL

This
byte
character.

)91

VDTEVT

This byte contains the event
terminated the read.

)92

VDTDEF

This
word
contains
the
sequential
cursor
position
of
the
beginning
of
the current
field.

)94

VDTPSR

This word is a
temporary
location
printer portion of the TSR.

2270512-9701

10-51

for

the

I/O Subsystem

DNOS System Design Document

)96

VDTPTP

This byte contains
as follows:
Value

Meaning
150 cps

75 cp s

40 cps

20 cps

300 cps

the current

)97

Rese rved.

)98

Run-time location for

)9A

Mask
to
determin~
connected.
Value

)9C

)AOOO

Meaning
DCD and DSR

)2000

DSR only

printer

type

speed in PDXCPS.
if

the

terminal

Remote Flags:
Bi t

Reserved.

Bi t

Blinking.
This flag is set
if
blinking
allowed for the terminal (940 only).

Bit 2

Wait for Positive Feedback.
This flag is set
when
a
printer buffer has been sent and the
TSR is waiting for
terminal
acknowledgement
(931 only).

Bit 3

Schedule on Positive Feedback.
This flag
is
set
when
a printer buffer has been sent and
the
TSR
wants
to
be
scheduled
when
the
terminal acknowledges the buffer (931 only).

Terminal has started power-up,
completed yet.

An immediate open has occurred
on
the
CRT,
the next close will be an immediate close.

Bit 6

An
immediate
open
has
occurred
on
the
printer,
the next close will be an immediate
close.

I/O Subsystem

10-52

but

has

not

2270512-9701

DNOS System Design Document

Bit 7-D Reserved.
Bit E

ESC Found.
This flag indicates that
an
was just found in a string in the TSR.

Bit F

Rese rved.

ESC

)9E

VDTERR

This word is used to pass an error code
the ISR to the TSR.

)AO

VDTOVR

a
This word is
counter
overrun e-r ror s detected.

the

number

)A2

VDTPAR

a
counter
This word is
parity errors detected.

the

number

)A4

VDTFRM

This word is
a
counter
framing errors detected.

the

number

)A6

VDTPTR

Run-time
PDXCP4.

address

)A8

PRTTIM

Timer for printer delay (940 only).

)AA

VDTEDL

This word is an opcode 15 Edit Flag.

Bi t

location

for

printer

Erase Field is an Event.

Bit 1

Right Field is an Event.

Bit 2

Cursor Left out of a Fi,eld is an Event.

Bi t

Tab is an Event.

Bit 4

Reserved.

Bit 5

Skip is an Event.

Bit 6

Home is an Event.

Bit 7

Return is an Event.

Bi t

Erase Input

is an Event.

Bit 9

Reserved.

Bit A

Delete Character is an Event.

Bit B

Insert

Bit C

Cursor Right out of a Field is an Event.

Bi t

Enter is an Event.

2270512-9701

from

Character is an Event.

10-53

I/O Subsystem

DNOS System Design DDcument

)AE

Bi t

Left Field is an Event.

Bi t

Rese rve d.

STATBD

This word contains the state of
follows:
Value
0

)BO

STATGR

STATFN

Board connected.

Board waiting on time ou t.

Board waiting on ring.

Board is in DSR diagnostic mode.

This word contains the
graphics.

Meaning
Input is not graphics.

Input

Value

10.5.3.11

state

Thi sword
mapping.

Meaning
Board disconnected.

Value

)B2

the board

the

input

is graphics.

contains

the

state

Meaning
Regular keys.

ESC was received.

Aid was received.

Pass Through Mode.

DSR Diagnostic Mode.

Read

the

key

Status Mode.

Serial Printer HSR Local

Extension.

Hex.
Byte

Field
Name

)00

PDXSMB

This word contains the inverted value of
the
byte
count
requested
for the long distance
buffer.
The DSR initializes this word during
the power-up sequence.

)02

PDXSMP

This word

I/O Subsystem

Description

contains

10-54

the beet

bias

address

2270512-9701

DNOS System Design Document

the long distance buffer requested by the DSR
during
the
power-up
sequence.
The
DSR
requests the buffer
by
calling
~he
system
routine IOGUB.

)04 )10

)OF

Reserved for
PDXCP4

HSR use.

This byte contains bit flags
printer
HSR.
The
flags
follows:

for
are

the
serial
defined
as

Bit 0

Reserved.

Bit

This bi t , when set to one, indicates
tha t
write SCB is being processed by the TSR.

Bit 2

Rese rve d.

Bit 3

This bit, when set
non-write
command
TSR.

Bit 4

This bit, when set
to
one,
indicates
that
data
transmission
to
the
device
has been
stopped because
the
data
set
ready
(DSR)
signal is not present.

Bi t

This bit, when set
to
one,
indicates
that
data
transmission
to
the
device
has been
stopped due to reception of a
DC3
character
from the device.

Bit

This bit, when set to one, indicates
that
a
KATAKANA
mode
select
character
is
being
transmitted.

Bit

This bit, when set to one, indicates that the
device supports extended
print
(lower
case
letters).

to one, indicates
tha t'
a
is being processed by the

Bit 8

Reserved.

Bit 9

This bit, when set to one, indicates that the
ISR
section
has
detected
a condition that
requires scheduling of the TSR section.

Bit

Reserved.

Bit

Reserved.

This bit, when set to one, indicates that the
TSR is
not
able
to
operate
due
to
Some
condition
(hardware
interface
not present,

2270512-9701

10-55

I/O Subsystem

DNOS System Design Document

not
supported
by
the
requested baud
rate
hardware
interface, power up failure, and so
on) •
Bit 13

This bit, when set
to
one,
indicates
initial power-up has occurred.

Bit 14

Reserved.

Bit 15

Reserved.

that

)12

PDXCP5

This word contains the transmit
and
receive
baud
rate word.
This word is initialized by
sysgen or the MVPC command.

)14

PDXCP6

the
operation
This word contains
word for the hardware interface.

)16

PDXCP7

This word contains the total error count seen
by
the
TSR ( the count of all parity errors,
overrun errors, framing errors, and so on).

10.5.3.12
Hex.
Byte
)00 -

pa rame te r

Serial Printer HSR Long-Distance Extension.
Field
Name

)8F

Description
These words are reserved for use by the HSRs.

)90

RTEXTO

This word is a count of the number of receive
break conditions sensed.

)92

RTEXT 1

This word is a count of the number of framing
errors received.

)94

RTEXT2

This word is a count of the number of
errors received.

)96

RTEXT3

This
word
is
a
count
of
the
receiver overrun errors received.

)98

RTEXT4

This word is a count of the number
errors received.

)9A

RTEXT5

This word is a count of the number of
UART interrupts received.

illegal

These words are reserved for
use.

ISR/TSR

)9C -

)BF

I/O Subsystem

10-56

parity

number

future

other

2270512-9701

DNOS System Design Document

10.6

I/O UTILITY (IOU)

The
initial
processing
of a utility request is similar to that
for device I/O.
The SVC
is
decoded
by
RPROOT,
which
passes
control
to
IOPREP, the I/O preprocessor.
IOPREP passes control
to the I/O Utility preprocessor, IUPREP, when
it
recognizes
an
IOU SVC.
The IOU preprocessor buffers the call block and any extensions to
the
call
block
as required by the individual subopcodes.
Call
block
extensions
include
pathname,
key
definitions,
and
parameters.
The
preprocessor checks for illegal subopcodes and
mapping errors during the buffering process.
BRBs for SVCs
that
do not require an access name (or whose access name begins with a
period)
are placed directly on the input queue for the IOU task.
Other BRBs are
first
queued
for
the
Name
Manager
task
for
resolution
of any logical names.
After logical name resolution,
Name Manager places the BRB on the input queue for the IOU task.
The IOU task has a main
driver
that
calls
other
routines
to
process
the individual IOU subopcodes.
The IOU task consists of
a root segment and three or four system overlays
depending
upon
the sysgen options chosen.
Assign LUNa, Release LUNa, and Delete
File
SVCs
are
handled by code in the IOU root segment.
Create
File SVCs are handled by code residing in one overlay; Add Alias,
Delete Alias, and Rename ~file
in
a
second
overlay;
and
the
remaining
IOU
SVCs are handled by code in the third overlay.
A
fourth overlay to handle security is
included
if
the
security
option was chosen during sysgen.
File security will be discussed
in a separate section.
The main driver, a stack, and subroutines
required by all overlays are included in the IOU root segment.
When
IOU
is
activated, it dequeues an entry from its queue and
processes the entry.
If the IOU SVC processor that
handles
the
SVC
resides
in
an
overlay,
the overlay is loaded into memory
(unless it already resides in
memory).
The
SVC
processor
is
called
to
perform
the
required operations; when it complet~s,
control is returned to the IOU main driver.
The
processing
of
the
SVC
may
require that the BRB be queued for processing by a
channel owner task.
If so, the request
is
passed
to
the
IPC
preprocessor for routing to the channel owner.
The IOU main driver takes the appropriate exit path after the SVC
processor
has
handled
the SVC.
If the request was queued to a
channel owner, the BRB will be unbuffered
later,
after
it
has
been
processed
by
the channel owner and placed back on the IOU
input queue by IPC.
If the SVC required the creation
of
a
job
temporary
file,
the
BRB
is placed on the input queue for Name
Manager for final processing
and
unbuffering.
If
neither
of
these
special
conditions
exists,
the
BRB
is
queued
for

2270512-9701

10-57

I/O Subsystem

DNOS System Design Document

unbuffering to the calling task.
IOU
then
requests
the
next
entry from its queue.
If the input queue is empty, IOU suspends,
awaiting queue input.
The
range
of
IOU
operations
includes
those that process SVC
requests to create and delete files, assign
and
release
LUNOs,
rename files, protect and unprotect files, add and delete aliases
for
filenames,
and
create
and
delete
channels.
IOU
also
processes requests for special operating system services such
as
releasing LUNOs in another job.

10.6.1

Configurability.

IOU
is
configurable
during
sysgen when the user specifies the
features desired.
The modules to process these features are then
selected for inclusion in the IOU task.
The
following
feature
levels can be selected:

*
*
10.6.2

Dynamic KIF creation and deletion
File access security

Memory Layout.

IOU
runs as a system task in map file 1.
are used as follows:

Its three map segments

The first

The
second
segment
changes
during
processing
contains
either
the user JCA, the system job JCA,
file management table area (FMT).

The third segment contains the IOU code.

10.6.3

segment contains the system root.
and
or a

Structures Maintained by IOU.

The file
management
table
areas
(FMTs)
are
memory
resident
segments, the number and size of which are defined during sysgen.
The
FMT
is used primarily for in memory representation of files
currently in use.
One may monitor the usage of the FMT by
using
the
Execute Performance Display (XPD) command.
If the system is
approaching maximum utilization, the error
message
INSUFFICIENT
FILE
MANAGEMENT
TABLE
AREA
AVAILABLE
will be issued.
In any
case, if it is determined that more table
area
is
needed,
the
Modify
System
Table (MST) command may be issued to increase the
FMT size up to 256K bytes.

I/O Subsystem

10-58

2270512-9701

DNOS System Design Document

The following structures are built by or used by
IOU,
and
they
are
found
in
several
different
areas,
as
noted
in
the
descriptions.
Detailed descriptions of the structures are
shown
in the section on data structure pictures.

Directory
overhead
record
(DOR) - Disk structure that
shows the number of files in a directory, the number
of
available
entries,
the
number of temporary files, and
several other pieces of miscellaneous directory data.

File descriptor record (FDR)
Disk
directory
record
that
describes
the name, location, and characteristics
of a disk file and the ID of the user
who
created
the
file.

Alias
descriptor
record
(ADR)
Disk structure that
contains an alternate pathname component for
some
file
pathname and points to the FDR for which this name is an
alias.

Key
descriptor
record
(KDR)
Disk
structure
that
describes the keys of a key indexed file; a
KDR
for
a
multifile
KIF
set contains additional fields to detect
illegal attempts to combine files.

Channel descriptor record (CDR) - Disk directory
record
that
describes
the
name and characteristics of an IPC
channel.
The CDR is located in the directory containing
the FDR of the program file that
contains
the
channel
owner
task,
and
it contains the record number of that
FDR.

File structure common (FSC)
and FCB variants.

File directory block (FDB) - A single node
of
the
inmemory
directory
tree
structure
located
in the file
management table areas.
Provides tree linkage
and
the
information
required
to
perform
direct disk I/O to a
directory.
An
FDB
is
created
for
each
pathname
component
on an assign or attach operation.
The FDB is
a variant of the FSC structure.

File control block (FCB) - In-memory equivalent
of
the
FDR, located in the file management table area.
The FCB
is built for only the last component of a file pathname.
The
FCB
points to its corresponding FDB.
The FCB is a
variant of the FSC structure.

Resource ownership block (ROB) - The
ROB
represents
a
job's
ownership
of
a
file
resulting
from an Attach
Resource operation.
The ROB points to an FCB.
ROBs are
always built in the
JCA
and
are
chained
in
a
list

2270512-9701

10-59

Template to define the FDB

I/O Subsystem

DNOS System Design Document

anchored by JITROB.

Channel
control block (CCB) - In-memory equivalent of a
CDR, built on an Assign LUNO to an
IPC
channel.
CCBs
contain a pointer to the File Descriptor Packet (FDP) of
the
program
file containing the channel owner task and
the eight-character name of the last
component
of
the
channel pathname.
CCBs for global channels are built in
the
STA,
and
are anchored from CCBSTR in NFPTR.
CCBs
for job-local and task-local channels are chained
in
a
single
list
anchored
from JITCCB in the JCA.
The CCB
points to the JSB and TSB of the owner task.

Logical
device
table
(LDT)
The
LDT
includes
a
description
of
an I/O resource, usage flags, ownership
information, and file rights.
Job-local and
task-local
LDTs
are
built in the JCA and are anchored from JITLDT
and TSBLDT, respectively.
Global LDTs are built in
the
STA and
are
anchored
from
LDTLST
in NFPTR.
LDTRLK
points to a CCB, FCB, or
PDT,
depending
on
the
LUNO
assignment.

Resource
privilege block (RPB) - The RPB is a structure
used to control access privileges
for
resources.
The
RPB
is
built on each Assign LUNO to a device, file, or
IPC channel.
The RPB contains the open access privilege
flags (2 bits), the address of its associated
LDT,
and
the
JSB address of the job that assigned the LUNO (the
JSB field is zero for
global
LUNOS).
An
RPB
for
a
device
is
chained
to the PDT, an RPB for a channel is
linked to the CCB, and an RPB for file is chained to the
FCB.
The RPB contains currency
information
for
LUNOs
assigned to files.

10.6.3.1

Directory Tree Construction.

In
DNOS,
an
FDB is built in the file management table area for
each component of a file pathname, and an FCB is built there
for
the last component of the pathname.
Each
disk
PDT
extension for a file contains the address of the
VCATALOG FDB and the SSB address of
the
file
management
table
area
in which it resides.
The VCATALOG entry is placed there by
IPL for all devices which are
on
line
during
IPL.
They
are
placed
there
by
Install
Volume (IV) otherwise.
IOU maps this
area into its second segment to
begin
the
tree
search.
Each
pointer
to
a
node
of the tree contains the SSB address of the
file management table area where that node resides.
Since
each
FDB
could potentially reside in a different table area, IOU must
be sure
that
it
has
the
correct
segment
mapped
in
before
following an FDB pointer.

I/O Subsystem

10-60

2270512-9701

DNOS System Design Document

When a new node is to be added to the tree, an attempt is made to
allocate
it
in
the same table area as its parent.
If no space
remains, other file management table areas are
checked,
if
any
exist.
FMSTR in NFPTR contains the SSB address of the first file
management
table area, and FMEND contains the SSB address of the
last.
The SSBs for the table areas are
chained
together.
IOU
maps
in
each successive table area and attempts to obtain space
for the FDB.
The requester is given an error if no
table
space
is
available.
When linking a new FDB into the tree, IOU must be
sure it has the correct table mapped in when changing parent
and
sibling FDB linkages.
For files
the STA.

to which global LUNas are assigned,

10.6.3.2

LDT Structure.

the LDT is built in

The
LDT
is
composed
of
two parts built by IOU when a LUNa is
assigned to an I/O resource.
These parts are the LDT and an RPB.
The LDT is linked into the LDT chain.
The
RPB
for
a
file
is
allocated
in
the
same
segment as the FDB of the corresponding
node.
It is impractical to chain together all LDTs assigned to a
file because the LDTs may be distributed to
various
JCAs.
The
RPB chain is the chain that can be traversed to find all users of
a
given
resource.
Figure 10-13 shows typical LDT chains for a
task that is associated with a station and a
task
that
is
not
associated with a station.
When a LUNa is opened, IOPREP searches the RPB chain to check for
access
privilege
conflicts.
Each RPB contains a two-bit field
representing its access privileges and a flag indicating an
open
LUNa.
A privilege
conflict could occur with other open LUNas.
If no conflicts arise, the access privileges are recorded in
the
RPB and it is marked open.
The RPB contains currency information (including the current file
index
set
up
by
file
management
for
concatenated
files).
Currency for any LUNas assigned to a file may be updated by
File
Management
as
necessary
by
updating
the currency in the RPB.
(Note that this is not the same as the KIF currency informati~n.)
Parameters may be included in
the
parameter
field
of
an
IOU
operation.
The
following parameters may be included, organized
in the sublists shown.
See the format of parameters described in
the Name Management paragraph in the section on Special SVCs.

2270512-9701

10-61

I/O Subsystem

DNOS System Design Document

Sublist
Type

Parameter
Number

03
04
05
06

07
08
09
OD
OE
OF
10
11

12
14
15
16

02
04
05

Pa rame ter
Description

Job access level
File type
Job local temporary file
Initial file allocation
Secondary allocation
Logical record length
Physical record length
Expandable
Forced write
Blank suppressed
Max /I of tasks
Max /I of procedures
Max /I of overlays
Max /I of directory entries
Default physical record size
KIF definition block
User ID parameter (see UIP template)
Modify file name security option
Continue LAN session on release Luno

Each of the parameters is optional and mayor may not
have
been
specified
by
the
user.
If a system parameter is chosen (those
with a sublist # of 0), the parameter overrides what is given
in
the
call
block.
System
parameters
are
used
to communicate
information between NAMMGR and IOU.
They are
not
intended
for
general
use.
Parameters 2, 4 and 5 are described in more detail
in the SVC manual.

I/O Subsystem

10-62

2270512-9701

DNOS System Design Document

System Table Area

*-----------------------------------------------*
I
LDT
LDT
LDT
I
I +-------+
------) I • -------)
I
I
I ------- I
I
I
Iglobal I
ILUNO nIl
I
I
I
I +-------+

+-------+
+-------+
I • -------). • • --) I 00
I
I ------- I
I ------- I
Iglobal I
Iglobal I
ILUNO n21
ILUNO nnl
+-------+
+-------+

I
I
I
I
I
I

II *-----------------------------------------------*
Job Communications Area
*-----------1---------------------------------------------------*
LDT
+------+
1---) I

I
I
I
I
I
I

LDT
+-------+

• -----------) I

1------1
I job I
PDT
Ilocal--)+----+
ILUNO 01 IDUMYI
+------+ +----+

• -----.

.-----)1

I
I
+- - - - - +

task

·------)1

TSB
+-----+
I
I

I
I

.----)--1

1-------1
I job
I

I local I
ILUNO nnl
+-------+

1---<----I

LDT
I
+-------+ I

.---- • • • )1

.----)-1

I ------ I
I ------- I
I t ask
I
I t ask
I
Ilocal--Ilocal
I
ILUNO 01 I ILUNO nIl
+------+ I +-------+
I

1-------1
I t ask
I
Ilocal
I
ILUNO nnl
+-------+
PDT
I
+-------+
--------------) I for
I
Istationl
+-------+

not at a
station

B -

• .-) I

1-------1
I job
I
I local I
ILUNO nIl
+-------+

task A - at a station
TSB
+-----+
I
I
LDT
LDT
+------+
+-------+
I
I

LDT
+-------+

LDT
+-------+
I .-----)1
.-----. • ·)1
.----)------------)------1------ I
I
I
I ------- I
+-----+
Itask
I
I task
I
I local I
Ilocal
I
I LUNO nIl
ILUNO nnl
+-------+
+-------+
I

LDT
+-------+

Fig u reI 0 - 1 1

2270512-9701

10-63

L DT Ch a ins

I/O Subsystem

DNOS System Design Document

10.6.4

Details of IOU Processing.

IOU processing occurs in a number of
modules.
Those
described
here include the preprocessor, IUPREP, the IOU task, and a number
of modules that support special functions.
IOU P~eprocessor (IU1REP).

10.6.4.1

IUPREP
runs
in map file 0 as XOP-level code.
The call block is
buffered according to the format required by each subopcode.
IOU
processes the
following
subopcodes.
(Starred
codes
are
NOT
documented in user manuals; they are to be used only by operating
system tasks.)

*
*
*
*
*
*
*

90
91
92
93
94
95
96
97
98
99
9A
9B
9C
9D
9E
AO
Al
A3
A4
AS
A6
A7

Create File
Assign LUNO to Pathname
Delete File
Re lease LUNO from Pathname
Assign Diagnostic Device
Rename File (Assign New Filename)
Unprotect File
Write Protect File
Delete Protect File
Verify Pathname
Add Alias
Delete Alias
Define Forced Write Mode
Create IPC Channel
Delete IPC Channe 1
Attach Resource
Detach Resource
Detach Resource by Number
Modify FDR Bit
Release LUNO in Another Job
Assign System LUNO FF
Release File Structures

Not dncumented to users.

Pathname
characters must be in the following ranges to allow for
international character support by DNOS:
)24, )28, )29, )2E, )30 through )39, )41 through )SA,
)61 through )7A (standard English pathnames)
)SB through )SD (European characters)
)A6 through )DF (Katakana

characters)

Pathname length
is
checked
for
all
subopcodes
that
have
a
pathname.
If
the
length
is zero or is greater than 48, error
code )92 (Bad Pathname Syntax) is set in the user call block, and
an exit is made to RPRTNE in RPROOT.
I/O Subsystem

10-64

2270512-9701

DNOS System Design Document

The module IUVRFY is used to verify pathname syntax.
It
can
be
linked
with
any code that performs pathname verification.
When
the routine is called, register 1 must have the
address
of
the
buffer containing the pathname.
The buffer has the length of the
pathname
in
its
first
byte.
Register 10 must be a seven word
buffer to be used as a stack
by
IUVRFY.
Register
0
will
be
modified
by
IUVRFY,
but no other registers of the calling code
will be modified.
If the pathname is correct in syntax, register
o receives a value )0000. If the pathname is incorrect, register
o receives )9200.
There are two entry points in IUVRFY.
IUVPND
is
used
if
the
pathname can contain both upper and lower case letters, numerals,
the
dollar
sign, periods, left and right parentheses around the
last pathname element,
and
the
pound
sign(#).
The
katakana
character set and special European characters are also permitted.
The entry point IUVLET is used if the pound sign is not permitted
in
the
pathname.
Entry to the routine is via a branch and link
(BL) to IUVPND or IUVLET, with
a
data
word
following
the
BL
instruction containing the return address for error conditions.
The
IOU preprocessor defines an RDB that specifies the buffering
of the standard IOU call block.
IUPREP
builds
RDB
expansions
dynamically to specify additional buffering as follows:

If the subopcode requires a pathname, it is set up to be
buffered
in the STA along with the call block, with the
pathname pointer placed in the BRB.

A flag in IRBFLG indicates
whether
the
IRB
parameter
pointer
is
valid
on Assign LUNO operations.
If it is
valid, the parameter list is buffered into the
caller's
JCA and
the
parameter pointer is set in the BRB.
The
use of parameters on Assign LUNO is
for
the
operating
system only and is not documented in user manuals.

If
the
utility
flags
following may apply:

specify

KIF,

either

the

If the subopcode is )91 (Assign Luno)
and
either
the
temporary
file
bit or the autocreate bit is
set, buffer the keys to the STA and set a
pointer
in the BRB.
If
the subopcode is )90 (Create File), buffer the
keys to the STA and set a pointer in the BRB.
A call is issued to
the
RPBUF,
to
perform
the
expansion definitions.

request
processor
buffering
routine,
buffering as defined by the RDB and RDB

BRBs for all subopcodes that have pathnames
are
placed
on
the
Name Manager queue, unless the first character of the pathname is

2270512-9701

10-65

I/O Subsystem

DNOS System Design Document

a
period.
In
the last
queue for the IOU task.

case,

the BRB is placed directly on the

Name Manager checks to see if the access name is a logical
name.
If
so,
the
true pathname(s) are buffered into the STA, and the
buffered
pathname
pointer
is
reset.
Name
Manager
may
add
parameters to the IRB.
If parameters exist on an Assign LUNO, they are buffered into the
STA,
the
IRB
parameter pointer is set, and the IRB flag is set
indicating that the parameter pointer is valid.
10.6.4.2

Initial Processing in the IOU Task.

If the IRB flag indicates that the parameter
pointer
IUPRM is called to process the parameter list.

valid,

IUPRM is a table-driven module.
Each parameter has an associated
parameter
ID.
The
parameter
ID
is used as an index into the
table of subroutine entry points.
Each subroutine
translates
a
parameter
from
Name Manager format to the call block format and
places the parameter in the correct position of the
call
block.
(See
the
paragraphs
on
name
management
for
the format of a
parameter list.)
For parameters that have no place in
the
IRB,
the
parameter (or its address) is saved in the IOU address space
for later processing.
10.6.4.3

Channel Operations.

In a Create Channel
operation,
the
channel
pathname
must
be
identical
to that of the program file containing the owner task,
except for the last component.
For example, for a
program
file
named
.DIRECT.PROGFILE,
a
valid
channel
pathname
is
.DIRECT.CHANNEL.
If the SVC call block specifies LUNO 0
as
the
program
file LUNO for the owner task, IOU assumes that the owner
task resides on program file .S$SHARED.
The SVC returns an error
if the owner task is
the
owner
of
an
existing
channel
with
different
scope
or if the specified scope is task local and the
owner is already the owner of an existing task-local channel.
The SVC causes a CDR to be built in the same directory as the FDR
for the program file.
The CDR contains the channel
description,
the
installed ID of the owner task, and the record number of the
FDR for the program file.
The CDR is similar to an
ADR
and
is
linked
into the chain of ADRs (that is, each CDR or ADR contains
the record number of the next
CDR
or
ADR).
The
CDR
can
be
protected
from
an
accidental
Delete
Channel
operation.
The
channel access name can be specified in
the
delete-protect
and
unprotect
I/O
operations.
When a program file is deleted, its
CDRs and ADRs are also deleted.
Only the delete-protect flag for
the program file is checked when the
program
file
is
deleted.
See the section on data structure pictures for details of the ADR
and CDR.

I/O Subsystem

10-66

2270512-9701

DNOS System Design Document

In
a Delete Channel operation, the CDR for the specified channel
name is deleted.
The program file containing the owner
task
is
not affected.
Channel
LDTs have a flag to indicate that they are assigned to a
channel.
The LDT points to the CCB.
The LDT shows
the
default
resource
type
and
type
flags carried in the CCB.
Each time a
LUNO is assigned to a channel, the
LUNO
count
in
the
CCB
is
incremented.
The count is decremented as LUNOS are released, and
the CCB is deleted when the count equals zero.
IOU cannot distinguish an Assign to a channel from an Assign to a
file until the CDR is read.
After it is read, an FDB and FCB are
created
for
the
program
file
of
the owner task.
The Assign
causes the creation of the CCB and the bidding of the owner
task
(unless the relevant structures already exist).
The"CCB contains
the
eight-character
name of the last pathname component for the
channel.
After an owner task is bid, the run-time ID is used
to
search
the
TSB list for the TSB address of the owner task.
The
calling job JSB address and owner task TSB address are placed
in
the
CCB.
Each CCB created by an Assign points to an FDP of the
program file
containing
the
owner
task.
To
search
for
an
existing
CCB,
IOU
searches for a CCB with an FMT,FCB pair that
matches the desired program file FMT,FCB
pair.
This
indicates
that
the
owner
task
came
from
the
same
program file.
The
installed ID of the owner task must match that of the owner
task
of
the
channel to which the caller is assigning; a match on the
last pathname component for the channel is also required.
To establish a global channel, the owner task must be running and
issue an Assign to the channel.
The CCB is built in the STA, and
subsequent Assigns to the channel cause the creation of LDTs that
point to this same CCB.
Any requester Assigns that
precede
the
owner's
Assign
will
receive
errors.
The
owner
of a global
channel is identified by its
installed
ID
and
the
value
for
TSBFMT and TSBFCB, the description of the program file from which
the task was bid.
The
first Assign to a job-local channel causes a CCB to be built
in the caller's JCA.
The
owner
task
is
bid
by
IOU
in
the
caller's job via the SVC option that allows a task to be bid in a
different
job.
Subsequent
Assigns to the same channel use the
same CCB and owner task.
For task-local channels, a CCB is created and an
owner
task
is
bid on each Assign to the channel (excluding Assigns by the owner
task).
IOU must
match
up
the
owner
task's Assign with the
correct CCB, which was previously created.
An error is
returned
if the owner is the first to assign to a task-local channel.
During initial IOU processing of an Assign to a channel for which
the
owner processes Assigns, an LDT flag is set to indicate that
the LDT is nonusable.
The address of the LDT is
placed
in
the
2270512-9701

10-67

I/O Subsystem

DNOS System Design Document

BRO,
and
a
BRO
flag is set to indicate that IOU has partially
processed this request.
IRBSID
(session
ID)
is
cleared.
An
NFMAPO
call
is
issued to the IPC pre-processor to transmit the
BRB to the owner task.
Parameters associated with this call
are
passed to the owner task along with the call block.
After the owner task processes the Assign, IPC returns the BRB to
the
IOU
queue.
The
BRO
flag
tells IOU that the request has
already been processed.
The LDT address
is
obtained
from
the
BRO.
If
the
IRB
error code is nonzero, the CCB LUNO count is
decremented, and the LDT is released.
If no error occurred,
the
LDT
is
completed.
The resource type is placed in the LDT, and
the nonusable flag in the LDT is cleared.
The LDT is built before the owner processes
the
Assign
because
the
number
being
assigned must be checked for conflicts before
owner
task
processing.
In
addition,
while
the
owner
is
processing
the
Assign,
it
must
be ensured that no other task
assigns the same job-local or global LUNO.
10.6.4.4

Concatenated Files and Multifile Sets.

FCBs for concatenated files are linked together via
pointers
in
the
FCBs.
The
FCBs
are
flagged
as
being
members
of
a
concatenation, and the first FCB of the set contains
th~
number
of
files in the concatenation.
Concatenated files may be shared
as a set.
IOU provides error checking to prevent concurrent
use
of
individual
files of a set.
This provides protection against
unanticipated changes in the structure of the
concatenated
file
set.
(For example, this prevents another task from changing the
end-of-medium on the second of three concatenated files.)
A zero in the first byte of the pathname indicates that
multiple
pathnames
are
present.
The second byte contains the number of
pathnames.
Only Name Manager can
provide
a
pathname
in
this
format,
because
the
IOU
preprocessor
disallows a zero-length
pathname.
The Name Manager generates a pathname when
processing
a logical name for the concatenated file.
IOU
builds an FCB for each file of a concatenated set.
An error
is returned if the files are special usage files or if not all of
the files are of the same file type.
If LUNOS
are
assigned
to
any
of the individual files, an error is returned.
The FCBs are
flagged and linked, and the number of
files
is
placed
in
the
first
FCB.
An RPB is built and linked to the first FCB.
Access
privileges for concatenated files apply to the set of files,
not
to
each
individual
file.
Open
processing
checks
access
privileges for the set of files by searching the
RPB
chain
for
the first FCB only.
On
an
attempt
to
share a concatenated set, IOU provides error
checking.
IOU checks to see that the same
number
of
files
is
specified,
and that the requested files are in the same order as
I/O Subsystem

10-68

2270512-9701

DNOS System Design Document

those already
concatenated.
An
error
is
returned
if
these
conditions
do
not
hold.
Each
usage
of the concatenated set
causes the creation of an RPB chained to the first FCB.
When the
concatenated set is no longer
in
use
(when
the
last
RPB
is
deleted), all FCBs in the set are released.
When
key
indexed files are combined, they are not considered to
be concatenated, but are called a multifile set.
This is because
after
files
are
concatenated,
they
can
still
be
used
as
individual files.
This is not true for key indexed files; once a
set
of
files
has
been combined into a multifile KIF set, they
cannot, be handled separately using KIF operations.
Multifile KIF sets require special handling.
IOU
uses
the
FDR
end-of-medium
field
to
determine whether a key indexed file is
empty.
If all the specified files being combined are empty,
and
are not members of an existing multifile set, IOU formats them as
a
single file.
The creation date and time of the first file are
placed in the KDR of each file in the set.
Each file is given
a
sequence
number,
which is an integer value that ranges from one
to the number of files being combined.
The
sequence
number
of
each file is also stored in the KDR of the file.
The KDR for the
first file contains the total number of files in this set.
Error
checking
is
provided when nonempty key indexed files are
combined.
Each KDR must contain the same creation date and time.
Also, the total number of files from the KDR must be the same
as
the number of files specified in the current combination request.
The
sequence numbers of the files must start at one and continue
sequentially up to the total number indicated in the
first
KDR.
If
any of the above conditions is not met, an error is returned.
An empty key indexed file may be used as the last (and
ONLY
the
last) file of a nonempty multifile set.
The new file must not be
a member of an existing multifile set.
The new file is formatted
and
given
a
sequence
number
and a time and date to match the
other file(s).
The file count in the first KDR is incremented.
When a LUNO is assigned to a single key indexed file, the KDR
is
checked
for a sequence number.
If one is present, a flag is set
in the FCB to indicate that the
file
can
be
opened
only' for
unblocked I/O.
This is the mode used by the directory utilities,
for example.
10.6.4.5

Temporary Files.

DNOS
supports two types of temporary files:
task and job local.
Task temporary files are created either by
using
the
temporary
file
bit
in
the Create File operation, or by issuing an Assign
LUNO with the temporary file bit set.
When the
Create
File
is
used,
a standard file name can be specified; when an Assign LUNO
is used, a name is created in the form Un, where n is
a
7-digit
integer.
Task temporary files are often used as scratch files by
system
utilities.
They are deleted when the last LUNO assigned
2270512-9701

10-69

I/O Subsystem

DNOS System Design Document

to the file

is released.

Job temporary files
are
created
by
specifying
the
temporary
option
on
an
Assign Logical Name operation.
The job temporary
file is created when an Assign LUNa is done to the
logical
name
or
when
a
Create
File specifies the logical name.
The access
name associated with the logical name is the disk or volume
name
on which the file is to be created.

IOU
creates
job temporary files under VCATALOG, and it sets the
temporary flag in the
FDR.
After
the
file
is
created,
IOU
automatically
attaches the resource to the job.
The file is not
detached
until
the
job
terminates
or
the
logical
name
is
released.
The
file
is
deleted when the count of attaches and
LUNas assigned in the FCB is zero.
After a job temporary file is created,
the
file
name
must
be
entered
in the Name Manager data base.
For job temporary files,
the Name Manager allocates 18 bytes for the pathnBme (enough
for
the
length,
eight-character
volume
name,
period,
and eightcharacter file name).
The actual length of the
disk
or
volume
name is in the first byte of the pathname buffer.
IOU places the
length
and
file
name
of the newly created file in the buffer.
The already-processed flag is set in the
BRa,
and
the
BRB
is
placed
on the Name Manager's queue.
Name Manager is responsible
for calling the routine to queue the BRB for unbuffering.

10.6.5

Operating System Support SVCs.

IOU provides SVC support for
several
subopcodes
that
are
not
available
to the general user community.
These codes, described
in detail in the section on
special
SVC
support,
include
the
following:
Subopcode
94
AO
Al
A3

A4
A5

10.7

Purpose
Assign Diagnostic Device
Attach Resource
Detach Resource
Detach Resource by Number
Modify FDR Bit
Release LUNa in Another Job

DEVICE I/O UTILITY (DIOU)

Device
utility
functions (bidding tasks from a device; changing
device state; disarming hard break at a terminal; allowing
8-bit
characters)
are
performed by issuing device utility operations'.
These operations are IOU subopcodes and are transportable through

I/O Subsystem

10-70

2270512-9701

DNOS System Design Document

IPC.
Since none of these
subopcodes
conflict
with
other
IOU
subopcodes,
they
are
processed
by
the
DIOU
task
to
get
concurrency.
Some of the subopcodes require software
privilege.
The operations and their subopcodes are:
Subopcode

C2
C3
C6
C7

10.7.1

Purpose

Get Selected Device Parameters
Set Selected Device Parameters
Get CDE From CDT
Process Device Task Bid

DIOU Functions.

All I/O subopcodes are passed by the SVC request processor RPROOT
to IOPREP, the I/O preprocessor.
IOPREP hands all I/O subopcodes
greater than )90 to IUPREP.
IUPREP verifies that DIOU subopcodes
are
in the proper range.
IUPREP buffers the parameter field (if
specified) along with
the
call
block
in
system
table
area.
Control
is
then transferred to to DUMAIN for specific subopcode
processing.
DSRs
bid
tasks
by
calling
IOFCDT.
IOFCDT
places
the
bid
character in the PDT and then places the PDT on the BIDREQ queue.
When
the
scheduler
finds
something
on
the
BIDREQ queue, it
activates
IOTBID.
IOTBID
gets
the
device
number
and
bid
character
from
the PDT and places them in a Process Device Task
Bid ()C7) call block.
The PDT is removed from the BIDREQ
queue,
the
bid
character is cleared in the PDT, and the call is issued
to DIOU.
When the CDFPEA flag is set to"l, DIOU passes the
bid
character
in
the
first
byte of the first parameter and leaves the second
byte O.
The device number is placed
in
the
second
parameter.
Logon
tasks that need to CDE can then perform a Get CDE from CDT
operation ()C6).
If the task is to be bid in
the
same
job
as
PDTJOB,
the
CDE
parameters
are
placed
in the )2B call block
parameter fields CDEPV1 and CDEPV2.
10.7.2

DIOU Data Base.

There is one data file for each operating system generated.
The
file
is
in the directory S$CDT under VCATALOG.
The file within
S$CDT has the same name as the system to which it is
associated.
Each
file
has
25
CDTs.
The file is initialized by the Modify
Command Definition Table (MCDT) command using
SCI,
or
by
DIOU
during IPL if it does not exist.

2270512-9701

10-71

I/O Subsystem

DNOS System Design Document

Each
record of the CDT file is a command definition table (CDT).
Each record contains the SCI command definition entry
(CDE)
and
hard
break
CDE, the DXP CDE, and 13 zeroed CDEs.
That is, each
CDT has a maximum of 16 COEs.
The last four
characters
of
the
CDT contains the characters CDT.
Each
time
a system is loaded, OlOU runs
device numbers into the PDTs.

the PDT list and places

Each device has a three-byte field in its PDT
to
represent
the
CDEs
that
apply to it.
One byte indicates the CDT to use and a
word represents the CDEs in the table
that
are
valid
for
the
device.
If
the first bit is on in the word, the first COE will
be valid for the device; second bit, second CDE; and so on.
This
way each device may have an unique set of CDEs, with a maximum of
sixteen.

10.7.3

Data Structures Used by OlOU.

System data structures
used
by
DIOU
include
the
PDT
and
template of parameters.
Relevant fields in the PDT include

*
*

POTNAM - an eight-byte device name field

POTCHR
10FCOT

*
*

POTCDT - a one-byte COT number

PDTNUM -

PDTCDE -

two-byte device number
a one-byte field

for the bid character set by

the CDE mask for this device's CDT

The structure template for device parameters (DPR) is
a
set
of
equates, one for each field in the DIOU data base (multiple flags
are
stored
in
one field).
Any not marked as read only require
either software privilege,
hardware
privilege
or
system
task
status to modify.

I/O Subsystem

10-72

2270512-9701

DNOS System Design Document

UNL
***********************************************************

*
*
( DPR)
DUTIL DEVICE PARAMETERS
03/11/83
*
*
*
*
CHANGES TO THIS TEMPLATE REQUIRE CORRESPONDING
*
*
CHANGES TO THE PASCAL TEMPLATE "DPRPAS".
************************************************************
*
*
*
*

*
*
*
*
*
**
*

**
*
*
*
*
*
*
*
*
*

THE DPR TEMPLATE DESCRIBES THE DEVICE PARAMETERS MANAGED
BY THE DEVICE I/O UTILITY (DUTIL).
IT INCLUDES PARAMETERS
IN THE FOLLOWING RANGES:
PARAMETER RANGE
)01 - )5F
)60 - )FF

PARAMETER USAGE
OPERATING SYSTEM RESERVED
NOT SUPPORTED

IN THE FIELD COMMENTS, RO INDICATES THAT A PARAMETER IS
READ ONLY AND CANNOT BE MODIFIED.
SPECIAL FIELD COMMENTS:
DPRNAM - ONE TO EIGHT ALPHANUMERIC CHARACTERS WITH A LETTER
AS THE FIRST CHARACTER.
DPRNUM - ONE WORD NUMBER BETWEEN )0001 AND )07FF, EXCLUDING
100 THROUGH 255 ()64 THROUGH )FF).
DPRTYP
LIKE THE PDTTYP FIELD.
ON AN ASSIGN LUNO, THE VALUE
OF THIS FIELD IS PUT INTO THE LDTTYP FIELD OF THE
LDT AND IS RETURNED TO THE CALL BLOCK IN THE UPPER
BYTE OF THE DATA BUFFER FIELD.
DPRJOB - JSB OF THE FIRST JOB TO ASSIGN A LUNO TO A TERMINAL.

*DPRNAM
DPRNUM
DPRFLG
DPRDSF
DPRTYP
DPRJOB
DPRRPB
DPRLC
DPRCDT
DPRCDE
DPRPDT
DPRDTF
DPRSTK
DPROHD
DPRWTK
DPRDRS
DPRFMS
DPRFDB
DPRTFL
DPRECT
DPRVNM
DPRCHR

EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU

2270512-9701

)01
)02
)03
)04
)05
)06
)07
)08
)09
)OA
)OB
)OC
)OD
)OE
)OF
)10
)11
)12
)13
)14
)15
)16

RO
RO
RO
RO
RO
RO
RO
RO

*DEVICE NAME
*DEVICE NUMBER
*WORD OF FLAGS
*DEVICE STATUS
*DEVICE TYPE
*OWNER JOB
*RPB LIST HEADER
*LUNO COUNT
*CDT NUMBER
*CDE MASK
*PDT ADDRESS
*DEVICE TYPE FLAGS
*SECTORS PER TRACK
*OVERHEAD PER RECORD
*WORDS PER TRACK
*DEFAULT PHYSICAL RECORD SIZE
*VCAT FD SPECIAL AREA SSB ADDRESS
*VCATALOG FDB ADDRESS
*TEMPORARY FILE NAME SEED
*RETRY COUNT
*VOLUME NAME
*BID CHARACTER
10-73

I/O Subsystem

DNOS System Design Document

DPRBLN EQU )17
*BUFFER LEN OR # VIRT TERMINALS
DPRMAX EQU )18
* THE LIMIT FOR CURRENT OS PARMS
DPROSM EQU
)5F
*MAXIMUM O.S. PARAMETER
* EQUATES FOR DPRFLG
DP1IRB EQU
0
RO
*COPY IRB TO SYSTEM LOG
DP1RSI EQU
1
RO
*RESERVED
DPIRS2 EQU
2
RO
*RESERVED
DPISTA EQU
3
* DEVICE STATE
00 - ONLINE
*
*
01 - OFFLINE
*
10 - DIAGNOSTIC
*
11 - SPOOLER
DP10PF EQU
5
RO
*OPEN FAILED
* EQUATE FOR DPRDSF
DP2RSI EQU
0
RO
*RESERVED
DP2AID EQU
1
RO
*ALTERNATE PDT
DP2BI
EQU
2
RO
*BUFFER INPUT
DP2BO
EQU
3
RO
*BUFFER OUTPUT
DP2JIS EQU
4
*JISCII, 8-BIT ASCII MODE
5
RO
DP2REN EQU
*RE ENTER ME
DP2JAR EQU
6
RO
*JISCII RECEIVE
DP2JAT EQU
7
RO
*JISCII TRANSMIT
DP2RS2 EQU
8
RO
*RESERVED
DP2RS3 EQU
9
RO
*RESERVED
DP2WPM EQU)A
RO
*WORD PROCESSING MODE
DP2IRE EQU)B
RO
*INITIAL REQUEST
DP2INT EQU)C
RO
*DEVICE INTERRUPT LEVEL MASK
* EQAUTES FOR DPRDTF - DEVICE TYPE FLAGS
DP3FIL EQU
0
RO
*FILE ORIENTED
DP3TIL EQU
1
RO
*TILINE DEVICE
DP3TIM EQU
2
RO
*ENABLE TIME-OUT
DP3PRI EQU
3
RO
*PRIVILEDGED DEVICE
DP3KSB EQU
4
RO
*TERMINAL WITH A KSB
DP3COM EQU
5
RO
*COMM DEVICE
DP3SYD EQU
6
RO
*SYSTEM DISC
SP3RES EQU
7
RO
*RESERVED
LIST

DPRNAM
One
to
eight
alphanumeric characters with a letter as the
first character.
DPRNUM
A one word number between
through 255.

)0001

and

)07FF

excluding

100

DPRFLG
DPRFLG is a flag word with the following bit definitions.

I/O Subsystem

10-74

2270512-9701

DNOS System Design Document

DPIIRB
( X •••••••••••••••
DPIRSI = ( • X ••••••••••••••
DPIRS2
( •• X •••••••••••••
DPlSTA
( ••• XX •••••••••••

DPIOPF
DPIRS3

)
)
)
)

( ••••••••••••• X •• )
( •••••••••••••• XX)

COpy IRB TO SY STEM LOG
RO
RESERVED
RESERVED
RO
DEVICE STATE
ONLINE
00
OFFLINE
01
DIAGNOSTIC
10
SPOOLER
11
OPEN FAILED
RO

DPRDSF
DSPDSF is a flag word with the following bit definitions.
DP2RSl
DP2AID
DP2BI
DP2BO
DP2JIS
DP2REN
DP2JAR
DP2JAT
DP2RS2
DP2RS3
DP2WPM
DP2 IRE
DP2INT

··...
... ·... ··...
...
... ·...
··...
... ···...
... ··...
( .. . .
...
·
...
...
.
·
...
··...... ·...
...
.
... .
·... ··...
( .. .. ·...
...
( . . .. ·...
·
...
.... ·...
·...
...
( .. .. · ...
·
= ( . . ..
(
(
(
(

X •••
• X ••
•• X.
••• X

(
(
(

(

)
)
)
)
X •••
)
)
• X ••
)
• • X.
)
• •• X
X •••
)
)
• X ••
)
• • X.
)
• •• X
XXXX)

·... ·...

RO
RO
RO
RO
RO
RO
RO
RO
RO
RO
RO
RO
RO

RESERVED
ALTERNATE PDT
BUFFER INPUT
BUFFER OUTPUT
JISCII, 8-BIT ASCII MODE
RE ENTER ME
JISCII RECEIVE
JISCII TRANSMIT
RESERVED
RESERVED
WORD PROCESSING MODE
INITIAL REQUEST
DEVICE INTERRUPT LEVEL MASK

DPRTYP
The
DPRTYP
field
corresponds
to the PDTTYP field.
On an
Assign LUNO, the value of this field is placed in the LDTTYP
field of the LDT as well as being returned in the upper byte
of the data buffer field of the Assign LUNO call block.
DPRJOB
DPRJOB is the same as PDTJOB.
It is only valid for
devices
with
a KSB (terminals).
The JSB of the first JOB to assign
a LUNO to terminal is placed in DPRJOB.
This
prevents
any
other JOB from assigning a LUNO to the terminal.
DPRRPB
is
the
same
as PDTRPB.
For devices that validate
DPRRPB
opens
an
RPB
must
be
generated
during
assign
LUNO
processing.
DPRRPB contains the address of the beginning of
the RPB list.
DPRLC
DPRLC
is the same as PDTLC.
This field contains a count of
the'number of LUNOs assigned to the device.
DPRCDT
The first
terminal.
2270512-9701

byte
The

of
DPRCDT
identifies
the
CDT
next
two
bytes
are
the
word
10-75

for
this
mask that

I/O Subsystem

DNOS System Design Document

identifies the CDEs within the CDT that are valid
terminal.

I
10.8

for

this

FILE ACCESS SECURITY

DNOS
1.2
includes
security
on
a
per
file basis.
Directory
security and volume security are not implemented in this release.
A user's security
environment
is
defined
at
the
job
level.
Associated
with each job in the system is a user ID and the list
of access groups of which he is a member.
A collection of
users
which
are
expected to have similar access to files belong to an
access group.
All secured files have a list of access groups and
rights which determine who
may
access
the
file
and
in
what
manner.
This list is called an access control list.
Permission
is granted if the user is a member of
an
access
group
in
the
access control list.
Since security is enforced on a per job basis, it is not possible
for
a
server
job
to
accept files from other jobs and perform
operations on those files with the original user's security.
The
spooler is an example of
such
a
server
job.
To
solve
this
problem, an option for secured IOU SVCs is supported.
A task can
specify the user ID with which the access rights for the LDT will
be
generated.
Such a task must have the security bypass feature
and enforce its own security, unless the passcode for the user ID
is also specified.
Specific operations that
have
this
feature
include
Assign LUNa, Create File, Delete File, Modify File Name,
and the Modify File Protection SVCs.
Assigning a LUNa to the disk (using direct disk I/O) and
bidding
a
task
in
another job are potential security bypass operations
that are not restricted
by
the
operating
system.
These
are
better
handled
through
the
use
of
functional security or by
allowing tasks to be members of access groups, features that
may
be implemented in a future release.
10.8.1

Establishing a Job's Security Environment.

A user's security environment is determined during job creation.
The logon task solicits a user ID
and
passcode.
If
logon
is
turned
off
through
use of the MTS command, this information is
located in
the
S$SCA
file.
The
user
ID
and
passcode
are
validated against the entries in the S$CLF file.
Job
Manager, during create job processing, validates the user ID
and passcode against the S$CLF.
This check
is
necessary
since
not
all
create
jobs are issued by the logon task.
Job manager
reads the S$CLF to find the user ID, passcode and access
groups.
The
user
ID
is
copied
into the JSB.
The encoded passcode is
I/O Subsystem

10-76

2270512-9701

DNOS System Design Document

copied into the JIT.
A capability
list
is
built.
This
list
includes a count of access groups followed by a list of encrypted
access group names, each name followed by a flag word.
This list
resides in the JCA, pointed to by JITCAP.
The
security manager function is performed by an overlay of IOU.
This overlay is not included as part of the kernel
program
file
if
the security option is not chosen during sysgen.
In general,
a user's security access to a file is
determined
during
assign
LUNO
processing.
The rights are stored in the LDT.
Subsequent
operations to the file check the rights in the LDT
to
determine
whether the user has appropriate access.
All
IOU
operations
are
first
processed
by
IUMAIN.
IUMAIN
maintains a table of secured IOU
operations.
These
operations
include
Create File, Assign LUNO, Delete File, Modify File Name,
Unprotect File, Write
Protect
File
and
Delete
Protect
File.
Several
conditions must be met before security checking is done:
the system must be secured, one of the above
secured
subopcodes
must
have been encountered, and the pathname must be longer than
a single node
(indicating
possibly
a
file
as
opposed
to
a
device).
IUSPRE
is
the security manager preprocessor routine.
If a user
ID parameter is passed with the IRB, IUSPRE verifies that
it
is
valid.
If
the parameter was not specified by a security bypass
task, the passcode is also
verified.
A capabilities
list
is
generated
from
the S$CLF file instead of using the capabilities
list pointed to by JITCAP.
For all secured suboperations except Create
File,
IUSPRE
calls
IUGAR
to
generate
the user's access rights to the file.
IUGAR
calls the IOU routines that build the FDB tree and
FCB
for
the
file.
It
calls a routine to compare the capabilities list with
the file's access control list.
If
the
access
group
in
the
capabilities
list
is
SYSMGR, the user receives total access to
the file.
If no access groups are associated with
the
job
the
user will receive PUBLIC access to the file.
If no access groups
are
found and no PUBLIC rights are specified, the operation will
fail.
The user will be returned a security violation error.
If
some access is determined, control is returned to IUSPRE.
If
the
operation is an Assign LUNO, the rights are saved off to
be later entered into the LDT during the
Assign
LUNO
routines.
If the operation is a Delete File or a Modify Protection SVC, the
proper
access
is
verified.
In the case of a Modify File Name,
the access is verified for the new pathname, if it existed.
The
access
for
the
old
pathname is verified by looking at the LDT
rights field.
A Modify File Name of a directory is
specifically
not allowed.
A Modify
File
Name option exists which allows the user to keep
the security of the new pathname.
If this option
is
specified,

2270512-9701

10-77

I/O Subsystem

DNOS System Design Document

the
security is copied to system table area in a structure known
as an access control packet.
After the Modify
File
Name
takes
place,
the
security is copied from the access control packet to
the file and the packet
is
released.
If
the
option
is
not
chosen,
the
default
results
of the Modify File Name leave the
file secured with the old pathname's access rights.
If
a
LUNO
is
being
assigned
to
a
concatenated
the
file,
concatenated
file
processor
calls
the
security
routines
to
determine the access rights for
each
file.
These
rights
are
ANDed to determine the final access rights.
In the case of file creation or Assign LUNO with auto-creation of
a
file,
IUSPRE calls a routine to search the capability list to
find the creation access groupIf no such group
is
specified,
the
default
is
taken as PUBLIC.
When the file is created, the
encrypted group name is written to the FDR with all access
right
flags set, and the public bits are turned off.
Aliases
inherit
the
security
of the file to which they refer.
The addition or deletion of aliases is not secured.
Minimal channel security is implemented.
IUSPRE saves the rights
to the channel owner program file.
Before
a
channel
owner
is
auto bid by an assign LUNO to the channel, the rights are checked
for execute access.

10.8.2

Enforcing Security.

The security manager does Some set up of the security environment
and
enforces
security for IOU operations.
Security is enforced
in each process that
performs
a
protected
or
a
particularly
dangerous function.
10.8.2.1

File Manager.

There are differences between open access privileges and security
rights.
The
access
privileges
specified on an Open operation
enable a user to limit access by others while performing
a
file
operation.
It
may
be
desirable
for a user who has only read
access rights to a file, for example, to open it
with
exclusive
use.
That is, he may only read the file, but while doing so, no
operation to this file by others may take place.
File manager enforces read and write security to files.
The file
manager routine IOPREP compares the I/O subopcode against a table
of allowable operations.
The
tables
and
required
access
are
given below.

I/O Subsystem

10-78

2270512-9701

DNOS System Design Document

File operations allowed only if

)09
)OA )41 )42
)44 )45 )48
)59

Read ASCII
Read Direct
Read Greater
Read by Key, Read Current
Read Greater Than
Read Next
Read Previous
Multiple Record Read

File operations allowed only if
)02
)OB
)OC
)OD
)10
)46
)47
)49
)5B

the requestor has read access:

the requestor has write access:

- Close with EOF
- Write ASCII
- Write Direct
- Write logical EOF
- Rewrite
- Insert
- Rewrite
- Delete by Key
- Multiple Record Write

File operations which will succeed if Assign LUNO was successful:
Open
Set Currency
Forward, Backward Space LUNO
Read File Characteristics
Unlock
Close
Specify Write Mode
Rewind
10.8.2.2

Program Manager.

Program management
enforces
security
on task bids and overlay
loads.
NFTBID checks the program file
LDT
for
execute
access
when
bidding
tasks.
Overlay loads are checked by PMOVYL.
Task
installations, deletions and assigning program space are enforced
by file manager when the user tries
to
read
or
write
to
the
program
file.
S$SHARED
is assumed to be a public program file
and cannot be secured.
When LUNO )FF is specified,
no
security
check
is
made
since
execute
access
to
the program file has
already been established.
10.8.2.3

Segment Manager.

In order to do a Change Segment
operation
for
a
program
file
segment,
the
user must have execute access to the program file.
In order to do relative record I/O using a
Change
Segment
SVC,

2270512-9701

10-79

I/O Subsystem

DNOS System Design Document

the
user
must have read and write access to the relative record
file.
In order to do relative record I/O using a Create
Segment
SVC, the user must have write access to the relative record file.
The above is enforced by segment management in SMPREP.
10.8.2.4

Sysgen.

In
DNOS
1.1,
if the SVC for security was specified the Encrypt
and Decrypt SVCs were included.
In DNOS 1.2, the ENCRYPTION
SVC
group
includes
those
SVCs.
In DNOS 1.2, a YES response to the
global SECURITY question causes the system option
word
security
bit
in
NFDATA
is to be set, the security overlay for IOU to be
added to the kernel program file, and the encryption SVC group to
be included.
10.8.3

Volume Security.

A utility called Modify Volume Security (MVS) is supplied to make
it impossible to install a secured DNOS volume on a
DX10
or
an
unsecured
DNOS
system.
It is located in the .S$SECURE program
file.
This task modifies a field in sector zero which
indicates
to
the
install volume processor that this can only be installed
on a secure system.
10.8.4

Networking.

For DNOS 1.2, the security access one will receive
doing
remote
I/O
will
be
the
access of the remote LAN job, as the SVCs are
issued remotely by this job.
When performing a remote logon, one
acquires the security associated with the user ID used to log on.
10.8.4.1

Manipulation of the Access Control List.

Modifications to the access control list for a file are made by a
system task called MSAR.
This utility
task
allows
a
user
to
modify
the security access rights of any file for which the user
has the control access right.
It also allows a user
to
display
the list of access groups which currently have access to the file
and what access rights each group has to the file.
MSAR
is
bid
by
the MSAR and LSAR SCI command procedures.
PARMS list is as follows:

I/O Subsystem

10-80

The

2270512-9701

DNOS System Design Document

PARM
1
2

3
4
5
6
7
8
9
10

Definition

----------

Function code: O=LSAR ;'
User's passcode
File pathname
Listing access name
Access group name
access (YES/NO)
Read
access (YES/NO)
Write
Delete
access (YES/NO)
Execute access (YES/NO)
Control access (YES/NO)

I=MSAR
(not
(not
(not
(not
(not
(not
(not

used
used
used
used
used
used
used

for
for
for
for
for
for
for

MSAR)
LSAR)
LSAR)
LSAR)
LSAR)
LSAR)
LSAR)

The MSAR task consists of the
modules
MSMAIN,
MSMSAR,
MSLSAR,
and MSRCLF from the VOLOBJ.MSAR.OBJECT
MSDOOR,
MSDDIO,
MSFUDR,
directory,
several
low
level
subroutines
from
the
VOLOBJ.IOU.OBJECT directory,
the passcode encryption subroutine
from the VOLOBJ.SECURITY.OBJECT directory,
and
stardard
UTCOMN
and S$ routines.
MSMAIN verifies
that the utility is being run on a DNOS 1.2 (or
later) system.
It then assigns and opens a LUNO to .S$CLF, picks
up the user's ID from the JSB, finds the user
deScriptor
record
(UDR)
within
.S$CLF
for
the
user,
and verifies the passcode
entered by the user.
If
the
passcode
verifies,
MSMAIN
then
assigns
a LUNO to the user specified file, finds the LDT for the
LUNO just assigned, and verifies that the file is a
local
file,
not
a
directory, and that the user has the control access right
for the file.
If all goes well, MSMAIN then calls IUGFCB to
map
in
the
FCB
for
the
file
and saves the FCB address for later
direct disk I/O operations.
MSMAIN then goes to either MSLSAR or
MSMSAR depending on the operation specified.
MSLSAR closes and releases the LUNO to .S$CLF as the
utility
is
done
with
that
file.
It then calls S$OPNS to open the listing
file with the security rights of the requesting
user
ID.
This
special
entry
point
in the S$OPEN routine must be used because
the MSAR task is installed with the
security
bypass
attribute,
but
the
user
must
not be allowed to put the listing on top of
files to which he does not have write access.
MSLSAR then
calls
MSRFDR
to
read
the FDR for the user specified file and formats
the listing to show the various access groups that have access to
the file and the access rights for each group.
MSMSAR calls S$PARM to get the user specified access group
name.
If
the
name is SYSMGR, MSMSAR terminates with an error message.
Otherwise, MSMSAR verifies that the access group name is valid on
this system.
If the name is PUBLIC, then it is considered valid.
Otherwise, MSMSAR calls MSRCLF to read records
from
.S$CLF
and
verifies that the name is a valid existing access group name.
At
this
point,
MSMSAR closes and releases the LUNO to .S$CLF since
2270512-9701

10-81

I/O Subsystem

DNOS System Design Document

the utility is now done with that file.
MSMSAR then calls S$PARM
several times to determine the various access
rights
which
the
specified for the access group to have.
MSMSAR then calls MSDCLO
to
close the door on the directory in which the FDR for the user
specified file resides, calls MSRFDR to
read
the
FDR
for
the
file, changes the access control list appropriately, calls MSWFDR
to
write the FDR back to disk, and then calls MSDOPN to open the
door for the directory.
MSMSAR then releases
the
LUNO
to
the
user specified file and terminates.

10.9

INTERPROCESS COMMUNICATION (IPC)

IPC
provides
the
capability
for two or more tasks to exchange
information.
The information exchanged may take the
form
of
a
synchronization signal, a short message, a request for a service,
or
a
high-volume
data transfer.
The distinction between these
categories is often blurred in practice.
The primary IPC operations are to read and write
messages.
The
task
to
which a write or read is addressed may be identified in
several ways.
In a message-oriented IPC mechanism, no
permanent
channel
exists
between the two communicating processes.
Writes
and reads are addressed to specifically named processes, and
the
IPC
supervisor
must
utilize
a
rendezvous
table
to
resolve
matching
operations.
The
IPC
approach
in
DNOS
is
channel
oriented.
Channels
are
created and exist independently of the
tasks that use them; IPC requests are directed to the appropriate
channels.
In DNOS, a
channel
is
defined
as
an
IPC
path
between
two
different
tasks
within the same computer, with one of the tasks
designated as the owner of the
channel.
A channel
owner
has
control
over how the channel is used, while the second task (the
requester) has less flexibility and fewer privileges.
IPC processing in DNOS has

the

following characteristics:

Each write or read operation is addressed to a
to which a LUNO has been assigned.

Each
operation
issued to a channel by a requester must
be
matched
by
~n
operation
of
the
channel
owner.
Depending
on
the
operation
issued
and
the
current
environment, the requester mayor may not
be
suspended
until the operation completes.

Each
channel
has
a
queue
of pending requests
owner, ordered chronologically.

IPC channels may be used via SCI like other I/O
DNOS system.
Some of the SCI commands available

I/O Subsystem

10-82

channel,

to the

resources
on
a
for use with IPC

2270512-9701

DNOS System Design Document

channels
are
the
Create
IPC Channel (CIC),
(DIC), and Show Channel Status (SCS) commands.

10.9.1

Delete IPC Channel

IPC SVC Interface.

All program-level access to the IPC facility is through the
DNOS
SVC
mechanism.
The
general
SVC
parameter block used for IPC
service calls
to
symmetric
channels
is
like
that
used
for
resource-independent
I/O.
The
SVC
parameter
block
used for
request SVCs to master-slave channels may be like that
used.
for
resource-specific
I/O.
The parameter block for utility calls is
like that used for file and I/O utility calls.
The
IPC
opcodes
are
shared
with
the
DNOS
I/O
facility,
with
the operation
performed depending on the context.
Every channel has one owner.
The owner of a
channel
is
always
involved
in
every
message
exchange or other operation on that
channel.
Any user other
than
the
owner
of
the
channel
may
communicate only with the owner.
This results from the matching
rules
used
by
IPC
when
handling requests to channels.
These
rules are given in the description of the
IPC
support
routine,
IPCGQR.
10.9.2

Channel Characteristics.

DNOS channels can be defined as either symmetric or master/slave.
Symmetric
channels function with simple read and write requests,
where one correspondent
on
the
channel
issues
a
read
while
another
issues
a
write.
The
data
written
is passed to the
reader's buffer when a pair of requests match.
In a master/slave
channel, the master task receives the entire buffered
SVC
block
for
processing.
The
master
task
processes
and
returns the
modified request to the requester (slave) task.
10.9.2.1

Symmetric Channel Activity.

Symmetric channels are used for communicating messages or data in
a relatively restricted fashion.
Tasks may be written
in
highlevel
languages or in assembly language to synchronize, exchange
information, or facilitate use of COmmon files.
The
operations
addressed
to
the
channel
by
such
tasks are limited to Open,
Close, Close EOF, Read Status, Read, Write, and Write EOF.
From the point of view of an owner or requester task,
channel is always in one of three states:

Closed -

Open - The task may issue any operation that
this channel access mode.

2270512-9701

The task must

a symmetric

issue an Open to use channel.

10-83

is legal in

I/O Subsystem

DNOS System Design Document

Dormant - The task must issue a Close and then may again
open and use the channel.

The transitions between states are shown in Figure 10-14.
An Open to a channel, when fielded by the
I/O
preprocessor,
is
checked
against
current
access
privileges
held
by
other
requesters.
The same rules apply for channels as for
other
I/O
resources
when
granting or denying access to any user after the
first.
For example,
if
one
requester
opens
a
channel
with
privileges
of
exclusive
all,
no
other requester can open the
channel.
Most symmetric channel requesters issue Opens with shared access.
When the requester wishes to be the only
requester
served,
the
channel should be created as a non-shared channel.
IPC
uses
the access privileges specified on an Open to allow or
deny particular I/O
operations
to
a
symmetric
channel.
For
example, a user who opens with read only privileges might issue a
Write.
That Write is not allowed (just as it is not allowed to a
read-only device like a card reader).
Although
requesters
may
not
be aware of the fact, the channel
definition may dictate more stringent access privileges ~han they
specify.
For example,
a
symmetric
channel
established
as
a
nonshared
channel
can be opened by a requester in any mode, but
it will function with only one requester
at
a
time.
This
is
necessary for the read/write channel resource mode of a symmetric
channel,
since
the
owner
task
has
no way of differentiating
between requesters.
A Close may be issued by an owner or a requester, or
it
may
issued
by DNOS when processing an abnormal termination by a
on the channel.
IPC adjusts the CCB to reflect
the
Close;
I/O
postprocessor
modifies the LDT as it does for devices.
queued requests from
the
closing
task
are
removed
from
queues.

be
task
the
Any
CCB

When
a
Close
is issued by an owner, IPC fields the request and
the channel is marked as dormant
for
all
requesters
currently
open.
This
setting
causes requesters to receive errors on any
operations except Open and Close.
As soon as a
requester
on
a
dormant
channel
issues a Close, the channel is again closed for
that requester; however,it is available to be opened.
Opens
to
a dormant channel are queued to the CCB until each Close has been
processed and the channel owner can again issue an Open.
A Read Device Status operation is queued to IPC for processing as
soon as the IPC task executes.

I/O Subsystem

10-84

2270512-9701

DNOS System Design Document

+---------------+ req. open
ICLOSED to
1---------+
1
owner
1
1
1
1
1CLOSED to
1
requester 1
1
1
OOP=NO
1 (-------+
1
OCL=NO
I
req. hangs
I
RCL=NO
I
req.+----)I
OPN=O
1(---+
closel
+---------------+
I
I
I
lowner close
+----------+
I
ownerl
lowner 1
+--------+
req.
req. gets
I
close 1
lopen
1
owner
owner
non)A7 error
1
I
1
I
nongets )E6
close
I
I
I
I
1
close
error
I
I
I
I
1
1
1
1

VII

+------------------+
ICLOSED to
1
I
owner
I
IDORMANT to
I
I
requester
I
I
OOP=NO
I
1
OCL=YES
I
1
RCL=NO
I
I
OPN=1
I
+------------------+
lowner open
I(owner
I hangs)
I
+-----)-----+

OOP
OCL
RCL
OPN

+-----------------+
+-----------------+
10PEN to
I
IDORMANT to
I
I
owner
I
I
owner
I
ICLOSED to
I
ICLOSED to
I
I
requester
I
I
requester
I
1
OOP=YES
I
I
OOP=YES
I
I
OCL=NO
I
1
OCL=NO
I
1
RCL=NO
I
I
RCL=YES
I
I
OPN=l
I
1
OPN=1
I
+-----------------+
+-----------------+
I
I
I
Ireq.
I
Ireq.
I
Ireq.
Iclose
I
lopen
I
lopen
I(shared I
+--(---+
I
I channel) I
(hang)
owner I
V
I
I
closel
+------------------+
Ireq. close
+---(--IOPEN to owner
I--)--+(non-shared
IOPEN to requester I
channel)
I
OOP=YES
I
I
OCL=NO
I
Owner Open
I
RCL=NO
I
Owner Closed
I
OPN=2
I
Requester Closed
+------------------+
IAII operations
Number of tasks
open
I
lexcluding opens
+----(--+and closes
Figure 10-12

Symmetric Channel States

On other operations to a symmetric channel, a match must be found
by IPC before the operation will be performed.
That is, one task
must
issue a Read and the other a Write before either operation
will be processed.
2270512-9701

10-85

I/O Subsystem

DNOS System Design Document

The owner task
may
have
only
one
request
outstanding
to
a
particular channel at anyone time.
If an owner issues a request
to
a
channel
to which an owner request is already pending, the
second request will be returned with an error.
10.9.2.2

Master/Slave Channel Activity.

A master/slave channel is established so that an owner
task
may
process
all
requests
of the requester tasks.
The master/slave
owner task can be written in assembly language using
the
Master
Read,
Master
Write,
Redirect
Assign Luno, and Read Call Block
operations.
It may be written
in
a
high-level
language
with
subroutine support to issue these SVCs.
When
accessing
a
master/slave channel, a requester may need to
pass a set of parameters
to
the
master
(owner)
task.
These
parameters
may
be
specified
as part of an Assign Logical Name
command
and
passed
to
the
owner
task
via
an
Assign
LUNO
operation.
In
this
and
other
cases
an
owner task may process requester
Assign LUNO and Release LUNO operations, gathering and
supplying
data from and to IOU.
This option is specified by the Create IPC
Channel
SVC
operation
or
SCI command.
The owner receives the
request with Master Read and modifies it to
reflect
appropriate
processing.
The
owner
task
then issues a Master Write of the
Assign LUNO call block.
IPC queues the request back to IOU to be
completed.
The owner task must not modify certain fields in
the
SVC block, so that IPC can correctly return the block.
Similarly,
the
owner
may
process
Abort I/O SVCs ()OF) or I/O
utility operations other
than
Assign
LUNO
and
Release
LUNO.
These
options
can
be
specified
by the Create IPC Channel SVC
operation or SCI command.

While using a master/slave channel, a requester
task
may
issue
any
I/O operation to a channel, and the owner task processes the
operation depending on how the owner task is designed.
The owner
task issues a Master Read to obtain a request for processing
and
a
matching Master Write to return messages or status information
to the requester.
Owners
of
master-slave
channels
may
have
only
one
request
outstanding
to a particular channel at anyone time.
The Master
Write and Redirect Assign LUNO operations are exceptions to
this
rule.
An
owner
may
issue either a Master Write or a Redirect
Assign LUNO while a Master Read, Read Call Block, or Read
Status
operation is pending.
All
I/O
operations
issued
by
the requester are passed to the
owner task by IPC.
Figure 10-15 shows the operations used by the
owner task.

I/O Subsystem

10-86

2270512-9701

DNOS System Design Document

*----------------------------------------------------------*
00

Open

IPCexecutes the Open
checks for legal access

----------+-----------------+-----------------------------I
01
1 Close
1
IPC executes the Close
I
----------+-----------------+-----------------------------I
05
1 Read Status
I
Owner receives status data 1
----------+-----------------+-----------------------------+
19

Master Read

Owner gets whole
of requester

call

blockl
1

----------+-----------------+-----------------------------I
lA

1 Read

Call Block 1

Owner gets first part
requester call block

----------+-----------------+-----------------------------I
IB

1 Master Write
1
Owner sends information
l i t o requester

1
1

----------+-----------------+-----------------------------I
lC

Redirect

Assign

1 LUNO

IPC sends call block to
another channel owner

----------------------------------------------------------*
Figure 10-13

10.9.3

Details of

Owner SVCs for Master/Slave

Channels

IPC Processing.

Service calls to IPC channels are first routed
through
the
I/O
preprocessor,
IOPREP,
for
common
I/O handling.
They are then
passed on to the IPC preprocessor, IPCPRE.
This
routine
checks
for
some
error
conditions.
If
no
error
is
found,
IPCPRE
determines whether fast transfer is possible.
If
fast
transfer
is
possible,
the exchange is performed immediately.
Otherwise,
the request is queued to the IPC queue server,
IPCTSK,
and
the
requester task is suspended.
10.9.3.1

Structures Used for

IPC Processing.

Each
channel
is represented by a channel control block (CCB) in
the system table area or the job
communication
area.
The
CCB
contains
two
queue headers:
the pending queue (CCBPBQ) and the
already-processed
queue
(CCBABQ).
All
requests
awaiting
processing
by
IPC
other
than Master Write and Redirect Assign
LUNO requests
are
placed
on
the
CCBPBQ.
Master
Write
and
Redirect
Assign
LUNO
requests
are
placed
on
the
CCBABQ.
Requester call blocks which have been master read
but
have
not
yet
been
master written or redirected are stored on the CCBABQ.
There is never more than one owner
request
on
any
queue.
If
there is an owner request on a queue, it will always be the first
entry on the queue.

2270512-9701

10-87

I/O Subsystem

DNOS System ,Design Document

The
IPCQUE, which is in the system table area, contains requests
for task level IPC processing.
The queued requests are pr~cessed
by the IPC queue server IPCTSK.
The queue entry is a QIR,
shown
in
the section on data structure pictures.
The queue link field
is used to chain all current requests to be performed by
IPCTSK.
If the channel being used for this queue entry is global, the JSB
address
(to
find the CCB) is zero.
This indicates that the CCB
and BRBs are in the STA.
For other typ~s of channels, the JSB is
used to find the segment information so that the JCA segment
can
be loaded into memory and the CCB and BRBs can be located.
The
anchor
for
IPCQUE is in the STA.
The anchor is a standard
DNOS queue header, shown by the QHR template in
the
section
on
data
structure pictures.
When NFQUEH places an entry on the IPC
queue, IPCTSK is bid.
IPCTSK processes
each
queue
request
by
examining
the CCBABQ and CCBPBQ for the CCB specified in the QIR
and matching as many requests as possible.
10.9.4

Detailed Operation of IPC Routines.

There are two paths through the IPC subsystem:
a task level path
and an XOP level (fast transfer)
path.
All
IPC
requests
are
handled
by
the
IPC
preprocessor,
IPCPRE.
IPCPRE. determines
whether a request can be handled in fast transfer mode. '. If
so,
IPCXFR
is
called to transfer the request to the IPC task (which
must be in memory).
The IPC task, running in XOP mode
(map
0),
processes
the
request.
The
routine
IPCXOP
in
the IPC task
handles the request.
If IPCPRE determines that fast transfer
is
not
possible,
the
request is queued and later processed by the
IPC queue server, IPCTSK.
The
same
code
(IPCPRO,
IPCMRD
and
IPCMWT)
is
used
to
perform both XOP level and task level IPC
processing.
Fast transfer is only possible when the IPC task and
all necessary buffer segments are in memory.
If a channel owner releases its LUNO to the channel,
or
if
the
owner
of
a
task-local
or
job-local
channel
terminates, the
channel is considered dead.
This is indicated by
the
CCB
flag
CCFDED.
IOU or PMTERM will set the CCFDED flag, build a QIR for
that channel, and queue it to IPCQUE in order
to
activate
IPC.
IPC will
return
outstanding
and subsequent requester requests
with an owner aborted error, (error code )A7).
10.9.4.1

IPC Preprocessor (IPCPRE).

IPCPRE runs at XOP level when an I/O
or
IOU
call
buffered
by
IOPREP
or
IUPREP
is
detected as being for a channel or remote
resource.
The
following
is
a
description
of
the
IPCPRE
algorithm:

I/O Subsystem

10-88

2270512-9701

DNOS System Design Document

IF the request is an I/O request or an Abort I/O request
THEN BEGIN
IF the request requires a buffer
THEN call IPCCB to build a Buffer Address Packet (BAP)
for the buffer.
IF the channel is not busy and the IPC task is in memory and the
request is not a Redirect
THEN BEGIN
call IPCXFR to process request in fast transfer mode.
IF IPCXFR returns without error
THEN return.
If IPCXFR returns an error, one of the task
*
segments
or buffer segments was not in memory,
*
so
fast
transfer
was not possible.
The request
*
ha~ been queued by IPCXOP to the CCB.
All we
*
have
to
do
now
is
queue
a
QIR
to
the
end
of IPCQUE
*
END
ELSE IF request is a Master Write or Redirect Assign LUNO
THEN queue request to head of CCBABQ.
ELSE IF request is an owner request
THEN queue request to head of CCBPBQ.
ELSE queue request to end of CCBPBQ.
END
generate a Queued IPC Request (QIR).
queue the QIR to the end of IPCQUE.
set the Channel Busy flag in the CCB.
return.

10.9.4.2

IPC Queue Server (IPCTSK).

When
a
request
cannot be processed in XOP mode, the request is
processed at the task level by IPCTSK.
IPCTSK
is
activated
by
NFQUEH when a
QIR
is
queued
to
IPCQUE.
The following is a
description of the IPCTSK algorithm.

2270512-9701

10-89

I/O Subsystem

DNOS System Design Document

WHILE the IPCQUE is not empty
BEGIN
get request from IPCQUE.
IF channel is job or task local
THEN map the JCA that contains the CCB
WHILE there exist processable requests on the
CCBPBQ or CCBABQ
BEGIN
call IPCGQR to get a request or a pair of
requests.
IF IPCGQR returned an owner request
THEN IF the owner request requires a buffer
THEN load the buffer segment.
IF IPCGQR returned a requester request
THEN IF the requester request requires a buffer
THEN load the buffer segment.
IF this is a master/slave channel and the owner
request is not a Redirect or a Read Call Block
THEN load all requester task segments.
call IPCPRO to execute the data exchange.
IF owner request was not processed
THEN requeue the request to the CCB.
IF requester request was not processed
THEN requeue the request to the CCB.
unload any task segments that were loaded.
END
reset the Channel Busy flag in the CCB.
END

10.9.4.3

IPC XOP level request

processor (IPCXOP).

The routine IPCXOP is in
the
IPC
task,
although
it
is
only
executed
in map O.
If IPCPRE determines that the IPC task is in
memory, a branch and link is performed to IPCXFR, which transfers
con~rol to IPCXOP.
IPCXOP queues the request to the CCB and calls IPCGQR
to
get
a
request
or
pair
of
requests
from
the CCBABQ or CCBPBQ.
The
subroutine IPCCHK is called to
determine
whether
the
requests
returned
by IPCGQR can be processed in fast transfer mode.
If a
request cannot be
processed,
either
because
of
an
error
or
because
fast
transfer
is not possible, the request is requeued
for processing by IPCTSK.
IPCXOP continues to process requests from the CCBPBQ
until a request cannot be processed.
10.9.4.4
IPCPRO,

IPC request

processors (IPCPRO,

IPCMRD, and IPCMWT are

I/O Subsystem

the

10-90

IPCMRD and

routines

and

CCBABQ

IPCMWT).

in the IPC task that

2270512-9701

DNOS System Design Document

actually perform the data exchange between requests.
IPCPRO
is
called by IPCTSK or IPCXOP for all requests.
IPCPRO calls IPCMRD
and
IPCMWT
to
process Master Reads, Master Writes and Redirect
Assign
LUNa
operations.
Other
operations
to
master/slave
channels
and
all operations to symmetric channels are performed
directly by IPCPRO.
On a Master Read or Read Call Block, IPCMRD or IPCPRO copies
the
requester's
call block into the master task's master read buffer
(MRB).
On a Master Read, the call is dequeued
from
the
CCBPBQ
and
placed
on
the CCBABQ to await a Master Write or a Redirect
Assign LUNa.
On a Read Call block operation, the requester
call
block is left on the CCBPBQ.
On a Master Write, IPCMWT unbuffers
selected
fields of the requester call block from the copy in the
MRB into the copy buffered in system table area.
Assign LUNa and
Release LUNa call blocks are queued for reprocessing by IOU.
End
of record processing is performed on all other call blocks.
The initial processing of the Redirect Assign LUNa
operation
is
similar
to
that of a Master Write of an Assign LUNa call block.
Selected fields of the call block are
unbuffered
from
the
MRB
into the copy of the call block in system table area.
Additional
processing required for Redirect Assign LUNa is as follows:

1. The LDT that was built by IOU while it
was
processing
the
requester
call
block
must
be
deleted.
IPC
accomplishes
this
by
obtaining
some
table
area,
building
a
call
block
for an )A5 I/O operation, and
queueing it to IOU.
An
)A5
is
a
Release
Luno
in
Another
Job
SVC.
It is documented in the section on
special SVCs.
The call block must look to IOU as if it
has already been processed once by IOU (otherwise,
IOU
will
note
that
the
channel
processes
assigns
and
releases and will give the call
block
back
to
IPC).
IOU
normally converts an )A5 into a )93 (Release Luno)
by changing the subopcode to )93, setting the )A5
flag
(BRFA5)
and
the Already Seen flag (BRFARS) in the BRa
flags, and swapping the JSB and TSB
in
the
)A5
call
block
with
the BROJSB and BROTSB.
IPC must duplicate
all of these actions.
When
IOU
processes
the
call
block, the LDT will be deleted.
2. The pathname in the
MRB
must
be
buffered
into
the
requester
call block in system table area.
IPC does a
Get Table Area SVC, copies the pathname into the
table
area
buffer,
and
changes the pathname pointer in the
requester call block
(IRBPNA)
to
point
to
the
new
pathname.
This pathname specifies the channel to which
the
Assign LUNO is to be redirected.
The field IRBRPN
(redirected resolved pathname), which is a null pointer
for all call blocks that have not been
redirected,
is
set
to
the
previous
value
of
IRBPNA.
Subsequent
2270512-9701

10-91

I/O Subsystem

DNOS System Design Document

redirects of this call block will not alter the
IRBRPN
field.
The
IRBRPN
field
points
to
the
resolved
original pathname.
3. The Already Seen flag (BRFARS)
in
the
BRO
flags
is
reset so that the Assign LUNO call block appears not to
have
been
processed
by
IOU.
The call block is then
queued to Name Manager.
Name Manager
will
queue
the
call
block
to
IOU,
and IOU will build a new LDT for
this Assign LUNO call block.
4. End of record processing is done on the Redirect Assign
LUNO call block.

10.9.4.5

IPC Support Routines.

IPCEOR
IPCEOR performs end of record processing on
requests.
The
BAP
is released and any buffer segments are unreserved.
If
the processing is being done in map 1, IPCEOR calls NFEOR to
perform end of record processing.
If in map 0, IPCEOR calls
IPCOBR to complete the end of record processing.
IPCOBR (in module IPCXFR)
IPCOBR loads the scheduler map file, calls NFEOBR to perform
end of record processing, and then reloads the IPC map file.
IPCCB
IPCCB creates a BAP, which is described in
the
section
on
data
structure pictures.
The BAP describes the data buffer
of an IPC request.
IPCXFR
IPCXFR transfers control between the SVCSHD segment and
the
IPC
code
segment in map 0, both of which must be mapped as
the third segment.
The IPC map file is loaded and IPCXOP is
called.
After IPCXOP returns,
the
original
map
file
is
reloaded and control returns to IPCPRE.
IPCGQR
IPCGQR dequeues
entries from an IPC channel for processing
by IPC opcode processors using the following algorithm:

I/O Subsystem

10-92

2270512-9701

DNOS System Design Document

WHILE there are processable requests on the CCBABQ or CCBPBQ
BEGIN
IF there is an owner request on the CCBABQ
THEN BEGIN
dequeue the owner request.
get the MRBSSI and MRBRCB fields from the call
block in the MRB.
IF there is a requester PRB on the CCBABQ
at the address specified by the MRBSSI and the
BRORCB field equals the MRBRCB field.
THEN BEGIN
dequeue the requester call block from the CCBABQ.
RETURN to the calling task, returning the matched
pair of requests.
END
ELSE do end-of-record processing on the Master Write,
returning a NO MATCHING REQUEST error.
END
ELSE IF the channel is dead (CCFDED is set) and there is
a request on the CCBABQ
THEN dequeue and RETURN the request.
ELSE IF there is a request on the CCBPBQ
THEN BEGIN
IF the request is not from an owner
THEN IF the request does not require a matching
owner request OR IF the channel is dead
THEN dequeue and RETURN the request.
ELSE RETURN no requests (no match is
available since owner requests always
precede requester requests on the
queue)
ELSE BEGIN
dequeue the request
IF the owner request does not require a
matching request
THEN RETURN the request
ELSE IF there is a requester request on
the CCBPBQ
THEN IF the requester request requires a
match
THEN dequeue the requester request
and RETURN both requests.
ELSE BEGIN
requeue the owner request.
RETURN the requester request.
END
ELSE requeue the owner request
END

2270512-9701

10-93

I/O Subsystem

DNOS System Design Document

IPCOPY
IPCOPY is used by the IPC request processing routine to copy
data buffers.
IPCOPY uses the nucleus routines
NFXCPY
and
NFCOPY
to
perform
the
data
transfer.
IPCOPY expects a
source address, a destination address,
and
the
number
of
bytes
to
transfer.
The addresses are either specified as
BAPs (for long distance data transfer) or local addresses.

10.10

NAME MANAGEMENT

The Name Manager task handles synonym and logical
name
segments
for
jobs
running
under DNOS.
It serves SVC requests from user
tasks and supplies support functions to various pieces of the I/O
subsystem and
to
task
management.
The
form
of
the
Name
Management
SVC
block
is shown in the section on data structure
pictures as the NRB.
Each DNOS task operates with a set
of
synonyms
and/or
logical
names
which is known as a stage.
A stage descriptor block (SDB)
is maintained in the synonym and logical name segment to describe
the stage and its relationship with other stages
within
a
job.
Stages
are
maintained in a hierarchical order.
When a daughter
stage is created, it is given a snapshot of its
paient's
names.
This is implemented logically rather than making physical copies.
The
stage
under which a task is executing when it issues an SVC
is known as the current stage of the task.
The Name Manager serves a queue of requests
that
include
userissued
SVCs
for
SVC
opcode )43 and task management entries to
show when a task is bid or terminated.
Also, IOU queues BRBs for
the following I/O SVCs:

I/O Subsystem

10-94

2270512-9701

DNOS System Design Document

Subopcode

90
91
92
94
9S
96
97

98
99
9A
9B

9D
9E
AO
Al
A4

Description
Create File
Assign LUNO
Delete File
Assign Diagnostic Device
Rename Fi Ie
Unprotect File
Write Protect File
Delete Protect File
Verify Pathname
Add Alias
Delete Alias
Create IPC Channel
Delete IPC Channel
At tach Resource
Detach Resource
Modify FDR Bit

Several of the Name Management SVC subopcodes
are
described
in
the
DNOS SVC Reference Manual,
since
they
are useful in userwritten code.
The subopcodes not described in
that
manual
are
described in the section on special SVCs in this manual.
For
IOU
requests,
the
Name Manager resolves logical names and
then places the BRBs on the IOU queue along with
any
applicable
information,
such
as
parameters.
These entries may be placed
back on the Name Manager queue by IOU if a
pathname
for
a
job
temporary file has been autogenerated.

10.10.1

Architecture of

the Name Manager.

The
Name
Manager
consists
of
a
preprocessor
that
works in
conjunction with the SVC request processor to
completely
buffer
the
request,
a
queue
server task, and a special postprocessor
that works in conjunction with the main SVC
unbuffering
routine
to return ipformation into the user's address space.

10.10.2

Data Structures Used by the Name Manager.

Each
name
segment
used
by
Name
Manager
uses
several
data
structures.
Names are
organized
in
stages,
with
each
stage
representing
a
complete
environment
of
names.
Each stage is
described by a Stage Definition Block (SDB), including a
pointer
to
the stage from which it was built, a task count of the number
of tasks using the stage, and a pointer to the
descendent
error
1 i st.
Names
and their values are organized in balanced binary trees of
Name Definition Blocks (NDB).
An NDB has the name,
pointers
to

2270512-9701

10-95

I/O Subsystem

DNOS System Design Document

the
left
and
right
son, a pointer to the lexical
pointer to the parent name, and a
pointer
to
the
block (SVB) list.

successor, a
stage
value

The
SVB
has
flags,
a
stage
number,
a
pointer
to
a value
definition block (VDB) and a pointer to the next SVB.
The
SVBs
are
kept in descending numerical order of stage number.
The VDB
has a value of a name, a count of the number of
SVBs
with
this
value,
and
a
pointer to a value continuation block (VCB).
The
VCB has a value and a pointer to another VCB.
A VCB is used when
a name has concatenated files or parameters
as
values.
Figure
10-14
shows
the
relationship of these various structures for a
segment with three names:
A, B, and C.
Name A is used in
three
stages and has the value .X.Y.FILE.

NDS

+-------+
+-----)1
B
1<-------+
1
+-------+
1
NDS

NDS

+-----+
1
c 1
+-----+

+------+
1

+------+
1
V

SVC

+-----+
1 4
1------+

+-----+
1
V

SVB

1
1

+-----+

1------+
+-----+
1
2

1
V

SVB

1
V

VDB

+-----+
+-+---------+
1 1 1-----)131 X.Y.FILEI
+-----+
+-+---------+
1

Figure 10-14

Name

Segment

Structure

Logical
names which are defined to have parameters make use of a
parameter list
structure
in
the
logical
name
segment.
The
structure is chained to the VCB and is of the following form:

I/O Subsystem

10-96

2270512-9701

DNOS System Design Document

Dec
0

Hex
0

*--------------------+--------------------*
-------I
Lengt h
I
0
I

+--------------------+--------------------+
1
Type for Sublist
I Length of Sublist
I
+--------------------+--------------------+ Required
4
4
I
I
Parameter
Entry Blocks
2+n
2+n
I
I
+--------------------+--------------------+ -------4+n
4+n
I
Type for Sublist
I Length of Sublist
I
+--------------------+--------------------+
6+n
6+n
I
I Optional
Parameter
Entry Blocks
2+n+m 2+n+ml
2

*-----------------------------------------*

The parameter list contains the following:
BYTE

CONTENTS

Length of entire structure; the sum of 1
plus two times the number of sublists.

Zero.

One or more sets of the following fields:
2
Type for sublist. The type of the parameters in
the sublist. Types of parameters are:

o - System parameters
1 - Spooler parameters
2-)7F - Reserved
)80-)FF - User IPC parameters

Length of sublist. The sum of the lengths of all
parameter entry blocks in the sublist, referred
to as n.

4-3+n

Parameter entry blocks, one for each parameter.
Formats of parameter entry blocks are described
in subsequent paragraphs.

Three
formats
are
defined
for parameter entry blocks, one for
each of the parameter sizes.
A parameter
may
be
a
single-bit
binary
value,
a
byte
value, or a value of more than one byte.
Each parameter format includes a parameter number, and one or two
bits that identify the format.
The parameter entry block
format
for a single-bit value is:

2270512-9701

10-97

I/O Subsystem

DNOS System Design Document

*----------------+-+-*
Parameter No.
IIIVI
*----------------+-+-*
The parameter entry block contains the
BIT

foll~wing:

CONTENTS

0-5

Parameter number, 0 through 63. Parameter numbers
need not be assigned or ordered in sequence, but
must be unique within the sublist.

Value,

0 or 1.

The parameter entry block format

for a one-byte parameter is:

*----------------+-+-*
I Parameter No.
10101
+----------------+-+-+
I
Value
I
*--------------------*
The parameter entry block contains the following:
BYTE

CONTENTS

Parameter number byte:
Bits 0-5 - Parameter number, 0 through 63.
Parameter numbers need not be assigned
or ordered in sequence, but must be
unique within the sublist.
Bit 6 - 0
Bit 7 - 0

A numeric value, 0 through 255, or an ASCII
character.

I/O Subsystem

10-98

2270512-9701

DNOS System Design Document

The parameter entry block format

for a multi-byte parameter is:

*----------------+-+-*
I Parameter No.
10111
+----------------+-+-+
I
Parameter Length
I
+--------------------+
I
I
Parameter
Value

*--------------------*
The parameter entry block contains the following:
BYTE

CONTENTS

Parameter number byte:
Bits 0-5 - Parameter number, 0 through 63.
Parameter numbers need not be assigned
or 6rdered in sequence, but must be
unique within the sublist.
Bit 6 - 0
Bit 7 - 1

Parameter length. The number of bytes required
for the parameter value.

2-nn

Parameter value. The numbers or characters of
the parameter.

The
parameter
list
consists
of
one
or
two
sublists.
All
parameters in a sublist are of the same type.
Each parameter
is
identified
by
a
parameter number in the range of 0 through 63.
The parameters in a sublist must have unique
parameter
numbers.
They
may
be numbered in any sequence, skipping numbers, or not,
as required.

10.10.3

Name Manager

SVC Preprocessing.

When a Name Manager SVC is issued, control is passed to
the
SVC
decoding
routine.
This routine buffers the user call block into
STA along with the BRO.
The decoding routine then passes control
to the Name Manager
preprocessor,
with
the
BRB
on
the
Name
Manager queue.
This BRB has the form:

2270512-9701

10-99

I/O Subsystem

DNOS System Design Document

Buffered Request Overhead _
User's call block as follows:
SVC code 43, error code
subopcode , flags
other fields depending on the entry type
Space for extra words of Name Manager information
The
Name
Manager
preprocessor
works
with
the
SVC buffering
routine to buffer call block extensions as needed,
depending
on
the SVC number and subopcode.
It also retrieves (from the user's
JCA)
the
ID
of
the requesting task,. the stage number, and the
name segment SSB address.
It stores these values
in
the
extra
words
of
space
for
Name
Manager
information.
Before an IOU
request reaches the
Name
Manager,
the
IOU
preprocessor
also
gathers
the
stage
number
and the name segment SSB address and
stores them in a three-word block following the standard buffered
I/O request block.

10.10.4

Details of Name Manager Modules.

The Name Manager consists
of
several
processors
and
a
short
section of code that selects one of these processors dep~nding on
the SVC code and the subopcode.
The entries are:
NMMAPN
NMGNPN
NMSETN
NMAPNV
NMDELN
NMFLEX
NMPURG
NMENS
NMRTPS
NMGDEL
NMGSSZ
NMSAVE
NMCTC
NMIOU
NMREST

Determine Name's Value
Determine Next Pathname of Name's Value
Create Logical Name/Assign Synonym
Append Pathname to Present Value of Name
Delete Name
Find Lexical Successor
Purge Names
Enter New Stage
Return to Previous Stage
Get Next Descendent Error List Entry
Get Segment Size
Save Names to a File
Notice of Task Bid or Termination
Pass SVC to IOU after Resolving
Logical Names
Restore Names from a File

A description of each of the entry processors follows.
NMMAPN - Determine Name's Value
For either synonyms or logical names, this operation returns
the value of the name to the requester.
If the Name Manager
finds the name specified, it returns the value string to the
buffer
specified
by
bytes 6 and 7 in the call block.
For
logical names, any parameters defined for the name are
also
returned,
using
the
buffer
to which bytes 8 and 9 of the
I/O Subsystem

10-100

2270512-9701

DNOS System Design Document

call block point.
Byte 10 is set to O.
If the logical name
is assigned to a set
of
files
that
have
been
logically
concatenated,
only
the first file pathname is returned and
byte 11 is set to the value 1.
Otherwise, byte 11 is set to
O.

NMGNPN - Determine Next Pathname of Name's Value
This is used to determine the various pathnames in a set
of
logically concatenated files.
OnlY one pathname is returned
by
this
operation.
This
pathname
corresponds
to
the
pathname number specified in bytes 10 and 11.
(The number 0
returns the first pathname, 1 returns
the
second,
and
so
on.)
In
addition
to
returning a pathname, the processor
also increments this word (bytes 10 and 11) if the
pathname
returned
is
not
the
last one in the list of concatenated
files.
If the pathname
is
the
last
one,
the
processor
returns 0 to bytes 10 and 11.
NMSETN - Create Logical Name/Assign Synonym
This
serves
either of two functions, depending on the flag
set by the user to tell whether
this
is
a
synonym
or
a
logical
name
operation.
If it is a synonym operation, the
Assign Synonym operation is performed, using the name
as
a
synonym
name and giving that name the specified value.
Any
previous value for the synonym
is
replaced
with
the
new
value.
Stage
scope
rules
(described
in paragraphs that
follow) are strictly followed in the
process
of
assigning
the new value to the name.
If
a
logical name operation is indicated, a Create Logical
Name operation is performed.
The specified
name
is
given
its
value
(pathname),
and
any
parameters
specified are
associated with the logical name.
As
with
synonyms,
any
previous
value
for the logical name is replaced, and stage
scope rules are strictly followed.
If the logical
name
is
for
a pathname that is to have its last component filled in
by IOU (unique pathname to be autogenerated), space for
the
pathname
to be supplied is reserved at the end of the value
field within the table entry.
However, the
length
of
the
value
is
recorded
as the length specified by the user and
does not change until IOU notifies the Name Manager
of
the
full pathname.
NMAPNV - Append Pathname to Present Value of Name
This
operation adds to a logical name that represents a set
of logically concatenated files.
The pathname for the first
file and all parameters to be associated
with
the
logical
name
are
specified with the Create Logical Name operation.
Additional pathnames may then be appended, one at a time, by
using this operation.
The additional pathnames
are
stored
separately
in
the
logical name segment to avoid having to
move the previous name definition to a location large enough
to accommodate the
additional
pathnames.
The
additional
2270512-9701

10-101

I/O Subsystem

DNOS System Design Document

pathnames
are
linked
to
the name definition in the order
they are supplied by the user.
NMDELN - Delete Name
Depending on the flag setting, the name is deleted from
the
synonym
table
or
the
logical
name
table.
Any appended
pathnames are also deleted.
If the name represents
a
joblocal
temporary
file,
a
Detach
Resource
operation
is
performed on the
resolved
name.
Stage
scope
rules
are
strictly
followed so that deleting the name does not affect
the definition seen by other stages within the same job.
NMFLEX - Find Lexical Successor
This
routine
searches
the
synonym
or
logical
name
definitions, as specified, for the name (if one exists) that
is
the immediate alphabetic predecessor or successor of the
specified name (pointed to by bytes 4 and 5).
Whether
the
predecessor
or
successor
is found depends on the value of
the word at bytes 10
and
11
(0
indicates
successor,
-1
indicates
predecessor).
If the desired name is found, its
name replaces the specified name (pointed to by bytes 4
and
5) and its value is placed in the buffer pointed to by bytes
6 and 7.
If parameters are associated with the name and the
parameters
buffer
pointer
(bytes
8 and 9) is nonzero and
points
to
a
nonzero-length
buffer,
the
parameters
are
returned
in
the
buffer.
If no name is found to meet the
requirements, a
null
string
(zero
length)
replaces
the
specified
name.
If
the
specified name points to a zerolength string, the
alphabetically
smallest
name
and
its
value
is
returned
if
the
successor
was
requested; the
alphabetically largest name and its value
are
returned
if
the
predecessor
was
requested.
If
the
value
pointer
originally is zero or points to a
zero-length
string,
any
name found is returned as usual, but its corresponding value
is omitted.
The name buffer to which the call block points must be large
enough to hold the maximum results possible, even though the
first
byte
shows
only
the
length
of
the
string
that
currently occupies the buffer.
This routine cannot check to
ensure that the buffer is large enough.
NMPURG - Purge Names
This SVC provides the capability to delete a series of names
that are (in some sense) logically related.
It searches all
names for those that have the first n-l
bytes
exactly
the
same
as
the
first
n-l bytes of the specified name.
Each
time such a name is found, the nth bytes are
compared.
If
the nth byte of the name is greater than or equal to the nth
byte
of
the
specified
name,
the
name found is deleted.
Otherwise, the name is left intact.
The length of the
name
deleted may be greater than or equal to the specified name.

I/O Subsystem

10-102

2270512-9701

DNOS System Design Document

NMENS - Enter New Stage
A new
stage
is
created
with a stage number equal to the
lowest number
not
currently
used
in
the
job,
and
the
requesting task is placed into the new stage.
This involves
allocating an SDB for the new stage, and placing a new stage
number in the TSB of the requestor.
NMRTPS - Return to Previous Stage
This operation returns the task to the stage in which it was
running
previous
to
its
last
Enter New Stage operation.
This operation is valid only when the task is returning to a
stage from which it issued an Enter New Stage SVC.
If
the
task
count
of
the
current stage is greater than one, the
task count is decremented and
the
stage
number
field
is
adjusted
in
the
TSB
of the requesting task.
If the task
count is only one, the current stage must be deleted.
This
requires the following:

Appending
any entries in the current stage's descendant
error list onto the descendant error list of the
parent
stage for the current stage

Searching
the current stage's synonyms for $$CC and, if
it is
found,
building
another
entry
on
parent
the
stage's descendent error list

Deleting all synonyms and logical names that are defined
at the level of the current stage

Delinking and deallocating the current stage's SDB
The
descendent error list is a set of synonyms used for SCI
to pass error information from one stage to its
parent
and
to
allow
a
background task to report error information to
the foreground SCI.
It consists of values for the
synonyms
$$CC, $$ES, $$FN, $$MN, and $$VT.
Whether
or
not
the stage is to be deleted, the requesting
task may also specify a list of synonym names to
be
passed
to
the parent stage.
The names must be placed back-to-back
in a buffer to which bytes 4 and 5 point, with the length of
each name (in bytes) immediately preceding
the
name.
The
length
of
the
entire
list must be specified in the first
byte of the buffer.

NMGDEL - Get Next Descendent Error List Entry
This returns the first entry on the
descendent
error
list
and
then
deletes that entry.
The entry is returned in the

2270512-9701

10-103

I/O Subsystem

DNOS System Design Document

value buffer to which bytes 6 and 7 point
and
consists
of
the
values
that
the
synonyms $$CC, $$ES, $$MN, $$FN t and
$$VT had when the entry was made.
Entries are made
when
a
daughter
stage
that
has
values
defined
for
these five
synonyms terminates.
The values are
returned
back-to-back
in
the buffer.
The first byte of the buffer must be set up
by the requester to indicate the length of the buffer.
Upon
completion of the SVC, the first byte contains the length of
the entry returned (0 if none).
NMGSSZ - Get Segment Size
This
returns
no
error
if
the
otherwise, an error is returned.

job

contains

synonyms;

NMSAVE - Save Names to a File
This physically copies all currently accessible names to the
file whose pathname is specified in bytes 4 and 5.
The file
is
built with only the names that are linked to the SDB for
that stage.
The file can be on any disk.
The
pathname
is
of the same format used to assign LUNOs.
NMCTC - Notice of Task Creation or Termination
Since
the
Name Manager must maintain a task count for each
stage, task management places an entry on the
Name
Manager
queue whenever a task is bid and whenever a task t~rminates.
Task management
does
not
suspend
while
this
entry
is
processed.
A task
inherits
its
stage
number
from
the
creator task.
The initial task of a job gets a stage number
of
zero.
The
call block format for this call is shown as
the
name
request
block
(NRB)
in
the
section
on
data
structure pictures.
It uses a pseudo-subopcode )OC.
NMIOU - Pass SVC to IOU after Resolving Logical Names
All
IOU operations that have an access name as one of their
arguments are queued to the Name Manager to be processed and
passed to IOU.
The Name Manager resolves any logical
names
to their full pathnames and then passes the BRB to IOU.
The
Name Manager allocates STA for the full pathname and for any
associated parameters and modifies the BRB to point to those
structures.
When IOU autogenerates a pathname for a logical
name,
it
places
the BRB back on the Name Manager queue so
that the Name Manager can update the logical name
with
the
full pathname.
NMREST - Restore Names from a File
Names
are
restored to a name segment from the file pointed
to by bytes 4 and 5 of the call block.
The name segment
ID
is
returned in bytes 12 and 13 of the call block.
Only one
stage exists in this segment, stage O.

I/O Subsystem

10-104

2270512-9701

DNOS System Design Document

10.10.5

Stage Scope Rules.

Stage scope rules are used to ensure that each stage has its
own
set
of
synonyms and logical names.
These rules also enable one
stage to make changes to these names without affecting the values
of
these
same
names
for
other
stages.
These
rules
are
circumvented
only
when
executing
a
Return
to Previous Stage
operation with names specified or when executing an
IOU
request
that
involves
autocreation
of
a
file
whose logical name was
previously assigned.
Rule 1
When a previously
undefined
name
is
defined,
the
value
definition
block
is
queued
to
the NDB of the requesting
stage only and is not accessible by other stages.
Rule 2
When a name's value (as seen by
the
requesting
stage)
is
changed, the previous (if any) value definition block in the
chain
of
the
requesting
stage
is
discarded and a value
definition block for the name is built and queued to the SDB
of the requesting stage only and is not accessible by
other
stages.

2270512-9701

10-105/10-106

I/O Subsystem

DNOS System Design Document

SECTION 11
DISK STRUCTURES AND FILE I/O

11. 1

OVERVIEW OF FILE MANAGEMENT

File
management
handles
I/O operations directed to disk files.
Code in the subsystem runs at either task
level
or
XOP
level,
depending on the stage of processing and the particular operation
involved.
As
with other I/O operations, handling begins in the
request processing modules of the
operating
system,
with
some
preliminary
work handled by the general I/O preprocessor IOPREP;
then, action is taken by the file management
code
itself.
The
initial work of file management occurs at the XOP level, with the
JCA of the calling job mapped into the second segment of map file
O.
Processing
proceeds
until
an
SVC (or direct I/O) must be
issued.
At this point, a change is made to the
file
management
task-level code.

STRUCTURE OF A NEW DISK

11 • 2

Before
a
disk can be initialized for use by file management, it
must be checked
for
surface
defects.
This
is
done
by
the
Initialize
Disk
Surface
(IDS)
utility.
Any defective tracks
found by vendor testing must be entered when the IDS
command
is
executed.
The
IDS
utility
does not always find all defective
tracks on a disk.
When
using
the
IDS
utility,
the
user
has
the
option
of
initializing
the
disk
for
DNOS
use
or
leaving
the
disk
uninitialized.
When left uninitialized for DNOS, the
format
of
the disk after running the IDS utility is as follows:
1. Track 0, sector 0 has all zeros except in the word that
shows
the
state
of the disk (SCOSTA).
This word has
the value 2.
2.

Track 0, sector 1 contains a list
of
bad
(defective)
tracks.
The list consists of pairs of words terminated
by
a
word
of
zero.
The
first
word
of each pair
contains the head and
cylinder
number
of
the
first
track
of
a
contiguous
set
of bad tracks.
The head
number is in bits 0 through 4 of the word, and the

2270512-9701

11-1

File

I/O

DNOS System Design Document

cylinder number is in bits 5 through
15.
The
second
word
of
each pair is the number of bad tracks in this
contiguous set.
The disk surface is required to
be
initialized
with
IDS
only
once.
The disk may then be initialized for use by DNOS with the
Initialize New Volume (INV) command
as
often
as
needed.
The
information
about
defective
tracks is preserved when an INV is
done,
but
the
information
can
be
extended
by
specifying
additional defective tracks.
The
INV utility functions only if the disk has a value of 2 or 3
in SCOSTA of track 0, sector O.
The value of 2 is
placed
there
by
the
IDS
utility, and the value of 3 is placed there by INV.
For all other values of SCOSTA, the disk
is
considered
not
to
have the surface initialized.

11.3

DISK DATA STRUCTURES

File
management uses a number of data structures on disk volumes
as well as a number of in-memory data structures to process
disk
I/O
requests.
The
structures
on
disk
include
information
describing the disk and structures describing each
file
on
the
volume.
Each of these structures is described in the section on
data structure pictures.
Under DNOS, all tracks
on
disks
are
initialized
in
physical
records
of
one
sector
per record.
Note that this record is a
disk characteristic and is not the same as
the
physical
record
size specified when files are created.

DNOS
disks
are
logically
divided
into allocatable disk units
(ADUs), an integral number of sectors on the disk; the number
of
sectors
per
ADU varies according to disk size (see Table 11-1).
The number of ADUs is always less than 65,536 (that is, each
ADU
on
the
disk
can be addressed in a 16-bit word).
The number of
sectors per ADU is always
1 or
a
multiple
of
3.
ADUs
are
numbered
from
0,
with the first starting on track 0, sector 0.
Table 11-2 shows the capabilities of available disks.

File I/O

11-2

2270512-9701

DNOS System Design Document

Table 11-1

Forma t

Avail
Space
(MB)

No.
of
ADUs

DSI0
4.7
DS25
22.3
DS31/DS32
2.81
DS50
44.6
DS200
169.5
FDI000
1 .15
CMD 16
13.5
CMD 80
67.3
DS80
62.7
DS300
238.3
WD800-18
18.5
WD800-43
43.2
WD800A-43
42.8
WD800A-100 99.9
WD500
4.75
WD500A
17.0

16320
25840
9744
51616
65381
4004
53196
44330
40819
62045
22311
52059
55744
65034
18560
22208

Disk Type

-----------

---------

No.
of
Bytes
No. of
Sectors Sectors
Heads Cylinders /Track
/Sector
/ADU

------ ------ ----- --------- ------

Table 11-2

Disk
Type

Information for Available Disks

Read
With
Strobing

--------

DSI0
DS25
DS31/DS32
DS50
DS200
FDI000
CMD 16
CMD 80
DS80
DS300
WD800-18
WD800-43
WD500
WD500A
WD800A-43
WD800A-IOO

2270512-9701

NO
YES
NO
YES
YES
NO
YES
YES
YES
YES
YES
YES
NO
NO
YES
YES

2
5
2
5
19
2

408
408
203
815
815
77
806
806
803
803
603
603
871
871
145
694

5
5
19
3
7
3
7
4
3

20
38
24
38
38
26
66
66
61
61
37
37
64
64
32
32

------- ------1
3
1
3
9
1
1
6
6
15
3
3
3
6
1
3

288
288
288
288
288
288
256
256
256
256
256
256
256
256
256
256

Capabilities of Available Disks
Variable
Read
Bad
With
InterTrack
Diagnostic Transfer
Offsets leave
Mapping
Cylinders
Inhibit

------- -------- ---------- -------- ------NO
YES
NO
YES
YES
NO
YES
YES
YES
YES
NO
NO
NO
NO
NO
NO

NO
NO
NO
NO
NO
YES
NO
NO
NO
NO
NO
NO
YES
NO
NO
NO

11-3

NO
NO
NO
NO
NO
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES

YES
YES
NO
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES
YES

NO
NO
NO
NO
NO
NO
NO
NO
YES
YES
NO
NO
NO
NO
YES
YES

File I/O

DNOS System Design Document

All
disks
that
have
been
following physical layout:

initialized

under

DNOS

have

Track 0, sector 0 -- Contains information about the disk
volume,
such
as
the
volume
name and pointers to the
volume directory (VCATALOG).
Template sca describes the
information here.

Track 0, sector 1 -- Contains a list of bad
(physically
imperfect)
areas on the disk.
Each entry is two words:
the first word is the address of the first bad ADU;
the
second
word is the address of the last bad ADD.
A zero
word terminates the list.

The
remainder
of
track
0
contains
information in the form of bit maps.

Track 1, sectors 0 to N-2 -- Optionally reserved for
disk program image loader.

Track
1,
sector O.

Track 1, last sector -- A copy of track 0, sector 1.

Highest
numbered
(innermost)
cylinder
-Diagnostic
information.
This
appears
on
disk
maps as the file
.S$DIAG.

The remaining tracks are available for

11.3.1

Volume

last

sector

disk

the

allocation

-- A copy of

the

track 0,

file allocation.

Information.

The information contained in track
0,
sector
0
of
all
disks
initialized
under DNOS is called volume information.
This block
is detailed in the section on data
structure
pictures
as
SCO,
Sector 0, Track 0.

11.3.2

Allocation Bit Map.

To
keep track of which areas on the disk are allocated and which
are free, the DNOS disk manager maintains a bit map of
allocated
ADUs.
The
bit map is located on track 0 of each disk, starting
at sector 2 and continuing through as many sectors as necessary.
The bit map is divided into 1~8-word
partial
bit
maps
(PBMs).
Each
PBM
is located in a separate sector on track O.
The first
word of each PBM contains the number of the ADU that
begins
the
largest
block of free disk space located in the part of the disk
that is mapped by the PBM.
Each bit in the remaining
127
words
represents
an
ADU.
If a bit is 0, the ADU is free; if a bit is
File I/O

11-4

2270512-9701

DNOS System Design Document

1, the ADU is allocated or bad.
Each
PBM
words of information and maps 2,032 ADUs.

11.4

contains

127

16-bit

FILE STRUCTURES

DNOS
supports
three file types:
relative record files (blocked
and unblocked), sequential files, and
key
indexed
files.
All
file
types are based on the unblocked relative record type, with
extra system overhead need~d
to
implement
sequential
and
key
indexed
files.
Also,
three
special
types of relative record
files are available:
program files, directory files,
and
image
files.
In
the
following
discussion
of
file
types and structures, a
physical record
of
a
file
is
the
amount
of
data
actually
transferred
by
the
operating system during an I/O operation to
the file; a logical record of a file is the amount of information
the user transfers in one (not multiple) Read or Write SVC
call.
The
ratio of the logical record size to the physical record size
is called the blocking factor.

1 1 .4. 1

Relative Record Files.

A relative record file is a file in which all logical records are
of a fixed length and each record can be randomly accessed by its
unique record number.
Relative record
files
may
be
unblocked
(physical
record
size
accommodates only one logical record) or
blocked (physical record size accommodates more than one
logical
record).
1 1 .4. 1 • 1

Unblocked Relative Record Files.

Each logical record of an unblocked relative record file occupies
one
physical
record
of the file.
A physical record may be any
integral multiple of contiguous sectors.
File
accesses
require
reading
or
writing
this number of sectors (reads and writes of
multiple contiguous sectors can
be
accomplished
via
one
disk
access).
Records
read from unblocked relative record files are
transferred directly from the disk to the
user
buffer,
without
intermediate
system
buffering.
When
the
user
specifies
a
particular record of the file, the record number is converted
by
file
management
to
an
absolute ADU number and a sector offset
within the ADU.
The absolute disk address is then passed to
the
disk
DSR
to
perform
the
actual
data transfer.
The disk DSR
converts the ADU and relative sector
to
a
physical
track
and
sector
disk
address
to
communicate
with
the disk controller
hardware.

2270512-9701

11-5

File

I/O

DNOS System Design Document

The diagrams that follow show examples of long unblocked relative
record files and short unblocked relative record
files.
Assume
that
the
disk
in
use
has
9
sectors
per ADU.
In the first
example, the record might span 3 ADUs, perhaps occupying a
total
of
25
sectors.
Thus, 2 sectors are wasted per physical record.
In the second
example,
each
physical
record
might
occupy
2
sectors, wasting 1 sector of each ADU.

Long Unblocked Relative Record File
Record Size > ADU Size

LONG UNBLOCKED RELATIVE RECORD. RECORD SIZE> ADU 51 ZE
RECORD

I
\

ALL DATA

I ,I

ALL DATA

I
I

V
ADU

ADU

ALL DATA

UNUSED

V
ADU

2278129

Unblocked Relative Record File
Record Size < ADU Size

PHYSICAL
,,-_ _....../A\,._ _ _"'"

DATA

~-------------------------------~v~----------------------------------~
ADU
2278486

Note
that
each physical record must begin on a sector boundary.
Also, a physical record that starts in the middle of an
ADU
may
not span the ADU boundary.
11.4.1.2

Blocked Relative Record Files.

Files
of
blocked
relative
unblocked files except
that
File I/O

records
are
treated
the
multiple
logical
records
11-6

same as
may
be

2270512-9701

DNOS System Design Document

stored
in
each
physical
record.
Logical records may not span
physical
records.
Records
are
transferred
via
intermediate
blocking
buffers,
which
are ~urnished from the general pool of
user space by buffer management.
Note that each physical record must begin on
a
sector
boundary
and
that a physical record that starts within an ADU cannot span
theADU boundary.
Also, when physical records are less
than
an
ADU, the number of sectors actually taken up by a physical record
is
the
number
of
sectors
per
ADO
divided
by the number of
physical records per ADU.
In the figure which follows, assume that the disk in
use
has
9
sectors
per ADU.
If a physical record occupies 3 sectors, three
of these physical records would fit into each ADO.
Each physical
record begins on a sector boundary, so there is no
unused
space
at
the end of each ADU, but there may be unused space at the end
of each physical record if the logical
record
size
is
not
an
exact
multiple
of
the
physical record size.
The figure shows
each physical record composed
of
4
logical
records
and
some
unused space.

Blocked Relative Record File

PHYSICAL RECORD 1

PHYSICAL RECORD 2

IREC1IREC2IREC3IREC4~

IREC5IREC6IREC7IREC8~

4 LOGICAL RECORDS
UNUSED

PHYSICAL RECORD 3

IREC9 1Rfg

I Rff IR1Ef

4 LOGICAL RECORDS
UNUSED

\~------------------------------------~v~---------------------------------------JI
ADU

2278485

11•4 •2

Sequential Files.

Sequential files are blocked relative record files with variablelength logical records.
Logical records may span physical record
boundaries
regardless
of ADO boundaries.
When a logical record
spans a physical record
boundary,
it
is
broken
into
partial
records
contained
in
separate
blocks.
The first word of each
physical record
has
two
flags
indicating
whether
the
first
logical
record
is
continued from the preceding physical record
and whether the last logical record is continued in the following
physical record.

2270512-9701

11-7

File I/O

DNOS System Design Document

PHYSICAL RECORD 0

BYTE

1, I

FLAGS

RECORD 0 HEADER

RECORD 0 TRAI LER

RECORD 1 HEADER

LOGICAL RECORD 0 DATA

6
8
A

14
16

LOCICAL RECORD 1 DATA

tc
1E

RECORD 1 TRAI LER

RECORD 2 HEADER (PARTIAL)

RECORD 2 TRAI LER (PARTIAL)

22
24

LOGICAL RECORD 2 DATA

28
2A

PHYSICAL RECORD 1
1

101

FLAGS
4

RECORD 2 HEADER (PARTIAL)

RECORD 2 TRAI LER (PARTI AL)

RECORD 3 HEADER

RECORD 3 TRAI LER

RECORD 4 HEADER

RECORD 4 TRAI LER

LOGICAL RECORD 2 DATA

LOGICAL RECORD 3 DATA

LOGICAL RECORD 4 DATA

0
0

THIS WORD POI N rs BACK ro EOF HEADER
NEXT RECORD STARTS IN NEX r BLOCK

2278132

Figure 11-1

File I/O

Sequential

11-8

File Format

2270512-9701

DNOS System Design Document

When set to 1, flag bits have

~h~

following meanings:

Bit 0 - First logical reco~d in this physical record
continued from the precedin~ record

Bit
1
Last
logical
record in this physical record
continues in the next record

Each logical record or partial record is
preceded
by
a
header
word
and
followed by a trailer word.
The content of the header
and trailer is the number of bytes of data between them.
An endof-file is signified by a zero value header and trailer •. A zero
length
record
is
indicated
by a header and trailer containing
)FFFF.
A special condition exists when a record or last
partial
record
ends
with only one or two words remaining in the physical block.
Since
there
is
not
room
for
another
partial
record
(header/data/trailer),
the
next
record begins in the following
block.
The last word of the current block contains the number in
the last trailer plus the number of unused bytes (two
or
four).
Figure 11-1 shows how a sequential file is arranged.
Logical
records
of
a
sequential
file may be blank-suppressed
(defined as blank-suppressed when created).
In
blank-suppressed
files,
all full words of blanks -are removed.
A blank-suppressed
logical record includes a header word,
a
set
of
data,
and
a
trailer
word.
The set of data includes one or more repetitions
of a
byte
containing
a
count
of
words
of
blanks,
a
byte
containing
a
count
of
words
of
characters
with no words of
blanks, and data characters.
If a logical record has a length of
zero, the physical record shows two words of FFFF.
Figure
11-2
shows a blank-suppressed record.

2270512-9701

11-9

File

I/O

DNOS System Design Document

Input Record:
column: 0
0
1

1
5

FIRST

LAST

Physical Record on File:

*----------------------*
0016
/
/

+----------+-----------+
J
00
J
03
J
+----------+-----------+
J
46
J
49
J
+----------+-----------+
J
52
J
53
J
+----------+-----------+
J
54
J
20
J
+----------+-----------+
J
04
J
02
J
+----------+-----------+
J
4C
J
41
J
+----------+-----------+
J
53
I
54
J
+----------+-----------+
I
05
J
02
I
+----------+-----------+
J
20
J
41
I
+----------+-----------+
J
47
J
45
I
+----------+-----------+
I
18
J
00
I
+----------+-----------+
/
0016
/

*----------------------*
Figure 11-2

11.4.3

2
5

AGE

3
5

4
5

50-80

(columns 33-80 blank)

(counts in diagram in hex,
characters in hex ASCII)
header record
(0 words blanks, 3 words data)

F I
R S
T blank
(4 words blanks, 2 words data)

L A
S T

(5 words blanks, 2 words data)
blank A

G E
(24 words blanks, 0 words data)
trailer record

Blank-Suppressed Record

Key Indexed Files.

Key
indexed
files have variable-length logical records that can
be accessed either
randomly,
by
any
of
up
to
14 keys,
or
sequentially,
in
the
sort order using any key.
On the disk, a
key indexed file with n keys is arranged as follows:

The first 18n+3 (n=number of keys) physical records
are
the
KIF
prelog blocks.
Be fore a record in the file is
modified, it is written into a prelog block
to
prevent
data
loss
case
in
an
error
of
( for example, power
the
failure)
during
data
transfer
case
or
in
the

File I/O

11-10

2270512-9701

DNOS System Design Document

operation
is
parti~lly compfeted when an error occurs.
If an error occurs, ihe loiged blocks are
written
back
into
the
original ·file 'reco~d
when the file is next
opened (in the case of a system
crash)
or
before
the
operation
terminates
(in the case of user errors), and
the file operation may be~~t~ied.

The next
n
physical
records
are
the
roots
of
the
balanced
trees
(B-trees)
that are used to locate each
logical record within the file by
key.
Every
defined
key
has
a
corresponding
B-tree
(up
to 14 B-trees);
therefore, each key indexed file has n B-tree roots.

Following the B-tree root
nodes
are
physical
records
that contain data as well as ·those that contain other Btree nodes.

B-trees are made up of a root node, branch nodes, and leaf nodes.
A root
node
is the first node of the tree.
Leaf nodes contain
pointers to the data records.
Branch nodes are all of the
nodes
between the root and leaf nodes.
A·root node may be a leaf node,
in which case there are no branch nodes.
A DNOS
B-tree has multiple branches per node and all leaf nodes
are at the same level.
DNOS,"B-trees may not exceed nine
levels.
Figure
11-3
shows
a
sample B-tree in which the key values are
single letters.
Each node of a B-tree occupies
one
physical
record
of
a
key
indexed
file,
and
is
called
a
B-tree block (BTB).
Each BTB
contains 18 bytes
of
overhead
and
several
pointer/key
value
entries.
These
entries
are
sorted in increasing order of key
value (smallest key value is the first entry).
If the block is not a leaf entry, each pointer field points to
a
subtree
that
contains
key values less than or equal to the key
value associated with the pointer.
In
fact,
the
highest
key
value
contained
in the subtree is the key value associated with
the pointer (as shown in the sample B-tree).
Further information on general B-tree structure is
available
The Art of Computer Programming, Volume III by Donald Knuth.

2270512-9701

11-11

File I/O

DNOS System Design Document

File I/O

11-12

2270512-9701

DNOS System Design Document

All
of
the data records (logical records) of a key indexed file
are contained in data blocks • . A. data block is a physical
record
of the file and contains 14 bytes of overhead and several logical
records.
The
word following the ~ast logical record has a zero
value.
The structure of a KIF in£ormation block (KIB)
is
shown
in the section on data structure pictures.
Whenever
a
data record is to be-inserted in a data block, it is
assigned an ID that is unique within the block.
The data
record
is then inserted after the last logical record in the block.
11.4.4

Program Files.

In
ad~ition to the three basic file
types, three special uses of
the relative record file
warrant
description:
program
files,
directory files, and image files.
Program
files are unblocked relative record files with a logical
record
size
of
one
sector.
The
sector
size
is
hardware
dependent, with the smallest se~tor size being 256 bytes.
Figure
11-4
shows
the
format
of
a
program
file.
The program file
directory index entry (PFI) and
the
program
file
record
zero
(PFZ)
are
shown
in
detail
in
the
section on data structure
pictures.
The sections
of
information
describing
the
contents
of
the
program
file
do not always start at the beginning of records or
in the same place for all program files.
The following equations
define the record number and the offset
into
the
record
which
defines
the
beginning
of the information.
In the equations, R
designates a record and F designates the offset.
R1
F1

1
0

R1 + {«MAX # TASKS +2)/2)

remainder of {«MAX # TASKS +2)/2)

R2 + {(MAX # TASKS +1)

remainder of {(MAX # TASKS +1)

R3 +{«MAX # PRoes +2)/2)

remainder of

R4 +{(MAX # PRoes +1)

remainder of

R5 +{«MAX # OVLYS +2)/2)

2270512-9701

)10) + F1}

)10 + F2}

{(MAX # PROeS +1)

11-13

)10 + F1}

)100

)10 + F3}

)10 + F4}

)100

)10 + F2} /

{«MAX # PRoes +2)/2)

)100

)10 + F3} /

)100

)10 + F4} /

)10 + F5}

)100

)100
File

I/O

DNOS System Design Document

remainder of { ( (MAX II OVLYS +2)/2)

F7 = R6 +{(MAX II OVLYS +1)

)10 + F6} /

remainder of {(MAX # OVLYS +1)

R7 + {«MAX # HOLES

* 4) "+2)

F8 = remainder of {«MAX # HOLES

)10 + F5} /

)100

)10 + F6} /

)100

+ F7} /)100

* 4)

+2) + F7} / )100

If F8 is not equal to zero, then R8 = R8 + 1
Rl,Fl:
R2,F2:
R3,F3:
R4,F4:
R5,F5:
R6,F6:
R7,F7:
R8:

Record
Record
Record
Record
Record
Record
Record
Record

number
number
number
number
number
number
number
number

and offset for
and offset for
and offset for
and offset for
and offset for
and offset for
and offset for
of first image

names of tasks.
task directory entries.
names of procedures.
procedures directory entries.
names of overlays.
overlay directory entries.
unused space directory.
record.

The first record (record number 0) of a program file contains six
bit maps.
These bit maps, in order of occurrence within
record
0,
are
for memory-resident tasks, memory-resident procedures or
segments, all tasks, all procedures, all
nonreplicatable
tasks,
and all overlays.

o
1
R2:02
R3:03
R4:04
R5:05
R6 :06
R7:07
R8

*-----------------------------------------------------*
OVERHEAD RECORD
I
+-----------------------------------------------------+
I
NAME ENTRIES FOR TASKS
I
+-----------------------------------------------------+
I
DESCRIPTION ENTRIES FOR TASKS
I
+-----------------------------------------------------+
I
NAME ENTRIES FOR PROCEDURES/SEGMENTS
I
+-----------------------------------------------------+
I
DESCRIPTION ENTRIES FOR PROCEDURES/SEGMENTS
I
+-----------------------------------------------------+
I
NAME ENTRIES FOR OVERLAYS
I
+-----------------------------------------------------+
I
DESCRIPTION ENTRIES FOR OVERLAYS
I
+-----------------------------------------------------+
I
AVAILABLE SPACE LIST
I
+-----------------------------------------------------+
I
IMAGE FORMATS FOR TASKS, PROCEDURES AND OVERLAYS
I

*-----------------------------------------------------*
Figure 11-4

Program File Format

When
record
0 is
initialized,
all
bits in the bit map are 0
except the first bit in the tasks, procedures/segments, overlays,
File I/O

11-14

2270512-9701

DNOS System Design Document

and nonreplicatable tasks bit maps (the bit maps occupying
bytes
)54
through
)D3).
The
first bit of these is a 1, restricting
user tasks from allocating ID O.
Each bit map has 16 words, with 16 bits per word; therefore, each
bit map can represent 256 IDs.
A bit set to 1 indicates that the
ID corresponding to the bit position (0 through 255) is
assigned
to
a
task, procedure, or overlay segment installed in the file.
The format of record 0 of
the
program
file
is
shown
in
the
section
on data structure pictures as PFZ, Program File - Record
Zero.
When a program file is created,
the
maximum
number
of
tasks,
procedures/segments,
and overlays to be set into bytes )D4, )D8,
and )DC of record 0 are defined by the
creator
of
the
program
file.
The maximum number of holes, which equals the sum of these
three
values,
is used to calculate the number of bytes required
in the overhead records for the available space list.
This
list
is headed by a word containing the number of entries in the list.
The
rest
of the list consists of two-word entries that describe
the unallocated spaces
(holes)
in
the
image
portion
of
the
program file.
Each entry contains the starting record number and
the
number
of
available
records in each hole.
A hole appears
when an image is deleted.
The hole. is recorded to be used
again
if
a new image that is the same size or smaller than the deleted
one is installed in the file.
Adjacent images, when deleted,
create only one hole.
Figure
11-5
sho~s
the
format
of
the
available space list.

2270512-9701

11-15

File

I/O

DNOS System Design Document

*-----------------------------------------------------*
NUMBER OF ENTRIES
I
+-----------------------------------------------------+--+
I
RECORD NUMBER
I
I
+-----------------------------------------------------+
ENTRY
I
RECORDS AVAILABLE
I
I
+-----------------------------------------------------+--+
I
I

/
I

+-----------------------------------------------------+--+
I
RECORD NUMBER
I
I
+-----------------------------------------------------+
ENTRY
I
RECORDS AVAILABLE
I
I
*-----------------------------------------------------*--+
Figure

11-5

Program File Available Space List

The available space list uses the entire record, not 256 bytes of
it
as
the
other
overhead
records do.
Therefore, if the list
spans records, an entry is split across two records.
(The
first
word
of the entry is the last word of one record, and the second
word of the entry is the first word of
the
next
record.)
The
available
space list is initialized at the same time record a is
initialized.
Its values are as follows:

*--------------------------*
1
+--------------------------+
I
R8
I
+--------------------------+
I
)FFFF-R8
I
*--------------------------*
R8 is the record number of
the available space list.

ONE HOLE
BEGINS AT RECORD 8
IS )FFFF -

the first

R8 RECORDS LONG

record following

The maximum number of records permitted in a
program
is
)FFFF.
Thus,
the maximum number of image records permitted in a program
file is )FFFF minus the number of overhead records.
The actual image of a task, procedure, or overlay must start on a
record boundary in the
program
file.
If
the
segment
has
a
relocation
bit
map,
the map begins at the first word folloWing
the program segment image.
However, any part of a
program
file
can
be
split
across secondary allocations.
The relocation bit
map begins at the first word following the program segment image.
The length of the relocation bit map is the length of the program
segment image, in bytes, divided by eight and rounded to
a
word
boundary

File

I/O

11-16

2270512-9701

DNOS System Design Document

The
task,
procedure/segment,
and
overlay
name entries in the
program file contain the names oj ~ll tasks, procedures/segments,
and overlays installed in the program
file.
A name
entry
is
eight
bytes
long, blank-filled to the right.
The name entry is
placed in the name block positio~
that
corresponds
to
the
ID
assigned to that segment.
For example, if task GENTX is assigned
ID
1,
the
name
GENTX is entered in bytes 8 through 15 (second
position) of the name entries block for tasks.
The task, procedure/segment, and overlay description
entries
in
the program file contain information about all segments installed
in
the
program
file as well as pointers to the segment images.
Each description is 16 bytes long.
The figures that follow
show
the
formats
of the program file description entries, with field
descriptions following each format.
Figure 11-6 shows the format
of the task description;
Figure
11-7
shows
the
format
of
a
procedure/segment
description;
and Figure 11-8 shows the format
of an overlay description.

Hex.
Byte

)00
)02
)04
)06
)08
)OA
)OC
)OE
)10

*-----------------------------------------------------*
LENGTH OF TASK SEGMENT
+-----------------------------------------------------+
I
FLAGS
I
+-----------------------------------------------------+
I
RECORD NUMBER
I
+-----------------------------------------------------+
I
DATE INSTALLED
I
+-----------------------------------------------------+
I
LOAD ADDRESS
I
+--------------------------+--------------------------+
I
OVERLAY LINK
I PRIORITY OF THE TASK
I
+--------------------------+--------------------------+
I
PROCEDURE 1 ID
I
PROCEDURE 2 ID
I
+--------------------------+--------------------------+
I
TASK LENGTH
I
*-----------------------------------------------------*
maximum size
Figure 11-6

2270512-9701

Task Description Entry

11-17

File

I/O

DNOS System Design Document

Hex.
Byte

Description of

Selected Fields

)00

Length of task segment in bytes.
Length of task root
plus length of the task's longest overlay path.

)02

Flags, as follows:
Bit

o
1
2
3
4
5
6

7
8
9
10
11
12
13
14
15

)04

)06

Meaning When Set
Privileged
System
Memory resident
Delete protected
Replicatable
Procedure 1 is on the system program file
Procedure 2 is on the system program file
Directory entry in use
Overflow
Writable control store (WCS)
Execute protected
Software privileged
Updatable
Reusable
Copyable
Security bypass

Record number.
Logical record number of
of the task ima~e in the program file.
Date installed, i~ the following format:
Bit

0-6
7-15

the start

Meaning
Year (displacement)
Julian date

)08

Load address.
Relative starting address within a
mapped task segment.
Must be on a beet boundary.

)OA

Overlay link.
The ID of the most recently installed
overlay associated with the task~
Each overlay entry is
in turn linked to the next entry so that tasks can be
associated with their overlays when status or delete
commands are executed.
A value of 0 is used to
terminate the list.

)OE

Task length.
Last defined task code.
If a BSS is the
last instruction in the task, its length is not included
in the value.

File I/O

11-18

2270512-9701

DNOS System Design Document

Hex.
Byte

)00
)02
)04

)06
)08
)OA

*-----------------------------------------------------*
I
LENGTH OF PROCEDURE/SEGMENT (BYTES)
I
+-----------------------------------------------------+
1
FLAGS
1
+-----------------------------------------------------+
I
RECORD NUMBER
I
+------------------------~----------------------------+
I

DATE INSTALLED

+---------------------~-------------------------------+
I

LOAD ADDRESS

+-----------------------------------------------------+
I
I
UNUSED (=0)

)10

*-----------------------------------------------------*
* maximum size
Figure 11-7

Procedure/S~gment

Description Entry

Hex.
Byte

)02

Description of Selected Fields

Flags, as

follows:

Bit

o
1

2
3
4
5
6
7
8
9

10
11
12
13
14
15

)04

Meaning When Set
Unused (set to zero)
System (segment only)
Memory resident
Delete protected
Replicatab1e (segment only)
Share protected
Unused (set to zero)
Directory entry in use
Unused (set to zero)
Writable-control store(WCS)
Execute protected
Write protected
Updatab1e (segment only)
Reusable (segment only)
Copyab1e (segment only)
Unused (set to zero)

Record number.

2270512-9701

Logical record number of

11-19

the start

File

I/O

DNOS System Design Document

of the procedure image in the program file.

)06

Date

install~d,

in the following

Bit

Meaning

0-6
7-15
)08
Hex.
Byte

format:

-----------------Year (displacement)
Julian date

Load address.
Relative starting address within a
mapped procedure segment.
Must be on a beet boundary.

)OC

*-----------------------------------------------------*
LENGTH OF OVERLAY SEGMENT (BYTES)
I
+-----------------------------------------------------+
I
FLAGS
I
+-----------------------------------------------------+
I
RECORD NUMBER
I
+-----------------------------------------------------+
I
DATE INSTALLED
I
+-----------------------------------------------------+
I
LOAD ADDRESS
I
+--------------------------+--------------------------+
I
LINK TO NEXT OVERLAY
I
ID OF ASSOCIATED TASK
I
+--------------------------+--------------------------+
I
UNUSED (=O)

)10

*-----------------------------------------------------*
* maximum size

)00

)02
)04

)06
)08
)OA

Figure 11-8

Hex.
Byte

)02

Description of Selected Fields
Flags,

as follows:
Meaning When Set

Bit

o
1-2
3

4-6
7
8-15

)04
File I/O

Overlay Description Entry

Relocation bit map is present
Unused (set to zero)
Delete protected
Unused (set to ~ero)
Directory entry in use
Unused (set to zero)

Record number.

Logical

11-20

record number of

the starting

2270512-9701

DNOS System Design Document

address of the overlay image

)06

Date installed,
Bit

0-6
7-15

)08

in the following

format:

Meaning
Year (displacement)
Julian date

Load address.
Relative
mapped overlay segment.

11.4.5

in the program file.

starting address within a
Must be on a beet boundary.

Directory Files.

Directory files are unblocked relative record
files
and
have
a
record
length
of
)86
or .)100
characters.
Record
0 of the
directory file contains an overhead record.
The remaining records
in the file may contain one of the following types of data blocks:

File Descriptor Record (FDR) -- Every file
cataloged
in
the
directory
is represented by an FDR, which describes
the file and its locatibn on the disk.

Alias Descriptor Record (ADR) -- Every alias
of
a
file
cataloged
in
the
directory
is
represented by an ADR,
which gives the location of the file and
points
to
the
FDR of the actual file.

Channel Descriptor Record (CDR) -- Every channel that has
an
owner
task
in
a
program
file in the directory is
represented
by
a
CDR,
which
describes ·the
channel
characteristics and identifies its owner task.

Key
Descriptor
Record
(KDR)
Each key indexed file
cataloged in the directory
is
represented
by
an
FDR,
which in turn points to another record, the KDR.
The KDR
describes all of the keys (1 through 14) that are defined
for
the file.
Note that the use of the KDR implies that
each key indexed file cataloged in a directory
uses
two
directory entries.

Figure
11-9
shows
the
general
structure
of a directory file.
Entries are made by hashing the name of the
file
being
entered.
The
hash
algorithm
results in a record number from 1 through n,
where n is the last record in the directory
file.
Figure
11-10
shows the hash algorithm.
If the directory file record is unused,
an
FDR
for the file being inserted is placed in that record.
If
the record is already used, a free record is
found
by
a
linear
search from the hashed record.

2270512-9701

11-21

File

I/O

DNOS System Design Document

Re co rd No.

o
1

*---------------------------*
I
OVERHEAD RECORD
I
+---------------------------+
I
I
+---------------------------+
I
I
+---------------------------+
+---------------------------+
I
I
*---------------------------*
Figure 11-9

\
I
I

DIRECTORY ENTRIES

I
I

Directory File Structure

PROCEDURE HASH (N : number of records in directory minus
NAME : name of the file being entered)
BEGIN
KEY : = 1;
I
: = 1;
C
:= NAME[I];
WHILE C <> ' , AND I < 9 DO
BEGIN
KEY := «KEY * C) MOD N) + 1;
I := I + 1;
C : = N AM E [ I ] ;
END
END
Figure 11-10

Computing a Hash Key

If
the
file
being
inserted
is
a
key
indexed
file, another
directory record must be found to contain the KDR.
This record is
found by searching linearly from the FDR for the file.
The KDR is
inserted into the first available directory record
following
the
FDR.
The
different
types
following paragraphs.

directory

The directory overhead record
directories, contains:

*
*

records are described in the

(DOR), which

record

all

The maximum number of records (entries) in the directory
The number of currently defined f~les

File I/O

11-22

2270512-9701

DNOS System Design Document

*
*

The number of available

rec~rds

(entries)

The file name of the directory

number of the directory in the disk hierarchy
The
level
(VCATALOG) is level 0)

*
*

The file name of the parent directory
The default physical record length

Each file cataloged under the directory is represented by an FDR.
Files can be given other names, each name being a separate
alias.
Each alias is hashed to find an entry in the directory just like a
file
name,
and an ADR is inserted in that entry.
The ADR points
to the actual file.
It also points to
the
next
alias
for
the
file.
Figure
11-11
shows
a
dump
of the directory file .JB.DIR.
The
directory contains a sequential file (.JB.DIR.SEQ), an image
file
(.JB.DIR.IMAG),
a
program file (.JB.DIR.PROG), and a key indexed
file (.JF.DIR.KIF).
The directory also contains an alias for
the
key indexed file.
The directory was created to have 11 entries in
addition to record 0 which is the DOR.

11.4.6

Image Files.

Image
files
are
contiguous
nonexpandable,
unblocked
relative
record files that contain memory images of programs.
They are not
organized in any format; that is, each sector of the
image
file,
starting
with
the
first sector, is completely filled with data.
There are no overhead records or words.
Image files are
designed
so
that
a program image can be read into memory in a single disk
access.

11.5

ALLOCATION OF SPACE FOR EXPANDABLE FILES

When a file
must
be
expanded,
the
amount
allocated
for
the
expansion
depends on how much space is needed and where the space
is
available
on
the
disk.
If
there
is
a
space
available
contiguous
with
the
last
allocation of the file, that space is
allocated for the expansion.
In this case, the
amount
of
space
allocated
may be less than that asked for by the file definition.
If space
is
not
available
contiguous
with
the
current
file
allocation,
one
of
two
secondary
allocations
is
made.
If a
contiguous block is available with the size requested, that
block
is
allocated.
Otherwise, the largest available contiguous block
of space is allocated as the secondary allocation.
2270512-9701

11-23

File I/O

DNOS System Design Document

The amount of space asked for initially is the larger of
SAS

USA)

and
TIMTBL(UEXT) converted to ADUs
where:
is the defined secondary allocation size in ADUs
is the number of noncontiguous secondary allocations
(ranging from 0 through 16)
UEXT
is the number of file extensions, ranging from 0 through
15, initialized to USA when a LUND is assigned
TIMTBL(O)
is
1 physical record
TIMTBL(I)
is
2 physical records
TIMTBL(2)
is
4 physical records
TIMTBL(3)
is
8 physical records
TIMTBL(4)
is 12 physical records
TIMTBL(5)
is 16 physical records
TIMTBL(6)
is 20 physical records
TIMTBL(7) through TIMTBL(15) are 24 physical records
SAS

USA

Each type of file can have secondary allocations.
An image
program file can also have a secondary allocation.

File I/O

11-24

2270512-9701

DNOS System Design Document

FILE ACCESS NAME: .JB.DIR
F:EC OF:D:

(11)01)(")

OOOB (u)04 1)(105 0000 444';- 5220 :20F! 2(,20

')(H)i)

on 1I)

ilt)!).:

:;AME

(IOFE

4A4 2 i02 i) 2020 2020 O:?,I)(.' 0000

[11

,_'B

O(l(l(i

1)(li)(1

HECORD:

OI)(Jl)Ol

0000 0002

0(~1

5345 5120

202(~

2020

Sf C'

({IOO O(Il)O

2289 1)001 O(I(ln ()(/()]
;)1:'20 0000 0000 0000 0000 (1000 O(h)O i~IMH~) liH~li)
0(1::::(· i)({H) 0000 1)000 (17Be 020:: 095B 07B(: 0203
(li)40 0'7'5B 01(11 (1(100 (/(lOO (t(/(h) (10(10 (1000 0000
SAME
(1090 4A4F 594:;: 4520 202(! ')000 0000 ,)00(1 000(1

,JO Y·C E

0(;00
RECOF:[t: 000002
(1(1()(i 0000 0001 494[1 4147 2(120 2020 0000 0000
(1010 C420 (.i 120 (1120 0022 3952 0001 ()(;OO (H) (I!)

....

O(l1(!

I)AOO (361) (1)51) O(Ji) 1

SAME

i)OFE

SAME

0036 (l7BC 0203 09[16 07Be 0203 09[16 010:; 0000

.:.~

(11)90

,JO

YC E

'~;AME

4A4F 5943 4ti2(J 2020

SAME
(I0FE (1(I(;el

({IOI)

0000 0000 0000

RECORD: 00000.3
0000 00(11 000:3 414(: 4941 5:320 2020 (10(10 000(1

Alj
H

..'

AL IA

001(1 !)A 10 0000 0000 0000 0000 (1)00 0000 0000
0020 (10(11 1)000 000(1 (if)O!) (iI)')(l 0000 1)i)O(l 0000

r
"

SAME

(lOFE

()(II"j(.

RECORD: 1)(Jn(lil4
(1000 1)t:IO(t 0000 0000

SAME
OOFE 1.I!JiJt)

(H)(Il)

0000 OOCH) O(li)(l (tOOO

RECORD: 000005
(1000 0000 0000 0000 0000 0000 0000 0000 O!)(IO

SAME

(I(IFE

0000

RECORD: 0(i0006
0000 0000 (1t)(l0 0000 0000 0000 (11)(11) 0000 0000

SAME

(I0FE (1000
RECORD: 000007
(10(10 0001 0007
(011) :3C20 0120
0020 0000 (104A
(1030 0000 0000
0040 OBF!;' 010:3

SAME

5(152 4F47 2020
0120 001 D 3B2A
OOO() (I04A 0000
0000 07B(: 020:3
0000 0000 0000

2(21) 0000 0000

•• FR 013

0001 0000 00(11)
0000 0000 0000
OBFC 07BC 0203
0000 0000 0000

(1090 4A4F 5943 4520 2020 0000 (1000 0000 (1000

SAME
(lOFE 00(11)

• .J

• ,J

(

.'.

,JO YC E

RECORD: 000008
(1000 (i(II)(! 1)(100 0000 0000 0000 0000 1)000 0000

SAME
OOFE 0000

RECORD: 000009
(1000 (1001 0(;09 4B45 5946 494C
0010 lEO:3 00140 (h)50 OOBO 72B9
0020 0000 0000 (III/XI 0016 0001
0030 0011:. 01F7 t~I(~H~)A 07BC 020:3
U!)40 (ten (ito.? .)(H)A (H)(I(! (h)Ot)
SAME
(li)'iO 4A4F 594:3 4520 2020 (lI)(H)
:3AME

KE YF IL E

4520 000(1 0000

0022 0000

.P .0 rot "

1)1)1)1)

0000 0016 0015
Oe23 (i7BC 0203
0009 0000 0000

000(1 0000 (1000

,JO YC E

OOFE 0000
HECOF:D: OOOOOA
0000 0000 FFFD () 1F4 0001 (,BOA 0000 0000 0000
SAME
(I0FE 0000

Figure 11-11

2270512-9701

Dump of Directory File

11- 25

File

I/O

DNOS System

11 .6

D~sign

Document

IN-MEMORY DATA STRUCTURES

The
primary
data
structure
used
by file management during its
execution is a record of the state of the request being processed,
the File Manager work area (FWA).
With
each
FM
request,
extra
storage
is
allocated
for
the
FWA when the IRB is processed by
FMPREP.
The
extra
storage
is
required
for
the
following
information:

*
*

A workspace for execution
Information
about
the
request including block numbers,
offsets, several fields of the FeB needed when the FCB is
not available",
a
description
of
the
user
buffer,
a
description
of
the blocking buffer, and vectors used to
terminate processing at XOP level and reactivate at
task
level
A stack in which called routines save registers

The
part of the buffered request allocated for working storage is
pointed to by register 15 (RI5), except in FMPREP and FMTASK,
and
is
addressed
with
the template FWA.
The FWA is detailed in the
section on data structure pictures, as
are
the
other
-in-memory
structures.
Other
in-memory
following:

structures

used

by file management include the

File
Control
Block
(FCB)
In-memory
structure
representing
the last component of a file pathname, used
to access the file for direct
disk
I/O
in
conjunction
with the file directory block

File Directory Block (FDB)
directory
tree
structure
table area.
Provides tree
to perform direct disk I/O

File Descriptor
Packet
(FDP)
A two-word
structure that is used to access an FCB

Logical
Device
Table
(LDT) - A description of the file
resource, including usage flags,
ownership
information,
parameters, and a pointer to the relevant FDP

Resource
Privilege
Block
(RPB)
A structure used to
control access privileges for resources

- Single node of the in-memory
located in the file management
linkage and information needed
to the file

Figure 11-12 shows the
location
and
relationships
various file structures maintained in memory in DNOS.

File I/O

11-26

in-memory

between

the

2270512-9701

DNOS System Design Document

File Management Table Area
+---------~--------------------+

I
FDB
I +--------+
I IVCATALOGI<----------------I
I I
I
I
FDB
FDB
I
I +--------+
+---+
+---+
I
I
I
---)Iforl---)Ifor --I
I
I
I
---------1 A 1<---1 B I
FDB
+---+
+---+
I
I +---+
I
I
I--)Iforl<-------I
I
I I I C I
I
I
I I +---+
I +-----------------------1------+
I I
I
I
I I
I
I
I I
I
I
I
I +----------------------+1
I I I
FCB
II
I
+-1---+-------+ +------+-+
I
I
I
for
I
I
for II
I
I
I
.B
II
I
I
I .A.C
.+-------+ +------+1
I
I
+------------------1---+-------+

+-----------------------I
I
Segment Manager

Table Area
I
I +-------------------------------+
I
I I
SGB
SSB
SSB
I
+---+
+---+ I
I
I I +---+
---)1
1---)1
1---···---)1
I I
I
+---+
+---+ I
I
I +---+
I
I
I
I
I
SGB
SSB
SSB
I
+---+
+---+ I
I
I +---+
--------)1
1---)1
1---···---)1
I I
+---+
+---+ I
I +---+

+--------------------------------+

Figure 11-12

In-Memory File Representation

File management routines fall

into the following categories:

*
*

XOP-Ievel preprocessing

Address
space
management,
including
transfers between
XOP-Ievel and
task-level
code
and
the
management
of
overlays

Task-level preprocessing

2270512-9701

11-27

File I/O

DNOS System Design Document

*
*

Buffer management

Low-level
processing

Routines

to perform file
routines

I/O operations

that

support

(IODRCT)

I/O

SVC

sub-opcode

File management code resides in four different areas.
Some
code
is
found
in
the map 0 segment SVCSHD with other SVC processors,
some is in the variable part of the operating system root, some is
in the file management task segment, and some is found in overlays
on disk.
Table 11-3 shows the major modules found in
the
file
management
source
directory and where they fit into the six major categories
of routines.
In
addition
to
those
listed,
modules
of
stub
routines
are
included
for
those
systems
that
do not support
particular file management options.
The names
of
these
modules
include
an
S after
the
functional
module
name (for example,
FMBKOFS is the stub for
FMBKOF).
Stubs
are
found
in
modules
FMBKOFS,
FMCKEXS,
FMFBSQS,
FMOPSXS,
FMRDBFS, FMRDUBS, FMRWSQS,
FMSQORS, FMWRBFS, FMWRUBS, and
KMBEGS.
The
last
stub
is
for
systems that do not support KIF.
Table 11-3

File Management Modules

XOP-Level Preprocessing
FMACTV
Driver for opcode processors
FMPREP
XOP-Ievel preprocessing - base routine
Task-Level Preprocessing
FMTASK
Task-level driver
Address and Overlay Ma na geme nt
FMOVLO
Overlay header tables, one for each overlay
Overlay header tables, one for each overlay
FMOVL1
FMOVL2
Overlay header tables, one for each overlay
Overlay header tables, one for each ove rIa y
FMOVL3
memory-resident
FMOVLYC
Overlay code location tables
systems
Overlay code location tables - disk-resident
FMOVLYD
systems
Set of overlay pool management routines
FMPMGR
Transfer at XOP level between SVCSHD and FMTASK
FMTRAN
Buffer Management
FMBIO
Set of routines to buffer I/O and map blocked
files
Copy buffer - blocked file
FMCPB
Interface routine for FMCPB
FMCPBI

File I/O

11-28

2270512-9701

DNOS System Design Document

Table 11-3

File

Manag~ment

Modules (Continued)

I/O SVC Sub-opcode Processors
FMCLEF
Close with EOF processor
FMCLOS
Close operation processor
FMFBSP
Forward Space/Backspace operation processor
FMFBSQ
Forward Space/Backspace processor for
sequential files
FMOPEN
Open operation processor
FMOPRW
Open Rewind operation processor
FMOPSX
Open Extend sequential file operation processor
FMOPUB
Unblocked Open operation processor
FMOPXT
Open Extend operation processor
FMRDF
Read operation processor
FMRDUF
Read Unblocked operation processor
FMRWF
Rewrite operation processor
FMSQOR
Open Rewind for sequential files
Unlock operation processor
FMLKUL
FMWEOF
Write with EOF operation processor
FMWTF
Write operation processor
FMWTUF
Write Unblocked operation processor
Lower Level Support Routines
FMBKAD
File extension
FMBKOF
Block number computation
FMBLAJ
Blank adjustment
FMBSRT
Blank suppression routines
FMCKEX
Check file extension
File extension
FMEXFL
FMMREC
Compute ADU and sector from block number
FMFIO
Unblocked relative record I/O interface to FMIO
FMIO
Read/write file block
FMLKNF
Lock operation processor; set of routines to
check for locks; add them, and remove them
FMLSET
Creates LUNO for FMBIO on first buffer I/O
of each FM task
FMRDBR
Read blocked relative record files
FMRDSQ
Read sequential file
Read file status
FMRDST
FMRDUB
Unblocked read of blocked files
Rewrite blank compressed counter
FMRWBC
Rewrite sequential file
FMRWSQ
Update FDR
FMUPFD
Set of routines to check EOM; set
FMUTLY
parameters, and find structures
FMWTBR
Write blocked relative record file
FMWTCK
Check write privileges on a file
FMWTSQ
Write sequential files
Unblocked write of a blocked file
FMWTUB

2270512-9701

11-29

File I/O

DNOS System Design Document

To
avoid
the
extra overhead required for preprocessing SVCs and
I/O calls, a special interface to I/O, FMIO, is
used
to
perform
file
reads
and
writes.
This same interface is used by the task
loader to perform reads and writes to the swap file,
and
by
IOU
and
the
File Manager to update FDR records.
The calling program
obtains a block of STA sufficient to
buffer
the
disk
I/O
call
block and initializes it as follows:
BROOFL
SMT address for segment containing buffer
BROBBA
SSB address for segment containing buffer
BROLDT = PDT address for device desired
BRORCB
0
(supplied by IODRCT)
BROTSB
EXTSB
BROJSB = EXJSB
BROBRO = 0
IRBSOC = 0
SVC opcode/error code
IRBOC
= 09/0B subopcode/O (no LUNO)
IRBSFL
0
system/user flags = 0
IRBDBA = offset into buffer segment
IRBICC = character count
IRBOCC = character count
IRBRNI
ADU of disk device to be read/written
IRBRN2
sector in ADU to be read/written
The
call block built is passed to the direct I/O routine; IODRCT.
It then proceeds
like
an
I/O
SVC,
but
the
overhead
of
SVC
processing has been avoided.
11.6.1

XOP-Level Preprocessing.

FMPREP initiates XOP-Ievel preprocessing for the File Manager, and
resides in SVCSHD.
It takes the I/O call block buffered by IOPREP
and
creates the FWA needed by the File Manager to execute at XOPlevel.

The routines in FMTRAN (File Manager task call, FMTCAL,
and
File
Manager
task return, FMTRTN) change map file 0 to map in the File
Manager task segment so that it can execute at
XOP
level.
When
XOP-Ievel
work
completes, control is transferred back to FMPREP;
consequently, the map file must be changed to its previous
state.
Some requests can complete execution at XOP level without changing
to
task-level
code.
The
follOWing
conditions must be met for
execution of a file management request to complete at
XOP
level;
such execution is referred to as fast transfer.

If
the
operation is active (such as write, rewrite), no
other operations are outstanding
for
the
FCB;
if
the
operation
is passive (such as read), no active operation
is outstanding for the same FCB.

No requests are outstanding for the LUNO
initiate I/O count must be zero).

File I/O

11-30

(that

is,

the

2270512-9701

DNOS System Design Document

The
overlay area is available when the opcode requires a
system overlay.

If the operation is Read or Write,
file.

*
*

The LDT does not have the unblocked I/O flag set.
If
the
forced.

request
is
a
write bit set.

Write,

the file is a

blocked

the LDT does not have

the

The required blocks are in memory.

A file management request begins execution at
XOP
level.
If
a
transfer
to
task-level code is required, the routine FMTSET from
module FMUTLY is called.
Such
conditions
can
be
detected
at
several
points,
both
in
FMACTV and in the operation processor.
The following processing occurs at the level indicated:
1.

(XOP) IOPREP sets the bu~y flag
in
the
IRB
prior
to
calling
FMPREP.
FMPREP passes control to FMACTV, which
can call FMTSET to enter task mode.
Other routines
may
also call FMTSET.

(XOP) FMPREP sets up the vector in FWAXWP (in
the
FMT)
such that a BLWP instruction transfers control to FMTRTN
(in FMUTLY).

3. (XOP) FMTSET checks to see if execution
is
already
in
task mode.
If so, it exits.
If not, it executes a BLWP
instruction
through
FWAXWP (RI5).
The only purpose of
the error is to
enable
the
caller
to
determine
the
previous execution mode.
4.

(XOP) The BLWP
executed
by
FMTSET
takes
control
to
FMTRTN,
which changes the map 0 file back to SVCSHD and
branches into FMPREP at label FMFXRT, which
checks
the
busy flag in the IRB.
If the flag is clear, the request
is
complete
and the call block is directly unbuffered.
Initiate event flags are checked; if
one
is
set,
the
event
is
marked
in
the
TSB
as
completed.
Upon
completion of the
unbuffering,
FMFXRT
returns
via
a
branch to NFTRTN.

(XOP) If the request is not complete, the value
in
R14
from the BLWP is stored in FWAPC (in the FWA).
The busy
flag is still set, causing FMPREP to queue the operation
for
task-level
file management and exit through IORTN.
The busy flag causes IORTN to suspend the
calling
task
(if this is not initiate I/O) and exit to the scheduler.

(TASK) Eventually, either the scheduler chooses
a
management task for execution (starting at FMTASK),

2270512-9701

11-31

file
or a
File

I/O

DNOS System Design Document

file
management
task already in execution dequeues the
operation.
If a buffer is required, the segment of
the
user
program containing the buffer is also loaded.
The
JCA is mapped in.
7.

(TASK) FMTASK puts the contents of FWAPC into
its
R14,
computes
the WP address in R13, and puts its own status
in RIS.
The FWAXWP and FWAXPC vector is set up to point
to FMP210 in FMTASK.
An RTWP is executed, thus resuming
the activity in FMTSET immediately
following
the
BLWP
that
transferred
control
to
FMTRTN.
FMTSET sets no
error and exits.

11.6.2

Task-Level Processing.

FMTASK is the driver routine that processes the start-up procedure
and handles the processing between requests at task level.
FMTASK
is activated by the operating system queue server mechanism.
When
a file management task begins, the STA is mapped
into
the
first
segment,
the
user
job JCA into the second segment, and the file
management code into the third segment.
FMTASK uses
a
workspace
and
stack that is allocated the first time the task is bid.
That
workspace is associated with the task, not with a BRB, and is used
for
the
dequeuing
and
queuing
calls
and
for
acquiring
the
execution
environment
needed
by the activity.
FMTASK transfers
execution to the point of suspension in
XOP-level
processing
by
activating the workspace in the BRB via an RTWP instruction.
File
management
overlays are read into and executed in a pool of
overlay areas allocated with the file management task segment.
A
set
of
subroutines
is used to transfer control between the file
management root and an overlay.
11.6.3

Flow of Control in File Management.

Figure 11-13 shows the flow of control through the
various
parts
of
the
file
management
processor and how a request is handled.
Each
transition
in
the
figure
is
numbered.
These
numbered
transitions are described in the list that follows.

File I/O

11-32

2270512-9701

DNOS System Design Document

+--------+
1
+-------------+
2
+--------+
I IOPREP 1-----) I
FMPREP
1------------------) I FMTCAL I
+--------+
I
I
+--------+
I
I
I 3
I
I
V
I
I
+--------+
6 +--------+
I
I
I FMTSET 1<----1 FMACTV 1<---+
I
I
+--------+<-+ +--------+
I
J
I
I
* 4
I
/
\
I
V
I
*
10
YES I
/
OP
\
1 9 +--------+
17
V
+---------
@SOVLTO

LI
LI
BL
DATA

TO ENTER DMRTN2
R9,DMOV37+)800
area
R8,
@SOVLTO
.ERRFIL

*
*
*
*
*
*
*

RSET(LUNO) -

for

reading

Open a sequential file for writing

CLOS(LUNO) -

Close a sequential file

MEOF(LUNO) -

Detect end-of-file

BKSPAC(LUNO) RWSEQ(LUNO) -

to the user or batch listing file

Open a sequential file

REWRIT(LUNO) -

Backspace
Read/write

the LUNO
buffer TXT

ENCOD(STR,LOC,X,P,B) - Write X into field STR,
at LOC in base B, with P digits of precision.

starting

DECODE(STR,LOC,STAT,VALUE)
Read
number
VALUE
from
the,
field STR, starting at the
location
LOC,
putting
status of the operation in STAT.

The
string
manipulation
utilities
add
strings
to the output
buffer TXT.
They all use the common variable BC to point to
the
location at which the insertion begins in the text.
The routines
and their uses and parameters are as follows:

*
*

ADDNMB(X)

ADDHEX(X)
(includes

ADDNAM(X,LEN) -

ADDPAT(X)

Insert
-

System Generation

decimal number X (left

Insert X as a

Insert

justified)

four-digit hexadecimal number

the name X of length LEN

a pathname

13-4

to which X points

2270512-9701

DNOS System Design Document

13.4

DETAILS OF THE INITIALIZATION PHASE

There are six
routines
in
the
INIT
INITDB, INITHD, INITAL, and INITOP.

overlay:

INIT,

INITCN,

INIT
- Opens the JENDAT file and verifies compatibility
between the file and the program.
It
also
opens
the
interactive
device
and
checks
the values of synonyms
assigned by the SCI
command
procedure
used
to
start
sysgen.

INITCN -

INITDB
Initializes list headers, implication tables,
the
XOP
tables,
all
answers
to
system
questions,
questions
unanswered
by
the
user, questions that are
nonlistable, and questions that are
preanswered
to
be
false

*
*
*

INITOP -

Initializes the SVC tables

INITAL -

Assigns LUNOs to input and output files

INITHD -

Initializes preanswered questions

13.4.1

Loads the arrays of constants used by SYSJEN

INIT.

INIT
first
finds the value of $$MO.
This indicates whether the
program is running in batch mode.
Then, the value of
$CSNAM
is
found
to
indicate
the
name
of
the
system being built.
The
station is opened next.
A Read
Device
Characteristics
SVC
is
issued
to
find
the
number
of
lines used by the device.
The
listing routine uses this number to get a maximum amount of
data
to
the
screen
before
waiting
for
the
user
to
signal
acknowledgment.
Finally, JENDAT is opened, and the first
record
(record 0) is read to find the version number of the file.
If an
incompatibility
is
found,
an error message is sent to the user
and processing stops.
If no problem is found, INITCN is
called,
followed by a call to INITDB.
13.4.2

INITAL.

INITAL
creates
the
S$SGU$ directory on the target disk, if one
does not exist.
It then creates' the configuration
directory
in
the S$SGU$ directory, if one does not exist.
It then creates all
output
files
needed
by sysgen and assigns LUNOs for use by the
program.

2270512-9701

13-5

System Generation

DNOS System Design Document

13.4.3

INITCN.

INITCN begins by printing an
informative
message
to
the
user
indicating
that execution has begun.
Next, the array indicating
the presence of TILINE devices (TILPRE)
is
set
to
zero.
All
positions
on the seven expansion chassis are marked unused.
Six
sets of devices are filled with devices
containing
the
desired
characteristics.
These
are
LEGALDEVICES,
TILINETYPES,
XCESSREQUIRED, TIMEOUTDEVICES, CHARQTYPES
and
ASYNCTYPES.
The
array
of
device
names
(DEVNAM)
is
filled.
Array
QTX
is
initialized with constants from
file
JDICONS.
QTX
holds
the
pointers
to
question text in the JENDAT file.
TQ, the array of
system question types, is the last array to
be
filled
in
this
routine.
13.4.4

INITDB.

INITDB
initializes
all
answers
to
system questions
(QANS),
questions unanswered by the user (QANSBUS),
all
questions
that
are
nonlistable
(QLIST), and all questions that are preanswered
(QHASDEF) to be false.
Next, all implications are cleared
(that
is,
YESINF
and NOINF are made false).
Now the implica~ions are
made.
All names and pathnames for system questions are allocated
from the heap.
The list headers are made null, and the array
of
PDT names (PDTNAM) is initialized with text.
13.4.5

INITHD.

INITHD
establishes
preanswered questions.
QANS is made true or
false (as needed), QANSBUS is made true, QHASDEF
is
made
true,
and NUMBIN is filled where needed.
(NUMBIN holds either a number
or a pointer to a name or pathname.)
13.4.6

INITOP.

INITOP
begins by initializing all SVC information to false.
The
array, (DESVC),
is
two
dimensional;
of
size
NOSVCGROUPS
by
SVCPARMS.
NOSVCGROUPS is a small integer constant, currently 14.
SVCPARMS is a scalar, with components DESIRED, and REQOND.
These
components
represent
whether
the user wants to include the SVC
and whether it is required.
The array
of
SVC
IDs
(OPSVC)
is
initialized
to false.
This array is used to build RPSDAT and to
decide which optional processors to include in
the
link
stream
built
in
the
BUILD
phase.
INITOP
then initializes DESVC by
assigning those values that are initially true.
Next the
SVCGRP
array is filled.
This array is used in the BUILD phase to decide
which SVCs have been chosen.
A value of 0 indicates that the SVC
is required, -2 indicates nonexistence, -3 indicates that the SVC
System Generation

13-6

2270512-9701

DNOS System Design Document

is
included
if
the
COmmon option is chosen,
indicate an SVC group chosen by group name.

13.5

and other numbers

DETAILS OF THE INTERACTIVE PHASE

Major routines in
the
INTERACTIVE
phase
are
ASKQST,
DEFSTR,
COMMND,
CHANRT,
DELRT,
and
LISTRT.
The translation routine,
TRAN, is also in this
overlay
and
is
called
by
any
routine
needing
a
response
parsed.
Several other support routines are
available throughout the phase.
13.5.1

General Support Routines.

TRAN
TRAN parses the user response and returns a token in
common
variable
TR.
If
the
user terminates a call with the CMD
key, TRAN
directly
calls
COMMND.
This
routine
removes
blanks
from the answer.
It also intercepts a STOP any time
one is entered by a user.
COMMND
entered.
Then
the
COMMND calls TRAN on each user command
proper
routine
is
called to perform the desired function.
CHANRT,
DELRT,
and
The routines called
from
COMMND
are
an
escape from the
LISTRT.
The
INQUIRE
command
causes
COMMND routine.
SETUP
SETUP is used by
INITI
to
convert
answers
what
looks
like
configuration
file
to
collected data.

read
from
a
interactively

Error Routines
Two error routines in the INTERACTIVE phase are
ERRMSG
and
PUNT.
ERRMSG
produces
the
set
of
questions
and error
messages that result from answering a
question
incorrectly
that
was asked by ASKNAM, ASKNMB, ASKYN, OR ASKPAT.
If the
error occurs while a configuration is being
read,
PUNT
is
called
to
indicate
which
record
was
in
error.
PUNT
terminates the program.
13.5.2

Asking System Questions.

The ASKQST routine asks all system questions by looking
for
the
question
type
of
QTA
in
array
TQ.
Then,
one
of the five
prompting routines (ASKNAM, ASKNMB,
ASKYN,
ASKPAT,
ASKELM)
is
called to prompt for and validate the answer.
This is one of two
major
drivers
in the INQUIRE mode.
These five routines all use
the numeric fields of
the
JENDAT
file
for
information
about
2270512-9701

13-7

System Generation

DNOS System Design Document

acceptable
answers
to
the
question.
The fields that contain
answer information are DEFt AAT t LB t UB and NEXT.
DEF contains a
default answer.
AAT is .the acceptable answer type.
LB
and
UB
are
lower
and
upper bounds on the answers.
NEXT is the record
number which logically follows this question.
ASKNAM
ASKNAM is used to ask name questions.
This routine uses the
DEF field to represent the ordinal of the default answer, if
any exists.
The possible values for AAT are as follows:
0
indicates
that
any
answer is acceptable; 1 indicates that
the only acceptable answer is either LB or UB (that
is,
an
answer
must begin with a letter whose ordinal is LB or UB);
and 2 indicates that the question must be answered.
If
DEF
is 0, no default answer exists.
ASKNMB
ASKNMB uses DEF as the default numeric answer.
The possible
vBlues
for AAT are as follows:
0 indicates that any answer
is acceptable; 1 means that an answer must be larger than LB
to be acceptable;
2
indicates
that
the
answer
must
be
between LB and UB inclusively; and 3 indicates that the only
acceptable
answers
are
LB
or
UB.
This
routine
is
a
function.
ASKYN
ASKYN uses DEF in a type transfer to Boolean values
as
the
default
answer,
such
that
0
represents
false
and
1
represents
true.
The
possible
values
for
AAT
are
as
follows:
0 indicates that a default exists and 1 indicates
that no default exists.
This routine is a function.
ASKPAT
producing
prompts
and
ASKPAT uses the logic of ASKNAM for
error
messages.
Then,
this
routine
checks
for
valid
pathname syntax, producing any prompting
necessary
because
of pathname syntax.
ASKELM
uses
the
logic of FNDANS.
It will not stop unless
ASKELM
the answer is found or the command key is entered.
FNDANS
NEXT,
comparing
the
TXT
FNPANS starts with record number
fi~ld
of
each record with the answer supplied by the user.
When a match is found, the DEF
field
is
returned
as
the
an s·w e r •
F NDAN S i s a fun c t ion, ret urn i n g f a I s e i f noma t c h
is found.

System Generation

13-8

2270512-9701

DNOS System Design Document

13.5.3

Defining Structures.

DEFSTR, the other driver in the INQUIRE
mode,
defines
devices,
XOPs,
and
system-supplied
optional
supervisor
calls.
The
routines used are ADDDEV, ADDXOP, and ADDSVC.
They
include
the
logic needed to call the prompt~ng routines for user interaction,
answer validation, and error message production.
ADDDEV
ADDDEV asks questions that allow the user to define devices.
Also
included
are
the
routines ADV2, ADV3, ADV4, DEVINT,
RENAME,
ADDTPD,
ADDVDT,
ADDSD,
and
ADDCOM,
which
are
continuations of ADDDEV.
ADDDEV initializes a local copy of
an empty device definition and calls DEVINT to ask interrupt
and
address-related
questions.
ADV2,
ADV3
and ADV4 are
called to ask other devi£e questions.
These
routines
ask
all
of the unanswered questions.
Then, RENAME is called to
revison bar off name this device.
If the user
answers
all
questions,
a
permanent
copy
is created from the heap and
linked to all other devices on a singly linked list.
ADDTPD
is called to ask more TPD questions.
ADDVDT
is
called
to
ask
more
VDT
questions.
ADDCOM
is
called
to ask more
communications device questions.
ADDSD is called from
ADV3
to ask more special device questions.
The declaration for a device is as follows:
DEVICE = RECORD
LINK
DVTP
INTRPT
POSITION
CHASSIS
SYSNAME
TIMEOUT
CHARQ
XCESS
CRUBIT
NODR
INTERFACE
CHNNMB
ADDRESS
CASE DEVTYPE OF
DS, DK
: ( RECSIZ

DEVPTR;
DEVTYPE;
INTEGER;
INTEGER;
INTEGER;
ARRAY [1 •• 4] 0 F WRD;
INTEGER;
INTEGER;
BOOLEAN;
(* RECORD
INTEGER;
INTEGER;
INTEGER;
INTEGER;
INTEGER;
:

TRUE *)

INTEGER

) ;

: ( WIDTH
PMODE
XCHAR
MULATOR
LP SPEED

INTEGER;
BOOLEAN;
BOOLEAN;
INTEGER;
INTEGER;

(*
(*

SERIAL = TRUE *)
EXTENDED = TRUE *)

) ;

2270512-9701

13-9

System Generation

DNOS System Design Document

VDT

(

KSR

(

ASR

(

INTEGER;
BOOLEAN;
INTEGER;
BOOLEAN;
INTEGER;

VDT TYPE
GOT-A PRINTER
SPEEDSWITCHED
OUTPUT FIFO

);
TERMINAL TYPE
BAUD RATE
ACU PRESENT
ACU-ADDRESS
ECHO
FULL DUPLEX
COMM- INTERFACE
SWITCHED LINE

INTEGER;
INTEGER;
BOOLEAN;
INTEGER;
BOOLEAN;
BOOLEAN;
INTEGER;
BOOLEAN

);
CASXCESS

BOOLEAN

);
COM

RECORD = TRUE

(

BOARDTP
USRBRDTP
SPNAME
BUFSIZ
NOMDL
IPCNOSES
PROTOCLS

COMBRDTP;
COMBRDTP;
WRD;
INTEGER;
INTEGER;
INTEGER;
ARRAY [0 •• 3] OF PROTO_REC;

) ;

SD
VT

(

SDNUMB
SDTIL
( VTNUMB

INTEGER;
BOOLEAN);
INTEGER);

" SD NUMBER
" TILINE DEVICE
." " 0 F VT

END;
ADDSVC
ADDSVC
adds
system optional
SVCs
to
the user-generated
system.
This routine asks
for
a
group
name.
The
user
enters
an
abbreviation or the whole name, and ADDSVC calls
FNDANS to find the group number of that group name.
If this
group is available on the generated system, it is
added
to
the
table
of
desired
SVCs
(DESVC).
Otherwise, an error
message results.
The definition of the DESVC is as follows:
SVCPARMS = ( DESIRED, REQOND, NSONC);
DESVC : ARRAY [1 •• NOSVCGROUPS,SVCPARMS] OF BOOLEAN;
ADDXOP
ADDXOP asks for the level of the XOP first.
If
that
level
is
available
the
user is asked for the entry point of the
XOP processor, the workspace pointer (WP) of the
processor,
and
the
pathname of the object code of the processor.
The
information is kept in the table XOPA.
The pathname is kept
in the heap as are all other pathnames.
The
definition
of
XOPA is as follows:

System Generation

13-10

2270512-9701

DNOS System Design Document

XOPVECTOR = RECORD
HERE
BOOLEAN;:" XOP DEFINED
XOPPC
ASMNAM; -'" ENTRY POINT LABEL
XOPWP
ASMNAM;
"WORKSPACE LABEL
XOPNAHE
PPTH
" PATHNAME OF OBJECT POINTER
END;
XOPA : ARRAY [0 •• 14] OF XOPVECTOR;

13.5.4

Changing Structures.

To
change
a
structure,
the
user must first identify it.
The
system then searches for
the
specified
structure.
If
it
is
found,
it
is deleted and redefined.
The routine CHADEV handles
this processing for devices, ~hile CHANRT handles
it
for
XOPs.
CHANRT calls routines FNDQST, CSYQST, FNDXOP, and ADDXOP.
CHADEV
calls FNDDEV, DELDEV, RENAME, and ADDDEV.
FNDQST
is
used by CHANRT to decide which question is being
FNDQST
abbreviated
by
the
user.
The
questions
are
scanned
sequentially
until
one that has been correctly abbreviated
is found.
To
correctly
abbreviate
a
keyword,
both
the
keyword
and
the
abbreviation
must
begin' with
the same
letter.
All letters in. the abbreviation must appear in
the
keyword and in the same order.
The first letter following a
blank
in
the
keyword
must
match
the
first
otherwise
unmatched letter in the abbreviation.
If
the
abbreviation
is unmatched, the value returned by this function is false.
CSYQST
changes
system
questions.
If
the
question
is
CSYQST
currently preanswered, it
is
marked
unanswered
and
made
listable.
Any other questions between this question and the
expansion card questions are unanswered.
FNDDEV
FNDDEV asks for the device name and searches the device list
for
a
device with that name.
The pointer to the device is
returned, if found, or an error message is produced.
FNDXOP
been
defined
on
the
FNDXOP verifies that a given XOP has
level
that
the
user
enters.
If that level has not been
defined, an error message
is
produced.
If
the
XOP
was
defined, the value is returned in common variable CXOP.
DELDEV
This
delete
routine
deletes an item by linking around the
item and disposing of the heap space used by the
structure.
Devices
are
kept in singly linked lists in the heap.
XOPS
are kept in an array in common; consequently,
they
require
2270512-9701

13-11

System Generation

I
I

DNOS System Design Document

no delete

13.5.5

routine.

Deleting Structures.

DELRT operates similarly to CHANRT except that DELRT never issues
a
call
to
add
a
new
structure;
it issues calls only to the
routine that finds the desired
item
and
to
the
routine
that
deletes that item.

13.5.6

Listing Structures.

LISTRT
is
the
routine
that
produces
configuration listings.
These listings may be produced at the station for viewing by
the
user
or
to
a
file
to be read by another use of SYSJEN or for
later reference.
The routines used by LISTRT are
FORM,
SHOWDV,
and
LIST2.
LIST2
is
a
continuation
of
LISTRT, which calls
FRMXOP.
These routines all call DUMYUP and LOOK which
transfer
text
from
the
JENDAT
file
to
the output buffer, eliminating
string constants from the program.
All of
these
routines
call
ADDHEX, ADDNAM, ADDNMB, and ADDPAT for string operations~
DISPAT
is
called
by
all
of these routines.
It directs the output to
either a file or the interactive device.
If the
program
is, in
the
INTERACTIVE
phase,
the' user sees the list; otherwise, the
information is written to the CONFIG file.
FORM
FORM is used to fill in the
answers
to
system
questions.
The type of question is found in array TQ, and the answer is
added to a line of text read from the JENDAT file.
LOOK
LOOK reads a record from JENDAT, scans for the question mark
in
the
text
field,
and initializes common variable BC to
point to the question mark.
Thus, answers
may
be
encoded
into the field.

SHOWDV
SHOWDV
uses
the
logic
of
information about a device.

FORMDV, FRMXOP
FORMDV, and FRMXOP build the lines of
information about devices and XOPs to
or the user.

FORMDV

show all

pertinent

text
for
displaying
the configuration file

FILLTB
FILLTB
is called after every system question is answered to
update the question-answered
table
by
implication.
This
routine
uses
common
arrays
YESINF
and
NOINF
to answer
certain questions for the user.

System Generation

13-12

2270512-9701

DNOS System Design Document

13.6

DETAILS OF THE BUILDING PHASE

The flow through the BUILD phase is
linear.
The
first
module
called
is
INITBL, which initializes data structures that cannot
be initialized as long as the user can change his mind.
The next
routine called is SYSJCA, which defines the system
job.
BLDWSR
is
called
to build interrupt decoder tables.
PDTBLD builds the
PDTs.
BLDSSB builds the SSBs.
If
communications
devices
are
genned,
BLDSWS
and BLDDSR build the files required to build the
communications
software
scheduler
and
communications
device
service routines, respectively.
Throughout
the
process, all of these routines and BILDRT itself
depend heavily on the COpy routine.
Although the COpy routine is
physically split into 17 different routines, they all function as
one routine.
COpy is used to access data
in
the
JENDAT
file,
process
it as specified in that file, and output it to the files
for the built system.
INITBL
INITBL marks the SVCs required by system common
and
system
disk in addition to those that were chosen by the user.
The
OPSVC array is then filled by assigning the values indicated
by
SVCGRP
and
the DESVC array.
The use of each interrupt
level is then determined (INTUSE) and expansion chassis .use
is
marked in array CHSINUSE.
INITBL marks the combinations
of communications
boards
and
protocols
which
have
been
chosen
by
the user.
This information will be saved in the
COMSTATUS
array.
If
communications
devices
have
been
genned, INITBL will call INITCM to create all files required
for communications link.
Finally, INITBL will set the flags
used 0 load the DSR overlays.
SYSJCA
SYSJCA
scans
the job list,
O.
If such a job exists, it
this
job
does
not
exist,
used to prevent special case
later routines.

looking for a job with an ID
becomes
the
system
job.
it is created.
This routine
coding for the
system
job

of
If
is
in

BLDWSR
first
builds
the
workspaces
for
the
interrupt
BLDWSR
decoder.
This
routine
uses
array
INTUSE,
which
was
initialized
in
INITBL to decide what devices are available
at each interrupt level.
The
workspace
is
different
for
single
device per interrupt, multiple device per interrupt,
one or more asynchronous TILINE controllers
per
interrupt,
and
each
of
the expansion chassis.
If an interrupt level
has more than one device, a multiple interrupt decoder table
is built for that interrupt level.
The
table
consists
of
interrupt
bit
positions
used for polling in the interrupt
decoder, and interrupt vector pointers.
The
table
is
of
variable
length.
If
an
interrupt
level has one or more

2270512-9701

13-13

System Generation

I
I

DNOS System Design Document

I
I
I
I

asynchronous TILINE controllers, a multiple interface
table
is built.
This table consists of the controller address and
a
pointer
to
the
table of channel entries.
The table of
channel entries consists of the
interrupt
vector
pointers
and
the
controller
chanriel
number.
If a device has been
defined on an expansion chassis, a table of interrupt vector
pointers for that chassis is built.
The size of
the
table
is
24
entries.
Then, all interrupt vectors are built, one
for each device that shared an interrupt level on
the
main
chassis and each device on an expansion chassis.
PDTBLD
PDTBLD
is
the
main
driver
used in building PDTs.
Note,
however, that PDTFIL builds the fields needed to fill in the
template kept in the JENDAT file, and PDTGO
calls
for
the
correct
pieces
of the template that are kept in the JRNDAT
file.
PDTBLD sets either a
flag
in
the
common
variable
DCODE
to
indicate
that
the
current
device is the first
device of a multiple drive cont~oller, or a flag
in
COmmon
variable
CASFLAG,
to indicate that the current device is a
cassette drive.
PDTBLD also chooses the correct name to
be
used
in
filling
the
PDT
template.
PDTBLD
is
also
responsible for producing the trailer equate for the end
of
the
PDT
chain.
Note
that
this
trailer
equate
is not
produced if RTS is present.
PDTFIL defines
the
values
of
flag
words,
labels,
and special constants used in filling
the template.
These include the device type
flags,
device
status
flags,
the address, and the interrupt level.
PDTGO
decides where to begin copying in
the
JENDAT
file.
Some
PDTs have no extensions, while others have as many as three.
BLDSSB
builds the SGB in the system table area, then builds
BLDSSB
SSBs for the segment management table area, file
management
table area, system root, and system COmmon.
The fields that
must be initialized are the link field, run-time ID, segment
attributes,
use count, segment group block pointer, segment
beet address, and
length
of
the
segment.
This
routine
initializes
these fields and calls the correct copy routine
to build the SSBs of the STA.

System Generation

13-14

2270512-9701

DNOS System Design Document

13.7

JENDAT FILE

SYSJEN maintains a large amount of data in the JENDAT file, which
is a random file of Pascal records.
The definition of the record
type is as follows:
TYPE GENMSG = RECORD
DEF
AAT
LB
UB
NEXT
LEN
TXT

INTEGER;
INTEGER;
INTEGER;
INTEGER;
INTEGER;
INTEGER;
PACKED ARRAY [1 •• 76] OF CHAR END;

The uses of each field are described first
for
the
INTERACTIVE
phase
of
SYSJEN and then for the BUILD phase.
(The uses differ
greatly.)
Since the field names are based on their original uses
in the INTERACTIVE phase, they do not accurately portray their
uses in
the
BUILD
phase.
The
names
were
chosen
from
the
following uses of each field:
Name
DEF
AAT
LB
UB
NEXT
LEN
TXT
13.7.1

Use
Default answer
Acceptable answer type
Lower bound on answers
Upper bound on answers
Record number that logically follows
Length of the text that follows
Message text

Interactive Use of the JENDAT File.

The
length
field
is
used
in
the call block as the number of
characters to be written.
The text field contains the message to
be written to the user's screen.
Five types of
questions
asked
by
sysgen determine how the fields of the record are to be used.
The types of questions asked are as follows:

Number questions

Name questions

*
*

Element questions
Pathname questions

2270512-9701

13-15

System Generation

DNOS System Design Document

YES/NO questions

13.7.1.1

Number Questions.

Number questions use the default field to find the answer
to
be
used
if
the
user
hits
the
RETURN
key
in
response
to
a
question.63No conversion is necessary.
The
value
in
the
AAT
field signifies the following:

o
1
2
3

any numerical answer is acceptable
any number greater than LB is acceptable
any number X such that LB <= X <= UB is acceptable
only LB or UB is acceptable

This
scheme
allows the ASKNMB routine to determine the validity
of answers without special
case
code
for
each
question
that
requires
a
number
answer.
If
only
one
of
three
or
more
noncontiguous numbers are acceptable, special case code is
still
required.
Consider the following example:
REC /I
20

DEF AAT
60
3

LB
50

UB NEXT LEN TXT
60
21
20 LINE FREQUENCY?

(60)

Record number 20 asks for the frequency of the line voltage.
The
default
answer
is
60.
The
default
is
always
included
in
parentheses in the text to inform the user of the default.
Since
AAT = 3, the only acceptable answers are 50 or 60.
The length of
the text string to be written is 20 characters.
This permits the
response to be accepted
directly
after
the
question,
without
scanning
the
text string.
The NEXT field indicates that if the
user responds
by
entering
a
?
or
incorrectly
answers
the
question,
the
longer
form
of
the question is at location 21.
This permits many changes to be made to the JENDAT file
with
no
changes in program logic, and recompiling is not necessary.
Often, several records are logically followed by the same record.
Such is the case when, in answering the second question, the user
incorrectly
defines
the
interrupt
levels.
All of these error
messages may be provided with the same
text,
as
shown
in
the
following
example.
(Note
that
all
of
the text will not fit
across the page in this example.)
REC /I DEF AAT
179
9
2
REC /I DEF AAT
180
7
2

LB
3
LB
3

UB NEXT LEN TXT
15
185
49 WHAT IS THE
UB NEXT LEN TXT
15
185
46 WHAT IS THE

INTERRUPT LEVEL
INTERRUPT LEVEL

This example asks for the interrupt level of a tape unit and then
the interrupt level of
a
flexible
diskette.
The
default
is
either
9
or
7.
The
acceptable- answers are the same, but the
question lengths differ slightly.
N~tice that the
next
logical

System Generation

13-16

2270512-9701

DNOS System Design Document

record is the same for each. question.
use the same text at recor.d 185.

Seven other questions also

Often,
the
value of NEXT is O.
This indicates that
record is the last of a chain.
This will be the last
the current request will di.splay.
13.7.1.2

the current
record that

Name Questions.

Name questions assume that only the first character of the answer
is significant.
The default contains the ordinal
of
the
first
character
of
the
name.
The
value
of
AAT is as follows:
0
indicates that any answer is acceptable, 1
indicates
that
only
ORD(LB)
or
ORD(UB) is acceptable, and 2 indicates that the user
must answer the question.
If AAT is 1 and DEF is 0, no default exists.
As
a
result.
the
question
(or
a
similar question) is asked until it is answered
correctly.
The following example
asks
for
the
type
of
line
printer
being
defined.
The
user is expected to answer either
serial or parallel.
The default is serial.
The ordinal of S
is
83, and the ordinal of P is 70.
Thus the user may hit the RETURN
key to indicate serial (the default).
Any answer except a RETURN
or words that begin in S or P are treated as incorrect answers.
REC II
272

DEF AAT
83
1

LB
70

UB NEXT LEN TXT
83
273
20 PRINT MODE?

(SERIAL)

In the next example, the user is asked for the workspace label of
a special DSR.
Any answer is acceptable, but note that an answer
must be given.
REC II
344
13.7.1.3

DEF AAT
o
2

UB NEXT LEN TXT
0
345
14 DSR WORKSPACE?

Element Questions.

Element questions use the default answer if AAT is 1 and the user
hits
the
RETURN
key
in response to the answer.
Otherwise the
value of NEXT points to a list of valid answers.
The list can then be searched using ASKELM,
which
compares
the
user
response
to
the TXT (message TEXT).
If a match is found,
the DEF field is returned as the
answer.
Otherwise,
the
next
logical
record is searched.
(The next logical record is pointed
to by the field NEXT.
If NEXT is 0, this signifies
the
end
of
the
list).
This process is continued until a match is found or
the CMD key is pressed.
If an invalid answer
is
entered,
then
the longer form of question is asked.
An
example of an element question is one
follows:

2270512-9701

13-17

that

asks

baud rate, as

System Generation

DNOS System Design Document

REC #
1820

DEF ATT
LB
000

UB NEXT LEN TXT
o 1822 10 BAUD RATE?

The next physical record of the file has the first
line
of
the
explanation of the question and records starting at 1822 have the
valid
options.
The
entries for the valid responses include as
the DEF field the internal value needed by SYSJEN.
NOTE
The first line of the longer question must be
physically after
the
short
question.
The
valid
answers
must
be
logically after the
short
form.
This
applies
only
for
the
element questions.

WARNING
The
internal
value
(the DEF field) usually
plays a significant
role
during
the
build
(and
sometimes the inquiry phase) of Sysgen.
When adding or deleting elements
from
these
lists, great caution should be used.

13.7.1.4

Pathname Questions.

Some
questions
are
answered by pathnames.
These questions use
the logic of the name questions.
When
a
valid
name
has
been
entered,
(almost
anything is an acceptable name), the syntax of
pathnames is checked.
Thus, no special entries are made
in
the
file.
In
the
following example, the user is forced to enter a
name.
The syntax requirements are treated in no special
way
in
the
JENDAT
file;
only
the
text
gives
any indication of the
requirements of the answer.
REC#
870

DEF AAT
o
2

UB NEXT LEN TXT
0
867
25 APPLICATION PROGRAM FILE?

In the following example (defining the KSB for a special device),
the user is not forced to answer the question;
this
means
that
the device does not have a keyboard.
REC#
337

DEF AAT
o 0

System Generation

UB NEXT LEN TXT
0
338
11 KSB? (NONE)

13-18

2270512-9701

DNOS System Design Document

13.7.1.5

Yes/No Questions.

Yes/No
questions
have
as
default
answers the internal Pascal
representation of true and false, 1 and O.
The value of
AAT
is
as
follows:
0 indicates that a default exists, 1 indicates that
no default exists and the user. must answer.
In the following example, the user is defining
a
line
printer.
The
question
determines
whether
an
extended character set is
available on that printer.REC II
277

DEF AAT
LB
000

UB NEXT LEN TXT
o 278 14 EXTENDED?

The default is NO, and the user
default.
13.7.2

may

press

(NO)
RETURN

get

the

BUILD Use of the JENDAT File.

The JENDAT file is predominantly used for building source code in
the
various
modules that describe the system being generated by
SYSJEN in the BUILD phase.
The DEF field is used as follows:
if
DEF is 0, no processing is required on the field; if
DEF
is
1,
AAT
contains
the
type
of modification that is required.
This
value is used as the case statement variable of the COpy routines
in SYSGEN.
The use of the values of NEXT and LEN
in
the
BUILD
phase
is
similar
to
their
use in the INTERACTIVE phase.
The
remaining fields are of variable usage.
The LB field
is
almost
always
a
pointer
into
the
record.
This value is the column
number of the first column that requires
modification.
In
the
example that follows, a label is inserted on a PDT.
REC II
378
The DEF
used to
If
the
and the

DEF AAT
LB
103

UB NEXT LEN TXT
o 379 13 PS

EQU

flag signals that the record must be modified.
Case 0 is
indicate adding the current device name into location LB.
current device is DSOl, this name is inserted at column 3
record is modified as follows:

PSDSOI EQU

Generally, the UB field is O.
However, it is sometimes
used
to
mark
a
second
column
for
modifications,
as in the following
example where an interrupt vector is being defined.
REC II
594

DEF AAT
1
29

LB
15

UB NEXT LEN TXT
29
0
57 IV

DATA

,SG3BGN,MP

The device name is added at co~umn 15, and an
offset
determined
by
the device type is added at location 30.
Internal logic also
adds the name at column 3 and a field determined
by
the
device
2270512-9701

13-19

System Generation

DNOS System Design Document

type
at
column 13.
If the device type were VDT and the current
name were STI6, the record would be modified as follows:
IVST16 DATA KBSTI6,SG3BGN,MPSTI6
Sometimes the UB field does not hold a
location
in
a
specific
record;
instead,
it
holds the current location in a section of
records.
For example, consider building
the
expansion
chassis
interrupt decoder table.
This table is 24 records long, each
containing
either 0 or a label of an interrupt vector (as in the
previous example).
REC #
830

DEF AAT
1
28

LB
15

UB NEXT LEN TXT
6
831
14

DATA IV

In this example the UB signifies that the user
is
building
the
seventh
entry,
the
entry
for
interrupt
position
6.
If the
current device name was STI6, the seventh entry in the
interrupt
table would become:
DATA IVST16
This
use
of
UB
is prevalent in the table building portions of
sysgen, although its use as a column number is more COmmon.
The
only
accurate
means
of
determining
its use is to examine the
source in the COPY modules.
13.7.3

Sample Copy Module.

The following copy module indicates
the
BUILD
usage
from
the
SYSJEN
program.
The
entries are divided into groups of ten to
simplify the requirements on the compiler.
The COpy module has a
case
statement
that
uses
the
AAT
field.divided
by
ten
to
determine
which
sub-COPY
module to call to process the record.
The ATT field is a hexadecimal number.
To determine
which
subCOpy
module
is
going
to
be
used, convert ATT to decimal and
divide by ten.
The example given determines whether
to
include
the
given
record
in
the
link stream.
The record in question
should be included if the system is a DNOS/D.
REC #
1621

DEF AAT
1
SF

UB NEXT LEN TXT
0 1622
20 PHASE

3,CFDFOV

the
COpy
The AAT field of SF indicates that case number
95
of
module
is called to process this record.
The code is taken from
COPY9.

System Generation

13-20

2270512-9701

DNOS System Design Document

BEGIN
DISK := QANS[DISKQST];
KIF := QANS[KIFQST];
CD := QANS[CDFQST];
FM := QANS[FMQST];
CASE JMSG.AAT MOD 10 OF
o PRFLAG:= QANS[EXFQST];
1
PRFLAG:= NOT FM;
2
PRFLAG:= NOT CD;
3
PRFLAG:= FM;
4
PRFLAG.- CD;
5
PRFLAG:= DISK;
6
PRFLAG:= NOT DISK;
7
PRFLAG:= NOT KIF;
8
PRFLAG:= KIF;
9
PRFLAG:= NOT QANS[EXFQST];
OTHERWISE ; END;
END;
The variable PRFLAG indicates that the record should
be
printed
if the value is true; otherwise it should not be printed.

13.8

JENDAT EDITOR

A special
editing
program is available to the DNOS development
staff to maintain and
modify
the
JENDAT
file.
This
editing
program is documented in the section on DNOS tools.

2270512-9701

13-21/13-22

System Generation

DNOS System Design Document

SECTION 14
LOGGING AND ACCOUNTING

14.1

LOGGING AND ACCOUNTING FUNCTIONS

The
DNOS logging system logs information
(.S$LOGI and .S$LOG2) and "an
optionally
The
log
is
used to inform the operator
the hardware and/or
oper~ting
system.
following types of messages:

to the system log files
specified
log
device.
or user of the state of
The
log
contains
the

Device
errors
with
after an operation

*
*
*
*
*
*
*

Device errors with the offending call block

the

controller

images before and

Abnormal task termination
Statistics from a DSR
Operating system informative messages
User messages (from SVC )21)
Cache memory errors
Memory parity errors

The DNOS accounting system logs
information
concerning
use
of
system
resources
by
user
tasks to the system accounting files
(.S$ACT1 and
.S$ACT2).
Entries
are
made
for
the
following
events:

*
*
*
*
*
*

Job initialization
Task termination
Job termination
Spooler device use
Initial program load (IPL)
User-defined

2270512-9701

(from SVC )47)

14-1

Logging and Accounting

DNOS System Design Document

14.2

LOGGING AND ACCOUNTING TASKS

The
logging and accounting systems each have a queue server task
to write data to the disk files.
Whenever data is to be
written
to
either
the
log or accounting files, an entry containing the
data is put on the appropriate queue to be processed by the queue
server.
Since the function of writing data to the disk files
is
similar
in
both
queue
servers, several subroutines are shared
between the tasks.
If errors are encountered
while
writing
to
the files, then a message is generated for the log device and th~
attention device.

14.2.1

LGFORM.

The
system
log
formatter
task
(LGFORM) serves the system log
queue.
This queue has system log blocks (SLBs) generated by user
tasks using SVC )21
and
from
a
variety
of
operating
system
sources.
LGFORM
first
ensures
that
logging
is
functional.
It
then
dequeues one entry after another until the queue is
empty.
For
each
log
entry,
LGFORM
builds one or more lines of system log
text and outputs it to the system log file (one of
two
possible
system files) and, optionally, to a system log device.
Since
the
log
queue is a finite limit, there may be times when
more messages are sent to the queue than will fit.
In that case,
DNOS increments a lost message count in the newest entry
on
the
log queue.
When LGFORM processes a log entry, it checks the lost
message
count.
If
it
is
greater than zero, LGFORM outputs a
message showing how many log entries were lost.
Other error conditions are also monitored and reported.
If
the
files
and/or
log device should become inoperative, a message is
sent to the attention device specified during system
generation.
When one of the log files becomes full, a message is also sent to
the
attention
device.
The alternate file will then become the
log file in use.

14.2.2

LGACCT.

For each
LGACCT is the task that processes the accounting queue.
entry on the accounting queue, LGACCT builds an accounting record
and writes it to the accounting file that is
currently
in
use.
Like
the
log
files, when one accounting file is filled, LGACCT
switches to the other accounting file.
Errors in the
accounting
files
are also reported to the log attention device.
Unlike the
log files, the accounting files contain binary
data
instead
of
text.
For
information on processing the data in the accounting
files see the DNOS System Programmer's Guide.

Logging and Accounting

14-2

2270512-9701

DNOS System Design Document

14.3

SUPPORT ROUTINES

Since many of the functions of the log and accounting system
are
similar,
many
of
the
following
routines are linked into both
systems.
LGALUN
LGALUN is used to assign a LUNO to the output
in use.
It may be used for either
the
log
accounting files.
LGATTN
LGATTN is used to write a message
one has been specified.

file currently
files
or
the

to the attention device if

LGCHEK
If
an
error
is encountered while writing to the log files
and log device, then LGCHEK will delay and continue retrying
the request until it succeeds.
LGSWTH
When an output file fills up, LGSWTH is called to close
the
current
file
and
open
the
other
file.
The new file is
marked as the current file.
If there is a task specified to
process the files, then that task is bid after the files are
switched.
If both a system-supplied task and a user-defined
task are supplied, the system-supplied task
is
bid
first.
This
routine
can
be used for either the log or accounting
files.
LGWACC
outputs
LGWACC
accounting file.

accounting

record

LGWDEV
LGWDEV writes a message to a device.
log device or the attention device.

the

current

It may be used for

the

LGWLOG
LGWLOG
outputs
a
log message to the current log file.
It
also ensures that the log files are switched when one
fills
up
and
that
the message goes to the log device if one has
been specified.

14.4

MISCELLANEOUS MODULES

Several modules are used

throughout DNOS to generate

log entries.

LGACHN
It
receives
LGACHN is a task that runs in the spooler job.
system
containing device
spooler
IPC
messages
from
the

2270512-9701

14-3

Logging and Accounting

DNOS System Design Document

accounting records.
LGACHN is responsible for putting those
accounting records on the accounting queue.
LGDEV
LGDEV is a routine in
the
DNOS
kernel
that
is
used
to
generate
log
messages 'for device errors.
It calls LGQBLK
after setting up a device message.
LGGLOG
system
restart
to
LGGLOG is a task that is invoked during
read the crash dump from the previous crash and retrieve any
log
messages
that
were generated before the crash but did
not make it to
the
log
file.
Those
messages
are
then
written to the log file.
LGQACC
LGQACC
is a kernel routine
to the accounting queue.
LGQBLK
LGQBLK is a kernel
log queue.

that queues an accounting record

routine that queues a log message to

the

LGRCRT
is a task that is invoked when the log or accounting
LGRCRT
files need to be created or recreated.
When
recreating
a
pair
of
files,
it
ensures that the new files are created
before destroying the old files.
LGSVC
LGSVC is the module in the DNOS kernel that
processes
user
log message SVCs (SVC )21).
It generates a log record to be
queued to the log queue.
PMACCT
PMACCT
is
the kernel routine that processes the accounting
SVCs (SVCs )47 and )49).
For the log accounting
entry
SVC
()47),
it creates an accounting record and queues it to the
accounting queue.
For the get
accounting
information
SVC
()49),
it
returns
the
accounting
information
for
the
requested task in the call block.

Logging and Accaunting

14-4

2270512-9701

DNOS System Design Document'

~ECTION

DNOS PERFORMANCE PACKAGE

15 • 1

OVERVIEW

The DNOS Performance Package uses
the
990/12
writable
control
store
(WCS)
to
enhance DNOS speed.
This section describes the
WCS component and also describes the way
DNOS
operates
without
the WCS component.

15.2

DNOS SOURCE CONVENTIONS

DNOS
source
has two components that enable use of WCS for speed
enhancement.
These are a set
of
XOPs
and
a' routine
in
the
NUCLEUS
source
directory
named
NFMAT.
For a number of system
routines, the execution takes place in WCS when
the
performance
package
is
available
and
otherwise,
takes
place
in
memory
(referred to as default code).
The access to the system routines
is via XOP instructions, placed into
the
DNOS
source
code
by
macros.
These
macros
are
described briefly in the section on
naming and coding conventions.
In addition, NFTBID ensures
that
all
system
tasks that are bid have their WCS status bits turned
on.
This will cause routine calls to go to microcode.
The XOP assignments are as follows.
XOP
XOP
XOP
XOP
XOP
XOP
XOP

10,Rl
10,R2
10,R3
10,R4
10,R5
11,RX
12,RX

RPPRCK
RPSGCK
NFRTA
NFGTA
NFGTAO
NFPOPX
NFPSHX

It is important to note that the microcode assumes that bit 11 of
the instruction is a zero.
This is used to quickly
decide
what
map
file the caller is in.
This means that only direct register
addressing can be used in the XOP instructions.
Any violation of
this rule generates unpredictable results.
NFMAT is
NFMAT is a data area that starts at location )EO.
used
to
tell
the microcode the location of things it wants to access
2270512-9701

15-1

DNOS Performance Package

DNOS System Design Document

in memory.
For example,
it
cont~ins
the
address
of
JCASTR.
Since
the
microcode uses its own equates, the order of the data
in NFMAT must not be changed without changing
both
the
default
and
performance
microcode
modules.
Data
used
to
crash and
provide addresses for the default microcode
starts
at
location
)100.
Since
the
microcode can only map an eight bit constant,
this area is addressed by shifting an eight
bit
number
to
the
left
one
bit
and
using that as the address.
For this reason,
some addresses have equates in the microcode that are
only
half
of
their
expected
value.
This also means that if new data is
added after )100, the corresponding equate in the microcode
must
be
divided
by two to force it into eight bits and 'multiplied by
two to generate the correct value.
The end of NFMAT
contains
a
set of ASSUME statements.
These ASSUME macros are needed because
the microcode will reference fields within a block (like TSBMLl).
If these assumes should fail, then the equates in the default and
performance code must be changed.
If the microcode should ever need to crash, the PC will be placed
into
Rl1
and
the
crash
code
written
to location )104.
The
program will then return out of microcode at location )100
which
contains a BLWP to NFCRSH.

15.3

MICROCODE CHARACTERISTICS

The
microcode is divided into two modules:
the performance code
and the default code.
The performance code is used to
speed
up
DNOS
and the default cOlde provides an interface when performance
code
is
not
installed
so "that
a
990/12
can
execute
XOPs
efficiently.
XOPs are decoded in the following manner:

The XOP instruction is vectored into WCS

2. The XOP level provides a first

3. The correct

routine is found

level of decoding

from a

branch table

The default control store is used so that XOPs can be executed on
a
990/12
quickly_
Since
it is always loaded, it is linked in
with the IPL procedure.
If SLWCS finds
no
WCS
image
file
on
disk,
it
moves
the default code into the WCS segment.
Located
before the WCS object is a module
called
PFWCSO.
This
module
simulates
the
overhead found in an image file.
It contains the
number of microwords in the file, the start
address,
and
other
information.
If
default
code is being changed, PFWCSO must be
changed to reflect the new length.
Equates for new symbols
must
also be added to the microcode.

DNOS Performance Package

15-2

2270512-9701

DNOS System Design Document

15.4

MICROCODE CODING CONVENTIONS

This
section
describes
th~
standard conventions used to write
microcode.
It specifies the",syntax, labels,
and
comments
that
microcode should contain.
It is assumed that the reader has read
the
990/12 Microcode Development System Programmer's Guide
or
that he knows 990/12 microcode language.

15.4.1

Standard Syntax For Microcode States.

Since the microassembler does
not
specify
an
order
in
which
microcode
mnemonics
are
written, an informal standard has been
adopted for DNOS
microcode.
This
order
makes
the
microcode
states
more
orderly
and
facilitates reading.
The format of a
state is:
LABEL:

READ,
ALUI. XAC, or an expression whose
value is numeric
Alphanumeric characters surrounded by
quo t e rna r k s (")
1 to 6 ASCII characters

Number

String
Label

An expression is any combination of numbers
or
addresses
using
addition or subtraction.
The addresses used in an expression may
be
stated
as labels that have been previously defined to have a
numeric value.
Arguments to the commands
may
also
use
signed
numbers,
preceding
the
number by a plus (+) or minus (-) sign.
Indirect arguments can be specified
by
preceding
the
argument
with
an asterisk (*).
In addition to labels defined by the user
with the EQU command, there are a number
of
predefined
labels.
Table 16-2 lists and defines the predefined labels.
Table 16-2

Predefined Labels for Tigress

Commands

La bel

Meaning

ADDRND
CMDSCB
DATSCB
ECHSCB
LSTSCB
NEWMEM
PC

First illegal (upper) Tigress address
Address of SVC b~ock used to read commands
Address of SVC block used to read data file
Address of SVC blo~k used to write echo
Address of SVC block used for listing file
Start of memory acquired with GET command
The record number of the current command
Tigress user registers 0 through 15
Address of start of the SVC block used by
Tigress to issue user specified SVCs
Address of stack of arguments from last BRL
command

RO - R15
SVCB
STK

The
labels
in Table 16-2 can be used in the DSP command to find
the location of special Tigress structures.
These labels
cannot
be redefined by the user.
The address

2270512-9701

space used by TIGRESS looks as follows:

16-5

DNOS Tools

DNOS System Design Document

0000

+---------------------------------+
I
REGISTERS RO - RlS
I

0032

+---------------------------------+
I
SERVICE CALL CONTROL BLOCK
I

+---------------------------------+
I
USER DEFINABLE ADDRESS SPACE
I

,I , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,I

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
I

+---------------------------------+
I
FIRST INVALID ADDRESS
I

The
entire
set
of command options is listed in Table 16-3.
In
addition to these, users may specify a comment line in a
cOmmand
file by placing an asterisk in the first column of the line.
The 3 letter command must begin in column 1 and the argument list
must begin in column S.
Each argument, except strings, generates
2
bytes
of
data.
The commands are described in the paragraphs
following the table.

DNOS Tools

16-6

2270S12-9701

DNOS System Design Document

Table 16-3
Command

BRL
DSP
END

EQU
GET
INC
INP

JMP
JPB
JPF
LBL
MSG
MVI
MVS

RBT
RTE
RTN
SBS

SBR
SBT

SCB
SEI

SRI
SLI
SNI

SES
SHS

SLS
SNS
SVC

2270512-9701

Tigress Commands

Parameters
label [ ••• number/address/string]
number,address
string,number
number
address,number
address,number1,number2
number
"label"
"label"
"string"
string
address,numberl,number2[,number3 ••• ]
addressl,number,address2
address,number
address,number
address,number
address,number
numberl,[,number2]
address,numberl,number2[,number3
address,numberl,number2[,number3
address,numberl,number2[,number3
address,numberl,number2[,number3
addressl,number,address2
addressl,number,address2
addressl.,number,address2
address1,number,address2
[num be r , ••• ]

16-7

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

]
]
]
]

DNOS Tools

DNOS System Design Document

BRL [label, ••• string]
The branch and link to subroutine command saves the
current
value
of PC, builds an argument list in the stack area, and
branches to a specified subroutine.
(See also RTN and RTE.)
For example, BRL
SUBl,)0400,@)100,A,B,23,"ABC" would
cause
subroutine SUBI to be called with a stack as follows:
PC
)0400
@)100
A
B

23
)4142
)4320
14

Location of the BRL command within the command file
Whatever 16 bit address this
Whatever this is equated to
Whatever this is equated to

resolves to

AB
C

The length of the argument list

in bytes

The value of STK is changed to point to the length word (the
14
in
the above example).
The stack itself resides within
the Tigress task area, but is not modifiable
by
the
user.
It is expected that a subroutine would pick up its arguments
as follows:
EQU
EQU

"ARGIAD",STK-*STK
"ARG2AD",ARGIAD+2

EQU

"ARG1",*ARGIAD

NOTE
(1)
Subroutines
may
call other subroutines
several levels deep if needed.
However,
the
total stack area is 120 bytes.
An error will
occur
if
a
BRL
is
attempted
which
will
overflow the 120 bytes limit and the BRL will
be ignored.
(2)Text strings may be passed
as
arguments.
They
are
put
directly
in the stack with a
blank at the end if the length would be
odd.
The
subroutine
must
either
be
capable of
determining the length or the
length
should
be passed as a separate argument.
Also, such
strings will quickly consume the 120 bytes of
stack
space,
so
use
this
feature
with
discretion.
Since a variable
length
string
in
the
stack
would make it inconvenient to
find an argument which followed
the
string,

DNOS Tools

16-8

2270512-9701

DNOS System Design Document

it is recommended that only the last argument
(if any) of a subroutine be such a string.
(3) The subroutine address (SUBl in the above
example)
must
have
been previously defined
with an EQU command before the subroutine can
be called.

DSP number,address
This
command
displays
the
number
of
bytes
specified,
starting
at
the address specified.
The address is rounded
to
an
even
numbered
address
if
necessary.
Memory
is
displayed
in multiples of 8 words per line of output.
Each
line of output shows the memory address of
the
first
word
displayed,
eight words of data in hexadecimal, and the same
eight words of data in ASCII.
END
The END command is used to terminate execution
of
Tigress.
A termination message is output, and control returns to the
task that activated Tigress.
EQU string,number
This command is used to assign a
value
to
a
label.
The
label
can
then
be
used
as
a parameter or as part of an
expression in other commands.
The string specified
is
the
label
to
be
used, and the number specified (or expression
that evaluates to a number) is the value retrieved
whenever
the label is used.
GET number
This
command gets 32 times the number of bytes of memory to
be included in the Tigress address space.
The
address
of
the
first
word
of
this block of memory is equated to the
string NEWMEM.
Note that NEWMEM
is
undefined
until
this
command
is
executed.
On
subsequent
executions
of
the
command, NEWMEM points to the start
of
the
new
block
of
memory acquired.
INC address,number
The
number
specified
address specified.

is added to the current value at

the

INP address,number1,number2
This command causes number1 bytes of data to
be
read
from
the data file into memory at the address specified, starting
from record number2 of the file.
JMP number
This
causes
Tigress
to
execute
next the command that is
located at a distance specified by number.
JMP 0
indicates

2270512-9701

16-9

DNOS Tools

DNOS System Design Document

that this same command should be executed.
JMP -2 indicates
that
Tigress
should
proceed to the command preceding this
command by two, JMP 3 indicates that the next
two
commands
should
be
skipped.
This
command
is
not
meaningful if
command input
is
from
a
terminal.
(Comments
count
as
commands.)
JMP is an unconditional command but can be used
with the skip commands below to accomplish branching.
JPB "label"
The jump backward to label causes a jump back in the command
file until an LBL command is
found
with
the
same
string
operand
as
is
on the JPB command.
For example, JPB "ABC"
jumps back in the file until
a
command
of
LBL
"ABC"
is
encountered.
The operand must be in quotes since it is not
entered in the symbol tahle.
It
is
treated
as
an
ASCII
string.
The string may be of any length, but only the first
six characters are used in the comparison.
JPF "label"
The jump forward to label command works like JPB except that
the
jump
is
in the forward direction rather than backward
through the command file.
LBL "string"
This command denotes a place for a destination of a- JPF
or
JPB command.
The string may be from 1 to 6 characters long.
MSG string
The string specified is output to the listing file.
This is
useful
for
noting
success or failure in a test stream and
for documenting the test in progress.
MVI address,numberl,number2[,number3 ••• ]
This command causes a
move
to
the
address
specified
of
numberl
bytes of data specified in number2 through the last
parameter.
Each
argument
creates
two
bytes
of
data.
Example:
MVI
ADDR,l,)FF
will move zero not )FF since the
data value is )OOFF.
MVS addressl,numberl,address2
This command causes a move to addressl of numberl bytes from
address2.
RBT address,number
This command resets (sets to zero) the bit at
specified
by
the
number
argument
in
the
specified address.

DNOS Tools

16-10

the
position
word
at
the

2270512-9701

DNOS System Design Document

RTE
the
current
The return with
error
command
returns
from
subroutine
to
the
second
command after the BRL which was
of
last encountered.
The stack is popped so that the value
STK
is
changed
to the location of the saved argument list
for the previous subroutine call (if any).
RTN
The return from subroutine command returns from the
current
subroutine to the first command after the BRL which was last
encountered.
As with RTE, the stack is popped.
SBR address,number
The
SBR
command tests the bit at the given position number
in the specified address and skips the next command
if
the
bit is reset (equal to zero).
SBS address,number
The
SBS
command tests the bit at the given position number
in the word at the specified
address
and
skips
the
next
command if the bit is set to one.
SBT address,number
This
command sets to 1 the bit at the given position number
in the word at the specified'address.
SCB numberl[,number2]
This command builds the SVC at the address specified by
the
first
argument,
with
the
argument
list beginning at the
second argument address, and executes the SVC.
If only
one
argument
is
specified,
then the currently existing SVC at
that address is executed.
(This
is
similar
to
the
SVC
command
except
that
the
address
is specified instead of
defaulting to location SVCB)
SEI address,numberl,number2[,number3 ••• ]
SRI address,numberl,number2[,number3 ••• ]
SLI address,numberl,number2[,number3 ••• ]
SNI address,numberl,number2[,number3 ••• ]
Each of these commands compares the string of length
numberl
at
the address specified with the value expressed in number2 through
the
last argument.
If the comparison succeeds, the next command
is skipped.
SEI causes a skip if the comparison is equal, SRI if
the first argument is high, SLI if the first argument is low, and
SNI if the first argument is not equal
to
the
immediate
data.
These
commands
are
not
meaningful
if command input is from a
terminal.

2270512-9701

16-11

DNOS Tools

DNOS

System Design Document

SES addressl,number,address2
SHS addressl,number,address2
SLS addressl,number,address2
SNS addressl,number,address2
Each of these commands compares the number of bytes specified
at
addressl
with the data at address2.
If the comparison succeeds,
the next command is skipped.
SES causes a skip if the comparison.
is equal, SHS if the first argument is high,
SLS
if
the
first
argument
is
low, and SNS if the arguments are not equal.
These
commands are not meaningful if command input is from a terminal.·
SVC

[number, ••• ]
If the argument list is null, the SVC currently
at
address
SVCB
is
executed.
If
an
argument list is presented, it
replaces the
data
currently
at
SVCB,
and
the
new
SVC
specified at SVCB is executed.

16.3.2

Directives of Tigress.

There
are
two directives which can be used to modify the manner
in which Tigress reads and processes commands.
These
directives
allow
for
buffering
of
Tigress
commands
to
reduce file I/O
interference for test instructions and test data.
Like
commands
they
consist
of
3
characters
and must begin in column 1 with
column 4 left blank.
Columns 5 through 80 may
contain
comments
and are ignored.
Directives are treated as commands and comments
by the jump and skip commands.
The directives are as follows:
BUF
this
directive Tigress proceeds to read
Upon
encountering
Approximately
200
and buffer commands in its memory space.
commands may be buffered.
UNB
Upon
encountering
this
directive
Tigress
discontinues
buffering commands and begins executing commands
in
memory
beginning with the first command buffered.
If
a
jump
is made from a buffered command to a command outside
the range of buffered commands the buffered mode is discontinued.
If a jump is made into an area
of
buffered
commands
buffering
mode
is
not initiated because Tigress did not encounter the BUF
command.
A BUF command following a BUF command but preceding the
UNB command causes no action.
An UNB command not preceeded by
a
BUF
command
causes
no
action.
While
in
buffering mode any
messages output by the MSG command will also be buffered.
If MSG
commands are included in a BUF-UNB. block
of
commands
then
the

DNOS Tools

16-12

2270512-9701

DNOS System Design Document

number of commands which may be buffered is reduced.
Echo output
while
in
buffer
mode i~ suppressed.
The DSP command output is
not affected by the buffet mode of operation.

16.3.3

User Defined Commands For Tigress.

When Tigress encounters a
command
it
searches
its
definition
table
and
if the command is found a BLWP is made with the value
of the command in the table being the address of the start of the
code to be executed for that command.
This method of implementing command execution enables the user to
define his own command as if if it were a Tigress
command.
The
procedure
for
doing
this is to equate a 3 character label to a
location at which code is to be executed.
By using MVI
commands
the
machine
code
is
placed
in
memor-y.
The
last
machine
instruction must be a RTWP ( )0380).
When the
code
is
to
be
executed
simply
enter
the label equated as a command.
Tigress
will search the table of equates and,
finding
the
label,
will
process
it
as
a
command.
This feature can be used for things
such as initiate mode I/O where a separate
call
block
must
be
built and executed.

16.4

THE SYSTEM DEBUG UTILITY

Since
it
is
not
always
possible or convenient to use the SCI
debugger or some other testing task, an interactive system
debug
program
is
available.
This program allows the user to display
and/or modify the workspace pointer, program counter,
registers,
and memory; to set as many as 16 software breakpoints in the code
being debugged, and to step through the code one instruction at a
time.
The program interacts with the user by doing I/O to a 911
VDT or an ASR device.
This program does not work on a 940 or 931
VDT.
About twenty-five commands are available for use with
the
debug
program.
Each command is specified by a single character.
When
the character is recognized as a command, the debug program calls
the appropriate processor, that may in
turn
require
additional
parameters
to
be
input.
Whenever
the program is expecting a
command to be
input,
it
prompts
with
a
question
mark
(?).
Parameters
that are entered are usually hexadecimal constants of
up to four digits.
A parameter is terminated by the fourth digit
or by a period or
Return
key
if
less
than
four
digits
are
specified.
If an invalid digit is typed, the entire parameter is
ignored
and
may be reentered for most commands.
In Some cases,
invalid input causes the debug program to terminate.

2270512-9701

16-13

DNOS Tools

I
I

DNOS System Design Document

16.4.1

Details of Debug Commands.

The entire set of commands and parameters is shown in Table 16-5.
Each command is detailed in the paragraphs that follow.
Commands
that allow the user to modify contents
of
some
location
first
display
the current value.
If no value is entered, no change is
made.
Table 16-4 shows the command
parameter
types
and
their
meanings.
Brackets indicate optional parameters.

Table 16-4

Parameter Types for Debug Commands

Type

Meaning

reI
adr
bt

Offset relative to the current base address
Absolute address in a task
Beet bias address for the segment being
addressed, located via map file information
carried in the TSB

NOTE
Breakpoints
should
not
be
used
on
instructions that change CURMAP (for example,
instructions that move something
to
the
OS
label
CURMAP) or on instructions that change
map file
(for
example,
LMF
Rn,O).
They
must
never
be
set
on
interruptable
instructions;
that
is,
XOP,
MOVS,
and
a
number of /12 instructions.

DNOS Tools

16-14

2270512-9701

DNOS System Design Document

Ta ble 16-5
Command

-------

Commands for

System Debug Program

Description

A adrl[ bt adr2]

Display and alter memory long
distance
B reI
Set a breakpoint relative to
current base
Display condition code in
C
status register
D a dr 1 adr2[ bt adr] Display memory long
distance
Examine locations relative to
E rell[ re12]
current base
F
Display and alter following
memory long distance
Inspect local memory
I [adrl adr2]
Show all local workspace registers
J
List all instruction breakpoints
L
Display and alter contents of
M adr
memory address
Display and alter contents of
N
next" memory address
Set add res s for bas e 0 f" reI a t i ve
0
offsets
Display and alter current program
P
counter
Quit debugging session
Q
Display and alter contents of
Rn
register n (Hex)
Set breakpoint at address in local
S adr
address space
Unset one or all breakpoints
U [adrJ
Display and alter address of
W
workspace pointer
Execute
a single instruction and
X
stop
Continue after current breakpoint
Z
Add the numbers nand m
+ n m
Subtract the number n from m
- n m
Display a menu of all commands
?

A -

Display and alter memory long distance
This command is used to display and alter memory that is not
mapped into the current task address space.
The form of the
command
is
A xxxx bbbb yyyy
where xxxx is the address of
the memory location to be displayed and altered and bbbb
is
the
starting
beet
bias of the segment in which the memory
'location resides.
The optional yyyy parameter
specifies
a
logical
address
at
which
the segment bbbb is supposed to

2270512-9701

16-15

DNOS Tools

DNOS System Design Document

start.
The appropriate beet bias can be determined from the
map file information in the task status block (TSB)
or
the
segment
status block (SSB) of the task being debugged.
The
bbbb and yyyy values default to their previous values.
B -

Set a breakpoint relative to current base
This command is valid only if the base address has been
set
correctly
using
the
0
command or the base address of the
program being debugged is zero.
The form of the command
is
B xxxx
where
xxxx
is
the offset from the base value at
which a breakpoint should
be
set.
When
the
program
is
executing
and reaches the breakpoint, all current workspace.
registers are displayed; and the debug program prompts for a
debug command.

C -

Display condition code in status register
The form of this command
is
C=xxxx yyyy
where
xxxx
is
displayed as the current contents of the status register and
yyyy
is
entered
by
the
user
as the new status register
contents.

D -

Display memory long distance
This command is used to inspect a portion of memory that
is
not
mapped
in the current task address space.
The form of
the command is D xxxx yyyy bbbb zzzz
where
xxxx
is
the
starting
address
of the to memory to be displayed, yyyy is
the ending address, and bbbb is the starting
beet
bias
of
the
segment
in
which this portion of memory resides.
The
bbbb
and
ZZ&Z
default
to
their
previous
values.
The
optional
zzzz specifies the starting logical address of the
segment at bbbb.
The beet bias can be
retrieved
from
the
task
status
block
(TSB)
of
the task being debugged (use
TSBML1, TSBML2, or TSBML3 depending on whether segment 1, 2,
or 3 is being examined), or use the SSB to get the
address.
Like
the
I command, this command displays memory in blocks
of )10 bytes, showing the starting address of each
line
of
the display.

E -

Examine locations relative to current base
This
command
is
valid only when the base address has been
set using the 0 command
or
the
starting
address
of
the
program
being debugged is zero.
The form of the command is
E xxxx where xxxx is an offset from the current
base.
_The
)20
bytes
of memory starting at the offset is displayed in
the same format as used for the I command.

F -

Display and alter following memory location long distance
This command can be used after an A command to
examine
the
following
memory location, similar to the N command is used
after an M command.

DNOS Tools

16-16

2270512-9701

DNOS System Design Document·

Inspect local memory
This command allows the user to inspect a
range
of
memory
locations
in the local task address space.
The form of the
command is I xxxx yyyy
where xxxx is the starting
address
of
the range to be inspected and yyyy is the ending address
of the range.
If an invalid address is specified, the debug
program will terminate.
Both the starting address and ending address
are
optional.
If
neither is specified, )20 bytes of memory are displayed,
starting
at
the
current
program
counter
address..
The
display
shows
)10 bytes per line of the display, preceding
the data with the first address of the data.
If
only
the
starting
address
is
specified,
)20
bytes
of memory are
displayed, starting at that address.
If both arguments
are
supplied,
a
multiple of )10 bytes is shown, starting at an
even address and including at least the amount specified.

Show all local workspace registers
This command displays all workspace registers on one line of
the display.

L -

List all instruction breakpoints
This command lists all
breakpoints
currently
set
in
the
program.
If an initial base address has been set using the
o command, this list includes the relative offset from the
base
for each breakpoint as well as the absolute address of
each breakpoint.

M -

Display and alter contents of memory address
This displays M xxxx=yyyy zzzz
where yyyy is
the
current
value
at
local memory address xxxx and zzzz is the desired
new value at that address.
Only addresses currently
mapped
in the task space may be modified with this command.

N -

Display and alter contents of next memory address
This command is used after an R, M, or another N instruction
to
display
and/or
alter the next memory address after the
address
examined
previously.
The
command
form
is
N xxxx=yyyy zzzz
where
xxxx
is the address displayed by
the debug program, yyyy is the current value,
and
zzzz
is
the new value supplied by the user.

o -

Set address for base of relative offsets
The
form
of
this
command
is 0 xxxx yyyy
where xxxx is
supplied by the debug program to show the current
base
and
yyyy
is
supplied
by the user as the new base.
After this
command has been used to specify the initial
address
of
a
program, the Band E commands can be used to set breakpoints
and
examine memory locations according to offsets from that
base.
This feature enables a user to work from an
assembly
language
listing
and
easily
determine
where
to
stop

2270512-9701

16-17

DNOS Tools

DNOS System Design Document

execution and where

to examine data.

P -

Display and alter program counter
This displays PC=xxxx yyyy
where yyyy is typed by the user
to indicate the new value desired for the program counter.

Q -

Quit debugging session
The Q command terminates the debug program.
If
the
debug
program
is
linked
as
part
of the operating system, this
causes the system to idle.
If linked with a user task,
the
Q command terminates that task.

Rn -

Display and alter register n
This displays Rn=xxxx yyyy
where yyyy is typed by the user
to indicate the new value desired in register n.

S -

Set a breakpoint
With
this
command,
the
user
can set a breakpoint at any
address currently mapped in the task space.
The form of the
command is S xxxx
where xxxx is the local
memory
address
at
which
execution
should
halt.
When the breakpoint is
reached, all current workspace registers are displayed;
and
the debug program prompts for a debug command.

U -

Unset one or all breakpoints
The
form
of
this
command
is
U xxxx
where xxxx is the
address at which a breakpoint has been set by either
the
S
or
the
B command.
The breakpoint specified is unset.
If
xxxx is not specified, all
currently
set
breakpoints
are
unset.

W -

Display and alter workspace pointer
This
displays WP=xxxx yyyy
where yyyy is typed by the user
to indicate the new value desired for the workspace pointer.

x - Execute a single instruction
This command allows the user to
step
through
the
program
being
debugged,
one
instruction
at
a
time.
After one
instruction is executed, all current workspace registers are
displayed;
and
the
debug
program
prompts
for
a "debug
command.
This command may not work predictably when used on
a breakpoint which is currently set.
Z -

Continue after breakpoint
When
this
command
is
issued, execution proceeds from the
current breakpoint to the next breakpoint, if there is
any.
Unless
a
U command
is used, the breakpoint that was just
used rema~ns in th~ code and can be reached again.

+ - Add numbers
The form of this command
is
+ xxxx yyyy zzzz
where
user types xxxx and yyyy and the debug program computes
as xxxx+yyyy.

DNOS Tools

16-18

the
zzzz

2270512-9701

DNOS System Design Document

Subtract numbers
The
form
of
this
command is - xxx x yyyy zzzz
where the
user types xxxx and yyyy and the debug program computes zzzz
as yyyy-xxxx.

- Display a menu
This displays the menu
of
all
available
debug
commands,
showing
the
characters required and an English description
of the commands.

16.4.2

Establishing the Debug Environment.

The system debugger can be added to the
disk
image
of
a
DNOS
system
by
executing
the
DEBUG
command,
located
in
the
.S$SYSTEM.S$$CMDS command library.
Before
executing
the
DEBUG
command, the following preparations should be made:
1. Verify that the DEBUG
procedure ID 1.

procedure

.S$SHARED

2. Make the two root segments on the

image
program
file
updateable.
This
can be done by issuing the XSCU and
QSCU
commands.
Issue
the
XSCU
command
with
the
following responses.
[]

XS CU

EXECUTE SYSTEM CONFIGURATION UTILITY
SYSTEM VOLUME:
SYSTEM NAME:

where:
An LDC listing appears.

Press the Command key.

Now issue the QSCU command with the following response:
[]

QS CU

QUIT CONFIGURATION UTILITY SESSION
ABORT?:

2270512-9701

16-19

DNOS Tools

DNOS System Design Document

3. Determine the illegal XOP WP and PC values
the LSM command with these responses:
[]

issuing

L SM

LIST SYSTEM MEMORY
OVERLAY NAME OR ID:
STARTING ADDRESS:
NUMBER OF BYTES:
LISTING ACCESS NAME:

ROOT
>SO
040

Record
the
first
two values starting at address OOSO
(for example, 2CA8, CS6A).
These are the
illegal
XOP
WP and PC values, respectively.
4.

Now you are ready to install the debugger.
to
give
access
to
the
DEBUn
command
S$SYSTEM.S$$CMDS, .S$CMDS).

S. Then enter
[]

Enter
( [
]

.USE
.USE

the DEBUG command:

DEBUG

ADD/REMOVE SYSTEM DEBUGGER
ADD/REMOVE/MODIFY?:
TARGET DISK/VOLUME:
SYSTEM NAME:
XOP LEVEL ( 0 - 14 ):
DEBUG TERMINAL CRU:
DEBUG TERMINAL TYPE:
ILLEGAL XOP
WP:
ILLEGAL XOP
PC:

alphanumeric
device name@
(*)
alphanumeric
(*)
integer
(1)
integer
(>100)
{9I1,KSR,ASR,VDT,EIA,TTY} (911)
integer
(>2C48)
integer
(>CS6A)

Use the debug command
to
add
or
remove
the
system
debugger from the disk image of a DNOS system, which is
located
in
program
file ..
The command may also
be
used
to
modify
the
operating
characteristics (for example, debug terminal
CRU address) of a previously installed system debugger.
PROMPT DETAILS:
ADD/REMOVE/MODIFY?
Enter ADD to add the debugger to a system.
Enter
REMOVE
to
delete
the
debugger
from
a system.
Enter
MODIFY
to
change
the
operating
characteristics of a previously added debugger.

DNOS Tools

16- 20

2270512-9701

DNOS System Design Document

TARGET DISK/VOLUME
Enter
the
name of~ the disk volume containing the
system to be debugged.
SYSTEH NAME
Enter the name of the system to be
changed.
The
system kernel image file resides on a program file
with the name 2C40) set by the B
instruction, will change.
6. Note the third word of
the
display
returned
by
the
DEBUG command.
This is the value which will be used as
the breakpoint instruction.
It should be equivalent to
the assembly language instruction
XOP RO,
where
fourth

2270512-9701

is
the number you entered for the
prompt of the DEBUG command.
Using listings and

16- 21

DNOS Tools

DNOS System Design Document

linkmaps, choose the address
of
the
task
(DSR,
SVC
processor,
etc.)
where
you wish to set your initial
breakpoint.
Use the MPI (or MRF) command to modify the
executable code image at that address
to
contain
the
value
noted
above.
Remember the proper value so that
the
instruction
can
be
be
restored
when
you
are
debugging.
7. Reboot the system or execute the task
or
whatever
it
takes
to
cause
entry
to the code of interest at the
selected address.
Use the M debug command
to
restore
the code at the initial breakpoint address, then set up
the debug environment that you require.
Use the X or Z
debug command to proceed with the execution of the code
to be debugged.

16.5

THE PICT UTILITY

The
PICT utility
is
used in the DNOS source library to create
tables from the assembly language templates to be used by
Pascal
code
and
to
generate
documentation
pictures
of the assembly
input, generating Pascal record descriptions and/or line- drawing
picture
files.
PICT is controlled by the use of macros (verbs)
in the assembly language input files.
These
macros
expand
to
appropriate
assembly
language
code
when
used with the macros
defined in the DNOS file .S$OSLINK.MACROS.TEMPLATE directory.
The PICT utility can be accessed by using the PICT command in the
.S$SYSTEM.S$$CMDS directory.
The
command
has
the
following
prompts, with descriptions as outlined below.
PICT (CREATE DATA TABLE PICTURE)
SOURCE FILE(S): filename
PICTURE FILE: [filename]
PASCAL OUTPUT FILE: [filename]
PAGE CONTROL?: (YES,NO,Y,N)

(YES)

Prompt Details:
SOURCE FILE(S)
Specify
the
file or files you want to have examined by the
picture processor.
If more than one file is specified,
the
files are concatenated and processed as a single file.
PICTURE FILE
Specify the pathname for

DNOS Tools

the picture file

16-22

to be created

2270512-9701

DNOS System Design Document

PASCAL OUTPUT FILE
Specify
the
pathname
statements.

for

the

file

of equivalent Pascal

PAGE CONTROL?
Specify NO if you want no embedded carriage control
in
the
picture
file
that is being built.
Specify YES if you want
carriage control.
If you specify YES, the picture file will
have a notation of (CONTINUED) after every 55 lines.
The complete set of verbs available with PICT is shown
16-6 along with the intended purpose of each verb.

Table

The
verbs
are
shown
with
brackets
[]
to
indicate optional
arguments and braces {} to indicate that a choice
must
be
made
from the indicated options.
.~

Since
the
assembly
language
macros automatically generate the
label xyzSIZ for the structure named xyz, users must avoid
using
their own labels of the same format.
The
verbs
are
used
in appropriate groupings to define various
types of structures.
The major structures are framed by DORG and
RORG, CSEG and CEND, and PCKREC and ENDREC.
The" first
pair
of
verbs
is
used
to
to
define
an
assembly language DSEG and a
corresponding Pascal packed
record
variable
declaration.
The
second
is used to define an assembly language CSEG (with data to
be
initialized
in
an
assembly
language
routine)
and
a
corresponding
Pascal
packed
record
variable declaration.
The
third pair of framing verbs provide an assembly language DSEG and
a Pascal packed record type declaration.
The
first
and
second
set of framing verbs are intended to be close to the work done in
assembly
language,
while the third set provides easy definition
of Pascal packed record structures with variants.

2270512-9701

16-23

DNOS Tools

DNOS System Design Document

Table

16-6

Verbs Used in Generating Structures

VERB
[label] ADDR)
[label] ARRAY
BITS
BSS
BYTE
CEND
[label] CHAR
COpy
CSEG
[label] DATA
DORG
ECHO
ENDREC
label
EQU
[label] EVEN
FLAG
[label] FLAGS
[label] INT
LIST
[label] LONG
PAGE
PCKREC
[label] POSINT
[ I a be 1] P TR
[label] REC
[label]
[label]

RORG
UNL
VARNT
[label] WORD

o
number of elements,
[comment]
{INT,LONG,POSINT,WORD}
or a type defined with PCKREC
[label,] number of bits [comment]
number of bytes
[comment]
o
[comment]
number of characters
filename
'label'

n or label

[comment]

[comment]
[comment]

[comment]
[comment]
[comment]
[comment]
[comment]
[comment]

[comment]

label

[comment]
[comment]
[comment]
[comment]

n or

label

{8,16}

o
type
type specified
by PCKREC above

n or label

[comment]
[comment]

The COpy verb is used to bring in a file before the PICT
utility
processes
the
entire input file.
If the input file refers to a
user-defined type or
constant,
the
appropriate
file
must
be
copied in to supply the definition.
Any number of COpy verbs may
be used, but they cannot be nested.
That is, a file may not copy
in a file which uses the COpy verb.
Most
of the other verbs can be used independently of each other,
and they can appear in any of the three framing verb
pairs.
An
exception
is
the set of verbs used to define flags fields.
The
verbs FLAGS,
FLAG,
and
BITS
must
be
used
in
a
relatively
restricted
fashion.
The FLAGS verb must appear first, defining
the number of flags being generated to be either 8 or
16.
This
can
be
followed
by
an
appropriate number of FLAG and or BITS
verbs to complete the field of 8 or 16.
The
entire
field
does

DNOS Tools

16- 24

2270512-9701

DNOS System Design Document

not
need
to be explicitly defined.
PICT will generate a filler
label and allocation in the Pascal structure,
and
the
assembly
language
macros generate only the required equates for the flags
defined.
For many of the verbs, the operand field is
optional.
However,
if a comment is used, the,operand field must be supplied to avoid
parsing part of the comment as operand.

16.5.1

Assembly Language Output.

The following paragraphs describe the effect of each of the verbs
for
the
assembly
language
output.
The
succeeding
set
of
paragraphs describe
the
Pascal
output,
and
a
third
set
of
paragraphs describe the picture output generated by PICT.

[ 1 abe 1] AD DR 0
This generates a one word integer
[label] ARRAY n,type
This
generates
an
optionally labeled field with a BSS for
the appropriate number of bytes to allocate n
instances
of
the type specified.
BITS

[label,]n
If
a label is specified, an EQU is generated with the label
equated to the current autogenerated bit number
within
the
FLAG field.

[ 1 a be 1] B S S 5
This is a

standard assembly language directive.

[label] BYTE 0
This is a standard assembly language directive.
CEND
This

is a standard assembly language directive.

[ 1 a be 1]

CHAR n
This generates a BSS for

the number of

characters specified.

COpy filename
This is a standard assembly language directive.
CSEG label
This is a standard assembly language directive.
[label] DATA 0
This is a standard assembly language directive.
DORG n or
This

label
is a standard assembly language directive.

2270512-9701

16-25

DNOS Tools

DNOS System Design Document

ECHO
This

is ignored.

ENDREC
This
terminates
a record definition begun with PCKREC.
generates a size equate aaaSIZ where aaa is the name of
packed record and an RORG 0 statement.
label EQU n or label
This
is
a
standard
BLOCK 3

assembly language directive.

It
the

RESERVE

[label] EVEN
This is a standard assembly language directive.
FLAG label
This generates an EQU, with the label equated to the current
autogenerated bit position
within
the
FLAGS
field.
The
first flag position is always position O.
[label] FLAGS {8,I6}
If the operand is 8, this generates a BSS 1.
is 16, it generates a BSS 2.

IF the

operand

[label] INT 0
This generates a BSS 2.
LIST
This is a standard assembly language directive.
[label] LONG 0
This generates a BSS 4.
PAGE
This is a standard assembly language directive.
PCKREC name
This
begins a packed record, indicated by a DORG O.
Notice
that if the packed record is to be assembled as well as used
with PICT, the structure name is limited
to
a
maximum
of
three characters.
[label] POSINT 0
This generates a BSS 2.
[label] PTR type of pointer
This generates a BSS 2.
[label] REC type
This
uses
the
aaaSIZ
equate built during processing of a
PCKREC to generate a BSS of the appropriate size.

DNOS Tools

16- 26

2270512-9701

DNOS System Design Document

RORG
This is a standard

as~embly

language directive.

UNL
This is a standard ,assembly language directive.
VARNT n or label
This generates a DORG n, where n is
the value of the label.

the

supplied

value

[label] WORD 0
This generates a BSS '2.
16.5.2

Pascal Template Output.

The
following
paragraphs
describe the output generated by PICT
for use in Pascal code.
In cases where a label is output to
the
Pascal
file
but
no
label
is supplied by the input line, PICT
generates a label of the form FILLxy where xy begins at 00 and is
incremented by 1 with each new filler label used.
In most cases, the comment found on an input line which generates
an output line is also found on that output line.
The exceptions
are output lines of PACKED RECORD, CASE INTEGER OF,
and
variant
labels.
Each
output file is intended to be unlisted in a Pascal program.
The first line is always (*$ NO LIST *)
and
the
last
line
is
always (*$ RESUME LIST *).
[label] ADDR
This generates:
label: ADDRESS; (ADDRESS is defined
DNOS file .TEMPLATE.PTABLE.TYPES as O •• #FFFF)
[label] ARRAY n,type
This generates:

label

in the

PACKED ARRAY [1 •• n] OF type;

BITS [labe1,]n
This
generates:
label: O •• m; where m is the maximum value
which can be expressed in n bits.
For example, BITS ALPHA,3
generates
ALPHA: 0 •• 7;
[label] BSS n
This generates:

labe,l

PACKED ARRAY [1 •• n] OF BYTE;

[label] BYTE 0
This generates:
label: BYTE; (BYTE is defined in the
file .TEMPLATE.PTABLE.TYPES as O •• #FF)

DNOS

CEND
This generates:

2270512-9701

END; for a CSEG file.

16- 27

DNOS Tools

DNOS

[label] CHAR n
This generates:

label

System Design Document

PACKED ARRAY[l •• n] OF CHAR;

COpy filename
This causes no Pascal output.
CSEC label
This
is
the beginning of a packed record named by the
label.
It
generates:
label = PACKED RECORD
(where
label has no quotes, though the CSEC label does)
[label] DATA 0
This
generates:
label: WORD; (WORD is defined
file
.TEMPLATE.PTABLE.TYPES as O •• #FFFF)

CSEC
the

in the DNOS.

DORC n or label
Depending on where it appears in an input file,
this
might
be
the
start
of
a
packed
record
or the beginning of a
variant in the packed record.
It is recommended that PCKREC
be used when creating new structures and that DORC
be
used
only
for compatibility purposes.
(DORC will also be needed
if the structure must have a starting location counter value
that is non-zero.)
When encountered the first time in a file, DORG 0
generates
xxx = PACKED RECORD
where xxx is the first three characters
in the next line with a label (unless that line has
an
EQU
directive,
in
which case it is skipped).
When encountered
in succeeding lines of the file, DORG generates a variant at
the
current
level.
Thus
several
DORC
statements
in
succession
with
the same operand will generate variants at
the same level.
A new operand on a succeeding DORC
defines
a
deeper
level of nesting.
It is necessary, of course, to
have all variants (and variants within variants) at the
end
of
the
structure
being
defined.
(See the description of
VARNT for further details.)
ECHO
The entire input file is ignored and
no
Pascal
output
is
generated other than the NO LIST and RESUME LIST directives.
The ECHO option is intended for files of equates needed only
for assembly language use.
ENDREC
This
generates:
construction.

END;

for

the

packed

record

under

label EQU n or label
This generates no Pascal output.
[label] EVEN
Th i s i s i g nor e d •

DNOS Tools

16-28

2270512-9701

DNOS System Design Document

[label] FLAGS {8,16}
This begins a flags
boolean values.
It
FLAG label
This identified a
[label] INT 0
This generates:

field,

that
is
label

gen~rates:

packed
record
PACKED RECORD

flag and generates: label
label

INTEGER;

label

LONGINT;

BOOLEAN;

LIST
This is ignored.
[label] LONG 0
This generates:
PAGE
This

is ignored.

PCKREC name
This generates:

name

PACKED RECORD

[label] POSINT 0
This
generates:
label: POSINT;
(POSINT is defined in the
DNOS file .TEMPLATE.PTABLE.TYPES as O •• #7FFF)
[label] PTR type of pointer
This generates:
label

@type;

[label] REC type
This generates:

type;

label

RORG
T his i sus edt 0 t e r min a t.e 'a pac ked r e cor d
It generates END;

s tar ted by DO R GO.

UNL
This

is ignored.

2270512-9701

16-29

DNOS Tools

DNOS System Design Document

VARNT n or label
This begins a variant of the current packed
record
at
the
current level if the operand is the same as the start of the
current level.
If the operand is not the same, a next level
of variant is begun.
This requires that variants be defined
in
correct
order
of
nesting.
That
is,
variants
of a
structure
(or
of
variants)
appear
at
the
end
of
the
structure.
At
the
first
VARNT
of
a
given
level, the
following is generated:
CASE

INTEGER OF
1: (

Succeeding variants at the same
level
generate
succeeding
integer
labels and open parentheses for the case statement.
Variants of variants generate a CASE statement and the label
1: ( for the
first
such
variant
and
succeeding
integer
labels and open parentheses for the following variants.
The
termination
of
the structure (ENDREC, RORG, or CEND) cause
the output of all required matching parentheses to close the
CASE(s) currently open.
[label] WORD 0
This generates:
label: WORD; (WORD is defined in the
file .TEMPLATE.PTABLE.TYPES as O •• #FFFF)
16.5.3

DNOS

PICT Picture Output.

The following paragraphs describe the output generated by PICT in
its
picture
output file.
Consult Figure 16-3 for an example of
some of the output generated.
Any
structure
that
must
output
more than four words of unlabeled blocks outputs a broken picture
but
maintains
an
accurate location counter value.
Fields that
must start on word boundaries do so, with the picture showing
an
unlabeled byte preceding that word boundary.
Each
line
of
the picture carries the associated comment of the
input line, as well as portraying the space occupied by the
verb
in
use on that line.
Some input lines do not affect the picture
but are used for information which appears
after
that
picture.
Flag details, equate information, and special comments follow the
picture.
A PAGE verb must appear at the end of the input file to
cause
output
of
flag
details, equate information, and special
comments.
[label] ADDR
This outputs a labeled block of one word on a word boundary.
[label] ARRAY n,type
This generates a labeled block of one
byte
(if
the
array
occupies only one byte or begins on an odd byte boundary) or
DNOS Tools

16-30

2270512-9701

DNOS System Design Document

a
labeled
block
of one word,
filling out the structure.

followed by unlabeled blocks

B.I T S [la be I , ] n
This generates an entry in the equates listing at the end of
the picture file, specifying the label and its
location
in
the structure.
[label] BSS n
This
generates
a
labeled block of one byte in the diagram
and an appropriate number of unlabeled blocks.
[ I a be 1] BYTE 0
This generates a

labeled block of one byte.

CEND
This is ignored.
[label] CHAR n
This
generates
a
labeled
block
of
appropriate number of unlabeled blocks.

one

and

byte

COpy filename
This is ignored.
CSEG label
This
is
assumed to occur only at the start of the picture.
Thus all initial conditions hold -- the location counter
is
zero, no output is generated.
[label] DATA 0
This
generates
boundary.

labeled

block

one

word

on a word

DORG n or label
This
sets
the
location
counter
to
the
operand
value,
terminates
any
picture in progress, outputs the comment on
the DORG line, and sets conditions to start another
picture
segment (indicated by

*----------+----------*).

ECHO
This
causes
the
entire
input
file
to be written to the
picture file as it is read.
It is
assumed
to
be
a
file
which otherwise generates no meaningful picture.
ENDREC
This
finishes
a
picture section, drawing a line below any
partially completed block and outputting
the
size
of
the
packed
record
just completed.
It also outputs the message
**END OF PACKED RECORD.
label EQU n or label
This generates a

2270512-9701

line of output in the

16-31

listing

equates

DNOS Tools

DNOS System Design Document

which follows the picture.
[label] EVEN
If
the
picture
is
currently
not
at a word boundary, an
unlabeled block of one byte is output.
[label] FLAGS {8,16}
A labeled block of one byte is output if the operand is 8; a
block of one word on
a
word
boundary
is
output
if
the
operand is 16.
FLAG label
This
generates
an
entry
in
the flags descriptions which
follow the picture.
Each flag is shown
with
its
relative
position in the field as well as any comment describing that
flag.
Comments
on lines following the FLAG input line are
also echoed in the flags description in the
picture
output
file.
[label] INT.O
This
generates
boundary.

labeled

block

one

word

on a word

LIST
This

is ignored.

[label] LONG 0
This generates two words, with the first
label and appearing on a word boundary.

word

carrying

the

PAGE
This
is used to determine that the end of the structure has
been reached.
It causes flags and equate descriptions to be
output.
Any comment lines which follow the PAGE
line
will
be
output
at
the
end
of
the
picture listing under the
heading COMMENTS ON THIS STRUCTURE.
This verb
is
REQUIRED
in
order
to
output
flags
and equates information to the
picture file.
PCKREC name
This begins a picture section, with the location counter set
to zero.
It outputs a line with **BEGINNING
PACKED
RECORD
name.
[label] POSINT 0
This outputs a

labeled block of one word on a word boundary.

[label] PTR type of pointer
This outputs a labeled block of one word on a word boundary.
[label] REC type
This
outputs
a
labeled
word
on
a
word boundary and an
appropriate number of
unlabeled
blocks
to
encompass
the

DNOS Tools

16-32

2270512-9701

DNOS System Design Document

total

required by the type specified.

RORG
This

is ignored.

This

is ignored.

UNL
VARNT n or label
This finishes the current picture section, sets the location
counter
to
the
operand
specified,
and
initiates
a new
section.
It outputs any comment on the VARNT input. line.
[ I a be I] WO RD 0
This outputs a labeled block of one word on a word boundary.
16.5.4

Input Format.

The input file may be in one of several forms, one
of
which
is
shown
in
Figure 16-1 and another which is shown in Figure 16-2.
The name of the structure is shown as aaa.
The heading
comments
are
of the form used for DNOS structures and are not enforced by
the PICT utility.
Any comments that precede the first
structure
verb
appear
in the output files before the structure.
Comments
to be printed at the end of the picture file must appear after
a
PAGE statement.
Figure
16-3 shows the format of the picture drawn by PICT.
line of the drawing is preceded by the
hexadecimal
offset
the template.
Each field carries its own label.

2270512-9701

16-33

Each
into

DNOS Tools

DNOS System Design Document

UNL
************************************************************

*
*
**

«aaa»

*
*
*

LOCATION:
************************************************************

PCKREC name

descriptive comment

descriptive comment
ENDREC

PAGE
LIST
Figure 16-1

PCKREC Input Format

UNL
************************************************************

*
*
*
*

«aaa»

*
*
*

LOCATION:
************************************************************

DORG or
CSEG 'label'

descriptive comment

aaaSIZ EQU
$
RORG
PAGE
LIST

or CEND

Figure 16-2

DNOS Tools

descriptive comment

DORG Input Format

16-34

2270512-9701

DNOS System Design Document

00
>02

structure verb>

*----------+----------*
.
!
+----------+----------+

+----------+----------+

!
*----------+----------*

>mn!

FLAGS FOR FIELD:
= (x •••

.... #mm
.... - •
••• ) -

= ( •• x • • • • • • • • • • • • • )

#nn

16.6

field>

EQUATE

Figure 16-3

VALUE
#mm

DESCRIPTION

Template Picture Format

THE JENDAT EDITOR

The
JENDAT
editor
is used to edit the JENDAT file used by DNOS
system generation.
It includes
commands
to
show
the
current
content
of
the JENDAT file, to edit any field, to format a file
for printing, to remove records from
the
file,
to
change
the
version number of the file, and to e~it the JENDAT editor.

16.7

XJENED Command Procedure

The
DNOS
JENDAT
editor
is invoked from SCI through the XJENED
command procedure.
No prompts are included.
The program expects
to find a value for synonym JENDAT, which specifies the file that
the
editor
edits.
The
normal
value
of
the
synonym
is
.S$SGU.JENDAT.
If
the
synonym
is
not
defined, a file named
.JENDAT@$ST is created (where SST is
a
synonym
for
the
users
station ID).
This file is empty and does not produce the desired
2270512-9701

16-35

DNOS Tools

DNOS System Design Document

results.
This error is easy to detect.
A SHOW or REMOVE command
responds
with
NUMBER OUT OF RANGE in the error field.
The EDIT
command responds with NEW RECORD
to
any
entry
in
the
record
number
field.
Quit
the
edit
and
assign the proper value to
synonym JENDAT.
The program
also
expects
a
value
for
synonym
PFILE,
which
specifies
the
file
used
for producing a formatted copy of the
JENDAT file.
This data goes to .PFILE@$ST otherwise.
This
file
should be precreated with a logical record length of 132.
If the
file
has
a
logical
record length 'less than 132, the file will
have twice the normal number of records.
For example, the
first
line
becomes
two
lines,
the first containing the numeric data
from the JENDAT record, the second containing the
text
portion.
The file contains escape sequences that compress the print of the
810
printer
and then restore it for normal operation at the end
of the file.
The file should be printed with 82 lines per page.
NOTE
The DNOS JENDAT editor requires
a
911
VDT.
Otherwise, it will not function properly.

16.8

JENED Commands

The
commands
available
file are as follows:

for

the maintenance of

the DNOS JENDAT

COMMAND

MEANING

EDIT
PRINT
QUIT
REMOVE
SHOW
VERSION
MOVE

Edit any field of a record)
Format a file for printing)
Exit the JENED editor)
Remove records from the JENDAT file)
Show the text of the JENDAT records)
Change the version number of the JENDAT file
Relink records of the file

The JENED program begins with a display of the main
menu,
which
lists
the
commands
available to the user.
The main menu is as
follows:

DNOS Tools

16-36

2270512-9701

DNOS System Design Document"

SELECT ONE OF THE FOLLOWING :
P - PRODUCE A FILE FOR PRINTING
V - CHANGE VERSION NUMBER OF JENDAT
R - ZERO FIELDS OF JENDAT RECORDS
S - SHOW TEXT OF JENDAT RECORDS
E - EDIT FIELDS OF JENDAT RECORDS
M - RELINK JENDAT RECORDS

Q - QUIT
COMMAND :
The character entered does not terminate the
the
command,
the user must hit
RETURN.
ignored.
16.8.1

call.
To process
Invalid entries are

EDIT Command.

When the EDIT command is entered, the menu field is
replaced
the editing template.
The following is an editing template:

EDIT RECORD NUMBER

• • • • • • • • • 1 • • • • • • • • .2. • • • • • • • .3. • • • • • • • .4. • • • • • • • .5. • • • • • • • .6. • • • •
DEF

AAT

The
number entered is a decimal number.
A zero entry or empty
entry places the editor in the append mode.
As a
result,
the
first
field
indicates
that a new record is being entered.
The
first field is modified as follows:
EDIT RECORD NUMBER

NEW RECORD

The text field
is
initialized with blanks.
The
first
four
numeric
fields
are initialized with 0000, and the NEXT field is
initialized to the record number of
the
record following
the
current record.
If an error is detected in the field,
is displayed:

the following error message

EDIT RECORD NUMBER 12AE
ERROR IN NUMERIC FIELD
If
the
record number is larger than that of the last record of
the current file, the editor enters the insert mode.
The
record
displayed is one larger than the last record, and the message NEW
2270512-9701

16-37

DNOS Tools

DNOS System Design Document

RECORD
is
displayed.
If
the
record
number
exists,
the
corresponding
data
appears
on
the
screen.
The
cursor
is
positioned
in
the
first
column of the text field when a valid
record number has been chosen.
The JENDAT editor requires a call termination character for
each
that
is
issued.
The valid termination characters, which
read
vary with the call that is outstanding, are as follows:

*
*
*
*
*
*
*
*
*
*

CMD
RETURN (SKIP)
ENTER
Up Arrow
Down Arrow
Fl (function key 1 )
F7 (function key 7 )
F8 (function key 8)
TAB
Left Field

CMD Key
The CMD always returns the user to the main
menu
from
the
edit mode, whether editing existing records or inserting new
records.
The current record is never updated with the data
on the screen.
RETURN Key
The RETURN key causes the call to
progress
from
the
text
field
to
the
DEF field, then to AAT, LB, VB, and NEXT, in
that order.
When the RETURN key is entered
from
the
NEXT
field,
the
data
on
the screen is moved to the file.
The
next physical record is entered on the display, and
a
read
is
issued
to
the
text field.
The record number field is
updated to the record number of the data that is
displayed.
The SKIP key causes the same effect as RETURN but blanks out
the
remainder
of
the
field.
This
produces
acceptable
results in the record number field and the
text
field
but
should be avoided in the numeric fields.

DNOS Tools

16-38

2270512-9701

DNOS System Design Document

NOTE
The
JENDAT
file is not a forced write file.
Therefore, the data is moved
to
the
memory
buffer
that
will
be
written
by
file
management
when
necessary
to
free
buffer
space.

ENTER Key
The ENTER key causes the data on the screen to be written to
the
file.
The
next
physical
record is entered into the
display, and a read is issued for the text
portion
of
the
record.
Down Arrow Key
Arrow
key
causes the next physical record to be
The
Down
The file is not altered in any manner.
displayed.
Fl Key
Function key
Fl
causes
the
next
logical
record
to
be
displayed
(that
is,
the
record
whose -record
number is,
currently displayed in the NEXT field).
No data is
written
to the file by this key.
F7 Key
Function
key
F7
causes. the editor to enter the find mode
when entered in any field of the record.
The
message
FIND
MODE
is
displayed,
and
the
record
displayed
is empty.
Altering any field causes all records of the JENDAT file
to
be
searched
for a record that matches in all of the chosen
fields.
If
no
match
is
found,
the
editor
returns,
displaying
the
NEW
RECORD message at the end of the file.
This indicates that the search failed.
If
the
record
is
found,
the
editor returns to the edit mode, displaying the
record that it found.
The text field is searched
only
when
nonblank
characters
are
entered
in
the
text
field
when
the
FIND
MODE
message
is
displayed.
A numeric field is searched when
the
field
is
the
search.
Entering any other valid termination characters returns
the editor to edit mode at the displayed record number.
F8 Key
The F8 key returns to the record number field.
This permits
the user to jump from editing record
number
15
to
record
number 65 by entering F8, followed by 65, and RETURN (SKIP).
TAB Key
The

TAB

2270512-9701

key

acceptable
16-39

only

in the text

field.

Tab

DNOS Tools

DNOS System Design Document

settings are fixed at 1, 8, 13, 31
and
76.
Entering
TAB
causes the read to be reissued at the next tab setting.
The
fields
rotate;
that
is,
a
TAB
key entered at column 76
returns to column 1.
TAB is not
accepted
in
the
numeric
fields.
Left FIELD Key
The
Left FIELD key acts as a reverse tab in the text field.
A Left FIELD issued from column 1 is ignored and returns
to
column
76.
In
the
numeric
fields,
pressing Left Field
causes a return to the previous field, including a return to
the text field from the DEF field.
If an error is detected in a numeric field, the message ERROR
IN
NUMERIC
FIELD
is
displayed.
When the error is corrected, the
m~ssage disappears.
Entering CMD corrects
the
error
condition
but also returns the user to the main menu~
Some errors will not
be detected.
The RIFLE DECODE procedure terminates the scan when
it
finds
letters
while
decoding
a
hexadecimal field.
Thus,
entering OlWQ in a hexadecimal field places 01 in that field.

16.8.2

PRINT Command.

Entering the PRINT command produces a
file
for
printing.
The
display
is informative only, displaying the record number of the
file currently being processed.
16.8.3

QUIT Command.

Entering QUIT closes the JENDAT file
and
updates
record
0
to
reflect
the
current version number and number of records in the
file.

16.8.4

REMOVE Command.

Entering REMOVE displays the following message:
REMOVE RECORDS
FROM

ARE YOU SURE?

The numbers entered are validated
and
may
produce
either
the
NUMBER
OUT
OF
RANGE
message
or
the
ERROR
IN NUMERIC FIELD
message.
If the response to ARE YOU SURE?
is
Y,
the
records
from
the
first
number to the _second are deleted.
This removes
the text and enters zero in each numeric field except NEXT, which
has the next physical record.
To return to the first field
from

DNOS Tools

16-4~

2270512-9701

DNOS System Design Document

the
second,
enter
the
Left
FIELD
key.
This requires that a
number for the second field be entered.
If
the
fill
character
( ) fills the field, the Left FIELD key is not accepted.
16.8.5

SHOW Command.

The SHOW command produces the following prompt:
SHOW TEXT FROM RECORD
The
field
is
validated;
and if
records beginning with that record
22 records is displayed.
If less
number entered, only those records

it is correct, the text of the
and extending through the next
than
22
records
follow
the
that exist are displayed.

This command accepts the up arrow, down arrow, Fl, and F2 keys in
the
same fashion as SHOW FILE.
F6 is a toggle switch that rolls
the file horizontally.
16.8.6

VERSION Command.

The VERSION command produces the following prompt:
VERSION NUMBER 01
The number shown is the
version
number
checked
by
SYSJEN
to
verify
compatibility.
The
number entered replaces the current
one.
No error checking is done.
16.8.7

MOVE Command.

The MOVE command produces the following prompt:
MOVE A RECORD
INSERT RECORD

BETWEEN

AND

This command causes the first record
to
be
logically
inserted
between
the
second
and
third
records.
All
records
which
originally pointed to the first record, now point to the
logical
successor of the first record.

2270512-9701

16-41/16-42

DNOSTools

DNOS System Design Document

SECTION 17
ANALYZING A SYSTEM CRASH

17.1

OVERVIEW

When
DNOS detects a system failure, it displays an error code in
the lights of the front panel and idles the CPU.
To analyze
the
problem,
copy
the
memo~y
image
to
the predefined crash file
.S$CRASH on the system disk by pressing HALT and then RUN on
the
programmer
panel.
When
activity ceases, and the error code is
redisplayed, perform an initial program load
by
pressing
HALT,
and LOAD.
When DNOS is ready, log on to a terminal and study the
crash file using the crash analysis utility.
The crash analysis utility can be used to study a crash file or a
running
system.
The paragraphs that follow discuss the commands
available with the crash analysis
utility
and
tell
when
each
command
is
useful.
In addition, guidelines are presented for
analyzing several particular system crash conditions.
The crash analysis utility is invoked with the XANAL
command
SCI.
The XANAL command procedure is of the following format:
XANAL
EXECUTE CRASH ANALYSIS UTILITY
CONTROL ACCESS NAME: pathname@
LISTING ACCESS NAME: pathname@
ANALYZE RUNNING SYSTEM: YES/NO
CRASH FILE NAME: pathname@

(ME)
(ME)
(NO)
(.S$CRASH)

The prompts and responses are described in detail below.
CONTROL ACCESS NAME
This
field
prompt
asks for the access name of the file or
device that will be used to issue commands to
the
utility.
Most
often~ the initial value is accepted, and commands are
input from the
station
at
which
the
XANAL
command
was
issued.
In
certain
cases, you may want to use a standard
set of analysis commands from a file.
If so,
each
command
must start in column 1 of a separate record of the file.
LISTING ACCESS NAME
If
the crash analysis is to be written to a file, specify a
file name.
If the station is to receive the listing, accept
the initial value.

2270512-9701

17-1

Analyzing a System Crash

DNOS System Design Document

ANALYZE RUNNING SYSTEM
Accept the initial value of NO if
you
wish
to
examine
a
crash
file on disk.
Enter a YES to analyze portions of the
running system.
CRASH FILE NAME
When examining a running system, accept
the
initial
value
for
this
prompt.
When analyzing a crash dump, specify the
name of the file.
Each time a system crash dump occurs, the
information is written to the file .S$CRASH
on
the
system
disk.
To protect a crash file from being overwritten, copy
it to a new file using
the
CD
(Copy
Directory)
command.
Specify
.S$CRASH as
the
input
pathname
and the desired
directory as the
output
pathname.
Upon
completion,
the
crash
file
will
be
found as S$CRASH within the directory
specified.
crash
analysis
When the
used
the
utility
is
interactively,
listing
comes
the
at
to
screen
pace.
a
rapid
To stop the
display, press the Attention key; to resume
the
press
display,
Attention
key
the
again.
To exit a command display, press the
Command key.
The ANALZ task is an RBID task, therefore you can enter and
exit
the
analysis of a crash to use SCI.
Table 17-1 shows the set of
commands used with ANALZ to examine a running system or
a
crash
file.
The
commands
are
described in detail in the paragraphs
which follow.

Analyzing a System Crash

17-2

2270512-9701

DNOS System Design Document

Table 17-1
Command
ALL
AQ
CCB
OM
FCB
GI
JSB
LOT
MM
OVB
PBM
PDT
PQ
QU
ROB
RPB
SGB
SSB
ST
TA
TR
TS
TSB
11

17.2

C~ash

Analysis Commands

Display Contents
Displays from all the commands
Contents of task active queue
Channel control blocks
Specific area of memory
File control blocks
General information
Job status blocks
Logical device tables
Memory maps
Overhead beets
Partial bit maps
Physical device tables
System queues (other than active
No display; terminates session
Resource ownership blocks
Resource privilege blocks
Segment group blocks
Segment status blocks
Secondary table areas
Task areas in memory
Registers for all tasks
Task status
Task status blocks
List of all available commands

qu~ue)

DETAILS OF CRASH ANALYSIS COMMANDS

When analyzin* a crash, th~ initial step should be to examine the
general information about the crash, followed by
an
examination
of
task
states
and
then
of
the
detailed
information about
particular queues and data stuctures.
First issue a GI
command,
then
a
TS
command, and then the relevant structure examination
command.
All of the commands and their parameters are
presented
in alphabetic order in the following paragraphs.
ALL
This
co~mand
lists
the
information
for all the commands
available.
It is frequently used to process a crash file to
a listing file
which
can
then
be
sent
to
someone
for
inspection.
When the ALL command is processed, it generates
output
for
the
commands in this order:
GI, TS, JSB, TSB,
SGB, SSB» PDT, FeB, LOT, ROB, CCB, MM, OVB, AQ, PQ, ST,
TR,
and TA.

2270512-9701

17-3

Analyzing a

System Crash

DNOS System Design Document

AQ
This
command causes the display of three lists, the list of
tasks on the active queue, the list
of
tasks
waiting
for
system
table
area, and the list of tasks on the waiting on
memory queue.
Each list shows the
JSB
address,
priority,
TSB address, and IDs for the tasks involved.
If the queues are empty, the system was idle.
If the queues
have
many
entries,
the
system was
busy.
Scanning the
queues, you can see what tasks were eligible to
execute
or
be
loaded
into
memory.
This information is helpful when
forcing a crash during a situation where the system appears
to be idle or hung in a loop.
CCB
This
command
shows
the
channel
control
blocks
for all
channels currently
in
use.
It
first
shows
the
global
channel
list
from the system table area then the job local
list from the JCA of each job in the system.
Each job local
list is identified by its JSB address.
DM
Before displaying memory,
following:
LOWER LIMIT
UPPER LIMIT
JSB ADDRESS
TSB ADDRESS

this command solicits data for

the

the starting address (rounded to even number)
the ending addres~
a JSB address, an SSB address for any SSB, or 0
the TSB address for the task memory being
displayed
or PDT ADDRESS - the PDT address of a device being viewed
or BEET BIAS - for any beet in memory
If the answer to the
JSB
ADDRESS
prompt
is
0,
the
PDT
ADDRESS
prompt
appears.
If the answer to the PDT ADDRESS
prompt is 0, the BEET BIAS prompt appears.
The first time DM is used, the prompt for LOWER LIMIT is
O.
After the first time, the prompt has an initial value of the
previously used LOWER LIMIT.
The UPPER LIMIT is initialized
with
a
value
)2E greater than the LOWER LIMIT value.
The
default listing is a three-line
display
of
)30
bytes
of
data, each line preceded by the address of the first word on
that
line.
The
data is shown in hexadecimal and in ASCII
equivalent.
Initial values for JSB ADDRESS and TSB
ADDRESS
are
the values used previously, after the first DM has been
specified.
To examine a physical TILINE address, specify the address as
LOWER LIMIT, and specify zero for all other fields of the DM
command.

Analyzing a System Crash

17-4

2270512-9701

DNOS System Design Document

FCB
This
command
causes
a
display
of
all
in-memory
file
structures
for files currently in use.
It presents the set
of structures for each disk device defined for
the
system,
showing for each file the FDB, FCB, and SAT.
GI
General
information about a crash is shown by this command,
including all of the following for analysis of a crash file.
For analysis of a running system, the information
beginning
with SYSTEM PATCH AREA is presented.
VERSION
The
release/version/revision
level
of the system or crash
file being analyzed is
shown
here.
This
field
provides
verification of the current level of software in use.
CRASH CODE
The code is shown as a four-digit hexadecimal value.
If the
crash
code
is one of those included in internal tables, an
English description of the code is also output.
Details
on
system
crash
codes
are
provided in the DNOS Messages and
Codes Reference Manual.
EXECUTING TASK
The next item displayed is the TSB address of the
executing
task
at the time of the crash.
If the TSB address is shown
as 0, there was no executing task at the time of crash.
The
error was probably within
the
operating
system
during
a
scheduling cycle.
If
the crash was an end action crash, this field identifies
the task which took end action.
If the
crash
was
forced,
this
field identifies the task which was in a loop when the
crash occurred.
The information here may not be useful
for
crashes in the range )13 through )IF (illegal interrupts) or
for the )60 series crashes (operating system failures).
EXECUTING TASK JSB
This
displays
the address of the JSB of the task executing
when the crash occurred.
Paired
with
the
EXECUTING
TASK
data,
it
identifies
the task executing at the time of the
crash.
LOCATION OF FAILURE
This is the address from which the crash routine NFCRSH was
called
or,
in
some
cases,
the
location
of
an illegal
instruction or other cause of the crash.
For crashes in the )60 series, this is not
useful.
For
a
)29
crash
(unexpected error return), this field identifies
whether NFPOPO or NFRTNO encountered the error.
2270512-9701

17-5

Analyzing a System Crash

DNOS System Design Document

STATUS REGISTER AT TIME OF FAILURE
This shows the contents of
the
status
register
when
the
crash
occurred.
Bit 8 indicates whether the error occurred
while executing in map file 0 (bit 8=0) or
in
map
file
1
(bit
8=1).
The last four bits show the interrupt mask.
If
the interrupt mask is less
than
(IS,
the
error
probably
occurred
in
a DSR or in the clock interrupt handler.
This
display is not useful for )60 series crashes.
JCASTR
This is the starting address of all
JCAs
area second segments mapped in by DNOS.

and

other

table

COUNTRY CODE
This entry shows the country code of the system.

IMAGE NAME
The
name
shown.

the kernel program file

that was executing is

MEMORY SIZE
This shows the total memory available to
the
system while
operating.
This
value
is less than or equal to the total
physical memory available.
CRASH FILE SIZE
This shows the size of the crash file in use.
If
this
is
not as large as MEMORY SIZE, Some portions of the crash dump
will
be
missing,
and the following message will appear at
the start of the GI display:

***

I
I

WARNING

***

ALL MEMORY NOT IN DUMP FILE

This generally means the dump is
not
increase the size of your crash file.

useful.

You

should

CURMAP ADDRESS
This
entry
shows the address of the current map 0 map file
at the time of the crash.
Bias
values
might
be
used
to
examine
portions
of
memory.
This field is not generally
useful if the crash occurred in map file 1.
SYSTEM PATCH AREA
This shows the system patch
area
in
hexadecimal
and
the
ASCII
equivalent.
The area might be scanned to ensure that
all appropriate patches have been
applied
to
the
system.
The starting address of the patch area should be the same as
the symbol NFPATCH in the system link map.

Analyzing a System Crash

17-6

2270512-9701

DNOS System Design Document

EXECUTING WORKSPACE AT TIME OF DUMP
These registers are the workspace registers of the executing
code at the time of the crash.
If the crash occurred in map
file
0,
this area shows the true contents of the registers
at the time of the crash.
If the crash is for a task taking
end action, these registers are
those
of
its
end
action
workspace,
which
mayor may not be those in effect at the
time the error occurred.
TOP 64 WORDS OF CURRENT STACK
This display assumes
that
register
10
of
the
executing
workspace is a stack pointer.
The utility displays 32 words
preceding
the address in register 10 and 32 words following
the address in register 10.
This data is most useful if
0, or in a system task.

the crash occurred in

map

file

If
the executing code does not use the stack, this area may
be useless.
Unused memory appears as initialized
to
)FOOD
values.
HARDWARE TRAP VECTORS
The
hardware interrupt vectors occupy the first 32 words of
physical memory and are defined
during
system
generation.
These
vectors
should
not be changed unless destroyed by a
system task that
branches
to
location
0
by
mistake
or
modifies
location
when using an incorrectly established
address
field.
If
a
BLWP
instruction
is
executed
to
location
0,
the
return context information of the calling
task is stored in locations )IA through )IF.

When the crash code is for an illegal interrupt ()13 through
)1F), these vectors are meaningful and
should
be
examined
carefully.
When
a
crash code for internal interrupt ()60
through )6F) occurs and the interrupt mask in register 15 of
the trap 2 workspace indicates
a
defined
interrupt
(mask
value
minus
one),
the
interrupt
trap
values
should be
checked to determine if they are within range.
The
correct
values
can
be
determined by examining locations 0 through
)3F of procedure ROOT in the kernel program file.
XOP VECTORS
The XOP vectors occupy
the
second
32
words
of
physical
memory
and
are
defined
during
system generation.
These
vectors should not be changed unless destroyed by
a
system
task
in
error.
Their
correct values can be found in the
same way as the HARDWARE TRAP VECTORS values.

2270512-9701

17-7

Analyzing a System Crash

DNOS System Design Document

CLOCK INTERRUPT WORKSPACE
This area shows one
of
the
two
clock workspaces.
This
display
workspace
shows
the
current
state
of the clock
interrupt processor.
Registers
13
through
15
show
the
return
context
of
the
last
entry to the clock interrupt
processor.
When a crash is
forced
during
a
system hang
condition,
this
workspace
may point to the location of an
infinite loop in a task, that is, the location at which
the
last clock interrupt occurred.
MACHINE ERROR (TRAP 2) WORKSPACE
This workspace contains diagnostic information about a crash
for
internal
interrupts (>60 through >6F).
The context of
the crash can be found in registers 13 through 15.
If bit 8
of register 15 is set to
1,
the
error
occurred
in
task
driven
code
(map file 1).
If bit 8 is set to 0, the error
occurred in system code (map file 0).
Register
1 of
this
workspace
carries
a
status
code, reflected as the second
digit
of
the
>60
series
crash.
A >62
crash
can
be
recognized as a forced crash if R14 points to an instruction
whose
preceding
instruction is a zero.
If R14 has a value
less than that of JCASTR, the error occurred
in
the
root.
Otherwise, if in map file 0, check the CURMAP address of the
GI
information
against
a
system link map for the" correct
segment of code.
If executing in map file
1,
consult
the
appropriate task link map for the correct segment of code.
TRAPPED WORKSPACE
This
workspace
is
found
using
workspace as the starting address.

R13

of the machine error

LOCATIONS AROUND TRAPPED PC
This display shows the 16 bytes before and
16
bytes
after
the address found in R14 of the machine error workspace.
SVC (XOP 15) WORKSPACE
This
workspace
is
used
by
both
the
scheduler
and SVC
processing.
The workspace contains the
current
state
for
whichever
of
those
processors last used it.
Registers 13
through
15 may
contain
the
return
context
(workspace
pointer,
program
counter,
and
status)
from the last SVC
issued by a task.
If the crash occurred in map file 0, this
workspace is
probably
the
executing
workspace.
If
the
workspace
is
not
that
of
the scheduler, it may be a DSR
workspace; if the starting address is in one of the PDTs, it
reflects the workspace of a DSR.
JSB
This command displays the job status blocks for every job in
the system.
The last JSB presented is that for
the
system
job.

Analyzing a System Crash

17-8

2270512-9701

DNOS System Design Document

LDT
This
command displays, with appropriate headers, all global
LDTs, followed by
all
job-local
LDTs
identified
by
JSB
address,
and
finally all task-local LDTs identified by TSB
and JSB addresses.
MM
Memory map information, specifying starting address, length,
current use, highest
address,
and
free
block
chain,
is
presented for each of the following:

*
*
*

System table .area
Special table areas for segment management and for
file management
Job communication areas for each job in the system

Information is then presented on user memory available, both
that
available
to
be swapped and that not available to be
swapped.
This is followed by tables
of
linked
lists
for.
these structures:

*
*
*
*
*
*

Free list of user memory
Deallocate queue
Time ordered list
Cache queue
Write queue
Buffer table area free list

The
MM
information
is especially useful for analyzing )21
(inconsistent
free
user
memory
structure),
and
)22
(inconsistent table area structures) crashes.
OVB
For each segment in memory, there is an overhead beet (OVB).
This
command lists all OVBs first by SSB address within the
segment manager tables 0 and
1.
Several
of
the
initial
segments
in
this
list
do not have an OVB associated with
them (these are
segments
of
resident
DNOS).
For
these
segments,
the
beet
preceeding the segment is displayed as
the OVB, and will appear as an inconsistent structure.
Then
the OVBs are listed in sequence in memory order.
This
list
is
useful
to
scan
the integrity of structures when a )21
(inconsistent
free
user
memory
structure)
or
)46
(inconsistent segment manager structure) crash occurs.
PBM
This
command
displays the contents of the partial bit maps
for each disk installed in the current system.
It is useful
when analyzing disk manager crashes.

2270512-9701

17-9

Analyzing a

System Crash

DNOS System Design Document

PDT
The PDT for each device known to the system is shown.
PQ
This command lists the queue server ID and the list of items
currently on the queue for
each
of
the
following
system
queues:

*
*
*
*
*
*
*
*
*
*
*
*
*

Task bidder
I/O Utility
Device I/O Utility
Disk Manager
Task diagnostic (kill task) processor
Job Manager
IPC task
Name Manager
User overlay loader
Forced roll processor
Return code processor
System log formatter
Accounting log formatter

The
PQ
lists
usually provide clues to any crash.
Most of
the queues should be
empty,
except
those
requiring
disk
access
to handle the queue.
If other queues are not empty,
the queue entries and queue servers need to be examined
for
errors.
The
log
queue
shows
valuable information, too,
since it carries the most recent errors sent to
the
system
log.
QU
This
command
utility.

provides

display.

terminates

the

ROB
All
resource
identifier.

ownership

blocks

are

displayed

JSB

RPB
This
command
prompts
for
an
I/O
resource pointer.
The
resource pointer can be an FCB for
a
file,
a
PDT
for
a
device,
or a CCB for a channel.
This command then displays
the RPB along with the other
relevant
structures.
For
a
file,
it displays the FDB, FCB, and RPBs.
For a device, it
displays the PDT and the RPBs.
For a channel,
it
displays
the CCB and the RPBs.
SGB
The
segment
group blocks (SGBs) for all segments currently
in memory are displayed, first those in table area
0,
then
those in table area 1.

Analyzing a System Crash

17-10

2270512-9701

DNOS System Design Document

SSB
All
segment status blocks (SSBs) for all segments currently
in memory are displayed, identified by SGB.
ST
The starting address, length, usage,
highest
address,
and
contents
of
the secondary table areas are displayed.
This
information is provided for each of the special table
areas
used
by segment management and file management and for each
JCA in the system.
TA
A memory area is displayed for each of the
tasks
in memory identified by TSB and JSB address.

currently

TR
The
registers
are
displayed
for each task in the system,
identified by TSB and JSB addresses.
TS
A table is displayed, showing the following information
each task in the system:

*
*
*
*
*
*

*
*

*
*
*

for

TASK NAME - Installed name of the task
ID - Installed ID and run-time ID of the task
WP - Workspace pointer
PC - Program counter
ST - Status register
STATE - Code for the task state (see DSC.TEMPLATE.
ATABLE.NFSTAT or the DNOS Messages and Codes Reference
Manual for details.
The first two digits are the
runtime priority of the task, the second two digits
are the task state.
Tasks in state )04 (terminating)
may have an inconsistent display as structures may
have been released.
FLAGS - The first word of task flags from the TSB
of the task
STATION - The station ID from the TSB of the task;
if the task was not bid at a station, no station
ID is displayed
TSBADR - The TSB address
JSBADR - The JSB address
PROG FILE - The name of the program file from which
the task was bid; only the last portion of the
pathname is listed

TSB
This
command displays each of the TSBs for each of
whose JCA is currently in memory.

2270512-9701

17-11

the

jobs

Analyzing a System Crash

DNOS System Design Document

??
This command lists all available crash analysis commands.

17.3

GUIDELINES FOR CRASH ANALYSIS

It is impossible to give a set of rules by which
crash
analysis
can
be
done.
There are several general guidelines which should
be known, and for
specific
crashes,
there
are
some
specific
guidelines.
The
following
paragraphs
address
general
hints
first, then some specific suggestions.
In general, an operating
system
crash
occurs
when
some
data
structure has been destroyed.
The problem in analyzing the crash
is then to find what structure has been changed, and what code or
combination
of
circumstances changed the structure.
To conduct
such an analysis,
you
must
be
familiar
with
the
DNOS
data
structures and be able to detect inconsistencies.
Data structure
pictures
are
available
in this manual to guide you through the
structures displayed by the crash analysis utility.
In addition,
you will need to understand as much as
yuu
can
about
how
the
structures
are
built,
used,
and released by the relevant DNOS
subsystems.
The subsystem descriptions in
this
manual' discuss
how they use DNOS data structures.
The

paragraphs
which
follow give Some specific suggestions for
particular crash codes.

handlin~

Codes )13 through )1F
These crashes
are
for
illegal
interrupts
from
devices.
Verify
that
all devices have been specified at the correct
interrupt levels during system generation.
If this
is
not
the
case,
perform a
new
system generation or change the
interrupt level using XSCU.
If
the
devices
are
at
the
correct
interrupt
levels, examine the HARDWARE TRAP VECTOR
information given by GI and see that it is correct.
If not,
you need to find the source of
the
modification.
If
the
information
is
correct,
check
the
workspace
for
the
interrupt (3 through )F) for clues to the crash.
Code )21 - PMUMGR inconsistent structure
Check register
4
in
the
MACHINE ERROR (TRAP 2) WORKSPACE
data.
If it is greater than the value in MEMSIZ, a request
has been made to
return
memory
beyond
the
end
of
free
memory.
If
the value in Register 4 is less than UADSTR, a
request has been made to return memory before the
start
of
free user memory.
If neither of these is the case, the free
memory list is incorrect.
If register 1 is zero, a block of
length zero has been specified.
If the value at the address
in
register 10 is greater than MEMSIZ, a block which is too
large has been specified.
If the value at
the
address
in
Analyzing a System Crash

17-12

2270512-9701

DNOS System Design Document,

register
10
is
greater than the value in register 11, two
blocks of memory
overlap.
If
register
4
is
less
than
register
0, two blocks will overlap when merged in the free
list.
UADSTR is the start of the free memory list shown
by
the MM command and MEMSIZ is the end of that list.
Code )22 - NFTMGR inconsistent structure
Examine
the
executing
stack for the return address of
caller of NFTMGR and the address of the item to
release
that order.

the
in

Code )23 - NFSCHD queueing error
Register 9 of the EXECUTING WORKSPACE has the TSB address of
the
task
that
issued the SVC which encountered the error.
Verify with the TSB address in EXTSB to see that it is still
valid.
Check the last SVC issued by that task to
find
the
processor which is in error.
Code )24 - IOBM inconsistent structure
Perform an analysis like that for code )21, using registers
2 and 4.
If register 2 has a
value
less
than
BTAADD
or
register
4 has
a
value greater than UADSTR, a request to
return buffer space is incorrect.
Code )26 - PMROLL cannot extend the swap file
This error occurs during task loading; an error indicator is
in register
of the
MACHINE ERROR (TRAP 2) WORKSPACE.
If
the
error indicator is )30, the file is not extendable.
If
the error is )3F, there is a structure error.
If the
error
is
)EO,
the
disk
is
full.
If
the
error
is )DA, the
secondary allocation table is full.

Code )29 - NFPOP or NFMAPO unexpected error returned
Register 11 of the EXECUTING ·WORKSPACE AT TIME OF
DUMP
has
the
address
of the return.
The return context tells which
location was called.
Code )2C - NFENAB - scheduler inhibit count is negative
Register 11 of the
MACHINE ERROR (TRAP 2) WORKSPACE
points
to
the
caller
of
NFENAB.
That routine mayor may not be
responsible for the error.
Code )46 - SEGMGR inconsistent structure
The executing stack has the
return
address,
the
caller's
register 2, and the caller's register 1.
Register 1 had the
address
of
the
SSB to delete.
Use this data to detect an
illegal request.
End action codes
task
Use the TSB list to find the terminating
and
examine
the
TSB.
diagnostic
packet
follows
the
which
The DIA
structure identifies the
fields
this
various
in
packet,
the
showing
the
error
caused
termination,
code
which
2270512-9701

17-13

Analyzing a

System Crash

DNOS System Design Document

workspace pointer, program counter, and status at
end action was taken.

the

time

Codes )60 through )6F - internal interrupts
Examine
the
return
context
(R13
R15)
of
the Trap 2
workspace in the GI
information
for
the
address
of
the
error.
Check
the
stack for recent routine calls and data
saved.
If none of the information in the GI information
or
structures lists is helpful, you might be able to find clues
to
the
crash
in the instruction trace kept by the 990/12.
The 990/12 hardware keeps 32
words
of
trace
information,
reflecting
the
most recent instruction execution.
When an.
internal interrupt occurs, the interrupt handler copies
the
hardware
trace
to
the
32
words
preceding the scheduler
workspace in the system root.
The address can be calculated
as 32 less than
the
start
of
the
SVC (XOP 15) WORKSPACE
displayed as part of the GI information.

17.4

HARDWARE TRACE INFORMATION

Hardware
trace
information
for a 990/12 can be found in the 64
bytes proceeding the SVC (XOPI5) workspace.
This
data
must
be
used
with
caution.
Because of optimizations being done by the
/12, the sequence
of
hardware
instruction
pairs
may
include
repetitious
data
or
pairs
that
appear to logically be out of
order.
The format of the trace data is shown in Table 17-2.
These words
are kept on the processor board for a
/12,
updated
continually
with
every
memory
cycle.
With
a level 2 interrupt, updating
ceases after the next
memory
cycle.
The
interrupt
processor
dumps
this
data
to
memory
proceeding the SVC workspace.
The
trace data consists of 16 pairs of words of the form
shown
here
as
Word
0
and
Word 1.
The set of entries appears in order of
latest instruction executed first, something of a pushdown stack.

Analyzing a System Crash

17-14

2270512-9701

DNOS System Design Document

Table 17-2
Bit

Format of Hardware Trace Information
Setting

Meaning

Word 0

Word

0
1
2
3

Execution violation
TILINE timeout
Memory data error
Mapping error

1=Yes
1=Yes
1=Yes
1=Yes

4
5
6
7

Illegal opcode
Privileged instruction attempted
Workspace read/write flag
TILINE access flag

1=Yes
1=Yes
I=Wri te
I=Access

8
9
10
11-15

TILINE R/W FLAG
I=Write
I=Access
Workspace access flag
Instruction fetch flag
I=Fetch
Most significant bits of TILINE address

0-14
15

Least significant bits of TILINE address
I=Yes
Write violation

The overlap of instruction execution in the 990/12
often
causes
pairs
of indicators to be set in a word, showing the activity of
the current instruction and the last instruction executed.
Some
typical examples of word 0 might be

ooco

Workspace access; TILINE write on previous instruction
TILINE address
0100
0120 = Instruction fetch
0160 = Instruction fetch; workspace reference on previous
instruction
TILINE write; TILINE access on previous instruction
01CO
Workspace write; TILINE write and workspace access on
02CO
previous instruction
Note
that the TILINE address field is not cleared from one trace
pair to the next.
Therefore, if the TILINE access
flag
is
not
set, the TILINE address is meaningless.
Information
given
about
each
of
the
crash codes in the DNOS
Messages and Codes Reference Manual
might
also
be
helpful~
resolving
the
cause of a system crash.
Each of the crash codes
is described there, with a general indication of its cause.

2270512-9701

17-15/17-16

Analyzing a

System Crash

DNOS System Design Document

SECTION 18
INTERRUPTS AND XOP PROCESSING

18.1

OVERVIEW OF INTERRUPT PROCESSING

The 990 computer has sixteen interrupt levels to serve
interrupt
requests
from
various
devices
and mechanisms.
They also have
sixteen
extended
operation
codes
(XOPs)
available
to
allow
extensions
to
the
standard instruction set.
Users cannot make
use of the XOP feature, since Texas
Instruments
software
makes
use
of
many
XOPs
and
is
likely to use the available set for
future products.
Interrupt levels are numbered from 0 through 15,
with
0
having
highest
priority.
There is a 4-bit interrupt mask which stores
the
level
number
of
any
interrupt
presently
executing
and
prevents interrupts of the same or lower levels from interrupting
the
CPU.
The
mask
is
displayed as the last four bits of the
status register.
The mask may be changed by a
LIMI
instruction
to enable or disable interrupts to the desired level.
Each
interrupt
level
is
uniquely
associated
with a two-word
location in memory, referred to as the interrupt trap.
This pair
of words includes
the
workspace
pointer
and
program
counter
values
for
the
program
which
services
the
interrupt.
The
interrupt traps for DNOS are built during system
generation
and
can
be found in the sysgen directory in file D$SOURCE (or in its
listing form in D$LIST).
DNOS uses

*
*
*
*
*

the interrupt levels

0 -

Power up

1 -

Power down

2 -

DNOS internal error

5 -

cPU clock

as follows:

Each
of
the
others
is
one
of:
standard
device
interrupt,
expansion chassis interrupt, multiple device
interrupt, undefined interrupt

When an interrupt occurs and is not masked
out
by
the
current
interrupt mask value, CPU control is transferred to the workspace
and program counter specified in the trap table.
If an undefined

2270512-9701

18-1

Interrupts and XOPs

DNOS System Design Document

interrupt occurs or an internal error is encountered in DNOS, the
trap
table
directs
the
CPU to a system crash routine.
In all
other cases, the interrupt trap table causes
a
transfer
to
an
interrupt
processing routine.
In DNOS, all interrupt processors
are found in the system root.

18.2

OVERVIEW OF XOP PROCESSING

Extended operations (XOPs) are available on the 990 to build
the
equivalent
of machine instructions not provided in the hardware.
There are 16 extended operation codes (levels) available.
One of
these, level 15, is reserved
by
DNOS
for
handling
supervisor
calls
(SVCs);
levels
9
through
12
are
used
by
the
DNOS
performance package, and the remaining levels
are
reserved
for
future DNOS use.
When
the
CPU encounters
an XOP instruction, it tests first to
determine if a hardware XOP processor is present.
If so, control
is passed to
that
processor
for
execution.
If
no
hardware
processor
is
present,
control
is
transferred
to
a software
routine via a table of processor addresses
built
during
system
generation.
This table is referred to as the XOP transfer table
and can be found in the sysgen directory in the file D*SOURCE (or
in its listing form in D$LIST).

18.3

BUILDING AN XOP PROCESSOR

In special situations, a programmer may
wish
to
implement
an
instruction or devise a service of DNOS which is not available in
the
supplied
version
of
DNOS.
To meet these situations, DNOS
allows the programmer to build his own supervisor
calls
(SVCs),
as
described
in
the DNOS Systems Programmer's Guide.
In cases
where this feature is not sufficient, DNOS
system
software
may
need to use an XOP processor.
To
add an XOP processor to DNOS, a processor must be written and
details must be provided during system generation.
18.3.1

System Generation Requirements for User XOPs.

The XOP related prompts during system generation are described in
Table 18-1.
The
system generation
program
inserts
the
XOP
processor entry point and workspace address into the XOP transfer
table
it
builds
for the system.
The system generation program
also includes the XOP processor object module in
the
linkstream
for DNOS.

Interrupts and XOPs

18-2

2270512-9701

DNOS

System Design Document

Table

18-1

System Generation Prompts

for XOPs

Prompt

Response required

ENTITY?
XOP LEVEL?

XOP
Level number (0 through decimal 14) that
is to be used
Entry point label of the XOP processor
Workspace label of the XOP processor
Name of the file that contains the object
module for the XOP processor

PC label?
WP label?
Pathname?

18.3.2

XOP Processor Details.

When an XOP instruction is executed, control transfers to the XOP
processor
via
the
XOP transfer table.
In the workspace of the
XOP processor, the following registers are loaded and must not be
destroyed by the processor:
Register 11 - the
address
of
the
relative to the calling task address

XOP
operand,
space

14 -

the

requesting

15 -

the

requesting task status

the

requesting

task

workspace

task program counter
register

The XOP processor should execute quickly and be relatively short.
It cannot issue supervisor calls, but must perform all operations
locally.
It can access the calling task address space
by
using
long distance instructions with the saved map file of the calling
task.
This
map file is at the offset TSBMLI in the task status
block
(TSB)
pointed
to
by
the
system
pointer
named
EXTSB
(executing
task TSB).
Figure 18-1 shows long distance access to
three parameters from the calling task address space.
The XOP processor must define
(DEF)
its
entry
point
and
its
workspace
address, and it must reference (REF) the system return
point, NFTRTN.
If it makes use of EXTSB, it must copy two system
templates, using the following statements:

COPY DSC.TEMPLATE.ATABLE.TSB
COpy DSC.TEMPLATE.COMMON.NFPTR
The first statement copies a template which has the offset TSBMLI
within a TSB.
The second copies a set of
system
pointers
that
includes
EXTSB.
Other data structures might also be accessed by
an XOP processor.
Consult the section on data structure pictures

2270512-9701

18-3

Interrupts and

XOPs

DNOS System Design Document

in this manual for details on the structures to be used.

*-----*
*
*
*

**
*

THIS EXAMPLE SHOWS HOW AN XOP PROCESSOR
INTERFACES WITH THE OPERATING SYSTEM TO ACCESS A CALLER'S
TASK AREA AND RETURN TO THE CALLER. THE EXAMPLE IS FOR
XOP LEVEL 10, WHERE THE PROCESSOR MOVES N WORDS OF DATA.
CALLED BY:
WITH:

*
*
*
*

ARGS

XOP

@ARGS,10
WITH X = SOURCE ADDRESS
DESTINATION ADDRESS
Y
NUMBER OF WORDS TO MOVE
N

DATA X,Y,N

*------

* EQUATES

COPY DSC.TEMPLATE.ATABLE.TSB
* GLOBAL DATA

*
*

COPY DSC.TEMPLATE.COMMON.NFPTR

REF
IDT
DEF
DEF
WPAD
BSS
USRXOP EQU
MOV
AI
LDS
MOV
LDS
MOV
LDS
MOV
LOOP
EQU
LDS
MOV
LDD
MOV
DEC
JNE
B
END

NFTRTN
'USRXOP'
USRXOP
WPAD
32
$

@EXTSB,R8
R8,TSBML1
*R8
*R11+,R1
*R8
*R11+,R2
*R8
*R11,R3
$

*R8
*R1+,R4
*R8
R4, *R2+
R3
LOOP
@NFTRTN

TO ACCESS EXTSB

SYSTEM RETURN POINT
ENTRY POINT FOR SYSGEN RESOLUTION
WORKSPACE ADDRESS FOR SYSGEN
LOCAL WORKSPACE
ROUTINE STARTS HERE
GET CALLER TSB ADDRESS
POINT TO THE MAP FILE
USING XOP OPERAND IN R11
GET ADDRESS OF ARGUMENT X
AND ADDRESS OF Y
AND OF N
MOVE N WORDS; ASSUME GOOD ADDRESSES
GET A WORD OF SOURCE INFORMATION
MOVE IT TO DESTINATION
COUNT DOWN
MORE TO DO IF COUNT POSITIVE
ELSE RETURN TO OPERATING SYSTEM

Figure 18-1

Interrupts and XOPs

TO ACCESS TSB FIELDS

XOP Processor

18-4

2270512-9701

DNOS System Design Document

SECTION 19
SPE CI AL SVCs

19.1

OVERVIEW

This set of SVC operations is supported for DNOS operating system
tasks only.
They are not documented in user manuals and must not
be issued by user-written code.
Each of the SVC blocks is shown with a hexadecimal offset at
the
left
of
each
word.
The upper right of the block shows special
conditions which must
be
met,
such
as
alignment
on
a
word
boundary, if such a condition is relevant.

19.2

I/O SVCs

Several
of
the
subopcodes of the I/O SVC can be issued only by
operating
system
tasks.
They
generate
error
conditions
otherwise.
19.2.1

DSRTPD Diagnostics Control

(Subopcode )08).

DSRTPD
supports
diagnostics
control
of
the
communications
hardware.
The mechanism to support this is
I/O
subopcode
)08.
The
extended
call
block
is
used
for
further subopcodes and
parameters.
The following functions

are supported:

SUBOPCODE 08 FUNCTIONS
DESCRIPTION

SUB-SUBOPCODE

56
66

2270512-9701

Write interface image
Read interface image

19-1

Special SVCs

DNOS System Design Document

The call block has
Hex Offset
)00
)02
)04
)06
)08
)OA
)OC
)OE
)10
)12
)14

the following format:
Align on Word Boundary

+------------------+----------------+
I
00
I
56)
Reserved for board compatibility

14
15

For the TTY/EIA card the format
Byte

Description.

Modem. lea ds
Bit
0 - Ignored
1 - Data terminal ready
2 - Request to send
3 - Clear read request
4 - Clear write request
5 - Clear new status
6 - Enable interrupts
7 - Diagnostic mode
Ignored
Ignored
Ignored
Subopcode (>56)
Reserved for board compatibility

12
13
14
15

19.2.1.2

is as follows:

Read Interface Image.

Sub-subopcode
)66 performs
the
diagnostic
read.
Modem
and
interface information is returned in the call block as follows:
For the

COMM board:

Byte
10

2270512-9701

Description
Interface information
Bit
0 - Write request
1 - Interrupt summary
19-3

Special

SVCs

DNOS System Design Document

2 -

Timer expiration

3 - New status flag
4
5
6
7

- Scan Busy
- Transmit underrun
- Readable copy of sync selection
- Read request
Modem leads
Bit
0-1 Unused
2 - Data carrier detect
3 - Ring indicator
4 - Reserved modem lead out
5 - Sec~ndary request to aend
6 - Clear to send
7 - Data set ready
Bits 0-3 - Unused
4 - Parity error
5 - Framing error
6 - Receiver over~un
7 - Receive error summary
Bits 0-7 - Receive data byte
Subopcode
Reserved for board compatibility

13
14
15

For the TTY/EIA board:
Byte
10
11

12
13
14
15
19.2.2

Description
Bits 0-7 - Receive data byte
Modem leads
Bit
0 - Interrupt
1 - Data set ready
2 - Data carrier detect
3 - Read request
4 - Write request
5 - Ring indicator (cable 2265151-0001)
reverse channel receive (other cables)
6 - Timing error (overrun)
7 - Xmit in progress
Ignored
Ignored
Subopcode
Reserved for board compatibility

Communications DSR Diagnostics Control

(Subopcode )08).

The DSRs used by communications software use a
call
block
like
DSRTPD
to
support
diagnostic
control
of
the
communications
hardware.
The
following
functions
are
supported,
using
the
specified
subopcodes
in
the extended call block at offset >14.
Note that for each subopcode that bits 0 through
3
are
defined
specially for that operation.

Special SVCs

19-4

2270512-9701

DNOS System Design Document

Sub-Subopcode

)XO

Abort/Timeout
Open
Close
Write
Read
Chained write
Miscellaneous ~hannel commands - diagnostics
Reserved for Protocol - immediate
Reserved for Protocol - data
Reserved for Protocol - data
Reserved for Protocol - data
Reserved for Protocol - data
Miscellaneous board - data
Miscellaneous board - immediate
Stand-alone diagnostics (not supported)
Immediate diagnostics

)X1

)X2
)X3
)X4
)X5
)X6
)X7
)X8
)X9

)XA
)XB
)XC

)XD
)XE
)XF
19.2.3

Meaning

Open Unblocked (Subopcode )13).

The Open Unblocked SVC block has

the following format:
Align on word boundary

Hex Offset
)00
)02
)04

*----------------+-----------------*
I
00
I
17.

19.2.5.3
This
call
options:

modifies

the

line

configuration with the following

Byte

Value

2
3
4,

LTA character (OO=don't change)
Speed **
Half-duplex = 1
Switched
Disabled
Auto-disconnect enabled
Require DLE+EOT for auto-disconnect
SCF ready/busy monitor
Exclusive access
LTA enable (half-duplex only)

Bit
Bit
Bit
Bit
Bit
Bit
Bit
Bit

0
1
2
3
4
5
6
7

**The following table gives the speed translations for the
of byte 20
Value

Speed (ASYNC BPS)

110
300
600
1200
2400
4800
9600
300 or 1200 depending on state of pin 12
at the COMM l/F.
This is used for automatic
speed selection in conjunction with VA3400
and 212A modems.

1
2
3
4
5
6
-1

19.2.5.4

value

Modify Terminal Type >18.

This call allows parameters related to the expected terminal type
to be altered.

Byte

Value

Terminal model**
(3=703, 7F=763)
Echo = 0

BI T 0

Special SVCs

19-8

2270512-9701

DNOS System Design Document

No echo = 1
**The following table gives the terminal type translation:
Value

Terminal Type

03
07
2B
2D
3F
41
51
53
55
57
78
7D

703
707
743
745
763
765
781
783
785
787
820
825

19.2.5.5

Modify Special Characters )19.

This
call modifies the characters used for end of
of file.
Byte

Value

2
3
19.2.5.6

record and end

End of record (OO=don't change)
End of file (OO=don't change)
Connect )IA.

This call establishes a connection in the indicated way.
If
bit
of
the
user
flags
is
set
(INITIATE
I/O) the task is not
suspended pending the establishment of connection.
revisifon bar
on If the TPD is not the call originator, DTR
is
asserted
only
after Ring Indicator or Data Set Ready is detected.
Once Ring or
Data Set Ready is detected, the timeout reverts to 10 seconds for
the
completion
of
the
connection.
Thus, if a port is s~t to
answer incoming calls with an infinite time-out,
and
some
nonmodem device
calls in, the DSR will timeout the call 10 seconds
after the phone rings.
In full-duplex environments, Data Carrier
Detect must be sensed for the call to complete successfully.

Byte
2

3
4,5

2270512-9701

Value
Assert RTS (00= do not assert)
Assert DTR (00= do not assert)
Timeout (250 ms increments, O=infinite)

19-9

Special SVCs

DNOS System Design Document

19.2.5.7

Flush Character Queue )IB.

This call removes any characters
of
the
KSB.
If
an
extended
extended user flags set, the DSR
If an extended call block is not
DSR is placed in normal mode.
19.2.5.8

buffered in the character
queue
call block is used with bit 4 of
is placed in
8-bit
data
mode.
used or if bit 4 is not set, the

Set Exclusive Access )ID.

This
call
places the port under control of file transfer tasks.
These tasks have bit 5 of the user flags in the PRB set to one on
opens.
19.2.5.9

Set Shared Access )IE.

This call releases
the user flags set

19.2.6

the port to tasks
to one on opens.

VDT Extended Edit

that do not have

bit

Flags (Subopcode )15).

Device
dependent
edit
modes
for the 911, 931 and 940 VDTs are
accessed like the DSRTPD Communications Control (Subopcode
)15).
When
using subopcode 00 in the data buffer, bytes 2 through 5 of
the data buffer form 2 words of flags.
The following bit setting
cause the described functions to be performed.
First flag word (Bytes 2-5 of the subopcode 15 data buffer)
Bit 0 - 931,940 - enable pass through mode
1 - 931,940 - in pass through mode, terminate read on
EXT ()03)
2
931,940 - in pass through mode, terminate read on
ESC-) pair
3 - 931,940 - allow extended event characters
911 - map hardware generated codes 00 -)IF to
event characters in range )EO - )FF
4
reserved
5
931,940 - allow ESC and SOH characters in Write
ASCII BUFFER (access to reverse video,
underline, and blink)
6
reserved
7 - reserved
8 - 911,915 - report modified data to caller on Read
ASCII (DSR sets bit 7 of system flags
byte)
9 - 911,915 - extended character validation (invalid
characters are not echoed, error flag not
set, beep occurs if warning beep flag is
set)
10 - 911,915 - Suppress null characters on input, allow
null character on either 7 or 8 bit Write

Special SVCs

19-10

2270512-9701

DNOS System Design Document

ASCII
convert embedded nulls to spaces on Read
ASCII
12 - Kanji - toggle screen edit mode and 911 emulation
13-15 - reserved - must be set to zero
11 -

911,915 -

Second flag word (bit set to 1 indicates key is enabled for
911 and 940 as an event key in the PDT.
The existence of the
second flag word enables its use.
(All the indicated keys
are mapped to the 913 code, as they would be in the WP mode
that is no longer available.

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

Erase Field
Right Field
Left Arrow at left margin
Tab
Down Arrow
Skip
Home
Return
Erase Input
Blank Gray (default anyway)
Delete Character
Insert Character
Right Arrow at right margin
Enter
Left Field
Up Arrow (default)

The first three bits of the first flag word allow the "pure passthru" support needed to use
the
940
in
block
mode
or
as
a
replacement
for
the
old SVCs )8 and )18 character mode.
These
functions are not perceived to be particularly useful,
but
will
be left in the DSR as a hook to any features not supported by our
software.
An application that uses these functions must restore
the screen image and terminal state to
standard
modes
on
exit
from pass thru mode.
Bit
3
(the
fourth
bit) of the first flag word allows the 3270
package (and any others) to get at the extended function keys
on
the 940 keyboard.

BiL 5 allows access to setting the extended display attributes
reverse video, underline and blinking.

19.2.7

Asynchronous Multiplexor Operation

(Subopcode )15).

Two
requests
for
the Modify Device Characteristics SVC (opcode
)00, subopcode )15) are supported for both VDT and
printer
DSRs
that
execute
on
buffered
TILINE
multiplexers
(CI403/CI404).
These two
requests
are
Read
UART
Registers
and
Write
UART

2270512-9701

19-11

Special

SVCs

DNOS System Design Document

Registers.
These requests are provided for the use of diagnostic
programs.
Their
use
requires
detailed
knowledge
of
the
CI403/CI404
controllers
and
the
WD8250
UART
used
on
the
controllers.
Refer to the CI403/CI404 hardware documentation for
more detailed information.
The
Read
and
Write
DART
Registers
both
directly access the
functions of slave word 1 of the
CI403/CI404
TILINE
Peripheral
Control Space (TPCS).
A diagnostic task is allowed direct access
to seven DART registers for each channel of the multiplexer.
19.2.7.1

Write DART Registers.

The
primary
function
of
the
Write
DART Registers request is
setting and resetting specific DART inputs and
RS-232-C
signals
for
a
diagnostic
program.
The request is implemented by using
the Modify Device Characteristics SVC (I/O
subopcode
>15)
with
the
sub-subopcode
>31.
This
opcode
provides direct, devicedependent access to slave word 1 of the
CI403/CI404
TPCS.
The
operation
must be issued with an extended call block; otherwise,
an error is returned.
Parameters furnished by the online diagnostic
task
include
the
output
data
buffer length, the contents of the data buffer, the
DART register number to which the data is
to
be
written
(call
block
byte
18), and the register data (call block byte 19).
If
the device (PDT) to which the
operation
is
issued
is
not
in
diagnostic
mode, the request is rejected.
Figure 19-0 shows the
call block formats
and
applicable
fields
in
the
Write
DART
Registers request.

Special SVCs

19-12

2270512-9701

DNOS System Design Document

+-------------------~-------------+
)00
I
,STATUS BYTE
1

----------------+--~------------~I

I/O SUB-OPCODE 1

LUNO

----------------+---------------SYSTEM FLAGS
r
USER FLAGS
----------------+---------------DATA BUFFER ADDRESS
-----------+

4
6

RESERVED
LOGICAL RECORD LENGTH

CHARACTER COUNT

10
12

REPLY BLOCK ADDRESS -

RESERVED

EXTENDED USER FLAGS

RESERVED
FILL CHARACTER I
EVENT BYTE

REG

RESERVED
FIELD ROW POS. I FIELD COL POS.

RES

I REGISTER DATA

+---------------------------------+
+---------------------------------+
1
)31
1
IGNORED
1<----------+
+---------------------------------+
Figure 19-1

Affected fields of
follows:
Byte

1
2
3
4
5
5

2270512-9701

the SVC call

block and

Bit

6,7

Write UART Register Format

their meanings

are

Meaning
Specifies SVC call type.
Enter )00 for I/O.
Used to return operation error codes.
Subopcode.
Enter )15 for Modify Device
Characteristics
LUNO. Use the LUNO from the diagnostic assign.
System flags.
Standard OS definitions apply.
User flags.
Standard OS definitions apply.
Extended call block. 1 = Read or Write UART
Registers.
Data buffer address. Points to the buffer that
contains the sub-subopcode.

19-13

Special SVCs

DNOS System Design Document

8,9
10,11
18

7-4

19.2.7.2

Logical record length. Not used.
Character count. 2 = Read or Write DART Registers.
Register number (0-7) left justified in byte.
Specifies the DART register to which
the operation is directed.
Register data.
For the Write UART subopcode,
specifies data to be written.

Read UART Registers.

The
primary
function
of
the
Read
UART
Registers request is
sensing
UART
inputs
and
RS-232-C
signals
for
a
diagnostic
program.
The
request is implemented by using the Modify Device
Characteristics SVC (I/O subopcode )15)
with
the
sub-subopcode
)j2.
This
opcode
provides
direct, device-dependent access to
slave word 1 of the CI403/CI404 TPCS.
The
operation
is
issued
with an extended SVC call block.
Parameters
furnished
by
the online diagnostic task include the
output data buffer length, the contents of the data
buffer,
and
the
UART register number from which the data is to be read (call
block byte 18).
The register data is returned in call block byte
19.
If the device (PDT) to which the operation is issued is
not
in
diagnostic
mode, the request is rejected.
Figure 19-2 shows
the SVC call block formats and applicable fields in the Read DART
Registers request.

Special SVCs

19-14

2270512-9701

DNOS System Design Document

+---------------------------------+
)00
1
STATUS BYTE-----------------+---------------I/O SUB-OPCODE 1
LUNO
----------------+---------------SYSTEM FLAGS
1
USER FLAGS
----------------+----------------

o
2

DATA BUFFER ADDRESS

LOGICAL RECORD LENGTH -

-----------+

RESERVED

CHARACTER COUNT
----------------------~----------

REPLY BLOCK ADDRESS

EXTENDED USER FLAGS.

RESERVED
FI LL CHARACTER 1
EVENT BYTE

REG II

RESERVED
FIELD ROW POSe 1 FIELD COL POSe

RES

+---------------------------------+
+---------------------------------+
1
)32
I
IGNORED
1<----------+
+---------------------------------+
Figure 19-2

Affected fields
follows:
Byte

2
3
4
5

2270512-9701

of the SVC call

block and

Format

their meanings

are

Meaning

Bit

Read UART Registers

Specifies SVC call type. Enter )00 for I/O.
Used to return operation error codes.
SUbopcode. Enter )15 for Modify Device
Characteristics.
LUNO. Use the LUNO from the diagnostic assign.
System flags. Standard OS definitions apply.
User flags. Standard OS definitions apply.
Extended call block. 1 = Read or Write UART
Regi ste rs •
Data buffer address. Points to the buffer that
contains the sub-subopcode.
Logical record length. Not used.

19-15

Special SVCs

DNOS System Design Document

10, 11
18

7-4

19.2.8

Character count. 2 = Read or Write UART
Registers.
Register number (0-7) left justified in byte.
Specifies the UART register to which
the operation is directed.
Register data.
For the Read UART subopcode,
the data read from the device is returned
in this location.

TILINE Diagnostic Port

(Subopcode >16).

The TILINE Diagnostic Port operat~on
allows
the
passing
of
a
sixteen
byte
controller
image
buffer
to
a
device
from
a
nonprivileged
task.
The
TILINE
controller
image
after
the
execution
of
the
command
is
returned in the controller image
buffer.
This subopcode is only valid for disk and magnetic
tape
devices and is used by online diagnostics.
The call block has the following format:
Hex Offset
>00
> 02
>04
>06
> 08
>0A
>OC
>OE

Align on Word Boundary

+-----------------+------------------+
I
0
I
(Return Code>
I
+-----------------+------------------+
I
16
I
Luno
I
+-----------------+------------------+
I (System Flags>
I
User Flags
I
+------------------------------------+
I
TILINE Image Buffer Address
I
+------------------------------------+
I
Re s e r v e d = > 1 0
I
+------------------------------------+
I
Re s e r v e d = > 1 0
I
+-----------------+------------------+
IBinary OS Ver/Rell Diagnostic Flags I
+-----------------+------------------+
I
Dynamic Passcode
I
+------------------------------------+

(>10 - maximum size)
Byte

Description

LUNO assigned to

Flags set by system Bit 0
Bit 1
Bit 2-7

Special SVCs

Flags set

the disk or mag tape
when set mean:

LUNO is bu sy
Error
Reserved (set
by user -

19-16

to 0)

when set mean:

2270512-9701

DNOS System Design Document

Bit 0
Bi t 1- 6
Bit 7

Initiate I/O
Reserved (set to 0)
No retries are to be performed

6-7

Address of TILINE image buffer.
This buffer will
contain the TILINE controller image after the
command completion.
Must begin on word boundary
and be sixteen bytes in length.

This byte must contain the version and release of the
operating system in binary.
For example, to execute
this I/O supervisor calIon DNOS 1.1, this byte must
contain the value >11.

Diagnostic flags
Bit 0

set by the user -

-0

Bi t
14-15

1-7

when set mean:

Bytes 10 and 11 in the TILINE
image buffer do not contain a
logical address,
Bytes 10 and 11 in the TILINE
image buffer contain a logical
address

Reserved (set

Dynamic passcode - must
of the system minute.

to 0)

contain the current value

When
bit
0
of
the
"diagnostic
flags"
(byte 13) is set, the
controller image buffer is modified by the operating system prior
to execution of the command.
In particular, bytes 10 and 11
are
assumed
to
contain a logical address; this address is converted
to a physical 21 bit TILINE address which is inserted into
bytes
10/11
(LSB),
and
bits 4-7 of byte 13 (MSB) of the TILINE image
buffer.

CAUTION
If
the
command
passed
in
the
TILINE
controller
image
transfers
data to or from
the device, it is the responsibility
of
the
task issuing the Diagnostic Port operation to
set
bit
0 of the diagnostic flags to 1, and
provide the logical address (bytes 10 and 11)
and byte
length
(bytes
8
and
9)
of
the
read/write
buffer
in
the
controller image
buffer.

The operating system performs address space verification when bit
of the diagnostic flags is set.
If this bit
is
not
set,
no

2270512-9701

19-17

Special SVCs

DNOS System Design Document

address
space
verification
is
performed.
The
address space
verification checks that the buffer address (bytes 10 and 11) and
buffer byte length (bytes 8 and 9) fit entirely in one segment of
the issuing task.
Write and execute protection
of
the
segment
are not checked.
The
unit
select field is ignored in the TILINE controller image
buffer; the DSR sets the unit select field properly
to
indicate
the
device
to
which
the luno is assigned.
It should be noted
that certain fields in the TILINE controller
image
buffer
have
meaning only after the command is ex€cuted.
The controller image
buffer has the following format:
FOR DISK DEVICES:

o
2
4
6
8
10
12
14

Special SVCs

+-------------------------------------------+
I
DISK STATUS
I
+-------------------------------------------+
I
COMMAND
I
+-------------------------------------------+
I
FORMAT/SECTOR
I
+-------------------------------------------+
I
CYLINDER
I
+-------------------------------------------+
I
COUNT
I
+-------------------------------------------+
I
LOGICAL ADDRESS (16 BIT)
I
+-------------------------------------------+
I
SELECT/MSB'ADDRESS
I
+-------------------------------------------+
I
CONTROLLER STATUS
I
+-------------------------------------------+

19-18

2270512-9701

DNOS System Design Document

FOR TAPE DEVICES:

+-------------------------------------------+
I
TAPE TRANSPORT STATUS
+-------------------------------------------+
I
READ OVERFLOW STATUS COUNT
+-------------------------------------------+
I
READ OVERFLOW STATUS COUNT
I

+-------------------~-----------------------+
I
READ OFFSET
I

o
2

8
10
12
14

+-------------------------------------------+
I
COUNT
+-------------------------------------------+
I
LOGICAL ADDRESS (16 BIT)
I
+-------------------------------------------+
I
COMMAND/SELECT/MSB ADDRESS
I
+-------------------------------------------+
I
STATUS/CONTROL
I
+-------------------------------------------+
J

The following error codes are unique to the Diagnostic Port.
All
other
error
codes that occur when using the Diagnostic Port are
standard SVC error codes.
Error

Meaning

)00E8

Invalid TILINE Diagnostic Port passcode.
The
passcode is -invalid if the following conditions
are not met in the SVC call block:
Byte 8 = )00,
Byte 9 = )10, Byte 10 = )00, Byte 11 = )10,
Byte 12 = Binary OS version/release (described
above), Byte 14-15 = value of system minute.

)00E9

Invalid TILINE command used with TILINE Diagnostic
Port.

The disk DSR handles TILINE Diagnostic Port requests in a
unique
manner.
(Other
than returning the TILINE controller image, the
tape DSR does not handle Diagnostic Port
requests
in
a
unique
manner.)
The
disk DSR i~sures that no requests are outstanding
on any of the devices attached to the
same
controller
(as
the
device receiving the request), before issuing the Diagnostic Port
operation.
After
all
outstanding
requests are completed, the
Diagnostic Port
operation
will
be
initiated.
Following
the
completion
of the Diagnostic Port operation, all requests queued
to the devices attached to the
same
controller
are
initiated.
During
the
interval
between
the
receipt of a Diagnostic Port
request and the completion of that
request,
no
other
requests
will be initiated to any device attached to the same controller.

2270512-9701

19-19

Special

SVCs

DNOS System Design Document

CAUTION
Because
the
disk
DSR
was
not designed to
handle seek and restore commands initiated by
the user, a seek or
restore
command
should
never
be
issued in the TILINE image buffer.
System error conditions will result if a seek
or restore is issued.

19.2.9

Read with Initial Value (Subopcode >17).

The Read with Initial Value subopcode is implemented for the 911,
931 and 940 devices.
This operation performs the same
functions
as
Read ASCII, except that the field initial value is taken from
the user's buffer rather than from the terminal
display
memory.
When
using
this
operation,
the
user
must
rationalize
any
discrepencies between the visible initial value in the field
and
that
which is passed to the DSR in the buffer.
The operation is
used by 3270 communications software.
The following call block is used: Align on Word Boundary

Dec
0

Hex
0

+----------------------------------------------+
I
00
I

I
+----------------------+-----------------------+
I
17
I
LUNO
I
+----------------------+-----------------------+
I

I
User Flags
I
+----------------------+-----------------------+
I
Data Buffer Address
I
+----------------------+-----------------------+
I
Read Character Count
I
+----------------------+-----------------------+
I

I
+----------------------+-----------------------+
I
Validation Table Address
J
+----------------------+----~------------------+
I
Extended User Flags
I

+----------------------+-----------------------+
I
Fill Character
I

I
+----------------------+-----------------------+
I Cursor Position Row
I
Column
I
+----------------------+-----------------------+
I Field Beginning Ro~
I
Column
I
+----------------------------------------------+

<)16 Byte
04

Maximum size)

System flags

Special SVCs

19-20

2270512-9701

DNOS System Design Document

o -

Busy
- Error
- EOF
- Event
- Modify data tag- (operator pressed a valid
data key or erase key)
User flags
5 - Extended block --must be set 1
Output character count on initial read option
size of initial value in the buffer
Actual count of characters read (always less than
or equal to size of initial value)
Specify the address of a validation table if
character validation is set in the extended user
flags.
Otherwise set to zero.
Extended user flags
o - Field start position
1 - Intensity
2 - Blink cursor
3 - Graphics
4 - Eight-bit characters (intensity bit)
5 - Task edit
6 - Beep
7 - Right boundary
Extended user flags
o - Cursor position in read field
1 - Fill character
2 - Do not initialize field
3 - Require termination char for return
4 - No echo
5 - Character validation
6 - Ignored
7 - Warning beep
Programmable key or blank returned
1
2
3
7

05
08-09
OA-OB
OC-OD

The "do not initialize field" flag set to 1
indicates
DSR will
not
replace
the data on the screen by what
buffer before doing the Read operation.

19.2.10

that
the
is in the

Assign Diagnostic Device (Subopcode )94).

The Assign
Diagnostic
Device
is
issued
by
a
task
that
is
assigning
a
LUNO
to
a device that is in the diagnostic state.
The call block is of exactly the same format as the
Assign
LUNO
(subopcode
)91);
but subopcode )94 is required to assign a LUNO
to a device that is in the diagnostic state.
Only one
task
can
successfully
execute
this
SVC
at
anyone time.
Other tasks
attempting the assign will receive a )9C error.

2270512-9701

19-21

Special SVCs

DNOS System Design Document

19.2.11

Attach File (Subopcode )AO).

The Attach File SVC is used
representing the file to be
already
in
memory).
The
support job local temporary

to reserve access to a file.
The FCB
attached
is
built
(or
located
if
SVC is currently used. by the O.S.
to
files.

If the request is the first attachment to this file by this
job,
an
ROB
is
built to point to the FCB representing the file.
An
attachment number between 0 and
255
(unique
to
this
job)
is
generated
and
placed in the ROB.
(See the discussion of Detach
File by Number SVC for details of it"s use.)
The LUNO
count
for
the FCB is incremented.
If the File was already attached by this
operations in the ROB is incremented.
The Attach Resource SVC block has

job,

the count of attach

the following format:

Align on word boundary

Hex Offset
)00
)02

*----------------+-----------------*
I
00
I

+----------------+-----------------+
I
A4
I
Rese rved
I
+----------------+-----------------+
I AS).

The
Release
LUNO
in Another Job SVC is used by the Job Manager
and by PMTERM to clean up job-local and task-local LUNOs
when
a
job or task terminates.
The format

of the SVC call

Hex Offset
)00

)02
)04
)06
)08
)OA
)OC

block is as follows:

Align on word boundary
*--~-------------+-----------------*
00

+----------------+-----------------+
I
AS
I LUNO to Release I
+----------------+-----------------+
I F.

DCBCHR
DCBCHR is an equate for the DCBCDE field.
on a bid task SVC is placed in this field.

The

bid character

DCBNAM
Up to eight character, left-adjusted, blank filled
name
of
the
device.
This is provided by the requestor when DCFNAM
is set to 1 for the SVCs
that
require
a
device
name
or
number.
It
is
filled" in
by
DIOU when a device name is
requested.
DCBNUM
The DIOU assigned number for the device.
It is returned
by
DIOU
when
a device number is requested.
It is provided by
the user when DCFNAM is set to
for the SVCs that require a
device name or number.

DCBUFL
DCFCON, when set to 1, indicates that
the
operation
being
performed is a Conditional Set Parameters.
DCFNAM, when set
to
1,
in~icates the name of the device is specified in the
call block.
When set to
the device number
is
specified.
DCFWCH
is
a
two
bit
flag that is used by the Get Device
Parameters operation
to
indicate
the
parameters
of
the
specified
device are desired (00), or the parameters of the
device that is lexically less thBn (01) or greater than (10)
the specified device
are
desired.
DCFREP
is
used
when
modifying
a
CDT.
If DCFREP is set to 1, the specified CDE
will replace the current CDE of that number.
If
DCFRGP
is
set to 0, the specified CDE will be added to the CDT only if
none
currently
exists with the same CDE number.
DCFVOL is
set to 1 if a volume name instead of a disk name is provided
in the call block.
DCFSDK is set to 1 if the
operation
is
applied
to
the
system
disk.
The order in which DCFSDK,
DSFVOL, and DCFNAM are checked is DCFSDK, DSFVOL,
and
then
DCFNAM.
In other words, DCFSDK overrides DCFVOL and DCFNAM,

Special SVCs

19-30

2270512-9701

DNOS System Design Document

and DSFVOL overrides DCFNAM.
DCBBUF
The
address
of the device parameters or the CDE, depending
on the subopcode.
The address may be odd.
When a buffer is
used, the first byte
contains
the
length
of
the
buffer
excluding the length byte.
19.2.18.1

)C2 -

Get

Selected Device Parameters.

The Get Selected Device Parameters operation return the values of
the
parameters identified in the bu"ffer pointed to by the DCBBUF
field.
The name and number of the device are always returned
in
the call block when this operation completes successfully.
DCB
fields
and DCBBUF.

used

include:

DCBOC ()C2),

DCBNUM, DCBNAM,

DCBUFL,

DCBNUM
If the
DCFNAM
flag
(see
DCBFLG)
is
0,
the
parameters
requested
are
those
of the device specified by the device
number in this field.
If it is 1 the device number will
be
returned
in
this
field
even
if
it
is
not
one of the
parameters requested.
DCBNAM
If the DCFNAM flag is 1, the parameters requested are
those
of
the
device
specified by the device name in this field.
If it is 0, the device name will be returned in
this
field
even if it is not one of the parameters requested.
DCBUFL
If
the
DCFNAM
flag
is 0, the number in the device number
field ident~ifies which device's
parameters
are
requested;
otherwise,
the
name
in
the
device name field does.
The
DCFWCH
flag
field
indicates
which
device's
parameters
relative
to
the
specified one are to be returned.
If the
field is 00 use the specified device, 01 use the device that
is lexically less than the specified device, or 10
use
the
device that is lexically greater than the specified device.
DCBBUF
The buffer pointed to by this field
the following manner.
length of the buffer
parameter number of a parameter
parameter number of a parameter

is set up by the user in

parameter number of a parameter

2270512-9701

Special SVCs

DNOS

Syst~m

Design Document

All
of
the
values
are bytes.
The length of the buffer is the
total number of bytes available for DIOU to place
the
specified
parameters back into the buffer.
If the name or number parameter
is
in
the
list of parameters the value will not be returned in
the buffer but instead it will be placed in the
name
or
number
field
of
the call block.
The buffer will be returned using the
following format.
length of the buffer
parameter number of a parameter
length of the parameter
parameter

----+
1
1- repeated

------------------------+

The length of the buffer will be the number of bytes taken up
by
the
parameter
overhead
(one
word
per
parameter)
and
the
parameters.
It will include a byte for the 0 terminator.
If
a
parameter is not defined, the length byte for that parameter will
be zero.

19.2.18.2

)C3 -

Set Selected Device Parameters.

The
Set Selected Device Parameters operation adds or changes
values of the parameters identified in the buffer pointed
to
the DCBBUF field.
DCB
fields
and DCBBUF.

used

include:

DCBOC ()C3),

DCBNUM, DCBNAM,

the
by

DCBUFL,

DCBNUM
If the DCFNAM flag (see DCBFLG) is 0, the parameters
to
be
set
are
those of the device specified by the device number
in this field.
DCBNAM
If the DCFNAM flag is 1, the parameters to be set are
those
of the device specified by the device name in this field.
DCBUFL
If
the
DCFNAM
flag
is 0, the number in the device number
field identifies which device's parameters are
to
be
set,
otherwise;
the
name in the device name field does.
If the
DCFCON flag is 1, the parameters in the list will be set
if
the
verification
value
provided with the new value is the
present value of the parameter.
DCBBUF
If DCFCON is 0,

Special SVCs

the

buffer pointed to by this

19-32

field will

2270512-9701

DNOS System Design Document

set up by the user in the following
length of the buffer
parameter number of a parameter
length of the parameter
parameter

form.

----+
1

1- repeated

-----------------------+

o
DIOU
processes
the
buffer
until
it
encounters a 0 parameter
number or the end of the buffer as defined by the first
byte
of
the buffer.
The length byte does not include itself.
If
DCFCON is 1, the buffer pointed to by this field
the user in the following form.
length of the buffer
parameter number of a parameter
length of the parameter
verification value
parameter

is set up by

----+1
1- repeated
1

-----------------------+

o
The verification value must be the same length as the
parameter.
DIOU
processes
the
buffer
until
it
encounters a 0 parameter
number or the end of the buffer as defined by the first
byte
of
the
buffer.
The length byte does not include itself.
Note that
only those parameters not declared as READ ONLY may be altered.
19.2.18.3

)C6 -

Get CDE From CDT.

The Get CDE From CDT
operation
returns
the
requested
command
definition entry from the specified command definition tabl~.
DCB
fields
DCBBUF.

used

include:

DCBOC

<)C6),

DCBCDE,

DCBNUM, and

DCBCDE
This field contains a value between 0 and )F that
the CDE to be retrieved.

identifies

DCBNUM
The CDT number from which the CDE
is
to
be
retrieved
placed in this field.
The first CDT is number O.

2270512-9701

19-33

Special SVCs

DNOS System Design Document

DCBBUF
The
CDE is returned in the buffer pointed to by this
The first byte will be thH length of the CDE.

1 9 • 2 • 18 • 4

> C7 -

Pro c e s s

field.

De vic E~ Ta s k Bid.

The
Process
Device
Task
Bid
operation
processes
the
CDE
corresponding
to
the
character passed in the call block if the
character is in the specified terminal's CDEs.
DCB fields used include:
and DCBUFL.
DCBCDE
The character of a

DCBOe (>C7),

DCBCDE,

DCBNUM,

DCBNAM,

CDE.

DCBNUM
If
the
DCFNAM flag (see DCBFLG) is 0, the task bid is from
the device specified by the device number in this field.
DCBNAM
If the DCFNAM flag is 1, the task bid
is
from
specified by the device name in this field.

the

device

DCBUFL
If
the
DCFNAM
flag
is 0, the number in the device number
field
identifies
which
device
the
task
is
bid
from;
otherwise,
the name in th.e device name field identifies the
device.

19.3

SPECIAL FEATURE OF EXECUTE TASK SVC

The Execute Task SVC (>2B) uses a bit in the
flag
byte
of
the
call
block
for implementing the RBID funetion.
When the bit is
set, the SVC processor bids the task and unconditionally suspends
the caller.
The caller is placed in state 6, as opposed to state
17.
This allows the task that is bid and the task that bid it to
alternate execution.
When
the
task
that
was
originally
bid
terminates, the caller is reactivated.
The
sole
function
of
the
R.BID bit is to support the SCI RBID
capability.
The RBID process is described in detail in the
DNOS
SCI and Utilities Design Document.

Special SVCs

19-34

2270512-9701

DNOS System Design Document

19.4

SEGMENT MANAGEMENT

The
Reset Exclusive Use Across Job Boundaries suboperation ()13)
of
the
Segment
Management
SVC
()40)
is
used
by
the
task
termination
processor
(PMTERM)
to
clean up any segments still
owned at task termination.
PMTERM will continue
to
issue
this
SVC
as
long as there are owned segment entries (OSEs) linked to
the TSB.
This operation uses the same SVC processor as the Reset
Exclusive Use suboperation but uses a different entry point.
If
the task in which exclusive use is being reset is not in state 04
(task
termination),
the
SVC will fail.
Otherwise, the segment
owner block (SOB)
is
delinked" from
the
SSB
and
its
memory
released.
The
OSE
is
removed from the list of owned segments
linked to the TSB and its memory released.
If the segment is not
in use or reserved, it is cached or. deleted.

19.5

NAME MANAGEMENT

The Name Management SVC (SVC )43) supports 15 subopcodes, most of
which are not useful to user programs.
Four
of
the
operations
are documented in the DNOS SVC Reference Manual.
These are:

*
*
*.,
*

Return the pathname and parameters for

a logical name

Create a logical name (Setting a name's value)
Delete a logical name
Restore name segment

operations
are
documented only in this section,
The
following
DNOS
utility
since they are useful only to operating system and
tasks:

Return
an additional pathname of a set
a logical name

Add a pathname to the set of
name

Return
the
logical
name
that immediately precedes or
follows in alphabetical order the specified logical name
in the current stage

Delete a defined subset
current stage

Create a new stage

2270512-9701

19-35

pathnames

the

logical

of pathnames for

for

name s

logical

the

Special SVCs

DNOS System Design Document

*
*
*
*
*
*

Return to the previous stage
Return error information
Return segment size
Copy logical names to new segment
Create empty name segment
Save name segment

A task
that
requires
a new logical name performs a Set Name's
Value (subopcode )02) operation, supplying the logical name,
the
value
(pathname), and the parameters, if any.
When the value of
a logical name is a set of pathnames, the task performs an Append
Pathname to Name (subopcode )03) operation, supplying the logical
name and a pathname.
The append operation is performed for
each
additional pathname.
When
a
task needs the pathname or parameters of a logical name,
it performs a Determine Name's Value (subopcode
)00)
operation.
When
the
value
of
the logical name is a set of pathnames, the
task performs a Determine Next Pathname (subopcode )01) operation
for each additional pathname.
The task supplies the logi~al name
for either of these two operations.
Within
DNOS,
most
Assign
LUNO
operations
go
through
the Name Manager for resolution of
names, therefore a task rarely needs to use this operation.
The Delete Name (subopcode )04)
operation
deletes
a
specified
logical
name.
The
Return
Next Name (subopcode )05) operation
returns a logical name that is adjacent to the supplied
name
in
the
current
name
list.
A flag specifies the preceding name or
the following name.
The Purge Names (subopcode )06) operation supplies a logical name
and its length.
The name is compared to each logical name in the
current name list.
If an equal
name
is
found,
that
name
is
deleted.
When
all but the rightmost character of the names are
equal, and the rightmost character of the name in
the
table
is
greater
than
the corresponding character of the specified name,
the operation deletes the name.
The Enter New Stage (subopcode )07) operation creates a new stage
with the calling task as the only task in the stage.
The
Return
to
Previous Stage (subopcode )08) operation may only be executed
by the task that created the current stage.
It returns that task
to the previous stage of the task.
It deletes the
stage
if
it
has no daughter stage and if the calling task is the only task in
the stage.
The Return Next Error Entry (subopcode )09) returns
error
synonyms
stored
in
the first entry in the
Special SVCs

19-36

the values of
list of error

2270512-9701

DNOS System Design Document

entries.
Several operations have to do
with
the- segments
that
contain
logical
names
and
synonyms.
The
Determine
Segment
Size
(subopcode )OA) operation returns the size required for a segment
that would hold the names available to
the
calling
task.
The
Copy
Names
to
New Segment (subopcode )OB) operation copies all
names ,available to the calling task
to
the
specified
segment.
The
Create
Empty
Name
Segment
(subopcode
)OD) creates a new
segment for names and Save Name Segment
(subopcode
)OE)
copies
the
name
segment
to disk.
The Restore Name Segment (subopcode
)OC) retrieves a disk copy of a name segment into memory.
The supervisor call

block is of

the following form:
Align on word

Hex Offset

)00
)02
)04
)06
)08
)OA
)OC

boundary

*--------------------+--------------------*
)43
01).

When the Determine
Name's
Value
operation
returns
1
in
the
miscellaneous field, the task executes one or more Determine Next
Pathname
operations
(subopcode
>01).
Each operation returns a
pathname and indicates whether or not there is another pathname.

2270512-9701

19-41

Special SVCs

DNOS

The following fields

*
*
*
*
*
*
*

Opcode

the

supervisor call

System Design Document

block apply:

)43

Return code
Subopcode

)01

Flags
Address

of name

Address

of value

Miscellaneous

The operation is defined only for logical names.
name type must be set to 1.

The

flag

for

The
address
of
name field must contain the address of a buffer
that contains the length of the name in the first byte,
and
the
characters of the logical name in succeeding bytes.
The
address
of value field must contain the address of a buffer
large enough to contain the pathname expected.
The first byte in
the buffer contains the length
of
the
buffer.
The
operation
replaces
that
value with the length of the pathname, and places
the characters of the pathname in succeeding bytes.
The miscellaneous field contains the number of the next
pathname
(the pathnBme to be returned).
Pathname 0 is the first pathname,
pathname
1
is
the
second,
etc.
The operation increments the
number, or sets the field to
zero
when
the
last
pathname
is
returned.

19.5.2

Append Pathname

to Name

(Subopcode )03).

When
a
logical
name
represents a set of pathnames, the Append
Pathname to Name operation (subopcode )03)
adds
the
pathnames,
one at a time.
The logical name must have been created, and must
have
a pathname and parameters (if required) prior to performing
this operation.
The following fields of the

*
*

Return code

Subopcode -

Flags

Opcode -

Special SVCs

supervisor call block apply:

)43

)03

19-42

2270512-9701

DNOS System Design Document

*
*

Address

of name

Address of value

The operation is defined only for
name type must be set to 1.

logical names.

The

flag

for

19.5.3

Return Next Name

(Subopcode )05).

The
Return
Next
Name operation (subopcode 05) returns the next
logical name and, optionally, the pathname of the
logical
name.
The
next
logical name is either the preceding or following name
in alphabetic order, selected by a
flag
supplied
in
the
call
block.
The following

*
*
*
*
*
*
*

Opcode

fields of

the

supervisor call

block apply:

)43

Return code
Subopcode

)05

Flags
Address

of name

Address

of value

Miscellaneous

name
type
When
the
operation expects the
synonym.

flag
name

in the flags byte is
to
be
a
synonym,

set to zero, the
and
returns
a

The
address
of
name field must contain the address of a buffer
that contains the length of a name in the
first
byte,
and
the
characters
of that logical name in succeeding bytes.
The buffer
may contain zero in the
first
byte
when
no
logical
name
is
supplied.
The
operation returns the first name in alphabetical
order when no logical name is supplied.

2270512-9701

19-43

Special

SVCs

DNOS

System Design Document

The operation returns the next logical name in the buffer at
the
address in the address of name field.
When the next logical name
does not exist, the operation returns a zero in the first byte of
the
buffer.
This
buffer
must
be
large enough to contain an
eight-character logical name.
The address of value field must contain the address of
a
buffer
in
which
the
operation returns the pathname.
When the calling
task places zero in the first byte of this buffer, the
operation
does
not
return a pathname.
The buffer must be large enough to
contain the longest pathname that could be returned.
The contents of the miscellaneous field determines which name
is
the
next name.
When the field contains 1, the operation returns
the
preceding
name
in
alphabetical
order.
When
the
field
contains 0, the operation returns the succeeding name.
19.5.4

Purge Names (Subopcode )06).

The Purge Names operation (subopcode )06) deletes related logical
names
from
the set of logical names available to the task.
The
calling task supplies a name containing N characters.
A name
is
deleted if any of the following statements is true of that name:

The name contains N characters, and these
equal to those of the supplied name.

The
name
contains
N characters, all but the last are
supplied
name,
and
the
last
equal to those
of
the
than
the
last character of the
character
is
greater
supplied name.

The name contains more than N characters and the first N
characters are equal to those of the supplied name.

The name contains more than N characters, the first
N-l
characters
are equal to the corresponding characters of
the supplied name, and the Nth character is greater than
the Nth character of the supplied name.

characters are

No name that is
shorter
than
the
supplied
name
is
deleted.
Otherwise,
the
length of the name does not determine whether or
not it is deleted.
The
pathname
of
the
name
is
ignored
in
selecting a name for deletion.
The following fields of the supervisor call block apply:

Opcode -

Return code

Subopcode -

Special SVCs

)43

)06
19-44

2270512-9701

DNOS System Design Document

*
*

Flags
Address of name

When
the
name
type
flag in the flags byte is set to zero,
purges
operation expects the name
to
be
a
synonym,
and
synonyms available to the calling task.

the
the

The
address
of
name field must contain the address of a buffer
that contains the length of a name in the
first
byte,
and
the
characters of that logical name in succeeding bytes.
As
an
task:

example,

the

INFILE
ABCD

folloWing

logical names are defined for a
INPUT
ABCDEF

OUTFILE
ABCDE

If a purge names operation
were
performed
supplying
name
IN,
names
INFILE
and
INPUT would be deleted.
If the name supplied
were INF, the same two names would be
deleted.
If
ABCDE
were
supplied as a name, names ABCDE and ABCDEF would be deleted.

19.5.5

Enter New Stage (Subopcode )07).

When
the Enter New Stage operation (subopcode 07) is issued, the
calling task becomes the first and only
task
in
a
new
stage.
Tasks
bid
by
the
calling
task also execute in the new stage.
Logical names
and
synonyms
ava1lable
to
the
task
prior
to
entering
the new stage become the logical names and synonyms for
the new stage.
Additions and changes made by tasks in the
stage
apply only to the stage.
The following fields of the supervisor call

*
*
*
19.5.6

Opcode -

block apply:

)43

Return code
Subopcode -

)07

Return to Previous Stage (Subopcode )08).

Only
a
task
that
has
created
a
new stage may return to the
previous stage (the stage it belonged to before creating the
new
stage).
The
Return to Previous Stage operation (subopcode )08)
returns the calling task to the previous stage, optionally taking
a set of synonym names.
When other tasks remain in the current stage, or when
descendant
stages
remain,
the
calling task returns to the previous stage,

2270512-9701

19-45

Special SVCs

DNOS System Design Document

and the current stage remains.
When the calling task is the only
task in the current stage and no
descendant
stages
exist,
the
calling
task returns to the previous stage and the current stage
is deleted.
The descendant error list is
the
mechanism
for
retaining
the
values
of error synonyms $$CC, $$ES, $$MN, $$FN, and $$VT when a
stage is deleted.
When a descendant stage is deleted,
and
that
stage
has
error synonym $$CC in the synonym table, a descendant
error list entry is built.
The entry becomes the first entry
in
the
descendant
error list for the stage, or an additional entry
in an existing list.
The descendant error list consists of a byte
that
contains
the
length
of
the
list, followed by the entries of the list.
Each
entry consists of the following:

The value of error synonym $$CC~ preceded by a
contains the length of the value.

The value of error synonym $$ES, preceded by a byte that
contains the length of the value, or zero
if
no
value
has been assigned.

The value of error synonym $$MN, preceded by a byte that
contains
the
length
of the value, or zero if no value
has been assigned.

The value of error synonym $$FN, preceded by a byte that
contains the length of the value, or zero
if
no
value
has been assigned.

The value of error synonym $$VT, preceded by a byte that
contains
the
length
of the value, or zero if no value
has been assigned.

When a stage is deleted,

byte that

the following actions occur:

Add the entries, if any, in the descendent error list of
the terminating stage to the list of the previous stage.

When error
synonym
$$CC
has
been
assigned
for
the
terminating
stage,
place a descendant error list entry
in the list of the previous stage.

Delete
synonyms
and
terminating stage.

The following fields

Opcode -

Return code

Special SVCs

logical

names

of the supervisor call

defined

for

the

block apply:

)43

19-46

2270512-9701

DNOS System Design Document

*
*

SUbopcode -

)08

Address 6f name

The
address
of
name field contains the address of a buffer, or
zero.
When
the
field
contains
zero,
no
synonym
names
are
returned.
When the field contains an address, the address is the
address
of
a
synonym
buffer.
The buffer contains a byte that
contains the length of the synonym list, followed by the names of
the synonyms in the list.
Each synonym is
preceded
by
a
byte
that
contains
the length of the synonym.
The synonym buffer is
returned to the previous stage, and the
Name
Manager
adds
the
synonyms
to
those
of
the previous stage, obtaining the values
from the synonym segment.
19.5.7

Return Next Error Entry "(Subopcode )09).

The Return Next Error Entry opera~ion (subopcode )09) obtains the
first entry on the descendant error
list
previously
described.
The operation also deletes the entry.
This operation is normally
performed by system tasks that process errors.
The following fields of the supervisor call block apply:

*
*
*
*

Opcode -

)43

Return code
Subopcode -

)09

Address of value

The
address
of
value field contains the addFess of a buffer in
which the operation returns a descendant error list
entry.
The
first byte of the buffer contains the length of the buffer.
When
there
is
no entry, the operation returns zero in the first byte
of the buffer.
Otherwise, the operation returns
the
length
of
the
entry
in
the
first
byte
of
the buffer, followed by the
characters of the entry.
19.5.8

Determine Segment Size (Subopcode )OA).

The Determine Segment Size operation (subopcode )OA) returns
size
required
for
a
segment
large
enough to contain all
logical names or synonyms available to the calling task.
The following fields of the supervisor call

*
*

Opcode -

the
the

block apply:

)43

Return code

2270512-9701

19-47

Special SVCs

DNOS System Design Document

Subopcode -

*
*

Flags

)OA

Miscellaneous

The name type flag in the flags field is set to 0 to
obtain
the
size
for
a
synonym
segment,
or to 1 to obtain the size for a
logical name segment.
The size, in bytes, required for the specified
returned in the miscellaneous field.

name

segment

Copy Names to New Segment (Subopcode )OB).

19.5.9

The
Copy
Names
to New Segment operation (subopcode )OB) copies
the logical names or synonyms available to the calling task to
a
specified segment.
The segment size should be obtained using the
Determine
Segment
Size
operation,
and
a segment of that size
should be
allocated.
The
segment
should
be
a
memory-based
segment with the share-protect and reusable attributes.
The following fields of the supervisor call block apply:

Opcode -

*
*
*

Return code

Flags

Miscellaneous

)43

Subopcode -

)OB

The
name
type
flag
in
the
flags field is set to 0 to copy a
synonym segment, or to 1 to copy a
logical
name
segment.
The
segment
ID
of
the
allocated
segment
is
placed
in
the
miscellaneous field.
19.5.10

Creating an Empty Name Segment (Subopcode )OD).

The Create Empty Name Segment operation (subopcode
)OD)
creates
an
empty
logical
name
segment.
The
following fields of the
supervisor call block apply:

*
*
*

Opcode -

)43

Return Code
Subopcode -

Special SVCs

)OD

19-48

2270512-9701

DNOS System Design Document

*
*
*

Flags
Segment size
Segment ID

The only flag examined is the global flag.
This operation can be
performed only once.
This is done by the system restart task.
The address of name field,
parameter must be zero.

address of value field,

and address of

The segment size is a value in bytes, specifying the initial size
of the segment.
The run ID of the segment is returned.
The following is an example of coding for a supervisor call block
for a Create Empty Name Segment operation and
for
the
required
buffers:
EVEN
CEMNAM BYTE )43
CENS
BYTE 0
BYTE )OD
BYTE )00
DATA 0
DATA 0
DATA 0
DATA )400
CID
DATA 0

19.5.11

CREATE EMPTY NAME SEGMENT

Saving a Name Segment (Subopcode )OE).

The
Save
Name Segment operation (subopcode )OE) saves a logical
name segment to
a
disk
file.
The
following
fields
of
the
supervisor call block apply:

*
*
*
*
*
*

Opcode

)43

Return Code
Subopcode

)OE

Flags
Address of name
Segment ID

The
only flags examined are the global flag and the run ID flag.
The global flag set to one indicates that the global names are to
be saved.
The run ID flag indicates that the segment to save
is
passed
in
the
call block in the run ID field.
If no flags are

2270512-9701

19-49

Special SVCs

DNOS System Design Document

set

the

job local synonyms are saved.

The address of name field must contain the address
of
a
buffer
that
contains
the
length of the name in the first byte and the
characters of the logical name definition
in
succeeding
bytes.
Names
can
be
saved
on
any
disk
on
any
system.
The
one
restriction is job-local logical names may not be used to specify
the pathname.
The address of value field,
must be zero.

and address of parameter

If
the
user flag for global operation is
names will be written, otherwise the
job
written,
unless the run ID flag is set to
segment passed in the run ID field will be

list

field

set to one, the global
local
names
will
be
one, in which case the
saved.

The following is an example of coding for a supervisor call block
for a Save Name Segment operation and for the required buffers:
SAVE NAME SEGMENT
EVEN
SAVNAM BYTE )43
SVNS
BYTE 0
BYTE )OE
BYTE )00
DATA LNME
DATA 0
DATA 0
LNME
BYTE 1 1
,
.DISK.FILE2'
TEXT

19.6

MODIFY BTA OR JCA SIZE

The Modify BTA or JCA Size SVC ()4A)

is of the following format:

Align on word boundary
Software privileged

Hex Offset
00
02
04
06

Special SVCs

*----------------+-----------------*
I
4A
I
800 beets and it must be
less than the maximum JCA -size.

19.7

HALT/RESUME TASK

The Halt/Resume Task SVC is

the following format:
Align on word boundary
Software privileged

Hex Offset
00

02
04

*----------------+-----------------*
I
4B
I

I
+----------------+-----------------+
I Task Run ID
I Task Station ID I
+----------------+-----------------+
I
I
Sub-Opcode
I
+----------------------------------+
I
Reserved
I
*----------------------------------*

Byte 5 -

o 1 -

Subopcodes:

Halt task
Resume task

The Halt/Resume Task SVC is used by the SCI Debugger
to
halt
a
task
before showing debugging information and to resume the task
once that information has been displayed to the user.
The program management routine PMHALT executes this
SVC
at
XOP
level.
If the station ID supplied is nonzero, the routine first
checks to be sure a task with the supplied run-time ID is running
at that station.
If no such task is running, an error code of
1
is returned.

2270512-9701

19-51

Special

SVCs

DNOS System Design Document

If
a task is found, the current state of the task is returned in
the byte reserved for the task state.
If the subopcode requested
is Halt, PMHALT sets the halt bit in the TSB
flags
TSBFL2.
If
the
current
task
state
is active, PMHALT calls the deactivate
routine and sets the task state to 6 (unconditional wait).
If the subopcode requested is Resume, PMHALT clears
all
of
the
debug (breakpoint) bits and the halt bit in the TSB flags TSBFL2.
If
the task is in state 6, PMHALT calls NFPACT to place the task
on the active queue.
In other cases, it exits after setting
the
TSB flags.

19.8

EXPAND JCA

The
job
communication
area
(JCA),
one of the data structures
maintained for each job by the system, is expandable.
The system
uses the Expand JCA operation to provide more space for
the
JCA
as required.
This operation is not available to user tasks.
Subopcode )08 specifies the Expand JCA operation.
Only the first
16 bytes of the supervisor call block apply.
The specific fields
are:

*
*
*
*

Opcode
Return code
Subopcode
Job run ID

The job run ID is supplied by the system task.
The following is an example of coding for a
for an Expand JCA operation:
EVEN
EXPJCA BYTE
XJERR
BYTE
BYTE
BYTE
DATA
DATA
DATA

Special SVCs

supervisor call block

EXPAND THE JCA FOR JOB )4F.
)48

°
°

)08

°)4F
0,0,0,0

19-52

2270512-9701

DNOS System Design Document

SECTION 20
LINKING INFORMATION FOR DNOS

20.1

OVERVIEW

Linking
the
portions
of DNOS involves standard use of the Link
Editor for
assembly
language
and
for
Pascal
modules.
Link
control
files for the nonconfigurable portions of DNOS are found
in
the
directories
DSC.LINK.SYSTEM
and
DSC.LINK.UTILITY.
Configurable
portions
of
DNOS
are
determined
during
system
generation and appropriate selections are included
in
the
link
control files DMLINK, IOULINK, and SYSLINK.
Conventions
used
in building the link control files are simple.
Each file makes use of the NOPAGE and ERROR options of
the
Link
Editor.
Wherever
possible
LIBRARY
and INCLUDE statements are
used to keep the files short and easy to read.
Tasks written in assembly language generally include
only
their
own
object
library.
If
they
make
use
of S$ routines, they
include the library VOLOBJ.SCI990.S$OBJECT.
In addition
to
the
S$ library, tasks written in Pascal have three run-time libraries
available
to
them.
These are located via the PASCAL synonym in
the libraries PASCAL.MINOBJ, PASCAL.LUNOBJ, and PASCAL.OBJ.
The
MINOBJ
library
is
a
minimum
size
library
for
a
non-debug
environment.
The LUNOBJ library is for a non-SCI environment and
includes routines to support I/O by LUNO.
The OBJ library is the
run-time collection for either environment.
Pascal tasks which make use of standard initialization must
use
the
statement
INCLUDE (R$TASKDP)
as
the first item in the
link control stream after the TASK or PHASE
0
statement.
When
linking
a
Pascal task which has a single procedure segment, the
PROCEDURE declaration must be followed
by
INCLUDE (R$PROCDP).
If
a procedure is shared by more than one task, a SEARCH command
must appear
at
the
end
of
the
include
statements
for
the
procedure,
and
an
ALLOCATE command must immediately follow the
R$TASKDP include statement.
This
is
to
ensure
that
all
the
shareable
run-time
routines
are
included
in
the
procedure
segment.
The directory DSC.LINK.SYSTEM includes
link
control
files
for
each
of
the
DNOS system tasks.
The directory DSC.LINK.UTILITY
includes link control files for each of the utility
tasks.
The
directory
DSC.LINK.DSR has link control files for DSRs, and the
directory
DSC.LINK.DNOSPROG
has
link
control
files
for
the
2270512-9701

20-1

Linking Information

DNOS

System Design Document

programs
used
to
build
DNO~.
Linkmaps for each of these are
found
in
the
directories
VOLLST.LINKMAP.SYSTEM
and
VOLLST.LINKMAP.UTILITY,
where
VOLLST
is
the
volume
to which
listings are
written
during
a
build
of
DNOS.
The
.SYSTEM
directory
includes
linkmaps
for each of the DNOS system tasks;
the .UTILITY subdirectory for each of
the
utility
tasks
which
supports
SCI
commands.
To
find the appropriate linkmap for a
given SCI command, check the task name being bid by
the
command
procedure
and search for that name as a linkmap file name in the
DSC.LINKMAP.UTILITY directory.
The paragraphs below describe the linking information
from
link
control
files
for a system task written in assembly language, a
system tBsk written in Pascal, a
DSR,
and
the
system
nucleus
(seed).
Examples
of link control files generated during system
generation are also presented.

20.2

LINKING A SYSTEM TASK

The link control stream for a system task must
provide
for
the
task
to
be
loaded
at address )COOO.
This requires use of the
PHASE command with the base option set to
)COOO.
The
starting
address
of
)COOO
allows
the task address space to include the
system root and a JCA prior to the task code.
All
system
tasks
are
linked
with
the procedure DUMROOT, which enables access to
the system root.
DUMROOT is built from the interrupt tables, the
system seed, and the common blocks 'initialized by sysgen.
Appropriate libraries must be
specified
if
subroutine
support
modules
are
included.
The link control stream for the IPL task
is shown below.
It includes support routines
from
the
DISKMGR
and
UTCOMN directories as well as the set of IPL object modules.
The synonym VOLOBJ is used throughout this section
t'o
represent
the
volume
on
which
the
operating
system object directories
reside.
NOPAGE
ERROR
FORMAT IMAGE,REPLACE
LIBRARY
VOLOBJ.DISKMGR.OBJECT
LIBRARY
VOLOBJ.UTCOMN.OBJECT
LIBRARY
VOLOBJ.NAMMGR.OBJECT
PROCEDURE DUMROOT
DUMMY
INCLUDE
VOLOBJ.S$SGU$.DUMROOT
PHASE O,IPL,PROG )COOO
INCLUDE
VOLOBJ.LOADERS.OBJECT.SLIPL
INCLUDE
VOLOBJ.LOADERS.OBJECT.SLCRSH
INCLUDE
VOLOBJ.LOADERS.OBJECT.SLDINT
INCLUDE
VOLOBJ.LOADERS.OBJECT.SLDIO
INCLUDE
VOLOBJ.LOADERS.OBJECT.SLDISP

Linking Information

20-2

2270512-9701

DNOS System Design Document

INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
END

VOLOBJ.LOADERS.OBJECT.SLDSR
VOLOBJ.PERFORM.OBJECT.PFWCSO
VOLOBJ.PERFORM.MOBJECT.PFDWCS
VOLOBJ.LOADERS.OBJECT.SLFDB
VOLOBJ.LOADERS.OBJECT.SLINIT
VOLOBJ.LOADERS.OBJECT.SLIV
VOLOBJ.LOADERS.OBJECT.SLJCA
VOLOBJ.LOADERS.OBJECT.SLLMOD
VOLOBJ.LOADERS.OBJECT.SLOPEN
VOLOBJ.LOADERS.OBJECT.SLPFIO
VOLOBJ.LOADERS.OBJECT.SLTABL
VOLOBJ.LOADERS.OBJECT.SLTASK
VOLOBJ.LOADERS.OBJECT.SLVRFY
VOLOBJ.LOADERS.OBJECT.SLWCS
(UTPTCH)
(UTVERS)
VOLOBJ.LOADERS.OBJECT.SLEND

The following link control stream links the log
formatter
task,
LGFORM.
It
is written in Pascal and requires run time support,
S$ routine support, interface
with
assembly
language
routines
using
the
PASASM
directory,
and
routines
from
the
UTCOMN
directory.
The file specifies the Pascal base
routine
R$TASKDP
as
the
first
portion
of the LGFORM task and includes required
modules from the various directories as needed.
NOPAGE
NOSYMT
VOLOBJ.LOG.OBJECT
LIBRARY
PASCAL.MINOBJ,PASCAL.LUNOBJ,PASCAL.OBJ
LIBRARY
VOLOBJ.UTCOMN.OBJECT
LIBRARY
VOLOBJ.PASASM.OBJECT
LIBRARY
PROCEDURE DUMROOT
DUMMY
INCLUDE
VOLOBJ.S$SGU$.DUMROOT
PHASE O,LGFORM,PROG )COOO
SYSTEM LOG FORMATTER TASK
INCLUDE (R$TASKDP)
INCLUDE (LGFORM)
INCLUDE (LGDATA)
INCLUDE (UTR$ST)
INCLUDE (UTPTCH)
END

20.3

LINKING A DSR

A DSR must be linked as a system
task,
including
the
relevant
as
the
source
code
modules
written
by
the
user
as
well
support
appropriate modules from VOLOBJ.IOMGR.OBJECT
to
access
2270512-9701

20-3

Linking Information

DNOS System Design Document

subroutines.
The section on writing DSRs lists the location and
function of each of the support
subroutines.
The
example
DSR
link
given
below
is
for
the 911 VDT and includes the modules
which
provide
keyboard
support
(IOKB)
and
end
of
record
processing (IONRCD).
NOPAGE
ERROR
PROCEDURE DUMROOT
DUMMY
INCLUDE
VOLOBJ.S$SGU$.DUMROOT
PHASE O,DSR911,PROG )COOO
VOLOBJ.DEVDSR.OBJECT.DSR911
INCLUDE
INCLUDE
VOLOBJ.IOMGR.OBJECT.IONRCD
INCLUDE
VOLOBJ.IOMGR.OBJECT.IOKB
INCLUDE
VOLOBJ.UTCOMN.OBJECT.UTPTCH
INCLUDE
VOLOBJ.DEVDSR.OBJECT.PWRFY
END

20.4

LINKING THE DNOS SEED

The
common
nucleus
functions are linked into a task nanr'ed SEED
using the link control file in DSC.LINK.SYSTEM.SEED.
Modules are
included if they must be used by operating system code in any
of
a number of mapping configurations.
The SEED is included as part
of
the
system root when the system is generated.
The following
is an example of the link control file for the SEED.
ERROR
PARTIAL
TASK
SEED
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE

VOLOBJ.NUCLEUS.OBJECT.NFMAT
VOLOBJ.IOMGR.OBJECT.IOBM
VOLOBJ.IOMGR.OBJECT.IODBGN
VOLOBJ.IPC.OBJECT.IPCPR
VOLOBJ.IPC.OBJECT.IPCXFR
VOLOBJ.LOG.OBJECT.LGQACC
VOLOBJ.LOG.OBJECT.LGQBLK
VOLOBJ.NUCLEUS.OBJECT.NFACTL
VOLOBJ.NUCLEUS.OBJECT.NFACTQ
VOLOBJ.NUCLEUS.OBJECT.NFATOL
VOLOBJ.NUCLEUS.OBJECT.NFCLOK
VOLOBJ.NUCLEUS.OBJECT.NFCOPY
VOLOBJ.NUCLEUS.OBJECT.NFCRSH
VOLOBJ.NUCLEUS.OBJECT.NFDACT
VOLOBJ.NUCLEUS.OBJECT.NFCEOR
VOLOBJ.NUCLEUS.OBJECT.NFDEF
VOLOBJ.NUCLEUS.OBJECT.NFDLNK
VOLOBJ.NUCLEUS.OBJECT.NFDLOV
VOLOBJ.NUCLEUS.OBJECT.NFDOOR

Linking Information

20-4

2270512-9701

DNOS System Design Document

INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
INCLUDE
2270512-9701

VOLOBJ.NUCLEUS.OBJECT.NFDOVB
VOLOBJ.NUCLEUS.OBJECT.NFDQl .
VOLOBJ.NUCLEUS.OBJECT.NFDQH
VOLOBJ.NUCLEUS.OBJECT.NFDTOL
VOLOBJ.NUCLEUS.OBJECT.NFDTSK
VOLOBJ.NUCLEUS.OBJECT.NFDWOM
VOLOBJ.NUCLEUS.OBJECT.NFDWOT
VOLOBJ.NUCLEUS.OBJECT.NFENAB
VOLOBJ.NUCLEUS.OBJECT.NFEOR
VOLOBJ.NUCLEUS.OBJECT.NFINT2·
VOLOBJ.NUCLEUS.OBJECT.NFLOVB
VOLOBJ.NUCLEUS.OBJECT.NFLWCS
VOLOBJ.NUCLEUS.OBJECT.NFMAPO
VOLOBJ.NUCLEUS.OBJECT.NFPACT
VOLOBJ.NUCLEUS.OBJECT.NFPOP
VOLOBJ.NUCLEUS.OBJECT.NFPSH
VOLOBJ.NUCLEUS.OBJECT.NFPWOT
VOLOBJ.NUCLEUS.OBJECT.NFPWUP
VOLOBJ.NUCLEUS.OBJECT.NFQERR
VOLOBJ.NUCLEUS.OBJECT.NFQOVB
VOLOBJ.NUCLEUS.OBJECT.NFQUEI
VOLOBJ.NUCLEUS.OBJECT.NFQUEH
VOLOBJ.NUCLEUS.OBJECT.NFSRTN
VOLOBJ.NUCLEUS.OBJECT.NFTBDO
VOLOBJ.NUCLEUS.OBJEC~.NFTERM

VOLOBJ.NUCLEUS.OBJECT.NFTMGR
VOLOBJ.NUCLEUS.OBJECT.NFTRTN
VOLOBJ.NUCLEUS.OBJECT.NFWAKE
VOLOBJ.NUCLEUS.OBJECT.NFWOMJ
VOLOBJ.NUCLEUS.OBJECT.NFWOML
VOLOBJ.NUCLEUS.OBJECT.NFWOTL
VOLOBJ.NUCLEUS.OBJECT.NFXOPS
VOLOBJ.NAMMGR.OBJECT.NMTRAN
VOLOBJ.PROGMGR.OBJECT.PMMPRI
VOLOBJ.PROGMGR.OBJECT.PMTSCH
VOLOBJ.REQPROC.OBJECT.RPDQl
VOLOBJ.REQPROC.OBJECT.RPMAP2
VOLOBJ.REQPROC.OBJECT.RPPRCK
VOLOBJ.REQPROC.OBJECT.RPSGCK
VOLOBJ.SEGMGR.OBJECT.SMBLDS
VOLOBJ.SEGMGR.OBJECT.SMBUFF
VOLOBJ.SEGMGR.OBJECT.SMCHUC
VOLOBJ.SEGMGR.OBJECT.SMCSGO
.VOLOBJ.SEGMGR.OBJECT.SMDSGB
VOLOBJ.SEGMGR.OBJECT.SMDSSB
VOLOBJ.SEGMGR.OBJECT.SMFSID
VOLOBJ.SEGMGR.OBJECT.SMLOAD
VOLOBJ.SEGMGR.OBJECT.SMMJCA
VOLOBJ.SEGMGR.OBJECT.SMMSEG
VOLOBJ.SEGMGR.OBJECT.SMMTBL
VOLOBJ.SEGMGR.OBJECT.SMRMVE
VOLOBJ.SEGMGR.OBJECT.SMSRCH
VOLOBJ.SEGMGR.OBJECT.SMUNLD
20-5

Linking Information

DNOS

System Design Document

END

20.5

LINK CONTROL FILES BUILT DURING SYSTEM GENERATION

Based on the options specified during system generation, a set of
link control files is built
as
SYSLINK,
IOULINK,
and
DMLINK.
These
files
are
in the directory .S$SGU$.(system name> for the
system you generate.
SYSLINK is the link of the
major
portions
of
the
operating
system
and
varies
according
to
user
specification of the following:

*
*
*
*

System SVC options
User SVCs
File Security
KIF support

The IOULINK file varies depending on whether
included.
The
DMLINK
task.

file

Linking Information

the

link control file

20-6

or not

security

for the

disk manager

2270512-9701

DNOS System Design Document

SECTION 21
DNOS SOURCE DISK STRUCTURE

21.1

DIRECTORY STRUCTURE

The following is a directory listing of the directorie.s on a DNOS
source disk.
Throughout this section, DSC is used as
a
synonym
for the volume on which DNOS source code resides.

AGTASK
ALN
ANALZ
ASP
AUI
AXREF
BATCH
BDD
BEMF
BLDPROCS
BMF
CB
CC
CD
CKD
CKR
COM
CONDASM
CONDPASC
CP
CPI
CRV
CSK
CSM
CV
CVD
DCOPY
DD
DEBUG
DEBUGGER
DEVDSR
DIOU
DISKMGR
DNCMS

2270512-9701

21-1

DNOS

Source Structure

DNOS System Design Document

DSCBLD
DXDP
EDITOR
FILEMGR
IBMUTL
IDS
IDT
IFSVC
IOMGR
IOU
IPC
JENED
JOBl>1GR
KIFMGR
LAGFR
LD
LINK
LINKER
LLR
LOADERS
LOC
LOGON
LS
LSC
LTS
MACROS
MAD
MAILBOX
MCDT
MD
MESSAGES
MKL
MLP
MPC
MPF
MPI
MRF
MS
MSAR
MTE
MVI
NAMMGR
NUCLEUS
0$
OPERATOR
PASASM
PATCH
PERFORM
PF
PICT
PROCMGR
RAL
REQPROC
DNOS Source Structure

21-2

2270512-9701

DNOS System Design Document

RESOLVE
RESTART
RVI
RWCRU
S$
S$SGU$
SCI990
SCS
SCU
SD
SDSMAC
SECURITY
SEGMGR
SEM
SIS
SJS
SMMAP
SMS
SND
SOS
SPOOLER
SRFI
SVS
SYSJEN
SYSOVLY
TEMPLATE
TFTPC
TIGRESS
TINFO
TPCALANS
TPDISC
TPLHPC
TPMHPC
UTCOMN
XBJ
XJM
XOI

The following files

also appear on the DNOS source disk:

DNOSPROG
TAPEOBJ

21.2

COMPONENTS USED IN BUILDING DNOS

Building
DNOS involves creating several batch streams as well as
using
some
batch
streams
which
already
exist
in
the
DSC.BATCH.BUILD
directory.
The batch streams which are created
2270512-9701

21-3

DNOS

Source Structure

DNOS

System Design Document

during the build are a product of the Create Batch
(CB)
utility
working
with the batch stream templates in the DSC.BATCH.CBINPUT
directory.
Any
process
(batch
stream)
which
needs
to
be
performed on a directory of files is generated by CB.
All
of
the
files
necessary
for
building
DNOS reside in the
DSC.BATCH
directory.
The
components
of
this
directory
are
described in the paragraphs which follow.
ASSEMBLE
This
is
a
directory
of
batch
streams,
each
of
which
assembles a directory of DNOS source code.
In
general,
a·
DNOS
code directory comprises the modules of a subsystem or
single utility.
This directory is built using CB and exists
only after a DNOS build has been done.
Executing the
batch
stream
DSC.BATCH.ASSEMBLE.ALL
causes
all
of
the
batch
streams in this directory to be executed.
BUILD
This directory consists of the batch streams to
build
DNOS
as
well
as
those used to build the DNOS SCI menus and SCI
command procedures.
Its
files
are
described
further
in
other portions of this section.
CBINPUT
When
CB
is
used
to
create
some of the DNOS build batch
streams, templates for those batch streams are found in this
directory.
The templates are
described
further
in
other
portions of this section.
COMPILE
Like
the ASSEMBLE directory, the COMPILE directory is built
using CB.
This directory is composed of the
batch
streams
which compile all of the Pascal source in DNOS.
The COMPILE
directory
exists
only
after
a
DNOS build has been done.
Executing the batch stream DSC.BATCH.COMPILE.ALL causes
all
of
the
compilation
batch
streams in this directory to be
executed.
LINK
This directory contains batch
streams
to
link
the
whole
system.
It
is built using CB and exists only after a DNOS
build
has
been
done.
Executing
the
batch
stream
DSC.BATCH.LINK.ALL links the whole system.
PICT
This
directory
consists of two batch streams, one of which
generates PTABLE
templates
for
the
ATABLE
directory
in
DSC.TEMPLATE and one of which generates PTABLE templates for
the
COMMON
directory.
This directory exists only after a
DNOS build has been done.
TRANSLIT
DNOS Source Structure

21-4

2270512-9701

DNOS System Design Document

This directory is composed of a set of batch
streams
which
transliterate
the
source
modules of the LINKER directory.
It exists only after a DNOS build has been done.
Executing
the
batch
stream
DSC.BATCH.TRANSLIT.ALL causes all of the
transliteration
batch
streams
in
this
directory
to
be
executed.
The
Create
Batch
(CB)
utility
processes
an input directory,
applying to each element
of
the
directory
a
specified
batch
stream
template.
It generates an output batch stream to a file
specified when the CB command is issued.
The command prompts are
documented in
the
DNOS System Command Interpreter (SCI)
Reference Manual.
Files
within
the
DSC.BATCH.CBINPUT directory are used as batch
template files for CB when creating many of the DNOS build
batch
streams.
These
CBINPUT
files
are described in the paragraphs
which follow.
ALL
This template
is
used
to
create
a
batch
stream
which
executes
a
directory
of batch streams.
It is used in the
DNOS build process to create the DSC.BATCH.(D).ALL where (D)
is ASSEMBLE, AXREF, COMPILE, DELETE, or PICT,
depending
on
which is needed.
ASSEMBLE
This template is used to create the batch stream to assemble
all the modules in one DNOS source directory.
AXREF
This
template is used to create a batch stream to produce a
directory
of
DNOS
cross-reference
listing
for
a
given
listings.
CB
This
template
is
used
to
create the DSC.BATCH.BUILD.(?)
batch stream where (?) is on~ of ASSEMBLE, AXREFS,
COMPILE,
DELETE,
PICT,
and
TRANSLIT.
Each of these batch streams
creates the directory
of
batch
streams
to
process
each
appropriate
directory
of
DNOS.
For
example,
the batch
stream e DSC.BATCH.BUILD.ASSEMBLE built using CB is a
batch
stream which
creates the assembly batch streamS (using CB)
for each of the source directories of
DNOS.
This
set
of
assembly
batch
streams resides in DSC.BATCH.ASSEMBLE.
the
whole
DNOS
directory
using
one
of
the
other
CBINPUT
templates.
For
example, it is used to build the directory
of assembly batch streams using the ASSEMBLE template.
COMPILE
This template is used to create the batch streams
one
of
all of
the
Pascal
source
modules
in
directories.

2270512-9701

21-5

DNOS

to compile
the
DNOS

Source Structure

DNOS System Design Document

DELETE
This
template
is used to create the batch stream to delete
the old, outdated object and
listing
directories
for
the
corresponding DNOS source directory.
FORTRN78
This
template
is
used to create a batch stream to compile
all of the
FORTRAN
source
modules
in
one
of
the
DNOS
directories.
LINK
This template is used to build a
of DNOS.

batch stream to link a part

PICT
This
template
is
used to create the batch stream to build
the PTABLE template directory for the appropriate ATABLE
or
COMMON template directory.
TRANSLIT
This
template
is
used
to
create
the
batch
stream
to
transliterate the modules in a given DNOS source
directory.
The
only
directory
for which this is needed is the LINKER
source directory.
The files in the DSC.BATCH.BUILD directory are
listed
in
Table
21-1.
The
purpose
of
each
file is indicated.
Those created
during the build process exist only after a DNOS build
has
been
done;
these
are indicated by a star in the second column of the
table.
All
those
not
created
during
a
build
are
further
explained
in
the
paragraphs
which detail the steps in doing a
DNOS build.
Table 21-1
File Name

Purpose

ASSEMBLE

AXREFS

BATCH
BSD2
BST2
BST3
BST4
CD1400
COMPILE
DELETE

DNOS Batch Stream Files

*
*

Creates the DSC.BATCH.ASSEMBLE directory
of batch streams to assemble all source
Creates the DSC.BATCH.AXREF directory of
batch streams to generate cross-reference
lists
Creates batch streams
Used for building DNOS from floppy disks
Used for building DNOS from tape
Used for building DNOS from tape
Used for building DNOS from tape
Builds a CD1400 system disk
Creates the DSC.BATCH.COMPILE directory of
batch streams to compile all source
Creates the DSC.BATCH.DELETE directory of
batch streams to delete object and

DNOS Source Structure

21-6

2270512-9701

DNOS System Design Document

DNOS
DNOSPROG
DSSO
DS200
DS300
DS80
LNKDNOS
MENU
MESSAGEI
MESSAGE2
OBJECT
OBJKIT
PICT

PROCO
PROC2
PROC4
PROC6
PROCSYS
S$LANG
S$OBJECT
S$SECURE
S$UTIL
SRCKIT
TAPE
TRANSLIT

2270512-9701

listings
Builds the DNOS system disk to be shipped
Builds a program file with DXI0 versions
of DNOS utilities needed to build DNOS
Builds DSSO system disk
Builds DS200 system disk
Builds DS300 system disk
Builds DS80 system disk
Builds the linkable parts needed to
generate DNOS
Builds the DNOS SCI menus
Builds the source directories and the
DNOS usable
directories of short and long form
messages as well as the batch streams to
build DNOS SCI command procedures
Builds the DNOS object from the source by
executing the ASSEMBLE, COMPILE, and
TRANSLIT batch streams
Builds a shippable DNOS object disk from
DNOS object libraries
Creates the PTABLE templates from the
corresponding ATABLE and COMMON
templates
Creates the privilege level 0 ~NOS SCI
procedures
Creates the privilege level 2 DNOS SCI
procedures
Creates the privilege level 4 DNOS SCI
procedures
Creates the privilege level 6 DNOS SCI
procedures
Creates the procedures for .SSYSTEM.S$CMDS
Creates the .S$LANG program file and
installs the Assembler and Link Editor
Builds the directory .SCI990.S$OBJECT
Performs the task, procedure, and overlay
installations to build the .SSECURE
program file.
Performs the task, procedure, and overlay
installations to build the .S$UTIL
program file.
Builds from source kit
Builds DNOS onto tape
Creates the DSC.BATCH.TRANSLIT directory
of batch streams to transliterate DNOS
source directories

21-7

DNOS Source Structure

DNOS System Design Document

21.3

THE PROCEDURE FOR BUILDING DNOS

The DNOS source disk includes the set of DNOS source modules,
a
program file
of
special
tasks
to build
DNOS, and a command
procedure library with
special
commands
to
build
DNOS.
The
process must
be executed using DNOS, following the instructions
in the DNOS Source Installation Document.

21.4

DNOS PROGRAM FILES

Table 21-2 and Table 21-3 are maps of the DNOS utility and system
program files, respectively.
The following
flags
are
used
in
both tables:
Flags in Program File Maps
FLAG DEFINITIONS
D
PRI - PRIORITY
U
S
- SYSTEM
o
P
- PRIVILEGED
C
M
- MEMORY RESIDENT
W
R
- REPLICATARLE
SH RU - REUSABLE
MAP CP - COPYABLE
OVLYE
- EXECUTE PROTECTED
SP - SOFTWARE PRIVILEGED
B
PIIS - PROCEDURE 1 IS ON SAME PROGRAM FILE
P2/S - PROCEDURE 2 IS ON SAME PROGRAM FILE

DNOS Source Structure

21-8

DELETE PROTECTED
UPDATABLE
OVERFLOW
WRITABLE CONTROL STORE
WRITE PROTECTED
SHARABLE
RELOCATION BIT MAP PRESENT
OVERLAY LINK
BYPASS SECURITY
AS TASK
AS TASK

2270512-9701

DNOS System Design Document

Table 21-2

Map of Utility Program File

FILE MAP OF .S$UTIL
TODAY IS 13:34:26 TUESDAY, SEPTEMBER 27, 1983.
TASK SEGMENTS: MAX POSSIBLE
ID NAME
LENGTH LOAD PRI S
01 SCI990
2056 7FAO 1
02 TINFO
30B8 7FAO 4
03 MS
OC28 lAOO 4
04 PMTERM
09CA COOO 0 S
05 IOTBID
0132 COOO 0 S
06 IPC
IB76 COCO 0 S
07 MAILBOX 24AA 0000 4
08 CKD
2096 lAOO 4
09 HPC
IF96 lAOO 4
OA LOGON
2568 COOO 0 S
OB XPD
ODE A COOO 1 S
OC SMM
OBEC COOO 1 S
OD DEBUGGER 70E8 lAOO 4
OE EDITOR
159C 5600 1
OF TIGR
5194 15AO 4
10 MRFSRF
2202 lAOO 4
11 CCAF
1224 lAOO 4
12 LS
OC42 lAOO 4
13 RD
74EO 0000 4
14 VB
6DEC 0000 4
15 CP
4FFO lAOO 4
16 IOBREAK 023C COOO 0 S
17 SVS
lE28 0000 4
18 RVI
OA48 lAOO 4
19 RESTART 399A COOO a s
IA ANALZ
65B2 1AOO 1
IB IFSVC
2108 lAOO 4
lC XBJS
2454 lAOO 4
ID MPFMKF
2090 lAOO 4
IE SCS
24F6 COOO 4 S
IF PMSBID
02F4 COOO 0 S
20 IUV
OD58 COOO 0 S
21 LGFORM
3F2A COCO 0 S
22 DD
lB92 lAOO 4
22EE lAOO 4
23 LD
lD4A lAOO 4
24 LLR
25 PMPINS
25CO COOO 0 S
26 MPISPI
IB70 lAOO 4
27 SMS
OD98 COOO 4 S
lCA4 COOO 0 S
28 PMPDEL
29 CKR
1580 lAOO 4
2A IDT
0952 lAOO 4
304C COOO 4 S
2B SIS
2C MADSAD
1576 1AOO 4
029C coon a s
2D PMRWTK
3130 COOO 4 S
2E SCU
OA74 lAOO 4
2F SND

2270512-9701

= 176
P M R D U RU CP E 0 C SP B OVLY PI/S P2/S
R
02/Y 03/Y
P
R
02/Y 03/Y
R
02/Y
P
SP
Ol/Y
P M
SP
01/Y
P
SP
01/Y
P

02/Y
02/Y
01/Y
01/Y
Ol/Y
02/Y
02/Y 05/Y
04/Y
02/Y
02/Y
02/Y

P
P
P
P

P
P
P
P
P
P
P
P
P
P
P
P
P

R
R
R

R
R

R
R
R

SP
SP

R
R

SP
SP

02/Y
01/Y

R
R
R

R
R

R
R
R
SP
RU
R
R

R
R

P
P

R
R

SP
SP

P
P
P
P

R
SP

RU
SP

R
R

21-9

02/Y
01/Y
02/Y
02/Y
02/Y
02/Y
01/Y
01/Y
Ol/Y
Ol/Y
02/Y
02/Y
02/Y
Ol/Y
02/Y
Ol/Y
Ol/Y
02/Y
02/Y
Ol/Y
02/Y
Ol/Y
Ol/Y
02/Y

DATE
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/30/83
8/30/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8i19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83

DNOS Sou rce Structure

DNOS System Design Document

Table 21-2 Map of Utility Program File (Continued)
30
31
32
33
34
35
36
37
38
39
3A
3B
3C
3D
3E
3F
40
41
42
43
44
45
46
47
48
49
4A
4B
4C
4D
4E
4F
55
56
57
58
59
SA
5B
5C
5D
5E
SF
60
61
62
63
64
65
66
67

SJSSTS
PMPNAP
MD
SYSGEN
CD
BD
VC
PMPASP
INV
AUIDUI
CRV
LTS
BMF
LGGLOG
MOEMPE
CPI
MKL
CVD
MVI
NAMMGR
RAL
CSKCKS
RWCRU
LGACCT
JOBMGR
BEMF
PMSBUF
IBMUTL
RPRCP
SP$DST
SPINIT
ASP
SEM
IDS
PF
MLP
LPWRITER
LGACHN
SPTASK
ALN
DCOPY
CSM
SCI NIT
SOS
OPERATOR
XOI
LGRCRT
LSC
CB
SRFI
DEBUG

2AEE
OD7A
2C12
6EC2
67C6
6258
5C68
1978
1FFE
34CO
OD5C
1794
307E
0606
2D24
lCE6
OFE8
3E08
lCDA
2000
06C8
1B9C
OAlE
301A
26E4
2D92
0562
1EF2
254C
4AOA
1C22
OD36
303E
4AOE
227A
OC3E
1F54
01B2
OA80
3940
41CA
3850
OCA4
3332
3D92
4A5E
25B6
2F24
2436
OFEC
OFFA

COOO
COOO
1AOO
0000
0000
0000
0000
COOO
COOO
lAOO
COOO
COOO
1AOO
COOO
lAOO
0000
1AOO
0000
0000
COOO
COOO
lAOO
lAOO
COOO
COOO
1AOO
COOO
0000
COOO
l1CO
11 CO
1AOO
1AOO
0000
IAOO
COOO
4580
COOO
0000
IAOO
0000
0000
1AOO
1AOO
COOO
lAOO
COOO
1AOO
1AOO
1AOO
COOO

DNOS Source Structure

S P

a S P

4
4
4
4
4

R
R

P
P
P
a S P
a S P
4
4 S P
4 S
4
a S P
P
4
4
P
P
4
P
4
P
4
a S P
4 S P
4
4
P
0 S P
a s P
4
a S P
P
4
a S P
P
1
1
4
4
4
P
4
4 S
4
a S P
4
4
P
4
4
1
4
1 S
4
4 S
4
4
4
P
4 S P

01/Y
01/Y
02/Y

RU
03

R
R
R

SP
SP
SP

R
R
R

SP
SP
SP

OZ/Y

R
R
R

RU
RU

R
R
R
R
R
R
R
R
R
R
R
R

01/Y
01/Y
02/Y
OliN
01/Y
02/Y
Ol/Y
02/Y

SP
SP
SP

Ol/Y
01/Y
02/Y
02/Y
Ol/Y
Ol/Y
02/Y
01/Y
01/Y
06/Y
06/Y
02/Y
02/Y

SP
02/Y
01/Y
07/Y
01/Y

02/Y
SP

R
R
R
RU
R
R
R
R

21-10

02/Y
02/Y
01/Y
02/Y
01/Y
02/Y
02/Y
02/Y
01/Y

8/19/83
8/19/83
8/19/83
8/19/83
8/30/83
8/30/83
8/30/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
9/13/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83

2270512-9701

DNOS System Design Document

Ta ble 21-2 Map of Utility Program File (Continued)
68
6F
70
71
72
74
75
83
85
86
87
88
8E
8F
90
93

SAVRES
TPCALANS
TPDISC
TPMHPC
TPLHPC
XJM
DIOU
MCDT
BDD
CV
CVINIT
SD
RESOLVE
XBJM
RESTART2
TFTPC

12B2
OF72
OCF8
OF5A
OEDE
193E
OFEC
1912
A934
5ECO
515E
D800
OC7e
03A4
2C24
52C4

PROCEDURE/PROGRAM
ID NAME
LENGTH
02 S$SYSTEM 19F6
03 SCI990
6586
04 TIGRESS 159A
as EDITOR
3BEC
06 SPCOMN
11BC
07 LPWRITER 4576

COOO
0000
0000
0000
0000
COOO
COOO
0000
0000
0000
0000
0000
1AOO
0000
COOO
0000

a S p
4
4
4
4
1

R
R
R

S P

a S p
4
4
4
4
4
4
4

R
R

SP
SP
SP

R
R

02/Y

R
R

a S p
4

01/Y
01/Y

P
P
P
P

01/Y
R

SEGMENTS: MAX POSSIBLE =
LOAD S M R D U SH RU CP E
0000
SH
1AOO
SH
0000
SH
1AOO
SH
0000
SH
E
0000
SH

OVERLAYS: MAX POSSIBLE = 96
ID NAME
LENGTH LOAD MAP D OVLY
01 IN IT
1572 21EO
02 INTERACT 4CE2 21EO
01
03 BUILD
4C2A 21EO
02
04 VERSION 0006 0000 MAP
41 SCUINIT OC4C E492
42 SCUDEV
0478 E492
41
43 SCULDC
05C2 E90A
42
44 SCUADD
0434 E492
4E
45 SCUPDT
0580 E8C6
44
46 SCUDSR
045A E8C6
4B
47 SCUDEL
05B6 E90A
4F
48 SCUMISC OA98 E492
53
49 SCUMSP
l.8
OB70 E492
AA SCUAINT 05C4 E8C6
46
4B SCUNAME 0462 E8C6
4D
4C SCUPD1
040C E8C6
45
4D SCUPD2
055A E8C6
4C
4E SCUMDS
043C E90A
47
4F SCUDATA 0558 E90A
43
53 SCUAHUX 02A6 EE8A
54
54 SCUAEXP 0248 EE8A
4A

2270512-9701

Ol/Y

R
R

21-11

20
W C OVLY
W

8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
DATE
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83

W
'\

DATE
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83

DNOS Source Structure

DNOS System Design Document

Table 21-3

Map of System Program File

FILE MAP OF .S$SHIP
TODAY IS 13:35:05 TUESDAY, SEPTEMBER 27, 1983.
TASK SEGMENTS: MAX POSSIBLE =
ID NAME
LENGTH LOAD PRI S P
02 PMTBID
OA12 COOO 0 S P
03 IOU
3DAA COOO 0 S P
04 PMTLDR
18EO COOO a s p
05 FILEMGR 380A COOO a s p
06 DISKMGR 0730 COOO 0 S P
07 PMOVYL
047C COOO 0 S P
02C6 COOO 0 S P
08 PMWRIT
PROCEDURE/PROGIW1
ID NAME
LENGTH
01 ROOT
3464
02 S$SHIP
39AA

8
H R D U RU CP E 0 C SP B OVLY
M
SP
RU
SP
14
M
SP
15
N
SP
05
M
11
SP
M
SP

SEGMENTS: MAX POSSI BLE =
2
LOAD S M R D U SH RU CP E W C OVLY
0000
U
3480
U

OVERLAYS: MAX POSSIBLE = 69
ID NAME
LENGTH LOAD MAP D OVLY
01 SMTAOI
008A 9000
03 SVCSHD
3800 COOO
04 SVCTWO
3800 COOO
05 KORW
0392 F80A
16
06 FORWFB
03FO F80A
07 FOMISC
0158 F80A
06
024C F80A
07
08 FOXFIL
09 FOOPEX
0366 F80A
08
OA KOINSR
03E8 F80A
09
OB KODLSR
02E2 F80A
OA
OC KOOPCL
03D2 F80A
OB
OD KOBDEL
025C F80A
OC
OE KOBTIS
03A8 F80A
aD
OF KORWS
038E F80A
OE
10 DMOV37
02A6 C48A
11 DMOV38
0280 C48A
10
12 CFOVLY
OF44 EE66
13 IUMISCOV OC18 EE66
12
14 IURFAADA OC74 EE66
13
15 PMERRS
0212 D8EO
16 KOPLG
01A6 F80A
OF
IB DSRDSK
ODOC COOO
20 DSR911
1226 COOO
3C JCAOOO
3000 9000
43 DSR93B
35C6 COOO
44 DSR93C
379A COOO

DNOS Source Structure

21-12

Pl/S P2/S
Ol/Y
01/Y
01/Y
01/Y
01/Y
Ol/Y
01/Y

DATE
8/19/83
8/19/83
8/19/83
8/19/83 .
8/19/83
8/19/83
8/19/83
DATE
8/19/83
8/19/83
DATE
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83
8/19/83

2270512-9701

DNOS System Design Document

SECTION 22
DATA STRUCTURE PICTURES

22.1

OVERVIEW

This
section
includes
details
of
the
templates found in the
DSC.TEMPLATE.COMMON
directory
atid
in
the
DSC.TEMPLATE.ATABLE
directory.
The DSC.TEMPLATE.COMMON directory includes templates
for the tables used as assembly language CSEG modules
throughout
DNOS.
It also includes sp~cial-purpose templates used only by a
single subsystem.
The special-purpose templates are not shown in
detail here;
consult
the
appropriate
TEMPLATE
directory
for
details.
The
DSC.TEMPLATE.ATABLE
directory
contains all of the assembly
language versions of
the
DNOS
data
structure
templates.
It
includes
templates
for structures used throughout the operating
system as well as templates for
special
purposes
in
a
single
subsystem.
This
section
includes
detailed
pictures
of
the
general-purpose structures;
consult
the
source
directory
for
details on special-purpose structures.
The
template
pictures include descriptions of various fields of
data structures used by DNOS, their locations, meanings of flags,
and special comments.
The following features are found in one or
more of the structure pictures:

Header showing
the
structure
name,
system, and abbreviat~on for the name

*
*

Comments describing the use of

location

the

the structure

Hexadecimal starting location (or offset relative to
beginning
of
the
structure)
for
each
word
of
structure
Label

for each field,

Blank if

chosen from

2270512-9701

types:

no label

Label
of
the
form
generated by software
Label

three

the
the

of 6 or fewer

FILLxy,

the

label

characters

22-1

Structure Pictures

DNOS

System Design Document

Size
of field
picture

*
*

Comment to right of field, describing that

indicated by space allocated

List of flag definitions for
structure

each

flag

in structure

field
field

the

Flag name
Diagram showing position of flag, initial position
being
O.
The
flag
is
always
defined
as
an
assembly
language
equate
fGr
the
first
bit
position shown with an X in the diagram.
Description of flag
Optional
settings

lines

extended explanations

List of equated labels for fields

flag

in the structure

Label being equated
Argument of the equate
Value of the equate
Description of
Table 22-1 lists the

Structure Pictures

(or location of the argument)

the label being equated

templates detailed in this

22-2

section.

2270512-9701

DNOS System Design Document

Table 22-1
Acronym

Template Acronyms
Meaning

-------------------------------------

From DSC.TEMPLATE.COMMON
JMDATA
LGACOM
LGLCOM
NFCLKD
NFDATA
NFJOBC
NFPTR
PMDATA

Job Management Common Area in JCA
Accounting Log Common Data
System Log Common Data
Clock Data Area
Global Data Values
Job Manager Common Area
System Pointers
Global Data Areas for Program Management

From DSC.TEMPLATE.ATABLE
ACC
ADR
AGR
BAP

BRO
BTB
CCB
CDE
CDR
CLR
DDB
DIA
DIT
DOR
DPD
DPR
DUS
FCB
FDB
FDP
FDR
FID
FIR
FSC
FWA
IRB
JIT
JMR
JSB
KCB
KDB
KDR
KIB
KIT
2270512-9701

Accounting Record Contents
Alias Descriptor Record
Access Group Record
Buffer Address Packet
Buffered Request Overhead
B-Tree Block
Channel Control Block
Command Definition Entry
Channel Descriptor Record
Capabilities List File Record
DIOU Data Base Definition
Diagnostic Status
Disk Information Table
Directory Overhead Record
Disk PDT Extension
Device Utility Parameters
Device Utility Session Table
File Control Block - See FSC
File Directory Block - See FSC
File Descriptor Packet
File Descriptor Record
File Identification
File Information Record
File Structure Common
File Manager Work Area
I/O Request Block
Job Information Table
Job Management Request
Job Status Block
KIF Currency Block
Key Descriptor Block (Memory Structure)
Key Descriptor Block (Disk Structure)
KIF Information Block
KIF Task Area
22-3

Structure Pictures

DNOS System Design Document

Table 22-1 Template Acronyms (Continued)
Acronym

KSB
LDT
LFD
LPD
LSE
MRB
MTX
NDB
NDS
NFCRSH
NFSTAT
NRB
OAD
OAW
OSE
OTI
OVB
OVT
PBM
PDT
PFI
PFZ
QHR
QIR
RDB
RIB
RLT
ROB
RPB
RST
SAT
SCO
SDB
SGB
SLB
SLH
SMR
SMT
SOB
SOV
SSB
STA
STE
SVB
TDL
TSB

Structure Pictures

Meaning

Keyboard Status Block
Logical Device Table
Log File Definition
Line Printer PDT Extension
Load Segment Entry
Master Read/Master Write Buffer
Extension for a Magnetic Tape
Name Definition Block
Name Definition Segment Overhead
System Crash Code Equates
Task State Definitions
Name Manager Request Block
Overlay Area Description
Overlay Area Wait Block
Owned Segment Entry
Opening Task Identifier
Overhead Beet
Overlay Table Entry
Partial Bit Map Table/Buffer
Physical Device Table
Program File Directory Index Entry
Program File Record Zero
Queue Header
Queued IPC Request
Request Definition Block
Return Information Block
Record Lock Table
Resource Ownership Block
Resource Privilege Block
Reserve Segment Table
Secondary Allocation Table
Track 0, Sector 0
Stage Descriptor Block
Segment Group Block
System Log Block Formats
Semaphore List Header
Segment Manager- Request Block
Segment Manager Table
Segment Owner Block
System Overlay Load Table
Segment Status Block
System Table Area Overhead
Swap Table Entry
Stage Value Block
Time Delay List Entry
Task Status Block

22-4

2270512-9701

DNOS System Design Document

Table 22-1 Template Acronyms (Continued)
Acronym

UDO
UDR
UIP
VCB
VDB
VRB
XTK

Meaning

User Descriptor Overflow Record
User Descriptor Record
User ID Parameter
Value Continuation Block
Value Definition Block
Virtual Request Block
Extension for a Terminal with a Keyboard

Several templates are
described
in
the
DNOS SCI and Utilities
descriptions
of
the
Design Document,
along
with
detailed
lists
the·
templates
utilities
that
use
them.
Table
22-2
described in that manual.
Table 22-2

Templates Described in SCI and Utilities Document

Acronym

ACC
CNT
FIR
SCA
SDEDOR
SDEMD
SDQ
SDT
SPM
UDR

2270512-9701

Meaning

Accounting Record Contents
Class Name Table
File Information Record
System Communications Area
Memory Resident DOR (UTSORT Structure)
Sorted Directory File Entries Table
Spooler Device Queue Entry
Spooler Device Table Entry
Spooler Message Format
User Descriptor Record

22-5

Structure Pictures

JMDATA

22.2

DNOS System Design Document

STRUCTURES FROM THE COMMON DIRECTORY

************************************************************

*
*
JMDATA - JOB MANAGER COMMON AREA
06/08/82
*
*
LOCATED IN JOB MANAGER TASK AREA
*
*
*
*
************************************************************
*
)00

*----------+----------*
CURJSB

CURRENT JSB POINTER

+----------+----------+
)02
)04
)06

JMRPTR

CURRENT JOB REQUEST

BROPTR

CURRENT BRO REQUEST

+----------+----------+
+----------+----------+
PARFMT

PARENTS FMT POINTER

+----------+----------+
)08

PARFCB

PARENTS FCB POINTER

+----------+----------+
)OA
)OC

JSTCRE

JSTEXC

+----------+----------+
JSTHLT

JSTTRM

+----------+----------+
)OE

TSTJHT!

TSTJMR

+----------+----------+

=============== JOB & TASK STATES
CREATING
EXECUTABLE
HALTED
TERMINATING
TASK SUSPENDED BY JOBMGR
TASK WAITING ON JMR SVC

Structure Pictures

22-6

2270512-9701

DNOS System Design Document

LGACOM

************************************************************

**
*
*

LGACOM -

ACCOUNTING LOG COMMON
TEMPLATE : LFD
(40 MAX = 2 KB OF MESSAGES)

**
*
*

04/26/82

************************************************************

)00

*---~------+----------*
FILLOO

FILL01

FLAGS AND ERROR BYTE

+----------+----------+

)02 !

MAX MESSAGE COUNT (0

+---~------+----------+

. )04!
FILL02
!
FI"LL03
!
+-------~--+---------~+
)06 !
FILL04
)08

NONE)

~ASK TO BID ON FULL
ID OF USER TASK TO BID ON FULL
ACCOUNTING FILE ALLOCATION

+----------+----------+
FILLOS
!
+----------+----------+

LUNOS

EQUATES:
LABEL
LGACOM

EQUATE TO
$

VALUE

DESCRIPTION

)00

2270512-9701

22-7

Structure Pictures

LGLCOH

DNOS

System Design Document

************************************************************

*
*
*
*

*
*
*
*
************************************************************
LGLCOM -

)00
)02
)04
)06
)08

)OA

SYSTEM LOG COMMON
TEMPLATE : LFD

*----------+----------*
FILLOO
+----------+----------+
FILLOl
+----------+----------+
FILL02
FILL03
+----------+----------+
FILL04
+----------+----------+
+----------+----------+
FILL05
+----------+----------+
/
/
/
/

FLAGS (SEE LFD TEMPLATE)
MAX MESSAGE COUNT (O=)NO MAX)
ID OF TASK TO BID ON FULL
ID OF USER TASK TO BID ON FULL
LOG DEVICE NAME (BLANKS=)NONE)"

FILENAME 1

+----------+----------+
FILL06
!
+----------+----------+
/
/
/

)12!

)IA

)IC

09/09/83

FILENAME 2

+----------+----------+
FILL07
+----------+----------+
FILL08
+----------+----------+

LOG FILE ALLOCATION
LUNOS

EQUATES:
LABEL
LGLCOM

EQUATE TO
$

VALUE

DESCRIPTION

)00

Structure Pictures

22-8

2270512-9701

DNOS System Design Document

NFCLKD

************************************************************

**
NFCLKD - CLOCK DATA AREA
01/31/82
**
*
*
************************************************************
* THIS COMMON SEGMENT INCLUDES FLAGS AND COUNTERS USED FOR
* PERFORMANCE DATA GATHERING AND SYSTEM CLOCK WORKSPACES.
* THE WORKSPACE STARTING AT CLKWP2 IS USED FOR UPDATING THE
* CLOCK; THAT AT CLKWP IS THE NORMAL CLOCK WORKSPACE. IN
* THE LATTER, THE ESTIMATED UTILIZATION VARIABLES (R4,RS)
* CONTAIN VALUES IN THE RANGE 0 THROUGH )8000 WHERE 0
* REPRESENTS 0% UTILIZATION AND )8000 REPRESENTS 100%
* UTILIZATION.

*----------+----------*
NBFLGS
+----------+----------+
)02
NBSAM1
+----------+----------+
)04 !
NBSAM2
!
+----------+----------+
)06 !
STFLGO
!
+----------+----------+
)08 !
FLGOH1
+----------+----------+
)OA
FLGOH2
+----------+----------+
)OC !
STFLG1
+----------+----------+
)OE
FLG1H1
+----------+----------+
)10
FLGIH2
+----------+----------+
)12 !
STFLG2
+----------+----------+
)14
FLG2H1
+----------+----------+
)16
FLG2H2
+----------+----------+
)18 !
STFLG3
+----------+----------+
)lA !
FLG3H1
!
+----------+----------+
)lC !
FLG3H2
!
+----------+----------+
)lE !
STFLG4
+----------+----------+
FL G4 H1
)20 !
+----------+----------+
FLG4H2
)22

)00 !

2270512-9701

NUMBER OF STATISTIC FLAGS
NUMBER SAMPLES ON FLAGS (WD 1 )
NUMBER SAMPLES ON FLAGS (WD 2)
FLAG 0

FOR DISK UTILITY

HIT COUNT FOR FLAG 0 (WD 1 )
HIT COUNT FOR FLAG 0 (WD 2)
FLAG 1

CPU UTILIZATION

HIT COUNT FOR FLAG 1 (WD 1 )
HIT COUNT FOR FLAG 1 (WD 2)
FLAG 2

SCHEDULER

HIT COUNT FOR FLAG 2 ( WD 1 )
HIT COUNT FOR FLAG 2 (WD 2)
FLAG 3

FILE MANAGER

HIT COUNT FOR FLAG 3 ( WD 1 )
HIT COUNT FOR FLAG 3 (WD 2)
FLAG 4

TASK LOADER

HIT COUNT FOR FLAG 4 (WD 1 )
HIT COUNT FOR FLAG 4 (WD 2)
22-9

Structure Pictures

NFCLKD

DNOS System Design Document

+----------+----------+

- MAP

)24 !

STFLG5

FLAG 5

)26 !

FLG5Hl

HIT COUNT FOR FLAG 5 (WD 1 )

)28

FLG5H2

HIT COUNT FOR FLAG 5 (WD 2)

STFLG6

FLAG 6

+----------+----------+
+----------+----------+

+----------+----------+

)2A

)2C

+----------+----------+
FLG6Hl

+----------+----------+
)2E
)30

ONE ACTIVITY

SVC CODE FILE MGR

HIT COUNT FOR FLAG 6 (WD 1 )

FLG6H2

HIT COUNT FOR FLAG 6 (WD 2)

STFLG7

FLAG 7

+----------+----------+
+----------+----------+

)32 !

FLG7Hl

HIT COUNT FOR FLAG 7 (WD 1 )

)34 !

FLG7H2

HIT COUNT FOR FLAG 7 (WD 2)

)36

STFLG8

FLAG 8

+----------+----------+

+----------+----------+
+----------+----------+

)38

FLG8Hl

HIT COUNT FOR FLAG 8 (WD 1 )

FLG8H2

HIT COUNT FOR FLAG 8 (WD 2)

+----------+----------+
)3A
)3C

+----------+----------+
STFLG9

FLAG 9

FLG9Hl

HIT COUNT FOR FLAG 9 (WD 1 )

+----------+----------+
)3E

+----------+----------+
)40
)42
)44

FLG9H2

+----------+----------+
STFLGA

+----------+----------+
FLGAHI

+----------+----------+
)46
)48

FLGAH2

+----------+----------+

)4C
)4E
)50
)52

HIT COUNT FOR FLAG 10 (WD 2)

FLGBHl

HIT COUNT FOR FLAG 11 (WD 1 )

+----------+----------+
FLGBH2

+----------+----------+

HIT COUNT FOR FLAG 11 (WD 2)

STCNTO

COUNTER 0

II JOBS COMPLETED

STCNTl

COUNTER 1

II TASKS COMPLETED

STCNT2

COUNTER 2

/I SEG MGR CALLS

STCNT3

COUNTER 3

STCNT4

COUNTER 4

+----------+----------+
+----------+----------+
+----------+----------+

)56

HIT COUNT FOR FLAG 10 (WD 1 )

FLAG 11

+----------+----------+
)54

FLAG 10

STFLGB

+----------+----------+
)4A

HIT COUNT FOR FLAG 9 (WD 2)

+----------+----------+
Structure Pictures

22-10

II FILE MGR CALLS
II IPC CALLS

2270512-9701

DNOS System Design Document

) S8
)SA
)SC

NFCLKD

STCNTS

COUNTER S

ROLL OUTS

COUNTER 6

FILE MGR Q REQ

+----------+----------+
STCNT6

+----------+----------+
STCNT7

COUNTER 7

SYSTEM OVLY LDS

STCNT8

COUNTER 8

NAME MANAGER CALLS

II IOU CALLS

+----------+----------+
)SE

+----------+----------+

)60 !

STCNT9

COUNTER 9

) 62

STCNTA

COUNTER lO- 11 SYSTAB SCHED CALLS

+----------+----------+

)64 !

STCNTB

COUNTER II

)66

CLKWP2

+----------+----------+

+----------+----------+
)68 !

CKTICI

)6A

CKTIC2

YEAR

+----------+----------+
+----------+----------+

)6C !

+----------+----------+

)6E !
)70
)72
)74

DAY

+----------+----------+

HOUR

MIN

+----------+----------+
+----------+----------+
SEC

+----------+----------+

)7E
)80
)82
)84

FILL03

+----------+----------+
FILL04

FILLOS

.- !

+----------+----------+
+----------+----------+
FILL06

+----------+----------+
)86
)88
)8A
)8C

DAYS PER YEAR

R12

SCRATCH

RI3

SCRATCH

RIS

TIC COUNT FOR TIME UNITS

SECONDS PER MINUTE

R14

CLKWP

SCRATCH

FILL07

SCRATCH

FILL08

SCRATCH

FOR BAR GRAPH

+----------+----------+
+----------+----------+
+----------+----------+

2270S12-9701

CLOCK SECOND COUNTER

+----------+----------+
!

CLOCK MINUTE COUNTER

Rll

FILL02

CLOCK HOUR COUNTER

HOURS PER DAY

FILLOO

+----------+----------+

CLOCK DAY COUNTER

)78

)7C

CLOCK YEAR COUNTER

RIO

FILLOI

)7A

WORDS 1 AND 2

CLOCK TIC COUNTER

TIC

+----------+----------+

32 BIT CLOCK TIC COUNTER

)76 !

+----------+----------+

FILL09

22-11

Structure Pictures

NFCLKD

DNOS System Design Document

+----------+----------+
)8E !

DSUTIL

)90

CPUTIL

- ESTIMATED DISK UTILIZ

- ESTIMATED CPU UTILIZ

TIME SLICE TIC COUNT

DSPFG1

INDEX TO FLAGS TO DISPLAY

)96 !

DSPFG2

)98

FILLOA

FILLOB

RIO -

FOR FRONT PANEL DISPLAY

+----------+----------+
+----------+----------+

)92

TSTIC

+----------+----------+
)94

+----------+----------+
+----------+----------+

)9A

+----------+----------+
+--------~-+----------+

ON FRONT PANEL
- FOR FRONT PANEL DISPLAY

)9C !

FILLOC

Rl1 -

SCRATCH

)9E

FILLOD

R12 -

FRONT PANAL ADDRESS

+----------+----------+

)AO

+----------+----------+
FILLOE

R13 - WORKSPACE POINTER

+----------+----------+
)A2

FILLOF

R14 -

PROGRAM COUNTER

R15 -

STATUS

+----------+----------+
)A4

FILL10

+----------+----------+
)A6

PFGOH2

+----------+----------+

)A8 !

PFG1H2

+----------+----------+

PREV NUMBER HITS FLAG 0 (WD 2)
PREV NUMBER HITS FLAG 1 (WD 2)

EQUATES:
LABEL
SFESIZ
NFCSIZ

EQUATE TO
6
$-NBFLGS

Structure Pictures

VALUE
)06
)AA

22-12

DESCRIPTION
STATISTICS FLAGS ENTRY SIZE

2270512-9701

DNOS System Design Document

NFDATA

************************************************************

*
*
NFDATA - GLOBAL DATA VALUES
03/08/83
*
*
*
*
************************************************************
* THIS COMMON SEGMENT CONTAINS GLOBAL DATA VALUES INCLUDING
* THE FOLLOWING: BEET ANCHORS FOR THE TIME ORDERED LIST
* (TOL), CACHE LIST, FREE MEMORY LIST, STATIC BUFFER AREA,
* AND THE TEMPORARY MEMORY BUFFER; PARAMETERS FOR PRIORITY
* COMPUTATION AND SCHEDULING; ROLL OUT AND LOAD PARAMETERS.
* A NUMBER OF MISCELLANEOUS DATA VALUES ARE ALSO FOUND IN
* THIS CSEG. COMMENTS IN THIS TEMPLATE'S SOURCE FILE SHOW
* PRIORITY, AGING, AND ROLLOUT PARAMETERS.
** NOTE: CHANGES TO THIS TEMPLATE REQUIRE CORRESPONDING
*
CHANGES TO SYSGEN.
*

)18

*----------+----------*
TMTOL
+----------+----------+
TOLBET
+----------+----------+
TMTOLN
+----------+----------+
TMTOLO
!
+----------+----------+
TMTTYP
+----------+----------+
FILLOO
+----------+----------+
!
FILL01
!
+----------+----------+
FILL02
+----------+----------+
FILL03
+----------+----------+
FILL04
+----------+----------+
+----------+----------+
INTCDT
+----------+----------+
RESPFL
RESTSK

)lA

RESTRT

)00
)02
)04
)06
)08
)OA
)OC
)OE
)10
)12
)14
)16

+----------+--------~-+

+----------+----------+
FILL05
+----------+----------+
RELOCA
+----------+----------+

START OF TIME ORDERED LIST
BEET ADDRESS OF TOL HEADER
FORWARD POINTER
BACKWARD POINTER
TYPE OF BLOCK

SCHEDULER ENTRY VECTOR (WP)
(PC)
(ST)
RESERVED

FAKE CDT FOR SYSTEM INIT. TASK
PROGRAM FILE LUNa
ID OF SYSTEM RESTART TASK
ID OF USER RESTART TASK

)lC !
)lE

2270512-9701

RELOCATION VALUE FOR LOADER

22-13

Structure

Pictures

NFDATA

)20

DNOS System Design Document

CHELST

+----------+----------+
CHEBET
!
+----------+----------+
CHEFWD
+----------+----------+
CHEBKW
+----------+----------+
CHETYP
+----------+----------+
SMTBMP
+----------+----------+
USERPF
!
+----------+----------+
/
/
/
/
/
/
+-------TSKDOA
-+----------+!
+----------+----------+
FILL06
+----------+----------+
CPU12
+----------+----------+
AJSBCT
+----------+----------+
!
ATSBCT
+----------+----------+
WTSBCT
+----------+----------+
UAHEAD
+----------+----------+
UAPTR
+----------+----------+
UAFWD
+----------+----------+
UABKW
+----------+----------+
UABADD
+----------+----------+
UATLEN
+----------+----------+
UADSTR
+----------+----------+
UADLEN
+----------+----------+
UADMIN
+----------+----------+
USEMEM
+----------+----------+
USEFRG
!
+----------+----------+
TICFRQ
!
+----------+----------+

START OF CACHE LIST

)22 !

BEET ADDRESS OF LIST HEADER

)24

FORWARD POINTER

)26
)28
)2A

)2C

BACKWARD POINTER
TYPE OF BLOCK
SEG MANAGER SCRATCH WORD
NAME OF PF CONTAINING USER-

-~-

)34
)36
)38
)3A

)3C
)3E
)40
)42
)44
)46
)48
)4A

)4C
)4E
)50
)52
)54
)56

Structure Pictures

FOR INTERRUPT 2 PROCESSOR TO
RETURN TASK ERR CODE TO SCHD.
* RESERVED * (SMRID)
SET IF 990/12 CPU
ACTIVE JSB COUNT
ACTIVE TSB COUNT
COUNT OF TSB'S ON WOM
START OF FREE USER AREA
BEET ADDRESS OF BLOCK
FOWARD LINK POINTER
BACKWARD LINK POINTER
START ADDRESS OF USER MEMORY
TOTAL LENGTH OF USER MEMORY
START OF DYNAMIC USER MEMORY
LENGTH OF DYNAMIC USER MEMORY
MIN AMOUNT OF DYNAMIC MEMORY
SUM OF ALL CURRENT FREE MEMORY
NUMBER OF FREE MEMORY FRAGMENT
CLOCK FREQUENCY (TICS/SEC)

22-14

2270512-9701

DNOS System Design Document

>58

NFDATA

UNTSLC

CLOCK TICS PER TIME SLICE

+----------+----------+
>5A

TPU

TICS PER TIME UNIT

+----------+----------+
>5C
>5E

TSENAB

TIME SLICE ENABLE FLAG

TICLMT

LIMIT FOR CURRENT TIME SLICE

BTAHED

SIZE OF ANCHOR BLOCK

+----------+----------+
+----------+----------+

>60

+----------+----------+
>62

BTAPTR

+----------+----------+

BEET ADDRESS OF THIS BLOCK

>64 !

BTAFWD

FORWARD POINTER

>66

BTAREV

REVERSE POINTER

+----------+----------+

>68

+----------+----------+
BTAADD

+----------+----------+

BEET ADDRESS OF TABLE AREA

>6A !

BTALEN

LENGTH OF TABLE AREA IN BEETS

>6C

BTAMAX

MAXIMUM AREA FOR BUFFERS

+----------+----------+
+----------+----------+

>6E

ALLOCATED TABLE AREA

BTAALL

+----------+----------+
>70 !

BTAHDN

+----------+----------+

>72

HIDDEN TABLE AREA
RESERVED

FILL07

+----------+----------+
SIZE OF SYSTEM IN BEETS

>74 !

MEMSIZ

>76 !

CMEMSZ

SIZE OF CRASH FILE IN BEETS

>78 !

CRSHTL

CRASH FILE TILINE ADDRESS

+----------+----------+

+----------+----------+
+----------+----------+

>7A

CRSHHD

CRSHSC

CRSHCL

CRASH FILE HEAD ADDRESS
CRASH FILE SECTOR ADDRESS
CRASH FILE CYLINDER ADDRESS

CRSHSL

CRASH FILE TILINE SELECT

+----------+----------+
>7C

+----------+----------+

>7E

+----------+----------+
>80
>82
>84

TMBHED

SIZE OF ANCHOR BLOCK

TMBPTR

BEET ADDRESS OF THIS BLOCK

TMBFWD

FORWARD POINTER

TMBBWD

BACK POINTER

+----------+----------+
+----------+----------+
+----------+----------+

>86

+----------+----------+
>88
>8A

TMBADD

TEMP ADDRESS BOUNDARY

TMBLEN

TEMP BUFFER LENGTH

FILL08

RESERVED

+----------+----------+
+----------+----------+

>8C
2270512-9701

22-15

Structure Pictures

NFDATA

DNOS System Design Document

+----------+----------+
)8E

FILL09

+----------+----------+
)90

)94

EXTIME

EXTEND TIME SLICE FLAG

FUTPDT

IOU PDT CURRENTLY IN USE

+----------+----------+

)92

+----------+----------+
UNLPDT

+----------+----------+
)96

SYSUNT

+----------+----------+
)98

JCABT

+----------+----------+
)9A
)9C

UNLOAD VOLUME PDT IN USE
ELASPED SYSTEM TIME UNITS
BEET ADDRESS OF JCA

TDLEXP

TIME DELAY EXPIRED FLAG

WJSBCT

WOM LIST JSB COUNT

+----------+----------+
+----------+----------+

)9E

RESERVED

LDTDSC

+----------+----------+
/
/

)AC

/
/

+----------+----------+
IOINDX

+----------+----------+
)AE
)BO

INTPRI

+----------+----------+

VALUE OF X IN I/O INDICATOR
FORMULA.
INSTALLED PRI 1 -) 188

+----------+----------+
)B2

JPRMOD

+----------+----------+

VALUE FOR INSTALLED PRI OF 1

)B4

+----------+----------+
)B6

DYNMOD

+----------+----------+
)B8

VALUE FOR INSTALLED PRI OF 1

+----------+----------+
) BA
) BC

AGE IND

+----------+----------+

VALUE FOR INSTALLED PRI OF 1

+----------+----------+
)BE

ENDLMT

+----------+----------+
)CO

CLMXBF

+----------+----------+
)C2

CLMXPS

+----------+----------+
)C4

CLMNBF

+----------+----------+
)C6

CLNBUF

+----------+----------+
)C8

CLNPRG

+----------+----------+
)CA

TLSPND

Structure Pictures

END ACTION EXECUTION TIME LIMIT
IN SYSTEM TIME UNITS
MAX # BUFFERS ON CACHE LIST
MAX # PROGRAM SEGS ON CACHE LIST
RESERVED
WAS MIN # BUFFERS ON CACHE LIST
# BUFFERS CURRENTLY ON CACHE LIST

# PROG SEGS CURRENTLY ON CACHE LIST
MIN # SYS TIME UNITS TASK MUST

22-16

2270512-9701

DNOS System Design Document

)CC

NFDATA

+----------+----------+
TLEXEC

+----------+----------+
)CE

TOLCNT

+----------+----------+
)DO
)D2

TOLS24

+----------+----------+
LDRTDY

+----------+----------+
)D4

NUMROL

BE SUSPENDED BEFORE ELIGIBLE FOR
MIN # SYS TIME UNITS OF EXECUTION
TASK MUST RECEIVE BEFORE
# TASKS ON TOL ELIGIBLE FOR ROLL
OUT (NOT MEMORY RESIDENT)
IF NOT 0 STATE 24 TASKS ARE
IMMEDIATELY ELIGIBLE FOR
TASK LOADER TIME DELAY VALUE
IN SYSTEM TIME UNITS
NUMBER OF SEGMENTS ROLLED OUT

+----------+----------+
)D6

ROLSPA

AMOUNT OF ROLL SPACE USED

+----------+----------+
)D8

LDREXC

TASK LOADER IS EXECUTING FLAG

+----------+----------+
)DA !

TSKCNT

COUNT OF TASKS IN SYSTEM

+----------+----------+
)DC

FRCROL

FORCED ROLL-OUT COUNT

+----------+----------+
)DE

PMSTSB

ADDRESS OF TSB TO ROLL

+----------+----------+
)EO!

SITENM

+----------+----------+
/
/

/
/

SITE NAME

/
/

+----------+----------+
)E8

MGRCG

SYSTEM MANAGER CONTROL GROUP

+----------+----------+
/
/

/
/

+----------+----------+
)FO!

PUBLIC

PUBLIC ACCESS GROUP

+----------+----------+
/
/

/
/

+----------+----------+
) F8 !

SYSGEN OPTIONS WORD(FLAGS BELOW)

SYSOPT

+----------+----------+
)FA

RESERVED TABLE AREA AMOUNT

JCARES

+----------+----------+
)FC !

EXPLEN

LENGTH TO EXPAND TABLE AREA

)FE

CONTRY

COUNTRY CODE FOR THIS SYSTEM

+----------+----------+

+----------+----------+
)0100

MAX ALLOC FOR GET AND PUT DATA

ITSKMX

+----------+----------+
)0102

ITSKCR

CURR ALLOC FOR GET & PUT DATA

DCPYAC

DCOPY ACTIVE INDICATOR
O=DCOPY NOT ACTIVE, I=ACTIVE
VERSION NUMBER

+----------+----------+

)0104 !

+----------+----------+

)0106

VERS

+----------+----------+

)0108
2270512-9701

22-17

Structure Pictures

DNOS System Design Document

NFDATA

+----------+----------+
)010A

+----------+----------+
) 0 10 C !

COUNT BEFORE MEM CNTRL CHECK

ME MT I C

+----------+----------+

)010E

NAME OF SYSTEM

SYSTEM

+----------+----------+
/
/

/
/

+----------+----------+
)0116

TO SCHEDULE OR NOT TO SCHEDULE

COMFLG

+----------+----------+
LD MAP TO LOAD WCS (LIMIT)

)0118 !

WCSMAP

)OIIA

FILLOB

(BIAS)

FILLOC

RESERVED

+----------+----------+
+----------+----------+

)OIIC

+----------+----------+
)OIIE !

IOTFLG

SCHEDULER, IOTBID FLAG
O=BID REQ OUTSTANDING-)BID NFTBID
FILE CLOSES OUTSTANDING

+----------+----------+
)0120 !

CLOCNT

+----------+----------+
)0122 !

CPUID

CPU ID

+----------+----------+

)0124

ATTENTION DEVICE NAME

ATTNDV

+----------+----------+

)0126 !

+----------+----------+
)0128

FILLOD

RESERVED

+----------+----------+
)012A

+----------+----------+

)012C

CLFLUN

STORAGE PLACE FOR LUNO TO .S$CLF
RSVD-FORCE CLFLUN IN LEFT BYTE
LARGEST FREE BLOCK OF DYNAMIC MEM

FILLOE

+----------+----------+
)012E

UALGFB

+----------+----------+
)0130 !

TILADD

)0132

PWRFLG

SAVE TILINE ADDR FOR POWER UP-MUX

+----------+----------+

CONTROLLER POWERUP FLAG-MUX

+----------+----------+
FLAGS FOR FIELD: SYSOPT
OPTDSK
OPTMFM
OPTCDF
OPTBLK
OPTBSF
OPTEXF
OPTACC
OPTOSP
OPTIPC

#F8 -

(x •••••••••.••••• )

(.X . . . . . . . . . . . . . .
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X•••••••••••
( ••••• X••••••••••
( •••••• X •••••••••
( ••••••• X ••••••••
( •••••••• X •••••••

Structure Pictures

)
)
)
)
)
)
)
)

22-18

SYSGEN OPTIONS WORD(FLAGS BELOW)
SYSTEM DISK PRESENT
MINIMUM FILE MANAGEMENT PRESENT
CREATE/DELETE FILE CAPABILITY
BLOCKED FILE CAPABILITY
BLANK SUPPRESSED FILE CAPABILITY
FILE EXTENSION CAPABILITY
ACCOUNTING DATA COLLECTED
OUTPUT SPOOLING
IPC PRESENT
2270512-9701

DNOS System Design Document

NFDATA

OPTSEC = ( • • • • • • • • • X ••••••
( •••••••••• X •••••
OPTKIF
OPTEXJ = ( ••••••••••• X ••••
OPTRAW
( •••••••••••• X •••
OPTWCS
( ••••••••••••• X ••
OPTPFR
( •••••••••••••• X.

) - SECURITY
) - KIF PRESENT
) - EXPANDABLE JCA
) - DM READ AFTER WRITE ENABLED
) - I=PERFORMANCE WCS
) - I=POWER FAIL RECOVERY
( ••••••••••••••• X) - RESERVED

EQUATES:
LABEL

EQUATE TO

NFSBWP
NFSIZE

$-26
$-TMTOL

2270512-9701

VALUE
)FFF2
)134

22-19

DESCRIPTION
SIZE OF THIS CSEG

Structure Pictures

NFJOBC

DNOS

System Design Document

************************************************************

*
*
NFJOBC - JOB MANAGER COMMON AREA
11/09/79 *
*
*
*
************************************************************
* THIS COMMON SEGMENT CONTAINS DATA VALUES USED BY THE
* JOB MANAGER.
)00
)02
)04
)06
)08

)OA
)OC
)OE
)10
)12
)14
)16
)18

*----------+----------*
NXTJID
+----------+----------+
FSTJID
+----------+----------+
LSTJID
+----------+----------+
JOBCNT
+----------+----------+
JOBLMT
!
+----------+----------+
JCAMIN
!
+----------+----------+
JCAAVG
+----------+----------+
JCAMAX
+----------+----------+
JWTQUE
+----------+----------+
JOBQ
+----------+----------+
JOBBCT
+----------+----------+
JOBBLM
+----------+----------+
JOBBWT
+----------+----------+

NEXT AVAILABLE JOB ID
BEGINING AVAILABLE JOB ID
LAST AVALIBLE ID IN LIST
NUMBER OF JOBS IN SYSTEM
SYSTEM LIMIT ON ACTIVE JOBS
SIZE OF JCA IN BYTES (SMALL)
SIZE OF JCA IN BYTES ( MED)
SIZE OF JCA IN BYTES ( LARGE)
FOREGROUND JOB WAIT LIST
JOB MANAGER REQUEST QUEUE
BACKGROUND JOB COUNT
BACKGROUND JOB LIMIT
BACKGROUND JOB WAIT LIST

EQUATES:
LABEL
NFJSIZ

EQUATE TO
$-NXTJID

VALUE
)lA

DESCRIPTION
CSEG SIZE

Structure Pictures

22-20

2270512-9701

DNOS System Design Document

NFPTR

*****************************~******************************

*
*
NFPTR - SYSTEM POINTERS
09/20/83
*
*
*
*
************************************************************
* THIS COMMON SEGMENT CONTAINS POINTERS USED BY MANY PARTS
* OF DNO S.
*----------+----------*
)00
)02

TDLHDR

TIME DELAY LIST HEADER

+----------+----------+
WOMQUE

WAITING ON MEMORY QUEUE HEADER

+----------+----------+
)04

EXTSB

CURRENTLY EXECUTING TASK

+----------+----------+
)06

EXJSB

EXECUTING TASK JSB ADDRESS

+----------+----------+
)08
)OA

PDTLST

START OF PDT LIST

LDTLST

START OF LDT LIST

JSBLST

START OF JSB LIST

+----------+----------+
+----------+----------+

)OC !

+----------+----------+
)OE

START OF ACTIVE JSB LIST

ACTJSB

+----------+----------+
)10 !

WOMJSB

START OF JSBS WAITING ON MEMORY

)12

JCASTR

START OF ALL JCA AREAS

+----------+----------+
+----------+----------+

)14

MBSSTR

+----------+----------+

POINTER TO SYSTEM SGB

)16 !

PDTSAV

POINTER TO SAVED PDT FOR DSRS

)18 !

MAPSHD

POINTER TO SCHEDULER MAP FILE

)lA

MAPSV2

+----------+----------+
+----------+----------+

POINTER TO SVC SECOND MAP FILE

+----------+----------+
)lC !

CURMAP

POINTER TO CURRENT MAP 0 FILE

)lE

RUTSSB

POINTER TO SSR FOR ROOT

COMSSB

SSB ADDR OF SY STEM COMMON

+----------+----------+

)20

+----------+----------+
+----------+----------+

)22

SMSTR

SSB ADDR OF FIRST SM SEGMENT

+----------+----------+
)24
)26

SMEND

+----------+----------+
FMSTR

SSB ADDR OF LAST SM SEGMENT
SSB ADDR OF FIRST SM SEGMENT

+----------+----------+

)28 !

FMEND

SSB ADDR OF LAST SM SEGMENT

+----------+----------+

2270512-9701

22-21

Structure Pictures

NFPTR

DNOS System Design Document

)2A

YRPTR

PTR TO YEAR COUNTER (DATE&TIME)

+----------+----------+
(CONTINUED)

+
)2C

+----------+----------+
SYSTAB

OVERHEAD PTR FOR TABLE AREA

SPATCH

START OF PATCH AREA S$$PAT

)30 !

IXPTR

ILLEGAL PC

)32

PCAPTR

)2E

+----------+----------+
+----------+----------+
+----------+----------+

)34
) 36

+----------+----------+
DTMRAD

+----------+----------+
FILLOO

MUX DEVIINT ENTRY
ADDRESS OF IODTMR
RESERVED

+----------+----------+
)38 !

FILLOl

RESERVED

)3A

FILL02

RESERVED

+----------+----------+

)3C

+----------+----------+
FILL03

+----------+----------+

RESERVED

)3E !

TRCPTR

)40

BIDREQ

ANCHOR FOR BID REQUESTS

EORNKR

ANCHOR FOR EOR REQUESTS

)44 !

SYSJSB

POINTER TO SYSTEM JOB JSB

)46

CCBSTR

+----------+----------+

)42

+----------+----------+

POINTER TO 112 TRACE SAVR AREA

+----------+----------+
+----------+----------+

)48
)4A
)4C
)4E
)50
)52

START OF THE GLOBAL CCBS

+----------+----------+
SCOTID

+----------+----------+
MAPISV

+----------+----------+
MSGQUE

+----------+----------+

NFTBID TASK ID AND LUNO
POINTER TO MAP FILE 1 SAVE
AREA FOR LEVEL 2 INTERRUPTS
PTR TO PUT DATA MESSAGES

SOPJSB

SYSTEM OPERATOR JSB ADDRESS

SYSPDT

$YSTEM DISK PDT ADDRESS

+----------+----------+
+----------+----------+
ETBPTR

EXPANSION CHASSIS TABLE

)54 !

PCSPTR

SINGLE DEVIINT ENTRY

)56 !

PCMPTR

)58 !

PCEPTR

)5A

OVYTAB

+----------+----------+
+----------+----------+
!

+----------+----------+
+----------+----------+

Structure Pictures

MULTIPLE DEVIINT ENTRY
EXPANSION CHASSIS ENTRY
SYSTEM OVERLAY TABLE ADDRESS

22-22

2270512-9701

NFPTR

DNOS System Design Document

+----------+----------+
)5C !

IDTAB

)5E

COMPTR

POINTER TO COMM MODULE

BADWP

ILLEGAL XOP WORKSPACE

+----------+----------+

IPL LOADED OVERLAY TABLE ADDR.

+----------+----------+

)60

+----------+----------+
)62

CLOK12

+----------+----------+

12 MS CLOCK VECTOR

(CONTINUED)

+
)64

+----------+----------+
WOTJSB

TABLE AREA WAIT QUEUE

+----------+----------+
)66

PDSOLD

PRIORITY DSR SCHEDULER QUE HEAD

+----------+----------+
)68 !

PDSNEW

+----------+----------+

PRIORITY DSR SCHEDULER QUE TAIL

EQUATES:
LABEL
NFPSIZ

EQUATE TO
$-TDLHDR

VALUE

DESCRIPTION

)6A

2270512-9701

22-23

Structure Pictures

PMDATA

DNOS

System Design Document

*.***.*******.*k************************************** ******

*
*
PMDATA - GLOBAL DATA VALUES
04/09/81
*
*
FOR PROGRAM MANAGEMENT
*
*
*
*
************************************************************
* THIS COMMON SEGMENT CONTAINS THE PROGRAM MANAGEMENT ERROR
* RECOVERY SAVE AREA (IN THIS AREA SEG1SB THROUGH SEGID2
* MUST BE CONTIGUOUS), THE COMMON DATA FOR TASK BID
* ROUTINES, THE COMMON DATA FOR TASK LOADER ROUTINES, THE
* PROGRAM FILE DIRECTORY DOOR, THE PATHNAME FOR THE SYSTEM
* PROGRAM FILE, AND THE PATHNAME FOR THE SHARED PROGRAM FILE.

*----------+----------*
SEG1SB
+----------+----------+
)02
SEG1ST
+----------+----------+
)04
SEG2SB
+----------+----------+
)06
SEG2ST
!
+----------+----------+
)08 !
SEG3SB
!
+----------+----------+
)OA
SEG3ST
+----------+----------+
)OC
CPYLDT
+----------+----------+
)OE
CPYRPB
!
+----------+----------+
)10
SEGID1
+----------+----------+
)12
SEGID2
.
+----------+----------+
)14 !
ATRSG1
+----------+----------+
)16
ATRSG2
+----------+----------+
)18
ATRTSK
+----------+----------+
)lA !
LENSG1
+----------+----------+
)lC !
LENSG2
+----------+----------+
)lE
LENTSK
+----------+----------+
)20 !
LODTSK
+----------+----------+
)22
TSKREP
+----------+----------+
)24
JCASSB
)00

Structure Pictures

SEGMENT 1 SSB ADDRESS
SEGMENT 1 SM TABLE SSB ADDRESS
SEGMENT 2 SSB ADDRESS
SEGMENT 2 SM TABLE SSB ADDRESS
SEGMENT 3 SSB ADDRESS
SEGMENT 3 SM TABLE SSB ADDRESS
ADDRESS OF LDT COpy
ADDRESS OF RPB COpy

***************************
SEGMENT INSTALLED ID(2 WORDS)

ATTRIBUTES OF 1ST ATT. SEG.
ATTRIBUTES OF 2ND ATT. SEG.
ATTRIBUTES OF TASK SEC.
BYTE LENGTH OF 1ST ATT. SEC.
BYTE LENGTH OF 2ND ATT. SEC.
BYTE LENGTH OF TASK SEG.
LOAD ADDRESS OF TASK SEG.
SSB REPLICATED IN MEMORY FLAG
SSB FOR JCA OF JOB FOR TASK BID

22-24

2 2 7 0 5-1 2 - 9 7 0 1

DNOS System Design Document

PMDATA

+----------+----------+
)26

JCASMT

+----------+----------+
)28

SG1BET

+----------+----------+
)2A
)2C

SG2BET

BEET ADDRESS OF SEGMENT 2

+----------+--------~-+

SC3BET

SMT FOR JCA OF JOB FOR TASK BID
** TASK LOADER COMMON DATA ***
BEET ADDRESS OF SEGMENT 1

BEET ADDRESS OF SEGMENT 3

+----------+----------+
)2E

LODFLG

)30
)32

+----------+----------+
ROLDIR

***************************
ROLL DIRECTORY POINTER

+----------+----------+
ROLPRS

FLAG FOR LOADED/NOT LOADED SEG

PHYSICAL RECORD LENGTH ROLL FILE

+----------+----------+
)34

SYSFDP

+----------+----------+
)36
)38
)3A

)3E

SYSFMT

SYSTEM PF FMT ADDR.

SYSFCB

SYSTEM PF FCB ADDR.

+----------+----------+
+----------+----------+
ROLFDP

+----------+----------+

)3C

ROLFMT

ROLL FILE FDP ADDR.
FMT OF ROLL FILE

+----------+----------+
ROLFCB

+----------+----------+
)40

SYSTEM PF FDP ADDR.

APLFDP

FCB OF ROLL FILE
APPLICATION PF FDP ADDR.

+----------+----------+
)42

APLFMT

APPLICATION PF FMT ADDRESS

+----------+----------+
)44

APLFCB

APPLICATION PF FCB ADDRESS

+----------+----------+
)46

IMGFDP

IMAGES PF FDP ADDR.

IMGFMT

IMAGES PF FMT ADDR.

+----------+----------+

)48

+----------+----------+
IMGFCB

)4A

IMAGES PF FCB ADDR.

+----------+----------+
)4C
)4E

SHRFDP

+----------+----------+

S$SHARED PF FDP ADDR.

SHRFMT

S$SHARED PF FMT ADDR.

)50 !

SHRFCB

S$SHARED PF FCB ADDR.

)52

TIMSPN

TIME DELAY SVC FOR TASK LOADER
SPIN ON DISK ERRORS

+----------+----------+
+----------+----------+
+----------+----------+

)54

+----------+----------+
)56 !

SYSPN

PATHNAME SYSTEM UTILITy PROG FL

+----------+----------+

)58

SYSPNC

+----------+----------+
2270512-9701

22-25

Structure Pictures

PMDATA

DNOS

/
/

)60
)62

/
/

System Design Document

/
/

+----------+----------+
SHRPN
+----------+----------+
WOMPRI
FILLOO
+----------+----------+

PATHNAME FOR S$SHARED PROG FL
PRIORITY OF TASK BEING LOADED
RESERVED

EQUATES:
LABEL
PMDSIZ

EQUATE TO
$-SEGISB

Structure Pictures

VALUE

DESCRIPTION

)64

22-26

2270512-9701

ACC

DNOS System Design Document

22.3

STRUCTURES FROM THE ATABLE DIRECTORY

************************************************************

** ACCOUNTING RECORD CONTENTS (ACC)
09/09/83
**
*
*
LOCATION:
SYSTEM TABLE AREA OR DISK
*
*
************************************************************
* THE ACC DESCRIBES THE FORMAT OF ENTRIES ON THE QUEUE FOR
* PROCESSING BY THE ACCOUNTING FORMATTING TASK (LGACCT).
* WITH THE EXCEPTION OF THE QUEUE LINK, THE ENTRIES ARE
* EXACTLY THE SAME WHEN ON DISK IN THE ACCOUNTING LOG FILE.
* EACH BLOCK TYPE HAS ITS OWN SET OF INFORMATION FOLLOWING
* A STANDARD HEADER. THE EXCEPTION IS IPL (RECORD TYPE 6),
* WHICH USES ONLY THE HEADER INFORMATION.
FIXED PART
)00

*----------+----------*
ACCLNK

QUEUE LINK

+----------+----------+
FIELD DESCRIPTOR VARIANT

*----------+----------*
)02

ACCTYP

)04 !
)06

ACCLEN

+----------+----------+
ACCYRD

+----------+----------+
ACCHOU

ACCMIN

+----------+----------+
)08

ACCSEC!

ACCPRI

+----------+----------+

)OA

ACCJID

+----------+----------+

RECORD TYPE
LENGTH OF RECORD
YEAR/DAY
HOUR
MINUTE
SECOND
PRIORITY
JOB ID

TYPE 1 - JOB INITIALIZATION

)OC

*----------+----------*
ACCAID

ACCOUNT ID

+----------+----------+
/
/

)lC

/
/

+----------+----------+
ACCUID

+----------+----------+
/
/

USER ID

/
/

+----------+----------+
)24

ACCJNM

+----------+----------+
/

2270512-9701

JOB NAME

/
22-27

Structure Pictures

ACC

DNOS System Design Document

+----------+----------+
TYPE 2 - TASK TERMINATION

*----------+----------*
)OC
)OE

ACCTID

ACCTCD

+----------+----------+
ACCCPU

TASK ID
TASK TERM CODE
TASK CPU TIME (CLOCK TICKS)

+----------+----------+

)10 !

+----------+----------+

)12

ACCSVC

+----------+----------+

NUMBER SVC'S ISSUED

)14

+----------+----------+
ACCIOB

)16

)18
)lA

+----------+----------+
+----------+----------+
ACCMEM

+----------+----------+
)lC !

ACCWAL

+----------+----------+

)lE

WALL CLOCK EXECUTION TIME

ACCIID

ACCSTN

+----------+----------+
)24

MAX MEMORY ALLOCATED(BEETS)

+----------+----------+

)20!
)22

NUMBER I/O BYTES TRANFERED

ACCATR

+----------+----------+
ACCTNM

+----------+----------+
/
/

/
/

INSTALLED TASK ID
STATION ID
TASK ATTRIBUTES
TASK NAME

/
/

+----------+----------+
TYPE 3 )OC

*----------+----------*
ACCJUD

JOB TERMINATION

JCA AREA USED

+----------+----------+
)OE
)10
)12

ACCJSZ

JCA TOTAL SIZE

ACCJEX

JOB EXECUTION TIME

+----------+----------+ .
+----------+----------+
+----------+----------+

TYPE 4 - DEVICE ENTRy
)OC
)OE

*----------+----------*
ACCTPF

ACCDTP

+----------+----------+
ACCNAM

+----------+----------+

DEVICE TYPE FLAGS
DEVICE TYPE
DEVICE NAME

)10
Structure Pictures

22-28

2270512-9701

DNOS System Design Document

ACC

+----------+----------+
)12

ACCNRQ

NUMBER I/O REQUESTS

+----------+----------+
)14

+----------+----------+
)16

ACCTMU

RESERVED-TIME USED(MINUTES)

+----------+----------+

TYPE 5 -

*----------+----------*
)OC

ACCCHR

USER DATA

+----------+----------+
/
/

/
/

USER ENTRY

/
/

+----------+----------+
TYPE 7 -

)OC

CO~M

*----------+----------*
ACCCOM

COMM DATA

+----------+----------+
/
/

/
/

ENTRY

/
/

+----------+----------+
SINGLE ENTITY VARIANT

*----------+----------*
)02

ACCTXT

+----------+----------+
/
/

/
/

+----------+----------+
FLAGS FOR FIELD: ACCYRD

"04 -

YEAR/DAY

ACCYER = (XXXXXXX ••••••••• ) - YEAR (7 BITS)
ACCDAY
( ••••••• XXXXXXXXX) - DAY (9 BITS)
EQUATES:
LABEL

EQUATE TO

VALUE

DESCRIPTION

-----

---------

-----

------------------------------

ACCVNT
ACTJIT
ACTTTM
ACTJTM
ACTDET
ACTUET
ACTIPL
ACCORD
ACCJIZ
ACCTTZ
2270512-9701

$
1

2
3
4
5
6
$
$
$

)02
)01
)02
)03
)04
)05
)06
)OC
)2C
)2C
22-29

JOB INITIALIZATION
TASK TERMINATION
JOB TERMINATION
DEVICE ENTRY
USER ENTRY
IPL ENTRy
END OF OVERHEAD

Structure Pictures

DNOS System Design Document

ACC

ACCJTZ
ACCDSZ
ACCUSZ
ACCISZ
ACCCTZ

$
$
$
$
$

Structure Pictures

)14
)18
)52
)OC
)52

22-30

2270512-9701

DNOS System Design Document

ADR

************************************************************

** ALIAS DESCRIPTOR RECORD
(ADR)
02/28/79
**
*
*
LOCATION: DISK
*
*
************************************************************
* THE ADR IS A VARIANT OF A FILE DESCRIPTOR RECORD (FDR),
* USED TO DESCRIBE AN ALIAS FOR A FILE NAME. THE FIELDS
* MARKED HERE WITH *** ARE IN THE ADR TEMPLATE TO MAINTAIN
* COMPATABILITY WITH THE FDR TEMPLATE.
*----------+----------*
)00 !

ADRHKC

)02 !

ADRHKV

+----------+----------+
+----------+----------+

)04!

ADRFNM

+----------+----------+
/
/

) OC

/
/

HASH KEY COUNT
HASH KEY VALUE
FI LE NAME

/
/

+----------+------~---+

ADRPSW

+----------+----------+

PASSWORD

)OE !

+----------+----------+

)10

ADRFLG

+----------+----------+
)12
)14

FILLOO

***

PHYSICAL RECORD SIZE

FILL01

***

LOGICAL RECORD SIZE

***

PRIMARY ALLOCATION SIZE

***

PRIMARY ALLOCATION ADDRESS

***

SECONDARY ALLOCATION SI ZE

***

SECONDARY ALLOCATION ADDRESS

+----------+----------+
+----------+----------+

)16 !

FILL02

)18

FILL03

+----------+----------+

)1A !

FILL04

)lC

FILL05

+----------+----------+

)20

+----------+----------+

)1E

ADRRNA

RECORD NUMBER OF NEXT ADR

+----------+----------+
ADRRAF

+----------+----------+

2270512-9701

FLAGS(SAME AS FDRFLG FLAGS)

RECORD # OF ACTUAL FDR

22-31

Structure Pictures

BAP

DNOS System Design Document

************************************************************

*
(BAP)
** BUFFER ADDRESS PACKET
9/30/81
*
*
*
LOCATION: SYSTEM AREA
*
*
************************************************************
* THE BAP IS THE ADDRESS OF AN I/O BUFFER WHICH IPC APPENDS
* TO A BUFFERED I/O REQUEST.
** BEGINNING PACKED RECORD BAP

)00
)02
)04

)06

*----------+----------*
BAPSMT
!
+----------+----------+
!
BAPSSB
!
+----------+----------+
BAPOFF
+----------+----------+
SIZE
** END

Structure Pictures

POINTER TO SMT SSB
POINTER TO BUFFER SEG. SSB
OFFSET TO BUFFER WITHIN SEG.
OF PACKED RECORD

22-32

2270512-9701

DNOS System Design Document"

BRO

************************************************************

**
**

BUFFERED REQUEST OVERHEAD
LOCATION:

(BRO)

09/09/83

SYSTEM TABLE AREA AND JCA

**
**

************************************************************

*
*
*

THE BRO APPEARS AT THE HEAD OF EACH BUFFERED SVC REQUEST
BLOCK WHILE BEING PROCESSED BY DNOS.
THE REQUEST IS
QUEUED USING THE BROBRO FIELD.

)FFEE

*----------+----------*
BROOFL

BROPRI

OVERHEAD FLAGS
TASK PRIORITY
OVERHEAD FLAGS PART 2
ALTERNATE REQUEST ID FOR M/D DSR
BUFFER BEET ADDRESS

+----------+----------+
)FFFO

BROOF2

BROAID

+----------+----------+

)FFF2

BROBBA

+----------+----------+

)FFF4 !

BROLDT

LDT ADDRESS

+----------+----------+
)FFF6

SESSION/DEVICE ID

BROSID

+----------+----------+
)FFF8
)FFFA

BRORCB

REQUESTOR CALL BLOCK ADDRESS

+----------+----------+
BROTSB

TSB ADDRESS

+----------+----------+
)FFFC

JSB ADDRESS

BROJSB

+----------+----------+
)FFFE

BROBRO

QUEUE LINK ADDRESS

+----------+----------+
FLAGS FOR FIELD:

#FFEE -

OVERHEAD FLAGS

- INITIATE EVENT REQUEST
(.X •••••••••••••• ) - ANOTHER ROUTINE HAS SEEN REQ
( •• X ••••••••••••• ) - )A5 CALL GIVEN TO IPC (IURL)
( ••• XXXXX •••••••• ) - INITIATE REQUEST NUMBER

BRFINR
BRFARS
BRFA5
BRFERN

(x ••.•••••••••••• )

FLAGS FOR FIELD:
BRFAPI
BRFRAV
BRFMRO
BRFTID
BRFSB
BRFSAB
BRFDNR

BROOFL

BROOF2

#FFFO -

ALTERNATE REQUEST ID SPECIFIED
REQUEST ACCEPTS EVENT KEYS
MULTI-RECORD READ/WRITE REQUEST
TASK ID SPECIFIED IN BROTSB
SECURITY BYPASS
SUSPENDING ABORT
DO NOT RELEASE MEMORY
UNUSED

22-33

Structure Pictures

(X .•...••••.••••.
(.X ...•••...••••.
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X •••••••••••
( ••••• X ••••••••••
( •••••• X •••••••••
= ( ••••••• X••••••••

2270512-9701

OVERHEAD FLAGS PART 2

)
)
)
)
)
)
)
)

BRO

DNOS

System Design Document

EQUATES:
LABEL
BRFEOR
BRFABT
BROSIZ

EQUATE TO
BRFA5
BRFSAB
$-BROOFL

Structure Pictures

VALUE
)02
)05
)12

22-34

DESCRIPTION
END OF RECORD DONE IMMEDIATELY
ABORTED OPERATION

2270512-9701

DNOS System Design Document

BTB

************************************************************

**
**

B - TREE BLOCK

(BTB)

LOCATION: DISK AND BUFFER SEGMENTS

09/07/79

**
*
*

************************************************************

*
*
*
*
**
*
*
*
*
*
**

**
*
*
*
*

*
*
*
*
*
*
*
*
*
**
*
*
*
*
**
*

THE BTB DESCRIBES THE OVERHEAD INFORMATION REQUIRED TO SORT
THE LOGICAL RECORDS OF A KEY INDEXED FILE.
THE BTB RESIDES
ON DISK AND IS READ INTO MEMORY WHEN USING A RECORD THAT
IT DESCRIBES.

SPECIAL FIELD COMMENTS:
BTBPPT - IF THIS BLOCK IS BEING USED AS A B-TREE NODE, THIS
FIELD IS THE PHYSICAL RECORD NUMBER OF THE
PRECEDING NODE ON THE SAME LEVEL (ZERO IF THIS IS
THE LEFTMOST NODE).
IF THIS BLOCK IS AVAILABLE
FOR USE, THIS FIELD POINTS TO THE NEXT AVAILABLE
BLOCK.
NUMBER OF POINTER/KEY VALUE PAIRS CURRENTLY
BTBNIE
CONTAINED IN THIS BLOCK.
BTBNEA - THIS BYTE IS ZERO WHEN THE BLOCK IS INITIALIZED
BECAUSE OF A B-TREE SPLIT. WHEN THE FIRST ENTRY
IS MADE TO THE BLOCK, THIS BYTE CONTAINS THE
NUMBER OF ENTRIES IN THE BLOCK THAT ARE GREATER
THAN THE NEW ENTRY.
BTBNEC - WHEN THE BLOCK IS INITIALIZED DUE TO A B-TREE
SPLIT, THIS VALUE IS THE MAXIMUM ENTRIES THAT MAY
BE INSERTED INTO THE BLOCK, PLUS ONE.
FOR EACH
SUBSEQUENT ENTRY TO THIS BLOCK, IF THE NUMBER OF
ENTRIES IN THE BLOCK THAT ARE GREATER THAN THE NEW
ENTRY EQUALS THE NUMBER IN BTBNEA, BTBNEC IS
DECREMENTED BY ONE.
WHEN THIS B-TREE BLOCK
IS ABOUT TO SPLIT, IF BTBNEC IS ZERO, THE SPLIT IS
AT A RATIO OF THE LOWER 90% OF THE ENTRIES ARE IN
ONE BLOCK AND THE UPPER 10% IN THE OTHER.
OTHERWISE,
THE SPLIT IS 50% TO EACH.
BTBDBK - IF THIS IS A NON-LEAF NODE, THE FIRST FOUR BYTES
CARRY THE RECORD NUMBER OF A BRANCH OR LEAF NODE AND
THE LAST TWO BYTES ARE NOT MEANINGFUL.
IF THIS IS' A
LEAF NODE, THE FIRST FOUR BYTES CONTAIN A RECORD NUMBER
OF A DATA RECORD AND THE LAST TWO BYTES CONTAIN THE
ID OF THE LOGICAL RECORD WITHIN THE DATA RECORD.
BTBCMD - THIS FIELD IS USED WHEN THIS RECORD HAS TO BE PRELOGGED.
IT IDENTIFIES ALL THE RECORDS PRELOGGED BY THE OPERATION.

*----------+----------*
)00 !

BTBBLK

+----------+----------+

)02

BLOCK NUMBER (2 WORD PHYSICAL
RECORD NUMBER OF THIS BTB)

+----------+----------+

)04

2270512-9701

BTBCMD

PRELOG NUMBER

22-35

Structure Pictures

BTB

DNOS

System Design Document

+----------+----------+
)06

BTBSR

+----------+----------+
)08 !

BTBPPT

+----------+----------+

)OA

SPACE REMAINING (BYTES) IN BTB
PREDECESSOR OR FREE POINTER

+----------+----------+

)OC

BTBSPT

SUCCESSOR POINTER

+----------+----------+
)OE

)10
)12

+----------+---------~+

BTBNIE

BTBLE

+----------+----------+
BTBNEA

BTBNEC

+----------+----------+
BTBDBK

)14

+----------+----------+
)16

NUMBER OF INDEX ENTRIES
LEAF ENTRY FLAG(l=THIS IS A LEAF)
# OF ENT. AFTER LAST INSERT
COUNT OF # SEO. INSERTS
B-BLOCK DATA BASE KEY

+----------+----------+

)18 !

+----------+----------+
)lA

BTBKVL

+----------+----------+

FIRST POINTER/KEY VALUE PAIR

EQUATES:
LABEL
BTBSIZ

EQUATE TO

Structure Pictures

VALUE

DESCRIPTION

)lC

22-36

2270512-9701

DNOS System Design Document

CCB

***********************************************************

** CHANNEL CONTROL BLOCK
*
(CCB)
06/09/83 *
*
*
LOCATION: SYSTEM AREA AND JCA
*
*
***********************************************************
* THE CCB IS THE IN-MEMORY REPRESENTATION OF A CHANNEL. IT
* RESIDES IN SYSTEM TABLE AREA FOR GLOBAL CHANNELS, IN THE
* JCA FOR JOB-LOCAL OR TASK-LOCAL CHANNELS. MOST OF THIS
* STRUCTURE IS BUILT FROM THE CHANNEL DESCRIPTOR RECORD ON
* DISK.
*----------+----------*
)00

CCBCCB

NEXT CCB ADDRESS

+----------+----------+
)02

CCBFLG

+----------+----------+
)04

CCBTYP

CCBTF

+----------+----------+
)06

CCBMXL

)08
)OA

+----------+----------+
CCBASG

CCBOPN

+----------+----------+
CCBRPB

CHANNEL FLAGS
DEFAULT RESOURCE TYPE
RESOURCE TYPE FLAGS
MAXIMUM MESSAGE LENGTH
NUMBER OF CURRENT ASSIGNS
NUMBER OF CURRENT OPENS
RPB POINTER

+----------+----------+
)OC

CCBTSB

OWNER TASK TSB ADDRESS

+----------+----------+
)OE

CCBJSB

OWNER TASK JSB ADDRESS

+----------+----------+
)10

CCBPFL

CCBIID

+----------+----------+

)12

CCBFMT

+----------+----------+
)14

CCBFCB

OWNER TASK PROG FILE LUNO (DPOS/M)
OWNER TASK INSTALLED ID
OWNER TASK PROGRAM FILE FDP (D)

+----------+----------+
) 16 !

CCB PBQ

PENDING BRB QUEUE HEADER

+----------+----------+
)18 !

CCBABQ

+--~-------+----------+
CCBNAM
!

) 1A!

+----------+----------+
/
/

ALREADY BEING PROCESSED QUEUE HEAD
CHANNEL NAME LENGTH AND NAME (M).

/
/

+----------+----------+
FLAGS FOR FIELD:

*
*

CCBFLG

#02 -

CHANNEL FLAGS

CCFSCI = (XX •••••••••••••• ) - SCOPE - GLOBAL,JOB,TASK
OO=TASK-LOCAL
01=JOB-LOCAL

2270512-9701

22-37

Structure Pictures

CCB

*
*

DNOS

CCFSHR
(
CCFTYP = (
CCFASG = (
CCFABT
(
CCFIOU = (
(

CCFBSY
(
CCFOOP
(
CCFOCL = (
CCFDED = (
CCFRCL = (
CCFRAB
(
(

System Design Document

10=GLOBAL
11=RESERVED
•• X ••••••••••••• )
SHARED(I)/NOT SHARED
••• X •••••••••••• )
SYMMETRIC(I) OR MASTER/SLAVE
•••• X ••••••••••• )
OWNER DOES(I) / NOT DO ASSIGN
••••• X •••••••••• )
OWNER DOES(I) / NOT DO ABORTS
•••••• X ••••••••• )
OWNER DOES(I) / NOT DO IOU OP S
••••••• X •••••••• )
RESERVED (AS IN CREATE CHAN RCB)
•••••••• X ••••••• ).- CCB IS BUSY (IN USE BY IPC TASK)
••••••••• X •••••• )
OWNER TASK HAS ISSUED OPEN
•••••••••• X ••••• )
OWNER TASK HAS CLOSED OR ABORTED
••••••••••• X •••• )
CHANNEL IS DEAD
•••••••••••• X ••• )
NON-SH SYMMETRIC REQUESTER CLOSED
••••••••••••• X •• )
NON-SH SYMMETRIC REQUESTER ABORTED
•••••••••••••• XX)
RESERVED

*
*

NOTE:

CCBTF=CCBTYP+l MUST BE TRUE

EQUATES:
LABEL

-----

CCFSC2
CCFSCM
CCFCHN
CCFDEV
CCFFIL
CCFREM
CCBDSZ
CCBCSZ

EQUATE TO

--------CCFSCl+l
)COOO
13
14
15
)0007
$+8
$

Structure Pictures

VALUE

----)01
)COOO
)OD
)OE
)OF
)07
)22
)4C

22-38

DESCRIPTION

-----------------------------CHANNEL SCOPE MASK
CHANNEL
DEVICE
FILE
RESOURCE TYPE FLAGS MASK
DPOS/D CCB SIZE
DPOS/M CCB SIZE

2270512-9701

CDE

DNOS System Design Document

********************************~***************************

** COMMAND DEFINITION ENTRY (CDE)
04/02/82
**
**************************************************************
* THE CDE DESCRIBES ONE ENTRY IN THE COMMAND DEFINITION
* TABLE FOR A DEVICE. THE ENTRY SHOWS WHAT TASK IS TO BE

BID WHEN A KEYBOARD TASK BID IS DONE.

)00
)02
)04
)06
)08
)OA

*----------+----------*
CDECHR
CDEFLG!
+----------+----------+
CDELL
CDELID!
+----------+----------+
CDEDL
CDEDID!
+----------+----------+
!
CDEPVl
!
+----------+----------+
CDEPV2
+----------+----------+
CDEUID
+----------+----------+
/
/
/
/

ENTRy IDENTIFICATION CHARACTER
BID FLAGS
LUNO WITH WHICH TO BID LOGIN
LOGIN TASK ID
LUNO TO BID DESTINATION TASK
DESTINATION TASK ID
PARAMETER VALUE 1 FOR DEST. TASK
PARAMETER VALUE 2 FOR DEST. TASK
DEFAULT USER ID

+----------+----------+
FLAGS FOR FIELD: CDEFLG

1101 -

BID FLAGS

CDFBCJ = (X ••••••••••••••• ) - BID DEST. TASK IN CURRENT JOB
CDFPEA = <.X .............. ) - PASS THE CDE ADDRESS TO LOGIN
CDFELB = ( •• X ••••••••••••• ) - EVEN LOADING BID
( ••• X •••••••••••• ) - DEFAULT USER ID FOR ELB
CDFDUI
( •••• XXXX •••••••• ) - * RESERVED *
EQUATES:
LABEL
CDESIZ

2270512-9701

EQUATE TO
$

VALUE
)12

22-39

DESCRIPTION
COMMAND DEFINITION ENTRY SIZE

Structure Pictures

CDR

DNOS

System Design Document

************************************************************

** CHANNEL DESCRIPTOR RECORD
(CDR)
08/14/81
**
*
*
LOCATION: DISK
*
*
************************************************************
* THE CDR IS THE PERMANENT RECORD OF A CHANNEL. IT IS
* CARRIED AS AN ALIAS OF THE PROGRAM FILE IN WHICH THE
* CHANNEL OWNER TASK RESIDES.
*----------+----------*
)00

CDRHKC

+----------+----------+
CDRHKV
+----------+----------+
)04!
CDRNAM
+----------+----------+
/
/
/
)02

+----------+----------+
FILLOO
+----------+----------+
)OE
FILL01
+----------+----------+
)10
CDRFDF
+----------+----------+
)12
CDRFLG
CDRIID
+----------+----------+
)14
CDRTYP
CDRTF
+----------+----------+
)16
CDRMXL
+----------+----------+
)18
FILL04
+----------+----------+
)lA !
+----------+----------+
)lC !
+----------+----------+
)lE
CDRRNA
+----------+----------+
)20 !
CDRRAF
+----------+----------+
)22!
FILL05
+----------+----------+
/
/
/
/

Structure Pictures

CHANNEL NAME

RESERVED
RESERVED
FLAGS
CHANNEL FLAGS
OWNER TASK INSTALLED ID
DEFAULT RESOURCE TYPE
RESOURCE TYPE FLAGS
MAXIMUM MESSAGE LENGTH
RESERVED

RECORD NUMBER OF NEXT CDR OR ADR
RECORD NUMBER OF ACTUAL FDR
RESERVED

+----------+----------+
)90!
CDRUID
!
+----------+----------+
/
/
/
/

HASH KEY VALUE

)OC

HASH KEY COUNT

USER ID OF CHANNEL CREATOR

/
22-40

2270512-9701

DNOS System Design Document

CDR

+----------+----------+
)98

CDRPSA

PUBLIC SECURITY ATTRIBUTES

+----------+----------+
)9A

CDRSCG

SDT WITH 9 CONTROL GROUPS

+----------+----------+
/
/

/
/

+----------+----------+
)F8!

FILL06

RESERVED

+----------+----------+
/
/

/
/

+----------+----------+
FLAGS FOR FIELD:

CDRFDF

1110 -

(XXXXXXXXXXXXXXX.) CDFCDR

( •••••••••••••••

FLAGS FOR FIELD:

*
*
*
*

CDRFLG

FLAGS
STANDARD FDR FLAGS
CDR(l) OR NOT(O)

1112 - .CHANNEL FLAGS

CDFSC1 = (Xx •••••••••••••• ) - SCOPE - GLOBAL, JOB, TASK
OO=TASK-LOCAL
01=JOB-LOCAL
10=GLOBAL
11=RESERVED
CDFSHR
( •• X ••••••••••••• ) - SHARED(I) OR NOT SHARED
CDFTYP
( ••• X •••••••••••• ) - SYMMETRIC(l) OR MASTER/SLAVE
CDFASG
( •••• X ••••••••••• ) - OWNER DOES(I) / NOT DO ASSIGN
( ••••• X •••••••••• ) - OWNER DOES(I) / NOT DO ABORTS
CDFABT
CDFIOU
( •••••• X ••••••••• ) - OWNER DOES(l) / NOT DO IOU OPS
( ••••••• X •••••••• ) - RESERVED (AS CREATE CHANNEL)
EQUATES:
LABEL
-----

CDRDPM
CDRCDM
CDFSC2
CDFSCH
CDFRM1
CDFCHN
CDFDEV
CDFFIL
CDFRM2
CDRSIZ
CDRMAX

2270512-9701

EQUATE TO

VALUE

---------

-----

)0080
)0001
CDFSC1+l
)COOO
)FEOO
13
14
15
)FF07
$

)3000

)80
)01
)01
)COOO
)FEOO
)OD
)OE
)OF
)FF07
)100
)3000

22-41

DESCRIPTION

-----------------------------DELETE-PROTECT MASK
CDR FLAG MASK

BASK FOR CHANNEL SCOPE
MASK TO ZERO RESERVED BITS
CHANNEL
DEVICE
FILE
MASK TO ZERO RESERVED TYPE FLAGS
MAXIMUM VALUE FOR CDRMXL

Structure Pictures

CLR

DNOS

System Design Document

*********************************~**************************

*
*
CAPABILITIES LIST FILE RECORD (CLR)
01/21/83
*
*
*
*
LOCATION .S$CLF ON DISK
*
*
*
*
************************************************************
* THE CLR IS USED BY TASKS WHICH ADD, DELETE, OR MODIFY
* USER IDS OR ACCESS GROUPS. IT HAS 5 VARIANTS: FIR, AGR,
* UDR, UDO, AND VFY. THE STRUCTURE AND PURPOSE OF EACH VARIANT
* IS DESCRIBED BELOW.
*
** THIS PACKED RECORD IS USED FOR USER ID ENTRIES IN FIR
*
** BEGINNING PACKED RECORD UID
)00

*----------+----------*
FIRID

USER ID

+----------+----------+
/
/

/
/

+----------+----------+
FIRRN

)08 !

+----------+----------+

)OA

**
*
*
*

SIZE

USER'S UDR RECORD NUMBER

END OF PACKED RECORD

THIS PACKED RECORD IS USED FOR ACCESS GROUP ENTRIES IN
USER DESCRIPTOR RECORDS (UDR) AND USER DESCRIPTOR OVERFLOW
RECORDS (UDO).

BEGINNING PACKED RECORD AGE
ACCESS GROUP ENTRY

*----------+----------*
AGERN

)00

+----------+----------+
)02

AGEOFF

OFFSET INTO ACCESS GROUP RECORD
ACCESS GROUP ENTRY FLAGS
END OF PACKED RECORD

+----------+----------+

)04 SIZE

**
*

AGEFLG

ACCESS GROUP RECORD NUMBER

THIS PACKED RECORD IS USED FOR ACCESS GROUP NAMES IN
ACCESS GROUP RECORDS (AGR)

BEGINNING PACKED RECORD AGN

*----------+----------*
)00

AGNNAM

Structure Pictures

ACCESS GROUP NAME

22-42

2270512-9701

DNOS System Design Document

CLR

+----------+----------+
/
/

)08

/
/

+----------+----------+
AGNRSV

RESERVED

+----------+----------+
)OA SIZE

*
*
*
**
**

*
*
*
*
*

END OF PACKED RECORD

BEGINNING PACKED RECORD CLR

FILE INFORMATION RECORD (FIR)
THIS VARIANT IS USED TO STORE USER IDs.
IT CONTAINS A
FLAG WORD, A POINTER TO ANOTHER FIR, AND 5 UID ENTRIES.
EACH UID ENTRY CONTAINS A USER ID AND THE RECORD NUMBER
OF ITS USER DESCRIPTOR RECORD (UDR).

)00

*----------+----------*
FIRFIR

CONTINUATION RECORD NUMBER

+----------+----------+
)02
)04

FIRRSV

+----------+----------+
FIRENT

FIR USED/AVAILABLE FLAG
5 UID ENTRIES

+----------+----------+
/
/

/
/

+----------+----------+
)OE

+----------+----------+
/
/

/
/

+----------+----------+
!

)18

+----------+----------+
/
/

/
/

+----------+----------+
)22 !

+----------+----------+
/
/

/
/

+----------+----------+
)2C

+----------+----------+
/
/

/
/

+----------+----------+
2270512-9701

22-43

Structure Pictures

CLR

**
**
*
*
*
*

DNOS System Design Document

ACCESS GROUP NAME RECORD (AGR)
THIS VARIANT IS USED TO STORE ACCESS GROUP NAMES.
IT CONTAINS A FLAG WORD, A POINTER TO THE NEXT AGR, AND
5 AGN ENTRIES.
EACH AGN ENTRY CONTAINS AN ACCESS GROUP
NAME AND A WORD OF UNUSRD FLAGS.

)00
)02
)04

*
*
**
*
*
*
*
*
*

*----------+----------*
AGRAGR
+----------+----------+
!
AGRRSV
+----------+----------+
AGRAGN
+----------+----------+
/
/
/
/

)OE

+----------+----------+
+----------+----------+
/
/
/

)18

+----------+----------+
+----------+----------+
/
/
/

)22

+----------+----------+
+----------+----------+
/
/
/

)2C

+----------+----------+
+----------+----------+
/
/
/

CONTINUATION RECORD NUMBER
AGR USED/AVAILABLE FLAG
5 AGN ENTRIES

+----------+----------+
USER DESCRIPTOR RECORD (UDR)
THIS VARIANT CONTAINS INFORMATION ASSOCIATED WITH A USER ID.
THIS INFORMATION INCLUDES THE ENCRYPTED PASSCODE, DESCRIPTION,
AND UP TO 5 ACCESS GROUP ENTRIES.
EACH ACCESS GROUP ENTRy
CONTAINS A RECORD NUMBER OF AN ACCESS GROUP RECORD (AGR)
AND THE OFFSET INTO THE AGR FOR AN ACCESS GROUP NAME OF
WHICH THIS USER IS A MEMBER.

*----------+----------*
Structure

Pictures

22-44

2270512-9701

DNOS System Design Document

)00

CLR

UDRUDO

POINTER TO OVERFLOW

UDRRSV

UDR USED/AVAILABLE FLAG

+----------+----------+

)02 !

+----------+----------+

)04

UDRPWD

+----------+----------+
/
/

)OC

/
/

ENCRYPTED PASSCODE

/
/

+----------+----------+
UDRFLG

+----------+----------+
)OE

UDRDES

+----------+----------+
/
/

/
/

UDR FLAG WORD
DESCRIPTION OF USER

/
/

+----------+----------+
)22

)24

UDRAGE

+----------+----------+
!

5 ACCESS GROUP ENTRIES (AGE)

+----------+----------+
)26

+----------+----------+
)28

+----------+----------+
)2A
)2C
)2E

+----------+----------+
+----------+----------+
+----------+----------+

)30 !

)32

+----------+----------+

)34

+----------+----------+
+----------+----------+

**
**
*
*
*

USER DESCRIPTOR OVERFLOW RECORD (UDO)
THIS VARIANT IS USED ONLY USED IN THE CASE THAT A USER IS
A MEMBER OF MORE ACCESS GROUPS THAN WILL FIT IN HIS UDR.
IT CONTAINS UP TO 12 ACCESS GROUP ENTRIES.

)00

*----------+----------*
UDOUDO

POINTER TO NEXT UDO

+----------+----------+
)02

UDORSV

+----------+----------+
)04 !
)06

UDOFIL

UDO USED/AVAILABLE FLAG
NOT USED

+----------+----------+

2270512-9701

UDOAGE

12 ACCESS GROUP ENTRIES (AGE)

22-45

Structure Pictures

CLR

DNOS System Design Document

)08

)OA
)OC
)OE

) 10
)12
)14

) 16
)18
)lA
)lC
)lE

)20
) 22
)24
)26
)28

)2A
)2C

)2E
)30
)32
)34

**
**
*
*

+----------+----------+
!
+----------+----------+
!
+----------+----------+
+----------+----------+
+----------+----------+
!
!
+----------+----------+
r
+----------+----------+
+----------+----------+
!
!
+----------+----------+
+----------+----------+
+----------+----------+
+----------+----------+
+----------+----------+
!
+----------+----------+
!
!
+----------+----------+
!
!
!
+----------+----------+
!
+----------+----------+
!
+----------+----------+
+----------+----------+
+----------+----------+
!
+----------+----------+
+----------+----------+
+----------+----------+
+----------+----------+
VERIFICATION RECORD (VFY)

THIS VARIANT IS USED BY THE SYSTEM RESTART TASK TO VERIFY
THE EXISTENCE OF .S$CLF.
IT IS ALSO USED BY TASKS WHICH
CREATE AND MODIFY ACCESS GROUPS BECAUSE IT CONTAINS A

Structure Pictures

22-46

2270512-9701

CLR

DNOS System Design Document

*
*

POINTER TO THE FIRST ACCESS GROUP RECORD.

)00

*----------+----------*
VFYNAM
+----------+----------+
/
/
/
/

)08
)OA

+----------+----------+
VFYBLK
+----------+----------+
VFYFIL
+----------+----------+
/
/
/
/

)36

NAME OF S$CLF

POINTER TO FIRST AGRBLK
NOT USED,

INITIALIZED TO BLANKS

+----------+----------+
SIZE
** END

FLAGS FOR FIELD: AGEFLG

OF PACKED RECORD

#03 - ACCESS GROUP ENTRY FLAGS

AGELDR = (X ••••••••••••••• ) - TRUE=USER IS LEADER OF ACCESS GROUP
AGEFCG
(.X •••••••••••••• ) - TRUE=FILE CREATION ACCESS GROUP
FLAGS FOR FIELD:

FIRRSV

#02 -

FIR USED/AVAILABLE FLAG

FIRFRE = (X ••••••••••••••• ) - TRUE=AVAILABLE RECORD
FLAGS FOR FIELD: AGRRSV

#02 - AGR USED/AVAILABLE FLAG

AGRFRE = (X ••••••••••••••• ) - TRUE=AVAILABLE RECORD
FLAGS FOR FIELD:

UDRRSV

#02 -

UDR USED/AVAILABLE FLAG

UDRFRE = (X ••••••••••••••• ) - TRUE=AVAILABLE RECORD
FLAGS FOR FIELD:

UDRFLG

HOC -

UDR FLAG WORD

UDRPVL = (XXXXX ••••••••••• ) - USER PRIVELEDGE LEVEL
UDRAGC = ( ••••• XXXXXXXXXXX) - ACCESS GROUP COUNT
FLAGS FOR FIELD: UDORSV
unOFRE

2270512-9701

#02 -

UDO USED/AVAILABLE FLAG

(X ••••••••••••••• ) - TRUE=AVAILABLE ENTRY

22-47

Structure Pictures

CLR

DNOS System Design Document

EQUATES:
LABEL

-----

FIR
AGR
UDR
UDO
VFY
FIRSIZ
AGRSIZ
UDRSIZ
UDOSIZ
VFYSIZ

EQUATE TO

--------$
$
$
$
$
$
$
$
$
$

Structure Pictures

VALUE

DESCRIPTION

)00
)00
)00
)00
)00
)36
)36
)36
)36
)36

22-48

2270512-9701

DNOS System Design Document

DDB

************************************************************

* DIOU DATA BASE DEFINITION
*
(DDB)
12/01/81*
*
*
LOCATION: DIOU NAME MANAGER SEGMENTS AND
*
*
RELATIVE RECORD FILE
*************************************************************
*

** BEGINNING PACKED RECORD DDB
DEVICE NAMES
DEVICE NUMBERS

*
*

RELATIVE RECORD FILE RECORDS

*----------+----------*
)00

DDBOR1

+----------+----------+
)02

DDBORT

+----------+----------+
)04!
)06

DDBODT

DDBOCT

+----------+----------+
DDBOCE

*RESERVED
*RESOURCE TYPE
*DEVICE TYPE
*CDT NUMBER
*CDE MASK

+----------+----------+
)08

DDBOWT

DDBOR2

+----------+----------+

*WRITE TASK ID
*RESERVED

*----------+----------*
)00

*DEVICE NUMBER

DDB1NU

+----------+----------+
)02
)04

DDB1RR

+----------+----------+
DDB1PA

*RELATIVE RECORD NUMBER
*PDT ADDRESS

+----------+----------+
)06

DDB1F1

*FLAGS

+----------+----------+
)08 !

DDB1F2

+----------+----------+

)OA

DDB1LC

DDB1TC!

+----------+----------+
)OC
)OE

DDBI0J

+----------+----------+
DDBILP

*FLAGS
*ASSIGNED LUNO COUNT
*ATTACHED TASK COUNT
*OWNER JOB
*LOCKED PARAMETER LIST ANCHOR

+----------+----------+

)10 !

*RPB ANCHOR

DDBIRP

+----------+----------+
*----------+----------*

)OO!

DDB2Rl

DDB2NF

+----------+----------+

2270512-9701

*RESERVED
*DEVICE NAME FILE

22-49

Structure Pictures

DDB

)02
)04

)00
)02

)00
)02
)04
)06

DNOS System Design Document

DDB2RR

+----------+----------+
DDB2NA
+----------+
*----------+----------*
OSPPRM
OSPSTR
+----------+----------+
OSPOFF
OSPLEN
+----------+----------+
*----------+----------*
STRES
STID
+----------+----------+
!
STFNAS
+----------+----------+
STFNUS
+----------+----------+
FILLOO
!
+----------+----------+
/
/

)1A

/
/

*DEVICE NAME

*PARAMETER NUMBER
*STRUCTURE IDENTIFIER
*OFFSET INTO STRUCTURE
*LENGTH OF PARAMETER

*RESERVED
*SESSION IDENTIFIER
*FIRST NAME SEGMENT RUN ID
*FIRST NUMBER SEGMENT RUN ID
*REST OF THE RUN IDS

/
/

+----------+----------+
STPTNM
+----------+----------+
/
/

*RELATIVE RECORD NUMBER

*PATHNAME OF SYSTEM

/
/

+----------+----------+

)2C SIZE

** END OF PACKED RECORD

EQUATES:
LABEL

-----

RELREC
NAMSEG
NUNSEG
DSKPDT
DDBOVL
DDBOPD
DDBOVD
DDBOUP
DDBNOS
DDB1SZ
DDF1DS

EQUATE TO

--------0
1
2
3
$
$
$
$
$
$
)1800

Structure Pictures

VALUE
)00
)01
)02
)03
)OA
)OA
)OA
)OA
)OA
)12
)1800

22-50

DESCRIPTION
*RELATIVE RECORD FILE
*NAME MANAGER SEGMENTS ORDERED BY
*NAME MANAGER SEGMENTS ORDERED BY
*DISK PDT
*BEGINNING OF VARIABLE LENGTH PARMS
*PRINT DEVICE NAME
*VIRTUAL DEVICE SERVER
*USER PARAMETERS
*NON O.S. PARAMETERS
*SIZE
*DEVICE STATE MASK

2270512-9701

DNOS System Design Document

DIA

***********************************************************

**
*
*
LOCATION:
JCA
*
*
***********************************************************
* THE DIA DESCRIBES A TASK WHICH IS TERMINATING ABNORMALLY.
* IT IS USED TO PROVIDE END ACTION STATUS TO A TASK AND TO
* BUILD A TERMINATION MESSAGE FOR THE SYSTEM LOG.
DIAGNOSTIC STATUS

(DIA)

*----------+----------*
DIAEC
FILLOO
+----------+----------+
DIAWP
+----------+----------+
DIAPC
+----------+----------+
!
DIAST
!
+----------+----------+
DIALM1
!
+----------+----------+
DIALM2
+----------+----------+

)OO!
)02
)04
)06
)08
)OA

05/16/79

TASK ERROR CODE
RESERVED
TASK WORKSPACE POINTER
TASK PROGRAM COUNTER
TASK STATUS
END ACTION TIME LIMIT(lST WORD)
(SECOND WORD)

EQUATES:
LABEL
DIASIZ

2270512-9701

EQUATE TO
$

VALUE

DESCRIPTION

)QC

22-51

Structure Pictures

DIT

DNOS System Design Document

*********************************************************************

*
*
DISK INFORMATION TABLE
(DIT)
09/09/83
*
*
*
*
*********************************************************************
* THIS TEMPLATE IS USED TO DESCRIBE EACH ENTRY IN THE DITDAT TABLE
* USED BY THE DISK VOLUME UTILITIES. THERE IS ONE ENTRY IN DITDAT
* FOR EACH DISK TYPE THAT IS SUPPORTED BY DNOS.
*
**

BEGINNING PACKED RECORD DIT

*----------+----------*
)00

DITSR1

DISK STORE REGISTERS 1.

+----------+----------+
)02

DITSR2

+----------+----------+
)04

DITSR3

DISK STORE REGISTERS 3

DITFLG

DISK INFORMATION FLAGS

+----------+----------+

)06

+----------+----------+
)08

DISK STORE REGISTERS 2

DITPRL

PHYSICAL RECORD LENGTH-DEFAULT

+----------+----------+
)OA

DITNVE

+----------+----------+

)OC

DITNAM

+----------+----------+
/
/

/
/

NUMBER VCATALOG ENTRIES-DEFAULT
DISK NAME

/
/

+----------+----------+
)lC

DITNSC

DITSCM

+----------+----------+
)lE

DITHIF

+----------+----------+

NUMBER SPARE CYLINDERS
SPARE CYLINDERS FOR MAPPING
HARDWARE INTERLEAVE FACTOR-DEFAULT

)20 !

DITTPP

TEST PATTERNS POINTER

)22

DITDSP

DIAGNOSTIC SECTORS POINTER

+----------+----------+

+----------+----------+
)24

DITNDS

FILL03

)26 !

DITRTF

NUMBER OF DIAGNOSTIC SECTORS
SPARE BYTE - NOT USED
READ TYPES FLAGS FOR SURFACE ANALYSI

)28

DITCRL

DISK CONTROLLER REVISION LEVEL

+----------+----------+
+----------+----------+
+----------+----------+
)2A

FILL05

SPARE -

NOT USED

+----------+----------+
)2C SIZE

Structure Pictures

END OF PACKED RECORD

22-52

2270512-9701

DNOS System Design Document

DOR

************************************************************

**
*
*

DIRECTORY OVERHEAD RECORD

(DOR)

LOCATION:

01/31/79

DISK

**
**

************************************************************

*
*

THE DOR IS THE FIRST RECORD (RECORD 0) OF A DIRECTORY FILE
AND SHOWS THE MAXIMUM SIZE AND CURRENT USE OF A DIRECTORY.

*----------+----------*

)00 !

DORNRC

)02 !

DORNFL

# FILES CURRENTLY IN DIRECTORY

)04

DORNAR

# OF AVAILABLE RECORDS

+----------+----------+
+----------+----------+

+----------+----------+
)06 !

DORTFC

+----------+----------+

)08

DORDNM

+----------+----------+
/
/

/
/

# RECORDS IN DIRECTORY

NUMBER OF TEMPORARY FILES
DIRECTORY FILE NAME

/
/

+----------+----------+
)10 !

LEVEL # OF DIRECTORY

DORLVL

+----------+----------+

)12!

DORPNM

/
/

DORPRS

+----------+----------+
/
/

NAME OF PARENT FILE

+----------+----------+
)1A

+----------+----------+

DEFAULT PHYSICAL RECORD LENGTH
(USED FOR FILE CREATION)

EQUATES:
LABEL
DORSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)lC

22-53

Structure Pictures

DPD

DNOS System Design Document

************************************************************

** DISK PDT EXTENSION
*
(DPD)
01/17/83 *
*
*
LOCATION: SYSTEM TABLE AREA
*
*
************************************************************
* THE DPD APPEARS AFTER THE StANDARD PDT INFORMATION FOR A
* DISK DEVICE. IT IS USED AS A WORK AREA BY THE DSR AND BY
* THE DISK MANAGER TASK.

*----------+----------*
DPDTIL
!
!
+----------+----------+
/
/
/

)OO!

) 10

+----------+----------+
DPDSLG!
!
+----------+----------+
/
/
/
/

TILINE IMAGE FOR SYSTEM LOG

+----------+----------+
)20 !
DPDECT
+----------+----------+
)22
DPDWTK
+----------+----------+
)24
DPDSTK
DPDOHD!
+----------+----------+
)26
DPDCYL
+----------+----------+
)28!
DPDSRD
!
DPDRTK
!
+----------+----------+
)2A
DPDWRD
+----------+----------+
)2C
DPDILF
!
+----------+----------+
)2E
DPDMAD
+----------+----------+
)30
DPDSAD
+----------+----------+
)32
DPDDRS
!
+----------+----------+
)34
DPDFLG
!
+----------+----------+
)36
DPDIBF
!
+----------+----------+
)38
+----------+----------+
)3A
+----------+----------+
)3C
DPDFMS
+----------+----------+
Structure Pictures

TILINE IMAGE

TILINE UNIT ERROR COUNT
WORDS PER TRACK
SECTORS PER TRACK
OVERHEAD PER RECORD
HEADS & CYLINDERS
PER RECORD
RECORDS PER TRACK
WORDS PER RECORD
SECT~RS

INTERLEAVING FACTOR
MAX NUMBER OF

ADUS ON DISK

SECTORS PER ADU
DEFAULT PHYSICAL RECORD SIZE
FLAGS
INITIALIZATION BUFFER

VCAT FD SPECIAL AREA SSB ADDRESS

22-54

2270512-9701

DNOS System Design Document

DPD

)3E

DPDFDB
+----------+--------~-+
)40
DPDPBM

POINTER TO VCATALOG FCB

)42

DISK MANAGER TABLE/BUFFER ADDR
(NON-ZERO = DISK INSTALLED)
VOLUME NAME

+----------+----------+
DPDVNM
+----------+----------+
/
/

/
/

)4A

/
/

+----------+----------+
DPDTFL
+----------+----------+
/
/

/
/

TEMPORARY FILE NAME SEED

/
/

+----------+----------+
DPDIVD
+----------+----------+
!
DPDIVT
!
+----------+----------+

)52 !

INSTALLED VOLUME CREATION DATE

)54

INSTALLED VOLUME CREATION TIME

FLAGS FOR FIELD: DPDFLG

#34 -

= ( X •••••••••••••••
DPFRAW = ( • X ••••••••••••••
DPFBRW
( •• X •••••••••••••
DPFRST
( ••• X ••••••••••••
DPFSTR = ( •••• X •••••••••••

*
*
*
*
*
*
*

DPFODI = (
DPFWRP = (
DPFBLF = (

DPFDTN = (
= (

)

FLAGS

DISK READ AFTER WRITE
BIT MAP READ AFTER WRITE
RESTORE FLAG
)
STORE REGISTER FLAG ( 1= STORE
REG COMMAND WAS ISSUED BY DSR
TO DETERMINE IF )lB ERROR IS
AN UNSAFE OR MEDIA CHANGE
••••• X •••••••••• )
1 = ONLINE DIAGNOSTIC REQUEST
•••••• X ••••••••• )
SOFTWARE WRITE PROTECT FLAG
••••••• X •••••••• ) - BUFFER LOCK FLAG.
1 = THIS DRIVE LOCKED THE
NON-RE ENTRANT BUFFER USED
BY MEDIA CHANGE VALIDATION
PROCESS.
•••••••• X ••••••• )
DIRECT TILINE I/O FLAG
••••••••• XXXXXXX)
)
)

EQUATES:
LABEL
DPDSIZ

2270512-9701

EQUATE TO

VALUE
)56

22-55

DESCRIPTION
DISK PDT

+ EXTENSION

SIZE

Structure Pictures

DPR

DNOS System Design Document

***********************************************************

*
*
DUTIL DEVICE PARAMETERS
(DPR)
10/04/83
*
*
*
*
CHANGES TO THIS TEMPLATE REQUIRE CORRESPONDING
*
*
CHANGES TO THE PASCAL TEMPLATE "DPRPAS".
*
*
***********************************************************
* THE DPR TEMPLATE DESCRIBES THE DEVICE PARAMETERS MANAGED
* BY THE DEVICE I/O UTILITY (DUTIL). IT INCLUDES PARAMETERS
* IN THE FOLLOWING RANGES:
*
PARAMETER USAGE
PARAMETER RANGE
*
*
)01 - )5F
OPERATING SYSTEM RESERVED
*
NOT
SUPPORTED
)60
)FF
*
** IN THE FIELD COMMENTS, RO INDICATES THAT A PARAMETER IS
* READ ONLY AND CANNOT BE MODIFIED.
** SPECIAL FIELD COMMENTS:
* DPRNAM - ONE TO EIGHT ALPHANUMERIC CHARACTERS WITH A LETTER
*
AS THE FIRST CHARACTER.
* DPRNUM - ONE WORD NUMBER BETWEEN )0001 AND )07FF, EXCLUDING
*
100 THROUGH 255 ()64 THROUGH )FF).
* DPRTYP LIKE THE PDTTYP FIELD. ON AN ASSIGN LUNO, THE VALUE
*
OF THIS FIELD IS PUT INTO THE LDTTYP FIELD OF THE
*
LDT AND IS RETURNED TO THE CALL BLOCK IN THE UPPER
*
BYTE OF THE DATA BUFFER FIELD.
* DPRJOB - JSB OF THE FIRST JOB TO ASSIGN A LUNO TO A TERMINAL.
** EQUATES FOR DPRFLG
*
00 - ONLINE
*
01 - OFFLINE
*
10 - DIAGNOSTIC
*
11 - SPOOLER
* EQUATE FOR DPRDSF
* EQUATES FOR DPRDTF - DEVICE TYPE FLAGS

Structure Pictures

22-56

2270512-9701

DNOS System Design Document

DUS

************************************************************

** DEVICE UTILITY SESSION TABLE (DUS)
*
09/09/83 *
*
*
LOCATION: IN DUDATA
*
*
**************************************************************
*----------+----------*
)OO!

)02

DUSRES

DUSLUN

+----------+----------+
DUSNAM

+----------+----------+
)04 !

RESERVED AT PRESENT
LUNO OF ACTIVE FILE
NAME MANAGER SEGMENT IDS

+----------+----------+

)06

)08

+----------+----------+
DUSVOL

VOLUME NAME OF SYSTEM DISK

+----------+----------+
/
/

/
/

+----------+----------+

)10!

DUSSYS

+----------+----------+
/
/

/
/

SYSTEM NAME

/
/

+----------+----------+
)18

DUSDTB

+----------+----------+
/
/

/
/

TABLE OF DEVICE TYPE COUNTS

/
/

+----------+----------+
EQUATES:
LABEL
MAXSEG
DUSSIZ

2270512-9701

EQUATE TO
3
$

VALUE

)03
)26

22-57

DESCRIPTION
MAXIMUM NUMBER OF SEGMENTS

Structure Pictures

FDP

DNOS System Design Document

************************************************************

** FILE DESCRIPTOR PACKET
(FDP)
06/22/81
**
*
*
LOCATION: ALWAYS A SUB-STRUCTURE
*************************************************************
*
* THE FDP IS A TWO WORD ADDRESS OF A FILE CONTROL BLOCK
* (FCB). THE FIRST WORD IS THE SSB ADDRESS OF THE TABLE IN
* WHICH THE SECOND WORD IS THE LOGICAL ADDRESS.

*----------+----------*
FDPFMT
+----------+----------+
!
FDPFCB
!
+----------+----------+

)00 !

SSB ADDRESS OF FILE MANAGER TABLE

)02

FCB ADDRESS

EQUATES:
LABEL
FDPSIZ

EQUATE TO

Structure Pictures

VALUE

DESCRIPTION

>04

22-58

2270512-9701

DNOS System Design Document

FDR

************************************************************

**
(FDR)
** FILE DESCRIPTION RECORD
09/09/83
*
*
*
LOCATION: DISK
*
************************************************************
* THE FDR IS THE DISK-RESIDENT FILE DESCRIPTOR TELLING WHERE
* THE FILE RESIDES, ITS CHARACTERISTICS, AND SECURITY DATA.
* SECURITY DATA IS STORED IN ACCESS CONTROL ENTRIES (ACEs)
*
** BEGINNING PACKED RECORD ACE
)00

*----------+----------*
ACEAGN!

/
/

+----------+----------+
/
/

ACCESS GROUP NAME

+----------+----------+
)08

ACEFLG

+----------+----------+

)OA SIZE

FLAGS

END OF PACKED RECORD

*
*----------+----------*

)00 !

FDRHKC

HASH KEY COUNT

+----------+----------+
)02 !

FDRHKV

+----------+----------+

)04·!

FDRFNM

+----------+----------+
/
/

)OC
)OE

/
/

HASH KEY VALUE
FILE NAME

/
/

+----------+----------+
FDRRSV

+-----~----+----------+

FDRFL1

RESERVED
FLAGS WORD 1

+----------+----------+
)10 !

FDRFLG

FLAGS WORD 2

)12

FDRPRS

PHYSICAL RECORD SIZE

FDRLRS

LOGICAL RECORD SIZE

+----------+----------+
+----------+----------+

)14 !
)16

+----------+----------+
FDRPAS

PRIMARY ALLOCATION SIZE

+----------+----------+
)18
)lA

FDRPAA

PRIMARY ALLOCATION ADDRESS

FDRSAS

SECONDARY ALLOCATION SIZE

+----------+----------+
+----------+----------+

2270512-9701

22-59

Structure Pictures

FDR

DNOS

)lC

FDRSAA

System Design Document

OFFSET OF SCONDARY TABLE

+----------+----------+
)lE !

FDRRFA

+----------+----------+

)20

FDREOM

+----------+----------+

) 22 !

RECORD NUMBER OF FIRST ALIAS
END OF MEDIUM RECORD NUMBER

+----------+----------+

)24

FDRBKM

+----------+----------+

END OF MEDIUM BLOCK NUMBER

)26

+----------+----------+
)28 !
)2A
)2C

FDROFM

+----------+----------+
FDRFBQ

+----------+----------+
+----------+----------+

)2E

END OF MEDIUM OFFSET/
PRELOG NUMBER FOR KIF
FREE BLOCK QUEUE HEAD

FDRBTR

+----------+----------+

)30!

FDREBQ

+----------+----------+

)32

B-TREE ROOTS BLOCK #
EMPTY BLOCK QUEUE

+----------+----------+
)34

FDRKDR

)36
)38

+----------+----------+
FDRUD

+----------+----------+

KEY DESCRIPTIONS RECORD #
LAST UPDATE DATE

+----------+----------+
)3A

+----------+----------+

)3C

FDRCD

CREATION DATE

+----------+----------+
)3E

+----------+----------+
)40

+----------+----------+

) 42!

FDRAPB

FDRBPA!

+----------+----------+

)44

FDRMRS

ADU'S PER BLOCK
BLOCKS PER ADU
MINIMUM KIF RECORD SIZE

+----------+----------+
)46!

FDRSAT

+----------+----------+
/
/

/
/

SECONDARY ALLOCATION TABLE

/
/

+----------+----------+
)86!

FDRRES

+----------+----------+
/
/

/
/

+----------+----------+
)90

FDRUID

Structure Pictures

RESERVED

USER ID OF FILE CREATOR

22-60

2270512-9701

DNOS System Design Document

FDR

+----------+----------+
/
/

)98

/
/

+----------+----------+"
FDRPSA

+----------+----------+
)9A

FDRACE

+----------+----------+
/
/

/
/

PUBLIC SECURITY ATTRIBUTES
9 ACCESS CONTROL ENTRIES

/
/

+----------+----------+
)A4

+----------+----------+
/
/

/
/

+----------+----------+
)AE

+----------+----------+
/
/

/
/

+----------+----------+
)B8

+----------+----------+
/
/

/
/

+----------+----------+
) C2

+----------+----------+
/
/

) CC

/
/

+----------+----------+
+----------+----------+
/
/

/
/

+----------+----------+
)D6 !

+----------+----------+
/
/

/
/

+----------+----------+
)EO

+----------+----------+
/
/

/
/

+----------+----------+
)EA

+----------+----------+
/
/

/
/

+----------+----------+
)F4

FDRFIL

+----------+----------+

2270512-9701

NOT USED

22-61

Structure Pictures

FDR

DNOS

/
/

System Design Document

/
/

+----------+----------+
FLAGS FOR FIELD: ACEFLG
ACERDF
ACEWRF
ACEDLF
ACEEXF
ACECTF

1108 -

( •• X • • • • • • • • • • • • • ) ( ••• X •••••••••••• ) ( •••• X ••••••••••• ) -

READ ACCESS FLAG
WRITE ACCESS FLAG
DELETE ACCESS FLAG
EXECUTE ACCESS FLAG
CONTROL ACCESS FLAG

( X ••••••••••••••• )

( • X •••••••••••••• )

=
=

FLAGS FOR FIELD: FDRFLI

FLAGS

IIOE -

FLAGS WORD 1

FDFSEC = (X ••••••••••••••• ) - FILE SECURED BIT
(.XXXXXXXXXXXXXXX) - RESERVED
FLAGS FOR FIELD:

FDRFLG

1110 -

FDFFU
( XX •••••••••••••• )
FDFFMT
( •• XX •••••••••••• )
FDFALL = ( •••• X ••••••••••• )
FDFFT
( ••••• XX ••••••••• )
FDFWPB
( ••••••• X •••••••• )
FDFDPB
( •••••••• X ••••••• )
FDFTMP
( ••••••••• X •••••• )
FDFBLB
( •••••••••• X ••••• )
FDFALI
( ••••••••••• X •••• )
FDFFWT
( •••••••••••• X ••• )
( ••••••••••••• XX • )
FDFCDR
( ••••••••••••••• X)

FLAGS WORD 2
FILE USAGE BITS
FILE FORMAT BITS
EXTENDABLE FILE FLAG
FILE TYPE BITS
WRITE PROTECT BI T
DELETE PROTECT BIT
TEMPORARY FILE FLAG
BLOCKED FILE FLAG
ALIAS FLAG BIT
FORCED WRITE/PARTIAL LOGGING
RESERVED
RECORD IS CDR

EQUATES:
LABEL

----FDFFUM
FDFFMM
FDFFTM
FDFUPM
FDRMNT
FDRMNP
FDRMNO
FDRSIZ
FDRMAG
FDRMNR

EQUATE TO

--------)COOO
)3000
)0600
)0180
$
$+ 1
$+2
$
9
5

Structure Pictures

VALUE

----)COOO
)3000
)600
)180
)2A

)2B
)2C
)100
)09
)05

22-62

DESCRIPTION
-------------------------~----

FILE USAGE MASK
FILE FORMAT BI TS MASK
FILE TYPE MASK
WRITE AND DELETE PROTECT MASK
MAX NUMBER OF TASKS IN PF
MAX NUMBER OF PROCEDURES
MAX NUMBER OF OVERLAYS
SIZE IN BYTES OF FDR
MAXIMUM ACCESS GROUP S ALLOWED
MAXIMUM II OF RIGHTS DEFINED

2270512-9701

DNOS System Design Document

FID

************************************************************

** FILE IDENTIFICATION
**
(FID)
02/22/80
*
**
LOCATION:
FILES
*
************************************************************
* THE FID IS USED TO IDENTIFY WITHIN A FILE ITS NAME AND
* VERSION NUMBER. THIS IS USED FOR SYSTEM FILES SUCH AS
* S$CLF AND S$SDTQUE.
*
** BEGINNING PACKED RECORD FID

*----------+----------*
FIDNAM
!
!
+----------+----------+

)OO!

/
/

)08
)OA
)OC

/
/

+----------+----------+
FIDVER
!
+----------+----------+
!
!
+----------+----------+
+----------+----------+

)OE SIZE

2270512-9701

FILE NAME

VERSION NUMBER

END OF PACKED RECORD

22-63

Structure Pictures

FIR

DNOS System Design Document

***********************************************************

** FILE INFORMATION RECORD
*
(FIR)
11/24/82
*
*
*
LOCATION: DISK
*
*
***********************************************************
* THE FIR IS USED BY THE TASKS WHICH ASSIGN, MODIFY, LIST,
* AND DELETE USER IDS. IT IS A VARIANT OF THE CAPABILITIES
* LIST FILE RECORD (CLR). FOR DETAILS SEE CLR.

Structure Pictures

22-64

2270512-9701

DNOS System Design Document

FSC

************************************************************

** FILE STRUCTURE COMMON
*
(FSC)
02/23/82 *
*
*
LOCATION: FILE MANAGEMENT TABLE AREA
*
*
**************************************************************
* THE FSC IS COMPOSED OF A COMMON FIRST STRUCTURE THAT IS
* SHARED BY BOTH THE FILE CONTROL BLOCK (FCB) AND THE FILE
* DIRECTORY BLOCK (FDB) VARIANTS OF THE REMAINDER OF THE
* STRUCTURE.
* THE FCB IS AN IN-MEMORY REPRESENTATION THAT IS USED TO
* TRACK THE CHARACTERISTICS OF A FILE THAT IS IN USE. AN FCB
* REPRESENTS THE LAST COMPONENT OF THE FILE PATHNAME.
* THE FDB IS AN IN-MEMORY STRUCTURE REPRESENTING ONE NODE
* OF THE PATHNAME OF A FILE. IT PROVIDES TREE LINKAGE FOR
* THE ENTIRE FILE PATHNAME.
*----------+----------*
)00

FSCPDT

PDT POINTER

+----------+----------+
)02

PTR TO PARENT'S DIRECTORY DOOR

FSCPDR

+----------+----------+
)04

FSCEOM

END OF MEDIUM LOGICAL REC #

+----------+----------+
)06

+----------+----------+
)08
)OA

FSCAPB

FSCBPA!

+----------+----------+
FSCPAS

ADUS PER BLOCK
BLOCKS PER ADU
PRIMARY ALLOCATION SIZE

+----------+----------+
)OC

FSCPAA

+----------+----------+
)OE

FSCSAA

PRIMARY ALLOCATION ADDRESS
SAT ADDRESS

+----------+----------+
)10

PHYSICAL RECORD SIZE

FSCPRS

+----------+----------+
)12

FDR ADU OF THIS FILE

FSCADU

+----------+----------+
)14

FSCOFF

FSCMFG

+----------+----------+

FDR OFFSET WITHIN ADU
MODIFIED ONLY FLAGS

FCB -

*----------+----------*
FCBFCB

)16

+----------+----------+
FCBRPB

)18 !
)lA

+----------+-------~--+

FCBCCT

FCBFLB

+----------+----------+
)lC
2270512-9701

FCBSGB

FILE CONTROL BLOCK VARIANT

LINK FOR CONCATENATED FILES
START OF RPB CHAIN
COUNT OF CONCATENATED FILES
FLAGS BYTE
SGB ADDRESS

22-65

Structure Pictures

FSC

)lE

DNOS System Design Document

+----------+----------+
FCBSMT

+----------+----------+

SM TABLE AREA SSB OF SGB

)20 !

FCBFLG

FILE FLAGS

)22

FCBFDB

POINTER TO DIRECTORY ENTRY

+----------+----------+
+----------+----------+

)24
)26

FCBSFD

+----------+----------+
FCBLRS

LOGICAL RECORD SIZE

FCBSAS

SECONDARY ALLOCATION SIZE

+----------+----------+

)28

+----------+----------+
)2A

SSB OF DIRECTORY ENTRY

FCBBKM

+----------+----------+

)2C !

END OF MEDIUM BLOCK #

+----------+----------+

)2E !

FCBOFM

+----------+----------+
)30 !

FCBLRL

)32 !

FCBEXT

+----------+----------+

END OF MEDIUM OFFSET
LOCKED RECORD LIST HEAD
BLOCK COUNT FOR FILE EXTENT

)34

+----------+----------+

)36!

FCBXCT

FCBCLA!

+----------+----------+

)38

FCBRLA

+----------+----------+

)3A

FCBCPO

FCBCAW!

+----------+----------+
)3C

*----------+----------*
FCBEBQ

+----------+----------+

FILE EXTENSION COUNT
COUNT OF THINGS POINTING HERE
REQUEST LIST ANCHOR
COUNT OF PASSIVE OPERATIONS
COUNT OF ACTIVE WAITERS

EMPTY BLOCK QUEUE

)3E !

+----------+----------+

)40 !

FCBCLB

+----------+----------+

)42!
)44
)46

FCBFBQ

+----------+----------+

)4A

FREE BLOCK QUEUE HEAD

+----------+----------+
FCBBTR

+----------+----------+
)48

CURRENT LOG BLOCK #

FCBSBB

+----------+----------+
FCBMRS

+----------+----------+

)4C

FCBKDB

+----------+----------+
/

Structure Pictures

B-TREE ROOTS BLOCK #
STARTING BUCKET BLOCK #
MINIMUM KIF RECORD SIZE
KEY DESCRIPTIONS BLOCK

/
22-66

2270512-9701

FSC

DNOS System Design Document

+----------+----------+
)3C

*----------+----------*

FCBMNT
FCBTO
+----------+--~-------+
)3E
FCBTR

MAXIMUM NUMBER OF TASKS
TASK DIRECTORY ENTRY OFFSET
TASK DIRECTORY ENTRY RECORD #

) 40!

MAXIMUM NUMBER OF PROCEDURES
PROC DIRECTORY ENTRY OFFSET
PROC DIRECTORY ENTRY RECORD #

+----------+----------+

)42
)44
)46

FCBMNP

FCBPO

+----------+-----~----+

FCBPR

+----------+----------+
FCBMNO
FCBOO
+----------+----------+
!
FCBOR
+----------+----------+

MAXIMUM NUMBER OF OVERLAYS
OVERLAY DIRECTORY ENTRY OFFSET
OVERLAY DIRECTORY ENTRY RECORD

FDB -

*----------+----------*
)16 !
FDBRNM
!
+----------+----------+
)18
FDBDDR
+----------+----------+
)IA!
FDBFNM
!
+----------+----------+
/
/

/
/

2270512-9701

RECORD NUMBER OF FDR
ADDRESS OF DIRECTORY DOOR (DDR)
FILE NAME

/
/

+----------+----------+
FDBFCB
!
+----------+----------+
) 24!
FDBCDF
FILL02
+----------+----------+
)26
FDBAFD
!
+----------+----------+
)28 !
FDBSAF
!
+----------+----------+
)2A
FDBALS
!
+----------+----------+
)2C
FDBSAL
!
+----------+----------+
)2E
FDBANS
+----------+----------+
)30
FDBSAN
!
+----------+----------+
)32 !
FDBAPF
+----------+----------+
)34
FDBSAP
+----------+----------+
)36 !
FDBFMT
!
+----------+----------+
)22

FILE DIRECTORY BLOCK VARIANT

ADDRESS OF FCB ANCHOR
COUNT OF DESCENDANTS
RESERVED
ADDRESS OF FIRST DESCENDANT (AFD)
SSB ADDRESS FOR AFD
ADDRESS OF LAST SIBLING (ALS)
SSB ADDRESS FOR ALS
ADDRE S S OF NEXT SIBLING (ANS)
SSB ADDRESS FOR ANS
ADDRESS OF PARENT FILE (APF)
SSB ADDRESS FOR APF
SSB ADDRESS FOR THIS FDB

22-67

Structure Pictures

FSC

DNOS System Design Document

FLAGS FOR FIELD:

FSCMFG

#15 - MODIFIED ONLY FLAGS

FSCMEC = (X •••••••••••••••
FSCMWT = (.X ••••••••••••••
FSCFUI
( •• XX ••••••••••••
FSCDEL
( •••• X •••••••••••

1 = END OF MEDIUM HAS CHANGED
1 = FILE HAS BEEN WRITTEN IN
) - FILE USAGE BIT ONE
) - FDB DELETE PROTECTION FLAG
) -

)

*
*
FLAGS FOR FIELD:

FCBFLB

#IB -

FCBFCC = ( X •••••••••••••••
FCBFUB = ( • X ••••••••••••••
FCBBSY
( •• X •••••••••••••
FCBFSE = ( ••• X ••••••••••••
FLAGS FOR FIELD: FCBFLG

*
*
*
*
*
*
*
*
*
*
*

)
)
)
)

FCBFDF

( •• XX •••••••••••• )

FCBFAT
( •••• X ••••••••••• )
FCBFFT = ( ••••• XX ••••••••• )

FCBFWP
FCBFDP
FCBFTF
FCBFBF
FCBFAF
FCBFFW
FCBFSC
FCBPLG
RESER

FILE IS IN CONCATENATION
OPEN MUST BE UNBLOCKED
FCB IS BUSY
SUPPRESS EOF BEFORE EOM

#20 -

FCBFFU = ( XX •••••••••••••• )

( ••••••• X •••••••• )
( •••••••• X ••••••• )

( ••••••••• X •••••• )
( •••••••••• X ••••• )

( ••••••••••• X •••• )

( •••••••••••• X ••• )
( ••••••••••••• X •• )
( •••••••••••••• X. )
( ••••••••••••••• X)

FLAGS BYTE

FILE FLAGS
FILE USAGE FLAGS
00 = NO SPECIAL USAGE
DIRECTORY
01
PROGRAM
10
11 = IMAGE
DATA FORMAT
00
NON-BLANK SUPPRESSED
01 = BLANK SUPPRESSED
10 & 11 = RESERVED
EXPANDABLE IF ON
FILE TYPE
RESERVED (FOR DEVICE)
00
SEQUENTIAL
01
10 = RELATIVE RECORD
11
KEY INDEXED
WRITE PROTECTED IF ON
DELETE PROTECTED IF ON
TEMPORARY FILE IF ON
BLOCKED FILE IF OFF
ALIAS ENTRY IF ON
FORCED WRITE IF ON
FILE SECURITY
FILE MARKED AS PARTIAL LOGGING
RESERVED

EQUATES:
LABEL
FSCFU2
FSCFUM
FSCSIZ

EQUATE TO
FSCFUl+1
)3000
$

Structure Pictures

VALUE
)03
)3000
)16
22-68

DESCRIPTION
FILE USAGE BIT TWO
FILE USAGE MASK
FSC SIZE
2270512-9701

DNOS System Design Document

FCBFFM
FCBFAM
FCBFTM
FCBMSZ
FCBSIZ
FCBPSZ
FCBPDT
FCBPDR
FCBEOM
FCBAPB
FCBBPA
FCBPAS
FCBPAA
FCBSAA
FCBPRS
FCBADU
FCBOFF
FCBMFG
FCBMEC
FCBMWT
FDBMSZ
FDBPDT
FDBPDR
FDBEOM
FDBAPB
FDBBPA
FDBPAS
FDBPAA
FDBSAA
FDBPRS
FDBADU
FDBOFF
FDBMFG
FDBMEC
FDBMWT
FDBFUI
FDBFU2
FDBFDL

2270512-9701

)COOO
)3000
)0600
$
$
$
FSCPDT
FSCPDR
FSCEOM
FSCAPB
FSCBPA
FSCPAS
FSCPAA
FSCSAA
FSCPRS
FSCADU
FSCOFF
FSCMFG
FSCMEC
FSCMWT
$
FSCPDT
FSCPDR
FSCEOM
FSCAPB
FSCBPA
FSCPAS
FSCPAA
FSCSAA
FSCPRS
FSCADU
FSCOFF
FSCMFG
FSCMEC
FSCMWT
FSCFUI
FSCFU2
FSCDEL

FSC

)COOO
)3000
)600
)3C
)86
)48
)00
)02
)04
)08
)09
)OA
)OC
)OE
)10
)12
)14
)15
)00
)01
)38
)00
)02
)04
)08
)09
)OA
)OC
)OE
)10
)12
)14
)15
)00
)01
)02
)03
)04

FILE USAGE FLAGS MASK
FILE FORMAT FLAGS MASK
FILE TYPE FLAGS MASK
MIN FCB SIZE
MAX FCB SIZE
PROGRAM FILE FCB SIZE
PDT ADDRESS
PTR TO PARENT'S DIRECTORY DOOR
END OF MEDIUM LOGICAL REC. #
ADUS PER BLOCK
BLOCKS PER ADU
PRIMARY ALLOCATION SI.ZE
PRIMARY ALLOCATION ADDRESS
SAT ADDRESS
PHYSICAL RECORD SIZE
FDR ADU FOR THIS FILE
FDR OFFSET WITHIN ADU
MODIFIED ONLY FLAGS
1= EOM HAS CHANGED
1= FILE WAS WRITTEN IN
FDB SIZE
PDT ADDRESS
PTR TO PARENT'S DIRECTORY DOOR
END OF MEDIUM LOGICAL REC. #
ADUS PER BLOCK
BLOCKS PER ADU
PRIMARY ALLOCATION SIZE
PRIMARY ALLOCATION ADDRESS
SAT ADDRESS
PHYSICAL RECORD SIZE
FDR ADU FOR THIS FILE
FDR SECTOR OFFSET IN ADU
MODIFIED ONLY FLAGS
1 = EOM HAS CHANGED
1 = FILE WAS WRITTEN IN
FILE USAGE BIT ONE
FILE USAGE BIT TWO
FDB DELETE PROTECTION FLAG

22-69

Structure Pictures

FWA

DNOS System Design Document

************************************************************

** FILE MANAGER WORK AREA
(FWA)
01/21/82
**
*
*
LOCATION: SYSTEM AREA
*
*************************************************************
* THE FWA IS USED BY FILE MANAGEMENT AND BY KIF MANAGEMENT
* AS A GENERAL WORK AREA. R15 POINTS TO THE FWA.

*----------+----------*
FWAWP
+----------+----------+

)OO!

/
/

WORKSPACE USED BY FM

/
/

+----------+----------+
FWAFLG
!
+----------+----------+
!
FWATCT
!
+----------+----------+
!
FWAOAD
f
+----------+----------+
!
FWAPC
+----------+----------+
!
FWAXWP
!
+----------+----------+
FWAXPC
+----------+----------+
!
FWABN
!
+----------+----------+
!
+----------+----------+
FWAOCB
!
+----------+----------+
FWALFG
!
+----------+----------+
FWAFFC
+----------+----------+
!
FWAFMT
!
+----------+----------+
!
FWAFCB
+----------+----------+
FWABST
+----------+----------+
FWABSB
+----------+----------+
FWAPRS
+----------+----------+
FWAUBT
+----------+----------+
FWAUBS
+----------+----------+

)20 f

MIDDLE SEGMENT FLAGS

)22

MULTIRECORD CHARS TRANSFERRED

)24
)26
) 28
)2A
)2C
)2E
)30
)32
)34
)36
)38
)3A
)3C
)3E
)40
)42

Structure Pictures

CURRENT OVERLAY AREA ADDRESS
SAVED PROGRAM COUNTER
BLWP VECTOR FOR RETURNING

SAVED RPBBN (2 WORDS)

SAVED RPBOCB
SAVED LDT FLAGS
FIRST FCB FOR CC FILES
SSB FOR THE FMT WITH THE FCB
FCB ADDRES S IN THE FMT
SMT SSB ADDR FOR BUFFER
SSB ADDR FOR BUFFER
PHYSICAL RECORD SIZE
USER BUFFER SMT SSB ADDR
USER BUFFER SSB ADDRESS

22-70

2270512-9701

DNOS System Design Document

)44

FWA

FWAUBO

USER BUFFER OFFSET

+----------+----------+
)46
FWAUBL
+----------+----------+
)48
FWAFMB
+----------+----------+
)4A !
FWARN1
!
+----------+----------+
)4C !
FWARN2
!
+----------+----------+
)4E
FWAOOB
+----------+----------+
)50 !
FWAUBR
!
+----------+----------+
)52
FWAFFG
+----------+----------+
)54!
FWASTK
!
!
+----------+----------+
/
/

/
/

USER BUFFER LENGTH
FMT BIAS
RECORD # RELATIVE TO CURRENT
FILE OF CONCATENATED SET
OLD OFFSET IN USER BUFFER
BUFFER LENGTH REMAINING
FILE MGR FLAGS
STACK AREA

/
/

+----------+----------+
FLAGS FOR FIELD: FWAFFG
FWAPOP
FWAQW

#52 -

FILE MGR FLAGS

- PASSIVE OPERATION FLAG
(.X .•.•.••.•..•.. ) - QUEUED TO WAITING QUEUE IN FeB
(x ••..•.•..•.•••. )

EQUATES:
LABEL
FWASIZ

2270512-9701

EQUATE TO

VALUE
)F4

22-71

DESCRIPTION
SIZE OF FWA INCLUDING WSP

Structure Pictures

IRB

DNOS System Design Document

************************************************************

*
*
*
LOCATION: SYSTEM TABLE AREA AND JCA
*
*
*
*
************************************************************

*
*
*
*
*
*
*
*
*
*
*

I/O REQUEST BLOCK

(IRB)

09/09/83*

THE IRB TEMPLATE HAS FOUR MAJOR VARIANTS.
ONE OF THESE IS
THE SIMPLE CALL BLOCK FOR RESOURCE INDEPENDENT I/O. ONE
HAS EXTENSIONS FOR VDT DEVICES.
ANOTHER IS THE CALL
BLOCK USED FOR I/O UTILITY CALLS.
IT INCLUDES INTERNAL
VARIANTS FOR REMOTE I/O HANDLING AND FOR LOGICAL NAME
SEGMENT HANDLING.
THERE IS ALSO A SET OF EQUATES USED BY
THE CODE WHICH CREATES PROGRAM FILES.
EQUATES FOR SPECIAL
PURPOSES IN CREATING KEY INDEXED FILES AND FOR REFERENCE
TO SPECIAL APPLICATIONS OF THE BASIC I/O BLOCK ARE IMBEDDED
IN THE TEMPLATE WHERE THE ORIGINAL FIELDS ARE DEFINED.
A FINAL VARIANT IS USED FOR FILE I/O CALL BLOCKS.

*------

* NOTE THAT FOR DUPLICATE LABELS, THE PREFERRED USAGE IS
* STARRED IN THE COMMENT COLUMNS.
** BEGINNING PACKED RECORD IRB

)00
)02

)04

*----------+----------*
IRBSOC
IRBEC
+----------+----------+
IRBOC
IRBLUN
+----------+----------+
IRBSFL
IRBUFL
+----------+----------+

SUPERVISOR REQUEST CODE
*REQUEST ERROR CODE
*SUB-OPERATION CODE
LOGICAL UNIT
*SYSTEM FLAGS
REQUESTOR (USER) FLAGS

RESOURCE-INDEPENDENT I/O VARIANT

)06
)08
)OA

*----------+----------*
!
IRBDBA
+----------+----------+
!
IRBICC
+----------+----------+
!
IRBOCC
+----------+----------+

*DATA BUFFER ADDRESS
*INPUT CHAR COUNT / ACTUAL OUTPUT
*OUTPUT CHAR COUNT / ACTUAL INPUT

FILE I/O VARIANTS
*----------+----------*
CURRENCY BLOCK ADDRESS
)OC
IRBCBA

+----------+----------+

)OC
)OE

*----------+----------*
IRBRNI
+----------+----------+
+----------+----------+

Structure Pictures

RELATIVE RECORD NUMBER

22-72

2270512-9701

DNOS

System Design Document

)10

IRB

FILL01

+----------+----------+
DIAGNOSTIC PORT VARIANT

*----------+----------*
)OC
)OE

IRBVRS

IRBOLF

+----------+----------+
IRBPCD

OS VERSION/RELEASE
ONLINE FLAGS
DYNAMIC PASS CODE

+----------+----------+
DIRECT DISK I/O
)OC

*----------+----------*
IRBADU

ADU ADDRESS

+----------+----------+
)OE

IRBOFF

SECTOR OFFSET

+----------+----------+
*----------+----------*
)OC

IRBTRK

TRACK ADDRESS

+----------+----------+
)OE

IRBSPR

IRBSCT

+----------+----------+

SECTORS PER RECORD
SECTOR

SUBOPCODE )18 VARIANT
)OC

*----------+----------*
IRBDKS

TPCS (RO) DISK STATUS FOR )18

+----------+----------+
)OE

IRBCRS

TPCS (R7)

CONTROLLER STAT FOR )18

+----------+----------+
TERMINAL DEVICE I/O VARIANTS

*----------+----------*
)OC

IRBRPY

REPLY BLOCK ADDRESS

+----------+----------+
)OE

IRBXFL

EXTENDED REQUEST FLAGS

+----------+----------+
)10

IRBFCH

IRBEVT

+----------+----------+
)12

IRBCRO

IRBCCO!

+----------+----------+
)14

IRBFRO

IRBFCO

+----------+----------+

VDT FILL CHARACTER
VDT EVENT BYTE
VDT CURSOR IN FIELD ROW
VDT CURSOR IN FIELD COLUMN
VDT FIELD BEGINNING ROW
VDT FIELD BEGINNING COLUMN

*----------+----------*
)OC

IRBVTA

VALIDATION TABLE ADDRESS

+----------+----------+
I/O UTILITY VARIANT

*----------+----------*
)06

IRBTYP

IRBTFL

+----------+----------+

2270512-9701

RESOURCE TYPE
RESOURCE TYPE FLAGS

22-73

Structure Pictures

DNfrS System Design Document

IRB

)08
)OA
)OC
)OE
)10
)12
)14
)16
)18
) 1A
)lC
)lE
)20
)22

IRBJSB

OWNER JSB ADDRESS (IOU SVC )A5)

+----------+----------+
IRBTSB
!
+----------+----------+
IRBKDB
+----------+----------+
!
FILL04
!
+----------+----------+
IRBFLG
+----------+----------+
!
IRBDLL
+----------+----------+
!
IRBDPL
!
+----------+----------+
!
IRBPNA
+----------+----------+
!
IRBPRM
+----------+----------+
!
IRBRES
!
+----------+----------+
!
IRBIFA
+----------+----------+
+----------+----------+
IRBSFA
+----------+----------+
!
+----------+----------+

OWNER TSB ADDRESS (IOU SVC )AS)
KEY DESCRIPTOR ADDRESS/OVERLAYS

IRBA

OVERLAYS IRBOFF
UTILITY FLAGS (2 BYTES)
DEFINED LOGICAL

RECORD LENGTH

DEFINED PHYSICAL RECORD LENGTH
PATHNAME ADDRESS
PARAMETER POINTER
RESERVED
INITIAL FILE ALLOCATION (2 WORDS)

SECONDARY FILE ALLOCATION (2 WORDS)

IOU VARIANT FOR LOGICAL NAME SEGMENT
*----------+----------*
)24
IRBSTG!
IRBNMF
TASK STAGE NUMBER
NAME MANAGER FLAGS
)26 !
IRBRPN
!
REDIRECTED RESOLVED PATHNAME
EQUATES FOR CREATE PROGRAM FILE VAR
)28 SIZE
** END OF PACKED RECORD

+----------+----------+
+----------+----------+

FLAGS FOR FIELD:

IRBSFL

#04 -

IRFBSY = (X •••••••••••••••
IRFERR = (.X ••••••••••••••
IRFEOF = ( •• X •••••••••••••
IRFVNT
( ••• X ••••••••••••

- BUSY
) - ERROR
) - END OF FILE
) - EVENT CHAR
)

( •••• XXX ••••••••• )

IRFMDT

( ••••••• X•••••••• ) - MODIFIED DATA TAG (OPCODE )17)

FLAGS FOR FIELD:
IRFINT
IRFRPY

*SYSTEM FLAGS

IRBUFL

#05 -

(X ••••••••••••••• )
( • X •••••••••••••• )

Structure Pictures

22-74

REQUESTOR (USER) FLAGS
INITIATE REQUEST
0 U T PUT WIT H RE PLY

2270512-9701

DNOS System Design Document

IRFSAR
( •• X ••••••••••••• )
IRFACC = ( ••• XX ••••••••••• )

IRFLOC
IRFOWN

SECURITY ACCESS RIGHTS (OP CODE )5)
ACCESS PRIVILEGES
OO=EXCLUSIVE WRITE
01=EXCLUSIVE ALL
10=SHARED
11 =READ ONLY
( ••••• X •••••••••• )
*LOCK/UNLOCK
OWNERSHIP LEVEL
( •••••• XX •••••••• )

*
*
*
*

FLAGS FOR FIELD:
*

IRB

IRBOLF

HOD - ONLINE FLAGS

OLDBFR = (X •••••••••.••••• ) - BUFFER ADDRESS SPECIFIED
O=NO BUFFER IN TIL. IMAGE
I=BUFFER IN TILINE IMAGE
(.XXXXXXX •••••••• ) - RESERVED (SET TO 0)
FLAGS FOR FIELD:
IRFCSF
IRFNTN
IRFFKR
IRFGRA
IRFEBA
IRFTER
IRFBP
IRFRDB
IRFCIF
IRFFC
IRFIF
IRFRFF
IRFECO
IRFVRQ
IRFVER
IRFWBP

IRBXFL

HOE -

= ( X ••••••••••••••• )
( • X •••••••••••••• )
= ( •• X ••••••••••••• )
( ••• X •••••••••••• )
•••• X ••••••••••• )

= (
(
= (
(
= (
(
(
= (
= (

••••• X ••••••••••
•••••• X •••••••••
••••••• X ••••••••
•••••••• X •••••••
••••••••• X ••••••
•••••••••• X •••••
••••••••••• X ••••
•••••••••••• X •••

( •• ,. •••••••••• X •• )

( •••••••••••••• X. )
( ••••••••••••••• X)

FLAGS FOR FIELD:

IRBTFL

FLAGS FOR FIELD:

IRBFLG

CURSOR START OF FIELD DEFN
INTENSITY
BLINKING CURSOR (FLICKER)
GRAPHICS DISPLAY(CHAR LT )20)
8-BI T ASCII
ENABLE TASK EDIT CHAR RETURN
BEEP
RIGHT DISPLAY EDGE BOUNDARY
CURSOR IN-FIELD DEF INED
FILL CHAR DEF I NED
INITIALIZE FIELD
REMAIN IN FULL FIELD
ECHO
VALIDATION REQUIRED
VERIFICATION ERROR
WARNING BEEP

#07 - RESOURCE TYPE FLAGS

( XXX •••••••••••••
IRFVD
( ••• X ••••••••••••
IRFREM = ( •••• X •••••••••••
( ••••• X ••••••••••
IRFCHN
IRFDEV
( •••••• X •••••••••
( ••••••• X ••••••••
IRFFIL

)
)
)
)
)
)
)
)

EXTENDED REQUEST FLAGS

) - RESERVED
) - VIRTUAL DEVICE
) - REMOTE CHANNEL
) - CHANNEL
) - DEVICE
) - FILE

#10 -

UTILITY FLAGS (2 BYTES)

IRFFCA
(X ••••••••••••••• ) - FILE CREATED BY ASSIGN
I RFFU 1 = (. XX ••••••••••••• ) - FI LE USAGE FLAG S
OO=NO SPECIAL USAGE

2270512-9701

22-75

Structure Pictures

IRB

*
*
*
*
*
*
*

*
*
*

DNOS System Design Document

IRFSC1

( ••• XX ••••••••••• )

IRFGEN
( ••••• X••••••••••
( •••••• X•••••••••
IRFACR
IRFPRM
( ••••••• x ••••••••
IRFLRL = ( •••••••• X•••••••
( ••••••••• X ••••••
IRFTMP
IRFIMW = ( •••••••••• X•••••
IRFDF1 = ( ••••••••••• xx •••

IRFALL
IRFFT1

)
)

)
)
)

)

( ••••••••••••• X •• )

( •••••••••••••• XX)

*
*
*
*
FLAGS FOR FIELD: IRBNMF
IRFRID
IRFNM1

01=DIRECTORY FILE
10=PROGRAM FILE
11=IMAGE FILE
- LUNO SCOPE
OO=TASK LOCAL
01=JOB LOCAL
10=GLOBAL
11=SHARED
- AUTOGENERATELUNO
- REQUEST AUTOCREATE FILE
- l=IRBPRM VALID (PARMS PRESENT)
- I=VALID LOGICAL RECORD LENGTH
- FILE IS TO BE TEMPORARY
- IMMEDIATE WRITE DISK FILES
- DATA FORMAT
OO=NORMAL RECORD IMAGE
01=BLANK SUPPRESSED
10,11 RESERVED
- ALLOCATION MAY GROW
- FILE TYPE
OO=RESERVED
01=SEQUENTIAL FILE
10=RELATIVE RECORD FILE
11=KEY INDEXED FILE

#25 - ,NAME MANAGER FLAGS

- USE SPECIFIED RUN ID
(.XXXXXXX •••••••• ) - RESERVED AT PRESENT

(x •••.•••••••.••• )

EQUATES:
LABEL
IRBERR
IRBOP
IRBSFG
IRFVAL
IRFKFG
IRFBFI
IRFRES
IRFAC1
IRFRLN
IRFACM
IRFOS
IRFOSF
IRFMDS
IRFLFG
IRFTIH
IRFIMO
IRFPAS

EQUATE TO
IRBEC
IRBOC
IRBSFL
IRFRPY
IRFRPY
IRFRPY
IRFSAR
IRFACC+1
IRFACC
)0018
IRFACC
IRFACC+1
IRFLOC
IRFLOC
IRFLOC
IRFLOC
IRFLOC

Structure Pictures

VALUE
)01
)02
)04
)01
)01
)01
)02
)04
)03
)18
)03
)04
)05
)05
)05
)05
)05
22-76

DESCRIPTION
REQUEST ERROR CODE
SUB-OPERATION CODE
SYSTEM FLAGS
READ WITH VALIDATION
KEY SPECIFIES FLAG
BUFF HAS WRITE INTERLEAVED FMT
ACCESS PRIVILEGES
MASTER RESOLVE LOGICAL NAMES
ACCESS PRIV. BIT MASK
READ BY TRACK/OFFSET ENABLED
READ BY TRACK/OFFSET FORWARD
MASTER DO NOT SUSPEND
LOCK/UNLOCK
READ BY TRACK/TRANSFER INHIBIT
IMMEDIATE OPEN FLAG FOR TPD
PASS THRU MODE FOR COMM DSRS
2270512-9701

DNOS System Design Document

IRFEXR
IRFBAD
IRFBFG
IRFWPM
IRFRTY
VARNT1
IRBRLN
IRBLRL
IRBCHT
IRBCMD
IRBHD
VARNT2
IRBCYL
IRBRN2
IRBFWA
IRBRT
IRBLRN
IRBPRS
IRFFU2
IRFFUM
IRFSC2
IRFSCM
IRFDF2
IRFDFM
IRFFT2
IRFFTM
IRBIF2
IRBRCS
VARNT3
IRBMXT
IRBMXP
IRBMXO

2270512-9701

IRFOWN
IRFOWN+1
IRFBAD
IRFOWN+1
IRFOWN+1
$
IRB I CC
IRBICC
IRBOCC
IRBOCC
IRBOCC+1
$
IRBRN1
IRBRN1+2
$
IRBXFL
IRBKDB
IRBKDB
IRFFU1+1
)6000
IRFSC1+1
)1800
IRFDF1+1
)0018
IRFFT1+1
)0003
IRBIFA+2
$
$
IRBRPY+1
IRBXFL
IRBXFL+1

IRB

)06
)07
)07
)07
)07
)06
)08
)08
)OA
)OA
)OB
)OC
)OC
)OE
)10
)OE
)OC
)OC
)02
)6000
)04
)1800
)OC
)18
)OF
)03
)lE

)24
)24
)OD
)OE
)OF

22-77

EXTENDED REQUEST
*BLANK ADJ/SET EVENT MODE
BLANK ADJ/SET EVENT MODE
WORD PROCESSING MODE
READ BY TRACK WITH NO RETRIES
RECORD LENGTH
LOGICAL RECORD LENGTH
OUTPUT CHARACTER COUNT
COMMAND FOR SUBOPCODE )18
HEAD # FOR SUBOPCODE )18
CYLINDER ADDRESS FOR SUBOP )18
SECOND WORD OF RECORD NUMBER
POINTER TO FILE WORK AREA
RESOURCE TYPE/TYPE FLAGS FOR CC
LOGICAL RECORD NUMBER
PHYSICAL RECORD SIZE (DIR OVHD.)
FILE USAGE FLAGS
FILE USAGE BIT MASK
LUNO SCOPE
LUNO SCOPE BIT MASK
DATA FORMAT
DATA FORMAT BIT MASK
FILE TYPE
FILE TYPE BIT MASK
INITIAL FILE ALLOCATION (2ND WORD:
REQUESTOR CALL BLOCK SIZE
MAXIMUM NUMBER TASKS IN PROG FILE
MAX NUMBER PROCS IN PROG FILE
MAX NUMBER OVERLAYS IN PROG FILE

Structure Pictures

DNOS System Design Document

JIT

************************************************************

** JOB INFORMATION TABLE
*
(JIT)
01/23/80
*
*
*
LOCATION: JCA
*
*
************************************************************
* THE JIT DESCRIBES THE JOB COMMUNICATION AREA (JCA) CONTENTS
* AND IS FOUND AT THE ADDRESS JCASTR (FOUND IN NFPTR) IN
* EACH JOB. IT INCLUDES DESCRIPTIVE INFORMATION ABOUT THE
* JOB AND POINTERS TO MANY JOB-LOCAL STRUCTURES IN THE JCA.
* (NOTE THAT JITOVB MUST BE ON A BEET BOUNDARY.)
)00
)02
)04
)06
)08
)OA
)OC
)OE
)10
)12
)14
) 16
)18
)1A
)1C
)1E
)20
)22
)24

*----------+----------*
JITHED
!
+----------+----------+
JITLNK
!
+----------+----------+
JITRES
+----------+----------+
JITEND
+----------+----------+
JITUSE
+----------+----------+
!
JITHI
!
+----------+----------+
JITPTR
+----------+----------+
JITCAP
+----------+----------+
JITSEM
+----------+----------+
!
JITLDT
!
+----------+----------+
JITIOC!
JITLUN
+----------+----------+
JITTYP!
JITTF
+----------+----------+
JITFLG
+----------+----------+
!
JITRLK
!
+----------+----------+
!
JITOTS
+----------+----------+
JITJSB
+----------+----------+
JITPRM
+----------+----------+
JITROB
+----------+----------+
JITCCB
+----------+----------+

Structure Pictures

SYSTEM TABLE AREA OVERHEAD
STA -

LINK TO FIRST BLOCK

STA -

RESERVE LIMIT

STA -

END OF AREA

STA -

TOTAL BYTES USED

STA - HIGHEST ADDR USED
POINTER TO JSB OF JCA OWNER
POINTER TO CAPABILITY LIST
POINTER TO SEMAPHORE LIST
JOB LOCAL LDT -

LDT LINK

LDT - INITIATE I/O COUNT
LDT - LUNO
LDT - RESOURCE TYPE
LDT - RESOURCE FLAGS
LDT - LDT FLAGS
LOT -

RESOURCE LINK

LDT -

OWNER TSB

LOT -

OWNER JSB

LOT -

PARAMETER LIST

POINTER TO RESOURCE OWNER BLK
POINTER TO CHANNEL CONTROL BLK

22-78

2270512-9701

DNOS System Design Document

)26

JIT

JITPAS

+----------+----------+
/
/

/
/

PASSWORD FOR USER ID

/
/

+----------+----------+
)2E

JITACC

ACCOUNT ID

+----------+----------+
/
/

/
/

+----------+----------+
)3E

JITPVL

JITLID

+----------+----------+
)40

JITTID

+----------+----------+
/
/

/
/

USER PRIVILEGE LEVEL
LAST TASK ID GIVEN
TSB RUN TIME ID BIT MAPS

/
/

+----------+----------+
)60

JITJBI

+----------+----------+
)62

JITFTB

POINTER TO FM TSB

JITFLK

FORWARD TOL LINK FOR FM

+----------+----------+

)64

+----------+----------+
)66

JITBLK

+----------+----------+

)68

SEGMENT ID OF JCA

JITFTP

BACKWARD TOL LINK FOR FM
FM TASK TYPE <)0100)

+----------+----------+
)6A !

JITFJB

+----------+----------+

)6C

FILLOO!

+----------+----------+
/
/

/
/

POINTER TO FM JSB
FILLER FOR DUMY OV B

/
/

+----------+----------+
)80

JITFMQ

+----------+----------+
/
/

/
/

FM QUEUE FOR JOB

/
/

+----------+----------+
)8C

JITEXC

+----------+----------+

EXECUTION TIME SINCE LOAD

)8E

+----------+----------+
)90

FILL01

+----------+----------+
)92

JITWOT

+----------+----------+
)94

FILL02

CURRENTLY UNUSED
TABLE AREA WAIT QUEUE
RESERVED AT PRESENT

+----------+----------+
)96

JITSSI

+----------+----------+
)98

JITSSS

+----------+----------+

2270512-9701

SYNONYM SEGMENT RUN ID
SYNONYM SEGMGR TAB AREA SSB

22-79

Structure Pictures

JIT

DNOS System Design Document

)9A

JITSSB

SYNONYM SSB ADDRESS

+----------+----------+
)9C

JITRST

+----------+----------+

)9E

JITTSB

+----------+----------+
)AO

JITACT

PTR TO RESERVE SEGMENT TABLE
POINTER TO TSB TREE
POINTER TO ACTIVE TSBS

+----------+----------+
)A2

JITWOM

+----------+----------+

)A4

JITFMW

+----------+----------+
/
/

/
/

POINTER TO WOM TSBS
FILE MGR WORKING WP & STACK

/
/

+----------+----------+
)E2

JITINS

+----------+----------+
/
/

/
/

INSTALL TASK QUEUE HEADER

/
/

+----------+----------+
)EE

JITDEL

+----------+----------+
/
/

/
/

DELETE TASK QUEUE HEADER

+----------+----------+
)FA

JITASP

+----------+----------+
/
/

/
/

ASSIGN SPACE QUEUE HEADER

/
/

+----------+----------+
)0106

JITMAP

+----------+----------+
/
/

/
/

MAP NAME TO ID QUEUE HEADER

/
/

+----------+----------+
)0112

JITINV

+----------+----------+
/
/

)OllE

/
/

+------~---+----------+

JITRCP

INITIALIZE NEW VOLUME QUEUE

RETURN CODE PROCESSOR QUEUE

+----------+----------+
/
/

/
/

+----------+----------+
EQUATES:
LABEL
JITOVB
JITSIZ

EQUATE TO

VALUE

)60

)12A

Structure Pictures

22-80

DESCRIPTION

2270512-9701

DNOS System Design Document

JMR

***********************************************************

** JOB MANAGEMENT REQUEST
*
(JMR)
04/28/79 *
*
LOCATION:
SYSTEM TABLE AREA
*
*
*
***********************************************************
* THE JMR IS A DESCRIPTION OF A JOB MANAGEMENT SVC BLOCK.
* IT IS USED WITHIN JOB MANAGMENT TO SCAN THE USER'S SVC
* REQUEST.
)00
)02
)04
)06
)08

*----------+----------*
JMRSVC
JMRERR
+----------+----------+
JMROP
JMRPRI!
+----------+----------+
JMRFLG
+----------+----------+
JMRJID
+----------+----------+
JMRNAM
+----------+----------+
/
/
/
/

+----------+----------+
JMRTID
JMRSSZ
+----------+----------+
) 12!
JMRPRM
+----------+----------+
)14 !
+----------+----------+
)16
JMRSID
JMRPFL
+----------+----------+
)18 !
JMRSYN
+----------+----------+
)lA
JMRLNM
+----------+----------+
)lC
JMRUID
+----------+----------+
/
/
/
)24

JOB ID
USER SPECIFIED JOB NAME

)10!

SVC CODE
(48)
ERROR CODE
JOB MANAGER SUBOPCODE
JOB PRIORITy
JOB MANAGER CONTROL FLAGS

TASK ID OF INITIAL TASK
SIZE OF JCA
1,2,3
TASK BID PARAMETERS

STATION ID OF TASK (JOB)
PROGRAM FILE LUNO OF TASK
SYNONYM SEGMENT SEGMENT ID
LOGICAL NAME BLOCK SEGMENT ID
USER ID

+----------+----------+
JMRPWD

PASSWORD

+--~-------+----------+

)2C

+----------+----------+
JMRACC
+----------+----------+
/
/
/
/

ACCOUNT NUMBER

+----------+----------+
2270512-9701

22-81

Structure Pictures

JMR

DNOS System Design Document

FLAGS FOR FIELD: JMRFLG
JMFNID
JMFVER
JMFBCH
JMFRES
JMFPVL

#04 - JOB MANAGER CONTROL FLAGS

(X ••••••••••••••• )
(.X •••..•..•.••.• )
( •• X ••••••••••••• )
( ••• XXXXXXXX ••••• )
( ••••••••••• XXXXX)

NEW USED ID SPECIFIED (CREATE)
BYPASS VERFY CHECKS IN JM
BATCH JOB
FLAG BITS 3 - 10 RESERVED
PRIVILEGE LEVEL

EQUATES:
LABEL
JMRSIZ
JMRSZ2

EQUATE TO
$
$

Structure Pictures

VALUE
)10
)3C

22-82

DESCRIPTION
SIZE OF BASIC CALL BLOCK
JMR SIZ FOR CREATE OPERATION

2270512-9701

JSB

DNOS System Design Document

***********************************~************************

** JOB STATUS BLOCK
(JSB)
09/09/83
**
*
*
LOCATION: SYSTEM AREA
*
*
************************************************************
* THE JSB PROVIDES THE INFORMATION ABOUT A JOB WHICH IS
* NEEDED BY DNOS WHETHER OR NOT THE JOB COMMUNICATION AREA
* IS IN MEMORY. THIS INFORMATION INCLUDES FLAGS, QUEUE
* LINKS, STATUS INFORMATION, AND JCA LOCATION DATA.
*----------+----------*
)00 !

JSBJSB

POINTER TO NEXT JSB

+----------+----------+
)02

JOB ID (UNIQUE TO SITE)

JSBJID

+----------+----------+
)04

JSBFLG

JSBTCT

+----------+----------+
)06!

JSBPRI

JSBSTA!

)08!

JSBAPR

JSBWPR

+----------+----------+

)OA
)OC

+----------+----------+
JSBQL

+----------+----------+
JSBWOM

LINK FOR WAITING MEMORY QUEUE

JSBEOR

END OF REQUEST PROCESSING ANCHOR

+----------+----------+

)OE !

JOB FLAGS
JOB TASK COUNT
JOB PRIORITY
JOB STATE
ACTIVE PRIORITY (HIGHEST)
WAITING ON MEMORY PRI(HIGHEST)
ACTIVE QUEUE LINK

+----------+----------+
)10 !

JSBJCA

SSB ADDRESS FOR JCA

)12

JSBSMT

SM TABLE SSB ADDRESS FOR JCA

+----------+----------+

+----------+----------+
) 14

J S BN AM

+----------+----------+
/
/

/
/

JOB NAME

/
/

+----------+----------+
)lC

JSBUID!

USER ID OF JOB

+----------+----------+
/
/

/
/

JSBWOT

+----------+----------+
)24

TABLE AREA JSB WAIT QUEUE LINK

+----------+----------+

)26

PTR TO SELF FOR VERIFICATION

JSBVER

+----------+----------+
FLAGS FOR FIELD: JSBFLG
JSFVER

1104 -

(X •••••••.••••••• ) -

2270512-9701

22-83

JOB FLAGS
BY-PASS VERIFICATION CHECKS

Structure Pictures

JSB

DNOS System Design Document

JSFACC
JSFBAC

(.X ......•.•.•.•. ) - ACCOUNTING STARTED FOR JOB
( •• X••••••••••••• ) - BACKGROUND JOB

EQUATES:
LABEL
JSBSIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)28

22-84

2270512-9701

DNOS System Design Document

KCB

************************************************************

** KIF CURRENCY BLOCK
(KCB)
01/22/82
**
*
*
LOCATION: SYSTEM TABLE AREA
*
*
*
*
************************************************************
* THE KCB IS USED TO MAINTAIN CURRENCY INFORMATION ABOUT A
* KEY INDEXED FILE IN USE. THE KCB IS BUFFERED ALONG WITH
* THE IRB DESCRIBING THE I/O RE~UEST.
** SPECIAL FIELD COMMENTS:
* KCBKAD - FIRST TWO WORDS GIVE THE PHYSICAL RECORD NUMBER
*
OF THE LOGICAL RECORD.
THE THIRD WORD IS THE
*
ID OF THE LOGICAL RECORD.
* KCBBTP - FIRST TWO WORDS GIVE THE PHYSICAL RECORD ~UMBER
*
OF THE KEY FROM WHICH THE CURRENCY WAS CREATED.
*
THE THIRD WORD IS THE LOGICAL ADDRESS OF THE KEY
*
WHEN THE PHYSICAL RECORD IS MAPPED INTO KIF
*
PROCESSING CODE.
*----------+----------*
)02!

KCBINF

KCBKNM

+----------+----------+
)04
)06

KCBKAD

+----------+----------+
KCBDBK

CURRENCY INFORMATION CODE
KEY NUMBER
KEY ADDRESS
DATA BASE KEY (3 WORDS)

+----------+----------+
)08

FILLOO

+----------+----------+

)OA

FILL01

+----------+----------+
)OC

B-TREE POINTER (3 WORDS)

KCBBTP

+----------+----------+
)OE
)10

FILL02

+----------+----------+
FILL03

+----------+----------+

)12

B-TREE ENTRY SIZE

KCBBES

+----------+----------+
) 14!

KCBLOC

KCBCOC

+----------+----------+

LAST OPCODE USED
CURRENT Op CODE

EQUATES:
LABEL
KCBSIZ

2270512-9701

EQUATE TO
$-KCBINF

VALUE

DESCRIPTION

)14

22-85

Structure Pictures

KDB

DNOS System Design Document

************************************************************
*
*

* KEY DESCRIPTOR BLOCK (KDB)
09/10/79
*
**
LOCATION: STA (PART OF IRB)
**
************************************************************
* THE KDB IS PART OF A CREATE KEY INDEXED FILE I/O REQUEST
* BRB WHICH DESCRIBES THE KEYS TO BE CREATED.

*----------+----------*
KDBOVH
!
+----------+----------+
)02
KDBMLR
+----------+----------+
)04 !
+----------+----------+
)06 !
KDBNKY
!
+----------+----------+
)08!
KDBOFF
!
+----------+----------+
)00 !

/
/

OVERHEAD
MAX NUMBER LOGICAL RECORDS

NUMBER OF KEYS
SPACE FOR MAXIMUM /I KEYS

/
/

+----------+----------+
DESCRIPTION OF ONE KEY

*----------+----------*
)OO!
KDBFGS
!
KDBSIZ
+----------+----------+
)02 !
KDBO
!
+----------+----------+
FLAGS FOR FIELD:

KDBFGS

FLAGS
NUMBER OF CHARACTERS IN KEY
KEY OFFSET IN RECORD

1100 -

( XXX •••••••••••••
KDBPLG
( ••• X ••••••••••••
KDB33
( •••• X •••••••••••
KDBOFG = ( ••••• X ••••••••••
KDBSFG = ( •••••• X •••••••••
KDBDFG
( ••••••• X ••••••••

)
)

)
)
)

)

FLAGS

- ***

BIT
BIT
BIT
BIT
BIT

RESERVED
3 SET IF
4 SET IF
5 SET IF
6 SET IF
7 SET IF

***

PARTIAL LOGGING
SEQUENTIAL KIF
KEY IS OPTIONAL
SEQUENTIAL CMNDS
DUPLICATES OK

EQUATES:
LABEL
KDBMKY
KDBMSZ
KDBNXT

EQUATE TO
14
100
$

Structure Pictures

VALUE
)OE
)64
)04

22-86

DESCRIPTION
MAXIMUM II OF KEYS IN FILE
MAXIMUM KEY SIZE
SIZE OF KEY DESCRIPTOR

2270512-9701

DNOS System Design Document

KDR

******************************~***************************

** KEY INDEXED FILE KEY DESCRIPTOR RECORD(KDR) 09/09/83 **
*
*
LOCATION: DISK RESIDENT STRUCTURE
*
*
**********************************************************
* THE KDR DESCRIBES THE KEYS OF A KEY INDEXED FILE. THE
* FIELD AT KDROFF IS ONE OR MORE REPLICATIONS OF THE
* FIELDS BEGINNING AT KDRFGS.

*----------+----------*
KDRHKC
!
+----------+----------+
)02 !
KDRHKV
+----------+----------+
)04 !
FILLOO
!
+----------+----------+
)06
KDRNKY
+----------+----------+
)08!
KDROFF
!
+----------+----------+
)00

/
/

HASH KEY COUNT
HASH KEY VAL UE
(WORD COPIED FROM KDB)
NUMBER OF KEYS
SPACE FOR MAXIMUM # KEYS

/
/

+----------+----------+
KDRCD
!
+----------+----------+
)42 !
!
I
+----------+----------+
)44 !
!
!
+----------+----------+
)46!
KDRSEQ
!
KDRCCT
!
+----------+----------+
)40

CREATION DATE AND TIME USED

CONCATENATED SET SEQUENCE NUM.
TOTAL CONCAT. FILES IN SET

FLAGS DESCRIPTION (NOT A VARIANT)

*----------+----------*
KDRFGS
KDRSIZ!
+----------+----------+
!
KDRO
!
+----------+----------+

)OO!
)02

FLAGS FOR FIELD: KDRFGS

FLAGS
II CHARS IN KEY
KEY OFFSET IN RECORD

#00 -

( XXX •••••••••••••
KDRPFG = ( ••• X • • • • • • • • • • • •
( '•••• X •••••••••••
KDR33
KDROFG
( ••••• X ••••••••••
KDRSFG
( •••••• X •••••••••
KDRDFG
( ••••••• X ••••••••

2270512-9701

)
)

)
)
)
)

FLAGS

- ***

22-87

BIT
BIT
BIT
BIT
BIT

RESERVED
3 SET IF
4 SET IF
5 SET IF
6 SET IF
7 SET IF

***

PARTIAL LOGGING
SEQUENTIAL KIF
KEY IS OPTIONAL
SEQUENTIAL CMNDS
DUPLICATES OK

Structure Pictures

KDR

DNOS System Design Document

EQUATES:
LABEL
KDRMKY
KDRMSZ
KDRNXT

EQUATE TO
14
100
$

Structure Pictures

VALUE
)OE
)64
)04

22-88

DESCRIPTION
MAX # OF KEYS IN FILE
MAX KEY SIZE
SIZE OF KEY DESCRIPTOR

2270512-9701

DNOS System Design Document

KIB

************************************************************

** KIF INFORMATION BLOCK
(KI B)
02/26/80
**
*
*
LOCATION: DISK AND BUFFER SEGMENT
*
*
************************************************************
* THE KIB DESCRIBES A KEY INDEXED FILE DATA BLOCK.
** SPECIAL FIELD COMMENTS:
* KIBBLK - THE PHYSICAL RECORD NUMBER OF THIS BLOCK. THIS
*
FIELD IS MAINTAINED SO THAT IF A SYSTEM CRASH
*
OCCURS WHILE THIS BLOCK IS BEING MODIFIED, THE
*
LOGGED IMAGE CAN BE RESTORED TO THE CORRECT FILE
*
RECORD.
* KIBCMD - THE OPCODE OF THE CURRENT COMMAND. THIS IS
*
MAINTAINED FOR LOGGING PURPOSES.
* KIBSR
THE NUMBER OF BYTES REMAINING IN THE PHYSICAL
*
RECORD.
* KIBFCB - THIS FIELD IS USED TO LINK THE BLOCK ON THE FREE
*
BLOCK CHAIN.
* KIBRSZ - THE SIZE IN BYTES OF THE FIRST LOGICAL RECORD
*
INCLUDING THIS WORD.
*----------+----------*
)00

KIBBLK

+----------+----------+
)02

BLOCK NUMBER

+----------+----------+
)04

KIBCMD

+----------+----------+

)06 !

COMMAND NUMBER
SPACE REMAINING IN BYTES

KIBSR

+----------+----------+
)08

FREE CHAIN POINTER

KIBFCB

+----------+----------+
)OA

+----------+----------+

)OC

KIBHID

HIGHEST LOGICAL RECORD ID USED

+----------+----------+
)OE

KIBRSZ

RECORD SIZE OF 1ST RECORD

+----------+----------+

)10 !

KIBRID

ID OF FIRST LOGICAL RECORD

+----------+----------+

EQUATES:
LABEL
KIBOFB

2270512-9701

EQUATE TO
$

VALUE
)08

22-89

DESCRIPTION
OVERFLOW BLOCK POINTER

Structure Pictures

KIT

DNOS System Design Document

************************************************************

** KIF TASK AREA
(KIT)
01/21/82
**
**
LOCATION: SYSTEM TABLE AREA
**
*
(USED ONLY BY ASSEMBLY LANGUAGE CODE)
*
************************************************************
* THE KIT IS ATTACHED TO THE FILE MANAGEMENT WORK AREA (FWA)
* FOR ADDITIONAL WORKING STORAGE FOR KIF PROCESSING. IT
* INCLUDES INFORMATION ABOUT THE CURRENT REQUEST, THE STATE
* OF THE FILE, AND SEVERAL FIELDS OF THE FCB TO MINIMIZE

MAPPING DURING PROCESSING.

************************************************************

** FILE MANAGER WORK AREA
(FWA)
01/21/82
**
*
*
LOCATION: SYSTEM AREA
*
*
************************************************************
* THE FWA IS USED BY FILE MANAGEMENT AND BY KIF MANAGEMENT
* AS A GENERAL WORK AREA. R15 POINTS TO THE FWA.
*----------+----------*
)00

FWAWP

+----------+----------+
/
/

/
/

WORKSPACE USED BY FM

/
/

+----------+----------+
)20

FWAFLG

MIDDLE SEGMENT FLAGS

FWATCT

MULTIRECORD CHARS TRANSFERRED

+----------+----------+

)22

+----------+----------+
)24 !

FWAOAD

)26

FWAPC

SAVED PROGRAM COUNTER

FWAXWP

BLWP VECTOR FOR RETURNING

+----------+----------+

)28

+----------+----------+
+----------+----------+

)2A
)2C
)2E

FWAXPC

CURRENT OVERLAY AREA ADDRESS

+----------+----------+
FWABN

+----------+----------+

SAVED RPBBN (2 WORDS)

+----------+----------+
)30
)32

FWAOCB

SAVED RPBOCB

FWALFG

SAVED LDT FLAGS

+----------+----------+
+----------+----------+

)34
)36

FWAFFC

+----------+----------+
FWAFMT

+----------+----------+

Structure Pictures

FIRST FCB FOR CC FILES
SSB FOR THE FMT WITH THE FCB

22-90

2270512-9701

DNOS System Design Document

)38 !
)3A
)3C
)3E
)40
)42
)44
)46
)48
)4A
)4C
)4E
)50
)52

FWAFCB

KIT

+----------+----------+
FWABST
+----------+----------+
FWABSB
!
+----------+----------+
FWAPRS
+----------+----------+
FWAUBT
!
+----------+----------+
FWAUBS
!
+----------+----------+
!
FWAUBO
!
+----------+----------+
FWAUBL
+----------+----------+
FWAFMB
+----------+----------+
FWARN1
!
+----------+----------+
FWARN2
!
+----------+----------+
FWAOOB
+----------+----------+
FWAUBR
+----------+----------+
FWAFFG

+----------+-----~----+

)54!

FWASTK

+----------+----------+

FCB ADDRESS IN THE FMT
SMT SSB ADDR FOR BUFFER
SSB ADDR FOR BUFFER
PHYSICAL RECORD SI ZE
USER BUFFER SMT SSB ADDR
USER BUFFER SSB AD DRES S
USER BUFFER OFFSET
USER BUFFER LENGTH
FMT BIAS
RECORD # RELATIVE TO CURRENT
FILE OF CONCATENATED SET
OLD OFFSET IN USER BUFFER
BUFFER LENGTH REMAINING
FILE MGR FLAGS
STACK AREA

/
/
/
/
/
/
+---~------+----------+

TEMPORARY KIF STORAGE IN TASK AREA

)54

*----------+----------*
,!
FILL01
+----------+----------+
/
/

)0134
)0136
)0138
)013A

/
/

+----------+----------+
KITBKM
+----------+----------+
+----------+----------+
KITCMD
!
+----------+----------+
KITEBQ
!
+----------+----------+
+----------+----------+
KITCLB
+----------+----------+

)0130 !
)0132

2270512-9701

KIF STACK

LOGICAL BLOCK END OF MEDIUM

CURRENT COMMAND NUMBER
EMPTY BLOCK QUEUE HEAD

CURRENT LOG BLOCK

22-91

Structure Pictures

KIT

)013C
)013E
)0140
)0142

DNOS System Design Document

KITFBQ

+----------+----------+
+----------+----------+
KITBTR
!
+----------+----------+
KITKDB
+----------+----------+
/
/
/
/

)017C
)017E
)0180
)0182
)0184
)0186

)01C4
)01C6
)01C8
)OICA
)OICC
)OICE
)OlDO
)01D2
)01D4
)01D6
)01D8
)OlDA
)OIDC

KDB OF CURRENT REQUEST

ADDRESS OF FIRST KEY BUFFER
ADDRESS OF SECOND KEY BUFFER
ADDRESS OF THIRD KEY BUFFER
KEY # OF KEY CURRENTLY USING
SIZE (CHARS) OF THIS KEY
B-TREE STACK

+----------+----------+
BTSTKA
!
+----------+----------+
BTSPTR
+----------+----------+
!
NEIBTS
!
+----------+----------+
TSIL2
+----------+----------+
TIL2A
+----------+----------+
!
TSIL2A
!
+----------+----------+
TSIL2B
+----------+----------+
!
TS1L2C
+----------+----------+
T1L2CA
+----------+----------+
TS1L2D
+----------+----------+
TIL2DA
+----------+----------+
TS1L4
+----------+----------+
+----------+----------+
T1L4A

Structure Pictures

B-TREE ROOTS

+----------+----------+
!
KBUFIA
+----------+----------+
KBUF2A
!
+----------+----------+
KBUF3A
+----------+----------+
KEYNUM
+----------+----------+
KEYSZ
+----------+----------+
B'TSTK
+----------+----------+
/
/
/
/

)01C2

FREE BLOCK QUEUE HEAD

ADDR 1ST ENTRY OF B-TREE STACK
ADDR 1ST UNUSED B-T STACK ENTRY
NUMBER ENTRIES IN B-TREE STACK
1 WORD OF LEVEL 1 TEMP STORAGE
ADDRESS OF TSIL4
I

WORD OF LEVEL 1 TEMP STORAGE

1 WORD OF LEVEL
I

1 TEMP STORAGE

WORD OF LEVEL 1 TEMP STORAGE

ADDRESS OF TSIL2C
1 WORD OF LEVEL 1 TEMP STO RAGE

ADDRESS OF TSIL2D
2 WORDS OF LEVEL 1 TEMP STORAGE

ADDRESS OF TSILY

22-92

2270512-9701

DNOS System Design Document

)OlDE

KIT

+----------+----------+
TS1L4A

+----------+----------+

2 WORDS OF LEVEL 1 TEMP STORAGE

)OlEO

+----------+----------+
)01E2

TIL4AA

ADDRESS OF TSIL4A

TSIL4B

2 WORDS OF LEVEL 1 TEMP STORAGE

+----------+----------+
)01E4

+----------+----------+
)01E6

+----------+----------+
)OlE8
)OlEA

T 1 L4 BA

+----------+----------+
TSIL6

+----------+----------+

ADDRESS OF TS1L4B
3 WORDS OF LEVEL 1 TEMP STORAGE

)OlEC

+----------+----------+
)OlEE

+----------+----------+
)OlFO

TIL6A

+----------+----------+
)01F2

TS2L2

+----------+----------+
)01F4

1 WORD OF LEVEL 2 TEMP STORAGE

T2L2A

ADDRESS OF TS2L2

TS2L4

2 WORDS OF LEVEL 2 TEMP STORAGE

+----------+----------+
)01F6

ADDRESS OF TS1L6

+----------+----------+
)01F8

+----------+----------+
)OlFA

ADD RES S OF TS2L4

T2L4A

+----------+----------+
)OlFC

TS2L4A

+----------+----------+

2 WORDS OF LEVEL 2 TEMP STORAGE

)OlFE

+----------+----------+
)0200
)0202

T2L4AA

ADDRESS OF TS2L4A

+----------+----------+
TS2L4B

+----------+----------+

2 WORDS OF LEVEL 2 TEMP STORAGE

)0204

+----------+----------+
)0206

T2L4BA

ADDRESS OF TS2L4B

+----------+----------+
)0208

TS2L4C

+----------+----------+

2 WORDS OF LEVEL 2 TEMP STORAGE

)020A
)020C
)020E

+----------+----------+
T2L4CA

ADDRESS OF TS2L4C

RQDBKA

ADDRESS OF KCBDBK

+----------+----------+
+----------+----------+

)0210

ADDRESS OF KCBBTP

RQBTPA

+----------+----------+
2270512-9701

22-93

Structure Pictures

KIT

)0212

DNOS System Design Document

BTDBKA

+----------+----------+

)0214

FDRCFG

+----------+----------+
)0216

ADDRESS OF BTBDBK
FDR CHANGE FLAG
B-TREE SPLIT FLAG

BTSPLT

+----------+----------+
)0218
)021A
)021C

TBTP

+----------+----------+
+----------+----------+
+----------+----------+

)021E r

ATBTP

+----------+----------+
)0220

TEMPORARY B-TREE POINTER

TDBK

ADR TEMPORARY B-TREE POINTER
TEMPORARY DATA BASE KEY

+----------+----------+

)0222 !

+----------+----------+

)0224 !

+----------+----------+

)0226 !
)0228

ADR OF TEMPORARy DATA BASE KEY

ATDBK

+----------+----------+
SBLK

SAVED SUCCESSOR BLOCK NUMBER

+----------+----------+
)022A !

+----------+----------+

)022C

ASBLK

+----------+----------+
)022E

LEAFFL

+----------+----------+
)0230

RWSAV8

+----------+----------+

)0232

RRPDC

ADR SAVED SUCCESSOR BLK NUMBER
SAVED LEAF FLAG
SAVE R8 HERE
DUP COUNT OF DUP WANTED

+----------+----------+
)0234
)0236

RRPDFL

DUPLICATES FLAG

RQSAVE

ORIG RQ FOR PASSIVE READS

+----------+----------+
+----------+----------+

)0238!

CWSRO

FILL02!

+----------+----------+

)023A

CWSR1

ALT SEQ=)FF, STD SEQ=)OO
CONV REQ FLAG (BIT 8)
STORAGE FOR KEY1 ADDRESS

+----------+----------+
)023C !

CWSR2

STORAGE FOR KEY2 ADDRESS

)023E

CWSR3

STORAGE FOR KEY LENGTH

+----------+----------+
+----------+----------+

)0240

CWSR4

+----------+----------+
)0242

CWSR5

+----------+----------+

FLAGS FOR FIELD: FWAFFG
Structure Pictures

KMCNV BASE DATA ADDRESS
KMUCV BASE DATA ADDRESS

#52 - FILE MGR FLAGS
22-94

2270512-9701

DNOS System Design Document

FWAPOP
FWAQW

KIT

(X ••••••••••••••• ) - PASSIVE OPERATION FLAG
( • X•••••••••••••• ). - QUE UEDT 0 WAI TIN G QUE UE IN F CB

EQUATES:
LABEL
FWASIZ
MAXSSZ
KITSIZ

2270512-9701

EQUATE TO
$
9

VALUE

)F4
)09
)244

22-95

DE SCRIP TION
SIZE OF FWA INCLUDING WSP
ONLY 9 STACK ENTRIES ALLOWED
SIZE INCLUDING WORKSPACE

Structure Pictures

KSB

DNOS

System Design Document

************************************************************
*

* KEYBOARD STATUS BLOCK
(KSB)
09/28/79
**
*
*
LOCATION: SYSTEM AREA
*
*
************************************************************
* THE KSB IS APPENDED TO A PHYSICAL DEVICE TABLE (PDT) FOR
* A KEYBOARD DEVICE. IT IS USED BY THE DEVICE SERVICE
* ROUTINE (DSR) AS A WORKSPACE WHILE HANDLING THE KEYBOARD.
CHARACTER BUFFER LENGTH

)00
)02
)04
)06
)08

)OA
)OC
)OE
)10
)12
)14
)16
)18

*----------+----------*
KSBPDT
+----------+----------+
KSBQOC
!
+----------+----------+
KSBQIP
+----------+----------+
KSBQOP
+----------+----------+
KSBQEP
+----------+----------+
KSBCRQ
+----------+----------+
KSBFL
!
KSBSN
!
+----------+----------+
KSBR7
+----------+----------+
KSBTSB
+----------+----------+
!
KSBR9
+----------+----------+
!
KSBRI0
!
+----------+----------+
!
KSBRII
+----------+----------+
KSBCRU

PDT POINTER

QUEUE OUTPUT COUNT

QUEUE INPUT POINTER

QUEUE OUTPUT POINTER

QUEUE END POINTER

GET CHAR REQUEST QUEUE

KSB FLAGS
STATION NUMBER
- SCRATCH
I

TSB ADDRESS OF CHAR OWNER

SCRATCH

RIO -

SCRATCH

Rl1 -

SCRATCH

R12 -

CRU BASE

R13 -

SAVED WORKSPACE POINTER

R14 -

SAVED PROGRAM COUNTER

R15 -

SAVED STATUS

+----~-----+----------+

)IA !
)IC
)IE

KSBR13

+----------+----------+
!
KSBR14
+----------+----------+
KSBR15
+----------+----------+

FLAGS FOR FIELD: KSBFL
KSBCHM
KSBCIE
KSBRCM
KSBCIB

HOC - R6

KSB FLAGS

(x ••••••••••••••• ) - CHARACTER MODE
(.X •••••••••••••• ) - SCI ENABLED
( •• X ••••••••••••• ) - RECORD MODE
( ••• X •••••••••••• ) - SCI BID IN PROCESS

Structure Pictures

22-96

2270512-9701

DNOS System Design Document

KSBICP
KSBSET
KSBKIO
KSBBRK

KSB

( .... x ........... ) ( ••••• x •••••••••• ) -

SCI ACTIVE
COMMAND I/O HOLD
( •••••• X ••••••••• ) - COMMAND I/O ABORT
( ••••••• X •••••••• ) - DEACTIVATE BREAK KEY

EQUATES:
LABEL
KSBCBL
KSBSIZ

2270512-9701

EQUATE TO
6
$

VALUE
)06
)20

22-97

DESCRIPTION
CHARACTER BUFFER LENGTH

Structure Pictures

LDT

DNOS System Design Document

***************~***~****************************************

*
** LOGICAL DEVICE TABLE
(LDT)
01/27/83 *
*
*
LOCATION: SYSTEM AREA AND JCA
*
*
************************************************************
* THE LDT CONTAINS INFORMATION DESCRIBING AN I/O RESOURCE TO
* WHICH A LOGICAL UNIT NUMBER (LUNO) HAS BEEN ASSIGNED. IT
* INCLUDES TYPE FLAGS, OWNERSHIP, AND STATE INFORMATION.
**

)00
)02

)04
)06
)08
)OA
)OC

BEGINNING PACKED RECORD LDT

*----------+----------*
LDTLDT
+----------+----------+
LDTIOC
LDTLUN
+----------+----------+
*----------+----------*
LDTTYP
LDTTF!
+----------+----------+
LDTFLG
!
+----------+----------+
LDTRLK
+----------+----------+
LDTTSB
!
+----------+----------+
LDTJSB
+----------+----------+

LINK TO NEXT LDT
INITIATE I/O COUNT
LOGICAL UNIT NUMBER

I/O RESOURCE TYPE.
FLAGS FOR LDT TYPE (SEE LDTXFL)
FLAGS
RESOURCE LINK: FCA, PDT OR CCB
OWNER TSB LIST ANCHOR
OWNER JSB ADDRESS

DEVICE, CHANNEL LDT

)OE

*----------+----------*
LDTSID
!
+----------+----------+

SESSION ID

FILE LDT

*----------+----------*
)OE
)10
)12

LDTFMT

+----------+----------+
LDTFCB
+----------+----------+
LDTCAR
+----------+----------+

SSB FOR THE FMT
FCB ADDRESS IN THE FMT
COMPOSITE ACCESS RIGHTS

*----------+----------*
)04

LDTXFL

+----------+----------+

)14 SIZE

Structure Pictures

RESOURCE TYPE /

FLAGS

END OF PACKED RECORD

22-98

2270512-9701

DNOS System Design Document

FLAGS FOR FIELD: LDTFLG

LDT

#06 -

LDFDEL
LDFFW,T
LDFCBA
LDFNUS
LDFPRM
LDFUBI
LDFACU

( ••••• X •••••••••• )
( •••••• XX •••••••• )

LDFSCI

( •••••••• XX •••••• )

( X ••••••••••••••• )
( • X •••••••••••••• )
( •• X ••••••••••••• )
( ••• X •••••••••••• )
( •••• X ••••••••••• )

*
*
*
*
*
*
*
*
LDFDWE
(
LDFVNT
(
LDFUSD = (
LDFDIA
(
(

•••••••••• X ••••• )
••••••••••• X •••• )
•••••••••••• X ••• )
••••••••••••• X •• )

•••••••••••••• XX)

FLAGS FOR FIELD: LDTCAR

FLAGS FOR FIELD: LDTXFL
LDFJLO
LDFVD
LDFREM
LDFCHN
LDFDEV
LDFFIL
*-----* VALUES FOR

*------

LDT IS DELETE PROTECTED
FORCED (IMMEDIATE) WRITE BIT
CREATED BY ASSIGN BI T
LDT IS CURRENTLY NON-USABLE
PARAMETERS ARE PRESENT
UNBLOCKED(I)/BLOCKED(O) OPEN
ACCESS PRIV. IN USE
EXCLUSIVE WRITE
00
EXCLUSIVE ALL
01
SHARED
10
11 = READ ONLY
- LDT SCOPE (TASK, JOB, GLOBAL)
TASK-LOCAL
00
01
JOB-LOCAL
10 = GLOBAL
SHARED
11
DEFERRED WRITE ERROR
EVENTS REQUESTED (KB DEVICES)
LDT HAS BEEN USED
DIAGNOSTIC STATE
- *** RESERVED ***
~

#12 -

LDFRDF
(X ••••••••••••••• )
LDFWRF = (.X •••••••••••••• )
LDFDLF
( •• X ••••••••••••• )
LDFEXF
( ••• X •••••••••••• )
LDFCTF
( •••• X ••••••••••• )
( ••••• XXXXXXXXXXX)

FLAGS

COMPOSITE ACCESS RIGHTS
READ ACCESS FLAG
WRITE ACCESS FLAG
DELETE ACCESS FLAG
EXECUTE ACCESS FLAG
CONTROL ACCESS FLAG
**RESERVED**

#04 - RESOURCE TYPE /

( XXXXXXXX •••••••• )
( •••••••• X ••••••• )
( ••••••••• XX ••••• )
( ••••••••••• X •••• )

FLAGS

** ACTUALLY LDTTYP FIELD **
I=JOB LEVEL OPEN
**RESERVED**
LDT FOR A VIRTUAL DEVICE
LDT FOR REMOTE RESOURCE
LDT FOR CHANNEL
LDT FOR DEVICE
LDT FOR FILE

I/O RESOURCE TYPE (FIELD LDTTYP)

*
EQUATES:

2270512-9701

22-99

Structure Pictures

LDT

DNOS System Design Document

LABEL
LDFACM
LDFSCM
LDFMM
LDTSZl
LDTSZ2
LDTFSZ
LDTRES
LDTSEQ
LDTRR
LDTKIF
LDTDIR
LDTPRG
LDTIMG
LDTDMY
LDTSD
LDTKSR
LDTASR
LDTCS
LDTRS2
LDTDK
LDTDS
LDTMT
LDTTPD
LDTVll
LDTLPS
LDTLPP
LDTC3Q
LDTCOM
LDTIND
LDTCR
LDT940
LDT931
LDTEN
LDTBCM
LDTVT

EQUATE TO
)0300
)OOCO
LDFDWE
$
$
$

o
1
2
3
4
5
6

1
2
3
4
5
6
7
8
9
)A
)B

)C
)D
)E
)F

)10
)11

)12
)13
)14
)15

Structure Pictures

VALUE

DESCRIPTION

)300
)CO
)OA
)OE
)10
)14
)00
)01
)02
)03
)04
)05
)06
)00
)01
)02
)03
)04
)05
)06
)07
)08
)09
)OA
)OB
)OC
)OD
)OE
)OF
)10
)11
)12
)13
)14
)15

22-100

ACCESS PRIV. BIT MASK
SCOPE BIT MASK
MAGIC MODE FOR EVDT
DEVICE, CHANNEL LDT SIZE
FILE LDT SIZE
RESERVED
SEQUENTIAL
RELATIVE RECORD
KEY INDEX
DIRECTORY
PROGRAM
IMAGE
DUMY
- SPECIAL DEVICES
KSR
ASR
CASSETTE
RESERVED
SINGLE DENSITy DISKETTE
DISK
MAG TAPE (979,CARTRIDGE)
820
911 VDT
LINE PRINTER (SERIAL)
LINE PRINTER (PARALLEL)
COMM 9903 (FCCC)
COMM I/F
INDUSTRIAL DEVICES
CARD READER
940 EVT
931 EVT
ETHERNET
BCAIM
VIRTUAL TERMINAL BASE

2270512-9701

DNOS System Design Document

LFD

************************************************************

** LOG FILE DEFINITION
(LFD)
04/26/82
**
*
*
LOCATION:
SY~TEM ROOT
*************************************************************
*
*

THE LFD IS BUILT DURING SYSTEM GENERATION AND IS USED TO
KEEP TRACK OF THE STATE OF THE SYSTEM LOG OPTIONS.

*----------+----------*
)00
)02
)04
)06
)08
)OA

LFDFLG

)12

)lC

FLAGS
ERROR BYTE FOR RECREATE TASK
MAX MESSAGE COUNT (0 = NONE)

TASK ID TO BID FOR FULL FILES
USER TASK ID TO BID ON FULL
LOG DEV I CE NAME
(' , = NONE)

FILENAME 1

+----------+----------+
LFDFN2
!
+----------+----------+
/
/
/
/

)lA

LFDERR

+----------+----------+
LFDMAX
+----------+----------+
LFDTID
LFDTDU
+----------+----------+
LFDDNH
+----------+----------+
+----------+----------+
LFDFN1
+----------+----------+
/
/
/

FILENAME 2

+----------+----------+
LFDALC
!
+----------+----------+
LFDLUN
+----------+----------+

FLAGS FOR FIELD: LFDFLG
LDFFDS
LDFDDS
LDF2ND
LDFCSH
LDFRCR
LDFIMW
LDFSBE

2270512-9701

LOG FILE ALLOCATION
LUNOS

1100 -

(X •••••••••••••••
(.X ••••••••••••••
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X •••••••••••
( ••••• X ••••••••••
( •••••• X •••••••••

)
)
)
)
)
)
)

22-101

FLAGS
FILES DISABLED
DEVICE DISABLED
CURRENTLY USING 2ND FILE
CRASH FILE PROCESSED
RECREATE FILES
FILE S ARE IMME DI AT E WR I TE
SUPPRESS BID ERROR LOGGING

Structure Pictures

LFD

DNOS System Design Document

EQUATES:
LABEL
LFDSIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)IE

22-102

2270512-9701

DNOS System Design Document

I.PD

***************************~********************************

**
**

LINE PRINTER PDT EXTENSION (LPD)
LOCATION:

04/21/82

SYSTEM AREA

**
*

************************************************************

*
*
*

THE LPD IS AN EXTENSION TO THE PHYSICAL DEVICE TABLE (PDT)
FOR A LINE PRINTER.
IT CONTAINS POINTERS AND FLAGS USED
BY THE LINE PRINTER DEVICE SERVICE ROUTINE (DSR).

*----------+----------*
)00

LPDIFF

INTERFACE FLAGS

LPDQCC

QUEUE CHARACTER COUNT

)04 !

LPDQIP

QUEUE INPUT POINTER

)06

LPDQOP

QUEUE OUTPUT POINTER

)02

+----------+----------+
+----------+----------+
+----------+----------+
+----------+----------+

)08 !

LPDQEP

QUEUE END POINTER

+----------+----------+

)OA

LPDBUF

CHARACTER BUFFER

+----------+----------+
)OC !

+----------+----------+
)OE

CHARACTER QUEUE SIZE

LPDQSZ

+----------+----------+

) 10!

LPDSPX

LPDSPR!

TRANSMIT SPEED
RECEIVE SPEED

+----------+----------+
FLAGS FOR FIELD: LPDIFF

*
*

#00 -

INTERFACE FLAGS

LPFIF
(X ..•.••..••••••• ) - INTERFACE
(O<=DM; O)EIA)
LPFUC
= (.X •....•••...••. ) - UPPERCASE ONLY (O=YES; I=NO)
LPFBSY = ( •• X ••••••••••••• ) - "RO" TERMINAL BUSY(O=NO ,1=YES)
( ••• X •••••••••••• ) - 9902 INTERFACE FLAG
LPF902
LPFEOR
( •••• X ••••••••••• )
END-OF-RECORD FLAG
1 = SAFE TO ISSUE ENDRCD
o = DON'T ISSUE ENDRCD
( ••••• XXXXXXXXXXX) - RESERVED
EQUATES:
LABEL
LPDSIZ

2270512-9701

EQUATE TO

VALUE

DE SCRIPTION

)12

22-103

Structure Pictures

LSE

DNOS System Design Document

************************************************************

**
**

LOAD SEGMENT ENTRY

(LSE)

04/04/79

LOCATION: JCA

*
**

*********************************************~**************

*
*
*

THE LSE DESCRIBES A SEGMENT WHICH IS LOADED INTO MEMORY
WHILE THIS TASK IS RUNNING, BUT MAY NOT CURRENTLY BE MAPPED
IN TO THE TASK.
IT IS LINKED TO THE TSB.

*----------+----------*
LSELSE

LINK TO NEXT LOAD SEGMENT ENTRY

)02 !

LSESSB

SSB ADDRESS OF LOADED SEGMENT

)04 !

LSESMT

)00

+----------+----------+
+----------+----------+
!

+----------+----------+

SM TABLE AREA SSB ADDR.

EQUATES:
LABEL
LSESIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)06

22-104

2270512-9701

DNOS System Design Document

MRB

************************************************************

** MASTER READ/MASTER WRITE BUFFER
(MRB)
04/04/83
**
*
*
LOCATION: TASK AREA
*
*
*
*
************************************************************
* THE MRB IS A DESCRIPTION OF THE DATA BUFFER RETURNED TO A
* CHANNEL OWNER TASK IN ITS MASTER READ BUFFER. THIS SAME
* BUFFER STRUCTURE IS USED IN THE MASTER WRITE OPERATION OF
* THE OWNER TASK. ALL BUFFER POINTERS IN THE MRB ARE
* RELATIVE OFFSETS FROM THE BEGINNING OF THE MRB, RATHER
* THAN BEING ABSOLUTE ADDRESSES.
* MRB VARIANTS ARE PROVIDED FOR THE MAJOR TYPES OF I/O CALL
* BLOCKS: BASIC FILE I/O, I/O WITH REPLY INFORMATION, I/O
* WITH VALIDATION, VDT EXTENSIONS, AND UTILITy OPERATIONS.
* THERE IS ALSO A VARIANT FOR ABORT I/O CALLS.
*
** BEGINNING PACKED RECORD MRB
*----------+----------*
)00
)02

SECURITY INFORMATION (SESSION ID)

MRBSID

+----------+----------+
MRBRCB

REQUESTOR CALL BLOCK ADDRESS

+----------+----------+
)04

REQUESTOR TSB ADDRESS

MRBTSB

+----------+----------+
)06

REQUESTOR JSB ADDRESS

MRBJSB

+----------+----------+
)08

SECURITY INFORMATION (QUEUE ADDR)

MRBSSI

+----------+----------+
)OA

MRBSOC

MRBEC

+----------+----------+

SVC OPERATION CODE
SVC RETURN (ERROR) CODE

ABORT I/O VARIANT
)OC

*----------+----------~
MRBABF

MRBABL

+----------+----------+

FLAGS
LOGICAL UNIT NUMBER

I/O VARIANTS

*----------+----------*
)OC!

MRBOC

MRBLUN

+----------+----------+
)OE

MRBSFL

MRBUFL

+----------+----------+

SUB-OPERATION CODE
LOGICAL UNIT NUMBER
SYSTEM FLAGS
REQUESTOR (USER) FLAGS

CDE NUMBER WITHIN CDT

*----------+----------*
)10!

FILL02

MRBSEG

+----------+----------+
)12

MRBNAM

2270512-9701

****

RESERVED ****
SEGMENT IDENTIFIER
DEVICE NAME

22-105

Structure Pictures

MRB

DNOS System Design Document

+----------+----------+
/
/

/
/

+----------+----------+
)lA

FILL03

RESERVED

+----------+----------+
)lC !

MRBNUM

)lE !

MRBDFL

)20 !

MRBBUF

+----------+----------+
!

+----------+----------+

DEVICE NUMBER
DIOU FLAGS
PARAMETER BUFFER ADDRESS

+----------+----------+
I/O AND IOU VARIANTS

*----------+----------*
)10 !

MRBDBA

BUFFER ADDR (OFFSET TO BUFFER)

)12

MRBICC

INPUT CHAR COUNT / ACTUAL OUTPUT

+----------+----------+

+----------+----------+
)14 !

MRBOCC

+----------+----------+

OUTPUT CHAR COUNT / ACTUAL INPUT

DISK I/O VARIANTS

*----------+----------*
)16 !

MRBTRK

+----------+----------+

)18

MRBSPR

MRBSCT

+----------+----------+

TRACK ADDRESS
SECTORS PER RECORD
SECTOR NUMBER

*----------+----------*
)16

MRBADU

+----------+----------+

)18 !

MRBOFF

+----------+----------+

ADU NUMBER
SECTOR OFFSET INTO ADU

TERMINAL I/O BLOCK WITH REPLY

*----------+----------*
)16

MRBRPY

+----------+----------+
)18

REPLY BLOCK ADDRESS (OFFSET)

MRBRES

)lA !

MRBRPA

)lC

MRBRIC

REPLY INPUT COUNT FROM REQUESTOR

MRBROC

REPLY OUTPUT COUNT FOR REQUESTOR

+----------+----------+
+----------+----------+

)lE

+----------+----------+
+----------+----------+

(EXTRA WORD BUFFERED)
REPLY BUFFER ADDR (OFFSET)

VDT READ BLOCK WITH VDT EXTENSION

*----------+----------*
)16

MRBROV

+----------+----------+

Structure Pictures

ZERO, REPLY PTR, OR VALIDATION PTR

22-106

2270512-9701

DNOS System Design Document

) 18 !

MRBXFL

MRB

+----------+----------+
)IA!
MRBFCH
MRBEVT!
+----------+----------+
)IC!
MRBCRO
MRBCCO!
+----------+----------+
)IE!
MRBFRO
!
MRBFCO .!
+----------+----------+

EXTENDED REQUEST FLAGS
VDT FILL CHARACTER
VDT EVENT BYTE
VDT CURSOR IN FIELD ROW
VDT CURSOR IN FIELD COLUMN
VDT FIELD BEGINNING ROW
VDT FIELD BEGINNING COLUMN

*
WRITE WITH VDT EXTN WITH REPLY

)20
)22
)24
)26

*----------+----------*
!
MRBRS3
!
+----------+----------+
t
MRBRY2
+----------+----------+
!
MRBRI2
!
+----------+----------+
!
MRBR02
+----------+----------+

(EXTRA WORD BUFFERED)
REPLY BUFFER POINTER (OFFSET)
REPLY INPUT COUNT FROM REQUESTOR
REPLY OUTPUT COUNT FOR REQUESTOR

BASIC FILE I/O BLOCK

)16
) 18

*----------+----------*
MRBRNI
+----------+----------+
!
!
+----------+----------+

RECORD NUMBER FOR REL REC (2 WORDS)

KIF I/O BLOCK

*----------+----------*
)16 !
MRBCBA
+----------+----------+
)18
MRBRSO
+----------+----------+
)1A
+----------+----------+
)lC!
MRBCUR
!
+----------+----------+
/
/

/
/

CURRENCY BLOCK ADDRESS
RESERVED

CURRENCY BLOCK

/
/

+----------+----------+
I/O UTILITY VARIANT

)10
)12
)14
)16
)18

*----------+----------*
MRBTYP
MRBTFL
+----------+----------+
1
FILL06
+----------+----------+
FILL07
+----------+----------+
MRBKDB
+----------+----------+

2270512-9701

MRBRS4

RESOURCE TYPE
RESOURCE TYPE FLAGS
RESERVED
RESERVED
KEY INDEX DEFINITION BLOCK (OFFSET)
RESERVED

22-107

Structure Pictures

r-1RB

DNOS System Design Document

)lA
)lC
)IE
)20
)22
)24
)26

)28
)2A
)2C
)30

+----------+----------+
MRBFLG
!
+----------+----------+
MRBDLL
+----------+----------+
MRBDPL
!
+----------+----------+
MRBPNA
!
+----------+----------+
MRBPRM
!
+----------+----------+
MRBRS5
+----------+----------+
MRBIFA
+----------+----------+
+----------+----------+
MRBSFA
!
+----------+----------+!
+----------+----------+
SIZE
** END

FLAGS FOR FIELD: MRBABF
MRFDNC

FLAGS FOR FIELD: MRBUFL

DEFINED PHYSICAL RECORD LENGTH
PATHNAME ADDR (OFFSET)
PARAMETER PTR (OFFSET)
RESERVED
INITIAL FILE ALLOCATION (2 WORDS)

SECONDARY FILE ALLOCATION (2 WORDS)

OF PACKED RECORD

/lOE - SYSTEM FLAGS

FLAGS FOR FIELD: MRBDFL

- BUSY
- ERROR
) - END OF FILE
) - EVENT CHAR
)
)

/lOF - REQUESTOR (USER) FLAGS

(X •••••••••••••••
(.X ••••••••••••••
( •• X •••••••••••••
( ••• XX •••••••••••
( ••••• X ••••••••••
( •••••• XX ••••••••

RECORD LENGTH

/lOc - FLAGS

MRFBSY = (X •••••••••••••••
MRFERR
( • X ••••••••••••••
MRFEOF
( •• X •••••••••••••
MRFVNT
( ••• X ••••••••••••

MRFLCK
MRFNAM

DEFINED LOGICAL

(X ••••••••••••••• ) - DO NOT CLOSE
(.XXXXXXX •••••••• ) - RESERVED

FLAGS FOR FIELD: MRBSFL

MRFINT
MRFRPY
MRFRES
MRFACC
MRFLOC
MRFOWN

UTILITY FLAGS (2 BYTES)

)
)
)
)
)
)

/lIE - DIOD FLAGS

(X ••••••••••••••• ) ( • X •••••••••••••• ) -

Structure Pictures

INITIATE REQUEST
OUTPUT WITH REPLY
RESERVED
ACCESS PRIVILEGES
LOCK/UNLOCK
OWNERSHIP LEVEL

22-108

LOCK/UNLOCK
NAME SPECI FI ED

2270512-9701

DNOS System Design Document

MRB

MRFVRD
( •• X ••••••••••••• ) - VIRTUAL DEVICE
MRFWCH = ( ••• X •••••••••. _ •• ) - WHICH RELATIVE DEVICE
MRFREP
( •••• X ••••••••••• ) - REPLACE
FLAGS FOR FIELD: MRBXFL
MRFCSF
MRFNTN
MRFFKR
MRFGRA
MRFEBA
MRFTER
MRFBP
MRFRDB
MRFCIF
MRFFC
MRFIF
MRFRFF
MRFECO
MRFVRQ
MRFVER
MRFWBP

#18 - EXTENDED REQUEST FLAGS

( X••••••••••••••• )
(
= • X•••••••••••••• )
= ( •• X••••••••••••• ),
( ••• X •••••••••••• )

( •••• X•••••••••••
(
= ••••• X••••••••••
= ( •••••• X•••••••••
( ••••••• X••••••••
( •••••••• X•••••••
( ••••••••• X••••••

( •••••••••• X ••••• )

( ••••••••••• X•••• )
( •••••••••••• X••• )
( ••••••••••••• X •• )

( •••••••••••••• X. )
( ••••••••••••••• X)

FLAGS FOR FIELD: MRBTFL

FLAGS FOR FIELD: MRBFLG

*
*
*
*
*
*
*
*

---

CURSOR START OF FIELD DEFN
INTENSITY
BLINKING CURSOR (FLICKER)
GRAPHICS DISPLAY (CHAR LT )20)
8-BIT ASCII
ENABLE TASK EDIT CHAR RETURN
BEEP
RIGHT DISPLAY EDGE BOUNDARY
CURSOR IN-FIELD DEFINED
FILL CHAR DEFI NED
INITIALIZE FIELD
REMAIN IN FULL FIELD
ECHO
VALIDATION REQUIRED
VERIFICATION ERROR
WARNING BEEP

#11 - RESOURCE TYPE FLAGS

= (XXX •••••••••••••
MRFVD = ( ••• X••••••••••••
MRFREM
( •••• X•••••••••••
MRFCHN
( ••••• X••••••••••
MRFDEV
( •••••• X•••••••••
MRFFIL
( ••••••• X••••••••

MRFFCA
MRFFUS

)
)
)
)
)
)

RESERVED
VIRTUAL DEVICE
REMOTE RESOURCE
CHANNEL
DEVICE
FILE

#IA - UTILITY FLAGS (2 BYTES)

( X ••••••••••••••• ) - FILE CREATED BY ASSIGN
(.XX ••••••••••••• ) - FILE USAGE FLAGS
OO=NO SPECIAL USAGE
01=DIRECTORY FILE
10=PROGRAM FILE
11=IMAGE FILE
MRFSCP
( ••• XX ••••••••••• ) - LUNO SCOPE
OO=TASK LOCAL
01=JOB LOCAL
10=GLOBAL
11=RESERVED
MRFGEN = ( ••••• X•••••••••• ) - AUTOGENERATE LUNO
MRFACR
(~ ••••• X••••••••• ) - REQUEST AUTOCREATE FILE
MRFPRM
( ••••••• X•••••••• ) - I=MRBPRM VALID (PARMS PRESENT)
MRFLRL
( •••••••• X••••••• ) - USE LOGICAL REC. LENGTH GIVEN
MRFTMP
( ••••••••• X•••••• ) - FILE IS TO BE TEMPORARY
=

2270512-9701

22-109

Structure Pictures

MRB

DNOS System Design Document

*
*
*
*
*
*
*

MRFIMW
( •••••••••• X ••••• )
IMMEDIATE WRITE DISK'FILES
MRFDFT = ( ••••••••••• XX ••• ) - DATA FORMAT
OO=NORMAL RECORD IMAGE
01=BLANK SUPPRESSED
10, 11 RESERVED
MRFALL
( ••••••••••••• X •• ) - ALLOCATION MAY GROW
MRFFTP
( •••••••••••••• XX) - FILE TYPE
OO=RESERVED
01=SEQUENTIAL FILE
10=RELATIVE RECORD FILE
II=KEY INDEXED FILE
EQUATES:
LABEL

-----

VARNO
MRBASZ
MRFVAL
MRFMDS
MRFEXR
MRFBAD
MRFWPM
MRBOSZ
MRBCDE
MRBSZD
MRBISZ
MRBDSZ
MRBRSZ
MRBVAL
MRBXSZ
MRBRS2
MRBVXS
MRBXRS
MRBFSZ
MRBKSZ
MRBUSZ

EQUATE TO

--------$
$
MRFRPY
MRFLOC
MRFOWN
MRFOWN+l
MRFOWN+1
$
MRBUFL
$
$
$
$
MRBROV
$
$
$
$
$
$
$

Structure Pictures

VALUE

... ----

)OC
)OE
)01
)05
)06
)07
)07
)10
)OF
)22
)16
)IA
)20
)16
)20
)20
)20
)28
)lA
)30
)2E

DESCRIPTION
~-----------------------------

22-110

ABORT I/O MRB SIZE
READ WITH VALIDATION
MASTER DO NOT SUSPEND
EXTENDED REQUEST
BLANK ADJ/SET EVENT MODE
WORD PROCESSING MODE
CDE NUMBER WITHIN CDT
SIZE OF DIOU VARIANT
BASIC I/O MRB SIZE
DISK I/O MRB SIZE
BASIC REPLY MRB SI ZE
VDT EXTENSION MRB SIZE
NO LONGER USED
READ WITH EXTN/VALIDATION MRB SIZE
WRITE WITH EXTN/REPLY MRB SIZE
SIZE OF BASIC FILE I/O MRB
SIZE OF KIF MRB
SIZE OF IOU CALL BLOCK

2270512-9701

MTX

DNOS System Design Document

************************************************************

**
*
REV 05/10/83 *
*
LOCATION: SYSTEM AREA
*************************************************************
*

*
*

EXTENTION FOR A MAGNETIC
TAPE DEVICE

(MTX)

04/13/83

* THE MTX IS AN EXTENSION TO THE PDT USED TO DESCRIBE A
IT IS USED AS A WORK AREA BY
* MAGNETIC TAPE DEVICE.
* THE DSR.
*----------+----------*
)OO!
MTXTIL
!
+----------+----------+

TILINE IMAGE

/
/
/
/
/
/
+----------+----------+
)10!
MTXSLG
!
+----------+----------+
/
/
/
/
/
/
+----------+----------+
) 20 !
MTXSVS
!
+----------+----------+
) 22 !
MTXMAJ
+----------+----------+
)24 !
MTXMIN
!
+----------+----------+
) 26 !
MTXFLG
!
+----------+----------+
FLAGS FOR FIELD: MTXFLG
MTFEOT

MTFODI

TILINE IMAGE FOR SYSTEM LOG

TILINE UNIT ERROR COUNT
MAJOR ERROR COUNT
MINOR ERROR COUNT
FLAGS

1126 - FLAGS

(X ••••••••••••••• )
(.XXX •••••••••••• )
( •••• X••••••••••• )
( ••••• XXXXXXXXXXX)

END-OF-TAPE FLAG
RESERVED
ON-LINE-DIAGNOSTICS
RESERVED

*
EQUATES:
LABEL

EQUATE TO

MTXSIZ
MTXCNT
MTXCMD

MTXTIL+)
MTXTIL+)

2270512-9701

VALUE

DESCRIPTION

)28
)08
)OC

22-111

MT PDT + EXTENSION SIZE
BYTE TRANSFER COUNT
TRANSPORT SELECT/COMMAND/ADDR

Structure Pictures

NDB

DNOS System Design Document

***********************************************************

NAME DEFINITION BLOCK (NDB)
07/16/81
*
*
*
*
LOCATION:
A NAME DEFINITION SEGMENT
************************************************************
*

*----------+----------*

FIXED LINK

SEQ PROCESSING

)00 !

NDBNDB

)02 !

NDBPAR

POINTER TO PARENT NDB

)04 !

NDBLLL

POINTER TO LEFT SON

)06

NDBRRR

POINTER TO RIGHT SON

)08 !

NDBNAM

PTR TO THE NAME

)OA

NDBSVB

+----------+----------+
+----------+----------+
+----------+----------+

+----------+----------+
+----------+----------+
!

+----------+----------+
)OC

NDBBAL

NDBWAT

+----------+----------+

ANCHOR OF STAGE VALUES
BALANCE FACTOR
SON INDICATOR

EQUATES:
LABEL
NDBSIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)OE

22-112

2270512-9701

DNOS System Design Document

NDS

************************************************************

*
*
**

NAME DEFINITION SEGMENT OVERHEAD
LOCATION:

(NDS)

12/16/81

A NAME DEFINITION SEGMENT

**
**

************************************************************

*----------+----------*
)00

NDSHED

1ST ENTRY ON FREE MEMORY LIST

+----------+----------+
)02

NDSLNK

+----------+----------+

)04

NDSRES

+----------+----------+
)06

NDSEND

PTR TO FREE MEMORY CHAIN
RESERVED TABLE AREA BOUNDRY
ACTUAL ADDRESS OF END OF SEG

+----------+----------+
)08
)OA
)OC

NDSUSE

CURRENT MEMORY USAGE

NDSHI

HIGHEST MEMORY ALLOCATION

+----------+----------+
+----------+----------+
NDSJSB

PTR TO JSB OR SSB OF OWNER

+----------+----------+
)OE

NDSNUL!

)10
)12

NDSOWN

+----------+----------+
NDSSTR

+----------+----------+
NDSLTR

HANDY NULL STRING
SEGMENT IN USE IF NON- ZERO
PTR TO ROOT OF SYN TREE
PTR TO ROOT OF LGN TREE

+----------+----------+
)14 !

NDSSDB

)16 !

NDSSYN

+----------+----------+

FIXED LINK OF SYNONYM NDBS

+----------+----------+
)18
)lA

PTR TO 1ST SDB FOR THE JOB

NDSLGN

FIXED LINK OF NAME NDBS

NDSTMP

TEMPORARY PACKET ADDRESS

+----------+----------+
+----------+----------+

EQUATES:
LABEL
NDSSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)lC

22-113

LENGTH OF NDS OVERHEAD

Structure Pictures

NFCRSH

DNOS System Design Document

************************************************************

*
*
(NFCRSH)
06/08/83
*
**************************************************************
* SYSTEM CRASH CODE EQUATES

* NFCRSH LISTS ALL POSSIBLE SYSTEM CRASH CODES GENERATED BY
* DNOS.
SOME CODES ARE ALSO RESERVED AS THEY ARE USED BY
* DXIO AND USE OF THOSE BY DNOS WOULD NOT BE DESIRABLE.

*CSHOOE EQU )OOOE
*
*CSHOIO THRU CSHOI2
* CSHOI3 THRU CSHOIF
*CSH020

*CSH02I

EQU
CSH022 EQU
CSH023 EQU
CSH024 EQU
CSH025 EQU
CSH026 EQU
CSH027 EQU
CSH028 EQU
CSH029 EQU
CSH02A EQU
*CSH02B

*CSH02C

)0021
)0022
)0023
)0024
)0025
)0026
)0027
)0028
)0029
)002A

EQU

)002C

*CSH02E
CSH02F EQU
CSH030 EQU
*CSH031

)002F
)0030

*CSH02D

*
*
*CSH033
*
*CSH034
*
*CSH035
*
*CSH036
*
*CSH040
*CSH032

CSH046
CSH048
CSH04A
CSH04B
CSH04C
CSH04D

THRU CSH045
EQU )0046
EQU )0048
EQU )004A
EQU )004B
EQU
)004C
EQU
)004D

Structure

Pictures

PMTLDR -

CANNOT ASSIGN TO ROLL
FILE
RESERVED-USED BY DXI0
ILLEGAL INTERRUPT AT LEVEL 3 THRU F
RESERVED-DXIO-ILLEGAL INTERNAL
INTERRUPT
PMUMGR - INCONSISTENT STRUCTURE
NFTMGR - INCONSISTENT STRUCTURE
NFSCHD - QUEUING ERROR
IOBM
- INCONSISTENT STRUCTURE
ILLEGAL SYSTEM XOP
PMROLL - CANNOT EXTEND SWAP FILE
PMROLL - SWAP FILE WRITE ERROR
PMLDSG - SWAP FILE READ ERROR
NFPOP - UNEXPECTED ERROR RETURNED
NUCLEUS - INCONSISTENT STRUCTURE
RESERVED-DXI0-ERR IN LDT BUILT
FOR PROG. FILE
NFENAB - SCHEDULER INHIBIT NEG.
RESERVED-DXIO-TM$LDR TOOK END
ACTION
RESERVED-DXI0-S0$CPR ERROR
SYSTEM OVERLAY LOAD ERROR
NFTMGR - NO SYSTEM TABLE AREA
RESERVED-DXIO-UNEXP ERR RETURN
IN RM$REL
RESERVED-DXIO-UNEXP ERR RETURN
IN BM$TRW
RESERVED-DXIO-UNEXP ERR RETURN
IN BM$W
RESERVED-DXI0-UNEXP ERR RETURN
IN BM$CLO
RESERVED-DXIO-UNEXP ERR RETURN
IN BM$FLS
RESERVED-DXIO-UNEXP ERR RETURN
IN BM$SCH
RESERVED-DXI0SEGMGR - INCONSISTENT STRUCTURE
JOBMGR - END ACTION TAKEN
JOBMGR - TASK QUEUING ERROR
JOBMGR - ERROR FROM SEG MGR
JOBMGR - ERROR FROM IOU
JOBMGR - CANNOT GET TABLE AREA
22-114

2270512-9701

DNOS System Design Document

*CSH050
CSH051 EQU

)0051

*CSH060

)0060

EQU

*
*
*
*
*
*
*
*
*
*
*
*

*
*
*
*

*
*
*
*
*
*
*CSH070

THRU CSH076
CSH077 EQU )0077
CSH080 EQU )0080
*CSH081
CSH082 EQU )0082
CSH083 EQU )0083
CSH084 EQU )0084

*CSH085 EQU )0085
*CSH086 EQU )0086
*CSH087 EQU )0087
*
*CSH088 THRU CSH089
CSH090 EQU )0090
CSH094 EQU )0094
CSHOAO EQU )OOAO
CSHOAI EQU )OOAI
CSHOA2 EQU )00A2
*CSHOA3 THRU CSHOA4
*CSHOAF
CSHOBO EQU )OOBO
CSHOBI EQU )OOBI
CSHOB2 EQU )00B2
CSHOB3 EQU )00B3
CSHOB5 EQU )00B5
2270512-9701

NFCRSH

RESERVED-DXI0PROGRAM FILE SVC'S INCONSISTENT LDT LIST
NFINT2 - INTERNAL INTERRUPT
60 THRU 6F RESERVED FOR
INTERNAL INTERRUPTS 0 - F
60 - INVALID INTERNAL INTERRUPT
61
MEMORY PARITY
62 - ILLEGAL INSTRUCTION
63 - TILINE TIMEOUT
64 - ILLEGAL SUPERVISOR CALL
(RESERVED,SOFTWARE DETECTED)
65 - MAPPING ERROR
66 - PRIVILEGED OPCODE
67 - TASK IS BEING KILLED
(RESERVED,SOFTWARE DETECTED)
68 - NOT ENOUGH USER TASK AREA
SOFTWARE DETECTED
69 - SEGMENT NOT PRESENT
6A - EXECUTE PROTECT VIOLATION
6B - WRITE PROTECT VIOLATION
6C - STACK OVERFLOW
6D - HARDWARE BREAKPOINT
6E - 12 MS CLOCK EXPIRED
6F - ARITHMETIC OVERFLOW
DISK SPACE
RESERVED-DXI0MEDIA CHANGE OCCURRED ON SYS DISK
DSKMGR - END ACTION TAKEN
RESERVED-DXI0DSKMGR - UNDEFINED OP CODE
DSKMGR - ADU ALLOCATED ALREADY USED
DSKMGR - FIRST AVAILABLE ADU
OUT OF RANGE
DSKMGR - ILLEGAL PARTIAL BIT MAP
NUMBER REQUESTED
DSKMGR - CACHED BIT MAP HAS
BEE N MO DI FIE D
DSKMGR - READ AFTER WRITE OF
PARTIAL BIT MAP DOES NOT VERIFY'
RESERVED-DXI0INVALID USE OF VTOI
DSR940 - CAN'T GET BUFFER TABLE AREA
FILMGR - END ACTION TAKEN
FILMGR - ERROR LOADING FM OVERLAY
FILMGR-INCONSISTENT STRUCTURE
RESERVED-DXI0RESERVED-DXI0NAMMGR - END ACTION TAKEN
NAMMGR - PASCAL RUN-TIME ABORT
IOTBID - END ACTION TAKEN
IPCTSK - END ACTION TAKEN
PMOVYL - END ACTION TAKEN
22-115

Structure Pictures

NFCRSH

ONOS System Design Document

CSHOB6 EQU
)00B6
CSHOB7 EQU
)00B7
CSHOB8 EQU
)00B8
CSHOB9 EQU
)00B9
CSHOBA EQU
)OOBA
)OOBB
CSHOBB EQU
CSHOBD EQU
)OOBD
CSHOBE EQU
)OOBE
CSHOCO EQU
)OOCO
*CSHOEO THRU CSHOE5
CSHI00 EQU
)0100
CSHI0l EQU
)0101
CSHI02 EQU
)0102
*CSHI03 THRU CSHI06
CSHI07 EQU
)0107
*CSHI08 THRU CSHI09
CSHI0A EQU
)010A

**CSHI0B

THRU CSHI0D
CSHI0E EQU
)010E
*CSHI20 THRU CSH123
*CSHI30 THRU CSH131
CSH132 EQU
)0132
*CSRI33 THRU CSH137
CSH138 EQU
)0138
CSH139 EQU
)0139
CSH13A EQU
)013A
CSH13B EQU
)013B
CSH13C EQU
)013C
CSH13D EQU
)013D
CSH13E EQU
)013E
*CSHI3F
*CSHI40
CSH141 EQU
)0141

*CSH142

EQU
CSH143 EQU
*
CSH144 EQU
*
CSH145 EQU
CSH146 EQU
*CSHI47
*
*CSHI50
*
CSH160 EQU
CSH161 EQU

)0142
)0143
)0144
)0145
)0146

)0160
)0161

*
CSH162 EQU

*
*

CSH163 EQU

)0162
)0163

Structure Pictures

PMTBID - END ACTION TAKEN
PMWRIT - END ACTION TAKEN
PMTLDR - END ACTION TAKEN
PMTERM - END ACTION TAKEN
PMSBUF - END ACTION TAKEN
PMRWTK - END ACTION TAKEN
PMSBID - END ACTION TAKEN
RCP - END ACTION TAKEN
NFEOBR - TSBIO HAS BECOME NEGATIVE
RESERVED-DXI0IOU - END ACTION TAKEN
IOU - WRONG SEGMENT MAPPED
IOU - LOOKUP, DE-LINK FAILURE
RESERVED-DXI0IOU - BAD FILE LDT LIST
RESERVED-DXI0IOU - ERROR RETURNING ADU
JUST OBTAINED
RESERVED-DXI0IOU - FCB BLOCK COUNT OVERFLOW
RESERVED-DXI0RESERVED-DXI0RPUTIL - END ACTION TAKEN
RESERVED-DXI0RPIV -BIT MAP TABLE ERROR
RPINV2 - DISK ALLOCATION FAILURE
RPINV2 - BAD BIT MAP NUMBER
RPINV2 - BAD ADU LIST RANGE OVERLAP
NFPWUP - NO POWER DOWN INTERRUPT
NFPWUP - CANNOT FIND RTWP CONTEXT
NFPWUP - INVALID RTWP CONTEXT
RESERVED-DXI0RESERVED-DXI0RESERVED-DX7 -NO POWER FAIL
RECOVERY SUPPORT
UNIV BLD -NO TERMINAL AVAILABLE
UNIV BLD -I/O ERROR TO TERMINAL
WHILE BUILDING DISK
UNIV BLD -NO RESPONSE TO INITIAL
MESSAGE
IPC - INCONSISTENT DATA STRUCTURES
DIOU TOOK END ACTION
RESERVED-DXI0-PDT'S POINTER TO
PRB IS INVALID
RESERVED-DX7 -DISK CHANGED WITH
NO UNLOAD (UV) COMMAND
(RESERVED DXI0-TM$BID END ACTION)
IOU (SECMGR) - UNABLE TO OPEN
LUNO TO .S$CLF
IOU (SECMGR) - UNABLE TO CREATE
OR MAP SPECIAL SEGMENT FOR
BUILDING CAPABILITy LIST
RESTART - JUST MADE CRASH FILE
22-116

2270512-9701

DNOS System Design Document

NFCRSH

BIGGER, SO WE FORCED CRASH
RESERVED-DX10************************************************************

**CSH177

*
*
SYSTEM LOADER FLASH CRASH CODES
*
*
*
*
************************************************************
FLSH01
FLSH02
FLSH03
FLSH04
FLSH05

*FLSH06
FLSH08
FLSH09
FLSHOA
FLSHOB
FLSHOC
FLSHOD
FLSHOE
FLSHOF

EQU
EQU
EQU
EQU
EQU

>0001
>0002
>0003
>0004
>0005

EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU

>0006
>0008
>0009
>OOOA
>OOOB
>OOOC
>OOOD
CSHOOE
>OOOF

*FLSH11

EQU
FLSH13 EQU
FLSH14 EQU
*FLSH60-6F
FLSH68 EQU

2270512-9701

>0011
>0013
>0014
EQU >60->6F
>0068

LOAD DEVICE I/O ERROR
NOT ENOUGH PHYSICAL MEMORY
CAN'T FIND SYSTEM DISK PDT
ERROR IN PROG FILE DIRECTORY
S$IPL INCONSISTENT WITH REV.
LEVEL OF CURRENT SYSTEM
ERROR IN DM BIT MAP ROUTINE
CAN'T FIND SYSTEM LOADER FILE
CAN'T FIND KERNEL PROGRAM FILE
CAN'T FIND A SYSTEM SEGMENT
NO PATCHES APPLIED TO SYSTEM
SOFTWARE VERSION TOO OLD
CAN'T FIND UTILITIES PROG FILE
CAN'T FIND SYSTEM ROLL FILE
KERNEL FILE LEVEL INCONSISTENT
WITH UTILITY FILE
CAN'T GET SYSTEM TABLE AREA
LOGICAL ADDRESS OVERFLOW
CAN'T LOAD WCS FILE
INTERNAL INTERRUPT (LEVEL 2)
NOT ENOUGH USER TASK AREA

22- 11 7

Structure Pictures

DNOS System Design Document

NFSTAT

************************************************************

*
** 7ASK STATE CODES
(NFSTAT)
09/20/83
*
** NOTES:
**
*
1) THIS MODULE REQUIRES NFEROO THRU NFER40 BE
*
COPIED ALSO.
*
*
**
2) CHANGES TO THIS MODULE REQUIRE CORRESPONDING
**
CHANGES IN 3 OF THE MESSAGES IN THE SVC MESSAGES *
*
*
FILE.
(SVC >35, SVC >07, AND SVC OE)
*
************************************************************
* THESE EQUATES DESCRIBE ALL THE LEGAL TASK STATE CODES AND
* JOB STATE CODES USED BY THE OS.
TSTACT
TSTWOM
TSTJWT
TSTLIP
TSTTRM
TSTDLY
TSTSUS
TSTENX

*TSTSIO
TSTSAI
TSTOVL
TSTCOA
TSTWIO
TSTDOR
TSTSBT
TSTIV
TSTDMG
TSTQIN
TSTIT
TSTIP
TSTIO
TSTDT
TSTDP
TSTDO
TSTBID
TSTRWT
TSTWOT
TSTMNI
TSTUV
TSTAIO
TSTAPS
TSTINV
TSTSEM
TSTSEG
TSTEWT
TSTNMG
TSTJMR

EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU

BYTEOO
BYTE01
BYTE02
BYTE03
BYTE04
BYTE05
BYTE06
BYTE07

EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU
EQU

BYTE09
BYTEOF
BYTE14
BYTE17
BYTE19
BYTE1E
BYTE! F
BYTE20
BYTE22
BYTE24
BYTE25
BYTE26
BYTE27
BYTE28
BYTE29
BYTE2A
BYTE2B
BYTE2D
BYTE30
BYTE31
BYTE34
BYTE36
BYTE37
BYTE38
BYTE3D
BYTE40
BYTE42
BYTE43
BYTE48

Structure Pictures

TASK IS ON ACTIVE LIST
TASK IS WAITING ON MEMORY
JOB IN A NONEXECUTABLE STATE
TASK LOAD IN PROGRESS
TASK HAS TERMINATED
TASK IS IN A TIME DELAY
TASK UNCONDITIONALLY SUSPENDED
WAITING FOR TEN X PROCESSOR
COMPLETION
TASK SUSPENDED FOR I/O
SUSPENDING FOR ABORTING I/O
WAITING FOR OVERLAY LOAD SVC
TASK AWAITING COROUTINE ACT
WAITING FOR INITIATED I/O
WAITING FOR DOOR TO OPEN
WAITING FOR SCHD TASK BID SVC
WAITING FOR INSTALL VOLUME SVC
WAITING FOR DISK MGR SVC
AWAITING QUEUE INPUT
WAITING FOR INSTALL TASK SVC
WAITING FOR INSTALL PROC SVC
WAITING FOR INSTALL OVLY SVC
WAITING FOR DELETE TASK SVC
WAITING FOR DELETE PROC SVC
WAITING FOR DELETE OVLY SVC
TASK SUSPENDED FOR BID SVC
WAITING FOR READ/WRITE TSK sve
WAITING FOR SYSTEM TABLE AREA
WAITING FOR MAP PROG NAME TO ID
WAITING FOR UNLOAD VOLUME SVC
WAITING FOR ANY I/O
WAITING FOR ASC PROG FILE SPACE
WAITING FOR INIT NEW VOL SVC
TASK SUSPENDED FOR SEMAPHORE
TASK AWAITING SEG MGR SERVICES
WAITING FOR EVENT COMPLETION
WAITING FOR NAME MGR SVC
TASK WAITING ON JOB MGR SVC
22-118

2270512-9701

NFSTAT

DNOS System Design Document

TSTFRL EQU
TSTRCP EQU

BYTE4A
BYTE4C

WAITING FOR FORCED ROLL SVC
WAITING FOR RETURN CODE PROC

************************************************************

*
*
*

JOB STATE CODES

JSTCRE
JSTEXC
JSTHLT
JSTTRM
JSTEXP

EQU
EQU
EQU
EQU
EQU

*
*

*
************************************************************

2270512-9701

BYTE01
BYTE02
BYTE03
BYTE04
BYTE05

JOB
JOB
JOB
JOB
JCA

IS
IS
IS
IS
IS

22-119

BEING CREATED
IN A EXECUTABLE STATE
HALTED
TERMINATING
BEING EXPANDED

Structure Pictures

NRB

DNOS System Design Document

***********************************************************

*
*
NAME REQUEST BLOCK (NRB)
09/09/83 *
*
*
*
LOCATION:
SYSTEM TABLE AREA
************************************************************
*
NAME MGR REQUEST BLOCK

)00
)02
)04
)06

)08

*----------+----------*
NRBSOC
NRBEC
+----------+----------+
f
NRBOC
NRBFLG!
+----------+----------+
!
NRBNAM
!
+----------+----------+
NRBVAL
!
+----------+----------+
!
NRBPRM
!
+----------+----------+

SVC CODE
ERROR CODE
SUBOPCODE
USER SET FLAGS
P TR TO" NAM E" ( 0 RNA MEL I S T )
PTR TO "VALUE" OR PATHNAME
PTR TO "PARMS" LIST

*----------+----------*
)OA

NRBPNO

+----------+----------+
)OC
NRBRSV
+----------+----------+
)OE
NRBTSK
NRBSTG
+----------+----------+
)10
NRBSMT
+----------+----------+
)12
NRBSSB
+----------+----------+
) 14!
NRBVBL
NRBPBL
+----------+----------+
)16
NRBLNA
+----------+----------+
)18
NRBLVA
+----------+----------+
)IA
NRBLPA
+----------+----------+

PATHNAME NUMBER
RESERVED
TASK ID
STAGE NUMBER
SMT FOR NAME SEGMENT
SSB FOR NAME SEGMENT
VALUE BUFFER LENGTH
PARMS BUFFER LENGTH
NAME POINTER -LOGICAL ADDRESS
VALUE POINTER-LOGICAL ADDRESS
PARMS POINTER-LOGICAL ADDRESS

)OA

*----------+----------*
NRBSSZ
+----------+----------+

SE GME NT SIZE

)OA

*----------+----------*
NRBSPF
+----------+----------+

SUCCESSOR/PREDECESSOR FLAG

Structure Pictures

22-120

2270512-9701

DNOS System Design Document

FLAGS FOR FIELD:

NRBFLG

NRB

#03 -

NRFLOG
(X •••••••••••••••
NRFINT
(.X ..•..•...•..•.
NRFBID
( •• X . . . . . . . . . . . . . .
NRFGLO
( ••• X ••••••••••••
NRFRID = ( •••• X •••••••••••
NRFNMX
( ••••• X ••••••••••
NRFPRO
( •••••• X •••••••••
NRF007
( ••••••• X ••••••••

LOG = 1, ELSE SYN OPERATION
INITIAL TASK IN JOB IF TRUE
BID = 1, TERMINATION = 0
GLOBAL REQUEST = 1
RUN ID SPECIFIED = 1
NAME SEGMENT CANNOT EXPAND
PROTECT NAME
FLAG BIT 7 UNUSED

) -

) ) ) )

)

USER SET FLAGS

EQUATES:
LABEL
NRBVAR
NRBSID
NRBSIZ

2270512-9701

EQUATE TO

$
$
$

VALUE

DESCRIPTION

)OA

)OC
)IC

22-121

SEGMENT ID
SIZE OF BASIC BLOCK TO BUFFER

Structure Pictures

OAD

DNOS System Design Document

************************************************************

**
** OVERLAY AREA DESCRIPTOR
(OAD)
12/07/79
*
*
LOCATION: WITH SYSTEM OVERLAY AREAS
*
*
************************************************************
* THE OAD PRECEDES A SYSTEM OVERLAY AND DESCRIBES ITS SIZE
* AND LOCATION.
SIZE OF OVERLAY DESCRIPTOR

*----------+----------*

)FFFO !

OADSMT

SMT ADDRESS OF OVERLAY AREA SEGMENT

)FFF2

OADSSB

SSB ADDRESS OF OVERLAY AREA SEGME NT

)FFF4

+----------+----------+

+----------+----------+
OADOFF

+----------+----------+

)FFF6 I
)FFF8

OADBSZ

+----------+----------+
OADSIZ

+----------+----------+

OFFSET INTO SEGMENT OF OVERLAY CODE
NUMBER OF BYTES TO READ
SIZE OF OVERLAY AREA

)FFFA !

OADOVN

CURRENT OVERLAY IN AREA -l=NONE

)FFFC

OADUSE

NUMBER OF TASKS USING THE-- OVERLAY

)FFFE

+----------+----------+
+----------+----------+
OADOAD

+----------+----------+

POINTER TO NEXT OVERLAY AREA

EQUATES:
LABEL
OADSZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)FFFO

22-122

SIZE OF OVERLAY DESCRIPTOR'

2270512-9701

DNOS System Design Document

OAW

************************************************************

* OVERLAY AREA WAIT BLOCK
*
(OAW)
11/08/79 *
*
*
*
LOCATION: SYSTEM TABLE AREA
*
*
************************************************************
* THE OAW IS USED TO REPRESENT THE TASK WAITING FOR ONE
* SYSTEM OVERLAY OF A POOL OF OVERLAYS. THE POOL MANAGER
* MAINTAINS A LIST OF OAW ENTRIES AND WHEN AN OVERLAY IS
* FREE, CHECKS TO SEE IF ANY TASK IS WAITING FOR IT. IF SO,
* THE OVERLAY IS LOADED AND TH TASK IS ACTIVATED.
)00
)02
)04

)06

*----------+----------*
OAWOAW
+----------+----------+
OAWJSB
!
+----------+----------+
OAWTSB
+----------+----------+
!
OAWOVN
+----------+----------+

NEXT WAIT BLOCK
JSB OF WAITING TASK
TSB OF WAITING TASK
NUMBER OF OV AREA BEING WAITED FOR

EQUATES:
LABEL
OAWSIZ

2270512-9701

EQUATE TO
$

VALUE

DESCRIPTION

)08

22-123

Structure Pictures

OSE

DNOS System Design Document

************************************************************

** OWNED SEGMENT ENTRY
*
(OSE)
09/23/81
*
*
*
LOCATION: JCA
*
*
************************************************************
* THE OSE DESCRIBES A SEGMENT WHICH IS EXCLUSIVELY USED BY A
* TASK. IT IS LINKED TO THE TSB.

*----------+----------*

)00 !

OSEOSE

LINK TO NEXT OWNED SEGMENT ENTRY

)02

OSESSB

SSB ADDRESS OF OWNED SEGMENT

+----------+----------+
+----------+----------+

)04

OSESMT

+----------+----------+

SSB ADDRESS OF SEGMGR TABLE AREA

EQUATES:
LABEL
OSESIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)06

22-124

2270512-9701

DNOS System Design Document

OTI

***********************************************************

**
*
*
LOCATION:
JCA OR STA
*
*
***********************************************************
* THE OTI IS AN ELEMENT OF A SINGLY LINKED LIST CONTAINING
* TSB ADDRESSES OF TASKS WHICH HAVE OPENED THE LUNO
* ASSOCIATED WITH THE PARENT LDT.
OPENING TASK IDENTIFIER

)00
)02

(OTI)

*----------+----------*
OTIOTI

+----------+----------+
OTITSB

+----------+----------+

08/25/81

LINK TO NEXT OTI
TSB ADDRESS OF OPENING TASK

EQUATES:
LABEL

EQUATE TO

OTISIZ

$-OTIOTI

2270512-9701

VALUE

DESCRIPTION"

)04

22-125

SIZE OF OTI

Structure Pictures

OVB

DNOS System Design Document

************************************************************

** OVE RHEAD BEET
*
(OVB)
10/04/83 *
*
*
LOCATION: USER MEMORY
*****************************************************~*~*****
*
* THE OVB IS THE 32 BYTES PRECEDING A SEGMENT WHEN IT IS IN
* MEMORY. THE OVB INCLUDES LINKAGE, TYPE, AND STATUS
* INFORMATION ABOUT THE SEGMENT.
** THE OVFROL FLAG ALSO HAS THE MEANING "SEGMENT LOGICALLY
* NOT IN MEMORY".
* THE OVBTIM IS THE COUNT OF TASKS WHICH BOTH:
* A) HAVE THE SEGMENT MAPPED IN OR LOADED, AND
* B) HAVE ALL THEIR MAPPED OR LOADED SEGMENTS PHYSICALLY
*
IN MEMORY.
* AN OVERRUN BEET IS ALLOCATED AT THE END OF THE SEGMENT
* TO PREVENT PROBLEMS WHICH COULD OCCUR BECAUSE OF /12 CPU
* PRE-FETCH OR CACHE FLUSH.
*

*----------+----------*
OVBLEN
+----------+----------+
OVBPTR
+----------+----------+
OVBFLK
+----------+----------+
!
OVBBLK
!
+----------+----------+
OVBTYP!
OVBIOC
!
+----------+----------+
OVBJSB
+----------+----------+
!
OVBSSB
!
+----------+----------+
!
OVBSMT
!
+----------+----------+
!
OVBQLK
+----------+----------+
!
OVBBRB
!
+----------+----------+
FILLOO
+----------+----------+
OVBSTS
FILLO!
+----------+----------+
OVBEXC
!
+----------+----------+
FILL03
+----------+----------+

)00 !
)02
)04
)06
)08
)OA
)OC
)OE
)10
)12
)14
)16
)18
)lA
)lC

Structure Pictures

LENGTH OF SEGME NT
OVERH·EAD BEET
OVERRUN BEET (BEETS)
TSB ADDRESS WHEN BLOCK IS ON TOL
LDT ADDRESS IF BUFFER SEGMENT
FORWARD LINK TO NEXT BLOCK

BACKWARD LINK TO NEXT BLOCK
SE GME NT TYP E
TILINE AND 911 I/O OUTSTANDING
JSB POINTER CORRESPONDING TO OVBPTR
SEGMENT STATUS BLOCK POINTER
TABLE AREA SSB ADDRESS
QUEUE LINK (DEALLOCATE/WRITE Q)
POINTER TO FORCE WRITE BRB
RESERVED
SEGMENT STATUS (IN MEMORY STATUS)
RESERVED
EXECUTION TIME SINCE LOAD
RESERVED FOR FUTURE USE

22-126

2270512-9701

DNOS System Design Document

)IE

OVB

+----------+----------+
OVBTIM

TASK IN MEMORY COUNT

+----------+----------+
FLAGS FOR FIELD: OVBSTS
OVFWRT
OVFROL
OVFUBS

#16 -

SEGMENT STATUS (IN MEMORY STATUS)
SEGMENT ON WRITE QUEUE
FORCE ROLL THIS SEGMENT
USER SEG USED AS FILE BUFFER

(x ••••••••••..•.• ) -

(.X ..•..•.•..•.•. ) ( •• X.~ ••• ~ ••••••• ) -

EQUATES:
LABEL
OVSHDR
OVSDAT
OVSPRO
OVSMEM
OVSFRE
OVSDEL
OVBSIZ

2270512-9701

EQUATE TO
)FF
)00
)01
)02
)03
)04
$

VALUE

DESCRIPTION

)FF
)00
)01
)02
)03
)04
)20

22-127

LIST HEADER = -1
DATA FILE SEGMENT = 0
PROGRAM FILE SEGMENT
1
MEMORY BASED SEGMENT = 2
FREE BLOCK = 3
DEALLOCATE QUEUE SEGMENT

Structure Pictures

OVT

DNOS System Design Document

.***********************************************************

** OVERLAY TABLE ENTRY
*
(OVT)
05/10/79 *
*
*
LOCATION: IN RPSDAT
*
*************************************************************
* THE SYSTEM OVERLAY TABLE (SOV) CONSISTS OF A NUMBER OF
* OVERLAY TABLE ENTRIES (OVT). IT IS BUILT DURING SYSTEM
* GENERATION, BASED ON THE CHOICES REQUESTED THEN.
*----------+----------*
)00
)02

OVTREC

+----------+----------+
OVTSIZ

+----------+----------+
)04

OVTLOD

+----------+----------+

Structure Pictures

RECORD NUMBER OF OVERLAY IMAGE
SIZE OF OVERLAY CODE
NATURAL LOAD ADDRESS OF OVERLAY

22-128

2270512-9701

DNOS System Design Document

PBM

************************************************************

**
**

PARTIAL BIT MAP

(PBM)

*
*
**

03/06/80

LOCATION: DISK, PARTIAL BIT MAP TABLE

************************************************************

*
*
*
*

THE PBM DESCRIBES THE CURRENT ALLOCATION OF A DISK.
THE
IN-MEMORY PBM IS IN THE PARTIAL BIT MAP TABLE SET ASIDE
FOR ONLY PBM TABLES.
EACH TIME A FILE IS CREATED OR
EXTENDED, THE PBM ISUPDATED IN BOTH MEMORY AND DISK
REPRESENTATIONS.

)00
)02
)04

)06
)08

*----------+----------*
PBMMAX
PBMNUM
+----------+----------+
PBMFAU
+----------+----------+
PBMLRC
+----------+----------+
PBMLCB
+----------+----------+
PBMMAP
+----------+----------+
/
/
/
/

**
*
*
*
*
*

NUMBER OF PARTIAL MAPS
PARTIAL MAP NUMBER IN BUFFER
FIRST AVAILABLE ADU ON DISK
LRC CHECKSUM OF MEMORY PBM
ADU OF LARGEST CONTIGUOUS BLK
PARTIAL BIT MAP

+----------+----------+
THIS SECTION MAPS EACH PBM; THE DISK MANAGER CAN EXAMINE
THIS "MAP" TO DETERMINE ON A FIRST-FIT BASIS THE PARTIAL
BIT MAP FROM WHICH TO ALLOCATE WITHOUT SEQUENTIALLY
SEARCHING THE DISK-RESIDENT BIT MAPS.
THE FOLLOWING
STRUCTURE IS REPEATED AS REQUIRED FOR EACH PARTIAL BIT MAP:

*----------+----------*
)00

)02
)04

PBMBIG

+----------+----------+
PBMBGN
!
+----------+----------+
PBMEND
+----------+----------+

LARGEST CONTIGUOUS BLK IN PBM
CONTIGUOUS BLK AT START
CONTIGUOUS BLK AT END

EQUATES:
LABEL
PBMBLK
PBMLEN
PBMTAB

2270512-9701

EQUATE TO

256
PBMBLK/2
$

VALUE

DESCRIPTION

)100
)7FO
)106
22-129

PARTIAL BIT MAP BLOCK SIZE
ADU'S IN PARTIAL BIT MAP
START OF BIT MAP TABLE
Structure

Pictures

PBM

DNOS System Design Document

PBHSIZ
PBMTES

$
$

Structure Pictures

)106
)06

22-130

PBM BUFFER/TABLE SIZE
SIZE OF EACH TABLE ENTRY

2270512-9701

DNOS System Design Document

PDT

************************************************************

** PHYSICAL DEVICE TABLE
*
(PDT)
06/22/83 *
*
*
LOCATION: SYSTEM AREA
*
*
************************************************************
* EACH DEVICE GENERATED INTO A SYSTEM IS REPRESENTED BY A
* PDT. THE PDT IS USED AS A WORK AREA FOR THE DEVICE SERVICE

ROUTINE WHILE PROCESSING REQUESTS FOR THE PARTICULAR DEVICE.

*************************************************************

*----------+----------*
PDTPDT
+----------+----------+
)02
PDTNAM
!
+----------+----------+
)04
!
+----------+----------+
)06
PDTNUM
+----------+----------+
)08
PDTLC
PDTIL!
+----------+----------+
)OA!
PDTCHR
PDTCDT!
+----------+----------+
)OC
PDTCDE
!
+----------+----------+
)OE
PDTFLG
!
+----------+----------+
)10 !
PDTMAP
!
+----------+----------+
/
/
/

)00

DEVICE NAME

DEVICE NUMBER
LUNOS ASSIGNED COUNT
INITIATE REQUEST LIMIT
BID CHARACTER
CDT NUMBER
DEVICE CDE MASK
DEVICE STATUS FLAGS EXTENSION
DSR MAP FILE

+----------+----------+
)lC
PDTJOB
!
+----------+----------+
)lE
PDTRPB
!
+----------+----------+
)20 !
PDTBQ
+----------+----------+
)22 !
PDTRO
!
+----------+----------+
)24
PDTPRB
+----------+----------+
)26
POTDSF
+----------+----------+
) 28!
PDTDTF
PDTTYP
+----------+----------+
)2A
POTOIB
+----------+----------+
)2C !
PDTR5
!
+----------+----------+
2270512-9701

FORWARD LINKAGE TO NEXT POT

JSB ADDRESS OWNER JOB
RESOURCE PRIVILEGE BLOCK POINTER
BID REQUEST QUEUE
RO

- DSR SCRATCH

QUEUED PRB ADDRESS

DEVICE STATUS FLAGS

DEVICE TYPE FLAGS
DEVICE TYPE
- DEVICE INFO BLOCK ADDRESS

22-131

DSR SCRATCH

Structure Pictures

PDT

)2E
)30
) 32
)34
)36
)38
)3A
)3C
)3E
)40
)42
)44
)46
)48
)4A
)4C
)4E
)50
)52
)54
)56
)58
)5A
)5C

DNOS System Design Document

PDTR6

+----------+----------+
PDTR7
+----------+----------+
PDTR8
!
+----------+----------+
PDTR9
!
+----------+----------+
PDTRI0
!
!
+----------+----------+
PDTR 11
!
+----------+----------+
PDTCRU
+----------+----------+
PDTR13
!
+----------+----------+
PDTR14
!
!
+----------+----------+
PDTR15
!
+----------+----------+
PDTERR
PDTRTY
+----------+----------+
PDTRC
!
+----------+----------+
PDTWC
+----------+----------+
PDTMC
!
+----------+----------+
PDTREC
!
!
+----------+----------+
PDTWEC
!
+----------+----------+
PDTMEC
+----------+----------+
PDTSL1
+----------+----------+
PDTSL2
+----------+----------+
PDTBLN
+----------+----------+
PDTTMI
+----------+----------+
PDTTM2
+----------+----------+
PDTHRQ
!
+----------+----------+
PDTWQ
!
+----------+-----~----+

)5E !
)60
)62

PDTSRB

+----------+----------+
PDTERQ
+----------+----------+
PDTSRQ

Structure Pictures

- DSR

DSR SCRATCH
SCRATCH

DSR SCRATCH

RIO

DSR SCRATCH

Rll

DSR SCRATCH

R12

R13

SAVED WP

R14

SAVED PC

R15

DSR SCRATCH

CRU OR TILINE ADDRES S

SAVED ST

SAVED ERROR CODE FOR SYS LOG
RETRIES ATTEMPTED COUNT
READ REQUEST COUNT
WRITE REQUEST COUNT
MISC

REQUEST COUNT

READ

ERROR COUNT

WRITE ERROR COUNT
MISC

ERROR COUNT

SY STEM LOG INFO
SY STEM LOG INFO
MAXIMUM BUFFER LENGTH
TIME OUT COUNT
TIME OUT COUNT DOWN
HIDDEN REQUEST QUEUE
WAITING REQUEST QUEUE
SAVED REQUEST ADDRESS
END -OF-RECORD

QUEUE

SPENT REQUEST QUEUE

22-132

2270512-9701

DNOS System Design Document

)64

PDT

+----------+----------+
PDTPDS
+----------+----------+

FLAGS FOR FIELD:

PDTFLG

PRIORITY DSR SCHEDULER QUE LINK

HOE -, DEVICE STATUS FLAGS EXTENSION

DFGIRB

*
*

(X ••••••••••••••• ) - COpy IRB TO SYSTEM LOG
(.XX ••••••••••••• ) - RESERVED
PDFSTA = ( ••• XX ••••••••••• ) - DEVICE STATE
00 ONLINE
01 OFFLINE
10 DIAGNOSTIC
11 SPOOLER
DFGOPF = ( ••••• X •••••••••• ) - DEVICE OPERATION FAILED
( •••••• X ••••••••• ) - RESERVED
( ••••••• X •••••• i.) - VIRTUAL DEVICE FLAG
DFGVRT
( •••••••• XXXXXXXX) - NIO-KEYBOARD BID OWNER TASK RUN ID
FLAGS FOR FIELD: PDTDSF
DSFCMO
DSFAID
DSFBI
DSFBO
DSFJIS
DSFREN
DSFJAR
DSFJAT

( X •••••••••••••••
( • X ••••••••••••••
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X •••••••••••
( ••••• X ••••••••••

)
)
)
)
)
)

( •••••• X ••••••••• )

(
(
(
DSFWPM
DSFIRE = (
(
DSFINT

••••••• X •••••••• )
•••••••• XX •••••• )
•••••••••• X ••••• )
••••••••••• X •••• )
•••••••••••• XXXX)

FLAGS FOR FIELD: PDTDTF
DTFFIL
DTFTIL
DTFTIM
DTFPRI
DTFKSB
DTFCOM
DTFSYD

#26 -

)
)
)
)
)
)
)
)

DEVICE STATUS FLAGS

OPENED WITH COMM OPEN ()4E)
USE ALTERNATE PDT
BUFFER INPUT
(I=YES)
BUFFER OUTPUT (I=YES)
JISCII FLAG(KATAKANA)
RE-ENTER-ME
JISCII RECEIVE
MODE
JISCII TRANSMIT MODE
RESERVED
WORD PROCESSING MODE
INITIAL REQUEST ENTRY
DEVICE INTERRUPT LEVEL MASK

#28 -

(X •••••••••••••••
(.X ••••••••••••••
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X •••••••••••
( ••••• X ••••••••••
( •••••• X •••••••••
( ••••••• X ••••••••

DEVICE TYPE FLAGS

FILE ORIENTED
TILINE DEVICE
ENABLE TIME-OUT
PRIVILEDGED DEVICE
TERMINAL WITH A KSB
COMM DEVICE
SYSTEM DISC
RESERVED

EQUATES:
LABEL
PDFDSM
PDTOCN
PDTRDN
2270512-9701

EQUATE TO
)1800
PDTMAP
PDTR5

VALUE

DESCRIPTION

)1800
)10
)2C
22-133

DEVICE STATE MASK
VIRT PDTS ONLY-OWNER CHANNEL LEN/NA
VIRT PDTS ONLY-REMOTE DEVICE LEN/NA
Structure Pictures

PDT

DNOS System Design Document

PDTRDJ
PDTSIZ

PDTCRU

)3A

)66

Structure Pictures

22-134

VIRT PDTS ONLY-REMOTE DEVICE JOB ID

2270512-9701

; DNOS System Design Document

PFI

************************************************************

** PROGRAM FILE DIRECTORY INDEX ENTRY (PFI)
04/20/79
**
**
**
LOCATION: DISK
************************************************************
* THE PFI IS USED TO DESCRIBE AN ENTRY IN A PROGRAM FILE.
* ENTRIES CAN BE TASK SEGMENTS, PROCEDURE SEGMENTS, PROGRAM
* SEGMENTS, AND OVERLAYS. IN ADDITION TO A COMMON FIRST
* PORTION, THERE IS A SEPARATE VARIANT FOR EACH TYPE OF
* ENTRY. IN THE FLAG COMMENTS, T INDICATES THE COMMENT APPLIES
* TO A TASK ENTRY, P TO A PROCEDURE ENTRY, S TO A PROGRAM
* SEGMENT ENTRY AND 0 TO AN OVERLAY ENTRY.
*----------+----------*
)00 !
)02

PFILEN

SEGMENT LENGTH (BYTES)

+----------+----------+
PFIFLG

FLAGS

+----------+----------+
) 04 !

P FIRE C

RECORD NUMBER OF START OF IMAGE

+----------+----------+
)06 !

PFIDAT

DATE INSTALLED IN JULIAN FORMAT

+----------+----------+
PFILOD

)08

LOAD ADDRESS IN TASK

+----------+----------+
TYPE DEPENDENT DATA (ANY SET)

*----------+----------*
)OA

PFIVAR

+----------+----------+
)OC

SINGLE PORTION OF DATA

+----------+----------+
)OE !

+----------+----------+
TASK ENTRY DESCRIPTION

*----------+----------*
)OA

PFIOVL

PFIPRI

+----------+----------+
)OC
)OE

PFISGI

PFISG2

+----------+----------+
PFITND

OVERLAY LINK
TASK PRIORITy
ID OF PROCEDURE 1 FOR TASK
ID OF PROCEDURE 2 FOR TASK
TASK LENGTH

+----------+----------+
OV~RLAY

ENTRY DESCRIPTION

*----------+----------*
)OA

PFIOV2

PFITID

+----------+----------+
)OC

PFIOND

OVERLAY LINK
ID OF ASSOCIATED TASK
RESERVED (SET TO ZERO)

+----------+----------+
2270512-9701

22-135

Structure Pictures

PFI

DNOS System Design Document

PROCEDURE/PROGRAM ENTRy DESCRIPTION

)OA

*----------+----------*
PFIPND
!
+----------+----------+

FLAGS FOR FIELD: PFIFLG
PFFPRI
PFFSYS
PFFRES
PFFDEL
PFFREP
PFFSG1
PFFSG2
PFFUSE
PFFOVF
PFFWCS
PFFEXP
PFFWRP
PFFUPD
PFFREU
PFFCPY
PFFSEC

=
=

RESERVED (SET TO ZERO)

#02 - FLAGS
)
)
)
)
)

= ( •••••• X••••••••• )

=
-

(X •••••••••••••••
(.X ••••••••••••••
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X •••••••••••

PRIVILEGED (T)
SYSTEM (T,S)
MEMORY RESIDENT (T,P,S)
DELETE PROTECTED(T,P,S,O)
REPLICATABLE (T,S)
PROC 1 IS ON THE PROG FILE (T)
PROC 2 IS ON THE PROG FILE (T)
PFI ENTRY IS IN USE (T,P,S,O)
OVERFLOW (T)
WRITEABLE CONTROL STORE (T,P,S)
EXECUTE PROTECTED (T,P,S)
WRITE PROTECTED (P,S)
UPDATABLE (T,S)
REUSABLE (T,S)
COPYABLE (T,S)
SECURITY BYPASS (T)

= ( ••••• X•••••••••• ) -

= ( ••••••• X•••••••• ) =

X••••••• ) ( ••••••••• X•••••• ) -

( ••••••••

= ( •••••••••• X••••• )

( •••••••••••• X ••• ) -

( ••••••••••••••• X) -

= ( ••••••••••• X•••• )

= ( ••••••••••••• X•• ) '= ( •••••••••••••• X.) -

*
EQUATES:
LABEL
PFFRED
PFFSHR
PFFSPR
PFISIZ

EQUATE TO
PFFPRI
PFFSG1
PFFWRP
$

Structure Pictures

VALUE

DESCRIPTION

)00
)05

)OB

READABLE (P)
SEG. IS SHARE PROTECTED (S)
SOFTWARE PRIVILEGED (T)

)10

22-136

2270512-9701

DNOS System Design Document

PFZ

*******************************i********************** ******

*
*
PROGRAM FILE RECORD ZERO
(PFZ)
3/7/78
*
*
*
*
LOCATION: DISK
*************************************************************
*
* THE PFZ DESCRIBES THE FIRST RECORD (RECORD 0) OF THE
* PROGRAM FILE.
IT INCLUDES BIT MAPS FOR ALL ELEMENTS IN
* THE PROGRAM FILE AS WELL AS DATA ABOUT CURRENT USE OF
*"THE FILE.

)00

*----------+----------*
PFZRES
+----------+----------+
/
/
/

)14

+----------+----------+
PFZMRT
!
+----------+----------+
/
/
/

)34

+----------+----------+
PFZMRP
+----------+----------+
/
/
/

)54

+----------+----------+
PFZTSK
+----------+----------+
/
/
/

)74

+----------+----------+
PFZPRC
+----------+----------+
/
/
/

)D4
)D6

/
/

BIT MAP - ALL PROCEDURES

BIT MAP - NONREPLICATABLE TASKS

BIT MAP - ALL OVERLAYS

/
/

+----------+----------+
PFZMNT
PFZTO
+----------+----------+
!
PFZTR
+----------+----------+

2270512-9701

BIT MAP - ALL TASKS

+----------+----------+
)B4!
PFZOVL
!
+----------+----------+
/

BIT MAP - MEMORY-RESIDENT PROCEDURES

+----------+----------+
PFZNRT
+----------+----------+
/
/
/
/

BIT MAP - MEMORY-RESIDENT TASKS

)94!

RESERVED

MAXIMUM NUMBER OF TASKS
FIRST TASK DIRECTORY ENTRY OFFSET
FIRST TASK DIRECTORY ENTRY REC #

22-137

Structure Pictures

PFZ

)D8
)DA
)DC
)DE
)EO
)E2

DNOS System Design Document

PFZMNP

PFZPO

+----------+----------+
PFZPR
+----------+----------+
PFZMNO
! . PFZOO
+----------+----------+
PFZOR
+----------+----------+
!
PFZMNH
!
+----------+----------+
PFZHO

+----------+---~------+
PFZHR
!

)E4 !

+----------+----------+

MAXIMUM NUMBER OF PROCEDURES
FIRST PROC DIRECTORY ENTRy OFFSET
FIRST PROC DIRECTORY ENTRy REC #
MAXIMUM NUMBER OF OVERLAYS
FIRST OVLY DIRECTORY ENTRY OFFSET
FIRST OVLY DIRECTORY ENTRY REC #
MAXIMUM NUMBER OF HOLES
FIRST AVAILABLE SPACE LIST OFFSET
FIRST AVAILABLE SPACE LIST REC #

EQUATES:
LABEL
PFZSIZ

EQUATE TO

Structure Pictures

VALUE

DESCRIPTION

)E6

22-138

SIZE OF INFORMATION SECTION OF REC

2270512-9701

DNOS System Design Document

QHR

**********************************~*************************

*
** QUEUE HEADER
(QHR)
09/06/79
*
**
**
LOCATION: SYSTEM ROOT, JCA
*****************************~******************************
* QUEUE HEADERS FOR SYSTEM QUEUE SERVERS THAT RUN IN THE
* SYSTEM JOB ARE BUILT DURING SYSTEM GENERATION IN THE
* SYSTEM ROOT. QUEUE HEADERS FOR SYSTEM QUEUE SERVERS
* THAT RUN IN A USER'S JOB ARE BUILD IN THE JCA WHEN THE
* JOB IS CREATED. EACH QUEUE HEADER FOLLOWS THE QHR FORM.

*----------+----------*
QHRNEW
!
+----------+----------+
)02 !
QHROLD
!
+----------+----------+
)04
QHRCNT!
QHRTID
!
+----------+----------+
)06 !
QHRTSB
!
+----------+----------+
)08 !
QHRJSB
+----------+----------+"
)OA!
QHRLUN
FILLOO!
+----------+----------+
) 00 !

ADDRESS OF NEWEST ENTRY
ADDRESS OF OLDEST ENTRy
NUMBER OF ENTRIES ON QUEUE
SERVER TASK ID
TSB ADDRESS OF SERVER TASK
JSB ADDRESS OF SERVER TASK
PROGRAM FILE LUNO FOR SERVER
RESERVED

EQUATES:
LABEL
QHRSIZ

2270512-9701

EQUATE TO
$

VALUE

DESCRIPTION

)OC

22-139

Structure Pictures

QIR

DNOS System Design Document

************************************************************

**
**

QUEUED IPC REQUEST
LOCATION:

(QIR)

*
*
**

8/15/81

SYSTEM AREA

***************~********************************************

*
*

THE QIR IS PUT ON THE IPC TASK QUEUE WHEN AN IPC REQUEST
CANNOT BE PROCESSED IN FAST TRANSFER IPC.
** BEGINNING PACKED RECORD QIR

*----------+----------*
QIRQIR
!
+----------+----------+
!
QIRJSB
r
+----------+----------+
r
QIRCCB
r
+----------+----------+
SIZE
** END

)00 !

POINTER TO NEXT QIR

)02

JSB ADDRESS OF OWNER
(0 IF GLOBAL CHANNEL)
ADDRESS OF CCB TO BE PROCESSED

)04
)06

Structure Pictures

OF PACKED RECORD

22-140

2270512-9701

DNOS System Design Document

RDB

************************************************************

REQUEST DESCRIPTION BLOCK

(RDB)

OS/21/79

**
*

*
LOCATION: RPSDAT AND SOME SVC PROCESSORS
*************************************************************
*
* THE RDB FOR A GIVEN SVC SPECIFIES HOW TO BUFFER THE USER'S
* REQUEST FOR PROCESSING BY THE SVC PROCESSOR. THE RDB IS
* LOCATED IN THE MODULE RPSDAT BUILT DURING SYSTEM GENERATION
*
*
*
*
*
*

IF THE SVC IS AN OPTIONAL SVC OR IF THE SVC IS PROCESSED BY
A QUEUE SERVER TASK.
OTaERWISE, THE RDB IS LOCATED IN,
THE FIRST PROCESSOR MODULE FOR THE SVC PROCESSOR.
AN RDB
EXISTS FOR A GIVEN SVC ONLY IF THE CALL BLOCK MUST BE
BUFFERED INTO A PORTION OF MEMORY FOR THE DURATION OF THE
PROCESSING.

*----------+----------*
RDBFLG
!
+----------+----------+
)02 !
RDBSRV
+----------+----------+
)04
RDBRIB
+----------+----------+
) 06 !
RDBMAX
!
+----------+----------+
)08!
RDBBAS
!
RDBACC
!
+----------+----------+
)OA
FILLOI
+----------+----------+
)OC!
RDBEXP
RDBLEN
+----------+----------+
)OE
RDBCOF
RDBBOF
+----------+----------+
)00

FLAGS FOR FIELD: RDBFLG
RDFEXT
RDFRST
RDFRPT
RDFQOP
RDFSOD
RDFDSJ =
RDFREV
RDFINT =

RDFQIJ

ADDRESS OF PROCESSOR ENTRY OR
QUEUE HDR ADDRESS{RDFQIJ=O) OR
ADDRESS OF RETURN INFORMATION BLOCK
MAXIMUM BUFFER LENGTH (BYTES)
BASIC REQUEST BLOCK LENGTH (BYTES)
ACCOUNTING WEIGHTING FACTOR
RESERVED FOR FUTURE USE
EX PAN S ION FL AGS
EXPANSION LENGTH TO BUFFER
OFFSET IN CALL BLOCK
OFFSET IN BRB (O=CONTINUE FROM LAST
#00 - DESCRIPTION FLAGS

( •• X ••••••••••••• ) ( ••• X •••••••••• ~.) ( •••• X ••••••••••• ) ( ••••• X •••••••••• ) ( •••••• X ••••••••• ) ( ••••••• X •••••••• ) -

EXTENSIONS TO THE RDB(I=YES)
REQUIRES SYSTEM TASK (I=YES)
REQUIRES SOFT.PRIVILEGED TASK
QUEUE SERVER(O) OR PROCESSOR
STATIC(O) OR DYNAMIC BUFFER
DYNAMIC BUFFER - STA(O) OR JCA
REVISING A BUFFER (I=YES)
CAN(I) OR CANNOT(O) BE
AN INITIATED EVENT
( •••••••• X ••••••• ) - QUEUE HDR IN STA(O) OR JCA
( ••••••••• XXXXXXX) - RESERVED

( X ••••••••••••••• )
( • X •••••••••••••• )

FLAGS FOR FIELD: RDBEXP
2270512-9701

DESCRIPTION FLAGS

HOc - EXPANSION FLAGS
22-141

Structure Pictures

DNOS System Design Document

RDB

*
*
*
*
*
*

RDFTYP = ( X••••••••••••••• )

RDFJCA = ( • X •••••••••••••• )
RDFMOR
( •• X••••••••••••• )

RDFJAV = ( ••• X •••••••••••• )
= ( •••• XXXX •••••••• )

TYPE OF CALL BLOCK OFFSET PTR
O=START OF DATA WITH RDBLEN
BYTES TO BUFFER
l=POINTER TO EXPANSION
BLOCK WITH OWN LENGTH
BYTE AND DATA BUFFER
l=BUFFER THIS IN JCA BY ITSELF
- MORE EXPANSION BLOCKS (l=YES)
(AFTER THIS ONE)
l=WERE ABLE TO GET JCA SPACE
- RESERVED

EQUATES:
LABEL
RDBSIZ

EQUATE TO
$

Structure Pictures

VALUE

DE SCRIP TION

)10

22-142

2270512-9701

DNOS System Design Document

RIB

************************************************************

**
*
*
LOCATION: RPSDAT AND SVC PROCESSORS
*
*
************************************************************
* THE RIB FOR A GIVEN SVC TELLS HOW MUCH AND WHERE TO
* RETURN INFORMATION FROM A BUFFERED CALL BLOCK THAT WAS
* USED BY THE SVC PROCESSOR. THE RIB IS IN THE MODULE
* RPSDAT BUILT DURING SYSTEM GENERATION IF THE SVC IS AN
* OPTIONAL SVC OR IS ONE PROCESSED BY A QUEUE SERVER TASK.
* OTHERWISE THE RIB IS IN ONE OF THE SVC PROCESSOR MODULES.
* THE RIB FOR A PARTICULAR SVC IS ACTUALLY SPECIFIED AS ONE
* FIELD FOR RIBPRO, THEN ANY NUMBER OF PAIRS OF VALUES FOR
* OFFSET AND LENGTH, THEN A WORD OF ZERO TO TERMINATE THE RIB.
RETURN INFORMATION BLOCK

(RI B)

*----------+----------*
RIBPRO
!
+----------+----------+
RIBOFF!
RIBLEN
!
+----------+----------+

02/08/79

)00 !

POSTPROCESSOR (IF SPECIAL ONE)

)02

CALL BLOCK OFFSET
LENGTH TO UNBUFFER (BYTES)

EQUATES:
LABEL
RIBSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)04

22-143

Structure Pictures

RLT

DNOS System Design Document

***************************************************************

* RECORD LOCK TABLE
(RLT)
05/09/79
*
**
LOCATION: SYSTEM TABLE AREA OR USER JCA
**
*
(WHEREVER FCB IS LOCATED)
*
***************************************************************
* FOR A FILE WHICH HAS LOCKED RECORDS, EACH LOCKED RECORD IS
* REPRESENTED BY A RLT CHAINED TO THE FILE CONTROL BLOCK OF
* THAT FILE.

*----------+----------*
RLTRLT
!
+----------+----------+
!
RLTLDT
!
+----------+----------+
RLTTSB
+----------+----------+
!
RLTJSB
!
+----------+----------+
RLTBN
+----------+----------+
!
!
+----------+----------+
!
RLTOFF
+----------+----------+

)00 !

NEXT TABLE ENTRy ADDRESS

)02

LOCKING LDT ADDRESS

)04

)06
)08
)OA
)OC

LOCKING TSB ADDRESS
OWNER JSB ADDRESS
LOCKED BLOCK NUMBER

LOCKED OFFSET

EQUATES:
LABEL
RLTSIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)OE

22-144

2270512-9701

DNOS System Design Document

ROB

************************************************************

**
**

RESOURCE OWNERSHIP BLOCK

(ROB)

08/29/83

LOCATION: JCA

**
**

************************************************************

*
*
*

AN ROB IS BUILT FOR AN I/O RE.SOURCE WHEN AN ATTACH RESOURCE
OPERATION IS PERFORMED. THE ROB IS LINKED INTO THE ROB
LIST ANCHORED IN THE JCA.

)00
)02
)04
)06

*----------+----------*
ROBROB
!
+----------+----------+
ROBACT
ROBATN!
+----------+----------+
ROBFMT
+----------+----------+
ROBFCB
!
+----------+----------+

NEXT ROB ADDRESS
ATTACHED COUNT
ATTACH NUMBER

EQUATES:
LABEL
ROBSIZ

2270512-9701

EQUATE TO
$

VALUE

DESCRIPTION

)08

22-145

Structure Pictures

DNOS System Design Document

RPB

************************************************************

** RESOURCE PRIVILEGE BLOCK (RPB)
*
08/30/83 *
*
*
LOCATION: SYSTEM AREA OR JCA
*************************************************************
*
* AN RPB IS BUILT FOR AN I/O RESOURCE WHEN A LUNO IS ASSIGNED.
* IT IS ATTACHED TO THE APPROPRIATE RESOURCE STRUCTURE: CCB,
* FCB, OR PDT.

*----------+----------*
RPBRPB
t
+----------+----------+
)02!
RPBFLG
RPBCFI
+----------+----------+
)04
RPBLDT
+----------+----------+
)06
RPBJSB
!
+----------+----------+
)08
RPBLRN
!

LINK TO NEXT RP B

)00 t

FLAG BYTE
CURRENT FILE INDEX (CONCAT. FILES)
LDT ADDRESS
JSB ADDRESS
LOGICAL RECORD NUMBER

+-- -~- - - - - - -+- - - - - - - - - - +
)OA

+----------+----------+
RPBBN
!
+----------+----------+
!
!
+----------+----------+
!
RPBOCB
+----------+----------+

)OC !
)OE
)10

FLAGS FOR FIELD: RPBFLG

*
*
*
*

BLOCK NUMBER

OFFSET IN CURRENT BLOCK

1102 -

RPFATT = ( X•••••••••••••••
RPFOPN = ( • X••••••••••••••
RPFFBS
( •• X•••••••••••••
( ••• XXX ••••••••••
RPFACU = ( •••••• XX ••••••••

)
)
)
)
)

FLAG BYTE
1 = ATTACHED
1 = LUNO OPEN

1
FORWARD OR BACK SPACE
RESERVED
ACCESS PRIVILEGES IN USE
00 = EXCLUSIVE WRITE
EXCLUSIVE ALL
01
SHARED
10
11
READ ONLY

EQUATES:
LABEL
RPBACM
RPBMSZ
RPBSIZ

EQUATE TO
>0300
$
$

Structure Pictures

VALUE

DESCRIPTION

>300
>08
>12
22-146

ACCESS PRIVILEGES BIT MASK
MINIMUM SIZE
RPB SIZE
2270512-9701

DNOS System Design Document

RST

************************************************************

*
*
**

RESERVE SEGMENT TABLE
LOCATION:

09/21/81

(RST)

JCA

*
*
**

************************************************************

*
*
*

THE RST DESCRIBES ALL OF THE SEGMENTS THAT A JOB HAS
RESERVED WITH A RESERVE SEGMENT SVC CALL.
EACH ENTRY IS:
SEGMENT SSB ADDRESS
SEGMENT SMT ADDRESS

MAX NUMBER OF ENTRIES IN RST

)00
)02

*----------+----------*
I
RSTRST
I
+----------+----------+
!
RSTSID
!
+----------+----------+
/
/

)22

/
/

LINK TO NEXT RST
ID'S OF RESERVED SEGMENTS (MAX 8)
(ZERO IF ENTRY NOT IN USE)

/
/

+----------+----------+
FILLOO
I RSTALC
+----------+----------+

RESERVED FOR FUTURE USE
NUMBER OF ALLOCATED ENTRIES (MAX 8)

EQUATES:
LABEL
RSTCNT
RSTSIZ

2270512-9701

EQUATE TO
8

VALUE

DESCRIPTION

)08
)24

22-147

MAX NUMBER OF ENTRIES IN RST

Structure Pictures

SAT

DNOS System Design Document

************************************************************

**
**

SECONDARY ALLOCATION TABLE (SAT)

01/25/77

LOCATION:JCA OR SYSTEM AREA, WITH FCB

**
**

************************************************************

*
*

THE SLr SHOWS THE NUMBER AND LOCATION OF SECONDARY FILE
ALLOCATIONS.
COUNT OF SAT ENTRIES

*----------+----------*

)00 !

SATASZ

+----------+----------+
)02
SATADU
!
+----------+----------+
)04!
FILLOO
+----------+----------+
/
/
/
/

ALLOCATION SIZE
ALLOCATION START
REMAINDER OF BLOCK

+----------+----------+
EQUATES:
LABEL
SATNSA
SATSIZ

EQUATE TO

VALUE

)10

)40

Structure Pictures

DESCRIPTION

22-148

COUNT OF SAT ENTRIES

2270512-9701

DNOS System Design Document

SCO

************************************************************

**
**

TRACK 0, SECTOR 0

(SCO)

09/09/83

LOCATION: TRACK 0, SECTOR 0 OF EACH DISK

**
**

************************************************************
)00

*----------+----------*
SCOVNM
+----------+----------+
/
/
/
/

+----------+----------+
)08
SCOTNA
+----------+----------+
)OA!
SCOSBM
SCOT,BM
+----------+----------+
)OC
SCORL
+----------+----------+
)OE
SCOSLT
+----------+----------+
)10
FILLOO
+----------+----------+
) 12 !
!
+----------+----------+
)14
+----------+----------+
)16
SCONBA
!
+----------+----------+
)18
SCOSLE
+----------+----------+
)IA
SCOSLL
!
+----------+----------+
)IC
FILLO!
+----------+----------+
/
/
/
/

)2E

SYSTEM LOADER TRACK ADDRESS

* *

RESERVED

* *

TOTAL SCO BAD ADU ON DISK
SYSTEM LOADER ENTRy POINT
SYSTEM LOADER LENGTH

* *

RESERVED

* *

SYSTEM LOADER TRACK (COpy 2)

* *

RESERVED

* *

PRIMARY SYSTEM FILE NAME

+----------+----------+
SCOPI2

2270512-9701

STARTING SECTOR OF BIT MAPS
TOTAL SCO BIT MAPS
TRACK 0 RECORD LENGTH

+----------+----------+
SCOPIl!
+----------+----------+
/
/
/
/

)36

TOTAL SCO ADU ON DISK

+----------+----------+
)24
SCOLTI
+----------+----------t
)26!
FILL02
+----------+----------+
/
/
/
/

VOLUME NAME

SECONDARY SYSTEM FILE NAME

22-149

Structure Pictures

DNOS System Design Document

SCO

+----------+----------+
/
/

/
/

+----------+----------+
SCOPIF
+----------+----------+
)40 !
SCOVDA
!
+----------+----------+
)42 !
SCOVPL
+----------+----------+
)44
SCOSPA
+----------+----------+
)46!
SCODCD
!
!
+----------+----------+
)48 !
+----------+----------+
)4A!
SCOPFI
!
!
+----------+----------+

)3E

/
/

+----------+----------+
SCOPF2
!
!
+----------+----------+
/
/

+----------+----------+
SCOPFF
!
+----------+----------+
)5C!
SCOOF1
+----------+----------+
/
/

+----------+----------+
SCOOF2
!
+----------+----------+

)6C
)6E

/
/

)76

)80

PRIMARY PROGRAM FILE

SECONDARY PROGRAM FILE

PROGRAM FILE SWITCH
PRIMARY OVERLAY FILE

SECONDARY OVERLAY FILE

OVERLAY FILE SWITCH
PRIMARY INTERMEDIATE LOADER

/
/

+----------+----------+
SCOIL2!
!
+----------+----------+

SECONDARY INTERMEDIATE LOADER

+----------+----------+
SCOILF
!
+----------+----------+

INTERMEDIATE LOADER FLAG

/
/

)7E

DISK CREATION DATE

/
/

+----------+----------+
SCOOFF
+----------+----------+
SCOILI
+----------+----------+
/
/

SECTORS/ADU

/
/

)64!

/
/

VCATALOG PHYSICAL RECORD LENGTH

/
/

)5A !

/
/

VOLUME DIRECTORY ADU SCO

/
/

)52!

/
/

SYSTEM SELECTOR

/
/

SCODIN

Structure Pictures

/
/

DIAGNOSTIC FILE NAME

22-150

2270512-9701

DNOS System Design Document

SCO

+----------+---------~+

/
/

+----------+----------+
SCODIF
!
+----------+----------+
)8A !
SCODRS
!
+----------+----------+
)8C !
SCOBAL
!
+----------+----------+
)8E !
SCOSPR
+----------+----------+
) 9 O!
S C0 WF 1
!
!
+----------+----------+
)88 !

DIAGNOSTIC FLAG
DBUILD DETERMINES DEFAULT PRS
STARTING SECTOR OF BAD ADU LIST
TRACK 0 SECTORS PER RECORD
WCS PRIMARY MICROCODE FILE

1 / /

+----------+----------+
SCOWF2
!
+----------+----------+

)98!

/
/

WCS SECONDARY MICROCODE FILE

/
/

+----------+----------+
SCOWFF
!
+----------+----------+
!
SCOVIF
!
+----------+----------+
!
SCOSTA
!
+----------+----------+
SCODCT
+----------+----------+
!
SCOFSF
!
+----------+----------+

)AO !

WCS FLAG SWI TCR

)A2

TRACK 1 SELECT FLAG

)A4
)A6
)A8

STATE OF DISK
1 - NOT AN AL Y ZE D
DISK CREATION TIME

* *

RESERVED

* *

EQUATES:
LABEL
SCOSIZ

2270512-9701

EQUATE TO
$

VALUE

DESCRIPTION

)AA

22-151

Structure Pictures

SDB

DNOS System Design Document

************************************************************

*
*
**

STAGE DESCRIPTOR BLOCK
LOCATION:

(SDB)

07/16/81

A NAME DEFINITION SEGMENT

**
**

************************************************************

*----------+----------*
SDBSDB
!
+----------+----------+
)02
SDBCID
SDBSNO!
+----------+----------+
)04!
SDBTCT
SDBRES!
+----------+----------+
)06 !
SDBPAR
!
+----------+----------+
)08 !
SDBDEL
!
+----------+----------+

)00

Structure Pictures

FIXED LINK
CREATOR TASK ID
STAGE NUMBER
TASK COUNT
RESERVED
POINTER TO PARENT SDB
DESCENDANT ERROR LIST ANCHOR

22-152

2270512-9701

DNOS System Design Document

SGB

************************************************************

**
** SEGMENT GROUP BLOCK (SGB)
04/09/81
**
LOCATION: SEGMENT MANAGER TABLE AREA
**
************************************************************
* THE SGB IS AN ANCHOR FOR SSBS OF SEGMENTS WHICH FORM A
* LOGICAL SET. IT IS USED TO ACCESS SSBS FOR SEGMENT
* MANAGER CALLS MADE BY LUNO.
*----------+----------*
SGBSGB

)00 !

)02
)04

)06
)08

)OA
)OC

POINTER TO NEXT SGB IN TABLE

+----------+----------+
!
SCBOMT
!
+----------+----------+
SGBOCB
!
+----------+----------+
!
SGBSSB
I
+----------+----------+
SGBFLG
+----------+----------+
SGBFMT
+----------+----------+
!
SGBFCB
!
+----------+----------+

FLAGS FOR FIELD:
SGFPFL
SGFDFL
SGFMBS
SGFRES

=
=
=

SGBFLG

SMT SSB POINTER FOR OVERFLOW SGB
SGB SSB POINTER FOR OVERFLOW SGB
SSB LI ST HEADER
FLAGS
FDP FOR THE SEGMENT GROUP

1108 -

(X ••••••••••••••• )
(.X •••••••••••••• )
( •• X••••••••••••• )
( ••• XXXXXXXXXXXXX)

FLAGS

- PROGRAM FILE SEGMENT GROUP
- DATA FILE SEGMENT GROUP
- MEMORY-BASED SEGMENT GROUP
- RESERVED

EQUATES:
LABEL
SGBOSB
SGBOLK
SGBSIZ

2270512-9701

EQUATE TO
SGBOMT
SGBOGB
$

VALUE

DESCRIPTION

)02
)04
)OE

22-153

Structure Pictures

SLB

DNOS System Design Document

************************************************************

*
(SLB)
02/08/82 *
* SYSTEM LOG BLOCK FORMATS
**
LOCATION: SYSTEM AREA
**
************************************************************
* THIS TEMPLATE INCLUDES FORMATS FOR SEVERAL TYPES OF SYSTEM
* LOG MESSAGES. EACH FORMAT INCLUDES THE SAME QUEUE LINK
* FIELD AND FLAGS FIELD. EACH ALSO HAS A 4 BYTE TYPE FIELD.
* OTHER FIELDS ARE PARTICULAR TO A TYPE OF LOG BLOCK BEING
* BUILT.
COMMON PORTION FOR ALL TYPES

*----------+----------*
)00 !

SLBSLB

QUEUE LINK

BLOCK TYPE
COUNT OF LOST MESSAGES
BINARY DAY

+----------+----------+

)02!
)04

SLBFLG

SLBCNT

+----------+----------+
SLBDAY

+----------+----------+
)06 !

SLBHR

)08

SLBMIN

+----------+----------+

)OA

BINARY MINUTES

+----------+----~-----+

SLBTYP!

/
/

+----------+----------+
/
/

BINARY HOUR

LOG BLOCK TYPE

+----------+----------+
TYPE 1 -

*----------+----------*
) 12!

SLBEC

SLBSTI

+----------+----------+

)14 !

SLBJOB

+----------+----------+
)16

SLBIID

SLBRID

+----------+----------+

DEVICE ERROR WITH IMAGE

ERROR CODE
STATION ID
JOB ID
TASK INSTALLED ID
TASK RUN ID

*----------+----------*
)18!

SLBLUN

SLBRTY!

)lA

SLBRSF

SLBACT!

+----------+----------+

)lC

+----------+----------+

LUNO
RETRY COUNT
RETRY SUCCESS(O)/FAILURE(l)
IMAGE WORD COUNT

*----------+----------*
SLBAIM

AFTER IMAGE

+----------+----------+
/
/

/
/

Structure Pictures

/
22-154

2270512-9701

SLB

DNOS System Design Document

)2C

+----------+----------+
SLBBIM
I
+----------+----------+
/
/

/
/

BEFORE IMAGE

/
/

+----------+----------+
TYPE 2 -

)lC

*----------+----------*
I
SLBIRB
I
+----------+----------+
/
/

/
/

DEVICE ERROR WITH CALL BLOC

SPACE FOR 12 BYTES OF CALL BLK

/
/

+----------+----------+
TYPE 3 - ABNORMAL TASK TERMINATION

*----------+----------*
SLBWP
I
+----------+----------+
!
SLBPC
!
+----------+----------+
I
SLBST
!
+----------+----------+

)18 I

WORKSPACE POINTER AT ERROR

) 1A

PROGRAM COUNTER

)lC

STATUS AT ERROR

TYPE 4

)12
)14
)16
)18
)lA
)lC

*----------+----------*
SLBRDG
!
!
+----------+----------+
SLBWRG
!
!
+----------+----------+
SLBOTG
!
!
+----------+----------+
SLBRDB
!
!
+----------+----------+
SLBWRB
r
!
+----------+----------+
SLBOTB
!
!
+----------+----------+

NUMBER OF GOOD READS
NUMBER OF GOOD WRITES
NUMBER OF GOOD OTHER OPS
NUMBER OF BAD READS
NUMBER OF BAD WRITES
NUMBER OF BAD OTHER OPS

TYPE 5 -

*----------+----------*
SLBLEN
FILLOO
+----------+----------+
) 1 4!
S L BUM S
I
!
+----------+----------+

)12

/
/

STATISTICS-- FROM A DSR

USER ISSUED SYSTEM LOG- SVC

LENGTH OF USER MESSAGE
RESERVED
USER MESSAGE BEGINS HERE

/
/

+----------+----------+
I
+----------+

)0112 !

TYPE 6 - MEMORY CACHE ERRORS

*----------+----------*
2270512-9701

22-155

Structure Pictures

SLB

)12
)14
)16
)18

DNOS System Design Document

SLBANK

SLBPRA

+----------+----------+
SLBPRB
SLBBA6
+----------+----------+
SLBME6
SLBEVN
+----------+----------+
SLBAD6
+----------+----------+

BANK (A OR B)
ADDRESS PARITY IN BANK A (G/B)
ADDRESS PARITY IN BANK B (G/B)
BASE ADDRESS OF CONTROLLER
AMOUNT OF MEMORY
ERROR ON EVEN WORD (YIN)
TPCS ADDRESS

TYPE 7 - MEMORY PARITy ERRORS

*----------+----------*
)12!
SLBBIT
SLBROW
+----------+----------+
)14
SLBCOR
SLBBA7
+----------+----------+
)16
SLBME7
SLBCTY
+----------+----------+
)18
SLBAD7
+----------+----------+

BIT IN ERROR
ROW IN ERROR
CORRECTABLE? (yIN)
BASE ADDRESS OF CONTROLLER
AMOUNT OF MEMORY
CONTROLLER TYPE
TPCS ADDRESS

EQUATES:
LABEL

-----

SLBVRI
SLBVR2
SLBVR3
SLBSZl
SLBSZ2
SLBSZ3
SLBSZ4
SLBMXL
SLBSZ5
SLBSZ6
SLBSZ7

EQUATE TO

---------

$
$
$
$-SLBSLB
$-SLBSLB
$-SLBSLB
$-SLBSLB
255
$-SLBSLB
$-SLBSLB
$-SLBSLB

Structure Pictures

VALUE

-----

)12
)18
)IC
)3C
)28
)IE
)IE
)FF
)113
)lA
)IA

DESCRIPTION

------------------------------

22-156

DEVICE MESSAGE SIZE

MAX USER LENGTH

2270512-9701

DNOS System Design Document

SLH

************************************************************

**
**

SEMAPHORE LIST HEADER

(SLH)

03/15/79

LOCATION: JCA

*
*
**

************************************************************

*
*
*
*

THE SLH IS USED TO DESCRIBE SEMAPHORES USED IN JOBS.
FOR
EACH SEMAPHORE IN USE, THERE IS A LIST HEADER SHOWING THE
NUMBER OF THE SEMAPHORE, ITS VALUE, AND THE ENTRIES WAITING
FOR SEMAPHORE ACTION.

*----------+----------*
)00 !

SLHSLH

+----------+----------+

)02!

SLHVAL

SLHNUM!

+----------+----------+

)04 !

SLHNEW

)06

SLHOLD

+----------+----------+

)08

+----------+----------+
SLHCNT

SLHTID

+----------+----------+
)OA

SLHTSB

+----------+----------+

NEXT SEMAPHORE ENTRY
SEMAPHORE VALUE
SEMAPHORE NUMBER
ADDRESS OF NEWEST ENTRy
ADDRESS OF OLDEST ENTRY
NUMBER OF ENTRIES ON QUEUE
SERVER TASK ID
(NOT USED)
TSB ADDRESS OF SERVER TASK(NU)

EQUATES:
LABEL
SLHSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)OC

22-157

Structure Pictures

DNOS System Design Document

SMR

***********************************************************
*
SEGMENT MANAGEMENT REQUEST
(SMR)
11/05/81
*

*
*
LOCATION: SYSTEM TABLE AREA
*
************************************************************
* THE SMR IS A SEGMENT MANAGEMENT SVC BLOCK WITH SEVERAL
* ADDITIONAL FIELDS DEFINED FOR USE BY SEGMENT MANAGER
* DURING PROCESSING OF THE SVC.

*----------+----------*
SMRSVC
!
SMRERR
!
+----------+----------+
SMROP
SMRLUN!
+----------+----------+
SMRFLG
!
+----------+----------+
SMRNS1
+----------+----------+
SMRNS2
+----------+----------+
SMROSG
!
+----------+----------+
!
SMRADR
+----------+----------+
!
SMRLEN
!
+----------+----------+
SMRATR
+----------+----------+
!
SMRFMT
+----------+----------+
!
SMRFCB
+----------+----------+

)OO!
)02
)04
)06
)08
)OA
)OC
)OE
)10
)12
)14

FLAGS FOR FIELD:

SMRFLG

SVC CODE
ERROR CODE
SEGMENT MANAGER SUB-OPCODE
LOGICAL UNIT
FLAGS
NEW SEGMENT ID WORD 1
NEW SEGMENT ID WORD 2
OLD SEGMENT ID
SEGMENT ADDRESS
SEGMENT LENGTH
SEGMENT ATTRIBUTE (AS IN 8SB)
FDP ADDRESS

1'04 - FLAGS

( X •••••••••••••••
SMFINS
SMFNMD
( • X••••••••••••••
SMFREL = ( •• X •••••••••••••
SMFMBS
( ••• X••••••••••••
SMFPOS
( •••• X •••••••••••

*
*
SMFTSK
SMFVLD
SMFSRE
SMFSEU

( ••••• X ••••••••••
( •••••• X •••••••••
( ••••••• X ••••••••
( •••••••• X •••••••

SMFSYS

( ••••••••• X ••••••

*
*
( •••••••••• XXXX ••
Structure Pictures

)
INSTALLED ID
)
NOT MODIFIED
) - RELEASABLE
)
MEMORY BASED
) -'0 IF POSITION NUMBER SPECIFIED
FOR OLD SEGMENT. 1 IF RUNTIME
ID SPECI FI ED.
)
TASK SEGMENT
)
VERIFY PROG. FILE LOAD ADDR
) - SET/RESET FLAG ENABLE
)
SET/RESET FLAG
l=)SET EXCLUS IVE USE
O=)RESET EXCLUS IVE USE
) - SYSTEM TASK
)
***RESERVED***

22-158

2270512-9701

DNOS System Design Document

SMFPSN

SMR

POSITION NUMBER(1,2,

( •••••••••••• ".,. XX)

OR 3)

EQUATES:
LABEL
SMRSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)16

22-159

Structure Pictures

SMT

DNOS

System Design Document

************************************************************

*
*
SEGMENT MANAGER TABLE (SMT)
1/30/79
*
*
*
*
LOCATION: USER MEMORY
*
*
************************************************************
* THE SMT IS THE TEMPLATE FOR THE STATIC DEFINITIONS IN
* THE SEGMENT MANAGER SPECIAL TABLE AREAS.
STARTS AFTER MM OVERHEAD

*----------+----------*
)00 !

SMTSGB

SGB LIST HEADER

)02

SMTRID

LAST RUN ID ALLOCATED

+----------+----------+
+----------+----------+
SMTMAP

)04

+----------+----------+
/
/

/
/

ALLOCATED RUN ID BIT MAP

/
/

+----------+----------+

Structure Pictures

22-160

2270512-9701

DNOS System Design Document

SOB

************************************************************

** SEGMENT OWNER BLOCK
(SOB)
09/23/81
**
*
*
LOCATION: SMT
*
*************************************************************
* THE SOB IS USED TO IDENTIFY THE TASK WHICH HAS EXCLUSIVE
* USE OF A SEGMENT. IT IS LINKED TO THE SSB.
*----------+----------*
)00 !

SOBJSB

.JSB ADDRESS OF SSB OWNER

)02

SOBTSB

TSB ADDRESS OF SSB OWNER

+----------+----------+
+----------+----------+

EQUATES:
LABEL
SOBSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)04

22-161

Structure Pictures

SOV

DNOS System Design Document

************************************************************

** SYSTEM OVERLAY LOAD TABLE
*
(SOV)
09/09/83 *
*
*
LOCATION: SYSTEM ROOT
*****~*******************************************************
*
* THE SOV IS BUILT DURING SYSTEM GENERATION AS PART OF THE
* MODULE SOVT, DEPENDING ON THE OPTIONS CHOSEN DURING THE
* GENERATION. THE FORMAT OF EACH ENTRY IS SHOWN IN THE OVT.
**

BEGINNING PACKED RECORD SOV

*----------+----------*
)00

FMORWT

+----------+----------+

)02

FM REWRITE RECORD OVERLAY

+----------+----------+
)04 !

+----------+----------+

)06 !

)08
)OA

FMOMSC

+----------+----------+

FM WEOF,CLOSE/EOF,OPEN REWIND,UNLK

+----------+----------+
+----------+----------+

)OC

FMOEXT

+----------+----------+

FM EXTEND FILE ALLOCATION OVERLAY

)OE

+----------+----------+
) 10 !

+----------+----------+

)12
)14

FMOOPX

FM OPEN EXTEND OVERLAY

+----------+----------+
!

+----------+----------+
)16

+----------+----------+
KMOINS

)18

+----------+----------+

KM INSERT PROCESSOR

)IA

+----------+----------+
!

) 1C

+----------+----------+
)IE !

KMODLS

+----------+----------+

KM DELETE AND SET CURRENCY

)20

+----------+----------+
)22

+----------+----------+
)24 !
)26

KMOOPC

+----------+----------+

Structure Pictures

KM OPEN AND CLOSE PROCESSORS

22-162

2270512-9701

SOV

DNOS System Design Document

)28
)2A
)2C
)2E

+----------+----------+
~

+----------+----------+
KMOBDE

+----------+----------+
+----------+----------+
+----------~----------+

)30 !
)32
)34

KM DELETE SUBROUTINES

KMOBTI

+----------+----------+

KM B-TREE SPLIT FOR KMBTI

+----------+----------+
+----------+----------+

) 36 !

KMORWS

+----------+----------+

)38 !

KM REWRITE SUBROUTINES

+----------+----------+

)3A !

+----------+----------+

) 3C !

DMALLC

+----------+----------+

)3E
)40

DM ALLOCATION SCAN OVERLAY

+----------+----------+
+----------+----------+

)42
)44

DMCHPM

)4A
)4C
)4E

DM CHANGE PARTIAL BIT MAPS

+----------+----------+

)46 !
)48

+----------+----------+
!

+----------+----------+
CFDFOV

+----------+----------+

IU CREATE/DELETE FILE OVERLAY

+----------+----------+
+----------+----------+
OTHOVI

+----------+----------+

IU OTHER FUNCTIONS OVERLAY·

)50 !

+----------+----------+

)52 !

+----------+----------+

)54 !
)56

OTHOV2

+----------+----------+

IU RF, AA, DA, CIC, DIC OVERLAY

+----------+----------+
)58
)SA

+----------+----------+
PMERRS

+----------+----------+

2270512-9701

PM ERROR PROCESSING SUBROUTINES

22-163

Structure Pictures

SOV

)5C
)5E
) 60
)62
)64

)66

)68
)6A
)6C
) 6E
)70
)72

DNOS System Design Document

+----------+----------+
+----------+----------+
!
KMOPLR
!
+----------+----------+
+----------+----------+
+----------+----------+
SECMGR
+----------+----------+!
+----------+----------+
+---~------+----------+

KMORWT

+----------+----------+
!
!
+----------+----------+
+----------+----------+
SIZE
** END

Structure Pictures

KM PARTIAL LOG ERROR RECOVERY

IU SECURITY MANAGER OVERLAY

KM REWRITE MAIN ROUTINE

OF PACKED RECORD

22-164

2270512-9701

DNOS System Design Document

SSB

************************************************************

*
*
SEGMENT STATUS BLOCK (SSB)
09/09/83 *
*
*
LOCATION:
ROOT AND SEGMENT MANAGER TABLE AREA *
*************************************************************
*

* EACH SEGMENT WHICH IS IN MEMORY IS DESCRIBED BY AN SSB.
* THE SSB INCLUDES CHARACTERISTICS OF THE SEGMENT, LOCATION,
* AND USE INFORMATION.

**
*
*

SPECIAL FIELD COMMENTS:
SSBWCT -

*
*

THIS FIELD IS USED TO KEEP TRACK OF THE AMOUNT
OF FREE AREA IN A SPECIAL TABLE AREA.
APPLIES
TO SSB'S FOR SMT'S AND FMT'S.

* SSBIDI/2 - THIS FIELD CONTAINS THE BLOCK NUMBER FOR A
*
SEGMENT WHICH IS ASSOCIATED WITH A DATA FILE.

*
)00

*----------+----------*
SSBSSB

SSB LINK

+----------~----------+

)02
)04
)06
)08
)OA
)OC
)OE
)10
)12
)14
)16
)18
)lA
)IC

SSBIDI
+----------+----------+
SSBID2
+----------+----------+
SSBRID
+----------+----------+
SSBATR
+----------+----------+
!
SSBRCT
!
+----------+----------+
SSBUCT
+----------+----------+
SSBSGB
+----------+----------+
SSBADR
+----------+----------+
!
SSBLEN
+----------+----------+
SSBREC
+----------+----------+
SSBLOD
+----------+----------+
!
SSBFLG
+----------+----------+
SSBOVL
SSBPRI!
+----------+----------+
!
SSBSTE
+----------+----------+

2270512-9701

SEGMENT INSTALLED ID FIRST WORD
SEGMENT INSTALLED ID SECOND WORD
SEGMENT RUN-TIME ID
SEGMENT ATTRIBUTES
SEGMENT RESERVE COUNT
SEGMENT USE COUNT
SEGMENT GROUP BLOCK POINTER
SEGMENT BEET ADDRESS (PTS TO OVB+l)
LENGTH OF SEGMENT (BYTES)
REC. # OF PF SEG. ON HOME FILE
LOAD ADDRESS OF SEGMENT (FROM P.F.)
SEGMENT FLAGS
LAST OVERLAY NUMBER LOADED IN SEG
INSTALLED PRIORITy (TASKS ONLY)
POINTER TO SWAP TABLE ENTRY

22-165

Structure Pictures

DNOS System Design Document

SSB

)lE

POINTER TO SEGMENT OWNER BLOCK

SSBSOB

+----------+----------+
)20

SSBPRC

THE

ID'S OF PROCEDURES ASSOCIATED
WITH THE TASK (TASK SEG ONLY)
TASK NAME (TASK SEG ONLY)

SSBPR2

+----------+----------+
)22

SSBNAM!

+----------+----------+
/
/

/
/

+----------+----------+
FLAGS FOR FIELD:

SSBATR

#08 - SEGMENT ATTRIBUTES

SSFRED
SSFSYS
SSFRES

(X ••••••••••••••• ·)

( ••

SSFREP
SSFSHR
SSFPR2

(.X ••••...•.•.•.•
X •••••••••••••
( ••• X ••••••••••••
( •••• X•••••••••••
( ••••• X ••••••••••
( • • • • • • X •••••••••

)
)
)
)
)
)

( ••••••• X •••••••• )

SSFOVF = ( • • • • • • • • X ••••••• )
SSFWCS = ( • • • • • • • • • X •••••• )
SSFEXC = ( • • • • • • • • • • X ••••• )
SSFWRT
( ••••••••••• X •••• )
SSFUPD = ( •••••••••••• X ••• )
SSFREU
( ••••••••••••• X •• )
SSFCPY = ( • • • • • • • • • • • • • • X.)
SSFSEC = ( • • • • • • • • • • • • • • • X)
FLAGS FOR FIELD: SSBFLG

#18 -

( X •••••••••••••••
SSFTSK
SSFEMP = ( • X••••••••••••••
SSFHOM
( •• X •••••••••••••
SSFINI = ( ••• X ••••••••••••

*
*

SSFNRP

(

SSFREL = (
SSFMOD = (
SSFMEM = (
SSFLLM
(

- READABLE (NONTASK)
- SYSTEM (BOTH)
- MEMORY RESIDENT (BOTH)
- RESERVED
- REPLICATABLE (BOTH)
- SHARE PROTECT (NONTASK)
- PROC 2 ON SYS P.F.(TASK)
- RESERVED
- OVERFLOW (TASK)
- WRITEABLE CONTROL STORE (BOTH)
- EXECUTE PROTECT (BOTH)
- WRITE PROTECT (NONTASK)
- UPDATEABLE (BOTH)
- REUSEABLE (BOTH)
- COPYABLE (BOTH)
- SECURITY BYPASS (TASK)

SEGMENT FLAGS

TASK SEGMENT
)
EMPTY SEGMENT (DO NOT LOAD)
)
LOAD FROM HOME FILE
)
INITIAL LOAD SEGMENT (SSB NOT
INITIALIZED)
•••• X ••••••••••• ) - DO NOT REPLICATE SSB (SINCE A
GET MEMORY WAS DONE)
••••• X •••••••••• )
RELEASABLE
•••••• X ••••••••• )
MODIFIED
••••••• X •••••••• )
IN MEMORY
•••••••• X ••••••• )
LOGICALLY IN MEMORY
)

EQUATES:
LABEL
SSBWCT
SSFPRI
SSFPR1

EQUATE TO
SSBIDI
SSFRED
SSFSHR

Structure Pictures

VALUE

DESCRIPTION

)02
)00
)05
22-166

UNALLOCATED WORDS IN SPECIAL TABLE
PRIVILEGED (TASK)
PROC 1 ON SYS P.F.(TASK)
2270512-9701

SSB

DNOS System Design Document

SSFSPR
SSBSIZ
SSBTSZ

2270512-9701

SSFWRT
$
$

)OB
)20
)2A

22-167

SOFTWARE PRIVILEGED (TASK)
BASIC SSB SIZE
TASK SEGMENT SSB SIZE

Structure Pictures

STA

DNOS System Design Document

************************************************************

**
*

**
*
LOCATION: START OF ALL TABLE AREAS
*************************************************************
*
* THE STA DESCRIBES OVERHEAD INFORMATION AT THE START OF
* EACH OF THE SYSTEM TABLE AREAS: THE FILE MANAGEMENT TABLE
* AREA, THE BUFFER TABLE AREA, THE SEGMENT MANAGEMENT TABLE
* AREAS, AND THE STANDARD SYSTEM TABLE AREA.
SYSTEM TABLE AREA OVERHEAD

)00
)02

)04
)06
)08

)OA
)OC

*----------+----------*
STARED
!
+----------+----------+
STALNK
+----------+----------+
STARES
+----------+----------+
STAEND
+----------+----------+
STAUSE
!
+----------+----------+
!
STAHl
!
+----------+----------+
STAPTR
+----------+----------+

(STA)

01/20/79

FIRST ENTRY ON FREE MEMORY LST
POINTER TO FREE MEMORY CHAIN
RESERVED TABLE AREA BOUNDRY
ENDING ADDRES OF TABLE AREA
CURRENT TABLE USAGE
HIGHEST MEMORY ALLOCATION
POINTER TO TABLE OWNER(JSB IF
JCA OR SSB IF SPECIAL TABLE)

EQUATES:
LABEL
STASIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)OE

22-168

2270512-9701

DNOS System Design Document

STE

************************************************************

*
** SWAP TABLE ENTRY
(STE)
11/05/81
*
**
**
LOCATION: SYSTEM JCA
************************************************************
* FOR EACH SEGMENT ON THE SWAP. FILE, THERE EXISTS AN STE
* IN MEMORY, LINKED IN FILE RECORD'ORDER ON THE FILE. THE
* ANCHOR OF STES IS ROLDIR IN PMDATA.
*----------+----------*
)00 !

STERDT

)02 !

STEPRC

ROLL FILE PHYS. RECORD NUMBER

)04 !

STERRL

NUMBER RECORDS IN ROLL FILE

)06 !

STELDT

CONTENTS OF OVBPTR

+----------+----------+
+----------+----------+
+----------+----------+
+----------+----------+

LINK TO NEXT STE

EQUATES:
LABEL
STESIZ

2270512-9701

EQUATE TO
$

VALUE

DESCRIPTION

)08

22-169

Structure Pictures

TDL

DNOS System Design Document

**************************************************************

*
*
TIME DELAY LIST ENTRY
(TDL)
03/15/78
*
*
*
*
LOCATION:
SYSTEM TABLE AREA
***************************************************************
*
* A TDL DESCRIBES AN ENTRY ON THE TIME DELAY LIST.
)00
)02
)04

*----------+----------*
TDLSVC
!
+----------+----------+
!
TDLTM1
!
+----------+----------+
TDLTM2
+----------+----------+

OP CODE (200)
REACTIVATION TIME (WD 1)

EQUATES:
LABEL
TDLVAL
TDLSIZ

EQUATE TO
$
$

Structure Pictures

VALUE

DESCRIPTION

)02

)06

22-170

TIME DELAY VALUE
SIZE OF BLOCK

2270512-9701

DNOS System Design Document

TSB

************************************************************

** TASK STATUS BLOCK
*
04/04/83
*
*
*
LOCATION:
JCA
*
*
************************************************************
* EACH TASK WHICH HAS BEEN BID IS REPRESENTED BY A TSB IN
* ITS JOB'S JCA. THE TSB INCLUDES STATE INFORMATION, LINKS
* TO VARIOUS QUEUES, CHARACTERISTICS' OF THE TASK, LOCATION
* INFORMATION, MAPPING INF9RMATION, AND STATISTICS COUNTERS.
** DETAILS ABOUT PARTICULAR FIELDS:
* TSBTSK - OFFSET INTO MAP FILE AND SSB ADDRESSES FOR THE
*
SEGMENT THAT IS THE TASK SEGMENT (O=FIRST SEGMENT,
*
4=SECOND SEGMENT, 8=THIRD SEGMENT)
** TSBIOI - I/O BOUND INDICATOR, MODIFIED BY THE SCHEDULER
** TSBGEN - GENERATION NUMBER IS ONE GREATER THAN THAT OF THE
*
PARENT OF THIS TASK.
IF THE PARENT TASK DIES, THE
*
GENERATION NUMBER OF THIS TASK IS REDUCED BY 1,
*
AS ARE THE GENERATION NUMBERS OF ANY DESCENDENTS
*
OF THIS TASK.
THIS VALUE IS 0 FOR QUEUE SERVERS.
** TSBSBN - SMT AND SSB PAIR FOR THE NEW SEGMENT WHEN A CHANGE
* TSBSTN SEGMENT OPERATION IS ISSUED. TSBPSN IS THE
* TSPPSN POSITION OF THE SEGMENT (0,4, OR 8). THESE ARE
*
USED ONLY WHEN THE SSB FOR THE NEW SEGMENT MUST
*
BE INITIALIZED.
** TSBLSE - LOAD SEGMENT ENTRIES INCLUDE THE JCA AND ANY OTHER
*
SEGMENTS THAT NEED TO BE LOADED IN MEMORY WHEN
*
THIS TASK EXECUTES, THOUGH THEY MAY NOT BE MAPPED
*
IN TO THE TASK. .
** TSBOSE - OWNED SEGMENTS ARE TEMPORARILY SHARE-PROTECTED
*
** BEGINNING PACKED RECORD TSB

*----------+----------*
TSBQL
!
+----------+----------+
)02 !
TSBWP
!
+----------+----------+
)04
TSBPC
!
+----------+----------+
)06
TSBST
+----------+----------+
)08!
TSBPRI
TSBSTA
+----------+----------+
)OA
TSBIPR
TSBINP
)00 !

2270512-9701

QUEUEING LINK FOR DYNAMIC QUEUES
ACTIVE WORKSPACE POINTER
ACTIVE PROGRAM COUNTER
ACTIVE STATUS
TASK PRIORITY (RUN TIME)
TASK STATE
INITIAL TASK PRIORITy

22-171

Structure Pictures

TSB

DNOS System Design Document

+----------+----------+.
)OC
)OE

TSBIID

TSBRID

+----------+----------+
TSBSTG

TSBIEC

+----------+----------+
)10 !
)12

TSBFL1

+----------+----------+
TSBFL2

+----------+----------+
) 14

T S B JS B

+----------+----------+
)16 !
)18

TSBXOP

+----------+----------+
TSBTSK

TSBIO

+----------+----------+
)lA

TSBIOI

TSBPSN

+----------+----------+

) 1C !
)lE

TSBCPT

+----------+----------+

INSTALLED TASK PRIORITy
INSTALLED TASK IDENTIFIER
RUN TIME TASK IDENTIFIER
TASK STAGE NUMBER
INITIATED EVENT COUNT
TASK FLAGS - SYSTEM FLAGS
TASK FLAGS -

CONTROL FLAGS

JSB ADDRESS
EFFECTIVE XOP ADDRESS
2 WORD OFFSET TO TASK (0,4,8)
GENERAL I/O COUNT
I/O BOUND INDICATOR
POSITION OF NEW SSB
CPU EXECUTION TIME (TICKS)

+----------+----------+
)20

TSBRPC

+----------+----------+

)22

NUMBER SERVICE CALLS· ISSUED

+----------+----------+
)24

TSBBY1

+----------+----------+

NUMBER I/O BYTES TRANSFERRED

) 26 !

TSBBY2

I/O BYTES TRANSFERRED - WORD 2

)28 I

TSBSPN

TICK COUNTER AT TIME SUSVENDED

+----------+----------+
+----------+----------+

)2A

TSBTSB

+----------+----------+
)2C

TSBSTI

TSBGEN

+----------+----------+

)2E

TSBPM1

+----------+----------+
)30

TSBPM2

+----------+----------+

TSB FIXED LINK IN SET FOR JOB
STATION ID (FF=NO STATION)
GENERATION NUMBER
PARAMETER 1
PARAMETER 2

)32 !

TSBINI

)34

TSBIN2

COMPLETED EVENT FLAGS - WORD 1

TSBLDT

LOT LIST HEADER POINTER

TSBEOR

END OF REQUEST PROCESSING
LI ST HEADER
END ACTION PROGRAM COUNTER

+----------+----------+

)36
)38

+----------+----------+
+----------+----------+
+----------+----------+

)3A

TSBEAP

COMPLETED EVENT FLAGS - WORD 1

+----------+----------+
)3C !

TSBEAW

)3E

TSBDIA

+----------+----------+
!

+----------+----------+

Structure Pictures

END ACTION WORKSPACE
END ACTION STATUS INFORMATION
(DIAGNOSTIC DATA ADDRESS)

22-172

2270512-9701

DNOS System Design Document

)40
)42
)44
)46

TSB

TSBSBN

+----------+----------+
TSBSTN

SM TABLE SSB FOR NEW SEGMENT

+----------+---------~+
TSBSBI
!

+----------+----------+
TSBSTI

TSBSB2

) 4A !

TSBST2

)4C !

TSBSB3

)4E

TSBST3

)48

+----------+----------+
+----------+----------+
+----------+----------+

+----------+----------+

)50
)52
)54
)56

ADDRESS OF NEW SSB

+----------+----------+
TSBMLI

TSBMBI

TSBML2

+----------+----------+
+----------+----------+
+----------+----------+
TSBMB2

SSB ADDRESS FOR 1ST SEGMEMT
SM TABLE SSB FOR 1ST SEGMENT
SSB ADDRESS FOR 2ND SEGMEMT
SM TABLE SSB FOR 2ND SEGMENT
SSB ADDRESS FOR 3RD SEGMENT
SM TABLE SSB FOR 3RD SEGMENT
MAP LIMIT ONE REGISTKR
MAP BIAS ONE REGISTER
MAP LIMIT TWO REGISTER
MAP BIAS TWO REGISTER

+----------+----------+
)58

TSBML3

+----------+----------+
)5A

TSBMB3

MAP LIMIT THREE REGISTER
MAP BIAS THREE REGISTER

+----------+----------+
)5C

TSBBLN

+----------+----------+

)5E !

TSBTLM

)60

TSBMXM

+----------+----------+

LENGTH OF MAPPED SEGMENTS (BEETS)
TOTAL ROLLABLE MEMORY (BEETS)
MAX VALUE OF TSBTLM

+----------+----------+
)62

TSBLSE

+----------+----------+

)64 !

TSBOSE

)66

TSBSRT

+----------+----------+

)68
)6A

OWNED SEGMENT ENTRY LIST HEADER
TICK COUNTER WHEN TASK STARTED

+----------+----------+
+----------+----------+
TSBFMT

+----------+----------+

)6C !
)6E

LOAD SEGMENT ENTRY LIST HEADER

TSBFCB

+----------+----------+
TSBAIC!

THE FDP OF PROGRAM FILE FOR
THE TASK SEGMENT

TSBRES

ABORTING I/O COUNT
+----------+----------+
RESERVED
)70 SIZE
** END OF PACKED RECORD

FLAGS FOR FIELD: TSBFLI
2270512-9701

#10 - TASK FLAGS - SYSTEM FLAGS
22-173

Structure Pictures

DNOS System Design Document

TSB

TSFSYS
( X ••••••••••••••• )
TSFPRI
( • X •••••••••••••• )
TSFMEM
( •• X ••••••••••••• )
TSFENA
( ••• X •••••••••••• )
TSFIOA
( •••• X ••••••••••• )
TSFABT
( ••••• X •••••••••• )
TSFSEC = ( •••••• X ••••••••• )
( ••••••• X •••••••• )
TSFQSR
TSFACT
( •••••••• X ••••••• )
TSFBID
( ••••••••• X •••••• )
TSFSPR
( •••••••••• X ••••• )
TSFTOA
( ••••••••••• X •••• )
TSFIOE
( •••••••••••• x ••• )

*
FLAGS FOR FIELD: TSBFL2
TSFCNT
TSFSSC
TSFSBK
TSFHLT
TSFRST
TSFRBD
TSFXOP
TSFCHO

=
=
=

(
(
(
(

#12 - TASK FLAGS - CONTROL FLAGS

X •••••••••••••••
• X ••••••••••••••
•• X •••••••••••••
••• X ••••••••••••

)
)
)
)

( •••• X ••••••••••• )

( ••••• X •••••••••• )

( •••••• X••••••••• )
=

( ••••••• X •••••••• )

Structure Pictures

SYSTEM TASK
PRIVILEGED TASK
CURRENT SEGMENT SET IN MEMORY
TAKE END ACTION ON ERROR
I/O HAS BEEN ABORTED FOR TASK
TASK BEING ABORTED
BYPASS SECURITY
QUEUE SERVER TASK
ACTIVATE TASK OUTSTANDING
INITIAL TASK BID
SOFTWARE PRIVILEGE
ABORT TIMEOUT FLAG
I/O EVENT PEND. UNBUFF
RESERVED - BITS 13 - 15

22-174

TASK BEING CONTROLLED
STOPPED BY SCHEDULER
STOPPED BY BREAKPOINT
TASK TO BE HALTED
RESTART PARENT ON TERM
RBID TASK
REISSUE XOP
JOB-LOCAL CHANNEL OWNER
E.ESERVED
BITS 8
15

2270512-9701

UDO

DNOS System Design Document-

***********************************************************

**
**

USER DESCRIPTOR OVERFLOW RECORD
LOCATION:

S$CLF ON DISK

(UDO)

11/24/82

*
*
**

***********************************************************

*
*
*
*

THE UDO IS USED ONLY IN THE CASE THAT A USER IS A MEMBER
OF MORE ACCESS GROUPS THAN WILL FIT IN HIS UDR.
IT CONTAINS
ACCESS GROUP INFORMATION.
IT IS A VARIANT OF THE CAPABILITIES
LIST FILE RECORD (CLR).
FOR DETAILS SEE CLR.

2270512-9701

22-175

Structure Pictures

UDR

DNOS

System Design Document

***********************************************************

USER DESCRIPTOR RECORD

(UDR)

11/24/82

*
*
*

*
LOCATION: DISK
*
***********************************************************
*
*
*
*

THE UDR DESCRIBES THE DISK STRUCTURES THAT REPRESENTS A
GIVEN USER OF THE SYSTEM.
IT INCLUDES LOGON INFORMATION
AND SECURITY INFORMATION.
IT IS A VARIANT OF THE CAPABILITIES
LIST FILE RECORD (CLR).
FOR DETAILS SEE CLR.

Structure Pictures

22-176

2270512-9701

UIP

DNOS System Design Document

************************************************************
*
*

USER ID PARAMETER (UIP)

LOCATION:

12/01/82

POINTED TO BY IRBPRM FIELD

**
*
*
*

************************************************************

**
*
*
*
*
*
*
*

THE USER ID PARAMETER IS CHECKED BY SECURITY
MANAGER AND WILL BE USED IN PLACE OF THE
ISSUER'S USER ID IF A VALID PASSCODE IS
SUPPLIED OR THE TASK HAS SECURITY BYPASS.
THIS PARM MAY BE SUPPLIED BY A USER, OR
MAY BE CREATED BY IOU TO PASS INFO ACROSS
THE NETWORK.

)00
)02

*----------+----------*
UIPSLN!
UIPLEN
!
+----------+----------+
UIPUID
I
!
+----------+----------+

SUBLIST NUMBER <)02)
LENGTH OF PARM-2 IN BYTES ()10)
USER ID

+----------+----------+
UIPPWD!
!
+----------+----------+

PASSWORD

/
/

)OA

/
/

/
/
/
1 / /

+----------+----------+

EQUATES:
LABEL
UIPSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)12

22-177

TOTAL LENGTH OF UIP

Structure Pictures

VCB

DNOS System Design Document

************************************************************
VALUE CONTINUATION BLOCK

*
**

LOCATION:

(VCB)

07/16/81

A NAME DEFINITION SEGMENT

*
**

************************************************************

)00

*----------+----------*
VCBVCB
+----------+----------+

POINTER TO NEXT NCB

EQUATES:
LABEL
VCBSIZ

EQUATE TO
$

Structure Pictures

VALUE

DESCRIPTION

)02

22-178

LENGTH OF NCB OVERHEAD

2270512-9701

DNOS System Design Document

VDB

***********************************************************
VALUE DEFINITION BLQCK

*
**

LOCATION:

(VDB)

07/21/81

NAME DEFINITION SEGMENT

***********************************************************

*----------+----------*
VDBVCB
!
+----------+----------+
)02!
VDBUSE
!
!
+----------+----------+
)00

NEXT NAME CONTINUATION BLOCK
NUMBER OF USERS OF THIS VALUE

EQUATES:
LABEL
VDBSIZ

2270512-9701

EQUATE TO

VALUE

DESCRIPTION

)03

22-179

SIZE OF THE VDB OVERHEAD

Structure Pictures

..
VRB

DNOS System Design Document

*****************************************************************

* VIRTUAL REQUEST BLOCK
*
(VRB)
8/22/83
*
*
*
*
LOCATION: SYSTEM TABLE AREA AND JCA
*
*
*
*
******************.* ********* * * *** * * *** ** *** * * ** ** * ** ** ** * * *** ** **
* DEFINITIONS OF FIELDS IN DSR CALL BLOCK (DATA BUFFER FOR I/O
* SVC SUBOPCODE )17) FOR VIRTUAL TERMINAL DSR.
*
** BEGI~NING PACKED RECORD VRB

*----------+----------*
VRBOC
!
VRBEC
!
+----------+----------+
!
VRBVT
+----------+----------+
VRBCHR
VRBLC
+----------+----------+
!
VRBJOB
+----------+----------+
!
VRBRDN
+----------+----------+
/
/
/

)OO!

)02

)04
)06
)08

)16

)18

REMOTE DEVICE NAME

REAL TERM JOB I.D.
OWNER IPC NAME

+----------+----------+
SIZE
** END

Structure Pictures

BID CHAR
LUNO USE COUNT
PDTJOB

+----------+----------+
!
VRBJID
+----------+----------+
!
VRBIPC
!
+----------+----------+
/
/
/
/

)24

VTDSR REQURST CODE
VTDSR RETURN CODE
VIRTUAL TERMINAL NUMBER (HEX)

OF PACKED RECORD

22-180

2270512-9701

DNOS System Design Document

XTK

************************************************************

** EXTENTION FOR A TERMINAL
**
(XTK)
02/12/82
*
WITH A KEYBOARD
*
**
LOCATION: SYSTEM AREA
**
************************************************************
* THE XTK IS AN EXTENSION TO THE' PDT USED TO DESCRIBE A
* DEVICE WITH A KEYBOARD. IT IS USED AS A WORK AREA BY
* THE DSR.

*----------+----------*
XTKXUF
+----------+----------+
XTKFLG
XTKSCH!
+----------+----------+
!
XTKCRD
!
+----------+----------+
XTKICD
!
+----------+----------+
XTKSSC
+----------+----------+
XTKABT
+----------+----------+
XTKTMO
+----------+----------+
XTKPFR
+----------+----------+
!
EDTFLO
!
+----------+----------+
!
EDTFLI
+----------+----------+

)00 !

EXTENDED USER FLAGS FROM BRB

)02

XTK GENERAL FLAGS
SAVED CHAR FOR JISCII TERMINAL
CARRIAGE RETURN DELAY COUNT

)04
)06
)08
)OA
)OC
)OE
)10
)12

FLAGS FOR FIELD:
KSFHNG
KSFTMS
KSFSCI
KSFDCD
KSFSIO
KSFDIF

XTKFLG

INTER-CHARACTER DELAY COUNT
SAVED STATUS OF CASSETTES
CODE ADDRESS TO PERFORM ABORT
TIME-OUT COUNT FOR HANG CONDITION
POWER FAIL FLAG/BUFFER BIAS
EXTENDED EDIT FLAGS - WORD 0
EXTENDED EDIT FLAG - WORD 1

#02 -

(X •••••••••••••••
(.X ••••••••••••••
( •• X •••••••••••••
( ••• X ••••••••••••
( •••• X•••••••••••
( ••••• X ••••••••••

FLAGS FOR FIELD:

EDTFLO

- HANG UP CONDITION ON 745
- TIME-OUT SWITCH FOR 745
- SCI ACTIVE DURING HANG UP
- DATA CARRIER DROP DETECTED
- SHIFT IN/SHIFT OUT JISCII
- DIRECT CHAR INPUT REQUESTED

#10 - EXTENDED EDIT FLAGS - WORD 0

(X •••••••••••••••
(.X ••••••••••••••
( •• X•••••••••••••
( ••• X ••••••••••••
( •••• X•••••••••••
2270512-9701

)
)
)
)
)
)

XTK GENERAL FLAGS

)
)
)
)
)

22-181

PASS-THROUGH MODE
940-IN PTM, TERMINATE READ ON ETX
940-IN PTM, TERMINATE READ ON ESC-)
USED, BUT NOT DOCUMENTED _
940-DISABLE USE OF BIT 0 FOR INTEN
Structure Pictures

DNOS System Design Document

XTK

( ••••• X •••••••••• ) - 940-ALLOW ESC & SOH IN WRITE ASCII B
= ( •••••• X••••••••• ) - 940-IGNORE DISPLAY CHARACTERS, ETC.
( ••••••• X•••••••• ) - 940-1=132 COL MODE; 0=80 COL MOD
MDTCHK
( •••••••• X ••••••• ) - POST DATA MODIFIED ON READ
EXVAL
( ••••••••• X •••••• ) - EXTENDED CHAR VALIDATION
NULFLG
( •••••••••• X ••••• ) - NULL CHARACTER SUPPRESSION
CNBFLG
( ••••••••••• X •••• ) - CONVERT NULL TO BLANK
( •••••••••••• X ••• ) - KANJI
( ••••••••••••• XXX) - RESERVED

FLAGS FOR FIELD: EDTFLI

1112

( X ••••••••••••••• )

( • X•••••••••••••• )
LEFARO =
=
=
=

( •• X •••••••• " •••• )

( ••• X
( •••• X••••••••••• )
It

••••••••••• )

( ••••• X •••••••••• )

( •••••• X••••••••• )
( ••••••• X •••••••• )
( •••••••• X ••••••• )

RITARO

( ••••••••• X••••••
( •••••••••• X•••••
( ••••••••••• X••••
( •••••••••••• X•••
( ••••••••••••• X••

)
)
)
)
)

( •••••••••••••• X. )

( ••••••••••••••• X)

- EXTENDED
- TERMINATE
- TERMINATE
- TERMINATE
- TERMINATE
- TERMINATE
TERMINATE
-

TERMINATE

TERMINATE
TERMINATE
TERMINATE

- TERMINATE
TERMINATE
-- TERMINATE
- TERMINATE
- TERMINATE
- TERMINATE
-

EDIT FLAG
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ
READ

ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON
ON

WORD 1

ERASE FIELD
RIGHT FIELD
LEFT ARROW
TAB
UP ARROW
SKIP
HOME
RETURN
ERASE INPUT
BLANK GRAY
DELETE CHAR
INSERT·· CHAR
RIGHT ARROW
ENTER
LEFT FIELD
DOWN ARROW

EQUATES:
LABEL

-----

XTKFIL
XTKEVT
XTKPOS
XTKDEF
XTKJIN
XTKSCI
XTKSC2
XTKSIZ
XTKBUF

EQUATE TO

------ .... -XTKFLG
XTKFLG+l
XTKCRD
XTKICD
XTKSSC
XTKABT
XTKTMO
$

XTKSIZ

Structure Pictures

VALUE

-----

)02
)03
)04
)06
)08
)OA
)OC
)14
)14

DESCRIPTION

------------------------------

22-182

FILL CHARACTER
EVENT CHARACTER
WITHIN
FIELD CURSOR POSITION
START OF FIELD CURSOR POSITION
ASCII/JISCII INTENSITy MASK
SCRATCH /I 1
SCRATCH /I 2
CHARACTER BUFFER

2270512-9701

Appendix A
Keycap Cross-Reference
Generic keycap names that apply to all terminals are used for keys on keyboards throughout this
manual. This appendix contains specific keyboard information to help you identify individual keys
on any supported terminal. For instance, every terminal has an Attention key, but not all Attention
keys look alike or have the same position on t~e keyboard. You can use the terminal information in
this appendix to find the Attention key on any terminal.
The terminals supported are the 931 VDT, 911 VDT, 915 VDT, 940 EVT, the Business System
terminal, and hard-copy terminals (including teleprinter devices). The 820 KSR has been used as a
typical hard-copy terminal. The 915 VDT keyboard information is the same as that for the 911 VDT
except where noted in the tables.
Appendix A contains three tables and keyboard drawings of the supported terminals.
Table A-1 lists the generic keycap names alphabetically and provides illustrations of the
corresponding keycaps on each of the currently supported keyboards. When you need to press
two keys to obtain a function, both keys are shown in the table. For example, on the 940 EVT the
Attention key function is activated by pressing and holding down the Shift key while pressing the
key labeled PREY FORM NEXT. Table A-1 shows the generic keycap name as Attention, and a
corresponding illustration shows a key labeled SHIFT above a key named PREY FORM NEXT.
Function keys, such as F1, F2, and so on, are considered to be already generic and do not need
further definition. However, a function key becomes generic when it does not appear on a certain
keyboard but has an alternate key sequence. For that reason, the function keys are included in the
table.
Multiple key sequences and simultaneous keystrokes can also be described in generic keycap
names that are applicable to all terminals. For example, you use a multiple key sequence and
simultaneous keystrokes with the log-on function. You log on by pressing the Attention key, then
holding down the Shift key while you press the exclamation (I) key. The same information in a table
appears as Attention/(Shift)!.
Table A-2 shows some frequently used multiple key sequences.
Table A-3 lists the generic names for 911 keycap designations used in previous manuals. You can
use this table to translate existing documentation into generic keycap documentation.
Figures A-1 through A-5 show diagrams of the 911 VDT, 915 VDT, 940 EVT, 931 VDT, and Business
System terminal, respectively. Figure A-6 shows a diagram of the 820 KSR.
2274834 (1/14)

2270512·9701

A·1

Keycap Cross-Reference

Table A·1.

Generic Name

911
VDT

Generic Keycap Names

940

931
VDT

EVT

ness
System
Termin

820'
KSR

Alternate
Mode

Attention 2

Back Tab

[8'"
SHIFTO;

: .. ".::

..• •.,.,.,.,.,.,.,.•. ,:.,.,.,.•..... ..,."

Command 2

Control

Delete
Character

~
EL".

HAFt:

..,.,.,.,.,.,",.,',.,.,.,." .....'•.

Enter

Erase Field

F(71I

Notes:
'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service
Routine (DSR). Keys on otherTPD devices may be missing or have different functions.
'On a 915 VDT the Command Key has the label F9 and the Attention Key has the label F10.

2284734 (2/1 4 )

A·2

2270512-9701

Keycap Cross-Reference

Table A·1.

Generic Name

Generic.Keycap Names (Continued)

911

940

931

VOT

EVT

VOT

ness
System
Terminal

820 1
KSR

Erase Input

Exit

:
iii

Forward Tab

....:......•.•.•• ~":"".'

......

.;:

~
~ <.• .•
. ••.•••..••. F.• . . • .•

, F4

~
~

Notes:

'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service
Routine (DSR). Keys on other TPD devices may be missing or have different functions.

2284734 (3/14)

2270512-9701

A·3

Keycap Cross-Reference

Table A·1.

Generic Name

911

VOT

Generic Keycap Names (Continued)

940
EVT

931

VOT

Bus ness
System
Tori," I I"' ... I

820 1
KSR

F10

Notes:
'The 820 KSR terminal has been used as a tYPical hard-copy terminal with the TPD Device Service
Routine (DSR). Keys on other TPD devices may be missing or have different functions.

2284'734 (4/14)

A·4

2270512-9701

Keycap Cross-Reference

Table A·1.

Generic Name

911
VOT

Generic Keycap Names (Continued)

940
EVT

ness
System
Terminal

931
VOT

820 1
KSR

F11

F12

F13

[8';
SHIFT

••;=:.:...........:•••.•:.:.:.:••.:.:.:.:.:•.•••••:.:.:.:••

F14

Home

[8
0Me::

..,.,.,.,',.,.,." .. )

FrE11
~
Initialize Input

Notes:
'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD DevlcP StHVlce
Routine (DSR). Keys on other TPD devices may be missing or have different functions.

2284734 (5/14)

2270512-9701

A·5

Keycap Cross-Reference

Table A·1.

Generic Name

Generic Keycap Names (Continued)

911

940

931

VOT

EVT

VOT

Business
System
Terminal

Insert
Character

820 1
KSR
None

Fiiiiij'

Next
Character
or

fiiit1
~

Next Field

None

[1]"
~

Next Line

.....".....••

~
~
Previous
Character

rEi
~

None

riI
Previous Field

Non",

Notes:
'The 820 KSR terminal has been used as a typical hard-copy termindl with the TPD Devlcf' St'fVICl'
Routine (DSR). Keys on other TPD devices may be missing or have different functions

2284734 (6(/14)

A·6

2270512·9701

Keycap Cross-Reference

Table A·1.

Generic Name

Generic Keycap Names (Continued)

911

940

931

VOT

EVT

VOT

Business
System
erminal

820 1
KSR

Previous Line

None

See
Note 3

Repeat

See
Note 3

None

~
~

Return

~:"

RETURN ;.
...:....,............ .. ....... .
~:.

.~ :~

:.~

Shift

Skip

Uppercase
Lock

r-=~

F
"C",.,.,.A,",.p
a
.....,.s
. . . ·.
.'•.,• .

Notes:
'The 820 KSR terminal has been used as a typical hard-copy terminal with the TPD Device Service
Routine (DSR). Keys on other TPD devices may be missing or have different functions.
'The keyboard is typamatic, and no repeat key is needed.

2284734 (7/14)

2270512-9701

A·7

Keycap Cross-Reference

Table A·2.
Function

Log-on
Hard-break
Hold
Resume

Table A·3.

Frequently Used Key Sequences
Key Sequence

A ttention/(Sh ift)!
Attention/(Control)x
Attention
Any key

911 Keycap Name Equivalents

911 Phrase

Generic Name

Blank gray
Blank orange
Down arrow
Escape
Left arrow
Right arrow
Up arrow

Initialize Input
Attention
Next Line
Exit
Previous Character
Next Character
Previous Line

2284734 (8/14)

A·a

2270512-9701

I\)
I\)

......

I\)

........

SPEC IAL A~
CONTROL
__________________________________________
______________________________________________~

V
CURSOR CONTROL
AND EDIT

NUMERIC PAD

v~------------------..J

DATA ENTRY

2284734 (9/14)

Figure A·1.

911 VOT Standard Keyboard Layout

'""'0"
(I)

(')

Q
o

C/)
C/)

:X,
(I)

Ci)

»
cD

Ci3

(')
(I)

~
......

(1)

'<:

(')
Q)

"C
()

C3
('J)
('J)

(1)

.....:...

Cti

:;,
(')

Source Exif Data:
File Type : PDF
File Type Extension : pdf
MIME Type : application/pdf
PDF Version : 1.3
Linearized : No
XMP Toolkit : Adobe XMP Core 4.2.1-c041 52.342996, 2008/05/07-21:37:19
Create Date : 2001:11:30 06:51:35Z
Creator Tool : g4pdf
Modify Date : 2017:03:05 11:02:44-08:00
Metadata Date : 2017:03:05 11:02:44-08:00
Producer : Adobe Acrobat 9.0 Paper Capture Plug-in
Format : application/pdf
Document ID : uuid:7b07bfe9-8837-5e46-b73f-9e3a07f8d94c
Instance ID : uuid:0d5eb9a4-6641-7a41-aa29-d39a3264b4fc
Page Mode : UseOutlines
Page Count : 694
Creator : g4pdf

EXIF Metadata provided by EXIF.tools

2270512B_DNOS_System_Design__Nov83 2270512B DNOS System Design Nov83

2270512B_DNOS_System_Design__Nov83 2270512B_DNOS_System_Design__Nov83

Navigation menu

Versions of this User Manual:

Views

Navigation