Digital PDFs

DEC-11-OMTBA-B-D

November 1975

210 pages

Original

7.1MB

Document:	RSX-11M Task Builder Reference Manual Version 2
Order Number:	DEC-11-OMTBA-B-D
Revision:	0
Pages:	210
Original Filename:	http://bitsavers.org/pdf/dec/pdp11/rsx11m_s/RSX11M_V2/DEC-11-OMTBA-B-D_TKB_197511.pdf

OCR Text

RSX-11M
Task Builder Reference Manual
DEC-11-0MTBA-B-D

RSX-llM Version 2

Order additional copies as directed on the Software
Information page at the back of this document.

digital equipment corporation · maynard. massachusetts

First Printing November, 1974
Revised, September 1975

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

@ 1974, 1975 by Digital Equipment Corporation

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

DIGITAL
DEC
PDP
DECUS
UNIBUS
COMPUTER LABS
COM TEX
DDT
DECCOMM

DECsystem-lo
DECtape
DIBOL
EDU SYSTEM
FLIP CHIP
FOCAL
INDAC
LAB-8

MASS BUS
OMNIBUS
OS/8
PHA
RSTS
RSX
TYPESET-8
TYPESET-11

LIMITED RIGHTS LEGEND
Contract No.
Contractor or Subcontractor:

Digital Equipment Corporation

All the material contained herein is considered limited rights data
under such contract.

"12/75-15

CONTENTS

PREFACE

xi
0.1
0.2

MANUAL OBJECTIVES AND READER ASSUMPTIONS
STRUCTURE OF THE DOCUMENT
ASSOCIATED DOCUMENTS

xi
xi

CHAPTER 1

INTRODUCTION

1-1

CHAPTER 2

COMMANDS

2-1

2 .1. 7

GENERAL COMMAND DISCUSSION
Task Command Line
Multiple Line Input
Options
Multiple Task Specification
Indirect Com.~and File Facility
Comments
File Specification

2-1
2-2
2-3
2-3
2-4
2-5
2-7
2-7

2.2
2.2.1
2.2.2
2.2.3

EXAMPLE: VERSION 1 OF CALC
Entering the Source Language
Compiling the FORTRAN Programs
Building the Task

2-8
2-10
2-11
2-11

2.3
2.3.l

SUMMARY OF SYNTAX RULES
Syntax Rules

2-11
2-12

SWITCHES AND OPTIONS

3-1

SWITCHES
Task Builder Switches
AC (Ancillary Control Processor)
CC (Concatenated Object Modules)
CP (Checkpointable)
CR (Cross Reference)
DA (Debugging Aid)
EA (Extended Arithmetic Element)
FP (Floating Point)
HD (Header)
LB (Library File)
MM (Memory Management)
MP (Overlay Description)
PI (Position Independent)
PM (Post Mortem Dump)
PR (Privileged)
SH (Short Map)
SP (Spool Map Output)
SQ (Sequential)
SS (Selective Search)
TR (Traceable)
XT:n (Exit on Diagnostic)
Examples
Override Conditions

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

/'\

...

u • .)

2.1
2 .1.1
2 .1. 2
2 .1. 3
2 .1. 4
2 .1. 5
2 .1. 6

CHAPTER 3
3.1
3 .1.1
3.1.1.1
3.1.1.2
3.1.1.3
3.1.1.4
3.1.1.5
3.1.1.6
3.1.1.7
3.1.1.8
3.1.1.9
3.1.1.10
3.1.1.11
3 .1.1.12
3 .1.1.13
3 .1.1.14
3.1.1.15
3 .1.1.16
3.1.1.17
3.1.1.18
3.1.1.19
3.1.1.20
3 .1. 2
3 .1. 3

iii

Xll

3.2
3.2.1
3.2.1.1
3.2.2
3.2.2.1
3.2.2.2
3.2.2.3
3.2.2.4
3.2.3
3.2.3.l
3.2.3.2
3.2.3.3
3.2.3.4
3.2.3.5
3.2.3.6
3.2.3.7
3.2.4
3.2.4.1
3.2.4.2
3.2.4.3
3.2.5
3.2.5.1
3.2.5.2
3.2.5.3
3.2.6
3.2.6.1
3.2.6.2
3.2.6.3
3.2.6.4
3.2.7
3.2.7.1
3.2.7.2

OPTIONS
Control Option
ABORT (Abort the Task Build)
Identification Options
TASK (Task Name)
UIC (User Identification Code)
PRI (Priority)
PAR (Partition)
Allocation Options
ACTFIL (Number of Active Files)
MAXBUF (Maximum Record Buffer Size)
FMTBUF (Format Buffer Size)
EXTSCT (Program Section Extension)
EXTTSK (Extend Task Memory)
STACK (Stack Size)
Examples of Allocation Options
Storage Sharing Options
COMMON (Resident Common Block)
LIBR (Resident Library)
Example of Storage Sharing Options
Device Specifying Options
UNITS (Logical Unit Usage)
ASG (Device Assignment}
Example of Device Specifying Options
Storage Altering Options
GBLDEF (Global Symbol Definition)
ABSPAT (Absolute Patch)
GBLPAT (Global Relative Patch)
Example of Storage Altering Options
Synchronous Trap Options
ODTV (ODT SST Vector)
TSKV (Task SST Vector)

3-10
3-13
3-13
3-13
3-14
3-14
3-14
3-14
3-15
3-15
3-16
3-16
3-17
3-17
3-18
3-18
3-18
3-18
3-19
3-19
3-20
3-20
3-20
3-20
3-21
3-21
3-21
3-22
3-22
3-23
3-23
3-23

3.3
3.3.1
3.3.2

EXAMPLE: CALC;2
Correcting the Errors in Program Logic
Building the Task

3-23
3-24
3-24

MEMORY ALLOCATION

4-1

4.1
4 .1.1
4 .1. 2
4.1.2.1
4 .1. 3

TASK MEMORY
P-Sections
Allocation of P-sections
Sequential Allocation of P-sections
The Resolution of Global Symbols

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

4.2
4.2.1
4.2.2

SYSTEM MEMORY
Mapped and Unmapped Systems
Privileged Tasks

4-7
4-8
4-8

4.3
4.3.l

TASK IMAGE FILE
Checkpoint Area

4-9
4-10

4.4
4.4.1
4.4.2
4.4.3

MEMORY ALLOCATION FILE
Memory Allocation File Format
Global Cross-Reference Format
Structure of the Memory Allocation File

4-11
4-11
4-16
4-16

4.5
4.5.l

EXAMPLE:
Heading

4-21
4-21

CHAPTER 4

CALC;l MAP

4.5.2
4.5.3
4.5.4

Segment Description
Program Section Allocation Synopsis
File Contents Description

4-21
4-22
4-22

4.6

EXAMPLE:

4-24

CHAPTER 5

CALC;2 MAP

OVERLAY CAPABILITY

5-1
5-1
5-2
5-4
5-4

5.1. 3
5.1.3.1
5.1.3.2
5.1.3.3
5.1.3.4
5 .1. 4
5.1.4.1
5.1.4.2
5 .1. 5

OVERLAY DESCRIPTION
Overlay Structure
Overlay Tree
Loading Mechanism
Resolution of Global Symbols in a
Multi-segment Task
Resolution of P-sections in a Multi-segment
Task
Overlay Description Language (ODL)
.ROOT and .END Directives
.FCTR Directive
.NAME Directive
.PSECT Directive
Multiple Tree Structures
Defining a Multiple Tree Structure
Multiple Tree Example
Overlay Core Image

5-6
5-7
5-7
5-8
5-9
5-10
5-10
5-11
5-12
5-13

5.2
5.2.1
5.2.2
5.2.3

EXAMPLE: CALC;3
Defining the ODL File
Building the Task
Memory Allocation File for CALC;3

5-15
5-15
5-16
5-16

5.3

EXAMPLE CALC;4

5-19

5.4

SUMMARY OF THE OVERLAY DESCRIPTION LANGUAGE

5-22

LOADING MECHANISMS

6-1

6.1
6 .1.1
6 .1. 2
6 .1. 3

AUTO LOAD
Autoload Indicator
Path-Loading
Autoload Vectors

6-2
6-2
6-4
6-5

6.2
6.2.1
6.2.2

MANUAL LOAD
Manual Load Calling Sequence
FORTRAN Subroutine for Manual Load Request

6-6

6-8

6.3

ERROR HANDLING

6-10

6.4

EXAMPLE:

6-10

6.5

GLOBAL CROSS-REFERENCE OF AN OVERLAID TASK

6-12

SHARED REGIONS

7-1

7.1

USING AN EXISTING SHARED REGION

7-3

7.2

CREATING A SHARED REGION

7-3

7.3

POSITION INDEPENDENT A..~D ABSOLUTE SHARED
REGIONS

7-4

5.1
5 .1.1
5.1. 2
5.1.2.1
5.1.2.2
5.1.2.3

CHAPTER 6

CHAPTER 7

CALC;5

5-4

6-7

7.4

EXAMPLE: CALC;6 BUILDING AND USING A SHARED
REGION
Building the Shared Region
Modifying the Task to Use the Shared Region
The Memory Allocation Files

7-5
7-5
7-6
7-7

HOST AND TARGET SYSTEMS

8-1

8.1
8 .1.1

BUILDING THE TASK FOR THE TARGET SYSTEM
Example

8-1
8-1

8.2
8.2.1
8.2.2
8.2.3

EXAMPLE: CALC;7
Rebuilding the Shared Region
Rebuilding the Task for the Target System
The Memory Allocation Files

8-2
8-2
8-3
8-3

MEMORY DUMPS

9-1

9.1
9 .1.1

POST-MORTEM DUMPS
Description of a Dump Generated by PMD ...

9-1
9-2

9.2
9.2.1
9.2.2

SNAPSHOT DUMP
Format of the SNPBK$ Macro
Format of the SNAP$ Macro
Example of a Snapshot Dump

9-6
9-6
9-7

ERROR MESSAGES

A-1

A. l

TASK BUILDER ERROR MESSAGES

A-1

A. 2

CROSS REFERENCE ERROR MESSAGES

A-10

TASK BUILDER DATA FORMATS

B-1

B.1.1
B. l. 2
B. l. 3
B. l. 4
B. l. 5
B. l. 6
B. l. 7

GLOBAL SYMBOL DIRECTORY (GSD)
Module Name
Control Section Name
Internal Symbol Name
Transfer Address
Global Symbol Name
Program Section Name
Program Version Identification

B-3
B-5
B-6
B-7
B-7
B-8
B-9

B.2

END-OF-GLOBAL-SYMBOL-DIRECTORY

B-11

B.3

TEXT INFORMATION

B-11

B.4

RELOCATION DIRECTORY
Internal Relocation
Global Relocation
Internal Displaced Relocation
Global Displaced Relocation
Global Additive Relocation
Global Additive Displaced Relocation
Location Counter Definition
Location Counter Modification
Program Limits
P-Section Relocation
P-Section Displaced Relocation

B-12
B-15
B-15
B-16
B-16
B-17
B-17
B-18

7.4.1
7.4.2
7.4.3
CHAPTER 8

CHAPTER 9

9.2.3
APPENDIX A

APPENDIX B
B.l

B.4.1
B.4.2
B.4.3
B.4.4

B.4.5
B.4.6
B.4.7
B.4.8
B.4.9
B.4.10
B.4.11

9-9

B-10

B-18

B-19
B-19

B-20

B.4.12
B.4.13
B.4.14

P-Section Additive Relocation
P-Section Additive Displaced Relocation
Complex Relocation

B-20
B-21
B-22

B.5

INTERNAL SYMBOL DIRECTORY

B-24

B.6

END OF MODULE

B-24

TASK IMAGE FILE STRUCTURE

C-1

C.l
C.1.1

LABEL BLOCK GROUP
Label Block Details

C-2
C-5

C.2
C.2.1
C.2.2

HEADER
Low Core Context
Logical Unit Table Entry

C-6
C-10
C-10

C.3
C.3.1
C.3.2
C.3.3
C.3.4

SEGMENT TABLES
Status
Relative Disk Address
Load Address
Segment Length

C.3.6
C.3.7

Link Down
Link Next

C.4

AUTOLOAD VECTORS

C-14

c.s

ROOT SEGMENT

C-14

C.6

OVERLAY SEGMENTS

C-14

APPENDIX D

RESERVED SYMBOLS

D-1

APPENDIX E

TAILORING THE TASK BUILDER

E-1

APPENDIX F

INCLUDING A DEBUGGING AID

F-1

APPENDIX G

RSX-llM TASK BUILDER GLOSSARY

G-1

APPENDIX H

CROSS REFERENCE PROCESSING AND DATA FORMATS

H-1

H.l

CROSS REFERENCE PROCESSOR

H-1

H.2

CREF INPUT FILE FORMAT

H-2

H.3

SEND PACKET FORMAT

H-4

H.4

ADJUSTING THE CROSS-REFERENCE LINE FORMAT

H-6

APPENDIX C

("'
') c:
'-' • ..J • _,

Link Up

C-11

C-12
C-12
C-12
C-13
C-13
C-13
C-13

vii

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

B-10
B-11
B-12
B-13

B-14
B-15
B-16
B-17
B-18
B-19
B-20
B-21
B-22
B-23
B-24
B-25
B-25A
B-26
B-27

Memory Allocation File for IMGl.TSK on a
Mapped System
Memory Allocation File for IMGl.TSK on an
Unmapped System
Cross Reference Listing for MPl.MAP
Memory Allocation File for CALC;l
(Mapped System)
Memory Allocation File for CALC;2.
(Mapped System)
Memory Allocation File for CALC;3
(Mapped System)
Memory Allocation File for CALC;4
{Mapped System)
Root Segment of Memory Allocation File for
CALC;5 (Mapped System)
Sample Overlaid Cross-Reference Listing
Memory Allocation File for the Shared Region
DTA (Mapped System)
Memory Allocation File for CALC;6
(Mapped System)
The Memory Allocation File for the Shared
Region (Unmapped System)
The Memory Allocation File for CALC;7
(Unmapped System)
Sample Post-Mortem Dump
Format of Snapshot Dump Control Block
Sample Program That Calls for Snapshot Dumps
Sample Snapshot Dump (Words Octal and RAD50)
Sample Snapshot Dump (Bytes Octal and ASCII)
General Object Module Format
GSD Record and Entry Format
Module Name Entry Format
Control Section Name Entry Format
Internal Symbol Name Entry Format
Transfer Address Entry Format
Global Symbol Name Entry Format
P-Section Name Entry Format
Program Version Identification Entry Format
End of GSD Record Format
Text Information Record Format
Relocation Directory Record Format
Internal Relocation Command Format
Global Relocation
Internal Displaced Relocation
Global Displaced Relocation
Global Additive Relocation
Global Additive Displaced Relocation
Location Counter Definition
Location Counter Modification
Program Limits
P-Section Relocation
P-Section Displaced Relocation
P-Section Additive Relocation
P-Section Additive Displaced Relocation
Complex Relocation
Internal Symbol Directory Record Format
End-of-Module Record Format

viii

4-12
4-14
4-17
4-23
4-24
5-17
5-20
6-11
6-12
7-8
7-9
8-4
8-5
9-4
9-9
9-10
9-11

9-12
B-3
B-5
B-6
B-6
B-7
B-7
B-8
B-10
B-11

B-11
B-12
B-14
B-15
B-15
B-16
B-16
B-17
B-17
B-18
B-18
B-19
B-19
B-20
B-21
B-22
B-24
B-24
B-24

FIGURES (Cont.)
Number
C-1
C-2
C-3
C-4
C-5
C-6
C-7
H-1
H-2

Page
Task Image on Disk
Label Block Group
Task Header Fixed Part
Task Header Variable Part
Logical Unit Table Entry
Segment Descriptor
Autoload Vector Entry
CREF Input File Format
Send Packet Format

C-1
C-3
C-7
C-9
C-11
C-12
C-14
H-3
H-5

TABLES
Number
3-1
3-2
4-1

Page
Task Builder Switches
Task Builder Options
P-Section Attributes

3-2
3-12
4-3

PREFACE

0.1

MANUAL OBJECTIVES AND READER ASSUMPTIONS

This manual is a tutorial, intended to introduce the user to the basic
concepts and capabilities of the RSX-llM Task Builder.
Examples are used to introduce and describe features of the Task
Builder.
These examples proceed from the simplest case to the most
complex. The reader may wish to try out some of the sequences to test
his understanding of the document.
The user should be familiar with the basic concepts of the RSX-llM
system described in the Introduction to RSX-llM and with
basic
operating procedures described in the RSX-llM Operator Procedures
Manual (see Section 0.3 below).

0.2

STRUCTURE OF THE DOCUMENT

The manual has nine chapters. The first four chapters describe the
basic capabilities of tne Task Builder.
The last four chapters
describe the advanced capabilities.
The Appendices list
error
messages and give detailed descriptions of the structures used by the
Task Builder.
Chapter 1 outlines the capabilities of the Task Builder.
Chapter 2 describes the command sequences used to
Task Builder.

interact

with

the

Chapter 3 lists the switches and options.
Chapter 4 describes memory allocation for the task and for the
and gives examples of the memory allocation file.
Chapter 5 describes the overlay capability and the
define an overlay structure.

language

system
used

Chapter 6 gives the two methods that can be used for
segments.

Chapter 7 introduces shared regions, which
tasks or to reduce
communication
between
requirements.

be
used
for
system's memory

can
the

overlay

Chapter 8 describes the considerations for building a task on
one
system to run on a system with a different hardware configuration.
Chapter 9
Snapshot.

describes

two

types of

memory

A Glossary of terms is given in Appendix G.
xi

dumps - Post-Mortem and

0.3

ASSOCIATED DOCUMENTS

Other manuals closely allied to the purposes of this document are described briefly in the RSX-llM/RSX-llS Documentation Directory, Order
No. DEC-11-0MUGA-B-D. The Documentation Directory defines the intended
readership of each manual in the RSX-llM/RSX-llS set and provides a
brief synopsis of each manual's contents.

xii

CHAPTER 1
INTRODUCTION

This manual introduces the user to the Task Builder
role of the Task Builder in the RSX-llM System.

and

defines

the

The fundamental executable unit in the RSX-llM System is the task.
routine becomes an executable task image, as follows:

The routine is written in a supported source language.

The routine is entered as a text file, through the editor.

The routine is translated to an
appropriate language translator.

The object module is converted to a task image using the Task
Builder.

Finally, the task is run.

object

module,

using

the

If errors are found in the routine as a result of executing the task,
the user edits the text file created in step 2 to correct the errors,
and then repeats steps 3 through 5.
If a single routine is to be executed, the use of the Task Builder is
appropriately simple.
The user gives as input only the name of the
file that contains the object module produced from the translation of
the program and gives as output a name for the task image.
In typical applications, generally a collection of routines is run
rather than a single program. In this case the user names each of the
object module files and the Task Builder links the object modules,
resolves any references to the system library, and produces a single
task image, ready to be installed and executed.
The Task Builder makes a set of assumptions (defaults) about the task
image
based on typical usage and storage requirements.
These
assumptions can be changed by including switches and options in the
task-building terminal sequence, thus directing the Task Builder to
build a task which more closely represents the input/output and
storage requirements of the task.

1-1

CHAPTER 1 INTRODUCTION
The Task Builder also produces, upon request, a memory allocation file
that contains information describing the allocation of storage, the
modules that comprise the task image, and the value of all global
symbols. The user may optionally request that a list of global symbols,
accompanied by the name of each referencing modules, be appended to the
file (global cross-reference).
If a reduction in the amount of memory required by the task is
necessary, the overlay capability can be used to divide the task into
overlay segments. Overlaying a task allows it to operate in a smaller
memory area and thus makes more space available to other tasks in the
system.
If the task is configured as an overlay structure,
(that is, a
multi-segment task) , the user becomes responsible for loading segments
into memory as they are needed. There are two methods provided for
loading overlay segments: autoload and manual.
The autoload method makes the loading of overlays transparent to the
user.
No special calls are required to load the overlay segments of
the task.
Loading of the
overlay
segments
is
accomplished
automatically by the Overlay Runtime System according to the structure
defined by the user at the time the task was built.
The manual load method requires that specific calls to the Overlay
Runtime System be included in the coding of the task, and gives the
user full control over the loading process.
If the task conununicates with another task, or makes use of resident
subroutines to save memory, the Task Builder allows the user to link
to existing shared regions and to create new shared regions for future
reference.
To move a task from one system to another with different memory
management status, a special switch (/MM) is included in the Task
Builder. The use of this switch allows tasks to be built on .one
system and to run on another.
The user can become familiar with the capabilities of the Task Builder
by degrees.
Chapter 2 of this manual gives the basic information
about Task Builder commands. This information is sufficient to handle
many applications. The remaining chapters deal with special features
and capabilities for handling advanced applications and tailoring the
task image to suit the application. The appendices give detailed
information about the structure of the input and output files
processed by the Task Builder.
This manual describes the handling of an example application, CALC.
In the first treatment of CALC, the user builds a task using all the
default assumptions. Successive treatments illustrate the main points
of each chapter in a realistic manner. Switches and options are added
as they are required, an overlay structure is defined when the task
increases in size, the loading of overlays is optimized, a shared
region is added and finally the task is moved from a development
system to a system which does not have memory management.
The memory allocation files for the various stages of task development
are included. The effect of a change can be observed by examining the
map for the previous example and the map for the example in which the
change is made.

1-2

CHAPTER 2
COMMANDS

2.1

GENERAL COMMAND DISCUSSION

This chapter describes conunand sequences that can be used to build
tasks.
Each conunand sequence is presented, by example, from the
simplest case to the most complex. All conunands are then sununarized
by a set of syntactic rules.
The first of a set of examples, designed to illustrate some of the
important features of the comrriand language, concludes this chapter.
This example illustrates a simple task building sequence for a typical
application.
The convention of underlining system-generated text to distinguish
from user type-in is used in this manual. For example:

TKB)IMGl=INl
The underline in the dialogue indicates that the system printed 'TKB>'
and the user typed 'IMGl=INl'.
Consider again the creation and execution of a task. Suppose a user
has written a FORTRAN program. He enters the program through a text
editor as the file PROG.FTN. Then he types the following conunands in
response to the Monitor Console Routine's request for input:
2FOR CALC=PROG
)TKB IMG=CALC
2I~I~

)RUN IMG
The first conunand (FOR) causes the FORTRAN compiler to translate the
source language of the file PROG.FTN into a relocatable object module
in the file CALC.OBJ.
The second conunand (TKB) causes the Task
Builder to process the file CALC.OBJ to produce the task image file
IMG.TSK. The third conunand (INS) causes Install to add the task to
the directory of executable tasks. Finally, the fourth conunand {RUN)
causes the task to execute.

2-1

CHAPTER 2.

COMMANDS

The example just given includes the command
2.TKB IMG=CALC
This command illustrates the simplest use of the Task Builder.
It
gives the name of a single file as output and the name of a single
file as input. This chapter describes, first by example and then by
syntactic definition, the complete facility for the specification of
input and output files to the Task Builder.

2.1.1

Task Command Line

The task-command-line contains the output
file
specifications,
followed by the input file specifications, separated by an equal sign.
There can be up to three output files and any number of input files.
The output files must be given in a specific order:
the first file
named is the task image file, the second is the memory allocation
file, and the third is the symbol definition file.
The memory
allocation file contains information about the size and location of
components within the task. The symbol definition file contains the
global symbol definitions in the task and their virtual or relocatable
addresses in a format suitable for re-processing by the Task Builder.
The Task Builder combines the input files to create a single
executable task image.
Any of the output file specifications can be omitted. When all
output files are given, the task-command line has the form:

three

task-image, map, symbol-definition = input,
Consider the following commands and
filenames are interpreted.

the

ways

which

the

output

Output Files

Command
2TKB IMGl,MPl,SFl=INl

The task image file is IMGl.TSK, the
memory allocation file is MPl.MAP, and
the symbol definition file is SFl.STB.

2TKB IMGl=INl

The task image file is IMGl.TSK.

2TKB ,MPl=INl

The memory allocation file is MPl.MAP.

2TKB ,,SFl=INl

The symbol definition file is SFl.STB.

)TKB IMGl,,SFl=INl

The task image file is IMGl.TSK and
symbol definition file is SFl.STB.

2TKB =INl

This is a diagnostic run with no
files.

2-2

the

output

CHAPTER 2.
2.1.2

COMMANDS

Multiple Line Input

Although there can be a maximum of three output files, there can be
any number of input files. When several input files are used, a more
flexible format is sometimes necessary, one that consists of several
lines.
This multi-line format is also necessary for the inclusion of
options, as discussed in the next section.
If the user types 'TKB' alone, the Monitor Console Routine (MCR)
invokes the Task Builder.
The Task Builder then prompts for input
until it receives a line consisting of only the terminating sequence
n 11
''" •

The sequence

)TKB
TKB)IMGl,MPl=INl
TKB)IN2,IN3
TKB)//
produces the same result as the single line conunand:
2_TKB IMGl,MPl=!Nl,IN2,IN3
This sequence produces the task image file IMGl.TSK and the memory
allocation file MPl.MAP from the input files INl.OBJ, IN2.0RJ, and
IN3.0BJ.
The output file specifications and the separator '=' must appear on
the first TKB command line. Input file specifications can begin or
continue on subsequent lines.

The terminating syrr~ol '//' directs the Task Builder to stop accepting
input, build the task, and return to the Monitor Console Routine
level.

2.1.3

Options

Options are used to specify the characteristics of the task being
built.
If the user types a single slash '/',the Task Builder
requests option information by displaying 'ENTER OPTIONS:'
and
prompting for input.

)TKB
TKB)IMGl,MPl=INl
TKB)IN2,IN3
TKB)/
ENTER OPTIONS:
TKB)PRI=lOO
TKB)COMMON=JRNAL:RO
TKB>//
In this sequence the user entered
the
options
l'.'RI=l0"
and
COMMON=.JR:1AL: RO and then typed a double slash to end option input.
It also returned to MCR! !

2-3

CHAPTER 2.

COMMANDS

The RSX-llM Task Builder provides 20 options.
The
interpretation of each option are given in Chapter 3.

syntax

and

The general form of an option is a keyword followed by an equal sign
'=' followed by an argument list. The arguments in the list are
separated from one another by colons. In the example given, the first
option consists of the keyword 'PRI' and a single argument 1 100'
indicating that the task is to be assigned ·the priority 100.
The
second option consists of the keyword 'COMMON' and an argument list
'JRNAL:RO', indicating that the task accesses a common region named
JRNAL and the access is read-only.
More than one option can be given on a line. The symbol exclamation
point '1' is used to separate options on a single line. For example:
TKB)PRI=lOO !

COMMON=JRNAL:RO

is equivalent to the two lines
TKB)PRI=lOO
TKB)COMMON=JRNAL:RO
Some options have argument lists that can be repeated.
The symbol
comma',' is used to separate the argument lists. For example:
TKB)COMMON=JRNAL:RO,RFIL:RW
In this command, the first argument list indicates that the task has
requested read-only access to the shared region JRNAL. The second
argument list indicates that the task has requested read-write access
to the shared region RFIL.
The following three sequences are equivalent:
TKB)COMMON=JRNAL:RO,RFIL:RW
TKB)COMMON=JRNAL:RO

COMMON=RFIL:RW

TKB)COMMON=JRNAL:RO
TKB)COMMON=RFIL:RW

2.1.4

Multiple Task Specification

If more than one task is to be built, the terminating symbol, '/'
(slash) , can be used following option input to direct the Task Builder
to stop accepting input, build the task, and request information for
the next task build.

2-4

CHAPTER 2.

COMMANDS

Consider the Sequence:
)TKB
TKB)IMGl=INl
TKB)IN2,IN3
TKB>I
ENTER OPTIONS:
TKB)PRI=lOO
TKB)COMMON=JRNAL:RO
TKB>I
TKB)IMG2=SUB1

TKB>ll

The Task Builder accepts the output and input file specifications and
the option input, then stops accepting input when it encounters the
'I' during option input. The Task Builder builds IMGl.TSK and returns
to accept more input for building IMG2.TSK.
2.1.5

Indirect Command File Facility

The sequence of commands to the Task Builder can be entered directly
or entered as a text file and later invoked through the indirect
command file facility.
To use the indirect command file facility, the user first

prepares

file

that contains the user command input for the desired interaction
with the Task Builder. He then invokes its contents by typing '@'
followed by the file specification.
Suppose the text file AFIL is prepared, as follows:
IMGl,MPl=INl
IN2,IN3

PRI=lOO
COMMON=JRNAL:RO

II
Later, the user can type:
>TKB

@AFIL

When the Task Builder encounters the symbol'@', it directs its search
for commands to the file specified following the '@' symbol. When the
Task Builder is accepting input from an indirect file, it does not
display prompting messages on the terminal. The 1-line command to
take commands from the indirect file AFIL is equivalent to the
keyboard sequence:
)TKB
TKB)IMGl,MPl=INl
TKB)IN2,IN3
TKB>I
ENTER OPTIONS:
TKB)PRI=lOO
TKB>COMMON=JRNAL:RO

TKB>ll

2-5

CHAPTER 2.

COMMANDS

t·7hen the Task Builder encounters a double-slash in the
indirect
file, it terminates indirect file processing, huil<ls the task, and
exits to the monitor upon completion.
However, if the Task Builder encounters an end-of-file in the indirect
file before a double slash, it returns its search for commands to the
terminal and prompts for input.
The Task Builder permits two levels of indirection in file references.
The indirect file referenced in a terminal sequence can contain a
reference to another indirect file.
Suppose the file BFIL.CMD contains all the standard options that are
used by a particular group at an installation.
That is every
programmer in the group uses the options in BFIL.CMD.
To include
these standard options in his task building file, the user modifies
AFIL to include an indirect file reference to BFIL.CMD as a separate
line in the option sequence.
The contents of AFIL.CMD then are:
IMGl,MPl=INl
IN2,IN3

PRI=lOO
COMMON=JRNAL:RO
@BFIL

II
Suppose the contents of BFIL.CMD are:
STACK=lOO
UNITS=S 1

ASG=DTl:S

The terminal equivalent of the command
)TKB @AFIL
then is:
)TKB
TKB)IMGl,MPl=INl
TKB)IN2,IN3
TKB>I
ENTER OPTIONS_:
TKB)PRI=lOO
TKB)COMMON=JRNAL:RO
TKB)STACK=lOO
TKB)UNITS=S
ASG=DTl:S

TKB>ll

The indirect file reference must appear as a separate line.
For
example, if AFIL.CMD were modified by adding the '@BFIL' reference on
the same line as the 'COMMON=JRNAL:RO' option, the substitution would
not take place and an error would be reported.

2-6

CHAPTER 2.
2.1.6

COMMANDS

Comments

Comment lines can be included at any point in the sequence. A comment
line begins with a semicolon ';' and is terminated by a carriage
return. All text on such a line is a comment.
Comments can be
included in option lines.
In this case, the text between the
semicolon and the carriage return is a comment.
Consider the annotation of the file just described;
the user adds
comments to provide more information about the purpose and the status
of the task he is working on. Specifically, he adds some identifying
lines, notes the function of his input files and shared region, and
concludes with a comment on the current status of the task.
The
contents of the file are as follows:
; TASK 33A

DATA FROM GROUP E-46 WEEKLY
IMGl,MPl=
PROCESSING ROUTINES
INl
STATISTICAL TABLES
IN2

ADDITIONAL CONTROLS
IN3

PRI=lOO
i

COHMON=JRNAL:RO ; RATE TABLES
I

; TASK STILL IN DEVELOPMENT
i

II
2.1.7

File Specification

Thus far the interaction with the Task Builder has been illustrated in
terms of filenames. The Task Builder adheres to the standard RSX-llM
conventions for file-specification.
For any file, the user can
specify the device, the user identification code, the filename, the
type, the version number, and any number of switches.
Thus, the file specification has the form:
device: [group,member]filename.type;version/sw ...

2-7

CHAPTER 2 •

COMMANDS

Consider, once again, the commands:
>TKB
TKB>IMGl,MPl=INl
TKB>IN2,IN3
TKB>//
When the files are specified by n~e only, the default assumptions for
device, group, member, type, version and switch settings are applied.
For example, if the default user identification code is [200,200], the
task image file specification of the example is assumed to be:
SY0:[200,200]IMG1.TSK;l
That is, the task image file is produced on the system device
(SYO)
under user identification code [200,200]. The default type for a task
image file is TSK and since the name IMGl.TSK is new, the version
number is 1.
The default settings for all the task image switches
also apply. Switch defaults are described in full in Chapter 3.
Consider the following commands:
>TKB
TKB)[20,23]IMG1/CP/DA,LP:/CR=IN1
TKB>IN2;3,IN3
TKB>//
This sequence of commands produces the task image file IMGl.TSK;l
(actually, it produces IMGl.TSK with a version 1 higher than the
current version of IMGl.TSK) under user identification code [20,23]
on the system device. The task image is checkpointable and contains
the standard debugging aid. The memory allocation map, including a
global cross-reference listing, is produced on the line printer. The
task is built from the latest versions of INl.OBJ and IN3.0BJ and a
specific version, number 3, of IN2.0BJ. The input files are all found
on the system device.
For some files, a device specification is sufficient.
In the above
example, the memory allocation file is fully specified by the device
LP. The memory allocation file is produced on the line printer, but
is not retained as a file.
In this example, switches CP, CR, and DA are used. There are 20 Task
Builder switch settings. The code, syntax and meaning for each switch
are given in Chapter 3.
2.2

EXAMPLE:

VERSION 1 OF CALC

An example task, CALC, is developed i~ this ~anual fr~m ~e sim~le
case
given
here through successive refinement~ and increas7ng
complexity. The successive versions of C~C are designed.to summarize
the major points of each chapter and to illustrate possible uses for
the facilities described.

2-8

CHAPTER 2.

COMMANDS

As the first step in the development of the task CALC, three separate
FORTRAN routines are entered by means of a text editor, translated by
the FORTRAN compiler, and built into a task by the Task Builder.
The routines are:
RDIN

which reads and analyzes input data and selects a
processing routine on the basis of the analysis.

data

PROCl

which processes the input according to a specified
of rules1 and

set

RPRT

which outputs the results as a series of reports.

The three routines communicate with each other through a common
named 'DTA'.

