ESD TR 71 74_Computer_Operating_System_Capabilities_A_Source_Selection_and_Analysis_Aid_Nov70 74 Computer Operating System Capabilities A Source Selection And Analysis Aid Nov70

ESD-TR-71-74_Computer_Operating_System_Capabilities_A_Source_Selection_and_Analysis_Aid_Nov70 ESD-TR-71-74_Computer_Operating_System_Capabilities_A_Source_Selection_and_Analysis_Aid_Nov70

User Manual: ESD-TR-71-74_Computer_Operating_System_Capabilities_A_Source_Selection_and_Analysis_Aid_Nov70

Open the PDF directly: View PDF PDF.
Page Count: 257 [warning: Documents this large are best viewed by clicking the View PDF Link!]

ESD-TR-71-74
CIO
t'40
COMPUTER
OFKRATING
SYSTEMS
CAPABILITIES;
A
SOURCE
SELECTION
AND
ANALYSIS
AID
William
C.
Mittwede
~
November
1970
DEPUTY
FOR
COMMAND AND
MANAGEMENT
SYSTEMS
HQ
ELECTRONIC
SYSTEMS
DIVISION
(AFSC)
1.
G.
Hanscom
Field,
Bedford,
Massachusetts
01730
T61s
document
has
been
approved
for
public
release
and
sale;
its
distribution
is
r-
unlimited.
(Prepared
under
Contract
No.
F19628-70-C-0258
by
The
COMTRE
Corp.,
151
Sevilic
Avenue, Coral
Gables,
Florida
33134.)
NATIONAL
TECHNICAL
INFORMATION
SERVICE
$Pringfield, Va. 22,51
LEGAL
NOTICE
When
U.
S.
Government
drawings,
specifications
or
other
data are
used
for
any
purpose
other
than
a
definitely
reiated
government procurement
operation,
the
government
thereby
incurs
no
responsibility
nor
any
obligation
whatsoever;
and
the
fact
that
the
government
may
have
formulated,
furnished,
or
in
ary
way
sup-
plied
the said
drawings,
specifications,
or
other
data
is
not
to
be
regarded
by
implication
or
otherwise
as
in any
manner
lic-.nsing
the
holder
or
any
other
person
or
conveying
any
rights
or permission
to
manufacture,
use,
or
sell
any
patented
invention
that
may
in
any
way
be
related
thereto.
OTHER
NOTICES
Do
not
return
this copy.
Rctan
or
destroy.
ESD-TR-71-74
COMPUTER
OPERATING
SYSTEMS
CAPABILITIES;
A
SOURCE
SELECTION
AND
ANALYSIS
AID
William
C.
Mittwede
November
1970
DEPUTY
FOR
COMMAND
AND
MANAGEMENT
SYSTEMS
HQ
ELECTRONIC
SYSTEMS
DIVISION
(AFSC)
L.
G.
Hanscom
Field,
Bedford, Massachusetts
01730
This
document
has
been
approved
for
public
release
and
sale;
Its
distribution
Is
unlimited.
(Prepared
under
Contract No.
Fi9628-70-C-0258
by
The
COMTRE
Corp.,
151
Sevilla
Avenue, Coral Gables,
Florida
33134.)
FOREWORD
This
reporL
presents
the
results
of
an
analysis
conducted
by
The
Cu(4TRE
Corporation,
151
Sevilla
Ave.,
Coral
Gables,
Florida.
The
analysis was
conducted
under
Contract
F19628-70-C-0258
4ith
the
Air
Force
Electronic
Systems
Division
in
support
of
ProjecL
6917, Task
691701.
Dr.
John
B.
Goodenough,
ESD/MCDS, was
the
ESD
Contract
Monitor.
This
report
has
been reviewed
and
is
approved.
/
/,//. I
AL
RED
*
BEAUCHAMP'
EDMUND
R
USAF
Pfoject
Officer
Director,
Syste
Design
&
Dev
Deputy
for
Command
&
Management
Sys
iD
ABSTRACT
This
report
presents
a
method
For
translating
operational
data
processing
requirements
into
specific
criteria
For use
in
selecting,
validating
or
evaluating
computer
operating
systems.
The
criteria
have been
structured
on
the
beJis
of
an
integrated
functional classification
structure
applicable
to
the
executive/control
functions,
system
management
functions
and
data
manipulation
functions
of
currently
available
operating
systems.
In
concert
with
the
methodology
presented,
a
checklist
Form
is
included
as
an
aid
to
developing
selection
criteria
for
particular
applications.
A
diagram
of
the
functional
classification
structure
is
also
inclu',3d.
iii
CONTENTS
Section
I -
Introduction
I
1.1
Purpose
1
1.2
Scope
2
Section
I
ofI
co'lon
jnJ
LvaluQ1;un
Guidelines
2.1
Operating
System
Requirements
Identification
3
2.2
Evaluation
of
the
Environment
3
2.3
Basic
Performance
Decisions
5
2.4
Use
of
the
Selection
and
Evaluation
Criteria 8
Section
III
Specification
ind
Evaluation
Criteria 11
3.1
Introduction
11
3.2
Requirements
Checklist
-
Part
I -
Executive/
Control
Functions)
11
3.2.1
First
Level
of Detail
(Part
I -
Executive/
Control
Functions)
11
3.2.2
Second
Level
of
Detail
(Part
I -
Executive/
Cont"I
Functions)
19
3.2.3
Thira
Level
of
Detail
(Part
I -
Executive/
Control
Functions)
43
3.2.4
Fourth
Level
of
Detail
(Part
I -
Executive/
Control
Functions)
109
3.3
Requirements
Checklist
-
Port
II
-
System
Manage-
ment
Functions
149
3.3.1
First
Level
of
Detail
(Part
II -
System
Management
Functions)
149
3.3.2
Second
Level
of
Detail
(Part
II -
System
Management
Functions)
159
3.3.3
Third
Level
of
Detail
(Part
II -
System
Management
Functions)
175
3.4
Requirements
Checklist
-
Part
III
-
Data
Manipulation
Functions
185
3.4.1
First Level
of
Detail
(Part
III
-
Data
Manipu-
lotion
Functions)
185
3.4.2
Second
Level
of
Detail
(Part
III
-
Data Man-
ipulation
Functions)
193
3.4.3
Third
Level
of Detail
(Part
III
-
Data
ManipL.-
lotion
Functions)
205
3.4.4
Fourth
Level
of
Detail
(Part
III
-
Data
Man-
ipulation
Functions)
235
Attachment
I
-Computer
Operating
System
Functional
Classification
Structure
V
SECTION
I
INTRODUCTION
1.1
Purpos
This
report
is
the
second
of
a
series
currently
being
produced
by
The
COMTRE
C.,poration
for
the
Electronic
Sytems
Division
of
the
Air
Force
Systems
Command.
The
first
report
of
this
series,
ESD-TR-70-377,
Presented
an
integrated
functional
clas-
sification
structure
applicable
to
the
executive/control
functions,
system
management
functions,
and
data
manipulation
functions
of
currently
available
commercial
operating
systems.
A
third
report
will
establish
validation
requirements
for
major
computer
operating
systems.
In
this
report,
criteria
have
been
developed
within
the
hierarchical
structure
of
the
functional
classification
presented
in
ESD-TR-70-377.
Along
with
these
criteria,
methods
for
establishing
a
relationship
between
the
criteria
and
operational
require-
ments
have
been
delineated
for
each
criterion
or group
of
associated
criteria.
These
methods
are
intended
to
aid
in
specifying
operating
system
requirements
and
preparing
operating
system
specifications.
The
analysis
was
based
upon
the
following
considerations
relating
to
system
speci-
fication
practices:
1.
Frequently
criteria
can
be
specified
but
are
not;
this
is
usually
an
oversight
due
to
the
lack
of
a
comprehensive
list
of
system
specifications.
2.
Each
u.-ser
tends
to
specify
details
for
an
area
in
direct
proportion
to
his
knowledge
of
that
area;
frequently,
certain
functions
are
slighted
due
to
a
lack
of
expertise
in
that
area.
3.
Features
of
aesthetic
value,
though
not
firm
requirements,
can
often
L_
specified
to
further
enhance
system usage.
4.
The
level
of detail
included
within
a
specification
can
vary
according
to
the
intended
purpose
of
the
specification.
The
method
developed
by
this
analysis
provides
a
requirements
checklist
which
will
reduce
the
lack
of
specification
due
to
oversights.
Further,
the
requirements
checklist
is
keyed
to
references
which
will
provide
users
information
for
areas
in
which
they
may
not
be
experienced.
And
finally,
the
requirements
checklist
and
references
are
structured
into
several
levels
of
detail.
While
it
is
quite
likely
that
the
level
of
detail
will
vary
for
each
section
of
a
specification,
the
structure
of
the
checklist
is
such
that
the
required
level
of
detail
for
each
section
can
be
reached
in
a
methodical
manner.
During
the
preparation
of
this
report,
the
use
of
the
requirements
checklist
and
ussociated
.eferences
as
an
aid
in
e--1-
,, , ;,
nrnoosed
systems
hecame
apparent.
During
the
evaluation
process
the
proposed
operating
system
design
can
be
compared
against
the
system
functional
structure
included
within
the
checklist
to
ascerta;n
com-
pleteness.
Then,
by
using
the
reference material,
the
methods
which
appear
to
be
most
applicable
to
the
given
problem
and
to
best
satisfy the
operational
requirements
can
be
systematically
determined.
The
entire
checklist
and
references
can
be
used
in
this
manner;
however,
levels
three
and
four
appear
to
be
ihe
most
appropriate
for
detailed evaluation.
1.2
Scope
The
analysis
in this
report
relates
operational
performance
requirements
to
specific
operating
system
requirements
for
executive/control
functions,
system
manogement
tunctions
and
data
manipulation
functions.
Requirements ore
related
to
functions
in
terms
of
specific
criteria
for
periormance
specification
or
evaluation.
This
report
is
presented
in
three
sections
with
one
supporting
attachment.
Sec-
tlon
2
presents
a
description
of
the
techniques
identified
for
determining
operating
system
performance requirements.
Section
3
presents
the
selection
and
evaluation
criteria
accompanied
by
explanatory
references.
Finally,
a
diagram
depicting
an
overview
of
the
operating
system
functional
classification
structure
corresponding
to
the
checklist
levels
of
detail
is
attached
to
this
report.
T
his
diagram
can
be
used
ci
a
reference
by
personnel
using
the
checklist
to
determine
the
association
of
the
area
in
which
they
are
working
with
the
total
classification
structure.
2
SECTION
II
SPECIFICATION
AND
EVALUATION
GUIDELINES
2.
1
Operating
System
Requirements
Identification
The
techniques
for
determining
operating
system
performance
requirements
can
best
be
described
as
a
procedure
consisting
of
three
to six
steps.
The
first
step
consists
wt
,C"
vauating
the
system
environment.
The
second step
consists
of
making
basic
system
performance
decisions.
The
tiiird
step
consists
of specifying
performance
criteria
at
a
general
level.
The
fourth,
fifth
and sixth
steps
amplify
the
third
step
at
successively
greater levels
of
detail.
The
total
number
of
steps
used
during
the
selection of
any
particular
operating
system
varies
depending
upon
t
e
permissable
level
of
detail
for
the
particular
selection.
The
appropriate
level
of detail,
in
turn,
varies
with
the
circumstances
of
a
particular
application
of
the
selection
technique.
For
example,
if
the
technique
is
being
applied
for
the
pu-pose
of
developing
on
operating
system
specification
for
a
known
hardware
configuration
then
the
specification
will
probably
be
of
a
more
detailed
form
than
if
the
specification
were
prepared
as
part
of
a
hardware
solicitation.
2.2
Evaluation
of
the
Environment
The
first
step
in
l.e
-rocedure
discussed
above
is
on
evaluation
of
the
environ-
ment
in
which
the
operating
system
will
be
expected
to
perform.
This
step
does
no
more
than
establish
an
overview
of
the
intent
of
the
system
procedurally.
It
is,
however,
very
impo~tant
since
it
establishes
the
framewcrk
upon
which
most
further
decisions
will
be
made.
Often,
the
essential
capabilities
necessary
to
satisfy
a
set
of
requirements
can
be
envisioned
conceptually
or
are
known
from
post
experience.
In
such
cases
an
evaluation
of
this
information
will
determine
the
basic
characteristics
of
the
operating
system
env-ronment.
In
any
case,
however,
the
following
environmental
character-
istics
should
be
determined:
a
First,
determine
the
salient
character,'tics
of
the
processing
modes
which
must
be
supported
by
the
system.
3
It
is
very important
in
the
further
development
of specific
requirements to
char-
acterize
system
processing
as
real-time,
batch,
remote
batch
or
time-sharing. It
is
also
necessary
to
determine
if
a
mixture
of
processing
modes
must
be
supported,
e.g.,
time-sharing
and
batch,
real time
and
batch,
etc.
If
the
system
is
to
perform
computation
that
controls
an
ongoing
process
and
delivers
its
outputs
(or
control
inouts)
not
later
than the
time
needed
for
effective
control
of
f'e
process,
then
the
processing
mode
is
real
time.
This
mode
is
usually
ass
ciated
with
air
defense
systems,
ballistic
missile
checkout/control,
space
vehicle
checkout/control,
etc.
Most
operating
systems
with
the
exception
of
some
real-time
processing
systems
allow
the processing
of
jobs
submitted
to
run
inde,.ondently
of
events
outside
the
system
on
a
deferred
or
time-independent
basis
(e.g.,
whenever
the
processing
work-
load
is
light).
If
the
system
is
to
support
this
type
of
processing,
then
the
processing
mode
is
batch.
Many
times
this
feature
is
required
for
remote
sites
as
well
as
the
nor-
mal
local
site
usage
which
means
that
the
environment
will
also consist
of
a
remote
batch
mode.
Finally,
if
the
system
is
to
support
concurrent
processing
capabilities
for
several
users
via
multiple
terminals,
then
the
mode
is
time-shoring.
o
Second,
develop
an
application
program
scenario.
Although
it
has
been
determined
by
defining
the
processing
mode
that
the
appli-
cation
programs
will
be
either
batch/time-sharing/real
time,
there
should
also
be
many
other
known
application
support
requirements.
To
formalize
these
requirements
it
is
best
to
examine known
applications
or
develop
concepts
re:tive
to
anticipated
applications.
Since
the
specification
of
requirements
for
an
operating
system
depends
to
a
large
extent
upon
the
satisfaction
of
application
orogram
requirements,
it
is
necessary
to
develop
an
operational
scenario
for
the
application
programs.
This
scenario
should
include
such items
as
program
descriptions,
estimated
program
s;zes,
respon
time requirements,
concurrency
requirements,
interaction
requirements,
irter-
dependency
requirements,
operational hierarchy
requirements,
anticipated
or
known
structural
requirements,
expsected
utilization,
and
unique
features
.r
requirements
ex-
hibited
by
the
application
programs.
4
o
Third,
delineate
all
known
hardware
configuration
information.
This
consideration
is
simplified
in
areas
where the hardware
Is
knc,wn
and
a
new
operating
system
is
being
acquired.
However,
when
a
total
hardware
and
software
system
is
being
acquired,
as
is
often
the
case,
this
delineation
can
be
quite
difficult.
Nevertheless,
specification
or
postulation
of
a
detailed
hardware
configuration
shold
be
accomplished
if
possible,
since
knowledge
of
a
configuration
is
requisite
to
devel-
opment
of
many
specific
criteria.
The
delineai.-n
of
peripheral
and
communication
devices
is
important
as
well
as
that
of
the
processor
configuration
and
the
size
or
estimated
size
of
the
system.
Within
the
framework
of
Section III
of
this
report,
reference
is
sometimes
made
to
the
size
]
of
the
system
as
a
guide
to
applicable
re-
quirements.
Previous
analyses
of
various
oper.
ring
s,stems
has
shown
that
the
occur-
rence
of
several
features
tends
to
be
closely
related
to
the
system
size.
The
considerations
listed
above
define
the
operating
system
environment,
an
application
program
scenario,
and
a
specific
hardware
configuration.
From
this
information,
further
decisions
can
be made
regarding
the
expected
performance
of
the
system.
2.3
Basic
Performance
Decisions
As
discussed
above,
there
are
certain
decisions
that
should
be
made
concerning
the
expected
performance
of
the
operating
ystern.
These
decisions
provide
an
in-
I
sight
into
the
totad
operational
philciophy
of
the
system
and
directly
affect
the
appli-
cobility
of
-pecific
requirements
for
specification
ot
evaluation.
The
following
topics
and
"scussions
are
designed
to
aid
in
making
these
decisions.
o
Processing
performnnce
Once
the
operating
systen
environment
has
been
established
and
the
applications
delineated,
the
next
step
shoul'i
be
to
consider the
need
or
lack
of
need
for
multi-
For
the
purposes
of this
report,
system
size
corresponds
to
the
Operating
System
levels
presented
in
ESD-TR-70-65,
Survey
and
Analysis
of
Major
Computing
Operating
Systems,
31
Jcnuary
1970.
Thc5e
levels
are:
-
small
scale
computers
with
core
storage
generally
less
than
32K
bytes
(where
i: ;
a
byte
consists
of
8
bits):
-
medium
scale
computers
with
core storage
ranging
from
32K
bytes
to
132K
bytes;
and
-
large scale
computers
with
core
storage
in
excess
of
132K
bytes.
5
program
processing.
If
the
application
scenario
previously
developed
indicates
that
the
operating
system
must
support
concurrent
core
residence
and
processing
of
multiple
?rograms,
then
multiprogramming
is
required.
If
there
appears
to
be
reason
to expect
that
simultaneous
execution of
programs
is
required
then
this
may
dictate
the consid-
eration
of
a
multiprocessor
hardware
configuration.
However,
if
requirements
indicate
that
concurrency
of
application
operation
is
not
an
absolute
prerequisite,
then
serial
processing
may
also
be
ac:eptable.
The
type
of
processing
environment (batch,
time-sharing,
real
time)
can
affect
the
operational
philosophy
of
the
syst,-m
in
the
following
respect.
In
a
batch
pro-
cessing
syste
,-
individual
job
throughput
may
not
be
of
prime
concern
due
to
the
usual
background
nature
of
the
jobs
supported;
therefore,
maximum
utilization
of
system
resources
is
usually
more
important
than
the
amount
of
system
overhead
incurred.
On
the
other
hand,
a
time-sharing
system
would
strive
for
a
balance
between
resource
utilization
versus
incurred
overhead
due
to
the
requirement
to
interact
and support
multiple
users.
Fina!ly, a
real-time
processing
system
usually
stresses
low
overhead
and
requires
maximum
job
throughput
with
resource
utilization
being
of
only
secondary
concern.
Therefore,
tradeoff
decisions
need
to
be
made
relative
to
serial
versus
multi-
program
processing,
and
overhead
versus
throughput
versus
resource
utilization
of
the
processing
system.
o
Mode
of
operational
support
There
are
two
basic
modes
of
operation
supported
by
operating
systems.
These
are:
continuous
operational
capability
over
an
extended period
of
time
and
scheduled
operation over
a fixed
period
of
time,
e.g.,
eight-hour
shift
per
day.
The
major
difference
between
these
modes
of
operation
is
the
criticality
of
the
processing supported.
Continuous
operation
is
not
normally
a
requirement
for
batch
processing
while it
is
almost
mandatory
for
real-time
processing
and
may
be
highly
desirable
for
some
time-sharing
systems.
The
determination
of
which
of
these
modes
of
operation
is
to
be
provided
by
the
system
will
aid
in
the
determination
of
how
comprehensive
the
error recovery require-
ments
will
be,
whether
on-line
maintenance
or
periodically
scheduled
off-line
main-
tenance
will
be
required,
and
whether
on-line
o-
off-line
program
checkout
will
be
6
necessary.
If
the
system
is
to
provide
the
capability
for
continuous
support
with
very
little
down
time,
then comprehensive
error
recovery
procedures,
on-line
maintenance,
and
on-lint
rrogram
checkout
should
receive
definite
consideration.
This
decision
can
also
affect
the hardware
configuration
since equipment
redundancy,
either
on
-line
or
off-line,
is
frequently
required for
continuous
support.
o
Type
of
user
personnel
Whn
it
is
known
that
the
system
must
interface
with
and
accomodate
users
with
limited
programming
interests,
such
as
in
a
general
time-sharing
system,
greater
attention
should
be
paid
to
the
area
of
diaqnostics
and
system
communication.
This
attention
should
focus
upon
the
ease
of
usage,
clear
and
simple
messages,
and
clear
and
simple
instructions.
If
the
system
is
real-time,
the
user
can
usually
be
assumed
to
be
a
sophisticated
assembly
or
machine language
programmer
familiar
with
the
internal
organization
of
the
computer;
and
although
diagnostic
and
debug
features
are
very
important, they
do
not
require
the
level
of
explanation
and
simplicity
required for general
time-
sharing
usage.
o
Type
of
checkout
supported
If
a
system
is
to
provide
continuous
operational
support,
then
a
method
should
be
considered
for
allowing
application
program
checkout
concurrent
with
on-line
operations.
This
would probably
involve
the
utilization
of
a
special checkout
mode
and
therefore
require
special
operating
system
support.
This
feature
is
required
mcst
frequently
in
real-time
processing
systems
and
is
usually
also
standard
in
time-sharing
processing
systems.
o
Operational
philosophy
of
ihe
system
The
question
of
manual
intervention
versus
automatic decision
making
must
be
cons;d4red.
Will
the
operating
system be
hig['y
dependent
upon
operator
interven-
tion
or
will
the
operating
system
be
as
independent
as
possible
requiri,
very
little
operator
intervention?
I
o
Maintainability
Certain
basic
decisions
should
be
made
concerning
the
capabilities
to
maintain
the
system
operationally,
e.g.,
the
ease
of
updating,
changing,
deleting,
generating,
and
initializing,
and
the
support
to
be
provided
for
changing
hardware
configurations.
7
o
Reliability
This
function
is
important
to
all
sy.-erns
but
the
real-time
environment
usually
has
the
most
stringent
requirements
in
this
area.
Specifications
for
this
area
should
con-
sider
the
degree
of
editing.
error
checking,
fault
isolation,
operational
degradation,
etc.,
that
will
be
required
by
the
operating
system.
o
Expandability
Finally,
it
should
be
determined
if
the
operating
system
may
be
required
to
per-
form
additional
functions
in
the
future
above
and
beyond
those
described
within
the
application
scenario.
This
decision
can
affect
the
selection
of
certain
requirements
which
will
ease
the
required
operational
transition
o
a
later
date.
When
all
of
these
considerations
have
been
assessed,
the
next
step
is
to
select
the
requirements
that
will
best
satisfy
the
decisions
made.
2.4
Use
of
the
Selection
and
Evaluation
Criteria
The
third
through
sixth
steps
used
in
selecting
operating
system
requirements
are
found
within
Section
III
of
this
report.
Section
III
contains
requirements
checklists
and
references
to
aid
in
the
selection
of
requirements
for
an
operating
system
or for
the
evaluation
of
a
proposed
operating
system.
These
requirements
checklists
are
constructed
within
the
framework
established
by
the
Operating
System
Functional
Classification
Structure.
The
entire
structure
as
it
relates to requirement
specifica-
tion
is
depicted
in
Attachment
1
to
this
report.
As
shown
in the
attachment,
the major
operating
system
areas
consist
of:
1)
Executive/Control
Functions,
2)
System
Management
Functions,
and
3)
Data
Manipulation
Functions.
Each
of
these
major
functionel
areas
is
broken
down
into
hierarchical
levels
of
functions
contained
within
the
major
functional
areas.
For
example,
within
the
major
functional
area
Executive/Control
the
first
level
grouping
is:
1.0
JOB
MANAGEMENT,
2.0
DIAGNOSTIC
ERROR
PROCESSING, and
3.0
PROCESSING
SUPPORT,
while
the
second
level
grouping
consists
of
such
functions
as
1.1
JOB
CONTROL,
1.2
I/O
CONTROL,
1.3
SYSTEM
COMMUNICATION,
1.4
RECOVERY
PROCESSING,
2.1
HARDWARE
ERROR
CONTROL,
2.2
PROGRAM
ERROR
CONTROL,
etc.
Each
lower
level
is a
more
detailed
functional
breakdown
of
the
functions
of
the
preceding
higher
level.
In
certain
functional
areas
this
structure
8
is
subdivided
into
only
two
levels,
while
in
other
areas
it
is
subdivided
into
as
many
as
four.
Similarly,
the
requirements
checklist
has
also
been
structured
by
the
same
hier-
archical
levels and
are
presented
for
each
of
the three major
functional
areas
(Execu-
tive/Control,
System
Management,
and
Data
Manipulation).
The
presentation
of
the
functions in
the group
level
format provides
a
procedural
structure
which
allows
personnel
using
the
checklist
t
,
perform
a
step-by-step
progression
to
the
level
of
deliil
required
for
a
particular
application.
Also, this type
of
structure
provides
a
total
system
overview at
each
level.
This
is
highly important
in
developing
an
understanding
of
the
entire
operating
system
structure.
With
this
in
mind, the
attached
diagram
illustrating
an
overview
of
all
levels
of
the
hierarchical
structure
will
also
enable
the
user
to
relate
each
particular
function
to
the
composite
structure.
The
level
to
which
the
requirements
are
selected
for
specification
is
dependent
upon
many
fa,;tors
and
an
absolute
rule
can
not
be
applied
to
determine
the
number
of
levels
that
should
be
used.
In
many
cases
the
level
to
which
the
requirements
can
be
specified
is
dependent
upon
the
detailed
knowledge
or
information
available
for
particular
system's
applications.
In
other
cases
the
level
of
specification
may
vary
according
to
particular
circumstances.
During
the
preparation
of
operating
system
specifications,
it
can
be
generally
assumed
that
for
a
known hardware
configuration
the
entire
checklist
should
be
used.
In
preparing
a
specification
for
an
unknown
hardware
configuration,
the
first
two
levels
are
most
appropriate,
while
caution
shouid
be
exercised
in
specifying
the
requirements
appearing
in
levels
three
and
four.
The
reason
for
this
is
that
many
of
the
methods
used
to
implement
operating
systems
are
directly
related
to
the
hardware
upon
which
the
operating
system
functions.
Hence,
many
operating
systems
perform
the
same
function
using
different
methods.
Consequently,
delineation
of
specific
requirements
for
operating
system
functions
may
lead
to
a
choice
between
different
implementation
methods,
the
specification
of
either
of
which
would
be
overly
re-
strictive
for
a
competitive
procurement.
A
word
of
caution
should
be
interjected
at
this
point:
The
requirements
check-
list
is
to
be
a
working
document
used
by
personnel
to
indicate
requirements
for
an
operating
system.
A
detailed
review
by
the
personnel
preparing
the
final
solicitation
9
document
must
be
conducted to
detect
the
specification
of
any
improper
or
superficial
requirements.
The
danger
in
using
a
checklist
of
the
type
proposed
is
that
criteria
can
be
specified,
when
in
fact
the
criteria
are
not
needed.
Consequently,
the
user
must
continually
recognize
that
valid justification
is
still
necessary
prior
to
the
selection
of
any
requirement.
Finally,
it
is a
near
certainty
that
although this
is a
fairly
comprehensive
check-
list,
there
will
still
be
some
user
requirements
or
methods
of stating
requirements
other
than
those
that
appear
within
the
check!ist.
These
requirements,
when
they occur,
should
first
be
incorporated
within
the
system
specification
by
the
user
and
along
with
available
reference
material
should
also
become
a
permanent
part
of
an
updated
check-
list.
This
will
insure
that
the
checklist
remains
a
comprehensive
tool in
performing
operating
system
specification,
selection
and
evaluation.
A
user
can
use
his own
discretion
in
how
he
designates
(e.g.,
yes,
no,
manda-
tory,
optional,
etc.)
that
a
requirement
is a
criterion
for
his
particular
system.
An
example
of
this
using page
44
(1.1.1
SCHEDULING)
of
this report
as
reference
is as
follows:
The
user
has
an
extremely
complex
scheduling
requirement
(several
jobs
compel-
ing
for
execution),
so
he
would
place
a
"yes"
by
requirement
(a).
Since
he
has
several
jobs
in
competition,
he
would
place
a
"yes"
by
requirement
(f),
and
if
he
knew
the
number
of
possible
jobs
in
contention,
he
would
fill
in
the
blank
within
requirement
(f),
etc.
In
many
cases
a
requirement
can
be
specified
as
"Mandatory"
and
this
can
be
used
as
a
designator
by
the
user,
or
a
requirement
may
be
specified
as
"Optional"
to
mean
that
if
a
system
has
this feature,
it
is
an
added
feature
and
will
be
a
weighting
factor
during
final
system
selection.
10
SECTION
III
SPECIFICATION
AND
EVALUATION
CRITERIA
3.1
Introduction
This
section
presents
the
operating
system
requirements
checklist
discussed
in
Section
II.
The
checklist
consists
of
a
column
of
requirements
applicable
to
each
functional
classification
area,
followed
by
three
columns
entitled
"Reference",
"Initial",
and "Extended."
The
"Reference"
column
contains
reference
numbers
adjacent
to
the
requirement
or requirements
to
which they
are
applicable.
These
reference
numbers
coincide
with
the
list
of
references
on
the
facing
page.
These
references
will
aid
in
the
determin-
ation
of
whether
the
requirement
should
be
specified
or
is
applicable
for
specification
for
a
particular
operating
system.
As
with
the
requirements
checklist,
the
references
are
intended
to
be
open-ended.
The
references
should
be
extended
as
users
identify
additional
considerations.
The
column
entitled
"Initial"
is
to
be
used
by
personnel
using
the
checklist
to
indicate
whether
a
requirement
6
a
criterion
for
Ohe
initial
phase
of
the
particlar
operating
system
which
is
being
specified;
while
the
column
entitled
"Extended"
is
to
be
used
to
indicate
requirements
that
will
be
included
within
the
operating
system
at
a
later
date
but
are
not required
for
initial
installation.
It
should also
be
noted
that
within
certain
listed
rmquirements
blanks
are
available
for
insertina
parameters
when
their
values
are
known.
3.2
Requirements
Checklist
-
Part
I -
Executive/Control
Functions
The
following
subsections present
specification
and
evaluation
criteria
for
the
components
of
the
operating
system
that maintain
real-time
execution
control
over
the
system
environment.
3. 2. 1
First
Level
of
Detail
(Part
I -
Executive/Control
Functions)
This
suhsection
covers the
following
first level
executive/control
functions:
1.0
JOB
MANAGEMENT
2.0
DIAGNOSTIC
ERROR
PROCESSING
3.0
PROCESSING
SUPPORT
!1
F!
REQUIREMENTS
OPERATING
SYSTEM
- -
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.0
JOB
MANAGEMENT
1
(a)
Batch
processing
support
m
ist
be
provided.
2
(b)
Real-time
support
must
be
provided.
2
(c)
Time-sharing
support
must
be
provided.
( q
Multiprogramming
support
must
be
provided.
3
(e)
Multiprocessing
support
must
be
provided
for
4
processors.
1
2ii
i ii i
1.0
JOB
MANAGEMENT
Reference:
1.
The
job
management
function
is
responsible
for
the
initiation,
scheduling,
monitoring,
and
control
of
system
operations
for
all
jobs
submitted
to
tie
system.
In
this
context,
a
job
encompasses
all
of
the
programs
required
for
the
execution of
a
given
application.
The
job
management
subfunc-
tions
consist
of: job
control,
input/output
control,
system
communication,
and
recovery
processing.
2.
The
operational
environment
(batch,
real-time,
time-sharing)
of
a
system
is
directly
established
by
the
intended
system
applications.
3.
Multprogramming
is a
technique
that
attempts
to
maximize
computer
throughput
by
interleaving
the
execution
of
two
or
more
programs.
Nor-
mally,
multiprogramming
is
not
a
requirement
as
long
as
system
throughput
requirements
can
be
met
in
a
non-multiprogrammed
manner.
However,
some
systems
require
multiprogramming
as
a
firm
operational
requirement
without
regard
to
throughput.
These
systems
are
normally
those
that
combine
two
or
more
processing
environments
(such
as
batch
and
real-time
process-
ing)
or
those
that
are
communication
based
systems
using
multiple
terminals
and
requiring
multiprogramming techniques
due
to
the
large
number
of
con-
current
messages
received.
4.
This
criterion
is
entirely
dependent
upon
the hardware
configuration
and
can
only
be
specified
when
the
configuration
is
known.
13
RE
QU
IREM
ENT
S
OPERATING
SYSTEM
nn
MENTS''
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.0
DIAGNOSTIC
ERROR
PROCESSING
I
(a)
The
system
must
provide
hardware
error
control.
2
(b)
The system
must
provide
program
error
control.
3
(c)
The
system
must
provide
interface
error
control.
4
(d)
The
system
must
provide
error
recovery
procedures.
5
14
2.0
DIAGNOSTIC
ERROR
PROCESSING
Reference:
1.
The
diagnostic
error
processing
function
is
responsible for
recognizing
hard-
ware,
program
cnd
interface
errors.
Recognition
is
usually
based
upon
hard-
ware
interrupts
or
program
testable
switches.
The
function
also
supports
the
diagnosis
and
resolution
of
error
conditions.
2.
This
criterion
is
highly
dependent
upon
the
hardware
configuration
and can
only
be
specified
in
detail
when
the
hardware
configuration
is
known.
3.
This
criterion
is
rarely specified.
However,
it
may
be
necessar>
to
specify
it
when
there
will
be
a
iarge
amount
of
program
testing
in
a
batch
processing
or
time-sharing
environment
or
if
the
system
operates
in
an
on-line
real-time
environment.
4.
Usually
any
interface
that
can
exhibit
control,
introduce
control,
request
control
or
initiate
an
executive
function
should
be
edited.
The
editing
performed
is
generally
ba-ed
upon
system
defined
format
constraints.
5.
Error
recovery
routirns
are usually
provided
with
a
system
and
they
may
be
augmented
by
the
installation
during
system
generation.
Augmentation
or
redesign
of
error
recovery routines
is
most
frequently
found
in
real-time
environments.
This
function
should
be
specified
for
all
processing
systems.
15
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extendc...
3.0
PROCESSING
SUPPORT
I
(a)
The system
must
provide
a
timing
service.
2
(b)
The
system
must
provide
testing/debugging
service.
3
(c)
The system
must
provide
a
logging
and
accounting
service.
(d)
The system
must
provide
system
description
maintenance.
4
16
3.0
PROCESSING
SUPPORT
Reference:
1.
The
processing
support
functions
consist
of
supervisor
routines
which
may
be
called
upon
to accomplish
a
variety
of
miscellaneous services
for
an
application
program.
In
general
the services
are
utilitarian
in
nature
and
provide
conven-
ient,
rather
than
necessary,
functional
support.
2.
Most
systems
have
an
internal
timing
device
which
provides
timing
services
to
application
programs.
A
few
systems,
to reduce
the
size
of
the resident
super-
visor,
only
include
these
services
as
an
option
during
system
generation.
This
tfature
is
highly
desirable
in
a
real-time
processing
system
and
frequently
occurs in both
the batch
processing
and
time-sharing
environments.
3. In a
real-time
environment
testing/debugging
service
spccifications
should
take
advantage
of
any
specially
provided
hardware
processing
modes.
4.
This
criterion
is
rarely specified.
However,
it
may be
advisable
when
a
single
set
of
app
;cation
and/or
system
programs
are to
be
executed
usinq
two
or
more
hardware
configurations
so
that
the
programs
may
tailor
themselves
to
the
specific
hardware
or
software
environment.
17
3.2.2
Second
Level
of
Detail
(Part
I -
Executive/Control
Functions)
This
subsection
covers
the
following
second
level
executive/control
func-
tions:
1.1
JOB
CONTROL
1.2
I/O
CONTROL
1.3
SYSTEM
COMMUNICATION
1.4
RECOVERY
PROCESSING
2.1
HARDWARE
ERROR
CONTROL
2.2
PROGRAM
ERROR
CONTROL
2.3
INTERFACE
ERROR
CONTROL
3.1
TIMING
SERVICE
3.2
TESTING/DEBUGGING
SERVICE
3.3
LOGCING
AND
ACCOUNTING
3.4
PROGRAM
ACCESSIBLE
SYSTEM
DESCRIPTION
MAINTENANCE
19
REQUIREMEI
!TS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1
JOB
CONTROL
1
(a)
The
system
must
provide
support
for
the
concurrent
2
execution
of
up
to batch
jobs.
(b-c)
Batch
support
must
be
provided
for:
(b)
cen'.ral
site
job
entry,
(c)
remote
job
entry.
(d)
The system
must
support
remote
job
entry
batch
3
terminals.
(e)
The system
must
provide
support
for
the
concurrent
2
execution
of
up
to
real-time
jobs.
(f)
The
maximum
service
time
for
a
real-time
request
4
under
average
load
conditions
is
(g)
The
maximum
service
time
for
a
real-tlme
request
4
under
maximum
load
conditions
is
(h)
The
system
must
provide
control for
real-time
jobs
initiated
by
clock
interrupts.
(i)
The
system
must
provide
support
for
the
concurrent
5
execution
of
up
to
time-sharing
jobs.
(j)
The
system
must
support,
at
a
maximum,
simultaneous
submission
of
jobs
from
terminals.
(k)
The
system
must
support,
on
the
average,
simultaneous
submission
of
jobs
from
terminals.
(I-m)
The
system
must
provide
a
response
to
interactive
4
terminals
within
a
time
frame
(I)
of
during
maximum
load
conditions,
(m)
of-during
average
load
conditions.
20
1.1
JOB
CONTROL
Reference,
1. D,
not
overlook
any future
expansion
requirements
in
this
area
since
it
will
I
obably
be
more
economical
to
include
these
requirements
in
the
basic
system
rn"her
than
to change
the
system
at
a
later
date.
2.
While frequently
employed
for
evaluation,
this
criterion
is
rarely
speci-
fied.
However,
it
may
be
necessary
under
the
fol!owing
circumstances:
a.
enough
information
is
known
about
the
real-time
environment
to
determine
the
number
of
independent
real-time
processes/
interrupts
requiring
near-simultaneous
servicing
b.
sufficient
information
is
known
about
the
hardwai
config-
uration,
throughput
requirements,
and
projected
batch
processing
load
to
dictate
a
level
of
accuracy.
3.
This
criterion
is
entirely
dependent
upon
the
hardware
configuration
and can
only
be
specified
when
the
configuration
is
known.
4.
This
criterion
should
be
specified
when
system
response
time
requirements
are
known.
5.
This
criterion
should
be
specified
for
a
time-sharing
sysgm.
24
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
inl;ial
Extended
1.2
1/0
CONTROL
1,2
(a)
The
system
must
support
I/0
scheduling.
3
(b)
The system
must
provide
support
for
up
to
remote
4
terminals.
(c)
The
system
must
permit
the
concurrent
activity
of
up
4,5
to
remote
terminals.
(d)
The
system
must
provide
support
for
up
In I/0
devices.
(e)
The system
must
support
the
concurrent
operation
of
up
6
to
devices.
(f)
The
system
must
provide
support
for
up
to
I/0
7
processors
or
channels.
(g)
The
system
must
support the
concurrent
operation
of
up
7
to
I/0
processors
or
channel.
(h-o)
The
system
must
support
the
following
device
types/
7
number
of
device
types:
(h)
unit
record
devices,
(i)
paper
tape
units,
(j)
magnetic
tape
units,
(k)
-console
typewriters,
(I) -
display
devices,
(m)
direct
access
storage
devices,
(n)
___plotters,
(o)
extended
core
storage.
22
1.2
I/O
CONTROL
Reference:
1.
System
control
over
the
activity
of
input
and
output
devices
is
a
characteristic
feature
of third-generation
operating
systems.
This
control
is
maintained
for
two
separate
reasons.
First,
it
simplifies
the
work
of
the
application
program-
mer
since
he
need
not
be
concerned
with
the
intricate
details
of
programming
for
a
variety
of
channel
and
device
characteristics.
This
upgrades
the
overall
effectiveness
of
the
programming
staff
since
a
standard
and
well
defined
approach,
rather
than
a
number
of
widely
varying
approaches,
is
always
used
to
interface
with
I/0
devices.
Secondly, since the
system
is
in
control
of
I/0
activity,
the
application
program
need
not
be
alerted
to
process
I/0
interrupts.
•
2.
Future
expansion
requirements
should
be
factored
into
the
quantity
of
each
device
to
be
supported.
3.
I/0
scheduling
is
the
process
of
acknowledging
a
request
for
I/0
services
and
initiating
the
physical
input
or
output
operations
to
satisfy
the
request.
Requests
for
service
may
be
processed
immediately
or
they
may be
serviced
according
to
a
queuing
scheme.
In
the
latter
case,
queues
are
provided
to
hold
requests
for
channel
or
device
services.
This
criterion
should
be
specified
for
all
system
environments.
4.
This
criterion
should
be
specified
for
either
a
time-sharing
or
remote
batch
processing
system.
It
may
only
be
specified
in
detail
when the
hardware
configuration
is
known.
5.
If
it
is
possible
that
all
remote
terminals
will
be
interacting
or
functioning
with
the
system
at
any
particular
time,
then
the
number
of
rer
ate
terminals
will
equal
the
number
requiring
concurrent
activity.
6.
This
value
should
be
de'
rmined
by
the
anticipated
utilization
under
peak
loading
conditions.
7.
This
criterion
is
highly dependent
upon
the
hardware
configuration
and
can
only
be
specified
in
detail
when
the
hardware
configuration
is
known.
23
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3
SYSTEM
COMMUNICATIONI
(a)
The
system
must
permit
up
to
operator
terminals/
2
displays.
(b)
The
system
must
permit
up
to
user
term'inals/
2
displays.
(c-f)
The
system
must
support
the
following
types
of
2
operator
and
user
communication devices:
(c)
card
reader,
3
(d)
console
typewriter,
(e)
typewriter-CRT
display,
4
(f)
ty
pewriter-printer.
4
(g)
The
system
must
provide
device
independent
communi-
5
cation
formats.
(h)
System
startup
must
be
provided.
24
1.3
SYSTEM
COMMUNICATION
Reference:
1.
System
communication incorporates
all
of
the
functions
involved
in
the
exchange
of
information
between
the
user
or
the
computer
-nerator
and
the
operating
system.
The
communication
may
be
oriented
either
to
controlling
the
execution
of
scheduled
jobs
within
the
system
or
to
configuring
system
components
and
monitoring
system
status.
2.
This
criterion
is
dependent
upon
the
hardware
configuration
and can
only
be
specified
in
detail
when
the
hardware
configuration
is
known.
Potential
expansion requirements
should
also
be
considered.
3.
The
use
of
a
card reader
as
a
communication
device
is
usually
only
associated
with
local
or remote
batch
processing.
4.
Typewriter
printers
and
typewriter-CRT
displays
can
be
associated
with
both
time-sharing
and
real-time
environments.
5.
Providing
device
independent communication
formats
entails
much
planning
in
the
design
pl.ase;
however,
it
is
quite worthwhile
to
the
user.
This
feature
allows
any
communication
device
to
be
substituted for another
device
type
without greatly
affecting
operation.
Furthermore,
this
method
of
format
standardization
can
be
an
economical
factor in
user
job
and
program
prep-
aration.
Consequently,
it
should
be
seriously
considered
during
the
develop-
ment
of
specifications
or
during
the
e,
:!-gotion
of
system
proposals.
A
25
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.4
RECOVERY
PROCESSING
(a-b)
The
system
must
provide
checkpoint/restart
facilities
1,2
at
the
following
levels:
(a)
program,
3
(b)
system.
(c)
The
system
must
provide
restart for
all
suspended
3
programs.
26
1.4
RECOVERY
PROCESSING
Reference:
1.
Checkpoint/restart
facilities
are
normally
invoked
whenever error
processing
routines
have
analyzed
an
error
and
determined
that
execution
should
be
resumed
from
an
earlier
point
in the
processing
cycie.
Consequently,
check-
point/restart
usually
supplements
normal
error
recovery
operations
and should
be
considered
for
specification
in
all
system
environments.
2.
Checkpointing
may be
performed
at
either
the
system
level
or
the
program
level.
Only
in
rare
circumstances
are
both
provided.
The
system
level checkpoints
the
entire
system
whereas
the
program
level
only
checkpoints
a
single
program.
Consequently,
in
a
real-time
system
checkpoint/restart
facilities
are
generally
initiatc
d
at
the
system
level
rather
than
the
program
level.
In
a
batch
pro-
cessing
or
time-sharing
system,
on
the
other
hand,
checkpoi,;jrestart
facilities
are
most
likely
to
be
initiated
at
the
program
level.
3.
When
checkpointing
is
performed
at
the
program
level,
a
checkpoint
nwy
also
be
used
to
temporarily
suspend
and
later
resume
an
executing
progiam
in
order
to
permit
execution
of
one
or
more
programs.
27
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.
1
HARDWARE
ERROR
CONTROL
1
(a) The
system
must
provide
for
error
correction.
2
(b)
The system
must
provide
error
notification.
3
(c)
The
system
must
provide
for
recovery
from
hardware
4
errors.
(d-i)
The
system
must
detect
the
following
hardware
errors-
5
(d)
CPU
errors,
(e)
I/0
device
errors,
(1)
I/0
channel
or
I/0
processor errors,
(g)
storage
parity
errors,
(h)
co-processor
errors,
6
(i)
power
failure.
2.
1
HARDWARE
ERROR
CONTROL
Reference:
1.
It
is
usually
necessary
to
specify
this
criterion
when
proposing
an
extensive
error
recovery
scheme
for
a
particularly
complex
system.
2.
Generally,
error
correction
is
performed
by
retrying
a
failing
operation
and,
if
this
fails,
relyng
upon
analternate
method
of
accomplishing
the
cperation.
3.
U5ally,
i"
error
correctior
can
be
satisfactorily
performed:
notification
of
the
error
is
not
requie-d.
However,
if
the
error
can
not
be
corrected,
some
form
of
crror
notification
should
be
directed
to
the
operator
ard
to
any
affected
inter-
active
user.
4.
System
recovery
from
hardware
errors
can
be
associated
with
systems
that
support
reconfiguration
either
through
standby
redundancy,
replaceable
modules
and
devices,
or
a
degraded
(fail
soft)
mode
of
opero;ion.
These
functions
are
most
frequently
found
in
medium-to-large
scale
systems
supporting
a
real
-tme
environment
where
full
time
operation
is
required.
5.
Indications
of
CPU
errors,
I/0
device
errcr,
I/0
channel
errors,
parity
errors,
and
power
failures
are
generated
by
almost
every
hardware
system.
6.
The
recognition
of
co-processor
errors
is
only
significant
in
a
multiprocessor
configuration.
Generally,
one
of
the
no"-failing
processors
will
initiate
diagnostics
to
determine
the
cause
of
the
failure,
the
exten
t
of
the
do,.ge,
and
the
recovery
procedures
that
can
be
inv,'od.
Error
recovery
for
u
mnulti-
processor
configuration
is
more
complicated
(by
an
order
of
cnagnitude) than
for
uni-processing
sys'ems.
29
REQUIREMENTS
OPERATING
SYSTEM
wE12:z=
_____________REQUIREMENTS
CHECKLIST
Reference
IInitial
Exlended
2.2
PROGRAM
ERROR
CONTROLr
(a)
The
system must
provide for
program
error
correction.I
(b)
The
system
must
provide
program
error
not
ificai
-on.
2
(c)
The
systein
must
provide
control
led abnormal
program
3
terminations,
(d-j)
The
system
must
detect
the
foi~owing
types
of
error:
4
(d)
n-rithmetic
errors,
(e-g)
Instruction
errors:
5
(e)
invalid
insfruction,
'f)
unsupported
instruction,
(g)
privileged
instruction,
(h!
invalid
address
errors,
6
(i)
storage
protecton
errors,
6
()
invalid
data
errors.7
2.2
PROGRAM
ERROR
CONTROL
Reference:
1.
Almost
all
,ystems
recognize
program errors
occuring
in
user
programs
and
assume
control
to
prevent
the
system
from
being adversely
affected.
The
user
is
frequently
allowed
to
supply
his
own
error
handling
routines
for
certain
types
of
errors,
such
as
arithmetic
and
data
errors.
2.
Program
error
notification
should
be
considered for
a
time-sharing
system
since
the
ineractive
user
can
frequently
determine the
corrective
action
that
should
be
taken.
In
batch
processing
the
error
is
normally
logged
and
on-line
nctifi-
cation
is
not
normally
performed.
In
the
real-time
environment
when an
error
occurs
in
an
operational
program,
it
is
usually
desirable
for
notification
to
be
made
directly
to the
console
operator.
3.
This
function
is
highly
desirable in
batch
and
time-sharino
systems.
In a
real-
time
environment,
a
form
of
error
recovery,
rather
than
abnormal
termination,
should
be
considered.
4.
These
criteria
are
dependent
upon
the
hardware
configuration
and
can
only
be
specified
in
detail
when
the hardware
configuration
is
known.
5.
There
are
several
different
types
of
instruction
errors
that
a
system
should
recognize
and
distinguish.
An
invalid
instruction
is
one
that
is
not
a
part
of
the
hardware's
instruction
repertoire.
The
normal
error
procedure
should
be
to
teiminate
the
offending
program.
An unsupported
instruction
error
occurs
when
a
computer
has
optional
instruction
sets.
Normally
a
programmed
procedure
can
be
used
to
simulate
the
optional
instruction.
Privileged
instructions
are
used
by
most
third
generation
systems
to
reserve
a
part
of
the
instruction
set
for
the
sole
use
of
the
supervisory
programs.
By
controlling
the
use
of
these
instructions,
aoplication
programs
are
much
less
likely
to
inadvertantly
damage
the
software
system.
The
recognition
or
detection
of
an
attempted
use
of
one
of
these
instructions
by
an
application
program
should
cause
operator
notification
and
possibly
job
termination.
6.
Invalid
addressing
errors
are
detected
by
most
systems
when
either
the address
does
not
physically
exist
within
hardware
storage
or
if
it
lies out
of
an
appli-
cation
program's assigned
working
area.
Unauthorized
attempts
to
access
OS
resident
areas
or
other
urer
areas
should
be
detected
and
the
offending
program
should
be
terminated.
In
a
shared
computer
system
(batch
or
time-sharing),
repeated occurences
should
be
brought
to
the
attention
of
the
operator.
Time-
sharing
systems
that
process
classified
or
private
information
should
always
storage
protect
this
information
and
notify
the
operator
of
any
violations.
7.
It
is
usually
impossible
to
determine
invalid
data
content
unless
the
user
has
specified
limit
values
within
which
the
data
should
occur.
However,
hardware
detection
can
be
used
for
detecting
invalid
data
parity
and
adherence
to
device
data
formatting
requirements.
31
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extendea
2.3
INTERFACE
ERROR
CONTROL
(a)
The
system
must
edit
operator
key-ins.
1
(b)
The
system
must
edit
input
stream
control
commands.
2
(c)
The
system
must
edit
remote
terminal
communications.
3
(d)
The
system
must
edit
program
to
system
linkages.
4
32
2.3
INTERFACE
ERROR
CONTROL
Reference:
1.
All
processing
system
environments
provide
a
form
of
operator
communication.
Most
systems
thoroughly
edit
and
validate
each
operator
input
command
prior
to
attempting to
execute
it
since
the
failure
to
do
so
could result
in
a
system
failure.
Consequently,
serious
consideration
should
be
given
to
this
criterion.
2.
This
criterion
should
be
specified
for
a
batch
processing
or
time-sharing
envi-on-
ment.
3.
This
criterion
should
be
specified
for
time-sharing
and remote
batch
processing
environments.
4.
This
criterion
is
highly
recommended
for
time-sharing
and
batch
processing
systems.
It's
usefulness
in
a
real-time
environment
is
somewhat
questionable
since
real-time
programs
should
be
thoroughly
validated prior
to
operational
processing.
33
3.1 TIMING
SERVICE
Reference:
I.
These
features
are
highly
desirable in
a
real-time
processing
system
and
are
quite
useful
in
time-sharing
and
batch
processing
environments.
Implementation,
how-
ever
is
dependent
upon
the
availability
of
a
timing device.
2.
Real-time
clock
services
are
generally
required
for
any
environment
in
which
the
time
of
day
will
affect
the
processing
workload.
For
example,
in
batch
processing
a
time
of
day
is
frequently
used
as
a
deadline
by
which
some
pro-
cessing
jobs
must
be
completed.
In
real-time
systems,
it
may
be
used
either
for
job
scheduling
or
for
distinguishing
event
occurences
(e.g.,
message
time-
stamping).
Time-sharing
systems
have
no
particular
requirement
for
a
real-
time
clock.
3.
Interval
timers are
generally
required
in
a
real-time
environment
in
which
execution
scheduling
is
based
upon
a
periodic
interval
(e.g.,
polling
of
communication
lines).
Interval timing
services
are also
used
by
most
time-
sharing
environments
to
control
the
execution
time
allotted
to
each
user.
Interval
timing
service
can
also
be
incorporated
within
all
systems
as
a
debugging
aid.
One
method
of
use
is
for
an
application
program
to
set
a
time
limit
on
the performance
of a
loop.
If
the time
expires
prior
to
loop
completion
or
exit,
then
this
indicates
that
something
is
wrong
within
the
loop.
Also,
this
function
is
sometimes
used
by
systems
to
detect
I/O
devices
that
fail
to
respond
within
a
certain
designated
time period.
35
REQUIREMENTS
OPERATING
SYSTEM
-24
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.2
TESTING/DEBUGGING
SERVICE
(a)
The
system
must
provide
storage
dumps.
I
(b)
The system
must
provide
tracing
facilities.
2
(c)
The
system
must
provide
a
special
test/debuj
3
operating
mode.
36
3.2
TESTING/DEBUGGING
SERVICE
Reference:
1.
This
criterion
should
be
specified
for
all
processing
systems.
2.
Tracing
facilities
are
usually
most
extensive
in
a
time-sharing
system
although
they
are
also
quite
useful
in
testing
batch
and
real-time
programs.
Specifica-
tion
of
the
criteric
,
should
be
dependent
upon
the
anticipated
level
of
pro-
gram
testing
that
will
be
performed.
3.
This
criterion
is
highly
desirable
in
both
a
batch
and
real-time
processing
environment.
In
real-time
processing,
it
may
permit
some
program
testing
while
the
system
is
actually
"on-line,"
or
it
may
allow
the
simulation
of
a
real-time
environment
when
the
system
is
"off-line."
It
is
also
extremely
useful
in
a
batch
processing
system
where
a
high
degree
of
program
testing
occurs.
In
this
area,
it
frequently
takes
the
form
of
a
set
of
pre-spocified
actions
that
can
be
invoked
when
a
program
error
occurs.
Theseoctions
override
the
system's
standard abnormal
termination
processing
capabilities.
4
37
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLST
Reference
Initial
Extended
3.3
LOGGING
AND ACCOUNTING
(a-c)
The
system
must
maintain:
(a)
job
charge
information,
1
(b)
error
statistics,
2
(c)
system
utilization
statistics.
3
38
3.3
LOGGING
AND
ACCOUNTING
References:
1.
Batch
processing
and
time-sharing
operating
systems
normally
require
detailed
accounting information
on
job
execution
time,
device
utilization,
core
utili-
zotion,
etc.
Consequently,
this
criterion
should
be
specified
-or
these
two
environments.
2.
It
is
usually
highly
desirable
to
accumulate
error
statistics
in
order to
iden-
tify
hardware
devices
that
have
a
greater
than
normal
frequency
of
intermittant
errors.
As
a
result
this
criterion
should be
considered
for
all
processing
systems.
3.
Though
this
criterion
is
rarely specified,
it
may
be
desirable
to
maintain
system
utilization
statistics
for
relatively
large
and
complex
systems. These
statistics
in
turn,
can
be
examined
to
enable
the
system
manager
to
tailor
and
tune
various
operating
system
functions
to
improve
overall
system
performance.
39
REQUIREMENTS
OPERATING
SY
." '
REQUIREMENTS
CHECKLIST
Refe',-.nce
Initial
Extended
3.4
PROGRAM
ACCESSIBLE
SYSTEM
I
DESCRIPTION
MAINTENANCE
(a)
The
system
must
maintain
current
system
status
infor-
2
mation.
(b)
The
system
must
maintain
currcnt
system
description
3
information.
(c)
The
system
must
provide
for
the
extraction
of
system
2
description
information
by
a
user
program.
40
3.4
PROGPAM
ACCESSIBLE
SYSTEM
DESCRIPTION
MAINTENANCE
References:
1.
Many
batch
processing
and
time-sharin
1
stems
maintain
a
certain
amount
of
descriptive
information
in
a
supervsor communication
region
that
may
be
interrogated
by
an
application
program. Three
types
of
information
are
likely
to
be
maintained:
system
defining
information,
current
system
status
information
and
individval
job
information.
2.
System
status
information
may
be
of
use
to
installation
monitoring
or
account-
ing routines
tha
-re
not
built
into
the
operating
supervisor.
Device
status
information
(availability)
is
also
extremely
useful when
an
application
program
may
use
a
number
of
different
devices
to
accomplish
its
processing.
3.
This
information
is
useful when there
are
general
purpose
programs
or
compilers
in operation
that
have
the
cap&.siiity
of
alternate
modes
of
opera-
tion
based
upon
hardware
and
sofi'are
status.
For
example,
sort
programs
are
usually
designed
to
use
all
of
the
core
areu
available.
41
3.2.3
Third Level of
Detail
(Part
I -
Executive/Control
Functions)
This
subsection
covers
the
folowing
third
level
execjtive/control
func-
tions:
1.1.1
SCHEDULING
1.1.2
RESOURCE
ALLOCATION
1.1.3
PROGRAM
LOAD!NG
1.1.4
EVENT
MONITORING
1.
1.5
PROGRAM
TERMINATION
PROCESSING
1.2.1
I/O
SCHEDULING
1.2,2
DATA
TRANSFER
1.2.3
DEVICE
MANIPULATION
1.2.4
REMOTE
TERMINAL
SUPPORT
1.3.1
SYSTEM STARTUP
1.3.2
JOB
CONTROL
r"
WMUNICATION
1.3.3
INPUT/OUTPUT
-
,EAM
CONTROL
1.3.4
RESOURCE
STATUS
MODIFICATION
1.3.5
SYSTEM
STATUS
I
NTRROGATION
1.4.1
CHECKPOINTING
1.4.2
RESTARTING
2. 1. 1
ERROR
CORRECTION (Hardware
errors)
2.1.2
ERROR
NOTIFICATION
(Hardware
errors)
2.
1.3
ERROR
RECOVERY
(Hardware
errors)
2.2.1
ERROR
CORRECTION
(Program
errors)
2.2.2
ERROR
NOTIFICATION
(Prgram
errors)
2.2.3
PROGRAM
TERMINATION
2.3.1
OPERATOR
KEY-IN
EDITING
2.3.2
CONTROL
COMMAND
EDITING
2.3.3
REMOTE
TERMINAL
COMMUNICATION
EDITING
2.3.4
PROGRAM
TO
SYSTEM
LINK
VERIFICATION
3.1.1
REAL-TIME
CLOCK
SERVICE
3.1.2
INTERVAL
TIMER SERVICE
3.2.1
STORAGE
DUMP
CONTROL
3.2.2
TRACING
CONTROL
3.2.3
SYSTEM
TEST
MODE
CONTROL
3.3.1
MAINTAINING
JOB
CHARGE
INFORMATION
3.3.2
MAINTAINING
ERROR
STATISTICS
3.3.3
MAINTAINING
SYSTEM
UTILIZATION
STATISTICS
3.4.1
CURRENT
SYSTEM
STATUS
INTERROGATION
3.4.2
SYSTEM
DEFINITION
INTERROGATION
43
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
RPerence
Initial
Extended
1.1.1
SCHEDULING
I
(a)
The
system
must
provide
an
algoriihmic
scheduling
2,7
capability.
(b)
The system
must
provide
a
time-initiated
scheduling
3
capability.
(c)
The
system must
provide
an
event-initiated
scheduling
4
capability.
(d)
The
system
must
provide
a program-initiated 5
scheduling
capability.
(e)
The
system must
provide
conditional
scheduling.
6
(f)
The
system
must
recognize
up
to
scheduling
7
priority
levels.
(g-k)
Batch
scheduling
must
be
permitted
from
the
following
sources:
(g)
local
input
s~ream,
(h)
remote
input
stream,
8
(i)
a,,
executing
interactive
job,
9,5
(j)
an
executing
real-time
job,
9,5
(k)
another
executing
batch
job.
9,5
(I)
The
system
must
provide
scheduling
for
programs
10
and/or
subprograms
which
will
be
consistent
with
the
desired
sequence
of
operations.
44
1.1.1
SCHEDULING
Reference:
1.
The
purpose
of
the
scheduling
function
is
to select
a
job
which
is
avail-
able
for
processing
and
prepare
it
for
execution.
The
function
may
be
extremely
complex,
as
in
an
extended multiprogramming
system
where
several
jobs
may
be
simultaneously
available
for
execution,
or
quite
simple,
as
in
serial
processing
systems
where
the
order
of
programs
in
the
input
stream
may
dictate
the
execution
sequence.
Since
most
systems
handle
more
than
one
type
of
processing
mode,
different
sch-
eduling
philosophies
are
used
for the
real-time,
time-sharing,
and
batch
processing
applications.
The
greatest
variation
in
the
implementation
of
the
scheduling
facility
exists
in
the
handiing
of
batch
processing.
The most
elementary
approach
is
to
schedule
each
job
for
execution
in
the
sequence
of
its
occurence
in
the
input
stream.
When
a
system
has
separate
input
streams
for
several
processing
areas,
as
in
serial
processing
or
basic
multiprogramming
systems,
each
input
stream serves
as
a
scheduling
queue
which
is
external
to
the
system.
Further
sophistication
of
the
sequential
approach
is
achieved
by
pre-reading
the
entire
input
stream
and
storing
it
on
a
secondary
storage
device
such
as
a
disk.
By so
doing,
jobs
may
be
executed in
an
order
other
than
input
stream
sequence.
In
this
type
of
system,
scheduling
parameters
are
intro-
duced
to
control
the
execution
sequence.
Normally,
these
parameters
are
priorities,
where
a
higher
priority
job
is
executed
before
a
lower
priority
job.
Alternatively,
the
parameters
may
be
clock
times,
where
a
job
is
initiated
at
a
selected
time
or
is
initiated
to
be
completed
by
a
certc*n
time.
Clock-time
scheduling
may
also
be
used
to
initiate
selected
real-
time
jobs.
The
batch
scheduling philosophy
of
an
extended multiprogramming
system
allows
jobs
submitted
from
more
than
one
input
stream
to
cam
F
te
for
exe-
cution
assignment.
Under
this
philosophy
a
scheduling
queue on
an
inter-
mediate
storage
device
is
mandatory,
and
jobs
are
placed
on
this
queue
whenever
they
are
entered
from
either
a
local
or
remote
input
terminal.
In
this
type
of
system,
an
input
stream
symbiont
is
used
to
read
the
input
stream
a.od
store
it
on
the
scheduling
queue.
The
symbiont
is
itself
scheduled
by
an
external event
such
as
an
operator
or
user command
to
initiate
input
stream
processing.
2.
Algorithmic
scheduling
provides
a
priority
scheduling
concept
where
a
number
of factors
may
be
allowed
to
influence
the
selection of
the
next
program
chosen
for
execution.
This
criterion
should
probably
be
speci-
fied
for
all
extended multiprogramming
systems.
45
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.1
SCHEDULING (repeated)
1
(a)
The
system
must
provide
an
algorithmic
scheduling
2,7
(b)
The
system
must
provide
a
flmi.-initiated
scheduling
3
capability,
(c)
The
system must
provide
an
event-initiated
scheduling
4
capability.
(d)
The
system
must
provide
a
program-initiated
5
scheduling
capability.
(e)
The
system
must
provide
conditional
scheduling.
6
(f)
The system
must
recognize
up
to
scheduling
7
priority
levels.
(g-k)
Batch
scheduling
must
be
permitted
from
the
following
sources:
(g)
local
input
stream,
(h)
remote
input
stream,
8
(i)
an
executing
interactive
job,
9,5
()
an
executing
real-time
job,
9,5
(k)
another
executing
batch
job. 9,5
(I)
Tk
system
must
provide
scheduling
for
programs
10
and/or
subprograms
which
will
be
consistent
with
the
desired
sequence
of
operations.
46
---
1.1.1
SCHEDULING
(cont'd.)
Reference:
3.
Time
initiated
scheduling
is
frequently
found
in
batch
and
real-time
processing
systems.
It
is
used
when
job
initiation
must
occur
at
a
certc'n
time
or
must
be
completed
by
a
certain
time.
Clock
time
scheduling
may
also
be
used
to
initiate
selected
real-time
jobs.
Consequently,
this
criterion
should
be
examined
for
a
batch
and
real-time
processing
system. The
criterion
is
rarely
specified
for
a
time-sharing
system.
4.
Initiating
programs
in
response
to
events
that
produce
an
external
signal
to
the
compute.
is
the
most
straightforward
of
the
scheduling
methods.
This
criterion
should
normally
be
specified
for both
real-time
and
time-
sharing
sysiems.
5.
Program-initiated
scheduling
permits
an
executing
program
task
to
request
that
another
program
task
be
scheduled
for
either
asynchronous
or
subsequent
execution.
This
capability
frequently
occurs
in
a
time-sharing
environment
where
background
batch
processing
is
in;tiated
by
a
foreground
time-sharing
program.
It
is
also
found
in large
multiprogrammed
batch
processing
systems.
6.
Conditional
scheduling
permits
the
user
to
specify
scheduling
parameters
which
must be
satisfied
before
the
program
can
be
initiated.
These
para-
meters
tend
to
be
the presence
or
absence
of
certain
errors
in
a
previous
job
step
as
well
as
the
status
of
internally
and
externally
set
switches.
7. Mans,
times
the
priority
levels
required
to
control
scheduling
can
be
determined
from
the
environment.
A
batch
environment
will
usually
only
have
a
few
levels
of
priority
to
expedite
urgent
and/or
short jobs.
Time-
sharing environments also
generally
need
few
priority
levels.
A
rea-time
environment
usually
requires
several
levels
of
priority.
These
levels
of
priority
are
assigned
to
individual
programs
according
to
their
execution
requirements
relative
to
other
programs.
If
the
system
is
to
operate
in
a
mixed
environment
(e.g.,
batch
and
real-time,
etc.)
then
a
combination
of
priority
levels
for
each
environ-
ment
will
probably
be
required.
8.
This
criterion
is
dependent
upon
the hardware
configuration
and
can
only
be
specified
when
the
hardware
configuration
is
known.
9.
A
detailed
examination
of
the
intended
or
existing
application
programs
must
be
performed
to
determine
the
desirability
of
this
criterion.
10.
This
criterion
should
be
specified
when
an
operational
scenario
is
included
within
the
specification.
47
1.1.2
RESOURCE
ALLOCATION
Reference:
1.
The
resource
allocation
function
is
responsible
for
assigning
resources
to
each
executing
job
in
such
a
way
that
conflicting
resource
assignments
are
avoided.
In
general
the
system
resources
are
CPU
time,
core
storage,
I/0
devices,
information
files,
and
commonly
used
routines.
The
allo-
cation
of
CPU
time
to
a
program
is
called
dispatching
and
is
covered
separately
under
Section
1 .1
.4.
2.
This
feature
is
not
necessary
in
a
serial
processing
system
since
all
system
resources
are
normally
made
available
to
the
executing
program.
However
the
criteria
should
be
considered
for
both
multiprogramming
and
time-
sharing
environments.
3.
Routines
that
can
be
used
by
multiple
programs
may
be
designed
to
be
loaded
and
executed
when
needed,
or
to
be
permanently
core
resident.
They
are
rarely
incorporated
as
a
part
of
+he
executing
program
during
the
binding
process
except
in
serial
processing
or
small
multiprogramming
systems.
4.
This
criterion
is
usually
relevant
for
a
basic
multiprogramming environment
where the
user
needs
little
control
over
resource
assignment. It
is
primarily
found
in
dedicated
environments,
such
as
real-time
foreground/
batch background
applications
in
which
the
resources
are
permanently
assigned
to
a
particular
environment.
5.
This
criterion
is
primarily
relevant
for
those
environments
supporting
input
job
streams
(local
and
remote
batch
processing)
and
is
also
frequently
found
in
time-sharing
systems.
The
request
for
system
resources
occurring
within
the
job
stream
generally
means
that
the
resources
are
assigned
to
the
requesting
element
(job,
job
step,
task)
for
the
entire
duration
of
the
element's
processing.
With
the
exception of
data
files,
these
resources
are
generally
not
available
for
the
use
of
other
programs
until
this
element
termin-
ates.
Many
systems
will
also
not permit
a
program
task
to
be
scheduled
until
all
static
resource
requests
have
been
satisfied.
The
criterion
should probably
not
be
specified
for
real-time
applications.
6. This
feature
occurs
in
many
real-time
environments
as
well
as
in
large
multiprogramming
and
time-sharing
systems. The
feature
permits
a
system
element
to
be
assigned
to
an
executing
task
only
for
the
length
it
is
actually
needed,
rather
than
;or
the
duration
of
the
entire
task.
A
program
will
execute
until
it
reaches
a
point at which
a
resource
is
required,
reques+
the
resource,
and
then
suspend
itself until
the
resource
becomes
available.
In
a
large
system
this
reduces the
nti'ber
of
I/O
devices required
and
allows
more
effective
utilization
of
core storage.
It
also
invokes
heavy
overhead
as
well
a-
introducing
the
possibility
that
a
job
in
execution
will
be
delayed
because
a
resource
is
not
available.
It
is
highly
recommended
for
those
systems
wher,-
several
programs may
require
access
to
a
single
on-line
data
base.
49
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
2HECKLIST
Reference
Initial
Extended
1.1.3
PROGRAM
LOADING
1
(a)
The
system
must
provide
for
program
or
program
segment
loading
into
main
memory.
(b-e)
The
sy-
em
must
permit
program
loading
from
the
2
Following
sources:
(b)
syst--n
library,
Wc
user Ilibrary,
(d)
input
s1ream,
(e)
temporary
library
(e.g.,
compiler
3
output
file).
(f)
The system
must
provide
facilities
for absolute
loading.
(g)
The
system
must
provide
facilities
for
relocatable
loading.
50
1.1.3
PROGRAM
LOADING
Reference:
1.
The
program
loading
function
is
responsible
for loading
a
program
task
into
-ore
storage
in
such
a
way that
it
can
be
executed
under
the
control
of
the
system
supervisor.
There
are
two basic
forms
of
program
loading
and
either
one
or
both
is
found
in
every operating
system.
The
first,
absolute
loading,
can
only
luau
a
program
that
is
in
complete
executable
(core
image)
form.
This
technique
requires
very
little
system
overhead
durirg
the
loading
process,
though
it
a,;o
usually
does
require
an
independent
supoort
program
element
to
convert
the
var-
ious programs
into
the
executable
core
mage
format.
The
second
form
of
loading,
relocutal
a
loading,
combines
most
of
the
functions
of
the
independent
support
program eiemc
it
and
the
absolute
loader
into
a
sing#
system
element. A
relocatable
loader
w I
assign
preliminary
storage
addresses
to
the
program,
perform
any
address
adjustments
that
may
be
required, combine
the program
with
any
required
support subroutines,
and
produce
a
loaded
execut-
able
program.
The
system
overhead
is
considerably
higher for
this
techniqut
,
however
the
human
requirements
for
compiling,
loading,
and
executing
a
program
are
greatly
simplified.
As
a
result, absolute
program
loading
is
most
generally
found
in
small
re,
-time
control
systems
(where overhead
must
be
minimized)
and
in
small
basic
mLIti-
programming and
serial
processing
systems
where
the
assigned program
execution
area
is
relatively
static
(such
as
a
fixed
background
partition).
Relocatable
ioad-
ers
occur
most
frequently
in
extended
multiprogramning
systems
as
well
as
in
most
time-sharing
environments.
Both
loading
techniques
frequently
co-exist
in
large
multi-purpose
systems.
2.
Programs
that
may
be
loaded
into
core
(using
either
technique)
must
reside
in
a
defined
location.
Every
system
provides
a
system
library
which
is
composed
of
the
operating
system
itself,
the
various
pnogram
language
compilers,
and many
of
the
most
frequently
used
application
programs.
The
system
'ibrary
is
almost
always
on-lin.'.
Separate
user
libraries
are
generally
designed
to
be
removed
when
not
in
use.
User
libraries
G,e
also
frequently
used
in
large
multi-user
environments
such
as
time-sharing
and
remote
batch
processing
systems.
The
loading
of
programs
through
the
input
stream
is
usually
a
supplement
to
lib-
,aries.
This
technique
dates
back
to
earlier
computer
systems
where
program
decks
were
maintained
apart
from the
computer
and
loaded
only
when
needed.
Most
systems
still
retain
the
capability,
but
apart
from remote
batch
processing
appli-
.cations
it
finds
little
use
except
in
program
testing.
3.
The
purpose
of
this
feature
is
to
protect
the
system
and
user
libraries
against
the
addition
of
unproven
programs.
Most
systems
provide
this
protection
in
some
form.
Therefore, the
nature
of
the
protection,
and
the
specification
of
this
criterion,
would
only
be
important
in
rare
circumstances.
51
REQUIREMENTS
OPERATING
SYSTEM
m
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.
1.4
EVENT
MONITORING
I
(a)
The
system
must
provide
fixed
time-slice
dispatching.
2
(b
The
system
must
provide
variable
time-slice
dispatching4
2
(c)
The
system
must
provide
contention
(priority)
2
lispatch
ing.
(d)
The
system
must
provide
event
synchronization.
3
(e)
'he
s
tem
must
recognize
up
to
distinct
external
4
interru
s.
(f)
The system
must
recognize
up
to
interrupt
levels.
4
(g)
The
system
must
provide
limit
monitoring.
5
52
1.1.4
EVENT
MONITORING
Reference:
1.
Event
monitoring
refers
to
the
control
the
operating
system
maintains
over
execu-
ting
programs.
The
function
includes: dispatching control,
interrupt
processing
control,
event
synchronization,
and program
limit
monitoring.
2.
Dispatching
is
the
supervisor
controlled
allocation of
processor
tire
to
a
speciic
task.
Tasks
that
are
eligible
for
dispatching
have
already
been
placed
in
an
execu-
tion
state
by
the
sckeduler
and
are
not
waiting
for
I/O
activity,
operator
responses,
etc. Dispatching
is
important
only
in multiprogramming
and
time-sharing.
Two
techniques
are
frequently
used:
time-slicing
and
contention.
Time-slicing
allows
one
program
to
execute
for
a
specified
length
of
time,
interrupts
it
,
and
selects another
program
to
execute
for
another
specified
time
period.
Consequen-
tly,
each
program
in
execution
is
guaranteed
a
certain
slice
of
time
for
execution.
The
contention
technique,
on
the
other
hand,
allows
the
highest
priority
program
to
execute
until
it
no
longer
requires
the
CPU
and
thien
assigns
the
CPU
to
the
next
highest
priority
program. A
low
priority
program
is
not
guaranteed any
execution
time
beyond
that
not
used by
higher
priority
programs.
Time-slicing
is
normally
used
for
time-sharing
whereas
contention
processing
is
almost
mandatory for
most
real-time
applic,.
)ns.
Batch
processing
systems
may
use
either
technique,
with
little
preference
shown
to
one
or the
other.
While
frequently
used
for
evaluation,
disptching
criteria
are
rarely specified.
However,
if
an
operating
system
is
to
be
specifically
designed
for
a
give:
;Ppli-
cation,
it
may be
desircble
to
consider
the
dispatching
technique
during
initial
criteria
specification.
3.
Event
synchronization
is
the
process
of
delaying
task
execution
until
some
specified
event
occurs
or
the
process
of
triggering a
task
upon
the
occurrence
of
a
specified
event.
The
most
common
types
of
events
which
may
delay
or
initiate
task
e-,ecu-
tion
are
I/O
completions,
selected
time
intervals,
subtosk
completions,
c' a
unsolicited
key-ins.
4.
This
criterion
is
highly
dependent
upon
the
hardware
configuration
and con
only
be
specified
in
detail
when the
hardware
configuration is
known.
Interrupts
that
ore
provided
in
response
to
certain
error
conditions
within
the
CPU
(e.g.,
illegal
instruction,
arithmetic
overflow,
pari'
error,
power
failure,
etc.)
are
considered
internal
interrupts
and
should not
enter
these
calculations.
5.
This
criterion
is
frequently
specified
for
time-sha,"q
and
batch
processing
in
order
to
prevent
misuse
of
system
resources.
The
featui
generall),
desirable
in
a
testing
environment
to
assure
that
a
program
error
does
not
result
in voluminous
output
records,
excessive
CPU
time,
etc.
Generally,
limits are
established
for.
CPU1
time,
output
lines/cords/or
records,
and
main
and
secondary
storage
space
allocation.
53
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.5
PROGRAM
TERMINATION
PROCESSING
I
(a)
The
system
must
deallocate
all
resources
at
program
2
termination.
(b-e)
The
system
must
provide
summaries
of
the
following 3
information:
(b)
error
statistics,
(c)
CPU
time
utilization,
(d)
device
utilization,
(e)
file
access
statistics.
(f-i)
The
system must
provide
the
fo!lowing
options
at
abnormal
termination:
(f)
durw.
core,
(g)
dump
files,
4
(h)
execute
a
specified
program,
4
(i)
initiate
recovery
procedures.
5
(j)
The
system
must
notify
'he
operator
of
abnormal
6
terminations.
(k)
The
system
must
notify
remote
terminal
users
of
7
abnormal
termintions.
54
1.1L5
PROGRAM
TERMINATION
PROCESSING
Reference:
1.
A
program
terminates
normally
when
it
has
completed
all
of
its
processing
and returns
control
to
the
s,.,ervisor.
A
program
may
also
be
abnormally
terminated
by
the
operating
system
under
a
number
of
different
circum-
stances.
This
is
frequently
caused
by
a
programmed
rejest
for
abnormal
termination
of
the
job,
a
system
determination
to
abort
due
to
lack
of
corrective
actions
for
certain
error
conditions,
or
a
console
command
to
terminate
issued
Oy
the computer
operator.
The
standard
abnormal
term-
ination
procedure
is
to
discontinue
execution
of
the
executing
task,
or
possibly
of
the
entire
job,
depending
upon
the
criticality
of
the
task
with
respect
to
the
job.
2.
This
criterion
should
be
specified
for
all
processing
systems
that
use
the
static
resource
allocation
technique.
3.
Summary
status
information
is
highly
desirable
for
most
batch
and
time-sharing
applications.
CPU
time
utilization,
device
utilizaton,
and
file
access
statistics
can
also
be
helpful
to
a
facility
in
"tuning"
the
system
to
best
meet
operational
requirements.
Error
statistics
are
an
aid
to
hardware
maintenance
personnel.
4.
This
feature
frequently
occurs
in
_
batch
processing
or
time-sharing
system
as
a
means
of
providing
program
testing
and
debug support.
5.
The
initiation
of
recovery
procedures
is
highly
desirable
and
usually
mandatory
for
most
real-time
processing
systems.
6.
This
feature
rarely
occurs
in time-sharing
or
large
batch
processing
systems.
When
it
does,
it
is
normally restricted
to
operational
programs
rathor
than
programs
being
tested.
It
should,
however,
be
specified
for
a
real-time
processing
system.
7.
This
criterion
should
be
specified
for time-sharing
proces.
ng,
remote
batch
processing
and
interactive
real-time
processing.
55
REQUIREMENTS
OPERATING
SYSTEM
A .
kQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.2.1
I/O
SCHEDULING
(a)
The
system
must
provide
immediate
scheduling
of
I
I/O
requests.
(b-e)
The
system
must
permit
specific
device
assignment
from
the
following
system
external
sources:
(b)
input
stream
(control
statement),
(c)
the
operator,
2
(d)
a
program,
(e)
interactive
user.
(F)
Specific
device
assignment
must
be
the
responsibility
3
of
the
system.
(g) The
system
must
provide
queuing
of
input
requests.
(h)
The
system
must
permit
specification
of device
4
priority.
(i)
Ihe
system
must
permit the
specification
of
I/O
5
request
prioriies.
(
i
The
system
must
attempt
to
route
I/O
to
a
specific
6
device
via
u,.
,
route
,
rni
.
ri
t
roule
is
busy
or
disabled.
(k)
The
system
must
provide
facilities
for
alternate
6
device
selection.
(I-m)
The
system
must
provide
facilitics
for
initiating
Glternate
device
selection:
(I)
automatically,
7
(M)
by
the
cperator.
56
1.2.1
I/O
SCHEDULING
Reference:
1.
This
criterion
should
be
specified
for
all
serial
processing
systems.
This
method
is
also
used
quite
frequently
in
basic
multnorogramming
systems
where
dedicacd
real-time
devices
ire
known
to
be
available.
Any
system
supporting
real-time
processing where
there
are
critical
I/O
operations
should
also
conside,
this
criterion.
2.
Operator
assignment
of
devices
is
highly
desirable in
most
processing
systems
to permit
an
override
of
other
assignment
techniques
due
to
unusual
workloads.
3. Specific
device
assignment
by
the
system
is
a
dynamic
method
of
selection
which
increases
system
throughput.
This
can
be
associated
with
multi-
program
processing
in which
the
system
knows
the
status
of
all
devices
and
can
therefore
make
the
best
decision at
a
given
moment
as
to
which
device
should
be
made
available
to
a
particular
program.
4.
In
certain
real-time
processing
systems
it
is
necessary
to
specify
device
priority
due
to
the
critically
of
device
operation,
e.g.
telemetry
data,
teleprocessing
data,
etc.
Within
some
time-sharing
systems,
a
require-
ment
may
also
exist
For
some
terminals
to
have
priority
over
other
terminals
during
system
operation.
5.
This
criterion
should
be
specified
for
most
real-time
processing
systems.
6.
This
criterion
is
highly
desirable
for
a
real-time
processing
system; how-
ever,
it
is
highly
dependent
upon
the
hardware
configuration
and
can
only
be
specified
in
detail
when
the hardware
configuration
is
known.
7.
Autornaic
initiation
is
most
useful
within
a
time-critical
environment
or
when
fhere
is
a
large
number
of
alternate
devices
from
which
to
make
the
selection.
57
REQUIREMENTS
.
'ERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Rrfrence
initial
Extended
1.2.2
DATA
TRANSFER
I
(a)
The
system
must
provide
buffer
control.
2
(b)
The
system
must
permit data
code
translation
during
3
data transfer.
(c-f)
The
system
must
process
the
following
4
record
types:
(c)
fixed
length
records,
(d)
variable
length
records,
(e)
undefined length
records,
(f)
character string
records.
(g)
The
system
must
accomplish
all
necessary
code
translation
without
the
requirement
for
conversion
or
translation
routines
within
applications
programs.
....
_______
_ __
_ _ _
1.2.2
DATA TRANSFER
Reference:
1.
Data
transfer
controls
the
movement
otf
input
or
output
data
between
main
storage
and seconwary
storage,
or
between
main
storage and
input/
output
devices.
Prior
to
initiating
tW3
data transfer
operalion,
an
area
of
main
storage
(called
a
buffer)
must
be
set
aside.
The
buffer
wiil
either
contain
the
output
data
to
be
transmitted
or
will
receive
the
input
data
as
it
is
being
transmitted.
Techniques
for
allocating
buffer
areas
vary
greatly
among
the
various
operating
systems.
2.
This
criterion
should
be
specified
for
all
processing
systems
cxcept
certcin
small
real-time
processing
systems
in
which
the
application
program
must
er:",
all
data
transfer
operations.
3.
This
requirement
frequently
occurs
in
teleprocessing
where
the
input
or
output
line
data
coding st,uctures
differ
irom
the
internal
computer
data
codes.
The
requirement
may
also
occur
in
real-time
systems
which
are
required
to
interface
with
analog
devices.
If
the
system
will
interface
with
any
non-standard
peripherals this
criterion
should
also
be
cons,4ered.
4.
An
examination
of
the
intended
applications
should
determine
if
the
OS
is
to
support:
Fixed
length
records:
Records
having
the
some
length
as
all
other
records
in
the
some
file.
Variable
length
records:
Records
having
a
length independent of
the
length
of
other
records
in
the
same
file.
Undefined
length
records:
Records
having
a
length
unspecified
or
unknown
to
the
system.
Character string
records:
An
unformatted
record
composed
of
a
series
of
contiguous
characters.
Character
string
processing
usually
applies
to
teleprocessing
message3.
59
REQUIRE
MENTS
()PERATINr-
SVSIEM
Inm=-
REQUIREMENTS CHECKLIST
Reference
Initial
Extended
-
1.2.3
DEVICE
MANIPULATION1
(a-d)
The
system
must
provide
facilities
for:
(a)
rope
positioning,
(b)
disk
positioning,
(c)
card
stacking,
(d)%
page
ejecting.
1.2.
DEVICE
MANIPULATION
Reference:
1.
Device
manipulation
is
a
control
function
which
allows
a
physical
I/O
device
to
be
positioned
without
actually
requiring
data
transfer.
Device
manipulation
facilities
l
.
,it
volume
positioning
(rewinding,
forward
spacing,
back-spacing,
disk
arn
positioning,
etc.),
printer
spacing
and
forms
control,
and
card
stacker
selection.
These
features
should
be
available
on
every operating
system
for
the
devices
associatea
with
the
system.
61
RLQUIR EMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.2.4
REMOTE
TERMINAL
SUPPORT
1
(a)
The
system
must
permit
interactive
communications.
(b)
The
system
must
permit
terminal
to
terminal
communi-
2
cations.
(c)
The
system
must
permit
terminal
to
operator
communli-
3
cations.
(d)
The
system
must
permit operator
control
over
remote
4
terminal
activity.
(e)
he
system
must
allow
slaved
remote
terminals.
5
(f)
The
system must
provide
a
remote
batch
communication
6
mode.
62
1.2.4
REMOTE
TERMINAL
SUPPORT
Rtference:
1.
Control
,%,er
remote
terminal
operations
is
found
in
all
time-sharing
systems,
interactive real-time
systems
and
batch
processing
sysfems
that
provide
emote
job
entry.
While
it
may
be
possible
io
attach
a
remote
terminal
to
practically
any
computer
system,
many
operating
systems
are
not
designed
to
specificully
support
remote
terminals
and
special
t.rminal
support
routines
must
be
designed
to augment
the
normal
supervisor
facilities.
2.
This
feature
is
found
in
some
time-sharing
processi ig
systems
as
well
as
in
a
few
real-time
environments.
It
is a
very
desirable
feature
for
applications
where
,emote
users
must
interact
with
each
other.
3.
This
feature
should
be
specified for
all
processing
systems
that
support
remote
terminals.
4.
This
feature
is
sometimes
used
to
inhibit
or
lock-out
certain
terminals
durina
processing
of
classified
or
private
information.
This
feature
may
also
be
used
to
restrict
the
usage
of
certain
termiials
during
critical
(%":
soft)
operations.
5.
W*thin
ertain
system
applications
there exists
t'
need
to
distribute
or
acquire
.ata
from
terminals
other
than the
prime
terminal.
If
'his
i4
"he
case,
then
for
proper
operation
certain
terminals
must
be
slaved
to
the
prime
terminal
until
completion
of
f.xecution.
6.
This
criterion
should
be
specified
for
all
remote
batch
applications.
63
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.1
SYSTEM
STARTUP
(a)
Startup
of
the
entire
system
must
be
provided.
(b)
Startup
on
a
partition
by
partition
basis
must
be
2
provided.
(c)
The system
must
allow
the
use
of
cctaloged
startup
3
procedures.
(d)
The
system
must
provide
a
capability
during
startup
4
for
respecification
of
parameters
specified
at
system
generation
ime.
(e)
The system must
permit
specification
of
device
5
availability
during
startup.
(f)
The
system
must
permit
controlled
system
reconfigur-
5
ation
during
startup.
(g)
The
system must
provide
full
system
restart
procedures.
6
(h)
The
system
must
schedule
user
initiation
programs.
7
(i)
The
system
must
request
time/date
specification.
(j)
The
system
must
permit
manual
initiation
of
symbionts.
8
(k)
The
system
must
provide
automatic
initiation
of
8
symbionts.
64
1
.3,1
SYSTEM
STARTUP
Reference:
1.
System
startup
is
performed
by
the
computer
operator
to
initialize
the
operating
system
for
normal
processing.
In
batch
processing
environments
this
is
the
normal
beginning-of-the-day
procedure
once
computer
power
has
been
turned
on.
In
real-time
environments
operating
arou,'d
the
clock,
startup
is
only
performed
when
the
system
has
been
shut down
for
some
reason.
2.
Startup
on
a
purtition
by
partition
bcsis
allows
each
partition
to
be
started
independently
of
the
other
partitions,
When
the
system
is
divided
into
environment
based
partitions
(batch,
real
time,
time-sharing),
then
each
area
con
be
initiated
without
requiring
the
other
areas. This
feature
is
also
associated
with
basic
multiprogramming
where each
partition
or group
of partitions
is
supported
by
its
own
input
stream.
3.
This
criterion
should
be
specified
where
startup
requirements are
extensive
and
consistent.
4.
This
feature
i:
highly
desirable
in
most
1
rocLsslng
systems
since
it
provides
flexibility
in
tailoring
a
system
to
meet
daily
requirements.
5.
This
criterion
should
be
specified
for
configurable
processing
systems.
6. System
restarting
is
required
when
a
failure
that affects
the
total
system,
rather
than
a specific
job,
occurs.
Restarting
functions
are
oriented
to
restoring
as
much
as
possible
of
the
system
environment
that
was
valid
at
the
time
of
the
error.
In
critical
real-time
environments,
for
example,
system
checkpoints
are
frequently
taken
at
regular
intervals.
These
checkpoints
can
be
used
to
reload
a
previous
valid
version
of
the
operating
environment
when
no
other
immediate
method
of
repair
is
possible.
7.
This
technique
is
highly
desirable in
a real-time
processing
system
in
which
the syrtem
is
required
to
interface
with
uniqu"
devices
which
can
not
be
initializeJ
using
general
initializafion
techniques.
For
example,
user
initiation
programs may
be
required
to
selectively
in'tiaie
teleprocessing operations.
8.
Automrti
-ymbiont
initiation
is
generally
.dvisable
for
output
symbionts
whereas
n.,,nual
initiation
is
more
desirable
for input
syrnbionts.
65
1
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.2
JOB
CONTROL
COMMUN!CATION 1
(a-d)
The
system
must
provide
control
of
user
jobs from
the
2
following
interactive
sources:
(a)
the
batch
job
submitter,
(b) the
operator,
(c)
interactive
users,
(d)
other
executing
jobs.
(i)
The
system
must
permit
up
to
_
separate
input
3
stream
devices.
(f)
The
system
must
provide
for
the
use
of
cataloged
4
procedures.
(g)
The
system
must
provide
procedures
for
modifying
4
cataloged
procedures.
(h)
The system
must
provide
for
conditional
execution
5
logic
within
the
input
stream.
(i)
The
system must
provide
the
operator
with
the
capability
to
redirect
or
abort
output
generated
by
a
job
initiated
at
a
remote
terminal.
(j) The system
must
provide
a
job
control
language
(JCL).
6
66
1.3.2
JOB
CONTROL
COMMUNICATION
Reference:
I.
Job
control
communication
refers
to
that
communication
between
the
operating
system
supervisor
and
either
the
user
or the
computer
operator
relating
to
the
initiation,
running,
or
termination
of
individual
jcbs
witHin
the
system.
In
batch
processing
systems,
user/system
communica-
tion is generally
non-interactive,
whereas
in
time-shcr-rg
systems
it
is
almost
always
interactive.
Operator/system communication
is
predomin-
antly
interactive.
2.
Job
submitter
control
occurs
primarily
in
serial
batch
processing
environments
where the
submitter
has
access
to
the
operator
console
area.
In
most
batch
environments
the
operator
has
the
capability
to
exercise
some
control
over
user
jobs,
e.g.
resource
assignment,
cancellation,
etc.
In
a
real-time
environment,
the
operator
should
have
the
capability
to
exercise
extensive
control
over
executing
jobs.
Most
time-sharing
and
remote
batch
processing
systems
assign
job control
functions
to
interactive
users.
3.
This
criterion
is
highly
dependent
upon
the
hardware
configuration
and
can
only
be
specified
in
detaiLwhen
the hardware
configuration
;s
kown.
In
a
basic
multiprogramming
system
this
parameter
is
directly
related
to
the
number
of
partitions.
4,
A
cataloged
procedure
is
a
set
of
job
control
statements
stored
on
a
library
and
which
may
be
invoked by being
named
on a
special
control
card.
This
is
an
excellent
feature
where
jobs
are
relatively
standard
or
where
the
control
language
is
complicated.
If cataloged
procedures
are
used,
then
the
flexibility
should
be
available
to
allow
modification of
the procedures.
This
would
be
useful
in
diverting
output
from
one
device
to
another
due
to
a
new
system
configuration.
5.
This
feature
is
frequently
found in
larger
batch
processing
systems.
It
allows
non-interactive
users
to
specify
conditions
for
performing
certain
job
steps.
This
feature
is
particularly
useful
in
program
testing
and
debugging.
6. This
criterion
should
be
specified
for
most
batch
processing
and
time-sharing
systems.
67
RE
QU
IREM
ENT
S
OPERATING
SYSTE
-
ENT
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.3
INPUT/OUTPUT
STREAM
CONTROL
I
(a)
The
system
must
provide
input
strecm
control
by
2
symbiont
processing.
(b)
The
system
must
provide output
stream
control
by
2
symbiont
processing.
(c)
The
system
must
provide
for
the
processing
of
up
to
3
___input
streams.
(d)
The
system
must
allow
up
to
____output
streams
to
3
be
maintained.
(e)
The
system
must
provide
automatic
editing
of
control
4
command
formats.
(f-j)
The
system
must
allow
the
following
output
stream
elements:
(f)
diagnostic
messages,
(g)
trace
control listings,
k;.%
data,
(i)
core
dumps,
()
file
dumps.
68
1.3.3
INPUT/OUTPUT
STREAM
CONTROL
Reference:
1.
The
input
job
stream
is
the sequence
of
batch
processing
control
statements
and
program
data
submitted
to
the
operating
system
on an
input
device
spec-
ified
for
this
purpose.
In
serial
processing
and
basic
multiprogra,
iming
systems,
the
device
tends
to
be
the
system
card
reader,
though,
in
fact,
any input
device
can
be
used.
In
thesc.
two
system
types,
jobs
are read,
processed,
and
output
in
the
order
in which they occur
in
the
input
stream.
2.
In
I.rger
systems,
particularly
extended multiprogramming
systems,
the
input
and
output
streams
are
maintained
as
separate
files
in
direct
access
storage.
Programs
called
symbionts
are
used
to
read
and
transfer
the
system
control
and
data
cards
from
input
devices
to
the
input
stream
files.
Other
symbionts
transfer
output
data
from
output
stream
files
to
the
actual
output
devices.
The
advantage
of
this
technique
can
be
best
illustrated
with
an
example.
Consider
the
concurrent
(either
multiprogrommed
or
time-shared)
execution
of
two
independent
application
programs
in
a
system
that
has
a
single
system
printer.
If
both
programs
require
the
use
of
the
printer,
only
one
can
phys-
ically
be
assigned
the
device.
If
the
device
were
assigned
to
both
programs,
output
data
from
both
jobs
would
appear
intermixed
in
the
listing.
However,
if
one program
is
assigned
the
device,
the
other
must
be suspended
until
the
device
again
becomes
available.
On
the
other
hand,
if
both
programs
create
separate
output
stream
files
on
a
direct
access
device,
both
programs
can
execute
concurrently.
When
each
program
closes
its
output
stream
file,
the.
file
can
be
transferred
to
the
printer
by
an
output
symbiont
when
the
prtnter
is
available.
Thus,
the
single
system
printer
does
not
inhibit
concurrent
processing.
A
further
benefit
is
that
the
system
printer
is
not
reserved
during
the
entire execution
period
of
either
application
program.
Rather,
it
is
reserved
only
for the length
of
time
it
takes
to
transfer
the
output
data
from
secondary
storage.
Thus,
symbiont
proct.ssing
enables
input/output
devices
to
be
utilized
a
physical
data
transfer
rates,
while
permitting
programs
to
process
input
and
output
stream
data
at
strorage
file
transfer
speeds
rather
than
at
tle
lower
peripheral
device
speeds.
The
overall
effect
on
the
system
is a
considerable
increase
in
throughput
without
requiring
additional
peripheral
devices.
Since,
in
time-sharing
applications,
the
terminal
is
usually dedicated
to
a
particular
time-sharing
job,
and
since
both
the
input
and
output
stream
are
usually located
at
the
same
terminal,
no
significant
equipment
or
time
saving
is
afforded
time-sharing
programs
by
using
symbiont
processing
tech-
niques.
On
the
other
hand,
when
the
terminal
is
used
for
remote
batch
processing,
symbiont processing
can
offer
both
time
and
equipment
saving.,
particularly
when
multiple
jobs
are
submitted.
3.
This
criterion
is
highly
dependent
upon
the
hardware
configuration
and
con
only
be
specified
in
detail
when
the
hardware
configuration
is
known.
4.
This
criterion
is
highly
desirable
for
all
batch
processino
systems.
69
REQUIREMENTS
OPERATING
SYSTWM
REQUIREMENTS
CHECKLIST
Reference
initial
Extended
1.3.4
RESOURCE
STATUS
MODIFICATION
(a-e)
The
system
must
provide
control
for
on-line
config-
2
uration
modification
of
the
following
resour,
s:
(a)
peripheral
devices,
(b)
mass
storage
allocation,
(c)
core
storage
allocation,
(d)
CPU
time
allocation,
(e)
input
job
queues.
(f)
The
system
must
permit
operator
control
of
systen
configuration
through
operator
console.
(g)
The
system
must
permit
user
control
of
system
resource
3
ccnfiguration.
(h-I)
The
system
must
recognize
the
following
device
condt
ons:
(h)
available,
(i)
down,
()
assigned,
(k)
reserved,
(I)
test
mode.
4
(m-p)
The system
must
permit
the
following
types
of
5
resource
modification:
(m) addition,
(n)
deletion,
(o)
replaceinent,
(p)
s"Vtching.
(q)
The
system
mus
allow
reconfiguration
in
the
event
6
of
fnalfunct*on
arid
maintain
continuity
of
ot
.ration.
70
1.3.4
RESOURCE
STATUS
MODIFICATION
Reference:
1.
In
most
computer
operating
enviroiments,
it
is
desirable
to
alter
the
computer
configuration
with_
ut
physically
terminaing
all
system
operations.
For
example,
a
tape
drive
may
require
cleaning,
a
disk
file
may
require
mainten-
ance,
or
an
off-line
operation
may
have
concluded
and
edditional
peripheral
devices
may
have become
available
for
system
use.
As
e,
result,
it
is
generally
advisable to
allow
the
computer
operator
to
alter
the
st.
is
of
resources
availa-
ble
to
the
system
during
system
operation.
This
is
frequently
accomplished
via
direct
operator
console
commands
to
the
operating
system
supervisor.
2.
These
criteria
provide
the
flexibility
to
support
changing workloads.
The
modification
of
peripheral
device
configuration
is
particularly
advantageous
where
dynamic
allocation
or
device
substitution
techniques
are employed.
Modification
of
mass
storage
allocation
is
desirable
when
this
storage
is
used
in
support
of
real
time
or
time-sharing.
On-line
modification
of
core
storage
allocation
is
desirable
in
a
system
that
supports
fixed
partitioning
so
that
the
allocation
between foreground and
background
or real
time,/hatch/time-sharing
can
be
altered
to
satisfy
chang-
ing
requirements.
This
feature
would
not
be
relevant
to
serial
processing,
variable
partitioned,
or
paged
environments.
In
multipurpose
environments,
it
is
sometimes
desirable
to
alter
the
dispatching
algorithm
due
to
changing
priorities
or
unusual
system
loads
In
any
environment
in
whi,;h
the
system
supports
input
job
queues,
it
is
a
necessity
that
some
control
be
provided
to
modify
these
queues.
This
control
should
allow
such
functions
as
job
deleting,
postponing,
replacing,
etc.
to
be
performed.
3.
This
feature
is
not
prevalent
e
c
to
the
impact
that
user
control could
have
on
the
total
multiprogramming
system
operation.
However,
when
the
user
does
have
dedicated
resources
(e.g.,
a
remote
batch
terminal)
then
the
criterion
may
be
advisable.
4.
Test
mode
recognition
should be
specified
if
on-line
diagnostics
are
supported
by
the
system.
5.
Replacement
is
a
manual
technique
while
switching
is
normally
used
for
automatic
transfer
to
a
standby
on-line
device.
6.
This
criterion
is
highly
desirable
for
a
real-time
processing
system.
71
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.5
SYSTEM
STATUS
INTERROGATION
1
(a)
The
status
of
the
system
must
be
displayed
continuously.
2
(b-c)
The
status
of
the
system
must
be
displayed
upon
request on
a:
(b)
CRT,
(c)
printer.
(d-i)
The
system must
provide
facilities
to
display
the
3
following
information:
(d)
identification
of
current
users,
(e)
resource
status,
f)
job
status
(executing,
waiting,
suspended,
etc.)
(g)
job
..
,formation
(priority,
title,
etc.)
(H)
input
job
queue status,
()
output
job
queue status.
(j-m)
The
system
must
display
causes
of
processing
delays
4
to
include:
()
peripheral
non-avoilability,
(k)
data
non-availability,
(!)
memory
non-availability,
()
CPU
delays
due
to
unavailability
of
resources.
72
1.3.5
SYSTEM
STATUS
INTERROGATION
Reference:
1.
The
computer
operator
is
usually given
the
capability
of
displaying
the status
of
various
system
elements.
This
may
range
from
ihe
status
of
specific
jobs
to
the
status
of
I/O
devices
and
main
and
secondary
storage.
Systems
vary
con-
siderably
in
the
capabilities
provided
and
where
some
may
only
provide
status
information
on
particular
items, others
will
produce
extensive visual
displays
showing
the
current
status,
relative
usage,
and
accumulated
error
statistics
for
any
system
element.
2.
The
display
of
system
status
continuously
generally
requires
the
use
of
a
reserved
CRT
display
Aevice.
3.
Many
of
these
elements
are
valuable
in monitoring
the
utilization
of
the
system.
It
should
be
determined
by
the
facility
which
will
be
most
useful
in
their
operating
environment.
4.
This
feature
is
very
important
to
a
facility
in
determining
where hardware
or
software
changes can
be
applied
to improve
operation.
73
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Referer
1
ue
Initial
Extended
1.4.1
CHECKPOINTING
I
(a-d)
The
system
must
provide
checkpoint
initiation
from
2
the
following
external
sources:
(a)
control
card,
(b)
system,
(c)
operator,
(d)
interactive
user.
(e)
The
system
must
permit
checkpoint
initiation
by
the
3
program
itself.
(f)
The
system
must
permit
checkpoint
initiation
by
other
4
programs.
(g-1)
The
system
must
provide
check<pointing
for
.he
follow-
5
ing
program
types:
(.9)
proLss
control
programs,
(h)
teleprocessing
programs,
(i)
interrupt
handling
programs,
(j)
interactive
programs,
6
(k)
batch
programs,
(I)
system
supervisory
programs.
7
(m-o)
The
system
must
allow
checkpoint
file
maintenance
8
on
the
following
devices:
(m)
mass
storage
devices,
(n)
scratch
tapes,
(a)
output
data
tapes.
(p)
The
system
must
allow
multiple
checkpoints
to
be
maintained.
74
1.4.1
CHECKPOINTING
Reference:
I.
Checkpointing
if
the
recording
of
information
about
a
program
and
its environ-
ment
on
secondary
storage
so
that at
any
Future
time the
program
may
bo
re-
initiated
from
that
point.
Small
operating
systems,
particularly
serial
process-
ing
systems,
checkpoint
all
of
core
while
most
multiprogfaonmed
systems
check-
point
only
individual
storage
partitions.
2.
In
batch
processing
systems,
control
card
initiation
of
checkpoints
sometimes
occurs
but
is
usually
considered
a
poor
substitute for
programmed
initiation.
Sy:tem
initiated
checkpointing
is
prevalent
in
small
time-sharing
systems
where
programs
are
continuc!!y
being
swapped
between
core
and
mass
storage.
System
initiated
c'eckpoints
are
highly
desirable
for
real-time
environments
as
an
aid
in
recycling
the
system.
However,
while
this
is
advantageous,
it
is
not
always
possible
and
the
intended
real-time
application
should
be
examined
to
see
if
this
is
warranted.
Operator
initiated
checkpoints
are
also
provided
for
many
processing
systems.
3.
This
feature
is
highly
desirable
for
all
processing
systems
during
program
check-
out
and
is
sometimes
mandatory
in
real-time
processing
systems
to
provide
a
recycle
capability.
4.
This
feature
frequently
occurs
in
multiprogramming
sysems
that
support
priarity
processing.
A
priority
program
requiring
extra
core can
checkpoint
an-
her
program and
use
its
assiond
core.
When
finished
the
priority
program
restarts
the
checkpointed
prigrom.
5.
Checkpointing
con
be
a
very
important
feature
in
a
real-time
environment
due
to
the
possible
requirement
for
continuous
support.
The
checkpoint
provides
the
system
with
the
capability
to
perform
quick
recovery
after
malfunction.
This
feature
con
be
very
advantageous
in
process
control
or
interrupt
handling
but
is
extremely
difficult
to
implement
due
to
the
unpredictable
nature
of
the
systems.
In
o
system
perforn.ing
real-tme
monitoring,
but
not
exercising
control
over
external
devices,
implementation
is
considerably
easier.
6.
A
checkpoint
capability
for
interactive
programs
can be
quite
useful
for
program
testing
and
debugging.
7.
Checkpointing
the
supervisory
programs
is
beneficial
duriwg
early
stages of
operating
system
development
if
the
area
in
which
the
supervisor
resides
is
not
storage
protected.
8.
The
device
upon
which
checkpoint files
are
maintcned
depends
upon
the
hardware
configuration.
If
the
amount
of
mass
storage
avcilable
for
check-
point
files
is
restricted,
t' e
use
of
scratch
tapes
should
be
considered.
Mass
storage
usually
only
allows
a
few
checkpoints
to
be
maintained,
while
mag-
netic
tapes
allow multiple
checkpoints.
Checkpoint
files
may
-liso
be
main-
tained
on
output
data
tapes. This
has
the
advantage
of
automatically
position-
ing
the
output
tape
when
loading
the
checkpoint
record for restart.
75
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.4.1
CHECKPOINTING
(Cont'd.)
(q-u)
Checkpoint information
recorded
must
include
the
9
following:
(q)
register
contents,
(r)
I/0
channel
activity,
(s)
contents
of
core
storage,
(t)
temporary data
files,
(u)
permanent
data
files.
(v-y)
The
system
must
allow
checkpoint
notification
10
directed
to
the
following
recipients:
(v)
operator
console,
(w)
interactive
user
terminal,
(x)
job
output
stream,
(y)
system
log.
76
1.4.1
CHECKPOINTING
(cont'd.)
Reference:
9.
It
is
necessary
that
all
information
required to
restart
a
program
be
recorded.
This
information
should
usually
consist
of
register
contents,
I/O
chc.nnel
'ctivity,
contents
of
core
storage,
and
temporary data
files.
Permanent
data
files
are
usually
not
needed
for
checkpoint
purposes
unless
they
are
being
modified.
Similarly,
.;';em
mass
storage
files
are
not
normally
included
within
a
check-
point
record.
aemporary
files
in
use
by
a
program
when
tlK
checkpoint occurs
are
normally
required for
proper
program
restart
and
should
automatically
be
included
as
part
of
the
checkpoint
output.
10.
If
an
interactive
user
has
directed
a
checkpoint
or
initiated
a
checkpoint,
then
he
should
be
notified.
When
checkpoint
notification
is
directed
solely
to
the
output
stream
it
generally
means
that
restart
must
be
performed
by
a
separate
batch
processing
job.
77
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference-
Initial
Extended
1.4.2
RESTARTING
1
(a.-e)
The
systri
must
permit restart
initiation
from the
following
sources:
(a)
job
stream,
2
(b)
program,
3
(c)
operator
console,
(d)
system,
4
(e)
interactive
user
terminal.
5
(f)
The system
must
permit
restart
from
the
last
check-
6
point
taken.
(g)
The
system
must
permit
restart
from
any
specified
7
checkpoint.
(h)
The system
must
permit
checkpoints
initiated
on
one
8
system
to
be
restarted
on
another
system.
(i)
The
system
must
permit
restart
from
the
beginning
9
of
a
job
step.
(j)
The
system
must
provide automatic
replacement
of
10
refreshable
modules.
(k)
The
system
must
provide
device
repositioning.
11
78
1.4.2
RESTARTING
Reference:
1.
Restarting
is
the
process
of
restoring
the
status
of
a
lob
to
some
previous
point
in
time.
The
three
basic
lypes
of
restart
capabilities
used
within
all
operating
systems
are
checkpoint,
task,
and
job.
A
restart
taken
from
a
checkpoint
re-
establishes
the
program
and
its
data
in
the
operating
environment
as
they
existed
when the
checkpoint
was
taken
and
resumes
execution
at
the
restart
address
included
in
the
checkpoint.
A
task
restart
re-initiates
processing
from
the
beginning
of
the
identified
task.
A
job
restart
re-initiates
processing
from
the
beginning
of
the
entire
job.
2.
Restart
initiat~nn
from
the
job
stream
is
the
normal
procedure in
a
batch
processing
system
where
checkpoint
notification
is
directed
to
the output
stream.
3.
Restart
initiation
by
a
program
should
be
specified
for
those
systems
that
support
program
initiated
checkpointing.
4.
System
initiated
restart
is
primarily
a
real-time
processing
function
to
attempt
recovery
after
a
malfunction
or
error.
5.
When
an
interactive
user
has
the
capability
to
initiate
che&'-ooints
he
should
also
have
the
capability
to
initiate
restart.
6.
This
criterion
should
be
specified
for
all
processing
systems
supporting
.heck-
points.
7.
If
a
multiple
checkpoint
capability
is
provided,
this
criterion
should
be
specified.
8.
This
criterion
is
highly
desirable
when
there
is a
separate
computer
system
that
may
be
used
as
a
backup.
9.
This
technique
frequently
occurs
in a
batch
processing
system
and
is a
fairly
simple
operation
to
perform.
10.
A
refreshabie
module
is
unique
in
that
it
is
not
modified
by
itself
or
any
other
program
during
execution.
If
there
are
indications
that
a
program module
has
been damaged
due
to
a
hardware
malfunction,
then the
system
can
replace
a
refreshable
module
with
a
duplicate
copy
without
disturbing
any
intermediate
data
calculations.
11.
Repositioning
of
all
sequential
devices
at
r
rt
should
be
specified
for
all
processing
systems.
It
is
not
normally
reqwired
for
IAS
devices.
79
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
R
terence
Initial
Extended
2.1.
1
ERROR
CORRECTION
(hardware
errors)
(a-c)
The
number
of
retries
of
a
failed
operation
must
be:
(a)
fixed,
1
(b)
determined
at
system
generation
time,
2
(c)
determined by
each
user
program.
3
(d-h)
The
system
must
provide
control
linkage
to
user
4
error
routines
upon
detection
of
the
following
errors:
(d)
CPU
errors,
(e)
I/0
channel
or
/O
processor
errors,
(f)
I/0
device
errors,
(g)
storage
parity
errors,
(h)
power
failure.
(i)
The system
must
provide
interactive
correction
5
procedures.
(j)
The
system
must
provide
alternate
I/0
routing.
6
(k)
The
system
must
initiate
an
automatic
diagnostic
4
routine
upon
equipment
malfunction.
80
2.1.
1
ERROR
CORRECTION (hardware
errors)
Reference:
I.
Most
systems
provide
some
form
of
failed
operation
retry.
The
method
most
frequently
used
by
all
processing
systems
is
a
fixed
number
of
retries.
2.
This
criterion
is
highly
desirable
for
all
processing
systems
since
it
pro-
vides
a
facility
the
flexibility
to
vary
retry
parameters
based
upon
exper-
ience.
This
type
of
variation
will
usually occur
due
to
different
char-
acteristics
of
magnetic
tape
or
non-standard
I/0
devices.
3.
This
method
is
sometimes
used
in
small
to
medium
sized
time-sharing
systems
and
also
real-time
systems
in
which
the
user
provides
an
I/0
routine
for unique
device
manipulation.
4.
This
function
is
highly
desirable for
a
real-time
processing
system.
5.
This
feature
rarely
occurs
in any
processing
system
except
as
a
means
of
permitting
the
operator to
select
from
available
options
or to
perform
an
override
where
redundancy
is
available.
An
example
of
override
could
be
in
the
case
of
a
real-time
processing
system
which
uses
triple
modular
redundant
voting
circuits,
one
of
which
is
continuously
indicating
error,
where the
operator
instructs
the
system
to
disregard
the
error since
two
circuits
are
still
functioning.
6.
This
criterion,
,ile
desirable
for
a
real-time
processing
system,
is
highly
dependent
upon
the
hardware
configuration.
81
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.1.2
ERROR
NOTIFICATION
(hardware
errors)
(a)
The
system
must
output
operator
console
error
1
messages.
(b)
The
system
must
output
interactive
user
console
1
error
messages.
(c)
The system
must
permit
subroutines
and
tasks
to
2
return error
codes
to
calling
programs.
(d)
The
system
must
update
and
maintain
error
statistics
3
files.
(e)
The system
must
provide
diagnostic
logout
of
3,4
permanent
errors.
(f)
The
system
must
provide
an
error
trace
showing
3
the events
leading
up
to
an
error.
(g)
The
system
must
notify
remote
users
o
equipment
mal
functions.
2.1.3
ERROR
RECOVERY
(hardware
errors)
(a-b)
The
system
must
provide
the
following
forms
of
1
system
reconfiguration:
(a)
alternate device
utilization,
(b)
controlled
system
degradation.
(c-d)
The
system
must
allow
manual
reconfiguration
1
through:
(c) resource
respecification,
(d)
system
regeneration.
(e)
The
system
must
permit
on-line
system
maintenance
2,3
of
devices.
(F)
The
system
must
provide
for
automatic
restart
from
2
a
system
maintained
checkpoint.
82
i
2.1.2
ERROR
NOTIFICATION
(hardware
errors)
Reference:
1.
This
criterion
is
highly
desirable
for
all
processing
systems.
Notification
should
usually
occur
if
an
error cannot
be
corrected
or
if
it
is
recurring
persistently.
2.
This
feature
is
desirable
for
most
processing
systems
since
continued
oper-
ation
is
usually
conditional
upon
error
notification.
Other
alternatives
to
this feature would
be
automatic
task
abort
or,
if
continued operation
is
required,
operator/user
notification.
3.
This
function
is
highly
desirable
for
all
processing
systems
but
is
usually
found
only
in
medium
to
large
scale
systems.
This
is a
definite
aid
for
hardware
naintenance
and
system
trouble
shooting.
4. In a
multiprocessor
configuration,
a
separate
processor
can
look
at
a
logout
from
another
processor
to attempt
to
effect
recovery.
2.1.3
ERROR
RECOVERY
(hardware
errors)
Reference:
1.
This
criterion
is
highly
dependent
upon
the hardware
configuration.
The
alternate
device
mode
is
considered the
better
of
the
two
modes
since
it
does
not
affect
the
capability
of
the
system
to
provide
total
support.
The
degraded
mode
allows
the
system
to
support
the
most
critical
operations
while
other
operations
are
suspended.
In
critical
real-time
control
systems
the
alternate
device
mode
is
used
as
a
first
resort
and
the degraded
mode
is
used
only
when
no
alternate devices
are
available.
Either
of
these
modes
can
be
either
manual
or
automatic,
however, the
automatic
mode
is
used
most
frequently.
Resource
specification
;s
the
best
metl
'd
for
performing
manual
reconfiguration
while
system
regen-
eration
is
generally
slow
and
used
on!y
as
a
i:st
resort.
2.
This
feature
is
highly
desirable
for
a
real-time
processing
system.
3.
This
function
can
help
reduce
system
down-time
for
scheduled
mainten-
ance.
However,
it
usually
requires
a
system
that
supports
device
pools
or
dynamic
allocation
of
devices.
83
F1
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.2.1
ERROR
CORRECTION
(program errors)
(a-g)
The
system
must
provide
controlled
linkage
to
user
1
error
routines
upon
detection
of
the
following
errors:
(a)
arithmetic
errors,
(b-d)
instruction
errors:
(b)
invalid
instruction,
(c)
unsupported
instruction,
2
(d)
privileged
instruction.
(e)
invalid
addresv
errors,
(f)
storage
protection
errors,
(g)
invalid
data
errors.
(h)
The
system
must
permit the
inclusion
of
user
defined
2
instruction
modules
for
unsupported
intructions.
(i)
The system
mu-
provide
interactive
correction
3
procedures.
2.2.2
ERROR
NOTIFICATION
(program errors)
(a)
The
system
must
output
program
error
messages
on
the
operator's
console.
(b)
The system
must
provide
abnormal
termination
2
indicators.
(c)
The
system
must
permit
job
steps
to
set
error
indicators
3
for
subsequent
job
steps.
(d)
The
system
must
provide
program
errop
notification
4
to
interactive
users.
84
2.2.1
ERROR
CORRECTION
(program
errors)
References:
1.
Most
frequently
linkage
is
provided
to
user
errrr
routines
due
to
arith-
metic
or
invalid
data
errors,
while
other
errors
tend
to
be
handled
by
the
system
itself.
2.
This
criterion
also
provides
the
user
with
the
capability
to
define
and
develop
his own
unique
instructions.
3.
This
function frequently
occurs
in
small
real-time
and
time-sharing
processing
systems
in
which
the
programmer/user
participates
in
an
on-line
mode
during
program
debug
cycles.
2.2.2
ERROR
NOTIFICATION
(program errors)
Reference:
1.
This
criterion,
while
highly
desirable
for
a
real-time
processing
system,
is
not
usually
desirable
in
a
time-sharing
ot
muttiprogrammed
batch
processing
system.
2.
This
Function
is
highly
desirable
for
all
processing
systems.
3.
This
feature,
while
highly
desirable
for
a
batch
processing
system,
does
not
aflord
any
advantage
in
a
ieal-time
or
time-sharing
application.
4.
This
criterion
is
highly
desirable
for
time-sharing
processing
systems.
85
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.2.3
PROGRAM
TERMINATION
(a)
The
system
must
provide
conditional
termination
1
based
upon
a
specified
error
level
being
reached.
(b-e)
The
system
must
allow
abnorma!
termination
to
be
initiated
by:
(1)
the
system,
2
(c)
the
operator,
2
(d) a
user
program,
(e)
an
interactive
user.
3
2°3.1
OPERATOR
KEY-IN
EDITING
(a)
The
system
must
provide
assumed
default
options.
b-d)
The
system
must
provide
the
following
forms
of
2
error
notificetion:
(b)
coded
m
ssages,
(c)
free
format
messages,
(d)
tutorial
messages.
86_
2.2.3
PROGRAM
TERMINATION
Reference:
1.
This
feature
is
highly
desirable
for
all
processing
systems
as
an
aid during
initial
program
compilaton
and
checkout.
2.
Abnormal
termination
by
the
system
is
frequently
used
when
system
rules
are
violated
e.g.,
privileged
instruction,
memory
protect,
or
in
a
real-
time
processing
system
due
to
the
invocation
of
a
degraded
mode
of
operation.
If
the
computer
operator
receives
program
error
notification,
he
should
also
have the
capability
to
initiate
abno-,mal
termination.
3.
TLis
criterion
should
be
specified
for
a
time-sharing
processing
system.
2.3.1
OPERATOR
KEY-IN
EDITING
Reference:
I.
This
criterion
should
be
considered
for
specification
for
all
processing
systems
since
it
will
expedite
operator
key-ins.
2. While
frequently
employed
for
evaluation,
these
criteria
are
-rely
specjied.
Generally,
if
the hardware
configuration
is
small,
then
coded
messages
ore
used
since
they
do not
require
much
storage
area.
In
larger
systems,
free
format
or
twtorial
messages
may
also
be
provided.
When
available,
the
tutorial
presentation
is
the
better
of
the
two.
87
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
nitial
Extended
2.3.2
CONTROL
COMMAND
EDITING
(a-c)
The
system
must
provide
the
following
options
upon
detection
of
a
control
command
error:
(a)
job
termination,
2
(b)
command
rejection,
3
(c)
request
for
clarification
by
the
3
operator/user.
2.3.3
REMOTE
TERMINAL
COMMUNICATION
EDITING
(a-d)
The
system
must
provide
editing
at
the
following
levels:
(a)
message
format,
(b)
command
structure,
(c)
data structure,
(d)
invalid
characters.
(e-g)
The
system
must
provide
the
following
types
of
error
2
notification:
(e)
coded
messages,
(f)
free
format
messages,
(g)
tutorial
messages.
(h)
The
system
muit
edit
the
user/terminal
ID.
2.3.4
PROGRAM
TO
SYSTEM
LINK
VERIFICATION
(a-c)
The
system
must
provide
linkoge
verification
at
the
following
levels:
(C)
reqiuested
operation
code,
(b)
parameter
list
validation,
(c)
calling
sequence.
88
2.3.2
CONTROL
COMMAND
EDITING
Reference:
1. A
mixture
of
these
criterion
may be
provided
based
upon
the
command
type.
2.
This
function
frequently
occurs
in
batch
processing
systems
and
is
desirable
for
all
non-interactive
processing.
3.
This
criterion
is
highly
desirable
for
interactive
processing
applications.
2.3.3
REMOTE
TERMINAL
COMMUNICATION
EDITING
Reference:
1.
These
criteria
are
highly
desirable
for
a
time-sharing
or
remote
batch
processing
system.
The
edit
levels
most
frequently
supported
(in
the order
of
frequency
at
which
support occurs)
are: data
structure,
message
format,
command
structure,
and
invalid
characters.
2.
Errcr
notification
should
be
specified
for
remote
batch
and
time-sharing
processing
systems,
with
coded
messages
being
most
prevalent
in
small
system-,
free
format
messages
prevalent
in
large
remote
batch
systems,
and
tutorial
messages
in
large
time-sharing
systems.
2.3.4
PROGRAM
TO
SYSTEM
LINK
VERIFICATION
Reference:
1.
These
criteria
should
be
considered for
most
processing
systems
sin
ce
the
degree
to
which
linkage
verification
is
performed
can
affect
system
reliability.
When
employed
in
evaluation,
the
system
providing
the
most
levels
of
verifi-
c'-tion
should
be
favored.
89
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.1.1
REAL-TIME
CLOCK
SERVICE
(a)
The
system
must
provide
the
current
date.
1
(b-d)
The
system
must
provide
the
time
of
day in
the
1
following
formats:
(b)
hours/minutes/seconds,
(c)
hours
and
decimal
fraction,
(d)
internal
code.
(e)
The
system
must
provide
date
conversion
facilities.
2
(f)
The
system
must
provide
time
format
conversion
2
faci
I
ities.
(g)
The
system
must
provide
facilities
for
task
interruption
3
at
a
specified
time.
(h)
The
system
must
provide
facilities
for
task suspension
3
until
a
specified
time.
90
3.
1. 1
REAL-TIME
CLOCK
SERVICE
Reference:
1.
This
criterion
should
be
specified
for
any
system
that
either
uses
job
accounting
facilities
or
time-initiated
scheduling.
2.
This
criterion
is
highly
desirable
since
it
is
usually
more
advantag-
eous
for
the
system
to
perform
conversion
than
each
user
program.
3.
This
feature
usually
occurs
in
multiprogramming
systems.
An
interrupt
at
a
specified
time
is
useful
to
a
program
that
is
to acquire
data
at
an
exact
time
of
day
e.g.,
acquisition
of
deep
space
telemety
data,
etc.
Suspension
of
a
program
until
a
specified
"*me
is
another way
of
acquiring
data
that
arrives
at
a
specified
tme.
k.
this
way the
program
performs
all execution
up
to
a
point
at
which
the
data
is
required
and
then
is
suspended.
91
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.1.2
INTERVAL
TIMER
SERVICE
(a)
ThL system
must
provide
up
to
interval
timers
(fixed
or
programmable).
(b-c)
The
system
must
provide
interrupt
service
as
follows:
(b)
at
the
completion
of
a
specified
2
single
interval.
(c)
at
each
completion
of
a
specified
2,3
periodic
interval.
(d-f)
The
system
must
permit
time
intervals
to
be
measured
in
terms
of:
(d)
actual
elapsed
time,
2,3
(e)
elapsed
task
execution
time,
3,4
(f)
time the
task
is
actually
using
the
3,4
CPU.
(g)
The
system
must
permit
task
suspension
for
a 2
specified
time
interval.
(h-m)
The
timer
base
(update
interval)
must
be:
5
(h)
the
same
for
all
interval
timers,
6
(i)
independent for
each
timer,
6
(j)
fixed,
6
(k)
specified
at
system
generation time,
7
(I)
specified
by
control
commands,
8
(in)
specified
dynamically. 9
92
3.1.2
INTERVAL
TIMER SERVICE
Reference:
1.
The
number
of
interval
timers
a
system
must
support
is a
function
of
how
the
interval
timers
will
be
used
and
the
anticipated
frequency
of
utiliza-
tion.
Since
the
interval
timer
is a
hardware
item,
the
number
supported
by
the
system
is
frequently
established by
hardware.
2.
This
criterion
should
be
specified
for
a
real-time
processing
system.
3.
This
function
frequently
occurs
in
a
time-sharing
processing
system.
4.
This
feature
frequently
occurs
in
systems
that
perform
an
accounting
function.
5.
The
precision
of
an
update
interval
can
usually
be
expressed
in
nano-
seconds,
microseconds,
milleseconds,
or
seconds.
A
real-time
pro-
cessing
system
will
usually
be
satisfied
by
microsecond
or
millesecond
updates
while
a
time-sharing
processing
system
will
usually
be
satisfied
by
millesecond
or
second
updates.
6.
Having
the
same
update
interval
or
a
fixed
timer
base
for
all
interval
timers
is
the
simplest
hardware
implementation
method
but
it
may
not
be
flexible
enough
to
support
a
combined
time
sharing
and
real-time
processing
system.
An
independent
update
interval
for
each
interval
timer
provides
quite
a
bit
of
flexibility
as
long
as
the
intervals
available
cover
the
realm
of application
possibilities.
7.
This
criterion
provides
a
great
deal
of
flexibility
if
each
timer
update
interval
can
be
specified
independently.
8.
This
criterion
provides
even
greater
flexibility
on
a
day
to
day
basis.
9.
This
methoa
is
the
most
flexible
means
available
and
should
be
considered
when
the
interval
timers
are
considered
allocatable
resources
within
a
multi-
programmed
real-time
processing
system.
93
R
JREM
ENT
S
OPERATING
SYSTEM
RO
EET
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.2.1
STORAGE
DUMP
CONTROL
(a)
The
system
must
provide
snapshot
storage
dump
facilities.
(b)
The
system
must
provide
postmortem
storage
dump
facilities.
(c-i)
The
system
must
permit
specification
of
dump
boundaries
as
follows:
(c)
all
available
storage
areas,
(d-g)
specified
areas:
(d)
resident
system
area,
2
(e)
user
areas,
(f)
I/0
areas,
(g)
common areas.
(h-i)
specified
locations:
(h)
all
storage
between
specified
starting
and
ending
lorations,
(i)
list
of
locations.
(j-o)
The
dumps must
3ntain
the
following
infb)rmation:
(j)
dump
identification,
(k)
registers,
(I)
indicators,
(m)
file
positions,
(n)
file
contents,
(o)
memory
contents.
(p-q)
The
system
must
provide
the
following
data
formats
for
dumps:
(p)
machine
code,
3
(q)
character
code.
4
(r-s)
The
system
must
provide
the
following
dump
format
5
options:
(r)
instruction
interpretation,
(s)
numeric
data
conversion.
94
3.2.1
STORAGE
DUMP
CONTROL
Reference:
I.
The
features
incorporated
under
storage
dump
control
should
be
carefully
evaluated
in
respect to
the
type
and
amount
cf
program
testing
that
is
anticipated.
Since
the
checkout
cycle
can
be
significantly
improved
by
the
implementation
of
many
of
these
techniques,
an
installation
anticipating
continued
program
development
would
do
well
to
assess
this
area
in
detail.
On
the
other
hand,
an
installation
with
little
involvement
in
program
development
would
only
require
a
minimum
of
these
facilities.
2.
This
criterion,
if
specified,
should
be
restricted
to
use
by
facility
OS
maintenance
personnel.
3.
This
criterion
should
be
considered
for
a
real-time
processing
system.
4.
This
criterion
is
highly
desirable
for
both
batch
and
time-sharing
processing
system.
5.
This
feature
is
highly
desirable
for
all
processing
systems
as
an
aid
in
the
checkout
cycle
since
the programmer/user
will
not
be
required
to
interpret
or
convert manually.
95
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.2.1
STORAGE
DUMP
CONTROL
(cont'd.)
(t)
The system
must
provide
conditional
dump
display
6
facilities,
i.e.,
dump
to high
speed
device
for
optional
display.
(u)
The
system
must
provide
automatic
dump
initiation. 7
(v)
The
system
must
provide
conditional
dump
initiation.
8
(w-y)
The
system must
allow
dump
in;tiation
from:
iw)
control
statements,
(x)
operator
key-in,
(y)
interactive
user
key-in.
96
3.2.1
STORAGE
DUMP
CONTROL
(cont'd.)
Reference:
6.
This
criterion
should
be
considered
for
specification
if
a
multiple
dump
capability
is
provided
since
it
will
give
the
user
selectivity
in
displaying
only
the
dumps
or portions
of
dumps
that
he
desires.
7.
This
feature
frequently
occurs
in
all
processing
systems
at
abnormal
termination.
8.
This
feature
frequently
occurs
in
processing
systems
that
provide
error
code
leveis,
etc.
97
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Exterded
3.2.2
TRACING CONTROL
(a-e)
The system
must
provide
the
following
types
of
I
tracing:
(a)
data
tracing,
(b)
intruction
tracing,
(c)
logic
tracing,
(d)
supervisor
service
request
tracing,
(e)
subroutine
call
tracing.
(f-h)
The
system
must
allow
trace
initiation
from:
(f)
control
statements,
2
(g)
operator
key-in,
3
(h)
interactive
key-in.
4
,o8
3.2.2
TRACING
CONTROL
Reference:
1.
These
criteria
are
frequently
employed
in
the
evaluation
of
a
tracing
package
and
can
only
be
specified
if
detailed
information
i,
available
on
the types
of
traces
that
will
be
required.
Data
tracing
traces
only
references
to
specified
data
locations,
instruction
tracing
traces
every
instruction,
logic
tracing
traces
only
changes
in
instruction
sequence
(e.g.,
branches),
supervisor
service
request
tracing
traces
only
system
service
request
occurrences,
and
subroutine
call
tracing
traces
only
entry
and
exit
from
subroutines.
2.
This
criterion
should
be
considered
for
a
batch
processing
system.
3.
This
criterion
should
be
considered
for
a
real-time
processing
system.
4.
This
criterion
should
be
considered
for
a
time-sharing
processing
sysiem.
99
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Refererce
Initial
Extended
3.2.3
SYSTEM
TEST
MODE
CONTROL
(a-d)
The system
must
proide
I/0
simulation
facilities
to-
(a)
ignore
I/0
requests,
(b)
reroute
I/0
requests,
(c)
log
I/0
requests,
(d)
simulate
I/0
error
conditions.
(e)
The
system
must
provide
automatic
storage
dumps.
2
(f)
The
%ystem
must
provide
automatic
file
dumps.
2
(g)
The
system must
allow
the
user
to
override
abnormal
3
abort
services.
(h)
The
system
must
allow
the
user
to
override
subsequent
3
job
step
cancellatiot.
(i)
The
system
mst
allow
fr
the
insertion
of
breakpoints
4
i-I
programs.
(I)
The
system
must
allow
the
user
to start
tr
restart
a 4
program
ce
a
specified
address.
(k)
The
system
must
permil
memory
searching/display.
4
(!)
The
system
mwt
permit
memory
modificotion. 4
(m)
The
system
must
provide
interrupt
or
error
notificat;on
4
and
allow
the
user
to
override
those
conditions.
(n-p)
The
system
must
proviae
for
on-line
program
4
development
from remote
terminals
to
;nclude:
(n)
statement
by
statement
entry
of
progi.-m
or
job,
(o)
compilation
or assembly
with
return
diagnostics,
(p)
line
update
or
mod
rication
of
r,
permanent
or
tempovory
program.
100
3.2.3
SYSTEM
TEST
MODE
CONTROL
Reference:
1.
When
a
system
has
a
test
mode
that
permits
program
or
hardware
testing
while
o'-line
support
is
also
being
provided,
it
is
usually
necessary
for
i/O
simulation
facilities
to
be
provided
to
keep
test
programs from
inter-
fering
with
actual
on-line
processing.
Simulation
of
I/O
can
also
be
a
very
:mportant
feature
in
performing
program
checkout
prior
to
total
system
installation.
The
different
types
of
simulation
techniques
are
rarely specified;
how-
ever,
they
should
be
used
as
a
means
of
evaluating
a
system's
capability.
The
best
method
employed
is
rerouting
of
i/O
requests,
second
is
logging
I/O
requests,
and
lost
is
ignoring
!/0
requests.
The
simulas'on
of
1/O
error
conditions
is
also
important
in
that
it
allow3
Aiagnostic
and
error
processing
routines
to
be
checked
wthout
actually
introducing
the
hard-
ware
error.
2,
This
criterion
should
be
specified
for
ali
processing
systems
as
a
means
of
supporting
abnormal
termination.
3.
Th.-s
criterion
should
be
specified
fcr all
processing
systems
that
provide
abnormcl
termination
services,
since
the
services
may
not
be
required
or
wanted
by
tIe
user
each time
abnormal
termination
occurs.
4.
These
criteria
are
h;ghly
desirable
in
all
processing
systems
in
which
interactive
testing
;s
F3rformed.
101
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.3.1
MAINTAIN!NG
JOB CHARGE
iNFORMATION
(a-g)
The
system must
record
and
mainalin
the
fol!owing
job
1
charge
information:
(a)
CPU
time
utilization,
(b)
I/0
channei
and
device
time
utili-
zution,
(c)
I/O
record
counts,
(d)
main
storage
utiiization,
(e)
secondary
storage
utilization,
(f)
remote
terminal
utilization,
(
g)
job
termnation
conditions,
(h)
total
elapsed
time,
()
date.
(j)
The
system
must
provide
linkage
to
user
supplied
2
accountir
routines.
(k-n)
The
system
must
allow
job
charge
information
to
be
placed
on:
(k) a
printed
log,
3
(1) a
card
file,
4
(m) a
system
file,
5
(n) a
user
file.
6
(o-p)
The system
must
allow
job
charge
information
to
be
displayed
at
a:
(o)
users
terminal,
(p)
central
site
device
102
3.3.1 MAINTAINING
JOB
CHARGE
INFORMATION
Reference:
1.
Many
of
these
criteria
are
highly
desirable
for
a
batch or
time-
sharing
processing
system
in
which
job
charge
information
is
required.
This
type
of
information
is
also
useful
in evaluating
system
utilization.
2.
This
criterion
is
highly
desirable
for
all
processing
systems
that
require
accounting
routines,
since
each
installation
usually
has
a
need
for
separate
charge
calculations.
3.
This
function
frequently
occurs
in
a
batch
processing
system.
4.
This
method
is
rarely
used
and
should
only
be
considered
for
small
systems
with
insufficient
IAS.
5.
This
criterion
should
be
specified
if
the
accounting
routines
are
system
supplied.
6.
This
criterion
should
be
specified
if
the
accounting
routines
are
supplied
by
the
installation.
103
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.3.2
MAINTAINING
ERROR
STAT!STICS
(a)
The
system
must
accumulate
information
for
a
hardware
error
summary.
(b)
The
system
must
accumulate
information
for
a
program
2
error
summary.
(c)
The
system
must
provide
facilities
for
the
analysis
3
of
error
statistics
(e.g.,
indication
of
faulty
/O
devices,
etc.).
(d)
The system
must
provide
lists
of
file
access
violation
4
attempts.
3.3.3
MAINTAINiNG
SYSTEM
UTILIZATION
STATISTICS
(a)
The
system must
maintain
a
summary
by
user
account.
1
(b)
The
system must
maintain
a
summary
of
file
accesses.
1
(c)
The
system
must
maintain
a
summary
of
system
service
rquests.
(d)
The system
must
provide
performance
monitoring
2
informaQ*,n.
104
3.3.2
MAINTAINING
ERROR
STATISTICS
Reference:
1.
This
criterion
should
be
considered
for
specification
for
all
processing
system
types
as
an
aid to
personnel
performing
hardware
diagnostic
maintenance.
2.
This
function
occurs
infrequently,
and
then
is
usually
restricted
to
batch
processing
systems
as
an
aid
in determining
which
programs
are
continually
incurring
error
conditions.
3.
Thi,
criterion
should
be
specified
for
all
processing
systems
that
accumu-
late
a
hardware
error
summary.
4.
This
criterion
is
highly
desirable
for
all
processing
systems
that
provide
file
access
security
controls.
3.3.3
MAINTAINING
SYSTEM
UTILIZATION
STATISTICS
Reference:
1.
These
criteria
should
be
considered
for
specification
in
multi-user
batch
processing
and
time-sharing
systems.
2.
These
criteria
are
desirable
when
a
general
purpose
system
is
to
be
tailored
to
a
specific
installation.
The
information
provided
should
present
sufficient
details
to
enable
the
installation
to
modify
system
generation
parameters
for
more
efficient
system
operation.
105
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.4.
1
CURRENT
SYSTEM
STATUS
INTERROGA-
TION
(a-h)
The system
must
maintain
the
following
status
informa-
I
tion.
(a)
number
of
jobs,
(b)
number
of
interactive
users,
(c)
list of
active
terminals,
(d)
main
storage
allocation
(e)
secondary
storage
allocation,
(f)
device
allocation,
(g)
device
status,
(h)
elapsed
execution
time.
3.4.2
SYSTEM
DEFINITION
INTERROGATION
(a-c)
The system
must
maintain
the
Following
definition
information:
(a)
hqrdware
configuration,
I
(b)'
software
configuration,
I
(c)
system
limits
(e.g.,
number
of
jobs
2
allowed,
etc.).
106
3.4.1
CURRENT
SYSTEM
STATUS
INTERROGATION
Reference:
1.
These
criteria
should be
considered
for
specification
since
they
can
be
useful
to
a
facility
in
monitoring
system
operation.
These
system
features
can
also
be
useful
during
system
evaluation.
3.4.2
SYSTEM
DEFINITION
INTERROGATION
Reference:
1.
This
criterion
is
highly
desirable in
all
processing
systems
in
which
adaptive
programs
are
available
e.g.,
a
compiler
that
can
operate
with
various
configurations
or
an
application
program
that
can
use
various
devices
or
reside
in
various
core
sizes.
2.
This
criterion
is
highly
desirable in
any
system
in which
performance
monitoring
is
to
be
performed.
107
3.2.4
Fourth
Level
of
Detail
(Part
I -
Executive/Control
Functions)
This
subsection
covers the
following
fourth
level
executive/control
functions:
1.1.1.1
ALGORITHMIC
SCHEDULING
1.1.1.2
TIME
INITIATED
SCHEDULING
1.1.1.3
EVENT
INITIATED
SCHEDULING
1.1.1.4
PROGRAM
INITIATED
SCHEDULING
1.1.1.5
CONDITIONAL
SCHEDULING
1.1.1.6
SCHEDULING
QUEUE
MAINTENANCE
1.1.2.1
CORE
STORAGE
ALLOCATION
1.1.2.2
I/O
DEVICE
ALLOCATION
1.1.2.3
COMMON
ROUTINE
ALLOCATION
1.1.3.1
LOADING
CONTROL
1.1.3.2
SWAPPING
CONTROL
1.1.3.3
STRUCTURE
CONTROL
1.1.4.1
DISPATCHING
CONTROL
1.1.4.2
EVENT
SYNCHRONIZATION
1.1.4.3
INTERRUPT
PROCESSING
CONTROL
1.1.4.4
PROGRAM
LIMIT
MONITORING
1.2.2.1
BUFFERING
CONTROL
1.2.2.2
DATA
CODE
TRANSLATION
1.3.1.1
SYSTEM
INITIALIZATION
1.3.1.2
SYSTEM
RESTART
1.4.2.1
PROGRAM
INITIATED
RESTARTING
1.4.2.2
SYSTEM
INITIATED
RESTARTING
1.4.2.3
DEVICE
REPOSITIONING
109
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.1.1
ALGORITHMIC
SCHEDULING
1
(a)
The
scheduling
algorithm
must
recognize
job
priority.
(b)
The
scheduling
algorithm
must
ascertain
resource
2
availability
prior
to
job
initiation.
(c)
The
scheduling
algorithm
must
be
responsive
to
the
length
of
time
a
program
has
remained
unscheduled
in
a
scheduling
queue.
(d)
The
scheduling
algorithm
must
take
into
consideration
estimated
time
requirements.
(e)
The
scheduling
algorithm
must
take
into
consideration
4
predictions
as
to
whether
a
given
job
will
be
I/0
or
CPU
bound.
(f)
The
system
must
permit operator
modification
of
job
priorities.
(g)
The
system
must
permit operator
modification of
the
scheduling
algorithm.
'I
___________
_______________ _____________
....
o1
1.1.1.1
ALGORITHMIC
SCHEDULING
Reference:
1.
Algorithmic
scheduling
is a
priorily
scheduling concept
where
man.
variables
influence
the
selection
of
the
program chosen
for
execution.
2.
It
is
generally
desirable
that
all
the
resources
a
program
may
need
be
made
available
prior
to
scheduling
the
program
for
execution.
For
example,
if
this
were
not
done
and
a
named
input
file
was
not
on-line
when
the
program was
scheduled,
the
program
would
be
unable
to
execute
until
the
file
was
located,
mounted,
and
recognized
by
the
system.
However, the
program
would
still
be
occupying
core
storage
which
could
otherwise
be
used.
3.
Since
it
is
possible,
because
of
low
priority
or
lack
of
resources,
For
a
program
to
be
delayed
in
the
scheduling
queue
for
a
long
time,
this
variable
is
some-
times
included
within
the
scheduling
algorithm.
If a
program
has
been
waiting
over
an
established time
limit
the
system
can
begin
to
reserve
the
resources
that
it
requires
as
they
become
free
in
order
to
insure
that
all
required
resources
will
be
available.
4.
A
parameter
denoting
those
programs
which
are
either
I/O
or
CPU
bound can
enable the scheduler to
develop
a
better
job mix
to maximize
system
utiliza-
tion
and/or
throughput.
111
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1
1.2
TIME
INITIATED
SCHEDULING
(a)
The
system
must
permit
a
job
to
be
scheduled
at
a 1
specified
time
of
day.
(b)
The system
must
permit
a
job
to
be
scheduled
after
a 2
specified
time
interval.
(c)
The
system
must
permit
a
job to
be
scheduled
period-
2
ically
at
each
elapsement
of
a
specified
time
interval.
(d)
The
system
must
permit
specification
of
a
time
dead-
1
Ine
for
scheduling
a
job.
1.1.1.3
EVENT
INITIATED
SCHEDULING
(a)
The
system
must
provide scheduling
based
upon
different
event
priority
levels.
(b-h)
The
system
must
provide scheduling
based
upon
the
following
types
of
events:
(b)
communications
interrupts,
2
(c)
operator
interrupts,
3
(d)
process
control
interrupts,
(e)
error
conditions,
3
(f)
I/O
completion,
(g)
task
completion,
(h)
unsolicited
key-ins.
2
112
1.1.1.2
TIME
INITIATED
SCHEDULING
Reference:
1.
This
criter'on
should
be
considered
for
real-time
and
batch
processing
applications.
2. This
criterion
should
be
considered
for
real
-time
processing
systems
that
monitor
input
f;om
external
devices
either
on
a
periodic or
elapsed
interval
basis
e.g.,
teleprocessing,
telemetry
updates,
analog
updates,
etc.
1.1.1.3
EVENT
INITIATED SCHEDULING
Reference:
1.
Multiple
priority
levels
will
most
likely
be
required
in
t'me-critical
environments.
2.
This
criterion
should
be
specified
for
real-time,
remote
batch
and
interactive
processing
systems.
3.
This
criterion
should
be
spec'Fied
for
all
processing
systems.
113
REQUIREMENTS
OPERATING
SYSTEM
I-
REQUIREMENTS
CHECKLIS"
Reference
Initial
Extended
1.1.1.4
PROGRAM
INITIATED
SCHEDULING
(a-c)
The
system
must
provide
for
program
initiated
scheduling
of:
(a)
symbionts,
1
(b)
subprograms/tasks,
I
(c)
independent
programs/tasks.
2
(d)
The
system
must
provide scheduling
for
immediate
3
execufI
cn
(e)
The
system
must
provide scheduling for
asynchronous
3
execution.
(f)
The
system
must
provide
scheduling
for sibsequent
3
execut;on.
114
1.1.1.4
PROGPAM
INITIATED
SCHEDULING
Reference:
1.
This
feature
is
most
frequently
found
in
large
multiprograrmred
batch
processing
systems.
2.
This
feature
is
frequently
found
in
time-sharing
systems
where
a
foreground
time-sharing
program
initiates
a
botch
processing
background
program.
3,
The
two simplest
rnet:ods
of
program
initiated
scheduling
are
immediate
execution
and
subsequent
execution.
in
the
immediate
method
the
program
in
execution
initiates
a
call
for another
program
to
be
scheduled.
The
calling
program
is
suspended
until
the
called
program
terminates.
When
subsequent execvution
is
specified,
the
called
prgram
is
not
executed
until
the
calling
program
terminates.
The
most
difficult
but
most
versatile
method
is
asynchronous
execution
whereby
both
the
calling
program
and
the
called
program
execute
con-
currently.
115
REQUIREMENTS
OPERATING
SYSTEM
..
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.1.5
CONDITIONAL
SCHEDULING
(a-d)
The
system
must
provide scheduling
which
is
conditional
upon
recognition
of
the
following:
(a)
task
completion/abnormal
termination,
(b)
internal
switches
set
by
prior
task,
(c)
error
code
set
by
prior
task,
(d)
externally
set
swcches.
(e)
The
system
must
provide
for
conditional logic
specifi-
cation
by
means
of
system
parameters.
(f)
The
system
must
provide
for
conditional
logic
specifi-
cation
by
means
of
job
control
statements.
(g)
The
system
must
permit
conditional
scheduling
at
the
job
level.
(h)
The
system
must
permit
conditional
scheduling
at
the
job
step
level.
(i)
The
system
must
permit
conditional
scheduling
at
the
task
level.
1.
1.1.6
SCHEDULING
QUEUE
MAINTENANCE
(a)
The
system
must
maintain
job
input
queues.
(b)
The
system
must
permit
up
to
job
entries
in
each
1,2
input
queue.
116
1.1.1.5
CONDITIONAL
SCHEDULING
Reference:
1.
While
frequently
employed
for
evaluation,
these
criteria
are
rarely specified.
The most
likely
reason
for
specification
would
be
when
designing
a
special
purpose
batch
processing
system
for
a
specific
application.
The
intended
application
program
capabilities
and
design should have
been
analyzed
in
sufficient
detail
to
justify
the
need
for
this
specification.
1.1.
.6
SCHEDULING
QUEUE
MAINTENANCE
Reference:
1.
These
criteria
are
highly
dependent
upon
the hardware
configuration
and
can
only
be
specified
in
detail
when
the
hardware
configuration
is
known.
2.
The
number
of
job
entries
in
each
queue
should
be
based
on
the
anticipated
work
load
and
the degree
of
job
stacking that
will
occur.
For
example,
a
remote
terminal
that
submitted
all
of
its
batch
jobs
at
a
single
time
rather
than
on
a
random
basis
would require
.
relatively
large
queue.
The
amount
of
secondary
storage
that
will
be
available
for
job
stacking
must
also
be
taken
into
account.
117
REQUIREMENTS
O
PERATIN
G
SY
STEM
... ..
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.2.1
CORE
STORAGE
ALLOCATION
(a-d)
Static
core
storage
allocation
will
be
provided
at
the
following
levels:
(a)
partition,
I
(b)
jrd
, 2
(c)
job
step,
2
(d)
task.
2
(e-i)
Core
storage
must
remain
allocated
until:
3
(e)
explicit
deallocation,
(f)
job
completion,
(g)
job
step
completion,
(h)
task
completion,
(i)
abnormal
termination
(j-m)
The system must
provide
static
(fixed)
core
allocation
4
for:
(j)
program
expansion,
(k)
I/0
buffers,
(I)
common
areas,
(m)
subtcsk
execution.
(n-q)
The
system must
provide
dynamic
core
allocation
for:
4
(n)
program
expansion,
(s-,)
I/0
buffers,
(p)
common
areas,
(q)
subtask
execution.
(r)
The system must
permit
common
(shared)
core
alloca-
5
tion
between
tasks
of
the
same
job
step.
(s)
The
system must
permit
common
core
allocation
bet-
5
ween
job
steps
of
a
job.
(t)
The
system must
permit
common
core
allocation
bet-
6
ween
jobs.
118
1.1.2.1
CORE
STORAGE
ALLOCATION
Reference:
1.
This
method
is
generally
used
in
most
basic
multiprogramming
systems
and
in
small
to
medium
scale
extended multiprogramming
systems.
It
may
also
be
f
ijnd
in
systems
which
support
concurrent operation
of
different
environments
e.g.,
real-,time
processing
in
a
foreground
partition
and
batch
processing in
a
background
partition.
2.
These
methods
of
allocation
occur in
most
time-sharing
systems
as
well
as
in
meidum
to
large
scale
extended
multiprogramming
systems.
3.
If
core
is
allocated at
the
partition
level,
this
criterion
is
unnecessary.
4.
The
previous
level
of
criteria
specification
(1.1.2)
will
have
determined
whether
a
static,
dynamic,
or combined
method
of
core
allocation
will
be
employed.
In
certain
instances
it
becomes
necessary
for
a
program
to expand
above
core
estimates
during
operation
due to
a
particular
data
test
or
tested
option.
Core
for
1/O
buffers
is
required
in
order
to
efficiently
transfer
data
or
inFormation
between
core
and
external
devices
without
continually
interfering
with
program
execution.
Core
for
common
areas
is
used
when
there
is
more
than
one program
depend-
ent
upon
previously
acquired
data
or
information.
Core
for
subtask
execution
is
derived
from
the
possible
scheduling
of
a
subtask
by
a
task
in
execution.
5.
This
criterion
is
highly
desirable
for
most
batch
processing
systems.
6.
This
criteria
should
only
be
specified
if
it
has
been
determined
that
it
is
desirable
for
multiple
jobs
to
communicate'and
pass
data
to
each
other.
This
solution
avoids
the
problem
of
passing
data
via
secondary
storage
files.
It
is
most
frequently
used
in
teleprocessing
applications
where
the
message
reader
and
message
writer
pass
and
receive
data
from
the
processing
program
via
a
core
buffer
-ther
than
secondary
storage
areas.
119
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.2.1
CORE
STORAGE
ALLOCATION
(cont'd.)
(u)
The
system
must
provide
storage
protection
against
7
unauthorized
program
access.
(v)
The
system
must
provide
storage
write
protection.
7
(w)
The
system
must
provide
storage
read
protection.
7
L2
120
K
'liQUIPFMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
E
tended
1.1.2.2
I/O
DEVICE
ALLOCATION
(a-b)
The
system must
provide
the
following
types
of
allocation:
(a)
physical
I/0
devices,
2
(b)
logical
I/0
files
(c-f)
The
systeo,.
must
permit
device
specif
cation
at
the
following
levels:
(c)
physical
device
reference,
3
(d)
symboiic
device
reference,
4
(e)
generic
device
reference
(e.g.,
tape,
5
disk,
etc.),
(f)
access method
reference
(e.g.,
seq-
6
uential,
direct
access).
(g)
The
system
must
provide
exclusive
allocation
of
devices/files.
(h)
The
system
must
provide
shared
allocation
of
devices/
7
files.
(i-m)
!/0
devices
must
remain
allocated
until:
(i)
explicit
deallocation,
8
(j)
job
completion,
(k)
job
step
completion,
(I)
task
completion,
(M)
abnormal
termination.
8
122
1.1.2.2
I/O
DEVICE
ALLOCATION
Reference:
1.
It
is
generally
advisable
for
a
multiprogrammed
system
to
control
the
allocation
of
physical
I/O
devices
and
logical
I/O
files.
In
this
way.
better
device
utilization
may
be
achieved
by
assigning
unused
devices
to
any
program
requiring
one.
The
system
controlled
allocation
of
logical
I/O
files
is
necessary
if
file
security
access
controls
are
to
be
implemented.
2.
These
are,
in
order,
increasingly
preferred
methods
of
allocating
I/O
devices
in
a
multiprogrammed
environment.
3.
This
method
is frequently
used
in
real-time
and
communication
processing
systems.
4.
Symbolic
device
references
are
particularly
desirable
when
device
substitution
and
reconfiguration
features
are also
implemented.
5.
Generic
device
referen-e
allows
the
system
to assign
any
device
within
a
device
group to
a
program
for
usage
e.g.,
any
tape
drive,
any
disk,
etc.
This
technique
greatly
increases
system
utilization
because
the
OS
can
assign
devices
that
it
knows
are not
in
use.
6.
The
access
method
reference
technique
is
considered
one
step
above
generic
reference in
that
the
program
merely
states
the requirement
for
either
a
sequential
or
direct
access
device
and
the
system
does
the
rest.
This
method
of device
reference
allows
greater
system
control
of
devices
and
greater
utilization
of
devices.
7.
This
method
is
desirable
in
most
time-sharing
and
extended
multi-
programming
systems.
8.
This
crilerion
shouid
be
specified
if
dynamic
allocation
is
specified.
123
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.2.3
COMMON
ROUTINE
ALLOCATION
(a-c)
The
system
must
support
the
following
routine/module
I
types:
(a)
non-reusable,
(b)
serially
reusable,
(c)
reentrant.
(d-g)
The
system
will
allow
common
routines
to
reside
in
2
the
following
areas:
(d)
transient
execution
area,
3
(e)
permanent
execution
area
within
the
supervisor, 4
(f)
problem
program area,
(g)
independent
partition.
4
124
1.1.2.3
COMMON
ROUTINE
ALLOCATION
Reference:
1.
Programs
or
subroutines
that
can
be
used
by
more
than
one
program
are
frequently
designed
to
be
loaded
and
executed
when
needed
rather
than
incorporated
as
a
part
of
the
executing
program
during
the
binding
process.
These
routines
may
be
loaded
into
a
specially-
designated
transient
execution
area,
into
any
available
area
of
core the
executing
program
can
find,
or,
if
used
frequently
enough,
made
a
part
of
the
resident
system.
Allocation
of
these
routines
to
requests
is
almost
always
dynamic
rather
than
static.
There
are three
types
of
subroutine
organization
that
require
differ-
ent
allocation
procedures.
Non-reusable
subroutines
are
subroutines
that
must
be
loaded
"fresh"
each
time
a
request
is
made
for
the
routine.
Serially
re-usable
routines
need
not
be
reloaded; however,
the
routine,
because
of
possible
modification
of
constants
or
inst
ictions,
can
only
be
used
by
one program
at
a
time. Re-entrant
routines
rnay
be
used
by
any
number
of
executing
programs
simultaneously.
Thus,
allocation
of
re-entrant
routines
is
straightforward,
whereas
serially
reu-able
routines
must
have
a
lock/unlock
facility
which
:imits
their
assignment
to
a
sinle
program
at
a
tme.
2.
While
frequently
employed
for
evaluatior,
these
criteria
are
rarely
specified.
3.
A
transient
execration
area
is
an
area
set
aside
to
hold
one
or
more
routines
that
norma!ly
reside
on
secondary
storage
and
which
are
loaded
only
when
actually
required.
This
technique
is
frequently
employed
for
executive
control
routines
with
low
utilization
rates
to
provide
more
available
main storage
for
application
programs.
The
technique
may,
however,
also
be uscd
by
application
programs
to
minimize
their
main
storage
requirements.
4.
This
method
frequently
occurs
in
m-ultiprogramming
systems
for
common
routines
which
have
a
hitih
utilization
rate.
Althojgh
this
method
requires permanent core,
it
is
offset
by
fewer
requests
for
transient
routines.
125
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.3.1
LOADING
CONTROL
(a-c)
The
system
must
allow
loading
to
be
initiated
by:
(a)
control
statement
reference,
1
(b)
explicit
program
reference,
2
(c)
implicit
program
reference.
3
(d-f)
The
system
must
provide
facilities
for
the
compaction
4
of
fr-gmented
core, to
be
initiated:
(d)
at
termination
of
each
task,
(e)
when
dictated
by
priority
requirements,
(f)
when
directed
by
the
operator,
(g)
periodically
by
the
system.
(h)
The
system
must
provide
automatic
overlay
loading.
5
(i)
The
system
must
provide
directed
overlay
loading.
5
126
1.1.3,1
LOADING
CONTROL
Reference
1.
This
criterion
should
be
specified
f,.
a
batch
processing
system.
2.
This
method
is
frequently
used
in
processing
systems
that
support
overlay
loading.
In
this
way
the
overlay
segment
in
residence
initiates
the
loading
of
the
next
overlay
segment.
3.
This
technique
is
geneially
used
with
segmented
or
paged
program
structures.
If
an
executing
program
tries
to
transfer
control
to
or
access
data
from
a
non-resident
segment
or
page,
an
intei..upt
is
generated,
the
referenced
segment
or
page
is
loaded,
and the
in-
struction
is
re-issued.
4.
While
frequently
employed
as
an
evaluation
measure
this
criterion
is
rarely specified.
However,
if a
multiprogrammed
system
is
to
utilize
core
to
the
maximum
extent
possible
compaction
is
a
require-
ment and
should
be
considered
for
both
specification
and
evaluation.
If
the
system
supports
a
paged
mode
of
memory
allocation,
however,
compaction
is
generally
unnecessary.
Compaction
at
the
te.mination
of
each
task
permits
maximum
ulili-
zation
of
core
but
increases
system
overhead
tremendously.
Com-
paction
dictated
by
priority
requiiements
will
minimize
compaction
overhead
while
making
it
more
likely
that
a
priority
program
can
operate
without
causing
the
termination
of
other
programs.
Oper-
ator directed
compaction
is
better
than
none
at
all;
however,
it
tends to
be
sporadic
and
may
not increase
core
utilization
to
a
s.ignificant
extent.
Some
systems,
to
minimize
overhead,
only
initiate
core
compaction
periodically
on
a
time
or
program
termina-
tion
count
interval.
5.
This
criterion
should
be
considered
for
specification
if
the
system
is
to
use
overlays.
In
automatic
overlay
loading
this
function is
entirely
transparent
to
the programmer and
con
be
likened
to
a
virtual
memory
concept.
In
directed
overlay
loading
the
overlay
in
residence
must
initiate
the
loading
of
the
next
overlay
and
this
load
initiation
is
prepared
externally
and
becomes
part
of
the
program
structure.
127
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.3.2
SWAPPING
CONTROL
1
(a)
The
system
must
allow
temporary
program
expansion
2
into
an
addi
"anal
area
of
core
by
rolling-out
lower
priority
programs.
(b)
The
system
must
allow
programs
to
time
share
core
3
storage.
128
1.1.3.2
SWAPPING
CONTROL
Reference:
1.
Swapping
is
a
method
of
sharing
main
storage
between
several
programs
by
maintaining
each
program
and
its
status
on
secondary
storage
and
loading
each
one
into
main storage
for
a limited
time
interval.
Certain
systems
use
paging
as
a
swapping
technique
in
which
pre-defined
program
segments
(pages)
are swapped
in
and
out
of
core.
This
is
rarely
specified
unless
the
system
hardware
configuration
is
such
that
most
pro-
grams
will
require
loading
or
swapping
from
IAS
in
which
case
paging
should
be
considered
for
specification.
If
paging
is
specified
then
it
should
also
be
specified
that
the
OS
will
allow
multiple
pages
with
the
page
size
entirely
dependent
upon
the
architecture
of
the
IAS
device
to
be
used.
2.
This
method
is
frequently
used
i,,
processing
systems
that
support con-
current
modes
of
oFeration
e.g.,
real-time
foreground
and
batch
background.
3.
This
function
frequently
occurs
in
small
to
medium
size
time-sharing
processing
systems.
129
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.3.3
STRUCTURE
CONTROL
1
(a-d)
The
system must
support
the
follcwing
types
of
2
program
structure:
(a)
simple,
(b)
overlay,
(c)
paged,
(d)
dynamic.
130
1.1.3.3
STRUCTURE
CONTROL
Reference:
1.
These
criteria
are
generally
employed
for
evaluation,
rather
than
specification.
In
some
isolated
rircimstances,
however,
it
may
be
necessary to
specify
the
program
structuring technique.
2.
A
simple
program
structure
corsists
of
a
single
module
occupying
a
fixed
amount
of
main
storage.
An
overlay
program
allows
for
repeated
use
of
the
same
blocks
of
core
storage
during
different
stages
of
program
execution.
Thus,
the
overlay
program
is
segmented
and
each
segment
is
loaded
as
it
is
required.
Paged
and
dynamic
structures are
considerably
more
sophisticated
in
scope
and
are
common
only
in
thE
larger
multiprogrammed
and
time-
sharing
environments.
Dynamic
IL
4ing
allows
a
relocatable
module
to
be
loaded
into
main
storage
upon
a
request
for
that
module
by
an
executing
program.
It
differs
from
an
overlay
structure
in
that
the
area
of
main storage
need
not
be
prespecified,
nor
does
the
module
necessarily replace
or
overlay
an
existing
program
segment.
One
of
the
major
problems
with
dynamically-loaded
F
"qrams
is
that
the
process
creates
unused
core
fragments
when
all
dynamically-loaded
programs
do
not
teminate
concurrently.
Consequently,
some
systems
relocate
all
active
progrum
segments
to
a
contiguous
core
storage
area
prior
to
dynamically
loading
another
module.
Others
only
compact
storage
when core
becomes
exhausted
or
when
certain
high
priority
proproms
require
loading.
When
storage
is
divided
into
pages
the
program
loading
function
may
consist
o.'
simply
loading
all
required
main
storage
pages,
or
it
may
entail
preparing
the
system
for
a
process
called
paging.
Paging
requires
a
fast
access
secondary
storage
device
(usually
a
magnetic
drum)
as
a
supplement
to
main
storage.
Both
the
secondary
storage
device
and
main storage
are
configured
to
the
same
fired
page
size.
A
program resides on
both
devices;
the
page
of
the
program
containing
the
instruction
sequence
currently •
xecuting
is
in
main
storage,
many
of
the
other
pages
are
in
secondary
storage.
Whenever a
page
not
in
main
storage
is
referenced
for
data
or
to
transfer
control,
a
page
area
is made
ready
in
main
storage
--
perulnos
by
moving
an
in-core
page
to
secondary
storage
--
and
the
required
page
is
read
in.
A
page
map
is
maintained
indicating
the
physical
page assignments
(main
storage
or
secondary
storage)
and
the
actual
storage
address
(core
locations
or
track).
This
map
is
consulted
to resolve
addresses
when
accessing
the
data
or
instructions
within
the
page.
In
many
systems,
this
address
resolut;on
is
accomplished
through
hardware
circuitry;
in
others,
it
must
be
accomplished
via
software.
131
REQUIREMENTS
OPERATIN(
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
EYtended
1.1.4.1
DISPATCHING
CONTROL
(a)
The
dispatching
algorithm
must
be
modifiable
at
system
generation
time.
(b) The
dispatching
algorithm
must
be
modifiable
by
the
operatcr.
(c)
The
system
must
allow
up
to entries
in
each
dispatch
queue.
2
1.IA..2
EVET
N.
SYNCHROiIIZATION
(a-d)
The
system must
recognize
the
following
events:
(a)
I/O
completion,
(b)
tme
interval
timeout,
(c)
program
completion/abnormal termination,
(d)
unsolicited
key-in.
132
1.1.4.1
DISPATCHING
CONTROL
Reference:
1.
The
dispatching algorithm
is
the
heart
of
every
multiprogramming
and
time-sharing
system.
This
algorithm
controls
the
allocation
of
processor
time
to
each
contending
task
and
is,
with
the
scheduling
algorithm,
the
factor
determining single
job
throughput.
Modifica-
tions
to
the
algorithm,
while
desirable,
should
only
be
incorporated
after
a
comprehensive
analysis
of
system
performance.
2. In
basic
multiprogramming
the
number
of
entries
in
the
dispatch
queue
is
equal
to
the
number
of
partitions.
In
extended multiprogramming
the
number
of
entries
in
the
dispatch
queue
is
equal
to
the
number
of
possible
core
resident
jobs.
In a
time-sharing
processing
system
the
number
of
entries
in
the
queue
is
equal
to
the
number
of
users.
1.1.4.2
EVENT
SYNCHRONIZATION
Reference:
1.
Event
synchronizatio,.
is
the
process
oi
delaying
task
execution
until
some
specified event
occurs
or
the
process
of
triggering
a
task
upon
the
occurrence
of
a
specified
event.
The
most
common
types
f
events
which
may
deiay
or
initiate
task
execution
are
!/0
comple-
tions,
selected
tir,
intervals,
subtask
completions,
and
unsolicited
key-ins.
Event
synchronization
may
also
be
effected
between
several
tasks
of
a
job.
One
task
may
initiate
any
number
of
subordinate
tasks
and
my
execute
concurrently
with
them.
This
main
task
may,
at
any
time,
isiue
wait
requests
whirh
will
suspend
main
task
F
rocessing
until
one
or
more
of
the
subordinate
tasks
have been
completed.
133
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.4.3
INTERRUPT
PROCESSING
CONTROL
1
(a-d)
The
system must
provide
the
following
interrupt
processing
options:
(a)
priority
recognition,
(b)
interrupt
masking,
(c)
interrupt
disarming,
(d)
stacked
interrupt
processing.
134
1.1.4.3
INTERRUPT
PROCESSING
CONTROL
Reference-
1.
An
interrupt,
as
the
name
indicates,
is
a
break
in
the normal
flow
of
program
execution.
An
interrupt
is
usually
caused
by
a
hardware-
generated
siqnal
such
as
an
I/0
event,
a
program
error,
a
machine
error,
or
an
operator-initiated
signal.
In
a real-time
system,
the
interrupt
levels
of
the
various
events
to
be
monitored
are
usually specified
when
the
system
is
generated;
in
general
purpose
systems,
they
are
usually
intrinsic
to
the
system
ard
may
not
be
specified.
Nor.nally,
processing
on
a
given
level
will
be
interrupted
whenever
higher
level
interrupts
occur;
interrupts
of
a
lower
level
than
the
processing
program
will
be
held
pending.
If
several
interrup~s
occur
simultaneously,
they
are
stacked
and
honored
according
to
their
priority.
Unfortunately,
in
some systems
nadequate
stack
lengths can
cause
multiple
interrupt
signals
to
be
lost.
Interrupt
acknowledgement
can
be
altered
by
disabling
interrupts
to
prevent
their
recognition
or
by
masking
them
to
defer
their
recognition.
W
,en
an
unmasked
interrupt
occurs, the
current
instruction
is
usually
allowed
to
complee
execution.
Then
the
program and
the
contents
of
Jhe
machine
registe,
are
saved
in main
storage
and
control
is
trans-
ferred
to
a
program
which
wil!
service
the
interrupt.
This
program
may
complete
execution
or
in
turn
may
be
interrupted
by
a
s'ill
higher
priority
interrupt.
When
in
interrupt
processing
pr-gram
does
complete
execution,
control
is
re'urned
to the
highest
pending
interrupt
processing
routine
or
to
thre
supervisor
dispatching routine
if
no
interrupts
are
penarnq.
135
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.4.4
PROGRAM
LIMIT
MONITORING
(a-g)
The
system must
permit
specification of
limits
for:
(a)
execution
time,
(b)
number
of input
records,
(c-e)
number
of
output:
(c)
lines,
(d)
cards,
(e)
records,
(f)
main storage
utilizatiorn,
(g)
secondary
storage
utilization.
136
1.1.-;.4
PROGRAM
LIMIT
MONITORING
Reference:
1.
Many
systems
monitor various
resources
during
job
execution
tni
insure
that
certain
specified
limits
are
not
exceeded.
Limits
are
usualy
established
for
such
elements
as
central
processor
time
used,
output
records
produced,
and
the
amount
of
main
and
secondary
storage
space
allocated.
While
installation
maximums
For
each
resource
are
normally
established
at
system
generation
time,
they
can
usually
be
overriauen
by
job
cortrol
cards.
Some
systems
automatically
cause
abnormal
job
termination
when
any
of
the
system
limits
for
a
parti:ular
job
are
exceeded.
Other
systems
permit
the
user
to
specify
other actions
to
be
exercised,
such
as
operator
or
program
notification,
whenever
the
various
limits
are exceeded.
In
some
smaller
real-time
systems,
execution
time
limits
are
not
explicitly
set;
however,
the
supervisor
maintains
a
countdown
loop
which
will
time
out
unless
it
is
periodically
reset
by
the
executing
program.
If
the
countdown
loop
times
out,
an
interrupt
is
generated
and
program
execution
terminates.
137
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.2.2.1
BUFFERING
CONTDOL
1
(a)
The system
buffering
concept
must
be
based
upon
user
2
specified
areas.
(b)
The system
must
provide
system
buffer
pools.
3
(c)
The
systen
must
permit
user
buffer
pools.
3
(d-f)
The
system
must
provide
the
following
buffering
methods:
(d)
simple
buffering,
(e)
exchange
buffering,
(f)
chained
segment
buffering.
(g)
The
system
must
permit
static
program
specification
4
of
buffer
areas.
(h)
The
system
must
allow
buffer
assignment
via
control
4
statements.
(i)
The
system
must
permit
dynamic
program
specification
4
of
buffer
areas.
138
1.2.2.1
BUFFERING
CONTROL
Reference:
1.
While frequently
employed
for
evaluation
this
criterion
is
rarely
specified.
2.
This
method
is
frequently
used
in
a
serial
processing
system
or
in
a
small
real-time
processing
system
in
which
the
user
performs
the
1/O
operations.
Buffering
based
upon
user
specified
areas
is
the
most
easily
imple-
mented
method;
however,
this
does
require
that
are-'s
of
core
be
set
aside
for
the
duraion
of
the
program.
3.
An
alternate
method
of
approaching
the
buffer
problem
is
the
use
of buffer
pools.
This
provides
an
area
of
core
that
will
always
be
used
for
bufferin9.
Thee
is
not
much
difference
between
system
buffer
pools
and
user
buffer
pools
except
by
using
system
buffer
pools
the
user
is
relieved
of
pool
handling
problems.
Some
systems
employ
both
user
and
system
buffer
pools.
4.
Static
program
speciflca)')n
of
buffer
areas
means
that
the
buffer
areas
are
set
aside
during
the
entire
execution
of
the
program.
Since
the
buffers
are
statically
assigned
there
is
no
flexibility
in
altering
the
assignment
other
than
a
piogram change.
This
technique
is
generally
prevalent
in
sma'l
scale
systems.
Control
statement
specificution
of
buffer
areas
means
that
the
buffer
will
-t
be
assigned
until
the
control
statem
nt
is
executed,
however,
it
will
main
assigned
throughout
program
execution.
This
is
a
Flexb!e
ineans
of
assigning
buffers since
tSe
control
statement
is
mod-
ifiable
input.
This
technique
is
generally
prevalent
In
medium
scale
systems.
Dynamic
program
specification
is
one
of
the
most
advanced
methods
of
assigning
buffer
areas
since
the
buffer
areas
are
only
assigned as
the
program
requires
them
and
can
usually
be
released
by
the
program
when
no
longer
needed.
This
technique
is
highly
desirable
in
large
scale
systems.r
139
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
In;tial
Extended
1.2.2.2
DATA
CODE
TRANSLATION
(a)
The
system
must
provide
data
compaction/expansion
1
facilities.
(b)
The system
must
provide character
code
conversion
2
facilities.
(c)
The
syst
'
must
provide
device
code
conversion
2
facilities
(e.g.,
paper
tape
codes,
teleprocessing
codes).
140
1.2.2.2
DAi'A
CODE
TRANSLATION
Reference:
1.
Th
criterion
should
be
considered
for
specification
for
all
processing
systems
that
will
be
processing
large
amounts
of
data,
since
this
method
wi;l
decrease storage
and
transmission
requirements.
2.
This
criterion
is
highly
dependent
upon
the
types
of
hardware
to
be
used,
however,
it
should
be
considered
for
c,'
processing
systems.
141
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.1.1
SYSTEM
INITIALIZATION
(a)
The
system
must
permit
modification
of
partition
s;zes.
1
(b)
The
system
must
permit
assignment/modification
of
1
partition
priorities.
(c)
The
system
must
permit
assignment/modification
of
2
time-slicing
specifications.
1.3.1.2
SYSTEM
RESTART
(a)
The
system must
schedule
installation
restart
programs.
1
(b)
The
system
must
automatically
restart
jobs
which
2
were
in
a
state
of execution at
the
time
the
system
came
to
a
ha
It.
(c)
The
system
must
automatically
reschedule
queued
3
jobs.
(d)
Job
queues
must
be
restored
by
the
system
to
their
3
condition
prior
to
the
system
halt.
(e)
The
system
must
provide
manual
reconfiguration
4
procedures.
4
(f)
The
system must
provide automatic
reconfiguration
4
procedures.
142
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.4.2.1
PROGRAM
INITIATED
RESTARTING
(a)
The system
must
require
operator
consent
before
allowing
a
program
initiated
restart.
(b)
The
system
must
allow
for
the
optional
!tftation
of
operator
consent
before
allowing
a
program
initiated
restart.
1.4.2.2
SYSTEM
INITIATED
RESTARTING
(a-c)
The system
must
provide for
restart
under
the
following
conditions:
(a)
device
error
recovery,
(b)
system
error
recovery,
(C)
power
failure.
2
144
1.4.2.1
PROGRAM
INITIATED
RESTARTING
Reference:
1.
This
criterion
is
highly
desirable
for
real-time
processing
systems.
When
a
real-time
program
experiences
an
error,
reliability
factors
can
usually
determine
whether
operator
consent
is
required
prior
to
restart.
1.4.2.2
SYSTEM
INITIATED
RESTARTING
Reference:
I.
These
criteria
are
highly
desirable
for
a
real-time
processing
system
due
to
the
usual
requirement
for
continuous
support.
These
criteria
can
also
be
quite
beneficial
for
batch
and
time-sharing
processing
systems
as
a
means
of
avoiding
total
system
re-initiolizatior.
2.
The
capability
of
the
OS
to
support
this
requirement
is
quite
depend-
ent
upon
a
sstem
hardwares
non-destructive
memory
capability.
145
REQUIREMENTS
O"R
ATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.4.2.3
DEVICE
REPOSITIONING
(a)
The
system
must
re-establish
teleprocessing
line
1
connections.
(b)
The
system
must
retransmit
interrupted
telecommuni-
2
cations
mrsc,;s.
(c)
The
system
must
reposition
temporary
files. 3
(d)
The
system
must
reposition
permanent
files.
3
(e-f)
The
system
must
reposition
the
following
devices:
(e)
sequential
access
devices,
(f)
direct
access
devices.
4
146
1.4.2.3
DEVICE
REPOSITIONING
Reference:
1.
This
criterion
is
highly
desirab!e
for
systems
supporting teleprocessing.
Usually
it
is
better
to
have the
system
perform
this
function
than the
operator
since the
connection
can
be
derived
from a
predefined
proc-
edural
matrix
and
can
be
performed
much
faster
and
accurately
by
the
system.
2.
This
criterion
should
be
specified
for
all
systems
supporting teleprocessing
to
assure
that
no
messages
are
lost
due
to
system
failure.
3.
This
criterion
should
be
considered
for
systems
containing
files
on
sequential
access
devices.
4.
The
specification
of
this
criterion
is
usually
not required
except
in
situations
where
direct
access
device
commands
do
not
perform
an
automatic
positioning
function.
IA7
3.3
Requirements
Checklist
-Part
11 -
Systemn
I4nagement
Functions
The
following
subsections present
specificationi
and
evaluation
criteria
for
"he
nont-real-tlime
cmponents
of
the
operating
syrstemn
which
support
and
main-
tain
both
systerr
and
application
programs.
3.
3.
1
First
Level
of
Detail
(Part
11
-
System Maonagement
Functions)
This
subsection covers
the
fo!lowing
first
level
system
management
func-
tionis:
1.0
OPE
RAT
ING
SYSTEM
M
ANAG
EME
NIT
2.0
PROGRAM
MAINTIENANCE
3.0
COMPILER
INTERFACES
4.0
IAANAGEMAENT
SUPPORT
UTILiTIES
149
REQUIREMENTS
OPERATING
SYSTEM
REQU!REMENTS CHECKLIST
Reference
Initial
Extended
1.0
OPERATING
SYSTEM
MANAGEMENT
1
(a)
System
generation
must
be
provided.
2,4
Vb
System
maintenance
must
be
provided.
3,4
150
1.0
OPERATING
SYSTEM
MANAGEMENT
Reference:
I.
Operating
system
management
routines
are
provided
by
all
systems
to
enable
each
installation
to
generate
and
maintain
a
version
of
the
computer
operating
system.
2.
System
generation
is
the
process
of
tailoring
and
adapting
a
generalized operating
system
to
the
specific
machine
configuration
and
operational
requirements
of
an
installation.
The
generalized
master
operating
system
is
normally
provided
by
the
vendor
to
every
installation.
The
master
system
contains
all
the
operating
system
routines
required
for
any
allowable
system
configuration
as
well
as
the
vendor-developed
optional
routines
that
might
be
desired
by
a
particular
installation.
3.
System
maintenance
allows
an
installation
to update
the
operating
system
in
response
to
changes
in
the
operating
environment
or
to
changes
of
the
programs
within
the
operating
system
itself.
The
latter
category
is
generally
related
to
vendor-supplied
updates
which
are
distributed
periodically.
Consequently,
this
type
of
maintenance
tends
to
be
performed
fairly
regularly
and
generally
neces-
sitates
suspension
of
all
other
processing
activity
until
the
update
is
complete.
Extensive
updates
to
the
system
may
involve
a
total
regeneration
of
the
system;
however,
minor
changes
may
frequently
be
effected by
simply
replacing
selected
system
modules.
4.
This
criterion
should
be
specified for
all
processing
systems.
151
REQUIREMENTS
OPERATiNG
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.0
PROGRAM
MAINTENANCE
1
(a)
The
system must
provide
facilities
for
program
2
library
maintenance.
(b)
The
system
must
provide
maintenance
facilities
for
3
system
control
card
libraries.
(c)
The system
must
provide
facilities
for
generating
4
executable
program
modules.
152
2.0
PROGRAM
MAINTENANCE
Reference:
1.
Program
maintenance
facilities
support
the
maintenance
and
modification
of
appli-
cation
programs
within
the
framework
of
the
system. These
facilities
are
distinct
from
the
support
features
that
an
application
program
can
call
upon
when
executing;
rather
these
facilities
treat
the
application
program
as
a
product
by
itself.
2.
Many
systems
provide
capabilities
for
maintaining
one
or
more
program
types
in
indexed
libraries.
In
general,
a
program
library
is a
collection
of
routines
or
instruction
sets
which
are
all
represented
at
the
same
code
level.
The
code
levels
generally
found
in
contemporary
operating
system
libraries
are.
macro
code,
source
program
code,
relocatable
program
code,
executable
code,
and
job
control
procedures.
3.
This
function
is
highly
desirable
for
a
batch
processing
system.
When
a
great
number
of
system
control
cards
are
required
for
the
execution
of
a
job,
it
is
best
for
the
system
to
catalog
these
control
cards
into
a
named
sequence.
This
named
sequence can
then
be
referenced
by
one
control
card
in
the
input
stream
rather
than
continually
inserting
multiple
control
cards
in
the
input
stream.
4.
This
criterion
should
be
specified
for
all
processing
systems.
153
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.0
COMPILER
INTERFACES
(a-c)
The system
must
provide
the
following
executive
rou-
2
tine
support
for
compilers:
(a)
recognition of
compiler
parameters
on
OS
control
cards,
(b)
system
maintained
compiler
communica-
tion
tables,
(c)
program
testing/debugging control.
(d-f)
The
system
must
provide
the
following
types
of
3
libraries
in
support
of
compilers:
(d)
source
program
libraries,
(e)
macro
libraries,
(f)
subroutine
libraries.
kg-i)
The
system must
provide
the
following
system
utilities 4
in
support
of
compiler
language
programs:
(g)
sort/merge
programs,
(h)
peripheral
conversion
programs,
(i)
data
management
system
programs.
154
3.0
COMPILER
INTERFACES
Reference:
1.
Those
operating
system
functions
that
provide
supporting services
to
the
system
language
compilers
are
the
least
standard
of
all
operating
system
functional
categories.
Furthermore,
differences
can
not
be
directly
attributed
to the
size,
orientation,
or
sophistication
of
the
operating
system.
2.
Many
operating
systems
grant
the
system
compilers
selected
privileges which
are
not
available
to
other
non-super.isory
programs.
For
example,
several
systems
allow
the
compiler
to
use
communication
tables
within
the resident
executive
for
passing
parameters and
storing
specifications
about the
compila-
tion.
Many
systems
also
providf, special
job
control
cards
for
compilers
which
include compilation
parometerb
along
with
normal
operating
system
parameters.
In
some
cases
the
executive
systen,
may
actually
decode
these parameters
and
place
them
in
an
appropriate compiler
communication
table.
Other
types
of
executive
routine
support are found
in
those
systems
that recognize
uniquely
formatted
compiler
input/output files
and
provide
non-standard
input
and
output
symbionts
for
processing
them.
Finally,
some
systems
also
provide
a
series
of
compi!ation
error
codes
which
can
be
used
as
conditional
scheduling
parameters
by
subsequent
tasks and
steps
within
the
job.
3. A
few
systems
provide
and
maintain
unique
libraries
for the
exclusive
use
of
the
system
compilers.
These
libraries
may
take
the
form
of
compiler
source program
libraries,
macro
statement
ibraries,
or
compiler
subroutine
libraries.
In
-ieneral,
the
same
maintenance
facilities
that
are
available
for
other
system
libraries
are
available
for
compiler-oriented
libraries.
4.
Some
compilers
have
the
capability
of
generating
linkage
sequences
to
selected
system
utility
programs
in
order
that
these
facililies
can
become
available
to
the
compiler
language
programmer.
For
example, COBOL
compilers
commonly
allow
references
to
the
system
sort
and
merge
functions.
Other
utility
iunctions
that
can
be
invoked
in
some
systems
are
the
data
management
and
data
handling
support
functions.
155
REQUIREMENTS
OPERATING
SYSTEM
m
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
4.0
MANAGEMENT
SUPPORT
UTILITIES
(a)
The
system
must
provide
facilities
for
peripheral
2
device
support.
(b)
The system
must
provide
facilities
for
simulation
3
routines.
(c)
The
system
must
provide
facilities
for
performance
4
measurement
routines.
(d)
The
system must
provide
facilities
for
stand-alone
5
utilities.
156
4.0
MANAGEMENT
SUPPORT
UTILITIES
Reference:
1.
The
muiagement
support
utilities
are
primarily
for the
use
of
the
system
manager
rather
than
the
average
user.
Utility
functions
provided
for
normal
users
are
listed
in
Part
III,
Data
Manipulation
Functions,
Section
2.0.
2.
This
function
shouid
be
considered for
specification
for
all
processing
systems.
3.
This
function
is
highly
desirable
in
a
real-time
processing
system
or
a
system
that
supports
teleprocessing
oriented
programs.
Certain
real-time
programs
can
only
be
invoked
by
the
occurrence
of
specific
interrupts.
It
may
be
difficult
to
provide
the
actual interrupt
when
these
programs
must
be
tested.
Consequently,
a
capability
to
simulate
the
occurrence
of
the
interrupts
and
to thereby
invoke
the
program
permits
much
greater
flexibility
in
program
testing.
Similarly,
an
exhaustive
test
of
communication
and
line
support
programs
might
require
a
scenario
so
complex
that
it
could
not
be
performed
from
available
support
terminals.
Agaii,,
the
capability
to
simulate
the
arrival
of
a
series
of
communication
messages
provides
a
needed
testing
capability.
Many
of
these
routines
might also
be used
by
the
system
manager
to
test and
validate
the
operating
system
itself.
4.
Systems
measurement
routines enable
the
system
manager
to
obtain various
statistics
ubout
the
operational
use
of
the
system.
Typical
statistics
include
job
through-put
times,
file
or
device
utilization
figures,
and
the
identification
of bottleneck
conditions.
In
addition,
there
are
a
few
systems
that
provide
visual
displays
of
current
and past
system
utilization
reflecting
error
statistics
on
all
configured
devices,
channel
usage,
memory
allocation,
programs
in
core,
programs
swapped
out
of
core,
and processor
time
consumed
by
each
program
at
that
point
in
time.
5.
These
routines
are
primarily
used
when
the
system
has
failed
and
normal
diagnostic
routines
are
incapable
of
restarting
the
system.
Two
types
of
routines
are
provided.
The
first
type includes
those status
display
routines
which
produce
core
dumps,
file
dumps,
and
dumps
of
selected
diagnostic
logout
areas.
These
dumps
are presented
for
interpretation
by
a
hardware
or
software
engineer
to
determine
the
cause of
the
failure.
The
second
type
consists
of
recovery
support
routines
which
enable
the
system
to
reconstruct
much
of
its
pre-failure
environment
and
toreinitiote
processing
b,
rebuilding
selected
queues,
reloading
various
program,'.
and
restarting
check-
pointed
programs.
The
recovery
support
functions
are
most
often
found
in
systems
oriented
to
supporting
real-time
or
communication-based
processing.
157
3.3.2
Second
Level
of Detail
(Part
II -
System
Management
Functions)
This
subsection
covers the
following
second
level
system
management
func-
tions:
1.1
SYSTEM
GENERATION
1.2
SYSTEM
MAINTENANCE
2.1
LIBRARY
AND
DIRECTORY
MAINTENANCE
2.2
LOAD MODULE
GENERATION
4.1
PERIPHERAL
DEVICE
SUPPORT
4.2
SYSTEM
SIMULATION
ROUTINES
4.3
SYSTEM
MEASUREMENT
ROUTINES
4.4
STAND-ALONE
UTILITIES
159
REQUIRE'VkENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1
SYSTEM
GENERATION
(a-c)
The
system
must
support
the
following
types
of
gener-
I
ation:
(a)
complete
system
generation,
(b)
nucleus
generation,
(c)
processor
library
generation.
(d-e)
The
system
must
support
the
following
met:hods
of
2
performing
system
generation:
(d)
interactive
macro
instructions,
(e)
pre-defined
control
statements.
(f-i)
The system
must
permit
specification
of:
3
(f)
memory
partitions,
(g)
available
resources,
(h)
number
of
interrupts,
4
(i)
interrupt hierarchy.
4
(i-k)
The
system must
support
specification
of
scheduling
definition
through:
(j)
priority
levels,
5
(k)
scheduling
algorithm.
6
(I-p)
The
system must
support
the
following
system
specifi-
3
cations:
(I)
file
specifications,
7
(m)
interrupt
options,
(n)
accounting
options,
(O)
error
recovery
procedures,
8
(p)
size
of
dynamic
core
allocation
pool.
160
1.1
SYSTEM
GENERATION
Reference:
I.
In
a
medium
to
large
scale
c-perating
system,
it
is generally
better
to
perform
nucleus
generat;on
and
processor
library
generation
as
separate
phases
rather
than
as
a
single
step.
However,
smaller
systems
normally
combine
these
two
phases
into
a
single
complete
system
generation
package.
2.
The
use
of interactive
as
opposed
to
pre-defined
control
statements
is
a
matter
of
personal
preference.
Either
method
is
an
accepfable
way
of
perfo,-ming
system
generation.
The
only
environment
where
interactive
techniques
might
prove
more
beneficial
is
in
the
"super-systems"
such
as
CP-67
which
permits
several
subordinate
operating
systems
to
time-share
the
computer.
Since
each
user
is
then responsible
for
generating
the
operating
system
he
will
use,
the
interactive
approach
might
prove
handier.
3. The
greater
the
number
of
speci'ication
options,
i,+e
better
a
general
purpose
system
car)
be
tailored
to
a
particular installation's
requirements.
4.
This
criterion
is
highly
desirable
for
a
real-time
processing
system.
5.
This
technique
is
normally
used
for
real-time
processing
systems.
6.
This
technique
is
normally
used
for batch
processing
systems.
7.
If
the
system
is
to
support
applications
that
perform
file
manipulation,
then
the
specification
at
system
generation
of
such
items
as
file
sizes,
privacy
codes,
maximum
file
tracks,
maximum
file
counts,
etc.
are
important.
8.
In
a
facility
that
is
supporting
different
environments
the
method
of
error
recovery
used
may
vary
depending
upon
the
environment
in
which
the
error
occurred.
161
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
11
SYSTEM
GENERATION
(cont'd.)
(q-s)
The
system must
recognize
the
following
specification
relative
to
users:
(q)
authorL
A
users,
(r)
priority
designations,
(s)
privacy
codes.
(t)
The system
must
have the
capability
to
incorporate
9
user-developed
routines.
(u-x)
The
system must
provide
the
following
support
systems
9
(u)
compilers,
(v)
utility
programs,
(w)
data
management
systems,
(x)
assemblers.
(y)
The
system must
provide
the
capability
to
specify
9
default
options.
162
i
l
SYSTEM
GENERATION
(cont'd.)
Reference:
9.
This
feature
is
highly
desirable
for
most
batch
processing
and
time-sharing
installations.
163
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.2
SYSTEM
MAINTENANCE
(a)
The
system
must
provide
dynamic
maintenance.
I
(b)
The
system
must
provide
patching
capability
for
2
system
software.
(c-e)
The
system
must
support the
following
methods
of
2
system
patching:
(c)
on-line,
(d)
temporary,
(e)
permanent.
(f-i)
The
system
must
permit
user-controlled
maintenance
3
th
rough:
(f)
new
command
definition,
(g)
command
renaming,
(h)
operand
enaming,
()
default
value
alteration.
164
1.2
SYSTEM
MAINTENANCE
Referenct
1.
This
criterion
is
highly
desirable
for
a
real-time
processing
system.
This
feature
aP.,ws
the
system
to
tcke
the necessary
steps
to
meet
a
changing
hardware
config-
uration
or to
operate
in
a
degraded
or
fall-back
mode
with
little
if
any
external
interaction.
2.
This
criterion
should
be
specified
for
all
processing
systems.
However,
the
instal-
lation
should
maintain stringent control
over
the
use
of
the
feature
and
restrict
its
use
to
system
maintenance
personnel.
3.
This
feature
occurs
in
time-sharing
processing
systems
and
provides
the
user
with
limited
system
tailoring
capabilities.
The
user
can
adapt
certain
system
features
to
best
meet
his
requirements
without
being
detrimental to
the
use
of
the
same
features
by
other
users.
165
REQUIREMENTS
OEATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.1
LIBRARY
AND
DIRECTORY
MAINTEN-
ANCE
(a-b)
The
system
mus
provide
dynamic
cataloging
support
for:
(a)
load
modules,
(b)
task/procedure
definitions.
(c-g)
The
s/stem
must
provide
static
cataloging
support
for:
(c)
load modules,
(d)
relocatable
modules,
(e)
source
modules,
(f)
macro
routines,
(g)
task
and
job
procedures.
(h-k)
The
system must
provide
the
following
utility
2
functions:
(h)
copying
libraries
or
library
elements,
(i)
renaming
library
elements,
()
allocating/deallocating/repacking
library
space,
(k)
punching/listing/displaying
library
elements.
166
2.1
LIBRARY
AND
DIRECTORY
MAIN
IENANCE
Reference:
1.
A
system
may
provide
both
static
and
dynamic
cataloging
capabilities.
Static
cataloging
requires the
explicit
execution
of
a
library
maintenance
program
to
perform the
cataloging function.
Dynamic
cataloging
permits
the
user
to
add
an
element
to
a
library
without
explicitly
invoking
a
librarian
program.
2.
These
criteria
should
be
considered
for
specification
for
all
systems
supported
by
libraries.
167
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREv ENTS
CHECKLIST
Reference
Initial
Extended
2.2
LOAD
MODULE
GENERATION
I
(a-b)
The
system
must
provide
facilities
for:
2
(a)
program
binding,
(b)
linkage
resolution.
(c)
The
system
must
support
dynamic
binding.
3
(d)
The system
must
support
static binding.
3
(e)
The
system must
provide
binder
code-altering
4
facilities.
(f-g)
The
system must
resolve
the
following
types
of
link-
2,5
age#s:
(f)
program
control
instructions,
(g)
data
field
references.
(h)
The system
must
-,ovide
an
automatic
system
library
6
scan
for
unn-solved references.
(i)
The
system
must
provide
a
system
library
scan
for
6
unresolved references
as
a
user
option.
168
2.2
LOAD
MODULE
GENERATION
Reference:
1. In
most
systems,
capabilities
exist
to
..
ombine
(bind)
the
object
modules
produced
by
various
language
compilers
with
subi
outines
and
other
object
modules
to
pro-
duce
a
single
program.
2.
This
criterion
should
be
specified
for
all
processing
systems.
3. In
dynamic
binding
the
system
performs
the
binding
function
at
the
command
of
an
executing
task;
in
static
binding, binding
is
performed
as
an
"off-line"
step
during
program
development.
4.
This
criterion
is
frequently
desirable.
It
permits
patches or
altered
code
to
be
inserted
in
an
object
module
during
the
binding
process.
While
this
could
be
done
by
reassembly
or
recompilation,
it
will
be
more
economical to
make
small
corrections
at
the
binding
stage.
5.
It
is
quvite
likely
that
there
will
be
a
certain
amount
of
interaction
or
branching
between
different
modules
of
a
linked
job.
In
order
for
the
programs
to
operate
properly
thesc
areas
of
control
must
be
defined
and
resolved
during
load
module
generation.
If
any
of
the
modules
to
be
linked
refer
to
data
fields
within,
or created
by
oher
modules,
or
within
existing
library
files,
"ien
the
linkage
program should
also resolve
these
references.
6.
During
the
linkage
phase
of
program
module
generation,
certain
references
may
be
made
to
items
that
are
external
to
the
system
and
reside
in
a
system
library.
Unless
all
library
elements
are
specifically
included,
some
references
to
system
library
routines
may
be
unresolved.
Several
systems
provide
a
capability
to
scan
the
system
library
for
the
elements
referenced.
If
found
it
is
irncluded
within
the
composite load
module.
The
library
scan may
be
either
automatic
or
a
user
option.
169
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
4.1
PERIPHERAL
DEVICE
SUPPORT
(a)
The
system
must
provide
volume
preparation
facilities.
(b)
The
system must
provide
volume maintenance
2
facilities.
(c-f)
The
system
must
provide
support
for
the
following
3
types
of
volumes:
(c)
tape,
(d)
removable
disks,
(e)
removable
drum!,
(f)
data
cells.
4.2
SYSTEM
SIMULATION
ROUTINES
(a-b)
The
system must
provide
the
following
types
of
simula-
tion
routines:
(a)
system
facilities,
(b)
communication
facilities.
170
4.1
PERIPHERAL
DEVICE SUPPORT
Reference:
1.
This
function
is
normally
invoked
when
a
new
volume
is
to
be
added
as
a
system
component.
The
-volume
preparation
function
writes
a
standard
system
label
on
the
volume,
formats
the
records
and/or
tracks
where
track
formatting
is
required
(such
as
for disk
files),
creates
any
necessary
volume
directory
entries,
and
allocates
space
for
additional
directories,
communication
buffers,
etc. Only
upon
completion
of
this
function
is a
volume
available
for
normal
system
use.
2.
Volume
maintenance
functions
may
also
provide
diagnostic
routines
to
verify
the correctness
of
all
volumes
in
the
system.
Normally,
these
routines perform
a
surface
analysis
of
the
volume
to
detect
failing
surface
areas
and
identify
or
replace
any
defective
areas.
Certain
file
purging
functions
may
also
be
invoked
to
erase
selected
areas
on
a
volume
or
to
clear
main
or
secondary
storage.
3.
This
criterion
is
entirely
dependent
upon
the hardware
to
be used
by
the
system
and
can
only
be
specified
when
the
hardware
is
known.
4.2
SYSTEM
SIMULATION
ROUTINES
Reference:
1.
These
criteria
should
be
considered for
specification
for
most
real-time
processing
systems
as
well
as
systems
that
will
foster
large development
effort-.
The
system
facilities
to
be
simulated
would
be
such
items
as
I/C
activity,
interrupts,
etc.,
while
the
communication
facilities
simulated
would
consist
of
such
items
as
mess-
age
transmission,
receipt,
etc.
171
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLISi
Reference
Initial
Extended
4.3
SYSTEM
MEASUREMENT
ROUTINES
(a-b)
The system
must
support
the
following
measurement
concepts:
(a) sampling,
(b)
intercept.
(c-e)
The
system
must
support the
following
methods
of
2
measurement:
(c)
software,
(d)
hardwa
re,
(e)
mixed.
4.4
STAND-ALONE
UTILITIES
(a-b)
The
system
must
support
the
following
types
of
stand-alone
utilities:
(a)
status
displays,
I
(b)
recovery
support.
2
172
4.3
SYSTEM
MEASUREMENT
ROUTINES
Reference:
1.
This
function
is
highly
desirible
for
most
processing
systems
and
greatly
aids
an
instoalotion
in
tailoriro
the
system
to
best meet
operational
requirements.
While
the
sampling
concept
of
measurement
produces
utilization
factors
at
periodic
intervals,
the
intercept
Aiethod
provides
a
view
of
total
utilization
by
recording
all
functions
of
interest.
The
intercept
method
provides
a
more
comprehensive
view
of
total
system
activity;
however,
it
is
somewhat
more
time
consuming.
2.
Very
few
systems
provide
adt.quate
methods
of
measuring
system
performance.
Methods
presently
used
consist
of
software
statistics
routines,
measurement
de-
vices
built
into
the
system
hardware,
and
mixtures
of
both
methods.
4.4
STAND-ALONE
UTILITIES
Reference:
I.
This
criterion
should
be
considered
as
cQn
aid
in
performing
diagnostic
maintenance.
2.
This
criterion
is
hinhly
desirable
for
a
real-time
processing
system
and
is
quite
useful
for
most
other
processing
systems.
173
3.3.3
Third
Level
of
Detail
(Part
Ii -
System
Management
Functions)
This
subsection
covers
the
following
third
level
system
management
func-
tions:
4.1.1
VOLUME
PREPARATION
4.1,2
VOLUME
MAINTENANCE
4.2.1
SIMULATION
OF
SYSTEM
FACILITIES
4.2.2
SIMULATION
OF
COMMUNICATION
FACILITIES
4.4.1
TAND-ALONE
STATUS
DISPLAY
4.4.2
bAND-ALONE
RECOVERY
SUPPORT
175
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
4.1.1
VOLUME
PREPARATION
(a-e)
The system
must
support
the
following
record
formats:
(a)
bIocked/unblocked,
(b)
hardware
keys,
(c)
software
keys,
(d)
variable
length,
(e)
fixed
length.
(f-g)
The system
must
support
the
following
directory
2
formats:
(f)
system
specified,
(g)
user
specified.
(h)
The system
must
provide
for
directory
levels.
(i-k)
The system
must
support
the
following
types
of
space
allocation:
(i)
file
space,
3
(j)
dynamic communication
buffer
areas,
4
(k)
workspace.
(I-m)
The
system
must
provide
the
following
space
5
allocation
modes:
(I)
record,
(m)
block,
(n)
track,
(o)
cylinder,
(p)
segment.
176
4.1.1
VOLUME
PREPARATION
Reference:
1.
Blocked/unblocked
record
formats
are
used
in
processing
data
for
transmission
between
storage
devices.
The
blocking
of
records
is
used
to
improve
data
rates
and
conserve storage
space on
the
storage
device
by
reducing
the
number
of
interrecord
gaps
in
the
file.
Hardware
and
software
keys
are
usually
associated
with
direct
access
devices
as
a
form
of
record
labeling.
The
hardware
key
is
usually
a
fixed
designator
that
never
changes
while
the
software
key
is
normally
a
data
item
within
the
record.
Since
the
types
of
records
handled by
a
system
can
vary
due
to
the
data
or
applications
programs,
the
capability
should
be
provided
to
support
both
variab!e
and
fixed
length
record
formats.
2.
Directories
are
usually
provided by
a
system
to
delineate
the
files,
programs,
etc.,
available
or
active
within
the
system.
The
use
of
system
specified
directory
formats
is
the
standard
method
of
directory
organization.
The
support
by
a
system
of
user
created
directory
formats
should
only
be
considered in
special
development
activities.
3.
If
the
system
is
to
support
the
creation
of
files,
then
it
should
support
the
allocation
of
areas
for
building
or
creating
files
on
storage
devices.
4.
Systems
that
support
the
processing
of
communication
information
should
support
the
allocation
of
communication
buffer
areas,
since
the
system
frequently
may
not
be
able
to
process
this
data
as
it
occurs
but
must
hold
it
for
processing
at
a
later
time.
5.
It
is
usually
desirable
to
provide
several
levels
of
space
allocation.
Large
alloca-
tion
blocks
are
desirable
for
creating
file
and
workspace
areas.
However,
the
system
should
also
provide
a
lower
level
of allocation
equal
to
the
level
to
which
the
data
element
can
be
individually
addressed.
177
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
4.1.2
VOLUME
MAINTENANCE
(a-b)
The system
must
provide
surface
analysis
for
the
1,2
following
devices:
(a)
magnetic
tape,
(b)
direct
access.
(c-d)
The
system must
provide
for
track
replacement:
3
(c)
automatically,
(d)
by
operator
command.
(e-f)
The
system
must
provide
the
following
types
of
1
purge
routines:
(e)
erase
tape,
(f)
overwrite
direct
access.
(g)
The
system must
provide
purge
verification.
4
178
4.1.2
VOLUME
MAINTENANCE
Reference:
1.
These
criteria
should
be
pecified
for
all
systems
whose
hardware
configuration
contains
these
device
types.
2.
Surface
analysis
is a
diagnostic
function
which
determines
whethe.
a
device
surface
area
is
performing
properly.
This
type
of
verification
should
be
avail-
able
for
all
recording or
data
holding
devices.
3.
These
criteria
should
be
considered
for
specification
for
all
systems
with
the
automatic
mode
being
highly
desirable
for
a
real-time
processing
system.
During
operation
with
a
storage
track,
an
error
may
occur which
indicates
a
defective
track.
The
automatic switch
to
an
alternate
track
by
the
system
allows
continuous
execution
without
external
interaction.
If
the
system
does
not
provide
automatic
switching
to
an
alternate
track,
the
operator
should
be
allowed
to
establish
an
alternate
track
and
initialize
the
program
at
a
point
where
the
first
output
to
the
defective
track
was
performed.
4.
This
criterion
should
be
specified
for
all
processing
systems
that
perform
purging
functions.
Usually
when
a
system
supports
the
purging
of
storage
elements,
the
purging
pattern
is
read
and
checked
for
verification.
A
diagnostic
check
of
storage
areas
is
frequently
a
by-product
of
this
funct
ion.
179
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
4.2.1
SIMULATION
OF
SYSTEM
FACILITIES
(a-d)
The system
must
provide
simulation
of
the
Following
system
facilities:
(a)
I/O
device
activity,
(b)
real-time
interrupts,
(c)
error
indicators,
(d)
executive
system
functions.
2
4.2.2
SIMULATION
OF
COMMUNICATION
FACILITIES
(a-c)
The
system
must
provide
simulation
of
the
following
communication
Facilities:
(a)
message
transmission,
(b)
message
receipt,
(c)
exception
processing.
180
4.2.1
SIMULATION
OF
SYSTEM
FACILITIES
Reference:
1.
The
simulation
of
I/O
device
activity
and
real-time
interrupts
is
important
during
program
checkout
and
development.
Simulation
of
error
indications
is
also
extre-
mly
useful
to
debug
diagnostic
software
routines.
If
the
system
is
to
support
real-
time
processing,
or checkout
is
to
be
performed
during
support
of
on-line
operations,
or
if
the
executive
system
is
under
development,
then
simulation
of
system
facilities
should
be
considered.
2.
The
simulation
of
executive
system
functions
is
highly
desirable
during
the
develop-
ment
of
a
large
comprehensive
operating
or
real-time
system.
By
simuhating
these
functions,
support
programs
may
be
tested
and
debugged
without
requiring
a
completed version
of
the
operational
executive
system.
Thus,
executive
system
development
may
parallel,
rather
than
precede, support
program
development.
4.2.2
SIMULATION
OF
COMMUNICATION
FACILITIES
Reference:
1.
These
criteria
should
be
considered
for
specification
if
the
system
is
to
support
program
development
for
teleprocessing
or
any
mode
of interactive
communication.
181
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS CHECKLIST
Reference
Initial
Extended
4.4.1
STAND-ALONE
STATUS
DISPLAY
(a-e)
The
system
must
provide
stand-alone
stotus
displays
I
of
the
following:
(a)
core
storage,
(b)
hardware
registers,
(c)
Ile
storage,
(d)
logout
areas,
(e)
read-only
storage.
4.4.2
STAND-ALONE
RECOVERY
SUPPORT
(a-e)
The
system
must
provide
the
following
types
of
stand-alone
recovery
support:
(a)
rebuild
message
queues,
(b)
rebuild
system
processing
queues,
(c)
reconstrucr
on-line
file
transactions,
(d) re-initiate
suspended
processing,
(e)
re-establish
communication
line
links.
-182 j ..
4.4.1
STAND-ALONE
STATUS
DISPLAY
Reference:
1.
The
capability
to
obtain
a
stand-alone
status
display
of
each
of
these
areas
is
highly
desirable
for
maintenance
after
a
system
failure.
4.4.2
STAND-ALONE
RECOVERY
SUPPORT
Reference:
1.
Since
stand
alone
routines
for
recovery
are
only
invoked
when
all other
automatic
attempts
for
recovery
have
been
exhausted,
the
capability
presented
here
is a
last-chance
type
of
control.
Consequerty,
the
critical
elements
for
continued
processing
should
be
emphasized,
while
the
aesthetic
features
should
be
ignored.
Thus,
if
the
system
is
message
based,
then
message
queues
should
be
rebuilt
if
there
is
no
way
to
request
the
terminals
to
retransmit
incompleted
messages.
Sim-
ilarly,
if
communication
line
links
are
not
easily
restored,
then
a
routine
to
perform
this
thould
be
provided.
A
word
of
caution,
however;
these
are individual
routines
executed
independently
and
as
a
last
resort;
consequently,
the
system
will
remain
inoperational
until
all
selected
routines
have
been
executed.
If
mean
time
to
recovery
is a critical
factor,
these
routines
should
be
short
and
few.
183
3.4
Requirements
Checklist
-
Part
III
-
Data
Manipulation
Functions
The
following
subsections
present
specification
and
evaluation
criteria
for
the
components
of
the
operating
system
that
permit
the
user
to
access
and
pro-
cess
data.
3.4.1
First
Level
of
Detail
(Part
III
-
Data
Manipulation
Functions)
This
subsection
covers
the
following
first
level
data
manipulation
func-
tions:
1.0
DATA
MANAGEMENT
2.0
DATA
HANDLING
UTILITIES
3.0
SORTING
AND
MERGING
185
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST Referen
e
Initial
Extended
1.0
DATA
MANAGEMENT
(a)
The system
must
provide
file
management
facilities.
(b)
The
system must
provide
I/O
support
facilities.
(c)
The
system must
provide
an
independent data
manage-
ment
system.
186
1.0
CIAETA
MANAGEMENT
Reference:
I.
The
data
management
functions
consist
)f
file
management
facilities,
1/0
support
facilities,
and
data
management
system
facilities.
File
manage-
ment
facilities
provide
file
support
for
the
system
files
as
entities
rather
than
for
the
individual
&ra
records
within
the
files.
Support
for
the
latter
is
provided
by
the
other
two
data
management
categories.
I/O
suppcrt
facilities
enable
a
program
to
access
and
process
individual
data
records
within
the
file.
These
facilities
are
normally invoked
by
issuing macro
instructions
within
the
problem
program
and
eliminate
the
need
for
programmers
to
be
concerned
with
many
of
the
problems
of
reading
and
writ;ng
data
records.
Data management
systems
allow
a
user
with
limited
programming
interests
to
perform
certain
functions
on a
data
file,
such
as
retrieving
and
display-
irg
selected
portions
of
the
file.
Generally,
data
management
systems
are
adjuncts
to
an operating
system
and
are
more
or
less
self-contained
depending
upon
the
architecture
of
the
particular
system.
Consequently,
a
data
management
system
will
make
use
of
many
of
the
features
provided
by
other
operating
system
functions in
its
own
internal
design.
187
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Refereee
Initial
Extended
2.0
DATA
HANDLING
UTILITIES
1
(a)
The
system must
provide
facilities
for
display
support.
2
(b)
The
system
must
provide
facilities
for
peripheral
device
2
support.
(c-d)
The
system
must
provide
the
following
types
of
utilities:
3
(c)
generated
code,
(d)
interpretive
code.
!88
2.0
DATA
HANDLING
UTILITIES
Reference:
1.
The
data
handling
utility
progrums
are
generally
rather uncomplicated
routines
of
general
usefulness
to
the
installation.
Classically,
these
routines
were
independent
programs
which
were
loaded
and
executed
when
required.
However,
in
contemporary
systems
they
have
been
incorporated
into
ihe
operating
system
and
are
activated
by
a
program
call,
a
system
control
card,
or an
operator
key-in.
These
utilities
rarely
interface
direct!y
with
an
executing
program,
though
they
are
frequently included
as
a
separate
job
step
in
a multi-step
job.
2.
The
utility
r-utines
that
produce
visual
output
as
final
products
are
termed
display
facilities.
While
the
printer
is
the
most
common
output
medium,
CRT's,
console
typewriters,
etc.,
may
also
be
utilized
by
various
display
routines.
The
utility
routines
that provide
peripheral
device
support
perform
such
functions
as
volume
positioning,
media
conversion,
data
editing,
and
test
file
support.
These
criteria
should
be
specified
for
all
batch
processing
and
time-sharing
systems.
3.
While
frequently
employed
for
evaluafion,
this
criterion
is
rarely
specified.
In
general,
generated
code
routines
are
somewhat
more
complex
and
faster
in
execution
than
interpretive
code.
189
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.0
SORTING
AND
MERGING
I
(a)
The
system
must
provide
a
balanced
merge
technique.
2,3
(b)
The
system must
provide
an
oscillating
sort
technique.
2,4
(c)
The
system
must
provide
a
polyphase
sort
technique.
2,5
(d)
The
system
must
pro'ide
a cascade sort
technique.
2,6
(e)
The
system must
permit
the
use
of
sequential devices
7
for
external
workspace.
(f)
The
system
must
permit
the
use
of
random
access
devices
7
for
external
workspace.
190
3.0
SORTING
AND
MERGING
Reference:
I.
Programs
that
sort or
merge
sets
of
data
records
normally
comprise
a
part
of
the
operating
system.
The
sorting
function
takes
strings
of
unordered
records
and
sequences them
according
to
a
given
key
or
set
of
keys
within
each
record.
The
merging
function,
on
the
other
hand,
takes
separate
strings
of
records
which
have
already
been
ordered
by
keys
and produces
a
composite
ordered
output
string.
The
design
of
most
sort
programs
is
such
tha.
the
zsnordered
records
are
placed
into
ordered strings
and
then
merged.
Consequently,
a
single
program
usually
suffices
to
perform
both
functions.
2.
While
frequently
employed
for
evaluation,
this
criterion
is
rarely
specified,
however,
it
may
be
possibie
to
specify
a
sorting
technique
based
on
prev-
ious
experience
or
based
on
the
hardware
configuration
supported
by
the
system.
3. P-
balanced
two-way
merge
requires
four
tape
L,,its,
two
for
output
and
two
for
input.
In a
multiway,
balanced
merge
any
number
of
tapes
can
be
used
for
input
as
long
as
the
same
number
are
available
for output.
In
other
words,
if
there
are
"IN"
input
tapes,
then
the
tapes
rquired
for
a
multiway
balanced
merge
must
be
"2N."
4.
An
oscillating
sort
is
one
in
which
there
is
an
oscillation
between the
internal
sort
(string
creation)
and
the
merge
phase.
Internal
sort
creates
an
ordered
string
of
records
on
all
but
one
of
the
secondary
storage
work
files.
The
merge
phase
then
sequences
these
strings
from each
work
area
onto
the
remaining
work
file.
Control
is
then
returned
to
the
internal
sort
phase
to
create
niew
input
strings
on
the
N-I
work
files.
Thus
control
oscillates
between
string
creation
and
string
merging.
5.
Polyphase
sort
moes
use
of
all
available
tape
drives to
perform
a
very
high
order
of
merge.
The
order
of
merge
is
"N-I"
where
N
is
the
number
of
tapes
available.
The
input
is
distributed
onto
the
N-I
tape%.
Then
each
of
these
units
;s
read
as
the
merged
records
are
written
oti
the
"Nth"
unit.
Polyphase
sorting
is
normally
only
advantageous
for magnetic
tape.
that
have
a
hardware
"read
bac<ward"
capability.
6.
Like
polyphase
sorting,
cascade
sorting
uses
fewer
tapes
to
do
higher
order
merges.
For
example,
with
five
tapes, one
as
input,
items
are
distributed
unequacly
onto
four
drives.
Ali
four
tapes
are
then
merged
(four-w.,ay
merge)
onto
the
;nput
tape
and
since
one
of
the
tapes
has
few strings
it
becomes
empty
first.
The
merge
then
continues
as
a
.hree-woy
merge.
two-way
merge, and
finally
'-
copy
operation.
7.
ThiS
criterion
is
highly
dependent
upon
the hardware
configuration
and can
only
be
specified
when
the
hardware
configuration
is
known.
191
3.4.2
Second
Level
of
Detail
(Part
III
-
Data
Manipulation
Functions)
This
subsection
covers
the
following
second
level
data
manipulation
func-
tions:
1.1
FILE
MANAGEMENT
FACILITIES
1.2
I/O
SUPPORT
FACILITIES
1.3
DATA
MANAGEMENT
SYSTEM
FACILITIES
2.1
DISPLAY
FACILITIES
2.2
PERIPHERAL
DEVICE
SUPPORT
3.1
SORT
MODULE
DEVELOPMENT
3.2
SORT
MODULE
EXECUTION
193
I
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
I
Extended
I.1
FILE
MANAGEMENT
FACILITIES
(a-c)
The
system
must
provide
the
following
file
management
capabilities:
(a)
file
location
recognition,
2
(b)
file
security
controls,
3
(c)
backup
and
restoration
facilities. 2
1.2
1/O
SUPPORT
FACILITIES
(a-b)
The
system
must
provide
the
following
types
of
I/0
support
facilities:
(a)
physical
i/0,
(b)
logical
I/0.
194
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLST
Reference
Initial
Extended
1.3
DATA
MANAGEMENT
SYSTEM
FACILITIES
I
(a-d)
The
system must
provide
data
management
facilities
2
with
the
following
capabilities:
(a)
data
base
creation,
(b)
data
base
modification,
(c)
data
base
":>terrogation,
(d)
report
development.
(e-f)
The
system
most
provide
data
management
facilities
that
3
operate
in
the
following
modes:
(e)
batch,
(f)
in.eractive.
196
1.3
DATA
MANAGEMENT
SYSTEM
FACILITIES
Reference:
1.
A
data
management
system is
a
group
of
integrated
routines
developed
to
create
and
maintain
an
organized
collection
of
related
data, known
as
the data
base,
and
to
interrogate
the
data
base
and
produce
various
types
of
formatted
reports.
A
data
management
system
will
create
files
from
various
input
sources;
mcintain
these
file,
by
additions,
deletions,
and
alterations;
create
new
files
and
reorgarize
and
merge
existing
files;
select
data
via
user-prepared
queries;
rake
computations
on
this
data;
and
produce
reports
in
system-defi
ed
r
user-specified
formats.
A
data
management
system
may
be
designed
I
operate
in
either
a
batch
or
inter-
active
mode.
2.
Normally,
a
data
management
system
consists
of
each
of
these
elements.
However,
there
may be
unusual
circumstances
whereby
one
or
more
of
these
elements
will
not
be
required.
For
example,
if
the
installation
intends
to
develop
its
own
report
generation
capability,
this
feature
need
not
be
included
within
the
DMS.
3.
This
criterion
is
directly
derived
from
the
intended
operational
environm
t.
197
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.1
DISPLAY
FACILITIES
I
(a)
The
system
must
allow
formatted
display.
2
(b)
The
sy4
em
must
allow
unformatted
display.
3
(c-e)
-e
system
must
provide
utilities
for
the
foilowing
4
types
of
display
devices:
( N
printer,
(d)
typewriter,
(e)
CRT.
L.2
PERIPHERAL
DEVICE
SUPPORT
(a-d)
The
sys
i
must
p.
vide
the
following
peripheral
device
support
f
,ci
Iities:
(a)
volume
positioning,
I
(b)
media
copying,
2
(c)
data
editing,
(d)
tet
data
file
support.
3
193
2.1
DISPLAY
FACILITIES
Reference:
1.
The
most
common
display
facilities
provided
are
for
main storage (core
dumps),
system
catalogs,
tables
and
directories. Other
display
facilities
are
generally
provided
for
data
stored on
any
secondary
storage media
supported
by
the
system.
2.
This mode
of
display
is
advantageous
when
the
recipient
is
concerned
with
the
contents
of
the
data
being
displayed,
rather
than
its
machine
structure.
3.
This
function
is
very
important
if
a
picture
image
of
the
exact
data
structure
is
required.
4.
The
printer
is
the
most
frequent
means
of
displaying
data.
However,
a
remote
user
may
only
have
a
typewriter
or
CRT
available.
2.2
PERIPHERAL
DEVICE
SUPPORT
Reference:
I.
This
function
consists
of
such
features
as
rewinding,
backspacing,
or
forward
spacing
a
magnetic
tape,
moving
a
disk
arm,
etc.
2.
Media
copying
facilities
should
normally
be
available
to
aN
facility
users.
They
consist
of
routines
to
accomplish
such
functions
as
tape
to
disk, tape to
card, tape to tape, card
to
tope,
etc.
3.
This
is
a
very
useful
feature
to
a
facility
and
should
be
-oecified
if
file-oriented
program
development
is
to
be
a
major
installation
objective.
192
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.1
SORT
MODULE
DEVELOPMENT
(a)
The system must
provide
a
tailorable
general
purpose
1
sort
program.
(b-c)
The
system
must
provide
parameter
specification
by:
2
(b)
control
cards,
(c)
internal
linkage
parameter.
(d)
The
system
must
determine
the
aliccation
of
internal
'
3
workspace.
(e)
The
system must
albw
a
supplied
parameter to
determine
3
internal
workspoce
allocation.
(f)
The
system
must
determine
external
workspace
allocation
3
(g)
The
system
must
allow
a
supplied
parameter
to
determine
3
externor
workspace
allocation.
(h-j)
The
system
must
provide
the.
following
options:
4
(h)
ascending/descending
outpu
sequence,
(i)
single/multiple
sort
control fields,
(i)
single/mixed
data
field
formats.
(k-n)
The
system
must
recognize
the
following
field
keys.
5
(k)
alphanumeric,
(I)
binary,
(m)
zoned,/packed
aeclr.ol
(n
floating
point.
(c)
The system
must
support
a
user-ipeclf%-d
collating
6
sequence.
200
3. 1
SORT
MODULE
DEVELOPMENT
Reference:
1.
This
technique
is
prevalent in
most
sort
packages
and
allow3
the
user
to
tailor
the
sort
program
eithe,
,nrough
control
statements
or
selectable
subroutines.
In
this
way
the
user
can
create
the
most
efficient
program
for
his
specific
need.
2.
Many
systems
provide
For
parameter
specification
either
through
ontrol
cards
or
internal
macro
instructions.
The
use
of
control
cards
is
recommended
for
"off-line"
sorting
of
fixed
data
files.
The
use
of
internal
macros
for
specify-
ing
parameters
is
most
desirable
when the
sort
program
operates
as
an
in-line
routine
for
a
more
comprehensive
application
package.
3.
It
is
generally
advisable
to
have
the
system
perform
all
workspace
calculations.
However, there
may
be
overriding
reasons
for
allowing
a
user
to
specify
these
as
parameters
-
particularly
if
the
generated
sort
routine
is
to
be
a
small
part
of
a
more
comprehensive
application
program
package.
4.
Most
systems
provide
the
capability
to
specifiy
ascending, descending,
or
a
mixture
of
an
ascending/descending output
sequence.
This
allows
the
user
to
specify
different
sort
orders
based
upon
different
keys.
Single
sort
control
fields
require
that
the
sort
key
consist
of
an
adjacent
set
of
characters.
Multiple
control
keys
permit sorting
using
a
number
of
data
elements
that
need
not
be
contiguous.
Some
systems
do
not
provide
the
capability
for sorting
mixed
files
containing
different
kinds
of
records
or
merging
files
with
fixed
and
variable
record
length.
While
other
systems
provide
these
features
as
options
to
increase
user
flexibility
and to
lessen
the
requirement
for
restructuring
files
prior
to
sort.
5. It is
generally
advisable
to
have
the
sort
program
recognize every
type
of
data
element
representation
ptrmitted
within
the
system
6.
This
function
rarely
occurs
ii.
standard
system
supplied
sort
programs.
However,
it
is
sometimes
necessary
for
a
user
to produce
sequences
based
upon
an
alternate
collating
sequence.
For
example,
if
the
data
is
sorted
on
one
system
but intended
for
a
different
system
(with
a
different
collating
sequence),
it
would
be
worthwhile
to
use
the
second
system's
collating
sequence.
201
REQUIREMENTS
OPERATING
SYSTIE
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
3.2
SORT
MODULE
EXECUTION
(a-c)
The
system must
provide
the
following
types
of
sorting:
(a)
full
data
records
(record sort),
(b)
sort
key
and
record
address
(tag
sort),
(c)
sort
key
and
selected
fields
(field
select
sort).
(d)
The
system
must
provide
control for
workspace
overflow.
(e-i)
The
system must
permit
the
inclusion
of
user
codes
2
relative
to:
(e)
!'bel
processing,
(f)
input
record
insertion/modification/deletion,
(g)
output
record
insertion/modification/
deletion,
(h)
blocking/deblocking
control,
(i)
error
processing
(j)
The
system
must
provide
an
automatic
final
pass
3
sequence
check.
(k)
The
system must
provde
an
optional
final
pass
sequence
3
check.
202
3.2
SORT
MODULE EXECUTION
Reference:
1.
Three
types
of
sorting
are
most
generally
used:
a
record
sort,
where the
full
record
is
sorted;
a
fie!d
select
sort,
where
certain
fields
are
deleted
from
the
record
pr;
o
&,a
sorting;
and
a
tag
sort, where
the
full
record
is
stored
on
an
intermediate
device
and
only
its
sort
key
and
address
are
sorted.
The
latter
is
primarily
of
advantage
wlhen
the
sort
program
is
used
as
a
suPorting
task
of
another
executing
application
program.
2.
Exits
to
user
codes
within
a
sort
module
provides
the
user
with
the
flxiE
ty
to
perform
any
of
the
listed
criteria
without
modifying
the
standard
sort
module.
Each
user
can
then
perform
any
of
fhe
unique
functions
required
without
affecting
the
more
general
sort
module
structure.
3.
It
is
usually
a
good
practice
to
perform
a
final
pass
sequence
check
to
validate
the
results
of
the
sort/merge.
Whether
or
not
this
is
performed
automatically
or
as
an
option
depends
upon the
operational
philosophy
of
the
installation.
203
3.4.3
Third
Level
of
Detail
(Part
III
-
Data
Manipulation
Functions)
This
subsection
ccvers
the
following
third level
data
manipulation func-
tions:
1.1.1
FILE
LOCATION
RECOGNITION
1.1.2
FILE
ACCESS
CONTROL
1.1.3
BACKUP
AND
RESTORATION
CAPAB".ITIES
1.2.1
DATA
ACCESS
CONTROL
1.2.2
DATA
BLOCKING/DEBLOCKING
CONTROL
1.2.3
LABEL
PROCESSING
1.3.1
CONTROL
SPECIFICATION
1.3.2
DATA
FILE
GENERATION
AND
MAINTENANCE
1.3.3
DATA
QUALIFICATION
AND
RETRIEVAL
1.3.4
DATA
OUTPUT
2.1.1
UNFORMATTED DISPLAY
2.1.2
FORMATTED
DISPLAY
2.2.1
VOLUME
POSITIONING
2.2.2
MEDIA
COPY
FACILITIES
2.2.3
DATA
EDITING
FACILITIES
2.2.4
TEST
DATA
FILE
SUPPORT
205
REQUiREMEki.)
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.1
FILE
LOCATION
RECOGNITION
1
(a-b)
The
system
must
provide
for locating
files
using
the
2
fol
lowing
methods:
(a)
cataloged
addresses,
2
(b)
label
recognition.
(c-d)
The
system
mubt
use
a
File
identifier
which is:
3
(c)
system
assigned,
(d)
user
assigned.
(e)
The system
must
support
multiple
cataloging
levels.
4,2
(f)
The
system
must
maintain
separate
catalogs.
5,2
206
1.1.1
FILF
I
11CATION
RECOGNITION
Reference:
1. In
most systems
permanent
data
files
are
identified
by
labels
assiqned
by
the
user
or
the
system.
File
labels
may be
composed
of
such
iems
as
the
file
id
'tifier,
the
file
edition
number,
the
owner's
name
and
account
number,
and
perhaps
a
file
utilization
privacy
code.
2.
Maintaining
a
catalog
of
file
locations
is
the
most
expeuitious
method
used
to
locate
files
in
that
the
system
merely
searches
the
catalog
for
the
address
of
the
referenced
file.
3.
Both
methods
of
label
assignment
are
presently
used.
With
system
assigned
labels,
the
system is
responsible
for
the
uniqueness
of
the
labels;
with
user
assigned
labels
the
user
must
assume
the
res-
ponsibility
,r
creating
a
unique
label.
Many
systems
provide
for
mixed
labei
;reation
in
which
the
user
identifier
is
used
by
the
system
in
conjunction
with
a
system
generated
label.
4.
Some
systems
provide
multiple
levels
of cataloging.
Though
not
extensively
used,
this
feature
may
be
of
advantage
when
a
hierarchi-
cal
structure
of
dato
ba-
musiagement
is
desired.
For
example,
a
payroll
file
could
be
constructed
to
consist
of
three
subfiles:
administrative
staff
Payroll,
professional
s;aff
payroll,
and
oper-
ational
staff
payroll.
The
professional
staff
payroll
file
could
also
be
made
into
multiple
files:
managerial
staff,
corporation
officers,
and
consultants.
Thus,
the
number
of
records composing
a
file
is
a function
of
the
file
cataloging level.
5.
Certain
systems
provide
for
an
active
or
master
catalog
and
a
temporary
catalog which
is used
for
programs
that
are
in
a
checkout
phase
and
which
would
not
be
placed
on
the
master
cuialog
until
operational.
207
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.1.2
FILE ACCESS
CONTROL
1
(a) The
system
must
provide
file
security
control.
2
(b)
The
system must
provide
read/write
access
control.
(c)
The
system
must
provide concurrent
access
control.
3
(d-h)
The
system
must
provide
file
access
protection
for
the
4
following
units:
(d)
volumes,
(e)
files,
(f)
physical
records,
(g)
logical
records,
(h)
data
elements.
(i-j)
The
system must
provide
for
acces!;
control
maintenance:
5
(i)
by
system
supervisor,
2
(j)
by
programming
conventions.
208
1.1.2
FILE
ACCESS
CONTROL
Reference:
1.
The
designation
and
restriction
of
file
access
may
be
a
function
under
control
of
the
operating
system
or
it
may
merely
be
established by
a
set
of
installation
programming
conventions.
When
controlled
by
the
system,
the
owner
of
a
file
can
usually
designate
that
the
file
is
to
be
maintained
for
his
use
only,
for
the
use
of
a
designated
group
only,
or
For
general
use.
Frequently,
the
owner
may
also
specify
the
level
of
access
afforded
each
designated
user.
For
example,
access may
be
restricted
to
a
read-only level
for
some
users
while
others
are
allowed
full
read and
write
capabilities.
2.
This
criterion
should
be
specified
For
all
processing
systems
that
main-
tain
classified
or
private
information.
3.
Concurrent
access
control
is
required
to
maintain
the
scheduling
and
handling
of
concurrent
or
simultaneous
requests
for
a
data
file
from
separate
programs
or
users
in
a
multiprogramming
or
time-sharing
environment.
Basically,
the
control
function
must
determine
if
multiple
user
access
can
be
permitted
or
whether
the
file
must
be
restricted
to
single
user
access.
In
situations
where
multiple
users
may
simultaneously
access
a
single
file,
it
is
usually
desir
able
to
grant any
number
of
them
read-only
access,
but
to
restrict
,v'ite
access
to
a
single
user
at
a
tine.
4.
The
level
of
rile
access
protection
*s a
part
of
the
overall
philosophy
of
data
base
design.
One
school
of
'hought
advocates
a
single
lage
data
base
with
individual
records
and
data elements
individually
allocated
or
denied
to
certcln
users.
Another
school
advocates
a
dot,
'i. -
-:n2ng
of
multiple files
with
the
user
either allowed
or
denied
access
to
the
entire
file.
5.
Either
of
these
criteria
can
be
specified
as
a
method
of
maintoining
access
cor.trol.
However,
system
superviscry
control
is
consderably
more
reliable;
the
other
method
is
dependent
upon
external
users
adhering
to
thi
conventions.
System
supervisory
control
should
be
specified
for
t
me-O-'orin
and
multiple-user
batch
processing
systems.
209
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.
1.3
BACKUP
AND
RESTORATION CAPABILITIES
(a-b)
The
system
must
support the
following
backup media:
I
(a)
on-line
devices,
2
(b)
off-line
devices.
(c-d)
The
system
must
provide
the
following
restoration
techniques:
(c)
automatic,
2
(d)
operator
in*tiated.
(e-g)
The system
must
provide
the
folowing
File
backup
3
techniques:
(e)
grandfather
files,
(f)
periodic
checkpoints,
(g)
retention
of
transoct*.n
data.
21.)
1.1.3
BACKUP
AND
RESTORATION
CAPABILITES
Reference:
1.
This
function
is
highly
dependent
upon
the
hardware
configuratior,
and
can
only
be
specified
when
the
hardware
configuration
is
known.
Syst
support
of
on-line
backup devices
can
s*-nificantly
improve
the
system
recovery
time
cnd
shLu!J
be
con,;dX,ed
ror
a
real-time
processing
syste
2.
Thi:
-rite,'ion
is
highly
desirable for
a
real-time
processing
system.
3.
The
use
of
grandfather
files
as
a
file
backup
technique
provides
a
secur0
base
from
which
a
system
can
be
restored
to
-ration.
However,
this
type
of
File
backup
is
usually
associated
with
a
periodic
update
of
he
grandfather
file
which
means
that
File
changes
made
during operation
of
the
system
must
be
retained
and
re-run
to
bring
the
grandfather
file
up
to
date.
This
pr
.cedure
is
normally
used
for batch
processing
commer-
cially
oriented
jobs.
Periodic
checkpoints
are
used
as
a
backup
technique
in
many
real-time
processing
environments.
However, the
file
maintained
on
the
check-
point
will
not
be
totally
up
to
date
and
intermediate transection
data
should
be
retained.
The
retention
of
all
transaction
datc
is
an
excellent
technique
to
be
used
in conjunction with
redundant
files
or
graJfather
files.
In
this
way
the
redundant
file
or
grandfc'her
file
can
be
updated to
the
status
of
the
previous
working
file.
211
REQUIREMENTS
OPERATING
SYSTEM
' --
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.2.1
DATA
ACCESS
CONTROL
(a-e)
The system
must
support
the
following
access
methods:
I
(a)
sequential,
2
(b)
random
(direct), 3
(c)
keyed,
4
(d)
indexed,
5
(e)
teleprocessing.
6
(f-r)
The
system
must
permit
data
access
at
the
fo!lowng
7
levels:
(f)
block,
(g)
record,
(h)
data
item,
(i)
character.
212
REQUIREMENTS
OPERATING
SYSTEM
1000
REQUI~REMENTS
CHECKLI
ST
Reference
Initial
Extended
1.2.2
DATA
BLOCKING/DEBLOCKING
1
CONTROL
(a)
The
system
must
provide
record
acquisition
by
deblocking.
(b)
The
system must
provide
move
mode
deblocking.
2
(c)
The
system
must
provide
locate
mode
deblocking.
2
(d-f)
Block
ing/deblock
ing
facilities
must
be
available
for:
3
(d)
fixed
length,
(e)
variable
length,
(f)
records
of
undefirnd
length.
(g)
The
system
must
provide
system
specified
block
sizes.
(h)
The
system
must
permit
user-specified
block
sizes.
214
1.2.2
DATA
BLOCKING/DEBLOCKING
CONTROL
Reference:
1.
Blocking
combines
two
or
more
individual
records
into
one
physical
data
block;
deblocking
isolates
the
individual
records
within
a
physical
data
block.
Record
lengths
may
be
fixed,
variable
or
undefined
and
all
of
these
types
may
be
blocked
or
unblocked.
2.
While frequently
employed
for
evaluation
these
criteria
are
rarely
specified.
The
locate
mode
of
deblocking
provides
the
user
with
the
capability
to
locate
and
process
a
,oecific
record
through
the
use
of
pointers
without
physically
moving
the
record
to
a
processing area.
In
move
mode
deblocking
the
system
physically
moves
each
deblocked
record
from
the
I/O
buffer
area
into
a
user
storage
area.
The
!ocate
mode
s
thus
somewhat
faster
and
requires
less
core storage.
It
may,
however,
also
*ntroduce
unnecessary
complexity in
record
processing
for
the
application
programmer.
1.
This
function
is
usually
supported
by
all
processing
systems
that
provide
logical input/output
support.
215
REQUIREMENTS
_____________________
OPERATING___________________________
SYSTEM________
________________
REQUIREMENTS
CHECKLI
ST
Reference
Initial
Extended
1.2.3
LABEL
PROCESSING
1
(ni)
The
system
must
provide
an
automnat~c
label
generation
2
capabiIi
ty.
(b)
The
system
must
allow
users
to
generate
labels.
3
(c)
The
system
must
provide
automatic
la~bel
checking
2
facilities.
(d)
The
system
must
ailow
label
checking
upon
user
request.
1.2,3
LABEL
PROCESSING
Reference:
1.
Most
systems
provide
facilities
for
writing
and
checking
fie
labels
when
a
data
file
is
opened
or
closed.
Many
systems
also
permit
the
user
to
spicify
his
own
labels
and to
supply
special
routines
for
processing
them.
A
few
of
the
smaller
systems
provide
no
label
generation
and
checling
facil~ties,
and
all
label
processing
functions
must
be
performed
s,y
the
user.
2.
This
function
is
usually
provided
in
medium
to
large
processing
syeems
and should
be
specified.
3.
Many
systems
support
user
generated
labels.
User
labels
also
require
special
user
routines to
read
and
validate
the
labels.
217
REQUIREMENTS
OPERATING
SYSTEM
REQUIkEMENTS CHECKLIST
Reference
Initial
Extended
1.3.1
CONTROL
SPECIFICATION
1
(a-d)
The system
must
allow
the
specification
of
the
following
2
types
of
formats:
(a)
ffli
formats,
(b)
report
formats,
(c)
input
formats,
(d)
query
formats.
(e-f)
The
system
must
provide
the
following
methods
of
deriving
control
functions:
(e)
generative
routines,
3
(f)
interpretative
routines.
218
1.3.
!
CONTROL
SPECIFICATION
Reference:
1.
A
data
management
system
must
be pri
ided
with
a
set
of
specifica-
tions
or
commands
delineating
the
jo
it
is
to
perform.
The
system
interprets
these
specifications,
and
generates
func.lonal
modules
to
perform
the
selected
jobs.
These
modules
may
take
the
form
of
interpretive
tables
or executable
programs
or
subroutines.
Generally,
the
system
will
maintain
an
extensive
library
of
functional
subroutines
which
may
be
incorporated
as
needed
into
the
final
support
modules.
These
subroutines
range
from
arithmetic
and
data
conversion
routines
to
file
searching
and
positioning
capabilities.
The
generation of
the
resulting
support
modules
is
analogous
to
the
process
used
by
a
compiler
to
convert
user
code
into
machine
executable
code.
2.
These
formats
should
be
specified
for
each
of
the
elements
selected
to
compose
the
data
management
system
(see
1.3
a,b,
c,d).
3.
The
generative
type
of
derivation
is a
process
which
actually
structures
a
machine
executable
module
to
perform
the
required
function.
219
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
ExteiJed
1.3.2
DATA
FILE
GENERATION
AND
MAINTEN-
ANCE
(a-e)
The
system
must
provide
the
following
data
file
genera-
tion
and
maintenance
facilities:
(a)
fixed
input
transaction
processing,
2
(b)
logical
(programmed)
file
maintenance,
3
(c)
interactive
file
mainteance,
4
(d)
file
reorganization,
5
(e)
data
error
procedures.
(f-g)
The
system
must
allow
the
following
types
of
correction:
6
(f)
interactive,
(g)
pre-establ
ished.
220
1.3.2
DATA
FILE
GENERATION AND
MAINTENANCE
Reference:
1.
Data
file
generation
and
maintenance
is
concerned
with
defining
the
internal
strurtur-
of
a
file,
allocating
space
for
the
file
on
a
storage
device,
prccessing
input
transactions
against
the
file,
per-
forming
logical
and
interactive
maintrance
on
the
file,
and
re-
organizing
the
file
when
the
structure
must
be
modified.
2.
Fixed
input
transacticn
processing
involves
defining
input
data element
formats,
validating
the
data
elements
as
they
are
entered,
converting
them
into
internal
formatt
and
storing
them
in
the
data
file.
Input
format
definitions
may be
established
prior
to
the
entry
of
the
data
into
the
system
or
the
data
entry
may
be
self-defining.
3.
Logical
file
mc
ntienc.e
permits
conditional
or
programmed
updating
of
a
data
file.
Logical
maintenance
may
or
may
not
be
transaction
oriented.
If
it
is,
the
transaction
updates
the
object
file
only
when
specified
criteria
are
satisfied.
Non-transaction
oriented
maintenance
is
usually
accomplished
via
internal
actions
generated by
a
computer
pseudo-language
program.
Fo,
example,
a
logical
mainttenance
job
might
specify
the
deletion
of
every
record
written
after
a
given
calendar
date,
or
convesey,
the
retention
of
only
those
records
written
between
two
given
calendar
dates.
4.
Interactive
maintenance,
as
its
name
implies,
is
the
updating
of
a
data
file
from
an
on-line
terminal.
Almost
all
interactive
maintenance
applications
utilize
logical
file
maintenance
featur,.s.
Prior
to
initiating
the
actual
transaction
the
terminal
user
must
usually
establish
logical
parameters
to
isolate
records
of
interest.
5.
this
function
provides
for
reorganization
of
one
or
more
existing
date
files
in.'o
a
new
composite
output
file.
Data
fields
may
be
added,
deleted,
or
changed
in
size
or
type
under
the
restructuring
v
)Cess.
6.
Most
data
management
systems
provide
for
the
use
of
pr-es-atlished
nctions to
be
performed
in
case
of
an
error.
A
more
unique
capability
is
that
of
an-lir,
interactive
correction
support
whereby
the
interactive
^er
can
correct
data
errors
s
they
are
recognized.
221
REQUIRFMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.3
DATA
QUALIFICATION
AND
RETRIEVAL
I
(a-b)
The system
must
allow
the
following
interrogation
modes:
(a)
interactive,
(b)
batch.
(c-e)
The
system
must
allow
retrieval
mode
control
through
the
following
pre-stored
queries:
(c)
fixed
logic, 2
(d)
modifiable
logic,
3
(e)
parameterized.
4
(F-h)
The
system
must
allow
retrieval
mode
control
through
the
following
interactive
queries:
(f)
cue-response
format,
5
(g)
prompting
format,
6
(h)
programmable
format.
7
(i-m)
The
system
must
allow
query
processing
through
the
8
following
types
of
logical
operators:
(i)
Boolean,
9
(j)
qt-intitative
(occurrence),
10
(k) arithmetic, 11
(I)
statistical,
12
(m)
application-defined.
13
(n)
The
system must
allow
nested
logical
operators.
(o-r)
The
system
must
allow
the
following
query
processing
8
operand
formats:
(o)
constant
value,
(p)
another
data
field,
(q)
interim
result,
14
(r)
arithmetic
expressions.
(s-u)
The
system
must
support
the
following
types
of
file
search-es:
(s)
single
file,
(t)
multi-file,
(u)
inter-file.
222
1.3.3
DATA
QUALIFICATION
AND
RETRIEVAL
Reference:
I.
Data management
systems
may
be
designed
so
that
data
qualification
and
retri
can
be
accomplished
in
either a
batch
or
interactive
mode.
In
the
batch
rr
J,
the
data
base
may be
interrogated
by
individually
prepared
logical
queries or
I
prestored
logical
queries
in which
specific
operands
can
be
altered.
In
$he
in:
active
mode
interrogation
may
be
by
a
cue-response
form
of
query,
by
a
promF
g
query
which
"guides"
the
user
through
the
interrogation,
or
by
a
user-progromf
d
query.
Each
record
satisfying
the poran,eter
of
the
query
may
be
directly
disp!
.ed,
retained
on
an
intermediate
file
for
subsequent
processing,
cr
passed
on
to
ano
r
portion of
the
data
management
system,
such
as
data
output
or
file
maintenance
Thus, a
single
data
qualification
scheme
generally
serves
the
entire
data
mona!
ment
system.
2.
Fixed
logic
pre-stored
queries
allows
the
user
to
store
frequently
used
queries
c
a
library
and to
directly
reference
them
ut
execution
time.
3.
Modifiable
!ogic
pre-stored
queries
allow
the
user
to
temporaril'
aler
query
Ic
prior
to
execution.
4.
Parameterized
pre-stored
queries
allow
the
user
to
store
skeleal
queries
within
c
system
and
then
insert
parameters
at execution
time.
5.
The
cue-response
format
provides the
user
with
the
capability
to
engage
in
a
question/answer
dialogue
with
the
system.
The user
furnishes
answers
to
the
sr
questions
in
order
to
execute
his
request.
6.
The
prompting
format
is
one
which
is
designed
primarily
for
inexperienced
users
The
system
prompts
the
user
when
he
is
uncertain
of
how
to
formulate
a
request.
7.
The
programmable
format
allows
the
user
to
program
and
execute
retrieval
requ.N
8,
The
specification
of
each
of
these
functions
's
entirely
dependent
upon
the
type
query
processing
envisioned
by
the
installatior.
9.
A
Boolean
query
allows
the
user
to
perform
logical
retrieval
statements
using
thl
comparators:
equal, not
equal,
greater
than,
less
than,
less
than
or
equal
to,
greater
than
cr
equal
to.
Additionally,
the
user
can
combine
statements
by
the
logical
conrnetors
AND,
OR,
-"d
NOT.
Thus,
the
user
can
perform
such
funr€
-1
as:
Search
for
"this
AND
this"
but
"NOT
t
iis";
search
for "this
OR
tHis"
but
"I
'T
this";
etc.
10.
A
quantitative
query
allows
the
user
to
retrieve
records
based
upon
a
count
of
t*
unique
occurrences
of
a
specified
value.
11.
An
arithmetic
query
provides
the
user
with
the
capability
to
perform
arthmetic
operations
on
data
values
oncd
to
retrieve
based
upon
the
numeric
result.
12.
Statistical
query
allows
the
user
to
retrieve
records
based
upon
strfisticcl
colcul
ions
such
as
derivation
frn
mean,
median,
etc.
13.
Application-def-ecd
query
r
ocessing
are
those
queries
required
for
special
appl
cations.
14.
This
function
allows
the
user
to
conitruct
a
qualification
for'--,
bcad
upon
a
previous
computation
or
query.
223
REQUIREMENTS
O~~~.PER
ATONG
SYSiF
EM-
" -
REQUIREMENTS
CHECKIST
Ra;erence
lnitioi
Extended
3.4
IDATA
OUTPUTf
(C-c;
The
fat!ow'ng
meti.vds
of
repert
control
must
be
s
;sported
by
the
system-
(a,
user
St-ucV.;r~,Vd
(b)
sysie',-
defined,
(C)
in-#ractively
dfirtedH
(d)
The
system
must
Iroyde
pre-stored
reNr?
Formats
for
2
data
output,
(e-i)
The
system
must
support
the
following
media;
3
(e)
CRT,
(f)
typewriter,
(g)
printer,
(h)
magnetic
tape
dr've,
(1)
card
punch.
(I)
The
sysiem
must
provide
support
for
mu!tipfe
copy
4
facilities.
(k-m)
The
sy!",m
must
provide
the
foik-wing
types
of
output
5
labeling:
(k)
headings,
(i)
trilers,
(n)
data
labels.
(n-o)
The
s,0'stem
must
provide
the
following
data
formatting
capablifies:
(n)
hor'zor-al/verti
cal
positioning,
5
(o)
rigqh,/left
justification.
(p-q)
The
sy!tem
must
provide
the
following
data
altering
5
capabilitie
:
(p)
data
editing,
6
(q)
decoding.
7
(r-s)
The
system
must
provide
the
following
output
account-
5
;ng
capabili
ies:
(r)
counting,
(s)
totaling.
(t-u)
The
system
must
provide
pagination control
for
the
8
following:
;)
pr;nted
reports,
(u)
CRT
disolavs.
224
1.3.4
DATA OUTPUT
Reference:
I,
User
structured
reports
provide
the
installation
with
the
greatest
flexibility
over
the
report
Format.
System
defined
reports,
while
less
likely
to
pro-
duce
c
Format
to
completely
satisfy every
report
requirement,
are
normally
considerably
faster.
System
defined
reports
are
usuay
adequate
for
printing
transaction
listings
and
other
internally
oriented
documents.
Externally
oriented
documents
(those
for
other
than the
actual
DMS
pro-
grammer)
should
probably
be
produced
via a
user
structured report.
Interactively
defined
reports
should,
of
course,
only
be
considered
for
facilities
supporting
on-line
interactive
support.
2.
This
criterion
is
highly
desirable for
a
data
management
system
that
will
process
standard reports
on
c
recurring
basis.
3.
The
selection
of
any
of
these
criteria
is
dependent
upon
the
devices
available
in
the
hardware
configuration.
4.
This
Function
is a
highly
desirable
Feature
for
a
data
management
system
in
that
it
provides
the
user
with
the
capability
to
obtain
multiple
copies
without
rerunning
the
output
program.
5.
Most
data
management
systems
provide
these
capabilities.
6.
The
capability
of
the
system
to
automatically
perform
data
editing
is
very
important
to
a
user
in
producing
an acceptable
report
appearance.
Editing
consists
of
such
things
as
suppressing
leading
zeroes,
supplying
punctuation,
etc.
7.
If
the
DMS
supports
data
encoding
when
data
is
entered
into
the
fie,
then
the
output
phase
should
support
a
corresponding
decoding
module.
8.
If
the
system
is
to support
such
devices
as
printers
or
CRTs
then
pagination
control
should
be
provided for starting
a
new page,
numbering
sequential
pages,
stopping
output
on one
page
and
beginning
a
new page,
etc.
225
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.1.1
UNFORMATTED
DISPLAY
(a-d)
Unformatted
display
must
be
provided
by
the
system
for
the
following
media:
(a)
cam,
(b)
magnetic
tape,
(c)
paper
tape,
(d)
random
access
storage.
2.1.2
FORMATTED
DISPLAY
(a-b)
The system must
allow
format
specification
by:
(a)
system,
(b)
user.
(c-d)
The
system
must
support
the
following
speci,.
display
categories:
(c)
data
files,
2
(d)
directories.
3
(e)
The
system
must
provide
for
selective
record
display.
4
(f)
The
system
must
provide
for
se'qctive
field
display.
4
226
2.1.
1
UNFORMATTED
DISPLAY
Reference:
1.
If
the
unformatted
display
option
has
been
selected
as
a
criterion
(see
2, 1
b),
then
;f
should
be
provided
for
each
storage
medium
within
the
system.
2.1.2
FORMATTED
DISPLAY
Reference:
1.
This
criterion
is
highly
desirable
since
it
gives
the
user
the
capability
to
specify
the
output
presentation,
e.g.,
octal,
decimal,
alpha
op-codes,
etc.
2.
The
capability
to
display
data
files
in
a
formatted
m..
e is
extremely
useful
to
the
user
during
program
testing
and
debugging.
It
is
also
useful
to
the
installation
as
a
method
for
displaying
total
file
contents.
This
type
of
file
display frequently
becomes
a
-uckup
to
the
report
generation
capabilities
of
a
data
management
system.
3.
If
the
system
maintains
directories
or
catalogs,
then
the
system
should
also
provide
routines
to
produce
formatted
displays
of their
contents.
4.
This
criterion
gives
the
user
the
capability
to
visually
examine
portions
of
a
file
without
requiring
a
total
file
dump.
This
can
be
a
definite
aid
during
system
troubleshooting
or
program
testing.
227
REQUIREMENTS
OPERATING
SYSTEM
-
-q
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.2.1
VOLUME
POSITIONING
(a-c)
The system
must
support
the
following
types
of
volumes:
(a)
magnetic
tape,
(b)
direct
access
storage,
(c)
card
files.
(d-h)
The
system
must
provide
the
following
magnetic
tape
2
support:
(d)
forward
spacing,
(e)
backspacing,
(f)
rewinding,
(g)
unloading,
(h)
erasing.
(i-j)
The
system must
provide
selective
positioning
of:
(i)
files,
3
()
records.
3
(k-I)
The
system
must
support the
following
..
thods
of
positioning:
(k)
count
oi
records
or
files,
3
(I)
field
or
record
contents.
4
228
2.2.1
VOLUME
POSITIONING
Reference:
I.
The
specification
of
these
criteria
is
highly
dependent
upon
the
hardware
configuration.
2.
These
criteria
should
be
specified
for
all
processing
systems
which
support
magnetic
tape.
3.
This
criterion
is
highly
desirable
for
all
processing
systems
supporting
sequential
access
devices.
4.
This
method
frequently
occurs
in
systems
supporting
direct
access
storage.
229
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
2.2.2
MEDIA
COPY
FACILITIES
(a-f)
The system
must
provide
copy
facilities
for
the
following
I
media:
(a)
card,
(b)
magnetic
tape,
(c)
paper
tape,
(d)
random
access
storage,
(e)
main
storage,
(f)
remote
terminal
devices.
(g-j)
The system
must
provide
the
following
options:
2
(g)
field
insertion,
(h)
field
selection,
(i)
format
conversion,
()
code
conversion.
(k-rn)
The
system
mus
t
provide
the
following
dump
and
reload
facilities:
(k)
file
compaction,
3
(I)
storage
compection,
3
(m)
backup
file
creation.
4
230
2.2.2
MEDIA
COPY
FACILITIES
Reference:
1.
This
criterion
should
be
specified
for
all
media
supported
by
the
processing
system.
2.
Field insertion
and
field
selection
provides
the
user
with
the
com-
patibility
to
alter
or
copy
selected
daia
fields
rather
than
entire
records.
Format
and code
conversion
is
generally
not
too
extensive
in
utility
programs.
It
is
normally
only
a
conversion
of
data struc-
ture
rather
than
a
conversion
of
the
data
itself.
Data cooe
conversion,
however,
is
necessary
when
the
media
use
a
different
code
representation
e.g.,
punched card
to paper
tape.
3.
These
considerations
normally apply
only
to
direct
access
storage
devices.
File
and
storage
compaction
is
highly
desirable
when
the
file
is
fairly
volatile
in
the
number
of
records
maintained.
As
records
are
deleted
from
a
file,
"holes"
of
unused
space
occur.
Compaction
eliminates
these
unused
areas,
thus
decreasing
the
total
amount
of
space
required
for
file
storage.
4.
Backup
file
creation
is
always
a
useful
feature
in
case
of
inadvertent
file
destruction.
231
!!
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reierence
Initial
Extended
2.2.3
DATA
EDITING
FACILITIES
(a-c)
The
following
types
of editing
must
be
provided
by
the
system:
(a)
full
file
compare,
(b)
selective
field
compare,
(c)
single
file
scan.
(d)
The system
must
provide
for
file
comparison
between
2
differing
file
formats.
2.2.4
TEST
DATA
FILE
SUPPORT
(a-b)
The system
must
support
the
creation
of
the
following
I
types
of
test
files:
(a)
data
files,
(b)
I/O
terminal
message
files.
(c)
The
system
must
provide
history/troce
fite
interpretation
2
232
2.2.3
DATA
EDITING
FACILITIES
Reference:
1.
A
full
file
compare
is
useful in
validating
file
contents.
A
selective
field
compare
is
useful
in
validating
selected
field
updates
without
validating
the
entire
File.
A
single
file
scan
is
useful
in
checking
file
structure,
sequence,
and formats.
2.
This
capability
occurs
in
very
few
processing
systms.
It
can,
however
be
quite
useful
when
validating
related
Files.
2.2.4
TEST
DATA
FILE
SUPPORT
Reference:
I.
Many
systems
provide
utilities
to
support the
checkout
of
application
programs
in
a
mode
which
will
not
impact
operational
files.
For
this
to
be
done
it
is
necessary to
create
a
simulated
environment
as
close
to
the
operational
environment
as
possible.
By
providing
test
data
files
and
terminal
message
files,
application
program
testing
becomes
considerably
easier.
2.
This
criterion
is
highly
desirable
for
a
processing
system
that
provides
trace
capabilities
(see
Part
I,
3.2.2).
233
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extende,
1.1.2.1
FILE
SECURITY
CONTROL
(a-b)
The
system
must
provide
the
following
file
security
control
protection
methods:
(a)
user
ID,
(b)
passwords.
1.1.2.2
READ/WRITE
ACCESS
CONTROL
(a-b)
The
system
must
provide
the
following
access
restric-
tions
to
authorized
users:
(a)
read
access
only,
(b)
read and
selective
write
access.
(c)
The
system
should
provide
unrestricted
access
to
authorized
users.
1.
1.2.3
CONCURRENT
ACCESS
COI'-r1L
(a-c)
The
system
must
provide
the
following
level
of
doto
shoring:
(a)
file,
(b)
record,
(c)
data
element.
236
1.1.2.1
FILE
SECURITY
CONTROL
Reference:
1.
If
the
user
ID is
used,
then
the
synpe-, must
maintain
a
checklist of
the
users
that
can
access
a
particular
file
and
perform
a
user
ID
compare
to
determine
if
the
user
can have
access.
If
the
password
method
is
used,
then
each
file
has
a
designated
password
and
the
mere
refer-
ence
by
a
user
to
the
password
allows
access.
Therefore,
the
pass-
word
method
is
more
efficient
from
a
processing
standpoint,
though
potentially
less
secure
than
user
ID
control.
1.1.2.2
READ/WRITE
ACCESS
CONTROL
Reference:
1.
Once
a
user
has
been
granted
access
to
a
file,
some
systems
limit
the
type
of
operation
he may
perform.
For
example,
some users
may
only
read
the
file,
other's
may
read
the
file
and
alter
existing
records,
but
may
not
add
new records.
The
type
of
access
designations
that
should
be
permitted
must
be
derived
from
the
anticipated
file
contents
and
the
type
of
user4
requiring
cccess.
1.1.2.3
CONCURRENT
ACCESS
CONTROL
Reference:
1.
Concurrent
access
control
is
required
to
-iintain
the
scheduling
and
handling
of
concurrent
or
simultaneous
requests
for
a
data
file
from
separcte
programs
or
users
in
a
multiprogramming
or
time-sharing
environment.
Basically,
the
control
function
must
determine
if
multiple
user
access
can
be
permitted
or
whether
the
file
must
be
restricted
to
single
user
access.
In
situations
where
multiple
users
may
simultaneously
access
a
single
file,
it
is
usually
desirable
to
grant
any
number
of
them
read-only
access
but
to
restrict
write
access
to
a
single
user
at
a
time.
237
REQUIREMENTS
OPERATING
SYSTEM
-
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.2.1.1
SEQUENTIAL
ACCESS
CONTROL
(a)
The
system
must
provide
basic
sequential
access
control.
(b)
The system
must
provide
automatic
read-ahead
sequen-
tial
(queued)
access.
1.2.1.2
KEYED/INDEXED
ACCESS
CONTROL
(a)
The
system
must
provide
automatic
key
computation.
(b)
The
system
must
provide
automatic
index
maintenance.
2
(c)
The system
must
allow
multiple
index
levels
to
be
3
maintained.
(d-e)
The
system must
support
the
following
types
of
access
keys:
(d)
software keys,
(e)
hardware
keys.
238
1.2.1.1
SEQUENTIAL
ACCESS
CONTROL
Reference:
1.
This
function
is
usually
desirable for
sequcntial
record
processing.
Auto-
matic read-ahead
facilities
are
provided
to
decrease the amount
of
wait
time
a
program
may
have
to
incur
during
successive
access
operations.
In
this
way the
program
can
be
processing
previously
obtained
data
while
the
next
data
access
is
being
performed.
1.2.1.2
KEYED/INDEXED
ACCESS
CONTROL
Reference:
1.
Automatic
key
computation
relieves
the
user
of
determining
the
physical
storage
address
of
the record.
2.
Automatic
index
maintenance
relieves
the
user
of
updating
the
index
of
an
indexed
file
when
he adds
or deletes
a
record
from
the
file.
3.
Indexes are
provided for
more
efficient
access
of
data. However,
if
the
index
itself
becomes
too
large,
then
an
index
to
the
index
may
be
desirable.
For
example,
a
disk
index could
consist
of
an
index
for
all
cylinders
in
a
file
and
a
separate
track
index
for
all
tracks
on
a
cylinder.
239
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENT:
CHECKLIST
Reference
Initial
Extended
1.2.1.3
TELEPROCESSING
ACCESS
CONTROL
(a)
The
system
must
provide automatic
message
time
1,2
stamoing.
(b)
The
system
must
provide
optional
message
time
stamping.
2
(c-e)
The system
must
provide
the
following
ioput
message
3
processing
facilities:
(c)
message
routing,
(d)
message
queuing,
(e)
message
priority
recognition.
(f-h)
The
system must
provide
the
following
output
message
3
processing
facilities:
(f)
message
routing,
(g)
message
queuing,
(h)
message
priority
recognition.
240
1.2.1.3
TELEPROCESSING
ACCESS
CONTROL
Reference:
1.
This
criterion
is
highly
desirable
for
al)
systems
supporting
teleproce.ssing.
2.
Message
time-stamping
is
one
of
the
more
convenient
ways
of
attuching
a
unique
identifier
to each
message
entering
the
system.
At
the
same
time,
it
allows
the
system
to
easily
recognize
messages
that
have
been
in
the
system
an excessive
length
of
time
in
order
to
increase
their
processing
priority
if
necessary.
3.
These
Features
are
quite
desirable
for
most
processing
systems
supporting
teleprocessing.
I"
241
REQUIREMENTS
OPERATING
SYSTEM
m
-
REQUIREMENTS
CHECKLIST
Reference
iitial
Extended
1.3.2.1
STRUCTURE
DEFINITION
(a-e)
The
system
must
allow
the
following
types
of
structures:
1
(a)
sequential,
2
(b)
hierarchical,
3
(c)
indexed,
4
(d)
ring,
5
(e)
list.
5
(f-g)
The
system must
provide
the
following
types
of
indexing
schemes:
(f)
normal,
(g)
inverted.
6
(h-j)
The
system
must
allow
the
following
types
of
data
elements:
(h)
fixed
length,
(i)
variable
length,
()
repetitive.
7
49
1.3.2.2
SPACE
ALLOCATION
(a-d)
The
system
will
provide
data
management
system
support
usinc,
the
following
storage
media:
(a)
tape,
(b)
disc,
(c)
drum,
(d)
mass
storage.
242
1.3.2.1
STRUCTURE
DEFINITION
Reference:
1.
While
frequently
employed
for
evaluation,
these
criteria
are
rarely
specified.
However
it
may
be
necessary
to
specify
certain
of
these
criteria
based
upon
anticipated
file
design
requirements.
2.
A
sequential structure
is
one
in
which
the data
elements
are
all
of
equal
rank. This
method
can
be
used
in
support
of
data
which
can
be
grouped
into
data
elements
that
are
an
entity within
themselves.
3.
Hierarchical
structures
provide
the
capability
to
structure
a
file
based
on
a
ranking
scheme
usually
related
to
a
specific
type
of
logical
group
relationship.
An
example
of
this
type
of
data
could
be
a
file
contain-
ing
a
logical
ranking
such
as:
nation,
political
subdivision,
counties.
major
cities,
etc.
4.
The
indexed
structure
may be
applied
to
either
the
sequential
or
hier-
archical
structure
method
and
can
be
used
to
selectively
locate data
elements
within
a
file.
5.
The
ring
and
':st
type
of
file
structure
are
closely
related.
Each
data
element
contains
the
address
of
the
next
successive
data
element
within
a
file.
The
difference
in
the two
structures
is
that
the
last
data
element
in
a
ring
contains
the
address
of
the
first
data
element,
whereas
the
list
does
not.
A ring
structure
thus
allows
the
user
tr
-ead
a
total
sequence
of
data elements
starting
with
any
element
within
the
ring.
6.
This
criterion
is
highly
desirable
for
a
processing
system
where
the
retrieval
elements
are
either
random
or
unpredictable.
In
this
struc-
ture
retrieval
time
is
minimized
regardless
of
the
data
fields
queried.
However,
this
type
0t
structure
also
requires
an
extremely
complex
file
updating
technique.
7.
Repetitive
data
elements
are
those
which
have
a
number
of
entries
under
c
single
data
label.
For
example,
in
a
bar
account
record,
deposits
and/or
withdrawels
tend to
be
repeating
entries.
1.3.2.2
SPACE
ALLOCATION
Reference:
1.
The
specification
of
these
criteria
;s
d*rsoondent upon
the
hardware
configuration.
243
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.2.3
INPUT
TRANSACTION
PROCESSING
(a-c)
The
system
must
provide
input
transaction
processing
fccilities
that
allow:
(a)
input
data
definition,
(b)
input
data
validation,
(c)
input
data
alteration.
(d-e)
The
system
must
allow
the
following
types
of
input
2
formats:
(d)
pre-established,
(')
self-defining.
(f-i)
The
system
must
provide
the
following
types
of
input
data
validation:
(f)
equal
value
compar;
n,
(g)
range
verification,
(h)
masked
comparison,
()
sequence
checking.
(j-)
The
system must
provide
the
following
types
of
input
3
dota alteration:
(j)
automatic
truncation/podding,
(k)
encoding/decoding,
(I)
constant
factor modification.
(m-o)
The system must
recognize
the
following
input
data
4
te
rn
inator,-
(m)
standard (embedded)
feld,
(n)
%peciol
charactec(s),
(o)
phys'cal
media
morkers.
244
1.3.2.3
INPUT
TRANSACTION
PROCESSING
Reference:
1.
These
criteria
should
be
specified
for
all
data
management
systems.
2.
In
many
cases
the
structure
of
the
input
to
be
received
can
be
established
in
advance.
At
other
times
the
method
in
which
the
user
receives
the
input
precludes
effective
data
structuring.
The
pre-established
format
is
useful
for
fixed
record
input
media
such
as
punched
cards,
magnetic
tape,
etc.
The
self
defining
Format
is
usually
best
For
teleprocessing
based
transactions.
3.
The
ability
to
truncate
or
pad
data
is
useful
in
forcing
data
conformity.
Encoding
can
be
useful
in
decreasing
storage
requirements,
while
decoding
is
the
reverse
but
allows
the
user
to
make
abbreviated
references.
Constant
factor
mnodification
allows input
data
values
to
beemodified
by
a
data
value.
4.
Input
terminators
are
used
to
signal
the
end
of
the
input
data
to
be
processed.
Each
of
these
techniques
has
its
advocatea,
and
no
part-
icular
method
is
favored.
245
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1.3.2.4
LOGICAL
RECORD
MAINTENANCE
(a)
The
system
must
allow
the
selection of
update
records
1
by
logical
query.
(b)
The
system
must
provide
record
maintenance
through
2
multi-record
logic.
(c'
The
system
must
provide automatic
updating
of
sub-
3
ordinate
files.
1.3.2.5
INTERACTIVE
FILE
MAINTENANCE
CONTROL
(a-b)
The
system
must
provide
interactive
oa
irride
capabili-
I
ties
for:
(a)
data
values,
(b)
update
logic.
246
1.3.2.4
LOGICAL
RECORD
MAINTENANCE
Peference:
1.
Logical query
provides
the
user
the
capability
to
update records
based
upon
a
specified
condition
being
satisfied.
An
example
of
this
would
be
the
statement
"delete
all
records
after
a
given
calendar
date"
or
"reain
all
records
between
two
given
calendar
dates".
2.
Update
by
multi-record logic
provides
the
user
the
capability
to
update
records
by
referencing another
record
or
records
as
control,
3.
A
system
that
provides subordinate
files
should have
the
capability
to
automatically
update
these
file,
when
an
update
is
performed
on
the
master
file
to
which
they
are
subordinate.
1.3.2.5
INTERACTIVE
FILE
MAINTENANCE
CONTROL
Reference:
1.
These
criteria
are
highly
desirable
for
a
data
management system
that
supports
interactive
maintenance
from
on-line
terminals.
This
feature
provides
a
user
with
the
capability
to
override
established
data
validation
conditions
or
data
definition
in
an
on-line
interactive
mode.
247
REQUIREMENTS
OPERATING
SYSTEM
REQUIREMENTS
CHECKLIST
Reference
Initial
Extended
1,3.2.6
FILE
REORGANIZATION
(a-c)
The
sy-ten.
mus
allow
the
following
methods
of
re-
structuring:
(a)
field
additi
n,
(b)
deletion,
(c)
reordering.
(d-e)
The
system must
allow
the
following
types
of
merging:
(d)
intra-file,
(e)
inter-file.
248
1.3.2.6
FILE
REORGANIZATION
Reference:
1.
These
methods
are
frequently
found
in
data
management
systems
and
are
desirable
for
meeting
varying
file
design
requirements.
2.
Intra
file
merging
involves
the
changing
of
the
internal
structure
of
a
file
by
restructuring
and
merging
records
within
the
file.
inter
-file
merging
consists
of
merging
different
files
into
a
single
file
structure
which
will
better
satisfy
a
particular
application,
This
allows
the
user
to
build
master
flies
of
related
data
from
existing
singularly
used
files.
249
1.1.1
SCHEDULING
ALGORITHMIC
TIME INITIATED EVENT
INITIATED
PROGRAM
INITIATED
CONDITIONAL
SCHEDULING
CORE
STO
1.!1.1
SCHEDULING
1.1.1.2
SCHEDULING
1.1.1.3
SCHEDULING
1.1.1.4
SCHEDULING
1.1.1.5
SCHEDULING
1.1.1.6
QUEUE
MAINTENANCE
1.1.2.1
ALLOCATI
HARDWARE
ERROR
2.1
CONROL
ERROR
ERROR CORRECTION
'IOTIFICATION
ERROR
2.1.1
(HARDWARE)
2.1..
t1ARDWARE)
2,1.3
ERROR
RECOVERY
2.2.1
Ppr'G
COMPUTER
OPE
1.1 JOB
CONTROL
RESOURCE PROGRAM
1.1.2
ALL
CATION
1.1.3
LOADING
CORE
STORAGE
I/O
DEVICE
COMMON
ROUTINE
LOADING
SWAPPING
STRUCTURE
DISPATCHING
EVE
I
ALLOCATION
1.1.2.2
ALLOCATION
1.1.2.3
ALLOCATIOi'
1.1.3.1
CONTROL
1.1.3.2
CONTROL
1.1.3.3
CONTROL
1.1.4.1
CONTROL
1.1.4.2
SYI
DIAGNOSTIC
ERROR
2,0
PROCESSING
PROGRAM
ERROR INTERFACE
ERROR
2.2
G..r OL 2,13
CONTROL
ERROR REMOTE
TERMINAL
ERPOrC
:ORP[CTION
NOTIFICATION
PROGRAM
OPERATOR
KEY-IN
CONTROL
COMMUNICATION
, IP'
,'.RAMl
2.2.2
tPROGRAM)
2.2.3
TERMINATION
2.3.1
EDITING
2.3.2
COMMAND
EpIIrNC.
2.3.3
EDITING
OPiRATING
SYSI'M
PROGCAM
10
MANAGEMENT 2.0
AINTENANCE
rER
OPERATING
SYSTEM
FUNCTIONAL
CLASSIFICATION
STRUCTURE
PAR I,-VEXEC0,VE/ONTROL
FUNCTIONS
1.0
JOB
MANAGEMENT
(,
1.2
I0
CONTROL
EVE
NT
PROGRAM
DEVICE
114
ITORING
5 TEPJNATION
PROCESSING
1.2.1
I/O
SCHEDULING
1.2.2
DATA TRANSFER
1.2.3
MANIPULATION
INTERRUPT
TCHING
EVENT
PROCESSING PROGRAM
LIMIT BUFFERING DATA
CODE
T ROL
1.1.4.2
-
NCHRONIZATION
1.1.4.3
CONTROL
1.1.44
MNiN
221
COTROL
1222
TRANSLATION
TESTING
DEBU
3.1
TIMING
SERVICE 3.2 SERVICE
11 TIRMINAt
PRO45RAm
TO
I TI Nt
SCRSTM
LINK REAL-TIME
CLOTCK IN1EPVAL
I MER
STO.ACF
UJMP
1IAT
3.1"
SESTEM LI.2SEkC
.4 '
ERIFICATION
3.1.,
2EICE
,..1l.2
SEVIC
_ 32 1 2 ONTOk. .,2
IkA(INI .
L
PAT
11
YSTEM
MANAGEMENT
FUNC
[I-S
*
.\IT
f rNAN I
3.0
COMPI.ER INTERFACES
4.1
LITIIITIE5
CTLIRE
SYSTEM
L
1.3
COMM
UNICATION
DEVICE REMOTE
TERMINAL JOB
CONTROL
INPUT/OUTPUT RESOURCE
STATUS
.2.3
MANIPULATION
1.2,4
SUPPORT
1.3.1
SYSTEM
STR
P
1.3.2
COMMUNICATION
1,3.3
STREAM
CONTROL
1.3.4
MODIFICATION
1.3.5
I
SYSTEM
1.3.1.1
INITIALIZATION
1
.3.
1.2
SYSTFM
RESTART
3.0
PROCE15INC,
SUPPORT
PR
TESTING
(.)EBUGGING
LOGGING
AND
3. 5ERVICE
3.3 ACCOUNTING
34
M
MAI NTAININCG
MAINIAINING
CURRENT
'Y510.
$yS1EM
TEST
h'IOI
jO
06CHA
R(-'E
MAINTIlNI
NG
SyTIEM
UIILI,?AIION
STATIUS
IkA
I
N(.
M, I
CON,3
C*4TKL
3..1
INI
OIMAT!ON
3.1,2
Ek OR SIAIIS1I(.S I qAIISTIC
3.41
IN1ENRC)GA1I')N
SYSTEMRECOVERY
.3COMMUNICATION
4 PROCESSING
INPUT/OUTPUT RESOURCE STATUS SYSTEM
STATUS
3.3
STREAM
CONTROL
1.3.4
MODIFICATION
1.3.5
INTERROGATION
1.4.1
CHECKPOINTING
1.4.2
RESTARTING_
PROGRAM
INITIATED SVSTEM
INITIATED
DEVICE
1.4.2.1
RESTARTING
1.4.2.2
RESTARTING 1.4.2.3
REPOSITIONING
PROGRAM ACCESSISLE
SYSTEM
DESCRIPTION
3,4
MAINTENANCE
M A
IN T A I
N
NCAI, r
SI~m
STEM
I L AI'TN TAIUStEM
DERINITION
J IAISIL~3.4.1 INTEIk()O..A1 )N
3.4.
iNTR)WX)ATI-)N
2.1 CONTROL
ERROR
ERRO
CRECTION
NOTI
FICATION
2.1.1
(HADA)
2.1.2
(HARDWARE)
2.1.3
ERROR
RECOVERY
2.2.
t'
FILE MA
NAGEW
NT
1.1
FACI
1111
FILE
LOCATION
FILE
ACCESS RESIO&tATION
I1,1
4RECNITIQ
1..
CI
)N
RO 1.1.1 CAPABII ITIFS
fc.
the
fRwmp,;
S,*-.,,
ifsol.
A;,
foc.
:"e
FILE
SIECURITY RfEAWARITE
CONCRJRIf"T
SEOIANTI
w
~d.
Co4.,t
N.,.
-1.'I--128 1
21
N RO
11.2.1
ACCSffl C.ONTROL
1.1.2.3
ACSS
MCONTROL
PROGRAM
ERROR INTERFACE
ERROR
2.2
CONTROL
2.3
CONTROL
ERROR REMOTE
TERMINAL
ERROR CORRECTION
NOTIFICATION
PROGRAM OPERATOR
KEY-IN
CONTROL
COMMUNICATION
2.2.1
(PROGRAM)
2.2.2
(PROGRAM)
2.2.3
TERMINATION
2.3.1
EDITING
2.3.2
COMMANDEDITING
2.3.3
EDITING
OPERATING
SYSTEM PROGRAM
1.0
MANAGEMENT
2.0
MAINTENANCE
LIBRARY
AND
DIRECTORY
LOAD
1.1
SYSTEM
GENERATION
1.2
SYSTEM
MAINTENANCE
2.1
MAINTENANCE
2.2
GENE
1.0
DATA,
GEMENT
I/O
SUPPORT
, .2 FACILITIES
DATA
PILE
DATA
$LOCKINGG
DATA
ACCESS
DESLOCkING CONTROL
GENERATION
AID
I1.
1
CO
TRo.
1.2,2
CONTROk
1.2,3
LAIEL
PROCESSIN
1,l3,1
SPCIFICATION
1.3.2
MAINTENANCE
NT
I Ju(NTIAL
EIY(D
INIXI,
TLIPROCESSING
STRUCTUlRE SPACE
ItI,0T
1A
,6ACTION
LOGICAL
RECORD MA
.
'mO
L A ONTY
L
1,1.1.3
A(CES
COONTROL
1.3.2.1
DEFINITION
1,3,2,2
ALLOCATION
I
1,12
P OCEXSSING
I3.2-.4
MAINTENANCE
TESTIN D
3.1
TIMING
SERVICE
3.2
SERVIC
OTE TERMINAL PROGRAM TO
MUNICATION
SYSTEM
LINK
REAL-TIME
CLOCK
INTERVAL TIMER STORAGE DUMP
ING
2.3.4
VERII-CATION
3.1.1 SERVICE 3.1.2 SERVICE
3.2.1
CONTROL
3.2.2 TRACI6
L ART JI
"
SYSTFM
MANAGEMENT
FUNCTIONS
PROGRAM
MANAGEME
NT SUPPORT
0
MAINTENANCE
3.0
COMPILER
INTERFACES
4.0
UTILITIES
II
CTORY LOAD
MODULE PERIPHERAL
DEVICE SYSTEM
SIMULATION
SYSTEM MEASUREMENT STAND-A
2.2
GENERATION
4.1 SUPPORT
4,2
ROUTINES
4.3
ROUTINES 4.4 UTILITIES
SIMULA'1ON
SIMULATION
OF
TAND-ALONE
VOLUME
VOLLIME
OF
SYSI
EM
COMMUNICATION
STATUS
A.1.1
PREPARATION
4.1.2
MAINENANCE 4.2.1
FACILITIES
4.2.2
FACILITIES
4.4.1
DISPLAY
PART
III
- DATA
MANIPUIATION
FUNCTIONS
DATA
MANAGEMENT
II
DATA
QUALIFICATION
1.3.3
AND RITTIEVAL
134DT
?y
JWTEIACTI'.E
FILE
.41.lO.
IAINTENANCE
OILE
I 125
CONTROL
TESTING
DEBUGGING
LOGGING
AND
3.2
SERVICE
3.3
ACCOUNTING
MAINTAINING
MAINTA:
NI
NG
fENT ys
DUMP $,(STEM TEST MODE
J08
CHA
PGE
MAINTANING
SYSTEM
UTILIZATION
STATUS
OL
3.2.2
TRACING
CONTROL
3.2.3
CONTROL
3.3,1
INW ',RMATION
3.3,2
ERROR
STATISTICS 1.3-3 STATISTICS
3.4.1
INTERROGl',
UREMENT
STAND-ALONE
4.4
UTILITIES
STAND-ALONE
STAND-ALONE
STATUS
RECO%,ERY
4.4.1
DSPLAY
4.4.2
SUPPOrT
DATA
HANOL
ING
2.0
UTILITIES
2.1
DISPI. Y
ALII.TIfl
P.D
RA 'V
1,).dAT1 ()I X!Ut2MA!R
OfAR
1,1
WA
C('#'.
AA5
?
).
344C~T~T21 _______________ Lid1PITON
21PA
".J poltloTIWS &i3ICRTS
-
.*,. .*..T.
DI1PA~
__________________
PROGRAM
ACCESSIBLE
I'D
SYSTEM DESCRiPTION
.0
3.4
MAINTENANCF
MAINTAINING
CURRENT 'YSTEM
SYSTEM UTILIZATION STATUS SYSTEM
DEFINITION
s.S3_ STATISTIC,
3.4.1
INTERROGATION
3.4.2
INTERROGATION
SOtTtNG
AP'D
3.0
WV-ING
4~~~
-
*~ftt$A.
3E.
h
00t
MCSS~
S~ST MS~\
Security
Classification
DOCUMENT
CONTROL
DATA.-
R & L
(Securitv
classification
of
title,
body
of afstract
and
,rndex~ng
ainoetton
muIIJt
be
entered
w'hen the
ovrll
report
is rlasajod
ORIGINATING
ACTIVITY
(Corporate
author)
,4REQ SCUIY LA;FC TO
The COMTRE
Corporation
UCASFE
151
Sevilla
Avenue
b
RU
Coral
Gables,
Florida
33134
_______
3.
REPORT
TITLE
COMPUTER
OPERATING
SYSTEMS
CAPABILITIES;
A
SOURCE
SELECTION
AND
ANALYSIS
AID
4.
DESCRIPTIVE
NOTES
(T-ype
ot
epo..t
and
inclue~re
dates)
None
5.
AU
THORISI
(First
name,
middle
initial,
Iaat
name)
William
C.
Mittwede
6.RPOTDAE7. TC
'AL
NO1O
PAGES
lb.
NO.
OF REFS
November
1970
249
None
*a.
CONTRACT
OR
GRANT
NO,9.
ODIGINATORS.7EPORT
NUMISERIS)
F19628-70-C-0258
b.
PROJECT
NO
ES
D-TR-71
-74
6917__
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_
C.
9.
OTHER
R
EPORT
NO'St (Any
other
rmrnbare
that
my
beooms
this
nvprt)
d.
10
DISTRIOUTION
STATEM.ENT
This
document
has
been
cppraved
for
public
release
and
sales;
its
distribution
is
unlimited.
11
SUPPLEMENTARY
I
TCS
la
SPONSORING
MILITARY
AC
TIIYI
Deputy
for
Command
and
Management
Syster
Hq
Electronic
Systems
Division
(AFSC)
________ABSTRACT__________
L
G
Hanscom
Field,
edford,
Mass.
01730
TisI
reporl
presents
a
method
for
translating operatiorial
data
processing
requirements
into
specific
criteria
for
use
in
se
t
ecting,
volidr'ting
or
evaluating
computer
operating
systems.
The
criteria
have
,*n
structured
on
the
basis
of
an
integrated
functional
classification
structure
applicable
to the
executive/control
functions,
system
management
functions
and
data
manipulation
functions of
currently
available
operating
systems.
In
concert
with
the
methodology
presented,
a
checklist
form
is
included
as
on
aid
to
developing selection
criteric
for
particular applications.
A
diagram
of
the
functional classification
structure
is
also
npii!udod.
DD~o
0,S~1473
Security
Classification
14
LINK
A
LINK
8
LINK
C
EY
WCIPD5
• -4
51OLE
WT
ROLE
W,
ROL
E
WT
opemting
systems
(computer)
specificiation
evaluation
validation
analysis
selection
guidelines
identification
Security
Claisilication

Navigation menu