w%I TECHNOLOGY:

UNIVAC 1108

EXEC LEVEL 32R2

PERFORMANCE HANDBOOK

00-34

NBS Special Publication 500-34

U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards
NATIONAL BUREAU OF STANDARDS

The National Bureau of Standards' was established by an act of Congress March 3, 1901. The

Bureau's overall goal is to strengthen and advance the Nation's science and technology and

facilitate their effective application for public benefit. To this end, the Bureau conducts

research and provides: (1) a basis for the Nation's physical measurement system, (2) scientific and technological services for industry and government, (3) a technical basis for equity in trade, and (4) technical services to promote public safety. The Bureau's technical work is performed by the National Measurement Laboratory, the National Engineering Laboratory,

and the Institute for Computer Sciences and Technology.

THE NATIONAL MEASUREMENT LABORATORY provides the national system of

physical and chemical and materials measurement; coordinates the system with measurement

systems of other nations and furnishes essential services leading to accurate and uniform

physical and chemical measurement throughout the Nation's scientific community, industry,

and commerce; conducts materials research leading to improved methods of measurement,

standards, and data on the properties of materials needed by industry, commerce, educational

institutions, p'^.- '^"vernment; provides advisory and research services to other Government

Agencies; develops, produces, and distributes Standard Reference Materials; and provides

calibration services. The Laboratory consists of the following centers:

Absolute Physical Quantities^ — Radiation Research — Thermodynamics and

Molecular Science — Analytical Chemistry — Materials Science. THE NATIONAL ENGINEERING LABORATORY provides technology and technical

services to users in the public and private sectors to address national needs and to solve national problems in the public interest; conducts research in engineering and applied science

in support of objectives in these efforts; builds and maintains competence in the necessary

disciplines required to carry out this research and technical service; develops engineering data and measurement capabilities; provides engineering measurement traceability services; develops test methods and proposes engineering standards and code changes; develops and

proposes new engineering practices; and develops and improves mechanisms to transfer

results of its research to the utlimate user. The Laboratory consists of the following centers:

Applied Mathematics — Electronics and Electrical Engineering^ — Mechanical

Engineering and Process Technology^ — Building Technology — Fire Research —

Consumer Product Technology — Field Methods.

THE INSTITUTE FOR COMPUTER SCIENCES AND TECHNOLOGY conducts

research and provides scientific and technical services to aid Federal Agencies in the selection, acquisition, application, and use of computer technology to improve effectiveness and

economy in Government operations in accordance with Public Law 89-306 (40 U.S.C. 759),

releva'nt Executive Orders, and other directives; carries out this mission by managing the Federal Information Processing Standards Program, developing Federal ADP standards

guidelines, and managing Federal participation in ADP voluntary standardization activities; provides scien^tific and technological advisory services and assistance to Federal Agencies; and

provides the technical foundation for computer-related policies of the Federal Government.

The Institute consists of the following divisions:

Systems and Software — Computer Systems Engineering — Information Technology.

'Headquarters and Laboratories at Gaithersburg, Maryland, unless otherwise noted; mailing address Washington, D.C. 20234. 'Some divisions "within the center are located at Boulder, Colorado, 80303.

The National Bureau of Standards was reorganized, effective April 9, 1978.
COMPUTER SCIENCE & TECHNOLOGY:

Performance Handbook

iSATIONAL BUREAU. OF STANDARDS

JUL 1 3 1978

