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 PDF.
Page Count: 694

Download2270512B_DNOS_System_Design__Nov83 2270512B DNOS System Design  Nov83
Open PDF In BrowserView PDF
DNOS

~

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

TEXAS INSTRUMENTS

© Texas Instruments Incorporated 1981, 1982, 1983

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

.......

o

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.

iv

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.

2

Overview of DNOS -- Discusses
the DNOS system.

3

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

4

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

5

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

6

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.

7

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

8

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

9

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

2270512-9701

v

the general

features

of
the

process
of
that support

DNOS System Design Document

10

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.

11

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.

12

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

13

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

14

Logging and Accounting
the
flow
of
control
accounting functions.

15

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

16

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.

17

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.

18

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

19

Special SVCs -Describes
operating system.

20

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.

21

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

Texas Instruments

vi

~4

Describes the functions and
for
the
system
log and job

SVCs

used

only

by

in
the

2270512*9701

DNOS System Design Document

22

A

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

to

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

......

ix

.......

...

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

......

x

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

xi

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

xv

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

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

xx

0

f

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

>

I

I

I

I

V

V

V

V

Execute
Task
Code
I

Process
SVC
Request
I

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

\

/
\

/

Time Slice
Expired

Process
Hardware
Interrupt
or
XOP
I
I
I

?

no

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

V

V

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:

of

the

following

PSOURCE for Pascal source

*
*
*
*
*
*
*

MSOURCE for /12 microcode

*

UTILITY for
code

I

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

be

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.

>

is

used

to

represent

a

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

to

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

I

I

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

an

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:

2.

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

by

is
of

a

XOP

@block,l~

Requester task issues
(or equivalent)

3. Decoder

the SVC

using

1.

request

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

I

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:

*
*
*
*
*
*

RO

-

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

R1

-

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

R2

-

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

o

)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.

I

I

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

is

to

be

the RDB

2.

Checks
the
violations

3.

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

b.

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

I

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

46

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

A

PMPMAP (task)

A

A,P
A,P

RPKILT
RPVOL
RPPTS
RPWT36
PMPASP
RPINV

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

A

RPIDT

[RPGSVC]

S

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

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]

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

A

PMACCT
PMSBUF (task)
PMHALT
RPRCP
(task)

A

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

I

I

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

I

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

*
*
*

R4

*
*
*

R5

-

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.

I

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

of

a

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

1

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

+--------+
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

V

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

1

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)

V

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

V

+----------+
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

V

V

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

I

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

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

be

in

by

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

a

BL

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
+--) 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

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
1

V

1

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

I

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

11
ISpecial table #2

1

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

I

DNOS System Design Document

I

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.

I

I

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.

I

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

I

I

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

V

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

V

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

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

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

I

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

I

V

V

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

I
I
I
I
I

V

(BL)
I

V

V

ACTIVATES
TASK

V

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

9.3.3

I

I

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

a

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

V

+----------+
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.

I

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

I

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

1.

Save the current system map file
CURMAP).

2.

Set
CURMAP
to
appropriate DSR.

the

on

a multiplexed

following

steps

pointer (accessed

via

for

the

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

the

the

DSR

map

file

pointer

to

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

V

+----------+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

V

I

V

1

+----------+
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-----------------------+

V

V

+----------+
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

1

DNOS Code

1

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

1 DSRI

1

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

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

1

1

1

1

1

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

1
Data
1 Buffer

1
1

1

DSR 1

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

o

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

of

the

PDT

in

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

is

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

9.

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

BL

I TSR
ISchedule
I

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

I

I
I

I
I
I

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

/

\

BLI
I

\ /

\ 1/

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

I

I Controller
I Service
I Routine

I
I
I

I

I

Controller
Interrupt

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

\1/

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

CONTROLLER

I

+---------------------+
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

of

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

t;

N

Z

N
-......J

o

CIl

o
V1

.....
N

931 940
ATTACHED PRINTER
DATA STRUCTURE

931940 PDT
DATA STRUCTURE

I

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

1

Reserved.

Bi t

2

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

7

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

to

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

2

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).

Bi

3

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

t

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

6

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

7

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.

1

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

1

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.

Bi

2

Printer Has Channel.
when the printer has

t

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

5

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

6

Cursor Is On.
This flag
the cursor is on.

Bi t

7

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

is

set

to

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.

14

Bit 15

is set

Insert Flag.
This flag
TSR is in insert mode.

indicates

This word
is
used
address by the TSR.

an

to

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.

as

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).

Bi

t

1

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

Read

on