2-9

block

CHAPTER 2 •
2.2.1

COMMANDS

Entering the Source Language

The source for the FORTRAN programs of the example CALC is entered and
filed by means of the text editor EDI. The user invokes EDI and types
in the source for the FORTRAN programs. The relevant parts of the
programs are shown below:
)EDI
EDI)RDIN.FTN
lCREATING NEW FILE]
INPUT
C
READ AND ANALYZE INPUT DATA,

SELECT A PROCESSING ROUTINE

c
C

ESTABLISH COMMON DATA BASE

c
C
1
C
C

COMMON /DTA/ A(200), I
READ IN RAW DATA
READ (6 ,1) A
FORMAT (200F6.2)
CALL DATA PROCESSING ROUTINE
CALL PROCl
GENERATE REPORT
CALL RPRT

END
*CL
EDI)PROCl.FTN
(CREATING NEW FILE]
INPUT
FIRST DATA PROCESSING ROUTINE
c
COMMUNICATION REGION
c
COMMON /DTA A(200),I
RETURN
END
_!CL
EDI> RPRT. FTN
[CREATING NEW FILE]
INPUT
INTERIM REPORT PROGRAM
c
COMMUNICATION REGION
c
COMMON /DTA/ A(200),I
RETURN
END
~EX

[EXIT]

2-10

CHAPTER 2.
2.2.2

COMMANDS

Compiling the FORTRAN Programs

The FORTRAN programs are compiled by the following sequence:
)FOR
FOR)RDIN,LRDIN=RDIN
FOR)PROCl,LPROCl=PROCl
FOR)RPRT,LRPRT=RPRT
The first command invokes the FORTRAN compiler.
The second command
directs the compiler to take source input from RDIN.FTN, place the
relocatable object code in RDIN.OBJ and write ti~e listing
in
LRDIN.LST.
The remaining commands perform similar actions for the
source files PROCl and RPRT.

2.2.3

Building the Task

The task for the three programs is built in the following way:
)TKB CALC;l,LP:=RDIN,PROCl,RPRT
The task building command specifies the name of the task image file
(CALC.TSK;l), the device for the memory allocation file (LP) and the
names of the input files (RDIN.OBJ, PROCl.OBJ and RPRT.OBJ). The task
makes use of all the default assumptions for switches and options.

2.3

SUMMARY OF SYNTAX RULES

Syntactic rules for the interaction between the user and the Task
Builder
are given here.
These rules do not present any new
information; rather, they define, in a more formal and concise way,
the syntax of the commands already described in this chapter.

In the syntax rules,
example,

the

symbol

indicates

repetition.

For

input-spec, •••
means one or more input-spec items separated by commas;
of the following forms:
input-spec
input-spec, input-spec
input-spec, input-spec, input-spec
etc.

2-11

that is,

one

CHAPTER 2.
As

COMMANDS

another example,
arg:

means one or more arg items separated by colons.
As

a final example,
TKB>input-line

means one or more of the indicated 'TKB input-line' items.

2.3.l

Syntax Rules

The syntax rules are as follows:
1.

A task-building-command can have one of several
first form is a single line:

forms.

>TKB task-command-line
The second form has additional lines for input file names:
)TKB
TKB>task-command-line
TKB>input-line

...

TKB>terminating-symbol
The third form allows the specification of options:
)TKB
TKB)task-command-line
TKB)/
ENTER OPTIONS:
TKB)option-line
TKB)terminating-symbol
The fourth form has both input lines and option lines:
)TKB
TKB>task-command-line
TKB>input-line

TKB)/
ENTER OPTIONS :
TKB>option-line

...

TKB>terminating-symbol

2-12

The

CHAPTER 2.

COMMA..~DS

The terminating symbol can be:
I
if more than one task is to be built, or
II
if control is to return to the Monitor
Console Routine.
2.

A task-command-line has one of the three forms:
output-file-list = input-file,

...

=input-file, •••
@indirect-file
where indirect-file is a
Rule 7.
3.

file-specification

defined

An output-file-list has one of the three forms:
task-file, map-file, symbol-file
task-file, map-file
task-file
where task-file is the file specification for the task image
file;
map-file is the file specification for the memory
allocation file; and symbol-file is the file specification
for the symbol definition file. Any of the specifications
can be omitted, so that, for example, the form:
task-file,,symbol-file
is permitted.

An input-line has either of the forms:
input-file, •••
@indirect-file
where input-file and indirect-file are file-specifications.

An option-line has either of the forms:
option 1 •••
@indirect-file
where indirect-file is a file-specification.

2-13

CHAPTER 2.
6.

COMMANDS

An option has the form:
keyword = argument-list,

...

where the argument-list is
arg: •••
The syntax for each of the 20 options is given in Chapter 3.
7.

file-specification
conforms
conventions. It has the form

standard

RSX-llM

device: [group,member]filename.type;version/sw ...
where everything is optional.
follows:

The components are defined

device

is the name of the physical device on which the
volume containing the desired file is mounted.
The name consists of two ASCII
characters
followed by an optional 1- or 2-digit octal wiit
number; for example, 'LP' or 'DTl'.

group

is the group nwnber
through 377 (octal).

member

is the member number in the range 1 through
(octal) .

and

the

range

1
377

The combination of the group number and the member number is
called the user identification code (UIC).
filename is the name of the desired file. The file name
can be from 1 to 9 alphanumeric characters, for
example, CALC.
type

is the 3-character type identification.
Files
with the same name but a different function are
distinguished from one another by the file type;
for example, CALC.TSK and CALC.OBJ.

version

is the octal version number of the
file.
Various
versions
of
the
same
file are
distinguished from each other by this number;
for example, CALC;l and CALC;2.

is a switch specification. More than one switch
can be used, each separated from the previous
one by a ' / ' .
The switch is a 2-character
alphabetic name which identifies the switch
option.
The permissable switch options and
their syntax are given in Chapter 3.

2-14

CHAPTER 2.

COMMANDS

The device, the user identification code, the type, the
the switch specifications are all optional.

version,

The following table of default assumptions
components of a file-specification:

item

applies

and

missing

default

device

SYO, the system device

group

the system group number currently in effect

member

the system member number currently in effect *

type

task image
TSK
memory allocation
MAP
symbol definition
STB
obiect module
OBJ
object module library OLB
overlay description
ODL
indirect command
CMD

version

for an input file, the
version.

highest-numbered

for an output file, one
greater
highest-numbered existing version.

switch

existing
than

the

(the default for each switch is given in Chapter
3.)
*Except when appearing with an overlay description, an explicit device
or UIC designation becomes the default for subsequent files separated
by commas.
For example:
DTl:IMGl,MPl=INl,DF:IN2,IN3
File

Device

IMGl.TSK
MPl.MAP
INl.OBJ
IN2.0BJ
IN3.0BJ

DTl
DTl
SYO
DFO
DFO

2-15

CHAPTER 3
SWITCHES AND OPTIONS

This chapter describes the ways in which additional directions can be
given to the Task Builder for the construction of a task image. Much
of the information in this chapter is quite specialized and refers to
topics that are described later in the manual. A quick reading of
this chapter will show the user the range of ways he can adjust the
task image he builds. Later, the chapter can be used as a reference
for practical applications with specific requirements.

3.1

SWITCHES

The syntax for a file specification, as given in Chapter 2, is:
dev: [group,rnernber]filenarne.type;version/sw-l/sw-2 ... /sw-n
The file specification concludes with zero or more switches,
sw-2, ••• , sw-n, and these are described in what follows:

sw-1,

~·vcu by the user, the Task Builder establishes a
setting for the switch, called a default assumption.

When a switch is not

A switch is designated by a 2-character switch code.
The allowable
code values are defined by the processor which interprets the code.
The code is an indication that the switch applies or does not apply.
For example, if the switch code is CP (checkpointable), then the
switch settings recognized are:
/CP
/-CP
/NOCP

The task is checkpointable.
The task is not checkpointable.
The task is not checkpointable.

The switch codes allowed by the Task Builder are given in alphabetical
order in Table 3-1. After the alphabetical listing, a more detailed
description is given for each switch.

3-1

CHAPTER 3.

SWITCHES AND OPTIONS
Table 3-1
Task Builder Switches
APPLIES
TO FILE*

MEANING

CODE

DEFAULT

Task is an ancillary control processor.

-AC

Input File Consists of concatenated
object modules.

Task is checkpointable.

-CP

Append a global cross-reference
listing to the memory allocation
file.

-CR

Task contains a debugging aid.

T,I

-DA

Task uses extended arithmetic
element.

-EA

Task uses the floating
point processor.

-FP

Task image includes a header.

T,S

Input file is a library file.

-LB

System has memory management.

Input file contains an overlay
description.

-MP

Task is position independent.

T,S

-PI

Post mortem dump is requested.

-PM

Task has privleged access rights.

-PR

Short memory allocation file is
requested.

-SH

Spool map output.

Task p-sections are allocated
sequentially.

-SQ

Selective Search for global
symbols.

-SS

Task is to be traced.

-TR

XT:n

Task Builder exits after n
diagnostics.

-XT

MM or-MM**

T
S
M
I

task image file
symbol definition file
memory allocation file
input file

The default for the memory management switch is MM if the host
system has memory management hardware and -MM if the host system
does not have memory management hardware.
3-2

CHAPTER 3.
3.1.1

SWITCHES AND OPTIONS

Task Builder Switches

The switches recognized by the Task Builder are described in
section. For each switch, the following information is given:

this

the switch mnemonic,

the file(s) to which the switch can be applied.

a description of the
Builder, and

the default assumption made if the switch is not present.

effect

the

switch

the

Task

The switches are given in alphabetical order.

3.1.1.1

AC (Ancillary Control Processor)

file:

task image

meaning:

The task is an ancillary control processor.
An ancillary
control processor is a privileged task that extends certain
Executive functions. For example, the system task 'FllACP'
is
an
ancillary control processor that receives and
processes file related input and output requests.

effecti

The task is privileged.
The Task Builder sets the AC
attribute flag and the privileged attribute flag in the task
label block flag word.

default:

-AC

3.1.1.2

CC (Concatenated Object Modules)

file:

input

meaning:

The file contains more than one object module.

effect:

The Task Builder includes in the task image all the modules
in the file.
If this switch is negated, the Task Builder
includes in the task image only the first module in the
file.

default:

3-3

CHAPTER 3.

SWITCHES AND OPTIONS

3.1.1.3

CP (Checkpointable)

file:

task image

meaning:

The task is checkpointable.

effect:

The Task Builder allocates in the task image a checkpoint
area equal to the size of the partition for which the task
is built. If the task is checkpointed, the entire partition is recorded in this area. The checkpoint area is
described in connection with the task image in Chapter 4.

default:

-CP

3.1.1.4

CR (Cross Reference)

file:

task image or memory allocation

meaning:

A global cross-reference is to be appended to the memory
allocation file.

effect:

The cross-reference task is invoked to append a list of
global symbols, and their referencing modules, to the
memory allocation file. The format and content of the
cross-reference is explained in Section 4.4.2.

default:

-CR

3.1.1.5

DA (Debugging Aid)

file:

task image or input

meaning:

The task includes a debugging aid.

effect:

The Task Builder performs the special processing described
in Appendix F. If this switch is applied to the task image
file, the Task Builder automatically includes the system
debugging aid SY: [l,l]ODT.OBJ in the task image.

default:

-DA

3.1.1.6

EA (Extended Arithmetic Element)

file:

task image

meaning:

The task uses the KE-llA Extended Arithmetic Element.

effect:

The Task Builder allocates three words in the task header
for the extended arithmetic element save area.

default:

-EA

3-4

CHAPTER 3.

SWITCHES AND OPTIONS

3.1.1.7

FP (Floating Point)

file:

task image

meaning:

The task uses the Floating Point Processor.

effect:

The Task Builder allocates 25 words in the task
the floating point save area.

default:

-FP

3.1.1.8

HD (Header)

file:

task image or symbol definition

meaning:

A header is to be included in the task image. The negation
of this switch to produce a shared region is described in
Chapter 7.

effect:

The Task Builder constructs a header in the task image.
content of the header is described in Appendix c.

default:

3.1.l.9

LB (Library File)

header

for

The

This switch has two forms:

Without arguments:

Witi~

arguments:

The interpretation of the switch depends upon the form.
file:

input

meaning:

If the switch is applied without arguments, the input
file is assumed to be a library file of relocatable
object modules to be searched for the resolution of
undefined global references.

If the switch is applied with arguments, the input file
is assumed to be a library file of relocatable object
modules from which the modules named in the argument
list are to be taken for inclusion in the task image.

If no arguments are specified, the Task Builder searches
the file to resolve undefined global references and
extracts from the library for inclusion in the task
image any modules that contain definitions for such
references.

If arguments are specified, the Task Builder
only the named modules ~n the task image.

effect:

3-5

includes

CHAPTER 3.

SWITCHES AND OPTIONS
NOTE

default:

If the user wants the Task Builder to
search a library file both to resolve
global references and to select named
modules for inclusion in the task image,
he must name the library file twice:
once,
with
the
LB switch and no
arguments to direct the Task Builder to
search the file for undefined global
references, and a second time with the
desired
modules to direct the Task
Builder to include those modules in the
task image being built.

The SS option may be used with the LB
option (with or without arguments)
to perform a selectb!e search for
global definitions.

-LB

3.1.1.10 MM (Memory Management)
file:

task image

meaning:

The system on which the task will run has memory management
hardware.
Mapped and unmapped systems are described in
Chapter 4. The use of this switch to build a task to run on
another system with different mapping status is illustrated
in Chapter 8.

effect:

The Task Builder allocates memory for a mapped or unmapped
system independent of the mapping status of the system on
which the task is being built. If -MM is specified, the
Task Builder assumes an unmapped system
and
no
memory
managmenet.

default:

MM or -MM. The Task Builder allocates memory according to
the mapping status of the system on which the task is being
built.

3.1.1.11

MP (Overlay Description)

file:

input

meaning:

The input file describes an overlay structure for the
Overlay descriptions are discussed in Chapter s.

effect=

The Task Builder receives all the input file specifications
from this file and allocates memory as directed by the
overlay description.

3-6

task.

CHAPTER 3.

SWITCHES AND OPTIONS
NOTE
When an overlay description file is
specified as the input file for a task,
it must be
the
only
input
file
specified.
The Task Builder does not
accept any other input files.

default:

-MP

3.1.1.12

PI (Position Independent)

file:

task image or symbol definition

meaning:

The task contains only position independent code or data.
Position independent shared regions are described in Chapter
7.

effect:

The Task Builder sets the Position

default:

-PI

Independent Code
attribute flag in the task label block flag word.

(PIC)

3.1.1.13

PM (Post Mortem Dump)

file:

task image

meaning:

In the event of an abnormal task termination, the system
will automatically list the contents
of task memory.
(See Chapter 9 for information on memory dumps.)

effect:

The Task Builder sets the
Task label flag word.

default:

-PM

Post-Mortem

Dump flag in

the

3.1.1.14

PR (Privileged)

file:

task image

meaning:

The task is privileged with respect to memory access rights.
The task can access the I/O page, and the Executive in
addition to its own partition.
Privileged tasks
are
described in Chapter 4.

effect:

The Task Builder sets the Privileged Attribute flag
task label block flag word.

default:

-PR

3-7

the

CHAPTER 3

SWITCHES AND OPTIONS

3.1.1.15

SH (Short Map)

file:

memory allocation

meaning:

The short version of the memory allocation file is produced.
Chapter 4 describes the memory allocation file and gives a
short and a long version of a memory allocation file.

effect:

The Task Builder does not produce the
section of the memory allocation file.

default:

-SH

3.1.1.16

SP (Spool Map Output)

file:

memory allocation

meaning:

Invoke the print symbiont to list the map file on LP~.
The file is deleted after printing.

effect:

The Task Builder creates a map file on SY~ and
then
uses the print symbiont to list the file. The file is
deleted after printing.

default:

3.1.1.17

SQ (Sequential)

file:

task image

meaning:

The task image is constructed from the specified program
sections in the order in which they are input. Chapter 4
describes the allocation of the task image and gives an
example which shows the allocation performed under the
default assumption and the allocation performed when the SQ
switch is specified.

effect:

The Task Builder does
alphabetically.

default:

-SQ

3.1.1.18

SS (Selective Search)

file:

input

meaning:

Do not include a global symbol definition from this module
unless a previously undefined reference to the global
symbol exists.

effect:

The Task Builder searches the Global Symbol Table for each
global symbol defined in the module. If an undefined
reference to a symbol is found, the corresponding definition
is included. When applied to a library or concatenated
object file, the switch is applied to each module in the
file.

default:

-SS

not

3-8

re-order

the

'File

program

Contents'

sections

CHAPTER 3.

SWITCHRS AND OPTIONS

3.1.1.19

TR (Traceable)

file:

task image

meaning:

The task is traceable.

effect:

The Task Builder sets the T bit in the initial PS word of
the task. When the task is executed, a trace trap occurs on
the completion of each instruction.

default:

-TR

3.1.1.20

XT:n (Exit on Diagnostic)

file:

task image

meaning:

More than n error diagnostics are not acceptable.

effect:

The Task Builder exits after n error diagnostics have been
produced.
The number of diagnostics can be specified as a

decimal or octal number, using the convention;
n.

means a decimal number (the decimal point flust be
included) .
#n or n means an octal number.

If n is not specifier'!., it is assurned to be 1.

default:
3.1.2

-XT

Examples

The following terminal sequences illustrate the use of
file specifications and the resulting interpretation~
Terminal Sequence

)TKB

IMGl/CP/DA=INl/-CC

switches

The task IMGl.TSK is checkpointable
includes
the
debugging
SY:[l,l]ODT.OBJ.
The input file
contains only one object module.

and
aid
INl

Interpretation

)TKB
TKB)IMG2/PR,MP1/SH=
TKB)IN2,RSX11M.STB
TKB)//

The task IMG2.TSK is a privileged task.
The short map MPl.MAP is requested. The
inputs for the task are the file IN2.0BJ
and
the
symbol
definition
file
RSXllM.STB which links the task to the
subroutines and data
base
of
the
Executive.

)TKB

The task IMG3.TSK contains the input
file IN3.0BJ, the modules SUBl and SUB2
from the library file LBl, and the
debugging aid DBGl.OBJ. The
library
file LBl.OLB is speci:ied a second time
without
arguments so that the Task
Builder will search
the
file
for
undefined global references.

TKB)IMG3=IN3
TKB)LBl/LB:SUBl:SUB2
TKB)LBl/LB,DBGl/DA

TKB>//

3-9

CHAPTER 3.

SWITCHES AND OPTIONS

The Task IMG4.TSK is built from the
overlay description contained in the
than
five
file TREE.ODL.
If more
diagnostics
occur, the Task Builder
aborts the run.

)TKB IMG4/XT:S=TREE/MP

3.1.3

Override Conditions

In some cases, it is not reasonable to apply two particular switches
to a file. When such a conflict occurs, the Task Builder selects the
overriding switch according to the following table:
switch

switch

overriding switch

For example, in the terminal sequence:
MCR)TKB IMGS=IN6,IN5/LB/CC
The input file INS is assumed to be a library file that is to be
searched for undefined global references and not an input file with
several object modules.

3.2

OPTIONS

Twenty options are available to the user of the RSX-llM Task
Builder.
These options give the Task Builder information about the
characteristics of the task.
Some of these options are of interest to all users of the system, some
of interest only to the FORTRAN programmer, and some of interest only
to the MACR0-11 progranuner. The interest range is given with the
description of the option. For more detailed descriptions
of
the
FORTRAN-related options, read the appropriate FORTRAN IV or
FORTRAN
IV-PLUS manual.

3-10

CHAPTER 3.

SWITCHES AND OPTIONS

Options can be divided into seven categories.
The identifying
mnemonics and a brief description for each category are listed below:
1.

contr

- Control options are used to affect Task Builder
execution.
ABORT is the only member of this
category. The user can direct the Task Builder to
abort the task build by the use of the option
MO~.

ident

- Identification options are used to identify task
characteristics.
The task name, priority, user
identification code,
and
partition
can
be
specified by the use of options in this category.

alloc

- Allocation options are used to modify the task's
memory
allocation.
The
size
of
stack,
program-sections in the task, and FORTRAN work
areas and buffers can be adjusted by the use of
options in this category.

- Storage sharing options are used to indicate
task's intention to access a shared region.

device

- Device specifying options are used to specify the
number of units required by the task and the
assignment of physical devices to logical unit
nwnbers.

alter

- Content altering options are used to define a
global symbol and value or to introduce patches in
the task image

synch

- Synchronous tran options
synchronous trap vectors.

are

used

the

define

Table 3-2 lists all the options alphabetically. A brief description
of each option is given.
The interest range of the option is
indicated by the following codes:
F
M
FM

option is of interest to FORTRAN programmers only.
option is of interest to MACR0-11 programmers only.
option is of interest to both.

The mnemonic for the category to which
indicated in the table.

the

option

belongs

The options are then described in more detail by category.

3-11

also

CHAPTER 3.

SWITCHES AND OPTIONS
Table 3-2
Task Builder Options

Option

Meaning

Interest

Category

ABORT

Direct TKB to terminate build.

contr

ABS PAT

Declare absolute patch values.

alter

ACTFIL

Declare number of files open
simultaneously.

alloc

ASG

Declare device assignment to
logical units.

device

COMMON

Declare task's intention to access
a memory resident shared region.

EXTSCT

Declare extension of a program
section.

alloc

EXTTSK

Extend the amount of memory
owned by a task.

alloc

FMTBUF

Declare extension of buff er used
for processing format strings
at run-time.

alloc

GBLDEF

Declare a global symbol definition.

alter

GBLPAT

Declare a series of patch values
relative to a global symbol.

alter

LIBR

Declare task's intention to access
a memory resident shared region.

.MAXBUF

Declare an extension to the FORTRAN
record buffer.

alloc

ODTV

Declare the address and size of
the debugging aid SST vector.

synch

PAR

ident

PRI

Declare partition name and
dimensions.
Declare priority.

ident

STACK

Declare the size of the stack.

alloc

TASK

Declare the name of the task.

ident

TSKV

Declare the address of the task
SST vector.

synch

UIC

Declare the user identification code
under which the task runs.

ident

UNITS

Declare the maximum number of mi ts.

device

3-12

CHAPTER 3.
3.2.1

SWITCHES AND OPTIONS

Control Option

There is only one control option.
users of the system.

This option is of interest

3.2.1.1 ABORT (Abort the Task Build} - The ABORT option
Task Builder to abort the task build.

all

directs

the

This option is used when it is discovered that an earlier error in the
terminal sequence
task image.

will cause the Task Builder to produce an unusable

The task Builder, on recognizing the keyword
input and restarts for another task build.

ABORT,

stops

accepting

An example of the use of the ABORT option is given in section 3.3.
ABORT = n

syntax:

where n

default:

is an integer value. The integer is required to
satisfy the general form of an option; however,
the value is ignored in this case.

none
NOTE
The use of CTRL/Z causes
Builder to stop accepting
build the task.

the
Task
input and

The ABORT option is the only proper way
to restart the Task Builder if an error
is discovered and the Task
Builder
output is not desired.

3.2.2

Identification Options

Four options are available for providing identifying information for
the task. These options are of interest to all users of the system.
The identification options specify the name of the task, the user
identification code, the priority, and the partition.
The user
identification code can be specified when the task is run.
If such a
specification is not made at run time, the user identification code
established when the task was built is used.

3-13

CHAPTER 3.

3. 2. 2 .1
task.

SWITCHES AND OPTIONS

TASI~

(Task Uame) - The

TASI~

option

specifies the name of the

syntax:

TASK = task-name

where:

task-name is a 1- to 6-character radix-SO
the task.

default:

The first six characters of the name of the task image file
are used to identify the task when the task is installed.

name

identifying

3.2.2.2 UIC (User Identification Code) - The UIC option declares the
User Identification Code
(UIC)
for the task if no UIC is specified
when execution is requested.
syntax:

UIC =

[group,member]

where:

group

is an octal number in
specifies the group.

the

range

- 377

which

member

is an octal number in
specifies the member.

the

range

- 377

which

running

The UIC under which the Task
(normally the terminal UIC) .

default:

Builder

3.2.2.3 PRI (Priority) - The PRI declares the priority at which the
task executes.
If no priority is specified when the task is
installed, this priority is used.

= priority-number

syntax:

PRI

where:

priority-number is a decimal integer in the range 1 - 250

default:

(established by Install)
Procedures Manual.

See

the RSX-llM

Operator's

3.2.2.4 PAR (Partition) - The PAR option identifies the partition for
which the task is bµilt.
In a mapped system a task can be installed
partition large enough to contain it.

any

system or user

In an unmapped system, the task is bound to physical memory and must
be installed in the partition for which it was built or in a partition
starting at the same memory address as that partition.
syntax:

PAR = pname [:base:length]

where

pname

is the name of the partition

base

is the octal byte address defining
the partition.

3-14

the

start

CHAPTER 3.

SWITCHES AND OPTIONS

length

is the octal number
partition.

bytes

contained

the

In a mapped system a length
of
zero implies a
system-controlled partition. A non-zero
length
implies a user-controlled partition.
default:

PAR

GEN

If the base and length are not specified, the Task Builder tries to
obtain that information from the system on which the task is being
built. If the partition named is resident in that system, the base
and length can be obtained.
The Task Builder binds the task to the addresses defined
by
the partition base and verifies that the task does not exceed the
length specification if the partition is user-controlled.
To determine the validity of the task the Task Builder must consider
two types of task images, runnable and non-runnable, and two types of
systems, mapped and unmapped. A runnable task image must have a
header and can be installed and run. A non-runnable image must not
have a header and can not be executed directly.
The Task Builder,
therefore, enforces the address limits according to the type of image
and type of system, as follows:
Runnable tasks

base
length
high address
bounc1

3.2.3

Non-runnable irna9eR

mapped

unmapped

mapper!

unmapped

I')

on 32wm 5
houn<lary

on 4k
boundarv

on 32word
boundary

nultiple
of 12words

multiple
of 12words

(3/K-3:?.)
words

(32K-32)Words

multiple multiple
o:f 32words of 32words
(32X-3?)

/.8K Words

words

Allocation Options

There are six options that direct the Task Builder to change the
length of an allocation. The first three options are of interest only
to the FORTRAN prograrrmler. The remaining options are of interest to
all.

3.2.3.1 ACTFIL (Number of Active Files) - The ACTFIL option declares
the number of files that the task can have open simultaneously. For
each active file, an allocation of approximately 512 bytes is made.

3-15

CHAPTER 3.

SWITCHES AND OPTIONS

If the number of active files used by a task is less than the default
assumption of four, the ACTFIL option can be used to save space. If
the number of active files is more than the default assumption, the
ACTFIL option must be used to direct the Task Builder to make the
additional allocation so that the task can run.
The FORTRAN Object Time System (OTS) and File Control Services
(FCS)
must be included in the task image for the extension to take place.
The p-section that is extended has the reserved name '$$FSR1'.
syntax:

ACTFIL = file-max

where:

file-max

default:

ACTFIL = 4

is a decimal integer indicating the maximum number
of files which can be open at the same time.

3.2.3.2 MAXBUF (Maximum Record Buffer Size) - The MAXBUF option
declares the maximum record buffer size required for any file used by
the task.
This option must be used to extend the buffer whenever a file is to be
processed in which the maximum record size exceeds the default buffer
length.
The FORTRAN Object Time System must be included in the task image for
the extension to take place. The program section that is extended has
the reserved name '$$IOB1'.
syntax:

MAXBUF = max-record

where:

max-record

default:

MAXBUF = 132

than
the
is a decimal integer, larger
default, which specifies the maximum record
size in bytes.

3.2.3.3 FMTBUF (Format Buffer Size) - The FMTBUF option declares the
length of internal working storage allocated for the compilation of
format specifications at run-time. The length of this area must equal
or exceed the number of bytes in the longest format string
to
be
processed.
Run-time compilation occurs whenever an array is referenced
as
source of formatting information within a FORTRAN I/O Statement.
program section to be extended has the reserved name '$$0BF1'.
syntax:

FMTBUF = max-format

where:

max-format

default:

FMTBUF = 132

the
The

is a decimal integer larger than the default,
which specifies the number of characters in
the longest format specification~

3-16

CHAPTER 3.

SWITCHES AND OPTIONS

3.2.3.4 EXTSCT (Program Section Extension) - The
EXTSCT
option
declares an extension in size for a p-section. P-sections and their
attributes are described in Chapter 4.
If the p-section has the attribute CON (concatenated) , the section is
extended by the specified number of bytes.
If the p-section has the
attribute OCR (overlay) , the section is extended only if the length of
the extension is greater than the length of the p-section.
For example, suppose that p-section BUFF is 200 bytes
option below is given:

long

and

the

EXTSCT = BUFF:250
The extension specified for
attribute; specifically:

the

p-section

depends

for CON

the extension is 250 bytes.

for OVR

the extension is 50 bytes.

the

The extension occurs when the p-section name is encounted
input object file or in the overlay description file.

CON/OVR

= p-sect-name:extension

Syntax:

EXTSCT

where:

p-sect-name

is a 1- to 6-character radix-5G
name
specifying the p-section to be extended.

extension

is an octal integer that specifies the number
of bytes by which to extend the p-section.

default:

none

3.2.3.5 EXTTSK (Extend Task Memory) - The EXTTSK option declares the
amount of additional menory to be allocated to the task when installed in a system-controlled partition.
The amount of memory available to the task will be the sum of the
task size plus the increment specified in the EXTTSK keyword (rounded
up to the nearest 32-word boundary).
If the task is built for a usercontrolled partition, the allocation of task memory reverts to the
partition size. The maximum size of the task may not exceed 32K 32
words.
In an unmapped system the EXTTSK keyword is ignored.
syntax:

EXTTSK

where:

length

default:

EXTTSK

length
is a decimal number specifying the increase
in task memory allocation (in words).

3-17

CHAPTER 3.

SWITCHES AND OPTIONS

3.2.3.6 STACK (Stack Size) - The STACK option
size of the stack required by the task.

declares

the

maximum

The stack is an area of memory used for temporary storage, subroutine
calls, and interrupt service linkages. The stack is referenced by
hardware register R6 (the stack pointer).
syntax:

STACK = stack-size

where:

stack-size

default:

STACK = 256

is a decimal integer specifying the number of
words required for the stack.

3.2.3.7 Examples of Allocation Options - Suppose the FORTRAN routines
contained in file GRPl use eight files simultaneously and the maximum
record length in one of these files is 160 characters.

The terminal sequence used to build the task that would
programs to run is:

permit

these

)TKB
TKB)IMGl,MPl=GRPl
TKB)/
ENTER OPTIONS:
TKB)ACTFIL
8
TKB)MAXBUF = 160
TKB)//

3.2.4

Storage Sharing Options

Two options indicate the task's intention to access a shared
These options are of interest to all users of the system.

region.

By convention, the COMMON option indicates the use of a shared region
that contains only data and the LIBR option indicates the use of a
shared region that contains only code. The two options have the same
effect, however, and can be used interchangeably.

3.2.4.1 COMMON (Resident Common Block) - The COMMON option declares a
resident common block for use by the task.
syntax:

COMMON= cornmon-name:access-code[:apr]

where:

common-name

is the 1- to 6-character radix-SO name of the
common block.

access-code

is the code RW (read-write) or the code RO
(read-only) indicating the type of access the
task requires.

3-18

CHAPTER 3.

SWITCHES AND OPTIONS
apr

default:

is an integer in the range
0-7
which
specifies the first Addressing Page Register
to be reserved for the conunon block.

none

The apr is optional and accepted only for a mapped

syste~.

3.2.4.2 LIBR (Resident Library) - The LIBR option declares a resident
library for use by the task.
syntax:

LIBR = library-name:access-code[:apr]

where:

library-name

is the 1- to 6-character
specifying the library.

access-code

is the code RW (read-write) or the code RO
(read-only) indicating the type of access the
task requires.

apr

is an integer in the range O - 7 which
specifies the first Addressing Page Register
to be reserved for the library.

default:

radix-SO

name

none

The apr is optional and is accepted only for a mapped system.

3.2.4.3 Example of Storage Sharing Options - Suppose
the
task
composed of tne MACR0-11 progrc?" .s TSTl and TST2 accesses a shared
region DTST that contains data and a shared region STST that contains
code.
1

The terminal sequence used to build the task is:
)TKB
TKB)CHK,LP:=TST1,TST2
TKB)/
ENTER OPTIONS:
TKB)COMMON = DTST:RW
TKB)LIBR = STST:RO
TKB)//

3-19

CHAPTER 3.
3.2.S

SWITCHES AND OPTIONS

Device Specifying Options

The two options in this category are of interest to all users of the
system.
The UNITS option declares the number of input/output units
that the task uses. The ASG option declares the devices that are
assigned to these units.
The number of logical units and the highest unit number assigned must
be compatible.
An attempt to assign a physical device to a unit
number that is larger than the total number of units declared is an
error.
Similarly, the number of units declared cannot be less than
the highest unit assigned.
Since the options are processed as they are encountered, to increase
the number of units and assign devices to these units, the user should
enter the UNITS option first and then the ASG option.
Entering the
options in the reverse order can produce an error message.

3.2.5.l UNITS {Logical Unit Usage) - The UNITS option
number of logical units that are used by the task.
syntax:

UNITS = max-units

where:

max-units

default:

is a decimal integer in
specifying the maximum
units.

declares

the range
number of

the

0 - 250

logical

UNITS = 6

3.2.S.2 ASG {Device Assignment) - The ASG option
physical device that is assigned to one or more units.

declares

syntax:

ASG = device-name:unit-num-l:unit-num-2 ••• :unit-num-8

where:

device-name - is a 2-character alphabetic device name
followed by a 1- or 2-digit decimal unit
number.
unit-num-1
unit-num-2

the

are decimal integers indicating the
logical unit numbers.

unit=num-8
default:

ASG = SY0:1:2:3:4, TIO:S, CL0:6

3.2.S.3 Example of Device Specifying Options - Suppose the FORTRAN
programs specified in the file GRPl require nine logical units. The
device assignments for units 1-6 agree with the default assumptions
and logical units 7,8 and 9 are assigned to DECtape 1 {DTl). The
terminal sequence of the example of 3.2.3.6 is changed to include
device assignment options, as follows.