f]p-+ <X4L(L.

UNIVAC 1108 EXEC LEVEL 32R2 us?

Capt. John C. Kelly and Lt. Gary P. Route ^(^CQ^\^ \

Federal Computer Performance Evaluation and

Simulation Center

Washington, DC 20330

Sponsored by

U.S. Military Personnel Center

Alexandria, VA 22332

U.S. DEPARTMENT OF COMMERCE, Juanita M. Kreps, Secretary

Dr. Sidney Harman, Under Secretary

Jordan J. Baruch, Assistant Secretary for Science and Tecinnology

VyV ^ NATIONAL BUREAU OF STANDARDS, Ernest Ambler, Director

Issued June 1978
Reports on Computer Science and Technology

The National Bureau of Standards has a special responsibility within the Federal

Government for computer science and technology activities. The programs of the

NBS Institute for Computer Sciences and Technology are designed to provide ADP

standards, guidelines, and technical advisory services to improve the effectiveness of

computer utilization in the Federal sector, and to perform appropriate research and

development efforts as foundation for such activities and programs. This publication

series will report these NBS efforts to the Federal computer community as well as to

interested specialists in the academic and private sectors. Those wishing to receive

notices of publications in this series should complete and return the form at the end

of this publication.

National Bureau of Standards Special Publication 500-34

Nat. Bur. Stand. (U.S.) Spec. Pub!. 500-34, 144 pages (June 1978) CODEN: XNBSAV

Library of Congress Catalog Card Number: 78-600054

U.S. GOVERNMENT PRINTING OFFICE

WASHINGTON: 1978

For sale by the Superintendent of Documents, U.S. Government Printing Office, Washington, D.C. 20402

Stock No. 003-003-01948-8 Price 3.25 (Add 25 percent additional for other than U.S. mailing).
FOREWORD

Operating systems largely determine the performance of

modern computer systems „ They control large-scale, multiprogramming computers with programmed rules and procedures

that may be tailored, within limits, to fit the particular

needs of different users in widely differing applications.

Proper tuning of operating system control variables is where

any serious attempt to achieve efficient computer utilization

must begin, and often where its greatest benefits accrue.

This report describes the user-adjustable controls of

one such operating system: UNIVAC EXEC 8, level 32 release

2. It presents methods of detecting and diagnosing performance problems, identifies important EXEC control points,

and recommends control settings that are believed to produce

generally satisfactory results at some installations.

Such information is, of course, site and system specific.

That is, it has direct application only to EXEC 8 sites,

limited application outside of level 32, and qualified

application even to other sites with the identical release.

For non-EXEC sites, the document should prove of interest

primarily as a format for presenting a kind of information

that would be useful in any operating system environment

and as a model for analyzing the subtle problem of operating

system tuning on any vendor system. For other releases of

EXEC 8, resemblances to level 32 are probably sufficient to

stimulate creative thinking about specific areas of performance improvement, although the caution against careless or

uncritical application of recommendations is especially

urgent here. For sites using level 32, the information

here should be of enormous value and much of it directly

transferable. This class of reader must remember only that

operating systems are adjustable precisely because no two

installations have quite the same configuration, workload

or functional priorities, and that no set of control

parameters will suit all implementations even of the same

system equally well.

This report was prepared in its original form by the

Federal Computer Performance Evaluation and Simulation

Center (FEDSIM) under the sponsorship of the U.S. Army

Military Personnel Center (MILPERCEN) . It is reprinted

here with minor editorial changes by the National Bureau of

Standards' Institute for Computer Sciences and Technology

(NBS/ICST) in the belief that it will have useful application

at other installations besides the one for which it was

intended.

iii
Publication of this report in no way implies recommendation or endorsement of UNIVAC EXEC 8 systems by the

National Bureau of Standards, nor is it to be construed to

pass qualitative judgment in any degree on the performance

characteristics of the system or any system features describe

herein

Special note is made of the fact that this publication

is the result of a cooperative interaction between NBS and

FEDSIM to make the results of FEDSIM's generally applicable

work available to the Federal ADP community. NBS also

wishes especially to express its appreciation to MILPERCEN

for making the occasion for this collaboration possible.

The authors of this report welcome questions concerning

the technical content, which should be addressed to them at:

FEDSIM, Washington, DC 20330. NBS/ICST would appreciate

very much comments concerning the general utility and need

for computer system tuning guides. Of particular interest

would be proposed or candidate reports, facilities interested

in sponsoring or participating in developing tuning guides,

and facilities interested in serving as test beds for

evaluating candidate guidelines. Queries and expressions

of interests of this nature should be addressed to either

John F. Wood or Richard Fo Dunlavey, National Bureau of

Standards, Building 225, RoomA265, Washington, DC 20234

(Area Code 301, 921-3485).

M. Zane Thornton, Acting Director

Institute for Computer Sciences

and Technology

National Bureau of Standards

U, S. Department of Commerce

iv
PREFACE

This report is based on a detailed analysis of the

UNIVAC 1108 Operating System - EXEC Level 32R2 - as operated

by the United States Army Military Personnel Center

(MILPERCEN) . Since the procedures and guidelines specified

in the report strongly depend on the particular equipment

type and EXEC level, care should be taken before applying

the results to different environments. Questions relating

to the subject of this report or to the possibility of extending the results should be addressed to the study's

authors at the Federal Computer Performance Evaluation and

Simulation Center (FSDSIM)

.

V
ABSTRACT

This is a report prepared for the Army MilitaryPersonnel Center (MILPERCEN) . It describes a set of

hypotheses for evaluating the performance of UNIVAC 1100

Computer Systems. The hypotheses specifically apply to

EXEC Level 32R2 operating on UNIVAC 1108 Computer Systems.

Attempts to apply the guidelines to different UNIVAC 1100

models or to different levels of the EXEC may lead to

erroneous results.

The report contains sections on each major complex

within the EXEC. Each section (1) states the performance

hypotheses associated with that complex, (2) explains how

the available measurement tools may be used to determine if

the hypotheses are true, and (3) identifies which performance

parameters need to be changed to correct the problem situation. All of the performance hypotheses discussed in the

body of the report are collected together in Appendix A.

Appendix B summarizes the performance parameters and

Appendix C contains an introduction to the Software Instrumentation Package (SIP)

Key words: Computer performance management; measurement

tools; operating system performance; performance guidelines;

performance measurement; tuning guides; UNIVAC 1108.

VI
TABLE OF CONTENTS

Section 'Page

I. INTRODUCTION „ 1

A. Background 1

B . Ob j ect ive <, 1

II. METHODOLOGY „ „ 3

III. PROCESSOR MANAGEMENT. .. „ 5

A. Introduction. o o o 5

Bo CPU Priorities. » o „ 7

C . CPU Quanta. „ o 8

D. Test and Set Interrupts o. 9

IV. MEMORY MANAGEMENT . . „ „ o . . 11

A. Memory Configuration 11

B. Memory Allocationo 11

C. Demand/Batch Sharing „.o 21

D. Function/Segment Activity 23

E. EXPOOL. „...,„ 25

V. FACILITIES MANAGEMENT 29

A. Master File Directory 29

B. Mass Storage Rollouts 31

C. Granule Tables 37

D. Mass Storage Management Practices 40

E. Scheduling o 43

VI. INPUT/OUTPUT. .. o . o .. o O...0 47

A. Late Acknowledgments o 47

B. Seek Time. . .

.

. . . 52

C . Block Size. „ „ . » 55

VII. TEST AND DEBUG , o. 59

APPENDICES

A. PERFORMANCE HYPOTHESES » 61

B . PERFORMANCE PARAMETERS . . . „ 67

C. INTRODUCTION TO SIP „.„ 10 7

vii
TABLE OF CONTENTS

TABLES

Tab le Page

III-l Activity Priority Types „ 7

III-2 CPU Quanta 8

IV- 1 Core Priorities o o. 14

IV-2 Demand Priority Levels for CQFACT=800 15

IV- 3 Demand Priority Levels for CQFACT=3200 16

IV-4 Batch Priority Levels 17

IV-5 Cost Table , » . . o . 21

IV-6 Segment Status Values o 25

V-1 Mass Storage Thresholds 31

V-2 Point Values for TSLR and MTBR 36

V-3 Point Values for SIZE„ „ 36

VII-1 Test and Debug Parameters o.o.... 59

B- 1 Performance Parameters 70

C-1 SIP Reports (Level 4 . 0) . . . » o 110

FIGURES

Figure

III-l Nesting of EXEC Functions 5

III-2 Major System Queues ... o 6

IV- 1 Memory Configuration o 12

IV-2 Demand/Batch Sharing Algorithm 22

viii
I. INTRODUCTION

A. BACKGROUND

The United States Army Military Personnel Center

(MILPERCEN) is responsible for maintaining the personnel

records of all enlisted and officer personnel in the Army.

In support of this mission, MILPERCEN operates seven UNIVAC

1108 computer systems. During FEDSIM's study, the computer

systems were operating under control of the UNIVAC 1100

Operating System, Level 32R2.

Because MILPERCEN recognized the importance of operating

system performance on overall system performance, they

requested that FEDSIM study how operating system performance

could be improved. Their request for assistance was formalized in FEDSIM/MILPERCEN Customer Agreement AY-505-080-ARJ^IY

,

titled MILPERCEN EXEC-8 ANALYSIS. Additional tasks in

support of this project were outlined in Amendment No. 1 to

Customer Agreement AY-505-080-ARMY . The funding for the

additional tasks was obtained by transferring funds from

another project, NA-505-079-ARf4Y

B. OBJECTIVE

The objective of this project was to optimize the performance of the UNIVAC 1100 Operating System for MILPERCEN'

unique environment. To accomplish this objective, the

project was divided into two parts: (1) the development of

a set of general performance guidelines and (2) the application of those guidelines to MILPERCEN. This report summarizes

the guidelines developed. A second report describes their

application to MILPERCEN.

In support of the project objective, the customer

agreement outlined 14 areas of investigation:

1. Library Configuration

2. Swapping

3. EXEC-8 Configuration Parameters

4. Queue Management/Interrupt Processing

5. Internal Priority Management

6. Real-Time Interface Tailoring

7. Dynamic Allocation of Core Memory

8. Management of Buffer Space

9. Dispatching Time Slice Management

10. Data File Rollout/Rollback Management

11. Communications Terminal Network

12. Officer Personnel Utilization System

13. I/O Complex

14. Remote Terminal Emulator
After preliminary analysis, it was found that many of these

areas overlapped with one another. To eliminate the redundancies, the following consolidated areas were developed:

(1) Officer Personnel Utilization System

(2) Processor Management

(3) Memory Management

(4) Facilities Management

(5) Input/Output

(6) Test and Debug

The Officer Personnel Utilization System is not discussed in

this report. It is treated separately in another report.

This report devotes a separate section to each of the

remaining areas mentioned above.

2
II. METHODOLOGY

A four-step procedure was used to prepare this set of

guidelines

:

(1) Learn the fundamentals of how each EXEC complex

works

.

(2) Identify the controllable performance parameters

associated with each complex.

(3) Outline the performance hypotheses associated

with each complex.

(4) Determine how SIP can be used to decide if the

hypotheses are true.

This procedure was followed for each EXEC complex. Results

for each complex are presented in separate sections.

The most difficult problem associated with this project

was obtaining adequate documentation. The primary source of

information was the actual EXEC program listings. Additional

information was obtained from the UNIVAC EXEC Internals

Course, the UNIVAC Dump Analysis Course, and the Programmer's

Reference Manual.

The hypotheses presented in this report describe conditions which, if true, would have an adverse affect on performance. They are stated as if they were true, though their

existence must be proven or disproven by empirical analysis.

The hypotheses are not intended to be statements of fact,

but rather pointers to potential performance problems.

I

3

III. PROCESSOR MANAGEMENT

A. INTRODUCTION

Processor management is the responsibility of the

Dispatcher. The Dispatcher is the heart of the operating

system; it makes the final decision about which activity to

execute next. Before a run can be dispatched, it must be

processed by other parts of the EXEC. The Course Scheduler

(CS) decides which runs should be opened; the Dynamic Allocator (DA) decides which activities associated with those

runs should be loaded into main storage; and the Dispatcher

(DISP) decides which activity, of those loaded into main

storage, should be given control of the CPU. The nested

relationship between the EXEC functions is illustrated in

Figure III-l. When a run enters the system, it must pass

through a series of queues before it eventually completes

executing. A queue is associated with each major EXEC

complex (see Figure III-2). This section addresses only the

Dispatcher Queue, also known as the Switch List (SWL) . The

other queues are discussed in following sections.

The three main performance hypotheses associated with

processor management and activity dispatching are listed

below:

(1) Batch programs that are assigned the same CPU

priority as demand programs are causing demand

programs to have degraded response times.

SCHEDULING

DYNAMIC ALLOCATION

DISPATCHING ______

NESTING OF EXEC FUNCTIONS

FIGURE III-l

5
6
(2) CPU quanta that are set either too high or too

low are causing the CPU to be inefficiently allocated.

(3) An excessive number of test and set interrupts

are causing programs to be delayed until data areas

are unlocked.

Each of these problems is discussed in the sections that

follow.

B. CPU PRIORITIES

All activities in the system are controlled by an internal priority referred to as type and level (TAL) . TAL is

interpreted by the Dispatcher as a CPU priority. Type

specifies the priority class of an activity, and level

specifies a subpriority within a type. There are seven

activity types numbered 0 through 6. The number of allowable levels varies for each type. TAL is denoted by a 3-digit

octal number of the form TLL, where T is the type and LL is

the level.

All activities are queued on the switch list according

to their TAL (CPU priority) . Whenever the state of the

system changes, the Dispatcher selects the highest priority

(lowest TAL) activity on the svzitch list to execute next.

Activity Types 0, 1, and 3 are reserved for EXEC activities. Type 2 is reserved for real-time activities; all

other user activities operate at Types 4, 5, and 6. The

activities associated with each type are summarized in

Table III-l. Type 4 is reserved for Transaction Interface

Package (TIP) programs. Both demand and batch programs run

at Type 6

.

TYPE LEVELS ACTIVITIES

0 00 Interlock Processing (EXEC-0)

1 01-02 High EXEC (EXEC-1)

2 01-35 Real-Time

3 01-35 Low EXEC (EXEC- 3)

4 01-07 TIP

5 01-07 Deadline Batch

6 01-07 Demand and Batch

ACTIVITY PRIORITY TYPES

TABLE III-l

7
This priority structure can cause performance problems

for demand programs. Since demand and batch programs have

the same CPU priority, demand programs may be preempted by

batch programs. In previous versions of the EXEC, demand

programs executed at Type 4; but, when TIP was introduced,

they were reduced to Type 6. For installations that do not

run TIP, demand programs may be changed back to Type 4 by

changing the software parameter DSWTCHTYP. If DSWTCHTYP is

changed to 4, batch throughput should be closely monitored

since demand programs may lock out batch programs.

C. CPU QUANTA

The length of time an activity is given access to a system resource is referred to as a quantum. There are two

types of quanta: core quanta and CPU quanta. The Dynamic

Allocator allocates main storage in terms of core quanta,

and the Dispatcher allocates CPU time in terms of CPU quanta

Since an activity must be core-resident before it can be

dispatched, it can receive a CPU quantum only if it is

currently allocated a core quantum. Core quanta and their

performance implications are discussed in a subsequent

chapter

Only Program Types 4, 5, and 6 are assigned CPU quanta;

Types 0, 1, 2, and 3 are allowed to execute until completion

or until they are preempted by a higher priority activity.

Quantum assignments are made according to the current level

of the activity. The quanta assigned to each user level are

summarized in Table III-2. These values are hardcoded in

the element DISP.

USER LEVEL

QUANTUM

(MILLISECONDS)

1 1.4

2 3

3 32

4 64

5 128

6 256

7 512

CPU QUANTA FOR TYPES 4, 5, AND 6

TABLE III-2

8
An activity initially begins execution at Level 2 and is

allowed to execute for the corresponding CPU quantum time.

Level 1 is reserved for the processing of I/O interrupts

that occur at the completion of an I/O operation (101$ and

IOWI$) . If the activity does not complete execution before

its quantum expires, the level of the activity is incremented; and the activity is requeued on the switch list.

This continues until the activity either completes execution

or reaches Level 7. If the activity reaches Level 7, it

continues there until it completes execution. One exception

to the above procedure occurs when an activity voluntarily

gives up control to do an I/O operation. In this case, the

activity returns to Level 2, regardless of its current

level.

CPU Dispatching is purely preemptive. An executing

activity may be preempted by a higher priority (TAL) activity

at any time. After each interrupt, the Dispatcher must

determine the highest priority activity and give control to

it. If the preempted activity has not exceeded its quantum,

it will be requeued at the same level. The next time it is

given control, it will be allowed to execute fo'r the quantum

time it has remaining.

CPU quanta are particularly sensitive to an installation's

workload. If they are set too low, the CPU will spend a

disproportionate percent of its time switching between

activities. Because of the large number of times the

Dispatcher is executed, this can represent a substantial

amount of EXEC overhead. The overhead will show up in a SIP

report as high EXEC 0 percentages. If the quanta are set

too high, compute bound programs may degrade the response

time of interactive programs. A delicate balance can only

be achieved by experimentation, but the process is simplified

with Level 33 of the EXEC. The SIP report for Level 3 3

prints the number of times an activity exceeded the quanta

at each level. This information can be used to determine if

the quantum assigned to a particular level should be increased

or decreased.

D, TEST AND SET INTERRUPTS

Test and set interrupts are used to protect common data

areas in a multiprocessor configuration. A common data area

is o-ne that may be concurrently accessed by more than one

activity. Each area to be protected has a test and set word

associated with it. Before accessing a protected area, an

activity executes a test and set (TS) instruction on the

protection word. If the word is clear, it is set; and the

9
access takes place. If the word is set, a test and set

interrupt occurs; and the activity continues to retry until

the word is cleared.

SIP counts the number of test and set interrupts for

each test and set word. SLEXl , which protects the switch

list, normally has the highest counts. Abnormally high test

and set counts indicate processor contention and should be

investigated

10
IV. MEMORY MANAGEMENT

A. MEMORY CONFIGURATION

The maximum memory space available on UNIVAC 1108 's is

262K words. Because memory is limited, it assumes increased

importance when evaluating system performance. Drawing a memory configuration is a useful first step in determining

how efficiently memory is being utilized. The configuration

should show how much memory is reserved for system functions

and how much is available for user programs. The dynamic

characteristics of memory behavior will determine if it is

distributed in the most efficient manner. The general

memory configuration for UNIVAC 1108 's is illustrated in

Figure IV-1. The dynamic characteristics of memory usage

are described in the sections that follow.

B. MEMORY ALLOCATION

User main storage is dynamically controlled within the

EXEC by the Dynamic Allocator (DA) . The DA is responsible

for allocating main storage (core) to all active users in

the system. User requests for core are maintained on the

Core Request Queue (CRQ) . The DA selects the highest priority

request from the CRQ and attempts to assign memory to it in

the most economical way possible. The desirability of

assigning a particular segment of core to a program is based

on a set of internal cost factors.

When programs are initially loaded into main memory,

they are assigned a core quantum. A core quantum represents

a guaranteed amount of time that a program is allowed to

use memory. Once assigned a core quantum, a program

cannot be forced to be swapped out by a higher priority

activity until its core quantum has expired. Programs that

have completed their core quantum are eligible to be swapped

out to make room for other activities.

Gaining access to memory does not guarantee access to

the CPU. An activity in memory must compete with all other

activities in memory on a pure priority basis for access to

the CPU. CPU access is also controlled by quanta; however,

unlike core quanta, CPU quanta do not guarantee that an

activity will not be interrupted by a higher priority

activity.

Situations exist wherein a program may be eligible for

swap out even though its core quantum has not expired. The

most common situation arises when the program is waiting for

11
Resident EXEC I-Bank

Permanent Segment Area

EXEC Segment Overlay Area

User Main Storage

EXPOOL Expansion

Resident EXEC D-Bank

EXPOOL

Interrupt locations,

permanently resident

EXEC instructions

Transient segments selected

for permanent residency

Area reserved for execution

of transient segments

User programs and data

EXEC segments on a space

available basis

Expansion area if EXPOOL

becomes tight

Permanently resident

EXEC data storage

EXEC data storage pool

Buffers are requested and

released as needed

MEMORY CONFIGURATION

FIGURE IV-1

12
the completion of Symbiont I/O operation (READ$ or,PRINT$).

In general, whenever a program enters a long wait state, it

becomes a candidate for swap out.

Three performance hypotheses arise in connection with

memory allocation:

(1) Inefficiently assigned core priorities prevent the

system from properly discriminating among users.

(2) Core quanta that are set either too low or too high

are causing unnecessary system overhead in the form of

excessive swapping.

(3) Fragmented memory is causing blocks of memory to go

unused and programs to remain swapped out longer than

necessary

.

1 . Core Priorities

Access to main memory is controlled by core priorities.

Two sets of core priorities are defined: in-core priorities

and request priorities. That is, a program may have a different core priority while it is waiting on the CRQ than

when it is actually loaded into memory. The two sets of

priorities are summarized in Table IV-1 . The following

observations about Table IV-1 are noteworthy:

(1) Both demand and batch programs have an in-core

priority of 07 when they are using their initial quantum.

This guarantees that they will be loaded before all

other programs that have already received at least one

quantum.

(2) The core request priority of 10 is reserved for

batch programs that have been elevated by the Dynamic

Allocator Periodic Adjustment Routine (DAPA) to satisfy

the demand/batch sharing algorithm.

(3) Batch programs have a higher in-core priority than

request-core priority. This assures that waiting batch

programs will not cause in-core batch programs to be

swapped.

(4) EXEC segments residing in user program area have

lower priorities than all user programs. Since EXEC

segments may reside in user program space, this guarantees that user programs can get the space back v/hen

they need it.

13
(5) Common banks have higher priorities than most other

usersThis is significant, since system performance

may be improved by configuring certain programs as

common banks

PRIORITY REQUEST-CORE PRIORITIES IN-CORE PRIORITIES

00 UNUSED RESIDENT EXEC . 01 UNUSED DOWNED MEMORY

02 REAL-TIME REAL-TIME

03 COMMON STATIC BANKS COMMON STATIC BANKS

04 TIP PROGRAMS TIP PROGRAMS

05 CRITICAL DEADLINE CRITICAL DEADLINE

06 INCORE MOVE REQUEST COMMON DYNAMIC BANKS

07 COMMON DYNAMIC BANKS INITIAL QUANTUM PROG

10 ELEVATED BATCH PROG DEMAND

11 -17 DEMAND DEMAND

20 -27 UNUSED BATCH/NON-CRIT DL

30 -37 BATCH/NON-CRIT DL UNUSED

40 -50 UNUSED WRONG MEMORY TYPE

51 UNUSED LONG-WAIT BANKS

52 UNUSED LOAD-IN-PROGRESS SEG

53 UNUSED ACTIVE SEGMENTS

54 UNUSED WAITING SEGMENTS

55 UNUSED INACTIVE SEGMENTS

56 -76 UNUSED UNUSED

77 UNUSED AVAILABLE CORE

CORE PRIORITIES

TABLE IV-1

The problems associated with demand and batch core

priorities are described below.

a. Demand Core Priorities . Demand core priorities are

a function of program size and the parameter CQFACT. If

CQFACT is incorrectly specified, the system will not

properly discriminate among demand users. The demand

core priority (CQHL) is computed as

CQHL = 010"'' + Min (7, L)

This report follows the UNIVAC convention of writing

octal integers with an initial 0.

14
where L is the program level. The program level is a

function of program size S and C=CQFACT , as given by the

following equation:

L = S^+C+C/2 s2

The brackets denote that only the integer portion of the

result is used. The program size S is specified in core

blocks (512 words)

.

To determine the range of program sizes that corresponds

to different levels, the above equation can be solved

for S:

S = v^C (L-3/2)

Since EXEC Level 32R2 currently has C set equal to 800,

S = 20/ 2L-3

The equation for S can be used to generate Table IV-2.

The table demonstrates two important points. First,

all demand programs greater than 34K have the same level

and consequently the same core priority. Second, the

range of program sizes assigned to a given level decreases

as the level increases. That is, the level equation is

more sensitive to size changes in large programs than it

is to size changes in small programs.

LEVEL

L

SIZE (BLOCKS)

S

SIZE (K) RANGE (K)

1 0-19 0- 9 9

2 20-34 10-17 7

3 35-44 18-22 4

4 45-52 23-26 3

5 53-59 27-29 2

6 60-66 30-33 3

7 67- 34-

DEMAND PRIORITY LEVELS FOR CQFACT = 800

TABLE IV-2

15
The range of program sizes assigned to a unique

level can be increased by properly adjusting CQFACT. To

double the range of programs assigned different levels,

CQFACT must be increased by a factor of 4. Letting C = 4*800 = 3200 produces Table IV-3. When CQFACT = 3200,

the system distinguishes among programs in the range 0

to 67. As will be seen shortly, the core priority also

affects the computation of core quanta.

LEVEL SIZE (BLOCKS) SIZE (K) RANGE (K)

1 0- 39 0-19 19

2 40- 69 20-34 14

3 70- 89 35-44 9

4 . 90-105 45-52 7

5 106-119 53-59 6

6 120-132 60-66 6

7 133- 67-

DEMAND PRIORITY LEVELS FOR CQFACT = 32 00

TABLE IV-3

The Dynamic Allocator Response Time Report from SIP

may be used to determine if CQFACT is properly set.

This report specifies the number of requests of each

core priority that the DA received. If the requests are

not distributed across all priorities, CQFACT should

probably be adjusted.

b. Batten Coj.g Priorities . Batch core priorities are a

function of the run card priority. As was noted earlier,

batch programs have different core priorities, depending

on whether they are waiting to get in core or whether

they are already in core. The computation of batch core

priority is similar to that for demand programs:

In core: CQHL = 020 + L

Waiting for Core: CQHL = 030 + L

where L is the priority level. The priority level is

computed directly from the run card priority as follows:

^ _ ( P -'A' ) *8 L - ^ ^ ^ where P denotes the octal representation of the Priority P.

16
If the equation is evaluated for all values of P, Table

IV-4 can be produced.

KUJN LAKU FKxUKlii T X?'\7TPT LltiV tiLl

a R r* n nu E,F,G 1

H,I,J 2

K,L,M - 3

N,0,P,Q 4

R,S,T 5

U,V,W 6

X,Y,Z 7

BATCH PRIORITY LEVELS

TABLE IV-4

Table IV-4 suggests that batch users should be

assigned run priorities according to their relative

importance. If all users default to the same priority,

the potential benefit of being able to distinguish

between different batch users is obviated. Data about,

how run card priorities are used may be extracted from

the Master Log File.

2 . Core Quanta

Quantum size has important performance implications. If

quanta are set too long, demand response time may be lengthened.

If quanta are set too short, excessive swapping overhead may

be generated. The first step in determining how core quanta

should be assigned is to understand how they are computed.

The core quantum of a program is a function of (1) the

RUN CARD priority, (2) the time required to swap the program,

(3) the parameter CQAN, and (4) the core priority. The

objective is to give the program at least as much core

residency time as it takes to swap the program in and out.

This is an attempt to cut down on swapping overhead. More

specifically, the core quantum is computed from the following

formula

* * S * SFRATE + SFLATE

CQHL-CLTAL

17
The core quanta are measured in Standard Units of Processing

(sup's). One SUP corresponds to a 200-microsecond increment.

Hereafter, a 200-microsecond increment is r^^erred to as a

tic. The maximum quantum size allowed is 2 -1 tics = 262,14 3 tics = 52.4 seconds. The individual terms in the

core quantum formula are described below.

a. Swap Time . The basis of the core quantum calculation

is the time required to swap a program. The time to

swap a program in and out is given by

S * SFRATE + SFLATE

where S is the program size in core blocks (512 words)

SFRATE is the time in tics required to transfer two

blocks to the SWAP$FILE device, and SFLATE is the average

number of tics required to make two accesses to the

SWAP$FILE device.

The other terms in the formula are adjustments to

the swap time.

b. Run Card Priority . The run card priority affects

the core quantum multiplicatively . The highest run card

priority effectively doubles the quantum size. The

adjustment is given by

CZ' + 25 - P)/25

where P equal's the priority from the run card and 'Z' =

037 = 31. For example, if P = 'S', the factor becomes

( 31+25-24 ) /25 = 1.28. The minimum and maximum values

are ( 31+25-31 ) /25 = 1.0 and (31+25-6)/25 = 2.0,

respectively.

c. CQAN Adjustment . CQAN is the core quantum dynamic

adjustment factor. It is currently hardcoded at 15.

Since it is divided by 10 in the quantum equation, it

increases the core quantum 1.5 times. CQAN is the only

external parameter available for adjusting the core

quantum size calculation.

d. Core Priority . When a program exceeds (uses up) its

core quantum, its core priority is reduced; that is, its

priority level is increased by one, up to a maximum

of 7. The next time the program is loaded, its quantum

size is doubled by multiplying the quantum by

I CQHL-CLTAL

2

18
where CQHL is the highest priority allowed for the

program and CLTAL is the priolrity last assigned to the

program. The computation of CQHL is described in the

section on core priorities (IV.B.l.a). CLTAL is given

by

CLTAL = CQHL + N

where N is the number of quanta that have been used since

the program began executing. Since the maximum spread

between CQHL and CL'gAL is 7, tl^e core priority adjustment

lies in the range 2 =1 and 2 = 128.

The fact that CQHL is used to compute CLTAL demonstrates the importance of correctly specifying the

parameter CQFACT. If CQFACT is set too low, large

programs will receive a high (low numeric value) initial

core priority. This means that the program will have

more opportunities to double its quantum size. System

performance could be affected if many large programs

begin doubling their core quanta.

e. Example . Consider the following parameter values:

P = 'S' = 030 = 24

S = 14 blocks = 7K

CQAN =15

SFRATE = 33 tics/block for 1782

SFLATE = 220 tics for 1782

CQHL = Oil = 9

CLTAL = 017 = 15

The core quantum Q is given by

Q = 2f^"-'-^l * [ (31 + 25-24 ) ^ 15^ * 14 * 33 + 220]

25 10

= 70851 tics

= 14.2 seconds

19
f. Problem Detection . Performance problems associated

with core quanta may be detected from SIP. The DA

Response Time Report specifies the number of requests

that exceeded their initial core quantum. If these

numbers are high, it may be advantageous to increase

CQAN. Performance for important batch users may be

improved by properly assigning run card priorities.

3 . Core Fragmentation

As memory is allocated and released, empty spaces are

created in memory that are too small to hold any available

program. This memory space goes unused, and memory becomes

fragmented. The Memory Fragmentation Report from SIP report

the number of program loads that failed because of memory

fragmentation. If memory fragmentation is found to be a

problem, it may be necessary to make adjustments to the

memory cost allocation table (CTABL)

CTABL is a set of seven parameters the DA uses to

optimize the allocation of memory. The cost table is

defined with two conflicting objectives in mind: (1) maximize memory utilization and (2) minimize the amount of

swapping. Swapping would be eliminated if a program were

allowed to remain in memory until it completed execution;

however, this would result in very poor memory utilization.

The cost table attempts to achieve a balance between these

two objectives.

The DA allocates memory in two phases: the first phase

(Phase 0) attempts to allocate memory based on a bank's

preference for primary or extended storage. Banks are

considered in the following order: require primary, require

extended, prefer primary, prefer extended, and no preference

The second phase (Phase 1) searches for available memory on

an individual, bank-by-bank basis.

A separate set of cost factors is used for each phase.

Of the seven factors in the cost tables, three are for

maximizing memory utilization and four are for minimizing

swapping. A sample cost table is given in Table IV-5.

Each factor in the cost table is used as a cost or weight to

perform a particular allocation. If C. is the cost for

factor i and X. is the value of factor i, the cost to make

a particular allocation is given by

7

Allocation Cost = E C

. *X

i=l ^ ^

20
Phase 0 cost factors attempt to minimize swapping, while

Phase 1 cost factors attempt to maximize memory utilization.

PHASE 0 PHASE 1

COST FACTOR COST COST

Core Priority 1 1

Distance from Edge 32 1, 024

Blocks not used , 1 2, 047

Blocks with I/D Conflict 1,024 32

Blocks not i^ Preferred

Storage Type

^

512 8

Blocks to swap out

^ 1,024 64

Programs to suspend 640 64

Minimize Swapping

COST TABLE

TABLE IV

C. DEMAND/BATCH SHARING

If system resources are not being properly distributed

between demand and batch users, it may be necessary to

adjust the parameters associated with the demand/batch

sharing algorithm. The demand/batch sharing algorithm is

driven by the three parameters DMIN, DMAX , and DINC. DMIN

specifies the minimum percentage of core block SUP's (CBSUP's)

guaranteed to demand users. DMAX is used to compute the

maximum percentage of CBSUP's that may be used by demand programs. That is, DMAX specifies the minimum percentage of

CBSUP's guaranteed to batch programs.

The DA Periodic Adjustment Routine (DAPA) is responsible

for guaranteeing that the required percentages are being

satisfied. DAPA computes the maximum allowed demand percentage as

MAXDEM = Min (DMAX, DMIN + DINC * DOPEN)

where DOPEN is the number of demand runs open at a particular

instant and DINC is the incremental percentage added to DMIM

21
for each demand run open. MAXDEM varies dynamically as the

number of demand runs open varies. MAXDEM is, however,

subject to an upper bound of DMAX. The entire process is

illustrated in Figure IV-2.

100%

BATCH MAY SWAP DEMAND

MAXIMUM

PERCENTAGE

ALLOWED

for dejiand

deadline may swap demand

demand may swap batch

minimTM

percentage

guaranteed

to demand

demand may swap deadline

0

DEMAND /BATCH SHARING ALGORITHM

FIGURE IV-2

MAXDEM

NOPxMAL

DMIN

DAPA computes the CBSUP ' s consumed by all demand programs during the previous n seconds . It then computes what

percentage this is of the total CBSUP 's available during

that time period. If the derived percentage is larger than

DMIN and less than MAXDEM, no adjustment is necessary. If

the derived percentage is greater than MAXDEM, DAPA adjusts

the core priorities of batch programs so that they are higher

than demand programs. This will enable batch programs to

swap out demand programs and consume a larger percentage of

the computer resources available. Similarly, if the derived

percentage is less than DMIN, demand programs are not receiving their guaranteed percentage. This is corrected by raising

the priority of demand programs above deadline batch priority.

SIP may be used to determine how the parameters are set.

The System Idle Activity Report lists the current values for

DMIN, DMAX, and DING. It also specifies the average number

22
of demand runs open (DOPEN) . These data can be used to

determine if DINC is reasonably set. For example, DINC

should be set such that

DMIN + DINC * AVG DOPEN < DMAX

The Master Log File can be used to determine the number

of CBSUP ' s being accumulated by demand and batch programs.

An estimate can be made from SIP by looking at the average

program size and the percent of CPU time consumed for each

type.

D. FUNCTION/SEGMENT ACTIVITY

The main performance problems associated with function/

segment activity are the delays caused by excessive segment

loads. EXEC segments are transient routines that normally

reside on mass storage (disk or drum) . If an activity

requests the service of a segment that is not in core, that

activity must wait until the needed segment is loaded.

Excessive loading of high frequency segments may significantly affect system performance.

The Function/Segment Activity Report in SIP may be used

to identify which segments are potential bottlenecks. Of

those segments with the highest request counts, the segments

with the highest load counts should be investigated in more

detail. Three hypotheses must be tested:

(1) The wrong segments have been made permanently

resident.

(2) The size of the segment overlay area is incorrectly

specified.

(3) The sticking powers assigned to the segments are

incorrectly specified.

These problems are discussed in the following sections.

1 . Resident Segments

The most direct approach to minimizing segment loads is

to make the most active segments permanently resident. This

approach, however, should be reserved for the most critical

situations. For example, if response time delays could be

23
directly related to the time required to load a particular

segment, that segment should be considered a candidate for

permanent residency. In many installations, the segment

D5CRIT satisfies this requirement.

Segments may be made permanently resident by specifying

them in an XXXSEG statement at system generation time. The

XXXSEG statement specifies how EXEC segments are to be

configured in the system.

2 . Segment Overlay Area

The next most direct approach for minimizing segment

loads is to increase the amount of storage permanently

reserved for EXEC segments. When memory is initially

configured, the EXEC reserves a fixed block of storage for

the execution of EXEC segments. Unless otherwise directed,

the EXEC reserves a space equal to the size of the largest

segment. If the size of the largest segment is 6K, the

segment overlay area may hold as many as 12 1-block (512-word)

segments. The size of the segment overlay area may easily

be increased by properly specifying the parameter OVSIZE.

Increasing the size of the overlay area does not guarantee

that certain segments will always be resident; it only

increases the probability that they will be resident. If a segment has a high sticking power (core priority) , the

probability will be even higher.

Segments do not have to execute in the segment overlay

area, and they may (and commonly do) execute in the user

program area. However, when executing in user core, they

have a lower core priority than any user program. If the

space they occupy is required by a user program, they will

be overlaid. (EXEC segments are reentrant and are never

swapped out. They are simply overlaid and reloaded when

needed again)

3 . Sticking Power

"Sticking power" is another name for a segment's core

priority. The term indicates the importance of retaining a copy of the segment in core. Sticking power is a four-digit

octal number in the form SSFF, where SS is the segment

status and FF is the segment frequency. The order of the

numbers determines that status is the most significant

component of sticking power. A segment's status changes

24
dynamically as the state of the segment changes. The four

possible states and associated status values are summarized

in Table IV-6. Note how these correspond to the core

priorities in Table IV-1.

STATUS STATE

52 Load-In-Progress (LIP)

53 Active

54 Waiting

55 Inactive

SEGMENT STATUS VALUES

TABLE IV-6

Frequency is the only part of sticking power that can be

explicitly specified. Frequency is defined at system

generation time by the parameter FREQ in the element AAPCT.

Frequency is an estimate of the relative expected usage of a particular segment. Since segment usage is very workload

dependent, the default values may be incorrect for a particular installation.

Proper frequency values are easy to assign. The segments

with the highest request counts should have the highest

frequencies. Increasing a segment's frequency should increase the probability of it being in core when it is requested.

When changing segment frequency, the following idiosyncrasy should be noted. Since frequency is a component of

core priority, low values correspond to high priorities. In

the element AAPCT, just the opposite is true. High values

correspond to high priorities. Frequencies in the range

00-77 may be specified.

E. EXPOOL

EXPOOL, the Executive Storage Pool, is a block of main

storage reserved for use by the EXEC. EXPOOL is organized

into a set of buffers that are acquired and released as

required. All buffers are initially one core block (512

I words )^in length; however, the EXEC may request buffers of

size 2 where n may range from 2 to 9 . When the EXEC

25
requests a buffer smaller than any that already exists, a larger buffer must be successively halved until the required

size is available. For example, a request for a four-word

EXPOOL buffer may result in a 512 word buffer being halved

seven times.

The major performance problems associated with EXPOOL

are listed below:

(1) EXPOOL size is set either too high or too low.

(2) Not enough EXPOOL expansion blocks are reserved.

(3) EXPOOL thresholds are improperly specified.

Each of these problems is discussed in the following sections.

1. EXPOOL Size

The size of EXPOOL is computed at system generation time

by the formula

EXPOOLSIZE = (e P . *W. +EXPADJ) * (9/8)

i

where P. is the value of parameter i and W. is the number of

words oi EXPOOL to be configured for each unit value of parameter i. For example, consider the number of EXPOOL words

required to support the maximum allowable number of batch runs.

MAXOPN specifies the maximum number of batch runs allowed

open, and EXPBCH estimates the number of EXPOOL words needed

to support each batch run. Therefore, MAXOPN* EXPBCH words

of EXPOOL will be reserved to support batch runs. Similar

requirements are computed in the element E8END for approximately 20 other parameters.

Since the EXPOOL requirement computed from the parameters

is an estimate, the computed value may have to be adjusted.

EXPADJ is a configuration parameter for this purpose. For

extra safety, a 12.5% cushion is added to the final value.

This is done by multiplying the final value by 9/8. A final

adjustment, not shown in the equation, is to round the

EXPOOL size up to an integral multiple of 01000.

Changes to EXPOOL size are made by changes to EXPADJ.

The proper size is easily determined by monitoring the

EXPOOL Activity Report in SIP. This report specifies the

maximum number of EXPOOL words in use during the monitoring

period. If this number is continually less than the number

26
of EXPOOL words allocated (also reported by SIP) , EXPADJ

should be set to a lower value. This may mean a larger

negative number. This is particularly important on a UNIVAC 1108, wherein memory is a critical resource.

The reverse problem is also important; i.e., not enough

EXPOOL is allocated. Such a condition will show up as an

EXPOOL tight condition or an EXPOOL expansion. In the

extreme case, all EXPOOL expansion blocks will be used, and

the system will crash with an 070 stop. These problems are

discussed in the next two sections.

Before assuming that EXPOOL size is too low, potential

problem areas should be investigated. The most common cause

of EXPOOL being used up is a program that uses an inordinate

number of mass storage granule tables. Another common cause

is excessive operator key-ins. Both these conditions use

large numbers of EXPOOL words.

2. EXPOOL Expansion

Whenever an EXPOOL request is made and there are only

two core blocks of EXPOOL space remaining, EXPOOL will

expand. EXPOOL expands one core block at a time, up to a maximum of EXPEXP blocks. EXPEXP is a CONFIG parameter that

specifies the maximum number of 512-word expansion blocks

allowed. Because EXPOOL expands so that the EXPOOL area

remains contiguous (see the configuration diagram in Figure

IV-1), user programs may have to be swapped out so that

memory can be reorganized. Once EXPOOL expands, it does not

contract

EXPEXP is an important parameter. If the system uses

all the expansion blocks available and still needs more, the

system will crash with an 070 stop. EXPEXP should therefore

be set high enough to avoid such a catastrophe.

3. EXPOOL Thresholds

Before EXPOOL thresholds can be explained, the priorities

associated with EXPOOL requests must be described. In

addition to specifying the size of EXPOOL buffer required,

each EXPOOL request has a priority associated with it.

There are two main priority types: non-immediate and immediate. Non-immediate requests are non-critical requests

that may be queued if no EXPOOL buffers are available.

Alternatively, non-immediate requests can specify an abnormal

27
return rather than be queued to wait for an available

buffer. Immediate requests, on the other hand, are critical. They must be satisfied immediately, and they cannot

be queued. If they cannot be satisfied, the system will

crash (070 stop)

Non-immediate requests are further divided into low,

medium, and high priorities. If no priority is specified,

medium priority is assumed. SIP summarizes the number of

EXPOOL requests by both size and priority.

Associated with each non-immediate priority is a threshold.

The purpose of each threshold is to guarantee that a certain

number of EXPOOL words will be reserved for the next higher

priority request. The thresholds are EXTLOW, EXTMED, and

EXTHIG for priorities low, medium, and high, respectively.

When the EXPOOL in use reaches one of the thresholds, all

requests with a priority less than or equal to the priority

for that threshold will be queued. For example, when the

EXPOOL in use reaches EXTHIG, only immediate requests will

be honored. All non-immediate requests will be queued or

given abnormal returns.

Whenever EXPOOL in use reaches one of the thresholds,

EXPOOL is said to be "tight." SIP reports the number of

times EXPOOL became tight and the number of requests that

occurred while EXPOOL was tight.

EXTLOW, EXTMED, and EXTHIG are hardcoded in the element

E8END. If they are not specified properly, EXPOOL may not

become tight soon enough to prevent a crash; or EXPOOL may

become tight too soon and cause severe system performance

degradation. They are specified as octal percentages of

EXPOOLSIZE. For example, the default value for EXTHIG is

EXPOOLSIZE * 076/0100. The corresponding multipliers for

EXTLOW and EXTMED are 070/0100 and 074/0100, respectively.

Another threshold used to signal a shortage of EXPOOL

space is EXSCH. EXSCH is defined as EXTLOW-EXPBCH , where

EXPBCH is the number of EXPOOL words required to support one

batch run. If the EXPOOL in use goes above EXSCH, the

Course Scheduler (CSN) prevents any additional batch runs

from being opened.

28
V. FACILITIES MANAGEMENT

A. MASTER FILE DIRECTORY

The Master File Directory (MFD) contains the control

information needed to manage catalogued files. At the heart

of the MFD is the directory look-up table. The look-up

table contains a one-word pointer to the detail information

for each catalogued file in the system. The look-up table

is indexed by a hash code computed from the file name. If

two file names are similar, there is a chance they will have

the same hash code and point to the same entry in the lookup table. If this happens, the look-up table entry must be

modified to point to a search item. The search item contains

pointers to the detail information for each file with that

hash code.

Four performance hypotheses apply to the efficient use

of the MFD:

(1) Too small a look-up table is causing duplicate hash

codes.

(2) Many similar (near duplicate) file names are causing

duplicate hash codes.

(3) Activities attempting to search the MFD at the same

time are being delayed because of contention.

(4) The MFD is improperly located on the mass storage

devices

1 . Look-up Table Size

The smaller the size of the directory look-up table, the

higher the probability of duplicate hash codes. Duplicate

hash codes have two adverse effects: (1) the MFD takes

longer to search, because an additional level of pointers is

introduced that requires an additional I/O operation; and

(2) mass storage space is wasted because a 28-word search

item is generated for as few as two file names with the same

hash code.

The size of the look-up table may be controlled by the

configuration parameter DCLUTS. UNIVAC recommends DCLUTS be

assigned a prime number at least twice as large as the

29
number of catalogued files in the system. Using a prime

number reduces the probability of two file names having the

same hash code.

2 . Similar File Names

Similar file names increase the probability of duplicate

hash codes. This may be minimized in two ways: (1) use a

prime number for DCLUTS and (2) avoid naming conventions that

repeat major portions of a file name.

A file's hash code is an index to the file's appropriate

look-up table entry. This hash code is obtained from a

hashing algorithm that operates on the file's file name and

qualifier. The file name and qualifier are combined by the

hashing algorithm to form a single 18-bit half-word. This

half-word is divided by the parameter DCLUTS, which specifies the look-up table's length. The remainder from this

division is the index into the look-up table. The entry

corresponding to the file name/qualifier combination is

found by adding the remainder to the look-up table's beginning address. Similar file names could therefore cause

several files to have the same entry in the look-up table.

3 . MFD Contention

Access to the MFD look-up table is controlled by a set

of lock cells. The number of lock cells is computed from

the parameter DLOKSF:

where DLOKSF must be an integer in the range 0 to 4 . N,

therefore, lies in the range 1 to 16.

The MFD is divided into N equal parts, and each part is

controlled by a separate lock cell. When an activity

accesses the MFD, only the portion of the MFD that contains

its file is locked. The remainder of the MFD is available

for concurrent use by another activity. If DLOKSF is set to

0, no concurrent accessing of the MFD may take place.

It would at first appear that DLOKSF should always be

set to 4. This is not true. When the EXEC needs to lock

the entire MFD, it must set each cell individually. Increasing DLOKSF by 1 doubles the overhead associated with locking

the entire MFD.

30
4. MFD Location

The MFD look-up table should be located on the fastest

mass storage device available (usually a drum) . The MFD

detail information for each file is contained on the same

device on which the file resides. This information comprises a device directory. For most mass storage devices,

the first directory track begins in Position 0. Three

exceptions to this rule are FASTRAND II, FASTRAND III, and

8460 disks.

The parameters POSDIR and POS60 control the positioning

of the directory on FASTRAND and 8460 devices, respectively.

To minimize arm and head movement, the parameters should be

set so that the directory is located near the middle of the

allocated file space. Alternatively, if one or two files

account for the majority of a device's activity, the directory should be located near those files.

B. MASS STORAGE ROLLOUTS

The EXEC manages mass storage as a virtual resource.

That is, from a user's viewpoint, an unlimited amount of

mass storage is available. When more mass storage is requested than is physically available, the EXEC releases

space by rolling out infrequently used files to magnetic

tape

The rollout process is controlled by the five thresholds,

MSWl through MSW5 . These thresholds, which specify critical

levels of mass storage in tracks, are computed at system

generation time (see Table V-1) . When the total number of

unallocated mass storage tracks drops below MSWl, mass

storage is said to be "tight." This tight condition is

detected by the facilities allocation element FALL. When a

tight condition is detected, FALL calls the element ROLOUT,

which actually initiates the unload/rollout operation.

THRESHOLD DEFINITION TYPICAL VALUE

MSWl MSW2+MSW4 1664 tracks

MSW2 MSW3+MSW4 1248 tracksj^

MSW3 0150*MAXOPN 832 tracks

MSW4 MSW3/2 416 tracks

MSW5 0200 128 tracks

MSTOL MSW4/4 104 tracks

Assumes that MAXOPN = 8

TABLE V-1: MASS STORAGE THRESHOLDS

31
Separate actions are triggered as unallocated mass

storage falls below each thresholds An actual rollout to

magnetic tape may be initiated when MSWl is passedc MSW2

simply causes a warning message to be printed on the operator's console. When MSW3 is passed, ROLOUT places a Coarse

Scheduler Hold on all demand and batch runSc MSW4 generates

another warning message. Finally, if mass storage decreases

below MSW5 , any user requesting mass storage for file expansion is terminated. However, any EXEC mass storage requests

are still honored.

The physical rollout process is not performed by the

element ROLOUT, ROLOUT starts a predefined (canned) run

stream, which in turn calls the SECURE Processor, The

SECURE Processor is responsible for the management of all

catalogued files in the system, and rollout is one of its

functions

„

Four performance hypotheses are associated with the mass

storage rollout process:

(1) Mass storage rollout is occurring either too soon or

too late,

(2) Frequent rollouts are causing unnecessary system

overhead,

(3) Since an excessive amount of mass storage is rolled

out during each rollout operation, frequent rollbacks

are occurring,

(4) The SECURE processor is unloading the wrong files

and allowing inactive files to occupy mass storage,

1 „ Rollout Initiation

As described above, the rollout process is based on the

three threshold values MSWl, MSW3 , and MSW5 , Setting these

values involves a trade-off. If they are set too high, the

rollout process will be initiated while a significant amount

of available mass storage remains. If they are set too low,

the rollout process will be delayed, and mass storage requests

by user programs may be terminated,

MSWl is the most important threshold because it may

initiate an actual rollout of mass storage to tape (see page

34). MSWl should be set according to the system's file

allocation activity. This activity is based on (1) the

number of runs entering the system and (2) the mass storage

dynamic expansion by existing runs. An additional consideration is the amount of time it takes the operator to mount

32
the rollout tape. If the file allocation activity causes

mass storage to decrease below the MSW5 threshold before a rollout completes , MSWl should be increased. However, MSWl

should not be so large as to cause the rollout of mass

storage with a significant amount of remaining space. This

would cause a portion of mass storage to remain unused.

The MSW3 threshold is important for two reasons. First,

MSWl, MSW2 , and MSW4 are currently computed as a function of

MSW3 (see Table V-1). Thus, alterations to MSW3 must consider the effect on the other thresholds. Second, MSW3

determines when a Coarse Scheduler Hold will be placed on

demand and batch runs. MSW3 should be set according to the

dynamic expansion activity of the currently open runs. If

this activity causes mass storage to decrease below MSW5

,

MSW3 should be increased. As a guideline, MSW3 should be

the average file space required for a run multiplied by the

average number of runs concurrently active.

Whenever mass storage is reduced to the MSW5 threshold,

only EXEC mass storage requests are statisfied. MSW5 should

therefore be set large enough to handle these requests.

The principal information source concerning the optimal

setting of MSWl, MSW3 , and MSW5 is the console warning

messages . A unique warning message is displayed when available mass storage falls below each threshold. The rate at

which these messages appear serves as a guideline for settin

the thresholds . If the MSWl warning message is quickly

followed by the MSW2 and MSW3 messages, the MSWl threshold

should be increased. If the MSW3 message is quickly followe

by the MSW4 and MSW5 messages, MSW3 should be increased.

The MSW3 message should be displayed only occasionally; the

MSW5 message should almost never be displayed.

2 . Frequent Rollouts

Frequent mass storage rollouts might occur for two

reasons: (1) too few tracks are being unloaded during each

rollout and (2) a large number of mass storage requests

occurs within a short time period. Although little can be

done about the second reason, the first can be controlled.

The element ROLOUT calculates the number of tracks to be

unloaded from the following formula:

NBTRK = (f^) - AV

33
where TC is the total mass storage capacity in tracks configured in the system, AV is the number of available (unallocated) tracks at the time of the rollout, and PERCNT is a

parameter that specifies the fraction of total system mass

storage tracks to be made available as result of a rollout.

For example, if PERCNT = 20, l/20th (5%) of all configured

mass storage should be available after the rollout is

complete. Since AV tracks are currently available, the

amount to be unloaded is reduced by this amount. The number

of tracks to be unloaded is constrained so that

MSWl <_ NBTRK < 030000

That is, at least MSWl tracks, but no more than 030000 tracks,

are unloaded for each rollout. This constrained value of

NBTRK is plugged into a SECURE Processor command to unload

mass storage. The command as it appears in the predefined

run stream is

UNLOAD TRACKS = NBTRK.

Unless the number of tracks (NBTRK) is specified, the UNLOAD

command releases 3000 tracks.

The SECURE Processor first attempts to satisfy the UNLOAD

command by eliminating files which have current copies on

magnetic tape. Since these files are already duplicated on

tape they are just marked in the MFD as being unloaded and

no I/O to tape is done. As a last resort, the SECURE

Processor will select files without current copies on tapes

for unloading. To unload these files, I/O is required to

transfer them to magnetic tape.

The number of rollouts that occurs during a certain

time period may be obtained from the Master Log File. SECURE

performs the rollout operation under the RUNID ROLOUT. If

Master Log Data is unavailable, the SIP I/O Trace report may

be used to obtain the approximate number of rollouts that

occurred. This report specifies the number of words unloaded

for each file. Converting the number of words to tracks and

summing them will give the total number of tracks unloaded.

Dividing the total number of tracks by NBTRK will yield the

approximate number of rollouts

3 . Frequent Rollbacks

Frequent rollbacks may occur because too much mass

storage is unloaded during each rollout. This problem is

easily resolved by increasing PERCNT so that fewer tracks

are unloaded each time.

34
4 . Unload Eligibility Factor

The unload eligibility factor (UEF) determines which

files are to be unloaded during a rollout operation. If the

UEF is improperly specified, files may have to be reloaded

(rolled back) shortly after they are rolled out. The SECURE

Processor computes a UEF for each catalogued file. Those

files with the highest UEF are unloaded first.

The UEF is a function of six factors: (1) time since

last reference, (2) mean time between references, (3) size,

(4) equipment type, (5) F-Cycle, and (6) type: public or

private. Of these factors, only the first three are significant. The UEF is computed from the following formula:

UEF = CURNCY*P (TSLR) + FREQCY*P (MTBR) + SI ZEWT*P ( SI ZE

)

where TSLR equals time since last reference, MTBR equals

mean time between references, and SIZE equals file size in

tracks. The notation P (FACTOR) denotes the number of points

assigned to the specified factor. CURNCY, FREQCY, and SIZEWT

are weights associated with each factor.

The point values assigned to each factor are obtained by

a table look-up operation. The table used to look-up the

points for TSLR and MTBR is given in Table V-2. The point

values for SIZE are given in Table V-3. The UEF is normalized so that it lies in the range 0 to 63. Three UEF values

are reserved for special use. A UEF of 0 is reserved for

files that are already unloaded; a UEF of 1 is reserved for

catalogued tape files and removeable disk files; and a UEF

of 2 is reserved for files that are "unload inhibit" (V option)

The optimal point values and weights depend on the

unique file characteristics of an installation. The characteristics of each file may be extracted from the MFD and

summarized by the program LISTER. In release 19R1 Version 2

of the SECURE Processor, CURNCY is set to zero. This implies

that TSLR has no effect on which files are selected for

unloading. The other weights have a value of 1 in the same

release Df SECURE.

The calculation of UEF by SECURE is illustrated by the

following example. The file ACOB*PFPROJECT has the following characteristics:

TSLR = 4 days 15 hours = 4.63 days

Time since catalogued = 104 days

Number of references = 46

35
HOURS DAYS POINTS HOURS DAYS POINTS

1X1X ft n X1 o

o VJ • u oo ^ o 41 n ft . u o X1 7/ U • -L ^ X X o 4 ft ^ X1 fto

A A*± X J 1 ^ ft X1 Qy 7 X ^ ^

1 n o X1 ft? o ^ 7/.JOi^iR ^ X

-L -J 7 X ^ ft ft ^ 16 0. 67 8 242 10.08 23

21 0 88 9 272 11 ^3 24

28 1.17 10 302 12.58 25

34 1.42 11 344 14.33 26

40 1.67 12 386 16 .08 27

50 2. 08 13 428 17.83 28

60 2.50 14 470 19.58 29

70 2. 97 15 512 21.33 30

544 23.08 31

TABLE V-2: POINT VALUES FOR TSLR AND MTBR

TRACKS POINTS TRACKS POINTS

20 1 500 16

40 2 550 17

60 3 600 18

80 4 650 19

100 5 700 20

120 6 810 21

140 7 920 22

160 8 1030 23

180 9 1140 24

200 10 1250 25

250 11 1360 26

300 12 1470 27

350 13 1580 28

400 14 1690 29

450 15 1800 30

1900 31

TABLE V-3: POINT VALUES FOR SIZE

36
MTBR = 2.26 days

SIZE = 2 tracks

From Tables V-2 and V-3, the point values are

P (TSLR) = 18

P (MTBR) = 14

P (SIZE) 1

Therefore, the UEF is 0*18+1*14+1*1 = 15.

C. GRANULE TABLES

Mass storage is allocated in increments called granules.

Granules may be specified in either tracks or positions.

One track equals 64 sectors or 1792 words; one position

equals 64 tracks or 114,688 words. The EXEC sets up buffers

called granule tables to keep track of the physical mass

storage assigned to each file. Granule tables contain 26-word

entries. Each entry in the granule table reserves a physical block (granule) of mass storage. If track granularity

is specified, each word in the granule table represents 1792

words of mass storage. If position granularity is specified,

each word in the granule table represents 114,688 words of

mass storage. If a file occupies non-contiguous mass storage

space, the intervening space must also be included in the

granule tables. Granule tables are stored on mass storage

and brought into EXPOOL buffers when they are needed.

Four performance hypotheses apply to granule table usage:

(1) Users are specifying the wrong file granularity on

their assign cards.

(2) The maximum number of granule tables allowed in

EXPOOL when EXPOOL becomes tight is inefficiently

specified.

(3) The maximum number of mass storage sectors requested

at one time for file granule tables is too small.

(4) The default values for the maximum number of granules

assigned to a file is excessive.

37
1 . File Granularity

A file is allocated mass storage in granules. Thus, if

a file with position granularity uses only one track of a

position, the entire position is allocated to that file. A

complete track is allocated to a file when track granularity

is specified.

Specifying track granularity utilizes mass storage more

effectively than position granularity. If a file with track

granularity uses only part of a track, only a portion of a

track is unused. However, if position granularity is specified for the same file, 63 additional tracks would be allocated to the file. These additional 63 tracks will be

unused and unavailable for allocation to other files. Since

track granularity results in a finer allocation of mass

storage, it is usually more efficient than position granulari

Position granularity should be specified only for large,

contiguous files. The main advantage of position granularity

is a reduction in main storage usage for PCT and EXPOOL

buffers. Position granularity uses a single granule or v/ord

of memory to specify 64 contiguous tracks. For the same 64

tracks, track granularity will use 64 granules or words of

memory. There is therefore a reduction in the amount of

main storage used. The swap file is one case wherein position granularity will reduce the amount of main storage

needed for granule tables.

2 . Granule Tables in EXPOOL

A file's granule tables, which are located in the

directory of the file's device, are chained together.

Whenever part of a file is accessed, the granule table

referencing that part is brought into EXPOOL. If an I/O

operation references a granule not addressed by the granule

table in EXPOOL, the other granule tables are read in one at

a time until the proper granule table is found.

The parameter NGTB specifies the maximum number of a file's granule tables permitted in memory when EXPOOL becomes

tight (when the remaining number of EXPOOL buffers has

dropped below a critical threshold) . If a file has more

than NGTB granule tables when EXPOOL becomes tight, granule

tables are paged out until only NGTB remain.

38
Two performance problems are associated with NGTB

First, if NGTB is set too large, valuable EXPOOL space is

occupied by excess granule tables. Second, if NGTB is set

too small, excessive granule table paging may result. As an

example, suppose NGTB were set to one and a random access

file were alternatively referencing two granule tables.

Each reference would cause one granule table to be written

out and the other to be read in. If NGTB were equal to 2

and both granule tables were in EXPOOL, the paging would be

eliminated.

NGTB may be determined by deciding the amount of EXPOOL

that should be reserved for granule tables when EXPOOL is

tight. If AMT denotes this amount, NGTB may be found by the

following formula:

where NFILE is the number of concurrent files using granule

tables and 032 represents the number of words per granule

table

3 . Granule Table Mass Storage Sectors

File granule tables are maintained in the device directory,

and each granule table occupies one mass storage sector.

The hardcoded parameter MAXSEC specifies the maximum number

of granule tables (mass storage sectors) that may be requested

by the EXEC at one time. The EXEC element FALL determines

whether the number of requested sectors is greater than

MAXSEC. If the requested number is greater, MAXSEC is used.

MAXSEC is also used to determine the required EXPOOL buffer

size for the element FASEC. (FASEC allocates sectors of

mass storage space for the EXEC.)

The main problem associated with JIAXSEC is setting it

too small. If a request is for more sectors than I4AXSEC

,

the remaining sectors will be requested again. Overhead is

generated because multiple FASEC requests occur when obtaining the required number of mass storage sectors. MAXSEC

should be set to the 80th or 90th percentile of the most

number of granule tables needed to describe the largest file.

4 . Default Value for Granules

An option on the facility control statements allows the

user to specify the maximum allowable file length in granules.

39
When this value is unspecified, MAXGRN is substituted.

MAXGRN is a configuration parameter that defines the default

value for a file's maximum number of granules. MAXGRN or

the specified value is used to indicate when the file's

length exceeds the maximum numiDer of granules.

The primary reason for specifying maximum file length is

to prevent a user from accidentally overallocating his file

space. Because this is more likely to occur during the

debug phase of a program, a possible value for MAXGRN is the

80th percentile of all file sizes.

D. MASS STORAGE MANAGEMENT PRACTICES

Improvement in facility performance is obtainable

through mass storage management. An overall review of mass

storage utilization should be made before the facility

parameters are altered. This would eliminate most of the

simple mass storage problems. Since mass storage usage is

dynamic, the review should be made on a periodic basis.

Depending on the system activity, a biweekly or monthly

review may be appropriate.

Three performance hypotheses apply to mass storage

management

(1) Incorrect file placement is causing excessive I/O

times and unit contention.

(2) Non-contiguously allocated mass storage file space

is causing excessive I/O and unused mass storage.

(3) Mass storage space is being wasted by unused cataloged files.

1 . File Placement

Several factors must be considered when attempting to

optimize file placement: the size of the file, the frequency

of file access, the potential for file contention, and the

performance characteristics of the available mass storage

devices. In general, the most frequently accessed files

should be placed on the fastest devices. If the files are

large or the devices are small, this may not be reasonable.

Similarly, if many frequently accessed files are placed on

the same device, a device contention bottleneck may result.

40
The following guidelines may be helpful when attempting

to optimally place files:

(a) Place the most frequently accessed files (usually

EXEC files) on the fastest device (usually a drum)

Contention and its resulting queuing may have to be

tolerated if no more high speed devices are available.

(b) Distribute large, frequently accessed files across

several devices to minimize the possible contention.

(c) Assure that files are allocated contiguous space on

the devices to which they are assigned.

(d) Distribute frequently accessed files across several

devices of the same speed.

(e) If the controller is found to be the source of most

queuing (rather than the individual devices), consider

installing a dual access controller.

The information needed to make the above decisions may

be obtained from a combination of SIP, MFD map (DIRVER) , and

MFD list (LISTER) . The Main Storage Analysis by Unit Report

in SIP summarizes the queuing associated with the controllers

and the units. DIRVER may be used to identify the largest

files; LISTER may be used to identify the most frequently

referenced files.

2 . Non-contiguous Mass Storage Allocations

Non-contiguous mass storage occurs when mass storage is

allocated in clusters throughout a device. This causes a newly catalogued file to be allocated in pieces throughout

the device. Non-contiguous allocations cause an increase in

the number of seeks required to read or write a file. As a result, the I/O times for this file will be greater than for

a contiguously allocated file. There will also be an increase

in overhead because of the multiple-parting (M-part) of I/O

requests, i.e., the user makes I/O requests for a group of

logically contiguous words that are actually non-contiguous

on mass storage. The EXEC must compute additional access

control words (ACW's) in order to handle these non-contiguous

blocks

The most convenient indicator of whether a system's mass

storage space is allocated non-contiguously is the number of

41
multiple-parting I/O requests that occur. The SIP report

that deals with the number of times various EXEC areas were

entered contains this information. This report provides the

number of times the EXEC area dealing with M-parts was entered.

If this number is large, non-contiguously allocated mass

storage is indicated. Specific, large, frequently accessed

catalogued files with non-contiguous allocations can be

identified by using (1) a MFD list (LISTER) for the number

of accesses since the file was catalogued and (2) a MFD map

(DIRVER) for determining if the files were non-contiguous.

Two actions may alleviate non-contiguous mass storage

space. First, unused catalogued files should be deleted (as

discussed in the following section) . This will make more

mass storage available and increase the probability of a file being allocated contiguously. Second, the file administrator should periodically review how large, frequently used

files are allocated. If a file is identified as being

non-contiguously allocated, it should be transferred to tape

and rewritten to a contiguous mass storage area. To make a

large enough contiguous space, several smaller files may

also need reallocation. The device that the file is being

allocated to should be considered at the same time that the

file is reallocated. If the file is accessed frequently,

assigning the file to a higher speed device may be

advantageous

3 . Unused Catalogued Files

One possible reason for mass storage unavailability is

the abundance of unused, mass storage catalogued files. A

good user practice is to delete a catalogued file when it is

no longer needed. If the users always delete their unused

catalogued files, (1) more mass storage space is available,

(2) there is less chance of allocating mass storage noncontiguously, and (3) mass storage rollouts will be reduced.

If there are users who do not delete their unused files,

then a procedure such as archiving might be employed.

Archiving is the deletion from mass storage of all catalogued

files not referenced for a fixed time period. These deleted

files are transferred to tape. At the same time the file is

deleted from mass storage, the file's Master File Directory

entry should also be eliminated. This will reduce the

number of unnecessary directory items. For example, catalogued files not accessed for seven days might be archived

to tape at the end of each week. Ideally, archiving will

prevent unnecessary EXEC initiated rollouts when mass storage

allocation activity is highest. The archiving process

should be done during non-production hours.

42
Another possible reason for mass storage unavailability

is that users are creating catalogued files instead 'of using

temporary files. This causes the " same situation as would

the unused catalogued files. The users should create a

catalogued file only when it is necessary.

E. SCHEDULING

The Course Scheduler handles the EXEC scheduling

functions. Batch runs are placed into a schedule queue

after the legality of the (SRUN control statement is checked.

Demand runs are immediately opened. When either a batch or

demand run is opened, the Course Scheduler reads the run's

first set of facility control statements. If the requested

facilities are unavailable, the run is placed in a facilities hold queue. When the run's facilities are available,

the run is fully accepted and the Dynamic Allocator is given

control

Two performance hypotheses apply to scheduling:

(1) The number of demand and batch runs simultaneously

open does not effectively utilize computer resources.

(2) The installation is not taking advantage of the run

card priorities to assist in scheduling work.

1 . Demand/Batch Runs Open

A system's run mix can consist of demand and batch runs.

The emphasis that the Course Scheduler places on either run

type should be based on the objective of the computer

system. If the objective is service to demand users, care

should be taken to see that performance is not degraded by

batch runs. However, the number of batch runs allowed

simultaneously open should be set high enough to utilize

those computer resources incompletely used by demand runs.

For example, batch runs may use the CPU while demand runs

are waiting for I/O to complete.

The two parameters that affect the balance between

demand and batch are CDHOLD and MAXOPN. CDHOLD specifies

the maximum possible number of simultaneously active demand

runs. Similarly, MAXOPN specifies the maximum possible

number of batch runs open at one time. CDHOLD should be set

to allow the greatest number of active demand runs without

43
(1) degrading demand response time to an unacceptable level

or (2) preventing the minimum required batch throughput.

MAXOPN should then be set high enough to allow the greatest

number of batch runs to be simultaneously open without

degrading demand response time. If MAXOPN is set as large

as possible, the Course Scheduler will control the computer

utilization. The Course Scheduler will select from the

backlog those batch runs that will use the remaining available computer resources.

Data needed for setting CDHOLD and MAXOPN are obtained

from two SIP reports. The System Idle Activity report gives

the average number of demand and batch runs open; the

Response Time Report provides the demand response time.

Demand response time is an indicator of the service that

users are obtaining. If the average number of open demand

runs is close to CDHOLD and demand response time is small,

CDHOLD can be increased. The same can be done for batch by

adjusting MAXOPN. If demand response time becomes unacceptable, CDHOLD and/or MAXOPN can be reduced until satisfactory

service is obtained (assuming some other condition is not at

fault)

2 . Run Priorities

The proper use of run priorities will result in (1)

providing equitable system availability to all users and (2)

establishing a priority structure that will allow critical

runs to receive better service. Whenever possible, user

runs should be assigned a priority. This allows the discrimination of various types of runs. For example, a distinction

should be made between a run's degree of I/O- versus CPUproneness. An I/O-prone run should receive a higher priority

than a CPU prone run. Of course, the urgency of the run is

another factor to be considered.

MPRIOR is one of two configuration parameters that

affect run priorities. MPRIOR specifies the maximum allowed

priority on a (SRUN statement. If the @RUN card priority is

higher than MPRIOR, then MPRIOR is substituted. MPRIOR is

useful in determining the number of priority classes that

may be assigned to a run. Since the possible priorities are

"A" through 'Z" (with "A" being a higher priority than "Z"),

up to 26 different classes (A through Z) are possible. If

MPRIOR is set to R, only nine classes are possible.

44
APRIOR is the second configuration parameter that

affects run priorities. APRIOR is the default priority used

for @RUN statements with no priority specified. Assuming

that most runs have a priority assigned, APRIOR should be

set to a lower priority than the majority of runs with

priorities assigned. However, if most runs default for

priority, the purpose of a priority structure is defeated.

The number of runs at each priority is obtainable from

the Master Log File. A report could be written that summarizes the general characteristics of those runs at each

priority. From this report, it may be determined if the

current priority structure is satisfactory or if runs with

common characteristics need assignment to a different run

priority.

45

VI . INPUT/OUTPUT

A. LATE ACKNOWLEDGMENTS

A late acknowledgment is the failure of the CPU to

respond to a control unit within a critical response time.

Every time a word is transferred between the CPU and a

control unit, the CPU must respond to a signal from the

control unit. For example, when a word is ready for input,

the control unit activates its Input Data Request (IDR)

line. When the word has been received by the CPU, the CPU

sends an Input Acknowledge (lA) signal back to the control

unit acknowledging receipt. The control unit can accept

another word from the device only after the lA signal has

been received from the CPU. Otherwise, the previous word

might be over-written before it has been accepted by the

CPU. During data output, the CPU must respond to an Output

Data Request (ODR) signal with an Output Acknowledge (OA)

signal within a critical response time. If a late acknowledgment occurs, the next word is not transferred until the

device's next revolution.

Four performance hypotheses apply to late acknowledgments

(1) Non-optimal drum interlace factors are resulting

in slow effective transfer rates.

(2) Scatter read and gather write requests on a disk

subsystem are causing persistent late acknowledgments.

(3) Symbiont scatter/gather I/O is causing late

acknowledgments

(4) Late acknowledgments are occurring on a memory

module overloaded by I/O requests.

1 . Interlace Factors

Five possible interlace factors are used on the FH-432,

FH-1782, and FH-880 drums: 1, 2, 4, 8, and 16. An interlace of 1 implies that logically consecutive data words are

stored in contiguous drum locations. If the drum interlace

is n, n-1 drum locations are skipped between consecutive

data words. Doubling the interlace factor halves the drum

transfer rate. Interlace factors may be altered either by

resetting a switch or by physically changing several integrated circuit boards within the drum's controller. The

47
configuration parameters DHLACE, DHLACH, and DHLAC8 tell the

EXEC what interlace factors are being used for the FH-4 32,

FH-1782, and FH-880 drums, respectively. If they are incorrectly specified, the EXEC vill erroneously compute timing

information associated with the drums.

The optimum interlace factor involves a trade-off

between obtaining the highest data transfer rate and the

number of late acknowledgments that occur. Whenever a late

acknowledgement occurs, an additional drum revolution

(called a missed revolution) is required to read or write

the next word. The number of late acknowledgments might

therefore be great enough to offset the doubling of the

transfer rate by using a lower interlace factor. The optimum interlace factor should be the least possible value of

1, 2, 4, 8, and 16, where the number of late acknowledgments

will not decrease the effective transfer rate below the

slower transfer rate obtainable at a higher interlace factor.

The SIP Input/Output Activity Report is useful in determining the optimum interlace factor. The following information is obtained from this report:

TIME = Total channel busy time in seconds

WORDS = Number of words transferred

ACW = Number of I/O operations

AVAXST = Time per I/O operation in milliseconds

excluding data transfer time

AVAXST includes both the access time and the time lost due

to missed drum revolutions. The number of missed drum

revolutions N may be estimated by

_ ACW * (AVAXST-A)

This formula depends on two important assumptions that

may not always be true: (1) the number of ACW's equals the

number of I/O operations and (2) the true average access

time is equal to the theoretical. The first assumption is

not true for scatter/gather I/O, and the second is not true

for a sequence of I/O operations to the same area on drum.

Each subsequent I/O request will have missed the next data

word and will have to wait another complete revolution to

access the word.

43
where A equals the average access time of the drum and D

equals the delay per missed drum revolution. The average

access times for the FH-432 is 4.3 ms and the FH-1782 is

17.0 ms. The delay times for a missed revolution are 8.5

ms for the FH-432 and 34.0 ms for the FH-1782.

The effective transfer rate ER (including the missed

drum revolutions) is found by the following formula:

ER = W/ (W/R+N*D)

In this formula, W equals the number of words transferred

(as recorded by SIP) and R is the maximum transfer rate at

the present interlace. The factor (W/R) is the time to

transfer W words at R words per second; the factor (N*D) is

the time lost due to missed drum revolutions. If the

effective transfer rate ER is less than the transfer rate

obtained at the next higher interlace factor, the higher

factor should be used. If ER is greater than the next

higher interlace factor's transfer rate, the present interlace factor is satisfactory. Another, similar experiment

should be performed at the next lower interlace factor to

determine if a higher transfer rate is possible on the drum.

2 . Scatter/Gather I/O Requests

Late acknowledgments may occur on a disk subsystem

during scatter read and gather write requests. A scatter

read is an I/O technique wherein a contiguous block of data

that resides on a peripheral device is read into multiple,

non-contiguous main storage buffers. These data are transferred in a single, continuous I/O operation. A gather

write is the converse I/O operation--writing from several

main storage areas to one mass storage area.

An I/O operation uses an access control word (ACW) to

specify the length and location of each I/O buffer in main

storage. During a scatter/gather request, the EXEC must

switch control between ACW s as the I/O operation transfers

data to or from each buffer. This switching of ACW s is a potential cause of late acknowledgments on a disk subsystem

with a high transfer rate. Since the I/O operation is

continuous, ACW s must be switched within the time interval

between the transfer of consecutive data words.

Late acknowledgments may be minimized by the configuration parameter INCORE . INCORE applies only to disk subsystems. When INCORE is set to one, code is generated to

49
I

ensure that each ACW specifies a main storage buffer 'whose

length is an integer multiple of a" disk's record length.

This guarantees that ACW switching will occur on record

boundaries. When ACW' s are switched on a record boundary,

more time is available for changing ACW's because additional

time is required to pass over the interrecord gap.

The SIP Input/Output Activity Report may be used to

determine if late acknowledgments are occurring on a disk

subsystem. The following information is obtained from this

report

ACW = Number of I/O operations

AVAXST = Time per I/O operation in milliseconds

excluding data transfer time

The number of late acknowledgements N may be estimated

by

N = ACW* (AVAXST - A)

D

Since AVAXST includes both the access time and time lost due

to missed disk revolutions, the disk's average access time

A is subtracted from AVAXST. The value D equals the delay

per missed disk revolution. If scatter/gather requests are

used often and N is large, INCORE should be set to 1.

As general guidelines, UNIVAC recommends that INCORE be

set to 1 on (1) any 1106 system or (2) an 1108 system with

8440 disks configured. If persistent late acknowledges

occur on an 1108 or 1106 II system, INCORE should also be

set to 1. INCORE should be set to 0 on (1) 1108 systems

configured with 8414, 8424, or 8425 disks on a high priority

channel or (2) any 1110 system.

3 . Symbiont Scatter/Gather Requests

Late acknowledgements may also occur during symbiont

scatter/gather I/O requests. The symbiont complex maintains

its data in chains of 28-word buffers within core. During

an I/O operation, symbiont data are read into or written

from this chain of eight buffers. A total of 224 words is

transferred at one time. These words are transferred directly

to or from these eight buffers during a scatter/gather I/O.

Since the I/O operation is continuous, the EXEC must be able

to change buffers between the transfer of consecutive words.

If the EXEC cannot switch to the next buffer fast enough, a

late acknowledgment occurs.

50
Symbiont late acknowledgments may be reduced by setting

the configuration parameter SCGA to 0. Symbiont scatter/

gather is disabled when SCGA equals 0. Instead of transferring data directly to or from the eight 28-word buffers,

a contiguous 224-word EXPOOL buffer is used. During a write

operation, the data of the eight 28-word buffers are transferred into a 224-word EXPOOL buffer. The actual I/O operation will then write the data from the 224-v7ord buffer to a

peripheral device. Conversely, the data read from a peripheral device will be transferred into the 224-word buffer and

then later dispersed into a chain of eight 28-word buffers.

UNIVAC states that SCGA must equal 0 if U20 tapes exist

on an 1106, 1108, 1108A or 1100/20 system. The U20 tapes

are not supported because of their high transfer rate of

about 53,33 3 words per second.

4 . Memory Module Overloading

Late acknowledgments, also called data overruns, may

occur when a memory module becomes saturated by I/O accesses.

This will occur when a memory module's transfer rate is less

than the combined transfer rate of the subsystems active on

the memory module. The number of late acknowledgments (data

overruns) can be reduced by setting the configuration parameter lOLM to 1. lOLM equated to 1 causes the assembly of

code for the EXEC's I/O Load Monitor.

I/O Load Monitor reduces late acknowledgments by adjusting the I/O activity on memory modules that are nearly

saturated with I/O requests. I/O Load Monitor does this by

maintaining the available I/O transfer rate (LMLVL) for each

memory module. LMLVL is the module's maximum I/O transfer

rate with the sum of subsystem transfer rates currently

active on the module subtracted out. Before a request goes

to the device handler, I/O Load Monitor compares this additional subsystem's transfer rate with LMLVL of the request's

memory module. If the request's subsystem transfe: rate is

greater, the request is queued. If not, the request's

subsystem transfer rate is subtracted from LMLVL, and the

request goes to the device handler. When a request's I/O

completes, the memory module's LMLVL is increased by the

amount of the completing request's subsystem transfer rate.

Another adjustment is made to LMLVL, depending on whether a data overrun occurred during the completed request's I/O.

If an overrun occurred, LMLVL is decreased by at least 12.5%

of LMLVL. This will reduce the number of future data overruns. If the request completed normally and a queue exists,

LMLVL is increased by at least 1.56% of LMLVL.

51
Information about the number of late acknowledgments

(data overruns) that are occurring can be obtained from the

SIP report I/O Load Monitor Activity. If nonrecoverable

data overruns are occurring^ the percentages used to adjust

a memory module's LMLVL might be altered.

lOLM may be set to 0 (turned off) when the sum of the

subsystem transfer rates is less than a memory module's

maximum I/O transfer rate. For example, a system could have

up to five FH-1782 drums transferring data to one memory

module before the sum of the subsystem transfer rates would

equal a memory module's maximum transfer rate. However, if

data overruns begin to occur, the monitor should be turned

on (lOLM = 1)

B. SEEK TIME

The time to access a disk record is the sum of seek time

and latency time. Seek time is the time needed to move the

disk's read/write head to the required cylinder. Latency

time is the time the disk rotates before the desired position

comes under the read/write head. Under pre-seeking, the

EXEC initiates disk seeks for requests that are queued.

When those requests are serviced, the disk v^ill be on position

and no seek time will be required.

Four performance hypotheses apply to pre-seeking:

(1) Pre-seeking is disabled on 8440 disk drives.

(2) The parameters used for selecting the next I/O

requests for pre-seeking are set wrong.

(3) Angular addressing on the 8440 disk subsystem is

disabled

(4) Full disk pack seeks are degrading disk performance.

1 , 8440 Disk Pre-seeking

When UNIVAC first introduced the 8440 disks, a hardware

error was associated with the 8440 pre-seeking function. As

a result, the parameter NOSEEK was placed in the element 10.

This parameter prevented 8440 pre-seeking until the problem

was corrected. Currently, NOSEEK is equated to 1-STPAUL.

If NOSEEK equals 1 (STPAUL = 0) , 8440 pre-seeking is disabled.

NOSEEK equated to 0 (STPAUL = 1) enables 8440 pre-seeking.

52
The hardware error associated with 844 0 pre-seeking was

corrected by Field Change Order (FCO) Number 037 (applied to

the disk controller). Field Support Bulletin Number 252,

dated 22 August 1974, details the application of pre-seeking

to the 8440 disks. If a site has this hardware error corrected, then NOSEEK should be equated to 0 in order to

enable pre-seeking. This problem does not apply to such

other disks as the 8414 's and 8460 's.

The amount of improvement obtained by pre-seeking depends

on the computer system's configuration and the system's

workload. Pre-seeking should provide significant improvement on an 8440 disk subsystem if (1) there are more than

two disks per control unit or more than three disks per dual

access controller, (2) the workload is I/O-prone, and (3)

the file activity is distributed evenly between disk units

and throughout each disk unit. The SIP Input-Output Activity

report is useful for determining whether pre-seeking is

advantageous. Pre-seeking should decrease the percent of

time a disk subsystem's channel is busy. The value of

AVAXST should also decrease (the average time per I/O operation, excluding data transfer time)

2 . On-Position Requests

The EXEC element 10 attempts to minimize disk access

time (read/write head movement) by servicing on-position

requests before other requests. An on-position request is

a request that references the cylinder where the read/write

head of the disk is currently positioned. The parameter

MAXOPR limits the number of on-position I/O requests that

will be serviced consecutively. After MAXOPR on-position

requests have been serviced, the disk's position is advanced

one position. The disk I/O handler moves the read/write

head in one direction until all requests in that direction

have been checked. When an edge is reached, the scan direction is reversed. If no on-position requests are found when

searching the request queue, the request closest to the

current disk position (in the scan direction) is selected

for service. Since the disk only scans in one direction at

a time, it is possible for the previous on-position request

to be closest and again given service.

To prevent a request from being permanently locked out

by on-position requests, the parameter MAXLLC is used.

MAXLLC specifies the maximum number of times that a request

may be passed over. A request is considered passed over if,

after having been selected as the closest request, it is

53
then rejected because either an on-position request or a

closer request was found. A request may be rejected only

once each time the request queue is searched. When 10

detects a request that has been rejected flAXLLC times, that

request is serviced immediately.

MAXLLC should be set larger than MAXOPR; otherwise, the

purpose of MAXOPR will be defeated. The value of MAXOPR

should be based on the length of time that requests may be

locked out because of on-position requests » The time allowed

depends on whether the computer's workload is demand or

batch. If the workload is demand, a series of on-position

requests should be allowed to monopolize a device for only a

short period of time (say, one-half second) . In a batch

environment, the potential lockout time may be longer (say,

one second) . After the allowed lockout time is established,

MAXOPR can be calculated from the SIP Input-Output Activity

report. For each disk subsystem, the average I/O time per

request is obtained by dividing the channel busy time by the

number of ACW's. MAXOPR for the subsystem is then obtained

by dividing the allowed lockout time by the average I/O time

per request. If several disk subsystems exist, potential

values of JIAXOPR should be calculated for each subsystem.

The actual value assigned to MAXOPR should be based on the

most active subsystem.

For example, assume the maximum allowed lockout time in

a demand environment is established at 0.5 seconds. From

SIP, the following data may be obtained:

8414 Channel Busy Time = 567,544 seconds

Number of 8414 ACW's = 17,119

Assuming one I/O request per ACW, the average I/O time

per request is 0.033 seconds. MAXOPR is calculated to be 15

requests (0.5/0.033).

3 . Angular Addressing

Angular addressing, also called rotational position

sensing, is another feature of the 8440 disk subsystem.

Like pre-seeking. Field Change Order (FCO) Number 037 must

be implemented on the 5033 Control Unit before the 8440

disks may use angular addressing. Angular addressing is

controlled by the parameter ANGLOF.

54
when an I/O request is initiated, a command is given to

the control unit specifying an angular position on a track.

The control unit will then determine if the disk is more

than a given distance away from the addressed position. If

it is, the channel is logically disconnected from the operation. Just before the disk rotates to the position where

the read or write will occur, the channel is logically

reconnected and the read or write occurs. This assumes that

the channel was not busy transferring another unit's data

when reconnection was supposed to take place. If the channel

was busy, the procedure is repeated during subsequent disk

revolutions. In these cases, the service time will actually

be longer than it would be without angular positioning.

4 . Full Pack Seeks

A performance problem occurs if a disk pack has frequently

used files allocated at the extremes of the pack. A simplified example is one file located on the pack's outer cylinder

and another file located on the inner cylinder. This would

generate full pack seeks and would result in an increase in

access times.

A special case of this problem is treated by the configuration parameter FASTSK. When the EXEC initially allocates

disk space to a file, the inner cylinder is allocated first.

Once the inner cylinder is full, the EXEC returns to the

outer cylinder to continue allocation. Since this process

often splits a frequently accessed system file, frequently

full pack seeks may occur. By setting FASTSK to 1, the

inner cylinder is marked allocated, and file fragmentation

is prevented.

One disadvantage associated with using FASTSK is a reduction in the amount of space available for allocation.

If an 8414 disk is prepped at 112 words per record, UNIVAC

states that 36 out of 3072 tracks will be unavailable for

allocation. A general solution to the seeking problem is to

force frequently accessed files to be placed close together.

This would eliminate frequent full pack seeks and not reduce

the amount of mass storage available for allocation.

C. BLOCK SIZE

I/O block size is the number of words transferred in one

I/O operation. Block size may degrade performance in either

of two ways:

55
(1) Block sizes that are not integer multiples Of the

physical disk record size are causing frequent read

before write operations.

(2) Small average block sizes are resulting in low

effective transfer rates and high EXEC I/O overhead.

Each of these problems are discussed below.

1 . Read Before Writes

Read before write I/O operations are generated by the

EXEC when the I/O block size is not an integer multiple of

the physical record size. Since the smallest unit of I/O is

the physical record size, a block which is smaller than the

record size must be written out as if it were a full block.

Since this might destroy good information at the end of the

physical record, the EXEC (1) reads the physical record into

core, (2) changes the part of the record that is being

written into, and (3) writes the entire record back to disk.

Read before write operations may be detected by SIP I/O

Trace. If a large number of them are occurring, two approaches may be used to reduce their frequency: (1) require

programs to specify an I/O block size that is an integer

multiple of the physical record size or (2) change the

physical record size to agree with frequently used I/O block

sizes

In general, disks may be prepped at one, two, or four

sectors per record. Since there are 2 8-words per sector,

disk record sizes may be 28, 56, or 112 words per record.

The only exception to the above rule is that a disk used for

EXEC files must be prepped at 28 or 112 words per record.

Since most disks are prepped at 112 words per record, I/O

block sizes should be multiples of 112 words. Since some

EXEC I/O is done in 2 8-word blocks, it may be advantageous

to prep the system disk at 2 8 words per record.

2 . Small Block Sizes

I/O block size is the number of words transferred in one

I/O operation. When this number is small, the effective

transfer rate for a large volume of data is substantially

reduced. This is because access times are typically much

longer than transfer times. Consider the following example

56
on a 1782 drum with a transfer rate of 240,000 words per

second and an average access time of 17 msec. A file of

10,000 words blocked at 100 words per block would require

1.74 seconds to transfer. Of this time, only 0.04 seconds

is devoted to the actual transfer of data; the remaining

time is due to access time. The same file transferred in

blocks of 1000 words would require only 0.21 seconds to

transfer, an eightfold improvement.

Besides reducing I/O time, large block sizes substantially reduce EXEC overhead. Fewer interrupts are generated, resulting in less I/O processing. The trade-off is

the increased memory size required to hold the buffers.

57

VII. TEST AND DEBUG

The EXEC contains parameters that control internal error

checking and the maintenance of trace entries. If the

system is unstable and crashes frequently, these parameters

are a valuable asset in debugging the system. Most of this

debugging information is found in a PANIC dump. On a stable

system, however, these parameters can be turned off and the

number of trace entries can be reduced.

Two performance hypotheses that relate to test and debug

parameters are:

(1) EXEC instructions are being executed to perform

unneeded error checking and event tracing.

(2) Critical memory space is being used for storing

trace entries and test and debug program instructions.

Table VII-1 lists the test and debug parameters and

identifies how each parameter adversely affects EXEC overhead. For the purposes of this table, the cutoff for low

and high time is based on the frequency that the code must

be executed; the cutoff used for low and high memory usage

is 200 words. Each of these parameters is described in

Appendix B.

PARAMETER

ADVERSE AFFECT ON EXEC OVERHEAD

TIME SPACE

DADBUG Low Low

DATRAC High Low

EXPTRACE High Low

FCDBSZ High High

FNCCHK High Low

lODBUG High High

SIPDAT High Low

SIPIO High Low

STPAUL High High

SWPCKO High Low

UNIVAC Low High

TEST AND DEBUG PARAMETERS

TABLE VII-1

59

APPENDIX A

PERFORMANCE HYPOTHESES

61

I. PROCESSOR MANAGEMENT

1. CPU Priorities . Batch programs that are assigned

the same CPU priority as demand programs are causing demand

programs to have degraded response times.

2. CPU Quanta . CPU quanta that are set either too high

or too low are causing the CPU to be inefficiently allocated.

3. Test and Set Interrupts . An excessive number of

test and set interrupts are causing programs to be delayed

until data areas are unlocked.

II. MEMORY ALLOCATION

1. Core Priorities . Inefficiently assigned core priorities

prevent the system from properly discriminating among users.

2. Core Quanta . Core quanta that are set either too

low or too high are causing unnecessary system overhead in

the form of excessive swapping.

3. Core Fragmentation . Fragmented memory is causing

blocks of memory to go unused and programs remain swapped

out longer than necessary.

4. Demand/Batch Sharing . System resources are not

being properly distributed between demand and batch users.

III. FUNCTION/SEGMENT ACTIVITY

1. Resident Segments . The wrong segments have been

made peirmanently resident.

2. Segment Overlay Area . The size of the segment

overlay area is incorrectly specified.

3. Sticking Power . The sticking powers assigned to

the segments are incorrectly specified.

IV. EXPOQL

1. EXPOOL Size . EXPOOL size is set either too high or

too low.

2. EXPOOL Expansion . Not enough EXPOOL expansion

blocks are reserved.

3. EXPOOL Thresholds . EXPOOL thresholds are improperly

specified.

63
V. MASTER FILE DIRECTORY

1. Look-up Table Size . Too small a look-up table is

causing duplicate hash codes.

2. Similar Filenames . Many similar (near duplicate)

filenames are causing duplicate hash codes.

3. MFD Contention . Activities attempting to search the

MFD at the same time are being delayed because of contention.

4. MFD Location . The MFD is improperly located on the

mass storage devices.

VI. MASS STORAGE ROLLOUTS

1. Rollout Initiation . Mass storage rollout is occurring

either too soon or too late.

2. Frequent Rollouts . Frequent rollouts are causing

performance degradation.

3. Frequent Rollbacks . Since an excessive amount of

mass storage is rolled out during each rollout operation,

frequent rollbacks are occurring.

4. Unload Eligibility Factor . The SECURE Processor is

unloading the wrong files and allowing inactive files to

occupy mass storage.

VII. GRANULE TABLES

1. File Granularity . Users are specifying the wrong

file granularity on their assign cards.

2 . Granule Tables in EXPOQL . The maximum number of

granule tables allowed in EXPOOL when EXPOOL becomes tight

is inefficiently specified.

3. Granule Table Sectors . The maximum number of mass

storage sectors requested at one time for file granule

tables is too small.

4. Default Value for Granules . The default value for

the maximum number of granules assigned to a file is excessive.

VIII. MASS STORAGE PRACTICES

1. File Placement . Incorrect file placement is causing

excessive I/O times and unit contention.

64
2. Non-Contiguous Mass Storage Allocation . Non-contiguously

allocated mass storage space is causing excessive I/O and

unused mass storage.

3. Unused Catalogued Files . Mass storage space is

being wasted by unused catalogued files.

IX. SCHEDULING

1. Demand/Batch Runs Open . The number of demand and

batch runs simultaneously open does not effectively utilize

computer resources.

2. Run Priorities . The installation is not taking

advantage of the run card priorities to assist in scheduling

work.

X. LATE ACKNOWLEDGMENTS

1. Interlace Factors . Non-optimal drum interlace

factors are resulting in slow effective transfer rates.

2. Scatter/Gather I/O Requests . Scatter read and

gather write requests on a disk subsystem are causing

persistent late acknowledgments.

3. Symbiont Scatter/Gather Requests . Symbiont scatter/

gather I/O is causing late acknowledgments

4. Memory Module Overloading . Late acknowledgments are

occurring on a memory module overloaded by I/O requests.

XI. SEEK TIME

1. 8440 Disk Pre-seeking . Pre-seeking is disabled on

8440 disk drives.

2. I/O Request Selection . The parameters used for

selecting the next I/O requests for pre-seeking are set

wrong

3. Angular Addressing . Angular addressing on the 84 40

disk subsystem is disabled.

4. Full Pack Seeks . Full disk pack seeks are degrading

disk performance.

XII. BLOCK SIZE

1. Read Be fore Writes . Block sizes that are not integer

multiples of~The physical disk record size are causing frequent

read before write operations.

65
2. Small Block Sizes . Small average block sizes are

resulting in low effective transfer rates and high EXEC I/O

overhead.

XIII. TEST AND DEBUG

1. Execution Time . EXEC instructions are being executed

to perform unneeded error checking and event tracing.

2. Memory Space . Critical memory space is being used

for storing trace entries and test and debug program instructions .

66
APPENDIX B

PERFORMANCE PARAMETERS

67

This appendix summarizes those parameters identified as

important for tuning system performance. The appendix

begins with a table (Table B-1) that alphabetically lists

all the parameters and identifies the EXEC area they affect.

Detailed descriptions of each parameter, organized into a

section for each EXEC area, follow the table. Each parameter has the following title line associated with it:

TYPE, ELEMENT, LINE NO, VALUE

where

TYPE = The parameter type: CP if

configuration and SW if software (hardcoded)

ELEMENT = Name of EXEC element where

the parameter is defined

LINE NO Line number within the element

where the parameter is defined

on System 7 as of 9 June 1976

VALUE Value on System 7 as of

9 June 1976

69
EXEC AREA AFFECTED

c M E F S I T

p E X A c / E u M P C H 0 S

0 0 I E T

t>K U

r

Li u /

Y L I U D

T L E

I I B

E N U

S G G

PARAMETER C M E F S I T

ANGLOF I APRIOR S

BAWAIT M

CDHOLD S

CHGDED S

SKSM F

CLRCOR M

COR$MAX E

COUNT C

CQAN M

CQFACT M

CTABL M

CURNCY F

DADBUG T

DATRAC T

DCLUTS F

DEDLIN S

DHLACE I DHLACH I DHLAC8 I DINC M

DLOKSF F

DMAX M

DMIN M

DSWTCHTYP C

EXPADJ E

EXPEXP E

PERFORMANCE PARAMETERS

TABLE B-1

70
EXEC AREA AFFECTED

Ci r co

T1 m1 P

TPb VA A

/-< V- Ei U

•Dr n

CO

0 0 I E T

R 0 L D /

Y L I U D

T L E

I I B

E N U

S G G

PARAMETER C M E F S I T

EXPRIM E

EXPSPL E

EXPTRACE T

EXSCH E

EXTHIG E

EXTLOW E

EXTMED E

FASTSK I FCDBSZ T

FNCCHK T

FREQ M

FREQCY F

INCORE I lODBUG T

lOLM I

LOGEOF F

LOGTYP F

LWAIT C

MAXCRD S

MAXCRQ S

MAXDEM S

MAXF4 I MAXF8 I MAXF17 I MAXGRN F

MAXLLC F

MAXOPN S

PERFORMANCE PARAMETERS

TABLE B-1

71
EXEC AREA AFFECTED

c M E F S I T

p E X A. C / E u M P C H 0 S

0 0 I E T

R 0 L D /

Y L I U D

T L E

I I B

E N U

S G G

PARAMETER C M E F S I T

MAXOPR I MAXPAG S

MAXRTC C

MAXSEC F

MAXTIM S

MAXTUX S

MAXTWAIT C

MPRIOR S

MSTOL F

MSWl F

MSV>?2 F

MSW3 F

MSW4 F

MSW5 F

NGTB F

NHOLDT S

NOSEEK I OVS I Z E M

PERCNT F

PMIN M

POOLS IZE I POSDIR F

POS60 F

PRIEXP E

QTMTBL C

RECBIN E

RSINCT S

PERFORMANCE PARAMETERS

TABLE B-1

72
EXEC AREA AFFECTED

c M E F S I T

p E X A C / E u M P C H 0 S

0 0 I E T

R 0 L D /

Y L I U D

T L E

I I B

E N U

S G G

PARAMETER C M E F S I T

SBLEVl T

SBLEV2 T

SBLEV3 T

SBLEV4 T

SBLEV5 T

SCGA I SIPDAT T

SIPIO T

SIZEWT F

SSDENS F

SSEQPT F

STORE M

STPAUL T

SWPCKO T

SWAP M

SYMALL I SYSPRP F

TFEXP F

TFMAX F

TRMXCO S

TRMXPO S

TRMXT S

UEFTRK F

UEFLUP F

UNIVAC T

WHLDRM F

XXXSEG M

PERFORMANCE PARAMETERS

TABLE B-1

73
PROCESSOR PARAMETERS

COUNT SW,

DSWTCHTYP SW,

LWAIT SW,

MAXRTC SW,

MAXTWAIT SW,

QTMTBL SW,

DISP, 134, EQU 01000

DAILR, 13, EQU BARH

AAPCT, 3041, EQU 50

DISP, 132, EQU 35000

DISP, 133, EQU 30001

DISP, 3677, See Below

74
PROCESSOR PARAMETERS

SW, DISP, 134, EQU 01000

COUNT specifies the number of words to

transfer for the Block Transfer instruction

in the Dispatcher IDLE Loop.

SW, DAILR, 13, EQU BATCH

DSWTCHTYP makes the demand switching type

equal to the Batch Type (6) . This was done

to reserve Type 4 for TIP processing. If no

TIP processing is being done, DSWTCHTYP may

be reevaluated.

SW, AAPCT, 3041, EQU 50

LWAIT is the length of wait time in milliseconds. It is used by routines that execute

an ER TWAIT$ to compute the desired length

of wait in msec. It is also used by the

Dispatcher as a threshold to determine if

the segment long wait bit (SGLWAT) should be

set. If the wait time is greater than or

equal to (5*LWAIT) , set SGLWAT.

SW, DISP, 132, EQU 35000

MAXRTC is the maximum real time clock value

in 200 ysec increments. The value 35000 is

equivalent to 7 sec. IVLAXRTC is used as the

"infinite" quantum size for Activity Types 1

through 3

SW, DISP, 133, EQU 30001

iyiAXTWAIT is the maximum time wait value in

milliseconds. The value 30001 is equivalent

to 30 sec. MAXTWAIT is the longest length of

time an activity will be allowed to wait

on the TWAIT queue.

SW, DISP, 3677, See Below

QTMTBL is a 7-word table that holds

the CPU quanta for Levels 1 through 7 for

75
PROCESSOR PARAMETERS (Cont'd)

Activity Types 4 through 6. The values in

milliseconds for the 1108 are:

LEVEL QUANTUM (msec)

1 1.4

2 3.0

3 32.0

4 64.0

5 128.0

6 256.0

7 512.0

76
MEMORY PARAMETERS

BAWAIT SW, DAPAM, 18, EQU 21

CLRCOR CP, AACONFIG, 7 32, EQU 1

CQAN SW, DA, 17 3, +15

CQFACT SW, AADAEQT, 17, EQU 800

CTABL SW, DA, 280, See Below

DINC CP, AACONFIG, 789, EQU 2

DMAX CP, AACONFIG, 8 02, EQU 50

DMIN CP, AACONFIG, 812, EQU 20

FREQ SW, AAPCT, 4996, See Below

OVSIZE CP, AACONFIG, 1068, EQU 0

PMIN SW, AADAEQT, 21, EQU 5

STORE CP, AACONFIG, 2193, See Below

SWAP CP, AACONFIG, 2903, See Below

XXXSEG CP, AACONFIG, 2.8 91, See Below

77
MEMORY PARAMETERS

BAWAIT SW, DAPAM, 18, EQU 21

CLRCOR

BAWAIT specifies the number of minutes a batch program will be allowed to wait on the

Core Request Queue (remain swapped out)

before DAPAM will requeue the core request

at a priority higher than all other demand

batch requests (priority 010)

CP, AACONFIG, 732, EQU 1

If CLRCOR is nonzero, core is always cleared

before loading a program. Core is cleared

regardless of the use of the B option at

collection

CQAN SW, DA, 173, +15

The core quantum adjustment factor, CQAN, is

one of several factors used to compute a program initial core quantum. Besides CQAN,

core quantum is a function of (1) RUN card

priority, (2) swap time, and (3) core

priority. The initial core quantum is

computed by SETCQU in DACCC in 200 ysec

increments

1

The maximum core quantum allowed is 2 -1 = 262,143 tics = 524 sees (1 tic = 200 ysec).

The core quantum is computed from

CQHL-CLTALl 'Z'+25-P *CQAN*SWAPTIME

25 10

where CQHL = Highest allowed priority

CLTAL = Current priority

CQAN = Core quantum adjustment factor

P = RUN card priority

CQFACT SW, AADAEQT, 17, EQU 800

CQFACT is used by CQLVL in DACCC and CCR

in DA to compute CQHL, the core priority for

demand programs. Demand core priorities lie

in the range Oil to 017. They are computed

from

78
MEMORY PARAMETERS (Cont'd)

CQHL = 010 + MIN(7,L)

CTBAL

where L is the program level. The program

level is a function of program size and C = CQFACT, as given by the following equation:

L = S'

C

+ 1.5

The brackets denote that only the integer

portion of the result is used. The program

size is specified in core blocks (512 words).

SW, DA, 280, See Below

The cost table (CTABL) is a set of seven

parameters used to optimize the allocation

of memory. The seven parameters are (1)

core priority, (2) distance of area from edge

of user space, (3) blocks within area not

in use, (4) blocks with I/D bank conflict,

(5) blocks not in preferred memory type,

(6) blocks that would have to be swapped

out, and (7) programs that would have to

be suspended. Each factor X. listed above

associated wit^i it. The cost

a program to a given area is

has a cost C.

of allocating

then given by

Allocation Cost =

E i=l

C. *X.

1 1

The area with the lowest cost is then selected

for allocation.

DINC

DMAX

DMIN

CP, AACONFIG, 78 9, EQU 2

DC, AACONFIG, 802, EQU 50

CP, AACONFIG, 812, EQU 20

DMIN, DMAX, and DINC are the basic

inputs to the demand/batches sharing

79
MEMORY PARAMETERS (Cont'd)

algorithm in DAPA. DMIN specifies the

minimum percent of computer time

guaranteed to demand programs . DMAX and

DINC are used to compute MAXDEM:

MAXDEM = MIN (DMAX , DMIN+D INC* DOPEN)

where DOPEN is the number of demand runs

open at any instant in time.

MAXDEM specifies the maximum amount of

time allowed for demand programs. This

guarantees that batch programs will

receive at least (100 -MAXDEM) percent

of the system resources.

SW, AAPCT, 4996, See Below

Frequency (FREQ) is a component of segment

sticking power. Sticking power is a fourdigit octal number of the form SSFF, where

SS is the segment status and FF is the

frequency. Status may have one of four

values, depending on a segment's current

state: 52 = load-in-progress , 53 = active,

54 = waiting, and 55 = inactive. Frequencies

are in the range 00 to 077 and are defined

at system generation time in the element

AAPCT. Sticking power is important because

it is issued as a segment's core priority.

CP, AACONFIG, 1068, EQU 0

OVSIZE defines the function/segment overlay

size. OVSIZE is the number of core blocks

devoted exclusively to transient EXEC segments

Increasing this value may increase throughput

but will decrease the amount of core available to user programs. A value of 0 will

cause the system to assign the minimum

amount of overlay core needed to avoid core

lock up, i.e., an amount equal to the size

of the largest segment.

80
MEMORY PARAMETERS (Cont'd)

SW, AADAEQT, 21, EQU 5

PMIN specifies the number of minutes a common static bank will be locked in memory

if unused. DAPAr4 scans the EXEC Bank Descriptor Table (BDT) and marks swappable

all common static banks that have not been

referenced for PMIN minutes.

CP, AACONFIG, 2193, See Below

STORE is a label in a System Generation

Statement (SGS) that defines the main

storage configuration. It has the form:

STORE FIRST, LENGTH, 'TYPE', INTLV

where

FIRST = First address of area

LENGTH = Length of area in 01000 's

TYPE = Memory type, e.g., '7005' for 1108

INTLV = 1 for no interleave and

2 for odd/even interleave

The fields are repeated for each area to

be defined. For example:

STORE 0 , 0100 ,

• 7005 ' , 2

CP, AACONFIG, 2903, See Below

SWAP is a label in an SGS that defines the

sizes and allocation of the program swap

file SWAP$FILE. It has the form:

SWAP MAX, 'CRN', 'DEVICE', GRAN

where

MAX = Maximum number of granules that

may be assigned to the file.

'GRN' = 'TRK' for track granularity

' POS ' for position granularity

81
MEMORY PARAMETERS (Cont'd)

•DEVICE' = Any Fastrand formatable

device type that may be used on an ASG

card, e.g., 'F17' = FH-1782 drum

GRAN = Number of granules to be reserved

on this device

' DEVICE ' , GRAN may be repeated as many

times as needed.

Example: SWAP 25, 'PCS', 'F17', 14, ' F2 ' , 1

XXXSEG CP, AACONFIG, 2891, See Below

XXXSEG is a label in an SGS that specifies

how EXEC segments are to be configured in

storage. It has the form:

XXXSEG, COND ' SEGl ' , ' SEG2 ' , . .

where

XXXSEG = XRESEG if segments are to be

made permanently resident for execution

in storage.

XXXSEG = XTPSEG if transient segments

are to be executed in primary storage.

Does not apply to 1106/1108.

XXXSEG = XRPSEG if segments are to be

executed in primary storage. Does not

apply to 1106/1108.

COND = An expression which, if it

evaluates to zero, indicates that the

XXXSEG statement should be ignored.

'SEGn' = A list of segments to which the

XXXSEG statement applies.

Example: XRESEG, NOMUX 'DSCRIT'

82
EXPOOL PARAJVIETERS

COR$MAX CP, AACONFIG, 739, EQU 32

EXPADJ CP, AACONFIG, 370, EQU 076000

EXPEXP CP, AACONFIG, 375, EQU 10

EXPRIM CP, AACONFIG, 868, EQU 0

EXPSPL CP, AACONFIG, 889, EQU 'H'

EXSCH sw. E8END, 28 5, EQU EXTLOW-EXPBCH

EXTLOW sw. E8END, 27 5, EQU EXTLNG*070/0100

EXTMED sw. E8END, 27 7, EQU EXTLNG*074/0100

EXTHIG sw. E8END, 27 9, EQU EXTLNG*076/0100

PRIEXP CP, AACONFIG, 1127, EQU 0

RECBIN sw. EXPOOL, 1 9 EQU 0

83
EXPOOL PARAMETERS

CP, AACONFIG, 739, EQU 3 2

COR$iyLAX is the maximum number of log entries

that is kept in core at any one time. Each

log entry uses a 32-word EXPOOL buffer. A

trade-off exists between EXPOOL usage and

logging overhead.

CP, AACONFIG, 370, EQU 076000

The EXEC estimates the amount of EXPOOL

required (EXPREQ) based on (1) the maximum

number of demand and batch jobs that may be

open simultaneously and (2) the particular

hardware configuration. Since EXPREQ may

over or under estimate the amount of EXPOOL

actually required, EXPREQ can be adjusted by

specifying an appropriate positive or

negative value for EXPADJ. The number of

words eventually reserved for EXPOOL is

given by EXPOOLSIZE and is computed in

E8END.

CP, AACONFIG, 375, EQU 10

EXPEXP is the number of 512-word EXPOOL

expansion blocks allowed. EXPOOL does not

contract once an expansion takes place.

CP, AACONFIG, 868, EQU 0

EXPRIM is the percent of EXPOOL in Primary

Storage (does not apply to 1106/8)

CP, AACONFIG, 889, EQU "H"

EXPSPL is the EXPOOL storage priority after

which EXPOOL gives buffers in extended

storage. This allows for fine tuning by

shifting allocation among PS and ES (does

not apply to 1106/8)

SW, E8END, 285, EQU EXTLOW-EXPBCH

EXSCH is used to signal to the system that

EXPOOL is approaching a tight condition.

EXSCH is equated to the low EXPOOL threshold

84
EXPOOL PARAMETERS (Cont'd)

less the estimated number of EXPOOL words

required for one batch run. EXPBCH is hardcoded in E8END to be 850. EXSCH is used by

the Coarse Scheduler (CSN) to prevent any

additional runs from being opened, it is

used in the UOM change in DAPA to indicate

an EXPOOL hold on the operator's console,

and it is used by FIMAIN to determine if a

facility's hold should be placed on a run.

SW, E8END, 275, EQU EXTLNG * 070/0100

SW, E8END, 277, EQU EXTLNG * 074/0100

SW, E8END, 279, EQU EXTLNG * 076/0100

Threshold values are used to determine when

EXPOOL is tight for the three types of nonimmediate priority requests. That is, if a low priority EXPOOL request is made when the

EXPOOL storage in use is greater than EXTLOW,

EXPOOL is said to be tight for that request,

and that request will be queued until the

EXPOOL in use drops below EXTLOW. EXTLNG is

the length EXPOOL storage in Extended

Storage; on the 1108, this is just EXPOOLSIZE.

CP, AACONFIG, 1127, EQU 0

PRIEXP is the number of primary EXPOOL

expansion blocks allowed (does not apply to

1106/8) .

SW, EXPOOL, 19, EQU 0

RECBIN is used as a conditional assembly

flag to turn EXPOOL recombination code on

and off. Its possible values have the

following meaning: 1 = complete recombining

and 0 = do not complete recombining.

85
FACILITIES PARAMETERS

CKbM CP , AACONFIG, 332, EQU 1

CURNLx bW

SECURE (MAIN)

"TOT _i_ r\ 16 1, +U

ULLiU i o AACONFIG, 765,

CF , AACONFIG, 793,

bWCTa7

/ SECURE (MAIN)

"7 "5 Q a. 1 / J y , +1

CF , AACONFIG, 488, U U

liUGi Yir LP / AACONFIG, 463, EQU 0

MAA(aKN UF f AACONFIG, 992, EQU 12 8

JMAAbJiC OTa7 bWFALL , 8 3, EQU 12 5

Mb i ULi CF , AACONFIG, 1014, EQU MSW4/4

MbWl LP / AACONFIG, 1012,

UF / AACONFIG, 1011, EQU MSW3+MSW4

MbW J CF , AACONFIG, 1009, EQU 0150*MAXOPN

OTa7 y1 LF , AACONFIG, 1010, EQU MSW3/2

JMbWo LP , AACONFIG, 1013, EQU 0200

OTa7 bW

FALL, 82, EQU 5 n"C^ T) ^IvTrn OTa7 bW , ROLOUT, 17, EQU 10

FUbUlK UF , AACONFIG, 1099, EQU 191

FUbD U L.F , AACONFIG, 1107, EQU 135

b J. ^HjW 1 bW , SECURE (MAIN)

738, +1

SSDENS CP, AACONFIG, 611, EQU 'V

SSEQPT CP, AACONFIG, 614, EQU '16N'

SYSPRP CP, AACONFIG, 621, EQU 4

86
FACILITIES PARAMETERS (Cont ' d

)

TFEXP CP, AACONFIG, 63 3, EQU 60

TFMAX CP, AACONFIG, 1327, EQU 360

UEFLUP SW, SECURE (SETUP), 2425, See V.B.4

UEFTRK SW, SECURE (SETUP), 2430, See V.B.4

WHLDRM CP, AACONFIG, 65 9, EQU 1

87
FACILITIES PARAMETERS

CP, AACONFIG, 332, EQU 1

CKSM activates the checksum feature of all

Master Bit Tables. The Master Bit Table

associated with each device will be lengthened

by one word because of the addition of a Checksum Word at the end. CKSM is also used

as a conditional assembly flag for code that

(1) adjusts each Master Bit Table's length,

(2) generates the checksum, and (3) determines

the validity of the checksum.

SW, SECURE (MAIN), 737, +0

CURNCY is the weight assigned to time since

last reference (TSLR) in the computation of

the unload eligibility factor (UEF) . A

weight of 0 implies that TSLR does not

affect which files are unloaded. This

setting applies to Level 19R1 VERS 2 of

SECURE.

CP, AACONFIG, 765, EQU 2049

DCLUTS specifies the size in words of the

Directory Loop-Up Table. The Directory

Look-Up Table is part of the Master File

Directory (MFD) and is used to index into

the other tables in the directory. The MFD

contains the identification and characteristics of each catalogued file.

CP, AACONFIG, 79 3, EQU 2

DLOKSF determines the number of MFD lock

cells and is called the MFD lock scale

factor. Each MFD lock cell prevents a portion of the directory look-up table from

being used. DLOKSF must be an integer from

0 to 4 . The number of MFD lock cells (one

36 bit word per cell) configured will be:

^DLOKSF

88
FACILITIES PARAMETERS (Cont'd)

Thus, the number of lock cells can range

from 1 to 16.

SW, SECURE (MAIN), 739, +1

FREQCY is the weight assigned to mean time

between references (MTBR) in the computation

of the unload eligibility factor UEF. This

setting applies to Level 19R1 VERS 2 of

SECURE

CP, AACONFIG, 488, EQU 0

LOGEOF, in conjunction with LOGTYP, controls

the conditional assembly of code that specif

action taken on log tape during autorecovery

LOGEOF is valid only when LOGTYP equals 1.

If LOGEOF equals 0, an EOF will not be

written; and the log tape will not be rewound on autorecovery. The EXEC will continue writing on the extended tape. If

LOGEOF equals 1, an EOF will be written on

the extended log tape; a rewind will be

done; and the next F-cycle assigned.

CP, AACONFIG, 463, EQU 0

LOGTYP controls conditional assembly flags.

Code is assembled, depending on whether the

Master Log is written on a FASTRAND device

or on tape. LOGTYP equals 0 specifies that

the Master Log is written on a FASTRAND

device. LOGTYP equal to 1 specifies that

the Master Log is to be written on tape.

LOGTYP is also used in conjunction with

LOGEOF to specify action taken during autorecovery .

CP, AACONFIG, 992, EQU 128

MAXGRN specifies the maximum number of

granules assigned to a file when no maximum

is provided.

89
FACILITIES PARAMETER (Cont'd)

MAXSEC SW, FALL, 83, EQU 12 5

MAXSEC specifies the maximum number of mass

storage sectors containing file granule

tables that may be requested at one time.

FALL checks if the number of requested

sectors is greater than MAXSEC. If the

requested number is greater than MAXSEC,

MAXSEC is used instead. MAXSEC is used in

the same manner to determine the required

EXPOOL request buffer size for the element

FASEC. FASEC is the EXEC element that

allocates sectors of mass storage space for

EXEC use.

MSWl CP, AACONFIG, 1012, EQU MSW2+MSW4

MSW2 CP, AACONFIG, 1011, EQU MSW3+MSW4

MSW3 CP, AACONFIG, 1009 , EQU 0150*MAXOPN

MSW4 CP, AACONFIG, 1010 , EQU MSW3/2

MSW5 CP, AACONFIG, 1013 , EQU 0200

MSTOL CP, AACONFIG, 1014 , EQU MSW4/4

MSWl through MSW5 are thresholds used in the

rollout process to determine the criticality

of mass storage availability. A console

message is displayed whenever mass storage

availability goes below each threshold, and

a different message is displayed when the

availability exceeds each threshold. MSTOL

makes the amount of available mass storage

appear less than it actually is when mass

storage availability increases. Thus, MSTOL

prevents "toggling" between console messages

when mass storage oscillates around a threshold.

NGTB SW, FALL, 82, EQU 5

NGTB specifies the maximum number of granule

tables that a catalogued file may have in

90
FACILITIES PARAMETERS (Cont'd)

EXPOOL when EXPOOL becomes 'tight'. EXPOOL

is 'tight' when the available EXPOOL Storage

drops below EXTLOW words (an EXPOOL parameter)

threshold. When a low-priority EXPOOL

request is refused during the addition of

another granule table, the number of granule

tables in EXPOOL is reduced to NGTB.

PERCNT SW, ROLOUT, 11, EQU 10

PERCNT specifies the fraction of total

system mass storage tracks to be made available as a result of a rollout. A rollout is

initiated when the number of available

(unassigned) mass storage tracks drops below

the threshold MSWl . If the amount of mass

storage available at the time of the rollout

is denoted by AV, the number of tracks

(NBTRK) to be unloaded to tape is given by

NBTRK = TC

PERCNT

where TC is the total mass storage capacity

in tracks configured on the system.

NBTRK is constrained so that it will be in

the interval

[MSWl, 3OOOO0]

o That is, at least MSWl tracks, but no more

than 30,000p tracks, will be unloaded for

each rollout.

POSDIR CP, AACONFIG, 1099, EQU 191

POS60 CP, AACONFIG, 1107, EQU 135

POSDIR specifies the position of the first

directory track on a FASTRAND II. It also

specifies the position of a FASTRAND Ill's

first directory track. For a FASTRAND III,

POSDIR*3/2 is used. POS60 specifies the

91
FACILITIES PARAMETERS ( Cont ' d

SIZEWT

SSDENS

position of the first directory track on a

F8460. For all other devices, the first

directory track is located in position 0.

SW, SECURE (MAIN), 738, +1

SIZEWT is the weight assigned to file size

in tracks in the computation of the unload

eligibility factor (UEF) . This setting

applies to LEVEL 19R1 VERS 2 of SECURE.

CP, AACONFIG, 611, EQU 'V

SSDENS specifies the density in flux changes

per inch (FPI) of tapes assigned by the

system. The codes for SSDENS are the same

as those used on the ^ASG control card. In

this case, a density of 1600 FPI is being

used

SSEQPT

SYSPRP

CP, AACONFIG, 614, EQU '16N'

SSFQPT specifies the equipment type all

tapes assigned by the system will use. In

this case, a UNISERVO 16 nine-track tape is

specified

CP, AACONFIG, 621, EQU 4

TFEXP

TFMAX

SYSPRP defines the system prep factor for

the EXEC resident on the system disk unit.

SYSPRP is the number of FASTRAND (28 word)

sectors that will constitute one disk record.

SYSPRP should be set to either 1 or 4 if

disks are configured. This will give either

28 or 112 words per record.

CP, AACONFIG, 633, EQU 6 0

CP, AACONFIG, 1327, EQU 360

TFEXP is a systems standard retention period

for tape files in days. TFMAX is the maximum

retention period for tape files in days.

Both TFEXP and TFMAX are limited to a maximum

specified value of 2047 because they are

stored in 12-bit fields.

92
FACILITIES MANAGEMENT (Cont'd)

SW, SECURE (SETUP), 2425, See V.B.4

UEFLUP is a look-up table for obtaining

(1) the point values assigned to time

since last reference (TSLR) and (2) the

mean time between references (MTBR) in

the unload eligibility factor (UEF)

computation

SW, SECURE (SETUP), 2430, See V.B.4

UEFTRK is a look-up table for obtaining

the point values assigned to file size

in tracks. It is used in the computation

of the unload eligibility factor (UEF)

CP, AACONFIG, 65 9, EQU 1

When WHLDRM is set to 1, word addressable,

unit-granular assignments will be made.

WHLDRM is a conditional assembly flag that

turns on code to handle unit-granular

assignments
SCHEDULER PARAMETERS

APRIOR CP

AACONFIG, 285, EQU • s

•

CDHOLD SW, LOCTAB, 53, +20

CHGDED SW, LOCTAB, 2, EQU 3

DEDLIN CP

AACONFIG, 363, EQU 1

MAXCRD CPAACONFIG

506 , EQU 500

MAXCRQ SW, LOCTAB , 1

EQU 2

MAXDEM SW, AAPCT, 1419, EQU RSICNT

MAXOPN CP , AACONFIG, 522 , EQU 8

MAXPAG CP

AACONFIG, 527 , EQU 300

MAXTIM CP , AACONFIG, 531

EQU 10

MAXTUX CPAACONFIG, 536 , EQU 30

MPRIOR CP

AACONFIG, 540 , EQU 'A'

NHOLDT CP , AACONFIG, 1016 , EQU 16

RSICNT CP, AACONFIG, 595, EQU 80

TRMXCO CP, AACONFIG, 642 , EQU 0

TRMXPO CP, AACONFIG, 646 , EQU 1

TRMXT CP, AACONFIG, 650 , EQU 1

94
SCHEDULER PARAMETERS

CP, AACONFIG, 28 5, EQU 'S'

APRIOR is the default priority for (SRUN

statements that have no priority specified.

APRIOR may be any alphabetic character

selected from the set A through Z. The

nearer APRIOR is to the beginning of the

alphabet, the higher the default priority

will be.

SW, LOCTAB, 53, +20

CDHOLD specifies the maximum number of

active demand runs. When the @RUN

statement is received from a terminal,

it is determined whether this additional

demand run will cause the number of

active demand runs to be greater than

CDHOLD. If the number of active demand

runs will be greater than CDHOLD, (1)

the user is informed that a system hold

exists on the number of demand runs and

(2) the information about the run is

released.

SW, LOCTAB, 2, EQU 3

CHGDED specifies in minutes when a deadline run's scheduling priority is

changed to critical as the run's deadline time approaches. The run's priority

is changed to one of the priorities 2

through 5. The priority is changed to

'n' when the run's deadline time is

CHGDED*n minutes away, where n can equal

2, 3, 4 or 5.

CP, AACONFIG, 36 3, EQU 1

Allow deadline runs if DEDLIN is nonzero .

CP, AACONFIG, 506, EQU 500

MAXCRD is the default for the maximum

number of cards punched for batch runs,

if not specified in the ORUN statement.

95
I

SCHEDULER PARAMETERS (Cont'd)

For a demand run without a maximum number of

punched cards specified, 131071 will be

used. Whether the maximum is specified or

not, it is limited to 262143.

MAXCRQ SW, LOCTAB, 1, EQU 2

MAXCRQ specifies the minimum number of core

queue entries that the Coarse Scheduler

should provide to the Dynamic Allocator. It

is defined, but apparently never used.

MAXDEM SW, AAPCT, 1419, EQU RSICNT

MAXDEM is a conditional assembly parameter

for turning on demand code when MAXDEM is

greater than 0. MAXDEM is also used in

determining the swap file size. RSICNT is

described below.

MAXOPN CP, AACONFIG, 52 2, EQU 8

MAXOPN is the maximum number of batch runs

that may be open at one time.

MAXPAG CP, AACONFIG, 527, EQU 300

If the estimated page count is unspecified

in the QRUN statement, the default for batch

runs is MAXPAG. The, value used will be

limited to 262143 (2-1) . If the P-option

on the @RUN card is specified, a run is

terminated when its page count is exceeded.

Otherwise, the operator is notified and

given the option of terminating the run.

MAXTIM CP, AACONFIG, 531, EQU 10

If the estimated run time is unspecified in

the (9RUN statement, the default for batch

runs is I^IAXTIM in minutes. If the T-option

on the @RUN card is specified, a run is

terminated when its estimated run time is

exceeded. Otherwise, the operator is notified

and given the option of terminating the run.

96
SCHEDULER PARAMETERS (Cont'd)

CP, AACONFIG, 536, EQU 30

MAXTUX is the number of seconds before

reaching the estimated run time at which the

MAXTIM contingency will be honored.

CP, AACONFIG, 54 0, EQU 'A'

MPRIOR is the maximum allowed priority on a

(3RUN statement. If the priority specified

on the @RUN card is higher than MPRIOR,

MPRIOR is substituted. MPRIOR may be any

alphabetic character selected from the set A

through Z. The nearer MPRIOR is to the

beginning of the alphabet, the higher the

maximum allowed priority will be.

CP, AACONFIG, 1016, EQU 16

NHOLDT is the maximum number of attempts to

open a run from the Hold Queue before the

operator is notified. Runs are placed in

the Hold Queue if facilities are unavailable.

NHOLDT must be less than or equal to 077.

CP, AACONFIG, 59 5, EQU 8 0

RSICNT is the maximum number of terminals

allowed to interface simultaneously with the

Remote Symbiont Interface (RSI) . When a

terminal signs on, a check is made to

determine if the number of active terminals

is greater than RSICNT. If the number of

active terminals is greater, the line is

terminated. RSICNT is also used as a conditional assembly flag to turn on demand

code when RSICNT is greater than 0.

CP, AACONFIG, 64 2, EQU 0

If non-zero, TRMXCO terminates a run when

the punched card estimate is exceeded.

TRMXCO has no effect on demand runs. It

overrules the "C" option on the (SRUN card.
*

TRMXPO

TRMXT

SCHEDULER PARAMETERS (Cont'd)

CP,, AACONFIG, 64 6 , EQU 1

If non-zero, TRMXPO terminates a run when

the page estimate is exceeded. This has no

effect on demand runs. It overrules the 'P'

option on @RUN card.

CP, AACONFIG, 650, EQU 1

If non-zero, TRMXT terminates a run when

the estimated run time is exceeded. This

has no effect on demand runs. It overrules

the 'T' option on @RUN card.

93
I/O PARAMETERS

ANGLOF

DHLACE

DHLACH

DHLAC8

FASTSK

INCORE

lOLM

MAXF4

MAXF8

MAXF17

MAXLLC

MAXOPR

NOSEEK

POOLSIZE

SCGA

SYMALL

SW,

CP

CP

CP

CP

CP

CP

CP

CP

CP

SW,

SW,

SW,

CP

CP

SW,

AAPCT, 93 3, EQU 1

AACONFIG, 66 8, EQU 0

AACONFIG

AACONFIG

AACONFIG

AACONFIG

AACONFIG

AACONFIG

AACONFIG

AACONFIG

10, 3561

10, 3560

AACONFIG

AACONFIG

AASMTAGS

671, EQU 1

674, EQU 0

379, EQU 0

416, EQU 1

451, EQU 1

510, EQU 200

513, EQU 10000

516, EQU 1000

EQU 30

EQU 12

10, 80, EQU 1-STPAUL

1093, EQU 25

688, EQU 0

3598, EQU 036

99
I / OPARAMETERS

ANGLOF SW, AAPCT, 93 3, EQU 1

ANGLOF dete

addressing

tional posi

disk subsys

conditional

angular add

wise, angul

ANGLOF is s (FCO) numbe

5033 Contro

use angular

rmines whether the angular

capability (also known as rotation sensing, RPS) on the 8440

tem will be used. ANGLOF is a assembly parameter that enables

ressing if equated to 0. Otherar addressing is disabled when

et to 1. Field Change Order

r 037 must be implemented on the

1 Unit before the 8440 disks may

addressing.

DHLACE

DHLACH

DHLAC8

CP, AACONFIG, 6 68, EQU 0

CP, AACONFIG, 671, EQU 1

CP, AACONFIG, 674, EQU 0

DHLACE, DHLACH, and DHLAC8 are the interlace

factors for 432, 1782, and 880 drums. The

possible values are 1, 2, 4, 8 and 16; these

values should correspond to the interlace

factor at which the drum is actually set.

An interlace of 1 implies that consecutive

data words are stored in consecutive drum

locations. If the drum interlace is n, n-1

drum locations are skipped between consecutive data words. Doubling the interlace

factor halves the drum transfer rate.

FASTSK

INCORE

CP, AACONFIG, 379, EQU 0

If FASTSK equals 1, all subsequently prepped

packs will have their last simulated FASTRAND

position marked as allocated. That the

inner cylinder remains unused results in a reduction of full pack seeks.

CP, AACONFIG, 416, EQU 1

INCORE specifies the method of processing a

scatter read or gather write request on a disk subsystem. If INCORE equals 1, the

100
I/O PARAMETERS (Cont ' d)

EXEC insures that access control words

(ACW's) fall on record boundaries. If ACW

do not all fall on record boundaries, the

code generated by INCORE will build a new

set of ACW's that do fall on record boundaries .

CP, AACONFIG, 4 51, EQU 1

lOLM is a conditional assembly parameter

that controls the I/O Load Monitor code

generation. I/O Load Monitor adjusts the

I/O load on memory modules that may be

overloaded by I/O requests. If a memory

module's maximum I/O transfer rate is less

than the combined transfer rate of the

subsystems active on the memory module , a late acknowledgement (data overrun) can

occur

CP, AACONFIG, 510, EQU 2 00

CP, AACONFIG, 513, EQU 10000

CP, AACONFIG, 516, EQU 1000

MAXF17 specifies the number of FH-432 (MAXF4)

,

FH-880 (MAXF8) , and FH-1782 (MAXF17) tracks

available to the symbiont complex for writing.

This FASTRAND-formatted mass storage allocation

for user symbiont files is accomplished by a quota system based on the number of user

symbiont files. A file will obtain a certain

track allocation quota on each type of drum.

The quotas will be used by a file in the

order (1) FH-432, (2) FH-1782, and (3) FH880. If the quotas on these three drums are

already used, the remaining amount of the

user symbiont file will be allocated on the

device specified by the parameter SYMALL.

SW, 10, 3561, EQU 30

I4AXLLC is the maximum number of times a queued I/O request may be locked out by onposition requests.

101
I/O PARAMETERS (Cont'd)

MAXOPR

NOSEEK

SW, 10, 3560, EQU 12

MAXOPR is the maximum number of consecutive

I/O requests that will be satisfied for a disk unit's current position before the

position will be forcibly changed.

SW, 10, 80, EQU 1-STPAUL

NOSEEK is a conditio

that enables 8440 di

NOSEEK equated to 1

pre-seeking off and

(STPAUL = 1) enables

Field Change Order ( implemented on the d

8440 pre-seeking is

NOSEEK to 0.

nal assembly parameter

sk unit pre-seeking.

(STPAUL = 0) turns 8440

NOSEEK equated to 0

8440 pre-seeking.

FCO) Number 037 must be

isk controller before

enabled by setting

POOLSIZE CP, AACONFIG, 1093, EQU 25

POOLSIZE sp

queue item

within the

represents

If POOLSIZE

will occur

instead. U

the element

buffers wil

ecifies the number of 15-word I/O

buffers (IQ items) maintained

EXEC element 10. Each IQ item

an I/O request that is queued.

equals 0, no pooling of IQ items

and EXPOOL buffers will be used

se of I/O queue buffers within

10 reduces EXPOOL overhead, but

1 be assigned to EXPOOL if required,

SCGA

SYMALL

CP, AACONFIG, 68 8, EQU 0

SCGA specifies whether scatter read and

gather write I/O will be used by the EXEC

symbiont element SYMBIO. SCGA greater than

zero will enable the use of scatter/gather

I/O by SYMBIO. No scatter/ gather I/O will

be done if SCGA equals 0.

SW, AASMTAGS, 3 598, EQU 03 6

SYMALL specifies the equipment code of the

mass storage device used for user symbiont

file allocation after the file's quotas on

102
I/O PARAMETER (Cont'd)

FH-432, FH-1782, and FH-880 are used. The

file's quotas for FH-432, FH-1782, and FH880 are specified by the parameters MAXF4,

MAXF17, and MAXF8, respectively. In this

case, 036 specifies that the FASTRANDformatted 8440 disk subsystem will be used.

103
TEST AND DEBUG PARAMETERS

DADBUG

DATRAC

EXPTRACE

FCDBSZ

FNCCHK

lODBUG

SBLEVl

SBLEV2

SBLEV3

SBLEV4

SBLEV5

SIPDAT

SIPIO

STPAUL

SWPCKO

UNIVAC

SW

SW

CP

CP

CP

CP

CP

CP

CP

CP

CP

CP

CP

CP

SW

CP

AADAEQT, 3, EQU STPAUL

AADAEQT, 9, EQU 30*UNIVAC

AACONFIG, 896, EQU 130

AACONFIG, 922, EQU 50

AACONFIG, 401, EQU 0

AACONFIG, 97 2, EQU 1

AACONFIG, 1199, EQU 1

AACONFIG, 1206, EQU 1

AACONFIG, 1210, EQU 1

AACONFIG, 1214, EQU 1

AACONFIG, 1218, EQU 1

AACONFIG, 1222, EQU 1

AACONFIG, 1229, EQU 1

AACONFIG, 2 80, EQU 0

AADAEQT, 5, EQU UNIVAC+2 * STPAUL

AACONFIG, 654, EQU 1

104
TEST AND DEBUG PARAMETERS

DADBUG

DATRAC

EXPTRACE

FCDBSZ

FNCCHK

lODBUG

SW, AADAEQT, 3, EQU STPAUL

DADBUG specifies whether additional Dynamic

Allocator internal error detection is done.

When DADBUG is equated to 1, error detection

occurs

SW, AADAEQT, 9, EQU 3 0*UNIVAC

DATRAC specifies the size of the swaplock trace

area. It must be an even number whose value is

2 -2, where n is any positive integer.

CP, AACONFIG, 896, EQU 13 0

EXPTRACE is the number of EXPOOL requests and

release trace entries. Each entry consists of

two words

CP, AACONFIG, 922, EQU 130

FCDBSZ specifies the number of FNCCNT actions

traced. Each action is traced by a five-word

trace entry.

CP, AACONFIG, 4 01, EQU 0

FNCCHK determines whether function validation

is performed whenever a nonresident function is

read from drum. If FNCCHK equals 0, no

checking is done. The function's keyword is

checked when FNCCHK is 1; a checksum is

computed when FNCCHK equals 2.

CP, AACONFIG, 972, EQU 1

SBLEVl

SBLEV2

SBLEV3

SBLEV4

When lODBUG equals 1, all debug aids within

the I/O complex are enabled.

CP, AACONFIG, 1199, EQU 1

CP, AACONFIG, 1206, EQU 1

CP, AACONFIG, 1210, EQU 1

CP, AACONFIG, 1214, EQU 1

105
TEST AND DEBUG PARAMETER (Cont'd)

SBLEV5 CP, AACONFIG, 1218, EQU 1

SIPDAT

These parameters turn on and off the various

levels of SIP. The SIP levels are discussed

in detail in the appendix on SIP.

CP, AACONFIG, 1222, EQU 1

The SIP Dynamic Allocator Trace is enabled

and written to the SIP SYSBAL$LOG$ file when

SIPDAT equals 1.

SIPIO

STPAUL

CP, AACONFIG, 1229, EQU 1

The SIP I/O Trace is enabled when SIPIO is

equated to 1.

CP, AACONFIG, 280, EQU 0

Extensive internal EXEC error checking is

done. STPAUL is set to 0 for all sites

that are not STPAUL sites.

SWPCKO SW, AADAEQT, 5, EQU UNIVAC+2 *STPAUL

When SWPCKO is non-zero, program bank swap

checksums are calculated. Two words per

block are summed if SWPCKO equals 1; and,

sixteen words per block are summed if SWPCKO

is 2. If SWPCKO is 3 or more, every word

in the bank is used in calculating the

checksum.

UNIVAC CP, AACONFIG, 654, EQU 1

When UNIVAC is non-zero, the primary EXEC

error checking is enabled.

106
APPENDIX C

INTRODUCTION TO SIP

107

SIP is an event-driven software monitor. That is, SIP

counts and times the occurrence of significant events within

the operating system. The data collection code is integrated into the operating system. Special instructions are

included in the executive programs to count the frequency of

certain events or to time the duration of certain activities.

These instructions are preceded by conditional assembly

flags. The conditional assembly flags are turned on or off

by system generation parameters. When the flags are off,

the SIP data collection code is not generated as part of the

operating system. Therefore, if SIP is not going to be

used, the SIP overhead may be avoided.

SIP data collection is hierarchically defined. Five

levels of detail may be specified at system generation time.

The lowest level generates the least overhead and collects

only a basic set of data. Each higher level of SIP includes

an additional degree of detail. The levels are divided into

two classes: user levels and development levels. User

levels collect basic data of general interest; development

levels collect detailed information needed for operating

system tuning. There are two user levels: User-A and User-B;

and three development levels: Development-A, Development-B

,

and Development-C. Each level has a separate conditional

assembly parameter associated with it. These parameters

determine which SIP code is or is not assembled when the

operating system is generated. The data collected by each

level are summarized in Table C-1. Each item in Table C-1

corresponds to a standard report.

Three programs support the SIP data collection code:

SYSBAL, SYSSIP, and SIPDRP. SYSBAL contains the storage

areas needed to hold the data collected by SIP. SYSBAL also

contains numerous subroutines that support the data collection process. SYSBAL must be permanently core-resident when

SIP is on. SYSSIP is a nonresident element that provides

the interface among the user, the operator, and the system.

SYSSIP is capable of responding to a large number of operator

key-ins. SIPDRP is the SIP Data Reduction Program; it summarizes the SIP data and produces a set of standard reports.

SIPDRP is a FORTRAN program that may be run whenever it is

convenient

The operator key-ins provide a substantial amount of

flexibility in controlling the operation of SIP. Of particular

interest is the SB CODES S1S2S3S4S5S6 key-in (all SIP

operator key-ins begin with SB). The codes' key-in may be

109
SIP REPORT

SIP LEVEIS

1 2 3 4 5

System Balance Sunmajry 1

rtonory Utilization 2

Exec Activity for Each CPU 2

Dist. of Prog. Size for Run Type 2

Processor Activity for Each CPU 1

Idle Tine by SIP Collection 2

I/O Activity for Each CPU 1

Mass Storage SS Queuing by Type 1

Mass Storage Analysis by Unit 1

I/O Queuing by SS 1 , Pre-Seeking and Pre-Positioning 1

SWSP$FILE Expansions 1

Facilities Hold Queue Statistics 1

I/O Load Monitor Activity 1

Common Bank Usage 2

CTMC Comm. Line Usage 1

EXPOOL Requests and Releases 3

EXPOOL Counts by Priority 4

Times EXPOOL Became Tight 1

EXPOOL Usage 1

Register Saves and Restores . 1

Segment Requests and Loads 3

Segment Initial/Active Requests 4

System Idle Activity 1

ER Counts 1

Response Times (Abbreviated) 2

Response Times (Complete) 3

Core Fragmentation 3

Suspend/Swap Statistics 3

Exec Frequency Counts 3

Test and Set Summary 5

SIP Overhead 1

SIP REPORTS (LEVEL 4.0)

TABLE C-1

110
used selectively to turn on (SI = 1) or off (SI = 0) six areas

of SIP data collection:

SI - User level A data

S2 - Distribution of user program sizes

S3 - Memory- in-use distributions

S4 - EXPOOL statistics

S5 - Function/Segment Activity

S6 - Most of the rest

The status of each of these codes is reported on the first

page of the SIP output. Within the operating system, the

SIP data collection code is still present; however, if the

appropriate status code is set, a branch instruction bypasses the SIP instructions.

The status codes are very helpful in reducing the amount

of overhead produced by SIP. Since SIP is event-driven, SIP

overhead is proportional to the overall activity of the

system. The overhead generated by SIP is displayed on the

last page of the SIP output. The overhead associated with

program size calculations is also reported. Since program

size calculations often account for 50% or more of the total

SIP overhead, it is usually a good idea to turn off the S2

status code. Another way to minimize the amount of SIP

overhead is to run SIP periodically for short periods

rather than continuously. Experience has shown that 10- or

15-minute periods are long enough to observe steady state

behavior. The starting and stopping of SIP are easily controlled with operator key-ins.

The remainder of this appendix is a set of annotated SIP

reports. Special comments have been typed on these reports

to aid in their interpretation. The reports are in the same

sequence that they were printed by SIP. Detailed information about SIP may be found in the SIP documentation manual.

Ill
<

ISD

COu

«<

•J

«<

PC

:gH

inI

IV

ti

<M

CVI n

00OMX

(U

0.H

CO<

10Unso

X)

•Jn

COHHP<W

><Hz

too

•J

•J

•<! (C(0

!h

CO

0^H

CO

nH

De; IDWWn

TDH

<!

CDCO

>^

CO

HD

a.HD

«•

(bID

toMOm

U)

•Jh

ID

CO<nP<

>-

Qd•<&

COwH >MHy

COp

COpou

to

CO

toHw f •

in•

ton

TI ZI GE IC

to ST in If) wfii HM I* Ui W

CVi > 1—' iT) (L •<

H

w

W

CM Ft 

rjw (Li

CLi to wi © ID CO B5

til rv

U ID

CO . » TP. CU oo <!

PC <; Lj

M in

W M-l t . f\(M w/

nw LU

M >^ TPi •

><!

H to

p

H

w 5S

m

w

in• t

(L.

p to 00

TP o

Uip o

ID z z Z z z Z o M U ID ID ID in

•< CO

H tt P 1 1 1 1 1 1 < M z

CO t-1 (VJ ro <t in \0

H

CO CO to CO CO toH

W

w Z K K P H H as

55 Oi M TI LA

to

W

M

PU < M H

CO IDH

(0M

COn

112
tit

0>

><K

O

0*u

nw

n

H

M Z>

)J Ck! M fU H

D 2

U

in W

W CO W CO

M

H

p

oUJX

>1

5

i U I Ui I W I w I

I

I

I

ooooooooooooo^o\cr) t oooooooooooo»nooN<f i isi OOOOOOOOOOOON<OvOOO I o> O 00 I 0^ h- in I rn rn n I in

ooooooooooo o f ro 00 r< I n

(vj a C\J I •* fO 00 I w

I ^

0000000000000(\JW>t)

US 1^ in 00 ro 00 0^

w tn CO CO CO CO CO CO CO CO CO CO CO CO 1 Ui M Ui M Ui • o O o o u o V u o u V 1 I-I ID ID 1 •< hJ iJ iJ I-I h4 1 H

CQ pa m CQ CD CQ CC ffl cn CD CD CP CQ CD 03 CQ I IDH

(VJ * o oo o W * >£) 00 o CM •* 00 o (\J

11 n (Vi 0> CM in 00 (M CO * oo rH 1

fl-t T-1 CM CM CM n f) * «

W

(M w

COw

[II

4* H

M

n ^ < (0

j; N

ID M (14 ,J o

CO It, w

P M

H

«(; CO M tsl M M

>< w ,J

pel o M >4

Z; CD < w K

CO >

C

6S w

c 'O •g <;

jEM

Cl r)w

CO (-1 W

CO

rjw

Jr Q M« CD IP w fw^ Qi Q

CV C < &

o o u. o ID z

H C M

S- R ><

1 CK ID CM -<a M

H 5! in z H

z <

CO H p

ID Cfi o o

ct; C^

>- M u <

1^ z >

z T M

•< D P z P

H p CO

*ff w

tt CO CO

tt u: p

hJ u o

Hi Ui

»- •• > H CD

113
O -r4—* 1 ' 1

1

] QJ

(_) "—1 E

1 ' cTi ri ^

•r—

QJE . ? 5

-t-> O M— O fD O

(/I fD LU E O X OJ LO

LU on ct -O Q r—

+-> LO LU OJ =J O X -c: c CT LU 4-) -1— OJ oooooooooooo

Hz

w

c.H o o o o o

10u o o o o o o o

o

o <t ID o CO

-* <* w • s in

1-4 CD H

w

>< o m

H u u u w u u

u X X X w w

X

[11

•<

Cki O

ID

oew

w

pt

H

n

H

0!H

w

ooooooooooo

ooooooooooo

oooooooooo O N

OOvO'4(\JO(J>f~-irOP»<>0>0

OOOOOOOOOOO^ OOOOOOOOOOOO OOOOOOOOOOOO

OOOOOOOOOOOO"

<ci£'-<t(\ioa'r-incD»Hif)i£)

114
'v) "O (L) 1

C71 O

, q_ •1— > ^ -{B 4-J QJ > O C 1— -M

(fl M

QJ -C W

ra a> +-> (/I t/1 +-> sM

a> S- C ^ C

f~ +-> O) 3 ••- H

+-> x: c ai+J _c: C 4-> (D 03 fO 1/1 -i-> >4

I/) to -CJ -!-> -C E - <

5 > -,- c +-> ro 3 H -i-> s- in <U s- 0) c w QJ (_) OJ C7' t/) <C E O) OJ s- M o a; H

CL-i- 0) T- s- •.-

(/) 1

&^ Q. I/) O-i— o Q

(D o> 0^ o> (J> 0^ o> oooooooooooo o w<tooooooooo

to t o (;> in O o o o o o o ID o o o o o o o o o vO vO in o o o o o o o o o

in o 00 ^ O o o o o o o (vr o o o o o o o o o o o o o o o o o o o o

ro o n N o o o o o ME o o o o o o o o o o o o ME 10 o ^ o o o o o o o o o

w

(VJ H

TI 00

iDi^ in»<r>if)oooooo

o iH If) o> m o (VI

(vi .H 4 ro CO <vi in

<vi «t ooinooooooooo ro -I oD

vt) n in « ^ ooooooooo

co<o*(vioo>r^in<i)iH\o\D «<vjro*<fin>oo>r)(yov

+-> o

QJU to ^ s_ X ^ c QJ QJ E QJ to X2 E

fO 1— ^ E to

s_ o i/i CD (/I D- QJ to CD o 3 o to

s- O -!-> QJ S- >

D- to c c O- t/) s- to +-> +-• o QJ QJ

n3 o tO +->

1/1 c l/l +-> C

M- +J o

O to c s- QJ u +J QJ to o a QJ M X)

QJ 1/1 O X -o QJ N OJ s- lA u QJ QJ I/) a C QJ QJ sz H-

(/) 3 O ^ S- >-, in o QJ E +J QJ +-> 1/1 U

QJ U E QJ 0) E O QJ ^ c O x: S- to S x: Q. 1— u 3 lO I— +-> i/i 3 1/1

a)<0'*<vioo>h-ino)»<\Ovo

»Hcvii«)it<*initJ(;>ioo>o^ M M M M M tx: UlvHtf M ut oo>0'*(vioo>h-inco»<voio•-•{vin-*<tiniot7ina'Oi

115
u

a

to\

H

>>

•!-> s_ -o

0) +J QJ o

> -a CL

0) .— -r- O)

co > !- E !- 3 -r- 3 crT3 S_

+-> O OJ O l/l te o "O TD

I— C o l/l 3 O

UJ •4-> O O (O X Q-x: 0)

LjJ 3 (/) (/I s- c:

i- <U Q- +J QJ 3 1—

(->

4-> 1— 00 3

s c to

•1- > -o o

cu <U c

4-> ^ (/» tn cu (0 O -1- Q- O -C (D o

'ai 1— +-> 1s_ s_ U <D J3

S-o >, l/l M- Ol o (O "O O s-03 a O i. Ol O OJ OJ O <U (/I o C c/l E OJ _c •1- 3 _C

oo OO V£3 C l£) 1— Oir(MO<VJin(DOOO<M<*.HOOOOO>DO

<\J If) *

en

S-E3

C

<U

<u _c1—

1/1 1—

UJ

>>

JD =c

-o c

OJ o

S_3 o(/I OJ fO

OJ fT3 E

CO tu

<o E

QJ -!-> E

OJ

4-> r- -a "O

OJ -o XI o

OJ

+-> m X)

TO E

3 3

+-> +-> O

UJ T7

w p

^ 0. M K

M >- o to to O CVI in o o o 0' in in t-i o o o o * o '0 n H hJ If) w o m o w 0) U >J «£) O in oo s Q a

•< «: 0- (M (VJ w M Z

(VI H

u U

c 0^ (i. w

U3 w w

m pi M in N <c *

U O in ^ in

X> ^ (0 to w in

OS in w • Ou •* (D

H

O

a<t)c

>jw

i-i CO Q P

M Z

X) D O N U

U <- (0 o ^

O

o

•

in

<to

0> o W

in

CVJ

IDL • < CO u \ ID H < z

w i-i U. HI OT M

&

> H

Z w M H TO

05 « H OS T> o (0 M <J H U H <

K OS 06 M > z H H Q O H

» w H Z H <D © p U M M < P. M HI N « H <c H H H H M U B) M u w TO W > H w M z Z »H z P H H (- W u TO HI M

Z u z Z TO Z K Z z o P z < < hJ K H M d x> X I-I kI w H w H H z z w p H H H

Bi •< iZ < u (fl M TO hI < < M z z W Z <

U. Hi M z H z w Z w 0. a> P w u

c K H p H K H P H P ce w u M p < OS z w tu u D H

W P 0. U W P Ph P a lU o c O O |i< in to TO z rs PS OS HI P

u ^1 Ol H H 0. H QU H H OS l-< z z z M M l/J M HI w m •< a. z z P P z P Z P X J H B. < H M IK l-< l-i VJ Q a. 01 z e

M lb M M <D H <C M » p H P w W >< » p

H i-l a w •< < IH y K u UJ lu w w m TO TO

•< i- •«! TO TO > w W TO TO >J hJ h) hI Z

V) w (Q w to in w w M «; M z P i-l >-l M Vl OS TO Q P p p n H

u M m PtS M M o U. Q P 0. >-l HI M < OS

116
©d>w o q o <

•z. MHU

•<P

Cu 1 If If IF If If If iF IF If ir IF IF If IF fl IF If If IF IF Ir Ir ?F If If If If if IP 11 ro O O O O O o O (/ O o O O 11 ro O O O O O i-« o o o o o 1 IP IP 1 *P tP tP iP IP IP IP *P IP IP tp tp iP 1 j ro 1

as

Ph

tP tP tP tP 1P iP tP IP tP iP Ip tp IP tP (1. j• DO o o o 00 o Q 1 CO o Q o o Q CO o ro Q o X

*^ *^ CM cH 1 If Ir If _

If (F

__

If

_

If

_

_ If )* IF »* - If IF

_

If

_If

_ -IP -

IF

_ - - ED 1 CJ OJ O o 1 <\j O O ro o 1 r- 0^ (7* 1 in (D M • o w U z

PSww " ! M 1 - D . inUJ m j m _ In _ m m _ H j OJ in I ni in fti

(-1 j I tc j : H 1 :1 1 1 © Z H _ to P n _ m m (VI — — Q - Q ~

ao

_

[u j 00 r) OD OS in CM 1 in Q\ ! OD in lO m (M < M * cu (M

CO,Jwz w z w z <

HI ^ IT

OJ in *^ CM z 1 UJ CD UJ 1 tn in CM ro

AlCM

H 1 If) Jn j (M 5

*"*

D OS

W 1 1 w P

(1 s

2:H z M OLi M p I lO Ct\ . — in CM w H * m Jr inU) in

Si

u 5 r Uj m 1 rn 0" Al CD Z 1 o in 1 fn tn At 1^ w

in \0 oo CD JL 1^ rvi TOm 1 O U) 1 »o pq M j *^ 5 r) u 1 M P i 1 D EC z H W P ^ _ ZP 1 OD — _

UJ

—_— ^ t rn If 1 1 1 ' If) tn _ — 1 in _ _ — m - —

—_ 1 in

"J

in

In In 1 (7* in o vl in

Si ID Z 1 m u) XO O 'O o 1 o o O in vn z lb 1 UJ 1 M 1 rj

In * O 10 j D CM hJ CD

m

**

XH

ID

H

u

H

T> >

»-( H

u

U

(\Jn EQ PC <VJ PC Eu CM «: u*

H

u ? QOU

u ? Mw b« ^ W w (VJ M w Al

CT\

—

w

w EC r] 1^ z w M H N N hj N H M w W Eb p M lO N r M w z z <B O u Pu 1 O W r> ^ in ^ 00 O <VI ro in 1 O •H CM ro in OO o r4 CM ro in (U w • 1 aa tc pa 1 H t H H 1 I-) •-I •J 1-1 i-i P 1 hJ i-l .J *J IJ 1-1 1-1 i-l Hi 1 w U u w m m m u Ou 1 w U u u m m Ul w Hi 1 2; z z z Z z z z z z z z Z z z z t- 1 Z z z z Z z z Z z z z z z z z Z 1 z z z z z z z z z z z z z z z z P 1 Z z z z z z z z z z z z z z z z U 1 < •< -< < < < < < < •< < < < < < < 1 •< < < < < < -< < < •< < <; < < •< H 1 Ed RO m EC n V m tn to K 1 K PC pa EC IE CO pa tr s PC PC « PC tc PC 1 o o u u u u V U u B U u u u u y V u V o o V Z 3 3 o o

fT3

"O "O 4-> Ol

(U 3 QC

!- 1— OJ

C

S- OJ QJX

fD D- - OJ CD

u

Q.1—. _ ,.

_

Oji/OM-cci/iOJ-c:

+->

C S~ SC O" n3

Ol +->+-> O U OJ o .— <u 3 E -O

•,- •.- Ol

J M- E +-> O

i- •!- l/l E : OJ 3 O > -Q O ^ : E - C o iI— OJ

fT3U

O OJ I— OI— OlE

i- 01

U Q-

<D E 1- !-> > 01 3

<c >— a.

a

ct CO (_>

Q 1

117
o o

t-l H

p

iJ 0. •< o

H IK ^ o <0 PS

tt. p cnw

N

OT3

<

K

O M n

> o o *

M o in o h

H • • • U s rH BS < 0> n U

H (C

fu p

>

t-t d. HD

y z

X M m

W CQ a, H

o ro w u U

w w w to w X X X HI w w u

H

OW oooooooooooo CO

ooooooooooo* ooooooooooow OOOOOOOOOOOCVI

ooooooooooo

a3<0*(VIO(7>NlflOO»4i£)<0

ooooooooooo

o

OOOOOOOOOOO!" oooooooooooo OOOOOOOOOOOO

OOOOOOOOO

(t)>0^(\JOaNI/)(D>4<0>0

P 8

118
o

(i) Q\ Q\ Q\ 0^ 0^ oooooooo o

o o o N w <t o o o o o o o o o

in o o 00 o o o o o o o <0 o o o o o o o o o <£ flH O o o o o o o o o m 00 o o o o o o o r> o o o o o o o o o o ^ o o o o o o o o o

<t ro <c in <0 o o o o o u o o o o o o o o o o o o \n o 03 o o o o o o o o o

\C n iH

<l-i£IWW<l-lOOOOOOO

>0 (M h <\J O ID o iH 1^ r) w <

<vi n

o o ooooooooo

H

D

o

>--)

«:

00 0^ o o o o

^ o o o o o

(Dv0*CVlO(J>NlfiC0.-v0>0

tH(\jri'*<i-ir)'Oo>i^(r>(J>

119
P«6CESSCJR ACTIVITY 9N CPTJ 1

TYPE aP INTERRUPT TALLY INT/SEC

ESI INTERPR6CFSS6R ?646 6.8

ISI INPUT MONITOR 1162 2.2

I SI 6UTPUT M6NIT6R 458 .8

ISI FUNCTieN Mf^NIT6R 0 .0

ISI EXTERNAL 19126 35.4

ISI INPUT M6NIT6R ( S/G ) 1472 2.7

ISI 6UTPUT M€)NIT6« (S/G) 1812 3.4

ESI INPUT MONITOR 1350 2.5

ESI 6UTPUT MONITOR 4053 7.5

ESI EXTERNAL 2468 4.6

DAY CLGCK 0 ,0

REAL TIME CL6CK 18848 34.9

INTEKPReCESS6R 192 .4

ILLEGAL INSTRUCTI-^N 2 .0

GUARD MODE 0 .0

FLOATING POINT OVERFLOTV 0 .0

FLOATING POINT UNDERFLOW 0 .0

DIVIDE FAULT 0 .0

EXEC TEST AND SETS 10095 18.7

USER TEST AND SETS 0 .0

PROCESSOR WENT IDLE

LOOPED IN IDLE ACTIVITY

IDLE TIME

IDLE TIME

IDLE PERCENTAGE

IDLE PERCENTAGE

45211 TIMES

2555395 TIMES

297.638 SECONDS BY SIP COLLECTION

291.599 SECONDS BY DRP CALCULATION

55% BY SIP COLLECTION

54% BY DRP CALCULATION

SYS IDLE LOOP CT 2284437 CPU IDLE LOOP CT 270908

ABNORMAL ENTRIES TO SYS IDLE 7241

RT OUTPUT ACTIVITY TIME - .000 SECONDS

120
n

a * # # # # tf (0 11 o o o o (\J o o o o o w 1 # # * * CVJ • o 00 o o o o o CM o o o 11 1^ * 1 oo o o o o o N o o o o o 1 cy <t o 1 x> !^ tli )^ o • P) o o O o o (M O o o o o o 1 © in cc <t o o

CO 01 w • IT. o o O o o ro in * 00 o o o o s • (VI «^ U) <t H • ?

0} 1 to 1 {Hi •< 11 •< 1• •<

01 (0 o I O" 0> tn o o O o o « o o o o p 1 •* n n (D o •H

p » 1 vD * •<t * <t 00 p. > 1 (\J IH > u •< a < a » a ^ n to o o O o o o o o CO o » H o a

<\J in >c CM

u > < a ri o> tH < a w r> ro a U<HD

0.H • <o in o o o o o >o o o o o C\l o D w a in oo 00 o 0>

m

p

a t-i in ^ oo ro

p • a in 0* ro ^^ tH » a in tvj 00 in vO « D a w <o in n a « »H tH z aaa o o o o o in vH ro o o o o o aa

ro * I 00 o o o o o o «^ r- oo o o l\J o o a r< o o o o o CO <c o o CD o o w a o o in o o o o w m a w w a in o OO m <o a ou D C\J M a {Vl *H m a IH 1 H H 1 H

(M •* o » n

K

nn CM <t o PS EC

O

CD

u

uu CD t-»

p CJ ID o

h- * * e * u CM

OO OO .J l-l >-) hJ 00 oo Ou IJ z z n M M < M M M M n M M < H l- X C » N N N N Q p N (J •< u

a o tH

D * in <C 00 0* o tH C\JD It in

a

H

a >J •J lj IJ iJ hI >-l ij i-l >-l P P a w M u lu 111 M u U w M U w M w U4 u 0.

B.a z Z z z z Z z z z Z z z Z z z z H Z a z Z z z z Z z z z Z z z Z z z z B M 1 < <! < < < < •< •< < •< < < •< < •< < © 1 B OB pa K n K K tc tn n n > u O o o u U u o u O o o u u u o a >f If )f i«2 aa

r>) o o o o o o ^ o (VI o o o o o a # * )^ * i in o 00 o o o o o CVI 10 o o O o o ' KU a * * # * * If h. a < 00 r- o o o o o h ^ CVI o o O o o a r-* CM (VI ICP a # «^ * * * # * w a t^ to o o o o o CVI o o o o o o K a «j o in 00 o o MPo lu w z

IH

,-1 VI

Ul Ul

to

aM

H

a o « « o o o o <0 in in o o o o H a n in CVI (VI >o (-1 a Ul z a p: M a H OS • 0. • !>- 1 hJ ID • ZC P a 0^ tH o o o o o ^ 10 CD o o o U4 UJ a <o in in tH o 0> OS a <t <f « tH <t m 00 (0 < M a ro CM (VI p a 03 a a It l-l Ul W K

l-l z

PJ U< z < a 10 o in tH o o o o o tH oo in o o Ul o z PB IH a 0> >c o ro ro in < o a 00 10 CVJ CVJ tc a u OS U a U' p

o:

Hp

M z ^

0.M

u

CK z P 0. t-l P a 00 (\J >o o o o o o ro <* oo o o o o E Ui H a CVJ ^ [0 in C o •* ro CM H m ID a tH tH CVI Ov in lO ro PQ Ot Z a OD tH iH (VI oo If) «H in tH z 0] a Q' * oo tH tH * l> < O tH tH in U PC P a m o a H M P g s IS Z

Ot •<

lu

p l-l

h

a. IHZP a t\l 10 o o o o o (VI o CM o o o o o a < p I-) a z

o:

a CD

N * 0 o o o o in •* in o o 10 o p OS

H 1 <t ro (^ in o o o o in o in o o o D Z a CM (D CVJ o o o o o <t o o o o z U. t> a u a (7- CD in 00 o tH 0] n tH (u 111 a M z pa a IH 1 1.) H <

lU> H H OS H w U lu

CVI o m to IS CO

n CM o OH pq o ij

€ < (u

oo tH

p {Ju o V CO « o u o ID a.

p

r^ It in t- l-l f H t^ <*

m CVJ in l-l PD CD oo Cu l-l l-l l-l l-l tH 00 oo ou •J z <;> z m w

(C

M IH < IH

M

M to tH •<

M

H t«!

H z H

b. P p

N

N

N ^4 lb

p P t-i

M

U < u z z

•<

M

10 « a o 0.

a o tH <VI ro <t in 10 00 o tH CVI 10 in

w Ul lu

a pp to PC a H H H a 1-1 l-l <-l l-J l-l l-l hJ iJ l-l l-l l-l .J i4 l-l a lu lu W lU HI lU lU HI HI lu Ul lU w w W w a z z z z z z z z z z z Z z z z z i z z z z z z z z z z z z z z z z M < •< < < •< < < •< < < < < •< < -< < (H a IE IT to cn s IE PC pa to PC DC pa to PC BP a u u u o u u u V u o u o w o o u Z

121
W JSJ lO -< o «

tf) OD 0>

OOOOOOOO OOOOOOOO

OOOOOOOO

o n o o o o <» o 0^ o o o o n

o « o o o o «

4-> !-> C t/1

tX) I I/) I

: +-> ^ T3

3 o

r +-> e j:: U QJ +-> O) +->

I X >> o

a. m

> X

I- m > UJ m >

m

Ul I- D W O M

X

s: u

lUt- o

(/) > u

(/) Ul

UJ X D Ol

UlU

< o

an I-a

(/I

(\j o n

s o o

r)<t(\ji^oinoO(j>(\iO'Ci*riinooooooo

pj rn «r u) in « If, ©

N CO lO W O

00 o> 00 o» in n

^ ^ O CD m -9 tn * <\j N « in in o lO

1^ c\j

O O O O O O o

>ot\JOlDO«oo^.(^c\J'0^^«'Ooooooo*

0

o-*r)vooiooo(7ironinf^ooo*m

-<Nc\iu< in -^-o (\jinain o o o o -•

S I— S 4-'

o- S- +->

4-> u c rj

I- VI in

o-H(\jUt-i(Mn'a'in«r-o«c\jnu-<(yn'9in>o

-c I— cr c +->

1- s- cn X

<U O M- (T3 QJ 4- O S- E •!-> QJ CU 3 TD CU > 3

OJ 1— O) tc <U

OJ OJ E E OJ cr

-E 3 O 3 ^

I— cr o c I— (D

4^ OJ

(\J(\JCM*^-».**^^-<fNr-h-N0D(D(DCOC0CDCD

z u U U u U w U u U U u

UJ l/l y; III I/) u> VJ v> 1/) CO VI in m CO V) 01 UJ LU UJ UJ UJ Ul

1- D a D 1-1 i-» IH a a a a a a a

in a O < (/) a CC CX Q Q Q o o a Q Q Q O a o < < < < < < <

>- Q 1- >• o Q o ti/i W <t o V) (M cy <» 3- •* «t •* * * <* O O o o

IS 00 HI 00 CO OO 0 « « iC « «

D * D ^ •» * <t 9 t <f <t •* in CO D 3 I/) <0 CO OO CD OO (0 OO OO CD (D OO 00 3 3 D 3

122
><m

D (O o z Ih M M H CO Z

0) P ^

0)p 01

01 ro

CO ro in

><

p o n n IT

r) c cn z 0! Ms W He >- vO o sa

in

10

n

n

»-< (A IN

». in P

t)< K

oe< W Z (0 »

Jf o o

lu 01 01

t-l

p

H

M

(0 PS P a

><

Q

01 Rl o n OO « p N * •*

01 CO OO

mH

01 I H Z P

IC

OW

K o: c

U. sr. © H H M t- B H

01

X

© < 0. zwn 01

01

H

01

K

U

C

po

V>K

MP >- M h4 01 Zow 0 o

•<

w

K Z H H Z z

01 ^ o w u >

Bi X)a Z M H C

01W

H

OSU P U

nJp

1-1 o

<.

w

lb

w ^— ni .

@in o o o o

<M (VI <y « H m <o in

v4 «-< rn

OS 01 Ci z

01M

W

M

W 01

u< IK « h * ^ o o «

10 « -•

•* <f <t P

(D OO CO OO 0* H4 l-l M M < O P P P H n <t lO 1^ 01

M (O 1/1 c o rtj OJ c Ol a O Q. +-> o 1- c

fO 0) Ol 1/1 +-> C u E 4J s- +-) c- O fO +J Ol t/l

(/»

X S- 3 Ol

O +-> 3 o Ol M- c

CL'iS- pr do at ea Q. S- O OJ 1*- ro "S "x cn OJ +J 01 +-I >i

>> (/l -o OJ

C c: i/i CO 1— o l-> I/) Ol M OJ r— +J t/1 E OJ 1/1 o

fO 0)

O i- OJ ^ Ol cr

S- -i^ Z3 OJ s_ +-> OJ

=5 OJ O" 1/1 Q. o cr OJ +J Ol 01 s- OJ Ol

s- TD o s- Mc: 1 p OJ M- O

0) 11- > M- 14- OJ S- o o OJ O S- O

J3 Q. E OJ

s- 4-> OJ S- JD s. 01

OJ >> c 01 E OJ fO XI CT C XI E O E fO o O E o c E O o u OJ 13 13 <!

OS

+-> c (/I +J -C

C +J

(/I >^ QJ (/) -!-> fO 01 ro 01 O l/l Ol 1/1 +-> OJ

H 3 E OJ o C o o _1Z

C3" 1— c D- 1— 1— o. 1— hOJ O

rj

00

S- LUX

ct UJ

Q LiJ U- C3 > OJ +-> i+- c

+J 3 t- Ol

1/1 Q_ cr -C

Ol

O 01 Ol t— 3 >< S- i_ I— u Q- > Ol

•I—

O 1/1 3 OJ •

OJ lO .— : ui -c: . o c I U O 4-1 1 't- 1/1 : -O 4-> =3 1 OJ •.- E : u

•rO

C ; > Q. o i S- ; OJ s- +J

1/1 OJ ro ^ 1—

in o

00 o M n fH 01

•<»HZ

>uaw

01 OS z p

ID 01 M <

01 o a 01 o

in OO in

r) (D in 0. 00 cn CO z

CM CMw

oe

w P J p

11

u.p

w z

•< o » M

01 01

01 o <

CM 00 ^ o

00 o

«-« >JM

b.ce

Pu•<

01zp

OS z M M » X ° O •o o <

CM (Vi

M z

lO in

K

Pj

HEH

H

1— 3 C U T3 O

M- (/I 4-1 S_ in QJ OJ S- 01 01 OJ S- -O 3 O U C 01 cr Q- 3 01 OJ 3

C3"i

— 00

ID ••- in +J t/l >)

O ID CO r—

X!

O

OJ Ol S- E .- >,4-J O C71 ra c

I— Ol 01 iC OJ

U CT ' I— x: tn s- — QJ . o u ) s- o

"D T3

O •- OJO

>,O Q- OJ 1— +-> O) S- r— Ol M- ro ro O 3 S. cr O 3 3 cn C O ro

+J +

CQ E

ro 1S- >,O -o (— It- (O

n

u ro T3 3 01 : CO -a -o

CO OJ 1 OJ ro OJ o c: u c - ro O OJ 1 J3 1 I— _c ; ro CJl >)

01 3 O S- S- 01 C fO

0- -a +-> 1—' c: • ro 1/1

-.

_ . ro

123
^ O

Q w

h) n o

Q >J

iJ m c

ID EC Q PC Vi M w

J W p P p U C w 10 P M © 10 i-l pa

AP AS z

»

X Id H X OS p a e

H H

< m z •< m m n n U W u < u •< P

a. z t- SB z H z

!h M < M •< u u u u U

H n «

tPQ Q <

I- D s z z z z <

111 »< H H U

S- M- 1— rn

I— cn c: 13 cn o

I/) m

on QJ

CD E

E -iCD -O

Q- O

M- S- +-> O

O C I— -c

OJ C to r— 1 ^ 13 C CD •

o o o o o o

o o o

o o o

o o o

o o o

o o o

o o o

o o

o o o o o o ©

©0©©©

c <_> z EX

3 -a O r—

dJ (1)

oo

wN

toX

CO W

M

. P

«Vi 00 o

&< ooV• n

03 W

(L lb

P n (u M a.

ts in p » w MOP

» iJ z

p w

If) X W W 11

ri ^ h

4^ OO

ft- \ iJ

•0 PI •<

• <D m

V P 4

in 00

10 < • in IK • 10 © p

cn 0) CO CO H w M w < in m

Pu a. (fl cu » < < p in in H H < ID p (0 a

X W < K

0. M X C p

u y p in 0. < -< w in P pa « K w pa lu H H Pu o » w

CL. 1 t U) a. p P VI

IE w K u P R »

EE o z z ftj W

< < n X

124
N

><

COpHPwDO

cn

(0

cnzKKW>

<!H<PW

PJH

CQ

0}nP

CO

m

i-i pp

w o ^ N o M t CQ |£)o sS <

>-P P o o o

COH

CO

pM

p P o OwH • z z o M

i-l

p P

•< P o o o o o o

(0zPwI<©OMKIz

COzpwi06©

<!H<PWn

•<w

OJ E N 3

•IC

O)

+-> O)

_ 'a

cr QJs- o _ o +-> CDMro CU 1—

S- S- <o

0) 0) :3 > ^ oOJ

T3

s- ro

O

0) E s 0)

t/1 >^

+-> 13 Sro o o E +-> Ol -o E

l/l +-> ra

1/1 o

d) o '4- rj O

a- >7

CU QJ

s_ +-> +J ro 4- s_ O QJ

l/l s- s- QJ

0) ro MJ3 u l/> E OJ J3 ro c s_

s- -tJ oM QJ

+->

-l-J CO o

OJ

<+- -a QJ

ro

U o o X

CU _i OJ Dl

I/) o c

+J 13

s- s- o >> s- Q- JD OJ

OJ >

s- ed o

ro

tu +-> ro 1— crx)

125
V

M

toN

O

Uw

0»»OCDO^-00^-l<^00000000000•-•00000000000000000000000000000

©

o n o o (vj o

<t r< O

Ifl o<tooooooooooooo»<ooooooooooooocoooooooooooooo

© O O O <M o oo o

<t \D OOOOOOOOOOOOOOMinOOO oooooooooooooooooooooo

oini/)U)ifioooif)i^eoooooooooooor)cuoooooooooocoooooo

a If) <M ri 01 ooooooooooo

aiCL.B<Bui3aOHOuti.BuoHii<CLaiai(LPuDuo.OHiLPua.aiPL,a,B.p>a<0<CLiBuaia>(i<a<PL<ii<ihO4(i<Puii<a<^ Zizzzzzzzzzzzzzzzzzzzzzzzazzzzzazzzzzzzzzzz

K <fi »H

<Ztt.mw(nHixxi><Qsctt.5!<aM>-i

OUO'-<OQSB.<<<!WOSB5-<!WUP2

Hi< KiHZweecetfi<fiMWWWiauinz<oszi-Hmt;MOT»it< "'^<KmmcDmiE(aiiiiauzu<'c>Me>mZ'«;M<uciup UCC»©«©©©T)'<<OOPlI.MIH < H ft. MS:WPBt-<iaU<UUUUUUUUWWW«)WWCfeW<»WWW«6(ftt»W<6 u,p<w(i,upaii!P3<!<<;<<:<<:uuwuoyyouuwuuuouu

H

Z

o ©

a z M

< w (B K « Z

126
i/i at

4-> +J

1/1 aj

S- 4->

C <T3 OJ O -O r— 3

o

4- +J i.

•r- OJ

O T3

.

E O

-iTT

tn c -c

s- o

QJ

+-> +J

QJ O- E o s_0)

s_ QJ -(-> IT! x: QJ Q. 1—

fC

S- UJ fO C3 +-> Q- 3 t/J s_ o >- o ^

oo O- UJ

QJ OS 'o OJ S- LA) >-

(/) oo

l/l o E QJ o +-I ^

OJ s- l-J T3

<- 4- QJ

fO QJ T3

-c <u QJ +-> OJ 0) 0) o (J S- >1

I/) QJ QJ s- !- C n3 QJ SS- S. o •1- QJ -l-> S- QJ o 3 S- S_ > ro

l/l t_) 3 QJ Ol o O 3

c QJ QJ M- S- u l-J o o s_ s_ S_ S- QJ IT3 -a U

QJ QJ 1- s- QJ s_ nD

4-> +-> to 4- 14- 3 O. l/l X3

ro Q) Q) a- LJ LO >, S- S- QJ QJ O o -!-> QJ > on D. D. Ol O C

OJ +-> < o

S_ M 11 II II II o. r-; X3 o >> QJ Q UJ LU LU LU Ll_ QJ

rO Ol cc q: LU QJ E x: l-> c o 1— tn +-> QJ o 3 o 3 D- QJ TD QJ _c C C

1— cn 1— o ID

=;

127
< w

» a

s

M •< H

O 2

>- H

4 •< to K

inw

%M

iJ

!Z •J

1-1 <: 01<

lb » U M

W V)

01swOS >J U H

H B

O * <

K

i-l U. D H

0) U)

OS w

w > m M

a H

s:. u

u

S X

9 M

Z

HI U

IK IE < H

a

w H

tsH C

oooooooo oooo*r)oooocom»<moor>(\j>o>DOO(ti\ooou>N(Dh-*inooiooo

M Z

OS M

C .J Z I-l V <

M t-i n c

H Z

f— O

. 1/1 fn

1 to c

, t/i 4_) . di (>i _

' c i1 -I- X CD

: r— cu +->

inioini<>ininu)uiinu>inu>ininininininintnir)Uiinininin(\i«u)iniriininininioininininintnir)ir)inin

tnnrinpiinpinninforopirjririmriioionrinrfnioNh-nriririr/rjririripironririt'iririf'i

.-(Min<t.-i<\ir)« — wr)<iniC»"CUfo*t^o.M<Mi«i*in>ot^OiH(vjri<^in\ONO'-c>jn<tiniONo-«(\i

oooOi-i»<«»"Ciiww<vico<vip)nr')r)r)<t*'*<j-<*<t<t<(-u)inininifiininir)vO'00'0>OiO'0'Ot^Nt^ oooooooooooooooooooooooooooooooooooooooooooooo

oooooooooooooooooooooooooooooooooooooooooooooo

128
UJ ;i)s

Q U)

01 UJin<

LU_l

III

> O 01

liJ K

(- I- l/l ^<:£^

UJ o

_| K UJ o "-a

O O vO — in n <* ^ cvj

c\j <c M —

CM

N If) N

o ^

<VJ 0> 10 * IT)

m oi *

o> m o

OO If) w

-< <\j CM -" in fn ^ u) CM <t n « -« cvi

n •<) <D « CM * o u} (j» o

CM cr in CO in CM

<r U> O CM

o

111 10

in N

ino •

>0 CD

CM *

V

UJ

in

in s

* CM

o

UJ

1/) o \

OO 1^ o •

vO CD

CM •*

D 0)

OJ

CU >

cx

CD U

03 ''"^ >^

ro fO

dJ E 13

s_ >> => O +J

0)

+-> s- > E

+-> ?

' E

CO s-o

"O

_J n3 o Ol

Q. C XUJ ^ +-> Q. CT

OJ M- 01 UJ

s- m

>, -a

Ol j3 >> c

!-> J3 (T3 rO Ol "O ' T3 0) S_ <U +J

CU +-> s- 3 -1- (O O) <D (O M- = 3 o <D CT

1 0) TD c E Ol c o E S- s_ o

o 03 _]

<* o o « o CM O O I

!-> Co

o

o

n3 O

OJ >i

CL

cn

on

(/) o

<L> <_> c

o lA St 4- OJnb >> 0) +J ss. 0) o {/) (/I Oi OJ x:

Q. 1—

eq

+-> s-

+-> _j

n3 1/1 oCU

CL) D- a crx

CU UJ

<u s- x:

+-> _Jo ra

i/i Q. "4- X o

UJ E

3 <u o x: LO -o -I-' OJ S- s: o

o tin <\j CM o o o in a o s o n o CO * m N N -

00 C\J CO o I

T-4 in o C3

in (/) in in «) cn (fl in QQQOOOOO zcEixizcEaiixa: ootDuooocj

-^-COvOCM-^OOtOCM

1-1 n \o (M in •-' CM in

w) in in in in in w) in OQQQQQQQ

oooooocio

^(DiOCM'^COvClM m >o CM in

I (M in

l/l U) V) in m in m in in l/l in Wl in l/l in o o O o a o Q a O Q o u o Q

q: It a a a a: cr CE cr (X !£ a q: (X o o o o o o o D o O o o o o o

s 3 s « % * 00 (VI (D « CM •* 0) (\l OO « n CM in 10 « CM in

CM U) CM

> >

01 01 C3 —I

129
>> c

<u o

+-> ou

10 •o

<D 3 >, EE s co

•a

St nun <u >-> o

t/) OJ t/i

+->

u CO tn

0) *-> 00 3 to •D O" 01 0) 0) Ol 3

s- cr

li- <u

on OJ s- V) i/> 3 4-> Ol _1 E (tj J= o 00 1—

(/) a.

4-> 0)

X to J3 LjJ Ol Q_ 3 -t-J O rcj- o 1— r—

<U c

s- c

(O r-- 14- (U o o

+J o>> &^

OJ n3O

D un

(U

UJUl 1- •rO 3 ><-

V)

tUJo

UJK>KM

ceo

ixQ.-**h-ino-'ooo

ro

w in a) cvi * (\j lO o m o

u) (/) «> in v) w) u) ui aoooQUOO

OOOUOOOCJ X « 2 #

>o (VI <t o « ni

ro >0 <\l If)

—

CM Ifl

+-> to 13 OJ

01 Ol 3

C/1 o-

<^ o 3 OJ

01 i- o C c JZ

0) o VfAL

ed OJ O) oAr SL

U-l c oc he "o

ga "O 4-1 lO

0) tn •M OJ o o 03 i- OJ o x:

+J

+-> d.

03 0) tn 1 Qx: OJ o 03

Ol -C 3 Cu to a.x

+-> •!- (-> E UJ

-t-J 03 •a

0) ^ OJ 3 l/l o

O" 03 -t-l Ol 3 on cn to

s_ 4-1 M- OJ 1 to +-> O s_ OJ o 0)

+-> o 3 cn 0) 4-J 03 O- CT d

rX Ol o OJ "O LiJ S- 0) +-I 0) 03 >i E O) >> Ol s- 4-1 E 00 s- _J -o 03 f- 3 03 S- o Ol O. !- 1 03 E O o Ol OJ O C <J •- E Q_ (_) O 0) S- 0) X X s- Z XI O- E UJ OJ cC Q. o o C • 01 3 X) -i^ 0) U

4-1 T3

O

C

C I—

O) 03 ja 3 Q-X c

4-1 Ol

O

03 •»- _j in

4-1

O c

OS _J Q- Q. O X X O UJ Ol X 4-1 _J

UJ OJ o -C O l<- 4-1 Q. O X

to UJ

4-1 T3 C S. H- 3 O O • 0 3 CL E s- X (Q 14- Ol UJ a J2 D- E Ex 3 !- 3 UJ E OJ C

•.-XI >, -3C E E XI 3 E C E C

•I- OJ

01 OJ

X > ^ ^ 03

4-1 4-1 E cn I I CO Q s © © <: ®

_i t- n y)

u in

_i

u UJ o < o a 3 I/) -1 3

to

u

X

O CD -D >• a _j UJ UJ Z K X o !£ UJ IJ O UJ u > o

00

OJ

cr

am

O < £ o 2 X V) <

S- C> UJ VI 3 U

_c If

a UJ

K

O

u 1- a u. > X UI -1

CD 2 la o (/) -1 1 o > U) < o 3 < o m z U X K a

a. a: UJ

u

X _l -1

XUJ I/)

D UJ UJ

n

D

t- UJ UJ z u

U Z UJ a < K a a 3 a o >- u UJ Z X X U 01 UJ UJ UJ u _i in 11 UJ a < t- UJ 3 (Z ^ z

_l U) _l 3 3 3 o X UJ < o UI U z o o u K a z a o a UJ UJ X X X m UJ 1- X X I < < r < a 1^ z

in

(/I in o • • • •

q: •*

m <> nj UI

Q. fVJ

N

n >- * UI I » _l P) (Ji 01

O

X -1 0> lO in < in H « n (M

in I/) UJ UJ

a: q: in W) o o

UJ UJ

K (- > > (/) in < < UJ UJ

in (/)

a q:

a. IX CLa

UJ UJ UJ UJ K t- K

in

mmm

»-t •H

13 13

UJ UJ UJ UJ X q: a a a u: q: o o o o z -) z -)

»-» < < z z y

O) 01 > >

OJ 01

130
o

w

K O o o o o o o o m o o o o o

h OOOOOOOOOOO <tooooooooooo

0

^ (\l <u a

h

U•<o<too^oo^o<-<ooooin»«ooino Or"00t->0000000000n00t-0

b. •

V)p

•<\ o O 00 H • ooron(Oor^a)0'Ooroo(\jr)roir^oooo^f^»onoor)o^flD(MN(\i*oo»o-^»^o*Hh-oo(\jon*HO»-to (vioP)r)f^U)ot^moor)or)<joD<vj<jinooo>tHtvi<ti^oo<f<t(\jr)(\/or^\D4inmo<tvooo'0.-i^oo^o

0©

O o w o o o o»<orioooo»«»HOONOo oninooooo<tin(yoooo owooo<too o .H ^ 1^ (0 o -I ^ (0 0

0)

lcnOlUO(000«00«Oh-OOOrtCM>000>0000*0000000>0(\l<tOOOOO(\JOOO<tOOO<t-(\I<\J\OOU)00

©

=£0*tn(?rorno><joio<vi»<<trooN»<>oo)r)io<Mio«i/iifir)vor^^onina>-<>OiMino»<<t-«^rooo.*»<oocotoin<0'0

o z 0. 0. 0) 0- hI to H VI 2 IS VI w la! 11 P H z a Q o M o o u M H Ul M » K K PS K VJ U u Q < VI Z ^- HI O e- H u q: hI p

u. >• B. X n a R » w w H OS 2 < 0. U B. D u l-l l-l w M 0S M a (J z 2 M lU < U] 2 u u o hI pj €> HI < HI 01 lu B z •< <: B. y 2 u M i-i p « 2 2 z lb u. >J lu VI VI u z l-l UJ u u o o s 2 < 2 Z X z <; HI M K lb 2 M X Oi M X s s » U) UJ < w S >- >> >- lu c •«; « < a, c < < < u «: M M M m lb VI Ul VI Ul < VI V) HI Ul lu VI w p 01 Ul (0 Ul (A (0 VI 0) IS P u D m W V) to OS M b< Ik u. lb p M o o VI < l-l z Ih lb lb lb (b U u u U P U U lb u W u

wlnNc^^o|^^a)r)l^<\la>•H<l<vl^cM^-l^>^o^ coiciniEwoDflon

^ nriio <fvc« 01 «o<riOtit^

H

z 0

r-CT'<\itnt^rot--<DMi^(viHi<t

CT't^w<\i in«-i oi»"»< 01

-I N (\i * in oi

r) u) o >o m o o

ID 4 in -< w

10 in

»^<\j.-<i-ioino^o(\j»ooi<oi<DPi4"0^o(\iinrotf>r^a3^^(sj.-*vD(^«o<\i(\j'00inr>ojw»o

01 -< 4w «eyoDrtM<\j u)>0(Mi-i (MM^ioin

^f Hi<\in<ti()<ONooo>o.M*io^o)O^Oi-i<\i(oniO(DO>Oi-<cyr)iO<oo>oro<fuiit(00>Oi->woo-<cviri«inioNo>'"r'

-•««-i-<,H^c\jw<\i(\in)ninn*«)-«it<i-<t<i-ininuiifiininin>oiCioiOt^NNl^r^i^Nr^N(Ooo

131
oooooooooo^oooooooooooooo& 0000000000(\)OOOOOOOOOOOOOOC .....t.. ...J

(E

ViJ

<

H«

w

w

o^ooin«oooooo'Ooo^ooino^oor) o<ton(Oi/)inooip*oooicot-iu o»<ooin I" ^

* w «

. . Z

•H « •<

<D C

cr 1/1 "D

<U QJ -r- OJ

s_ 3 CO 5

cr (U o

cn s-

•,- S- 01 -C OJ o c

3 -E

cr CD

fo (13 -i<: s- t/i o ^ <u tu +->>+-> 4-J r— (T3 l/l

LO o TD CU

4-> I— C 1/1

CD fO O CU E S- CDTD (1) u

<L C S- C

cr (/I q: t/)

cr re -M cr

fO -r-

+J S- -MO

OJ _Q OJ S- 3 3 CU cr dJ crjDc

>, l/l +J OJ +-> <u

•r- s- •!- cr > 3 > lO

•I- l/l (- s_

+-> (U +J (U u QJ u > _

=c e: =£ =t hoooooooooocooooooooooooo

ooooooooooNOOooooooooooo(\iin

4 (M <t * -1 *

«; I z c w

01 «: < c u a U CL B. U X U> t < < M < H

« O Q S Q h,

e 0. tn M M

Z Z 2 2 S

3:> ^ c u

i O U O

n ij

Bh w >-

•< 2 U. S ^ »

U] V) Ul WMJ^iMt-HMtHt-WUlOW

Vw

in

0- iC CM lO r; n (Vi o O CJ in (\j n CJ lO o <* (Vi O) (VI (0 iC in 10 * oo <o

OJ w CJ <M * t~- m

in oo ffo

lu(0\ Ol n 00 CVI vO <Vi o n * N N <\j in w m <D o lO (VI *H

01 ro o •O fH CVl (VJ ri w < {VI oo o

in m (VI

toJ

•<

t- m Pi <t (0 o 1/) 10 ^ <o n Ul 00 o CVI H

CO (D 0' 01 0- o o o o o o CO CM n M m m n n n It * CH

-^-p

CU -C ^ +-> 3O -D

CJ) <U l/l +J U ro •'-

- -r- OJ 4-

CD "D -C 1/ S- C S- <u r- QJ > _ > C

•I- Qj O

S- _ cu ct dj cI X: Q JD

sec • M O O •>- -M

l/l 1— «- S- C

OJ +J +-> OJ 3 O U l/l EI

CD 3 S- OJ

S- l/l 4- O l/l

OJ OJ OJ

(1) '.- ^ +-> 5 U

O OJ </) o o

> CD O +J u -o -o

+-) -rOJ (J

132
3 O) U •!- o -u

tC -1->

(U -r- S- +->

+-> o_

rO >-<

+-> Ul

QJ E O S- fT3 O S- t-O O o s- +-> +-> Q. o

O) Ol +-> s- cn c

03 n3 Q. S- i_ E OJ a. O > O cC i

Ul • O >lJ 03 lf>

f\J OJ

<( CT CO

D • • • (\) in Ol

J<H

<!

t5Mm

tn (fl

QJ 1 +J

COE

O)

+->

t/1

OO (/> c:

-l-> +->

ra 3 s

in QJ

Ol SQJS

!-> Ul

QJ ZD -o D-O

©

(M

O « vC CO <y <c

U) « (J> ^ M Ulw » u<

<\J

O lO CD (VI vO

inw

h 0^

w

p c M

O

U o H o z u O

2.K

H ->!

w CM * o o >0

M Mj Ul 0.

m Z CO CO f-( <o « f*

Dfi

y CO 05 c> HI * <t <* * P

Ifl

T < o in in in » p:

w rH CO 00 a; CO

Pu fp

H

u • • (-

H EC

MMM <

Ul

W •< «! 2 CO CO U) U) U. P C

R

u< z z M OJ CO OJ

w >- ^

(h HJ

M

M

HK

H

w Ul ID <! CP (D CO w UJ Ul Ul UJ © P p ro

?5C

:UN UN zD zp zp

U; U7 Ul Ul

M C>« Oi

W

K

H

H

I-I <i

U

M

ID

U o H U » >-) M

h) •< o O bi < Uj M O wp «: 3 ID UJ HI Ul H H H

Ul

W

U

>-

H

Ul

W Ul CK

1-1 a.

cm Ul

i-i ID <; I-)

HV

y •<

133
THIS SECTICN GIVES THE NUMBER 6F ERS BY TYPE FflE (3NI,Y THOSE REQUESTED

BASIC EXEC PR'S:

This report may be useful

in explaining why EXEC overhead is high.

# ER TALLY ER RATE/SEC. ER GR0UI

1

I0S 3128 5.8 2 2. I0IS 89 . 2 2

3 . lews 21 540 3? . 9 2 6. WAITS 1907 3 . 5 3 7. WANY? 937 1 . 3

8. CAMS 66 . 1 1 9. EXITS 2052 3 . 8 6

11 . Ff^RKS 253 . 5 6 13. REAPS 1 072 2 . 0 4 lA. PRINTS 2531 4.7 4 15. CSFS 561 1 .0 7

16. leAxif 128 . 2 2 18. 57 . 1 1 19. TIMES 165 , 3 1 21 . lexiJt 38 .1 2 23. IIS 4 . 0 6 26. FITEM? 23 . 0 7 33, MOTS 1 . 0 1 35 , MCf RES 13 .0 1 38, CMTS 2 . 0 5 39, CMIS 2 . 0 5 40. CMflS 1 S80 2.9 5 43 . CMSAS 2723 5.0 5 44 . TDATFS 1 44 .3 1

, TWAITS 34856 64 , 6 3 51 . 16 . 0 1 52 . PCTf 27 . 1 1 53 , SETCS 4 . 0 1 56. APRNTS 51 . 1 4 65. TALLP 3-» . 1 6 66 . TREADS 1 .0 4 68. PFI « Q . 0 7 69 . PFS« 4 . 0 -

72 . PFWL« 9 . 0 7 73. LaADS 1 47 , 3 1 76 . FACTLS 1 1 1 . 2 7 85 . MSCflNS 1 . 0 7 87. SWTCHS 47061 8''. 2 6 92 . AWAITf 5 . 0 3 93. T SWAPS 1 . 0 7 95 . PRTTNS 3 . 0 4 96 . ACSFS 1 5 . 0 7 99 . FACTTft 1 49 .3 7 101. PNCHAS 1 4f, .3 4

1 02 . NAMES 6 . 0 6

1 03 . ACTS 3248 15.3 6

1 04 . DACTS 7567 14.1 6

1 06. CRE L$ 2 . 0 5 111. PSRS .0 1 112. BANK3 9 .0 1 113. ADEDS 12 .0 6 118. ARE ADS 2 . 0 4

1 20. ATREAD 45 .1 4 121 . LINK? 8 .0 6 123. EXLNKS 4 .0 6

1 24. UNLNPS . 0 6 125. RLI STS 8 . 0 6

1 37624 2 54.8 8

ER GPflUP BASIC EXEC ER'S:

ALL EXEC ER'S

le RELATED ER'S

ER'S THAT CAUSE ACTIVITIES T0 WAIT

ER'S ENVeLVED WITH SYMBIflNT ACTIVITY

COMMUNICATIfN RELATED ER'S

ER'S THAT START i. STOP ACTIVITIES

FACILITY INVENTflHY RELATED ER'S

TALLY ER RATE/SEC. FR GRflUP

13762^ 254.9 1 24923 46.2 2 37705 69. R 3 3351 7,1 4 4309 8.0 5 65285 120.9 6 897 1.7 7

134
p

J «C In

(- o . I- Z ^

t~ < Ui c c O X o © o o c o o © o

IC o

as

© in o OS o

in

UM

K B. Ul K

J

K 10 < D W

u. s

<c 0 H 2: w

OS

UJ

w

O< M iu

Si l- 2 w M

•<

H <

0) E

cn s- fO CD 3 «

4_> _Q OJ

000

000

©

it0 o <u 0 0 0 0 0 0 0 •* 0 • N CO m O' 1 a 0 0 0 0 0 n a 0 CD 1 <}•

rj 0'0- 0 00 0 CD 0 a 0 1 t- CO

<t rn CD cy r> I nN 1 0' 0 OD 0 in 0 o> CO 1 d m ^ (VI r> 1 o> n 1 0 IT) m « 1 O' 1 • CO 0 ^ 1 CM n ri IX) n 1 m ID 0 <D CD <» >D CO o> 0 lO 1 <t <t

(C 00 0' CON t- 1 0>

•0 0^ * CM CM 1 •* <* 0 00 0 0 0 10 0 1 CO n

.1 in1 1 1 Q 1 Z >

•0 1 < M

u

uu

a s l- \ N 1 HI •< 1

(M1 n1 *1

in1

•01 1 1 1 Q 1 U

l-l ss Q Q a 0 0 0 • < s S S X s s s S 1 i- w w w M M u w H 1 C 0 H Q 0 0 0 Q 0 Q Q P 1 h <

135
»bPWwDauwoz

<;

I"©H

MJO

<!hw« wp o * O It «

(VI « o o O O • H • * O

rM

ID o W !D O W H •

OKU H M

P£ Oi

W

wH 1 w (0 1 o If) < n W 1 P 1 O O 1 H z M 1 W 1 M c o o U a o o •< M o » H • • M M > <! H <

in 10 o o 1 o o • • 1 • • 1 o R o o o 1 o o 1 • • 1 o e o o 1 o • t 1 1 • ?f St o

(VI 1 (VI o

»-( o 8 • • 1 • • in 1 in in 1 o a c • 1 • 11I in I QL) I .H sIIII o I o I y> I • III

z; 1t PB > P 1 u M < I H 1 < •< P a •J • w R u a <! P M H g H U a << a o u m a •<

pmpwu

•< CO H H Z z

-<

p P u <MHMz pz Rz >w z P

CV/O CD (^

O 0^ (7»

I/) ro ,-1 in

(vj ro <t in »o

r

136
m

inpZ K

t)C

W> 0 W

a •<

N

a.p

M

0>m

1- fw U K w

m u. P •< ss H w •< w w < n a N w (- K > H •<

t<: »>: t<; t<: o G o < n o o o <» * M IK M o: us o o o <\i n o o o n n m o M V K « Z » U M C W » U K U U PS IK lU M M W W 0! S P U. b< B< 0 o w w U U Qi OS C

as IK CL. O' z 1 I I I I o tH w r) <» «

u. a: N

M

M

CO 0'n > •* u l- >

TE

•< OST> Z M u OS a CL o

•< CB »

</! c

•< cn » TA

B

111 o K p O (VJ

a

U

H z < © % © Z M (n OS <

0. ?

PS

M

PSH c IE J H M P4

CO Wl D p < < 0 u w lU n n p W u u w t hJ u M < <

b. vO ^ M <* tvj w < m

la! >

in < Ul < < H > w < m

Ul Ul w

ai

m

H

NM

<n 4D s ©

©

©

MO

b. OSu. < p. a• U)

Ul<H ow W

x > < <

Ul i- e H Z (1. 0) P IX

<! Ul •• c a < Ul t w h < Z Ul » « o ~

Ul

WH

h < K ^ M H W U.

U. P P OS >J C W C iJ

ea •*

IL) b. o P o >• ? b; iij M r » tre K u. u H C B (1, w

Ul

H ^ M

Ul < u. < s. H Ul H w PC

ttXH

b<NM

Ul

(«:

MZ

<;

IT

IP b. Ul >

•< z Ul t Ul < a H p % t Ul w a M M N M 1- Kw

Ul <a

g

(t < o o t> H Ul h N w M a S p, Ul o M C P <\l u w> U 0

IEH

HW

•I- 5 4- c > CD

OJ 03 fT3 o .— c o <u CO U -Q

DX "D

e: -c

V > 01 Z w z •< M n > b. OS 1- •< 1 U w z a p z c

ns z o B

f- (-

aV

H <

PS

M IU

0. Ul lb

at Ul M f o Ul <

lb evi

u

a IB

u

iU <; UlH o z p «>

t> >0 o < < ri < p z H H o <t b. bl H Ul t> O h

(DJ

p •«

© >J < w <) >-i

i-l P < «) Qi z a H «; p

lb Ula o

Ul o u H •J <

IS P. < X

p

w < H <t H w

0' Ul

n < r" IK U m H •< > M CJ

(b < o P w

I-l

B < o H H Ulh< H U<

Li- o S- >

137
w

Q

<

M

K

m

w

o

<

•J

u

u

D

w

o

w

Q

"<

.J

w

w

piu

u

w

rn r) m

w

h

<

-<o

u

M

P < In»W

w

•4 ^ CM « M < u

»

W

hJ

CI

138
0© s

in £ © oo

(-» m in

OS

H o o

ai

w

LEA 0z

=t <_)

m 1— 1— 1— 1— c Q1 Q Q ea; «^ o o 1 1 1 1 1 1 ss 1 1 1 1 1 1 1 •< •<K P o 0 H P u H w !s a CO » M lU s \ \ 2 0. o o 0 M CO n w H

0.

D o x 0 P S5

C

tn CO iZ

w

H (14 P o H w :s CO

CO

wp CO

»<: CO

A.

m

t<: 0.

CO

0.

CO

WCO CO

w !Z < P -cD DPP

K

W

H COH CO

m Si,

X

U 0. \ \ \ M CU

in CO CO CO Ui

M a. 0.

V

u

u CO tn CO

CO

w

mw < B » < CO cn CO H H cn CO n M

f- CD

m (\i o (? (\i in o in o O ft o

Ul >< • • • •< 0 N r- in m ;e 00

•<H

M

in

in <!

•*

H

©

PU

W ou < n •< s

in

p (0 z m w

ta PC H a i-- D ^J H K iJ

<!

11. CO S P K

S; 15 H

lA

COM cu

p cn 0.

CO <!H

©H

b. 55 c Pw w OS p H w w P m w D z p

0. z CO

•<» c

Ifl z NM O

>0 at 0>

Ifl oa © Hn © In m

tn >"K

M <2

a.

M » < m U

tB CO IE H 1- MZ

IK

0<^ z y * IE M W

COH s cn

H,

NM \W Z U

WP P < tn a, n ID m m ? © © s cn a. B.

cn o o \ N B, 0, \ cn ifl < <

cn Ik u. a. Oh ^ » - ©©•<< cn cn © » & M t>i M CO cn M M

ro 0^ 0^ 00 Ifl

w rj in CD o

l^ocvi.tinuiNiT'C^o r)*^<looo>o>Cf'C^o

NrtycvjoaCMCM

<-OD(M*i)OCO^ritHO^ •HMCvjcvm^inoi

C' ©©©©©©©©© HHHHHt-Hl-l-'l-'

o-*<o(vi\r>oooiont-i

rH ri (\j (M

m n- in ow

tcH

M

,J

iH ID m M

1/1 z CO © ©

a.

p CO o M MX s111 M

t"

© P

ii<

H

w

p P © < W p a< p

a. U4 P < Oi z a<

in

C5 cn < zM a' o a) z «;

aj cn

CO

?; < © p a)

a. a] < m p H w> z a. © < © K m M

ac tu z Z ©

CO

© z M H a)

EC cn « U < w M u IE s »j ^

in

a^ < z z © © CO H

aj

CO ? H H ij P © z

CO z u < M z

>-

M

p hJ <! up < Oi z P H

aj cn

W

a.p

cn a. P cn M

CO P

EE Z

«. P

139
wJw o U < 04 o O

u

w

€

M

MM >J

Uu fa fa CO to to to M to to

w >< < •< < -< < < >< < < M

H

ft

H

O o fip

p P p

p

p P P pKH w

»5

(ti

h o fa Ul! fa fa (0 u;

H o fa < to fa w z M

a ft; < o < fa I-l <

10 OS

u s 4! Pi

M pa PS fa

u o fa <! o fa fa fa

H z a, to fa fa ID fa D

to a. z M

u o ft; ft! IE o \ U < M c fa < fa fa fa •< fa ft! M M • fa Ui ft! p: •0 ft! <; •< fa W • o to fa H fa o fa < fa «0 "< ft; (/i 06 < 10 < P to H w ft! ;e Z ft! M to H ft; fa ft! fa 10 £> to "< fa to P <

a< (1-! ft! Z z H M M Qi o < fa fa s t •< fa

M fa < 10 10 ID 10 fa u u w Q P ft! ft; ft! ft! M fa H

CO

w o < a < •< fa fa fa fa c fa

[Ll fa fa IT 10 o © o z fa ftS Hi CO to to to 10 H M TV fi to P p u to z P K <! © ft! < < z z fc fa z

<! fa z z 10 •< < c ID

M > « M H fa "< < fa n P H fa

(0

uw

H in I/) o ro t-<

n o ct in r- 00 <0

H

K

Ui rH ft (VI (VI

(fa Dh •* n

Pfl Hzw

to in ro f-fl ro in ^0 in 00 (0 *t o

CO PJ »o <t vO ro ro o ro M (VI 0^ CM c^ (^ H o H ro (VJ >< ro (VI

CO IT H % §M

)-) <

•-) (t) ID

(fa < o c«

w

p z to (0 10

Q < < to

M

M

ft! 10 P Z Z V

C fa tc w Oi •< M hJ Hi •< fa PQ UJ w !X! H ><; u V) fa M z fa fa ID z <; < M fa u fa M M ft: PS i-l ft! p P P Z

cn

fO I C7) o <u fO >

SQ Q 4_> 1)

I-l CO i_

(/} QJ

Q jy

c: q_ rv

</> o 1 1 1 o QJ CO CD to ,—~ QJ d) *o Q r*i 4_> • r~ i—

•r- +-> >

fO

Q 4-* OO CO *r— > 1 c > QJ dJ O Q O 't— NX o O

Q) o CO

O

(/I ,— c QJ fO CD rn s_

i_ i_ o "O SQ I/) QJ c~

<+- "O

O <C

M—

O QJ

CD 1 ^ CU <C QJ

O •M

CI 1 1 

1

"O

Q SZ -M 1 o fO o "O

to [-H CQ E CO (/) 1 

fO QJ o C 1

Q. (J o n d) CO s_

(/) ec CU QJ

d) -Q

Q CO CO CO 1

CO • QJ CU

fO CO r- £ QJ o (— £ 1— 'r- rX j_ o

CL) t)_ c i- Q_ O CD • o X to • 1— Q QJ

CD S- c/) S- QJ -r— QJ o o •p- Q_ o fd to CO fO E ri q; QJ M— QJ

t_ o "O o (/)

O _Q

Q

4-> o CD QJ

fO cc QJ

C

(J

Q fO 4_> .r- fO Q CQ M- "O "O

<D (J fO c

c~ QJ QJ • fD QJ -QO^ CO r*> (/) C t—

fO

O QJ •1—

X o >^ CO

i. <t5 QJ *r- QJ CD

QJQ SZ c i_ (/I to "O o

>^ CD "O CU t/) QJ

Q

Q

O j_ "O 1— -P CO £Z o tl— r— 3 Q QJ fO

CU QQ QJ •r- ro

O

4_) [ [ ) "O " -M TQ +-> CT) CI X

•r— I-LJ M— M- Q Q -r rv O O .o Q r— Q- Q_ ^

CD

O

O QJ E to Q_ O O

CO QJ ^v cn (C CD 3 o 1— -fc^ O J3 O +-> O O r— "O 1— 1—

S- n3 o 03 CU

O QJ

O 3 Cl O)

f~

a ro

O Q-) ^ .j > +-) 1—

1— 4-> c~ coo Q Q d^ fO fO o o

SO CJ I O E E C r— o o O >, 1—

O S- ra QJ O o s- o 1 > •r— o s- l-H o M- £2. •r— +-> O) 4- CD +-> O) E S- res +-> •r— t- s- o QJ C QJ "tO- SZ CU <u U O CU _c: o _c: o 1— E CU 00 1—

O D- Q. 1— CJ hcii a; CJ o 1—

C_> Q- _i t/O 1—

CJ <c eC < cC 1—

o Q Q Q O 1—
TEST AND SET SUMMARY

EXEC T/S T6TAL «

SLEXl " 18433

TSSWL • 15

0,X • 32

IE - 198

TSASA - 1 JK - 1 MB " 13

PCFTS - <508

KDACT - 1 SLKDNT • 23

TSSLC « 33

TSACS - 2

TSCCIL - 5

TSCMAP - 21

TSNAMl • 12

ESITEH " 292

TOTAL TRACED T/S « 19^90

21199 USER T/S T6TAL - 0

^For both processors~

Common Test and Set Cells

SLEXl: Protects the switch list queues.

TSSWL: Protects information in the switch list entry.

SLRUNT: Protects total accumulated run time in the PCT,

IE: Protects ER to CPOOL$ and CJOIN$.

PCFTS: Protects granule item.

ESITER: Protects ESI Activity Termination Queue.

TSCMAP: Protects demand/batch sharing information.

141
"O

OJ -M

. c ^-

•<- o

E

Z P iz; Sz; ^ 2: W W W w W W >,ts wwwww xn rooj

\0 o <t a I o

^—

<t vD i <f *-j 00 O I N

• (M • • • I •

. I o

<J- I W I (M

IC O © P M

U. >< M

O p p pq

>< O < W

M (Li P PU K <

D3 n < K M H

09 CtS M Qi ^ O

(u IX IS (u ID H

> > > t O W IE. Z p Z > <! 5

Z < ID !Z <!

-< -< P «

P ^ W C

P W <; p H

w H w <: w

H < P W tc

««; w w <j Pi H

M w h (t) u

« O •< P& u » u w

CO 0:; %

M W U U H

O tsl 05 fH

<! w <! p

M W ID l» C> U U 0! < 2 H <

a, C! <! 0. H

a- H D

a. 2 M Qh M ft W U H

M c s <! a

C5 « ID W U << H

n i-i PK pu H <1 IL TD H

P w

ID M Pe W (14 M tc ID pn B

Pi H O H H

M

a, p p p p ^ c © c

(H H H H M

CO W W W PC U (1:1 (I! (i^ (4 H a< pu PL.

(/] vj c/i tfj v; M M M H M

(C n PQ [B P3 H H t-< e

c» o o o o

2: z z z z

M M H M M

OQ W K p; pe: D P P P D

P P p p p

142
NBS-114A (Rtv. 1 )-77>

U.S. DEPT. OF COMM. BIBLIOGRAPHIC DATA

SHEET

1. PUBLICATION OR REPORT NO. ms SP 500-34

2. Gov't Accession

No.

3. Recipient's Accession No.

4. TITLE AND SUBTITLE

COMPUTER SCIENCE & TECHNOLOGY:

UNIVAC 1108 EXEC LEVEL 32R2 Performance Handbook

5. Publication Date June 1978

6. Performing Organization Code

7. AUTHOR(S)

Capt. John C. Kelly and Lt. Gary P. Route

8. Performing Organ. Report No.

9. PERFORMING ORGANIZATION NAME AND ADDRESS

NATIONAL BUREAU OF STANDARDS

DEPARTMENT OF COMMERCE

WASHINGTON, D.C. 20234

10. Project/Task/Work Unit No.

n. Contract/Grant No.

AY-505-080-Armv

12. Sponsoring Organization Name and Complete Address (Street, City, State, ZIP)

U.S. Army Military Personnel Center

Alexandria, VA 22332

13. Type of Report & Period Covered Final

14. Sponsoring Agency Code

15. SUPPLEMENTARY NOTES

Study performed and report prepared by the Federal Computer Performance Evaluation

and Simulation Center, Washington, DC 20330.

16. ABSTRACT (A 200-word or less factual summary of most significant information. If document includes a significant

bibliography or literature survey, mention it here.)

This is a report prepared for the Army Military Personnel Center (MILPERCEN) . It

describes a set of hypotheses for evaluating the performance of UNIVAC 1100 Computer

Systems. The hypotheses specifically apply to EXEC Level 32R2 operating on UNIVAC

1108 Computer Systems. Attempts to apply the guidelines to different UNIVAC 1100

models or to different levels of the EXEC may lead to erroneous results.

The report contains sections on each major complex within the EXEC. Each section

(1) states the performance hypotheses associated with that complex, (2) explains

how the available measurement tools may be used to determine if the hypotheses are

true, and (3) identifies which performance parameters need to be changed to correct

the problem situation. All of the performance hypotheses discussed in the body of

the report are collected together in Appendix A. Appendix B summarizes the

performance parameters and Appendix C contains an introduction to the Software

Instrumentation Package (SIP)

17. KEY WORDS (six to twelve entries; alphabetical order; capitalize only the first letter of the first key word unless a proper name; separated by semicolons)

Computer performance management; measurement tools; operating system performance;

performance guidelines; performance measurement; tuning guides; UNIVAC 1108.

18. AVAILABILITY Unlimited 19. SECURITY CLASS

(THIS REPORT)

21. NO. OF PAGES

1 ! For Official Distribution. Do Not Release to NTIS UNCL ASSIFIED T44

1 X 1 Order From Sup. of Doc, U.S. Government Printing

Washington. D.C. 20402. SD Stock No. SN00irP03

Office 20. SECURITY CLASS

(THIS PAGE)

22. Price

1 1 Order From National Technical Information Service

Springfield, Virginia 22151

(NTIS)

UNCLASSIFIED

$3.25

USCOMM-DC 66033-P7e
ANNOUNCEMENT OF NEW PUBLICATIONS ON

COMPUTER SCIENCE & TECHNOLOGY

Superintendent of Documents,

Government Printing Office,

Washington, D. C. 20402

Dear Sir:

Please add my name to the announcement Hst of new publications to be issued in the series: National Bureau of Standards Special Publication 500-.

Name

Company

Address

City Stale Zip Code

(Notification key N-503)

•U.S. GOVERNMENT PRINTING OFFICE : 1978 0-261-238/143
NBS TECHNICAL PUBLICATIONS

PERIODICALS

JOURNAL OF RESEARCH—The Journal of Research

of the National Bureau of Standards reports NBS research

and development in those disciplines of the physical and

engineering sciences in which the Bureau is active. These

include physics, chemistry, engineering, mathematics, and

computer sciences. Papers cover a broad range of subjects,

with major emphasis on measurement methodology, and

the' basic technology underlying standardization. Also in- cluded from time to time are survey articles on topics closely

related to the Bureau's technical and scientific programs. As

a special service to subscribers each issue contains complete

citations to all recent NBS publications in NBS and non- NBS media. Issued six times a year. Annual subscription: domestic $17.00; foreign $21.25. Single copy, $3.00 domestic;

$3.75 foreign. Note: The Journal was formerly published in two sections: Section A "Physics and Chemistry" and Section B "Mathematical Sciences." DIMENSIONS/NBS

; This monthly magazine is published to inform scientists, engineers, businessmen, industry, teachers, students, and

consumers of the latest advances in science and technology,

I with primary emphasis on the work at NBS. The magazine

j highlights and reviews such issues as energy research, fire

I protection, building technology, metric conversion, pollution

I abatement, health and safety, and consumer product perI formance. In addition, it reports the results of Bureau pro-

• grams in measurement standards and techniques, properties

I of matter and materials, engineering standards and services,

I instrumentation, and automatic data processing.

I

Annual subscription: Domestic, $12.50; Foreign $15.65.

I NONPERIODICALS

1 Monographs—Major contributions to the technical liter- ature on various subjects related to the Bureau's scientific

I and technical activities.

'j Handbooks—Recommended codes of engineering and industrial practice (including safety codes) developed in cooperaj tion with interested industries, professional organizations,

! and regulatory bodies.

I Special Publications—Include proceedings of conferences

j sponsored by NBS, NBS annual reports, and other special

I publications appropriate to this grouping such as wall charts,

ji pocket cards, and bibliographies.

[{Applied Mathematics Series—Mathematical tables, manij uals, and studies of special interest to physicists, engineers,

1 chemists, biologists, mathematicians, computer programmers,

land others engaged in scientific and technical work.

National Standard Reference Data Series—Provides quantitative data on the physical and chemical properties of

materials, compiled from the world's literature and critically

ijevaluated. Developed under a world-wide program cojiprdinated by NBS. Program under authority of National

iStandard Data Act (Public Law 90-396).

NOTE: At present the principal publication outlet for these data is the Journal of Physical and Chemical Reference Data (JPC'RD) published quarterly for NBS by the American Chemical Society (ACS) and the American Institute of

Physics (AIP). Subscriptions, reprints, and supplements

available from ACS, 1155 Sixteenth St. N.W., Wash., D.C.

20056.

Building Science Series—Disseminates technical information developed at the Bureau on building materials, components,

systems, and whole structures. The series presents research

results, test methods, and performance criteria related to the

structural and environmental functions and the durability and safety characteristics of building elements and systems. Technical Notes—Studies or reports which are complete in themselves but restrictive in their treatment of a subject.

Analogous to monographs but not so comprehensive in scope or definitive in treatment of the subject area. Often

serve as a vehicle for final reports of work performed at NBS under the sponsorship of other government agencies.

Voluntary Product Standards—Developed under procedures

published by the Department of Commerce in Part 10, Title 15, of the Code of Federal Regulations. The purpose

of the standards is to establish nationally recognized require- ments for products, and to provide all concerned interests with a basis for common understanding of the characteristics of the products. NBS administers this program as a supple- ment to the activities of the private sector standardizing

organizations.

Consumer Information Series—Practical information, based on NBS research and experience, covering areas of interest

to the consumer. Easily understandable language and

illustrations provide useful background knowledge for shopping in today's technological marketplace.

Order above NBS publications from: Superintendent of Documents, Government Printing Office, Washington, D.C.

20402. Order following NBS publications—NBSIR's and FIPS from

the National Technical Information Services, Springfield, Va. 22161.

Federal Information Processing Standards Publications (FIPS PUB)—Publications in this series collectively constitute the Federal Information Processing Standards Register.

Register serves as the official source of information in the Federal Government regarding standards issued by NBS

pursuant to the Federal Property and Administrative Services Act of 1949 as amended. Public Law 89-306 (79 Stat. 1127), and as implemented by Executive Order 11717

(38 FR 12315, dated May 11, 1973) and Part 6 of Tide 15 CFR (Code of Federal Regulations).

NBS Interagency Reports (NBSIR)—A special series of

interim or final reports on work performed by NBS for outside sponsors (both government and non-government).

In general, initial distribution is handled by the sponsor;

public distribution is by the National Technical Information

Services (Springfield, Va. 22161) in paper copy or microfiche form.

BIBLIOGRAPHIC SUBSCRIPTION SERVICES

|irhe foUowing current-awareness and literature-survey bibliliographies are issued periodically by the Bureau:

jCryogenic Data Center Current Awareness Service. A litera- ture survey issued biweekly. Annual subscription: Domes-

: tic, $25.00; Foreign, $30.00.

pquified Natural Gas. A literature survey issued quarterly.

|\nnual subscription: $20.00.

Superconducting Devices and Materials. A literature survey

issued quarterly. Annual subscription: $30.00. Send subscription orders and remittances for the preceding bibliographic

services to National Bureau of Standards, Cryogenic Data

Center (275.02) Boulder, Colorado 80302.
U.S. DEPARTMENT OF COMMERCE

National Bureau of Standards

Washington, D.C. 20234

OFFICIAL BUSINESS POSTAGE AND FEES PAID

U.S. DEPARTMENT OF COMMERCE COM-215

Penalty for Private Use, $300

SPECIAL FOURTH-CLASS RATE

BOOK