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

Download
Open PDF In Browser	View PDF

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
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 supplied 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.
/,//.

* BEAUCHAMP'
Pfoject Officer

AL RED

EDMUND
R
USAF
Director, Syste
Design & Dev
Deputy for Command & Management Sys

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

1.1 Purpose
1.2 Scope

1
2

ofIco'lon jnJ LvaluQ1;un Guidelines
2.1
2.2
2.3
2.4

Section III

Operating System Requirements Identification
Evaluation of the Environment
Basic Performance Decisions
Use of the Selection and Evaluation Criteria

3
3
5
8

Specification ind Evaluation Criteria

3.1 Introduction
3.2 Requirements Checklist - Part I - Executive/
Control Functions)
3.2.1 First Level of Detail (Part I - Executive/
Control Functions)
3.2.2 Second Level of Detail (Part I - Executive/
Cont"I Functions)
3.2.3 Thira Level of Detail (Part I - Executive/
Control Functions)
3.2.4 Fourth Level of Detail (Part I - Executive/
Control Functions)

3.3 Requirements Checklist - Port II - System Management Functions
3.3.1 First Level of Detail (Part II - System
Management Functions)
3.3.2 Second Level of Detail (Part II - System
Management Functions)
3.3.3 Third Level of Detail (Part II - System
Management Functions)
3.4 Requirements Checklist - Part III - Data Manipulation
Functions
3.4.1 First Level of Detail (Part III - Data Manipulotion Functions)
3.4.2 Second Level of Detail (Part III - Data Manipulation Functions)
3.4.3 Third Level of Detail (Part III - Data ManipL.lotion Functions)

11
11
19
43
109
149
149
159
175
185
185
193
205

3.4.4 Fourth Level of Detail (Part III - Data Manipulation Functions)
Attachment I -Computer Operating System Functional Classification Structure

235

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 classification 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.
Inthis 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 requirements 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 specification 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
, 1, -,
ussociated .eferences as an aid in e--

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 completeness. 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. Sectlon 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.

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.
wt
,C"

vauating the system environment.

The first step consists

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.

It is very important in the further development of specific requirements to characterize 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 workload 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 normal 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 application 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 exhibited by the application programs.

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 development 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 requirements. Previous analyses of various oper. ring s,stems has shown that the occurrence 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-

sight into the totad operational philciophy of the system and directly affect the applicobility 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 multiFor 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
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

i:;

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 consideration 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 multiprogram 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 requirements will be, whether on-line maintenance or periodically scheduled off-line maintenance will be required, and whether on-line o- off-line program checkout will be

necessary. If the system isto 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 timesharing 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 intervention or will the operating system be as independent as possible requiri,

very little

operator intervention?
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

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 consider 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 perform 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 specification 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

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 hierarchical levels and are presented for each of the three major functional areas (Executive/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 restrictive for a competitive procurement.
A word of caution should be interjected at this point: The requirements checklist 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 checklist, 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 checklist. 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, mandatory, 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 compeling 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.

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

Reference

REQUIREMENTS CHECKLIST

JOB MANAGEMENT

(a)

Batch processing support m ist be provided.

(b)

Real-time support must be provided.

(c)

Time-sharing support must be provided.

Multiprogramming support must be provided.

(e)

Multiprocessing support must be provided for
processors.

1.0

i
12ii

Initial

Extended

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 subfunctions consist of: job control, input/output control, system communication,
and recovery processing.

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. Normally, 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 processing) or those that are communication based systems using multiple terminals
and requiring multiprogramming techniques due to the large number of concurrent messages received.
4.

This criterion is entirely dependent upon the hardware configuration and
can only be specified when the configuration is known.

RE QU IREM ENT S
NT S '
E
M
nn

OPERATING SYSTEM
REQUIREMENTS CHECKLIST

Reference

DIAGNOSTIC ERROR PROCESSING

(a)

The system must provide hardware error control.

(b)

The system must provide program error control.

(c)

The system must provide interface error control.

(d)

The system must provide error recovery procedures.

2.0

Initial

Extended

2.0

DIAGNOSTIC ERROR PROCESSING
Reference:
1. The diagnostic error processing function is responsible for recognizing hardware, program cnd interface errors. Recognition is usually based upon hardware 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.

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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
3.0

PROCESSING SUPPORT

Reference
I

(a)

The system must provide a timing service.

(b)

The system must provide testing/debugging service.

(c)

The system must provide a logging and accounting
service.

(d)

The system must provide system description maintenance.

Initial

Extendc...

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 convenient, rather than necessary, functional support.

Most systems have an internal timing device which provides timing services to
application programs. A few systems, to reduce the size of the resident supervisor, 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.

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.

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
1.2
1.3
1.4
2.1
2.2
2.3
3.1
3.2
3.3
3.4

JOB CONTROL
I/O CONTROL
SYSTEM COMMUNICATION
RECOVERY PROCESSING
HARDWARE ERROR CONTROL
PROGRAM ERROR CONTROL
INTERFACE ERROR CONTROL
TIMING SERVICE
TESTING/DEBUGGING SERVICE
LOGCING AND ACCOUNTING
PROGRAM ACCESSIBLE SYSTEM DESCRIPTION MAINTENANCE

REQUIREMEI !TS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST

(a)

JOB CONTROL
1.1
The system must provide support for the concurrent
execution of up to

(b-c)

Reference
1
2

batch jobs.

Batch support must be provided for:
(b)
(c)

cen'.ral site job entry,
remote job entry.

(d)

The system must support
terminals.

remote job entry batch

(e)

The system must provide support for the concurrent
real-time jobs.
execution of up to

(f)

The maximum service time for a real-time request
under average load conditions is

(g)

The maximum service time for a real-tlme request
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
time-sharing jobs.
execution of up to

(j)

The system must support, at a maximum, simultaneous
terminals.
submission of jobs from

(k)

The system must support, on the average, simultaneous
terminals.
submission of jobs from

(I-m)

The system must provide a response to interactive
terminals within a time frame

(I) of

during maximum load conditions,

(m) of-during average load conditions.

Initial

Extended

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 specified. 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 configuration, 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.

This criterion should be specified when system response time requirements are
known.

This criterion should be specified for a time-sharing sysgm.

REQUIREMENTS
OPERATING SYSTEM
Reference

REQUIREMENTS CHECKLIST
1.2

1/0 CONTROL

1,2

must support I/0 scheduling.

(a)

The system

(b)

The system must provide support for up to
terminals.

(c)

The system must permit the concurrent activity of up
remote terminals.
to

(d)

The system must provide support for up In
devices.

(e)

The system must support the concurrent operation of up
devices.
to

(f)

The system must provide support for up to
processors or channels.

(g)

The system must support the concurrent operation of up
I/0 processors or channel.
to

The system must support the following device types/
number of device types:

(h-o)

(h)
(i)

(j)
(k)
(I)
(m)

(n)
(o)

remote

I/0

direct access storage devices,

4,5

I/0

unit record devices,
paper tape units,
magnetic tape units,
typewriters,
-console
display devices,
___plotters,
extended core storage.

inl;ial

Extended

1.2

I/O CONTROL
Reference:
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 programmer 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.
1.

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.

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.

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.

This value should be de' rmined by the anticipated utilization under peak
loading conditions.

This criterion is highly dependent upon the hardware configuration and can
only be specified in detail when the hardware configuration is known.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.3

Reference

SYSTEM COMMUNICATIONI

(a)

The system must permit up to
displays.

operator terminals/

(b)

The system must permit up to
displays.

user term'inals/

(c-f) The system must support the following types of
operator and user communication devices:
(c)
(d)
(e)
(f)

card reader,
console typewriter,
typewriter-CRT display,
ty pewriter-printer.

2
3
4
4

(g)

The system must provide device independent communication formats.

(h)

System startup must be provided.

Initial

Extended

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.

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 preparation. Consequently, it should be seriously considered during the development of specifications or during the e, :!-gotion of system proposals.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.4

RECOVERY PROCESSING

(a-b) The system must provide checkpoint/restart facilities
at the following levels:
(a)
(b)
(c)

Reference

1,2
3

program,
system.

The system must provide restart for all suspended
programs.

Initial

Extended

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, checkpoint/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 processing or time-sharing system, on the other hand, checkpoi,;jrestart facilities
are most likely to be initiated at the program level.

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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
2. 1

HARDWARE ERROR CONTROL

Reference
1

(a)

The system must provide for error correction.

(b)

The system must provide error notification.

(c)

The system must provide for recovery from hardware
errors.

(d-i) The system must detect the following hardware errors(d)
(e)
(1)
(g)
(h)
(i)

CPU errors,
I/0 device errors,
I/0 channel or I/0 processor errors,
storage parity errors,
co-processor errors,
power failure.

Initial

Extended

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.

Generally, error correction is performed by retrying a failing operation and, if
this fails, relyng upon analternate method of accomplishing the cperation.

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 interactive user.

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.

Indications of CPU errors, I/0 device errcr, I/0 channel errors, parity errors,
and power failures are generated by almost every hardware system.

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 extent of the do,.ge,
and the recovery procedures that can be inv,'od. Error recovery for u mnultiprocessor configuration is more complicated (by an order of cnagnitude) than
for uni-processing sys'ems.

REQUIREMENTS
wE12:z=

OPERATING SYSTEM
_____________REQUIREMENTS

CHECKLIST

Reference

PROGRAM ERROR CONTROLr

2.2
(a)

The system must provide for program error correction.I

(b)

The system must provide program error not ificai -on.

(c)

The systein must provide control led abnormal program

terminations,
(d-j) The system must detect the foi~owing types of error:
(d)
(e-g)

(h!
(i)

n-rithmetic errors,
Instruction errors:
(e) invalid insfruction,
'f) unsupported instruction,
(g) privileged instruction,
invalid address errors,
storage protecton errors,

() invalid data errors.7

4
5

6
6

IInitial

Exlended

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

This function is highly desirable in batch and time-sharino systems. In a realtime environment, a form of error recovery, rather than abnormal termination,
should be considered.

These criteria are dependent upon the hardware configuration and can only be
specified in detail when the hardware configuration is known.

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.

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 application 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. Timesharing systems that process classified or private information should always
storage protect this information and notify the operator of any violations.

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.

REQUIREMENTS
OPERATING SYSTEM

REQUIREMENTS CHECKLIST
2.3

Reference

INTERFACE ERROR CONTROL

(a)

The system must edit operator key-ins.

(b)

The system must edit input stream control commands.

(c)

The system must edit remote terminal communications.

(d)

The system must edit program to system linkages.

Initial

Extendea

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

REQUIREMENTS
-

OPERATING SYSTEM
REQUIREMENTS CHECKLIST
3.1

TIMING SERVICE

Reference
I

(a)

The system must provide real.-time clock services.

(b)

The system must provide interval timing services.

Initial

"s
Extended

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, however 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 processing jobs must be completed. In real-time systems, it may be used either
for job scheduling or for distinguishing event occurences (e.g., message timestamping). Time-sharing systems have no particular requirement for a realtime 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 timesharing 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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
3.2
(a)

Reference

TESTING/DEBUGGING SERVICE

The system must provide storage dumps.

(b) The system must provide tracing facilities.
(c)

-24

The system must provide a special test/debuj
operating mode.

I
2
3

Initial

Extended

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. Specification of the criteric , should be dependent upon the anticipated level of program testing that will be performed.

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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLST
3.3

Reference

LOGGING AND ACCOUNTING

(a-c) The system must maintain:
(a)
(b)
(c)

job charge information,
error statistics,
system utilization statistics.

1
2
3

Initial

Extended

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 utilizotion, etc. Consequently, this criterion should be specified -or these two
environments.

It is usually highly desirable to accumulate error statistics in order to identify hardware devices that have a greater than normal frequency of intermittant
errors. As a result this criterion should be considered for all processing
systems.

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.

OPERATING SY

REQUIREMENTS
'
"

REQUIREMENTS CHECKLIST
3.4

PROGRAM ACCESSIBLE SYSTEM
DESCRIPTION MAINTENANCE

Refe',-.nce
I

(a)

The system must maintain current system status information.

(b)

The system must maintain currcnt system description
information.

(c)

The system must provide for the extraction of system
description information by a user program.

Initial

Extended

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.

System status information may be of use to installation monitoring or accounting 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.

This information is useful when there are general purpose programs or
compilers in operation that have the cap&.siiity of alternate modes of operation based upon hardware and sofi'are status. For example, sort programs
are usually designed to use all of the core areu available.

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
1.1.2
1.1.3
1.1.4
1. 1.5
1.2.1
1.2,2
1.2.3
1.2.4
1.3.1
1.3.2
1.3.3

1.3.4
1.3.5
1.4.1
1.4.2
2. 1. 1
2.1.2
2. 1.3
2.2.1
2.2.2
2.2.3
2.3.1
2.3.2
2.3.3
2.3.4
3.1.1
3.1.2
3.2.1
3.2.2
3.2.3
3.3.1
3.3.2
3.3.3
3.4.1
3.4.2

SCHEDULING
RESOURCE ALLOCATION
PROGRAM LOAD!NG
EVENT MONITORING
PROGRAM TERMINATION PROCESSING
I/O SCHEDULING
DATA TRANSFER
DEVICE MANIPULATION
REMOTE TERMINAL SUPPORT
SYSTEM STARTUP
JOB CONTROL r" WMUNICATION
,EAM CONTROL
INPUT/OUTPUT
RESOURCE STATUS MODIFICATION
SYSTEM STATUS I NTRROGATION
CHECKPOINTING
RESTARTING
ERROR CORRECTION (Hardware errors)
ERROR NOTIFICATION (Hardware errors)
ERROR RECOVERY (Hardware errors)
ERROR CORRECTION (Program errors)
ERROR NOTIFICATION (Prgram errors)
PROGRAM TERMINATION
OPERATOR KEY-IN EDITING
CONTROL COMMAND EDITING
REMOTE TERMINAL COMMUNICATION EDITING
PROGRAM TO SYSTEM LINK VERIFICATION
REAL-TIME CLOCK SERVICE
INTERVAL TIMER SERVICE
STORAGE DUMP CONTROL
TRACING CONTROL
SYSTEM TEST MODE CONTROL
MAINTAINING JOB CHARGE INFORMATION
MAINTAINING ERROR STATISTICS
MAINTAINING SYSTEM UTILIZATION STATISTICS
CURRENT SYSTEM STATUS INTERROGATION
SYSTEM DEFINITION INTERROGATION
-

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.1.1

SCHEDULING

RPerence

(a)

The system must provide an algoriihmic scheduling
capability.

2,7

(b)

The system must provide a time-initiated scheduling
capability.

(c)

The system must provide an event-initiated scheduling
capability.

(d)

The system must provide a program-initiated
scheduling capability.

(e)

The system must provide conditional scheduling.

(f)

The system must recognize up to
priority levels.

(g-k)

Batch scheduling must be permitted from the
following sources:
(g)
(h)
(i)

(j)
(k)
(I)

scheduling

local input s~ream,
remote input stream,
a,, executing interactive job,
an executing real-time job,
another executing batch job.

The system must provide scheduling for programs
and/or subprograms which will be consistent with
the desired sequence of operations.

8
9,5
9,5
9,5
10

Initial

Extended

1.1.1

SCHEDULING
Reference:

The purpose of the scheduling function is to select a job which is available 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 scheduling 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 introduced 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 realtime jobs.
The batch scheduling philosophy of an extended multiprogramming system
allows jobs submitted from more than one input stream to cam F te for execution assignment. Under this philosophy a scheduling queue on an intermediate 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.

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 specified for all extended multiprogramming systems.

REQUIREMENTS
OPERATING SYSTEM
Reference

REQUIREMENTS CHECKLIST
1.1.1

SCHEDULING (repeated)

(a)

The system must provide an algorithmic scheduling

2,7

(b)

The system must provide a flmi.-initiated scheduling
capability,

(c)

The system must provide an event-initiated scheduling
capability.

(d)

The system must provide a program-initiated
scheduling capability.

(e)

The system must provide conditional scheduling.

(f)

The system must recognize up to
priority levels.

(g-k)

Batch scheduling must be permitted from the
following sources:
(g)
(h)
(i)

()
(k)
(I)

scheduling

local input stream,
remote input stream,
an executing interactive job,
an executing real-time job,
another executing batch job.

8
9,5
9,5
9,5

Tk system must provide scheduling for programs
and/or subprograms which will be consistent with
the desired sequence of operations.

---

Initial

Extended

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.

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 timesharing sysiems.

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.

Conditional scheduling permits the user to specify scheduling parameters
which must be satisfied before the program can be initiated. These parameters 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.

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. Timesharing 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 environment will probably be required.

This criterion is dependent upon the hardware configuration and can only be
specified when the hardware configuration is known.

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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
RESOURCE ALLOCATION

The system must allocate and prevent conflicts for,
the following resources:

1.1.2
(a-d)

(a)
(b)
(c)
(d)
(e-g)

permanent assignment,
static (job stream) requests,
dynamic (execution time) requests.

4
5
6

The allocation of I/0 devices must be by:
(h)
(i)

()
(k-I)

core storage,
I/O devices,
data files,
common routines.

Extended

Initial

The allocation of core storage must be by:
(e)
(f)
(g)

(h-i)

Reference

permanent assignment,
static (job stream) requests,
dynamic (execution time) requests.

4
5
6

The allocation of data files must be by:
(k)
(I)

static (job stream) requests,
dynamic (execution time) requests.

48_

5
6

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 allocation of CPU time to a program is called dispatching and is covered
separately under Section 1.1 .4.

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 timesharing environments.

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.

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.

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

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
1.1.3

PROGRAM LOADING

(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
Following sources:
(b)

syst--n library,

(d)
(e)

input s1ream,
temporary library (e.g., compiler
output file).

Reference

user Ilibrary,

(f)

The system must provide facilities for absolute
loading.

(g)

The system must provide facilities for relocatable
loading.

Initial

Extended

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 various 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 executable 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 mLItiprogramming and serial processing systems where the assigned program execution
area is relatively static (such as a fixed background partition). Relocatable ioaders 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.

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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1. 1.4

Reference
I

EVENT MONITORING

(a)

The system must provide fixed time-slice dispatching.

The system must provide variable time-slice dispatching4

(c)

The system must provide contention (priority)
lispatch ing.

(d)
(e)

The system must provide event synchronization.
distinct external
'he s tem must recognize up to

3
4

interru s.
interrupt levels.

(f)

The system must recognize up to

(g)

The system must provide limit monitoring.

4
5

Initial

Extended

1.1.4

EVENT MONITORING
Reference:
1.

Event monitoring refers to the control the operating system maintains over executing programs. The function includes: dispatching control, interrupt processing
control, event synchronization, and program limit monitoring.

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 execution 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. Consequently, 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: ;Pplication, it may be desircble to consider the dispatching technique during initial
criteria specification.

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-,ecution are I/O completions, selected time intervals, subtosk completions, c' a
unsolicited key-ins.

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.

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.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.1.5

PROGRAM TERMINATION PROCESSING

Reference
I

The system must deallocate all resources at program
termination.

(b-e) The system must provide summaries of the following
information:

(a)

(b)
(c)
(d)
(e)

error statistics,
CPU time utilization,
device utilization,
file access statistics.

(f-i) The system must provide the fo!lowing options at
abnormal termination:
(f)
(g)
(h)
(i)

durw. core,
dump files,
execute a specified program,
initiate recovery procedures.

4
4
5

(j)

The system must notify 'he operator of abnormal
terminations.

(k)

The system must notify remote terminal users of
abnormal termintions.

Initial

Extended

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 circumstances. 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 termination 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.

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.

REQUIREMENTS
.

OPERATING SYSTEMA
kQUIREMENTS CHECKLIST
1.2.1

I/O SCHEDULING

(a)

The system must provide immediate scheduling of
I/O requests.

(b-e)

The system must permit specific device assignment
from the following system external sources:
(b)
(c)
(d)
(e)

Reference

input stream (control statement),
the operator,
a program,
interactive user.

(F)

Specific device assignment must be the responsibility
of the system.

(g)

The system must provide queuing of input requests.

(h)

The system must permit specification of device
priority.

(i)

Ihe system must permit the specification of I/O
request prioriies.

(

The
i system must attempt to route I/O to a specific
route , rni. ri t roule
device via u,. ,
is busy or disabled.

(k)

The system must provide facilities for alternate
device selection.

(I-m)

The system must provide facilitics for initiating

Glternate device selection:
(I)

automatically,

(M)

by the cperator.

Initial

Extended

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.

Operator assignment of devices is highly desirable in most processing
systems to permit an override of other assignment techniques due to
unusual workloads.

Specific device assignment by the system is a dynamic method of selection
which increases system throughput. This can be associated with multiprogram 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.

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 requirement may also exist For some terminals to have priority over other
terminals during system operation.

This criterion should be specified for most real-time processing systems.

This criterion is highly desirable for a real-time processing system; however, it is highly dependent upon the hardware configuration and can
only be specified in detail when the hardware configuration is known.

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.

REQUIREMENTS
.'ERATING SYSTEM
REQUIREMENTS CHECKLIST
1.2.2

Rrfrence

The system must provide buffer control.

(b)

The system must permit data code translation during
data transfer.

(c-f) The system must process the following
record types:

(g)

Extended

DATA TRANSFER

(a)

initial

fixed length records,
variable length records,
undefined length records,
character string records.

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.

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.

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

REQUIRE MENTS
Inm=-

()PERATINr- SVSIEM
REQUIREMENTS CHECKLIST
-

1.2.3

DEVICE MANIPULATION1

(a-d) The system must provide facilities for:
(a)
(b)
(c)

rope positioning,
disk positioning,
card stacking,

(d)%

page ejecting.

Reference

Initial

Extended

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.

RLQUIR EMENTS
OPERATING SYSTEM

1.2.4

REQUIREMENTS CHECKLIST

Reference

REMOTE TERMINAL SUPPORT

(a)

The system must permit interactive communications.

(b)

The system must permit terminal to terminal communications.

(c)

The system must permit terminal to operator communlications.

(d)

The system must permit operator control over remote
terminal activity.

(e)
(f)

he system must allow slaved remote terminals.
The system must provide a remote batch communication
mode.

5
6

Initial

Extended

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.

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.

This feature should be specified for all processing systems that support
remote terminals.

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.

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.

This criterion should be specified for all remote batch applications.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.3.1

Reference

SYSTEM STARTUP

(a)

Startup of the entire system must be provided.

(b)

Startup on a partition by partition basis must be
provided.

(c)

The system must allow the use of cctaloged startup
procedures.

(d)

The system must provide a capability during startup
for respecification of parameters specified at system
generation ime.

(e)

The system must permit specification of device
availability during startup.

(f)

The system must permit controlled system reconfiguration during startup.

(g)

The system must provide full system restart procedures.

(h)

The system must schedule user initiation programs.

(i)

The system must request time/date specification.

(j)

The system must permit manual initiation of symbionts.

(k)

The system must provide automatic initiation of
symbionts.

Initial

Extended

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.

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.

This criterion should be specified where startup requirements are extensive
and consistent.

This feature i: highly desirable in most 1 rocLsslng systems since it
provides flexibility in tailoring a system to meet daily requirements.

This criterion should be specified for configurable processing systems.

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.

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.

Automrti -ymbiont initiation is generally .dvisable for output symbionts
whereas n.,,nual initiation is more desirable for input syrnbionts.

1
OPERATING

SYSTEM

REQUIREMENTS CHECKLIST
1.3.2

JOB CONTROL COMMUN!CATION

(a-d) The system must provide control of user jobs from the
following interactive sources:
(a)
(b)
(c)
(d)

REQUIREMENTS

Reference
1
2

the batch job submitter,
the operator,
interactive users,
other executing jobs.
separate input

(i)

The system must permit up to
stream devices.

(f)

The system must provide for the use of cataloged
procedures.

(g)

The system must provide procedures for modifying
cataloged procedures.

(h)

The system must provide for conditional execution
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).

Initial

Extended

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 communication is generally non-interactive, whereas in time-shcr-rg systems it is
almost always interactive. Operator/system communication is predominantly interactive.

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.

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.

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.

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.

This criterion should be specified for most batch processing and time-sharing
systems.

RE QU IREM ENT S
ENT
-

OPERATING SYSTE
REQUIREMENTS CHECKLIST
1.3.3

INPUT/OUTPUT STREAM CONTROL

Reference
I

(a)

The system must provide input strecm control by
symbiont processing.

(b)

The system must provide output stream control by
symbiont processing.

(c)

The system must provide for the processing of up to
___input streams.

(d)

The system must allow up to ____output streams to
be maintained.

(e)

The system must provide automatic editing of control
command formats.

(f-j)

The system must allow the following output stream
elements:
(f)
(g)
k;.%
(i)

()

diagnostic messages,
trace control listings,
data,
core dumps,
file dumps.

Initial

Extended

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

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 physically 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 techniques. 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.

This criterion is highly dependent upon the hardware configuration and con
only be specified in detail when the hardware configuration is known.

This criterion is highly desirable for all batch processino systems.

REQUIREMENTS
OPERATING SYSTWM
REQUIREMENTS CHECKLIST
1.3.4

RESOURCE STATUS MODIFICATION

(a-e) The system must provide control for on-line configuration modification of the following resour, s:
(a)
(b)
(c)
(d)
(e)

The system must permit operator control of systen
configuration through operator console.

(g)

The system must permit user control of system resource
ccnfiguration.

(h-I)

The system must recognize the following device
condt ons:
(h)

available,

(i)

down,

()

assigned,
reserved,
test mode.

(m)

addition,

(n)
(o)
(p)

deletion,
replaceinent,
s"Vtching.

(m-p) The system must permit the following types of
resource modification:

(q)

peripheral devices,
mass storage allocation,
core storage allocation,
CPU time allocation,
input job queues.

(f)

(k)
(I)

Reference

The system mus allow reconfiguration in the event
of fnalfunct*on arid maintain continuity of ot .ration.

initial

Extended

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 maintenance, 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 available to the system during system operation. This is frequently accomplished via
direct operator console commands to the operating system supervisor.

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

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.

Test mode recognition should be specified if on-line diagnostics are
supported by the system.

Replacement is a manual technique while switching is normally used for
automatic transfer to a standby on-line device.

This criterion is highly desirable for a real-time processing system.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.3.5

SYSTEM STATUS INTERROGATION

(a)

The status of the system must be displayed continuously.

(b-c)

The status of the system must be displayed upon
request on a:
(b)
(c)

(d-i)

(g)
(H)
()
(j-m)

(k)
(!)
()

identification of current users,
resource status,
job status (executing, waiting,
suspended, etc.)
job ..,formation (priority, title, etc.)
input job queue status,
output job queue status.

The system must display causes of processing delays
to include:

()

CRT,
printer.

The system must provide facilities to display the
following information:
(d)
(e)
f)

Reference

peripheral non-avoilability,
data non-availability,
memory non-availability,
CPU delays due to unavailability
of resources.

Initial

Extended

1.3.5

SYSTEM STATUS INTERROGATION
Reference:
1. The computer operator isusually 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 considerably 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.

This feature is very important to a facility in determining where hardware or
software changes can be applied to improve operation.

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.4.1

Referer1 ue

CHECKPOINTING

(a-d) The system must provide checkpoint initiation from
the following external sources:

(a)
(b)
(c)
(d)

control card,
system,
operator,
interactive user.

(e)

The system must permit checkpoint initiation by the
program itself.

(f)

The system must permit checkpoint initiation by other
programs.

(g-1) The system must provide checkterrogation,
report development.

(e-f) The system most provide data management facilities that
operate in the following modes:
(e)
(f)

Reference

batch,
in.eractive.

196

Initial

Extended

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 interactive mode.

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.

This criterion is directly derived from the intended operational environm

197

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
2.1

DISPLAY FACILITIES

Reference
I

(a)

The system must allow formatted display.

(b)

The sy4 em must allow unformatted display.

(c-e)

-e system must provide utilities for the foilowing
types of display devices:

( N
(d)
(e)

L.2

printer,
typewriter,
CRT.

PERIPHERAL DEVICE SUPPORT

(a-d) The sys i must p. vide the following peripheral device
support f,ci Iities:
(a)
(b)
(c)
(d)

volume positioning,
media copying,
data editing,
tet data file support.

I
2
3

193

Initial

Extended

2.1

DISPLAY FACILITIES
Reference:

2.2

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.

This mode of display is advantageous when the recipient is concerned with the
contents of the data being displayed, rather than its machine structure.

This function is very important if a picture image of the exact data structure
is required.

The printer is the most frequent means of displaying data.
user may only have a typewriter or CRT available.

However, a remote

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.

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.

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
Reference

REQUIREMENTS CHECKLIST
3.1
(a)

SORT MODULE DEVELOPMENT

The system must provide a tailorable general purpose
sort program.

(b-c) The system must provide parameter specification by:
(b)
(c)

control cards,
internal linkage parameter.
3

(d)

The system must determine the aliccation of internal
workspace.

(e)

The system must albw a supplied parameter to determine
internal workspoce allocation.

(f) The system must determine external workspace allocation

(g)

The system must allow a supplied parameter to determine
externor workspace allocation.

(h-j) The system must provide the. following options:
(h)
(i)

(i)

ascending/descending outpu sequence,
single/multiple sort control fields,
single/mixed data field formats.

(k-n) The system must recognize the following field keys.
(k)
(I)

alphanumeric,
binary,

(m)

zoned,/packed aeclr.ol

floating point.

200

Initial

Extended

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

It is generally advisable to have the sort program recognize every type of data
element representation ptrmitted within the system

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
3.2

Reference

SORT MODULE EXECUTION

(a-c) The system must provide the following types of sorting:
(a)
(b)
(c)
(d)

full data records (record sort),
sort key and record address (tag sort),
sort key and selected fields (field select
sort).

The system must provide control for workspace overflow.

(e-i) The system must permit the inclusion of user codes
relative to:
(e)
(f)
(g)
(h)
(i)

!'bel processing,
input record insertion/modification/deletion,
output record insertion/modification/
deletion,
blocking/deblocking control,
error processing

(j)

The system must provide an automatic final pass
sequence check.

(k)

The system must provde an optional final pass sequence
check.

202

Initial

Extended

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 &,asorting; 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.

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
1.1.2
1.1.3
1.2.1
1.2.2
1.2.3
1.3.1
1.3.2
1.3.3
1.3.4
2.1.1
2.1.2
2.2.1
2.2.2
2.2.3
2.2.4

FILE LOCATION RECOGNITION
FILE ACCESS CONTROL
BACKUP AND RESTORATION CAPAB".ITIES
DATA ACCESS CONTROL
DATA BLOCKING/DEBLOCKING CONTROL
LABEL PROCESSING
CONTROL SPECIFICATION
DATA FILE GENERATION AND MAINTENANCE
DATA QUALIFICATION AND RETRIEVAL
DATA OUTPUT
UNFORMATTED DISPLAY
FORMATTED DISPLAY
VOLUME POSITIONING
MEDIA COPY FACILITIES
DATA EDITING FACILITIES
TEST DATA FILE SUPPORT

205

REQUiREMEki.)
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
1.1.1 FILE LOCATION RECOGNITION
(a-b) The system must provide for locating files using the
fol lowing methods:
(a)
(b)

cataloged addresses,
label recognition.

1
2
2

(c-d) The system mubt use a File identifier which is:
(c)
(d)

Reference

system assigned,
user assigned.

(e)

The system must support multiple cataloging levels.

4,2

(f)

The system must maintain separate catalogs.

5,2

206

Initial

Extended

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.

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.

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 responsibility ,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.

Some systems provide multiple levels of cataloging. Though not
extensively used, this feature may be of advantage when a hierarchical 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 operational 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.

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
1.1.2

FILE ACCESS CONTROL

The system must provide file security control.

(b)

The system must provide read/write access control.

(c)

The system must provide concurrent access control.

(d-h) The system must provide file access protection for the
following units:

(i-j)

(j)

3
4

volumes,
files,
physical records,
logical records,
data elements.

The system must provide for acces!; control maintenance:
(i)

Reference
1

(a)

(d)
(e)
(f)
(g)
(h)

5
2

by system supervisor,
by programming conventions.

208

Initial

Extended

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.

This criterion should be specified For all processing systems that maintain classified or private information.

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 desirable to
grant any number of them read-only access, but to restrict ,v'ite
access to a single user at a tine.

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.

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

1. 1.3 BACKUP AND RESTORATION CAPABILITIES
(a-b) The system must support the following backup media:
(a)
(b)

on-line devices,
off-line devices.

I
2

(c-d) The system must provide the following restoration
techniques:
(c)
(d)

automatic,
operator in*tiated.

(e-g) The system must provide the folowing File backup
techniques:
(e)
(f)
(g)

grandfather files,
periodic checkpoints,
retention of transoct*.n data.

21.)

Initial

Extended

1.1.3

BACKUP AND RESTORATION CAPABILITES
Reference:

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

Thi: -rite,'ion is highly desirable for a real-time processing system.

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 commercially oriented jobs.
Periodic checkpoints are used as a backup technique in many real-time
processing environments. However, the file maintained on the checkpoint 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
1.2.1

sequential,
random (direct),
keyed,
indexed,
teleprocessing.

I
2
3
4
5
6

(f-r) The system must permit data access at the fo!lowng
levels:
(f)
(g)
(h)
(i)

Reference

DATA ACCESS CONTROL

(a-e) The system must support the following access methods:
(a)
(b)
(c)
(d)
(e)

block,
record,
data item,
character.

212

Initial

Extended

1.2. I

DATA ACCESS CONTROL
Reference:
1.

The specification of these criteria is highiy dependent upon the
system hardware configuration.

Sequential access methods process records serially and read or write
them consecutively on a storage volume. Sequential access may be
provided for data stored on any secondat, storage medium; although,
certain storage media, such as magnetic tape, obviously dictate a
file organization of this type.

Random access methods read and write records without regard to the
physical sequence in which they are stored. Consequently, records
stored in this type of organization must have some type of identificc,..on code that will enable the record location to be determined.
Usually, an algorithm is used to convert a unique record identification into a unique storage address on a random access storage
device.

Keyed access methods rely on a selected data field within each
record to uniquely identify the record. This data field, called the
record key, frequently corresponds to the record identification code,
though it need not do so. Keyed access is useful for secondary
storage devices which have a physical design that features hardwareimplemented search instructions. In such systems, a record request
will cause the read/write mechanism of the storage medium to scan
the entire file in search of a selected record key. The technique
is advantageous since processor time need not be spent in scanning
secondary storage and may thus be employed with other execution
functions. The technique is also frequently augmented by software
which isolates a portion of the file prior to issuing the keyed search
in order to avoid a scan of the entire file.

Indexed access methods create and maintain files which, in addition
to the data record have directories of selected record field values
and their corresponding record addresses. Records may then be located by seL. ,ing the directory rather than the file. Some form of
immediate access storage, such as disk, is necessary for indexed access
methods to have value.

Teleprocessing data is usually composed of character trings of varying
lengths. While not a file in the classical definition, most systems
provide assistance in accessing and processing the relatively unformatted messages that accumulate in the system communication buffers.
This assistance normally handles all communication between the
computing system and remotely located terminals.

The level to which access is provided greatly increases user capability
with a corresponding increase in system overhead.
213

REQUIREMENTS
1000

OPERATING SYSTEM
REQUI~REMENTS CHECKLI ST
1.2.2 DATA BLOCKING/DEBLOCKING
CONTROL

Reference
1

(a)

The system must provide record acquisition by
deblocking.

(b)

The system must provide move mode deblocking.

(c)

The system must provide locate mode deblocking.

(d-f) Block ing/deblock ing facilities must be available for:
(d)
(e)
(f)

fixed length,
variable length,
records of undefirnd length.

(g)

The system must provide system specified block sizes.

(h)

The system must permit user-specified block sizes.

214

Initial

Extended

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
_____________________

SYSTEM________
OPERATING___________________________

REQUIREMENTS

1.2.3

CHECKLI ST

LABEL PROCESSING

system must provide an automnat~c label generation
capabiIi ty.

________________

Reference

(ni)

The

(b)

The

system must allow users to generate labels.

(c)

The system must provide automatic la~bel checking

facilities.
(d)

The

system must ailow label checking upon user request.

Initial

Extended

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.

This function is usually provided in medium to large processing syeems
and should be specified.

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

CONTROL SPECIFICATION

(a-d) The system must allow the specification of the following
types of formats:

1.3.1

(a)
(b)
(c)
(d)

ffli formats,
report formats,
input formats,
query formats.

(e-f) The system must provide the following methods of
deriving control functions:
(e)
(f)

generative routines,
interpretative routines.

218

Initial

Extended

1.3. !

CONTROL SPECIFICATION
Reference:
1.

A data management system must be pri ided with a set of specifications 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.

These formats should be specified for each of the elements selected to
compose the data management system (see 1.3 a,b, c,d).

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

1.3.2 DATA FILE GENERATION AND MAINTENANCE
(a-e) The system must provide the following data file generation and maintenance facilities:
(a)
(b)
(c)
(d)
(e)

fixed input transaction processing,
logical (programmed) file maintenance,
interactive file mainteance,
file reorganization,
data error procedures.

(f-g) The system must allow the following types of correction:
(f)
(g)

interactive,
pre-establ ished.

220

2
3
4
5

Initial

ExteiJed

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, performing logical and interactive maintrance on the file, and reorganizing the file when the structure must be modified.

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.

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.

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.

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.

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

1.3.3 DATA QUALIFICATION AND RETRIEVAL

(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:
2
3
4

(c)
fixed logic,
(d) modifiable logic,
(e) parameterized.
(F-h) The system must allow retrieval mode control through
the following interactive queries:
(f) cue-response format,
(g) prompting format,
(h) programmable format.

5
6
7

(i-m) The system must allow query processing through the
following types of logical operators:
(i)

Boolean,
(j) qt-intitative (occurrence),
(k) arithmetic,
(I) statistical,
(m) application-defined.

8
9
10
11
12

(n) The system must allow nested logical operators.
(o-r) The system must allow the following query processing
operand formats:
(o)
(p)
(q)
(r)

constant value,
another data field,
interim result,
arithmetic expressions.

(s-u) The system must support the following types of file
search-es:
(s)
(t)
(u)

single file,
multi-file,
inter-file.
222

Initial

Extended

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.

Fixed logic pre-stored queries allows the user to store frequently used queries c
a library and to directly reference them ut execution time.

Modifiable !ogic pre-stored queries allow the user to temporaril' aler query Ic
prior to execution.

Parameterized pre-stored queries allow the user to store skeleal queries within
system and then insert parameters at execution time.

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.

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.

The programmable format allows the user to program and execute retrieval requ.N

The specification of each of these functions 's entirely dependent upon the type
query processing envisioned by the installatior.

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€
as: Search for "this AND this" but "NOT t iis"; search for "this OR tHis" but "I
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

-1
'T

REQUIREMENTS
"

O~~~.PER ATONG SYSiFEM-

REQUIREMENTS CHECKIST

Ra;erence

3.4 IDATA OUTPUTf
(C-c; The fat!ow'ng meti.vds of repert control must be
s ;sported by the system-

(a,

(b)
(C)
(d)

user St-ucV.;r~,Vd

sysie',- defined,
in-#ractively dfirtedH

The system must
data output,

Iroyde pre-stored reNr? Formats for

(e-i) The system must support the following media;
(e)
(f)
(g)
(h)
(1)
(I)

2
3

CRT,
typewriter,
printer,
magnetic tape dr've,
card punch.

The sysiem must provide support for mu!tipfe copy
facilities.

(k-m) The sy!",m must provide the foik-wing types of output
labeling:
(k)
(i)

headings,
trilers,

(n)

data labels.

4
5

(n-o) The s,0'stem must provide the following data formatting
capablifies:
(n)
(o)

hor'zor-al/verti cal positioning,
rigqh,/left justification.

(p-q) The sy!tem must provide the following data altering
capabilitie :
(p)
(q)

data editing,
decoding.

(r-s) The system must provide the following output account;ng capabili ies:
(r)
(s)

5
6
7

counting,
totaling.

(t-u) The system must provide pagination control for the
following:
pr;nted reports,
;)
(u) CRT disolavs.
224

lnitioi

Extended

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

This criterion is highly desirable for a data management system that will
process standard reports on c recurring basis.

The selection of any of these criteria is dependent upon the devices
available in the hardware configuration.

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.

Most data management systems provide these capabilities.

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.
If the DMS supports data encoding when data is entered into the fie,
then the output phase should support a corresponding decoding module.

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

Reference

UNFORMATTED DISPLAY

(a-d) Unformatted display must be provided by the system for
the following media:
(a)
(b)
(c)
(d)

cam,
magnetic tape,
paper tape,
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)
(d)

2
3

data files,
directories.

(e)

The system must provide for selective record display.

(f)

The system must provide for se'qctive field display.

226

Initial

Extended

2.1. 1

UNFORMATTED DISPLAY
Reference:
1.

2.1.2

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.

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.

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.

If the system maintains directories or catalogs, then the system should
also provide routines to produce formatted displays of their contents.

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

Reference

2.2.1 VOLUME POSITIONING
(a-c) The system must support the following types of volumes:
(a)
(b)
(c)

magnetic tape,
direct access storage,
card files.

(d-h) The system must provide the following magnetic tape
support:
(d)
(e)
(f)
(g)
(h)

forward spacing,
backspacing,
rewinding,
unloading,
erasing.

(i-j) The system must provide selective positioning of:
(i)

files,

()

records.

(k-I) The system must support the following .. thods of
positioning:
(k)

count oi records or files,

(I)

field or record contents.

3
4

228

Initial

-q

Extended

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

2.2.2 MEDIA COPY FACILITIES
(a-f) The system must provide copy facilities for the following
media:
(a)
(b)
(c)
(d)
(e)
(f)

card,
magnetic tape,
paper tape,
random access storage,
main storage,
remote terminal devices.

(g-j) The system must provide the following options:
(g)
(h)
(i)

()

field insertion,
field selection,
format conversion,
code conversion.

(k-rn) The system must provide the following dump and reload
facilities:
(k)

(I)

file compaction,
storage compection,

3
3

(m)

backup file creation.

230

Initial

Extended

2.2.2

MEDIA COPY FACILITIES
Reference:
1.

This criterion should be specified for all media supported by the
processing system.

Field insertion and field selection provides the user with the compatibility 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 structure 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.

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.

Backup file creation is always a useful feature in case of inadvertent
file destruction.

231

!! REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST
2.2.3

Reierence

DATA EDITING FACILITIES

(a-c) The following types of editing must be provided by the
system:
(a)
(b)
(c)
(d)

full file compare,
selective field compare,
single file scan.

The system must provide for file comparison between
differing file formats.

2.2.4

TEST DATA FILE SUPPORT

(a-b) The system must support the creation of the following
types of test files:
(a)
(b)
(c)

data files,
I/O terminal message files.

The system must provide history/troce fite interpretation

232

Initial

Extended

2.2.3

DATA EDITING FACILITIES
Reference:

2.2.4

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.

This capability occurs in very few processing systms.
be quite useful when validating related Files.

It can, however

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.

This criterion ishighly desirable for a processing system that provides
trace capabilities (see Part I, 3.2.2).

233

3.4.4

Fourth Level of Detail (Part III - Data Manipulation Functions)
This subsection covers the following fourth level data manipulation func-

tions:
1.1.2.1
1.1,2.2
1.1.2.3
1.2.1.1
1.2.1.2
1.2.1.3
1.3.2.1
1.3.2.2
1.3.2.3
1.3.2.4
1.3.2.5
1.3.2.6

FILE SECURITY CONTROL
READ/WRITE ACCESS CONTROL
CONCURRENT ACCESS CONTROL
SEQUENTIAL ACCESS CONTROL
KEYED/INDEXED ACCESS CONTROL
TELEPROCESSING ACCESS CONTROL
STRUCTURE DEFINITION
SPACE ALLOCATION
INPUT TRANSACTION PROCESSING
LOGICAL RECORD MAINTENANCE
INTERACTIVE FILE MAINTENANCE CONTROL
FILE REORGANIZATION

235

REQUIREMENTS

OPERATING SYSTEM
REQUIREMENTS CHECKLIST
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 restrictions to authorized users:
(a)
(b)
(c)

read access only,
read and selective write access.

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

Reference

Initial

Extende,

1.1.2.1

FILE SECURITY CONTROL
Reference:
1.

1.1.2.2

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 reference by a user to the password allows access. Therefore, the password method is more efficient from a processing standpoint, though
potentially less secure than user ID control.

READ/WRITE ACCESS CONTROL
Reference:
1.

1.1.2.3

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.

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

1.2.1.1 SEQUENTIAL ACCESS CONTROL
(a)

The system must provide basic sequential access
control.

(b)

The system must provide automatic read-ahead sequential (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.

(c)

The system must allow multiple index levels to be
maintained.

(d-e) The system must support the following types of access
keys:
(d)
(e)

software keys,
hardware keys.

238

Initial

Extended

1.2.1.1

SEQUENTIAL ACCESS CONTROL
Reference:
1.

1.2.1.2

This function is usually desirable for sequcntial record processing. Automatic 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.

KEYED/INDEXED ACCESS CONTROL
Reference:
1.

Automatic key computation relieves the user of determining the physical
storage address of the record.

Automatic index maintenance relieves the user of updating the index
of an indexed file when he adds or deletes a record from the file.

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

1.2.1.3 TELEPROCESSING ACCESS CONTROL
(a)

The system must provide automatic message time
stamoing.

1,2

(b)

The system must provide optional message time stamping.

(c-e) The system must provide the following ioput message
processing facilities:
(c)
(d)
(e)

message routing,
message queuing,
message priority recognition.

(f-h) The system must provide the following output message
processing facilities:
(f)
(g)
(h)

message routing,
message queuing,
message priority recognition.

240

Initial

Extended

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.
These Features are quite desirable for most
processing systems supporting
teleprocessing.

241

REQUIREMENTS
OPERATING SYSTEM

REQUIREMENTS CHECKLIST
1.3.2.1

iitial

Extended

STRUCTURE DEFINITION

(a-e) The system must allow the following types of structures:
(a)
(b)
(c)
(d)
(e)

Reference

1
2
3
4
5
5

sequential,
hierarchical,
indexed,
ring,
list.

(f-g) The system must provide the following types of
indexing schemes:
(f)
(g)

normal,
inverted.

(h-j) The system must allow the following types of data
elements:
(h)
(i)

fixed length,
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)
(b)
(c)
(d)

tape,
disc,
drum,
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.

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

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 containing a logical ranking such as: nation, political subdivision, counties.
major cities, etc.

The indexed structure may be applied to either the sequential or hierarchical structure method and can be used to selectively locate data
elements within a file.

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.

This criterion is highly desirable for a processing system where the
retrieval elements are either random or unpredictable. In this structure retrieval time is minimized regardless of the data fields queried.
However, this type 0t structure also requires an extremely complex
file updating technique.

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.

SPACE ALLOCATION
Reference:
1.

The specification of these criteria ;s d*rsoondent upon the
hardware configuration.
243

REQUIREMENTS
OPERATING SYSTEM

REQUIREMENTS CHECKLIST

Reference

1.3.2.3 INPUT TRANSACTION PROCESSING
(a-c) The system must provide input transaction processing
fccilities that allow:
(a)
(b)
(c)

input data definition,
input data validation,
input data alteration.

(d-e) The system must allow the following types of input
formats:
(d)
(')

pre-established,
self-defining.

(f-i) The system must provide the following types of input
data validation:
(f)
(g)
(h)
()
(j-)

equal value compar; n,
range verification,
masked comparison,
sequence checking.

The system must provide the following types of input
dota alteration:

(j)
(k)
(I)

automatic truncation/podding,
encoding/decoding,
constant factor modification.

(m-o) The system must recognize the following input data
te rn inator,(m)

standard (embedded) feld,

(n)
(o)

%peciolcharactec(s),
phys'cal media morkers.

244

Initial

Extended

1.3.2.3

INPUT TRANSACTION PROCESSING
Reference:
1.

These criteria should be specified for all data management systems.

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.

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.
Input terminators are used to signal the end of the input data to be
processed. Each of these techniques has its advocatea, and no particular method is favored.

245

REQUIREMENTS
OPERATING SYSTEM
REQUIREMENTS CHECKLIST

Reference

1.3.2.4 LOGICAL RECORD MAINTENANCE
(a)

The system must allow the selection of update records
by logical query.

(b)

The system must provide record maintenance through
multi-record logic.

(c'

The system must provide automatic updating of subordinate files.

1.3.2.5 INTERACTIVE FILE MAINTENANCE
CONTROL
(a-b) The system must provide interactive oa irride capabilities for:
(a)
(b)

data values,
update logic.

246

Initial

Extended

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

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
1,3.2.6 FILE REORGANIZATION
(a-c) The sy-ten. mus allow the following methods of restructuring:
(a)
(b)
(c)

field additi n,
deletion,
reordering.

(d-e) The system must allow the following types of merging:
(d)
(e)

intra-file,
inter-file.

248

Reference

Initial

Extended

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

1.!1.1

ALGORITHMIC
SCHEDULING

1.1.1.2

TIMEINITIATED
SCHEDULING

1.1.1.3

EVENTINITIATED
SCHEDULING

1.1.1.4

PROGRAMINITIATED
SCHEDULING

1.1.1.5

2.1

2.1.1

ERROR
CORRECTION
(HARDWARE)

2.1..

CONDITIONAL
SCHEDULING

1.1.1.6

SCHEDULING
QUEUEMAINTENANCE

1.1.2.1

CORESTO
ALLOCATI

ERROR
HARDWARE
CONROL

ERROR
'IOTIFICATION
t1ARDWARE)

RECOVERY
2,1.3 ERROR

2.2.1

ERROR
Ppr'G

COMPUTER

1.1

JOBCONTROL

PROGRAM
1.1.3 LOADING

RESOURCE
1.1.2 ALL CATION

CORESTORAGE
I ALLOCATION

1.1.2.2

I/O DEVICE
ALLOCATION

2,0

2.2

ERPOrC:ORP[CTION
,'.RAMl
IP'
,

OPE

1.1.2.3

COMMON ROUTINE
ALLOCATIOi'

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

DIAGNOSTIC ERROR
PROCESSING

ERROR
INTERFACE

ERROR
PROGRAM
G..r

2,13 CONTROL

ERROR
NOTIFICATION
2.2.2 tPROGRAM)

2.2.3

PROGRAM
TERMINATION

2.3.1

KEY-IN
OPERATOR
EDITING

OPiRATING SYSI'M
10 MANAGEMENT

CONTROL
2.3.2 COMMAND EpIIrNC.

REMOTETERMINAL
COMMUNICATION
2.3.3 EDITING

2.0

PROGCAM
AINTENANCE

EVE
SYI

rER OPERATING

SYSTEM FUNCTIONAL CLASSIFICATION

STRUCTURE

PARI,-VEXEC0,VE/ONTROL FUNCTIONS

1.0

JOBMANAGEMENT

1.2

114

TCHING
TROL

EVENT
ITORING

INTERRUPT
PROCESSING

EVENT
1.1.4.2

PROGRAM
5 TEPJNATION PROCESSING

- NCHRONIZATION

1.1.4.3

CONTROL

1.2.1

BUFFERING
221

3.1

11 TIRMINAt
I TI
Nt

PRO45RAm TO

SCRSTM LINK
SESTEM
1IAT LI.2SEkC
.4 ' ERIFICATION

REAL-TIME
CLOTCK

* .\IT f rNAN I

3.0

COMPI.ERINTERFACES

PAT 11

COTROL

DATACODE
1222

TRANSLATION

TESTINGDEBU
3.2 SERVICE

TIMING SERVICE

IN1EPVALI MER

3.1"

DEVICE
1.2.3 MANIPULATION

1.2.2 DATATRANSFER

I/O SCHEDULING

PROGRAMLIMIT
1.1.44 MNiN

I0 CONTROL

,..1l.2 SEVIC

YSTEM MANAGEMENT FUNC [I-S

4.1

LITIIITIE5

STO.ACF UJMP
3222EICE
3.1.,
1 ONTOk.

.,2 IkA(INI .

CTLIRE

1.3

DEVICE
.2.3 MANIPULATION

TERMINAL
REMOTE
1.2,4 SUPPORT

1.3.1.1

SYSTEM
INITIALIZATION

3.0

1.3. 1.2

1.3.2

STATUS
RESOURCE

INPUT/OUTPUT

JOBCONTROL
1.3.1 SYSTEMSTR

SYSTEM
COMMUNICATION

COMMUNICATION

1,3.3

STREAM
CONTROL

1.3.4

MODIFICATION

1.3.5

SYSTFMRESTART

SUPPORT
PROCE15INC,

PR
3.

TESTING(.)EBUGGING
5ERVICE

M, I
IkA I N(. CON,3

3.3

$yS1EM TEST h'IOI
C*4TKL

3..1

MAI NTAININCG
jO
06CHA R(-'E
INI OIMAT!ON

3.1,2

LOGGING AND
ACCOUNTING

MAINTIlNI NG
Ek OR SIAIIS1I(.S

MAINIAINING
SyTIEM UIILI,?AIION
qAIISTIC

3.41

CURRENT 'Y510.
STATIUS
IN1ENRC)GA1I')N

SYSTEMRECOVERY
4

.3COMMUNICATION

RESOURCE
STATUS
1.3.4 MODIFICATION

INPUT/OUTPUT
3.3 STREAM
CONTROL

SYSTEMSTATUS
INTERROGATION

1.3.5

1.4.1 CHECKPOINTING

1.4.2.1

3,4

M A IN TA I N NCAI,
STEM
J

IAISIL~3.4.1

PROGRAM
ACCESSISLE
SYSTEMDESCRIPTION
MAINTENANCE

r
SI~m
TAIUStEM
AI'TN
INTEIk()O..A1 )N

3.4.

DERINITION
iNTR)WX)ATI-)N

PROCESSING

1.4.2

INITIATED
PROGRAM
1.4.2.2
RESTARTING

RESTARTING_

SVSTEMINITIATED
RESTARTING

1.4.2.3

DEVICE
REPOSITIONING

2.1

2.1.1

ERROCRECTION
(HADA)

CONTROL

ERROR
NOTIFICATION
2.1.2 (HARDWARE)

RECOVERY
2.1.3 ERROR

2.2. t'

FILEMANAGEW NT

FACI1111

1.1

FILELOCATION
I1,1 4RECNITIQ

fc. the fRwmp,; S,*-.,,
Co4.,t N.,.
w

~d.

ifsol. A;, foc.

:"e

1..

FILESIECURITY
11.2.1
-1.'I--128
1 21 N RO

FILEACCESS
CI)N RO

RfEAWARITE
ACCSfflC.ONTROL

RESIO&tATION
1.1.1 CAPABIIITIFS

1.1.2.3

CONCRJRIf"T
ACSS
MCONTROL

SEOIANTI

ERROR
PROGRAM
2.2 CONTROL

ERROR
CORRECTION
2.2.1 (PROGRAM)

ERROR
NOTIFICATION
2.2.2 (PROGRAM)

2.3

2.2.3

KEY-IN
OPERATOR
2.3.1 EDITING

PROGRAM
TERMINATION

1.0

1.1

1.0

DATA,

2.3.2

ERROR
INTERFACE
CONTROL

TERMINAL
REMOTE
COMMUNICATION
2.3.3 EDITING

CONTROL
COMMANDEDITING

OPERATING SYSTEM
MANAGEMENT

GENERATION
SYSTEM

1.2

2.0

MAINTENANCE
SYSTEM

2.1

PROGRAM
MAINTENANCE

AND DIRECTORY
LIBRARY
MAINTENANCE

2.2

LOAD
GENE

GEMENT

I/O SUPPORT
,.2 FACILITIES

DATAPILE
DATAACCESS
I1. 1 CO TRo.

Ju(NTIAL
.'mO

EIY(D INIXI,
ONTYL
A

DATA$LOCKINGG
DESLOCkING
1.2,2CONTROk

1,1.1.3

TLIPROCESSING
A(CES COONTROL

1.2,3 LAIELPROCESSIN

1.3.2.1

STRUCTUlRE
DEFINITION

1,l3,1

CONTROL
SPCIFICATION

SPACE
1,3,2,2 ALLOCATION

1,12

GENERATION AID
1.3.2 MAINTENANCE

,6ACTION
ItI,0T 1A
P OCEXSSING

I3.2-.4

LOGICAL RECORD
MAINTENANCE

NT
MA

3.1

PROGRAM
TO
SYSTEMLINK
2.3.4 VERII-CATION

OTETERMINAL
MUNICATION
ING

3.2

TIMING SERVICE

INTERVALTIMER
3.1.2 SERVICE

REAL-TIME
CLOCK
3.1.1SERVICE

3.2.1

STORAGEDUMP
CONTROL

TESTIN D
SERVIC

3.2.2 TRACI6

LARTJI" SYSTFM
MANAGEMENT FUNCTIONS

PROGRAM
MAINTENANCE

3.0

COMPILERINTERFACES

4.0

MANAGEME NT SUPPORT
UTILITIES

4,2

SYSTEMSIMULATION
ROUTINES

II
DEVICE
PERIPHERAL
4.1 SUPPORT

LOADMODULE
GENERATION

CTORY
2.2

A.1.1

SIMULA'1ON
OF SYSIEM
4.2.1 FACILITIES

VOLLIME
4.1.2 MAINENANCE

VOLUME
PREPARATION

4.3

SYSTEMMEASUREMENT
ROUTINES

SIMULATION OF
COMMUNICATION
4.2.2 FACILITIES

STAND-A
4.4 UTILITIES

TAND-ALONE
STATUS
4.4.1 DISPLAY

PART
III - DATAMANIPUIATION FUNCTIONS

DATAMANAGEMENT

DATAQUALIFICATION
1.3.3 AND RITTIEVAL

II
.41.lO.
I

JWTEIACTI'.E FILE
IAINTENANCE
125CONTROL

OILE

134DT

3.2

TESTINGDEBUGGING
SERVICE

DUMP
3.2.2

UREMENT
4.4

TRACING CONTROL

3.3

$,(STEMTESTMODE
3.2.3 CONTROL

MAINTAINING
J08 CHA PGE
3.3,1 INW ',RMATION

LOGGING AND
ACCOUNTING

MAINTANING
3.3,2 ERROR
STATISTICS

MAINTA: NI NG
SYSTEMUTILIZATION
1.3-3 STATISTICS

3.4.1

fENT ys
STATUS
INTERROGl',

STAND-ALONE
UTILITIES

STAND-ALONE
STATUS
4.4.1 DSPLAY

STAND-ALONE
RECO%,ERY
4.4.2 SUPPOrT

2.0

2.1

DISPI. Y ALII.TIfl

1,).dAT1
X!Ut2MA!R ()I
).

P.D

1,1
344C~T~T21

DATAHANOL ING
UTILITIES

_______________
-Lid1PITON
DI1PA~
.*,.

.*..T.

OfAR
".J
poltloTIWS
__________________

21PA

C('#'.

AA5 ?
&i3ICRTS

I'D
3.4

MAINTAINING
SYSTEM UTILIZATION
s.S3_

STATISTIC,

PROGRAM ACCESSIBLE
SYSTEM DESCRiPTION
MAINTENANCF

CURRENT 'YSTEM
STATUS
3.4.1

SYSTEM DEFINITION

INTERROGATION

3.4.2

INTERROGATION

SOtTtNG AP'D

3.0

WV-ING

4~~~

*~ftt$A.
00t MCSS~3E.

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
ORIGINATING

(Corporate author)

ACTIVITY

,4REQ

The COMTRE Corporation

LA;FC

151 Sevilla Avenue
REPORT

UCASFE
b

Coral Gables, Florida 33134

report is rlasajod

SCUIY

_______

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

November 1970
*a.

NO1O

lb. NO. OF REFS

PAGES

249

CONTRACT OR GRANT NO,9.

None

ODIGINATORS.7EPORT NUMISERIS)

F19628-70-C-0258

ES D-TR-71 -74

b. PROJECT NO

6917__

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

________ABSTRACT__________

TCS

SPONSORING MILITARY

AC TIIYI

Deputy for Command and Management Syster
Hq Electronic Systems Division (AFSC)
L G Hanscom Field,

edford, Mass. 01730

TisI reporl presents a method for translating operatiorial data processing
requirements into specific criteria for use in set 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
EY

WCIPD5

LINK

•
51OLE

ROLE

opemting systems (computer)
specificiation
evaluation
validation

analysis
selection
guidelines
identification

Security Claisilication

LINK
ROL E

C
WT

Source Exif Data:

File Type                       : PDF
File Type Extension             : pdf
MIME Type                       : application/pdf
PDF Version                     : 1.4
Linearized                      : No
Creator                         : 
Producer                        : 
Page Count                      : 257

EXIF Metadata provided by EXIF.tools

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

Navigation menu

Versions of this User Manual:

Views

Navigation