3-20

CHAPTER 3.

SWITCHES AND OPTIONS
)TKB
TKB)IMGl,MPl=GRPl
TKB)/
ENTER OPTIONS:
TKB)ACTFIL = 8 ! MAXBUF = 160
TKB)UNITS=9
ASG = DT1:7:8:9
TKB>//

3.2.6

Storage Altering Options

These options alter the task image and are of

interest only to the
MACR0-11 programmer.
The GBLDEF option declares a global symbol and
value. The options ABSPAT and GBLPAT introduce patches into the task
image.

3.2.6.1 GBLDEF
(Global Symbol
Definition) - The
declares the definition of a global symbol.

GBLDEF

option

The symbol definition is considered absolute.
syntax:

GBLDEF = symbol-name:symbol-value

where:

symbol-narne

is a 1- to 6-character radix-50
defined symbol.

symbol-value

is an octal number in the range
assigned to the defined symbol.

default:

name

the

0-177777

none

3.2.6.2 ABSPAT (Absolute Patch) ~ The ABSPAT option declares a series
of patches starting at the specified base address. Up to 8 patch
values can be given.
syntax:

ABSPAT = seg-name:address:val-l:val-2 •••• :val-8

where:

seg-name

is the 1- to 6-character radix-SO name of
segment.

address

is the octal address of the first patch.
The
address may be on a byte boundary; however,
two bytes are always modified for each patch.

val-1

is an octal number in the range 0-177777 to be
assigned to address.

val-2

is an octal nwnber in the range 0-177777 to be
assigned to address+2

val-8

is an octal number in the range 0-177777 to be
assigned to address+20.

3-21

the

CHAPTER 3.

SWITCHES AND OPTIONS
NOTE
All patches must be within the segment
memory
limits or a fatal error is
generated.

3.2.6.3 GBLPAT (Global Relative Patch) - The GBLPAT option declares a
series of patch values starting at an offset relative to a global
symbol. Up to 8 patch values can be given.
syntax:

GBLPAT=seg-name:sym-name[+/-offset]:val-l:val-2 ••• :val-8

where:

seg-name
sym-name

is as defined for ABSPAT
is
a
1- to
6-character
specifying the global syMbol.

radix-SO

name

off set

is an octal number specifying the offset
the global symbol.

from

val-1
val-2

}

are as defined for ABSPAT

val-8
default:

none
NOTE
All patches must be within the segment
address limits or a fatal error is
generated.

3.2.6.4 Example of Storage Altering Options - Suppose that in theexample composed of the MACR0-11 programs TSTl and TST2, GAMMA is a
referenced symbol whose value is to be specified when the task is
built.
The user defines the symbol GAMMA to have the value 25. He
introduces 10 patch values relative to the global symbol DELTA.
The terminal sequence of Example 3.2.4.3 is modified
options GBLPAT and GBLDEF as follows:

)TKB
TKB)CHK,LP:=TST1,TST2
TKB/
ENTER OPTIONS:
TKB)COMMON=DTST:RW:S, STST:RO
TKB)GBLDEF = GAMMA:25
TKB)GBLPAT = TSTl:DELTA:l:5:10:15:20:25:30:35
TKB)GBLPAT = TSTl:DELTA+20:40:45
TKB>//

include

the

CHAPTER 3.

3.2.7

SWITCHES AND OPTIONS

Synchronous Trap Options

There are two options which declare that the specified vector address
is to be preloaded into the task header thus enabling the task to
receive control on the occurrence of synchronous traps. These options
are of interest only to the MACR0-11 prograrruner.

3.2.7.1 ODTV (ODT SST Vector) - The ODTV option declares a global
symbol to be the address of the ODT Synchronous System Trap vector.
The defined global symbol must exist in the part of the task t.~at is
always in memory.
syntax:

ODTV = symbol-name:vector-length

where:

symbol-name

is a 1- to 6-character
global symbol.

radix-50

name

vector-length is a decimal integer in the range 1
32
specifying the length of the SST vector in
words;
default:

none

3.2.7.2 TSKV (Task SST Vector) - The TSKV option declares a global
symbol to be the address of the task SST vector. The defined symbol
must exist in the part of the task that is always in memory.
syntax:

TSKV = symbol-name:vector-length

where:

symbol-name
vector-length

default:

3.3

~ are as defined for ODTV

none

EXAMPLE:

CALC;2

Suppose that in the first execution of the task CALC several logical
errors are found.
The user corrects the program and is now ready to
make the changes in the program and some adjustments in the task image
file based on the information he obtained about the size of the task
in the first task build.
In this example, he modifies the text file for the program, recompiles
the program, and rebuilds the task so that only one active file buffer
is reserved and the task is built for a larger partition.

3-23

CHAPTER 3.
3.3.1

SWITCHES AND OPTIONS

Correcting the Errors in Program Logic

The FORTRAN source language for the program 'RDIN' is corrected to be:
C
C

READ AND ANALYZE INPUT DATA

SELECT A PROCESSING ROUTINE
ESTABLISH COMMON DATA BASE

c
C

COMMON /DTA/ A(200), I
READ IN RAW DATA

FORMAT (200 F6.2)

READ (6 ,1) A

CALL PROCl
CALL RDl
CALL RPRT
END
SUBROUTINE RDl
RB TURN
END

:-Jext, the program 'RDIN' is recompiled:
2FOR RDIN,LRDIN=RDIN
Observe that the corrections to 'RDIN' included the addition of a
subroutine 'RDl'. The object file produced by the FORTRAN compiler as
a result of the above terminal sequence now contains two object
modules.
3.3.2

Building the Task

Suppose that the user knows from the logic of the program that only
one file is open at a time. The Task Builder assumes that four files
are open simultaneously, so some space can be saved in the task by use
of the ACTFIL option. In addition, the task is moved from the default
partition 'GEN' which on the host system is 8192 words to a larger
partition 1 PAR14K'.
Since 'PAR14K' is resident in the host system,
the base and length are known to the Task Builder.

3-24

CHAPTER 3.

SWITCHES AND OPTIONS

He builds the task with the following terminal sequence:
)TKB
TKB)CALC;2,=RDIN,RPRT,PROC1
TKB)/
ENTER OPTIONS:
TKB)PAR=PAR14K
TKB)ABORT=l
~ -- *FATAL* - ABORTED VIA REQUEST
ABORT=l
TKB)CALC;2,LP:/SH=RDIN,PROC1,RPRT
TKB)/
ENTER OPTIONS:
TKB)PAR=PAR14K
TKB)ACTFIL=l
TKB>//
The user introduced the ABORT option ~o end the task build
realized that he had omitted the memory allocation file.

when

The effect of these options on the memory allocation is seen in the
next chapter. After the description of the task and memory allocation
files, the memory allocation files for the first two ex~~ples are
given.

3-25

CHAPTER 4
MEMORY ALLOCATION

This chapter describes the allocation of task and system memory.
The
two types of systems supported by RSX-llM, mapped and unmapped, are
described and the memory access rights of tasks within those systems
are defined.
The memory allocation file is described in detail and
examples of memory allocation files in mapped and unmapped systems are
illustrated.
The memory allocation file for t.~e exa..~ple CALC;l of
Chapter 2 and CALC;2 of Chapter 3 are included and discussed.
The
effect of the options used in CALC;2 can be observed by comparing the
two memory allocation files.

4.1

TASK MEMORY

Task memory in RSX-llM consists of a header, stack, and a set of named
areas
called program section
(p-sections).
Each p-section has
associated with it attributes from which the Task Builder can
determine its base and length.
Task Memory can be represented by the following diagram:
-- end of partition
unused portion
p-section
p-section

...
p-section
stack
header
-- partition base
Task Memory

4-1

CHAPTER 4.

MEMORY ALLOCATION

The header contains task parameters and data required by the Executive
and provides a storage area for recording the tasks context. The
contents of the header are described in detail in Appendix c.
The stack is an area that can be used for temporary storage and
subroutine linkages and is referenced by general register R6, the
stack pointer. The size of the stack can be changed by the use of the
STACK option, as described in Chapter 3.

4.1.1

P-Sections

A program section, or p-section, is the basic unit of memory for the
task.
A source language program is translated into an object module
consisting of p-sections. For example, the object module produced by
compiling a typical FORTRAN program consists of a p-section containing
the code generated by the compiler, a p-section for each conunon block
defined in the FORTRAN program, and a set of p-sections required by
the FORTRAN Object Time System.
A name and a set of attributes are associated with
The p-section attributes are given in Table 4-1.

4-2

each

p-section.

CHAPTER 4.

MEMORY ALLOCATION
Table 4-1
P-Section Attributes

MEANING

ATTRIBUTE

VALUE

access-code

(read/write}. Data can be
written into the p-section.

from

and

(read only). Data can be read from,
cannot be written into the p-section.

but

type-code

scope-code

I D**

The p-section contains data.

I**

(instruction).
The
p-section
contains
instructions or data and instructions.

GBL

(global). The p-section name is considered
across segment boundaries. The Task Builder
allocates storage for the p-section from
references outside the defining segment.

I LCL

alloc-code

(data).

read

(local). The p-section name is considered
only within the defining segment. The Task
Builder allocates storage for the p-section
from references within the defining segment
only.

CON

(concatenate). P-sections with the same name
are concatenated.
The total allocation is
the sum of the individual allocations.

OVR

(overlay). P-sections with the same name
overlay each other. The total allocation is
the length
of
the
longest
individual

allocation.
reloc-code

memory-code

p-section is
virtual base

REL

(relocatable). Storage in the
allocated
relative
to the
address of the partition.

ABS

(absolute).
Storage in the p-section
always allocated relative to zero.

HIGH

(high). The p-section is
high speed memory.

LOW

(low) •
core.

The

4-3

to be loaded into

p-section is to be

** Not to be confused with the I and D
11/45 and 11/70.

space

hardware

loaded into

the

PDP

CHAPTER 4.

MEMORY ALLOCATION

The scope-code and type-code are only meaningful when an overlay
structure is defined for the task. The scope-code is described in
connection with the resolution of p-section in Chapter 5.
The
type-code is described in connection with the generation of autoload
vectors in Chapter 6.
The memory-code is not used by the Task
Builder.
The access-code and alloc-code are used by the Task Builder to
determine the placement and the size of the p-section in task memory.
The Task Builder divides storage into read/write and read-only memory
and places the p-sections in the appropriate area according to
access-code. However, memory allocated to read-only p-sections is not
hardware protected.
The alloc-code is used to determine the starting address and length of
p-sections with the same name.
If the alloc-code indicates that
p-sections with the same name are to be overlaid, the Task Builder
places each reference at the same position in task memory and
determines the total allocation from the length of the longest
reference.
If the alloc-code indicates that p-sections with the same
name are to he concatenated, the Task Builder places each reference
one after another in task memory and determines the total allocation
from the sur11 of the lengths of each reference.
The initial reference to any p-section is always aligned on a word
boundary. When a p-section has the
concatenate attribute,
all
references to that p-section are placed adjacent to one another in task
memory.
If any of these references ends on a byte boundary, the next
reference to that p-section is not word-aligned.
4.1.2

Allocation of P-sections

Suppose the user enters the following conunantl:
)TKB IMGl,MPl=INl,IN2,IN3,LBRl/LB
The user is directing the Task Builder to build a task image file,
IHGl.TSK, and a memory allocation file, MPl.MAP, from the input files
INl.OBJ, IN2.0BJ, and IN3.0BJ, and to search the library file LBRl.OLB
for any undefined global references.
Suppose the input files are
composed of p-sections with the following access-codes, alloc-codes,
and sizes:

Access
Code

Alloc
Code

Size
(octal)

RW
RW
RO

CON
OVR
CON

100
300
150

IN2

A
B

RW
RW

OVR
CON

250
120

IN3

CON

File-name
INl

P-section
name
B
A

4-4

CHAPTER 4.

MEMORY ALLOCATION

First, the Task Builder collects all p-sections with the same name
determine the allocation for each uniquely named p-section.

In this example, there are two occurrences of the p-section named B
with attributes RW and CON. The total allocation for B is the sum of
the lengths of each reference;
that is, 100 + 120
220.
The
allocation for each uniquely named p-section then is:

P-section
Name

Total

... , , ---•.: --

L-1..L.LV~Ql...LUU

220

B
A

30¢

220

The Task Builder then re-organizes the p-sections alphabetically
places them in memory according to their access-code, as follows:

c (220)

B (220)

read only

read/write

A (300)

stack

and

task memory

header

4.1.2.1 Sequential Allocation of P-sections - The SQ (sequential)
switch affects only the place~ent of p-sections in task memory.
P-sections with the same name and attributes are collected as
described; then uniquely named p-sections are placed in memory in the
order of input sequence according to the access-code.
Suppose the user adds the SQ switch to the previous example:
)TKB IMGl/SQ,MPl=INl,IN2,IN3,LBRl/LB
The Task Builder collects the p-sections and places them in memory
the input sequence, as follows:

4-5

CHAPTER 4.

MEMORY ALLOCATION

c (22¢)

read only

A (3(2)¢)

read/write

B (22¢)

task memory

stack
header

4.1.3

The Resolution of Global Symbols

When creating the task image file, the Task Builder resolves global
references.
Suppose the global symbols are defined and referenced in
the p-sections in the following way:

File
Name

P-section
Name

Global
Defn.

Global
Name

INl

Bl
B2

Al
Ll
Cl

xxx

c
IN2

A
B

IN3

Al
Bl

B2
Bl

In processing the first file, INl, the Task Builder finds definitions
for Bl and B2 and references to Al,Ll,Cl, and xxx.
Since no
definition exists for these references, the Task Builder defers the
resolution of these global symbols. In processing the next file, IN2,
the Task Builder finds a definition for Al, which resolves the
previous reference, and a reference to B2, which can be immediately
resolved.

4-6

CHAPTER 4.

MEMORY ALLOCATION

When all the input object files have been processed, the Task Builder
has three unresolved global references, namely: Cl, Ll, and xxx. A
search of the library file LBRl resolves Ll and the Task Builder
includes the defining module in the task image. A search of the
System Library resolves xxx. The global symbol Cl remains unresolved
and is, therefore, listed as an undefined global symbol.
The relocatable global symbol Bl is defined twice and is listed as a
multiply-defined global symbol on the terminal. The first definition
of a multiply defined symbol is used by the Task Builder. An absolute
global symbol can be defined more than once without being listed as
multiply defined as long as each occurrence of the syrribol has the same
value.

4.2

SYSTEM MEMORY

In RSX-llM, system memory consists of the resident Executive and a set
of named areas. These named areas are partitions, sub-partitions, and
common blocks; associated with each of them are parameters of base
and length.
System memory can be represented by the following diagram:
partition or
common block

...

partition

sub-partition

...
sub-partition
unused portion
p-section
task
memory

p-section
partition

...

system
memory

p-section
stack
header
partition or
common block
resident
executive

4-7

CHAPTER 4.

4.2.1

MEMORY ALLOCATION

Mapped and Unmapped Systems

RSX-llM supports two types of systems, mapped and unmapped. A system
with memory management hardware is called a mapped system. Mapped
systems differ from unmapped systems in three respects:
1.

Binding

In
an
unmapped
system, the
task
is
relocated to the base
specified by the
partition at the time the task is built, and
therefore, the task can not be installed in a
partition with a different base address.

In a mapped system, the task is bound to
virtual zero and relocated by the mapping
hardware, and therefore, the task can be
installed in any partition large enough to
contain it.
2.

Protection

In an unmapped system, the
all physical memory.

task

can

access

In a mapped system, the task can only access
memory specifically owned by the task.
3.

Size

In an unmapped system, the largest task
is 28K minus the size of the Executive.

size

In a mapped system, the largest task size

32K - 32.
The structure of task memory is identical in both systems. No object
code alterations are required to run a task in either a mapped or
unmapped system.

4.2.2

Privileged Tasks

A privileged task has special memory access rights. A non-privileged
task can access only its own partition and any referenced shared
regions, but a privileged task can, in addition, access the Executive
and the I/O page.
In an unmapped system, a task cannot be prevented from accessing the
entire memory, but the users of the system are expected to observe the
access rules and preserve the distinction between privileged and
non-privileged tasks.
In a mapped system, however, the task can only access the memory
specifically owned by the task, so the distinction between privileged
tasks and non-privileged tasks is a real one.
The memory allocation for a privileged task in a mapped system can
represented by the following diagram:

4-8

CHAPTER 4.

MEMORY ALLOCATION

I/O page
virtual

16~~~~

end of partition
unused portion
available to
task
task code and
data

stack
header

partition base
(virtual 100000)

executive
R/W mapping
low core
context

-- virtual ~

The Executive and system tables occupy virtual locations within
address limits 0 - 77777.
The task can occupy virtual locations
100000 - 160000. A privileged task can not reside in a partition
whose length exceeds 12K (checked by the Task Builder and by Install) .

4.3

TASK IMAGE FILE

In addition to the task memory, or core image, the task image file
contains a label block group and possibly a checkpoint area. The
label block group contains data that is used by the Install processor
to create an entry in the system task directory for the task. The
label is described in detail in Appendix c.
The checkpoint area is allocated if the user specifies that
is checkpointable in building the task:

his

task

that

the

2TKB IMGl/CP,MPl=INl,IN2,IN3
The switch CP is appended to the task image file indicating
task is checkpointable.

4-9

CHAPTER 4.
4.3.1

MEMORY ALLOCATION

Checkpoint Area

If the task is checkpointable, the Task Builder must reserve space in
the task image file large enough to save all of the memory owned by the
task.
If this area is too small, the task must be installed with the
checkpointable attribute disabled.
When the task is to reside in a system-controlled partition, the size
of this area is the task size plus any increment specified through the
EXTTSK keyword (see paragraph 3.2.3.5).
If the task is to reside in a
user-controlled partition, the size of this area is equal to the partition si.ze.
When building a task for an unmapped system, the Task Builder always
allocates the checkpoint area based on partition size (all partitions
must be user-controlled) .
When building a task for a mapped system, the Task Builder assumes that
the partition is system-controlled if:
1.

A length of zero is specified in the PAR keyword (see
paragraph 3.2.2.4),

A resident, system-controlled partition is specified in the
PAR keyword,

The resident, default partition, GEN, is system-controlled,

The EXTTSK keyword is used after any partition specifications
(see paragraph 3.2.3.5}.

The following examples illustrate option input for the above conditions.
Example 1:

Explicitly specifying a system-controlled partition.

TKB>PAR=SYSCNT: :
The two colon delimiters define a base and length of 0.
Example 2:

Specifying a resident partition.

TKB>PAR=GEN
In this case the assumption made by the Task Builder depends upon
whether or not the resident partition, GEN, is system-controlled.
Example 3:

Default partition is to be used.

ENTER OPTIONS
TKB>/
The default partition, GEN, is assumed.
The allocation of checkpoint space in the task file depends upon whether this partition
is user-controlled.

4-10

CHAPTER 4.

MEMORY ALLOCATION

Example 4:

Use of the EXTTSK keyword.

TKB EXTTSK=4000
TKB>/
The EXTTSK keyword is used to increase the amount of memory by
4000 words. The partition in which the task will reside is
assumed to be system-controlled.

4.4

MEMORY ALLOCATION FILE

The memory allocation file lists information about the allocation of
task memory and the resolution of global symbols. Optionally, a global
cross reference list may be appended to the file by means of the /CR
switch.

4.4.l

Memory Allocation File Format

In the discussion of task memory allocation, the following example was
used:
>TKB IMGl,MPl=INl,IN2,IN3
The requested memory allocation file, MPl, is shown in Figure 4-1 for
a mapped system and in Figure 4-2 for an unmapped system. In the
mapped system, the task is bound to virtual address zero and can be
relocated by the mapping hardware into various partitions. In the

unmapped system, the task is bound to physical address 50100; the base
address of the default partition 'GEN'.
The memory allocation file header contains inf o.uuation that identifies
Task Builder, the task, and the task-build time.
The segment description gives memory limits, identification, and
attributes.
The task IMGl.TSK has a read/write memory allocation of
1744 bytes (that is, the header, the stack, and p-sections A and B)
and a read-only memory allocation of 220 bytes (p-section C).
The PROGRAM SECTION ALLOCATION SYNOPSIS shows the placement
of all p-sections.

and

size

The file contents section lists the input files, the p-sections that
make up the file, and the global symbols that are defined in the
p-sections.
Undefined global symbols are listed following
the
absolute p-section and summarized at the end of the listing.

4-11

CHAPTER 4.

MEMORY ALLOCATION

FILE IMG1,TSKJ1 MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON ZS•SEP•74
AT 14115 BY TASK BUILDER VERSION M08

*** ROOT SEGMENTI INl
R/W MEM LIMITSI 000000 001743 001744
R•O MEM ~IMITSI 001744 002163 000220
STACK
LIMITSI 00020Q 001203 00100e
DISK BLK LIMITSI 000002 000004 000003
IO~NTIFICATION I 00
TASK ATTRIBUTES1 NC

PROGRAM

SECTION ALLOCATION SYNOPSIS1

<. BLK~>I 001204 001204 000000

~01503 000300
001723 000220
>1 0017q4 002163 000220
<SS!
>1 0~1724 001743 008020
<. ABS~>I 000000 ~00000 000000

<A
<B
<C

>1 001204

~01504

*** FILEI IN1,0BJ,1

TITL~I

,M•I~.

IOENTI

<. ABS~>I 000000 000000 000000

>>>>>>>>>>>> UNDEFINED REFERENCES Cl

001506•R

>1 001204 001503 000300

001744 002113 000150

Fiqure 4-1
Memory Allocation File for IMGl.TSK on a Mapped System

4-12

CHAPTER 4.

MEMORY ALLOCATION

*** FI LE I INZ,OBJs1
<A

TITL.EI ,MAIN,

IOENTI

>1 001204 001qs3 000250

At
<B

001210•R

>I :Jl31b0U 01211723 000120

00150b•R

*** FIL.El IN3,0BJJ3
<C

>1 ~02114

TITL.EI ,MAIN,

lDENTI

002163 01210050

*** FILES L.BIU e 01..B J 1

I DENT I H

TITLE I L.1

<~ BLl<.>r 0e1204 t'Hli.204 0000H

~01204•R

*** FILEI SYSLIB.OLBJ1
dU

TlTL.EI

xxx

iOENTI H

>1 00112u 001743 000020

xxx

00172Ll•R

************
UNDEFINED REFERENCESI
Ct

Figure 4-1 (Cont.)
Memory Allocation File for IMGl.TSK on a Mapped System

4-13

CHAPTER 4.

MEMORY ALLOCATION

FILE IMG2,TSKJ1 MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25•SEP•74
AT 14115 BY TASK BUILDE~ VERSION M08

'It** ROOT SEGMENTS IN1
LIMITS I 1350100 052043 001 7 lt4
l.lMITSr 052044 052263 00022"1
LI~ITSI ~50304 051303 0010'11~
STACI<
DISK BLI< L.IMITSI 000002 00012104 0000"3
IDENTIFICATION I ~0

R/W MEM
R•O MEM

TASK ATTRIBUTESr NC

PROGRAM SECTION ALLOC•TION SYNOPSIS I
<. BL1<.>1 051304 es1304 000000
>1 051304 051*>03 000300
<A
<B
>1 051600 e52023 "'00220
<C
>1 052044 es22t>3 000220
>1 id52024 1352043 000020
<US
<. ABS .• >I 0~0000 1300000 000000

*** FILES IN1,0BJJ1

TITLEt ,MAIN,

IOENTI

<. ABS~>& 000000 0~0000 100000

>>>>>>>>>>>> UNDEFINED REFERENCES Cl
<B

~51604

~51703

000100

~5130q

~51603

000300

>r 052044 052213 000150

Figure 4-2
Memory Allocation File for IMGl.TSK on an Unmapped System

4-14

CHAPTER 4.

MEMORY ALLOCATION

*** FILEI IN2,0BJ•1
<A

IOENTI

051304 es1ss3 0002s0

~51704

e52023 000120

*** FILEI IN3,0BJr3
<C

.~~IN,

05131~-R

TITLES

052214

TITLEI

~52263

*** FILEI LBR1.0LBJ1

,M~IN,

IDENTI

000050

I DENT I 00

T ITLEI L1

<. BLK>1 851304 Cl51304 000000

051304•R

*** FILEI SYSLIB,OLBJ1
dU

xxx

TITLES

xxx

I DENT I 00

0522'24 052043 000020

052024 .. R

************
UNOEFINEO REFERENCES1
C1

Figure 4-2 (Cont.)
Memory Allocation File for IMGl.TSK on an Unmapped System

4-15

CHAPTER 4.

4.4.2

MEMORY ALLOCATION

Global Cross-Reference Format

In addition to the memory allocation information described, the user
may also request that a listing of all global symbols, accompanied
by the name of each referencing module, be appended to the memory
allocation file described above.
A listing of this type, termed a
global cross-reference, is frequently useful when debugging and
maintaining a task that consists of many modules.
Cross-reference processing is performed by a separate task that is
invoked by including the CR switch in the memory allocation file
specification as shown in the following example.
TKB>IMG1,MP1/CR=IN1,IN2,IN3
A portion of the cross-reference output is shown in Figure 4-3.
The page header contains the name of the memory allocation file, along
with the originating task (TKB), and the time and date the file was
created.
Cross-reference information consisting of the global symbol
name, value, relocatability (-R), and the name of each referencing
module is shown in the body of the listing.
For this unoverlayed task, the name of the module containing the
symbol definition is preceded by a #.
A complete summary of the
cross-reference format is included in section 4.4.3.
The reader
should consult Appendix H for detailed information on cross-reference
processi~g and data formats.

4.4.3

Structure of the Memory Allocation File

The structure of the memory
follows:
1.

allocat~on

file can be described as

The memory allocation file consists of the following sequence
of items:
heading
segment description
program section allocation synopsis
file contents description
undefined references summary
If the /CR switch was used to request a global cross-reference,
the following items are added to the memory allocation file:
cross-reference page header
cross-reference list entries
Each of the above named items is defined in 2 through 9.

The heading gives the time and date of the task-build in the
following form:

FILE task-image-file-name MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON date
AT time BY TASK BUILDER VERSION version-no.

4-16

CHAPTER

-:i:.

!'Ii.EMORY ALLOCATION

SYMBOL

VALUE

SOTSV

000052

Rr;fERENCES •••
SCLOSE
SISNLS

$St;uC
$SST

01620b•R
011662-R
027034•R
027136•R
011714-R
027274-R
001516•R
016206•R
016734•R

$SSTO

004.HO•R

$SST1
$SST2
$SST3

004316-R
004330-R
004336-R
004344•R
004352-R
00443o•R
004362-R
006002-R
030436•R

$0TSVA

SPUTRE
$RLCB
$RQCB
$R50

SSAVRG
$SrlR

$SST4

SSST5
$SST6
$SST7
$SVTKS
.ASLUN
.CLOSE
.FATAL
.Fl.NIT

.FSRCB
.FSHPT

024702-R

031430-R
025140-R
024264-R
000050

.GTD.lO

025244-~

• MBFCT
.MOL UN
.NLUNS

024364•R
016214-R
016212-R

.OPFNb

025262•R

.PPASC

032004-R

.PPR50

032132-R

.PUTSQ
.SAVR1

027320-R

• .ALC 1
• .ALOC
•• ALUN
• .1:WRC
•• BKR<;
•• CREA
•. Dt,;L 1

•• u I 0
• .lHDF

• .EFCK
•. EFC 1
•• ~NTR
• • E.:XTD
•• ~XTl

... FCSX

•• FIND
•• FINI
•• GTl>I

# $0TV

Sli'W
# RQLCB
OPFNB
St::RRPT
RQLCB
# SF ADD
# $0TV
# SOTV
# SERRPT
# SERRPT
# $Ei:RRPT
# $ERRPT
# SERRPT
# SERRPT
# SERRPT
# SERR PT
# SERRPT
# ASSLUN
# CLOSE
# COMMON

031352-R

025150•R
031440•R

SFIO
SSTPPA

SlNITl
SVTRAN

fCSFSR

l"!NIT

OPFNB

WAIT!

XQlOl

FIN IT

SAVR1

$ERRPT

.MAIN.
SPUTRE
RSUDB
# RQLCB
# $R50
# SAVRG

SOTV
SOTV
$0TV
SOTV
SOTV
SOTV
SOTV
SCLOSt.;
WAI Tl
SOT!
$0TV
CHEA TE
RSTFDB
$OPEN

••# GETOIO
FCSFSR
SOTV
SOTV
# OPFNB
PARDI
DIDFND
# l'UTSU

SERR PT
SRETS

ASSLUN
PARDI
I
#

#
#

ASSLUN

,..,

034012-R
033742•R
030442•R
030632•R
030714•R
030734-R
031122•R
032216-R
032076•R
031162-R
031170•R
0.31336•R
OH042•R
034116-R
031424-R

SOT!

# flNIT
# FC&f SR

(l ~(l.tl(l').Q
V..,Y~-·

SEOL

OPFNB
# CKALOC
# CKALOC
# ASSLUN
# SOB REC
# BKRG
# CREATE
# DEL
L>lDFNO
DIDFND
# EOFCHK
# t;OFCHK

•

Dt:L
#
#

SOP EN
PPNASC
PPNH50
$PUTRE
CKALOC
PUT SQ

WTWAIT
GETDl
OPFNB

RDWAl 1'

w·n~AI T

ROwAlT

WTWAlT

GET DID
SOP EN

OPFNB

OPf NB
OPfo.NH
# Off NU
PA RD ID

PUT SQ
# DIRECT

OPFNB

COMMON
wATSET

CREATE
WTwAlT
OPFNB

CJ\ALOC
CKALUC
CLOSE

WAI Tl
DlFND

# DIRECT

# f'INIT

# GETOi

OPFNB
GET DID

Figure 4-3
· Cross Reference Listing for MPl.MAP

4-17

Ol'fNB

PUT SQ

CHAPTER 4.

MEMORY ALLOCATION

The segment description consists of the following sequence of
items:
***SEGMENT segment-name
R/W MEM
LIMITS:
R/O MEM
LIMITS:
STACK
LIMITS:
DISK BLK LIMITS:
IDENTIFICATION:
ODT XFR ADDRESS:
PRG XFR ADDRESS:
TASK ATTRIBUTES:

start-addr
start-addr
start-addr
start-blk
name
address
address
attr-1 •••

end-addr
end-addr
end-addr
end-blk

length
length
length
blk-length

attr-n

Any line in the sequence is omitted if it does not apply to a
given task image.
The constructs in this sequence are defined in paragraph 7.
4.

The program section allocation synopsis has the form:
p-sect-name-1

start-addr

end-addr

length

If the SQ switch is applied, the p-sect-narnes are listed in
input
order;
otherwise
p-sect-narnes
are
listed in
alphabetical order. Since p-sections are allocated according
to
their access-code, the alphabetical listing is not
necessarily sequential.

The file contents description
input file in the form:
***FILE filename

ABS.)

>»»

<p-sect-name-1>
• BLK.

contains

TITLE title-name

entry

for

each

IDENT ident-narne

start-addr end-addr length
g-name-1 value g-name-2 value •••
UNDEFINED REFERENCE g-name-n
start-addr end-addr length •••
g-name-1 value-R g-name-2 value-R •••
start-addr end-addr length
g-narne-1 value g-name-2 value

The absolute global symbols are listed in the p-section named
• ABS, which is collated first. The blank p-section • BLK.
is collated last in the listing.
6.

The undefined references summary has the form:
************************
REFERENCES
UNDEFINED
g-narne-1

4-18

CHAPTER 4.

MEMORY ALLOCATION
The Cross-Reference Page header gives the name of the memory
allocation file, the originating task (TKB), the date and time
the memory allocation file was created and the cross reference
page number, in the following format:
GLOBAL

CROSS

FILE:

map-file-name

SYMBOL
8.

REFERENCE

VALUE

CREATED BY TKB ON date AT time
REFERENCES •••

The cross-reference list contains an alphabetic listing of
each global symbol along with its value and the name of each
referencing module. When a symbol is defined in several
segments within an overlay structure, the last defined value
is printed. Similarly, if a module is loaded in several
segments within the structure, the module name will be displayed more than once within each entry.
Entries have the form:
g-name-1

value

(-R)

title-name-1 .....
title-name-n

g-name-2

value

(-R)

title-name-1 .....
title-name-n

The suffix '-R' is appended to the value if the symbol is
relocatable.
Prefix symbols accompanying each module name define the type
of reference as follows:
Prefix Symbol

Reference Type

blank

Module contains a reference that is resolved
in the same segment or in a segment towards
the root.

Module contains a reference that is resolved
directly in a segment away from the root or
in a co-tree.

Module contains a reference that is resolved
through an autoload vector.
Module contains a non-autoloadable
definition.

Module contains an autoloadable definition.
NOTE

The reader should consult the glossary and
Chapter 5 for a discussion of unfamiliar
terms.

4-19

CHAPTER 4.

MEMORY ALLOCATION

The remaining constructs are defined as follows:
segment-name

is the name of the segment.

start-addr

is the first storage
byte format.

address

octal

end-addr

is the last storage
byte format.

address

octal

length

is the number
occupied.

start-blk

is the relative block number (in
for the starting disk location.

end-blk

is the last relative
the disk allocation.

block

number

blk-length

is the number
occupied.

octal)

address

is a byte address (in octal).

name

is the name attached to the
first
non-blank .IDENT entry encountered.

attr

is an attribute code that applies to the
task image.
The list of codes printed
is:

(in octal)

(in

of bytes
octal)
for

blocks

Task is not checkpointable

Task uses the floating point
processor

Task includes the
standard
debugging aid SYO:[l,l]ODT.OBJ

Task contains only position
independent code and data

Post mortem dump will be produced
in the event of an abnormal task
termination

Task is privileged

Task initial PS word has T-bit
enabled

Task uses
KE-llA
arithmetic element

extended

Task is an
processor

control

Task does not contain a header

4-20

ancillary

CHAPTER 4 •

4.5

MEMORY ALLOCATION
p-sect-na.."ne

is the na.~e of a p-section.

file-name

is the name of an input object file.

title-name

is the name of the first non-blank .TITLE
encountered.

ident-name

is the name of the first non-blank .IDENT
encountered.

g-name

is the name of a global symbol.

EXAMPLE:

CALC;l MAP

The first run of CALC, discussed in Chapter 2, produces the memory
allocation file shown in Figure 4-4. This memory allocation file
contains all the parts described in this chapter.
For inclusion in
the manual, the map was truncated after the second entry in the file
contents description. The truncated entries are described in general
terms in the section on the file contents.

4.5.1

Heading

The heading contains the date and time the example was run.

4.5.2

Segment Description

The task code and data for CALC;l occupies 37024 octal bytes of
read-write memory. After examining the map, the user decided to build
the next version of CALC for a partition larger than the default
partition GEN, which on the system he is using consists of 40000
bytes.
There is no entry for read-only memory because this task does not have
any read-only p-sections.
The stack occupies 1000 bytes because the
default stack size.

user

did

The identification $FORT is assigned by the FORTRAN
main programs.

not

change

compiler

the
all

The program transfer address is the virtual address 1210 (that is, the
starting address of the program.)
The task has the attribute NC (not checkpointable).

4-21

CHAPTER 4

4.5.3

MEMORY ALLOCATION

Program Section Allocation Synopsis

The blank program section '· BLK.' contains the object code produced
from the translation of the modules for CALC;l. The code begins at
virtual address 1210, ends at virtual address 26127, and occupies
24720 bytes.
The program section 'DTA ' is the memory allocation reserved
common block OTA.

for

the

The remaining program sections are storage regions required by the
FORTRAN object time system (OTS) and File Control Services (FCS),
which were called in by the FORTRAN compiler to perform services for
the FORTR&~ program.

4.5.4

File Contents Description

The file contents description lists for each file the program sections
that the file contributed to the segment. In CALC;l there are three
input files, RDIN.OBJ, PROCl.OBJ, and RPRT.OBJ. In addition to these
files, the library file SYSLIB.OLB is required to contribute the
FORTRAN run-time routines.
The input file RDIN.OBJ contains three p-sections; namely,
'.$$$$.',
'· BLK.', and 'DTA '
The p-section '.$$$$.'is the conunon block
reservation for unnamed or blank common. Since this task does not use
blank common, the storage reservation is zero. The p-section •. BLK.'
contains the code for RDIN.OBJ, starts at virtual address 1210, and
occupies 110 bytes.
'DTA ' is the p-section containing the conunon
block DTA. This section starts at virtual address 26130, and occupies
1442 bytes.
The input file, PROCl.OBJ, also contains three p-sections;
namely,
'.$$$$.', '· BLK.', and 1 DTA '. The p-section '. BLK.' contains the
code for PROCl and the definition for global symbol 'PROCl', the name
of the subroutine.
The map reproduced below does not contain the modules
the library file SYSLIB.OLB.

4-22

contributed

CHAPTER 4.

MEMORY ALLOCATION

FILE CALC.TSK;l MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25-JUL-74
AT 14:53 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT: RDIN
R/W MEM LIMITS:
STACK
LIMITS:
DISK BLK LIMITS:
IDENTIFICATION :
PRG XFR ADDRESS:
TASK ATTRIBUTES:

000000 037023 037024
000210 001207 001000
000002 000041 000040
$FORT
001210
NC

PROGRAM SECTION ALLOCATION SYNOPSIS:
<. BLK.>:
(OTA
):
($$AOTS):
<$$DEVT):
($$FSR1):
<$$FSR2>:
($$IOB1):
<$$IOB2):
<$$0BF1):
($$OBF2):
($$RESL):
<. ABS.):
<.$$$$.>:

001210 026127 024720
026130 027571 001442
027572 030347 000556
030350 031557 001210
031560 035657 004100
035660 035761 000102
035762 036165 000204
036166 036166 000000
036166 036275 000110
036276 036276 000000
036276 037023 000526
000000 000000 000000
037024 037024 000000

*** FILE: RDIN.OBJ:l

TITLE: .MAIN.

!DENT:

$FORT

(.$$$$.): 037024 037024 000000
(DTA
): 026130 027571 001442
<. BLK.): 001210 001317 000110

*** FILF: PROCl.OBJ:l TITLE: PROCl !DENT: $FCRTS
<. BLK.): 001320 001320 000000
PROCl

001320-R

<.$$$$.>: 037024 037024 000000
<DTA

): 026130 027571 001442

<. BLK.): 001320 003003 001464
Figure 4-4
Memory Allocation File for CALC;l
(Mapped System)

4-23

CHAPTER 4.

4.6

MEMORY ALLOCATION

EXAMPLE:

CALC;2 MAP

In the example CALC;2 in Chapter 3, the user added some code to
and entered two options during option input:
o

ACTFIL=l

to eliminate the three active
needed by CALC.

PAR=PAR14K

to direct the Task
partition for CALC
expand the task.

file

buffers

RDIN,
not

Builder to use a larger
since the user intends to

The memory allocation file shown in Figure 4-5 reflects these changes:
FILE CALC.TASK;2 MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25-JUL-74
AT 15:07 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT: RDIN
R/W MEM LIMITS:
STACK
LIMITS:
DISK BLK LIMITS:
IDENTIFICATION :
PRG XFR ADDRESS:
TASK ATTRIBUTES:

000000 033777 034000
000210 001207 001000
000002 000035 000034
$FORT
001210
NC

PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.):
<OTA
>:
($$AOTS):
($$DEVT):
($$FSRT):
($$FSR2>:
<$$IOB1>:
<$$IOB2):
($$0BFl>:
($$0BF2):
<$$RESL):
<. ABS.>:

001210 026163 024754
026164 027625 001442
027626 030403 000556
030404 031613 001210
031614 032633 001020
032634 032735 000102
032736 033141 000204
033142 033142 000000
033142 033251 000110
033252 033252 000000
033252 033777 000526
000000 000000 000000
<.$$$$.>: 034000 034000 000000
Figure 4-5
Memory Allocation File for CALC;2
(Mapped System)

4-24

CHAPTER 4.

MEMORY ALLOCATION

Because of the additional logic in the program RDIN, the task
allocation increased from 24720 in CALC;l to 24754 in CALC;2.

code

Because the ACTFIL keyword was used, the File Storage Region
pool, $$FSR1, decreased from 4100 in CALC;l to 1020 in CALC;2.

buffer

task code

CALC;l

CALC;2

24720

24754

A inn

$$FSR1

Difference

-"lne:::n

"'Z..&.VV

-.JVVV

-3024
The use of the ACTFIL keyword saved 3060 bytes.
The net saving of
3024 bytes, when added to the memory requirements for CALC;2, gives
the memory requirement for CALC;l
CALC;2

34000

D!FF

3024

CALC;l

37024

4-25

CHAPTER 5
OVERLAY CAPABILITY

This chapter describes the use of the overlay capability to reduce the
memory requirements of a task.
The concept of tree structured
overlays is introduced and a language for representing this structure
is defined.
Examples are given that illustrate the use of the
language and the allocation of memory for an overlayed task.

5.1

OVERLAY DESCRIPTION

To create an overlay structure, the
series of segments; specifically:

user

divides

his

task

•

a single root segment, which is always in memory, and

•

any number of overlay segments, which share memory
another.

into

with

one

A segment consists of a set of modules and p-sections that can be
loaded by a single disk access. Segments that overlay each other must
be logically independent. Two segments are said to be logically
independent if the components of one segment do not reference and are
not referenced by any of the components of the other segment.
When the user defines an overlay structure, he must consider the
general flow of control within his task in addition to the logical
independence of the overlay segments. Dividing a task into overlays
saves space, but introduces the overhead activity of loading these
segments into memory as they are needed.
The programmer must make
optimization decisions in constructing the overlay just as he does in
writing the programs.
There are several large classes of tasks that can be handled
effectively by an overlay structure. A task that moves sequentially
through a set of modules is well suited to the use of an overlay
structure.
A task which selects one of a set of modules according to
the value of an item of input data is also well suited to an overlay
structure.

5-1

CHAPTER 5.
S.1.1

OVERLAY CAPABILITY

Overlay Structure

Consider a task, TKl, which consists of four input files. Each input
file consists of a single module of the same name as the file. The
task is built by the command:
)TKB TKl=CNTRL,A,B,C
Suppose the user knows that the modules A,
independent. In this example:

and

c are

logically

A does not call B or c and does not use the data of B or c,
B does not call A or c and does not use the data of A or c,
c does not call A or B and does not use the data of A or B.
The user can define an overlay structure in which A, B, and c are
overlay segments that occupy the same storage. Suppose further that
the flow of contr.ol for the task is as follows :
CNTRL calls A and A returns to CNTRL,
CNTRL calls B and B returns to CNTRL,
CNTRL calls c and c returns to CNTRL,
CNTRL calls A and A returns to CNTRL.
The loading of overlays occurs only four times during the execution of
the task.
Therefore, the user can reduce the memory requirements of
the task without unduly increasing the overhead activity.
Consider the effect of introducing an overlay structure on the
allocation of memory for the task. Suppose the lengths of the modules
are as follows:
CNTRL
A
B

10000 bytes
6000 bytes
5000 bytes
1200 bytes

The memory allocation produced as a result of building the task as a
single segment on a system with memory mapping hardware is as follows:
- 24200

- 23000
B

- 15000
A

- 10000

CNTRL
- 0

The memory allocation for a single-segment task requires 24200 bytes.

5-2

CHAPTER 5.

OVERLAY CAPABILITY

The memory allocation produced as a result of using the
capability and building a multi-segment task is as follows:

overlay

- 16000

- 10000

CNTRL
-

The multi-segment task requires 16000 bytes.
In addition to the
module storage, additional storage is required for overhead connected
with handling the overlay structure. This overhead is described later
and illustrated in the example CALC.
Observe that the amount of storage required for the task is determined
by the length of the root segment and the length of the longest
overlay segment. Overlay segments A and B in this representation are
much longer than overlay segment c. If the user can divide A and B
into sets of logically independent modules, he can further reduce the
storage requirements of his task. Suppose he divides A into a control
program AO and two overlays Al and A2. A2 is then further divided
into the main part A2 and two overlays A21 and A22. Similarly, he
divides the B overlay into a control module BO and two overlays Bl and
B2.
The memory allocation for the task produced by the additional overlays
defined for A and B is given by the diagram:

Ff8A221 FlI
Al

1-I

Bl I B 2

Ii-----_C__._NT~__.__!-1 1

13600

10000
0

a single-segment task, TKl required 24200 bytes of storage.
The
first overlay structure reduced the requirement by 6200 bytes. The
second overlay structure further reduced the storage requirement by
2200 bytes.

Observe that a vertical line can be drawn through the memory diagram
to indicate a state of memory.
In the diagram given here, the
leftmost such line gives memory when CNTRL, AO, and Al are loaded:
the next such line gives memory when CNTRL, AO, A2, and A21 are
loaded: and so on.
Observe also that a horizontal line can be drawn through the memory
diagram to indicate segments that share the same storage. In the
given diagram, the uppermost such line gives Al, A21, A22, Bl, B2 and
c, all of which can use the same memory1 the next such line gives Al,
A2, Bl, B2, and C; and so on.

5-3

CHAPTER S.
S.1.2

OVERLAY CAPABILITY

Overlay Tree

The Task Builder provides a language for
structure consisting of one or more trees.

representing

A single overlay tree is described first and then
describing multiple overlay trees is given.

overlay

the

procedure

for

The memory allocation for the previous example can be

represented

the single overlay tree shown below:
A21
I

A22
I

B2
I

AO
CNTRL

The tree has a root, CNTRL, and three main branches, AO,
The tree has six leaves, Al, A21, A22, Bl, B2, and c.
The tree has as many paths as it has leaves.
from the leaf to the root, for example:

BO,

and

The path down is defined

A21-A2-A0-CNTRL
The path up is defined from the root to the leaf, for example:
CNTRL-BO-Bl.
Understanding the tree and its paths is important to the understanding
of the overlay loading mechanism and the resolution of global symbols.

s.1.2.1 Loading Mechanism - Modules can call other modules that exist
on the same path.
The module CNTRL is coI'CIJ'llon to every path of the
tree and, therefore, can call and be called by every module in the
tree.
The module A2 can call the modules A21, A22, AO, and CNTRL;
but A2 can not call Al, Bl, B2, BO or c.
When a module calls a module in another overlay segment, the overlay
segment must be in memory or must be brought into memory. The methods
for loading overlays are described in the next chapter.

5.1.2.2 Resolution of Global Symbols in a Multi-segment Task - The
Task Builder performs the same activities in resolving global symbols
for a multi-segment task as it does for a single segment task.
The
rules defined in Chapter 4 for the resolution of global symbols in a
single segment task still apply, but the scope of the global symbols
is altered by the overlay structure.

5-'1

CHAPTER Se

OVERLAY CAPABILITY

In a single segment task, any global definition can be referenced by
any module.
In a multi-segment task, a module can only reference a
global symbol that is defined on a path that passes through the
segment to which the module belongs.
In a single segment task, if two global symbols with the same name are
defined, the symbols are multiply defined and an error message is
produced.
In a multi-segment task two global symbols can be defined
with the same name as long as the definitions are on separate paths.
A reference is said to be ambiguous if there are multiple definitions
on common paths to which the reference could be resolved.
Consider the task TKl and the global symbols Q, R,
A21
T (def)

I
Al
Q(ref)
R (ref)
I

s, and T.

A22
R(ref)
Q (ref)
J

A2
R(def)

Bl
Q(ref)

I
1

AO
Q (def)

B0
Q (def)

s (def)

s (def)
T (def)
CNTRL
S (ref)

The following remarks apply to the use of each of the symbols shown in
the diagram:

The global symbol Q is defined in the segment AO and in the
segment BO.
The reference to Q in segment A22 and the
reference to Q in segment Al are resolved to the definition
in AO. The reference to Q in Bl is resolved to refer to the
definition of BO. The two definitions of Q are distinct in
all respects and occupy different memory allocations.

The global symbol ~ is defined in the segment A2.
The
reference to R in A22 is resolved to the definition in A2
because there is a path to the reference from the definition
(CNTRL-A0-A2-A22).
The reference to R in Al, however, is
undefined because there is no definition for R on a path
through Al.

5-5

CHAPTER 5.

OVERLAY CAPABILITY

The global symbol S is defined in AO and BO. References to s
from Al, A21 or A22 are resolved to the definition in AO and
references to s in Bl and B2 are resolved to the definition
in BO.
However, the reference to S in CNTRL cannot be
resolved because there are two definitions of S on separate
paths through CNTRL. S is ambiguously defined.

The global symbol T is defined in A21 and AO. Since there is
a single path through the two definitions (CNTRL-A0-A2-A21),
the global symbol T is multiply defined.

5.1.2.3 Resolution of P-sections in
a
Multi-segment
Task - A
p-section has an attribute that indicates whether the p-section is
local (LCL) to the segment in which it is defined or of global (GBL)
extent.
Local p-sections with the same name can appear in any number of
segments.
Storage is allocated for each local p-section in the
segment in which it is declared. Global p-sections of the same name,
however, must be resolved by the Task Builder.
When a global p-section is defined in several overlay segments along a
common path, the Task Builder allocates all storage for the p-section
in the overlay segment closest to the root.
FORTRAN common blocks are translated into global p-sections with the
overlay attribute.
Suppose that in the task TKl the common block
COMA is defined in modules A2 and A21. The Task Builder allocates the
storage for COMA in A2 because that segment is closer to the root than
the segment which contains A21.
However, if the programs AO and BO .lse a common block COMAB, the Task
Builder allocates the storage for COMAB in both the segment which
contains AO and the segment which contains BO.
AO and BO can not
communicate through COMAB. When the overlay segment containing BO is
loaded, any data stored in COMAB by AO is lost.
The tree for the task TKl
blocks COMA and COMAB is:

including

A21

allocation

A22

the

A2
CO.MA
I

AO
CO.MAB

CNTRL

5-'5

the

common

CHAPTER 5.

OVERLAY CAPABILITY

The allocation of p-sections can be specified by the user. If AO and
BO need to share the contents of COMAB, the user can force the
allocation of this p-section into the root segment by the use of the
.PSECT directive, described in Section 5.1.3.4.

Overlay Description Language (ODL)

5.1.3

The Task Builder provides a language that allows the user to describe
the
overlay structure.
The overlay description language (ODL)
contains five directives by which the user can describe the overlay
structure of his task.
An overlay description consists of a series of ODL directives.
There
must be one .ROOT directive and one .END directive. The .ROOT
directive tells the Task Builder where to start building the tree and
the .END directive tells the Task Builder where the input ends.

5.1.3.1 .ROOT and .END Directives - The arguments of the
ROOT
directive make use of two operators to express concatenation and
overlaying. A pair of parentheses delimits a group of segments that
start at the same location in memory. The maximum number of nested
parentheses cannot exceed 32.
•

The operator dash '-' indicates the concatenation of storage.
For example, 'X-Y' means that the memory allocation must
contain X and Y simultaneously. So X and Y are allocated in
sequencee

•

The operator conuna ','appearing within parentheses indicates
the overlaying of storage.
For ex&~ple, 'Y,Z' means that
memory can contain either Y or z.
Therefore Y and Z are
share storage.
This operator is also used to
structures, as described in 5.1.4.

5-7

define

multiple

tree

CHAPTER 5.

OVERLAY CAPABILITY

Consider the overlay description language directives:
.ROOT X-(Y,Z-(Zl,Z2))
.END
These directives describe the following
memory diagram:

tree

YT-3
x

and

its

corresponding

fr
z

To create the overlay description for the task TKl described earlier
in this chapter, the user creates a file TFIL that contains the
directives:

.ROOT CNTRL-(AO-(Al,A2-(A21,A22)) ,BO-(Bl,B2),C)
.END
To build the task with that overlay structure, the user types:
)TKB TKl=TFIL/MP
The switch MP tells the Task Builder that there is only one input
file, TFIL.ODL, and that file contains an overlay description for the
task.

5.1.3.2 .FCTR Directive - The tree that represents the
overlay
structure can be complicated.
The overlay description language
includes another directive, .FCTR, which allows the user to build
large trees and represent them systematically.
The .FCTR directive allows the user to extend the tree description
beyond a single line. Since there can be only one .ROOT directive,
the .FCTR directive must be used if the tree definition exceeds one
line.
The .FCTR directive, however, can also be used to introduce
clarity in the representation of the tree.

CHAPTER 5.

OVERLAY CAPABILITY

The maximum number of nested .FCTR levels is 32.
To simplify the tree given in the file TFIL the .FCTR directive
introduced into the overlay description language as follows:
AFCTR:
BFCTR:

.ROOT CNTRL-(AFCTR,BFCTR,C)
.FCTR A0-(Al,A2-(A21,A22))
• FCTR BO- (Bl ,B2)
.END

The label 'BFCTR', is used in the .ROOT directive to designate the
argument of the .FCTR directive, 'BO-(Bl,B2) '· The resulting overlay
description is easier to interpret than the original description. The
tree consists of a root, CNTRL, and three main branches. Two of the
main branches have sub-branches.
The .FCTR directive can be
follow:

nested.

TFIL

The decision to use the .FCTR directive is based on considerations
space and style.

AFCTR:
A2FCTR:
BFCTR:

The

user

can

modify

.ROOT CNTRL-(AFCTR,BFCTR,C)
.FCTR A0-(Al,A2FCTR)
.FCTR A2-(A21,A22)
.FCTR BO- (Bl,B2)
.END

5.1.3.3 .NAME Directive - The .NAME directive allows a segment name
to be defined and included at any appropriate point in the tree. The
defined name must be unique with respect to filenwues, p-section
names, .FCTR labels and other segment names that are used in the
overlay description.
The .NAME directive is used to uniquely identify a segment that is to
be loaded into memory by means of the Manual Load Method described in
Chapter 6.
Suppose that, in the definition of the tree for TKl, the user wants to
give a name to every main branch of the tree. He defines three names
and includes these new names in the overlay description for the tree.
TFIL is modified as follows:

AFCTR:
BFCTR:

.NAME BRNCHl
.NAME BRNCH2
.NAME BRNCH3
•ROOT CNTRL- (BRNCH1-AFCTR,BRNCH2-BFCTR,BRNCH3-C)
.FCTR AO-(Al,A2-(A21,A22))
• FCTR BO- (Bl ,B2)
.END

5-9

CHAPTER S.

OVERLAY CAPABILITY

5.1.3.4 .PSECT Directive - The .PSECT directive allows the placement
of a global p-section to be specified directly. The name of the
p-section and its attributes are given in the .PSRCT directive. Then,
the name can be used explicitly in the definition of the tree to
indicate the segment in which the p-section is to be allocated.
Suppose the user encountered a problem in corrununication resulting from
the overlay description for TKl.
The user was careful about the
logical independence of the modules in the overlay segment, but he
failed to take into account the logical independence requirement of
multiple executions of the same overlay segment.
The flow of the task TKl, as described earlier in this chapter, can be
summarized in the following way.
CNTRIJ calls each of the overlay
segments and the overlay segment returns to CNTRL in the following
order: A,B,C,A. The module A is executed twice. The overlay segment
containing A must be reloaded for the second execution of A.
The module A uses the common block DATA3. The Task Builder allocates
DATA3 in the overlay segment containing A. ·The first execution of A
stores some results in DATA3. The second execution of A requires
these values. In the present overlay description, however, the values
calculated by the first execution of A are overlaid. When the segment
containing A is read in for the second execution, the common block is
in its initial state.
The use of a .PSECT directive forces the allocation of DATA3 into the
root segMent to permit the two executions of A to conununicate. TFIL
is modified as follows:

AFCTR:
BFCTR:

.PSF.CT DATA3,RW,GBL,REL,OVR
.ROOT CNTRL-DATA3-(AFCTR,BFCTR,C)
.FCTR A0-(Al,A2-(A21,A22))
.FCTR BO-(Bl,B2)
.END

The attributes RW,GBL,REL and OVR are described in Chapter 4.

5.1.4

Multiple Tree Structures

The Task Builder allows the specification of more than one tree within
the overlay structure. A structure containing multiple trees has the
following properties:
1.

Storage is not shared among trees.
The total storage
required is the sum of the longest path ·on each tree.

Each path in a tree h
tree.

common to all

paths

every

other

These properties allow modules, that would otherwise have to reside in
the root segment, to be contained in an overlay tree.

5-1()

CHAPTER 5.

OVERLAY CAPABILITY

Such overlay trees within the structure consist of a main tree and one
or more co-trees. The root segment of the main tree is loaded by the
monitor when the task is made active while segments within each
co-tree are loaded through calls to the overlay runtime system.
Except for the above distinction, all overlay trees have identical
characteristics.
That is, each tree must have a root segment and
possibly one or more overlay segments.
The following paragraphs describe the procedure for
specifying
multiple trees in the overlay description language and illustrate the
use of co-trees to reduce the memory required by a task.

5.1.4.1 Defining a Multiple Tree Structure - Multiple tree structures
are specified within the overlay description language by extending the
function of the comma',' operator.
As previously discussed, this
operator, when included within parentheses, defines a pair of segments
that share storage. The inclusion of the comma operator outside all
parentheses delimits overlay trees.
The first overlay tree thus
defined is the main tree. Subsequent trees are co-trees.
Consider the following:
X:

.ROOT
.FCTR

X,Y

.FCTR
.END

YO-(Yl,Y2)

XO- (Xl ,X2 ,X3)

Two overlay trees are specified. A main tree containing the root
segment XO and three overlay segments and a co-tree consisting of root
segment YO and two overlay segments. The Executive loads segment XO
into memory when the task is activated. The task then loads the
remaining segments through calls to the overlay runtime system.
A co-tree must have a root segment to establish linkages to the
overlay segments within the co-tree. Logically, these root segments
need not contain code or data.
(Such modules can be resident in the
main root).
A
segment of this type termed a 'null segment', may be
created by means of the .NAME directive.
The previous example is
modified as shown below to include a null segment •

X:
Y:

• ROOT
.FCTR
.NAME
.FCTR

X,Y
XO-YO-(Xl,X2,X3)
YNUL
YNUL-(Yl,Y2)

.END

The null segment 'Y1'1UL' is created, using the .NAME directive, and
replaces the co-tree root that formerly contained YO.OBJ. YO now
resides in the main root.

5-11

CHAPTER S.

OVERLAY CAPABILITY

5.1.4.2 Multiple Tree Example - The following example illustrates the
use of multiple trees to reduce the size of the task.
Suppose that in the task TKl, the root segment CNTRL consists of a
small dispatching routine and two long modules, CNTRLX and CNTRLY.
CNTRLX and CNTRLY are logically independent of each other, are
approximately equal in length, and must access modules on all the
paths of the main tree.
The user can define a co-tree for CNTRLX and CNTRLY and effect a
saving in the storage required by the task. He modifies the overlay
description in TFIL as follows:

.NAME CNTRL2
.ROOT CNTRL-(AFCTR,BFCTR,C),CNTRL2-(CNTRLX,CNTRLY)

...

• END

The co-tree is defined at the 'zeroth' parenthesis level in the .ROOT
directive.
A co-tree rnust have a root segment, to establish linkages
to the overlay segments within the co-tree.
When no code or data
logically belong in the root, the .NAME directive can be used to
create a null root segment.
The tree for the task TKl now is:

AOI

CNTRLX
I

CNTRL

CNTRLY

CNTRL2

The corresponding memory diagram is:
6200

CNTRLX

CNTRLY

CNTRL2
,___i:.--...1
A211A22
r-----1
Bl B2
A2
Al
BO

2200

c
1000

CNTRL
0

5-12

CHAPTER 5.

OVERLAY CAPABIT,ITY

The specification of the co-tree decreases the storage allocation by
4000 bytes.
CNTRLX and CNTRLY can still access modules on all the
paths of the main tree.
The only requirement imposed by the
introduction of the co-tree is the logical independence of CNTRLX and
CNTRLY.
Any number of co-trees can be defined. Additional co-trees can access
all the modules in the main tree and in the other co-trees.

5.1.5

Overlay Core Image

The core image for a task with an overlay structure can be represented
by the following diagram:

co-tree
overlay
segment
co-tree
root segment

co-tree

overlay
segments
co-tree
root segment
main tree
overlay
segments
main tree
root
segment
stack
header

5-13

CHAPTER 5.

OVERLAY CAPABILITY

The header and stack are described in Chapter 4.
The root segment of the main tree contains all the modules that are
resident in memory throughout the entire execution of the task, along
with the segment tables, and if the autoload loading method is used,
the autoload vectors.
autoload
vectors
segment
tables

main tree
root segment

code and
data

The segment table contains a segment descriptor for every segment in
the task. The descriptor contains information about the load address,
the length of the segment, and the tree linkages. The segment table
is described in detail in Appendix c.
Autoload vectors appear in every segment that calls modules in another
segment that is further from the root of the tree. Autoload vectors
are described in connection with loading mechanisms in Chapter 6 and
the detailed composition of the autoload vector is given in Appendix

The main tree overlay region consists
overlay segments of the main tree.
area of memory as they are needed.

of memory allocated for the
The overlays are read into this

-1

autoload vectors

overlay
segment

code and data

..
.

autoload vectors

overlay
segment

code and data
The co-tree overlay region consists
overlay segments of the co-trees.

overlay

for

the

The co-tree root segment contains the modules that, once loaded,
remain resident in memory.

must

5-1'1

memory

allocated

CHAPTER 5.

5.2

OVERLAY CAPABILITY

EXAMPLE:

CALC13

The version of CALC introduced earlier is now ready for the addition
of two more data processing routines, PROC2 and PROC3. These new
algorithms are logically independent of each other and of PROCl.
The
third algorithm, PROC3, contains two independent routines SUBl and
SUB2.
The user defines an overlay structure for CALC as follows:
SUBl
PROCl
I

PROC2

SUB2

PROC3
I

RDIN
RPRT

5.2.1

Defining the ODL File

The user constructs a file, CALTR, of ODL directives to represent
tree for CALC, as follows:
)EDI
EDI)CALTR.ODL
(CREATING NEW FILE]
INPUT
.ROOT RDIN-RPRT-*(PROC1,PROC2,P3FCTR)
P3FCTR: .FCTR PROC2-(SUB1,SUB2)
.END
!EX
NOTE
The '*' in the ODL description is the
autoload indicator and is described in
Chapter 6.

5-15

the

CHAPTER S.
S.2.2

OVERLAY CAPABILITY

Building the Task

The user builds the task with the same options as in the example of
Chapter 3.
He replaces the names of the input files by a single
filename that designates the file containing the overlay description:
)TKB
TKB)CALCJ3,LP:/SH•CALTR/MP
ENTER OPTIONS:
TKB)PAR•PAR14K
TKB>ACTFIL•l
TKB)//

5.2.3

Memory Allocation File for CALC;3

The short memory allocation file for this multi-segment task consists
of one page per segment. For convenience the pages are compressed in
this manual. See Figure s-1.
The memory diagram for CALC;3 is:

SUBl

PROCl

SUB2

36400
35724
35310

PROC3

PROC2

segment tables and auto load vectors

33254
33012

FORTRAN buffers
26220
OTA

24556

RPRT
RDIN
1214
stack
214
header
0

If the user had not used an overlay structure for the task, the memory
requirement of the task would have been:
ROOT

PROCl
PROC2
PROC3
SUBl
SUB2

33012
3124
2304
2034
414
404

43516
5-16

CHAPTER 5 •

OVERLAY CAPABILITY
FILE CALC.TSKJ3 MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25-JUL-74
AT 15:36 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT:RDIN
R/W MEM LIMITS:
STACK
LIMITS:
DISK BLD LIMITS:
IDENTIFICATION :
PRG XFR ADDRESS:
TASK ATTRIBUTES:

000000 033253 033254
000214 001213 001000
000002 000035 000034
$FORT
001214
NC

PROGRAM SECTION ALLOCATION SYNOPSIS:
(. BLK.>:
(OTA
>:
($$ALER):
($$AOTS):
($$DEVT):
($$FSR1>:
($$FSR2):
($$IOB1):
<$$IOB2):
($$0BF1):
($$0BF2):
($$0VDT):
($$RESL):
($$SGDF>:
<. ABS.):
<.$$$$.>:

001214 024555 023342
024556 026217 001442
026220 026243 000024
026244 027021 000556
027022 030231 001210
030232 031251 001020
031252 031353 000102
031354 031557 000204
031560 031560 000000
031560 031667 000110
031670 031670 000000
000000 000000 000000
031670 033011 001122
000000 000000 000000
000000 000000 000000
033012 033012 000000

*** SEGMENT: PROCl
R/W MEM LIMITS: 033254 036377 003124
DISK BLK LIMITS: 000036 000041 000004

Figure 5-1
Memory Allocation File ~or CALC;~
(Mapped Syi:;tern)

5-17

CHAPTER 5.

OVERLAY CAPABILITY
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.): 033254 034737 001464

(ADTA

): 034740 036377 001440

*** SEGMENT: PROC2

R/W MEM LIMITS: 033254 035557 002304
DISK BLK LIMITS: 000042 000044 000003
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.): 033254 034117 000644
<ADTA

): 034120 035557 001440

*** SEGMENT: PROC3
R/W MEM LIMITS: 033254 035307 002034
DISK BLK LIMITS: 000045 000047 000003
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.): 033254 033627 000354
(ADTA ): 033630 035267 001400
***SEGMENT: SUBl
R/W MEM LIMITS: 035310 035723 000414
DISK BLK LIMITS: 000050 000050 000001

PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.): 035310 035723 000414
*** SEGMENT: SUB2

R/W MEM LIMITS: 035310 035713 000404
DISK BLK LIMITS: 000051 000051 000001

PROGRAM SECTION ALLOCATION SYNOPSIS:
(. BLK.): 035310 035713 000404
Figure 5-1 (Cont.)
Memory Allocation File for CALC13
(Mapped System)
5-18

CH/l..PTER 5 s

5.3

OVERLAY CAPABILITY

EXAMPLE CALC14

After examining the memory allocation
observes that the Task Builder has
segments PROCl, PROC2, and PROC3, since
equidistant from the root.

file for CALC13, the user
allocated ADTA in the overlay
all of these segments are

The user knows, however, that these segments need to conuuunicate with
each other through ADTA.
In the existing allocation, any values
placed in ADTA by PROCl are lost when PROC2 is loaded. Similarly, any
values stored in ADTA by PROC2 are lost when PROC3 is loaded.
The user adds a .PSECT directive to the overlay description to force
ADTA into the root segment so that PROCl, PROC2, and PROC3 can
cormnunicate with each other. He modifies CALTR as follows:
P3FCTR:

.ROOT RDIN-RPRT-ADTA-*(PROC1,PROC2,P3FCTR)
.FCTR PROC3-(SUB1,SUB2)
.PSECT ADTA,RW,GBL,REL,OVR
.END

He builds the task as in CALC13 and the resulting
file can be represented by the following diagram:

memory

36400

SUBl
PROCl

PROC2

35724

SUB2
35310

PROC3
34714

segment table and autoload vectors

34452

FORTRAN buffers
27660
OTA

26216
ADTA

24556
RPRT

RDIN
1214
stack
214
header
0

5-19

allocation

CHAPTER 5.

OVERLAY CAPABILITY
FILE CALC.TSK14 MEMORY ALLOCATION MAP
THIS ALLOCATI~N WAS DONE ON 25-JUL-74
AT 15:44 BY TASK BUILDER VERSION M06

***ROOT SEGMENT: RDIN