Bi

t

2

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

on

Bi

t

3

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.

7

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.

10

Bits 11-15
)24

PDXCPF

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

Hex.
Byte

input

o

Meaning
Ignore input and do not produce output.

4

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

0

Meaning
150 cps

1

75 cp s

2

40 cps

3

20 cps

4

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

is

Remote Flags:
Bi t

0

Reserved.

Bi t

1

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

is

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).

Bi

t

4

Terminal has started power-up,
completed yet.

Bi

t

5

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.

of

the

number

of

)A2

VDTPAR

a
counter
This word is
parity errors detected.

of

the

number

of

)A4

VDTFRM

This word is
a
counter
framing errors detected.

of

the

number

of

)A6

VDTPTR

Run-time
PDXCP4.

address

in

)A8

PRTTIM

Timer for printer delay (940 only).

)AA

VDTEDL

This word is an opcode 15 Edit Flag.

Bi t

location

for

printer

0

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.

3

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

8

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

D

from

Character is an Event.

10-53

I/O Subsystem

DNOS System Design DDcument

)AE

Bi t

E

Left Field is an Event.

Bi t

F

Rese rve d.

STATBD

This word contains the state of
follows:
Value
0

)BO

STATGR

STATFN

Board connected.

8

Board waiting on time ou t.

12

Board waiting on ring.

16

Board is in DSR diagnostic mode.

This word contains the
graphics.

Meaning
Input is not graphics.

4

Input

Value

10.5.3.11

state

o

Thi sword
mapping.

as

Meaning
Board disconnected.

4

Value

)B2

the board

of

the

input

is graphics.

contains

the

state

o

Meaning
Regular keys.

4

ESC was received.

8

Aid was received.

12

Pass Through Mode.

16

DSR Diagnostic Mode.

20

Read

of

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

of

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.

1

a

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

5

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

6

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

Bit

7

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

10

Reserved.

Bit

11

Reserved.

Bi

12

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

t

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

of

of

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

I

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

I

DNOS System Design Document

Sublist
Type

00

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

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

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

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

of

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.

is

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.

I

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 -

a

a

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.

I

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

V

I

1

VII

V

+------------------+
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.

I

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

I

I

IPCexecutes the Open
checks for legal access

1

----------+-----------------+-----------------------------I
01
1 Close
1
IPC executes the Close
I
----------+-----------------+-----------------------------I
05
1 Read Status
I
Owner receives status data 1
----------+-----------------+-----------------------------+
19

1

Master Read

1

1

1

Owner gets whole
of requester

call

blockl
1

----------+-----------------+-----------------------------I
lA

1 Read

Call Block 1

1

1

Owner gets first part
requester call block

of

1

1

----------+-----------------+-----------------------------I
IB

1 Master Write
1
Owner sends information
l i t o requester

1
1

----------+-----------------+-----------------------------I
lC

1

Redirect

Assign

1 LUNO

1

1

IPC sends call block to
another channel owner

1

1

----------------------------------------------------------*
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

I

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

I

I

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

V

NDS

1

A

V

+-----+
1
c 1
+-----+

+------+
1

+------+
1
V

SVC

+-----+
1 4
1------+

+-----+
1
V

SVB

1

1
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

2

*-----------------------------------------*

The parameter list contains the following:
BYTE

CONTENTS

o

Length of entire structure; the sum of 1
plus two times the number of sublists.

1

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

3

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.

6

1

7

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

o

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

1

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

o

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

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

I

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.

I

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

1

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

I

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.

I

*

The
remainder
of
track
0
contains
information in the form of bit maps.

I

*

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

I

11.3.1

Volume

next

to

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
\

I

ALL DATA

I ,I

\

ALL DATA

I

V

"

I
I

V
ADU

ADU

,

D

ALL DATA

UNUSED

I

V
ADU

2278129

Unblocked Relative Record File
Record Size < ADU Size

PHYSICAL
,,-_ _....../A\,._ _ _"'"

DATA

~

DATA

~

DATA

~

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

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

I

DNOS System Design Document

PHYSICAL RECORD 0

BYTE

o

o

1, I

FLAGS

2

8

RECORD 0 HEADER

C

8

RECORD 0 TRAI LER

E

E

RECORD 1 HEADER

4

LOGICAL RECORD 0 DATA

6
8
A

10

12

14
16

LOCICAL RECORD 1 DATA

18

1A

tc
1E

E

RECORD 1 TRAI LER

20

8

RECORD 2 HEADER (PARTIAL)

8

RECORD 2 TRAI LER (PARTIAL)

