901984A_UTS_Overview_And__Tech_Sep73 901984A UTS Overview And Tech Sep73
901984A_UTS_Overview_And__Tech_Sep73 901984A_UTS_Overview_And__Tech_Sep73
User Manual: 901984A_UTS_Overview_And__Tech_Sep73
Open the PDF directly: View PDF 
.
Page Count: 171
| Download | |
| Open PDF In Browser | View PDF |
Xerox Universal Time-Sharing System (UTS)
Sigma :6 /7/9 Compute,.
.'Overvlew and Index
;Technical Manual
9019 i84A
Xerox Corporation
701 South Aviation Boulevard
EI Segundo, California 90245
213679-4511
XEROX
Xerox Universal Time-Sharing System [UTS)
Sigma 6/7/9. Computers .
Overview 'and Index
Technical MCIlual
First Edition
90 19 84A
September 1973
Price: $6.00
© 1973. Xerox Corporation
.
Printed in U.S.A.
NOTICE
This publication provides an overview of UTS and an index to the complete set of UTS technical manuals. The
overview reflects the COl version of UTS. The index reflects the BOl version. However, the index is largely
applicable to the COl version as well.
RELATED PUBLICATIONS
Publication No.
UTS Basic Control and Basic
I/o Technical
90 1985
Manual
UTS System and Memory Management Technical Manual
90 1986
UTS Symbiont and Job Management Technical Manual
90 1987
UTS Operator Communication and Monitor Services Technical Manual
90 19 88
UTS File Management Technical Manual
t
90 1989
UTS Rei iabi lity and Maintainabi I ity Technical Manual
UTS Interrupt Driven Tasks Technical Manual
90 19 90
t
90 19 91
UTS Initialization and Recovery Technical Manual
90 19 92
UTS Command Processors Technical Manual
90 19 93
UTS System Processors Technical Manual
90 19 94
UTS Data Bases Technical Manual'
90 19 95
t
Not published as of the publication data given on the title page of this manual. Refer to the PAL Manual for
current avai lobi lity.
ii
CONTENTS
User State Queues ___________________ 48
Scheduler Operation _ _ _ _ _ _ _ _ __ 50
I/O Scheduling _ _ _ _ _ _ _ _ _ __ 54
Reentrancy _ _ _ _ _ _ _ _ _ _ _ __ 55
Batch Jobs _ _ _ _ _ _ _ _ _ _ _ __ 56
Memory Management ____________
56
Physical Core Allocation _ _ _ _ _ __
57
Job Step Control _ _ _ _ _ _ _ _ _ _ __ 58
Symbionts, Cooperatives, and Multibatch
Scheduling (RBBAT) _ _ _ _ _ _ _ __
61
Symbiont/Cooperatives _ _ _ _ _ _ _ __
61
Multibatch Scheduler _ _ _ _ _ _ _ _ __ 62
Scheduling Algorithm ___________ 63
System Services _ _ _ _ _ _ _ _ _ _ _ __
64
System Initialization _ _ _ _ _ _ _ _ __
64
INITIAL _ _ _ _ _ _ _ _ _ _ __ 65
BOOTSUBR _ _ _ _ _ _ _ _ _ __ 68
GHOST1 _ _ _ _ _ _ _ _ _ __
69
Operator Communications
73
Accounting and Performance Monitoring__ 74
Automatic Recovery
75
System Debugging
77
Error Logging, Diagnostic Device Access_ 78
User Service
79
File Management
79
Load-and-Link Command
80
Batch Debugging
81
INTRODUCTION
The UTS Operating System _ _ _ _ _ _ _ __
Salient Characteristics _ _ _ _ _ _ _ __
Lineage _ _ _ _ _ _ _ _ _ _ _ _ __
Typical Hardware _ _ _ _ _ _ _ _ _ _ __
CONCEPTS
2
4
5
7
8
Jobs ____________________ 8
User _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 9
User Number _ _ _ _ _ _ _ _ _ _ _ _ _ _ 9
User ID _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 9
Job Step _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 9
Virtual Memory _ _ _ _ _ _ _ _ _ _ _ _ _ 10
JITs _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 12
Shared Programs _ _ _ _ _ _ _ _ _ _ _ _ 13
Public Programs _ _ _ _ _ _ _ _ _ _ _ _ _ 14
Fi I es and Accounts
15
Star Files _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 15
Libraries _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 17
UTS Structures _ _ _ _ _ _ _ _ _ _ _ _ _ 18
Logical Structure _ _ _ _ _ _ _ _ _ _ _ 19
. 20'
Dynamic Structure
Slave Level
20
Monitor Service Level
20
Schedul ing Level
20
MONITOR PHYSICAL STRUCTURE,
CORE, SWAP, RAD, FILE, and SYSTEM TAPE
LAYOUTS
Core Memory _ _ _ _ _ _ _ _ _ _ _ _ _ _
System Residence and Swapping RAD ______
System Storage
Swapping Storage _ _ _ _ _ _ _ _ _ _ _
Symbionts and Files _ _ _ _ _ _ _ _ _ _ _
File Structure
System PO Tape Contents
Root Size
Resident Table Sizes _-'--_ _-~~---Typical Contents of UTS in Loadirig'Order _ __
Differences Between a Large and MiQimum
Resident Monitor ________________
Monitor Size Increases D~e to SYSGEN
Parameters _______________
Monitor Modules..,..:-_ _ _ _ _ _ _ _ _ _ _ _
Utility Processors~.,---_ _ _---'-_ _ _ _ _ _ _
BPM!UTS Equivalent Modules
22
22
24
24
28
29
30
33
83
85
86
87
88
89
91
99
100
UTS PROCESSORS
MONITOR FUNCTIONAL STRUCTURE
Basic I/o System _ _ _ _ _ _ _ _ _ _ _ _
I/o Queuing and Device Handlers
Logical I/O Channels
System Flow
Terminal I/O (COC)
System Management
Schedul ing and Swapping
Scheduler Inputs
Scheduler Output
Executive Language Processors _ _ _ _ _ _ _ _
LOGON
Terminal Executive Language
Contro I Card Interpreter
System Management Processors
Super
Control
RATES
35
36
36
38
40
42
44
44
44
45
F~RGE
FILL
ERR: LIST
ERR:SUM
iii
102
102
103
103
105
105
105
105
1M
106
107
107
Language Processors
Execution Control Processors
Link
Load
Delta
FORTRAN Debug Package
Utility Processors
Edit
Peripheral Conversion Language
Sort/Merge
1400 Series Simulator
SYSGEN
DEFCOM
108
108
108
108
109
110
110
110
111
111
112
113
113
SYMCON
ANALZ
BATCH
LABEL
DRSP
INDEX to UTS TECHNICAL MANUALS
Key to Index
Index by Item
Index by Module
iv
113
114
114
115
115
116
116
117
159
UTS TECHNICAL MANUAL
SECTION BA
1/12/73
l'AGE
1
INTRODUCTION
This document is designed to give the technically-oriented reader,
who is assumed to have a general knowledge of large computer
operating systems, an overview of UTS. It is assumed that the
reader is familiar with the use of the system, knowing both the
kinds of service which are provided and the language elements
which the user uses to request these services. He should come
away from the reading with a general knowledge of how UTS
accomplishes the various requests made of it. He should also come
away with an idea of .the parts into which the system is divided,
both functionally and physically. Finally, he should be able to
understand where to look, both in the technical documentation and
in the listing of the code itself, when there is a need" for more
detailed ~nowledge.
.
As can be seen from the table of contents, this overview comprises
six major sections:
The introductory section (of which this paragraph is a part)
skims lightly over the system as a whole describing the
services it provides, the salient characteristic of its
implementation, the operating systems on which it is hased,
and the hardware which is required for operation.
The second section describes the concepts fundamental to UTS
operation.
It introduces some of the vocabulary
used
throughout the technical documentation of the system.
In section three are gathered descriptions of how UTS formats
all the storage elements under its control: core memory in
both physical and virtual forms, secondary storage used for
UTS residence and user swapping space, RAD and disc storage
used for files of stored data, and the contents of the source
system tape are included.
Section four divides the system into functional groupings and
describes the general techniques used to accomplish those
functions.
Section five reviews the functional structure of section four
giving module-by-module names, sizes, and description of
function performed.
Finally, in section six, the processors which, together with
the UTS monitor, make up the total system are functionally
reviewed.
UTS TECHNICAL MANUAL
SECTION BA
1/12/73
PAGE
2
The UTS Operating System
UTS is a multiple-user Sigma 6/7/9 operating system providing
service for a maximum of 50-200 concurrent on-line terminals (a
physical limitation of 512 lines is imposed by the hardware;
system logic limits the number of concurrent terminals to 250,
response and throughput impose a practical limit of 50-200
terminals
depending
on
the
load
sUbmitted)
and
full
multiprogrammed batch processing services with full resource
control.
It includes BPM-compatible management of consecutive-,
key-indexed (ISAM-like), and random (direct) files (on either
fixed-head disc (RAD) , disk pack, or magnetic tape). These files
are use-protected by password and access designation. A symbiont
(spooling)
system
services the low-speed peripherals (card
equipment and line printers) asynchronously with other
CPU
functions to buffer I/O to and from secondary storage.
Central to the operation of the system is the secondary storage,
used for monitor and processor residence, symbiont buffers,
swapping, and user information files.
Users at the terminals may create, modify, compile, execute, and
symbolically debug programs on-line in BASIC, FORTRAN, COBOL,
METASY~mOL, and other languages.
Through terminal batch entry the
user
may
submit
tasks to batch processing, where COBOL,
SORT/MERGE, MANAGE, and other processors are available.
Any
program may be run in either on-line or batch environments:
Memory mapping allows reentrant processors (which may be overlaid
and may contain initial data areas) to be shared by terminal and
batch users. Other shared processors of UTS are EDIT (a context
editor), DELTA (a DDT-like machine-language debugger), FDP (a
FORTRAN debugging package), a program loader and link-editor, PCL
(a device-to-device transmission and conversion program), and both
batch and on-line executive-level command processors. The system
can easily admit additional shared processors for other languages
or for specialized user services added at each installation.
Batch jobs may be inserted either at the central site, from
remote
batch terminals, or from on-line consoles.
On-line
terminals make use of the output printers and punches via the
symbiont mechanism; they may also access tape drives and private
disk packs.
2
UTS TECHNICAL MANUAL
SECTION BA
1/12/73
PAGE
3
Map access controls and write locks secure the system from its
users and the users from one another. Through the map the full
virtual address range is available for user programs,
I/O
buffering, shared libraries, and the operating system on machines
with less than maximum memory. Multilevel queue scheduling for
execution and swapping assures rapid response and overlap of
computation with file I/O swapping.
The map makes possible
multiple user programs and shared processors in core, which
contributes to efficient operation through the overlap of CPU
execution with I/O. The map obviates the need for core shuffling
or compaction.
A comprehensive performance monitoring facility which instruments
and displays a wide variety of internal counts and timings allows
an installation manager to examine current operation and adjust
system performance.
Continuous operation is maintained by automatic error detection,
reporting, and recovery.
System
recovery,
which
includes
automatic failure analysis, maintains integrity of user files
while providing automatic restart within one to three minutes.
Printers, punches, card readers, and tapes are maintained with
time-shared diagnostics duri~g system operation. System services
allow on-line diagnostic programs for
maintenance
of
all
peripheral devices concurrent with system operation.
UTS is delivered as a package which includes the following:
1.
An operational system tape for a standard configuration.
2.
A tape containing compressed decks, symbolic updates, and
binary versions of each system module.
3.
Tapes containing symbolic, binary, and object modules for the
following language processors: BASIC, ~mTASYM OL, FORTRAN
IV, SORT/~mRGE, the Extended FORTRAN IV Library, ANS COBOL,
and 1401 Simulator.
q.
A full set of user and operations manuals for the system
language processors.
5.
A
set
of
test
cases
to exercise and verify proper system
operat~on.
b.
A
de~ivery
and
document (-11 or -61) describing it all.
3
UTS TECHNICAL
SECTION BA
1/12/73
PAGE
4
~mNUAL
Salient Characteristics
Some especially
following:
noteworthy
characteristics
of
UTS
are
the
1.
Full
use
of hardware page mapping (equivalent
to a
relocation register per page) to provide for location of a
user's program and data in an arbitrary set of physical core
pages (512 words each).
This makes it possible for a
variable number of different sized program partitions to be
concurrently resident in core memory and for the number and
size of partitions to vary dynamically from moment-to-moment.
2.
Use of the map to share the code portions of reentrant
processors among concurrent users with attendant savings in
core requirements and associated overhead.
3.
Division of all programs into procedure and data areas
separately protected with execute-only and read/write access
codes.
Access codes and write locks are used to protect
users from another, to protect the system code from the user,
and to prevent the system from writing in its own procedure
area.
4.
Identical treatment at the execution level of batch and
on-line programs, which provides for multiprogramming of
batch programs and of batch with on-line, and for file
sharing between batch on-line programs.
5.
Swapping of user programs as a whole (rather than demand
paging) as regulated "by the swap scheduling algorithm.
Unmodified pure procedure is never swapped out.
6.
A multi-level queue scheduling discipline, which provides a
cornmon
algorithm
controlling
both execution and swap
scheduling and which allows separate scheduling of terminal
I/O, file I/O, interactive CPU requests, batch/compute-bound
execution, and other special situations. Terminal I/O, for
example, has a higher priority than file I/O or compute-bound
execution.
7.
Full overlapping of user and swap I/O with CPU execution
through scheduling, provided that there is enough core in
which to do the overlapping.
8.
Complete automatic recovery system with primary attention to
preservation of user files provides fast restart following
hardware malfunction.
4
UTS TECHNICAL }1ANUAL
SECTION BA
1/12/73
PAGE
5
9.
Ability to create an installation-specific command processor
to efficiently pass control to a subsystem and field all
exits, errors, etc.
10.
On-line
diagnostics for card
printers, tapes, and disk packs.
11.
A comprehensive file management system which
organizations:
reader,
card
punch,
includes
line
three
Random (direct)
Contiguous pre-allocated set of 512-word granules accessed by
relative granule number. Content is managed entirely by the
user program.
Consecutive
A collection of variable length logical records physically
blocked into granules by the system. Access is tape-like:
sequential, forward, reverse or spacing.
Allocation is
dynamically limited only by the size of physical devices on
the system.
Key-indexed
(ISru~-like)
Collection of variable length logical records each of which
has an associated key (name). Access is either by key or
sequentially or a mixture. A tiered tree index provides for
fast access by key to any record. Allocation is dynamically
limited only by the size of physical devices on the system.
Lineage
UTS is the latest member of a family of operating systems, or
monitors, for the XEROX 6/7/9 line of computers. Because each is
built upon its predecessor, each takes advantage of much of the
experienced code of the preceding systems.
From time to time
portions of the monitor are rewritten to add facility, improve
performance, enhance maintainability, reduce size,
or
some
combinations of these. When this happens the common line makes it
possible to apply the improvement to all monitors in the line.
Broad-brush characteristics of each system are given below.
5
_lIl'S TECHNICAL MANUAL
SECTION BA
1/12/73
PAGE
6
BCM, the Basic Control Monitor, provides device handlers for XEROX
peripheral devices and
an
I/O
enqueueing
routine
which
synchronizes requests and provides for error recovery.
Two
monitor families distinguished by their file management systems,
arose from this common ancestor.
RBM, the Real-time Batch Monitor, added simple job scheduling for
batch jobs, and a basic file management system as well as
real-time services.
A new version of the I/O queueing routines
and device handlers were
added
which
improved
real-time
performance.
They also replaced their counterparts in BPM, BTM,
and UTS.' n
BPM, the Batch Processing Monitor, is a major full-service
operating system for a single stream of batch jobs. Real-time
services allow concurrent process control and other high response
needs.
Symbionts
concurrently
spool
card-to-disk
and
disk-to-printer or punch.
A full file management system is
included with access methods for consecutive files, indexed
sequential files (called KEYED), and pre-allocated direct files
(called RANDOM).
A Control Command Interpreter (CCI) processes
the job control language to allow the user to call processors for
compilation, assembly, loading, and execution, and to assign
logical I/O units (DCBs) to physical devices or files on RAD or
disk pack.
BTM, the Batch Timesharing Monitor, added to the full BPM batch
service a single fixed partition of memory for terminal users.
Editing, debugging, and various interactive languages serve the
terminal user through a terminal command language. Since BTM does
not make use of the memory map, it may be used on Sigma 5,. 6, 7,
8, or 9 computers. It is limited by its two partition design.
UTS utilizes the hardware memory map to provide for a variable
number of variable-sized memory partitions that do not require
relocation after being moved into physical memory. Having several
user programs in core increases the probability that the system
can find concurrent'computing to overlap with swapping and file
I/O. The map also makes it possible to share the code portions of
processors (e.g., BASIC, FORTRAN) in concurrent use. Because the
executing partitions need not be confined to on-line users, UTS
contains ~ basic multiprogramming facility for batch jobs. Up to
1'6 simultaneous batch streams are multiprogr::ammed with full
control over physical resources, such as tapes, to prevent
inter-job lockup.
New and improved processors for
on-line
interactive use are provided in UTS.
6
UTS TECHNICAL MANUAL
SECTION BA
1/12/73
PAGE
Typical Hardware
A typical UTS hardware configuration would include the following:
Sigma 6/7/9 CPU with 256-page map
64K-128K word core memory
High speed swapping RAD
File RAD and/or disk pack
Tape units
Card punch, card reader, line printer
Operator's console
8 - 512 teletype, typewriter, or CRT terminals
7
7
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
8
CONCEPTS
Jobs
-The
UTS scheduling unit is the JOB or USER
(see below).
As each
terminal user calls up or as a batch job is selected for execution,
the job becomes active. For each active job, UTS maintains in core
records in the form of user-associated tables that allow the job to
be scheduled and swapped. Also, associated with each active job is
a Job Information Table (JIT) which is the first page of each job both in core and on the swapping RAD.
It contains accounting
information,
memory
map,
swap storage addresses, and other
information.
There are three kinds of jobs in UTS: BATCH, ON-LINE, and GHOST.
Batch jobs arrive via the input symbiont from a local card reader, a
remote card reader, or an on-line terminal. They may be scheduled
in the same way as on-line jobs, or in other ways, at the discretion
of the system manager. The Control Command Interpreter (CCI) is the
shared processor thAt reads and acts upon the control command stream
(!commands) for batch jobs.
On-line jobs are terminal-initiated and generally assume interaction
with a user at a keyboard-type device. The Terminal Executive
Language (TEL) processor handles control commands for on-line jobs.
Additionally, a user may build his awn command processor.
Ghost jobs are operator- or progra~initiated by naming the program
load module to be "forked" to and do not have card or terminal input
streams, although they may read command files or take commands from
the operator's console.
Ghost jobs are used in UTS for the
following: initialization, operator key-in commands, file backUp,
hardware error log processing, certain diagnostics, performance
monitoring, secondary storage (file space) granule allocation,
multibatch
scheduling,
and
remote batch and input symbiont
processing.
8
~
TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
9
User, User Number, User 10
The term USER is often used to describe a UTS job.
Users are
either terminal users, batch jobs, or ghost jobs. Each user is
assigned a unique humber at job entry which is carried in his JIT,
printed on terminal page headings, and listed
with
every
user-associated message that is typed at the operator's console.
The number is also referred to as the user 10 (or system ID)
and
is used by the operator to send messages, to abort or otherwise
affect the user's job. A different, but associated value, user
number, is used to index scheduler control tables when jobs are
active.
Job Step
Each job, whether under terminal control or submitted through the
batch stream, is divided into a set of sequential increments
called job steps. For example, a FORTRAN compile and execute job
divides into three job steps: a compilation, a load operation, and
the execution.
Common information carried across all steps is the accounting and
limit information carried in JIT (CPU time, elapsed time, pages
out, cards in, tapes used, RAn space accumulated, etc.), and DCR
assignment information carried in a special RAD record called the
ASSIGN/MERGE
record.
The
latter
is the accumulation of
information from all the ASSIGN cards or SET commands which have
occurred previously in the job stream.
At each job step, control returns to the user's associated command
processor.
For batch jobs, all control cards occur between job
steps and are read by CCI. For on-line, TEL reads and acts on all
commands issued to it between steps and, in certain cases, during
interruptions within job steps.
At the end of each job step, the user's core memory areas are
released to the system's common pool, as are the corresponding
spaces on the swap device.
Thus, only the JIT accounting
information, COOP buffers, and the DCB ASSIGN/MERGE records
(plus
files created by the steps) are carried from step to step.
9
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
10
Virtual Memory
Virtual memory is the logical memory seen by the user or other
mapped program running under UTS. Instruction addresses of the
program are virtual memory addresses. During program execution a
hardware map register relates each virtual memory page (user
addresses)
to a page in real physical core memory. UTS keeps
track of physical memory and assigns it as appropriate to
individual
users by establishing the contents of the map.
Physical pages are associated on user program request either for
an explicit page or implicitly when a program is called for and
requires memory for residence. Unassigned pages are filled with
the physical page address of a write-protected monitor page. This
protects the system from erroneous references in master-mapped
routines.
The map frees the monitor to choose any physical page to satisfy a
request for virtual space at a g1ven location.
Thus, programs
rema1n at the same virtual (logical) location and requirement for
moving programs in core and relocating them are removed.
A
program may be placed in any available collection of physical
memory pages.
also permits sharing of the pure program procedure
portions of commonly used system processors.
(It is also possible
to share data areas but this feature is only used for monitor
data.) Programs requesting shared processors are connected via
the map to a single in-core copy.
Separate data areas are
provided for each instance of execution of a shared processor.
Programs which do not modify themselves may be shared in this
map-reentrant way by separating them into data and pure procedure
sections.
~mpping
UTS takes full advantage of the extended memory capabilities
offered with'the Sigma 9, and may use up to 512K words to hold the
monitor and user programs. User program area size may be as large
as 64K and additionally have up to 12K of context area.
UTS has over 40 shared processors including ordinary shared
processors, their overlays, monitor overlays, shared command
processors, a shared debugger, and shared run-time libraries.
Shared processors may be added or replaced during system operation
by use of the processor DRSP.
Figure BB-1 shows how several users, each with his own virtual
memory, might be mapped when they are all in the same physical
core.
10
UTS TECHNICAL MANUAL
SECTION 88
J/12/73
Figure 88-1 - Relation of Several Users l Virtual Memory
to the Sigma Physical Iv\emory
Monitor
Overlay JIT
Virtual Mernor
User 1
DeB
PAGE
11
Data
Shared Processor
Physical Memory
Vi rtua I Memoryr-----r----;f~-",------+-~-+-~I..---+----~-+----------,
User 2
-.
~
I.
User 3
•
•
•
!
I
T.'. fI
User n
J is the physical JIT for unmapped programs.
Map cell s for:
Virtual Pages not used are set to X l 20 1 i
Vi rtual Pages assigned a swap image but not yet a
core page contain X1221.
11
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
12
Each user has a separate JIT, DCBs, Data, and other memory areas
which are private to him and his execution. User 1 and User 2
share a single processor as indicated by the fact that their maps
point to the same places in physical memory. Similarly, User 1
and User 3 share a single monitor overlay. User n has his own
private program resident in the same virtual space which Users 1
and 2 are using for a shared processor.
JITs
The Job Information Table (JIT)
is the central record keeping
place
for
information
related
to
each job.
Accounting
information, the memory map image, disc addresses for the job's
image on swap image on swap device, the I/O command chain used for
swapping, a DCB for terminal use (H:UC) and one for miscellaneous
functions (M:XX), control command buffers, and the user-related
push stack are some of the important elements stored in this
table.
JIT is mapped. The CPU accounting clock ticks subjectively into
one user's JIT or another depending on how the map is set. The
monitor pushes temporary data into a user-related stack depending
on how the map is set. In fact, much of the monitor, the file
system for example, need not be and is not aware of which user it
is working for, rather it is mapped to the appropriate user via
the hardware ~ap.
A master JIT exists
virtual space where
unmapped programs,
for example.
All
therefore, recorded
in the physical space corresponding to the
all JITS are located. This JIT is used by all
the symbiont system, and interrupt processing,
CPU accounting for symbiont operation is,
in the master JIT.
Each user is assigned a JIT in order to create the job. Depending
on the source of the job, a JIT may be created which is
appropriate to 1) an on-line, 2) a batch, or 3) a ghost program.
The JIT for KEYIN, the operator's command language, holds in its
push stack the entire program for KEYIN operation: a call for the
KEYIN overlay and a self-destructive exit.
The JIT disc address is the scheduler's "handle" which allows
retrieval of the job when needed from the swap device.
This
address
is
kept in a core-resident table along with the
job-scheduling information.
12
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
13
Shared Programs
There are six distinct kinds of shared programs in UTS:
1.
Ordinary shared processors (FORTRAN, BASIC, PCL, LOAD)
2.
Overlays of the ordinary shared processors
3.
Special shared processors (TEL, LINK)
4.
Shared debuggers (DELTA)
5.
Public libraries (FORTRAN run-time library, FDP)
6.
Monitor overlays (OPEN, labeled tape routines, KEYIN)
Ordinary shared processors occupy the same virtual memory as user
programs. Special shared processors, shared debuggers, and public
libraries occupy (and are overlaid in) dedicated high virtual
memory and may be associated with user programs or ordinary shared
processors.
The processors CCI, TEL, and LOGON which require
store access to JIT are granted that special privilege.
Although user programs may have large complex tree structures in
both data and procedure sections, ordinary shared processors are
restricted to a single overlay level in the procedure area only.
However, they may have any number of overlays within that level.
All changeable data must be in the root segment (unlike the
overlays of unshared programs, which may have data in the
overlays). Data is initialized at the same time the shared
processor is called, and thereafter is associated with each user
of that processor and swapped in and out with him.
Shared processors
overlays.
of
other
than
ordinary
type
may
not
have
Shared processors are not limited to programs provided by XEROX.
The facilities may be effectively used whenever a program has a
high probability of common usage. Service bureaus, for example,
may use the mechanism for proprietary packages, and corporate
installations may use it for programs with a high frequency of
use.
13
UTS TECHNICAL
SECTION BB
~~NUAL
1/12/73
PAGE
14
UTS processors may be shared processors when they are named during
SYSGEN and contain shareable pure procedure (reentrant code) or
when they are added during system operation using the program
DRSP. Data areas of the processor which will be user-associated
are initialized at first entry.
A shared processor has the
following special charastics:
1.
Its name is known to the system at SYSGEN time or provided by
DRSP and is stored in resident tables.
2.
It has dedicated residency on swap
system initialization or by DRSP.
3.
A single copy of
requesting users.
the
pure
storage
procedure
is
established
shared
at
by all
Any program which meets the restrictions may be established as a
shared processor by naming it at SYSGEN, which causes the file
, copy of the program from the :SYS account to be written on the
swapping RAD and its name placed in shared processor tables in
resident monitor core during system initialization.
The program
is
then
available
through high-speed swapping I/O.
DRSP
accomplishes a similar task during system operation.
The file copy of the program is retained for recovery purposes and
may be run as an unshared program under DELTA for development and
debugging purposes.
If the load module in the :SYS account is
replaced, the shared copy of the program on the swapping device is
updated to the newer version in the event of a system recovery.
Public Programs
A program whose load module is in the :SYS account is a public
program in the sense that it may be called either by a control
card containing the ! symbOl and the program name or by entry of
the program name in response to a TEL prompt (!) for commands.
Each user of a public program has his own copy of the program. If
a program name refers both to a shared processor and to a load
module in :SYS, then the shared copy is used.
14
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
15
Files and Accounts
Upon the basic physical I/O management routines of UTS/BTM/BPM
systems is built a file management system which is used not only
by the users and processors of the system but also by the system
itself. Read, write, open, close, and other command directives of
this "file system" are issued by users and processors via CAL
instructions. The monitor itself may issue CALs as a user does or
may BAL directly to the routines through internal interfaces.
with minor exceptions, all temporary storage needed by the monitor
is managed by this file system.
Files may be either consecutive or key-indexed and consist of a
variable number of variable length records. Records may be read
from key-indexed files by name or in a sequential manner. Unlike
the file management of many systems, space is acquired from a
general pool and files may expand indefinitely in size restricted
only by the physical size of the secondary storage av~i1able.
A third type of file, called RANDOH, pre-allocates a fixed amount
of space at open time and is read or written addressing by
relative granule number. This type of file is not used by the
monitor for any of its I/O.
All
files
are
divided
into
and
cataloged by account.
Authorization to read or write a file within a given account is
granted on an account basis. Each user must establish an account
under which he runs at logon time.
Logon account, therefore, establishes control with respect to the
file system and should not be confused with accounts established
by the installation for fiscal purposes or with the "accounting"
records produced at the end of each job to record time, core use,
I/O activity, and other resource utilization. Accounting routines
which gather this information have nothing to do with file
accounts.
Star Files
Processes within the monitor, including the loaders and CCI, which
require files of temporary intermediate information place this
information in files which are called star files. These files are
special with respect to their handling by file management since
they are not entered into the file directory, and are special in
their naming convention and in handling at job logoff.
15
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
The file name of star files is constructed of three characters:
the first two are the halfword user 10 which is included to assure
that the file has a name unique in the system.
(Two distinct
files will therefore be created and used by a shared processor or
monitor component executing concurrently for two different users.)
The third character of the file name is assigned to the process
using the file. The file named idD for example is a file used by
the monitor batch debugging facility to temporarily save MODIFY
and SNAP commands. Note that the star file names are often
referred to with the ID in lower case and the following character
in upper case to indicate that 10 is substituted at file creation
time.
Star files and their use in UTS are as follows:
idS
Binary file of ROMs from card input formed by eCI (and
the tree table) so that the Loader may make its two
passes.
idD
Batch debugging commands - MODIFYs, SNAPs, etc.
idL
Load module output file created by LOADER or LINK when
a LM file is not explicitly named.
idG
Assembler or compiler output ROM file used when the GO
option is specified.
The default file assignment of
the M:GO DCB.
idR
Assembler ROM output for LINK if no explicit file is
given.
R is exactly equivalent to B with respect to
the file system.
idT
File containing the names of all files which have been
marked for release at job end by the M:TFILE operation.
idN
Load and Link files
16
16
UT~
TECHNICAL MANUAL
SECTION BB
1/12/73
17
PAGE
Libraries
There are three kinds of program libraries provided in UTS:
1.
Relocatable Object Module
(ROM)
libraries
(computer
or
assembler output) which may be private to a user's account or
public by placement in the system account.
2.
Load Module (LM) librarios (loader output) which may also be
either publicly or privately held (these are formed by the
Loader in :DIC and :LIB files as described in the UTS System
Management Reference Manual) •
3.
Shared libraries (in absolute form) which are publicly shared
by all concurrent users.
Association of libraries with a user program is carried out by one
of the loaders, either the one-pass on-line loader, LINK or the
two-pass overlay loader, LOAD. LINK does not include LM loading
in its capabilities. Both loaders associate programs with the
shared libraries either on explicit command or implicitly by
knowing that certain unsatisfied references can be found in a
particular library (e.g., 9INITIAL is to be found in the FORTRAN
run-time shared library).
Shared libraries are created and absolutized at SYSGEN time.
consist of three elments each:
of
the
library
They
1.
The instructions (pure procedure)
which will be the shared part,
routines
2.
An unitialized data area which provides local library context
to each user at a fixed virtual address, and
3.
A symbol table
(REF/DEF stack) which enables the Loader to
provide direct linkages to the library from the user program.
Two shared libraries are supplied with each UTS system: a standard
set of FORTRAN run-time routines
(excepting only
complex and
hyperbolic functions),
and the same standard set, together with
the FORTRAN Debug Package (FOP).
17
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
UTS Structures
The UTS Operating System may be divided into the resident monitor
with its overlays and the processing programs without which it
would be skeletal.
As shown in Figure BB-2, the processors may be thought of on two
levels: first, on the executive level, are the command processors.
These shared processors, of which TEL, CCI, LOGON, and EASY are
examples, pass control to other processors on error command. They
are returned to in the case of errors and aborts or exits in the
other processors 1 secondly is a level containing user programs,
language processors, utility programs, and management control
processors.
On this level, any special privileges required are
granted to the user job.
The monitor and all processors except the application processors,
language processors, FDP, libraries, are termed the control
program and are those programs delivered with a UTS release.
(As
a matter of convenience, the latest versions of the FORTRAN
Library and the language processors Meta-Symbol, FORTRAN, and
BASIC are included in a UTS release.)
18
18
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
19
Figure BB-2 - UTS Logical Structure
Monitor
Basic Control
Scheduling & Swapping
Memory Management
~ile Management
P'ob Step Control
r,rerminal I/O
Symbionts & Coop.
Sys. Integrity
(Recovery)
ILOGON/LOGOF,
System
l1anagemen t
rocessors
SUPER
ONTROL
RATES
PURGE
ILL
RR:T.IST
RR: SU1-i
o DUMP
OLINIT
SPM
UMMARY
RSP
I
Initialization & Startup
Operator Communication
Batch Debugging
System Debugging'
Load-and-Link
Read-Time Serve (proposed)
Remote Batch Serve
I
EASY
Language
Processors
FORT. IV
Metasymb.
BASIC
ANS-COBOL
MANAGE
FLAG
Terminal Exec.
Language
(TEL)
j
Exec. Control
Processors
Link
Load
DELTA
FDP
Libraries
(FORTRAN)
19
Utility
Processors
Edit
PCL
SYSGEN
DE FC OM
SYMCON
ANALZ
BATCH
Command
Interpreter
(CCI)
~ontrol
~pplication
Processors
SORT/MERGE
1401 SIM
OMS
GPDS
SL-1
CIRC
UTS TECHNICAL MANUAL
SECTION DB
1/12/73
PAGE
Dynamic Structure
Another way of viewing UTS is through the dynamics of its
operation. Here we see three levels: the slave program level, the
monitor service level for carrying out the users' requests, and
the scheduiing level where the decision for next user is made.
Slave Level
This level includes all programs that run in the nAPPED,
SLAVE mode (parts of some specifically privileged programs on
this level may run in master mode). Batch and on-line user
programs,
with their shared public libraries, language
processors, such as FORTRAN and COBOL, and the special
processors of the system, such as CeI, TEL, LINK, and DELTA,
all fall into this category. Programs operating at the slave
level are always mapped and are protected from others in core
by the access codes and write-locks of the hardware. Monitor
services for I/O and other services are provided via CAL
instructions which pass control to the monitor service level.
Monitor Service Level
The second logical level of UTS provides for service of CAL
instructions, processing of machine traps, I/O interrupts,
clock interrupts, and external interrupts. Operation at this
level is always in the ~mSTER mode and may be either mapped
or unmapped. Code at this level is largely resident in core
memory and is divided into data and pure procedure sections.
Write locks are set so that the procedure area can never be
written even by the monitor itself. After the called service
program is executed, exit is made to the scheduling level.
Scheduling Level
The third logical level of UTS controls scheduling of machine
operations by making an appropriate selection for a swap
between the swapping device and core memory, followed by
selection of the next user for execution. Map, access codes,
PSD and general registers are then loaded and control goes to
the selected slave program.
This logical organization of UTS is shown in the diagram of Figure
BB-3.
20
20
UTS TECHNICAL MANUAL
SECTION BB
1/12/73
PAGE
21
Figure BB-3 - UTS Dynamic Organization
Users
Slave
Level
Processors with Special Status
Processors
On-line jobs
Batch jobs
Ghost jobs
BASIC
FORTRAN
EDIT
COBOL
PCL
TEL,CCI,EASY
LINK, LOAD
DELTA, PDP, RUNNER
LOGON/LOGOFF
Libraries, SUPER
CONTROL
Diagnostics
ERR:LlST
ERR: SUr-1
DRSP
User Requests
Async ronous Events
Traps
f\o.)
Honitor
Service
Level
Program &
machine
errors;
System
recovery
Clock
Time slice
9uantumi
External
lOO
!
I' cac
Processing for
error recovery
& retries;
/\
Char.
interrupts
cac
~r.minal
Read &
Write
Start more I/O
Schedulin
Level
Entere w1th event codes descr1b1ng act1v1ty.
Four general duties:
1)
Schedule for swap
2)
Schedule for execution
3)
Load map and access codes
4)
Return to selected slave program
CALS
'"
Read,
Wri te ,
. CALs,
Aborts, Open,
Special Close
Exits
(Associate
Process,
IOQ
Link,
Run,
Program,
Fetch,
DCB
r·1ERGE
1
Get &
Rep lace
Pages;
Control
Access;
,
i
UTS TECHNICAh MANUAL
SECTION BC
1/12/73
PAGE
22
CORE, SWAP RAD, FILE, AND SYSTEM TAPE LAYOUTS
Core Memory
UTS makes full use of Sigma 6/7/9 mapping hardware, access protection,
write locks, and Sigma 9 extended memory in allocating available
physical core pages to users. Physical core pages are allocated to
users at their request. At system boot time the physical size of the
actual memory is determined by referencing all memory and linking
existing pages into an available pool. Thus, it is possible to remove
core from service by turning off the physical boxes so long as the
available physical memory is contiguous from address zero.
Use of the map obviates the need for program relocation or physical
moves. Full protection is provided, not only of the monitor from the
users but also of one user from another, the monitor from itself, and
each user from himself. All programs including the monitor itself are
divided into procedure and data. The procedure area is protected by
write-locks or access codes, or both, against inadvertent stores.
The strategy of write-lock usage to protect master mode programs are
as follows:
See the Sigma 7 Reference Manual for a complete description of locks
and keys, but remember that a key is associated with each program
through the PSD and a lock is attached to each core memory page. Keys
and locks control only store accesses. A key of 00 fits any lock; a
lock of zero is "unlocked"; otherwise, the key must match to permit a
store.
1•
A key of" 11 is never used nor is a lock of 10.
2.
The monitor operates with a key of 01 and thus may store in
a.
b.
c.
its own data area (lock = 01).
any batch, on-line, or shared processor core (lock = 01).
a reserved area for resident real-time data (lock = 00) •
It may not store in
a.
b.
3.
its own procedure (lock = 11).
pure procedure of resident real-time (lock
=
11).
User programs operate with a key of 00 but in mapped/slaves
mode so that protection is provided by the access controls.
22
UTS TECHNICAL MANUAL
SECTION BC
1/12/73
PAGE
23
4.
A key of 10 is reserved for resident real-time.
It may
store only in its own data area (lock = 00). It may not
store anYHhere else (lock = 01 and 11).
5.
Write-locks are initialized only once (at system startup)
and are not changed thereafter except when running under
control of EXECUTIVE DELTA where they are used to enable
data breakpoints.
A typical layout of physical memory is shown in Figure BC-1.
The access code of each virtual memory page controls references made
by slave mode programs (user programs and shared processors). Full
access and map images are retained in the JIT of each user and are
loaded when the user gains control. TEL, CCI, and LOGON are given
special write access to JIT and other job context areas.
In examining the virtual and physical memory layouts to determine the
protections, the reader should recall that although the map applies to
all addressing operations when the map bit of the PSD is on, address
protection depends on the master/slave bit. In slave mode, the access
test is made first and then the write-key write-lock test.
In master
mode, the access test is skipped.
The layout of virtual memory that applies to user programs and
ordinary shared processors is shown in Figure BC-2. Virtual core
addresses shown are those appropriate for a typical system. More (or
less) physical core may be established for the resident monitor at
SYSGEN time depending on installation needs, such as the requirement
for special device handlers or other options. The bound at which the
one-pass Loader (LINK) places the user program is adjustable by
assembly parameter in LINK.
23
SECTION BC
1/12/73
PAGE
24
UTS TECHNICAL MANUAL
Typical contents of the various areas together with number of pages
used are as follows:
Context Area
Available Area
Special Area
Job Information Table (1-2)
User programs, data,
and symbol tables.
Special shared
processor and
data:
DCBs (1-n)
Ordinary shared
proces~ors including:
LINK
File Buffers (4-n)
Root segment
DELTA
('\
COOP Buffers (0-2)
Initial Data
TEL
Overlay Area
FDP
Public Libraries
Monitor Overlay (1-6)
Virtual pages which have no physical core page associated and are
mapped into a resident monitor page (20) that is write-locked and
protected by the no-access (11) code. Thus, slave mode programs are
denied access through the access mode, and attempts to store at these
virtual addresses by a master mode program are protected by
write-locks.
System Residence and Swapping RAD
In UTS, the system resides on the swapping RAD or disk pack.
Allocation of. components of the operating system on this system device
is accomplished at the time the system is booted from a PO tape. The
initial portions of the RAD contain enough information to accomplish a
complete restart after quiescence or a recovery in event of system
failure.
This device is also allocated dynamically to individual user jobs as
they are swapped between bursts of activity which require core
residence and use of the CPU or an lOP.
System Storage
Table BC-1 lists the system components and shared processors appearing
on the system/swap device. Two categories are listed: the area
provided by the boot-from-tape process, and the area constructed from
system files by the initializer GHOST1. This latter area is used by
recovery for a core dump area and is reconstructed by the initializer
following each recovery. The remaining portion of the system device
is dedicated to user-swap space.
24
o
-------- ----
end
-_._--- --------
:n
co
c..,
CD
Contents
Resident realtime programs
and data
On-line Jobs, Batch Jobs, Shared
Processors, Nonresident Monitor
Overl ays (Master mode)
Res i den t Mon itor
(Proposed)
'"
()
I
-I
"'<
~.
n
Data
Program
Data
Program
0
~
CD
01
Keys
3
..,
0
10
00
"'<
r-
-
0
Locks
01
01
11
00
"'<
11
--0
c
-.--~-
j
0
Mapping
Unmapped
Mapped
Mapped or Unmapped
0
VI
n
0
CD
.-~~--
_ ..
_-- r---------. - - - - - - - - - - -
Use Mode
Master
~--.-.
- - ..
~
----.
..
~
- _.-
- _.
-- ---_.
~-.
-_. -.
.
-
-
. -
.-
Slave
Note that the system is protected from users by access codes, not locks and keys.
Note that key = 11 and lock = 10 are never used.
.-.
--_._---
Master or Slave
-
C
-I
1
~
-I
?)
:c
Z
-»
()
r-
~
»
z
C
»
r-
o
Figure 8C-2 - Typical User - Program Virtual Memory Layout
(Not to Scale)
48K
-- - --_. _. - -- ..- - - - - - - - - - _ - - - - - - __ - . - - ---
112K
128K
- _ _- ---Special area
Avai lable Area (LINK Loader)
for special
Monitor
Context
M sh ared pro96K
. - - ' ' - - --_ _-_._----Area
Area
~ cessors and
Program
o lOb
Delta
Data Area
U
I ranes
Code
Symbol ~ (DELTA,
(pure
II
Mon J
Program; Dynamic! Unallo- ! Common procedure) Table
Q LINK,
TEL,
IDeBs
!Buffers
Overlay
Data
Program
cated ! P
I
Area
FDP}
Data !; Pages . PaJO es :i
ages Area
6
Var ! Var
T
-
32K
....
~--
..
..
-.~
- - -
-
..
-
-_ .. -
..
..
0
i:T1
User
Access
~I""__-
none - - -•••. - read
t.!..read (first
I
--I~"'i~.
pag~=--.--
'
nonerwrite
.
I
I.t
i
ii
I
'l
.;.none-.
write--.i!.. execute +-read
i
I
ton~
C
-I
or
execute
Vl
-f
m
()
:c
/
Z
()
r------------------------------------------ -
»
Available Area (LOAD Loader)
r-
I
~
Program' Dynamic' Unallo- ICommon _
Delta'
Program Data ' t d
i Code I Pages: ca e
i Pages ..... 1'0...... Symbol
1
Pages!
Tables
I
1_
Z
~
- -
r-
write--....~xecute+write+ none_~write~
read
M
l
all,
to allocated
to allocated physical page or to a protected locked monitor page
physical page
Access
Codes
11
10
none - no access of any kind permitted
read - read access on Iy
01
00
-1
~'"
~;:::; ~
m,,;j
"0
W
execute - execute and read access
write - write,' execute, and read permitted
z
UTS TECHNICAL MANUAL
SECTION BC
1/12/73
PAGE
27
Table BC-1 - Contents of System Portion of the Swapping RAD
A.
Items Written During System Boot
1.
Disc bootstrap routine (Sectors 0-1).
2.
Space for ALLOCAT JIT, AJIT (Sectors 2-5).
3.
Master JIT (Sectors 6-7).
4.
ALLOCAT data, including HGPs, the granule
bit maps.
allocation
5.
ALLOCAT procedure - the granule allocation ghost
program.
6.
GHOST1, the system initializer.
7.
Space for new or replaced monitor overlays (six
each per MOSPACE).
pages
8.
Nine monitor overlays - Open Files (OPEN), Close Files
(CLOSE), Label Tape (LTAPE), Operator Keyins
(KEYIN),
Load-and-Link (LDLNK), Batch Debugs
(DEBUG), multilevel
index creator (MUL), Device
and Type CALs (IODTYPR), and
miscellaneous routines
(MISOV).
B.
9.
RECOVERY, the system failure recovery and restart
routines.
10.
XDELTA, the executive system debugger.
11.
UTS Monitor Root, in absolute core image format.
Items Written by GHOST1.
The shared processors are built according to specifications in
monitor tables provided by SYSGEN. XEROX shared processors
established automatically by SYSGEN are as follows:
CCI, TEL, LOGON
LOGON, LOADER
BASIC, l.fETASYMBOL, FORTRAN
EDIT, PCL, DELTA, BATCH
FILL, RUNNER
GHOST1, DRSP
FORTRAN Public Library, FDP
27
UTS TECHNICAL MANUAL
SECTION Be
1/12/73
PAGE
28
Swapping Storage
Users (batch and on-line) are removed from core to a dedicated area of
secondary storage (RAD or disk pack) when core storage is required for
higher priority users.
A bit table (SGP) is used to keep track of the availability of each
granule (two sectors = 512 words) on the RAD. In this table, a zero
is used to indicate that the granule is in use (assigned to a user)
and a one is used to indicate that the granule is available. Users
are assigned, in groups of four, a sufficient number of page-size
granules to accommodate their current use. The assignment is done in
such a way that command chaining of the I/O can order the granules to
be fetched for a single user with a minimum latency. That is, each
user's pages are spread evenly over the set of available granules so
that data will be transmitted in every disc sector passed over when
the user is swapped.
The records of disc granules associated with each user are kept in the
user's Job Information Table (JIT), which is kept on the s\-lap device
when the user is not in core. The disc location of the JIT is kept in
core by the scheduler. The device layout is such that suf~icient ti~e
is available after the user's JIT arrives from the swap device for the
system to set up the I/O command chain contained therein for swapping
the reaminder of the user program.
,
The amount of secondary storage assigned to swapping is a parameter of
SYSGEN. The number of active (batch and on-line) users that the
system can accommodate is limited by the space allocated for swapping
and the total size of all active users.
If the swap device is a disk pack, each user is allocated one or two
cylinders during SYSGEN. The system still uses the RAD SGP and
allocates swapping storage in terms of granules. The exception is the
swap I/O routine which obtains the user's cylinder number from a
resident table and epecially sets up disk pack command lists to
perform I/O to continuous granules on cylinders.
28
UTS TECHNICAL
~·1ANUAL
SECTION Be
1/12/73
PAGE
29
Symbionts and Files
RAns and disk packs are
Each RAD or pack except
symbiont area (PER) and
of each kind of storage
the PER and PFA are not
pools, except that when
space.
divided into page size (512 words) granules.
for the system (swap) RAn is divided into a
a file area (PFA). At SYSGEN, the proportion
on each device is specified. Once generated
exchangeable: they form separate allocation
PER is exhausted, PFA is used for symbiont
For each device, SYSGEN provides an allocation table which contains a
bit per granule on the device.
These tables are collectively referred
to as the HGP, although technically, HGP, the Head of Granule Pool, is
a cell containing the address of the first of a linked chain of
allocation tables.
Also, contained in each allocation table are
pointers dividing the PER and PFA area and constants defining the
number of granules per track and other device-specific parameters.
These allocation tables reside in and are manipulated by the ghost
program, ALLOCAT, which is called occasionally to fill or empty stacks
of available granules in core memory.
Granules required for file
addition or released when files are deleted are taken from the stacks
of available granules. When the stacks' contents exceed
pre-established thresholds, then the ALLOCAT Ghost is called to
refresh them to an optimum level.
29
UTS TECHNICAL MANUAL
SECTION BC
1/12/73
PAGE
30
File Structure
A file may be organized as consecutive, keyed, or random. In a
consecutive file, the records may be accessed only in the sequence in
which they were orginally written. In a keyed file, each record has
an associated name or key. Records in a keyed file may be accessed
directly by specific key values or sequentially, according to their
order in the file. A random file consists of contiguous granules
rather than a group of records. Random files are accessed by granule
number relative to the beginning of the file.
A disk file resides on the Monitor's secondary storage. UTS uses both
the RAD and disk pack devices for secondary storage. Any combination
of these devices can be defined for a UTS system at SYSGEN time. A
disk pack device has dismountable volumes and can be declared either a
public or private device at SYSGEN time, while a disk device, not
having dismountable volumes, can only be declared a public device. A
public disk pack has only one volume that can be recognized by UTS,
and that volume must be mounted at all times while the system is
active. A private disk pack device has any number of dismountable
volumes that can be recognized by UTS. The Monitor requires that only
those volumes needed for execution of the user's job be made available
and be mounted. A public file resides on public devices (RAD and/or
disk pack); a private file resides on private disk pack volumes.
A private volume set is defined as a collection of removable volumes
that the user has grouped together containing any number of files with
any type of organization (consecutive, keyed, or random). All files
in a private set must belong to the same account. A private volume
set is identified by the volume serial numbers specified in the SN
option of the lASSIGN command when the first file is written on the
set. Volumes may be added to the set by entering a new volume serial
number in the" SN list, but a volume may not be removed.
Keyed and consecutive file space is allocated.on a demand basis as the
file is being created or updated, therefore such files do not
necessarily exist in· contiguous areas on a RAD or disk pack device and
can exist on many different physical devices. Random file space is
allocated when the file is opened for output. The size of a random
file can never be changed.
30
UTS TECHNICAL l1ANUAL
SECTION BC
1/12/73
PAGE
31
Access to user files is via a hierarchy of disk-resident Monitor
files.
Figure BC-3 shows the structure of system-managed files.
The
top file is an Account Directory, which contains a directory of all
accounts that have public user disk files.
There is one account
directory for all public files in the system (the Public File Account
Directory). Each account has its own file directory, which contains a
directory of all files in the account. Each file has a File
Information Table (FIT), which is part of the file directory for
random files and part of the file itself for keyed and consecutive
files, and contains all the information necessary to open a file, such
as its organization, location, password, etc.
To locate a public file, the public account directory is searched for
the file account number.
The account number entry contains the disk
address of the account's file director1. The file directory is
searched for the file name. The file name entry contains the disk
address of the file's FIT. The FIT contains the disk address of the
file.
Private files are located via AVR and MOUNT logic. A keyed file
consists of two parts: a Master Index and a set of data granules. The
data granules contain the records in the file, which are packed in
granule-size blocks.
Data granules do not contain any system
information. The Master Index is a collection of hierarchical levels
of index blocks where the entries in a higher level point to index
blocks at the next lower level, and the entries in the lowest level
point to data records.
A consecutive file consists of granules containing the data of the
records preceded by four bytes of control information per record,
generally. A random file is devoid of system information.
Record
management and format of the file is the user's responsibility.
Besides the security checks required for access to a file, the only
checks made by the system are to prevent the user from reading or
writing past the limits of the file.
Functionally and operationally,
a random file is a collection of contiguous granules on the specified
device type. However, if a random file is larger than a disk pack in
size, the file will extend beyond volume boundaries (if private) or
device boundaries (if public).
31
R~~1)OM
(f"lXeb..o:=
"D\e.e-~1 )
cn
.... n
'"t1 ....
)"t'Ij
(j)
,H
-...10
t'ljr-vt-3
wZ
t:d
I
i
f ____ ?'!.. , •••, , _ - - - - - - '
Figure BC-3 - UTS/BTM/BPM File Structure
()
I
UTS TECHNICAL MANUAL
SECTION BC
1/12/73
PAGE
33
System PO Tape Contents
The system tape, called a 'PO tape' for reasons lost in antiquity,
contains all data needed to begin UTS operation. The tape contains
ready-to-run load modules for the monitor, its overlays, and the
processors of the operating system. It may contain any other files
which the installation desires and includes when the tape is written
(DEFed). The tape is structured into two parts. Prior to the first
file mark are records absolutely required in getting the system into
operation: the monitor, its overlays, EXEC DELTA, recovery, ALLOCAT,
and the elements of the initialization program, GHOST1. Following the
first file mark, the tape is in standard labeled tape format and
contains load modules for all remaining parts of the system. The tape
may contain any modules or files whatever. Only those preceding a
null file named LASTLM are copied to the system device file structure
during system initialization.
The system tape may contain any necessary number of records prior to
the formatted part and still be a valid standard format tape because
of the label tape identification procedure (AVR sequence). In this
sequence, the tape is rewound, forward spaced to the first file mark,
backspaced two records, and read forward to find the tape label.
Thus, the label is found independent of the number of records
preceding the first file mark.
Table BC-2 lists the records on a UTS PO tape.
33
UTS TECHNICAL MANUAL
SECTION BC
1/12/73
PAGE
34
Table BC-2 - Contents of UTS PO Tape
A.
Unformatted Area Records
Tape Boot
Root in one-page records
System information record containing
version and creation date
EXEC DELTA Head
EXEC DELTA Data.
ALLOCAT Head
ALLOCAT Data.
ALLOCAT Procedure
GHOST 1 Head
GHOST1 DCBs (load module protection type 2)
GHOST1 Data.
GHOST1 Procedure (load module protection type 1)
Overlay Head
Overlay Data.
Recover Head
Repeated for the nine overlays:
MISOV,IODTYPR,OPEN,CLOSE,LBLT,KEYIN,
Recover Data. DEBUG,DLNK,MUL
~Ioni tor
B.
Standard Labeled Tape Formatted Area
:LBL
:ACN
First Physical End-of-File
File records for all system load modules and
other needed files (SYSTEl--t PROCs, Error
Message Files, etc.)
LASTLM File
Other files as desired
:EOT
*Data is protection type
0 of the load module.
34
UTS TECHNICAL MANUAL
SECTION RD
1/12/73
PAGE
35
MONITOR FUNCTIONAL STRUCTURE
This section describes the UTS monitor's functional capabilities
together with the broad strategy which is used to accomplish each.
The outline of this section is echoed in the following section,
BE, which reviews the system module by module giving details of
the function provided by each, together with approximate physical
size.
The broad categories and services provided by each are as follows:
1.
Basic I/O
This section describes the operation of routines which
centrally queue all requests for I/O, provide devLce-specific
handling of each request, service I/O interrupts, and buffer
and manage all terminal I/O requests.
2.
System Management
This section describes the operation of those portions of the
monitor which are responsible for scheduling execution and
swapping of user programs, managing core and swap RAD memory,
and controlling the sequencing of jobs from step to step.
3.
Symbionts and Cooperatives
The routines described in this section provide for buffing of
input and output between user programs
and
low-speed
peripherals
(card readers, card punches, line printers, and
remote batch terminals).
4.
System Services
This section describes routines which relate to the system as
a whole.
Areas covered are:
initialization, recovery,
operator communications, accounting, performance monitoring,
system debugging, and hardware error logging.
5.
User Services
The routines described in this section carry out services at
the explicit request of user programs. Covered are file
management, the load-and-link commands, and batch debugging
commands.
35
UTS TECHNICAL MANUAL
1.
SECTION BD
1/12/73
PAGE
36
Basic I/O System
The code grouped in the 'basic control' category includes Ca)
the routine which queues up requests for I/O activity and
handles the I/O interrupt, (b) the basic device I/O handling
routines,
and
(c)
the UTS terminal I/O and buffering
routines. The first two sets are nearly identical for the
BP~I,
BTM, and UTS systems.
The I/O queue routines and
handlers are also close cousins to those used in nCM and RBM.
Data used by these routines are largely generated hy RYSGEN,
including the Device Control Tahles (DCTs) and RAD Granule
Maps (HGP) in the module IOTABLE, the Queue Tables
(100)
in
M:CPU, and the terminal I/O tables in M:COC.
a.
. I/O Queueing and Device Handlers
The Basic Input/Output System which is common code to
RBM, BPM, and UTS provides a simple interface between
all parts of the operating system and the external
peripheral devices.
It stacks or 'queues' the requests
for service rather than waiting for each operation to
complete before returning to the caller.
When a
request is completed, the caller is notified via
certain parameters in the DCB, or the caller may
specify the address of a subroutine to be executed at
this time
(called the 'end-action' routine). It is
capable of receiving requests for input at any time or
from any place in the system and dispatching them in a
manner which is independent of
other
operations
concurrently being executed by the system.
Error
recovery procedures are invoked when necessary and do
not require any additional specifications from the
caller.
Requests are normally serviced in the order in which
they are received.
In a real-time system, requests are
serviced by task priority. Precautions are taken to
prevent any major service to lower priority requests
when a higher priority task is active.
Standard
techniques
within
the handlers provide
centralized
recovery
from
errors
and
device
malfunctions Operator intervention is enlisted when
required, for example, to reinsert a card read with
error
or to take action on unrecoverable device
failure.
36
UTS TECHNICAL MANUAL
SECTION RD
1/12/73
PAGE
37
There are two basic entries to IOQ: a standard entry in
which the I/O commands are prepared by IOO and the
handlers, and an entry in which the entire I/O command
list is supplied by the caller.
Few restrictions are placed on buffer size or location.
Facilities are included for gather-write/scatter-read
operations
(data chaining), and provision is made to
allow construction of lOP command lists outside of the
basic I/O.
For standard tape, RAn, and Pack I/O, a
monitor buffer is obtained in which data chained I/O
command
lists are built according to the actual
physical core locations of the record requested.
A
maximum of 8K words is allowed for tape requests.
UTS 'blocks' I/O requests if the calling process is
mapped,
i.e.,
a
user
service.
Operation
is
discontinued for this user and the system turns to the
next.
The inherent differences between peripheral devices are
accounted for by the insertion of device-oriented code
(handler)
for each type of device in the system. A
well-defined handler interface allows addition of new
handlers with a minimum of difficulty. Also, a number
of subroutines are availahle which perform common
hander functions.
Handlers are added to the monitor root as a result of a
SYSGEN PASS2 DEVICE command which names the device, its
addresses, and its handler. This causes the handler to
be added to the standard file of handlers which
initially includes the handlers for the operator's
console, the card reader, the line printer, the RAD,
and nine-track tape.
37
UTS TECHNICAL MANUAL
SF.CTION BD
1/12/73
PAGE
b.
38
Logical I/O Channels
A channel is a data path connecting one or more devices
with the CPU, only one of which may be transmitting
data (to or from memory) at any time.
Thus, a magnetic tape controller connected to an MIOP
is a channel. But one connected to an SlOP is not, for
in this case, the SlOP itself fits the definition.
Other examples of channels are a card reader on an
MIOP, a keyboard/printer on an MIOP or a RAD controller
on an MlOP.
Input/Output requests made on the system are queued by
channel.
This method facilitates starting a new
request on the channel when the previous one has
completed.
The
exception
to this rule is the
'off-line' type of operation such as rewinding of
magnetic tape or arm movement of certain moving arm
devices. If this type of operation is started, an
attempt is always made to start a data transfer
operation as well. Thus, the channel is always kept
busy, if concurrent requests are available.
By using logical channels to separate devices on a
physical channel (MlOP), the IOO routine may be used to
prevent data overruns when more devices are connected
than can be handled by the MlOP simultaneously.
In addition to assigning a logical channel(data path)
to a group of devices, it is possible to define two
logical channels for a group of devices where the
hardware permits. Thus, requests to use any of the
devices will be honored as soon as either channel (data
path)
is
available for data .transmission.
This
facility is commonly referred to as 'device pooling'.
Thus, for example, two controllers can simultaneously
have any two of eight disk packs; whereas, without the
feature, each controller would be able to serve anyone
of four. Obviously, the former case is more efficient,
in general.
38
UTS TECHNICAL
~~~UAL
SECTION BD
1/12/73
PAGE
39
Since requests on a channel are normally "chained" by
the I/O interrupt, there must be a means whereby any
action on a request which is deferred by priority may
be resumed at a later time. This provision is the
'Control Task', usually the lowest level external
interrupt in the system. \"lhen action is deferred, the
device code is entered into the Control Task stack and
its interrupt-is triggered. When it becomes active it
will call the scheduler for the device in question. In
a system created with no Control Task, the console
interrupt will be triggered instead.
The console
interrupt receiver is designed to perform Control Task
functions when there is no external interrupt assigned
for this purpose.
There are two major parts involved in the processing of
an I/O request: start (done -by STARTlO) and cleanup
(done by CLEANUP). The start consists of building the
lOP command list and executing the SIO instruction,
while the cleanup consists of testing for errors and
notifying the caller of the completion.
For a given
request, the tiMe at which a start of cleanup is done
is determined by the I/O scheduler (called Service
Device or SERDEV) •
39
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
40
System Flow
The center of I/O activity is the scheduler, Service Device. This
routine starts all operations and processes their interrupts
(cleanup). Thus, Service Device Must he callen whenever certain
key events occur or when other special conditions are present in
the system. The figure below shows the downward flow of control
from some of the most important areas of the I/O systeM.
Request is
made
NEWO
QUEUE1
1
Interrupt occurs
IOINT
J
S E R V ICE
Hon1tor wa1ts
for completion
IOSPIN
J
D E V ICE
J
j
1
In1 t1ate
operation
STARTIO
Process
interrupt
CLEANUP
,
,.
H
Hanc ler
pre-processor
Handler
post-processor
40
Contra
Task
CTIOP
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
41
service Device is a highly independent routine in the
sense that it can be called at any time from anywhere
in the monitor.
It is called whenever there is any
chance that a start or cleanup can be done for a given
device. Some examples of when Service Device is called
are as follows:
1.
When a request is queued (start may be performed
for the next request in the queue).
2.
After an I/O interrupt has occurred (cleanup
be dohe).
3.
After a cleanup has been done (a start may be
performed for the next request in the queue).
may
Device-dependent routines are provided for building
command lists and testing for errors. STARTIO calls
the 'handler pre-processor' to do the former, while
CLEANUP calls the 'handler post-processor' to do the
latter. These two parts constitute the device handler
for any given peripheral and are provided in separate
assembly modules.:9
Information pertaining to requests,
devices,
and
channels is maintained in a series of parallel tables
produced at System Generation Time.
The first entry
(index = 0) in each table is reserved for special use
by the system. Three groups of tables are used 1) to
carry individual I/O requests, 2) to carry status and
control information for each device, and 3) to group
the requests for each logical channel.
IOQ, Request Information
These tables contain all information necessary to
perform
an
input/output operation.
When a
request is made on
the
system,
data
is
transferred
from the controlling DCB and/or
registers into one element in each of
the
parallel IOQ tables. This set of elements forms
a 'queue entry'. The entry is then linked into
the channel queue below other requests of higher
or the same priority.
41
UTSTECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
42
OCT, Device Control
The
device
control
tables
contain
fixed
information about each system device (unit level)
and variable information about the operation
currently being performed on the device.
CIT, Channel Information
These tables are used primarily to define the
'head'
and
'tail'
of those entries which
represent the queue for a given channel at any
time.
A
channel queue may have more than one
entry active at any time (such as several tapes
rewinding while another reads or writes).
c.
Terminal I/O (Cae)
Terminal I/O cac routines are the read/write buffering
and the external interrupt handling routines for I/O
directed
to user terminals.
The read and write
routines
on
the
user-interface
side
translate
characters to external form and buffer messages into
linked, core-resident blocking buffers.
Insertion of
page headers, vertical format control (VFC), user
headings, tab simulation, and other formatting tasks
are performed.
The interrupt routines demultiplex incoming characters
by line, translate to internal EBCDIC form, check
parity, block messages into buffers, echo characters to
the
terminal,
and test for valid end-of-message
characters.
The routines support teletypes, ASCII-compatible CRrs,
and
2741's for most common speeds, formats, and
character encodings. Where full-duplex terminal are
available, type-ahead is supported - the user may type
input while output is ongoing or before a read request
is received.
Paper tape units are supported for both
full- and half-duplex terminals.
Translation
of
characters may be suppressed to provide arbitrary
binary I/O.
Recognition of special characters to allow simple
character-delete and line-delete editing functions,
mode settings to control echoplex _ operation,
tab
simulation, code set restriction, and other activities
'are inoluded.
42
SECTION BD
UTS TECHNICAL MANUAL
1/12/73
PAGE
43
A routine entered periodically as a result of
a clock
interrupt scans all 7611 lines to detect data set
hangup and data set answer to provide automatic logoff
and logon, respectively.
The cac routines carry out their functions using
information carried in a series of line-associated
tables, processing both characters deposited by the
7611 hardware in a 'ring-buffer' and messages to and
from a pool of four-word blocking buffers. All these
data are included in the module COCD and in M:COC,
which is provided by SYSGEN as a result of processing
the :COC control card. Initialization of 7611 lines is
accomplished by the routine COCI, which is needed
during
system initialization, recovery, and power
fail-safe restart.
The COC routines are resident in the monitor root and
consist of four main parts plus common subroutines, all
assembled as a single unit:
1.
Output interrupt handler.
2.
Output interrupt handler.
3.
Code to process a user's Write CALs directed to
the terminal.
4.
Code to process
terminal.
43
Read
CALs
directed
to
the
BD
UTS TECHNICAL MANUAL
PAGE
2.
«
System Manaqement
Four groups of routines are associated with this activity: a)
those that record the significant events which occur during
operation and schedule user execution and swapping from them,
b) those that centrally manage core and RAD or Pack memory,
allocating and releasing pages of core and granules of
secondary storage on demand, c) those that properly sequence
the operation of a job between its individual steps, and d)
those that associate and release monitor overlays in a job's
virtual memory space.
a.
Scheduling and swapping
The
routines
in this group control the overall
operation of the system.
Inputs to these routines,
together with the current state of users as recorded by
the scheduler, are used to change the position of each
user in the scheduling state queues. It is from these
queues that selections are made for both swapping and
execution. Swaps are set up by the selection of a
high-priority user to be brought into core and by
pairing this user with one or more low-priority users
to be transferred to swap storage. Similarly, the
highest priority user in core
is
selected
for
execution.
,
Scheduler Inputs
System activities are reported by direct entry to the
scheduler, which makes changes to user state state
queues through a logical event signaling table. The
scheduler records inputs by changing the user the user
state and other information associated with the user.
In general, a table-driven technique is used.
The
received event is on one coordinate of the table and
the current state of the user is on the other.
The
table entry thus defined names the resulting state or
the routine to be executed in response to the given
event-state combination.
Since the number of events
and states is large, the table technique aids in
debugging by forcing complete specification to all the
possibilities. Inputs to the Scheduler are listed in
Table BD-1.
UTS TECHNICAL
M&~UAL
SECTION BD
1/12/73
PAGE
45
The Scheduler also receives control at execution of
each CAL issued by a user program that is requesting
monitor service.
All these entries (Table BD-2), the
special entries from the executive language processors,
and entries from internally reported events drive the
scheduling
of the system.
Other entries to the
Scheduler occur following each trap, each interrupt,
and the end of each clock quanta.
Scheduler Output
The scheduling routine performs two major functions
during the time it is in control of the computer.
The
first is to set up swaps between main core memory and
swap storage in such a way that high-priority users are
brought into core to replace
low-priority
users
transferred to swap storage.
The actual swap is
controlled by the swapper according to specifications
prepared by the Scheduler according to priority state
queues described in the next section. Given a suitably
large ratio of available core to average user size
(greater than 4), the Scheduler can keep swaps and
compute 100 percent overlapped.
The second function is to select a user for execution
according to the priority state queues and the rules
for batch processing. The rule is simple: the highest
priority user whose program and data are in core is
selected.
45
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
46
Table BD-1 - Events Received by Scheduler
EVENT
E:ABRT
E:AP
E:ART
E:CBA
E:CBK
E:CBL
E:CEC
E:CFB
E:CIC
E:CRD
E:CUB
E:DPA
E:EI
E:ERR
E:IC
E:IIP
E:IP
E:KI
E:KO
E:NC
E:ND
E:NOCR
E:NRD
E:NSYMD
E:NSYMF
E:OCR
E:OFF
E:QA
E:QE
E:QFAC
E:QMF
E:SL
E:SYMD
E:SYMF
E:UQA
E:UQFAC
E:WU
MEANING
Operator-aborted user.
Associate shared processor with user.
Associate real-time job (not used).
COC buffer available.
Break signal received.
Number of output characters
system limit.
TEL request: Y received.
COC buffer available.
Terminal input message complete.
Read terminal command received.
Number of output characters = system limit.
Swap page available.
External interrupt event (unused).
Operator errored user.
I/O complete.
I/O started and now in progress.
Request permission to start I/O.
User back in core.
User kicked out of core.
Cannot get requested core pages.
Cannot get requested swap page.
Initiate user requesting open or close.
Job exit until next external interrupt (unused
No symbiont disc space.
No symbiont file entry.
User request to do open or close.
User hung up or logged off.
Q for access (e.g., for access to tape
or disk pack).
Quantum end.
No file granules available for user.
Master I/O function count exceeded.
Sleep time for user.
Symbiont disc granule is now available.
Symbiont file table entry is now available.
De-Q for access (e.g., for access to tape
or disk pack) •
ALLOCAT has filed granule stacks.
Wake up time for user.
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
47
Table BD-2 - Service Request Input to Monitor
SOURCE OF INPUTS
SERVICE REQUEST ENTRIES
User program (through
monitor service calls)
1.
Terminal input/output request.
2.
Input/output service calls for RAD, disk
pack, or magnetic tape.
3.
l"1ait (sleep) request.
4.
Program exit (complete).
5.
Core request (for common, dynamic, or
specific· pages).
6.
Program overlay request.
7.
Debug requests.
8.
Requests for control of breaks, traps,
timing, etc.
1.
Name of system programs (shared or not)
to be loaded and entered (implies
deletion of any current program).
2.
Continuation signal
3.
LINK load-and-go exit.
Executive Processor
47
SECTION BD
UTS TECHNICAL MANUAL
1/12/73
PAGE
48
User State Queues
State queues form a single priority structure from
which selections for swapping and execution are made.
The state queues form an ordered list with one and only
one entry for each user. The position in queue is an
implied bid for the services of the computer. As
events are reported to the Scheduler, individual users
move up and down in the priority structure. When they
are at the low end, they are prime candidates for
removal to secondary storage.
This latter feature,
that of having a definite priority for removal of users
to swap storage, is an important and often overlooked
aid to efficient swap management.
It avoids extraneous
swaps by making an intelligent choice about outgoing as
well as incoming users.
In addition to these primary
queues have other functions:
functions, user state
1.
Synchronizing the presence in core of the user
program and data with the ability of I/O devices.
2.
Queueing user program
pre-established time.
3.
Queueing requests
processors.
4.
Managing core memory.
5.
Queueing
6.
Queueing requests
services.
for
to
be
entry
'awakened'
at a
use
off
and
requests for buffers in core or on RAD.
for
several
non-reentrant
A list of the state queues is given in Table BD-3.
48
UTS TECHNICAL MANUAL
SECTION BO
1/12/73
PAGE
49
Table BO-3 - Scheduler State Queues
STATE NAME
AB
BAT
BK
C
COM
CU
CP
OP
EC
ERR
IOC
lOW
lOt-iF
f
i" IR
~
NRRT
loeu
I
OFF
; ON
, QA
l QFAC
SYf.1D
• SYMF
j
TI
TIO
TOB
TOBO
TOC
w
NOTE:
MEANING
Users waiting for a COC buffer.
Batch compute-bound users under segregated batch
scheduling discipline.
Users who have high BREAK.
High-priority compute-queue (used for associating
processors and some special cases of memory and I
swap storage management).
I
Compute-bound users
Current user of the CPU.
Users waiting for a core page.
Users waiting to be allocated a swapping page.
:
Users queued for entry to TEL (they have hit yC) • ~
User jobs errored by the operator.
Users with I/O complete.
Users with I/O in progress.
Users queue because of excessive current
I/O count.
Users with complete terminal input messages.
External interrupt received (not used).
Users waiting to open or close a file while
another open or close is in progress (nonreentrant portions only).
Operator aborted user or user hung up.
Users queued for the log-in process.
Users queued for access to an I/O device.
Users queued for ALLOCAT managed granules.
Users queued for symbiont disc space.
Users queued for symbiont file table entry. '
Users typing input and in core.
i
Users typing input and user not in core.
Terminal output users - in core (more
characters than the system limit are ready
for typing).
Same as TOB except user is not in core.
Users ready to continue terminal output
(the number of characters remaining to be
typed is less than a system limit).
Users waiting for a specified 'wake up'
time.
The actual names of the scheduler state queues are those
given above prefixed with the letter'S'.
f
I
49
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
50
Scheduler Operation
The
scheduling
categories:
1.
queues
be
divided
into
four
READY Queues (SB:EXU)
Jobs in one of these
execution if in core
not.
Through some
present need for the
2.
may
state queues are ready for
or ready to be swapped in if
event, they have indicated a
CPU.
ACTIVE Queues
Jobs, in one of the states CU or lOW, are
currently running either using the CPU or one of
the lOPs.
3.
WAITING Queues (SB:SWP)
These jobs have no present need for the
and are not in core.
4.
computer
OUT-OF-IT Queues
These jobs have no present need for the computer
and are not in core.
Table BD-4 shows the queue list used for selection of
users to be brought in for execution and the queue list
used for execution of users to be moved to the swap
device. HIR (High-In-core-Ready-to-run) is a condition
set when an in core user is in one of the READY Queue
states (actually a count of such users).
50
SECTION BD
1/12/73
PAGE
51
UTS TECHNICAL MANUAL
Table BD-4
Ready and Waiting Queue Lists
WAITING QUEUES
READY QUEUES
:
NRRT
ON
OFF
ERR
EC
BK
IR
TOC
C
IOC
COM
BAT
-
High Priority
SYMF
SYMD
W
OEI
OA
DP
TI
TOB
r
j
HIR
OCU
1
I,
Low Priority
To select users for execution, the scheduler searches a
list of the state queues, the READY list, in order to
find the highest priority user in core memory.
The
highest priority user is served first.
Thus, for
example, interrupting users are served before those
with an active input message (both of these take
precedence over users with unblocked terminal output),
then come' on-line compute-bound users and, finally,
compute-bound batch jobs. Note that users in order
states have no current requests for CPU resources.
Note also that as each user is selected for execution,
the state queue of the user is changed to CU. When the
quantum is complete, the highest priority queue which
the user can enter is the compute queue.
Users that
enter any of the high (above COM) priority states
receive rapid response, but only for the first quantum
of serivce. Thereafter, they share service with others
in the compute queue.
51
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
52
A similar selection procedure is used to set up users
for swapping. First, the highest priority in the READY
list who is not in core is selected and his size
requirement
(including the requirement for shared
processors not in core) is determined.
Second, users
are selected from the WAITING list until enough space
is freed until enough space is freed by these users and
their shared processors to provide for the
user
selected for swapping. If a single user can be found
to swap out, then a single rather than mUltiple swap is
chosen. No swaps occur until a user that is out of
core enters a high-priority queue (READY Queue). No
execution selection occurs prior to the end of the
minimum compute quanta. No execution selection occurs
prior to the end of the full compute quanta unless the
HIR signal is set.
Two lists resulting from this selection are presented
to the swapper. One list contains the user (or users)
to be swapped out and the other contains the user to be
swapped in, the shared processors that must accompany
the user, and the current free core-page list.
Priority queues are arranged from high to low in order
, of increasing expected time before the next activation.
This ensures that the users that are least likely to be
needed are .swapped out first, while the users most
likely to require execution are retained in core.
For
example, the swap algorithm operates so that compute
users remain in core and use all available compute time
while the interactive users are swapped through the
remaining core space whenever the following three
conditions exist:
1.
2.
3.
There is room in core for three user programs.
Two users are comput~ng steadily.
Other users are doing short interactive tasks.
In order to prevent deadlocks and to provide for round
robin scheduling of the compute-bound queue, the swap
algorithm also provides for a search through the READY
Queue list in inverse order up to the level of the
inswap user for a set of outswap users.
52
UTS TECHNICAL
~mNUAL
SECTION BO
1/12/73
PAGE
53
Thus, users whose programs have just issued a terminal
input request will be swapped out before programs which
have blocked on terminal output. Both of these will
precede programs blocked by file I/O requests, and the
final selection will be made in reverse order through
the queue of compute-bound users.
For file I/O, programs are blocked from the time the
I/O command is issued until it is complete. Terminal
input is similar. Output to the terminal is no wait
until
about
four
seconds
of typing have been
accumulated in system buffers.
It is then blocked;
unblocking occurs when one-half second remains.
Since users' programs are of different sizes, it may be
necessary to swap out more than one program to make
room for the incoming program, although a detail of the
selection algorithm causes it to preferentially select
a
single
outswap
program if one adequate size
(including any associated shared processors)
can be
found on the WAITING Queue list.
The layout of programs on the swap device is made by
selecting four pages (always a 512-word granule) at a
time from a common pool, but preferential allocation
occurs for pages which will maintain nearly continuous
sector-by-sector allocation. This technique keeps swap
timeshort while preserving a general allocation
scheme. Programs are allocated to storage with the
pure procedure portions ordered last so that the
procedure portions do not have to be transferred from
core to swap storage when a copy already exists on the
device.
Note that the queues CU, IO~v, TOBO, and TID do not
appear in either list. Thus, the users in these states
are not selected either for execution or for swapping,
nor is unnecessary overhead expended in their search.
Two
examples
of
typical
interactive
use
are
illustrative of the scheduling operation.
The first
example traces scheduling operations for a simple,
short interactive user request.
At the time the
request is typed, the user is in the typing input (TI)
queue. His program, which has probably been swapped,
remains on swap storage until the cae routines receive
an activation chracter. Receipt of this character is
reported to the scheduler and causes a change in state
of the user to input received eIR).
53
UTS TECHNICAL r.1ANUAL
SECTION BD
1/12/73
PAGE
54
The scheduler finds a high-priority user not in core
and initiates a swap removing a low-priority user (if
necessary) and bringing in the one just activated.
On
completion of the swap, the scheduler is again called
and now finds a high priority user ready to run. Given
that the current user has completed his minimum quanta,
the user's state is changed to cu, the program is
entered, and the input command is examined by the
reading program.
The cycle in this
example
is
completed by preparation of a response line and a
request to the monitor for more input, which changes
the user's state to TI again, making him a prime
candidate for removal to swap storage.
The second example illustrates an output-bound terminal
program. This program moves through the state cycle
TOB-Toe-cu as output is generated by the program. The
cac routines signal when the output limit has been
reached, thus causing the program to be delayed while
output is transferred to the terminal.
In a typical
operation, four to six seconds of typing is readied in
buffers each time the user program is brought into core
and executed. During the typing time, the program is
not required in core and the CPU resources can be given
to other programs.
I/O Scheduling
I/O scheduling is designed to give job step I/O a very
high priority to provide good terminal response. Other
I/O is permitted to run as fast as possible 'until the
user has accumulated a full maximum quantum of CPU
time, at which point the user is placed at the bottom
of
the compute queue.
The scheduling scheme is
illustrated in Figu~e BD-1.
.
54
UTS TECHNICAL r1ANUAL
SECTION SD
1/12/73
PAGE
55
.~E:IOC
J b
Quantum end fo)"
,ob step users
step
•
processing
•
0
~/
~,'
"
~
./-'
,/'
\
High-priority
sel ection for
execution
i
l
--·0
~/
I
/
'.
CU \~
\
I
~
"',
Low- pri ori ty
selection for
.~xecution
Quantum end: ~.~
used comp-ute ti me
.
QMAX-QMIN
..
i
:~M
~
-------
QO
I~
I
S)
..
//
~
An I/O-bound user cycles through the queues cu, row,
IOC, and CU until he exhausts his tiMe quantum at which
time he cycles through the compute (Cor·n queue s. Thi s
·ensures that a single I/O bound user does not dominate
the system.
I/O that occurs at job step time (that
done by CCI, TEL, and the program fetch logic) proceeds
through the higher priority C queue. If the number of
concurrent
I/O
operations for a user exceeds a
specified limit, the user is blocked in state laMP
until some of them complete.
Reentrancy
The scheduler permits job-to-job switching only at
certain carefully controlled points within the monitor.
At these points control is explicitly given to the
scheduler
for job switching.
The scheduler also
receives control on asynchronous events from traps and
interrupts (this code is completely stack-reentrant in
the unmapped stack), but it enforces a logical disable
of monitor operations by returning to the point of
interrupt if the trap or interrupt occurred with the
monitor in control.
This scheduler-enforced logical
disable allows critical monitor operations, such as a
file
index
update
to run to completion before
permitting another user job to proceed and possibly
interfere with the incomplete activity.
55
UTS TECHNICAL
~mNUAL
SECTION BO
1/12/73
PAGE
56
Batch Jobs
Two ways of scheduling batch jobs which result in quite
different fractions of machine time devoted to batch
processing are reasonable in this priority structure.
Both are provided in UTS, and the mode of opration may
be selected by the installation manager.
The first scheduling technique keeps the batch job
stream in a separate queue
(BAT)
that has a lower
priority than the interactive compute queue indicated
in Table BD-3. Thus, batch jobs get service only when
no interactive user has a request.
Estimates from
current systems indicate that 10 to 20 percent of
compute time is available to batch processing on a
system supporting between 20 and 30 concurrent users in
prime shift. During nonprime time, 80 percent or more
of CPU time is available to batch jobs.
The second method of scheduling cycles batch jobs
through the interactive compute queue, where each job
receives an equal fraction of the available time.
It
is usual in on-line systems for 5 to 20 percent of the
on-line users to be computing at anyone time.
Thus,
as much as one-half of prime time, plus 80 percent of
nonprime time, could be devoted to batch background
operation. In this scheme, batch jobs can be biased to
get
a different quantum than on-line user, thus
permitting the installation manager to control the
actual percentage of computer time devoted to batch
processing.
b.
Memory Management
These routines control the allocation of physical core
memory, maintain the map and access images for each
user, service the get and free page CALs, and manage
the swapping space.
56
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
57
Core management includes the parallel management of
swap space. When a core page is requested, a swap page
must also ~e acquired. Similarly, a release of core
requires release of swap space. In order to provide
for fast swaps, space acquired must be contiguous, or
nearly so, to that already allocated. Further, the
program pure procedure is always placed last on swap
device so that it need not be written out if it is
unchanged. These two requirements make necessary a
shuffling of space on the swap device and corresponding
adjustment of· memory maps and swap command list when a
new data page is acquired.
Frequently no new core pages are available
when
requested.
In this event, memory management must
allocate the swap space and not the core space by the
'get virtual, no physical' process and cause an entry
to the swapper to provide the needed extra page(s)
through its normal swap scheduling algorithms.
Physical Core Allocation
Allocation of core memory pages to a user at his
request depends on the actual size of the machine as
determined during initialization, the current size of
the user including all needed shared processors and the
management set limits on user size.
Details of the
calculations are given below.
57
SECTION BD
1/12/73
PAGE
58
UTS TECHNICAL MANUAL
The following table describes how physical memory is
reserved for system functions in UTS:
AMOUNT (in pages)
(JITLOC+511)/512
9
6
3
1
1
1
USED FOR
HOW ESTABLISHED
Resident Monitor
XDELTA
Longest Overlay
(OPEN)
KEYIN Procedure
KEYIN JIT
Monitor JIT
Each Symbiont Device
SYSGEN
Answering "Y" to DELTA
during initialization
request.
Initialization
Initialization
Initialization
Initialization
Initialization
The above table shows that an SDK system with three symbiont
devices and a 27K monitor will have q1.5K in which to run
user programs if XDELTA is requested, and 46K if it is not.
In addition, pages must be reserved for the context area and
other things, as follows:
PURPOSE
HOW ACQUIRED
1
1
JIT
AJIT
n
DCBs
m
IPOOL/FPOOL
Buffers
2
CPOOL Buffers
8
TEL
Logon
Allocated when N pages
are acquired and is
never released once
allocated. N is 32 for
~7 and 13 on ~9 greater
than 128K.
Job step time, from
user program.
Job step time. A
minimum of two IPOOL
and two IPOOL are required; i.e., three
pages.
Automatic for batch
jobs, ·reserved if an
on-line user has symbiont access in his
account.
Reserved if user is
on-line.
PAGES
Note: n may be obtained from the
program-dependent.
58
LOADER
map
and
is
never
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
59
m may be altered using !POOL card; otherwise, system
defaults are assumed.
these defaults are defined at
SYSGEN time and may be altered using CONTROL.
Therefore, the maximum user program size run on-line on
the previously mentioned system, with two pages of DCBs
and the ~n1mum allocation of file buffers (three
pages) would be 33K with XDELTA and 37.SK without. The
maximum size of the same program in batch would be 37K
with XDELTA and 41.SK without.
An increase in physical memory will increase the
maximum size of a user program up to a point (less than
128K) where the limiting factor is the virtual memory
layout.
The first 32K of virtual memory is dedicated
to the Monitor.
The context area which includes
monitor overlays, buffers, DCBs, JIT, and AJIT follows
in the next 16K of virtual memory. The next 64K is set
aside for user programs, and the last 16K of virtual
memory is allocated to special shared processors and
shared libraries. 64K is available for user program
pure procedure and data, and 12K is available for user
context (DCBs, buffers), not including JIT and AJIT
maximum program size is 76K.
On Sigma 6 and Sigma 9 configurations with 128K or
less, an AJIT is required when the user size exceeds 32
pages.
On Sigma 9 configuration over 128K, this
threshold is 13 pages due to the larger memory map.
c.
Job Step Control
The collection of monitor resident routines called STEP
is entered between major segments of a job or an
on-line user's session.
Entries are made whenever
ERROR, EXIT, or ABORT CALs are executed or when a new
shared processor or new program must be fetched.
When
command processors (CCI, TEL, or LOGON/OFF) exit, they
do so with coded information in registers which are
used to associate a shared processor or fetch a
prepared load module.
(This exit is known as an
interpretive exit.) Prior to either type of fetch, the
user's core and swap RAD space are returned to the
available pool to be reacquired during the fetch.
Following the fetches, all DCB assignments associated
with the user are merged into the DCBs acquired in the
latest
fetch.
Required initialization of JIT is
completed.
59
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
60
Following an exit by LINK from the load phase of
processing a RUN command, step control sets up the
loaded program, core image for execution, including the
association of required shared debuggers and public
libraries.
Exit from CeI, TEL, and LOGON/OFF includes two other
'interpretive' exits. The first, to simply continue
the current activity, and the second, to do the final
cleanup after LOGOFF exits. The latter includes a test
for completion of a batch job.
If the job
is
completed, entry is made to the batch scheduler for
selection of another batch job for processing.
I/O, issued by STEP in order to fetch programs and
processors at user request, is handled as a special
high priority in order that good response time be
achieved in these cases.
60
UTS TECHNICAL MANUAL
3.
SECTION BD
1/12/73
PAGE
61
Symbionts, Cooperatives, and Multibatch Scheduling (RBBAT)
a.
Symbionts/Cooperatives
Records sent to and received from the
low-speed
peripherals (CR,CP,LP,PL,RBT)
are buffered to RAD or
pack through the symbiont-cooperative routines.
Four
stages are readily identifiable.
First, input jobs from the CR or RBT are blocked by the
input symbiont into disc unit records and written in
the peripheral storage area (PER).
This process is
carried out asynchronously with respect to other tasks
in the system and, once started, is interrupt-driven
until
completion.
Initiation is accomplished by
operator command for CR and is automatic for RBT.
The
input symbiont recognizes !JOB cards for CR and RAT and
treats them as beginning-of-file and end of previous
file (if any), recognizes !FIN cards for CR and RBT and
treats them as end-of-stream, and recognizes !RB cards
for RBT and treats them as beginning-of-file/end of
previous file as with !JOB cards.
At file end, the
file starting disc address is passed to RBBAT, the
symbiont file ghost job, for entry into the batch
tables.
Second, when a user issues a read directed to the card
reader, the operation is intercepted by the input
cooperative.
This routine reads and deblocks the
records for presentation to the reading program, which
is not allowed to read past the end of the symbiont
file containing his own job. Initially, the multibatch
scheduler selects the job to be run by placing the job
and resource information in the GET tables. The batch
user is started and the !JOB card CCl read causes this
information
to
be
placed
in
the user's JIT.
Thereafter, records of the file are passed to the user
on subsequent reads.
Third, the output cooperative, which is an intercept
routine acting on ali output directed to symbiont
devices, blocks records into buffers, and writes them
to secondary storage.
Separate symbiont files are
built for each type of output (print and punch). Upon
user signal ('superclose', usually at end of job), the
file is cloosed by entering it into the RBBAT queue via
the add output file communication.
61
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
62
Fourth
is
the interrupt-driven task (the output
symbiont), which reads symbiont files and writes the
symb10nt
device.
Output
symbionts
are started
automatically when RBBAT senses that there is work to
do, the device is idle and, otherwise, capable of
processing the output.
Symbionts use, for buffer memory, pages obtained from
the general pool of physical memory. This restricts
maximum user size in that a user must not be allowed to
exceed the available physical memory
ieft
while
symbionts are active.
The cooperatives use similar
buffer and control memory pages from the user's virtual
space. The buffer management routines get memory and
restrict
size
appropriate to the mapped/unmapped
(cooperative/symbiont) condition on entry.
Symbiont files are selected by the Multibatch Scheduler
(MBS) portion, RBBAT, for input and output by resource,
priority, system id, and control information maintained
by RBBAT. Priority by symbiont files which originates
from the job card (or on-line user default) may be
changed by the operator, who may also delete files.
Control
information (e.g., remote batch hold) is
specified by the user. Figure GA-1 shows the symbiont
and cooperative big picture.
b.
Multibatch Scheduler
Inputs
o
Job description (resource requirements) from JOB
and LIMIT cards. This information is carried in
input symbiont tables which reside in the RBBAT.
o
Partition definitions (permissible ranges
of
resource values) created by SYSGEN in resident
tables and modifiable dynamically during system
operation using CONTROL.
o
Maximums, also carried in resident tables and
changeable via CONTROL, which limit the total use
of each resource by all batch (or on-line)
jobs
taken together.
62
UTS TECHNICAL MANUAL
SECTION BD.
1/12/73
PAGE
63
New Job selection initiated whenever:
1.
2.
3.
4.
5.
6.
a job completes exeuction.
a new job is entered.
partition definitions are changed.
operator command 15 is issued.
Resources are released (by an on-line job
or by a CAL which releases resources).
Clock routine which checks a flag set by
certain cases of resource releasing.
Scheduling Algorithm
1.
Identify all available partitions (not executing,
not locked).
2.
Find the highest priority job which fits
the available partitions.
3.
Verify
that
execution
established maximums.
4.
Failing 3, increment job priority and go to
2.
5.
Verify that order and account parameters do not
preclude running the job.
6.
Run the job
passed.
7.
Go back to Step 1, unless:
a.
b.
c.
selected
if
would
all
tests
one
J
not
have
of
exceed
Step
been
The job was 'F' priority and not selected.
No partitions are available.
All jobs in the input queue have been processed.
63
UTS TECHNICAL
4.
~mNUAL
SECTION BD
1/12/73
PAGE
64
System Services
a.
System Initialization
UTS initialization routines accomplish three major
functions: booting from a system PO tape, booting from
system
resident
secondary
storage,
and
recovery-restart. The functions are accomplished by
common routines which distinguish recovery from booting
by zero contents of cell 2A which is always filled in
during a device boot by the hardware.
The initialization routines fall into three physical
groups: first, the routine INITIAL which initializes
trap and interrupt cells and loads locks and access
images both for booting
and recovery; second, the
routine BOOTSUBR which provides for monitor patching
and system storage initialization; and third, the
initialization job, GHOST1, which copies the system
tape to the system account, provides for GENMOD patches
to
processors,
and
completes
system
storage
initialization. The last two processes which have
similar functions are divided in order to remove as
much code as possible from the monitor root to job
status even though, in this case, it is a master mode
job. BOOTSUBR completes just enough initializatio~ of
the system to enable it to run its first job, GHOST1,
which completes the initialization task.
Figure BD-1
summarizes the initializarion process.
SECTION BD
UTS ""TECHNICAL MANUAL
1/12/73
PAGE
65
INITIAL
This routine is entered immediately after a tape or
disc boot has read in the monitor's root or after
recovery has done the same thing.
Its purpose is to
preset the hardware
for
system
operation.
It
accomplishes this in the following order:
1.
the unmapped JIT is moved from assembled location
to execution location;
2.
external interrupt cells are preset to zero;
3.
the trap and
initialized;
4.
the memory locks are set to 01 everywhere except
the code portion of the monitor, which is set to
11 ;
5.
the virtual memory map is preset in
correspondence with physical memory;
6.
access is preset to read-only for virtual page
zero and to no-access for the rest;
7.
I/O interrupts are enabled for tape boot;
counter for disc boot; and
8.
GETHGP
is
called
to
read
initialization is from disc.
interrupt cells 40 through SF are
65
in
one-to-one
CLOCK4
XDELTA
if
UTS TECHNICAL MANUAL
-0
0
0
0
al
c:Q
CD
--
Q..
0
I-
U
CIt
0
~
s-
CD
U
CD
0::::
~
II I 1
I
I
1
1
I
I
FIGURE BD-1 - Initialization Overview
>
0
1
I I
INITIAL
Move master JIT to Execution Location.
Zero external interrupts
Set up 40 through SF.
Load Locks, Access.
Enable I/O interrupts.
Enable CLOCK4 counter interrupts.
BOOTSUBR
MONINIT
Check and set assigns for C, LL, DC, COC.
Print and type patch numbers.
Type sense switch setting assignments.
Set up location 2B with proper monitor type.
Read in XDELTA.
Read card reader via XDELTA, patch root.
SWAPINIT
Copy ALLOCAT, GHOST1, Monitor Overlays
XDELTA, RECOVER to swapper.
Set up monitor tables with disc addresses.
WRTROOT
i
1
Write monitor root to swapper.
write bootstrap on swapper.
66
-oo
CO
0
0
CO
CD
U
ISS
.-
a.
I-
II)
0
~
,..
UTS TECHNICAL MANUAL
....
~
U
SECTION BD
1/12/73
PAGE
67
CD
0=:::
1T
I
GETHGP (Get XDELTA)
Set up memory size info.
Turn off symbionts.
Enable all interrupts.
GHOST 1
1
T,
.J.
1
J.
I
Ask about DELTA and keep or no; release core
of INITIAL and BOOTSUBR.
PASSO to read and patch (GEN1-10D) processors.
RECOVER2 for shutdown of open files.
SYSMAK: copy shared processors to swap RAD
Request date and time from operator.
Write start record in ERRLOG.
Initialize COC.
Turn on symbionts
Log on Analyze to process crash dump
Start scheduling batch jobs by start of RBBAT
ghost job; interpretive exit to PILL.
67
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
68
BOOTSUBR
Three subroutines of BOOTSUBR are then called if the
initialization is from a PO tape:
MONINIT, SWAPINIT,
WRTROOT.
MONINIT, the first subroutine of BOOTSUBR, carries on
the initial dialogue with the operator:
1.
it requests from the
operator
new
device
addresses for card reader, line printer, system
resident swapper, and COC, providing dynamic
reconfiguration for these devices;
2.
it prints the patch segment numbers and sense
swith setting both on line printer and on the
operator's console;
3.
it sets location 2B with monitor version and
type; version comes from the monitor information
record generated on the PO tape by DEF;
4.
it reads in EXEC DELTA and
monitor cells which locate it;
5.
it then passes control to EXEC DELTA to read the
card reader for monitor patches, interpret them,
and place them. If the ** card is read, a flag
is
set
to
control
the
'boot-under-the-file-structure'
operation,
in
which the PO tape is not read.
initializes
the
SWAPINIT,
the
second
subroutine
of
BOOTSUBR,
initializes the system portion of the swapping RAD.
Enough monitor elements must be placed to be able to
run the first job - the GHOST 1 initializer.
During
copying to the swapper of monitor overlays, ALLOCAT,
the elements of GHOST1, ~IDELTA, and the
RECOVER
overlays, the card reader is read by DELTA for patches
to them; monitor tables which record overlay swapper
locations are set up. This setup defines the portion
of system RAn which must be intact to accomplish
recovery.
Recovery uses the system swapper from this
point on (that which will be occupied by the shared
processors) to save the crash core dump.
68
SECTION BD
1/12/73
PAGE
69
UTS TECHNICAL MANUAL
WRTROOT, the third subroutine of BOOTSUBR, writes the
monitor root which is now fully initialized and patched
to the system swapper. The routine also writes the
disc bootstrap routine onto system swap storage.
INITIAL's Entry to GHOST1
Final activity
includes:
carried
out
before
entry
to GHOST1
1.
scanning memory for existing physical pages which
are linked into an available memory page poolJ
2.
enabling of all interrupts
(COC lines' are not
scanned by the clock interrupt routines until
later when the input external interrupt locations
are set up);
3.
temporary disabling of the symbionts so that
GHOST1 will use printer and card reader directly.
INITIAL exits through the job
calling for startup of GHOST1.
initialization logic
GHOST1, The System Initializing Program'
This master mode job contains all initialization and
recovery functions which can be run as a job (as
distinct from those functions which must be imbedded in
the monitor root).
The program takes differential
action on recovery (cell 2A = 0) and on disc and tape
boots.
Major elements included in GHOST1 are as
follows:
1.
RECOVER2, which is entered only in a recovery
situation to replace dynamic system information
like the date, to provide accounting summaries
for all interrupted jobs, to copy files that were
open in update mode and could not be closed
normally, and to copy the core dump from the
swapper to a permanent file,
2.
PASSO, which copies PO tapes to files,
the application of GENMOD patches,
3.
SYSMAK, which reads the shared processors from
files and prepares absolute copies
on
the
swapper.
69
including
UTS TECHNICAL MANUAL
SECTION BO
1/12/73
PAGE
70-
As shown in the schematic flowchart of Figure BD-2,
GHOST 1 first asks if EXEC DELTA is required.
If not,
or if there is no answer within six seconds, the
physical memory used by EXEC DELTA (from about 60-64K
physical) is released to the physical page pool and the
'Lees-watering-hole' entry to EXEC DELTA at location 4E
is disabled.
A
check of location 2A determines whether recovery (2A
= 0) or boot is intended. RECOVER2, PASSO, and SYSMAK
are entered, as shown.
Following a date-time request, if booting, common logic
is entered which:
1.
writes a startup
(or recovery) record into the
hardware error file,
2.
initializes terminal I/O by starting
turning on all line receivers,
3.
turns on the symbiont system,
4.
logs on a ghost job for Analyze (if recovering)
to process the crash dump,
5.
enters the batch job scheduler
still
in the input symbiont
recover, and, finally,
6.
exits through the monitor's interpretive exit
logic to activate FILL for possible reading of
backup tapes.
cac
I/O
and
to start jobs
queue after a
The flowchart Figure BD-3 shows PASSO's main
line.
execution
SYS~mK
copies the shared processors listed in the
monitor table P:NAME from files to locations on the
swapper with addresses, sizes, and start addresses
placed in the monitor shared processor tables.
70
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
71
entry
_ _,--.....-.-.,<~..~--...J....---~
.. ,. . . . . ".~.,.,,,_.=,.
_
Do you want Exec De Ita?
.~~;--------- I~~
~~I~~:~~re pages to physical pool,
I
reset XPSD in location 4E to an
effective NOP.
I
l---.------r---~- .._. _~.".
c •• _ ....".. '··
f~overy o~ Boo~?
,
t
disc·
"'"
Do you want HGP reconstruct? )
.---~
ape
f
).
No
r-· . ·
\ REi
ON
/
\ RECOVER2
.
PASSO\
BO-3.
/
. .,~I
&...-_---._-
I
I
-------
/----
1Fi9
,/
"-
(tiGP
.-------\
I
SYSMAK
/
_ _ _ _--J
SYSMAK
Write start record to ERRLOG
Initialize COC
Turn on Symbionts
Initiate Analyze, if recovery
Schedul e batch iobs
Exit to FILL
71
Figure 8D-2 Overview of GHOST1
SECTION BO
1/12/73
UTS TECHNICAL MANUAL
PAGE
72
Figure BO-3 - PASSO Overview
.-----_._.-_.._-/
\
PASSO
\~----I---.!
.____.._._ .. _. __ . ___ ._.... . . ..._.-.__L........ _ . _ __
Read Cards (GENMOO, GENDCB, etc)
saving them in a core buffer
'_
...
-
........... -.-. . . --····-·-·r--··-----·--···-····--····-·····--·· --
BITOTM
.!L____._~
Boot under fj les?
(was a ** card read?)
:.
~.
yes
-"'
-
/1
"
\
--.----
'
..
- ._..
. no
_"'--_.-
.-
Read all fi Ies from PO tape and wri te
them on fj Ie RAD using standard monitor
CALs and continuing until the fj ~e
LASTLM is encountered.
--_._-_._,
!
I
PHASEC
Open each file in the :SYS account and if
GENMODs exist for that file read it in, patch
it, and write it back on fj Ie.
r-----·
~.
eXit
72
UTS-TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
h.
73
Operator communications
The machine operator communicates his instructions and
requests
to
the
system through key-ins at the
operator's console. This 7012 console is a TTY-like
EBCDIC transmitting device connected to an MIOP. It is
usually designated TYA01. Since the device may be used
in only one direction at a time, the operator must
signal his desire to type by pressing the PCP interrupt
button. He is prompted for input with a !, carriage
return terminates the control message, and EOM deletes
it for a retry.
When the PCP interrupt button
is
pres~ed,
IOQ
recognizes the request and starts the console read
. operation into a dedicated buffer.
On completion of
the message, the ghost job for KEYIN is initiated. The
pre-established JIT for this job is read, and the
initial environment is pulled and executed as is normal
for job beginning. For the KEYIN job, the program is
contained
entirely
in
the
registers.
The
two-instruction program calls for association and entry
into the KEYIN overlay and for job deletion after
return.
The KEYIN overlay reads the input message from its
fixed buffer, interprets it and acts on the commands.
The overlay structure is used in order to provide
convenient direct entry to monitor routines and to the
monitor tables which KEYIN is directed to change or
display.
73
UTS TECHNICAL MANUAL
SECTION BO
1/12/73
PAGE
c.
74
Accounting and Performance Monitoring
CPU execution accounting is carried out
by
th~
incrementing of the CLOCK4 timer. This clock ticks
each 2ms into a cell in the JIT.
Addressing is
subjective, that is, the JIT of the current user is
selected by the setting of the memory map.
When the
map mode is not on, the time increments are accumulated
into the monitor's JIT located at the same physical
address that is occupied virtually by user JITs.
Thus, when the CPU is executing for a given user,
whether in his program or in the monitor -cting at his
request, time ticks are directed to his JIT via the
map.
When the monitor is operating unmapped in
servicing I/O or
terminal
character
interrupts,
processinq traps, providing symbiont I/O or scheduling
jobs - all general services which are not simnlv
allocatable to a single job
the time ticks are
accumulated to overhead cells in the master unmapped
JIT.
Two other breakdowns are performed on the CPU time
accumulated for each user. The two breakdowns result
in four separate CPU time accumulations.
Time is
separated at the CAL boundary accumulating time used by
the user program and monitor time used to carry out his
CAL requests. Honitor service and program time are
carried
separately also for UTS shared processor
execution and other proqram execution.
This
is
slightly different than BPM/BTM which counts processor
execution for all programs coming from the
:SYS
account. COBOL is the important processor which is not
shared and is therefore accounted for as a user
program.
Performance monitoring is carried out as an integral
part
of
the
UTS
system.
Subroutines
and
count-incrementing instructions are embedded in the
monitor at appropriate places. The counts which they
accumulate and the program to display these counts are
described in detail in the UTS System l-1anagement
Reference f.1anual.
74
UTS .'!-'ECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
75
Approximatelv one page of memory is
devoted
to
accumulation of data on system operation. In order to
keen the memory required small some reduction of the
data is done at the time of gathering. Along with sums
and counts for averaging, certain data is accounted for
by adding into an appropriate cell of a distribution
histogram.
d.
Automatic Recovery
The system recovery function is provided to restore UTS
to operational status very quickly
following
an
unrecoverable failure, which may be either hardware or
software caused. Some examples are memory parity error
by the hardware or an illegal memory reference trap
because of software error.
Each reported error is
checked to determine whether the entire system is in
danger (unmapped mode errors) or iT only one user is
affected (mapped mode errors).
In the latter case,
that user is logged off, or failing that, deleted, and
system operation continues.
In the former
case,
recovery is entered. Recovery consists of cleaning up
all
open-ended
information
(both
user
and
system-oriented information) and restarting the system
at initialization. If this occurs all terminal users
must log on again and the current executing batch
job(s) must be resubmitted.
Any job partially read
through the card reader must be reinserted. Jobs
already submitted but not yet in execution are saved
and need not be resubmitted. The recovery routine is
entered whenever hardware and software errors are
detected. Hanual entry is also provided for use by the
operator when the system cannot automatically recover,
such as if low core erased or the system loops.
When the recovery routine is entered, none of the
normal operating system is assumed to be operating.
Most routines of the normal system required
for
recovery are duplicated in the recovery routine, but
for automatic recovery a small resident recovery driver
is required intact. This driver brings in the bulk of
the recovery routine, overlaying the pure procedure
portion of UTS.
Certain monitor tables are also
required intact. This is verified where possible. If
the "recovery process cannot be completed, the operator
is instructed to reload the system from the PO and file
backup tapes.
75
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
The
recovery routine
per~orms
76
the following functions:
1.
Displays cause of failure.
2.
Takes a full core dump for later analysis.
3.
Closes all open files using default o,tions.
4.
Packages or releases all partial s"mbiont
5.
Packages error log.
6.
Informs users
7.
Saves time, date, error log pointers, accounting
information, s~biont file directory, and RAD
granule stack contents.
8.
Restarts
o~
system
files.
interruption.
and restores items saved above.
lihen any functions cannot be performed, these are noted'
on the operator's console.
If the
function
is
considered
minor,
recovery continues • . If it is
connected with file operations, the file identification
is noted and recovery proceeds.
If recovery determines that the RAD allocation tables
(HGP) or File Control Tables (CFU) have been destroyed,
then a routin~ is called to rebuild the II P bv reading
through the entire file hierarchy, recording RAD and
pack addresses as it proceeds. While this technique
cannot repair or replace file elements which have come
unlinked during the failure, it does provide a much
faster restart mechanism than reloading of files from
tape (about 15 minutes, as opposed to one to five
hours, dependinq on reload technique and file size).
76
UTS TECHNICAL 14ANUAL
e.
SECTION BD
1/12/73
PAGE
77
System Debugging
Although much system debugging is carried out by other
means and with other tools, UTS carries with it a
master interactive debugger called EXECUTIVE DELTA.
Language
features of this debugger are virtually
iqentical to those of user DELTA as described in the
UTS Time-Sharing Reference Manual.
EXECUTIVE DELTA carries with it an elided symbol table
for the monitor and may be entered through location 4E.
EXEC DELTA does not use (and therefore depend on)
monitor I/O and thus, may be used to examine, change,
set breakpoints and otherwise completely control the
operation of the system whenever such steps
are
necessary
for
detailed debuggginn or development
activities.
(~or
most crash analysis on
running
systems, the dumps taken by recovery and reported by
ANALYZE are adequate for finding problems.)
EXECUTIVE DELTA is loaded with the monitor's REF/DEF
stack and placed on the system PO tape by SYSGEN. One
of the first tasks of the boot routines is to bring in
EXEC DELTA and place in physical memory at approximate
location 60-64K. During the boot processes it may be
used to make svrnbolic patches to the system either
entered from the console or from the card reader.
At
the end of the boot process the onerator has the option
of retaining DELTA for possible later use or releasing
it and returning its physical soace to system use.
Once released EXEC DELTA cannot be regained except
through the recovery process.
77
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
f.
78
Error Logging, Diagnostic Device Access
Recording of hardware errors for analysis by customer
engineers is carried out by a special
procedure
designed to minimize the possibility of losing the
record of the errors.
Each device error, watchdog
timer trap, memory parity error, device timeout, etc.,
together with system startup and recovery records and
software-detected inconsistencies which might have been
caused by hardware errors are recorded by the resident
error logging routine into a pair of 64-word core
buffers which are then transferred to RAD in a simple
linked chain. A special CAL may be used to read this
file and a routine, ERR:FIL, is provided with the
system read this special file and, using standard file
management
operations, transfer it to a standard
managed file, ERRFILE. ERR:FIL is called as a ghost
program each time five error records are accumulated.
In file form, the records are accessible to customer
engineers and to two standard system programs, ERR:LIST
and ERR:SUM, for listing and summarizing the error file
contents.
Descriptions of these programs and of
ERRFILE record formats are given in the UTS System
Management Guide.
Also provided for customer engineers is a privileged
method for opening I/O directly to a device, bypassing
the symbiont operation. Thus, diagnostics may be run
on-line during system operation to diagnose, test, or
PM the peripherals.
In this special mode, the AIO,
TDV, and TIO status information from the device are
returned directly to the program via the DCB. Error
and failure records are still recorded in the error log
'-and privilege-controlled CALs allow direct reading and
writing of the special error file. Alternately, the
diagnostic program may cause. ERR:FIL to
transfer
records to the. standard file, ERRFILE, by issuing a
ghost job initiation CAL, and read the records from
that file.
78
UTS
5.
TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
79
User Service
This category encompasses most of the monitor routines which
are called at the explicit request of user programs, both
batch and on-line, through CAL instructions.
The major
categories are: a)
file management service for reading and
writing of files on tape, RAD,
and
disk
pack;
b)
load-and-link services; and c) batch debugging services.
Also in this category but not explicitly described in this
overview, are routines for the UTS-specific CALs, trap
control and timer CALs, the user program overlay segment
loading CAL, error log read and writing CALs, and the job
entry CAL.
a.
File Management
This category includes routines which manage
the
contents
of
and
access
to
physical files of
information. Included are the functions of indexing,
blocking and deblocking, management of the pools of
granules on RADs and disk packs, labeling, label
checking and positioning for mag tape, formatting for
printer and card equipment, and controlling access to
and simultaneous use of a hierarchy of files.
Four subgroups are identifiable:
1.
Basic routines for reading and writing files and
physical devices.
2.
Routines for opening and closing files.
3.
Routines to
changes in
WEOF, PEOF)
device DCBs
4.
Routines to service labeled tape.
service the CALs requesting position
files or on tape (PFIL, PRECORD, REW,
and those requesting DCB changes for
(all the M:DEVICE CALs).
The primary storage areas used by file management are
the DCBs and buffer areas in user virtual memory, and
the CFUs in resident core which control simultaneous
file usage.
Also in resident memory are 'monitor
buffers' from MPOOL, which are used primarily for
preparing operator console I/O. Occasional use of nCT
and IOQ tables occurs.
79
UTS TECHNICAL r·1ANUAL
SECTION BD
1/12/73
PAGE
80
All physical I/O is accomplished via the basic I/O
routine, IOQ. Entries to the file management routines
are via the CAL receivers, CALPROC and ALTCP.
b.
Load-and-Link Command
This set of monitor routines is contained in the
overlay, LDLNK, and processes the M:LINK and M:LDTRC
CALs.
They allow processors to pass control back and
forth from one to another in either a subroutine or
transfer-of-control fashion. COBOL object programs and
the MANAGE processor use SORT as a subroutine via
M:LINK; PASS3 of SYSGEN uses the Loader in a similar
way.
Communication between caller and callee is via
information stored in COMMON memory and in registers.
When an t1:LINK is issued, the entire program and
context, including open DCBs but not the COMMON memory
area, is saved in the star file idN where N is a binary
number incremented for each l-1:LINK. All memory except
COMMON is released and control passes to a point in
STEP to associate the indicated shared processor or
fetch the named program. The parameter N is passed to
the called program to identify the saved program for
possible return.
Two possible actions are available for M:LDTRC.
The
first is like M:LINK except that the current program is
not saved. The second occurs when the request names a
program file, idN, preserved by a previous M:LINK.
Current memory pages are released and the file idN is
read in. The file idN is released and the program
entered at its return point just following the M:LINK.
Cleanup is necessary for the saved program images after
program exit or abort and processing of any PMOs. This
need is indicated by a nonzero value of the link
counter, N, in the rightmost byte of the JIT cell,
J:RNST. Each idN file is read and all DeBs therein are
closed, the file is released, and finally, N is zeroed.
80
UTS TECHNICAL MANUAL
SECTION BD
1/12/73
PAGE
c.
81
Batch Debugging
Batch debugging services
include
program
MODIFY
commands, execution output and test via SNAP, IF, AND,
COUNT,-etc., CALs and control cards, and postmortem
dumps through PMD commands.
These commands are read, processed, and'executed by the
coordinated action of the processors CCI and RUNNER,
the root element STEP, and the monitor overlay DEBUG.
The processors read and prepare tabular forms of the
commands while the monitor elements carry out the
indicated actions.
The process begins when eCI reads the MODIFY, SNAP,
PDM, etc., cards which follow the RUN command in the
JCL stream. A RUN table is built from the information
on the RUN card and left in high virtual memory for use
by RUNNER and STEP. For each card read after the RUN
card, a record is written into the star file, idD. A
flag is left in JIT to indicate the presence of PMDs
and a count of the number of other debug cards is left
in the run table and CCI exits indicating the required
load module fetch to STEP.
The fetch portion of STEP calls the special shared
processor, RUNNER, as an aside in order to process the
idD file. RUNNER reads the file and creates two tables
in core, the first of which contains location and
contents values corresponding to MODIFYs and SNAPs.
The second table contains FPTs for the debug CALs. PMD
and PMDI records are left in the idD file.
The head and tree of the load module requested (as
recorded in the RUN table) by the original fetch are
read by RUNNER, the size of the pure procedure area is
determined, the two tables are moved into position just
above it, and the head and tree records are updated to
reflect the additional pages (if any) and the LM start
address.
The page containing the Run
table
is
released.
STEP interprets the final exit from RUNNER and, after
completing the load module, fetch places the MODIFYs
and SNAPs in the appropriate locations in the user
program as indicated in the Rm~ER prepared tables.
The user's program is then placed in execution.
81
SECTION BD
UTS .TECHNICAL MANUAL
1/12/73
PAGE
82
When SNAPs, IFs, COUNTs, etc., are executed, the CAL
receiver associates the DEBUG overlay which provides
the dumps and other required operations.
On final exit from the user's program, if either the
flag indicating idD presence is set, or if the program
exits with an error or abort indication, then STEP
associates the DEBUG overlay. The TELUSER portion of
this overlay processes error and abort codes into
messages and appropriate dumps, while the PMD portion
processes
PMOs
from the idD file, provides the
indicated dumps, and releases the idD file.
Return to STEP is made for the
step shutdown procedure.
82
remainder
of
the
job
UTS TECHNICAL MANUAL
SECTION BE
1/12/73
PAGE
83
MONITOR PHYSICAL STRUCTURE
This
section
summarizes
the
UTS monitor by listing and
functionally noti~g each of the system modules. The modules are
summarized in S1X functional categories, then each category is
detailed, module by -module, as to function and size. Finally, the
utility processors (as distinct from language processors, which
are delivered with the system) are listed by function and size.
Sizes and exact module content are approximate only; they are
accurate for a particular version of UTS. The gross size of the
system can also be estimated from the size of the compressed
source files (280 files totaling 2400 granules) and from the size
of a typical :SYS account (175 files totaling 3100 granules),
although this later value is highly dependent on individual
installation desires.
Modules are grouped by place of residence in four categories:
1.
MONITOR ROOT - These routines are loaded together, enter the
machine at system boot time, and are never replaced except
during recovery.
2.
VIRTUAL OVERLAY - These groups of routines are required to
perform specific user serivces.
They are loaded with the
REF/DEF stack of the monitor root and communicate directly
with it.
They run in master mode but are mapped. They act
as map reentrant shared processors
only one copy is
required for all users.
More than one overlay may be
physically resident in the CPU if appropriate in light of
cumulative user size and processor association.
3.
PHYSICAL
OVERLAY
Three kinds are used: a) monitor
initialization code booted with the root but where space is
reclaimed after startup; b) space is physically reserved
permanently for execution of DELTA if that debugger is
selected at boot time; and c) the recovery routines are
loaded over code of the root monitor.
4.
PROCESSOR - The utility routines of UTS are mostly user-style
programs running in slave mode and mapped.
Some of the
programs are shared processors and others are ordinary
unshared ones.
Two exceptions are
the
initialization
program, GHOST1, which runs in master mode in order to patch
the monitor and to establish shared processors on the swapper
with direct execution of I/O commands, and the granule
allocation program, ALLOCAT.
83
UTS TECHNICAL MANUAL
SECTION BE
1/12/73
PAGE
84
Root size is summarized in Table BE-1.
Table sizes are detailed in Table BE-2.
Typical
size
of modules in loading order is given in Table BE-3.
Differences between a large and a minimum
Table BE-4.
monitor
are
given
in
The major SYSGEN parameters which control root size are given in
Table BE-S.
84
UTS TECHNICAL MANUAL
SECTION BE
1/12/73
PAGE
85
Table BE-1 - UTS Root Size
Code
BASICS
6900
System Management
6100
Symbionts and COOP 1700
System Services
User Services
400
5300
20,400
Tables
Fixed Size
1400
Variable Size
8000
TOTAL
Large 128 user systeM
(small system = 2800)
in variable tables1
a difference of 5200)
29,800
85
UTS TECHNICAL MANUAL
SECTION BE
1/12/73
PAGE
86
Table BE-2 - UTS-C01 Resident Tables
INITIAL
DEF
NAME
DECIMAL
SIZE
SYSGEN
COMMAND
DESCRIPTION
Fixed Size Tables and Assembly Parameterized Tables
SSDAT
PPP
PMDAT
HGPSTK
CFUD
598
PPP
PMDAT
BUFSPD
CFUD
4
218
424
6
M:OLIMIT SL:OTIME
14
:OLIMIT
M:ELIMIT SL:ETlME
14
:ELIMIT
M:BLIMIT SL:BTIME
14
:BLIMIT
COMBAT
74
GI:SDA
Ghost job tables, swapper skeleton command list and
disc address, swapper page pools, swap scheduler
tables
Physical page, pool data
Performance monitor counters and distribution
Granule allocation stacks, pointers, comm. buffers, etc.e
Parameters definitions for Packs and RADs
(sectors/track, etc.)
Default limits (print, punch, time, core, etc.)
for on-line
Limits (print, punch, time, core, etc.)
for exit control
Default limits (print, punch, time, core, etc.)'
for batch
Contains GETI tables and RBBAT symbiont and MBS
communication buffers.
SYSGEN-Generated Variable Size Tables
M:COC
M:SPROCS
M:IMC
M:CPU
IOTABLE
COD:LPC
P:NAME
S:CUAIS
MPOOL
IOTABLE
M: SDEV
SSTAT
PL:LK
M:PART
1100
550
650
4370
1150
34
-
138
8 000
:COC
Terminal I/O control tables and buffers
:SPROCS
Shared processor control tables
: IMC
System control parameters, user tables for scheduling, etc,
:UTM
MPOOL, CPOOL, IOQ Tables, CFUs, PPUT, Sigma 9 PSDs
:CHAN,:DEV DCT, CIT, OPLABEL, TPMEN, AVR Tables, Remote Batch
Control Tables, Swapper configuration definitions, HGP
skeletons, private HGPs
:SDEV
Symbiont control tables
: PART
Multibatch partition control tables
UTS TECHNICAL MANUAL
Table BE-3
Name
Decimal
Size
Begin
SSDAT
PPP
PHDAT
100
598
4
218
SLI~1S
0
COCD
COCI
Tables
M:COC
H:SPROCS
r1: IHC
H:OLIMIT
H:BLIHIT
r·1:ELIHIT
REQDC
CFUD
RECORD
CHK
l~:CPU
I'1:BIG9
IOTABLE
11: SDEV
COHBAT
H:PART
HGPSTK
lNlTRCUR
GPHGP
CLOCK4
ACCT
Handlers
48
76
623
1100
550
650
14
14
14
64
6
2
28
4370
0
1150
34
78
138
424
100
18
155
52
419
Name
-
\J
Cl)
E
"-
Cl)
a...
Cl)
0i:
~
~
Q)
...a
c
t-
c:
'0
~
0
U
en
Q)
:::>
\J
0
~
Q)
-g
u
--e
SECTION BE
1/12/73
PAGE
87
TlEical Contents of UTS-DOO
In Loading Order
Decimal
Size
CRDOUT
90
PLOT
14
SKD
728
7TAP
102
DPACK
140
COC
1982
TSIO
432
ANSTP
256
S9TRAP
170
2741 Tables 384
ERHNDLR
394
FBCD
21
SSS
2388
STEP
1906
1111
1018
CALPROC
203
ALTCP
542
P14
264
T:OV
214
1346
lOO
ENTRY
202
BUFF
58
GRAN
260
GRANSUB
263
ADD
86
SUB
19
AVR
160
COOP
312
SUPCLS
296
SACT
163
\J
Cl)
u
Cl)
---
0..
I
Cl)
"-
~
87
Name
OUTSYl·1
INSY~'1
SUSPTERM
SYr.1SUBR
IORT
RDF
NRTF
WRTD
PFSR
INITIAL
JIT
BOOTSUBR
Decimal
Size
361
212
24
50
757
2345
1158
622
73
246
512
964
>-.
c
-
0
c
Cl)
\J
°Vi
Q)
a:::::
>-.
c:
0
c
oz0
0
N
0
00-
c
UTS
TECHNICAL MANUAL
SECTION BE
1/12/73
PAGE
88
Table BE-4 - Differences Between a Large and
Minimum Resident Monitor
Large Resident
~1inimum
29,800 Words
Resident
23,500
6,300
cac
Without 2741, etc.*
800
Handlers: DISK, ANSTP
400
COC Tables & Buffers
128 Lines
1,100
Symbiont Tables, CFUs
Monitor Buffers, Patch
4,000
6,300
*SYSGEN options will remove 384 words of 2741 translation tables
from the monitor load. To recover code for 2741 handling, the cac
module must be reassembled. A total of 760 locations may be saved
in COC by eliminating 2741 code, page heading, logic, buffer
checking, and performance monitor entries.
88
SECTION BE
1/12/73
PAGE
89
UTS- TECHNICAL MANUAL
Table BE-5 - UTS-DOO Monitor
Size Increases due to SYSGEN Par"amete"rs
MODULE
FACTOR
SYSGEN
KEY~RD
~1:COC
4 words per buffer
5-3/4 words per line
BUFFERS
LINES
M:SPROCs
9-1/2 words per shared
processor entry.
10 if Disc Swapping or BIG9
10-1/2 if Disc Swapping and
BIG9.
:SPROCs entries
r4: IMC
7 words per user
2-1/4 words per ghost job
~fAXG+MAXB+MAXOL
34 words per MPOOL
8 words per IOQ
19 words per CFU
6-1/4 words per tape if ANS
system
1 word per input symbiont
file
1 word per output symbiont
file
1-1/4* «AVGSER*16)+3+17
words
1/4 word per physical page
(1/2 word if BIG9)
18 words for Sigma 9 PSDs
Patch Space
2-1/4 words per RBT device
MPOOL
QUEUE
CFU
13-3/4 words per OCT
2 words per CIT
3-1/2 words per tape and
private pack (AVR)
8 words per public HGP
20 words per private pack HGP
1 word per DCT+AVR IOCTQ
6-74-word CLIST per device
One per :DEVICE
One per : CF..AN
One per PRIV + tape
r·1:CPU
IOTABLE
2-1/2 words per RBT device
89
MAXG
:DEVICE
INFILE
OUTFILE
AVGSER
CORE, (BIG9)
SIG9,BIG9
MPATCH
:DEVICE
One per pack or RAn
One per PRIV
One per device:
Punch - 74
SKD
- 74
DP
- 12
Other - 6-8
:DEVICE
UTS TECHNICAL MANUAL
M:SDEV
SECTION BE
1/12/73
PAGE
90
6-3/4 words per symbiont
device
:SDEVICE names
M:PART
7-3/4 words per partition
Maximum n in PART,n
S9TRAPS
169 words for Sigma 9 traps
SIG9,BIG9
90
SECTION BE
UTS TECHNICAL MANUAL
1/12/73
PAGE
Basics
Control & I/O
Device Handlers
Terminal I/O &
Buffering
Root
'!100
Virtual
Monitor
Overlay
Physical
Monitor
Overlay
91
Ghost Job
or
Processor
1100
2500
6900
System Mana2ement
Scheduling &
Swapping
2388
Memory Management
1589
(Core & Files)
Job Step Control
1906
f.1oni to rOve r 1 ay
control + CHK
242
Multibatch Scheduling
Symb. File Handling
and Remote Batch
1700
680
3800
1rn25
System Services
Initialization
Operator Communications
Accounting &
Performance
Monitoring
Recovery
System Debugging
113
1200
10700
1800
300
7000
4400
400
User Services
5300
File Management
Load & Link
commands
Batch Debugging
commands
Other User Services
~
Tables
TOTALS
l.finimum Size
11900
800
1700
3600
1900
9400
29800
24,600
19800
91
12600
17100
000
Size
No.
Lines
ALTCP
542
886
CAL P ROC
203
358
CLOCK4
155
323
TABLES
623
671
1346
202
2028
258
73
121
lOa
ENTRY
PFSR
S9TRAPS
"-0
~
(I/O Device
Handlers
170
1100
PTAP
(143)
172
PLOT
7 TAP
MTAP
MAGTAP
CRDOUT
DPAK
FBCD
( 14)
(41 )
(71 )
( 162)
90
140
44
128
296
54
TSIO
DPSIO
432
(688 )
.683
Descri
rap
nterrupt an erS1
I/O Queueinn:
Secondary C , Processor 1
trap processing
CAL receiver and distributor
(direct for CAL1,1 CAL1,2)
Clock 3 handler (time of day,
timed-events)
Constants, dates, error log
routine & buffer, WD trap
memory parity interrupt, file
account directory index
Central I/O queueing and dispatching
Central XPSD receivers1 routines for
traps and interrupts
Power fail-safe recovery
Trap & interrupt handlers for the
Sigma 9
Device-specific'I/O start & recovery
routines'
, pr n er, car rea er,
tape, operator console
Paper tape handler (not teletype
terminal top)
Plotter handler
Seven-tracK tape handler
Nine-track tape handler
Common mag tape routines
Card punch handler
Disk pack (7242) handler
Hollerith to EBCDIC (026 to 029)H
conversion
Swapper I/O routines
Swapper I/O routines for
disk pack swapping
'"tJ '"
>'m
Q-n
m~;:!
'10
W
z
~
o:J
m
-'
(function)
LM Name
('l'erIriinai flo
Handler)
ROM
Compressed
COC
(1364)
COCI
COCD
DOO
Size
No.
Lines
2500
2791
1982
2378
76
143
48
622
384
(System Management)
BUF
5950
7'945
1018
1899
58
146
260
GRAN SUB
SSS
253
2388
454
328
3602
STEP
1906
2482
T:OV
CHK
214
28
248
GRAN
(Symbionts &
Cooperatives)
430
1675
COOP
86
161
312
554
INSYM
OUTSYM
212
361
400
64
142
SACT
163
488
SUSPTERM
SUPCLS
24
296
437
50
109
ADD
REQDC
SYMSUBR
571
35
Description
Teletype terminal (7611) handler and
buffering routines including 2741 code
Initialization for 7611
Data areas for terminal I/O, not
generated by SYSGEN
2741 Translation tables
Scheduling, swapping, memory management
step control
Memory management - core & swap
RAD pages
Core buffer management
File & symbiont granule management
Granule management subroutines
Scheduler for swap & execution 7
swapping
Job step control - exits, program
fetch, assign merge
Monitor overlay association
System consistency checking
RAD buffered and queued I/O for
printers and card e~uipment
Move Input informat10n to JIT.
Input cooperative & common routines
for cooperatives
Input symbiont for card reader
Output symbiont for punch & printer,
deletes symbiont files
Disc and core allocation for symbionts
and cooperatives
Start & restart requests for buffers
or I/O
Type suspended & terminated messages
Close output coop files1 output coop
routines
Miscellaneous symbiont routines
(function)
LM Name
ROM
Compress'ed
(Initialization)
DOO
Size
1325
No.
Lines'
BOOTSUBR
964
956
INITIAL
INITRCVR
GPHGP
246
100
285
18
57
KEYIN (operator
communications)
121
1850
DELPRI
DISPLAY
IOREC
KEYN
KEYSUB
(Other System
Services)
52
110
507
30
1190
465
86
1716
68
139
300
ACCT
PM
RECORD
RECOVER
CYCUSR
RCVCTL
SYMFILS
TSTHGP
52
88
264
2
568
7050
2560
2750
660
1071
187
1324
590
523
980
Boot from tape or RADi space reclaimed from root after root
Initlalizer & patch monitor portion
of swap RAD - all space reclaimed
Turns on system & initiates GHOST1
Initialization or recovery entry
Read XDELTA
Operator Command Processor,
virtual overlay
Delete symbiont files & change
priorities
Display key-ins
Device I/O recovery key-ins
All ather key-ins
Symbiont command analyzer
System instrumentation, Root resident'
CPU accounting
Performance monitoring
System event trace recorder & buffer
1
Recover from crashes, physical monitor
, overlay
UTS-specific - process users
Recovery control
Symbiont file recovery
File system recovery
Executive (monitor) debugger dedicated physical, if used.
XDELTA
DELSYMS
SYMTAB
XDLT
XDELTA
730
357
3661
4808
Symbol table for Exec DELTA
Debugger
(function)
LM Name
Fl. e Management
ROM
ressed
DOO
Size
CFUD
IORT
. 350
3430
NRTD
622
919
WRTF
1158
1592
4775
LTAPE
ARDL
250
359
LBLT
1289
1669
243
430
RDL
OPEN
Labeled tape operations:
virtual overlay
Read labeled tape reverse
Write labeled tape & general purpose
labeled tape out routines
Read labeled tape records
All open operations:
virtual overlay
Open subroutines: scan FPT, check
na~es, file security checks
Open labeled tape - output
Open files & device DCBs except tape
Open labeled tape - input
Open free form mag tape
3000
OBSE
291
490
OPLO
OPN
213
1610
363
2074
1201
OPNL
OPNTP
CLOSE
LDLNK
1175
256
2345
ANSTP
RDF
Descri tion
Fl. e & tape rout1nes, root reS1 ent
304
53
AVR
MUL
No.
Lines
887
12
56
2860
CLS
DLT
1998
2721
867
1160
MUL
nUL
OBSE
1330
LNKTRC
1046
1389
291
490
850
1103
~
Monitor overlay for all close
°ferations
C ose DCBs
Delete records and files
Honitor overlay which creates
treed indices
Create treed 1n 1ces .or
Security checks, etc.
Load-and-link, load-and-transfer;
virtual overla
(function)
LM Name
DEBUG
ROM
Compressed
DEBUGTV
PMD
TELLUSR
SNAP
DUMP
IODTYPR
TYPR
100
MISOV
000
Size
1700
11
No.
Lines
28
370
500
250
590
990
622
122'5
808
1043
320
508
664
430
Description
Batch debug commands; virtual overlay
Entry vector for debug overlay
Postmortem dumper
Batch error message generator
Execution time routines for debug CALs
Core dump routine for SNAP, etc.
Tape mount and dismount, messages
M:DEVICE & M:SETDCB CALs
2360
UCAL
600
1000
TRAPC
150
RDERLOC
T:DSMNT
T:JOBENT
TFILE
280
190
200
350
100
280
TIM
POS
120
400
200
580
SEGLD
320
470
(Data Tables)
140
580
145
UTS CALs
Trap control CALs
Read and write special error log file
Print tape dismount messages at logoff
Symbiont file insertion CAL
Record temporary file name for release
at end of job
Time CALs
Positioning operations
Load overlay for user program
9400
SSDAT
600
411
PPP
PMDAT*
4
218
HGPSTK
424
145
218
51
6
53
CFUD
H:OLIMIT*
14
M:ELIMIT
14
M:BLIMIT*
14
COMBAT
M:COC*
74
1100
*
*
*
**
GJOB tables, swapper she!! command
lists, miscellaneous tables
Physical page pool data
Performance monitoring buffers
Granule allocation stack, points,
communication buffers, etc.
-0 Vl
»""-m
G')-n
m~;:j
......0
W
Default limits (print, punch, time,
~
etc.) to on-line
Limits (print, punch, time, etc.)
for exit control
Default limits (print, punch, time,
etc.) for batch
Contains communication buffers for RBBAT
Terminal I/O command tables from :COC
SYSGEN command
z
0'
m
(function)
LM Name
ROM
co;ressed
M: PROCS'
M:IMC*
000
Size
550
M:CPU*
4370
IOTABLE*
1150
M:SDEV*
M:PART*
650
34
138
*Data and Tables generated by SYSGEN.
No compressed or source corresponds
. to the ROMs.
~*Size
depends on SYSGEN parameters this example is a 45-user system for
the Xerox Data Center which is approximately typical.
No.
Lines
••**
*
*
*
Description
(function)
LM Name
ROM
Compressed
GHOST 1
BITOTM
No.
Lines
10675
220
178
DOO
ceIO
CLS1
GHOST1D
MODIFY
PHASE A
PHASE B
1180
273
465
523
362
496
1414
PHASE C
328
990
PODCBS
RECOVER 2
SYSMAK
296
1360
860
84
1331
1033
ACCTSUM
1760
1850
MAILBOX
HGPRECON
RCVRIO
180
3180
166
3090
510
413
ALYHD
M:HGP*
ALLYTL
GRANSUB
ALLYCAT
RBBATM
MBS
RBBATR
8
66
253
352
9
328
460
Description
System initialization - tape boot or
recovery. A master mode user.
Move modules from boot tape to
file RAD
Reads PASSO control cards
Character scan routines
Ghost 1 driver
Subroutines for GENMODs
Process GENCHN, GENOP, GENDCB
Process GENMODs, GENDICTs builds tables
Executes changes as dictated
by PHASE B
DeBs for GHOST1
Restore systems data saved by RECOVER
Initialize swap RAD with shared
processors
Produce accounting for jobs shut down
during recovery
Recovery messages to users
Rebuild HGP tables for recovery
I/O routines for Rrecovery
Ghost jobs which allocate RAD and
. pack space
Granule counters, master account
directory pointer
The HGP maps for granule allocation
List of AD granules & first name in each
Granule allocation routines
Control module - comm. buffers,
stack-adjusting, counting
3810
3085
370
350
*Data and Tables generated by SYSGEN.
No compressed or source corresponds
Id:nthe ROMs_
403
228
748
482
770
680
AL~OCAT
RBtiAT
Size
2955
481
394
symbIont file control
Multi-batch scheduling
Symbiont file recovery
UTS TECHNICAL MANUAL
SECTION BE
1/12/73
PAGE
99
UTS UTILITY PROCESSORS
PROCESSOR
LMN
APPROX.
TOTAL
SIZE
ANALZ
BATCH
CCI
CONTROL
4254
869
7177
3546
DEF
DEFCOl-1
DELTA
DRSP
EASY
EDCON
EDIT
ERR:FIL
3961
200
3810
3700
E~:LIST
2642
4288
1817
3451
1331
230
3496
3207
ERR: SUM
ERRMWR
FILL
FPURGE
LABEL
LINK
LOAD
LOCCT
LOGON
MEDDUMP
3798
8138
809
2570
12700
PASS2
PASS3
PCL
PFIL
RATES
REW
RUNNER
SUPER
SUMMARY
11647
2468
3121
1800
516
1800
1900
2350
21800
SYl-iCON
TEL
UTSPM
ttffiOF
1144
3767
9600
1800
DESCRIPTION
Crash Dump Analyzer
Terminal Batch Job Entry
Batch Control Command Interpreter
Installation Management Displays
and Controls
System Tapewriter for SYSGEN
Extracts REF/DEFs from LM
User Debugging Language
Dynamic Replacer of Shared Processors
GE Mark II Command Processor
Compressed Deck to Edit File
Editor for Symbolic Files
Hardware Error Logging
Hardware Error Log List
Hardware Error Summaries
Centralized Error Message Filewriter
File Save, Restore, and Auto PURGE
File Save/Restore Program
Pre labels ANS tapes
On-line/On-pass Loader
Overlay Program Loader (Link-Editor)
Loader Command Tablewriter
Job/User Logon/Logoff Control
Pack and RAD Surface
(Cylinder-by~Cylinder Dump)
SYSGEN Monitor Table Compiler
SYSGEN Loader Runner
File & Device Copying Utility
Position File Control Command
Charge Rate Table Creator
Rewind Control Command
Debug Command Preprocessor
User Authorization File Maintenance
Performance Monitor History
File Processor
LM REF/DEF Stack Manipulator
Terminal Executive Language
Performance Monitor
Write-End-of-File Control Command
99
SECTION BE
1/12/73
PAGE
100
UTS TECHNICAL MANUAL
BPM MODULES
UTS
LDPRGM
EXIT
PRGMLDR
STEP
}
MEMALOC
EQUIVALENT
DESCRIPTION
Load and Execute Programs
MXXX, M:ERR, M:EXIT
Load Programs
MM
Core & Swap
RAD
LNKRT
LNKLDTRC
LNKIO
l
LNKTRC
Load & Link CALs
CHKPT
CHPTDCBM
}
None (TELSAVE/GET
Checkpoint
REC
REC
REC
REC
}
RECOVER
CNTC
COOP
FILE
BTM
MONSEGLD
T:OV
COOPRES
COPNRES
SYMCR
SYMPPRTY
SYMC OM
COOP
SUPCLS.
INSYM
OUTSYM
KEYSUB
Management
. System Recovery·
Monitor Overlay Control
}
100
Symbionts & Cooperatives
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
101
UTS PROCESSORS
The UTS Operating System consists of a monitor and a number of
associated processors (Figure BF-1). The monitor provides overall
supervision of program processing and the associated processors
provide spe·cific functions, such as compilation, execution, and
debugging.
Processors operate in slave mode and thus request all I/O and
other master mode services through monitor CALs like an ordinary
program. CeI, TEL, and LOGON have store access to JIT in order
that they may update accounting and other information stored
there. These programs (command processors) also have a special
interpretation applied to their EXIT CALs to provide the mechanism
for calling other programs or processors into service. Special
EXIT interpretation also applies to LINK
to
provide
the
load-and-go facility of the. RUN command.
All processors are independent loads except those that use JIT
which are loaded with the JIT definitions. Many shared processors
are single assemblies. Exceptions are CCI, PCL, and the Public
Libraries which consist of many assemblies. Further, processors
may be shared - that is, a single copy is established at system
boot time in absolute form on the swapping RAD and then shared by
all concurrent users. An ordinary shared processor may have a
single level overlay structure; that overlay is also shared amonq
all concurrent users. Processors may be special - that is, they
reside in the highest 16K of virtual memory. This is because the
user's program already occupies or may soon occupy the remainder
of virtual memory.
debugging language
Public
Libraries,
DELTA
(the
on-line
batch
interpreter), LINK (the on-line Loader), RUNNER (the
debugging language preparation program), and TEL (the on-line
executive language interpreter) reside in the special shared
processor area.
Processors may require that the user have a certain privilege
level in order to run.
Examples are CONTROL, DRSP, ERR:SUM,
ERR:LIST, RATES, and SUPER.
101
- UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
Five kinds of shared processors may be associated with a given
user at one time:
1) an ordinary shared processor, 2)
the
ordinary processor's overlay, 3) a monitor overlay, 4) a public
library, and 5) a debugger (DELTA
is
the
only
current
possibility).
TEL may be associated and used without forgetting
the other processor associations. DELTA and Public Libraries may
be used by the same program but breakpoints may not be set in the
library nor can DELTA make use of the library subroutines.
Processors
Processors are illustrated in Figure BF-1 at two levels.
The
upper level contains executive language and related processors,
and the lower level, all other processors. These processors are
defined in the following paragraphs.
Executive Language Processors
The three processors in this group are: LOGON, TEL, and CCI. The
first two of these processors are available to on-line users only
and the last to batch users only.
It is also possible to
implement other command processors, such as UTS-EASY.
LOGON
LOGON admits on-line users to the system and connects the user's
terminal either to TEL or to an alternative processor, such as
BASIC that has been selected by the user. User authorization is
established by reading the file USERS for a record keyed by the
concatenation of the LOGON account and name.
LOGON
also
disconnects a user from the system and does the final cleanup and
accounting (reference: Section PC).
102
102
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
103
Terminal Executive Language
The Terminal Executive Language (TEL) is the principal terminal
language for UTS.
Most activities associated with FORTRAN and
assembly language programming can be carried out directly in TEL.
These include such major operations as composing proqrams and
other bodies of text, compiling and assembling programs, linking
object programs, initiating execution, and debugging proqrams.
They also include such minor operations as checkpointing on-line
sessions, determining current user charge status, and setting
simulated tab stops (reference: Sigma 7 UTS/TS Reference Manual,
Publication No. 90 09 07).
Control Card Interpreter
The Control Card Interpreter is the batch counterpart of TEL. It
provides the batch user with control over the processing of batch
programs just as TEL provides on-line users with control over the
processing of on-line programs. Authorization for batch jobs is
obtained by reading the USERS file and final job exit is through
LOGOFF (LOGON).
103
UTS TECHNICAL MANUAL
Figure BF-l - UTS Logical Structure
SECTION BF
1/12/73
PAGE
104
Monitor
Basic Control
Scheduling & Swapping
Memory Management
File Management
Job Step Control
Terminal I/O
Symbionts & Coop.
Sys. Integrity
(Recovery)
LOGON/LOGOFF
System
Management
Processors
SUPER
CONTROL
RATES
FPURGE
FILL
ERR:LIST
ERR:SUM
MEDDUMP
VOLIN IT
UTSPM
SUMMARY
DRSP
Terminal Exec.
Language
(TEL)
User Command
Processor
e.g., EASY
Language
Processors
FORT. IV
Metasymb.
BASIC
ANS-COBOL
MANAGE
FLAG
Initialization & Startup
Operator Communication
Batch Debuggging
System Debugging
Load-and-Link
Real-Time Serve (Proposed)
Remote Batch Serve
Exec. Control
Processors
Link
Load
DELTA
FDP
Libraries
(FORTRAN)
104
Utility
Processors
Edit
PCL
SYSGEN
DEFCOM
SYMCON
ANALZ
BATCH
Control Connnand
Interpreter
(CCI)
Application
Processors
SORT/MERGE
1401 SIM
DMS
GPDS
SL-1
CIRC
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
105
System Management Processors
System management. processors furnish the manager of a
~s
installation with on-line control of the system. Eight system
management processors are supplied: SUPER, CONTROL, RATES, DRSP,
FPURGE, FILL, ERR:LIST, and ERR:SUM.
SUPER
SUPER gives the ins~allation manager control over the entry of
users and the privileges extended to users. Through the user of
SUPER commands, the installation manager may add and delete users,
specify how many central site magnetic tape units a user will
have.
lie may also grant certain users,
such
as
system
programmers, special privileges, e.g., examining, accessing, and
changing the monitor.
All commands result in creation
or
modification of the file USERS in account :SYS.
CONTROL
The CONTROL processor provides control over system performance.
UTS has a number of performance measurements built directly into
the
system.
Commands of the CONTROL processor enable the
installation manager to display these measurements and to "tune"
the system as needed by setting new values for the parameters that
control system performance.
RATES
The RATES processor allows the installation manager to set
relative charge weights on the utilization of system services.
Specific items to which charge weights may be assigned include the
following:
1.
2.
3.
4.
5.
6.
7.
8.
CPU time
CPU time multiplied by core size
Terminal interactions
I/O CALs
Console minutes
Tapes and packs mounted
Page-date storage
Peripheral I/O cards plus pages
105
t1I'S TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
FPURGE
106
The FPURGE processor allows the installation manager, through the
computer operator, to purge unwanted files from the system.
Specifically, FPURGE provides for:
1.
Purging
2.
Loading (restoring) RAD storage with files that were created
and saved under the Batch Time-Sharing Monitor (BTM) , or
under UTS.
3.
Printing (on the line printer) the names of all files on
storage by account number.
(Reference:
(releasing all unwanted user files from RAD storage.
RAD
Sigma 7 UTS/OPS Reference Manual, Publication No. 90
16 75)
FILL
The FILL program executes as a ghost program to provide for the
safety of file information. This program writes backup copies of
files on a system-owned magnetic tape. In addition, a facility is
provided for the automatic deletion of expired files and a
semi-automatic (operator-initiated) purge of inactive files in the
event of a critical shortage of available file storage.
The FILL ghost is scheduled by a file called BACK:SCHED in account
:SYS.
This file may be created or modified during system
operation to suit the requirements of individual installations.
If the schedule is not frequent enough for some users, the user
may employ terminal command !BACKUP to request that a specific
file be added to the current backup tape.
106
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
107
PAGE
The backup schedule specifies the frequency of three types of
backup which are necessary to keep the physical amount of tape at
a minimum to speed recovery while holding loss of filed data to a
minimum.
The three types of backup in ascending frequency of operation
as follows:
1.
are
SAVEALL - Saves all files currently known to the system.
This provides a starting point for recovery (FILL) and allows
the release of all previous backup tapes.
2.
INCREMENTAL
Saves all files that have been created or
modified since the last INCREMENTAL (or SAVEALL, whichever is
later). During a recovery or initial load, these -tapes are
processed by FILL after the SAVEALL tape has been processed.
3.
SQUIRREL - Saves all files that have been created or modified
since the last backup of any tape. These tapes provide for a
minimal loss of data but occupy a large volume of tape1 they
are therefore replaced periodically by the INCREMENTAL tapes.
In case of a catastrophic failure during which the information on
the RAD is lost, recovery routines instruct the operator to
request execution of FILL.
The FILL program reads the various
sets of backup tapes in sequence by date/time and thereby restores
the backed-up files to the latest version available.
ERR:LIST and ERR:SUM
All hardware malfunctions occurring during UTS operation, whether
recovered or not, are recorded in a special RAD storage file which
is periodically copied into two standard UTS files (ERRFILE and
SUMFILE) by a ghost program (ERR:FIL)
that
is
initiated
automatically for that purpose. The resulting files may be listed
and summarized by the two programs, ERR:LIST and ERR:SUM. These
files are also available for on-line preventive maintenance of the
system and for diagnosis and prediction of hardware malfunctions.
107
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
108
The ERR;LIST program examines the error file
(ERRFILE)
for
malfunct10n records that were written during the specified time
period and produces a formatted listing of these records with
(optionally) a summary of the records for that period.
The
formatted
listing is complete with headings and formatting
necessary for easy reading and use by field personnel.
ERR:SUM produces a complete one-page summary of errors accumulated
in the error file.
Language Processors
Language processors translate high-level source code into machine
object code.
Five processors are of special importance (XDS
Extended FORTRAN IV, Meta-Symbol, MANAGE, ANS COBOL, and BASIC)
and can be used in both on-line and batch mode.
Execution Control Processors
Processors in this group control the execution of object p·rograms.
Two of the processors (LINK and nELTA) can be used in on-line mode
only. Load can be used in batch mode only. The FORTRAN.Debuqging
Package (FOP) can be used in either batch or on-line mode.
LINK
LINK is a one-pass Linking Loader that constructs a single entity
called a load module which is an executable program formed from
relocatable object modules (ROMs). LINK is designed to make full
use of mapping hardware. It is not an Overlay Loader.
If the
need for an Overlay Loader exists, the Overlay Loader (LOAD) must
be called by entering the job in the batch stream (reference:
UTS/BP Reference Manual, Publication No. 90 17 64).
LOAD
LOAD is a two-pass Overlay Loader.
The first pass processes:
1•
all relocatable object modules
2.
the protection types
sections of the ROMs.
3.
defining expressions for definition and references
secondary, and forward references).
and
(RO~1s).
sizes
108
for the control and dummy
(primary,
SECTION BF
UTS TECHNICAL MANUAL
1/12/73
PAGE
4.
109
loads from libraries as requested.
The second pass forms the actual core image and its relocation
dictionary, and produces the executable program in Load Module
(LM) form.
DELTA
DELTA is designed to aid in the debugging of programs of the
assembly language or machine language levels.
It operates on
object programs and tables of internal and global symbols used by
the programs but does not require that the tables be at hand.
With or without the symbol tables, DELTA recognizes computer
instruction mnemonic codes and can assemble machine lanquage
programs on an instruction-by-instruction basis. The main purpose
of DELTA, however, is to facilitate the activities of debugging
by:
1
examining, inserting, and modifying such program elements as
instructions, numeric values, and coded information (i.e.,
data in all its representations and formats).
2.
controlling execution, including the insertion of breakpoints
into a program and requests for breaks on changes in elements
of data.
3.
tracing execution by
points in a program.
displaying
4.
searching
programs
subelements.
and
data
information
for
specific
at
designated
elements
and
Although DELTA is specifically tailored to machine language
programs, it may be used to debug FORTRAN, COBOL, or any other
program. DELTA is designed and interfaced to UTS in such a way
that it may be called in to aid debugging at any time, even after
a program has been loaded and execution has begun (reference:
UTS/TS Reference Manual, Publication No. 90 09 07).
109
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
110
FORTRAN Debug Package
The FORTRAN Debug Package (FDP) is made up of special library
routines that are called by XDS Extended FORTRAN IV object
programs compiled in the debug mode. These routines interact with
the program to detect,
diagnose, and in many cases, repair
program errors.
The debugger can be used in batch and on-line modes. An extensive
set of debugging commands are available in both cases.
In batch
operation, the debugging commands are included in the source input
and are used by the debugger during execution of the program. In
on-line operations, the debugging commands are entered through the
terminal keyboard when requested by the debugger.
Such requests
are made when execution starts, stops, or restarts. The debugger
normally has control of such stops.
In addition to the debugging commands, the debugger has a few
automatic debugging features.
One of these features is the
automatic comparison of standard calling and rece1v1ng sequence
arguments for type compatitility. When applicable, the number of
arguments in the standard calling sequence is checked for equality
with the receiving sequence.
These calling
and
receiving
arguments are also tested for protection conflicts. Another
automatic feature is the testing of subprogram dummy storage
instructions to determine if they violate the protection of the
calling argument (reference: Sigma 7 FORTRAN Debugger Reference
Manual, Publication No. 90 16 77).
Utility Processors
The processors in this group perform such functions as editing,
sorting, and transferring data between RAD storage and central
site peripheral devices. One of the processors (EDIT) can be used
in the on-line mode only.
Three processors (peL, SYMCON, and
ANALYZ) can be used in both batGh and on-line mode. The remaining
processors can be used in batch mode only.
EDIT
The EDIT processor is a context editor designed for on-line
creation, modification, and handling of programs and other bodies
of information. All EDIT data is stored on RAD storage in a keyed
file structure of sequence number variable length records.
This
structure permits EDIT to dirctly access each line or record of
data.
110
UTS TECHNICAL l-mNUAL
SECTION BF
1/12/73
PAGE
111
EDIT functions are controlled through single line
commands
supplied
by the user.
The command langugage provides for
insertion, deletion, reordering, and replacement of lines or
groups of lines of text. It also provides for selective printing,
renumbering records, and context editing operations of matching,
moving, and substituting line-by-line within a specified range of
text lines. File maintenance commands are also provided to allow
the user to build, copy, merge, and delete whole files (reference:
UTS/TS Reference Manual, Publication No. 90 09 07).
Peripheral Conversion Language
The Peripheral Conversion Language (PCL) is a utility subsystem
designed for operation in a batch or on-line environment under
UTS. It provides for information movement among card and paper
tape devices, line printers, Teletyp"e terminals, magnetic tape
devices, disk pack, and RAD storage.
peL is controlled by single-line commands supplied through on-line
terminal input or through command card input in the job stream.
The
command language provides for single or multiple file
transfers with options for selecting, sequencing, formatting, and
converting data records. Additional file maintenance and utility
commands are provided (reference: UTS/TS
Reference
Manual,
Publication No. 90 09 07).
SORT/MERGE
The XDS SORT/MERGE processor provides the user with a fast, highly
efficient method of sequencing a nonordered file. SORT may be
called as a subroutine from within a user's program or as a batch
processing job by control cards.
It is designed to operate
efficiently in a mini~um hardware environment. Sorting can take
place on from one to sixteen keys1 each individual key field may
be sorted in ascending or descending sequence.
The sorting
technique used is that of replacement selection tournament and
offers the user the flexibility of changing the blocking and
logical record lengths in explicitly structured files to different
values in the output file.
111
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
112
The principal highlights of SORT are as follows:
1.
Sorting
both.
capability
allows
either
2.
Linkages allow execution of the user's own code.
3.
Sorting on from one to sixteen key fields in ascending or
descending sequence is allowed. Keys may be alphanumeric,
binary, packed decimal, or zoned decimal data.
4.
Records may be fixed or variable length.
5.
Fixed length records may be blocked or unblocked.
6.
RADs may be used as file input
intermediate storage devices.
7.
SORT employs the read backward capability of the tape device
to eliminate rewind time.
8.
User-specified character collation sequence may be used.
9.
Buffered input/output is used.
or
magnetic tapes, RADs, or
output
devices,
or
as
(Reference: Sigma 6/7 'SORT/MERGE Reference Manual, Publication No.
90 11 99.)
1400 Series Simulator
The 1400 Series Simulator provides an economical and effective
solution to the program conversion problem that arose because of a
change in hardware.
This interpretive program is designed to
execute 1400 series object programs automatically as if they run
on a 1401, 1460, or 1440. Thus, an existing level of computing
capability can be maintained while new processing methods that
take advantage of the new, more powerful Sigma equipment are
designed and implemented.
112
UTS TECHNICAL MANUAL
SECTION BF
1/12/73
PAGE
113
The 1400 Series Simulator simulates object code produced by SPS,
FORTRAN, Auto-coder, RPG, and utility routines. Almost all 1400
operations may be simulated except for I/O operations in which
hardware differences make total simulation impossible. Full 1400
operator capabilities are provided
(reference: Sigma 5/7 1400
Series Simulator Reference Manual, Publication No. 90 15 01).
SYSGEN
SYSGEN is made up of several processors that are used to generate
a variety of UTS systems tailored to the specific requirements of
an installation. The SYSGEN processors are: PASS2, LOCCT, PASS3,
and DEF.
PASS2 compiles the required dynamic tables for the
resident monitor.
generation.
PASS2 compiles the
required
dynamic
tables for the resident monitor.
LOCCT and PASS3
respectively file away and execute load cards to produce load
modules for the monitor and its processors.
DEF writes a monitor
system tape that may be booted and used
(reference:
Xerox
Universal
Time-Sharing
System
(UTS)/SM
Reference
Manual,
Publication No. 90 16 74).
DEFCOM
DEFCOM makes the DEFs and their associated values in one load
module available to another load module by using a load module as
input and by producing another load module that contains only the
DEFs and DEF values from the input modules. The resultant load
modules of DEFs can be combined with other load modulas.
DEFCOM
is used extensively in constructing the UTS monitor and the shared
run-time
libraries
(reference:
UTS/BP
Reference
r.1anual,
Publication No. 90 17 64).
SYMCON
The Symbol Control Processor
(SYf-1CON)
provides a means
of
controlling external symbols in a load module.
Its primary
function is to give the programmer a means of preventing double
definitions of external symbols, but it may also be used to reduce
the number of external symbols.
For example, if certain load
modules cannot be combined because their control tables are too
large, the size of the tables may be reduced by deleting all but
essential external symbols (reference: UTS/BP Reference Manual,
Publication No.
90 17 64).
113
UTS TECHNICAL
SECTION BF
1/12/73
pl\r;E 114
~~NUAL
ANALZ
ANALZ provides the system programmer with a means of examining and
analyzing the contents of dumps taken prior to system recovery.
It is called automatically by the system initializer following a
recovery and is executed as a ghost job.
It may also he called by
the operator to analyze tape dumps when recovery is not possible,
or by an on-line user to examine dumps or the currently running
monitor.
ANALZ performs three Major functions:
1.
It runs a series of monitor integrity checks on the contents
of a core dump to determine what caused the crash.
2.
It provides formatted dumps of the monitor's
time of recovery.
3.
It permits, via commands, the examination of dumps and the
examination and change of the monitor.
tables
at
the
BATCH
The Terminal Batch Job Entry
(BATCH)
processor inserts the
contents of a RAD file into the symbiont input job queue. After
insertion, the user is notified of job ID and queue position
relative to the currently executing job.
BATCH functions are controlled by a TEL or CCI command line in
which the user has specified the FID{s} to be inserted.
The status of a previously inserted job may be checked via the JOB
command in TEL.
Batch is an ordinary shared processor consisting
of a single assembly.
114
UTS TECHNICAL MANUAL
SECTION BF
1/12/7~
PAGE
115
LABEL
LABEL processor tapes with ANS header sentinels and readies them
in a protected shop 50 they may be AVRed.
DRSP
DRSP controls the addition, deletion, or replacement of shared
processors, shared libraries, and monitor overlays during normal
system operation. Current users of a replaced processor, library,
or overlay continue to use the old copy while additional users are
associated with the new version (reference: UTS/SM Reference
Manual, Publication No. 90 16 74).
115
INDEX TO UTS TECHNICAL MANUALS
SECTION BF
1/12/73
PAGE
116
The following pages contain two indexes to the complete set of UTS technical manuals.
The first is an index by item and the second is an index by module. The two indexes
are preceded by a key that indicates the volume numbers in which the various section
numbers are located.
KEY TO INDEXES
I
Sections Included in Volume
Tit Ie
Volume Number
-
B, BA, BB, BC, BD, BE, BF
90 19 84
Overview and Index
C, CA, CB, CC, CD
D, DA, DB, DC
90 19 85
Basic Control and Basic I/O
E, EA, EB, EC, ED, EE
F, FA, FB,
90 19 86
System and Memory Management
G, GA, GB, GC, GD
90 19 87
Symbiont and Job Management
H, HA
I, IA, IB, IC, ID
90 19 88
Operator Connnunication and
Monitor Services
J, JA, JB, JC, JD, JE,
JF, JG, JH, JI, JJ, JK,
JL, JM, IN, JO
90 19 89
File Management
K, KC, KD, KE, KF
L, LA, LB, LD, LE, LF, LH
W, WA, WB
90 19 90
Reliability and Maintainability
M
90 19 91
Interrupt Driven Tasks
N, NA, NB, NC, ND, NE, NG
0, OA, DB, OC, OD, OE, OF
OG, OR
90 19 92
Initialization and Recovery
P, PA, PB, PC
90 19 93
Connnand Processors
90 19 94
System Processors
90 19 95
Data Bases
I
II
I
I
I
r
Q,
R,
S,
U,
QB, QC, QD, QE
RA
SC, SD, SE
UB, UC, UD, UE, UF
V, VA, VC, VD, VE, VF,
VG, VH, VI, VK, VL , VM ,
VN, VO
!
116
JUL 19,' 7'3
INr,f-X
8,'1'
!T~M
UTS TEr~NTC~L MA.NUAL
117
.................................................................. ....................................... ,
• • • • • • • • • • • • • • • • • II . . . . . . . . . . . . "
F ~ R I Tr: ~,~
I \1
~~
e r, "I L ~
................................................................,
ceMM ~ NT
S E r;- S E r:" I e~!
~
:8ACKUP
~A..CV'~)!=)
KA.("1
: LeG
Ace,.. <; II M
Pr • 0 t
:USERS
:US~R!=;
I",PUr rTLE rl!l~ SACKtJ O r~c:-A""F'r, ~V TEL
Ace e u ~ T r NC3
V\l.~1
L~G!=t~'
DATA BASE
#. ;;;F S\A}A~
:USERS
SUP~~
QC
.SWAF$DrV
sss
sss
E:r: .01
'
e:,.,.O?
PASS~
9r 18 17
#Sw.~.D~v
ABC
A6E~RETUR
ABN~~T
Jlr
ABe
T~L
JTT
.I'ef'FI
PASS1RQ'1
ABRX/2
AHRXI1
ASS
ASS
A~SeUT
,SSO
ACCN
ACeNT SuM
VA
9~
18 77
PASe1R~M
SvSrr~
9~
9~
1~
1~
VA.
ACCeU~'T!f\Jr;
8')
P~. rj 1
K~.01
e~
8~
T~
.CCT
ACCr
• CCTS Uj+1
Ace T SUM
Pr
AOOr
F,
ADDF
ADJusr.ncs
~~~
tA
AJIT
~~
ALL
.A, NA L l
L~ • 01
ALLJIT
~7
is- 71
PC.01
eVEt"'!VT~lJ
l~VEDV T~,/
17
9r 18 17
18 77
9~
9~
V'J.01
ACCBU,.,JT~
A~B~T
P~~CFSS
IN JIT
AND A~~~OMAL
ce~~
E~~A~
C DEvrCE
~~
A.R~e~MAL ~VF~~I~E .nn~
f~H'EN A8'-J"R"1AL ~N BI/~I
ACC'U~IT 'DIQEC ftVEh:VT~i",j
ACCeU~T SUMRV ACCTS!JM
ACCeU\JT
TsrB qETURNS
~~"UESTS ~~r:-Rt'
Sv-1AP ~r~LJ~STS ~~F'~Rr Tsre ~ETURNS
VA
g, 18 7'
A9S
JIT
~BQ SUP~R
ABl\jB~MAL R~'T" 'QN RE.,.,TNr: TF.'~MI ~AL
PAS~'1A~
AAS
A9S
te
.A{JTHBRY,crO usr:~S
P~.03
ACCi~' 1M
REC~v~~~
:USC"R~
,CC~TSU~
IJ '}F
L ~ G OAT" ~ A~ r.
I:"t~t.
GA
=~8CES~
A8~Q~~'L
eN
Dt'vrC'.r
er
~6PV
TR F
RY/rt DEVICF
PR~CESS AB~AQMAL READ 9~
~Rec~SS~s Ape (8PM 4~LV)
PASSe !NITIALTZE ANn
.
81/£1
C~NT~~L
GENEQAT~ ~:.Q~ LBAD ~enULr
~~~C~St; "JEXT r::»,~~ENTIoolc:"TTCAl
RAUTINE
~!E:L""
S~E JA~C~
L~GBrF" ACC~lJ"" I NG L~ 1 ~UBF(AU" I ~It
ACC~~~TTNG ~q~ USER~ OU~IN3 rRA~~
A.reeLI"',. FIF'L~ I~ USC"~S ~rL~
C~AI'.' ~~ ACC--lJNTS A...,~ rtLF' D!~F'C:TeRIr;S
"N .. l..INE USE~ ~U~MARv
TY"'1E A~ln Rt~--lJRC:EO 1'~Er;
~ r LE M~, NA GfM~~T ~Ss~r.! AT T8" .. USF'~/F I LES
~~~!T~~
TI~~
.CceUNTTN~
R~UTr~!~
UP D• TEA CCRII ",. Le C3 JI RELEA. ~ r. T e: ""1 p • F I Lf! S
AD'
F'IL~S
T~
~prN_P~T~E:
A~DJTrA~AL
qYMFIL~
~~~GE
JTT TR
D~~
TA8L~~
eAqAM~TEo~
~ALD LAR~r
CL
S U~1 M A J:( ! 7 E ~ U"1 P 8 R R I J t\J N TN G ~~ ~ ~, r T Iq R
A~AlZ
L~.Q1
p~IN' uSER~
A~eCCT
JIr
VA
9ITS
AL Tep
AL T("'P
cr
D[C"~E
15.31
JTT,AJtT, ANO
AQ~
CAL~
e~~T~xT AR~A
ADDR ~~ LeA~ C~NTReL
~.5'~" q
A~'D
T~AJ!'S
eM
••••••• ,
••••
4
00
........., .......................r.........................................................................
118
..JUL 1 Q ,'71
r: tl R 1T E~!
I~.J
I. ,
"t ,), ,L F
SF. r'
C; E
T
I fl' ,
C~ M Me::' N"
• • • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 4
ALTMB~~
ALT""';
AL TMe ~ I
ANALZ
ANALZ
!'t \I F LV
ASS r; ~
"'1BP\JITQR ~;:(F''-4 ~9qTF'Il.~
~ R9 M A.. ~! L r:" ALA. ..... ~ N~ 1)(
t:; V~ T r ~ r. t:( AC ~ A~~ ALVC; T~ r' ~ ~~H1 ~ AM
r,
~L TE'Rl'!ATt"
~ ~ f\j ! ,. :\ ~
L e ,.
BVECVTt"',i
er.-
~vt:'VTr:""
~VE~VT~~
8r'
A",t~LvSTS ~, C::)(A~1 eF' 0tCAVr~v r"IU'A~S
A..NALVSI~ ~ ~YAM BF ~~cnVr~v 'U~~S
AI='PE',!D r""~i'T'Qql. Cf'MMA\'D TA 'L. RC~T'
.'
A~! A'. Z
ANLZ
ANLZ
APNDSt:.:G
L~ArJ
\jC!"
Rr:"
L~
Tt"
PAS~~3pqM
eel
A~JALVS!S ~ r:-'tA'1 6F' et"cqv~~V ~uvPS
B~
~~
A.
18 77
PA
ASS! G~'J
TE: L
ASSIGN.MERGE
UCAL
!~
Ass~crATtr')r.L
Alo.lALl
Le-.01
VA
P t~ • C' '3
ATITLE
JTT
AUTe-CALL
AVR
:uS~:~~
v".a1
~C8 oAQ.METE~ TA~Lt"
4.~S~""J ~TE ')e'Lr A
~F~ J:TTTL~
AUT~~A'T'TC p~r\rESSR~ A!;~~rY~T!~"':
AVR
~~
TAPE '1'1U\JT PJ~
AVRID
S~DAT
V~.03
U~~R
A Vq TeL
T J. B I F' ~
TABlr~
V I'j • c ~
'i 'Ai
vfl.C3
TA~I ;':.'~
V~.fi~
i( f, •
AVRTB1..3IZ
"VRT8LS1.Zr"
8 ACI( : 'S C~~ r r.~
B ACKU~
BACKUP
R'AS! C I IF!
RAT Cj..j
8ATC~
alAe
~3A C~ . l:1 C
~L~~IL
r, i
I~
T ~ ;; I ~
~"
~TZF Aj? AVQT~L
~T7E 19r: AV~T~t.
B A. CK L' P S CH~ ~ If l E. • ~ I I
~ ACvl .'!:)
K A • 01
Br'
~~
T ~ ~ M T\.j A L J 11 ~
~VE~VTt"J
~UrU~
I I~ I
8r
8r,
P~QC~~'T'A3E
RATC~CAL
KAT~~
M~NrIX
~~
L~.n1.~1
~LAG
R~~T
-:;
TT .• T ~
BIT S
A \l A, 7
T~ L
8I..A'\JK~L;F
PAS~1~q'l
AL.. 0 Cb
ReeTA Q.~
B6BTF'ILE
peL..
~ AS
c: 1::( ~,~
MqN~'IY
f\ I")
L~
p ~ • 01
9') tA 77
i ~ 3 n21
9'") 1 ~ 17
Lr;.01,'1
l' AP ~ ~
=
r U r L or
V ~, AN .A ~ t: R
C~ p I ~ S 'J S e: ~ ,~ F" r L.. E~ ,. ~ 8 A r It'''. I eTA PE
SAVE r:- TL.E~
fjVE"':VTr:"
8 I T9 TM
A I T PUT
tH~~~n)
#
~~ AI) ~,J T J:" r)
aVE::;; v Tc',!
·"lVEi.."V T t:"';
~ A, T''r4
~!')
,VR
~V
•
BATCH SrHe::-rJUL
8F
C~,AR
c: ":' '"
ASS I C; 'I
~ A~'r'I p ~"r: C!" t: S q P
A ~ e. I ,.. '.J 1M E ~ :; r: T A ~~ Lt [V ~ ~JT ~ UI ATAR
r"1r;:THFlD~
~I!"~\j
A~
r Ce:
C'
r
T~'T~~~lJPTe,
r t: 5 ~ ~ P.
TER~ ~'1.
r' l\,t T RV 0 ~ R
C~MPUT~R
TJ~~
r~Q
BATC~
-:tF" A~~Er.TINr, eATC~ Sr::~C""'UL.INr;
SV~HlqNT
~LRCK
AN~
!~~U£
~!Jee
FILE PlJTLT HV ~~N~yx ~~~ ALTMe N
r: ~ p v T A I=' E T q r"'! 5 C
J:) UTe 8 ....1 \I E R't e" ~ H V T E T" ~ l JT PUT S ! J~ F' ER
~ r: 5 E T ~ TLF t::" TEN S
9L/l~lk AUT q'.,~r:~~
r "",1
8 TT S
g U I L ~ ~ ~ p E"1 !:t LIS T A,,! r, 4 0 E' NC; DC"
p ~"I Cc:- SS .·8 \! ~ ~ MAL n u ~ TN ~
YL F' ~ ~A 0 F R~ M
ReqT F'!I..f. ;\I.ITI T HV "1~NrI)( ~R~ ALTMe N
r:
J UL 1 96 , ,~
! N~ t )(
0
y r" r M
UT S Te: r t..I N T r. AI. ~ A to.II 'A L..
119
• • • • • • • • • • • • I • • • • 4 • • • • • • • • • • I • • I • • • I • • I • • • • • • • • I • • • • • • • I • • • • • • • • I • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • t • • • • • • •
F'''R I 'T'r: ~
•• I •••••• ,
I \J ··~~ItLF"
S[~
t:;~~T
C~MMF-"'N'T'
I p"1
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • I I • • • • • • • • • • 1'1 • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • t • • • • • • • • • • • • • •
AeeTSUBP
o~e.,. su~o
B~8TSUBR
M~~,1
BVE~VT~W
~PM
U~
8~
SYSTrM T~ITrALIZATI~~ M~DUL~
T~ A~StM~Lf ~~~ITeR ~E~VrC~ P~ACEDUR~S
BPMBT
~~Mp'T'
9'" 1$\ 77
W~!TF.
8TM
SyS~~~
STE~
HUF~QA~
9~ 1B 17
E~
FA.o~.r2
PQPcrss~S PT~ (APM A~LV'
CI-!AI~,IS LRF.P~~ATIVE A\lD r'TLr;.: ~U~r:ERS
SV~T~M ~UF~~Q.~RANU, ~ ~~.~.n~ME~T
RUFBUi
A"IAL"-
Lr:"
BUILDC~i
SDEvrr~
9~
BP~
eUF'C~AI'"
BU~GRAN
I T~"
8~'1
r
P~~/P.'T'M
~UBReU,.
TNrs
N"
~.SE
q~T
UP
MAST~Q
c:PRe~RrQ
~MDAT
CAL
VJ
R,)
CALPRRC
~vE~VTr:1.)
CA~rR~r
CP
ryEC"E CAL5 1,?
CASSIGN
JIT
VA
SF"E J:r.A.SSTt.J
C~I~~
SVMr~~
SVSOF~
S~
9~
DEFpA~
q~
JYT
DEF~RM
eeI
cet
cCIR
eel
eel
~CITA~LS
eelO
CCLrLAGS
CCL6AD
CCLTFLGS
CCL..O
COP~
CEXT
CHA'1NFL
~vEPVT~W
eel
CClo
JtT
P" TAPE:
~U~~~R
USE~
tR ~7
1R 7'
1~
77
N~
~F
~~RC~S~~R
T'~~S
RE~Ut.e:T
r:-~r(
WAS~'T
PRRr'ss~~
M~~!TTA~
IN
ce~~
QE~U!~ED
sr;pv!cr
r~TEpPQ~T (XP~~ ~TArK ~~~T~AL QVTES
~V~GEN ~~NT~~L CRMMA~O srA~ PL!STS
SA~E.S cc~
RfT 8
~~T ~AV~ C~T~. CMn.
WRIT~ ~UT PA TAPE
CR~TQ~L CAo~ T~TERP~~TrR
cA~T~eL CAQ~ T~TERPo~TrR
reI, EXrCUTTV~ R~UTT~E
DATA T6~~E ~qnULE
PA~S~
C~NT~~I
CARD
PQ~rESSTN~
JrT
VA
90 1S 77
V4
SSs
E~.01
USCHA"J
VA
VA
9i'",. 1 ~ 77
~YT~ 0-14 A~~ CURRENT ~rRU~ oA~rs ~UT
CU~RE'IT EXErt 'T I eN T, ME
;FT UP C~A~T~L FNTRy F~~ :CHAN CBMMANO
AA
~ALI~NT
PAS~~rrT
JrT
JYT
CHA~ACTERTSTC aVEPVT~~
e~ARN)(
CHARR~UT
V~
9~
p~
B~
p~
p~
# ~F
TIMES A
PLIST
VJ
cC PLISTS
CCA
CCBEF
CCE
'T'~
!.·IR I T~ p!JFr:~~ qUTPUT
18 77
PMDAT
C:~'PQBr
~VSTF.:to.1
SVMCfP 1
eel
SE
FA
qeUTIN~
~CAN
Ta
q~nER
C~
A~Tt.~
C~ARAr.TERISTTC~
~~.c
~~
I~PUT r~MMANOS
SYNTAX A~ALV~T5 SUH~~u~r~Fq
UTS
I
120
'IT:;; iErlooINTCAL ~A,NIJAl..
•••••••••••• •••••••• ••••••••••••••••••••••••• •••••*••••••• ••••••••••••••••••••••••••••••••••••••• ••••••••4
F''' R I 'T E' ~
I \l ,..< A") I ! LF.
SEe" t; F' r T I A""
CBM'-1 r ~j T
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • 4
CH"RSCA~I
CHECK
C~ECKPt1
SVSGE'j
CI-IK
I ~I"
CHEK"-iAME
UCAL
ApS
91
1~
K'"
IA
g~
~~
1 A 77
C~K
If,..
CHKD~
STEP
~~,
j;)'-.03
9"1 t~
CHKDCR~
Tr:.L
PASC~':1~~~l
CHSTSCA~I
~rAR~~
~J~E~
cHK
CHI(\lAM
77
~~~
C~\'S
L'~~
VALI":'ATr:
Vr:.O?
eITl
IGTA~31 r.'
vr;.r;~
CIT~
I~TA:~LC'
I ~T ~ Hl t:
vr:.Q?
It:'TA~L~
vr;.o~
~A~D,
TABI..~~
;:(CV ('1"1.
V~.Ij~
rU~R;.'\jT
rIT4
CJ8~
eKRAD
cl...
CLEANUP
CLB8B~~
cLeeK
j
cLeCK~
TPL
piT
or~
~~
1"\
~
US~~
A[)~~
JIT
D A. 01
t'F'C:'F~~I\,' ~~~T. T\JTER~t '~T P~FO\~~~S' "'3
C~ .. 'T II I \' C\ LOr. s: VAL Ut: F' q Q nr q I ! G~
f" t ,:, ( 0(' ~ I ~~ T e:"' Q Q f .n:' T ~ ~ ~ Ceo ~ ~ ~ Q
CLAC~ 1 INT~~QUPT ~~~C~~~p~
CLt'r-jI(· I",
L:'.01
C~~
C""
Ce~MA~D
i(Q'I}~,"7
r:L':'C;C" r:"TL.E'c;
C~ARACT~~
CU~R~~T
eNST
r:NVDEr-
JIT
V,J.,.
F':(G:
q''', 1 ~ 77
CNV'Jr:X
F~G:'
q~
CqC
Dr
C~C
V ~. ,]5
C~C
~r.,:"\1.c4
Cc;C'"
r'!~
C~C
1.8
77
Cf.lCIo.!C
tqC
C'r.-J1 ,-''+
i),....il.1"\4
CtiCI
cqCr
i')r".J1.i4
Cqc
r.:-·"')1.r"'4
C~ '.1 Vr Q T F R
C~\V~~T
SrA~
~UM~~Q
r ~ Tr.:
EPC~
BF
~,~C
~~AN~FL
PRI., f1 tTY
I~Q
RljNr. q~.~
CL f1r I<.4
c~r~<
T~T~
At-It)
~WAPP[~
~J~
CHCICP
FAP
~1UTIN~
VALI~rTY
TST~Jf;r.
Cf}CGF'To
'.IAME
Kn.~~.C"2
CLS.,
C9CCRLF
~AUTy~lE'
ASSqr.~A~TBN
f".01
CLSFIL~
cec,
~~~CE~~AR
sss
CLSt
C~C
C~ C=5F-'
~ArYLYTV
",rj
q",
JIT
vr-..r'J"?
CIooII!"r:1(
r~ECKPATNT
JE:T r:: ~M T',JE p~~c:; I BLE r;r;:"LF T p~'" ~r ~ I LE
'-:ir;r r.'E ~T S'T'~ T
~ TT 5 ~ - 1 5 Ao~' CAR D T" t P 1.' T C~ Ur. t T C" ~
gYTE, ~UEU[ r~~T~ H~AD
evrE", ~llfUr "ul\ IN TAT l.
qYTE,gYT C C;r:'T' IMPLTr'S C:~~A"f\:C"L ~USy
SYSf.~~~!
r.IT3
U~~~
vALI~
etC
1~
~~LIMITE~
ST~NCV
r~FC~ PR~C~~qq~ NAMr
~Y~Tt"'M C~NST~"E~CV rt~E:r.K
C~EC~S
77
77
I
A~n~ESSF~
LIS'T'
R~UTT~E~
~F
F~~
~~QA'T'r.~
°A~~O
T~pr~
T'" H c:' ~ A'" r: r P' AL
T'" ~EXA~~C T"'-1AL 'T~ ~F')(ADFr I
CA ~
~J A -" r) L E. ~
p, VT E ~ ') r) ~ n c:- ,I r:: ){ T I \1 ~ U'T' r 1-1 .\ ~ ~ V LN Ii
P'jT rA.C:~IAtif;' Q.t:"Tur~N AN'" LT':r ~~F'D I" ~
T~:~LC"s ~~R "'(\r H.A~DI rQ
S~T
T/A
J F T r f'T
~U~~~Q
A~ D
F~AM
'? ~ t'> ~ ~ T
r~ITT!ALTl~TTA\!
"-1AT~ITA'" VAI.!t~
~F
~~
~ t.
~~~
QUF~t:"~
"G .. UP" ~,J '"'
7~11
C~"Q!E~
D~RL
~
r A L • UP
PA~T"TfjN
yN!,,)EX ~v
JUL 19,'7]
,,.rM
uTS
TEr~NTr:~L ~At\JlJA.L
121
• • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • t • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • • • • • • • • • • •
~eR
I Tr~
I \l
~B""ILr
Se:r SF.:L"r I 9~-)
CBI'1""~N"
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • • • • • • • • • • • • • • • t • • • • • • • • • • •
ceCINIT
CeCINP
CeCIl'
C~CMI NT'
cSCMU
C~C
Dr:.01.~4
I N I i I A ,-
';A
Dr.()1.,2
c~c
c~c
or.01.r'U.
C~C
c~c
or.ot.1)1
ceceoe:
c~c
A~AL]
c:~c
V".05
L;-:.01
CBC~P
Cae
D~.01.~3
ceC~BUF
cec~c
CeCeFF'
cecpcrB
ceCJ'UT8L
CBC~D
cec~IC
ceCRrc:Xu
c8 CSCYB
c~c
DC.01.rl4
r ~i I T YA L TZE r. q r:
~
PE:0r:c+~t.A
r:
~tSPLAV
DC.01.04+
D~.01.r.4
c:
eTA F~ LEI ".1 TTl A LIZ A T I q ~,f F" Q A ,,-1 ~
eec: T""PUT c~ ~ R h CTrt:? PQ,AC:ESS I ~IG
I~ITTALIZE LT~E MRD~ CANTRAL BYTES
MaVE t\l~UT MrC;~AGe: r:Q~~1 c~r. T~ USER ~u
q ~ f!) R~ T t:' AN' 'T'. I ~-l D- ~ I t I=' F' ~ ~ E: V~ "" T
"I ~F" ~UT 9\1Tc:"~ LEr:"T ~v LTNt" II
c
TAdLES
c~c
! NIT TAL TZ E L T 1\1 E F" R L A~ G T. . .1r;
ur.01.Q4
Dr.01.el
DC.01.~4
~F'PB~T
C~C
DC.01.')4
RE:CBQD rNP'JT r"MPLETCO
~ T ~ q r t" PUT r" I-! A C< ACT ~ ~
cec
Dr.01.~4
F' ~
r.Ae:
C9C
C"C
CqC
A
PF'RF'PRM coe qUTPUT T\jT~pqUPT P~~CESS!N
~UT AUTPUT r.~A~ACTE~ !'"
PUF'F'ER
PUT !/A tiU~F'r~ IN F~~E r.~c QUF'C"r;.:R CIooIAI
I N TT , A T I:' P ~ ~ r C" r; ~ I "J ti ~ r: TE" ~ ~~ yt-.! ~ L RE • D R
~VE~JT
T~
SCHI:''''IULE~
T~ I P' 'T 8 UF' F" F. ~
T t\!
cBCse
CQC
D"-.01.r4
c.;TART CAe '':l[IT'PUT
C6CTe:RM
CBCWR
C~C
CAC
v~.o~
~~.O1.01
C"Cr:--
V~.I');
~VTE,TC::R"!P'JAt
TYPE ~v LI"'J~ 11
!NIT!AT~ P~ql"'coSSI~·1(1 ~~ T~p'VI~'Al
B VT E , c:; r: E C~ ~ q
1\1 ~ UTE A M r:: ~ "I ~
ceDe:
-c6MeINE
CeMLlST
peL
. 8ASWA"'J~L.
A.~ALZ
Lr.~1
9~
C6M~ETA
F~G~
1 ~ 17
9~'
1~
CeNTReL
C6NTR"L
CBNv
C"'NT~~I"
QA
77
~VE~VTr:\!f
er
L~CrT~A~
PAS~~OA""
9"'" 1R 17
9:"1 t~ 17
c-er'
ceel='
F'A
~I3TAT'"
Y"'ST/ILLATT~"l
CR~VFRT
"1 A r-..JAGEr; TQ~L
ER~A~/.BN~R~4L CqDF
E~o~c/A8N~~~4L c~nr
C~~V~~T
I t\jPI,.IT/AUTP)T
~LJc:'Ft'"~~
r:\
foJVE~VT ~I"
R~
C"ePERATIVE'S
SVMt;ICA~
~A
US::~
ceepF'tLs
5VM~T,-c:
1(~.O4.~5
CL~S~
~
VALJ~
"N. L r "l£' PE ~r:~Q"'l A~'CE '-vALL
~PR9C~S~
JyT
JYT
I~Q
F'~R
~~~p!Nr, •• cc~~s
DATe:
neT10
C~~~.. ,:" NT
• • • • • • • • • • • • • • • • • •
peL.
W~~D,
I
LAST
USF.:~
~TATUS ~~ D~vrr~
! ~l U,S
V~.01
RYTE,
I ,T ABI
t"
IeTABC~
V~.01
v~.o1.
I'TJ.BL~
vr;'01
W~RDI ~~VIC~ M~EMeNTr =v DCT r~DEX
HW, ~~T~V ANr" CRNTlt\I!JE ~UNCTr~" ceDE
BVTE, TTME9UT INCREM~NTS ~~~ O~Tl1
v~.Ot
t/6 ST~~ ceU~T
gVTE, crT
!~~FX
BV
BV Dr.T
RY OCT IND
I·BTASl.t"
IeTA~L~
t • t • • • • • • • • • • •
~eT
r~OEX
rN~~X
• • • • • • • • • • • • • • t • • • •
UT ~ T Er Ht-.I !
JUL 19"7~
r. AL
~ ANI '" L
123
. t • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
FeR
ITF'~
I'~
~'ft')IILC"
~t"c:
~~r:'Tlr::P.'
••••••••••••••••••••• ' •••••••••••••••••••• '"
•••••.••••••••••••••••••••••••••••••••••••••••••• t ••••••••••••• I
OCT3
OCT..
I~TARLc:"
vr;.~t
~VTE,
LFC,jAL
I'TACjLc:-
vr;.01
RVTE,
DCT~
oCT~
I~TA4Lc:"
I~TA~Lc:"
v~.n1
V~.c'
eyrE,
TyPM'Jr'
~YTE,
SwITC~~~ RY
'uEU~ ~~A~ r~~~x
OCT1.
I~TA~Lc:-
V"i."1
~WAR!"'I,
~CT~
DC; T CJ
I~TA3t~
V~.01
I ~ T A ~ l c:"
DEB UG TAB LF"
RUN Q e ~
V~ • ~ 1
LP • 0 t
W~~D,
\.OJ
A ~ D,
A~~RATr~~,IS
T"!DEX
A~DRr'<:~ ~F
AnDREq~
A D~ ~
C~".I T A I ~
A~
S
DE8l~ST"
L:1
TQ/l"Jt:;F'r:Q
DEca I N
TEL
p~.,.,3
OEceNV
OECSCAN
A~S
9~
1~
SYSG~~
SvS~~~
9~
9~
s~
1R 17
OEF
DEFceM
DE F' Ce ~
o E r: QDec
!:)Ea:"X
DEFC9 M
eVE t: V T ~ :.;
D~ F 0 5 ~1
S!)EVT~c:"
1~
77
B~
9~
tB , 7
9·"" t8 77
C,~V~RT
~ECT"-1A~
r
p'
DELoRT
OELTA
~VERVTc:"'·f
SF'
"SSE~BLY
DELTA
M~NrTX
L".C1.02
DtLTA
~1AV
DELTA
A"JAL 7.
LA
LE. 01
L~. 01
DELTA
INTE~rArE
DIAGNeSTIC ep CLS
DIAGN~STIe ~p Cq6p
DIAGNeSTIC SF' leQ
Kn
,PEN SYMBIANT
(~
K~
RPEN
DIAGNeSTIC ep 6pN
1(""'
IMTF~FC
DEL T AGET
DEL TAPUT
DEVTRAN
DISASSDEL
DlSCle
D I SPLAY
A~IAl.Z
peL
1~30t.t1
A~ALZ
BAS~At...J"'L
DA .03
L~.01
Dr SPL_ v
j-l4
T~DEx
FNTRv
TA
p~eCESS~R
~~UTTNES
~FV
~TAC~ ~XTRArTI~~
p ~ Ep ~ R ~ L I 8 ~ A Q I ES • 1:'1=" 1'1 ~ Vr- L A, ~ E F' RB M L M
~ ~ A C;. s s ~ E)(" r: '" "-J TRH, CA ~ ~
C;F'T l.'F' nEF' J3L TST r:~~ MA~Tr:'v p~IITINF.
DEL.,..
DELTA
SIZ~
~E~T~AL ~TRING
WO!T~S
TA~~S
L~AD M~nULE ~~F/DEF
DELPRJ
~A
~CT
TAqL~ ~~~
(~~A~,~~~)
ce~V~RT
DELTA
LA
=y
CA"-1MI\'I!") L r~T ~v DCT
VErT~~ F!"~ ~E'PIJr,
Ee~r f
T6 ~,~IA ~v
GET
!~'DE'{
T· J:' t< ~,. ~ c; ~ T ~. ! r: ~ t\.! T Rv
r q EAT E r" Dr p. ur,I=" P T ~
eel
77
""c:r
~~ PR~~Q~C~qST~G
I ~
V~
M~~IT~~ AN~ QATCH
O~9U~~I~G C~~~A~D
~VEeVTc:"~
BV
QV ""(T !t'-I~F.:V
Dr~ ,~~~~
p..l ~ ~
B~
~~
DEBUGGING
DEBUGR
DEBUGTV
1
C~rv'v~N'"
DELET~ ~YLE~ r~RM Sv~F'!Lr A~D ~TSC
C~~IVE'R~ATI!ttNe: PRRGRA~ "t'BUGr,YNr; PR~C.
L~·Nr:;UA3E
Dr:"~U~Gr."~
~e:" [lSED TA n~~UG
WYT~
~
~V~ATFIL~
~~A~~~SAR~
GE:T ~UPR8UT t \,~ FeR r"~L" A
PUT ~U~~tjUT J "f!" F'BR ~t"'L TA
c~e:CI(S
r:-~Q
CAD~
D!AA~ASTICS
~A~ Dr~O~~~TIC9
r~~ ~TA~N·~TICS
VAl ID OEVTCr Tro,
D~VIC~
OEVIC~
DEVtC~
FqR
~~EN SYMBI~~T
SVMBt~~T
'PE'J SV~1BI~NT DEVICr; ~o~ ~TAG~JqSTICS
~TSA~S~LIATE ~ELTA
~AD ! Iq ~A~I"'L~R
"" YSPLAV SPe:~ Tr I ED M~'! I T~R t ~JI="A~MA T I 8~'
UTS
INDEX BY y"M
124
MANUAL
TEr~NTCAL
••••••••••••••••••• I ••• I I •• I • I-I' • t ••••••• I •••••••••••••••••• I ••••••••••• • •••••••••• • t ••••••••••••• t ••• I . I • ••
F'~
ITEM
IN
~~n~LE
• • • • • • • • • • • • • • • • • •
SE~ S~~TIe~
• • • • • • • • • • • • • • • • • I
DISPLAY
ANALZ
OISPLAV
"-4511,,;'M
9~
TSI~
DISPLY
O!ROC:K
AC:CTSUM
l~.01
18 17
pe'Oi
ceMM~NT
• • • • • •
• • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • t • • • • • • • • • • • • • • • • • •
SUMMARIlE .N~ ~ISP~AV
DISPLAY F!Lr:: NAMES
D6WTtK
SSS
DewTe~
TSlp
O~
O~
nPAK
DPAK
OA.03
IF SET
w~T
WPtT~
~~TNG
IS
C~Fr~tNG
6~
N~NE
DUM
OSCTS
ANALZ
~tSC PACK ~A~~~~R
~EMeTE 8ATC~ ~.NDLE~
L[.01
OUMP
I")UMP
OUMp
L~.O!5
DUM~SI!ME
Dve
~
A8RT
E AP
e:
~
~
~
A~T
caA
CSt<
eel
E CEC
~ CFB
J::
~ C~D
~
Cre
~
~
cue
OPA
O~A
E [t
E E~
~ALZ
M~
sss
IF:
GA.01
EA
PRINT
~ELETE
EVENT iel
~VENT
585
E~
!V£NT 1Q,
SsS
55S·
SIS
S9S
E.
1A,
e:VENT 11t'
~VENT ~..
~ ..
~N TE:~MTN.L
T~L ~EQUEST R~CT~V~~
e: VF.''1,.
U"JAL ~Cl(e:" A"J TE: R~ 1~! A L ~UTPUT
SSS
E.
M~
GA.Ot
EA
'IS
~A
[A
[A
EA
EA
EVE~T
EVENT
4..
~~pe~T~~
qy
~V!NT ~,
O!~r ~AG~
eUTPUT
R~~.
M~M~~V
MANAG~~ENT
,~ .VATLA~L~
£vrNT 11, E)(T-=-qNAL T '.ITe-RRUPT
RF' AL
EV[NT 1~1 qp~~Are~ ~~RA~~~ USE~
EV!NT C, I/~ ~~MPLE"~O
e:VENT ~, II" ~TARTE~ A·"O ,.." ~R~r,RE5S
.,.
'SIS
•••
EA
~VENT
A,
~
Kr
£A
EV~NT
1~,
F (8
~
N~
SI.
SIS
~A
EVENT
r:'
Nt
III
[4
EVENT ~,
GA.01
BL"'r\(ED
D. CANT ~INO r~C BUF~
EVENT 2, TE~~T\JAL. It-.!C'UT "'~~SAr,F' Ce~F'LE
EVENT 1, RrA~ ceMMA~~ ~~c~Tvro ~eR T~R
Ie
MM
TRT~C3ER Rr:AL TTM! us~~
c~~ ijuFFE~ AVArLA~LE
B~~ .4~ RECE T \lE~
EVENT 6.
lIP
I~
~PF'RAT6R A~e~TF'O lJSE:~
A~~~CrA.TE ~~A~~n p~~e~sseR
EA
~
~
~
Du~P
EVENT
SIS
III
•••
PA~E~
EA
EA
EA
SIS
SkAP
J:'f'RMATT~O MEM~QV
vP A~~ pp
EA
e:.
~E~F~~M~~
SP~CtFTFD LeCATTe~9
c:e~E ~UMP ~~lITI~E
SSS
sss
TABLES
SUB~~UTt~E F'~~ ACC'"'t''''TyNC; A~ID QANNER
I' SET, R£A~ ~~ECKI~~ TS n~N~
O~
£~
oSCt!
~~~TTe~
~VE~T
PFRM!~~r-~
r:.,C(
T~
~TAOT
I/q
J~~~ RETU~~E~ T~ r~R~
U~~~ KICK~~ ~UT ~F C~~E
Qr~e~T~n 8Y M~~e~v MANAGr~ENT
1',
C"L\IT
r.i~T R~rUe'C;Tr:1') r:~~~ PAG~S
JUL
125
UTS TErHN!CAL MANUAL
1~~'1~
..... , ..........•........ ..................................................•.....••...•.•••••••••••••••••.
•••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• "
F'R I TF""
~:ND
£:ND
r:~4RO
F.le~~
I"
")I~,.,,'IL ~
MM
SSS
sss
,
Se:c:- SF.: CT I e~.J
CeMt."1~NT
EVENT ~~pePT~D BY
EVENT 9, rANT ~ET
G'.01
EA
M~~eoV MA~AG~MENT
R~OU~ST~~~!~t
EVENT 1~' qt'ALTIME Je~ ~)(I"
E:A
PAGFS
E:A
EA
EVE"'T ie, us~o HUNG UP
e:VENT 1~' 0 110 r:eR 'Ie OL"'vrc~ AcCESS
EVENT 7, QUA~TU~ EN~
~V~"'T 1~' SLr:,:-P TY""'C' F'~~ LJC;~~
e::UQA
ssS
sss
c;ss
sss
FDC6N
sss
F..:A
~A
!VENT 10'
EDC~N
BvE~VT~W
NqN~
BATC~ p~ec~s~~q
B'
~:QA
~:QE
F.':SL
~IWU
~DC~N
~OIT
E' DI T
~ND ACTle~
~ND ACTra~
~NTRY
sss
EDIT
8 V E:;- VT~ i,.1
RDERLQ~
~A
~l
~VEN.,. t4,
N~N~
svMR/~~~
~~
CA
~BCCSCA~"
~eCCSCA"J
~eCCSCA~
DEF~e1'-1
PAS~l~,q'~
~ASS3QA~
E8MTTME
CeCn
v~.O'5
~RLFLAGS
JYT
V4
~Re
FRR:fIL
ERR:LIST
9~ iR 17
9'" 18 77
9~ 1B 17
K~.O~
rtJ~~E"JT r.e"lTR~L C"eM~AND
SE:ARc:~ ~6~ r:~ID Br Cf'\"'T!(~L C6~MAt\,'D
SE:ARrH ~~R ~M~ SF CA~Te~L C8~M.ND
~W, TIMF:: eJ:' ~'10 eF \A~S~AGF' ev LyNE ,
S~E J:CASSIN
rILE
Bv EQ V T ~ \~i
8 F'
LIS T E ~ ~ ~ R LA r;
F.:RRtsUM
ERR:SUM
ERR:su~
1(F:.03
Br:"
E~R"~
P.S~1QAM
£RRL~LGS
~R~LeG
JYT
~ILES
F'f"" ::"Ir") 8F'
F:: ~ R: LIS T
ERRce~TL
~~~MAT
Kt',05
VA
E: R RDEL I M P ~ S~ 1. :;) ~ ~.I
~DYT
a15·~1 ys ERq~R eVEPQrOE ADD~
~R~GeA~ T8 ~~py ER~pqL~G T~ KEVED
E~R~~ L~G F'~OMATTrNI'"4 ~ Lr~"I~IC; "RBGQAM
Jlr
E~R:~Ti
ERR~LT~T
eVE~Vy~w
FeR
UTILITV FaR E~TT u~r~s
CA~TEXT EDYTAP
CA ~J TEXT EDI 'T' ~ ~
WAQNrNG ~N u~~ 9F EN~ ACT!~~
END ACTT~N ~Q'VEN I/~ ~PUTrN~S
ENr Rv AND r~TT ~e~ p~~c£s~t~G CA~S
~ATCW
Br:"
lA
ENToV
Uh.J " ~RR 'Ie D~VYC~ ACCESS
WA~~ uP T'~E ~8R USE~
.
9~
q,.,
1~
77
t g 77
VA
fA
ERR l... eG
R!)EoLqr=
T ~ BLF" ~
Kf • 0 1
ERRMSG
ERRMW~
u~
r:'RR~SGE
T::L.
po
L"G
SlJ~M~RV p~~c~ss~~
LIST EQReR LqG
SPECr.L PAS~1 ER R6 R
~eUTrNr
~ I=' EerA L P A <; S 1. EP R" R ~" I) T r I'J
~EE J:CASSIN
USER ~Qf.t(iRAM T\JTERFA~E
r-~Q~Q
1£ ~ ~ ~ L ~ (; G! ~,~ R ~ UTI ~'E".
~Y~T~M ~RR~~ MESSAG~
r::PQ~~ .... ~ssAr;C" FILE ~I JB~~UT TN~
e
r
r"
rTLF
L.eG
••••• , •••••••• 4
UTS
TFr~NTCAL
126
~ANUAL
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • t • • • • • t • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • • • , • • • • • • • • •
FeR I rEM
IN
t-
4
8t')1-IL ~
C6 MMr;NT
SEE SECT' I e~!
••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••• t ••••••••••••••••••••••
ERRMWR
E~R~wQ
up·
~RRNAME
~RReR
peL.
PASS1QA~
9~
LeG
~RR"R
BVEPV T~\,J
1R 17
7~~02'
p.r,
~RR~R Re:P~RT
M'JNF"YX
Lr3.0t,f)4
ERR6UT
e:RRS£Q
PASS1 RFH1
~ AS~
9'" 18 "
9" 1$j 17
~NALZ
L~.01
P.S~1Rql\.1
SVMC~N
9~
FV£~TS
~xITCL
r: x I TSVS\l.1
r:.:xNe:XT .
t ~At-~
eVE\:(V y e:'~J
~XPAND
TEL..
~XPR
SVMr.e~
FI3C~
FBC'"
SDEVtr~
rXPRX
r:op
eVE~V
~ETtH
F"ETCH3
F'IO
F'IO
FILe:
DI~EC:TRV
r:S.I.ENAMr::
T~I,.J
E~~~~ ~~SSA~~ Fr~E r~NT~~L PRee[SseR
SPECIAL PASS, ERR~R ~eUTI~~
~£ce~DS
q~ce~D
~~ce~o
ERpq~
~EVlr.r
~, ALI
ceNOITt&~
FAtLU~~S
ERR~R~ MAV
~rSPLAv ER~~Q M£SSAA~
Nfo'NE:
SPe:CYAL PAS~~ ERReR ~eUTrN~
EVENTS ~ECE'V~D BV ~e~~DUL~~
rXECUTE Ne~~6l tXIT Te ~eNTTAq
£)(IT SVSWRT
~r.T ~~GrSTE~ T' EXp~. ~TA~~ tT£~
~)(PA~'O C~MJ)ArTe:D AIM TABL£ ~~IT~V
STAC~ P~~Dur.~n BV ~~AD
S~T UP rXP~ ~LIST FaQ ~e~"v R~UTINE
F~RT~AN Be, r~NVE~ST~N
SF'
'e~T~A~
e'j
i8 17
s~
F'~.o~
sr
9~ 18 "
OEBU~GER
STEr
E~
ASSeCIATE
STE~
E~
CRNV~~JT~'
Rr.pePTS
A~.01
~tLE
UN~~AREO ~~ee~s~~Q ~~UTINE
A8~~T
ceo£
P=.03
B~[A~
C~~PL~~ ~ID
BVE~v T~!"I
A~ALZ
8e'
CIoofAl~,~
eF" F'IL"
LF".01
r:IL[NM
PASS1QQM
F"1L.£NT
TE:L.
18 '7
PQ.03
FILL
I'J A l ST~ f t\I(1 GET T~~
~~T
~~!GINAL
J~9 r~~~AND
L~CCT TABl~
rQ~M
STBRAG!
-
..................... , .........................................................,.... , ....................
UTS TErHN r CAL MAN')A'-
FeR I TEM
t.i~'""ilE
IN
••••••••••••••••••••• ,
SEF' SECT I e~,J
GET~
PASS1R~~~
~~ALZ
FA
g~
Ie"
GETKEV
GET NA111 e:
FRG~
p ~ S 1 r( A L~
90
18 7'
FqGr
P.SS1RAM
9~
GETePLB
GETPAGE
GETPAGE
s
PAS~3~~M
GETQ
leG
GETRITEMe~
D~FQe~
PASS\~A~
GETqITEM6N
GETVAL
LF
91 1 8 "
D~.01
9~ 1~
9' 1~
G~BST
F~Gn
~VEPVT~w
GHBST1
eVEPVTc:-\r1
SI"'
G~eST1u
G~eSTt~
I~!T!ATE UCAL
GP~GP
GpHGP
GTMeNTRE'
PASC:::1QR~
~r
GJSB
18 17
q, 19"
9~ 18 71
9~
B~
7'
77
18 77
It.
~~
9" 18 77
•••••••••••••••••••••••••••• ,
G~T FIL~ FQ~~ SVMFII~
~ET ~1~XT F'!E:LLl ANO VALToATr
C8~V~RT ~BcnTC TB ~~x
G~T ~EYW~RD
r; E T "I EXT N AM~ A ~J 0 V AL I '" A T F'
q~ LABEL A~O LR~ATt~N VALU~
M~qF W~~~ A~EA
PA~~S ~~Q ~AVE ~~T!~~
"BTAIN yNDE:)( ~F QUElI~ c.:~JT~V ""R~M
~FT
~ET
~£T
B'~TA~LE ~~RTT~~ ~~ pA
A~D F~TE~ NE~nE~ ~V~RLAV
G£NEoATF
'BTAIN
ceNVE~T T~ 8TNARV
~E~~~~~r~~ PSEUnq.~e~YTep ~UNCTIAN
9VST~M T~IT'ALIZATt.~' "-1~"ULt:
Ja8
G~eST 1 DR!v~~
G~~ST Jq~ T~TTIATr"~1
~rAD/WQTTE ~~~ TR S~AP RAD (AL~a
"8TAI~ M:M~~Jt: TREE ~T~UCTLJ~~
H.NrL~gq
eVE~V T~\-}
Dh
Q~QUrqE~
SA
TVJ:) I r AL
~EAO
DEFc~~
sn
I-fEXBCO
SyMrs\,
4EXBCD9
SVMC~~
TA9L~ PR~OUC~D BY L~AD
C~~V~RT ~EXA~~C MAL. VALUr '"
CHARACT~Q CA~vERSle~ TAALF
~E:)(A~£CTMAL "'lJMP PRp~£~S~~
~E)(DUMP
~EXSCAN
HEX~PRNT
peL
l-IGP
svs~~~
,8ATC~
~r,PQ~rA\1
~GP
I~TABI ~
HGP~Ece~1
HGP:?~r.~~'
~ L.. e e p A ~I AL Z
TMe
S vS r; ~ ~,
TNC~EMe:NTAL
9ACIG M eF A•.1l T SET BV SWAP I ~.!
~~E J:A~S!GN
~~XT AVAIL C~MM8N p~
BVTE AOOR[SS, ~~TT6M e~ C~MM~N PAGES
BVTE TA. AloE F' .. ~ PHVq T~AL PA Gc::: NU~1BER
INITYALrZrO ~v MEMM~V ~'."~IAr,t:MF:"J,.(JIT'
p»~Y "G SET lJl:' w~EN C:\4IAPF'tNr; IN USER
eVTE ADDR, rU~RENT I. TN~ C:"U~lT .. ~, TERMI
BVTE TAB~E LT~~rNG ALL~CAT~D P4GES
I N r T r AL r ZED ~ V ME Mp, ~ V ~ A~J Ar; ~ ME:" T ( J IT'
USED T~ Lt~K T~~U PA~ T8
srT
UP CL
J rT
VA
eYTE A,.,,,~ I ·IJ ~F l. I Nr:~ PER PAGE ~N TERM
J8mASft
JIT
J!T
BVTE AODR£S!-;, MAXrMlI~ II ~r:
RVTE NEXT AVATLABLE: ~ECTR~
JeIN.,,,
MM
JII'CC
JIT
VA
VA
GA
VA
J811.P"
JSIMNPA
132
ceMM~NT
'JIVL.e!f"
JIT
TEr~N'CAL MANUA~
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
GA
ED.O~
JAJ
MM
VA
VA
V.
V.
VA
VA
uTS
•••••• I •••••• • •• I • • , •••••••• I •••• • • • • •••• • • • • • ••••••• • •• • ••• • • ••• •
PAC;~S AVAIL
p~STTIeN
INITYALtZED ~V MEMe~V twlAt\lAr,E'M~"'T(JIT)
BVTE ADORESS, PAGE r~UMT ~~ CA~TEXT
......................................... , ................. , ... , ......... ,., ... ,.........................
UTS
FeR I 'T'E ~
IN
MfH~lI-IL~
SEE" SE r.'T' I BN
TEr~N!CAl
MANUA~
133
'
ceMM~NT
.t ••••••••••••••••••••••••••••••••••••••••••••••••••••• t •••••••••• , •••••••••••••••••••••••••••••••••••••• '
JB:PCD
J6:PCOD
JrT
JIT
J6:~CF'
M"1
JB:PCw
J6P'PC
JS F'PC
JB PP~
JI3 PP~
Je PPT
J6 PPr
J~ PRYV
JI:! PR'MPT
J6·TDP
JS:TOP
JIT
JYT
J6:VL~
J8:VL~
Jti:VLT
JS:VLT
J68CF
JBMNPA
JSNAS~
J6PCC
JBP~P
~JBPPC
JBPPH
JBPPr
J6TDP
Jaup
~J6VLH
J~VLT
JCCL
JCL.
JCLE
. JeLL
-
Co\)
Co\)
MM
JYT
M~
JIT
MM
JIT
JYT
!'t1M
JIT
JtT
MM
JYT
MM
JrT
JrT
JrT
JrT
JYT
JrT
JrT
JrT
JrT
JyT
JYT
JrT
JYT
Jlr
JIT
JYT
'1"VA.
GA
VA
VA
G"
VA
GA
VA,'
GA,
A:)D~ES~, PAGE
C~UNT
INrT!~LTZED 1:\ V
~VTE
Br: nVN,Mrr. OAT'
MEMfI!j:(v MAN. t'1F'HE~JT (J r T)
9VTE AD"'~, PLATEN wT"-'T~ e~ 'T'F.:RMINAL.
~VTE ADDQESS, "'I..fYSlr."L F'Ar.;~ ceUNT
BVTE F'''GE
USERS F'j.ofY pr;
USERS
~VTE
VA
G4.01
BYTE
VA
(3"
ratU'-JT
Al.'D~ESSI P~YStr4L p.G~ ~e:AD
USERS PIo4 Y pr, r~AIN IJ~A~
BYTE ADDRESS, IiIHYSlrAL PAG~ TAIL
VA,
VA.
r~AIN
BYTE
. ~J~XT
BVTE
BVTE
H~AD
PHY pr; ~~AIN T4IL
A",..,R ~F' ~RtVL.Er,~ LF'VF'L ~F' JeB
ADDR, ~! I~RENT ~~eMPT C~AR
A.VAIL "'''~, PG
Tep B~ DV~!AMtC PAGES
AI)[)RESC;,
ADORESC;, VIRTUAL LINI( ~F.:."
tLl~ VrqTI.'AL.. LrNj( CIJAJ~J
A''''~ES~, VIRTUAL Ly~1( TAIL
eF' VI~Tl1AL LIN\( C~AIN
VA
RVTE
TAIL
BVTE DIsP RF" Jt3SBCF'
BVTE OlaFi' ~r: .. J~: MNP A
evrE D!9 P ~r .jB:NASP
qVTE O!Sp ar: j8:PCC
9VTF' DTSP Ar jB:PCP
'3VTE DT~P ~~ .JI1 : PPC
BYTE DySP Ar;:' ,.JB: pp~
BYTE OI~Fi' ~r: Jf3:PPT
I3YTE O!RF' ~r: jt-3:TDP
VA
~EE
VA
GA
VA
VA
VA
V"
V"
VA
V4
VA
VA
VA
v~
~JH I
VLH
,J~:
C~~M 4~IO
VL T
DY~p
~YTE
DI~P
srZE
VA
\~AP.D
VA
~EE
VA
J:F?u P
J1V'T'E
~r
or~P
JICLE
St.'E ~J: eLL
~~
~r;:'
~r:
LrST
.HCL
( T'! W"~DS'
( J: C.L )
!N~)EX c,Y !'f'r:M
LJTS Te:r~NTCAI. MANtIA!.
134.•............... ......•.....
, .............................................••..•..•.•.••.••.••.•.•••.••••.
FaR
SEt:
.•.•••...•...............
, •......•.......•. , ..... , .........................•...••......•.•...•.•.••..•.••.
JUL 19,' 73
'
ITr~
JCLP
JCLPA
I~
~'~r")I~ILE'
Jlr
s~r.Tle~~
JCL.'S
JYT
VA.
VA.
VA,
JCMAP
JtT
V~
JCPC
JCUL
JDA
JDOL.L
Jlr
JyT
JYT
JrT
JOLL.
JDUL
JEUP
JHIOA
JH:OA
J~:PC
J~DA
JHS~PID
JIT
JIT
JITF"PSIZ
JITfPSIZ
J I TLM~1
Jl"T'LMNP
JITREE:
.. JI T5
JITUSCDX
JJAC
JL.MAP
JBB
JetB STEP
JeeR
JePT
J"PT
JPLL
JPPC
JIT
JIT
JIT
JrT
JIT
ceMM~NT
SEE
JICLPA
qF.'E J:r.LS
SE:~ JBrC""AF
VA,
W~r.(D
VA
VA
VA
VA
VA
SF:;:
VA,
VA
J:LL~
~~E
Dr sF'
~~
J:cuL.
W~RD D!Sp
9FE JI!')nL.L
,J~
I PCfJ
qr JH:DA
S£'E J:"LL.
t;£E:
C;F:E
J:DUL.
J:~UP
~ALFwe~D TA~L~
GA.
INyTrALTZE'
JIT
JIT
VA
VA
~w AOO~,
PA~F
~ALFwe~n
01S~ ~~
,JIT
~A~FweQD DI~P
JI T '
VA,
VA.
eVEQV Tc:'yl
J~B
JR~
JYT
JIT
B~
VA,
VA.
efTS 0.t5
BTTS 0-\5
JIT
VA
VA
VA
JIT
JrT
"~AL7.
L~.01
JtT
V,A
JtT
VA
JIT
B~
'IVISI~~S
JIT
TEL
VA
VA
TABL~
TAHI ~
T~E s'ZE
AR~
A~' T~E
JB:L~"P
C;CHEDUL TNG Uf\' TT
J~9
wT'~IN J~Q~
r~MMAND
o~eCESS~~
'PTIA~ 8ITS TN
~C9 ASSTGNM,MT
USE
BITS
,SEe: J P'LL.
W~RO
DtS~
~F
~~ ~L~C~TNG
BUF
9'1£ ~~ rNOE~ BUFF~~
'IF'E JZ\o.'AC
PA
JIT
J~tnA
SWA= to
"
J:LMP
ADOR ~F TR[~ TAa~E
PRINT ~PEC!~T~O JfT
9F"E J:U~CDX
eel
MA~A~rM£~T(JIT)
T£=MINAL
SF'e:
6vEC?V Tc:-',..j
JrT
* F~R
SE:E J:L"'1 N
SF"E
PR
VA.
MEM~~v
!N~~RMATT~~
!~~~~MAT'~~
V4
B8
evE PV Tr: \./
~v
D,~C AnD~rss~s
SF
MM
JH:PPC
13S
• • • • • • • • • • • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • I • , •
reR
I"~~
IN
~AF'r)I'IL~
Se:F"
S~c:"!B~J
C~M~~N"
•••••••••••••• ' •• , ••••••••••••••••••••••••••••••••••••••• " ••••••••••• , •••• "
JPPI..f
JTT
V~
JF'PT
JPUL
JRESeQT
JRNST
Jfo(ST
J5TART
JTT
JYT
JYT
VA.
JSTOfH'r
JTC9
JTELF'LCiS
JTELFLG~
JUL r A. \.J
.JUL. r A\!
JU~AMF:
JVL.CS
JVL.4
JVLr
Jr T .
JYT
Jyr
JIT
JYT
JIT
T;:L
JULTA'.J
VA
V4.
Wt'RD
DY~~
q~
,J"3:PP ....
WR~D
DT~P
9~
J~:PPT
fjE"E J:PUI..
T~MP C~LI.. U~~D
A~~
J~~IST
J:~TART
V4
8TTS 0.,
V~
~EE
VI.
sr:r
VA
V~
R'TA'~ STA~D4RD
Te
QU~ STATU~
U4
1(~.01
JIT
JrT
JrT
JTT
DATE
Vb..
VA
FeR
~A'LB~X
W~RD DI~PLAr~MENT e~ JtU~A~E
S~E JIVLCS
I<~Tte
8AS~A""'L
DA.Q~
i(DSUT
CA.C"
vr;.O!5
T~AN~LATleN TA~LE F~~
eVE~V T~\'"
S'"'
V ft.,
VA
GHeST/~vERLAV
KEYN
KE Y~I
j..I~
KE:Vr.;un
ANALZ
HA
e"N VE\!T~'!
A\I", 1
AO.01
QA.UT I "f!'~
R~CBVERV.CREAT~D
NAMI~G reNV~~T!~NS
L~.01
V~.05
USER # RY LT~~.
LABEL'TAP~
L~Be:LS
LASTC~ASH
L6:UN
LDL.NK
cac6
L.NKTRr.
LDT~C
l.~K'T'Rr.
LEXIT
I..NKTRr
-=tVEClV T~~J
LIBRA~lES
:US~R~
LIMITS
LIMITS,De:F'ALT BA.TCH
LIMR
eeI
L~.01
~UTpUT
JIT
e V ERe
e~r~AT~R C~M~UNrCATN
F6R
TA.BLF.~
VC;.03
KO
r~
~o BVTES, ~~VTN MES~iG~ BUF'FFR
'F'FRATqq ce~J~~L.E 'C"MM"~lD "~"c~~seR
KEYIN8UF"
KEVSU8
"PT
REC~Vt"o?
we~D DySP ~r J~:VLH
wa~D ny~p ~~ J~:VLT
TY~E~'~ 1. TER ~A~IDLER
KEVIN
TN JtT
A. W"~D wH I CH C:'~T AI ~It; ,.~~ ~T A~J~A RD
A.Dr,)R ~~ TC~,
C~NvF~qTR~
I(~V I~.I
qrAD
~PEN
M~ST
Rr:"
RC
~~UTtN~
RRUT!~E
T6
Ta
R~
~~UTr~E
T~
Q~~~NT
TAP~
M6~~~p
PQ~CESS
P~~CESS
-
I ~,,~ ~ LINK C"~S
I ~A~ ~ T~A~S ceNT
I NKTRC CLEA~UP
VN.01
OQ~CESS
GE~E~AL ~ESC~TPTtaN
~PACr(RAO) LTMITS
p"
O~~AULT ~I~!T~ USED 9V ~.TC~
LfMIT,MESSAA"TITLE ee~MAN~ PR~eESS~
BP
sr
••••••••• '"
6 PrI
F'L~Gr. 1)~ED RV Ttl.
~LAG AITS r~Q CrRTAT~ LRGT~AL QTAT[S
C~NV~Q'T' ~e~T~a~ DATA.T'~F T~ JULIAN
VA
p~
t • • • • • • • • • • •
AND
TD[NTIFrCATr~N
II •••••••••••••••
TEr~NTCAL
LJTS
136
MANUAL.
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • II • • • I • • • • • • I • • • • •
FeR I TEM
I N "1~~I'ILE
SE:f S~r.:T I 61\'
ceMM~NT
• t •••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••••
LINEAGE
LINK
LINt(
LINK
LINKLIMS
LIST
LIST
BVEklV Tr:t~
SA
L..tNK
RA
eVERV TCo ~J
BF"
e,en
FeRE~AT~ER5 ~~ UTS
LeAD~R p~eG~ A~1
'N.LI~£ ~eADT~G 6F
Vr';.05
HW, AD'R
E::~
FA
SUPE'~
QC
C~MM~\J')
De:F~e"'"
P.SS1~AM
P4S~~R~~
LMF~GD·
F~G~
9~
F~G!"
9,., 1R 71
1.6CCT1
LBCJIT
LBCI.6C
L6CTRAPS
LBG'F"F"
LBG6N
LeGaN
LeGR
~AM~
M~~S.G~ ~U~F~~
eel
LlSTCC
LISTCC
LISTC"NT
LISTCeN'T'
LISTERR
LISTYT
LMA
LNK
LNI(CNTR
LBAD
LeAOR
LBCCT
L6CCT
LBCCT FILI:.'S
FyRST
S~TS Ar.CES~ WYT~rN A r,TVr.~ RAN~r
LTSTr~G AN? F~ReR M~~SAG~ UTILTTY
STE~"
LISTec
LMINT
B~
9~ 18 71
90 1A 11
9~
18 7'
De:F~B~
P.S~3C?A~~
9r 18 71
PAS~1~~~
9~
P4S~f.H""!
I~JI"'TAI~
L..yNv
q1 lR 7'
1~
9c 18 "
NA
18 17
~A
JIT
VA.
l.eA~
R~.01
eel
SVSr;~f\l
M~NJ:"t)(
SYSr.;~-f'..!
I.~CCTPA'1
·A~ALl
At\1 ALl.
A~IALZ
"VEr:v Tr:'~J
7'
FA
9j 18 77
Lf).01.01
9/j 18 "
9f"1 1 R 77
Lr
Lr:
Lr:
~TSPLAV ce~T~~L
Ce~T~AL
Dt~PLAV
4DD
JNTFRr~
SAME
A~
TA~LES
~I~K
,q
~:~R~~
L~AO M~O
L~.D
~enu
LY~K C'U~TER
GE:T ~'E XT REr:qI;'O F'R~"1 L~CCT T4BL~ I NF'~R
8UtL~ "'ABL~
tJITPA~,
~FTU~~ STA~TT~G A~D ~N~T~G L6C.TleNS
t1 UI Lr" T A ~ L£ ~ n t SPA '., n P SO" r;
Tr:.:~M!f\JATE ,. "~~~/J~!l
L~G6'" TI="RMT'JAL USE~. L~GAr:~ ALL Je~S
~e.
FA
'JSt: R
LF.~1
CLBS~
At\lALl
~ESSA~~
r"~M4 T, ~Nt. V
L~AD A~D ~vr~l.Av ceM~A~D p~~rr~seR
~UIL.~S L~CCT FILES
USEe' TA BUIL.~ ~e~TF'TL£
LRCC,.. T A~Lt./C" TI.~ ST~!JCTUF(F
vr
LP
ev
r: tt NT Rtt I e " M ~ •
BtTS 24.31 ~F J:RNST,
I NTEF=lN.AL SV~A~~L.. TA~Lr:"
9VE oV T1:'1-'
St;OAT
eel
~euT
ceM~AN~ ~~£CIFt~D
s
C~~MANO F~~~ C~.RACT~R
~J D
L~AD M~M~~V r'~TReL.. QErrS'T'r:'~~
~LL~r,ATt. W~~~ ~REA ~qR M:F~G~
S~
j:'r'
L~G~T
ER~~Q
L TSTe' J ~ RE ~J T
L,.qG;!HJ
Ar
BV L*
"rsPLAV c:e~JT~~L.. C"MMAN~
LtST ~ASSl ~q~TR6L rAMMA~D~
"'SPLAV ce~TQ~L ceMMAN~
ryTSPlAv
t ••••••• • •••••••••••••••••••••
r~E:NTr~V ~
AF
A"'MIT A lI~Er:
L'GGEO ~N
T~
U5F~S
L~r;·er-.J
AND
TI4E:
SVSTE~
~~'CESS.Q
~~.~~~N
M!Le
T~
'FVrr~
~p
137
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • .. • • • t • • • • • • • • • • • • • • • • • • , • • • • • • •
. ..,....................................................................................................'
c:
F' " R I,. r; ~
MAL Deb
M Broca
M
M
Beoes
eoce
Mel DCB
~ C'!DC6
M O'DCB
M rIDeB
IN
~~ Et ') I-i L C'
Se: C" c:; E: r T I ~ \j
M : AL Dc: ~
v ~ , 04
M:BrDr~
V~.04
V~.04
v~. '=>4
v~. 04
M:BADCR
M: C:jC~
M: C T!"H~~ Q
C~ M ~ ~ NT
• Ct':' l' 'J T r N G L ~ r, DeB
8I~A~V INPUT nC8
9r~APY ~UTPUT 9CB
C~NT~eL C6"1M A ~JD I t\JPUT ~CB
ceMPI::lE~~ED ! 'I~UT DeC!'
C~MP~E~~EI) q"rPUT Dr"Q
M: CPD~Q
\/rJ. 04
!1:D~Dr:~
V~.1)4
"rA(i~!~C:jIC
~:ETDtR
~:Eencl!)
VP.04
V~.04
E:LEMr~T
EL.EM~"'T
M:CPu
V~
caUNT
MM
M"'1
Gh
M:F'PP~
GA
~B'lI\TR~
MSFPPT
~:CPu
VF"
TAIL RF
~~rr: ~~GE PAqL H~A~
~~~TT~Q FRE~ P_G~ P~~L
MB~IT~~
FF~C"
LTST!~G
LeG
MIEeOCa
MIFPPC
MIF'PPC
~IFPPT
~~
GA
QllTPUT
Dr-~
INPUT JCH
~UTI="JT
DCs
q~ M~~TT~~ ~R~r ~AGF' p~eL
"1Br-.JIT~R F"R;:-F' pAGE p~qL C~lJ""T
~AGE
PA~L
'1tGeDrR
"1:l..Y:)rQ
E)(ECl'T!~N AU"'~!JT OCR
Lr9RA~V INPIJT DCR
M:l..LDr~
Vn..04
V",04
VQ.04
~:Leoca
P1IL"Dr~
V~.04
Lr~T!\JG ~UT~"T
~:eCOCB
M:e~DrR
M t P Q ~ I='
VP .C4
V" • 0 4
qP[RAT~~'S rq~q8LE
~ U~J CL1 ~ !J T P U'T' fj CA
MM
GAt01
~T'!D~
V~.04
~VST~M
~~L'RrE
MIG'OCB
MILIOCS
MILLOCS
e
.., I P 0 CB
. MlsGP
r.
MIStOCB
M:SYDCQ
V~.04
MISLOCB
M:SL~r.Q
~: Sf< Dr.Q
V".:)4
MIUC
MIXX
JIT
JyT
JIT
M4I~Bex
MAILB~X
MAILB~x
MAIL8~v
BACvUO
~r;C~vC"~~
MAN 0
MA~
S\! AP
K::>.O?
L ~ • (j 2
TABL~~
V~.03
MAPM60E
A~ALZ
L~.ot
L~AD
MAS I(
A '.! A L Z
Lt"'. 11
M
~: S~DCB
~IUS
V/~
VA
VA
ur
Kfl
~,;JAt=
~rg
r;QA."
DeB
~~URrE T~FUT ~C9
LRn
~~9
P,,~,
~r~
qUTPI JT nr:B
w~~D "D!)~
.J~R TITLE
W~QD
AD~R,
TAyL
"r:
t7~C l"'~~DS)
S~r:
J:TITLE
SYSTEM nCB lJ~r:D BV r')1:'LTA A\'D 'T~ER p~e
DFLIvER~ Mr~~AGES T~ U~~R~
S~~!D 8~rl(u15 A~lJ FYLI Mr:'~~A";t:~"q USEJ:)S
r:TL( r"'r.~NSTC::"Er-.JCV v~t;~AGF" T~ USER
~ q U T T\J ~ T
p ~ q CF S ~ A
~L~
S~TS MAp
A;
I(
e
8IT TN
~A~ ~A~
U~ I=" D I '"
",or.
p~o AN~ ~~TU~~S
~~EC!FT~D
~ ~A. R CH
USF~
T6
~1
~
.. ''',
eN
00
INDEX RV
I ••••• I I I I •••••••••••••••• "
-Fe'f--fTE~
. . IN
Mer)(,LE
rT~M
• • • • • • • • • • • • • • '"
Se:~
se: CT r e~J
138
••••••••••••••• '"
CA.MM~ NT
•••••••••• • "
"
• • • • • • • '"
••••••••••••••• I .,
•• II I • • • • • • • • I ••• i ••••••••••••••••••••••••••••••••••••••• t • • • • • • • • • • • • • • • • • • • • • • • • • • • I • • • • • • • • • • • • • • • I ••• ,
MAlTER !NO£X eVE~VT~W
K~Y IN~rX IN~~ FeR ~AC~ rTLE
\~AX ~UMBER ~~ TASK JtTS r~ SVSTrM
M.X'V~V
MrSPR~~S
v~
MA~IMUM !VERlA' PR~r's~~~ MM
G.~ .01.08
SWAP ~AO TA~Lr·· ow ~TZ~ ~~
Be
ve
"'AxJ1TS-SsDAT
MIlICW,
'-'MTtClA MI---
~M
MI'GAM2
MBIGAM3
-~'MTa I'A"'.
MM
MM
-. MM
MIIIA"I
MIt a.,.."
MM
MM
-MI1 Ct'T------
GA.01.0!
GA..Oi.0S
G•• 01.08
MBIPPUT
MM
'--SSS
MM
MI''''UT
HI'
----r---
u
- -
MJC'LG
MM
--MNSf---
L~.02
~eUTrNE
GA
...SIIW.,.,
MtauNT
-Mope ---- -.-- --. SNAp
J1T
MEMeRV LAveUT eVE~VT~W
~FL
EO.01
GA.01,·08
vr:
MICPU
MllfltPUT
JIT
--'SNAP
JtT
MM
-'-JTT
VA
Be
VA
L.A.02
VA
G.
VA.
Meo!
C8CO
MID'
FRGQ
VA,O!
gn 18 "
MeOtFv
SYSGEN
9C 18 "
90 18 77
9n 18 "
-M~ClrN-
MID!'V
M8Dr,v
-M-eo-t'Y---'~'--
MIDIFY PLISTS
M!DULrS
MOOULIS .
MIND"P
MIN'IX
--.vBarN
-'TUP,~"
---
SVSA~N
eVERVT~W
-~VE~Vt~W
RECf'VF.D!
M8Nr:tx
MASK
SWAP RAO TA~L~- GRA~UL, P~qL W.~DS/GRN
SWAP RAO TARl~. SHI~T ~AAL T9 ~RAN p~s
SWAP ~AD TAStr:- SHY,., TRAe\( Te GRA~! AD
SWAP ~AO TABlr:- S~I~T ~F 04 TB TRACK
SWAP ~.o TA9lr:- SECT~R A~nR~~S MASK
SWAP RAD 'AelF- GRA~UL~S P~R T~ACK
LINK T~ NEXT pHYSICAL ~AG' IN r~AIN
PHV ~G e~ArN~ SET u~ IN 1T
USAG! TABLE e~~TAtN~ SWAP PG C~AIN
~WAP RAO TA~L~. SHI'T r,~AN p~s ,6 SGPX
G•• 01.0S
GA'01108
GAI01,es
GA.01.08
MM
SGP
QWAP ~AD T~Btr:- GRA~llJLIfr, ADORESq
QC
90 18 "
B~
BCI'
IASS 0
1~
1~
••••••••••••••••••••••••••••••••••••••••••••••••• I
RAn
PA~E~
BP.
9,.,
9"
••• "
77
71
DA.01
9j 1R 11
~eT
s~.~rD
DC:8~
A~~TGNS PA~S? C~~~AN'S
p~eCtSSI=:S
~ECE TVE R[~',Jr~TS F"~ lIB APERAT eNS
R£ADS AND
Cor
r
GrT liE XT F I ~L" ANO r'I-fECK' F'~R STR! NG
BA~E ~~ ACC6UNTT~r, RAT~ S'~UCTu~E
V~". O~
OAT A
~ILE ~~ C~A~r,~ RATE~
C~AR~~ ~AT£ re~TReL ~~qc~qS~~
~STA~Lr~H ~AT~
PReC~Ss :L~e~L
~~CeVE~v MAT~ CBNTR~l
RATes
RCL.SLE.
6VERV TC"IAf
PASS1RA~
QP
QI=
Br:
91j 1B 11
ReVeTL
ReVell
KO.01
c~py
DUMP
T~
~An
RCVRAD
cvcusp
1(~.O3.04
j("q • O~.
QI+-
MA
~~q C~~~ ~UMP
RDE~~~G
RDEcLFl~
lA,
L~CATI9~ Ce~TAI~N~
~£AD E~ReR L4G
RorCLtsT
9~
ROINCF"CH
UBC,""A~
P~SS2Cr-!
CHANGE RELe~ATleN D,eTI~NA~V
GET Fr~~T ~rFLD 5F r,NTReL C~MMANO
S£T QEGySTE~ T~ REF/~Er STACK !TEM
RDSRCH
SVMr.:ft ll !
sVMcr:t\1
71
'7
RATt: F"ILF"
~ATE:S
QCVDHP
~DNE)(T
RATr:-S
R~,Tr~
cvcu~~
1~
9:) 18
S~
IN
L~CATE ~VM8AL
RE'/Or~
P~~F~RM~ F"rL~ cepv
MAKE ~EfNT~ A ~'~E
s~
~OW~T
peL
RElENT
B.SI-IAl,l~L
7'3027
OA.02
READA~
eel
P~.03
READer
TEl.
~EAOCC
Oe:Fp9M
90 1R 77
9n tR 77
9~ 18 77
9(") 18 11
9~ 18 77
9~ 18
READCC
QEAOCC
READCD
REAOceNT
READC~UNT
PAS~~~,..!
PASS3~A~-1
P.S51~~M
DEF~FtM
PAS~3~AM
R~ceV~~v
WEI~~TS Fe~ US~~S
ceMMA~D
~T4CK
TEST
R~AD AIM TABL~ ~~TRV
TRANSF"E~S t~PlJT DATA T~
PA
"
C~MM~ND
C~NTR~L reMMAN~
Q~AD
~~AO
~E~T
RFAD
TEMpeRARY FII.E
NEXT
~~AD
NEXT
C~~T~e~ C~MMANO
PA~Sl CeNTq~L e~MMANO
r
F'~eCe:ss CB~T 1~JUAT ~~, C~MMA ""
~~~CFS~
Ce~T'NUATt6~
C~MM.N~
-
-
tINDEX
JUL. 19,'73
••••••••••••••• ,
F~R
ITEM
~y
144
IT~M
•••••••••••••••••••••••••••••
IN
MPn~L~
,
••• ,
••••••••••••••••••••••••••••••••••••••••••••••••••••••••• 1
S£~ S~CTIe~
CeMM'NT
•••• t ••••••••• ••• ••••••• •••• ••••••• • •• • ••• ••• •• •• •••• • •••••••••••••••••••••••••••••••••••••••••••••••••••••
P.SS1~~M
P'S~1~AM
T~L
REC~R~
REAOFtLE
~EAOX
~[erT
REceRD
REceVER
RECeVERY
RECeVERY
REceVER2
gn 1a 71
g~ 18 11
P~.03
L'
ENTE~ NAMe: TN STD TAel~
gA~E AS CepV~TM
~~5ET ~~Tt~N ~IT UP~N
q£~E.SE
~V~NT Q[ceq~ ~~uTrN~ A~O eU'~E~
nCB
I ~ I TRr.v~
BVERVY~~
~UFF CVCus~
8~
K8.0~
L"
BEG I~) ~ r NGL~ l tSER .A~RT ,~ ~~C:"VERY
~EST~R! SYSTFM AFT!~ U~~£~~VRBL ~AILUR
BU,FER ,eR qAvING SV~T~M P.RAM~TERS
~EC~V~~2
K~.01
SVMce~!
ceNVrNT~!
DUM~
s~
A~.Ot
~£ST~RE SVST~~ TAB~~~
STAC~ P~~Our.'n BY ~~AO
ST~C~ ~ReDue~~ BY ~~AO
SVM~~L ALIGN~~~T BY ~ET.
LR.02
p~INTS
REF/O~F
REF/DEF
R£r,N
REGPRT
REGS
D[FC8M
sn
A~~ L~.OER
~So ~ ~EGS
De:TEFMt'lE CAU~E: 6F rqAS~
RE~STARF
RE~SVM
ANALl
ACCTSUM
SVMrTLc
LC'".01
Pc.Ot
K~.04.02
A'JO OUMP ~Er;l
SUBR~UTr~E T~ RtLEA~~ STAR FrL~S
RELEASE FrL~q ~F ALL SVMFtLE ENTRIES
REMeV!·
SUP~~
QC
ceMMAND
REP~ACEM£~T
ANALZ
L~.O'
REQceM
IeQ
DA.01
ALT£~ RU~NI~~ MeN!T~~
P~RF~RM FINAL CLEANlJr:t -F A ~~QUF"ST
~TSC AND c~~, ALL~CATr.N ~.R SVMa,ce~p
D~TE~Mr~E ~~~~LUTr~N e~ ~~F/O£~ ITEM
~F~ETE ELE~r~T FILE~
REQDC
REQ~C
RESC8M
9VMr~N
PASS3~A~
R6MOELET
RB8M
R68TCNT
qeaTSvM
RRSG, RRBI'i
RSZ
RTMAINCL
RUNFLAG
RUNNE~
SDEvI~~
SVMTA~
SVMTAR
TSTIooJGP
·CeCa
DEFQB~
JIT
FA
S~
90 1A 77
9~ 18 "
v~
VM
K=. 02. ~3
V~.05
90 1R 77
VA
C~EC~ ~eQ
AV.yLABLE
BITS 10.1_
RUNQ6~
L~.C1
SIAJP
slAJP
SSDAT
VC
SSS
£~.02
T~~P US~D
T~
SSDAT
VC
~TST e~ PTR~
sss
~D.01
BfG
~~q
stBeL
FILE
Aq~ RUN ~LAGS
8UIL~ ~~BUr, TA~LES
eel
stBel
AQEA
~YTE, MAX ~~~~AGE S'ZE BV Lt~£ PR~C~SS AB~A~M~L REAO ~F TNCLU~~
RUNR
PA
We~K
~UM8~R ~F ~ W~~D ENT~t~s y~ Re~TSYM
SVM~~L T9L,W1.XA400.w2 •• nD~,w31_.N.~E
':~[E A (1R A ~JUL.~ F8R AFt L, ~~ SYMB I ~NT
~U~
r~~M.~~
~r
r.~
P~~CESS~~
~AVE
AJTT pp
~URr~G
SWAP
T' CMN~ ~t~TI(SEE ~Blesu~
USE~
~w.ppF.n
~UT
1
145
..................................... ... ................. ................... ........... ..... ..........
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •• • • • • • • • • • • • • • • • • •
FeR IT~M
I~ ""6~1-'LF'
s~~ se:~"!""'J
CBMMC!pN"
, ,
'.
,
,
,
LIST 'C- 8E:GTt..! 'JISC A'~DO. c«)F'F.: ~~leSUL)
V':
SSDAT
SIBDA
FIRST DtSC.A~~ ~F U~rR SWAPpro ~UT
sss
slBOA
E~.01
~UM~f~ ~~ J~~S TN 8ATC~ STq~.~
SSOAT
vr.
SIBFIS
9ATC~ USERS 41 LeWED ~N T~~ ~VSTrM
M,IMC
vr
·SI SUA IS'
vr
C~UNT "r: BATC'~ USER~ r 'I ~VC:;TE:M
SSOAT
glBUIS
=~!NTE~ Te w~~D DE~T~~Yr~ TN U~ER'S r~
sss
s:CL..P
ED.'1
weRD DEsT~Av~n IN Cl BY TTC
sss
Er"'I.01
SICL..S
SICUAIS
SICUIS
SICUM
SIEAF
SIECL
MI I Me
SSDAT
ssDAT
SSOAT
SSO.T
vr.
vr:
vr:.
vr
vr.
CURR~NT
ceuNT
CUQRr~T
LTST
sss
EN~
SIEOA
SSD~T
E"'.01
SIEVF
SSOAT
SSOAT
SSS
SSDAT
v":,
EVENT
SIECL
~IFPPC
SI~"PC
~:F"p~
SIr:PP~
SIFPPT
SIFPPT
slGJe6rBL
SIHIR
SIIDLE
gllSUN
sIISU~
glJCL
slJeL
SIJITER~
SIJSP
SIJSP
SII.UN
Siess
S.eUAIS
-~
sss
SSO.,T
sss
SSDAT
SSD~T
SSDAT
SSDAT
v"':.
v~
E~·~1
Vr:'.
En.o,
vr
USE~~
~~
'r
-N
T~F
SYSTEM
SV~T~M
~UMBER
PTRg
T~
END
~r C~N~ LI~T
USEQ ~WA~p~n BUT
LIST SF EN~T~G DISC AD~~ c~EE qe:esUL)
~F
C~
FA~
~AS ~crU~ED FI AG
C~UNT ~~ N'. ~F F~E~ PAG~q TN ~:FPPT
C~U~T ~~ SWA~PER'S ~~E~ p~v P.,\?r P~~L
~~AD ~~
4~AD ~~
SWAP~rq FRE~ PAG~ P~~L
SWA~P~q.S F~~E P~V PAG~
TAIL
SWAPD~~ FRE~ PAGr P~~L
SWAP~~q,S F~~E P~Y PAG~
ar
TAIL ~~
ow I ~J" MF er:
v~
r NSW~. ~
vr
vr
IN
USF~
vr..
E:rj.01
ALL~W~~
US~Q~
C~UNT
r~LE
~~
n~'ST J~9 ~v G~e9T
~!.eQIBRITV Jq~~
peeL
peeL
,Jee
~FADY
II
T6 RUN
FLAG
sss
e:n.o~
SSO,.T
vr".
lJ SEq ~" I AJ! 8 ER
T~E t! -F' T4~ LJr;~R Til P"r.PA~E: F'~~ EXEC
C~MM6Nr) LIST ~'H~ REA'I~'G JTT "'~ AutT
s~s
E~·O;t
~r".O~
q~UTT~~
Sss
SSDAT
sss
SSOAT
SSDAT
MrIMC
vr.
e:"'.0"
v,vr.
vr-
W~ERr
(JIT
SAvE~
LA~T
~UTI
CL
T Te SWAP
~A~~l~S
S~r.TB~
Jr TS
US~R
JIT
!~
~WA~
AJIT
~
JIT
~Q~q~q
~RS • • ~~LAV)/~
r;~A \I pes 1 Sr SWAP
Ir.,
~J'JMRER
~UTSI-!A t'
S Il~
qN.L!\J~
USER~
ALL~\l'r~
~"!
T~E
S"STEM
r'-.
-
L
t
STATF eVENT 'R~NSrT'~N TABr
SWAP r~ PR'G~rSS F~AG
RESET AT ENO 8F SWA~ !~, qWAP eeMPL[TE
ceUNT 8~ us~~s Te 8~ SWAPP~D TN
SWAP C~U~T!~ ,~~ SWA~ T~~NT!FleATle~
~EAO eH~CK I~ FeR N~XT eUTSW4P USER
EV!NT T~AN9. vEeTeR ,e~ ~V"NTS )-X'40'
USER SYSTEM ,,.,
5T'ATe: 1~, USFRS wA IT' Nt;
,,--'-'-".
QUEUrO
R£GI~TERS
'Y"'fLi
810AT
SI' ,--Sl'
ISDAT
1.~o·'i,.,L.
SSDAT
--
~Eeev~~v
& ANALZ
IN ~GP
"e~E FeR SVST~M ST~RAGE
SAVE SVMFIL~ A~O SYM'SOA
ceuNT ~F us~~s IN Q BV STATE •
EVENT INDEX TNTe SI~'T
LTST eF EXECUTABLE ~TAT£S
~rST ~~ PRee~sseR~ FRErO BV ~UTSWAP
~0M8ER e' ~~SgeR~ F~ErO ey ~UTSWAP
~~eST Je B ~LAGS ev ~~eST J~B M
.
Clt-4'eST Je B Ug,~ NUM8,~, Bv At-4eST Jete ,
Q ,F Q' S
~!ST e' ~IS~ ~RleRITV STATrS
~Rets T~MP P~VStCA~ PAO~ C~A1N ~EAO
OSt" • tJF FY~~TUSER IN STATe: ~
NUMBrR 8' ~R~~ESS8R~ Te SWAP IN
rNOICATr ~ew MANY P'8C,SS8RS T~ SWAPrN
SAvt LeeCT
".ISIJt.M .
SID.T
SAVED FeR
SAvE ('OA),(~~Mr),
TIT~(J.
, III
eee BUFFER
TVPE
,
JNITRevR
s.·..."
,.."q
SYMet~NT ANO eeep Rr.STA~T
~rMITEO ~N~r~~ CHEc~~erNT
8F AUT~MATIC 8AeKUP
ANO (SM!)
·..r: .e........................srI:'........re'......................................., ................................
JUL.
.,
147
19."~
R IT
I 'J ..
,., L
F"
C
NT
••••..••..•..•.................................
.......................................•.•.......•.....••.
~~
~~~
~
~
~ 'r
~ M ~. C!'
I
'
s~
eSN
sso. T
vr::
sS
es~
sss
E~.'1
SSOA T
vr
"JU~~H~~
~UMH~~
sss
t:D.·,1
~~. ~ 1
L T~T 9r ~U"G~ T'~G lJ~~~S
U!it: R ~UM!jE:q~ q~' USE~s ,.~ S\;,'AP ~lJT
Tr MP W~RI( T A ~LE I DE"T r rAL T~ SA! eSUL
S8 PNL
sss
E~.J~
sa SET
sss
SSS
~A
r~
SS TQ
ssDAT
vr
SeA T
sSINeUT
5S S E A
C:f'N"'R~i'
LJ4
S8 !SUL
s8 SSUL
s8
8.SULT
SB PNL
sa swp
~8K
sBLANK
sC
SCAN
sss
S~O.T
vr
sss
E~
QA
SSS
TEL
£A
CeN,.~" t'"
PR.O~
__ F'
~F'
~U'T'~~'I ~G
U~~QS T6
N ~~ p~~c£s~~~s Ta ~WA~
Lt~T e~ • ~~ p~ec~s~qR~
SCANNE~
A~ALZ
L~.o,
r~TE~PQrT
SCHEOUL.ER
eVERV T~I,I
B0
ACT I ~t\J "ERF"~Q~~D
SVMSU~~
V!.o~
vr.o~
sss
F-4
sCREEC~
INIT~~vq
L~
stu
SSS
E~
90EC
C~NT~~~
sDEvrCE
SoEvteEo
SVSGe~
SoEvt~~
sDEVO
SOEVIr.~
gn 18 77
18 77
g~ 1R 17
9~ 1R 77
sss
E~.o~
sss
EA
SDEVJ~~
SDEV8
sDLAV
sDLAV
SSDAT
sDp
gOaT
SEARC~
1A
ceNTR~i
A~ALZ
g~
vr
G4
L~.01
t~Er Se:N~)
!,.
9'18 77
M:SnF.V
IN
TB SWAP IN
S".T~ ~VENT TRA~SrTTqN ~? c~nE~
Lf~T ~~ SWA~AqL~ ~TA~r~
U~~~ • A~ 1~T USER ,~ ~TAT~ ,
STAT t' 9, BAT r ~ c 6 MP t E B9 U',! n U~ F' RS
C~'JV~RT~ eI~AC)v T6 r:"~C"'TC:
STAT~ 4, US~Q~ wH~ ~AV~ ~T" ~~~AK
AF'F'E ~·'DC; A C;pr:c: I F' I ED ti ,,~ BL A~II(~ Te
STATr 7, H! ~~IeRITv CAM~UT~ a
PA~Sr ~A~~A~~ ~TNE
SCAN ReUTYNES SVSG~\I
sCJeBx
SCNTXT
SeeM
LJ~EoS
~~A~ ~UT
BUT
sv~G~\J C~A~ArT;':R SCA"IN'~,!G q~UT'NES
A~"LVZE C.~MA~~~
eN
C;T A"r 'I'jUEUI="S
~v~BTeNT C~~TrXT BL~~K ADOR ~v SVMBr~N
C; ,. A T ~ ~ I
C~ MDt JT E B0 LJ '" D U5 F' ~ !;
'3F.:G I ~I c; t ~GL~ USER A Q~~T ,,~ RECAVERV
C;TAT~ A, CIJ~e)F'\JT US~Q
e~~V~~T EeC~'~ T6 ~T~AQV
~ReC~ss~s 9n~vICE
PRec£S~ NEXT P~RENT~~ltCAL
PRec~sS ~EXT vYNDO
~rNE~AT~
M!~~~V
LeA~
F"T~L"
MA~UL~
~ eF S~CTe~q ~ETWEEN JYT ~ RrST 6F PGS
g~CT~R DELAV ~ETWEEN JfT ~ U~E~ GRAN
INSE~T OECIMAL PBINT
STATr D, Uqr~~ WAtTTNG r~~ SWA~ RAD pG
S~ARC~ ~~~ ~orCtFrEn V~Lvr W!T~!N LIM!
i
., '.' .........
UTS TErt-fN!CAL ~ANUAL.
tNoEX BV tT£M
'-lfEM
~
.148
..... •.....•••.•..........
•...........•.•.. ....... ....................................•.....•.•...•..•.
'1'
'''''0 .
>,;• . • '.;. . . '• • • • • • • • • • • • • • • • • • • •, • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • ,
IN Meot1Lr --
SIC'
i'M-·'
I"~
.....i.AM
C."'.8;
",
90 18 "
.WTCt-f~·--,ue-------··'·
'IS
SIRtI'
SlRVDrV
leQ
.Ll_'~--·-------·'.11 ' - .
" "',;1 ~:,~.
_MAN:
-----
CINTRei'
""
-%n~~~~-...........IO'-.
• .----- ..- - - - - - - - -
~~~:..LL--+-- ____
S~'''A
'ID"
'1'
_________ .
SIO.T
SSDAT
a..' ••.. ' ...... SI'
. . ...... •••
at'""tO
,..
.I"~
SZI,,, --.----, ----- "8-
ew
L
" ........... ' .
sss
,sss .... ,.
_. . __
USOiJAN-
al.I'1I
MIIMe
.M, fMC
st.t:K
-i1:leelt[-----~rrM~
sLlte
sl.ltT
-St'WfJlt..--_·--
MIJMC
MIIM!:
H
----
"'''IMe--
M,lMe
tt.,,.MtIMC
81.1,_N
[0.01
VC
EO.O~
V'V,
EO.01
rA
'EA
--.. .
T£L (CANTReL.
E
rrqRfH"~£O USfr~
"8U·T·jN! SETS ,~e:GS I~ TStS F'~~ N£WQ
PReCrSS ALL. ~"T t eN ~N SEL~C:T IUPOATE ctt
eurL.O ~GP BT' MAP9 r:eR
At--10 PER
"'A
MAN I PULATE L~AO MeOIlLE
O!'TERMt NES A~I 1NOEX VALU,- P"AR ~'AME
SW4PPE ~RANUl' ALLerATT~N P~~L
·L.AST cISC, AO~ 6F US'R ~WAPPE:O ~uT
OfSC AOOR£SS,S FeR ,-1tT ANO AJIT
OYSC ADDRESS TABL.E ,eR SI JeL
crsC ADDRESS ~F GH6~, J~B JYT ev G~e~T
gE£K DISC AO'-'RESSES qE"~ BV SISC:lAREA USr:.:o O "'e~ 0 t sc .r,R F"R 91 sel
f'URE P~"C:EDU~~S S~A~,O ev USERS
~ALF W!RD rn~ FeR RJ"'O Cf.f~C::l
SVMTAR
!=;VMSU9R
SYMTA~
gYMTAA
SYMX
-
0'1
SVMr~'J
M: Sr.-I~V
RU~F~RS
F~
I"
01
.n1
~~.01
S~
BJ!"
1(~.04.04
SF'
F'.
LA.
sr
vc
9T
SU~~qUTINE ~"Dl}L~
~UTPl'T r."e~, TERMINAL t:VMBt~H"T r:ILE
LRGR .. , C"NTR~L ~QeCE~C:;"~
A.UTH~R!lE uc:;r:~S FeR LJS~ er: SVSTf;.M
TV~E SUss:aE~J~ A'JD TE~Mt~IATr MrS<';AGES
SAvE LI~T ~~
DrVICES
C:;AVE e~~ !T~M IN REr~V~RV ~UFFFR
STAT~ E, usr~~ WArT'~G ~~R A TTME
F'~~MAT A'Jl' PQT'Jj SWAC) TA8LfS
ENTRv T~ SWAo IN PRqCESS~R ~ JTT LBG!C
sss
A~AlZ
sss
EA
FLAG
INTEPNAL
S~RT
SV~~~L
A~.'D PR T"T
r
D~ Vr.:~! ~e'JT I NE:S
TA~I ~s ~UTLT BV LeAD
MBN I T~R DF."j:'S
~AM I ~JG C6NVF:"'TI eNS
M~OULE ~vM8eL r~NT~~L p~e~~sseR
SVMB~L ceNT~~L
p~ec~ss SYMP'~~T TA~LE~
LeAD
~[~T SVMR~L F'R~M TNPUT C~MMAND
~tSC~LLANE~U~ SVMBI~~T sue~eUTTNES
~XECUTIVE D~LTA SYM~~L TA~L~
C~ARACT~~ TV~F TABL,"
SVMBre~IT Me~JTT'R TA~LE ~rC;M~~'T
SCAN
.
I
lJrs
MANUAL.
!N,,£X
ITF.'M
152.
.•...................•...................•.•.....•......•..•...•.......•...••••
, .......•..••....•..•.•.•...•
TEr~NTeAL
~V
....................................... , ....................................................................FeR 1TEM
IN
"AEt~t ILE
SE'~
SECT I e"J.
SYNTAX
SVSGFN
9~
SYNTAX
SYStRR
SYSGEN
TE~
T~L
P8.03
eVE~VT~W
SVSG~N
P~.03
8~
9~ 1A
SYSGEN LM'S
SYSIO
SySAFN
9~
JJT
VA,
sYS~IM
CVCUSR
K~.1n
N~
B~
B~
B~
SYSGE~
SYSMAK
sYSMAK
SYSTEM tD
SYSTf M MANAGE
~YSWRT
SYSWRT2
T STAR F"ILF"
TIAB6RT
T:ABe~T~
TIAceT
TIACCT[X
TIACCT8V
T: AOet3r-i A Sr
TIAMRDWT
T:A$P
T:.sseCIAT~
TIBTsc~rD
TICHS
SVS~AK
eVERVT~W
eVE~VT~t~!
eVE~VT~Y
PAS~tRA~
PAS~1~AM
ACC"C;LI~
STEP
STEp
ACCr
ACCT
ACCT
9n
71
CARD
11
ceMM.N~ ERR~~ HANO~'R
SV~T~M ~R~6~
~ANO~~q
G~NE~AT~ A UTR SVST~~
SYSGEN eVERVT~W
18 11
lR 77
90 1B 7'
pr.01
EB
SCANNE~,AETS
epTt~NS
SVSG~N LeAn M~~ULE ~TRU~TU~~
8e.e~'LTt\IE, R1.Gl-teST. B1b.~1 c;v~TEM 10
SAVE SY~TE~ LT~rTS
INITYALylF qWAPPING qA~ (P~~CSIJITS)
~VSTFM
JNITT.LtZATI~N
Me~ULr
E)(TE.~~,AL A'J" T"'TERNAL U~IT~UF' J--R IOE~T
~C~E~ULT~G, qWAPprN~. JeB MANA~~MENT
p~eC~ss :SV~w~T ceMM.N~
~BT.t~ ~ILr~ .~D oe ~V~WRT
~E:LEASE eF" "'~M~ FtL.,.~
E~
T~
Tr
ENTRv P~INT F~Q .B"~T CAL
INTEQNAL r~TQV ~eR A MANITA~ ~~~RT
~AIN TtME Arr~uNTt~A SUB~~UTY~~
ENTRy ~6~ ~x~rUTJ~N TIM~ ACC~U~TING
t~
~NTRv P~INT
SSS
EA
ADD A
ueAl
IA
Gl-fBST IIRER
~eUTrNE TA ~~.D/WRI,~
STED
ER
IA
A~SeCIATE ~H.~EO PR~r.E~S~~ ~~u'rNE
,~sRctATE ~~~UESTED LI~~A~v/n£~uGGER
~A
~A
SC~~OUL~ BATr~
C~A~G~ STAT~
fA
~~UTt~E T~ rWANGE c~r TRANSLAT£ TAS~£S
n~8U~G~R ~XTT CeNTR~L L~GrC
I NTE~NAL ~~'T"V -T6 D~LETe: • U~~~
OYSA~SACIAT' LIRRA~V/O~RU~~~~
UeAI.
gSS
TIC~T8L
TID~L
·Sss
ueAL
STEP
T: DELUS
STEP
F=
TIEe
sss
r~
E~
ssS
EA
T:Drs.ssecYAT UCAL
TIECB
1~
c:eMM,NT
T:E~R~R
STEP
TIExrT
STE~
E~
E~
~Q
Ge
T~L
!NTRV
~~INT
P~INT
T~
~REA~
~~TRv
Ta TEL
~~~ eVEQ~~.O ACr~U~TING
,~R
~RQ
ASST~N.M~RGE
ERR~~ CAL
EXIT CAL
Rr C
................., ..................e'!............................................................., ..........
..........................................................................., ................................
JUL
FeR I TF.~
TIFep
T FP
I I\J ~t'''''-'LF"
FREE
C~M~e"
J:~EE
J:~e:E
Pr.i
G•• 01
F'~rEVP
MM
G~.01
C; A, • () 1
GE:T
GE:T
UeAl
IA
M~
M~
T F'VP
T FVPM
T GAJP
T GC:P
T G~eST
T GJ8BSTR'T'
M""1
M'1
T GNVNP!
T GNVPI
T GP
T GPP
T GVGPI
,. GVP
T GvpI
T GVPM
T
T
T
T
T
T
T
T
IACU
INITJeB
JeBENT
NAMrCHt<
eFr:
6V
eVER
eVE~LAY
TleVE~LAV1
M~
ueAL
MM
MM
GA.et
G~T
GA.01
Gr:T
'1M
(;.4.01
r;~T
MM
GA..Ot
r;~T
M~
GA.01
(3FT
I"1M
M"'1
G~.•
ueAl
T : J A3 r: t\1 ,.
. TleV
sss
T:6v
T:B"
T:6v
T:6"
TsBv
M'-'1
CI-oII(
sss
T:6v
sss
sss
G~
r.
01
.01
rA
£~
FA
r:l
F'r'
E:C
J:)(1
!I1ASTt!~
~JIT PA~F'
C"a~M~N p~
"I
GF"T ~!
!11~
~M
G~.01
PG
!=)~V
~eUTT~E T6 ~~~Q ERR ~S~ r~ G~'~T
q~UT!Nr TA ~~.~T UP G~~~T J~RS
Ge,T C~~~~N LT~ITS
(;A.01
TI~GC~t<
rlPULLA
rlPULI.E
GA.~1.
t't;
J:"RE:E VTRTUAL
"1"'1
TISV2
T:PAC
TIPGC~K
T:P~etC6V
fA
153
~ANUAL.
Cft~MI="NT'
SEF SECT I
GA.1j1
G•• 01
GA.C1
C;A .01
MM
T F'PP
,. GL
TEr~NTCAL
UTS
19~'73
~~T
V~
ABBRT
A"H-' ~J"'" pp
A\in oF"'
""
PC;
J'~v
'i' Vr:>
PG
G I \lC'~ PF'
VrqTUAL
or,
I NT~~~I.L
VP
VP ~AS"C"Q
!NTE~~~~ATE A~
r;~T
R~UTTN~
e:~TE:~
T8
J~~
TN
U~~~tq
p~qCESS
! ~J
~ VMS
~~a~T
re"T
!MAGE
STA~T CA~S
~T~F=',A M
C~E"C" r:~Q VAl TD G~8~T ·,JAHr:
F'A~C~ A USER ~F'F'
.ss~~rATE ~A~TT~~ ~vC"~LAV
" ~ 5 C' A. T B V~ Q L A. It( • '.1 A 0 ~ T lJ ~ 'J
ASS6CIAT ~vrQL~V • ~~M~~~~~ P~TURN
e r
N.ME TN
T:~V~~LAY
WTT~
GA.01
o~~CC"~~~Q
ArrC-SS C~":T~aL
Krt:r"I.~1
'1 ~,,~ IT" ~ " ~ c; ~I A ~ PER ~ A G~ r ~ AT'" "" ..H: CK
CV S V AL YD I TV q F' M'" N • ~ WA ~ ~. LJ ~ r Q ~ ~ c: HA N
E'r
.~sRLrATE
~A
PULL A'I ENVrQA1\.J~ENT
I:'ULL A~I ENVy ~~\Jf'-1FNT
Er.
E:~
E"A
T : B v W! T ~ ',J U'A q E " SFJ J!" r. I
Q~GTS,£qS
r: Y~ ~
r
S~AQED
PR~~
·vrQLAV
T" ALT A~~~
UTS T!rJ..lNreAL MANUAL.
lUI. 19,' 13
154
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • , • • • • • • t • • • • • • • , • • • • • t • • • • • • • • • • • t.~ • • • • • • ••
FeR 1TEM
IN M8","'Il.E
• • • • • • • • • • • • t • • ,
'I
RCE
'IRI
tlRrceRO
t I MG
t •••
SE~ SeC." t e~1
Sss
£A
\R~~~~T £VE~T
CUR~'NT USER
EO.01C'RrATES SWAP OEBUG T~'~
E A R r. Ft" RT ~ VENT. ND Gtv, u~ CPU
EC
qF.'Ce~D C:UR~F.~IT SEG A/I~D R11 F~R RETURN
~tRVS~I
T t ev
STEp
sss
9Tt'P' -_.' ---, MM
MM
["eo,
GA.01
GA.O!
rl$AC
MM
GA. 01
'IRUE
;. RUNoeWN
~IRVPt
rlSle
r.SlVEGET
MM
UCAL
fIst ..
SSS
rISEL'OESTRUC UCAL
E~
~~SET
~~peRT ~V£NT
GA.O!
!.'
EA
IA
SSS
EO
rlSGA
MM
MM
r1M
MM
GA.Ot
GA.Ot.OS
rISGA~IT
r.SIR - r
rlSGRNU
rlSI!
fsIe
O~
GA .01
GA.Ot.OS
TSI~
O~
flSMHe
,ISMP
MM
GA.01
MM
rlSNAC
MM
GA.OI
GA.ot
,18'- -,ISlE
,ISar M
flSflJM"T
,'SXAC
"SXMAP
fISTS
flsvs~aAC
1'_ITST!SZ
SiSSSS
SIS
~L--
MM
MM
--- -
R~L~A
UCAL
,_~~S ___
R[PfltFtT A
EA
rlSENIE
ristXti
F'VENT
EA
. ,sss
~IRSTLMS
cee
SIS'
SSS
'. REMEMBER
ceMM,NT
t • t • • • • • • • • • • • • • • • • • • • t • • • • • • • , • • • • • • , • • • • • • • • • • • • • • • • • • • • • • • • • • • • t • • • • • • • • • • • • • • • , • • • •
AL~
t NTE~NAL
~rLEASE
R~LEAS!
JYT MEMeRV
p~r~T~~~
SPErrFT~n U~ER
USE~
SF.'T ACC,-SS
S~ARCH AND nT~PLAV
~eUTrN~ Te P~~CESS ~.vrIG~T
S~~EOUL~
FeR ~XFCUTT~N
Te nr~ASSeCTATE
CALtCMKP,)
~eUTrN!
~~N ~V!~~AV
~eUTrN£ RETl'~NS RAD ~EAD p~S!T,eN
~eUTrNr USe:O
RETURN T~ ~.LLF.:~
SWAP GRAN ALLeCATre~
T"
SWAP
GRANUL~ ALLeeATTe~ WTT~~UT
SWAP
G~ANUL~ ~ELEASr WtT~~UT A USE~
PE~,e~M ~WAP TIB
SWAP GRAN ~EL~~SE
A US£R
!NTRV Te TSt- Te
S[T UP M~C
9~T
~EMeRY p~~T£CTt~~
SFT N
A~CES~
seHEOULr SWAP
EA
SC~EOUL! SWA~
9C~EOUL~ SWAP
tA
GA.01
8N
ENT~V TI! R" TNT T I AL t l~ A
vp INTERNAL
vp SAvE pp
EA
£A
eN
~eUTrNE
r!
ANO Ex,CUTteN
AND
EX,CUTr~~
~~TA8L..tSI-l
GA,01
fA
EX!CUTr AC
EXECUTE MAP
ReUTtN£ re ~'vE
%A
£A
qeUTfNE T! e~MPUTE 'TMF
eAL.CULATE us,,,s SIZ,
S~Av~
MAPPED
E~T
,,"'eMF'T C:~'~ACTE~
USrR
MAST~R ~eDE
..............................................................-.............................................
JUL. 19~"~
!~""EX ~\' trr M
UTS TF.r"'~NTCAl
~A~J"AL
155
FeR I
I
C;Er." I
••••••••••.•.•.........................•...
, .... ..................................•......•••.••...•...•••.•..
SSS
T~~
'J ~~~"IILr:
S[~
~"
C~MMt'NT
'
TIUTS~TS
TIWAIT
T I W~K[UP
T:' WTERLeG
TfX~~C
TIZPUP
TABLe:
TABLES
TAPOMP
UCAL
UCAL
~,
T~ANerf~
IA
~eUTr~r
~BlIT YN~
r~
RDE~L· ~
T~.
~M
M~
P.SS1Q"~·
T.BL~~
GA-01
GA.01
CVCIJ~~
STAr~
Te
rNvtQ~N~rNT
~~qC~SS
\.J AKE UP
fSLErp) CAL
~!WATT
T"
f::LEr P r ~,Ir] l'Sr:'~S
~~UT Y~r: TB '-,~ T TF.: A ~t"CA~D T~ ~~~8R L~G
EXECUTr MM~
9" 1~ 77
\jA"'!F:
K=.~~.~5
~~
7.r.~~ PU~E ~~~r.EDURE ACrE"C;!!;
~NTEQ ~IA'1f 1'" FILE A~ ~T' TA8LF"
C8t\ ISTA ~ITS, ,., AT A
CRPY ~t:C:~V~~v ')UM~ Tq TAPr:
~V~!TAX SCA"J "TILITV !!)t\\''T'P4~S
TAP£C~ST
TAF'e:F'CN
TAP~C~eT
T.Pc-F'~",
pro,
~~""1M~ND
TAP~P
A~~LZ
L~.j1
Q~AD E~r:C
T ~ L SC• N
PAS S 1 Q"~"
9~
~ F' A~ C~ T A8 L r: ~
TCe.C~
JIT
VA
1~ 77
FU\!CTT~N
PRArE~C;AR
'r.LT~.CQEATE~
TAP~
(F" I LEI e T ~)
~DDR 8F' Teg
TF."~M!NAL E)(~r'JTIVE
F' -- R CLJ RRE NT F"
TEL
tjvERVT~\AI
13r::"'
TEL
Te:L
PQ
TELLTEL
STEP
EP
~XEC! 'T YVE LA "'GUAGF' ~qe"'~s~"'Q
Ass~r.rATE"S T~t
A"'O ~~PIqRT~ ~Q~"Q
TELLU~Q
L~.o~
~~TNT
TELLUSR
TELSCAN
TELSC!PE
TEXTARG
TEXT A~G
TE:XTeUT
TFILrLGS
TIC
TIM
TI~TMP
TL
TMABNR
TePRT
TPEXT
TPIeT
01
01
ER~~R
ME~SAr,ES
T~
CBOF
BATC~
C
~~~U~E~T FIELD ~F BATr~ c~~MANn
~U~ITq~~,.N~ l~CCT TABL~ ~PTIMT'ER
G~~E~AL ~E~eQT~TleN q~ UT~ ~TACKS
"3~27
C~EC~S
peL
1~30~7
~ATrH
sr
VA
J'~~C~S~~S i" o~
TY~E 8UT P UT TA
BAT~~
eel
TEMPST~CKS
TExceM
sr
M~~ri~~
I bN~UAr,r
SVMreN
peL
sr
JIT
SCAN
~A
C~MPA~~
TEXT~
~AMES
AqGUM~~T
LEN~"~
~EF:L
'!U~8E'~r.:
TERM T "'AL
SSS
E~.01
ABBR~VIATle~ ~~R TRA~sr~~
TIM
JtT
r.
DATE/TIME CAL
C~CD
VA
VG.05
PAS~1~A~
Tep~T
9~
V~
J!T
JJT'
VA
VA
1~
T~~PAQARY
77
TN
C~AN
I~CD
PReCE~Se~
Tr~~ CELL TN JIT
~W, Lt~K T9 T~E AUF ,~~ TN~UT TAB SIMU
P~BCESS A8~~PMAL REAn W~[N ~FN~~ATIN~
S~G NA~FS A~n ENTRV ~eTNT ~Y~PLACEMENT
T~TAL
TeTAl
PR~C~~~~~
PR~Cr~~~~
EXErUTT~~
I~ rT~~ TN
TIME TN JIr
JTT
JUL l ' I " !
INOEX ev tT~M
UTS TE~~N!CAL MANUA~
156
.,
.•••......... , ••...........
...................•.....•.................•.•••......•..•••.
, ............•...
. FeR ·-ITt-~
IN·~-80iiLE-··
SEE 9£CTlel\J
ceM~~NT
.•.............•••...•.•.•.......................•.................•......... , ...........•......••.•.•..•...
~
r peVT
J rT
TRACE
ANACl-··_··
TRAe
luSrR~
TRANS,TRANSSl ANALl
~R~P
TRAP
TRAP. PRBC£SNG
TRAPe
TR[!
TRE!
TREER
TRUNDLE
Tsee
JIT
AI. T.CJ'
TRAPC
C
N!NE
so
JrT
O!F~eM
SVMeeN
eel
TEL
SSDAT
SSllA T
TSe!
TSI!
SSDAT
TSTACK
JrT
TST~GP
TSTUSR
TTYIN
TTveUT
TUEXT
TST~GP
CV-CU9·~
c:eCn
C!CD
JrT
u8.ev
usapCT
MIJ~C
sss·
MtJM~
M~
OUMP EV£NT ~pt~eRDER
TrMPeRARY ~AO SPACE
Lr~tT
rNTe r~co!C
LecATreN e' LAST TRAD ~XrCUT~D
BtTS 20.23 A~F THE re AT T~AT T~AP
!XECU TI eN TRAP PRec,~S T~IG
ep~ CAL PRee~~S~R
TABL! PR80Ur.rn BY L~AO
TABLr PR~OUr~n BY L~AD
T~.N~LAT! Br~ARY W~QD
TREE
A~O PT~'~ ceMMA~O PRaCESS~~
ceMPACT P.LyqT
VC
TEMP~R.RV SWAPPER C,LL 0
v e T F: MpeR ARV SW" FI' fi!' E: R C, L L 1
Vr-
EO.O'
VA
U81ASP
u81BL
U8IJ!T
PA
P~.03
sss
MIIMC
M'IMC
MIIMC
M: I ~ c:
MIIMC
U81FL
uSIJIT
S~
C~
JIT
JIT
UB: os
VA
T9I~
1UI!T
tueVT
uelAPR
V~.01
L!
VA
TIe 1 .
~SIe
v A T e T~ L p.~ e CE S~~ R eVE" "'4E A. D T t Me: TN J I T
L! .01
K~.02.01
I(~. 03. 03
V(1.0~
va.os
VA
V~
VA
VD
VD
V~
Vn
V~
VD
EO.O~
VO
G4
T~MP~RARV SW.~PER C'LL 2
SWAPPER tIe ~~UTtNE
~~UTrNE us£n T~ P~R~~R~ SWAP tIe
9TACK PTR OW A~O STAeK FB~ TF-MP CNTXT
VALIetTv c~,r.~ eF ~r,~ TA8Lrs
V~R I f="V USE~ eeNTRel. TAeL~S
TRA.NSLAT TBl "~R TTv I~'PUT ~v .SCI I
TRANSLAT TBl FeR TTv eUTPUT PY ~BCDlc
TeTAL USER F~~cuTteN TrM~ IN JYT
TeTAL U~ER r~ TIME ,~ JtT
TeTAL USER ~v~R~EAD TI~~ T~ JYT
PReC£SS8~ • ~~ PR8C ~V'RLAV RY USER ~
PR~C ~ ~F SP,CIAL p~~c ~~ TrL • eel
eACKwA~O LIN~ IN STATE OU~ 8Y USER
*
*
~ F' 0 r Q lJ C3 GERTF' A~I V Bvue; e: R
'~~W.RD I.t~K T~ STAT~ nu~ ~v Uq~R •
FI'·t,.fVStC.l PAG~ N~ eF JrT tr: I~,' ~RRE
JIT'S p~y ,,~ 1J SET uP ev ~''''AP !~
~ReC ~ SF Me~TTeR ~v~RlAV ~FQUT~EO
tNtTtALTlE~ ~v MEMM~V MA~AG~M[~T(JyT'
PRe C _
................................................, .............................., ............................
..........................................................................................., ................
JUL
157
19,t1~
F'~R
ITE~~
~,·pnl"",.~
I'J
:1"1
U8:SWA.P1.
Ut3:US
M: I
LJf3C~.~
SVSc~·"'J
UCAL
uCL6
UCAL
ID
U~:
10
UNAM£
U~M4F
UPAGE:S
LJ~DATE
USER
USER ~U~1B~~
IND~~
USE~
_
Vr')
USER r~ #
E:n,o~
FLAG~
G4..C1
~A ~r
~~.O~
SSS
JJT
E:D.01
A\IALl
ANAl Z
ACC,..r:;,
Le.:.01
Lr."'.01
JIT
f'} vEr. VT~ \-'
8VE c V T,:'\;1
~N
l'SE:R •
JrT
N SWAP
,~qeR~
JtT
~WAP
R~UT r N~ Te U~IL INK C, Ar'~~ se.Nt;:t:
SF:e: JU"" A ~E
~I="SET F"LAG T" INDICATE MAPPt~IG
VA
!~
ev
~~T
q~ ~~AG FA~ 1ST
~e"1E DA Fe~ ~lrT 1ST TI~t:
F'i'.~t'
PAS~t~A'1
UPDATE:
USE
~y
~=IHC
v~
sss
UL..CLC
~~~c~ss~s C~A~,DEvtr'/~ToLq/A~·eLB
~~eC~SSrS MT~CEl~AN~~U~ UT~ CAL~
~AD
OQ
I/VIr.:
s~s
U~:TS
9r 1,8 11
IA
vr::
sss
UH:JIT
U5E Rt S ~WAP
U~~R STATE j
F.i'.f1~
MM
U~:r:LG2
GA.01.0S
Vi'
TSIF\
:~:
UH:r:LG
C~~Mr;'NT
CL6St A~D Q.r..A~£N MILe T~ OtVr~r uc
OTSC ADD~ ,~ ADDITI~~AL JYT r~ ANY
DA e~ AJIT ~~ 1ST T'~r ~r JTT
U~ER FLAGS R,v USER j
"URE J:t F'\..G ~'T
RITS 1311_,1~ FeR N ~WAP ~~~~RS
sss
UH:F'LG
9~CTI~"
L~.C1
A ", AL. Z
M: I ~r.
U~:AJrT
U~:AJrT
U~:
~'lC
SEJ:."
GrT USFRS ~rAnITAIL. 4ND C~'.I~'T
T~ U~DATr: RAD ~PAr.E U~ED
Pro:. 01.
9'" 1 R 17
V /"
BR
qr.
Lrr.01
SU8~f.!UTTNE
o~ec~ss
~4 ~F
=UPnATE ceMMAND
J:AAC, ~~Ar, ~~Q
AIT
T~~Mt~AL
rNTE~NAL
TA~~
BATC~ e~ G~~~T JeB
U'IT"lJE NU~~cr~ F"~R rAC~ JeF
usr~,
PQTNT USEQ
T'~L£S
LJSE'~S
Af\'AL 1
UTILITY
UTMBPMBT
PeL
7~302'
SVS(jr'!
UTMSPhIIBT
UTMr:'lp~~~"
9n 18 77.
9' t ~ 77
lJTS
UTS
vALID
vALU
ur:
WRIT~S ~~eTA~I,E PAR,
PA/~~ TAPES
WR!T~ UTS 8A~~ SVST~~ T~ ~A TA~r
U~ED r:q~ ASSf:'~18LIN(i UT!; M~\'!"~~
SJEvTr-~
~'" 1 ~
9'1 1 ~
CH[C~
F"~G~:
VJC~
RA
voce
v I ~TUAL
MF"l"iRY ~VEPv T~;'J
BATCH
vLDC~Cj(
IN ATe ~ (1 e GT T~1 ER T "BL~'q
UT t L TTV AND r~NVE~S T'-N R~U"" r ~'E:e!
77
77
er
~BTA
r~q
AVATLABLE
~rvrrr~
TNT ~Tf.R'IA L. ce"JT~AL. TA ~L~ r\lTRY vA
R~
LBGICAL
S,.
Cr'1
Df T E C"T
~EM~~V SEEN ~v USFQ
Ace", U"" TAN 0 to l • Mrr r RQ ~ P S
\-JATC~DItlr,
T:>4~ PReCE~~T~'G
01
00
UTS
JUL 19,'73
TEr.~NfCAl.
158.
MANUAl.
• • • t • , • • • • • • • • • • t • • • • • • • • • • • • • • • • • • • I • • • • • I • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • t • • • • • • • • • • • • • • • • • • • •
FeR
ITEt-"
1'1 Mr:l"'IL~
SEP SEC:TI~'"
C"MM~NT'
t , ••••• I II •••• • •••••••••••• I •••••••••••••• • •••••••••• • • • • • •••• I
TABl~q
TE~
P~.03
wRITE
ASS
90 1.!! 17
\tJRI T~ ..." ASS L~AO M"~UL~ T~
wRITE
PAS~1qAM
9n 18 77
'BTAIN
wRITEr
wRITELM
WRIT£MSN
wRITETM
wRITLM
wRITM
wRITR'ST
wRSU
WRTBeeT
wRTMSOEv
wRT~eeT
W~T~eeT
xDELTA
Xr TCTRL..
X~IMIT
xMeNIT6R
XSL
z~FrL
OA
o~
oC
oD
oE
SQEvJr~
SVSn~~
8~MPT
F~GD
FRGn
PASC;3~A~
PAS~3~A~
c~c
PAS~t~A~
SOEvYr~
8eeT!-i'.J~~
eVE~VT~\·1
C~
TRAP
•••••••• •
WOeGPGM
wRITAM
wATc~oeA T!~~~
WR!T~
9~
1~"
90
ta 77
9r 18"
9~ 18 7'
9n 1~ "
9~ 18"
9~ 18 11
OC.01.~~
9~ lR
9~ 1~
NB
"
11
A/~
TA~IE
FILE~.
P~RF~RM ~~An
WR!T~S SVSG~~
ENT~V
M: A~S
LeAO
LeAD
W~ITr M:FRGn
W~IT£ ~tFRGn
WRITr
•
•
•• • •
FIl.,[
FReM ~T/EY. orvrcE
M6DULE wRTT£
Mq~ULFS
~~~E~AT~ e~~TA~LE p~qTr~N ~F
L'AD
BDM/8TM 8
M~OULE PA~TS
M~~UL~
Q"~T l.~AD MeDlf'-~ T~ ~~~T
SA~E AS WRIT~
~~T ~r~sT 8U'FER
eF
FIL.E
~UTPUT C~AtN
G~NE~AT~ Be~TA6LE P~~TreN ~F p~ TAFE
WRITE MtSO~v L6AO M~~UL~ T~ MtSOEV FrL
WRIT~
Mf'NtT~~ QeeT Tilt SWAP RAO
r~ITr'LIZATI~'" ~~~ULe:
9""
SVSTe:M
t:P
"'fANDLES EX I T
LA
~eUTINr
EXECUTIVE
SVSGF~
SVS~FN
9~
9~
JrT
VA
TSIe
TSIR
TSIR
D~
D~LTA
r"~JTRe, T~ D~L T"
~ReC£SSFS aLTMIT,B~'M!T,OL!~rT
P~~Crss~s UTM.M~NrT~~
BITS 20.23 A~ JIRNST, ~x£eUTfe~ .SEVE~1
D~LETE ~ILE ~TRECTe~v rNTRV
S~FTWA~~ CK • INceN~tSTANT ~~O'-R IN eL
~e~T~A~~ CK • Ne SENSE e~ 9EEK t N CL
TSI~
o~
seF"T~IARFr
TSI~
D~
seFTwA~~
q~'TWAQ~
XDELTA
·STEP
TST~GP
of
TSIA
1-00 SIMULATR eVE~VT~~
18 7'
1~ 17
K~.O~.C8
o~
D~
OR
8'
S~'TWARF
CK
CK
CK
CK
• ~AD ~~v PG , IN CL
• CL oer:'~N'T F~O AS EXPEe1'
• N8 C~
• BAD FrN PA~A~~T~P
INTE~p~~Tlvr ~IMULATeR
,TAP
93
~.SHA".I~L
0 •• O~
LeAD F"AU~ 8VTJ:'S F~e~ CA LL~'" S ~UFFER
7TAP
DA.03
TSI~
DP
D~
'.T~ACK TAF~ ~ANDLE~
~eFTwAR' CK • N ERRARS ~
q5
TSIs
O~
~~'TWA~~
4CHAR
g_
TSI~
S6~TWAR~
N~ CL ~eUND
CK • SAD e~~E~ ~N w~T ~K
CK • ~ !RR~~S ~ BAO Tf~ AOR
•
• •
•
• "
•
• •
•• •
•
•
•
•
• • •••••••• • •
................. ........................................................., .................,.......,.....
159
-
r
SrF
.•••••••.•................••.........
, ................... " ....... .........•..... ........••.....•..•......
N
MenUL~
~~~
IT~~
~~CTT"~
r~~ME~T
~
:USER~
Ace T
tUsr~(S
'J~,~.~1
'L~ljq~1
Ar
pc. a1
PC':·
L ~ GA ~ r: • c r ~ ~J N'T' T~J G LeG
Ace or
r. ~ 'T S U"~
Ace T S U11
ACCTSUM
ACCTSUM
ADDF
A~Dr
AI.TM~
ALTt"'~\J
ANALZ
A VR
At\JALZ
AVR
RACKU~
AAC~UP
ALTC P A L T r" P
SASIoofAt-luL
(RDT'\!
RAS~ A".J DLeI S( r ~
n:
M~ '-1 I T~ q
.AUT~~~TZED US~PS
T T~~ E
ACr ~ u ~.! T r N~
U~!)~T~ ftCr~UNT Lq(~,
~
r. s
R~ UT T~,I
~ u 8 D A LJ" ! ~! eo
REIt"Ae~ Tt"MP.rYLES
FILt"S
~A
A~D
T~ ~Y~FILE TA~L~R
r' e n : : c q n~ . C 4 L S 3 • ~ , 8 ,9 A, ! ~ T ~ Ape
"i~
LqAI'" ~LTe::~~"I~TE ~q\JIT~R r:'R~~1 1=,t\A'T'r:TLE
LE
·-.19
Source Exif Data:
File Type : PDF
File Type Extension : pdf
MIME Type : application/pdf
PDF Version : 1.3
Linearized : No
XMP Toolkit : Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:56:37
Producer : Adobe Acrobat 9.13 Paper Capture Plug-in
Modify Date : 2009:09:20 05:54:54-07:00
Create Date : 2009:09:20 05:54:54-07:00
Metadata Date : 2009:09:20 05:54:54-07:00
Format : application/pdf
Document ID : uuid:70885324-c1d0-41bb-9524-4bea686ff761
Instance ID : uuid:ec9cead8-5b9e-4b31-ab6d-03b3b4df1775
Page Layout : SinglePage
Page Mode : UseOutlines
Page Count : 171
EXIF Metadata provided by EXIF.tools