R/W MEM LIMITS: 000000 034713 034714
STACK
LIMITS: 000214 001213 001000
DISK BLK LIMITS: 000002 000036 000035
IDENTIFICATION : $FORT
PRG XFR ADDRESS: 001214
TASK ATTRIBUTES: NC
PROGRAM SECTION ALLOCATION SYNOPSIS
<. BLK.>
(ADTA )
(OTA
>
<$$ALER>
($$AO'l'S)
($$DEVT)
($$FSR1>
($$FSR2)
($$IOB1>
($$IOB2)
($$0BF1>
($$OBF2>
($$0VDT)
<$$RESL)
<$$SGOF)
<. ABS.>
<.$$$$.>

001214 024555 023342
024556 026215 001440
026216 027657 001442
027660 027703 000024
027704 030461 000556
030462 031671 001210
031672 032711 001020
032712 033013 000102
033014 033217 000204
033220 033220 000000
033220 033327 000110
033330 033330 000000
000000 000000 000000
033330 034451 001122
000000 000000 000000
000000 000000 000000
034452 034452 000000

Figure 5-2
Memory Allocation File for CALC~4
(Mappecl System)

5-20

CHAPTER 5.

OVERLAY CAPABILITY

*** SEGMENT: PROCl
R/W MEM LIMITS: 034714 036377 001464
DISK BLK LIMITS: 000037 000040 000002
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.>: 034714 036377 001464
*** SEGMENT: PROC2
R/W MEM LIMITS:
DISK BLK LIMITS:

034714 035557 000644
000041 000041 000001

PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.>: 034714 035557 000644

*** SEGMENT: PROC3
R/W MEM LIMITS: 034714 035307 000374
DISK BLK LIMITS: 000042 000042 000001
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.>: 034713 035267 000354

*** SEGMENT: SUBl
R/W MEM LIMITS:
DISK BLK LIMITS:

035310 035723 000414
000043 000043 000001

PROGRAM SECTION ALLOCATION SYNOPSIS:
(. BLK.>: 035310 035723 000414

*** SEGMENT: SUB2
R/W MEM LIMITS: 035310 035713 000404
DISK BLK LIMITS: 000044 000044 000001
Figure 5-2 (cont.)
Memory Allocation File for CALC74
(Mapped System)

5-21

CHAPTER S..
5.4

OVERLAY CAPABILITY

SUMMARY OF THE OVERLAY DESCRIPTION LANGUAGE
1.

An overlay structure consists of one or more trees.
Each
tree contains at least one segment. A segment is a set of
modules and p-sections that can be loaded by a single disk
access.
A tree can have only one root segment, but it
number of overlay segments.

can

have

any

The overlay description language provides five directives for
specifying the tree representation of the overlay structure,
namely:
.ROOT
.END
.PSECT
.FCTR
.NAME
These directives can appear in any order in the
description, subject to the following restrictions:

overlay

There can be only one .ROOT and one .END directive.

The .END directive must be the last directive,
terminates input.

The tree structure is defined by the operators
and ' , '

since

'-'

(hyphen)

(comma) and by the use of parentheses.

The operator 1 - 1 (hyphen) indicates that its arguments are to
be concatenated and thus co-exist in memory. The operator','

(comma) within parentheses indicates that its arguments are
to be overlaid and thus share memory. The operator',' not
enclosed in parentheses delimits
overlay
trees.
The
parentheses group segments that begin at the same point in
memory.
For example,
.ROOT A-B-(C,D-(E,F))
defines an O\erlay structure with a root segment consisting
of the modules A and B. In this structure, there are four
overlay segments, c, D, E, and F. The outer parenthesis pair
indicates that the overlay segments C and D start at the same
location in memory.
4.

The simplest overlay description consists of two
as follows:
.ROOT A-B-(C,D-(E,F))
.END

5-22

directives,

CHAPTER 5.

OVERLAY CAPABILITY

Any number of the optional
.NAME) can be included.

directives

(.FCTR,

.PSECT,

and

The .ROOT directive defines the overlay structure.
The
arguments of the .ROOT directive are one or more of the
following:
•

File specifications as described in 2.3.1

•

Factor labels

•

Segment names

•

P-section names

The .END directive terminates input.

The .FCTR directive provides a means for replacing text by a
symbolic reference (the factor label). This replacement is
useful for two reasons:
a.

The .FCTR directive effectively extends the text of the
.ROOT directive to more than one line and thus allows
complex trees to be represented.
The .FCTR directive allows the overlay description to be
in a form that makes the structure of the tree
more apparent.

written

For example:
.ROOT A-(B-(C,D),E-(F,G),H)
.END
can be expressed, using the .FCTR directive, as follows:
Fl:
F2:

.ROOT A-(Fl,F2,H)
.FCTR B- (C,D)
.FCTR E-(F,G)
.END

The second representation makes it clear that
three main branches.

the

tree

has

The .PSECT directive provides a means for directly specifying
the segment in which a p-section is placed.
The .PSECT directive gives the name of the p-section and
attributes. For example:

its

.PSECT ALPHA,CON,GBL,RW,I,REL
ALPHA is the p-section name and the remaining arguments are
attributes. P-section attributes are described in Chapter 4.

5-23

CHAPTER S.

OVERLAY CAPABILITY

The p-section name must appear first on the .PSECT directive,
but the attributes can appear in any order or can be omitted.
If an attribute is omitted, a default assumption is made.
For p-section attributes the default assumptions are:
RW,I,LCL,REL,CON
In the above example, therefore, it is only necessary to
specify the attributes that do not correspond to the default
assumption:
.PSECT ALPHA,GBL
9.

The .NAME directive provides a means for defining a segment
name for use in the overlay description. This directive is
useful for creating a null segment or naming a segment that
is to be loaded manually.
If the .NAME directive is not
used, the name of the first file, or p-section in the segment
is used to identify the segment.
The .NAME directive defines a name, as follows:
.NAME NEWNM
The defined name must be unique with respect to the names
p-sections, segments, files, and factor labels.

10.

A co-tree can be defined by specifying an additional tree
structure in the .ROOT directive. The first overlay tree
description in the .ROOT directive is the main
tree.
Subsequent overlay descriptions are co-trees. For example:
.ROOT A-B-(C,D-(E,F)) ,X-(Y,Z),Q-(R,S,T)
The main tree in this example has the root segment consisting
of files A.OBJ and B.OBJ1 two co-trees are defined1 the
first co-tree has the root segment X and the second co-tree
has the root segment Q.

5-24

CHAPTER 6
LOADING MECHANISMS

When the user divides his task into overlay segments, he becomes
responsible for loading these overlay segments into memory as they are
needed. The degree of involvement on the part of the user can range
from minimum, in which he specifies that the loading of all segments
be handled automatically, to maximum, in which he explicitly controls
the asynchronous loading of each .segment and handles any errors that
occur as a result of the load request.
This chapter describes the loading mechanisms available to the user.
There are two methods for loading overlays:
Auto load

in
which
the
overlay
Runtime
System
is
automatically invoked to load those segments that
are marked by the user.

Manual Load

in which the user includes explicit calls
Overlay Runtime System in his programs.

the

In the autoload method, loading and error recovery are handled by the
Overlay Runtime System. In the manual load method, the user handles
loading and error recovery explicitly. The user has more control and
can
specify
whether
loading is to be done synchronously or
asynchronously.
The user must decide which method he is going to use, because both
methods can not be used in a single task.
Both methods offer
advantages. The autoload method allows the user to divide his task
into segments without explicit calls to load overlays. The manual
load method saves space and gives the user full control over the
loading process.
The user is responsible for loading the overlay segments of the main
tree, and if co-trees are used, the root segment as well as the
overlay segments of the co-tree. Once loaded, the root segment of the
co-tree remains in memory;

6-1

CHAPTER 6.
6.1

LOADING MECHANISMS

AUTOLOAD

If the user decides to use the autoload method, he places the autoload
indicator '*' in the ODL description of the task at the points where
loading must take place. The execution of a transfer of control
instruction to an autoloadable segment up-tree automatically initiates
the autoload process.

6.1.1

Autoload Indicator

The autoload indicator, '*', marks the construct to which it is
applied as autoloadable.
If the autoload indicator is applied to a
parenthesized construct then every name within the parentheses is
marked autoloadable. Applying the autoload indicator at the outermost
parentheses level of the ODL tree description marks every module in
the overlay segments autoloadable.
Consider the example TKl of Chapter 5, and suppose further that
segment C consists of a set of modules Cl, C2, C3, C4 and cs. The
tree diagram for TKl then is:
A22

A21
I

AO
I

C4
C3
C2
Cl

Al
I

spI

CNTRL

If the . user introduces the autoload indicator at the outermost
parentheses level, he is assured that, regardless of the flow of
control within the task, a module is always properly loaded when it is
called. The ODL description for the task with this provision then is:
AFCTR:
BFCTR:
CFCTR:

.ROOT CNTRL-*(AFCTR,BCTR,CFCTR)
.FCTR A0-(Al,A2-(A21,A22))
.FCTR BO-(Bl,B2)
.FCTR Cl-C2-C3-C4-C5
.END

To be assured that all modules of a co-tree are properly loaded, the
user must mark the root seg~r.ent as well as the outermost parentheses
level of the co-tree, as follows:
.ROOT CNTRL-* (l~CTR,.LFTCR,CFCTR) ,*CNTRL2-* (CNTRLX,CNTRLY)
The above example assu~es that
executable code reside in CNTRL2.

one

modules

containing

CHAPTER 6 •

LOADING MECHANISMS

The autoload indicator can be applied to the following constructs:

•

Filenames - to
autoloadable.

the

file

•

Parenthesized ODL tree descriptions - to make all the
within the parentheses autoloadable.

names

•

P-section names - to make the p-section autoloadable.
p-section must have the I (instruction) attribute.

The

make

all

the

components

Defined names introduced by the .NAME directive - to make
all components of the segment to which the name applies
autoloadable.
•

Factor label names - to make the first irreducible component
of the factor autoloadable.
If the entire factor is
enclosed in parentheses, then the entire factor is made
autoloadable.

Suppose the user introduces two .PSECT directives and a .NAME
directive into the ODL description for TKl and then applies autoload
indicators in the following wayi
AFCTR:
BFCTR:
CFCTR:

.ROOT CNTRL-(*AFCTR,*BFCTR,*CFCTR)
.FCTR A0-*~.SUBl-ASUB2-*(Al,A2-(A21,A22))
.FCTR (BO-{Bl,B2))
.FCTR CNAM-Cl-C2-C3-C4-CS
.NAME CNAM

.PSECT ASUBl,I,GBL,OVR
.PSECT ASUB2,I,GBL,OVR
.END
The interpretation for each
description is as follows:

autoload

indicator

the

overlay

*AFCTR

The autoload indicator is applied to a factor label
name, so the first irreducible component of that
factor, AO, is made autoloadable.

*BFCTR

The autoload indicator is applied to a factor label
name, so the first irreducible component of that
factor, (BO-{Bl,B2)), is made autoloadable.

*CF CTR

Again, the autoload indicator is applied to a factor
label name, so the first irreducible component, CNAM,
of the factor is made autoloadable. CNAM, however, is
a defined name introduced by a .NAME directive, so all
the components of the segment to which the name applies
are made autoloadable;
that is, Cl, C2, C3, C4, and

cs.

*ASUBl

The autoload indicator is applied to a p-section
so the p-section ASUBl is made autoloadable.

6-3

name,

CHAPTER 6.

LOADING MECHANISMS

*(Al,A2-(A21,A22)) The autoload indicator is applied to
a
parenthesized ODL description so every name within the
parentheses is made autoloadable1
that is, Al, A2,
A21, and A22.
The net effect of the above ODL description
except ASUB2 autoloadable.

6.1.2

make

every

name

Path-Loading

Autoload uses the technique of path-loading. That is, a call from a
segment to a segment up-tree (farther away from the root) requires
that all the segments on the path from the calling segment to the
called segment to be resident in memory. Path loading is confined to
the tree in which the called segment resides. A call from a segment
in another tree ~sults in the loading of all segments on the path in
the second tree from the root to the called module.
Consider again the example TKl and the tree diagram:

Ay2
tl

AO
I

A2I

cs
~l

BO
I

B2
I

C4
C3
C2
Cl
I

CNTRL

If CNTRL calls A2, then all the modules between the calling module
CNTRL and the called module A2 are.loaded. In this case modules AO
and A2 are loaded.
The Overlay Runtime System keeps track of the segments in memory and
only issues load requests for those segments not in memory. If, in
the above example, CNTRL called Al and then called A2, AO and Al are
loaded first and then A2 is loaded. AO is not loaded when A2 is
loaded because it is already in memory.
A reference from a segment to a segment down-tree (closer to the root)
is resolved directly. For example, if A2 calls AO, then the reference
is resolved directly because AO is known to be in memory as a result
of the path-loading that took place in the call to A2.

fi-4

CHAPTER 6.

6.1.3

LOADING MECHANISMS

Autoload Vectors

When the Task Builder sees a reference from a segment to an
autoloadable segment up-tree, it generates an autoload vector for the
referenced global symbol. The definition of the symbol is changed to
an autoload vector table entry. The autoload vector has the following
format:

JSR

PC
$AUTO

SEGMENT DESCRIPTOR ADDR.
ENTRY POINT ADDRESS

Observe that a Transfer of Control instruction to the referenced
global symbol executes the call to the autoload routine, $AUTO
contained in the autoload vector.
An exception is made in the case of a p-section with the D (data)
attribute.
References from a segment to a global symbol up-tree in a
p-section with the D attribute are resolved directly.
Since the Task Builder can obtain no information about the flow of
control within the task, it often generates more autoload vectors than
are necessary. The user, however, can apply his knowledge of the flow
of control of his task and his knowledge of path-loading to determine
the placement of autoload indicators.
By placing the autoload
indicators only at the points where loading is actually required, the
user can minimize the number of autoload vectors generated for the
task.

F;-5

CHAPTER 6.

LOADING MECHANISMS

Suppose that in TKl all the calls to overlays originate in the root
segment.
That is 1 no module in an overlay segment calls outside its
overlay segment. Suppose further that the root segment CNTRL has the
following contents:
PROGRAM CNTRL
CALL Al
CALL A21

CALL A2
CALL AO
CALL A22
CALL BO
CALL Bl
CALL B2
CALL Cl
CALL C2
CALL C3
CALL C4
CALL CS

END
If the autoload indicator is placed at the outermost parentheses
level, thirteen autoload vectors are generated for this task.
The user observes that since A2 and AO are loaded by path loading to
A21, the autoload vectors for A2 and AO are unnecessary. He observes,
further, that the call to Cl loads the segment which contains C2, C3,
C4 and CS;
therefore autoload vectors for C2 through CS are
unnecessary.
The user eliminates the unnecessary autoload vectors by placing the
autoload indicator only at the points where loading is required, as
follows:
AFCTR:
BFCTR:
CFCTR:

.ROOT CNTRL-(AFCTR,*BFCTR,CFCTR)
.FCTR AO-(*Al,A2-*(A21,A22))
.FCTR (BO-(Bl,B2))
.FCTR *Cl-C2-C3-C4-C5
.END

With this ODL description, the Task Builder generates only seven
autoload vectors, namely those for Al, A21, A22, BO, Bl, B2, and Cl.

6.2

MANUAL LOAD

If the user decides to use the manual load method of loading segments,
he must include explicit calls to the $LOAD routine in his programs.
These load requests give the name of the segment to be loaded and
optionally give information necessary to perform asynchronous load
requests and to handle unsuccessful load requests.
The $LOAD routine does not path-load. A call to $LOAD always results
in the segment named in the load request being loaded and only that
segment being loaded.

CHAPTER 6.

LOADING MECHANISMS

The MACR0-11 programmer calls the $LOAD routine directly.
programmer is provided with the subroutine 'MNLOAD'.

6.2.1

The FORTRAN

Manual Load Calling Sequence

The MACR0-11 programmer calls $LOAD, as follows:

#PBLK;RO

MOV
CALL

$LOAD

where PBLK labels a parameter block with the following format:
PBLK:

.BYTE
.RADSO
.WORD
.WORD

length,event-flag
/seg-name/
I/0-status
AST-trp

The user must specify the following parameters:
length

the length of the parameter block (3 - 5 words)

event-flag

the event flag number, used for asynchronous
loading.
If the event-flag number is zero,
synchronous loading is performed.

seg-name

the name of the segment to be loaded, a 1- to
6-character radix-SO name, occupying two words.

The following para.~eters are optional~
I/0-status

the

address

the

I/O

status

doubleword.

Standard QIO status codes apply.
AST-trp

the address of an asynchronous trap
service
routine to which control is transferred at the
completion of the load request.

The condition code C is set or cleared on return, as follows:
If the condition code C = O, the load
executed.

request

was

successfully

If condition code C = 1, the load request was unsuccessful.
For a synchronous load request, the return of the condition code O
means that the desired segment has been loaded and is ready to be
executed. For an asynchronous load request, the return of the code 0
means that the load request has been successfully queued to the device
driver, but the segment is not necessarily in memory. The user must
ensure that loading has been completed by waiting for the specified
event flag before calling any routines or accessing any data in the
segment.

6-7

CHAPTER 6.

LOADING MECHANISMS

FORTRAN Subroutine for Manual Load Request

6.2.2

To use manual load in a FORTRAN program, the program makes explicit
reference to the $LOAD routine by means of the 'MNLOAD' subroutine.
The subroutine call has the following form:
CALL MNLOAD (seg-name,event-flag,I/O-status,ast-trp,ld-ind)
where:
seg-name

is a 2 word real variable containing the
in radix-SO format.

event-flag

is an optional integer event flag nwnber, to be used
for an asynchronous load request. If the event flag
number is zero, the load request
is
considered
synchronous.

I/O-status

is an optional 2-word integer array to contain the I/O
status doubleword, as described for the QIO directive
in the RSX-llM Executive Reference Manual.

ast-trp

is an optional asynchronous trap subroutine to be
entered
at the completion of a request.
MNLOAD
requires that all pending traps specify the same
subroutine.

ld-ind

is an optional integer variable to contain the results
of the subroutine call. One of the following values is
returned:
+l

request was successfully executed.

-1

request had bad parameters or was
successfully.

6-R

segment

not

name

executed

CHAPTER 6.

LOADING MECHANISMS

Optional arguments can be omitted.
Call

The following calls are all legal:
Effect

CALL MNLOAD (SEGAl)

Load segment named
synchronously

CALL MNLOAD (SEGAl,O,,,LDIND)

Load segment named in ·SEGAl
synchronously
and
return
success indicator to LDIND.

SEGAl

CALL MNLOAD (SEGAl,l,IOSTAT,ASTSUB,LDINDj
Load segment named in SEGAl
asynchronously,
transferring
control
to
ASTSUB
upon
completion
of
the
load
request,
storing
the
I/O-status
doubleword
in
I OS TAT
and
the
success
indicator in LDIND
Consider the program CNTRL, discussed in connection with the autoload
method, and suppose that between tht: calls to the overlay segments
there is sufficient processing to make asynchronous loading effective.
The user removes the autoload indicators from his ODL description and
recompiles his FORTRAN programs with explicit calls to the MNLOAD

subroutine, as follows:
PROGRAM CNTRL
EXTERNAL ASTSUB
DATA SEGAl /6RA1
DATA SEGA21 /6RA21

...
...
CALL

/
/

CALL MNLOAD (SEGAl,1,IOSTAT,ASTSUB,LDIND)
Al

...
...

CALL MNLOAD (SEGA21,l,IOSTAT,ASTSUB,LDIND)
CALL A21

END
SUBROUTINE ASTSUB
DIMENSION IOSTAT{2)

...

END
When the AST trap routine is given as shown in the preceding example,
the IO status doubleword is automatically supplied to the dununy
variable IOSTAT.

CHAPTER 6.
6.3

LOADING MECHANISMS

ERROR HANDLING

If the manual load method is selected, the user must provide error
handling routines which diagnose load errors and provide appropriate
recovery.
If the autoload method is selected, a simple recovery procedure is
provided, which checks the Directive Status Word (DSW)
for the
presence of an error indication. If the DSW indicates that no system
dynamic
storage is available, the routine issues a
'wait for
significant event' directive and tries again; if the problem is not
dynamic
storage, the recovery procedure generates a breakpoint
synchronous trap. If the using routine is set to service the trap and
return without altering the state of the program, the request can be
retried.
A more comprehensive user-written error recovery subroutine can be
substituted
for
the
system-provided routine if the following
conventions are observed:
1.

The error recovery routine must have

the

entry

point

name

$ALERR.

The contents of all registers must be saved and restored.

On entry to $ALERR, R2 contains the address of the segment descriptor
that could not be loaded. Before recovery action can be taken, the
routine must determine the cause of the error by examining the
following words in the sequence indicated:

6.4

$DSW -

The Directive Status Word may contain an error
status code, indicating that the I/O request to
load the overlay segment was rejected by the
Executive.

N.OVPT -

The contents of this location, offset by N.IOST,
point to a 2-word I/O Status block containing the
results of the load overlay request returned by
the device driver. The status code occupies the
low-order byte of word O.

EXAMPLE:

CALC;S

Suppose the task CALC is now complete and checked out and the- user
wants to adjust the autoload vectors to minimize the amount of storage
required.
From his knowledge of the flow of control of the task he can determine
that PROC3 is always in memory as a result of path-loading when it is
called and therefore, the autoload vector for PROC3 can be eliminated.
He modifies the ODL description in CALTR, as follows:

6-1n

CHAPTER 6.

LOADING MECHANISMS

P3FCTR:

.ROOT RDIN-RPRT-ADTA-(*PROC1,*PROC2,P3FCTR)
.FCTR PROC3-*(SUB1,SUB2)
.END

He builds the task and the resulting memory allocation file in Figure
6-1 shows that the repositioning of the autoload indicator saved 10
bytes.
FILE CALC.TSK;S MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25-JUL-74
AT 15:50 BY TASK BUILDER VERSION M06

*** ROOT SEG'l.IBNT: RDIN
R/W MEM LIMITS:
STACK
LIMITS:
DISK BLK LIMITS:
IDENTIFICATION :
PRG XFR ADDRESS:
TASK ATTRIBUTES:

000000 034703 034704
000214 001213 001000
000002 000036 000035
$FORT
001214
NC

PROGRAM SECTION ALLOCATION SYNOPSlS:
<. BLK.):
(ADTA ):
(DTA
):
($$ALER):
($$AOTS):
($$DEVT):
<$$FSR1):
<$$FSR2):
<$$!0Bl):
($$IOB2):
($$0BF1):
($$0BF2):
<$$0VDT):
<$$RESL):
($$BGDF):
<. ABS.>:
<.$$$$.>:

6-11

CHAPTER 6.
6.5

LOADING MECHANISMS

GLOBAL CROSS-REFERENCE OF AN OVERLAID TASK

Chapter 4 introduced the global cross-reference feature. This section
illustrates a global cross-reference that has been created for an
overlaid task. The task consists of a root segment containing the
module ROOT.OBJ, and two overlay segments comprised of modules
OVRl and OVR2. The overlay description of the file is as follows:
.ROOT

ROOT-(OVR1,*0VR2)

Only segment OVR2 is autoloadable.
The resulting cross-reference listing is shown in Figure 6-2. By
consulting the cross-reference listing, the following observations
can be made.
The global symbol OVRl is defined in the module OVRl and a single
non-autoloadable, up-tree reference is made to this symbol by the
module ROOT (as indicated by the up-arrow, i.e., circumflx, ~haracter).
The asterisk preceding the module OVR2 indicates that the global
symbol OVR2 is an autoload symbol and is referenced from the module
ROOT through an autoload vector as shown by the @ character.
Down-tree references to the global symbol ROOT are made from modules
OVRl and OVR2. These references are resolved directly.

GLOBAL CHOSS REFERENCE
CREATED BY

Fil.IE: OVHTST

ON 21•MAR•75 AT 14:04

TKB

SYMBOL

VALUI::

REft:RENCES •••

N,ALER

000010
000004
000000
000054
000002
001764•R
001764-R
000037
001210•R
001226-R
001252•R
000046
001406•R
001512•R
001662-R
001224•R
001220-R
001214•R
000042
001216•R

AUTO
OVCTL
OVCTL
AUTO
OVRES
# OVR1
* OVR2

N,IOST
N.OVLY
N.UV~T

N.STBL
OVR1
OVR2

OSVEF
ROOT
$ALERR
SAU TO

sosw

SMARKS

SRDSt:;G
SSAVRG
,NALER
.NlOST
,NOV LY
.NOVPT
.NSTSL

•
• OVRl
ALERR
• AUTO
ALE RR

OVRES
• OVRES
#
# OVRES

OVCTL
.. wROOT
il ROOT

OVCTL

AUTO
AUTO
AUTO
# OVOAT
# OVDAT
# OVDAT
OVDAT
# OVOAT

OVR2
OVDAT

# ROOT

# OVCTL
# OVCTL
# SAVRG

•

Figure 6-2
Sample Overlaid Cross-reference Listing

6-12

PAGE l

CHAPTER 7

SHARED REGIONS

This chapter describes the use of shared regions. A shared region
a block of data or code that can be shared by any number of tasks.

Shared regions are useful because they
memory:

use

tasks

can

make

efficient

Shared regions provide a way in which two or more
communicate.

Shared regions provide a way in which a single copy of a data
base or conunonly used subroutines can be shared by several
tasks.

Consider the first case, in which two tasks, Task A and Task B, need
to conununicate a large amount of data.
A convenient method of
transporting this data is the use of a shared region.
Tasks can
communicate independent of their time of execution. This case is
illustrated by the following diagram:

shared region

Task A

Task B

Resident
Executive

System Memory
(Time t)

(System Memory)
Time t+n

7-1

CHAPTER 7.

SHARED REGIONS

Task A and Task B communicate through the shared region.
of tasks can link to a shared region.

Any

number

Consider the second case, in which tasks make use of common routines.
The common subroutines are not included in each task image; instead,
they are included in a shared region so that a single copy is
accessible to all tasks. This case is shown in the following diagram:

Routine R

Routine R
Task A
Routine R

Task A

Task B

Resident
Executive

System Memory

7-2

CHAPTER 7.

SHARED REGIONS

A task can link to as many as three shared regions. A privileged task
in a mapped system, however, can link to a maximum of two shared
regions.
A shared region has associated with it a task image file and a symbol
definition file.
When a task links to a shared region the Task
Builder uses the symbol definition file of the shared region to
establish the linkages between the task and the shared region.

7.1

USING AN EXISTING SHARED REGION

The user can link to any of the system shared regions by using the
COMMON or LIBR keyword option and specifying the name of the shared
region and the type of access he is requesting.
Suppose JRNAL is a system shared region and the user wants his task
IMGl to link to that region and examine some relevant data. He
specifies the name in the COMMON keyword with read-only access as
follows:
)TKB
TKB)IMG1,LP:=IN1,IN2,IN3
TKB>/
ENTER OPTIONS:
TKB)COMMON=JRNAL:RO
TKB)//
A task can link to any shared region on the disk. However, before the
task can be activated, any shared region it uses must be resident in
memory.

7.2

CREATING A SHARED REGION

To create a shared region, the task image and symbol definition
must be built under UIC (1,1] on the system device.

files

In Chapter 4, runnable tasks were described. A shared region differs
from a runnable task in that it does not have a header or a stack.
The user must therefore specify that no header and stack are to be
produced for the task image file in creating a shared region.
In swmnary, to create a shared region the following steps are taken:
•

The task image file and symbol definition
under UIC [1,1] on the system device.

•

The task image file or symbol definition file has the switch
/-HD, indicating that no header is required.

•

The option STACK=O
eliminate the stack.

entered

7-3

during

file

option

are

built

input

CHAPTER 7.

SHARED REGIONS

Suppose the user wants to create a resident library, ZETA, from
files Zl, Z2, and Z3. He builds the shared region, as follows:

the

>TKB
TKB>[l,l]ZETA/-HD,LP:,SY:[l,l]ZETA=Zl,Z2,Z3
TKB>/
ENTER OPTIONS :
TKB)STACK=O
TKB>//
A task can now link to the shared region. However, before the task
can be installed and activated, the shared region must be made
resident in memory. Space is allocated for the library and the
library is loaded into memory by the following commands (see the
RSX-llM Operator's Procedures Manual for a description of the commands).

>1 ALLOCATE SPACE FOR RESIDENT LIBRARY
)SET /MAIN=ZETA:l40011001COM
lINS [l,l]ZETA/PAR=ZETA
7.3

POSITION INDEPENDENT AND ABSOLUTE SHARED REGIONS

A shared region can be either position independent or absolute.
Position independent shared regions can be placed anywhere in the
task's virtual address space when the system on which the task runs
has memory management hardware. Absolute regions must be fixed in the
virtual address space.
The user must ensure that the region is position independent, if he
applies the PI switch.
The PI switch directs the Task Builder to
treat the region as position independent, but the Task Builder can not
determine whether or not the region is position independent. If the
PI switch is applied to a region which is not truly position
independent, the execution of a task linked to that region is
unpredictable.
Data is always position independent.
Code
can
be
position
independent, but the code produced as a result of compiling a FORTRAN
program is not position independent.
Furthermore, FORTRAN programs
can not be used as shared libraries because these programs do not
satisfy the re-entrancy requirements necessary for shared regions.
FORTRAN common blocks can be included in shared regions. However, the
only way FORTRAN programs can communicate through the use of common
blocks is by the common block name1 to retain this name, the shared
region must be declared position independent. If the region is not
declared position independent, the name is not retained and no FORTRAN
program can link to the common block.
Chapter 8 illustrates the use of a FORTRAN common block
region on an unmapped system.
Absolute shared regions
re-entrancy requirements
independent.

are
for

used for
a shared

7-A.

shared

code which satisfies the
region but is not position

CHAPTER 7.

7.4

SHARED REGIONS

EXAMPLE:

CALC76 BUILDING AND USING A SHARED REGION

Suppose the task CALC has been completely debugged cmd the user wants
to replace the dwmny reporting routine RPRT by a generalized reporting
program that operates as a separate task. This generalized reporting
program GPRT was developed by another programmer in parallel with the
development of CALC. Now both routines are ready and the user wants
to create a shared region so that the two tasks

c~~ comm\L~icate.

In addition to creating the shared region, the user must modify his
FORTRAN routine to replace the call to the dummy reporting routine by
a call to REQUEST for the task GPRT and he must remove the dwmny
routine from his ODL description for the task.

7.4.1

Building the Shared Region

The common block into which CALC places its results and from which
GPRT takes its input is named OTA. The user wants to make OTA into a
shared region so that the two tasks can communicate.
The user first creates a separate input file for OTA:
)EDI
EDI)DTA.FTN
CC-REATING NEW FILE]
INPUT

GLOBAL COMMON AREA FOR 1 CALC' AND
REPORTING TASK 1 GPRT 1
BLOCK DATA
COMMON /OTA/ A(200),I
END

*EX
He then compiles OTA:
)FOR DTA,LP:=DTA
He then builds the task image
shared region OTA:

and

symbol

definition

file

for

the

)TKB
TKB>[l,l]DTA/PI,LP:/SH,SYO:[l,l]DTA/-HD=DTA
TKB>/
ENTER OPTIONS:
TKB)STACK=O
TKB>//
He marks the task image file for OTA as position independent in
to retain the name of the referenced common block,.DTA.

7-5

order

CHAPTER 7.

SHARED REGIONS

As required, he creates the task image and symbol definition file on
the system device under the User Identification Code [1,1,], applies
the switch -HD to the symbol definition file to specify that the task
has no header, and enters the option STACK=O to eliminate the stack.
It was necessary to specify the system device SYO for the symbol
definition file;
if the user does not specify a device, the last
named device applies. In this case, failure to specify the system
device
would
have resulted in the application of the device
specification LP to the symbol definition file.
The shared region DTA now exists on the disk as an eligible candidate
for inclusion in an active system. The user can now modify his task
to link to that shared region.
However, before the task can be
executed, the shared region must be made resident in memory.

7.4.2

Modifying the Task to Use the Shared Region

The user now modifies the task CALC. He edits the file containing the
program RDIN to include the name of the reporting task in radix-SO
format:
DATA RPTSK/6RGPRT

And he replaces the call to the dmnmy reporting routine
call:

RPRT

the

CALL REQUES (RPTSK)
The relevant part of the program RDIN is shown below:
C
C
C
C

READ AND ANALYZE INPUT DATA
ESTABLISH COMMON DATA BASE
COMMON /DTA/ A(200), I
SET UP NAME OF REPORTING TASK IN RADIX SO
DATA RPTSK /6RGPRT /
READ IN RAW DATA

...
...
END

CALL REQUES (RPTSK)

The user now modifies the ODL description of the task CALC
the file RPRT.OBJ. He changes the .ROOT directive from:
.ROOT RDIN-RPRT-ADTA-(*PROC1,*PROC2,P3FCTR)
to:
.ROOT RDIN-ADTA-(*PROC1,*PROC2,P3FCTR)

7-6

remove

CHAPTER 7.

SHARED REGIONS

He then builds an indirect conunand file to include the COMMON keyword:
2EDI
EDI)CALCBLD.CMD
(CREATING NEW FILE]
INPUT
CALC,LP:ISH=CALTRIMP
PAR=PAR14K
ACTFIL=l
COMMON=DTA:RW

II
_:EX

And then he builds the task with the single
indirect file:

conunand

referencing

the

)TKB @CALCBLD
The communication between the two tasks, CALC and GPRT, is now
established.
When the shared region DTA is made resident, the two
tasks can run.

7.4.3

The Memory Allocation Files

Figure 7-1 gives the memory allocation file for the shared region DTA.
The attribute list indicates that the task image was built with no
header (NH) and is position independent (PI).
Figure 7-2 gives the memory allocation file for the task CALC after
the shared region DTA was created and the dununy reporting routine
removed from the task. The read-write memory limits for the root
segment code have increased due to the call to REQUES. The read-write
memory limits for the entire task have decreased because the common
block DTA is now a shared region allocated at 160000 and no longer
part of the task.

7-7

CHAPTER 7.

SHARED REGIONS

FILE DTA.TSK:2 MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25-JUL-74
AT 16:25 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT: DTA
R/W MEM LIMITS: 000000 001443 001444
DIS BLK LIMITS: 000002 000003 000002
IDENTIFICATION:
TASK ATTRIBUTES:NC,NH,PI
PROGRAM SECTION ALLOCATION SYNOPSIS:
<. BLK.>:
(DTA
>:
<. ABS.>:
<.$$$$.>:

000000 000000 000000
000000 001441 001442
000000 000000 000000
001442 001442 000000

*** FILE: DTA.OBJ:2

TITLE: .DATA.

IDENT:

<.$$$$.>: 001442 001442 000000
(DTA

>: 000000 001441 001442

Figure 7-1
Memory Allocation File for the Shared Region DTA
(Mapped System)

7-8

CHAPTER 7.

SHARED REGIONS

FILE CALC.TSK:6 MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 25-JUL-74
AT 16:20 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT: RDIN
R/W MEM LIMITS: 000000 033337 033340
STACK
LIMITS: 000214 001213 001000
DISK BLK LIMITS: 000002 000035 000034
IDENTIFICATION : $FORT
PRG XFR ADDRESS: 001214
TASK ATTRIBUTES: NC
PROGRAM SECTION ALLOCATION SYNOPSIS:
<. BLK.): 001214 024651 023436
(ADTA ): 024652 026311 001440
(DTA
): 160000 161441 001442
($$ALER): 026312 026335 000024
($$AOTS): 026336 027113 000556
($$DEVT): 027114 030323 001210
($$FSR1): 030324 031343 001020
($$FSR2): 031344 031445 000102
($$IOR1): 031446 031651 000204
($$IOB2): 031652 031652 000000
($$0BF1): 031652 031761 000110
($$0BF2): 031762 031762 000000
($$0VOT): 000000 000000 000000
($$RESL): 031762 033103 001122
($$SGDF): 000000 000000 000000
(. ABS.): 000000 000000 000000
<.$$$$.>: 161442 161422 000000

*** FILE: DTA.STB;2
(DTA

TITLE: OTA

IDENT:

); 160000 161441 001442

<. ABS.): 000000 000000 000000
N.OVPT 000054