22
24

LOGICAL RECORD 2 DATA

26

28
2A

PHYSICAL RECORD 1
1

101

FLAGS
4

RECORD 2 HEADER (PARTIAL)

4

RECORD 2 TRAI LER (PARTI AL)

A

RECORD 3 HEADER

A

RECORD 3 TRAI LER

A

RECORD 4 HEADER

A

RECORD 4 TRAI LER

LOGICAL RECORD 2 DATA

LOGICAL RECORD 3 DATA

LOGICAL RECORD 4 DATA

0
0

2

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

is

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

I

DNOS System Design Document

Input Record:
column: 0
0
1

5

1

o

1
5

FIRST

2

o

3

o

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

4

3
5

o

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

in

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

R2

R1 + {«MAX # TASKS +2)/2)

F2

remainder of {«MAX # TASKS +2)/2)

R3

R2 + {(MAX # TASKS +1)

F3

remainder of {(MAX # TASKS +1)

R4

R3 +{«MAX # PRoes +2)/2)

F4

remainder of

R5

R4 +{(MAX # PRoes +1)

F5

remainder of

R6

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

)100

)100

)10 + F3} /

)100

)100

)10 + F4} /

)10 + F5}

/

)100

)100
File

I/O

DNOS System Design Document

remainder of { ( (MAX II OVLYS +2)/2)

F6

F7 = R6 +{(MAX II OVLYS +1)

*

)10 + F6} /

F7

remainder of {(MAX # OVLYS +1)

R8

R7 + {«MAX # HOLES

* 4) "+2)

F8 = remainder of {«MAX # HOLES

*

*

)10 + F5} /

)100

)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

1

/
I

+-----------------------------------------------------+--+
I
RECORD NUMBER
I
I
+-----------------------------------------------------+
ENTRY
I
RECORDS AVAILABLE
I
I
*-----------------------------------------------------*--+
Figure

11-5

n

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

I

DATE INSTALLED

+---------------------~-------------------------------+
I

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

J

I

I

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

2

n

*---------------------------*
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

1,

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.

of

directory

The directory overhead record
directories, contains:

*
*

records are described in the

(DOR), which

is

record

0

of

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

*

(2

**

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

I

Each type of file can have secondary allocations.
An image
program file can also have a secondary allocation.

File I/O

11-24

in

a

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

R

1)(li)(1

HECORD:

OI)(Jl)Ol

0000 0002

0(~1

5345 5120

202(~

2020

Sf C'

({IOO O(Il)O

.P

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

1M

0036 (l7BC 0203 09[16 07Be 0203 09[16 010:; 0000

.:.~

..

.V

(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

..'

IJ

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

9R

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)

if

• .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.

I

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

I

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.

2.

(XOP) FMPREP sets up the vector in FWAXWP (in
the
FMT)
such that a BLWP instruction transfers control to FMTRTN
(in FMUTLY).

I

I

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.

5.

(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.

6.

(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) -

X,

to the user or batch listing file

Open a sequential file

REWRIT(LUNO) -

at

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

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

I

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

) ;

LP

: ( 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

I
I

I

I
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

I

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.

I

SHOWDV
SHOWDV
uses
the
logic
of
information about a device.

I

FORMDV, FRMXOP
FORMDV, and FRMXOP build the lines of
information about devices and XOPs to
or the user.

FORMDV

to

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
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

I

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

I

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

LB

o

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

LB

o

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

LB

o

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

to

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

LB

o

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.

an

accounting

record

LGWDEV
LGWDEV writes a message to a device.
log device or the attention device.

to

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

15

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

I

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:

1.

The XOP instruction is vectored into WCS

2. The XOP level provides a first

I

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

,I , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,I

,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,
I

X

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·

I

-

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

J

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

is

in

.S$SHARED

as

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

NO

DNOS Tools

DNOS System Design Document

3. Determine the illegal XOP WP and PC values
the LSM command with these responses:
[]

by

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

I

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)

I

(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.

in

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'

o

n or label

[comment]

[comment]
[comment]

o

[comment]
[comment]
[comment]
[comment]
[comment]
[comment]

o

[comment]

label

[comment]
[comment]
[comment]
[comment]

n or

label

label

{8,16}

o
type
type specified
by PCKREC above

n or label

o

[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.

I

[ 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

or

[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

a

gen~rates:

packed
record
PACKED RECORD

flag and generates: label
label

INTEGER;

label

LONGINT;

of

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

an

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.

a

labeled

block

of

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

of

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.

a

labeled

block

of

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