$DSW

000046

$0TSV

000052

<.$$$$.>: 161442 161442 000000

*** FILE: RDIN.OBJ;S

TITLE: .MAIN.

IDENT: $FORT

<.$$$$.>: 161442 161442 000000
<.$$$$.>: 161442 161442 000000

Figure 7-2
Memory Allocation File for CALC;6
(Mapped System)

7-9

.FSPRT 000050

CHAPTER 8
HOST AND TARGET SYSTEMS

This chapter describes the construction of a task destined to
another system.

8.1

run

BUILDING THE TASK FOR THE TARGET SYSTEM

The user can transfer a task fran the host system (the system on which
the task is built) to the target system (the system on which the task
will run) by following a few simple steps:

8.1.1

He builds the task image specifying a partition that has the
base address and size of the partition in which the task will
run on the target system.

He ensures that any shared regions accessed by the
present in both systems under UIC[l,1].

If the target system and the host system do not have the same
mapping status, he sets the Memory Management switch (MM) to
reflect the mapping status of the target system.

task

are

Example

Suppose that in a given installation, there is one large computer
system with mapping hardware and several smaller systems without
mapping hardware. The programmers in this installation create and
debug their tasks on the large host system and when the tasks are
ready to go into production, they transfer them to the smaller
systems.
If the programmer is developing the task, TKl, in the
default partition on the host system, his task building sequence is:
)TKB TK1,LP:=SQ1,SQ2
When he is ready to move his task to a target system, he builds the
task again, indicating the mapping status of the target system and
naming the partition in which the task is to reside on the target
system:

B-1

CHAPTER 8.

HOST AND TARGET SYSTEMS

)TKB
TKB>TKl/-MM,LP:=SQl,SQ2
TKB)/
ENTER OPTIONS:
TKB)PAR=PART1:100000:40000
TKB)//
The resulting task image is
system.

8.2

EXAMPLE:

ready

run

the

unmapped

target

CALC;7

Suppose the user has now completed checking out the interface between
his task CALC and the generalized reporting routine and he is now
ready to move the task to another system. The system on which he has
been working has mapping hardware, but the system on which CALC is
going to run does not have mapping hardware.
The user knows the configuration of the target system. He knows that
there is a partition called PAR8K with base at 40000 in which the task
CALC is going to run.
To move the tasks CALC and GPRT, he must also move the shared region
DTA.
Therefore, he must rebuild the shared region task image for the
partition in which it will reside on the target system.

8.2.l

Rebuilding the Shared Region

He builds the task image for the shared region again, this time for
partition in the target system:
>TKB
TKB>[l,l]DTA/PI/-MM,LP:/SH,SYO:[l,l]DTA/-HD=DTA
ENTER OPTIONS:
TKB)STACK=O
TKB)PAR=PARS1:156000:2000
TKB>//

8-2

CHAPTER 8.
8.2.2

HOST AND TARGET SYSTEMS

Rebuilding the Task for the Target System

He modifies the indirect command file CALCBLD, so that it includes the
memory mapping switch and the target partitions.
He also adds
comments to identify the task building sequence:
PROCESS ANALYSIS FOR SYSTEM M23
VERSION 1 DATE: AUG 26, 1974
CALC/-MM,LP:/SH=CALTR/MP
PAR=PAR8K:40000:40000
COMMON=DTA:RW
JCOMMUNICATION WITH GPRT

II
He then builds his task with the single command1
_?TKB @CALCBLD
His task is now ready to be installed and run on the target system.
Before the task can be installed, the shared region must be made
memory resident on the target system.

8.2.3

The Memory Allocation Files

Figure 8-1 gives the memory allocation file of the shared region DTA
for an unmapped system. The shared region is bound to the partition
base specified by the PAR keyword in the task build.
Note that the
shared region is declared position independent in the unmapped system
even though it is bound to the partition base 156000.
The position
independent declaration is necessary to preserve the relocatable
p-section DTA so that other FORTRAN tasks can link to the region.
Figure 8-2 gives the memory allocation file of the task CALC for an
unmapped system.
The task is bound to the specified partition base
40000 and linked to the shared region DTA bound at 156000.

R-3

CHAPTER 8.

HOST AND TARGET SYSTEMS

FILE DTA.TSK;l MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 20-AUG-74
AT 07:09 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT: OTA
R/W MEM LIMITS: 156000 157443 001444
DISK BLK LIMITS: 000002 000003 000002
IDENTIFICATION:
TASK ATTRIBUTES: NC,NH,PI
PROGRAM SECTION ALLOCATION SYNOPSIS:
<. BLK.):
(DTA
):
<. ABS.):
<.$$$$.):

156000 156000 000000
156000 157441 001442
000000 000000 000000
157442 157442 000000

*** FILE: DTA.OBJ;l TITLE: .DATA. IDENT:
<.$$$$.): 157442 157442 000000
(OTA

): 156000 157441 001442

Figure 8-1
The Memory Allocation File for the Shared Region
(Unmapped System)

R-4

CHAPTER 8.

HOST AND TARGET SYSTEMS

FILE CALC.TSK:>: MEMORY ALLOCATION MAP
THIS ALLOCATION WAS DONE ON 20-AUG-74
AT 08:25 BY TASK BUILDER VERSION M06

*** ROOT SEGMENT: RDIN
R.W MEM LIMITS: 040000 073337 033340
STACK
LIMITS: 040214 041213 001000
DISK BLK LIMITS: 000002 000035 000034
IDENTIFICATION : $FORT
PRG XFR ADDRESS: 041214
TASK ATTRIBUTES: NC
PROGRAM SECTION ALLOCATION SYNOPSIS:
<. BLK.): 041214 064661 023446
<ADTA ): 064662 066321 001440
(DTA
): 156000 157441 001442
($$ALER): 066322 066345 000024
<$$AOTS): 066346 067123 000556
($$DEVT): 067124 070333 001210
($$FSR1): 070334 071353 001020
($$FSR2): 071354 071445 000102
<$$IOB1): 071456 071661 000204
($$IOB2): 071662 071662 000000
($$0BF1): 071662 071771 000110
<$$0BF2): 071772 071772 000000
<$$0VDT): 000000 000000 000000
($$RESL): 071772 073113 001122
($$SGDF): 000000 000000 000000
<. ABS.): 000000 000000 000000
<.$$$$.> 157442 157442 000000

*** SEGMENT: PROCl
R/W MEM LIMITS: 073340 075023 001464
DISK BLK LIMITS: 000036 000037 000002
PROGRAM SECTION ALLOCATION SYNOPSIS:
<. BLK.): 073340 075023 001464
Figure 8-2
The Memory Allocation File for
CALC:7 (Unmapped System)

8-5

CHAPTER 8.

HOST AND TARGET SYSTEMS

*** SEGMENT, PROC2
R/W MEM LIMITS: 073340 074203 000644
DISK BLK LIMITS: 000040 000040 0000'01
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.>: 073340 074203 000644
*** SEGMENT: PROC3
R/W MEM LIMITS: 073340 073673 000334
DISK BLK LIMITS: 000041 000041 000001
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.>: 073340 073673 000334
*** SEGMENT: SUBl
R/W MEM LIMITS: 073674 074307 000414
DISK BLK LIMITS: 000042 000042 000001
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.>: 073674 074307 000414
*** SEGMENT: SUB2
R/W MEM LIMITS: 073674 074307 000414
DISK BLK LIMITS: 000043 000043 000001
PROGRAM SECTION ALLOCATION SYNOPSIS:

<. BLK.): 073674 074307 000414
Figure 8-2 (Cont.)
The Memory Allocation File for CALC17
(Urunapped System)

8-6

CHAPTER 9
MEMORY DUMPS

9.1

POST-MORTEM DUMPS

The task PMD ... generates a Post-mortem Dump of a task that is abnormally terminated. A task may be made eligible for a Post-Mortem
dump in one of two ways:
1.

At task build time by specifying the /PM switch on the
task file.
/-PM will disable dumps and is the default.

At task installation time the /PMD switch may be used
to override the task built option. /PMD=YES will enable
dumping; /PMD=NO will disable dumping.

The Post-mortem Dump task PMD ... should be installed in a 4K partition in which all other tasks are checkpointable. This allows the
dump to be generated in a timely manner and prevents the system from
being locked up while the dump is being generated. The dump task
is capable of dumping from memory or from the checkpoint image of
the user's task. The Post-mortem Dump task is sensitive to the
location of the aborted task. Thus, if the aborted task is checkpointed during the dump, the dump task will switch to reading the
checkpoint image. If the aborted task returns to memory after
being checkpointed, the Post-mortem Dump will switch to using the
core image again.
Dumps are always generated on the system disk under UIC (1,4]. Thus,
to avoid errors from PMD ... the user must allocate a UFD for [1,4]
before installing the task. When the dump task finishes generating
the dump, it will attempt to queue it to the print spooler for subsequent printing.
If no spooler is installed, the dump file will be
left on the disk and may be printed at a later time using PIP.
NOTE
Dump files tend to be rather large. The dump of an
8K partition will average about 340 blocks. Therefore, if there is little space on the disk, it is
important to print and delete the dump file without
delay.

9-1

CHAPTER 9.
9.1.1

MEMORY DUMPS

Description of a Dump Generated by PMD ...

The following description of the contents of Post-Mortem and Snapshot
dumps is keyed to Figure 9-1.
Snapshot dumps are explained more
fully in Section 9.2.
Item

Description

Type of dump - Post-Mortem or Snapshot.
dump, the dump ID is printed.

The name of the task being dumped and the date and time the
dump was generated.

The program counter at the time of the dump; and if it is a
post-mortem dump, the reason the task was aborted.

The general registers, stack pointer, and processor status
at the time of the dump.

The task status flags at the time of the dump. See the
description of ATL or TAL in the RSX-llM Operator's Procedures Manual for the meaning of the flags.

The task event flag mask words at the time of the dump.
If
the dump is a Snapshot dump, the EFN specified in the SNAP
macro will be ON.

The task UIC and the current value of the directive status
word.

The task's priority, number of outstanding I/O requests, and
the terminal from which the task was initiated (TI:).

The task load device and the logical block number of the
start of the task image on the device.

The floating point unit (FPU) registers or the extended
arithmetic element (EAE) registers if the task is using one
of these pieces of hardware.
If the task is not using the
FPU or EAE, these registers will not be printed. If the
task uses the FPU and doesn't specify /FP on the task image
file, or if it uses the EAE unit and has not specified the
/EA switch, the registers will not be printed. If the
machine being used has both an FPU and an EAE, PMD will
assume the user is using the FPU since it is the unit
of choice for arithmetic computations.

The logical unit assignments at the time of the dump.
UNIT
is the logical unit number, and DEVICE is the device to which
the logical unit is assigned. For Snapshot dumps, file
status will display the file name of any open files.
Postmortem dumps will not display this information since all of
the files will have been closed as a result of the I/O
rundown on the aborted task.

9-2

If it is a Snapshot

CHAPTER 9.

MEMORY DUMPS

Item

Description

The overlay segments loaded at the time of the dump, the
relative block number of the segment, the base address, the
length of the segment, and, for tasks using manual loads,
the segment names are displayed.
The block number may be
used to determine which segment is loaded by reference to
the memory allocation file generated by the Task Builder.
The starting block number for each segment is the relative
blo~k number of the segment.
By obtaining a match, the
name of the segment in memory may be determined.
Zero
length segments are usually co-tree roots.

The task stack at the time of the dump. The address is
displayed, along with the contents, in octal, ASCII, and
RADSO.
Each word on the stack is dumped.
If the stack
pointer is above the initial value of the stack (H.ISP),
only one word will be dumped. The rest will be dumped
as part of the task image.

The task image itself. The partition being dumped and the
limits of interest are displayed= For post-mortem du.~ps,
this is the entire task limit. For Snapshot dumps, this is
the virtual task limits requested by the user.
The dump
routine rounds the requested low limit down to the nearest
multiple of 8 bytes and rounds the requested high limit up
to the nearest multiple of 8 bytes. The dump image displays
the virtual starting address of a four-word block of memory,
the data in both octal and RADSO on the first line, and
byte octal and ASCII on the second line. A four-word block
which is repeated in a contiguous region of memory will be
printed once, and then noted by the message

***

DUPLICATE THROUGH xxxxxx

***

where xxxxxx indicates the last word which is duplicated.
If the task was aborted, the task partition, and the
libraries and common blocks it is linked to, will be dumped.
If the dump is a Snapshot dump, up to four contiguous
blocks of memory will be dumped, if requested.

9-3

CHAPTER 9.

MEMORY DUMPS

{1)

TASKt SNPTST
~

PCt 000726

!OT !XECUTION

R!GSI

Rt • 01110120

R3 • 10130}

SP • 0H312

PS •

(!)

170000

TASK SUTUSt
C01•16• 000001
C33•48> 0000'110

oswa 1.

(j)

PAIOAITVt !50,

l/O COUNTS et,

LOAD DEVICE • SV01

L!NI 0,002265

~LOATJNG

00(11000

~001211110

00000!0

000000
000000

00~U0

Ql00000

000H0

000000
000000
000000

R!5 •

044400

Rt • 000000
R2 • 00'11000
R3 • 00000111
R.t •

POINT UNIT

STATUS •
R0 •

TI DEVICE • TT101

000000
0011100111

00(Jl000

"'00000

000!000
000000
OIH000
000000
000000
P"'0000

LOGICAL UNITS
UNIT

DEVICE

1
2
3

sv01
sv01

FILE STATUS

sv01

OV!ALAV SEGMF-NTS LOADED
ST•ATING AfLlTlV! 8LOCK1 000002
~TARTING RELATIVE 8LOCK1 0000041

TASK STACK
AOORE SS

0U3t2

CONTENTS ASCII
000045

BASE I 000000
BASEi 0014e4

' l

~uoe0

LENGTH1
LENGTH I

)

Figure 9-1
Sample Post-Mortem Dump

9-4

em1•e•
000~64

l
)

TUI< IMAGE

F'AIHITION1 G[N

0U0H

01210312

312 00"11

000170
170 00~

003200

UH 10

001717
371 003

200 GH!!6

000020

000J000

12100000

000 000

•••

OUPLICAH TMROUGM

000040

000000
000 000

Ql0tlllll!50

'1100000
12100 000
000060 000001
001 e00
100200
000070
200 200
000100 00A312

0000H
000 000

000000

~IMITSI

0!5642•
024 13!5
0ei00r110
000 000
00000CIJ
000 000
000036

000000
000 000
000126

000000 • 001177

000000

000 QJ00
000000

N!5,

YW A Alt

000 000

000000
00!0 000

•••
A1

000001
001 000

1(0

000000

00'1;1 000
00ei0u
000 000
00!0360
360 000

000 000
0!5"502
102 13!5

326 001
000000

100200
200 200
000000

170011
011 360
000000

312 0""

000 00C!J
000lfill00

000 000

009' 009'

00~"1!0QI

~oi000e

000 000
000120 000000
0NI! 000
000130 000003
003 000

000 00111
1401'0

000 Ol00

000 000

1
1
ltUV 1
1

000110

000140

0001 !5121

000160
000170

et00200

•••

0~0000

00U60

001720

001750

0!52352
3!52 124

0000~1.'!

136 147
0!52352

Q!00 0QIQI

3!52 12•

0523!52

000000

1700~V1!

352 12•

000 e00
0000011l

000 360

000'1!02

002 000
07U0QI
000 1 71

'2!00'1100
000 000
00011l00
000

~~ltli

012

c MlllR

~Ol0P.ICll!0

3!53 000
000000
0e0 000

000 000
'1100000

P<SM

Pi~@

000246
00001210

001464
M• 01213

~00264

000000

00~~00!

ll!A0001
~"' 1 000

264 "'00

000

A063P3

006101
101 A14
005200
200 11112

020116
\16 0•0
005366
366 012

003367
361 006

02262~
226 0•~

000201

0~000~

000 000

000000

0000H
000 000

2r1 ~00
000000
000 000

000 000

021 1116

"
T

811 1

01 1

SN5'

1V
1
1P

E!5

103402

1(4

TT I
l
A1

x• 1

000002
002 001?!

1BO ABQ EFl!I

4 l

uwe 1
1•

16PA UM

1ADW ~

"''

v co

000000

•••

Figure 9-1 (Cont.)
Sample Post-Mortem Dump

9-5

002 207

1
1

1
1
1

I
I

•••

000 000
~00

00"' 000
000!000
0~ii! 000

000732

0'11"'

Miii~ 1

MiitjR

0003~3

~00~00

I
l(QI

000

,. 11
l
1

10130
130 300

332 001

DUPLICATE Tlo4AOUGM

lTVP TVP 8PO

000 0100

000000
0'1l0 000

0~0

A N64

063536

0000~0

000 000

•••

000000
000 000

000 000
000726
326 0Ql1
0!001201
1ni 0oi0
044400
000 111
o.t0Ql000J
00Cll 000

300 014
001'30 161601
201 343

U1'•0

0~0000

170 3'-'0

DUPL.I CAT! TMAOUGM

0002!50

000 000

CHAPTER 9.
9.2

MEMORY DUMPS

SNAPSHOT DUMP

The task PMD ... is also capable of producing edited dumps for running
tasks. These dumps are called Snapshot Dumps, and they are useful as
debugging aids. A Snapshot Dump may be requested any number of times
during the execution of a task.
The information generated is under
the control of the programmer.
Snapshot Dumps are generated by the following macros:
SNPDF$

Defines offsets in the Snap~hot Dump Control Block
and control bits which control the format of the
dump.

SNPBK$

Allocates the Snapshot Dump Control Block (see
Figure 9-2).

SNAP$

Causes a Snapshot Dump to be generated.

SNPBK$ and SNAP$ issue calls to SNPDF$, so, in most cases, the programmer does not have to explicitly issue the SNPDF$ macro call.

9.2.1

Format of the SNPBK$ Macro

The format of the SNPBK$ macro call is as follows:
SNPBK$

dev,unit,ctl,efn,id,Ll,Hl,L2,H2,L3,H3,L4,H4

where:
dev

Is the 2 character ASCII name of the device to which
the dump is directed.
If it is a directory device,
the UFD [1,4] must be on the volume. The dump will
be written to the disk and then spooled to the line
printer.
If there is no print spooler, the file
will be left on the disk.
If the device is not a
directory device, the dump will go directly to the
device.

unit

Is the unit number of the device to which the dump
is directed.

ctl

Are the flags which control the format of the dump
and the data to be printed. The flags are:
SC.HDR
SC.LUN
SC.OVL
SC.STK
SC.WRD
SC.BYT

Print the dump header.
(Items 1-10 in
Figure 9-1.)
Print information on all assigned LUNs.
(Item 11)
Print information about all loaded overlay segments.
(Item 12)
Print the user stack.
(Item 13)
Print the requested memory in octal words
and RADSO.
(Item 14)
Print the requested memory in octal bytes
and ASCII.
(Item 14)

9-6

CHAPTER 9.

MEMORY DUMPS

ef n

Is the event flag to be used to synchronize the user
program and the task PMD . . . .

Is a number which identifies the Snapshot Dump.
Since
dumps can be requested at different times and under
different conditions, this ID is used to identify the
place or reason for the dump.

Ll,L2
L3,L4

Are the starting addresses of the memory blocks to
be dumped.

Hl,H2,
H3,H4

Are the ending addresses cf the memory blocks to be
dumped.

NOTE
If no memory is to be dumped, each limit
(Ll,L2,L3,L4,Hl,H2,H3,H4) should be zero.
Only one snap block is allowed.
.. SPBK.

It generates the global label
NOTE

Since SNPBK$ is used to allocate storage
for the snap block, all arguments except
dev must be valid arguments for .WORD or
.BYTE directives.

9.2.2

Format of the SNAP$ Macro

The format of the SNAP$ macro is as follows:
SNAP$ ctl,efn,id,Ll,Hl,L2,H2,L3,H3,L4,H4
where:
ctl

Are the flags which control the format of the dump
and the data to be printed.
The flags are:
SC.HDR
SC.LUN
SC.STK
SC.OVL
SC.WRD
SC.BYT

ef n

Print the dump header.
Print information on all assigned LUNs.
Print the user stack.
Print information about all loaded
overlay segments.
Print the requested memory in octal words
and RAD50.
Print the requested memory in octal bytes
and ASCII.

Is the event flag to be used to synchronize the user
program and the task PMD • . . • A wait for single
event flag directive is always generated to perform
synchronization.

9-7

CHAPTER 9.

MEMORY DUMPS

Is a number which identifies the snapshot dump.
Since dumps can be requested at different times
and under different conditions, this ID is used
to identify the place or reason for the dump.

Ll,L2,
L3,L4

Are the starting addresses of memory blocks to
be dumped.

Hl,H2,
H3,H4

Are the ending addresses of memory blocks to be
dumped.
NOTE

If no memory is to be dumped, each limit
(Ll,L2,L3,L4,Hl,H2,H3,H4) should be zero.

The control flags may be set in any combination. They are NOT mutually exclusive. Thus,
any number of options may be obtained; e.g.,
SC.HDR!SC.LUN!SC.WRD will print the header,
LUNs, and the requested memory in word octal
and RADSO mode.

Arguments should only be specified to override
the information already in the snap control
block.

Since SNAP$ generates instructions to move
data into the snap block, its arguments must
be valid source operands for move commands.

9-8

CHAPTER 9.

MEMORY DUMPS

Symbol

Off set

SB.CTL

Control Flags

SB.DEV

Device Mnemonic

SB.UNT

Unit Number

SB.EFN

Event Flag

SB.ID

Snap Identification

(Ll)

Memory Block 1
Limits

(Hl)

(L2)

(H2)

(L3)

(H3)

(L4)

(H4)

SB.LMl

SB.PMD

Description

Memory Block 2
Limits
Memory Block 3
Limits
Memory Block 4
Limits
"PMD ••• " in RAD50

Figure 9~2
Format of Snapshot Dump Control Block

9.2.3

Example of a Snapshot Dump

The sample program shown in Figure 9-3 will cause two Snapshot dumps
to be printed directly on LPO:. The first dump will use the parameters defined in the Snap Control Block. The header will be generated and the data in relative locations BLK to BLK+220 will be displayed in word octal and RAD50. The identification on the dump will
be 1.
The second dump causes the data in the locations BLK to BLK+220 to
be displayed in byte octal and ASCII. A header is also generated.
The dump identification is 64 (100 octal) . Figures 9-4 and 9-5
show the dumps generated by the sample program.

9-9

SNPTST • TEST SNAP DUMP ANO PMO MACRO MXOC
1

•TITLE

SNPTST • TEST SNAP

2
3

.IDE~T

l~tl
S~PBKS,SNAP!,CALL

•

CJ)

000000
e 000036
0000A l

123

116

120

U~4

12"3

00'1HU4

00'0

""d

1--'

.MCALL
SNPBKS

LP,0,SC.HOR&!C,OVL&SC,WR0,1,1,BL~,BLK•22~

RUFI

• UC t Z

/!NPTST/

START I

SNAPS

.EV!N

000046
8 000216
9 000222
U!I 0002'-6

012100

11 000412

000004

8
!:J"
PJ t'rj

0000461

I'd
Ii

l.Q

ANO PMO

8LK1

(I)

OU~P

000036 1

!NAPS

•8UF,R0
J SET BUFFER ADDRESS
SC&T5
I CONVEQT TO RA0~0
•SC.HOR&SC.OVL&SC.RVT,,#100

TOT
.ENO

START

2711JUN•7~

09124

MOV

CALL

;

ABO•H

rt .....
l.Q

l.O

I
1--'
0

() c

PJ Ii

1--' (I)
1--'

"°I

HiW

SNPTST • TEST SNAP DUMP ANO PMO MACRO MX9C
SYMBOL TABt.E

BLI<

0~000!0R

CJ)

8U'

000036R

SB.CTL.•

AOl0CH't0

PJ
""d

!:J"
0

IE. ACh

• ABS,

""d

!RRORS

•••••• GX

S8,0f.V• 000002

SB.EFN• 000006
SB,IO • 0~0010
SS,LMt• 000012
SB,PMO• 000032
S8,UNT• 000!004

000000
00041'
DETECTED I

l"REE CO"EI

000
001
0

6418, WORDS

SNPTST,SNPTST~SNPTST

SC.BVT• 000040

PAGE 1•1

SC• HDSh

~0QIQIPI 1

SC,WRO• 000020
SU~T
000046R

SC,LU~•

0000fll2

SCATO •

SC,OVL• 000004
SC,STI<• 00001 Cil

SOSW

****** GX
• ****** GX

UST2 •

0!~"'~21

•• S~BI<

00000011G

, , , SNP•

000'1132

CHAPTER 9.

MEMORY DUMPS

ID; 64

SNAPSMOT DUMP
TASKS SNPTST

PCt 00t'1724
~E"GS1

• 074400

•

000120

PS •

SP • 00"'312

1100~0

TASK STATUSs

EVENT FLAG MASKSt
CURRENT UICI

<01•16> 000001

<17•32> 056502

<33848>

<49•64~

000~~0

000000

[20~,200]

TI OEVICE • TT101

I/O COUNTI 0,

LOAO DEVICE • sv01

LBNI 0,002265

FLOATING POINT UNIT
STATUS •

.•""
RJ
.•

044400

00~0~0!

000000

01'100~0

~00000

000000

0~0!0Hl!0

000000
000000

~00000

00000~

0~0~~~

Ql00000

0QJ0Cll00
Ql00000

0ei0°'00

000000

~00~00

0"'000~

00~0~0

t?!000Ql0

t'llil000~

00Ql000

OVERLAY SEGMENTS LOADED
STARTING RELATIVE BLOCK1 000002
STAQTING RELATIVE 8LOCK1 ~0000•
TASK

BASEi 000000
8ASE1 P101464

0~0310

001 li'00

045 000

001 000

100 000
P.100 12100

00~3~0

00"'5l'l0
000510
000~20

H0530

000 000
ef 0" 000

006 206
002 ~03
176 317
300 02!

000 000

JJ1 0.t5
346
350

000264

LIMITS1 000312 • 000!32
114
312
0'00
014

120

00!0 000

0~0

1J2 001

000

0G'l0 000
174 263

14!

02~

371 377
005 001
0e1 002

0~0

367

26\ 00!21

001464

IMAGE

PARTITIONa GEN
00e'320
000330

LENGT~t
L~NGTM1

011

046 000
346 03e

317 21121
312 001

'• J z '
LP

1
Jl

' .x
'..
l

Figure 9-4

Sample Snapshot Dump (Words Octal and RADS O)

9-11

CHAPTER 9.

MEMORY DUMPS

SNAPSMOT DUMP

PC1

IOI 1

~0~530

R 1 • 000000

~EGSt

SP • 000:512

PS •

t 70000

TASK STATUS1

EVENT FLAG MASKSt

«01•16> 000001

C17•32> 056502
c•9•6•> 000000

<33•48> 000000

osw 1 t.

CURRENT UICI [2Ql0 1 20et]
l'RIO~ITVI

TI DEVICE

I/O cnuNTI 0,

50,

LOAD OEVICE • sv01

TT10S

L.RNt 0,0A226!

FLOATING POINT UNIT
STATUS •
A0 •

044400

00000411

Rt .. 000000
Q2 • 00et000

0!0~000

000000

000000
000000

000000
00000~

A3 •

0~0000

Q4 •

HH00

00"'
"""
000000

0009100

R! • 000000

000"'00

Q:l00gl00

OVE~LAV

SEGMENT!

0~U00

000000
000000
00000et
000000
0011000
000000

LOAD!O

STARTING RELATIVE 8LOCK1 000002

!USEt 000000

LENGTM I 001464

TASK IMAGE

PARTITIONI GEN

LIMITSI 000312 • 000!5J2

0H310

000A~ 1

00002!

0e011•

000320

000001

00121312

000330
000340

000000
00000~

0A0"01
000000
000000

000000

000000
H0!32
000000

06301•

131674

•A

ll L36
A
F. 8

PMO

'
'

MZ1
I

t t

HOJ!H
000! 10
000520

10300!

022737

177771

H00J4!

&UQ0 FBO

001•02

000261

00040!

177576

0127•6

Ql~U51

016746
10077

I SJ OQ
I !F CTF

'U 01N&

000e;50

012100

H0350

004767

000712

ICS~

9-12

M3 U61'
I(~'

E2 hi 1

Figure 9-5
Sample Snapshot Dump (Bytes Octal and ASCII)

APPENDIX A
ERROR MESSAGES
A.l

TASK BUILDER ERROR MESSAGES

The Task Builder produces diagnostic and fatal error messages.
messages are printed in the following forms:

Error

TKB -- *DIAG*-error-message
or
TKB -- *FATAL*-error-message
Some errors are dependent upon correction from the terminal.
If the
user is entering text at the terminal, a diagnostic error message can
be printed, the error corrected, and the task building sequence
continued.
If the same error is detected by the Task Builder in an
indirect file, the Task Builder cannot request correction and thus the
error is termed fatal and the task build is aborted.
Some diagnostic error messages are simply informative and advise the
user of an unusual condition. If the user considers the condition
normal to his task, he can install and run the task imagee
This appendix tabulates the error messages produced by the Task
Builder.
Most of the error messages are self-explanatory. The Task
Builder prints the text shown in this manual in upper case letters.
In some cases, the Task Builder prints the line in which the error
occurred, so that the user can examine the line which caused the
problem and correct it.

ILLEGAL GET COMMAND LINE ERROR
System error.

(no recovery.)

COMMAND SYNTAX ERROR
invalid-line
The invalid-line printed has incorrect syntax.

REQUIRED INPUT FILE MISSING
At least one input file is required for a task build.

A-1

APPENDIX A.

24.

ERROR MESSAGES

ALLOCATION FAILURE ON FILE file-name
The Task Builder could not acquire sufficient contiguous disk
space to store the task image file.
(If possible, delete
unnecessary files on disk to make more room available.)

25.

I/O ERROR ON OUTPUT FILE file-name
This error may occur on any of the three output files.

26.

LOAD ADDR OUT OF RANGE IN MODULE module-name
An attempt has been made to store data in
outside the address limits of the segment.

27.

the

task

image

TRUNCATION ERROR IN MODULE module-name
An attempt has been made to load a global value greater than
+127 or less than -128 into a byte. The low-order eight bits
are loaded.

28.

nwnber UNDEFINED SYMBOLS SEGMENT seg-narne
The Memory Allocation File lists
segment.

29.

each

undefined

symbol

INVALID KEYWORD IDENTIFIER
invalid-line
The invalid-line printed contains an unrecognizable keyword.

30.

OPTION SYNTAX ERROR
invalid-line
The invalid-line printed contains unrecognizable syntax.

31.

TOO MANY PARAMETERS
invalid- line
The invalid-line printed
parameters than required.

32.

contains

keyword

with

ILLEGAL MULTIPLE PARAMETER SETS
invalid-line
The invalid-line printed contains multiple parameters
keyword which only allows a single parameter.

33.

for

INSUFFICIENT PARAMETERS
invalid-line
The invalid-line contains a keyword with an insufficient
number of parameters to complete the keyword meaning.

A-4

APPENDIX A.

34.

ERROR MESSAGES

TASK HAS ILLEGAL MEMORY LIMITS
attempt has been made to build a task whose
the partition boundary.

35.

size

exceeds

OVERLAY DIRECTIVE HAS NO OPERANDS
invalid-line
All overlay directives except .END require operands.

36.

ILLEGAL OVERLAY DIRECTIVE
invalid-line
The invalid-line printed contains an
directive.

37.

unrecognizable

overlay

OVERLAY DIRECTIVE SYNTAX ERROR
invalid-line
The invalid-line printed contains a syntax error.

38.

ROOT SEGMENT MULTIPLY DEFINED
invalid-line
The invalid-line printed contains the second .ROOT
encountered. Only one .ROOT directive is allowed.

39.

LABEL OR NAME IS MULTIPLY DEFINED
invalid-line
The invalid-line printed contains a name that has
appeared on a .FCTR, .NAME, or .PSECT directive.

40.

directive

already

NO ROOT SEGMENT SPECIFIED
The overlay description did not contain a .ROOT directive.

41.

BLANK P-SECTION NAME IS ILLEGAL
invalid-line
The invalid-line printed contains
does not have a p-section name.

42.

43.

.PSECT

directive

that

The invalid-line printed contains a p-section attribute
is not recognized.

that

ILLEGAL P-SECTION ATTRIBUTE
invalid-line

ILLEGAL OVERLAY DESCRIPTION OPERATOR
invalid-line
The invalid-line printed contains an unrecognizable
in an overlay description.

A-5

operator

APPENDIX A.

44.

ERROR MESSAGES

TOO MANY NESTED .ROOT/.FCTR DIRECTIVES
invalid-line
The invalid-line printed contains a .FCTR
exceeds the maximum nesting level (32).

45.

directive

TOO MANY PARENTHESES LEVELS
invalid-line
The invalid-line printed contains a parenthesis that
the maximum nesting level (32).

46.

that

exceeds

UNBALANCED PARENTHESES
invalid-line
The invalid-line printed contains unbalanced parentheses.

47.

not used.

48.

ILLEGAL LOGICAL UNIT NUMBER
invalid-line
The invalid-line printed contains a device assignment to a
unit number larger than the number of logical units specified
by the UNITS keyword or assumed by default if the UNITS
keyword is not used.

49.

ILLEGAL NUMBER OF LOGICAL UNITS
invalid-line
The invalid-line printed contains a number
greater than 250.

SO.

not used.

51.

not used.

52.

not used.

53.

ILLEGAL DEFAULT PRIORITY SPECIFIED
invalid-line
The invalid-line printed contains
250.

54.

logical

unit

priority

greater

than

ILLEGAL ODT OR TASK VECTOR SIZE
SST vector size specified greater than 32 words.

55.

ILLEGAL FILENAME
invalid-line
The invalid-line printed contains a wild card (*) in
specification. The use of wild cards is prohibited.

A-~

file

APPENDIX A.

ERROR MESSAGES

56.

not used.

57.

LOOKUP FAILURE ON FILE filename
invalid-line
The invalid-line printed contains a filename which cannot
located in the directory.

58.

ILLEGAL DIRECTORY
invalid-line
The invalid-line printed contains an illegal UIC.

59.

INCOMPATIBLE REFERENCE TO A LIBRARY P-SECTION p-sect-name
A task has attempted to reference more storage in a
region than exists in the shared region definition.

60.

shared

ILLEGAL REFERENCE TO LIBRARY P-SECTION p-sect-name
A task has attempted to reference a p-sect-name existing in a
resident library (shared region) but has not named the
library in a COMMON or LIBR keyword.

61.

RESIDENT LIBRARY MEMORY ALLOCATION CONFLICT
keyword-string
One of the following problems has occurred:

62.

More than three shared regions have been specified.

The same shared region has been specified more than once.

Shared regions whose memory allocations overlap have been
specified.

LOOKUP FAILURE RESIDENT LIBRARY FILE
invalid-line
No symbol table or task image
region on SYO under UIC [1,1].

63.

file

found

for

the

INVALID ACCESS TYPE
invalid-line
Requested access to shared region was not RW or RO.

64.

ILLEGAL PARTITION/COMMON BLOCK SPECIFIED
invalid-line
User defined base or length not on 32 word boundary.

A-7

shared

APPENDIX .'A..
65.

ERROR MESSAGES

NO MEMORY AVAILABLE FOR LIBRARY library-name
Insufficient virtual memory available to cover total memory
needed by referenced shared regions (mapped system only).

66.

PIC LIBRARIES MAY NOT REFERENCE OTHER LIBRARIES
invalid-line

67.

ILLEGAL APR RESERVATION
APR specified on COMMON or LIBR keyword that is outside
range 0-7; or APR specified in an unmapped system.

68.

I/O ERROR LIBRARY IMAGE FILE
An I/O error has occurred during an attempt to open
the Task Image File of a shared region.

69.

not used.

70.

not used.

71.

INVALID APR RESERVATION
APR specified on a LIBR or COMMON
library.

7 2.

the

COMPLEX RELOCATION
module-name

keyword

DIVIDE

ERROR

for

read

absolute

ZERO:

MODULE

A divisor having the value zero was detected in a complex
expression.
The result of the divide was set to zero.
(Probable cause- division by an undefined global symbol.)
73.

WORK FILE I/O ERROR
I/O error during an attempt to reference data stored
Task Builder in a work file.

74.

the

LOOKUP FAILURE ON SYSTEM LIBRARY FILE
The
Task
Builder
cannot
find
the
system
Library
(SYO:[l,l]SYSLIB.OLD) file to resolve undafinen syMbols.

7 5.

UNl\BLE TO Ol:'EN woru:< FIL:::
The work file is located on the same device as the Task
Builder.
(Work file device is not mounted or Task Builder
UIC not present on the device.)

76.

NO VIRTUAL MEMORY STORAGE AVAILABLE
Maximum permissible
recovery).

size

A-~

the

work

file

exceeded

(no

APPENDIX A.
77.

ERROR MESSAGES

MODULE module-name NOT IN LIBRARY
The Task Builder could not find the module named
switch in the library.

78.

the

non-Radix-SO

LIBRARY FILE filencuue HAS INCORRECT FORMAT
A module has been requested from a library file that
empty module name table.

80.

82.

has

one

RESIDENT LIBRARY IMAGE HAS INCORRECT FORMAT
invalid-line
The invalid-line specifies a shared region that
the following problems:

81.

INCORRECT LIBRARY MODULE SPECIFICATION
invalid-line
The invalid-line contains a module name with
character.

i9.

has

The library file image has a header.

The library references another library with invalid
address bounds (i.e., not on 4K boundary in a mapped
system).

The library has invalid address bounds.

PARTITION partition-name HAS ILLEGAL MEMORY LIMITS
in the host system
has
with respect to the target

The partition-narr~ defined
incompatible memory limits
system.

The user has attempted to build a privileged
partition whose length exceeds 12K.

task

INVALID PARTITION/COMMON BLOCK SPECIFIED
invalid-line
Partition is invalid for one of the following reasons:
1.

The Task Builder cannot find the partition name
host system in order to get the base and length.

The system is mapped, but the base address of the
partition is not on a 4K boundary for a non-runnable task
or is not 0 for a runnable task.

The memory bounds for
region.

The partition name is identical to the name
previously defined COMMON or LIBR shared region.

the

partition

overlap

the

shared
of

APPENDIX A.

83.

ERROR MESSAGES

The to~ address of the partition for a runnable task
exceeds 32K-32 words for a mapped system or exceeds 28K-l
for an un-rnapped system.

A system-controlled partition
mapped system.

was

specified

for an un-

ABORTED VIA JIBQUEST
input-line
The input-line contains a request from the user to abort
task build.

A.2

the

CROSS REFERENCE ERROR MESSAGES

The following error messages are output by the Cross Reference Task.
Each message is preceded by one of .the following prefixes:
CRF
CRF

*DIAG* - <name of originating task> - MESSAGE
*FATAL* - <name of originating task> - MESSAGE

CREF INPUT FILE <file name> HAS ILLEGAL FORMAT
A premature end-of-file was encountered on the CREF data file.
This problem should be reported to the Digital Software
representative.

FAILED TO DELETE FILE <file name>
Cross reference processor did not have delete privileges.
Verify that the cross-reference task is installed to run
under UIC [10,l].

FILE <file name> NOT FOUND
File <file name> could not be located.

ILLEGAL ERROR/SEVERITY CODE
The occurrence of this error indicates a software malfunction
that should be reported to the Digital Software Representative.

INPUT FROM UNKNOWN TASK
Cross reference processing requested by the originating task
is not supported by CREF.

I/O ERROR ON FILE <file name>
An error has been encountered while reading or writing the
specified file.
A possible hardware problem is indicated;
or the device may have insufficient space to accommodate the
CREF output file.

INVALID OUTPUT FORMAT SPECIFIED
This message indicates an inconsistency in the data file
submitted for CREF processing.
The occurrence of this error
should be reported to your Digital software representative.
A-10

APPENDIX A.
8.

ERROR MESSAGES

NO DYNAMIC STORAGE AVAILABLE
The Cross Reference task requires more working storage than is
available within the area of memory owned by the task.
If
possible, install the task in a larger partition.

NO VIRTUAL MEMORY STORAGE AVAILABLE
The Cross-Reference processor work file storage requirements
exceed 65,536 words. No recovery is possible from this error.

10.

OPEN FAILURE ON FILE <file name>
The Cross-reference processor was unable to open the named
file to append the cross-reference listing. Ensure that
tne cross-reference task is installed to run under UIC
[10,1] to allow unrestricted access to all files.

11.

SYMBOL TABLE SEARCH STACK OVERFLOW
Software error.

12.

Notify the DEC Software Representative.

UNABLE TO OPEN WORKFILE
Possible causes are:
1.
2.

Device not mounted
Device write protected

The workfile device is assigned to LUN 7 and is normally the
device from which CRF was installed.
13.

WORK FILE I/O ERROR
The Cross Reference Processor encountered an I/O error while
reading or writing data on its workfile.
Possible causes:
1.
2.

Device full
Hardware error

A-11

APPENDIX B
TASK BUILDER DATA FORMATS

An object module is the fundamental unit of input to the Task Builder.
Object modules are created by any of the standard language processors
(i.e., ~ACRO=ll, FORTRAN, etc.) or the Task Builder itself (symbol
definition file). The RSX-llM librarian (LBR) provides the ability to
combine a number of object modules together into a single library
file.
An object module consists of variable length records of information
that describe the contents of the module~ Six record (or block) types
are included in the object language. These records guide the Task
Builder in the translation of the object language into a task image.
The six record types are:
Type 1 - Declare Global Symbol Directory (GSD)
Type 2 - End of Global Symbol Directory
Type 3 - Text Information (TXT)
Type 4 - Relocation Directory (RLD)
Type 5 - Internal Symbol Directory (ISD)
Type 6 - End of Module
Each object module must consist of at least five of the record types.
The one record type that is not mandatory is the internal symbol
directory. The appearance of the various record types in an object
module follows a defined format. See Figure B-1.
An object module must begin with

a Declare GSD record and end with an
end-of-module record.
Additional Declare GSD records may occur
anywhere in the file but before an end-of-GSD record.
An end-of-GSD
record must appear before the end-of-module record. At least one
relocation directory record must appear before the first
text

B-1

APPENDIX B.

TASK BUILDER DATA FORMATS

information
record.
Additional
relocation directory and text
information records may appear anywhere in the file.
The internal
symbol directory records may appear anywhere in the file between the
initial declare GSD and end-of-module records.
Object module records are variable length and are identified by a
record type code in the first word of the record. The format of
additional information in the record is dependent upon the record
type.

~-2

APPENDIX B.

TASK BUILDER DATA FORMATS

RLD

Initial GSD
Initial Relocation Directory

GSD

Additional GSD

TXT
TXT
RLD

Text Information
Text Information
Relocation Directory

GSD

Additional GSD

END GSD

End of GSD

ISO

Internal Symbol Directory

ISO
TXT

Internal Symbol Directory
Text Information

TXT
TXT

Text Information
Text Information

GSD

END OF MODULE

END MODULE

Figure B-1
General Object Module Format

B.l

GLOBAL SYMBOL DIRECTORY (GSD)

Global symbol directory records contain all the information necessary
to assign addresses to global symbols and to allocate the memory
required by a task.
GSD records are the only records processed in the first pass, thus
significant time can be saved if all GSD records are placed at the
beginning of a module (i.e., less of the file must be read in phase
3) •

B-3

APPENDIX B.

TASK BUILDER DATA FORMATS

GSD records contain seven types of entries:
Type 0 - Module Name
Type 1 - Control Section Name
Type 2 - Internal Symbol Name
Type 3 - Transfer Address
Type 4 - Global Symbol Name
Type 5 - Program Section Name
Type 6 - Program Version Identification
Each entry type is represented by four words in the GSD record.
The
first two words contain six Radix-SO characters. The third word
contains a flag byte and the entry type identification.
The fourth
word contains additional information about the entry. See Figure B-2.

B-4

APPENDIX B.

TASK BUILDER DATA FORMATS

RECORD
lRAD SOTYPE

= 1

NAME
ENTRY TYPE

FLAGS
l
VALUE
RAD SO
NAME

TYPE

FLAGS

VALUE

RAD50

NAME

TYPE

FLAGS
1
VALUE
RAD50
NAME
FLAGS
VALUE

Figure B-2
GSD Record and Entry Format

B.1.1

Module Name

The module name entry declares the name of the object module.
The
name need not be unique with respect to other object modules (i.e.,
modules are identified by file not module name) but only one such
declaration may occur in any given object module. See Figure B-3.

B-5

APPENDIX B.

TASK BUILDER DATA FORMATS

MODULE
NAME
0

Figure B-3
Module Name Entry Format

B.1.2

Control Section Name

Control sections, which include ASECTs, blank-CSECTS, and named-CSECTs
are supplanted in RSX-llM by PSECTs. For compatibility, the Task
Builder processes ASECTs and both forms of CSECTs.
Section B.1.6
details the entry generated for a PSECT statement. In terms of a
PSECT statement we can define ASECT and CSECT statements as follows:
For a blank CSECT, a PSECT is defined with the following attributes:
.PSECT ,LCL,REL,CON,RW,I,LOW
For a named CSECT, The PSECT definition is:
.PSECT name, GBL,REL,OVR,RW,I,LOW
For an ASECT, The PSECT definition is:
.PSECT .ABS.,GBL,ABS,I,OVR,RW,LOW
ASECTs and CSECTs are processed by the Task Builder as PSECTs with the
fixed attributes defined above.
The entry generated for a control
section is shown in Figure B-4.

CONTROL SECTION
NAME
1

IGNORED
MAXIMUM LENGTH

-"""·-·-·-----------Figure B-4
Control Section Name Entry Format

B-6

APPENDIX B.
B.1.3

TASK BUILDER DATA FORMATS

Internal Symbol Name

The internal symbol name entry declares the name of an internal symbol
(with respect to the module). TKB does not support internal symbol
tables and therefore the detailed format of this entry is not defined
(Figure B-5).
If an internal symbol entry is encountered while
reading the GSD, it is merely ignored.

C_2
t

SYMBOL

_N__._AME_ _
o _
UNDEFINED

Figure B-5
Internal Symbol Name Entry Format

B.1.4

Transfer Address

The transfer address entry declares the transfer address of a module
relative to a P-section. The first two words of the entry define the
naiue of the P=section and the fourth word the relative offset from the
beginning of that P-section. If no transfer address is declared in a
module, a transfer address entry either must not be included in the
GSD or a transfer address of 000001 relative to the default absolute
P-section (. ABS.) must be specified. See Figure B-6.

SYMBOL
NAME
3

I
OFFSET

Figure B-6
Transfer Address Entry Format
NOTE
If the P-section is absolute,
then
OFFSET is the actual
transfer
address
if
not
000001.

B-7

APPENDIX B.
B.1.5

TASK BUILDER DATA FORMATS

Global Symbol Name

The global symbol name entry (Figure B-7) declares either a global
reference or a definition. All definition entries must appear after
the declaration of the P-section under which they are defined and
before the declaration of another P-section. Global references may
appear anywhere within the GSD.
The first two words of the entry define th( name of the global symbol.
The flag byte declares the attributes of the symbol and the fourth
word the value of the symbol relative to the P-section under which it
is defined.
The flag byte of the symbol declaration entry has
assignments.
Bits 0 - 2 - Not used.
Bit 3 - Definition
O = Global symbol references.
1 = Global symbol definition.

Bit 4 - Not used
Bit 5 - Relocation
0

= Absolute symbol value.

1 = Relative symbol value
Bit 6 - 7 - Not used.

SYMBOL
NAME
4

l
VALUE

FLAGS

Figure B-7
Global Symbol Name Entry Format

B-8

the

following

bit

APPENDIX B.
B.1.6

TASK BUILDER DATA FORMATS

Program Section Name

The P-section name entry (Figure B-8) declares the name of a P-section
and its maximum length in the module. It also declares the attributes
of the P-section via the flag byte.
GSD records must be constructed such that once a P-section name has
been declared all global symbol definitions that pertain to that
P-section must appear before another P-section name is declared.
Global symbols are declared via symbol declaration entries. Thus the
normal format is a P-section name followed by zero or more symbol
declarations, followed by another P-section name followed by zero or
more symbol declarations, and so on.
The flag byte
assignments:

the

P-section

entry

has

the

following

bit

Bit 0 - Memory Speed
0 = P-section is to occupy low speed (core) memory.

1 = P-section is to occupy high speed (i.e., MOS/Bipolar) memory.
Bit 1 - Library P-section
0 = Normal P-section.
1 = Relocatable P-section that references a core resident

library

or common block.

Bit 2 - Allocation
0

= P-section

references are
references to the same
allocated to the section.

to be concatenated with
other
P-section to form the total memory

1 = P-section references are to be overlaid.
The total memory
allocated to the P-section is the largest request made by
individual references to the same P-section.
Bit 3 - Not used but reserved.
Bit 4 - Access

O = P-section has read/write access.
1 - P-section has read-only access.
Bit 5 - Relocation
0 = P-section is absolute and requires no relocation.

B-9

APPENDIX B.
l

TASK BUILDER DATA FORMATS

= P-section is relocatable and references to the control section
must
have
absolute.

relocation

bias

added

before

they

become

Bit 6 - Scope
0 = The scope of the P-section is local. References to the same
P-section will be collected only within the segment in which
the P-section is defined.
1

= The scope of the

P-section is global.
References to the
P-section are collected across segment boundaries.
The
segment in which a global P-section is allocated storage is
determined either by the first module that defines the
P-section on a path or by direct placement of a P-section in
a
segment via the Overlay Description Language .PSECT
directive.

Bit 7 - Type
O = The P-section contains instruction (I) references.
1 = The P-section contains data (D) references.

P-SECTION
NAME
5

1
MAX

FLAGS

LENGTH

Figure B-8
P-Section Name Entry Format
NOTE
The length of all
sections is zero.

B.1.7

absolute

Program Version Identification

The program version identification entry (Figure B-9) declares the
version of the module. TKB saves the version identification of the
first module that defines a nonblank version. This identification is
then included on the memory allocation map and is written in the label
block of the task image file.

B-10

APPENDIX B.

TASK BUILDER DATA FOR~TS

The first two words of the entry contains the version identification.
The flag byte and fourth words are not used and contain no meaningful
information.

SYMBOL
NAME
0

6
0

Figure B-9
Program Version Identification Entry Format

B.2

END-OF-GLOBAL-SYMBOL-DIRECTORY

The end-of-global-symbol-directory record (Figure B-10) declares that
no other GSD records are contained further on in the file. Exactly
one end-of-GSD-record must appear in every object module and is one
word in length.

RECORD
TYPE

Figure B-10
End of GSD Record Format

B.3

TEXT INFORMATION

The text information record (Figure B-11) contains a byte string of
information that is to be written directly into the task image file.
The record consists of a load address followed by the byte string.
Text records may contain words and/or bytes of information whose final
contents are yet to be determined. This information will be bound by
a relocation directory record that inunediately follows the text record
(see B.4 below). If the text record does not need modification, then
no relocation directory record is needed. Thus multiple text records
may appear in sequence before a relocation directory record.
The load address of the text record is specified as an offset from the
current P-section base. At least one relocation directory record must
precede the first text record.
This directory must declare the
current P-section.

B-11

APPENDIX B.

TASK BUILDER DATA FORMATS

TKB writes a text record directly into the task image file and
computes the value of the load address minus four. This value is
stored in anticipation of a subsequent relocation directory that
modifies words and/or bytes that are contained in the text record.
When added to a relocation directory displacement byte, this value
yields the address of the word and/or byte to be modified in the task
image.

RECORD
=3
TYPK
LOAD ADDRESS
TEXT
TEXT
TEXT
"
0

"
"

TEXT

Figure B-11
Text Information Record Format

B.4

RELOCATION DIRECTORY

Relocation directory records (Figure B-12) contain the information
necessary to relocate and link a preceding text information record.
Every module must have at least one relocation directory record that
precedes the first text information record. The first record does not
modify a preceding text record, but rather it defines the current
P-section and location. Relocation directory records contain 13 types

B-12

APPENDIX B.

TASK BUILDER DATA FORMATS

of entries. These entries are classified as relocation or location
modification entries. The following types of entries are defined:
Type 1 - Internal Relocation
Type 2 - Global Relocation
Type 3 - Internal Displaced Relocation
Type 4 - Global Displaced Relocation
Type 5 - Global Additive Relocation
Type 6 - Global Additive Displaced Relocation
Type 7 - Location Counter Definition
Type 10 - Location Counter Modification
Type 11 - Program Limits
Type 12 - P-Section Relocation
Type 13 - Not used
Type 14 - P-Section Displaced Relocation
Type 15 - P-Section Additive Relocation
Type 16 - P-Section Additive Displaced Relocation
Type 17 - Complex Relocation
Each type of entry is represented by a command byte (specifies type of
entry and word/byte modification), followed by a displacement byte,
followed by the information required for the particular type of entry.
The displacement byte, when added to the value calculated from the
load address of the previous text information record, (see B.3 above)
yields the virtual address in the image that is to be modified. The
command byte of each entry has the following bit assignments.
Bits O - 6 Specify the type of entry. Potentially 128 command types
may be specified although only 15(decimal) are implemented.
Bit - 7 Modification
O = The command modifies an entire word.

1 = The command modifies only one byte. The Task Builder checks
for truncation errors in byte modification commands.
If
truncation is detected (i.e., the modification value has a
magnitude greater than 255), an error is produced.

B-13

APPENDIX B.

TASK BUILDER DATA FORMATS

RECORD = 4
TYPE

DISP

CMD

INFO

"
"

CMD

INFO

DISP

"
"
"

INFO

"
"

DISP

CMD

INFO

Figure B-12
Relocation Directory Record Format

B-14

APPENDIX B.
B.4.1

TASK BUILDER DATA FORMATS

Internal Relocation

This type of entry (Figure B-13) relocates a direct pointer to an
address within a module. The current P-section base address is added
to a specified constant and the result is written into the task image
file at the calculated address (i.e., displacement byte added to value
calculated from the load address of the previous text block).
Example:
A:

MOV

#A,RO

.WORD

DISP

CONSTANT
Figure B-13
Internal Relocation Command Format

B.4.2

Global Relocation

This type of entry (Figure B-14)

global

symbol.

The

relocates

the result is written into the
address.

task

image

Example.:
MOV

i GLOBAL, RO
or

.WORD

direct

pointer

definition of t.i~e global symbol is obtained and

GLOBAL

DISP

SYMBOL
NAME

Figure B-14
Global Relocation

B-15

file

the

calculated

APPENDIX B.
B.4.3

TASK BUILDER DATA FORMATS

Internal Displaced Relocation

This type of entry (Figure B-15) relocates a relative reference to an
absolute address from within a relocatable control section. The
address plus 2 that the relocated value is to be written into is
subtracted from the specified constant. The result is then written
into the task image file at the calculated address.
Example
CLR

177550
or

MOV

177550.RO
DISP

CONSTANT
Figure B-15
Internal Displaced Relocation

B.4.4

Global Displaced Relocation

This type of entry (Figure B-16) relocates a relative reference to
global symbol.
The definition of the global symbol is obtained and
the address plus 2 that the relocated value is to be written into is
subtracted from the definition value. This value is then written into
the task image file at the calculated address.
Example:
CLR GLOBAL
or
MOV GLOBAL,RO

DISP

Jsl

Figure B-16
Global Displaced Relocation

B-16

APPENDIX B.
B.4.5

TASK BUILDER DATA FORMATS

Global Additive Relocation

This type of entry (Figure B-17) relocates a direct pointer to a
global symbol with an additive constant. The definition of the global
symbol is obtained, the specified constant is added, and the resultant
value is then written into the task image file at the calculated
address.
ExaI11ple:
MOV #GLOBAL+2,RO
V.L.

.WORD GLOBAL-4
DISP

JBJ

SYMBOL
NAME
CONSTANT

Figure B-17
Global Additive Relocation

B.4.6

Global Additive Displaced Relocation

This type of entry (Figure B-18) relocates a relative reference to a
global symbol with an additive constant. The definition of the global
symbol is obtained and the specified constant is added to the
definition value.
The address plus 2 that the relocated value is to
be written into is subtracted from the resultant additive value.
The
resultant value is then written into the task image file at the
calculated address.
Example:
CLR

GLOBAL+2

or
MOV

GLOBAL-5,RO
DISP

lsl

SYMBOL
NAME
CONSTANT
Figure B-18
Global Additive Displaced Relocation
R-17

APPENDIX B.
B.4.7

TASI\ BUILDER DATA FORMATS

Location Counter Definition

This type of entry (Figure B-19) declares a current P-section and
location counter value.
The control base is stored as the current
control section and the current control section base is added to the
specified constant and stored as the current location counter value.

lBl

SECTION
NAME
CONSTANT

Figure B-19
Location Counter Definition
B.4.8

Location Counter Modification

This type of entry (Figure B-20) modifies the current location
counter.
The current P-section base is added to the specified
constant and the result is stored as the current location counter.
Example:
.=.+N

or
.BLKB

CONSTANT

Figure B-20
Location Counter Modification

B-18

APPENDIX B.
B.4.9

TASK BUILDER DATA FORMATS

Program Limits

This type of entry {Figure B-21) is generated by the .LIMIT assembler
directive. The first address above the header (normally the beginning
of the stack) and highest address allocated to the tasks are obtained
and written into the task image file at the calculated address and at
the calculated address plus 2 respectively.
Example:
.LIMIT
11

DISP

Figure B-21
Program Limits
B.4.10

P-Section Relocation

This type of entry (Figure B-22) relocates a

direct pointer to the
beginning adnress of another P-section (other than the P-section in
which the reference is made) within a module.
The current base
address of the specified P-section is obtained and written into the
task i~age file at the calculated address.
Example:
.PSECT

PSECT

c
#B,RO

HOV

or
.WORD

DISP
SECTION

NAME
Figure B-22
P-Section Relocation

B-19

APPENDIX B.

B.4.11

TASK BUILDER DATA FORMATS

P-Section Displaced Relocation

This type of entry (Figure B-23) relocates a relative reference to the
beginning address of another P-section within a module. The current
base address of the specified P-section is obtained and the address
plus 2 that the relocated value is to be written into is subtracted
from the base value. This value is then written into the task image
file at the calculated address.
Example:
.PSECT

.PSECT

MOV

B,RO

DISP

jal

SECTION
NAME

Figure B-23
P-Section Displaced Relocation

B.4.12

P-Section Additive Relocation

The type of entry (Figure B-24) relocates a direct pointer to an
address in another P-section within a module.
The current base
address of the specified P-section is obtained and added to the
specified constant. The result is written into the task image file at
the calculated address.

APPENDIX B.

TASK BUILDER DATA FORMATS

Example:
.PSECT

PSECT
MOV
MOV

iB+lO ,RO
iC,RO

.WORD
.WORD

B+lO
C
DISP

15
SECTION
NAME
CONSTANT

Figure B-24
P-Section Additive Relocation

B.4.13

P-Section Additive Displaced Relocation

This type of entry (Figure B-25) relocates a relative reference to an
address in another P-section within a module.
The current base
address of the specified P-section is obtained and added to the
specified constant. The address plus 2 that the relocated value is to
be written into is subtracted from the resultant additive value. This
value is then written into the task image file at the calculated
address.

B-21

APPENDIX B.

TASK BUILDER DATA FORMATS

Example:
.PSECT

•

• PSECT

MOV
MOV

B+lO,RO
C,RO
DISP

lal

SECTION
NAME
CONSTANT

Figure B-25
P-Section Additive Displaced Relocation

B.4.14

Complex Relocation

This type of entry (Figure B-25A) resolves a complex relocation
expression.
Such an expression is one in which any of the MACR0-11
binary or unary operations are permitted with any type of argument,
regardless of whether the argument is unresolved global, relocatable
to any P-section base,
absolute,
or
a
complex
relocatable
subexpression.
The RLD command word is followed by a string of numerically-specified
operation codes and arguments. All of the operation codes occupy one
byte. The entire RLD command must fit in a single record.
The
following operation codes are defined.
0 - No operation

1 - Addition (+)
2

- Subtraction (-)

3 - Multiplication (*)
4 - Division (/)

B-22

APPENDIX B.

TASK BUILDER DATA FORMATS

5 - Logical AND (&)
6 -

Logical inclusive OR (1)

10 - Negation (-)
11 - Complement (tC)
12 - Store result (conunand termination)

13 - Store result with displaced relocation (command termination)
16 - Fetch global symbol. It is followed by four bytes containing
the syrr~ol nai~e in RADIX-SO representation.
17 - Fetch relocatable value.
It is followed by one
byte
containing the sector number, and two bytes containing the
offset within the sector.
20 - Fetch constant.

It is followed by two bytes

containing

the

constant.
The STORi~ conu~ands indicate that the value is to be written
task image file at the calculated address.

into

the

All operands are evaluated as 16-bit signed quantities using two's
complement arithmetic. The results are equivalent to expressions that
are evaluated internally by the assembler. The following rules are to
be noted.
attempt to divide by zero yields a zero result.
Builder issues a nonfatal diagnostic.

The

task

All results are truncated from the left in order to fit in~o
16 bits.
No diagnostic is issued if the nurriber was too
large. If the result modifies a byte, the Task nuilder
checks for trWLcation errors as described in Section 3.4.

All operations are performed
absolute 16-bit quantities.
the result only.

Example:
.PSECT

ALPHA

.PSECT

BETA

B-23

on relocated (additive) or
PC displacement is applied to

APPENDIX B.

TASK BUILDER DATA FORMATS

MOV

#A+D-Gl/G2&(tC(l77120!G3)),Rl

lBl

DISP

COMPLEX STRING

Figure B-25A
Complex Relocation

B.5

INTF.RNAL SYMBOL DIRECTORY

Internal symbol directory records (Figure B-26) declare definitions of
syrnhols that are local to a module. This feature is not supported by
TKB and therefore a detailed record format is not specified.
If TKB
encounters this type of record, it will ignore it.

RECORD
= 5
TYPE
NOT
SPECIFIED

Figure D-26
Internal Symbol Directory Record Format

B.6

END OF MODULE

The end-of-module record (Figure n-27) declares the end-of-an object
module.
Exactly one end of module record must appear in each ohject
module and is one word in length.
RECORD

TYPE

Figure B-27
End-of-Module Record ~ormat

B-2'1

APPENDIX C
TASK IMAGE FILE STRUCTURE

The task image as it is recorded on the disk appears in Figure C-1.

I AUTOLOAD VECTORS

l
I

CO-TREE OVERLAY

BLOCK
AUTOLOAD VECTORS
CO-TREE ROOT
BLOCK

AUTOLOAD VECTORS
MAIN TREE
OVERLAY
BLOCK
AUTOLOAD VECTORS
SEGMENT TABLES
ROOT SEGMENT
COIJE & DATA
STACK
FP/EA SAVE AREA
HEADER

BLOCK

CHECKPOINT AREA
BLOCK
LABEL

Figure C-1
Task Image on Disk

C-1

APPENDIX C.

C.l

TASK IMAGE FILE STRUCTURE

LABEL BLOCK GROUP

The label block group, shown in Figure C-2, precedes the task on the
disk, and contains data that need not be resident during task
execution, and up to two blocks containing device assignment data for
LUNs 1-255. The task label blocks (first block in group) are read and
verified by Install. The information in these blocks is used to fill
in the task header.

r.-2

APPENDIX C.

LABEL
L$BSTK

Tl,.SK IMAGE FILE STRUCTURE

TASK

NAME

TASK PARTITION

in radix 50 format

L$BFLG

TASK FLAG WORD

L$BPRI

L$BLDZ

LOAD SIZE IN 32-WORD BLOCKS

L$BMXZ

MAX SIZE IN 32-WORD BLOCKS

L$BSA

TASK STARTING ADDRESS

L$BHRB

L$BPAR

TASK PRIORITY

HEADER RELATIVE BLOCK

J..J'i'.D.DJ..Jl\.

.O:.'t

'"'I A

NUMBER OF BLOCKS IN TABLE

L$BXFR

TASK TRANSFER ADDRESS

L$BDAT

YEAR

"f"

l'-T"\T"'\T" T?

L$BLIB

YEAR

CREATION

MONTH

DATE

DAY

LIBRARY/COMMON NAME
IN RADIX 50 FORl".iAT

(32w blks)

LIBRARY LENGTH

CREATION

YEAR

DATE

MONTH
DAY

50
52

three 8
word entries)

STARTING ADDRESS

LIBRARY FLAGS

L$BEXT 116

TASK EXTENSION

Figure C-2
Label Block Group

c-~

{In increments of
32 words)

APPENDIX C.

TASK IHA~E FILE STRUCTtl'Rr
746
750

FILE

752

754
756

FILENAME

760
762

TYPE

764

VERSION

766
770
772

DIRECTORY ID

774

DEVICE NAME

776

UNIT

DEVICE NAME
LUN 1
UNIT NUMBER

.
.
.

LUN
BLOCK
1

DEVICE NAME
LUN 127
UNIT NUMBER

.
-···~_,..,w

DEVICE NAME
LUN 128
UNIT NUMBER

LUN
BLOCK
2

.
.
.
DEVICE NAME
UNIT NUMBER

Fiqure C-2 (Cont.)
Label Block Group

~-4

LUN 255

APPENDIX C.
C.1.1

TASK Il'1AGE FILE STRUCTURE

Label Block Details

The information contained in the label block is verified by the
install t~3k in creating a system task directory entry for the task,
and in linking the task to resident shared regions.
L$BTSK

Task name, consisting of two words in Radix-SO format.
The value of this parameter is set by the TASK keyword.

L$BPAR

Partition name, consisting of two words in
format. Its value is set by the PAR keyword.

L$BFLG

Task flag word containing bit values that are set or
cleared
depending
on
defined
task
attributes.
Attributes are established by appending the appropriate
switches to the task image file specification.
Attribute if Bit=l

Bit
TS$CHK
TS$PRV
TS$ACP
TS$NHD
TS$PIC

6
8

13
14

Radix-SO

Task is non-checkpointable
Task is privilieged
Task is ancillary control processor
Task image does not have header
Task is position independent

L$BPRI

Default priority, set by the PRI keyword.

L$BLDZ

Load size of the task, expressed in multiples of
32-word blocks.
The value of L$BLDZ is equal to the
size of the root segment, in multi-segment tasks.

L$BMXZ

Maximum size of the task, expressed in multiples
32=word blocks. The header size is included.

L$BMXZ is used by Install to verify that the task
into the specified partition.

fits

L$BSA

Starting address of task. Marks the base
the Task image in the addressing space.

L$BHRB

Relative block of the header with respect to the
block in the task file.

L$BBLK

Number of blocks in the Label Block group.

L$BXFR

Transfer address of the task. Used by BOOT to load and
start
a bootable core image;
for example:
the
resident executive.

C-5

address

first

APPENDIX C.
L$BDAT

TASK IMAGE FILE STRUCTURE
Three words, containing the task
2-digit integer values, as follows:

creation

date

YEAR (since 1900)
MONTH OF YEAR
DAY OF MONTH
L$BEXT

Task extension size in 32 word blocks.
The value of
this parameter is set by means of the EXTTSK keyword.

The following paragraphs describe components of the Resident Library
Name Block.
An 8-word block is generated for each Resident Library
referenced by the task. Because shared regions need not be resident
in the system, the Task Builder builds the block from the region's
disk image, using information in the header and label blocks.
Library Name

A 2-word Radix-SO name specified in the LIBR or
keyword.

Length

Length of the shared region in 32 word blocks.
The
INSTALL routine verifies that this value does not
exceed the size of the resident common block area.

Creation Date

Obtained from the creation date in
label block.

the

library

Starting Address First address used to map the Library into
addressing space.

the

COMMON

image
task

Flag Word Bits 2, 14 and 15 are used as follows:
Bit
LD$REL

Value

r-teaning

Library is absolute
Library is PIC
Reserved

C.2

LD$RSV

LD$ACC

0
1

Access request type is Read only
Access request type is Read
Write

HEADER

The task is read into memory starting at the base of the Header.
Since the root segment is a contiguous set of disk blocks it is loaded
with a single disk access. Figure C-3 illustrates the format of the
fixed part, and Figure c-4 the Logical Unit Table. The Floating Point
Save Area is storage for the PDP-11/45 floating point registers when
this option is requested.
The task header starts on a block boundary and is immediately followed
by the task image.
In an unmapped system, the header is fully accessible to the task. In
a mapped system, the Executive copies the header of an active task to
protected memory and restores the header contents when the task is
completed or checkpointed.

C-6

APPENDIX C.

TASK IMAGE FILE STRUCTURE

H.CSP

H.HDLN

LENGTH OF HEADER (bytes)

H.PCBT

TASK PCB

CURRENT STACK POINTER

10
12
H.PCBC

COMMON/LIBR PCB#l

16
20
22
24

COMMON/LIBR PCB#2

30
32
34 I COMMON/LIBR PCB#3
36

40
42
44

END OF PCB DESCRIPTORS

H.DSW

DSW CONTEXT SAVE

H.FCS

FCS CONTEXT SAVE/PTR

H.FOR

FORTRAN OTS CONTEXT SAVE/PTR

H.OVLY

OVERLAY RUNTIME SYSTEM PTR

H.RSVD

RESERVED

Figure C-3
Task Header Fixed Part

C-7

Impure Area
Pointers

APPENDIX C.

H.EFLM

TASK IMAGE FILE STRUCTURE

EVENT FLAG MASK WORD (1-16)

(17-32}

(33-48)

(49-64)

H.CUIC

CURRENT UIC

H.DUIC

DEFAULT UIC

H.IPS

INITIAL PS

H.IPC

INITIAL PC

H.ISP

100

I INITIAL SP

H.ODVA

102

ODT SST VECTOR ADDRESS

H.ODVL

104

ODT SST VECTOR LENGTH

H.TKVA

106

TASK SST VECTOR ADDRESS

H.TKVL

110

TASK SST VECTOR LENGTH

H.PFVA

112

POWER FAIL AST CONTROL BLOCK

H.FPVA

114

FLOATING POINT AST CONT BLK

H.RCVA

116

RECEIVE AST CONTROL BLOCK

120

RESERVED

122

FLOATING POINT/EAE SAVE PTR

124

RESERVED

H.GARD

126

HEADER GUARD WORD POINTER

H.NLUN

130

NUMBERS OF LUNS

H.FPSA

Figure C-3 (Cont.)
Task Header Fixed Part

C-8

APPENDIX C.

TASK IMAGE FILE STRUCTURE

H.LUN

LUN TABLE (2 words/LON)

CURRENT PS
INITIAL VALUES

CURRENT PC

CURRENT R4

relative block
number of header
ident word #2

CURRENT R3

ident word 1tJI.,.....

CURRENT R2

task name word #2

CURRENT Rl

task name word #1

CURRENT RS

pro~ram

transfer
a dress

CURRENT RO
HEADER GUARD WORD

Figure c-4
Task Header Variable Part

C-9

APPENDIX C.

TASK IMAGE FILE STRUCTURE
NOTE

To save the identification, the initial
value set by the Task Builder should be
moved to local storage.
When
the
program is fixed in memory and being
restarted without being re-loaded, it is
necessary to test the reserved program
words for their initial
values
to
determine whether the contents of R3 and
R4 should be saved.
The contents of RO, Rl and R2 are only
set when a debugging aid is present in
the task image.

c.2.1

Low Core Context

The low core context for a task consists of the Directive Status Word
and the Impure Area Pointers.
The Task Builder predefines the
symbolic reference names as follows:
$DSW

Directive Status Word

.FSRPT File Control Services work area and buffer pool
Pointer
$OTSV

FORTRAN OTS work area Pointer

N.OVPT Overlay Runtime System work area Pointer
The only proper reference to these pointers is by symbolic name.
The
pointers are read-only. If they are written into, the result will be
lost on the next context switch.
The Directive Status Word is a one
results of an Executive Directive.

word

The Impure Area Pointers are necessary to
requirements of the associated routines.

C.2.2

area

used

report

the

satisfy

the

re-entrancy

Logical Unit Table Entry

Each entry in the Logical Unit Table has the form shown in Figure c-s.

r-1n

APPENDIX C.

TASK IMAGE FILE STRUCTURE

UCB ADDR
WINDOW BLOCK POINTER

Figure c-s
Logical Unit Table Entry

The first word contains the address of the device unit control block
in
the Executive system tables that contains device dependent
information.
The second word is a pointer to the window
file-structured.

block

the

device

The UCB address is set at install-time if a corresponding ASG
parameter is specified at task-build-time. This word can also be set
at run-time with the Assign Lun Directive to the Executive.
The window block pointer is set when a file is opened on the device
whose UCB address is specified by word l. The window block pointer is
cleared when the file is closed.

C.3

SEGMENT TABLES

The Segment Table contains a segment descriptor for every segment in
the task. The segment descriptor is formatted as shown in Figure C-6.
If the autoload method is used, the segment descriptor is six words in
length.
If the manual load method is used, the segment descriptor is
expanded to be eight words in length to include the segment name.

c-11

APPENDIX C.

TASK IMAGE FILE STRUCTURE

STATUS

lREL. DISK ADDRESS

LOAD ADDRESS
LENGTH IN BYTES
LINK UP
LINK DOWN
LINK NEXT
SEGMENT

I---

NAME

Figure C-6
Segment Descriptor

C.3.1

Status

The status bit is used in the autoload
overlay is in memory, that is:

C.3.2

method

determine

bit 12 = 0

segment is in memory.

bit 12 = 1

segment is not in memory.

Relative Disk Address

Each segment begins on a block boundary and occupies a contiguous disk
area to allow an overlay to be loaded by a single device access. The
relative disk address is the relative block nwnber of the overlay
segment from the start of the task image. The maximum relative block
number can not exceed 4096 since twelve bits are allocated for the
relative disk address.

C.3.3

Load Address

The load address contains the address into which the
overlay segment starts.

C-12

the

APPENDIX C.

C.3.4

TASK IMAGE FILE STRUCTURE

Segment Length

The segment length contains the length of the overlay segment in bytes
and is used to construct the disk read.

C.3.5

Link Up

The link up is a pointer to a segment descriptor away from the root.

C.3.6

Link Down

The link down is a pointer to a segment nearer the root.

C.3.7

Link Next

The link next is a pointer to the adjoining segment descriptor.
When
a segment is leaded, the leading routine follows the link next to
determine if a segment in memory is being overlaid and should
therefore be marked out-of-memory.

The link next pointers are linked in a circular fashion:
Consider the tree:

Af 1 I A2f
I

The segment descriptors are linked in the following way:
A21

~A2
L,

A22

A21
Al

A22

~r
A2

A21~-A22
Al~A2

~r
AO

link up

link down

link next

C-13

APPENDIX C.

TASK IMAGE FILE STRUCTURE

If there is a co-tree, the link next of the segment descriptor for the
root points to the segment descriptor for the root segment of the
co-tree.

C.4

AUTOLOAD VECTORS

Autoload vectors ~ppear in every
entry points in segments that
referencing segment.

segment that references autoload
are farther from the root than the

The autoload vector table consists of one
point in the form shown in Figure C-7.

JSR

entry

per

autoload

entry

PC
$AUTO

SEGMENT DESCRIPTOR ADDR.
ENTRY POINT ADDRESS

Figure C-7
Autoload Vector Entry

C.5

ROOT SEGMENT

The root segment is written as a contiguous number of blocks.
C.6

OVERLAY SEGMENTS

Each overlay segment begins on a block boundary. The relative block
number for the segment is placed in the segment table. Note that a
given overlay segment occupies as many contiguous disk blocks as it
needs to supply its space request - the maximum size for any segment,
including the root, is 32K-32 words.

C-14

APPENDIX D
RESERVED SYMBOLS

Several global symbol and p-section* names are reserved for use by the
Task Builder.
Special handling occurs when a definition of one of
these names is encountered in a task image.
The definition of a reserved global symbol in the root segment causes
a word in the Task Image to be modified with a value calculated by the
Task Builder. The relocated value of the symbol is taken as the
modification address.
The following global sy~bols are reserved by the Task Builder~
GLOBAL
SYMBOL

MODIFICATION
VALUE

• MOLUN

Error message output device •

.NLUNS

The number of logical units used by the task,
including the Message Output and Overlay units.

• NOVLY

The overlay logical unit number •

.NSTBL

The address of the segment description tables.
Note
that this location is modified only when the number of
segments is greater than one.

• TRLUN

The trace subroutine output logical unit number •

• ODTLl

Logical unit number for the ODT terminal device TI: .

• ODTL2

Logical unit number for the ODT line printer device CL: .

* P-sections are created by .ASECT, .CSECT, or .PSECT directives.

not

The
.PSECT directive obviates the need for either the .ASECT or .CSECT
directives, these being retained for compatibility only.
In this
document all sections will be referred to as p-sections unless the
specific characteristics of .ASECTS or .CSECT apply.

D-1

APPENDIX D.

RESERVED SYMBOLS

The definition of a reserved p-section causes that p-section to be
extended if the appropriate option input is specified (see section
3.2.3.4).
The following p-section names are reserved by the Task Builder:
SECTION
NAME

$$DEVT

EXTENSION
LENGTH
The extension length (in bytes) is calculated from
the formula
EXT = <S.FDB+52)*UNITS
Where the definition of s.FDB is obtained from the
root segment symbol table and UNITS is the number
of logical units used by the task, excluding the
Message Output, Overlay , and ODT units.

$$FSR1

The extension of this section is specified by
ACTFIL option input.

the

$$IOB1

The extension of this section is specified by
MAXBUF option input.

the

$$0BF1

FORTRAN OTS uses this area to parse array type
format specifications. May be extended by FMTBUF
keyword.

D-2

APPENDIX E
TAILORING THE TASK BUILDER

There are several ways in which the performance of the Task Builder
can be improved by making use of the resources of a given system.
Like most system programs, the Task Builder is heavily overlaid.
There are two versions of the Task Builder available: BIGTKB, which
occupies more storage and runs faster than TKB and TKB, which has more
overlays, occupies less storage and runs slower.
In order to minimize storage requirements, the Task Builder uses a
work file for storing symbol definitions and other tables. The work
file is organized as a virtual memory file. When tables exceed the
available memory, the information is displaced to the work file and
retrieved when it is required. The work file and the Task Builder
usually exist on the same device, namely: SYO.
The following techniques are available for improving the performance
of the Task Builder based on the resources of the system on which the
Task Builder is to run.
1.

The appropriate version of the Task Builder should be chosen;
that is, one which conserves space or time depending on the
system's requirements.

If a device with a faster response time is
Task Builder should be moved to that device.

If additional memory is available, the Task Builder should be
installed in a larger partition so that it can make use of
the extra memory as dynamic storage.

If two moving head disks are available the Task Builder
should be moved to one disk and the work file to another by
re-assigning LUN 8. There will be less head movement in this
case and the disks can, therefore, respond faster.

available,

the

If the user has the resources to rebuild the Task Builder, he can
alter some parameters at build time which affect the Task Builder's
performance.

E-1

APPENDIX E.

TAILORING THE TASK BUILDER

W$KEXT - defines the number of blocks by which the work file
is extended when an extension is required. If
W$KEXT is increased, the access to the work file
will be faster.

N$MPAG - defines a threshold which determines whether a fast
or slow work file page search is used. The fast
page search saves about 15% of the execution time,
but requires 256 words of the Task Builder's dynamic
storage. This threshold defines the minimum page
storage capacity of dynamic memory required for the
fast search method. It is currently set at 20.

E-2

APPENDIX F
INCLUDING A DEBUGGING AID

If the user wants to include a program which controls the execution of
the task he is building, he can do so by naming the appropriate object
module as an input file and applying the /DA switch.
When such a program is input, the Task Builder causes control
passed to the progra.~ when the task execution is initiated=

Such control programs might trace a task, printing out relevant
debugging information, or monitor the task's performance for analysis.
The switch has the following effect:
1.

The transfer address in the debugging aid overrides the
transfer address.

task

On initial task
indicated value:

the

load,

the

following

registers

RO - Transfer address of task
Rl - Task name in Radix-SO format (word il)
R2 - Task name (word #2)

F-1

have

APPENDIX G
RSX-llM TASK BUILDER GLOSSARY

AUTOLOAD -

The method of loading overlay segments, in
which
the
Overlay
Runtime
System
automatically loads overlay segments when
they are needed and handles any unsuccessful
load requests.

CO-TREE-

An overlay tree whose segments, including the
root segment, are made resident in
memory
through calls to the Overlay Runtime System.

GLOBAL CO~~~ON BLOCK -

An area of memory reserved
library or common block.

for

resident

GLOBAL CROSS REFERENCE - A list of global symbols, in
alphabetical
order, accompanied by the name of each referencing module.
GLOBAL SYMBOL -

A symbol whose definition
the defining module.

known

outside

HOST SYSTEM -

The system on which the task is built.

MAIN PARTITION -

A partition whose memory may be subdivided
into fixed-length sub-partitions or
dynamically allocated
to
each
task by
the
Executive (system-controlled partitions).

MAIN TREE-

An overlay tree whose root segment is loaded
by the Monitor when the task is made active.

MANUAL LOAD -

The method of loading overlay segments
in
which the user includes explicit calls in his
routines to load overlays
and
handles
unsuccessful load requests.

MEMORY ALLOCATION FILE - The output file created by the Task Builder
that describes the allocation of task memory.
OVERLAY DESCRIPTION LANGUAGE - A language that describes
structure of a task.

G-1

the

overlay

APPENDIX G.

RSX-llM TASK BUILDER GLOSSARY

OVERLAY RUNTIME SYSTEM - A set of subroutines linked as part
overlaid task that are called to
segments into memory.

an
load

OVERLAY SEGMENT -

A segment that shares storage with other
segments and is loaded when it is needed.

OVER~YT~E-

A tree structure consisting of a root segment
and optionally one or more overlay segments.

PARTITION -

An area of
of tasks.

PATH -

A route that is traced from one segment in
the overlay tree to another segment in that
tree.

PATH-DOWN -

A path toward the root of the tree.

PATH-UP -

A path away from the root of the tree.

PATH-LOADING -

The technique used by the autoload method to
load all segments on
the path between a
calling segment and a called segment.

PRIVILEGED TASK -

A task that has privileged memory access
rights. A privileged task can access the
Executive and the I/O page in addition to its
own partition and referenced shared regions.

P-SECTION -

A section of memory that is a unit of the
total allocation. A
source
program
is
translated into object modules that consist
of
p-sections with attributes describing
access, allocation, relocatability, etc.

ROOT SEGMENT -

The segment of an overlay tree
loaded,
remains
in
memory
execution of the task.

RUNNABLE TASK -

A task that has a header and stack
can be installed and executed.

SHA~D

REGION -

memory reserved for the execution

that, once
during the
and

that

An area of system memory whose contents
be shared by any number of tasks.

can

SEGMENT -

A group of modules and/or p-sections
that
occupy memory simultaneously and that can be
loaded by a single disk access.

SUB-PARTITION -

A partition
partition.

that

resides

within

main

SYMBOL DEFINITION FILE - The output file created by the Task Builder
that contains the global symbol definitions
and values in a format suitable for reprocessing by the Task
Builder.
Symbol
definition files are used to link tasks to
shared regions.

G-2

APPENDIX G.

RSX-llM TASK BUILDER GLOSSARY

SYSTEM-CONTROLLED PARTITION - A partition whose
memory
may
be
dynamically allocated by the Executive to
several concurrently active, resident tasks.
TARGET SYSTEM -

The system on which the task executes.

TASK IMAGE FILE -

The output file created by the Task Builder
that contains the executable portion of the
task.

USER-CONTROLLED PARTITION - A partition that can
one active, resident task.

G-3

acconunodate

only

APPENDIX H
CROSS REFERENCE PROCESSING AND DATA FORMATS

H.l

CROSS REFERENCE PROCESSOR

The Cross Reference Processor is an independent task that is invoked
by the Task Builder to convert an input file of the specified format
into a cross reference listing that is appended to a text output file.
Input to the cross reference file consists of the following:
. A text file to which the cross reference listing is to be
appended. The file must reside on a random access filestructured device.
. A cross reference input file having the format shown in
Figure H-1. The file is assumed to reside on the same
device and have the same UIC and filename as the text
file.
The input file, however, has an extension of .CRF .

. A "SEND" packet having the format shown in Figure H-2.
Normally the output ri1e will reside on the input device; however, by
means of the appropriate flags within the send packet, the cross reference task can be instructed to dispose of this file in one of the
following ways:
The text file may be submitted to the print symbiont
for output.
The file may be copied to a record-oriented device,
then deleted from the system device.
Requesting a global cross-reference listing via the /CR switch causes
the Task Builder to perform the additional processing outlined below .
. If the output device is sequential; or record-oriented;
i.e., LP:, a temporary memory allocation file is created
on SYO:. The target device and unit are recorded .
. After the memory allocation file has been written, another
pass is made over the object files to create the cross
reference input file.

H-1

APPENDIX H.

CROSS-REFERENCE PROCESSING AND DATA FORMATS

. The SEND packet is always constructed regardless of the
target device. The spooling flag is set if the target
device is a random access device .
. The packet is sent to the cross-reference task .
. The cross reference task is requested to run.

H.2

CREF INPUT FILE FORMAT

The cross-reference input file consists of a single header record
followed by data records as shown in Figure H-1.
The header record consists of the name of the originating task (in
RADIX-50) , followed by a numeric value that identifies the task. The
value is used to access internal cross-reference tables that contain
information describing the CREF output format.
The next 5 words contain the creation time and date for the text
file.
Subsequent data records contain the information used by CRF to create
the body of the listing. The first two words comprise the symbol
name (in RADIX-50).
The second two words consist of information that
identifies the reference.
For a global cross-reference, these words
contain the module name (in RADIX-50).
The symbol value is an octal
quantity associated with the symbol name.
The last word in the data record is subdivided into the attributes
flag byte and the format number byte. The contents of the flag byte
cause specific characters to be printed to the left of each reference,
and within the value field.
For the Task Builder the flags and related symbols are:
Flag

Symbol

Definition
Reference is defined in an overlay segment away
from the root.

200
040

-R

Symbol is relocatable.

020

Module contains an autoloadable definition.

010

Module contains a non-autoloadable definition.

002

Module contains a reference that is resolved
through an autoload vector.

Th~ format byte defines the table to which the data record belongs.
This allows several types of cross-reference listings to be generated
by a single originating task.
The Task Builder always sets this value
to zero. The format number identifies the cross-reference list to which
the data record belongs. Currently, only one type of cross-reference is
created by the Task Builder and the value is always zero.

H-2

APPENDIX H.

CROSS-REFERENCE PROCESSING AND DATA FORMATS

NAUE OF ORIGINATING

TASK (2-WORD RADSO)

I
HEl~DER

ORIGINATING TASK IDENTIFIER

(TKD=O)

CREATION DATE

YEAR

MONTH

CREF INPUT

DAY

FILE

HOUR

RECORD

I
I
~

MINUTE
RESERVED
SYMBOL NAME
( 2 WORD RAD50)

DATA
RECORD

REFERENCE IDENTIFIER
(2

WORDS)

SYMBOL VALUE
FORMAT NUMDER

ATTRIBUTES

DATA RECORDS
TO END-OFFILE

Figure II-1
CREF Input File Format

H-3

---

APPENDIX H.
H.3

CROSS-REFERENCE PROCESSING AND DATA FORMATS

SEND PACKET FORMAT

The format of the send packet is shown in Figure H-2.
of the packet are as follows.

The contents

Words 1 through 10 contain information describing the text output file
name, directory file identification, device name and unit, and a flags
byte. A value of 1 in bit 0 of the flags byte instructs CREF to submit the text file to the print symbiont after processing.
The remaining three ·mrds specify the CREF input data file version
and the device to receive the text output after processing (if a
record-oriented device was specified in the map file portion of the
Task Builder conunand line) .
Using the above information, CREF constructs the data input file name
as follows:
File name:
Version:
Type:
Device:
Directory ID:

Same as text file
As specified
.CRF
Same as text file
Same as text file

H-4

APPENDIX H.

CROSS-REFERENCE PROCESSING AND DATA FORMATS

TEXT FILE NAME
3-WORDS
RAD 50

FILE TYPE
FILE VERSION
WORD 0
DIRECTORY ID

WORD 1

WORD 2
DEVICE NAME

FT"',...
.....
J..ift\Ji:)

II UNIT

CREF FILE VERSION
TARGET DEVICE
RESERVED

UUIT

Figure H-2
Send Packet Format

H-5

APPENDIX H.
H.4

CROSS-REFERENCE PROCESSING AND DATA FORMATS

ADJUSTING THE CROSS-REFERENCE LINE FORMAT

The user may adjust the cross-reference output format for either
132-column or 72-column printers by revising the build file
CRFBLK.CMD under UFD [1,24] (mapped) or [l,20] (unmapped) and rebuilding the task as follows.
To obtain the narrow format (default), the user should edit the build
file and insert a semi-colon in front of the command:
EXTSCT=$$RCB0:204
Conversely, the wide format is obtained by removing the semi-colon
preceding the above command.

H-6

INDEX
ABORT, 3-13
Absolute patch, 3-21
Absolute shared regions, position
independent and, 7-4
ABSPAT, 3-21
AC switch, 3-3
ACTFIL, 3-15, 4-22
Active files, 3-15
Allocation options, 3-10, 3-15
Allocation of p-sections, 4-4
Ancillary control processor
switch, 3-3
Arithmetic element, extended, 3-4
ASG, 3-20
Assignment, device, 3-20
Attributes, p-section, 4-3
Autoload, 1-2, 6-1
Autoload indicator, 6-2
Autoload vectors, 5-14, 6-6, C-14

Building shared region, 7-5
Building task, 2-11, 3-24, 5-16
Building task for target system,
8-1
Buffer size, format, 3-16
Buffer size, maximum record, 3-16

Data formats, task builder, B-1
Debugging aid switch, 3-4, F-1
Defining a multiple tree structure,
5-11
Defining ODL file, 5-15
Default, 2-15
Default assumptions, 2-8
Default type, 2-8
Defaults, 1-1
Device, 2-14
Device assignment, 3-20
Device options, 3-10
Device specifying options; 3-20
Diagnostic, exit on, 3-8
Directive,
. END, 5-7, 5-23
.FCTR, 5-8, 5-23
.NAME, 5-9, 5-24
.PSECT, 5-10, 5-23
. ROOT, 5-7, 5-23
Directory,
end of global symbol, B-11
internal symbol, B-24
relocation, B-12
Directory, global symbol, B-3
Disk address, relative, C-12
Dumps,
post-mortem, 9-1
snapshot, 9-6

CC switch, 3-3
Checkpointable switch, 3-4
Checkpoint area, 4-10
Code, user identification, 2-8
Comma operator, 5-11

EA switch, 3-4
Editor, text, 2-10
.END directive, 5-7, 5-23
End of module, B-24
~-~~--~
1~-~~~~
~-~
..L..LUC::f
Entering source language, 2=10
Commands, 2-1
Error handling, 6-10
task building, 2-12
Error messages,
Comment lines, 2-7
cross-reference, A-10
Comments, 2-7
task builder, A-1
COMMON, 3-18
Existing shared region, 7-3
Common block, resident, 3-18
Exit on disgnostic switch, 3-9
Compiling FORTRAN programs, 2-11
Extended arithmetic element switch,
Complex relocation, B-22
3-4
Concatenated object modules switch, Extend task memory, 3-15
3-3
EXTSCT, 3-17
Content altering options, 3-10
EXTTSK, 3-17
Control option, 3-13
Control section name, B-6
Core image, overlay, 5-13
.FCTR directive, 5-8, 5-23
Co-tree, 5-24
Co-trees, 5-12
File,
Co-tree overlay region, 5-14
memory allocation, 4-10, 4-15
CP switch, 3-4
task image, 4-9
Cross reference switch, 3-4
File contents, 4-19
CR switch, 3-4
Filename, 2-14
File, output, 2-13
File storage region, 4-22
File
specifications, 2-7, 2-14
DA switch, 3-4
~VlLULIO.llU

1...Cl.;::).l'>.f

.,,.-.,,.

INDEX-1

File structure, task image, C-1
Files, memory allocation, 1-2,
5-16, 7-7, 8-3
Floating point switch, 3-5
FMTBUF, 3-16
Format buffer size, 3-16
FORTRAN, 6-8
FORTRAN programs, compiling, 2-11
FP switch, 3-5

Link up, C-13
Load address, C-12
Loading mechanism, 5-4, 6-1
Location counter definition, B-18
Location counter modification, B-18
Logical unit table entry, C-10
Low core context, C-10

Manual load, 1-2, 6-1, 6-6
Manual load calling sequence, 6-7
GBLDEF, 3-21
Manual load request, 6-8
GBLPAT, 3-22
Map, short, 3-8
GDS, 8-3
Mapped and unmapped systems, 4-8
MAXBUF, 3-16
Global additive displaced relocaMaximum record buffer size, 3-16
tion, B-17
Memory,
Global additive relocation, B-17
system, 4-7
Global cross-reference format, H-1
task, 4-1
Global displaced relocation, B-16
Memory allocation, 4-1
Global relative patch, 3-22
Memory allocation file, 1-2, 4-10,
Global relocation, B-15
Global symbol definition, 3-21
4-15, 5-16, 7-7, 8-3
Memory allocation file format, 7-7
Global symbol directory, B-3
Memory dumps, 9-1
Global symbol directory, end of,
B-11
Memory management switch, 1-2, 3-6
Messages, error, A-1
Global symbol name, B-8
MM switch, 3-6
Glossary, G-1
Modifying the task to use the
Group, 2-14
shared region, 7-6
Module, end of, B-24
Module name, B-5
HD switch, 3-5
Module, object, 1-1
Header switch, 3-5, C-6
MP switch, 3-6
Heading, 4-18
Multiple line input, 2-3
Host and target systems, 8-1
Multi-segment task, 5-4, 5-6
Multiple task specification, 2-4
Multiple tree, 5-12
Multiple tree structure, defining
Identification options, 3-12
a, 5-11
Indirect conunand file facility, 2-5 Multiple tree structures, 5-10
Input, multiple line, 2-3
Internal display relocation, B-16
Internal relocation, B-15
Internal symbol directory, B-24
.NAME directive, 5-9, 5-24
Internal symbol name, B-7

Label block, C-5
Label block group, C-2
LB switch, 3-5
LIBR, 3-19
Library file switch, 3-5
Library, resident, 3-19
Library, system, 1-1
Line,
input, 2-13
option, 2-13
task conunand, 2-13
Lines, conunent, 2-7
Link down, C-13
Link next, C-13

Object module, 1-1
Object modules, concatenated, 3-3
ODL, 5-7
ODL file, defining, 5-15
ODT SST vector, 3-23
ODTV, 3-23
Operators, tree structure, 5-22
Option, 2-14
Options, 2-3, 3-10
ABORT, 3-13
ABSPAT, 3-21
ACTFIL, 3-15
allocation, 3-10, 3-15
ASG, 3-20
COMMON, 3-18
INDEX-2

Options (cont.) ,
content altering, 3-10
~~-~~~1

"- u J. J. '"-..L. '-' ..L I

~-1A

~ -

..&...

v I

~-1~

-' -

..L ..J

device, 3-10
device specifying, 3-20
EXTSCT, 3-17
EXTTSK, 3-17
FMTBUF, 3-16
GBLDEF, 3-21
GBLPAT, 3-22
identification, 3-10, 3-13
LIBR, 3-19
MAXBUF, 3-16
ODTV, 3-23
PAR, 3-14
PRI, 3-14
STACK, 3-18
storage altering, 3-21
storage sharing, 3-10, 3-18
synchronous trap, 3-10, 3-23
TASK, 3-14
TSKV, 3-23
UIC, 3-14
UNITS, 3-20
Options, switches and, 3-1
Output file, 2-13
Overlay, 1-2, 5-1
Overlay core image, 5-13
Overlay description switch, 3-6,
5-1
Overlay description language, 5-7,
5-22
Overlay region, co-tree, 5-14
Overlay segments, c-14
Overlay structure, 5-2
Overlay tree, 5-4
Overriding switch, 3-9
Owner, 2-14

PAR, 3-14
Partition, 3-14
Patch, absolute, 3-21
Patch, global relative, 3-22
Path-loading, 6-4
Performance of task builder, E-1
PI switch, 3-7
PM switch, 3-7
Position independent switch, 3-7
Position independent and absolute
shared regions, 7-4
Post mortem dump, 9-1
Post mortem dump switch, 3-7
PR switch, 3-7
PRI, 3-14
Priority, 3-14
Privileged switch, 3-7
Privileged tasks, 4-8
Program limits, B-19
Program section, 4-2
Program section allocation, 4-19
Program section extension, 3-17

Program section name, B-9
Program version identification, B-10
.PSECT directive, 5=10, 5-23
P-section additive displaced
relocation, B-21
P-section additive relocation, B-20
P-section,allocation of, 4-4, 4-5
P-section attributes, 4-3
P-section displaced relocation,
B-20
P-section relocation, B-19
P-sections, 4-2

Rebuilding shared region, 8-2
Rebuilding task for target system,
8-3
Relative disk address, C-12
Relocation,
global, B-15
global additive, B-17
global additive displaced, B-17
global displaced, B-16
internal, B-15
internal displaced, B-16
P-section, B-19
P-section additive, B-20
P-section additive displaced,
complex, B-21, B-22
P-section displaced, B-12
Relocation directory, B-12
Reserved symbols, D-1
Resident common block, 3-18
Resident library, 3-19
Resolution of global symbols, 4-6,
5-4
Resolution of p-sections, 5-6
.ROOT directive, 5-7, 5-23
Root segment, C-14

Segment description, 4-18
Segment length, C-13
Segment tables, C-11
Selective search switch, 3-8
Sequential, 3-8
SH switch, 3-8
Shared region, building, 7-5
Shared region, existing, 7-3
Shared region, modifying the task
to use the, 7-6
Shared region, rebuilding, 8-2
Shared regions, 1-2, 7-1
Shared regions, position independent
and absolute, 7-4
Short map, 3-8
Snapshot dump, 9-6
Source language, entering, 2-10
SP switch, 3-8
Spool map output switch, 3-8
SQ switch, 3-8

INDEX-3

SS switch, 3-8
Task image file structure, C-1
SST vector, task, 3-23
Task memory, 4-1
STACK, 3-18
Task, multi-segment, 5-4, 5-6
Stack size, 3-18
Task specification, multiple, 2-4
Status, C-12
Task SST Vector, 3-23
Storage altering options, 3-21
Text editor, 2-10
Storage sharing options, 3-10, 3-18 Traceable switch, 3-9
Switch, 2-8, 2-14, 3-2
Transfer address, B-7
Switch, overriding, 3-9
Tree structures, multiple, 5-10
Switches,
Tree structure operators, 5-22
AC, 3-3
Tree, overlay, 5-4
cc, 3-3
TSKV, 3-23
CP, 3-4
Type, 2-14
CR, 3-4
Type, default, 2-8
DA, 3-4
EA, 3-4
FP, 3-5
HD, 3-5
UIC, 2-15, 3-14
LB, 3-5
UNITS, 3-20
Unmapped systems, mapped and, 4-8
MM, 3-6
MP, 3-6
User identification code, 2-8,
PI, 3-7
2-15, 3-14
PM, 3-7
PR, 3-7
SH, 3-8
Version, 2-14
SP, 3-8
SQ, 3-8
Version identification program,
SS, 3-8
B-10
TP., 3-9
XT, 3-9
Switches and options, 3-1
XT switch, 3-9
Symbol definition, global, 3-21
Symbol directory, global, B-3
Symbol directory, internal, B-24
Symbol name, global, B-8
Symbol name, internal, B-7
Symbols, reserved, D-1
Symbols, resolution of global, 4-6,
5-4
Synchronous trap options, 3-10,
3-23
Syntax rules, 2-11
System library, 1-1
System memory, 4-7
Systems, host and target, 8-1
Systems, mapped and unmapped, 4-8

Tables, segment, C-11
Target system, building task for,
8-1
Target system, rebuilding task for,
8-3
Target systems, host and, 8-1
TASK, 3-14
Task, building, 2-11, 3-24, 5-16
Task builder data formats, B-1
Task builder, performance of, E-1
Task conunand line, 2-2
Task image, 1-1
Task image file, 4-9

INDEX-4

RSX-llM Task Builder
Reference Manual
DEC-11-0MTBA-B-D

READER'S COMMENTS
NOTE:

This form is for document comments only. Problems
with software should be reported on a Software
Problem Repcrt (SPR) form

Did you find errors in this manual?

If so, specify by page.

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

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

Please indicate the type of user/reader that you most nearly represent.
[] Assembly language programmer
[]

Higher-level language programmer

[] Occasional programmer (experienced)
[] User with little programming experience
[]

Student programmer

[] Non-programmer interested in computer concepts and capabilities

CitY~~~~~~~~~~~~~~State~~~~~~-Zip Code~~~~~~~

or
Country
If you do not require a written reply, please check here.

[]

----------------------------------------------------------Fold llere------------------------------------------------------------

·-----------------------------------------.. - Do Not Tear • Fold llere and Staple -----------------------------------------------

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

)Stage will be paid by:

mnmnamn
Software Communications
P. o. Box F
Maynard, Massachusetts 01754

DIGITAL EQUIPMENT CORPORATION
MAYNARD~ MASSACHUSETTS 01754