INSTITUTE OF MATHEMATICAL SC IENCES

C ompute r Sc ienc e NSO— 6

SYSTEM S PEC IFICATION US ING VERY HIGH LEVEL DICTIONS

Pe te r Marks te in

Rep ort No . NSO— 6 p repare d unde r

Grant No " NSF-DCR75 - O9218 f rom

the Nati onal S c ience Foundation

Peter Ma=rksteivn

1975

CONTENTS

1. In troduction to Operating System sInformal Review of Operat ing System Objectives1. 1 The Automatic Operator

Program Libraries1.3 Resource Uti lization

A

1.4 Hardware Contro l1.5 Preparat ion and Maintenance of Software

l .2 Overview of Operat ing System InternalsThe Sta te of a Computation

1.2 2 Mappings

1.

1.

1.

1.

1.

2. Paralle l SETLSETL DeficienciesAn Overa l l V iew of the Extensions Which Wil l Define PSETL

Jobs and ProcessesContro l of InterruptsPrivate and Shared DataStandard Q ueues and Faci l i t iesProcess Contro l

Process CreationProcess SuspensionInterprocess Communica tionProcess Termination

ExamplesA Remark Concerning Machine Dependent Features and PSETL

Time and ClocksInput/O utput

Detailed Summary of the Elements of PSETLSpecia l Se tsPrimi tive Opera t ionsMacro Operations

O ther Proposals forHigh Level Language Operat ing Sys tem Primitives

3 . A Sim ple Operating SystemSystem Object ivesJob Contro l Language

The Job StatementThe Job-Step StatementThe Data Fi le StatementEnd-of-File Statement

Moni tor ServicesStep Termination

3 .2 Input/O utputSystem Organization4 1 System Nucleus

Resource AllocationMajor Components

Operator Communicat ionsSchedulerInpu t ReaderOutput Printer

User ProgramsCoded Operating System

Se ts , Maps , and TablesG lobal InformationUser Oriented Information

3 Process and Mover Ori ented Information

3 .

3

3

3

3 .

3 .

3 .

— i i i

. 1.4 Channel and Device O riented Sets5 Maps with Domain program filesRemarks on the Uniprogramm ed System

.2. 1 Input Reader2.2 Outpu t Wri ter3 Scheduler4 Job Control5 Resource Allocation6 Operator Services

T

3 .

3 .

5 .

3 .

3 .

3 .

3 .

3 .

3 .

3 . 7 Monitor Se rvicesu

m

m

m

m

m

m

w

w

m

m

4 . A Mul tiprogramming SystemSystem Objectives

4 .2 Multiprogramming Stra tegy Considerations4 .3 Job Contro l Language

OrganizationThe Code

4 .6 Possib le Enhancements to the Batch Systems

5 . An Interac tive SystemIntroductionCommand Language

LogonLogoff

Main Memory St ructure5 .4 The File System5 . File Names5 .4 .2 Comm ands for the File System5 .4 .3 Comm unication Between Users5 .4 .4 LibrariesOrganization

The NucleusPrivileged System Com mands

5 .3 Non-Privileged System Comm andsRemarks on the Interactive System

Log-O n

6 .2 Comm and Analyzer6 .

6

C7 .

7 .

5 .

5 .

3 Main Storage Management4 Scheduling and Timingoded Interactive System1 System St ructures2 The Code

5

5 .

5 .

5 .

6

5 .

5 .

5 .

5 .

5 7

5 .

5 .

6 .

Classificat ion of PSETL ExtentionsExperience with PSETLFuture Directions

Bibliography

Appendix A : A Precis of the SETL Language

Index

_ iv_

ABSTRACT

Today,operating systems are an integra l part of computing systems . Yet high leve l programm ing

languages are not genera lly used by the designers and implementors of systems software . In thi s

report we introduce a language , PSETL, in tended for operating system descript ion and based on

the SETL se t-theoret ic programming language .

PSETL i s a version of SETL which has been enlarged to a l low-

the descrip t ion of a lgori thms

invo lving interrupts,paralle l ism , and to some extent , machine dependent features . Using PSETL ,

several operat ing systems are presented in detai l . The firs t , a s imple uniprogramm ed batch system

i l lu strate s bas ic contro l mechan isms and schedu ling . The second , a mul t iprogrammed batch

system,shows addi t ional complica tions which ari se due to contention for resources and conflict ing

objectives . Our third system i s interact ive and includes data sharing capabi li t i es .

PREFACE

This thesi s i s an experiment in extending a very high level language , SETL, for operating system

description .

’

We propose an extension to SETL ,and then use our extension to speci fy severa l

operating systems . The principal question we are t rying to address i s : can extended SETL be used

for the specificat ion of operating systems as effective ly as SETL can be used for other c lasses of

problems"The reader , after studying the examples of Chapters III , IV , and V wil l have formed his

answer to this question .

An experiment of this kind cannot confine i tse lf to the discussion of small examples . Operating

sys tems are i nheren tly larger and more complex than , say , sort ing algori thms . To give a fair

demonstration of extended SETL we fee l i t necessary to describe an entire operating system ; even

a simple example of thi s kind is relatively large , and requires at least a dozen pages of code .

I f our experiment i s successfu l , then de tai led speci fica tions of severa l operat ing systems , in

comprehensible form , appear in this work . In order to motivate the examples which are presented,

and“

make them as clear as possible , this thesi s has been cast in the form of an introductory text on

opera ting systems which contains three comple te ly coded examples . Of course , i t i s these

examples which make the text unique .

The reader is assumed to have a working knowledge of SETL ; no explanations of SETL coding

dic tions appear in the body of the text . On the other hand , no previous exposure to Operating

system internals is assumed on the part of the reader .

Acknow ledgem ents

I am indebted to Professor Schwartz for his many usefu l suggestions during the preparation of this

work .

My employer , International Business Machines , Inc . has very generously given support to this work

through its Graduate Work-Study Program .

Special thanks go to my wife , V icky , for her encouragement and patience during my graduate

years . And apologies are due to my daughters Carole and Michele for my occasional preoccupa

t ion with my studies .

Chapter I

Introduction to Operating System s

Our firs t task is to de fine what an operat ing sys tem i s . I t wi l l not be possib le to do thi s wi th

mathemat ica l p reci s ion . I nstead , a loose characteri za t ion of‘operat ing system ’ wil l be given

,

motivated by ci t ing object ives which such systems at tempt to sati sfy .

Inform al Rev iew of Operating System Objectives

The Autom atic Operator

In the early days of computing each job or run was an independent enti ty . A user submi t ted his

own copy of a language processor , loader , or debugging aid , along with ins truct ions for the

operator on act ions to take on the occurrence of various machine hal t s . At the end of a run,

computer memory was genera lly c leared , tape ree ls associated wi th the concluded run dismounted ,and tape ree ls for the next run mounted . Transit ion time between runs was frequent ly of the order

of 1 to 5 minutes . These inefficiencies were often compounded by the inabi l i ty of a computing

instal lat ion to process a mul ti-step job . Thus , a" compi le and go job was usually two runs , with

the attendant overhead paid twice .

With a larger number of appl icat ions becoming economica l ly feasib le and with increased computer

speed , the length of typica l computer runs especial ly runs for debugging approached and fe l l

below the run transi tion time . Just as the human ’s abi li ty to enter data and commands became the

limi t ing factor for desk calculators , so the speed of humans during run transi t ion time threatened to

become the limit ing factor in the use of computers .

As wi th conventional compu ting , the solu t ion to the job transi t ion problem used the stored

program concept . Information describing characterist ics of a job and the re la tions between job

steps are included in machine readable form along with the data and programs which comprise the

job . A compu ter program given a sequence of jobs which include job characteri stic information

can then determine an effic ien t order in which to run jobs . Such a program is commonly cal led an

operat ing system . (The additonal sta tements speci fying job characteri s tics and other opera tional

i nforma tion const i tu te the ‘

job contro l Mul t ip le job s teps per run become more

common as a machine,instead of an operator

,interpre ts and acts upon condit ions stat ing whether

subsequent s teps should be executed , and transmits the output of one s tep to the next . By using

precise ly s tated job or step transi tion information and resource requirements a computer program

can take many of the actions previous ly associated with human operators , reducing job transi tion

t ime to a few seconds a t most .

Success of the programmed or au tomatic operator depends on control re turning to the operating

system at the conclusion of a job or step . This is insured ei ther through software conventions ,

specia l hardware , or bo th . Modern computers have hardware faci l i t ies whose use guarantees

integri ty of the operating system , and enforces i t s software conventions .

1 Program Libraries

In any computer installation , there are a number of programs which are useful to a large class of

users . Examples of such programs are language processors , loaders , debugging aids , as we l l as

appli ca tion programs such as sorting programs . Rather than require each use r to supp ly his ow n

copy of such programs , an installation maint ains a library of these frequently used programs , and

an ope rating sys tem can invoke these library programs on behalf of a user in response to job

control language sta tements . Thus ,instead of submitting a bulky program , a few ICL statements

are all that a user need submit to invoke a library routine . Use of a cen tralized program library

also insures that the most current version of a util i ty progr am is availab le to all .

Opera ting systems usually include faciliti es for upda ting and maintaining program libraries .

An obvious extens ion to the program library idea is to pe rmit subgroups of users to create and

main tain pri vate librarie s of programs . The same ope ra ting syst em facili t i es which are used to

crea te and maintain the central library are usually avail ab le for the private lib r aries , and JCL

general ly invokes program s from any library with equal ease .

One aspect of program library maintenan ce should be mentioned at this po int because of its utilityin a wide c lass of situations : this is the data management capability of Operating systems . Data

management involves co nstruct ion and main tenance of ca tal ogues which can be used to locate

use rs ’ files . and structuring data files so that specified subse ts can be easil y extracted . In its most

prim itv e fo rm , data management mere ly ai ds in the coding of complex input—output inst ructions ;

advanced data management makes avail ab le convenient and powe rful linguis tic devices for

characterizing and extracting subse ts from data files .

Resource Util ization

The discussion of au tomatic operat ion in section indica ted the need for a program to manage

the sequencing of jobs in order to avoid excessive system idle time be tween runs . This function of

Ope rating system s , while i t is the function w hich his torically motivated their construction , is j ust

one aspec t of the more general problem of maxim izing utilization of the entire computing system .

Many of today ’s compu ting sy stems include more equipment than any single job in the ins tall ation

can use . Such conf igura tions are j us tif ied by the des ire to Offer a w ide c l ass of se rv i ces . For

example , a large accounting applica tion might require many tape or disc drives but not much main

memory , while even a modera te linear programming prob lem can use a l arge main memory to

advantage .

Most jobs , however , do not tax any one component of hardware to the utmost . For such large

computing systems , running only one job at a time can resul t in a subs tantial portion of the

computing system’ s resources standin 0 idle . To increase to tal system u tilization

,Operat ing sy stems

exploi t the fact that equipment other than CPU and main memory can ope ra te autonomous ly from

the CPU for myriads of CPU ins t ruct ion cyc les . Several jobs are placed in to main memory

concurrently and cont ro l o f the CPU gi ven to one of them . When the curren tly running job

reaches a sta te where i t cannot utilize the CPU until the te rmination of an I/O Ope ra tion ,the CPU

can be exp loi ted by one of the other jobs in main memory . On the other hand , i t would be

undesirab le if each app lica tion were to be wri tten in such a manner to cooperate onl y with a

spec if ic se t o f other applica t ions . for then the econom i es of concurrent running can onl y be

real iz ed when all membe rs of a set of Coope ra ting program s run together . Ideally,i t should be

possib le to wri te a program as if i t were the only program being run,and st i l l real ize economies if i t

fi ts in to main memory with another program which has a di fferent pat tern of I/O usage .

Many operating systems permit preci se ly this type of programm ing . Using the interrupt faci li t ies

of the CPU , the Operating system can gain control when a user program is about to become idle ,and give control of the CPU to another job . Simi larly , when an awaited condi tion i s sat isfied , the

opera ting system can regain con tro l , and then return control to the task which was wai ting for the

condi t ion to be sati sfied . The sharing of hardware resources by independent jobs in the manner

just described is ca l led mult iprogramming .

To effective ly schedule the typica l mix of jobs present in a mu ltiprogramming environment,the

operating system may require characterizations of the jobs being submit ted for execution . Such

information can be supplied via the job control language . Assuming that more than enough work

is avai lable a possible objective of an operat ing system in scheduling jobs and determining which

jobs are to run concurren tly i s to minimize the ren ta l paid for id le equipment .

I n prac t ice , however , the system must take accoun t of o ther cons train t s such as job deadl ines .

I ndeed,i f we take a broader view of a computing system and inc lude as " components the people

whose activi tie s depend on the resu l ts of computa tion , then thei r id le t ime must a lso be taken in to

account . A direct consequence of such reasoning is the cons truct ion of in teracti ve computing or

t ime-shari ng systems which on the surface appear to require ex tra hardware which does not

contribute direct ly to throughput .

The users of shared sys tems must have guaran tee s tha t the i r programs and da ta wi l l not be

disturbed by co-resident programs . This problem has already been al luded to in the discussion of

au tomatic Opera tion i n sect ion the same techniques which guaran tee integri ty of the

operating system in a uniprogram m ed environment can be extended to preven t physical interfer

ence among mul tiprogrammed jobs .

Hardw are Contro l

To guaran tee the integri ty of programs sharing a computing system,one removes direct contro l of

some hardware features from the system ’s u sers,and makes those fea tures avai l able only through

simulat ion , during which potential misuse can be detected and prevented .

The hardware features whose contro l the operat ing system reserves for i tse l f are precisely those

fea tures which are used to subdivide the computing sys tem ’s re sources . The ins truc tion se t of

today ’s computers usual ly consists of two classes : privi leged and non-privileged instructions . The

privi leged ins truct ion se t includes faci l i t ie s for inpu t-output , ins truct ions for se t t ing access

boundaries i n main memory,i nterrup t contro l i nstruc tions

,and instruct ions which t ransfer the

computer between problem sta te and supervi sor sta te . I n the supervisor state , al l i nstructions are

val id ; i n the problem state , privileged instruc tions are treated as i l lega l and cause interrupts . The

enabl ing and disab l ing of the interrupt system requires privi leged instruct ions .

I npu t/output instruc tions are c lassi fied as privi leged to prevent one user from accessing a device

which contains data belonging to ano ther user . In many cases , a single physical device , such as a

disc , contains data belonging to several users , and the opera ting system is required to es tab lish

correct ‘ logical ’ to ‘physica l ’ correspondences . To replace the privi leged I/O instruct ions which

_3_

users are not allowed to invoke directly , the operating system provides I/O routines . A benefi t to

the user is that the operating system also provides addi tional facilities which provide autom atic

buffering and synchronization between and computing .

By rese rv ing control o f physical I/O addresses to the opera ting system , the chance that arbi trary

programs can be mul tiprogramm ed is maximized ; for if two program s depe nded on using the same

physical I/O unit from a set of identical devices , these tw o programs could never run concurrent ly .

Job control language provides mechanisms to es tablis h correspondences between user invented file

names and the devices on which the files are located . A compensation for the loss of direct control

of I/O de v ice s is that the I/O ins t ructions and I/O error indicat ions provided by the operating

system tend to be device independent , so that frequent ly a program can utilize a wide varie ty of

device s for a temporary file without any modificat ion .

The inte rrup t system is also pri v il eged , as i t is the principal means of comm unicating exceptional

condi tions to the operat ing system , inc luding attempted violat ions of security . Often a sim ula ted

inte rrup t sys tem is made avail ab le to user programs , so that these programs can a lso hand le

exceptional condi tions wi thout explicit ly executing tes ts which usually fail . Of course , the fact that

the operating system handles many classes of inte rrupts explici t ly means that programs are re lieved

of all necessi ty to conce rn themselves with interrupts .

To allow sharing of main memory , users mus t often state how much contiguous space they w ill

require , but usually do not have the freedom to specify the actual addresses in memory where the

space will be . This limitat ion imposes minimal user discomf ort , since the use of re loca ting loade rs

has already preempted some control over memory allocation . Even this modest level of discomf ort

i s avoided in computing systems which have"

v irtual memory" capabilit ie s . Such sys tems can

often be programmed so that each user in a mul tiprogramm ed environm ent has the illusion of

hav ing all the o riginal resources of the computer , including all memory locations , at his disposal .

Preparation andMaintenance of So f tw are

Once one has realised what the object ives of Operating systems are , one is faced w i th the prob lem

of producing the operating system itse lf . With what programming approach sha ll the ini t ial design ,

deve lopment , and debugging of the operating system be attempted" What features for se lf

maintenance shall be introduced into the operating system : what instrumentation , software error

detection capabili ty , what ability to test the Operating system under i tself" Ability Of the operat ing

system to accomodate a wide vari ety of hardware conf igurat ions is also an important design is sue .

A significant fract ion of an Operating system cons i sts of library programs which behave as user

programs and which are maintained in the same way as ordinary user programs . Language

processors are examples of such opera ting system components . Standard library facilit ies can also

be used to maintain and update the source programs compri sing the operat ing system ,and the

language processors to compile these programs . Furthermore , ordinary programs can be used to

st ructure compiled operating system program s into a new operating system . The only port ions of

the operating system which are notably dif ficul t to debug in an opera ting system environmen t are

those routines involved with hardware and resource allocation .

O v erv iew of Operating System lntem als

Simulation of human operations , achieving hardware control and opt imizing hardware u ti l ization

imply characteri st ics not often found in ordinary application programs . A human Opera tor a t the

conso le of a computer exerc ises direc t contro l on ly sporadica l l y , whi le he observes the system

cont inuously , looki ng for for unusua l occurences . An opera ting sys tem , which among other things

simulates a human compu ter Opera tor , must be ab le to exhib i t s imi lar behavior , tha t i s , the

operating system must give up contro l O f the CPU for a majori ty of the t ime so that user programs

can run , and in ini tia t ing a user program i t must p lace the CPU in such a state such that i f any of a

number of specia l s i tuat ions ari se , contro l re tu rns immedia te ly to the Opera t ing sys tem . Such

behavior can be achieved by simula ting successive user program instruct ions and test ing for the

unusual condit ions as part of the simula tor ’s basic cycle , but this is very inefficient . Computers

which are designed to run with Operat ing systems contai n an in terrupt system which makes i t

possib le for crucia l changes of CPU control to take place effic ient ly . Leaving the computers in a

sta te enab led for a l l i nterrup t condi t ions i s equivalen t to cons tan tl y moni tori ng for unusual

conditions bu t taking overt act ion only when such condi tions occur . Control and management of

the interrupt system is fundamental to an operating system .

Even the simplest operat ing sys tem creates a mu l tiprogramming environment in the sense tha t theoperating system consis ts of severa l re lat ive ly autonomous subprograms which run " concurrently "

and which have the property of requiring only short bu rs ts o f CPU usage be tween which only

moni toring of unusual even ts i s required . Example s of funct ions trea ted in th is way inc lude :

scheduling and dispatching jobs , contro l l i ng inpu t/ou tpu t devices , requesting and confi rming the

mounting of tape ree ls or disc packs , and avoiding use r program time overruns . Such functions are

then mult iprogrammed with one or more user programs .

The State of a Com puta tion

A computer running under an operat ing system is actual ly invo lved with several poten tia lly act ive

computations at the same t ime . One of these programs may be in control of the CPU ; the state of

the other computa tions must be stored in a form allowing them to be restarted .

The de tai led descrip t ion of a compu ta t ion ’s sta te i s machine dependent ; however , i t can be

characterized with sufficient precision in an abs tract way . The state O f an interrupted computation

consis ts of al l the informat ion necessary to resume the computation . At the machine leve l , this

information fa l l s in to three broad categories : data resident in registers of the CPU , data resident in

the address space of the computation , and data resident in fi les .

For each program which it manages,an operat ing system reserves a port ion of memory , addressa

ble only by the Operating system , for storing the CPU residen t data when the program loses control

of the CPU . A typical i tem O f regis ter-resident data is the locat ion at which to resume execu tion ;

thi s is the last datum which the opera ting system restores when re turning control to a program .

I n many batch systems , address space residen t data remains physica l ly resident in cen tra l memory

during a program ’s en ti re run,i nc luding t imes when the program does not cont ro l the CPU .

Alternative ly , one can copy the memory residen t da ta associa ted wi th a program P onto a fi le

accessib le onl y by the Operating system when P loses contro l of the CPU , and can bring i t back to

physica l cen tra l memory before re turn ing contro l o f the CPU to P . O ther schemes invo lve

-5

maintaining only a fract ion of address space residen t data in physica l memory ; this‘virtual

memory ’ approach will be discussed in greater detail below .

Since physical devices may store files associated with independent programs , the operating system

must keep track of the assumptions which each program makes about the logica l posi tioni ng of

such devices,so that these assumptions wi ll remain valid even if the device is shared in a m ultipro

gramming environment .

Mappings

I t has already been Observed that for reasons of securi ty and because of uncertainty over which of.

several identical resources wil l be assigned , programs running in an operat ing system environment

are preven ted from direct ly accessing many of the computer ’s resource s . Consequent ly , such

resources are referenced using programmer-invented symbols rather than physical addresses . The

Operat ing system assigns real resources to symbol ical ly named resources , and creates a map from

symbolic name space to the space of rea l resources . Operat ions on symbolical ly named devices are

interpre ted and symbolic device names are mapped to physica l device addresses . I nverse maps

must also be available so that signals from real devices can be associated wi th the symbolica l ly

named devices .

Tables representing maps between various symbolic name spaces and device address spaces can

consume a large fract ion of the space occupied by operat ing systems ; many system actions employ

these maps or the ir inverses . For example , in fi le manipu lation maps between external file name

space , external volume name space , symbolic name space , and physical device address space ,are al l required .

Chapter 11

Parallel SETL

In presenting opera ting system algori thms , i t i s desirable to focus on algori thmic content rather

than machine dependent deta i l s . A natura l approach is to present programs embodying the

algori thms in a higher level language .

The language used should have the property of not forcing art ificia l s tructure on the data which the

Operating system manipu lates . While in pract ice the structure chosen may have a great beari ng on

performance , this choice of data s tructure may be hardware dependent and should not be dictated

by the language chosen . In the programs to be given in this thesi s , the focus wi ll be on algori thmic

conten t . The po ten ti a l advantage for a st ructure free nota t ion wi l l become apparen t when we

come to represent the many maps which an Opera t ing system requires . A crisp ,mathematica l

notat ion preserves spiri t of the algori thms manipula ting these maps ; thi s spi ri t would be obscured

by a language which insi s ted upon structura l de tai l s . Accordingly our algori thms wi l l,after

appropriate informal descrip t ion , be presented as SETL programs . I t wi l l be seen to be of

particu lar advantage that SETL al lows arbi trary index se ts (domains of maps) without requiring

explici t attention to how indices map into integers or o ther preferred en ti ties .

SETL Deficiencies

There are however severa l no tio ns needed in describ ing operating systems whi ch cannot be

expressed in ordinary SETL . Operat ing systems coordinate mul t ip le processes,and mechanisms

are required to identi fy these processes and to speci fy the way in which control passes between

them . I nterrup t mechanisms are necessary as a means of communica ting between opera ting

system and user programs , and it must be possib le to speci fy protection mechanisms in order to

al low programs to run concurren t ly in a safe way . O ther fea tures which must be described in

presen ting opera t ing system algori thms , bu t which are not avai l ab le in standard SETL , i nc lude

clocks and t imers , external device communica tion , resource a l location , and resource sharing .

To make i t possible to describe operating system algori thms , we shal l add idea lized versions of

these fea tures to SETL . Our operat ing system oriented ex tensions wil l no t necessari ly correspond

direct ly to the hardware of a speci fic machine ; however , al l our extensions can be rea lized on third

genera t ion or later comput ing systems . SETL wi th opera t ing system extensions wi l l be cal led

PSETL , short for paral le l SETL .

Our SETL enhancements wi l l take severa l forms . Special se ts which indicate the state of compo

nents of the computing system , such as the process in contro l o f the CPU , wil l be added to SETL .

These sets wi l l be accessib le to certain operat ing system routines bu t not to user programs . Names

of specia l sets , which are only access ib le to the Operat ing system si l l appear in bo ldface type in this

text .

A number of new operations wi l l be defined . Of these Operations ,only a few are tru ly fundam en

ta l ; the remainder can be defined in terms of the fundamenta l ones and ordinary SETL . But most

o f the t ime i t wi l l be convenient to think in terms of of the macro opera t ions which wi l l be

introduced . Of course,the representation of these macros in term s of a stripped down PSETL

embodies some qui te fundamental operat ing system algori thms .

An O v erall View of the Extensions Which Will Define PSETL

Jobs and Pr0cesses

The coarsest identification Of independent programs and data within the computer wi l l be by job .

To uni fy the control s tructures of the operating system , the Operating system itse l f wil l a lso be

considered to be a job,although none of the user jobs are independent of the opera t ing system .

With each job,a ‘mover ’ i s associa ted as a means of ident ificat ion , and a special set ,

"

m ov ers" ,

within the operating system will ho ld the identifiers of all currently active jobs .

In representing the operating system ’s processing of a job , i t is not sufficien t to take into account

only the code (i.e. program text ) and data which comprise the job ; the varying data sta te generated

when the program execu tes must also be considered . The words ‘program ’ and ‘procedure ’ wil l be

reserved to signi fy the ( sta tic ) pattern of bits which the hardware is ini t iall y given to execute . A

program in execut ion, i.e . a program already coupled to data and thus a t least potentia l ly ‘ in

motion ’ wil l be ca lled a ‘process ’ . The notion of process can be put formally by mimicking the

defini t ion of a computat ion used in discuss ing Turing machines . A process i s the sequence of

sta tes which a CPU takes on in executing a program . Since /w e wish to al low programs to initiate

independent paths of execution (i.e . to ini tia te para llel processing) , we wi l l a llow for more thanone process to be associa ted with a job . Each process corresponds to a complete path taken by a

C PU through the program .

Formal ly , a process is then identica l wi th the hi sto ry of a C PU’

s execution of a program . In order

to be able to regard such a history, (which may actua lly be executed in bi ts and pieces ) as an

identi fiab le ‘ thing’ , we will associate a unique blank atom p with each process at the time of i ts

inception ; p wi l l serve , and occasionally be referred to , as the process identifier , though sometimes

in the interests of brevi ty , we wil l refer to this identifier simply as‘a process ’ . That is , we wil l

some times u se the term ‘process ’ i nformally , i n the sense explained in the previous paragraph .

Thus we wi l l use expressions such as ‘

interrupting a process ’ to mean that a CPU is diverted to

other act ivi t ie s be tween the execution of successive steps associa ted wi th a proce ss,

‘ s tart ing a

process ’ to mean that the CPU is forced to take on the state indicated by a s tate vector supplied

with the process identi fier , and‘ resuming a process ’ (presumably after an interrupt) to mean that

some CPU which was interrupted after the nth step of a process is now continuing execu tion from

the n+ l st step associated with tha t process . An Operating system is an example of a job using

multiple processes , whereas the majori ty of ( today’s ) applications consis t of a single process .

I n the discussion which fo l lows , the specia l set of pairs , processes , contains e lements of the form

where m is a mover and p a process be longing to m . The se t processes{m } consis ts of al l

active processes belonging to the mover m .

Let us firs t consider the case in which only a si ngle CPU is avai lab le . The spec ial variab le

C PUcontroI identi fie s the process control l ing the CPU ; the conten ts of C PUcontrol i s a lways a

member of the se t processes . The special se t state,which is indexed by members of processes ,

— 8

gives the envi ronment for each process . By the environment of a process,— w e mean all the

information necessary to define the path which execution of a process wil l take w hen the process

comes into control of the CPU . Detai ls of what is speci fied in an environment are machine and

implementa tion dependent , and may include in formation concerning the code block to be execut

ed,the next instruct ion within it to be execu ted , and the values of all variables accessib le to the

process,together wi th the pat tern of ca l l s effect ive a t a given moment

,e tor- EOr an e lement

se state ,environment ( s ) ex tracts the environment part o f s , and processpart(s) i den ti fies the

process described by s . The macros Ioctr, code , and pri v ilege ex trac t the components of an

environment which give the next instruc t ion to be execu ted , the string of b its which is the

execu tab le code wi thin that environment , and the privi lege class associated with tha t environment .

Process swi tch ing is achieved by changing C PUcontrol . (See examples and the simple

dispa tcher in for examples of th is , i.e . , for process swi tching by assignment to C PUcontrol. )Ordinary ‘

go-tos

’ are a part icu lar case of modifica t ions of state ; more speci fical ly , for a privi leged

process , the two statements

go to L ; and

have the same effect . The firs t i s s ti l l the prefered form ; the second is shown by way of explana

tion .

Control of Interrupts

Interrupt ion is a major communica t ion mechanism be tween parts of an Opera t ing system and

problem programs . General ly this mechanism has no counterpart in higher leve l languages,since

these languages are intended to describe simple , non-paral le l , deterministic a lgori thms .

In SETL , the standard flow of control i s from one statement to the next sequential statement , with

the exception of branch statements , i f sta tements ,‘while ’ and ‘

V’ i terations

,subprogram cal l s and

re turns . An interrupt is an addi t ional control mechanism which causes the flow of control to move

to a speci fic instruction in memory on the occurrence of a specia l event , such as an end of an I/O

operation , a machine mal function , the end of a measured time interval , or a rare side effect of an

instruct ion . I f there are severa l di fferent statements to which control may flow on interruption ,

depending on the condi tion which caused the interrupt , a l l the condi tions which cause control to

f low to the same statement wi ll be said to be long to a single ‘ in terrupt class ’ .

Two features are required to descr ibe an interrup t system . I t must be possib le to define the

process which i s invoked on the occurrence of particu lar i nterrup ts , and i t must be possib le to

inactivate the interrupt system .

We define a se t , interrupt , which consis ts o f a col lection of pairs of the form

where i nt speci fie s an i nterrup t class,and ‘

intprocess’ iden ti fies the process invoked when an

in terrup t of c lass int i s encountered .

‘

intprocess’ must be of an appropria te form to identi fy a

process , as described in A set resum e takes on the value which C PUcontrol had immediately

before the moment of interruption,and can be used to resume the interrup ted process , via the

simple statement :

C PUcontrol resum e ;

After an interrupt has occurred further detai l s concerning i t are contained in the variable cause ; the

_9_

value of this variab le shows all re levant interrupt-re lated information . Onl y privi leged Operating

sys tem code has access to the sets interrupt , cause , and resum e , which abstract ly represent the

hardware mechanisms which are direct ly associated with physical interrupts .

I n PSETL,the interrup t system is genera l ly act ive or enab led , so tha t in terruption is genera l ly

possib le . At certain moments , however , i nte rruption is into lerable , and computing systems

therefore contain ins tructions for disab l ing and enab ling the interrupt system under program

control . A sim i lar mechanism is required for PSETL . However , the PSETL in terrupt disab l ing

fea ture wil l be less genera l than that found on most computing systems , i n tha t i t wi l l not be

possib le to keep the computing system permanent ly disab led . This may cause minor inconv enienc

es in some cases bu t i t wi l l have the beneficia l property of making i t linguis tical ly impossible to

introduce a "bug which prevents the system from re-enab ling the interrupt system .

To thi s end we add to SETL a new semantic facil i ty , the disabled block , which has the form

(disab le) block ; end disable ;

The block of code in a disabled block is rest ric ted in the fol lowing ways

1. There may be no w hile i teration headers wi thin the block .

2. Only fow ard branches wi thin the block are a llowed .

3 . Branches out of the block end the disab led condi tion .

4 . Calls to user defined subroutines , or subroutine returns , end the disabled condi tion .

While in the disab led state , the process in contro l of the CPU is guaranteed uninte rrup ted control .

The restrict ions on the disabled block guarantee that a disabled process cannot permanently ho ld

the CPU .

In the case of a multi-CPU configurat ion , onl y one CPU may be in the disabled state a t a given

time . Attempted entry into a disabled block whi le another CPU is already disabled implies a wai t ,which is known to be fini te because of linguistic limita tions on the contents of a disab led block .

Thus , in PSETL , disab led blocks may be used to guaran tee integri ty of specia l se ts during their use .

I f the procedure executed as the re su lt of an interrupt begins wi th a disabled-block , no addi tional

interrupts can occur on that CPU until the end of the disabled-block . Fai lure to start an interrupt

act ivated process wi th a di sab led-block would a l low a second interrup t to overwri te cause and

resum e before the process activated by the first in terrupt can save them , thereby preventing proper

recovery from the first interrup t .

Private and Shared Data

Conventiona l SETL dis t inguishes between tw o types of variab les , loca l ly owned and externa l .

Loca l ly owned variab les are those which occur wi thin a subprogram and are not otherwise

declared . Local ly owned variab les can be referenced by name only wi thin the subprogram in

which they are defined , al though their values may be transmit ted between subprograms using the

standard SETL ‘cal l ’ mechanisms . External variables are explici t ly declared by use Of the SETL

include and global statements . External variab les may often be thought of as implici t arguments .

PSETL requires a third class of variable . Recal l that the notion of a process invo lves the further

notion Of ‘path of control of a CPU ’

. I t i s possib le that several pa ths of control should execute the

_10_

https://www.forgottenbooks.com/join

To faci li tate searchi ng a w orkset for an item satisfying a condi tion , macro is

provided . The value of this function is the firs t i tem x in j’

s w orkset satisfying the condi t ion C (x) .

To augment w orksets, we have the subroutine which makes y the successor of x

in j’

s w orkqueue (unless x i s no t in the w orkqueue, i n which case y becomes the last i tem) .

Simi larly , makes y the predecessor of x , or the first i tem if

We also introduce two other useful auxil iary functions by the informal defini tions

putfirst(j ,x) and

putlast(j ,x)

Various important notions connected with the overal l concept O f dedica ted computing system

portions will be represented in PSETL using a specia l se t ca l led facilities . An object x is a faci li ty if

if the test xe facilities i s true . The special set busy identifies those faci li t ies which are momentari ly

in use or reserved . The specia l set ho lds identifie s the fac ili ties whi ch are busy on behalf Of each

process . I f p e processes , then holds{p} is that subset of busy which is dedicated to p .

We also regard the pool of avai lable C PUs as an objec t wi th a w orkset. The w orkset associa ted

with the pool of C PUs contains a l l the processes which are ready to start or to continue to execute ,but which are not running because every CPU is engaged in other activi ty . The fol lowing line of

code may wel l serve as the fina l line of a dispatcher ( a routine which se lects the next process to be

executed and starts the CPU on that process ) :

C PUcontrol getfirst(C PU) ;

To ease the coding of the common opera ting system operation which de lays execu tion of a

subprogram unti l a reserved faci l i ty becomes availab le , a new form of subprogram is added to

PSETL . This i s the queued subroutine . A queued subrou tine is defined by a header of the form :

define qd on fac ;

This'

header i s dist inguished from the conventional SETL subroutine header by the keywords qd

and on and by the expression fo l lowing the keyword on. A queued subrou tine wi th the above

header is entered only when the cal ling program has exclusive contro l o f the faci li ty fac, which is

genera lly an expression in the arguments al , an .

Each queued subrou tine must use the labe l nonexistent in i ts body . Control passes to this label

in the event that n(face facilities) . I f face facilities, the subroutine i s entered as soon as fac is not

busy . At the moment of entry , fac i s made busy on behalf of the process invoking the queued

subroutine by adding fac to the se ts busy and holds . I t i s the process ’s responsibi li ty to re lease the

faci li ty when i t i s no longer needed by issuing the statement :

free fac ;

In addi t ion to the subrou t ine header shown at the beginning of this sect ion,the various o ther

funct ion defini tion forms which SETL provides , including infix , postfix and prefix forms , are

al lowed to have the obvious queued forms , too . Q ueued subprograms are invoked in the same

manner as conventional subprograms . Thi s frees the cal le r from concern wi th many detailed

synchronization activ it ie s implied by the use of facil i t ies .

Process Contro l

Among an opera t ing system ’s prime responsibi l i t i e s is the contro l of processes . Functions

belonging to th is genera l heading include process creat ion and termination , process suspension ,

and interprocess communicat ion . We sha l l now describe statements use fu l in support ing these

importan t functions . We point out tha t the operat ions described in this sect ion are avai lable only

to privi leged processes in PSETL .

Process Creation

The PSETL sta tement

spli t to s (e ) for p,;

i s used to begin a new process from the state 5 ; the new process is identified by processpart(s) ,

and execution begins a t The pair <p1.e> i s passed to this process through

i ts environment . The new process can extract the pair from its environment by applying

the posit ional macro initialv ar to i t s environment . Moreover , the posit ional macros‘ancestor ’ and

‘ info ’ re trieve p1 and e from initialv ar(s) . Thus , a process may identi fy the process which ini tia ted

i t by retrieving and i t may reference the information being

passed to it by re trieving

Process Suspension

A privi leged process may suspend i ts ow n Operat ion unti l a speci fied condi tion is met . The PSETL

sta tement

aw ait cond ;

causes the process which issued the aw ai t to test the condi tion cond , and i f i t is found to be false ,

to suspend operation unti l cond becomes true . I t is c lear that for the condit ion to change in value

other processes must be able to proceed during the suspension of the process which issued the

awai t . (Non-privi leged programs wi l l be provided wi th a simi lar capab i l i ty in the form of an

operating system service which is invoked by a standard Operat ing system request . )

Processes suspended by aw ait statements wi l l be saved in the special set w aitset. When a process x

is en tered into w aitset, i s se t up to re-evaluate the condition cond .

Interprocess Com m unica tion

A process may require the serv ices of a second process , even though in many cases the time at

which the services are rendered are notmaterial to the first process , which moves forward as soon

as the parameters for the second process are transmit ted . The second process , on the other hand ,

may a lready be occupied with another request . A PSETL statement , enqueue provides this li nkage

by using the w orkset for the second process . The PSETL statement

_ 13_

enqueue e on p2 for p l

enters the pair <p1,e> on pz’

s w orkqueue . The process pz must be wri t ten to examine i ts

w orkqueue for addit ional requests each tim e i t finishes servicing a request . See example

Process Term ination

A process can terminate i ts execution by execu ting the PSETL statement

This causes al l faci li t ies held by the process to be free ’d , and its w orkqueue to be purged .

A process can force the termination of a second process by execu ting the PSETL statm ent

kill P2;

General ly,the issuing process must have at least as high a level of privi lege as the process itki l ls .

As on the execu tion of a term statement , the kill’

d process ’s w orkqueue i s purged , and facili t ies

he ld by itare free’d .

Exam ples

The fo l lowing trivia l routine , which we wil l use frequently in thi s work , can be cal led to

delay a process until a facili ty x can be secured :

define qd reserv e(x) on x ;nonexistent : return ;end ;

D1jkstra [Di68] defines P and V Operat ions for process synchronization using semaphores ,which are initial ized to O or 1.

"A process , 0 say , that performs the operation decreases the value of the semaphorecal led ‘ sem ’ by 1. I f the resul tant value O f the semaphore concerned is non-negative , process 0can cont inue wi th the execution of i t s next sta tement ; i f , however , the resu l t ing value isnegative , process 0 i s s topped and booked on a wai t ing l i s t associa ted wi th the semaphoreconcerned . Unti l further notice (i.e . a V operation on this very same semaphore ) , dynamicprogress of Q i s not logica lly possible .

A process ,‘R ’ say , tha t performs the operation increases the va lue of the semaphore

ca lled ‘ sem ’ by 1. I f the resu l ting va lue of the semaphore concerned is posi t ive,the V

operat ion has no further effect ; i f , however , the resul t ing value of the semaphore concerned isnon-posi tive , one of the processes booked on its wai ting lis t is removed from this wait ing li st ,i.e. i ts dynam ic progress is again logical ly possible .

"

I n PSETL , wi th the understanding tha t semaphore variab les are faci l i t ie s , tha t semaphores

ini tia lized to O are busy , and that sem v al i s a map from semaphores to their values,we can express

the P and V operations by :

define P (sem ) ; shared sem v al ;

(disab le ) - 1 i s news ;i f news ge 0 then sem in busy ;

_ 14_

e lse reserv e(sem ) ;end if ;

end disable ;end P ;

define V (sem ) ; shared sem v al ;

(disab le ) is news ;if news le 0 then free sem ; ;

end disable ;end V ;

Clearly,i f one mere ly desires to synchronize processes , without requiring that a count of delayed

processes be kept explici t ly by sem , our dic t ions are rich enough to a l low for

and for The number of de layed processes can always be computed

by

A more complex example : Le t d be a se t a l l of whose e lements are faci l i t ies . I f al l

e lements of (1must be secured before a process can continue , one can simp ly i nsert the code

(Vface d ) reserv e( fac)

at an appropriate posi tion . The above code achieves reservations one at a time . On the other

hand , i t may be preferable to se ize each device as soon as i t becomes avai lab le , since i f one fol lows

any part icu lar sequentia l order , devices avai lable a t the s tart of the sequence but required later may

be preempted by another process by the time an at tempt i s made to re serve them . A paral le l

reservation s trategy must sure ly be at least as fas t as the sequentia l approach,and may be wri t ten

in PSETL as fol lows :

w = new at;

(Vfaced) spl i t to forC PUcontrol”

awai t #processes{ w }eq 0;

S: i s(disab le )i in holds ;

out holds ;term ;

end disab le ;

Reca l l tha t is a pair where p is the process which spawned

the reservat ion processes , and fac is the faci l i ty to be reserved . The s tatement S reserves the

faci l i ty fac on behal f of the proce ss q execu ting S; the fol lowing disabled block swi tches the

reservation to the process p to avoid the reserva tion being lost when term i s execu ted by q .

A final example : Let us sketch a simple output rou tine which accepts a single string of

characters as inpu t and prints the string using embedded er characters to deduce where the lines

start . We assume that the routine i s invoked by

enqueue str on printer for C PUcontrol ;

where printer identifies the process associa ted with the program to be given below . The advantage

15

to the call ing program is that i t can proceed immediately after the enqueue regardless of the work

already scheduled for the prin ter or the time physica lly required to prin t the st ring .

output : await #w orkset{printer} ne 0;str = info(getfirst(printer) )i= 1:(while str(k) eq er) doingprintout str( jzk-j ) ;

end while ;go to output ;

The first s tatement causes ‘outpu t ’ to wait un ti l (or unless ) there i s work stacked on its w orkqueue,

and the second statement extracts the next string to be printed from the w orkqueue. The remain

der of the code shown above is straigh tfoward SETL ; we assume that‘pri ntout ’ i s a more primitive

routine which prints i ts argument on a new line , le ft adjusted , on a printer .

A RemarkConcerning Machine Dependent Features and PSETL

The PSETL features introduced in section al low the desription of a good port ion of opera ting

sys tems . At some stage , however , we wi l l wish to stop hiding crucia l underlying detai ls by

l ingui st ic facades , and to face them . Some (but not al l ) of these underlying detai ls are machine

dependent . Those which are not we may subsequently wish to describe in additional detai l ; of

course deta il s which are highly machine dependent we exclude as be longing to a different type of

discussion . Thus,for example , a read verb in PSETL describes an i nput action , and presumably is

trans la ted in to a cal l on a standard I/O package . I f we wish to describe the I/O package in

PSETL , we are u l t imately faced with the necessi ty of issuing I/O instruct ions which carry out the

read, a task which cannot be circumvented by using another PSETL read . Such ult imate levels of

machine dependence can only be handled by the use of primit ive machine-leve l subprograms or by

specia l bi t pat terns or other data object s whose signi ficance must be described in English and

coded in a lower level language .

The specia l sets , interrupt and cause , are addi t ional examples of features of PSETL whose inner

detai ls are so machine dependent that de tailed defini tion is left to the actua l system implementer .

In our PSETL discussion we may assume certain d ist inc t in terrupt classes,and some particu lar

manner in which the information describing the circumstances of the interrup t is posted,but we

shall not describe the machine-level mechanisms which cause this to occur .

Tim e and C locks

We assume the exis tence of two specia l global in teger variab les,tim er and clock . The variable

clock is incremented by one au tomatica l ly by the hardware every n microseconds,where n is a

hardware dependent parameter . We further speci fy that clock is read-only , i.e . ,tha t storage

operators applied to clock have no effect . By reading a message from the Operator ’s console giving

the real tim e , clock can then be used to compute the real time at later points in t ime .

The vari ab le t im er may be accessed by fe tch or store opera t ions . Whenever the clock changes

value and matches (or exceeds ) the value in tim er , a tim e interrupt occurs .

— 16

Input/Output

The SETL inpu t/outpu t s tatement forms shou ld be viewed as subprogram cal l s,for the

”statements " (or instruct ions ) which perform the physical inpu t/outpu t operations are privi leged

instruct ions . Even the subprograms which interpre t the SETL I/O cannot use the physical I/O

in struct ions of the computer direc t ly ; they must use the services of the opera ting sys tem to

interpre t more primi t ive I/O opera tions than the ones supplied by SETL .

A sample se t of such opera ting system services in described in sect ion and used in all the

sample operating sys tems of Chapters I I I , IV , and V . I n addi t ion , the uniprogram m ed operating

system of sect ion shows in detai l how the operat ing system interpre ts I/O .

When the Operating system interpre ts the requests for I/O , i t must eventual ly speci fy physical I/O

operations . These operations are highly machine dependen t , and often require observing timing

constra ints . We therefore do not at tempt to specify in detai l how the physical I/O i nstructions

should be represented in PSETL ; however , for the sake of describing that port ion of the operating

system which interpre ts inpu t/outpu t reques ts , we wi l l u se the fo l lowing s ta tement formats to

specify physical I/O (which requ ires no further in terpre ta t ion except by the hardware )

1. Read operat ions are coded

where d spcifies a physica l I/O device , and‘command ’ i s a s tructure which speci fie s the

location and size of the block of main memory to be read into .

2. Write operations are coded

wri te

3 . Simple control operations are coded

where d is a device , and‘op ’ i s an operat ion such as rewind

,or backspace . For positioning

Operations , such as disc-seeks , we write :

where c speci fied the cyl inder position to which the read/wri te head is to be moved .

The reader disturbed by the vagueness wi th which physica l I/O i s treated here may be consoled by

the fact that physical I/O wi l l not be used extensive ly i n the opera ting system examples which

fol low in later chapters . With the excep tion of the sect ions of code iden ti fied as"Moni tor

Services " at the end of the code of sect ion the operating system itse l f uses ei ther SETL

or the monitor services described in section

DetailedAccount of the Elem ents of PSETL

I n this sect ion , the fea tu re s o f PSETL summarised in sec tion are described in deta i l . Our

descrip t ion is arranged in to three headings : special se t s , new prim i t ive operations, and m acro

opera tions . I n the case of macro operat ions , possib le expansions in terms of SETL using the

special set s and new primit ive Operat ions are given in order to il luminate the mechanisms involved ,

al though the actua l implementat ion is part ly immateria l,s ince such macros are designed to be

thought of as primit ive .

_ 17_

In giving prototypes of PSETL statements , we wil l use symbols in the following standardized ways

fac represents a facility ,represent e lements of processes ,

m represents an element of m ov ers,

n identi fies a path of control for a mover ,

represent states ,represent interrupt c lasses ,represent system objects having w orksets,

arlrepresent arguments to subprograms or processes ,

v n represen t names of variables ,

L and M represent compiler generated labels .

The table which fo llows shows where the descript ion

infoinit ia l ly

-11 initialv ar

2-4-1-7 insertafter2-4 insertbefore

1

gym "

1 m

‘

2 4 3 5m ov erpart

moversprivi legeprocess swi tching

Processes

processpart

Special Sets

m overs

Elements : SETL ‘blank atoms ’,used as identi fiers for independent jobs .

Uses : To identify independent jobs .

processes

Elements : pairs of the form <m ,n> where m em ov ers, and it identifies a process for the mover m .

Uses : For m em ov ers, processes{m } identi fies the set of processes associated with the mover m .

The elements of processes are the processes in progress under control of the operating system .

state

Elements : pairs of the form <p ,e> where peprocesses, and e is the environment associated with

the process p .

Uses : For pe processes, state(p ) determ i nes a l l the control information , or environment , concern

— 18

each PSETL feature wil l be found

putfirst

putlast

24 3 3 queued subprogram“3 7 readfirst

removereserveresumeh d 2 4 2 4S are

termtimerw aitset

w orkset

https://www.forgottenbooks.com/join

w aitset

Elements : A collection of processes suspended awai t ing a condi tion to be satisfied .

Uses : For xe w aitset, execut ing C PUcontrol = x; te-evaluates the awai ted condi tion for the process

x,which after this evaluation will either begin to move forward , orwill resume its wait .

facilities

Elements : Seri a l ly te-usable system objects , such as devices , variables or subprograms .

Uses : The elements of facilities may be rese rved by processes , via use of queued subprograms . I f

xe facilities and xebusy, then x has been reserved by a process . For objects in facilities , the use of

queued subrou tines and the free s tatement provides automatic management of the objects ’

w orksets, and synchroniza tion of processes wi th the avai labi l i ty of faci l i t ie s designated i n the

queued subprogram header .

busy

Elements : members of facilities

Uses : xe busy implies that some process is using the faci li ty x .

holds

Elements : pairs of the form <p,fac> with p eprocesses, and face facilities.

Uses : <p,fac> eholds implies that the facili ty fac i s busy on behalf of the process p .

clock and tim er

Elements : Each of these va ri ab les is an integer .

Descrip t ion : clock is automatica l ly incremented by 1 every n microseconds by the hardware

(where n is a machine dependent cons tant ) . A timer in terrupt i s genera ted by the hardware

whenever the clock becomes zero or clock changes value and matches or exceeds tim er .

Uses : By using input from an external source,one can corre late a value of the clock wi th real time ,

and thereafter use clock to determine by program the time in the outside world . tim er can be se t to

cause an interrupt at a predetermined time .

Primitive Operations

disabled b lock

Statement form : (disab le ) block ;Description : Whi le executing ‘block ’

, the inte rrupt mechanism is disab led . I f there are multiple

C PUs, only one may be disabled at a t im e ; indeed , the entry of one CPU into a disab le block

temporari ly suspends the activi ty of a l l o ther C PUs which at tempt to en ter di sab led blocks .

While-i tera t ion headers and backward branches are syn tact ic errors wi th in a disab led b lock .

Branches out of the block , re turns , or invocations of user defined subprograms end the disabled

condi t ion .

_20_

initial block

Statement form : initially block ;Description : On each process ’s first entry to a subprogram , the

‘block ’ i s execu ted . To effective ly

execu te the i ni ti a l b lock only once regardless of the number of unique processes execu ting the

subprogram,use a shared vari ab le to dist inguish between a first and subsequent uses of the

subprogram .

process sw i tching; the special variab le‘C PUcontrol

’

A CPU is directed to swi tch processes by assignment to the specia l vari ab le C PUcontrol. The

assignment C PUcontrol = s; causes the process 5 to contro l the CPU start ing at and

to opera te in the privilege c lass If a process p re linquishes contro l of the CPU

as fo l lows :

C PUcontrol : x ;

then i f another process i ssues C PUcontrol = p ; , then p resumes execution at the statement labe l led

L in the above program fragment .

shared variab les

Statement form : share v 1, v 2, v n ;

Description : Variables declared in a share statement and owned by a subprogram have only one

instance in storage , regardless of the number of distinct processes executing the subprogram . Such

variab les,especial ly if global , may be used to communicate between subprocesses . For variables

not declared as being shared , a unique value exis ts for each process execu ting the subprogram .

Macro Operations

aw ai t

Sta tement form : aw ai t cond ;Description : The privi leged process issuing an awai t cont inues execution i f the boolean expression

cond is true ; otherwise i ts execution is suspended unti l cond becomes true .

Expansion

i f not cond then(disab le )

C PUcontrol in w aitset;

C PUcontrol = dispatcher;

end disab le ;(disab le )

isok= cond ;

CPUcontrol = dispatcher;

end di sab le ;end if ;

_21_

The expansion works in cooperat ion w i th the operating system ’s dispatching process , which , in the

above code is identif ied by the name ‘dispatcher ’ . The variab le ‘

isok ’ transmits to the dispatching

process the recomputed condition . A sim p le dispatcher is

getw ork: w aitcopy = w aitset;

loop : if w aitcopy ne ulthen s from w aitcopy;

/ * recompute condit ion“

C PUcontrol = s;

if isok then 5 out w aitset;

e lse end if ;go to loop ;

end if ;/ *if w aitcopy eq ul then */

if 5 eq S2 then go to getw ork: :

C PUcontrol = s; gi ve control of CPU to chosen process*/

go to getw ork;

Notice in the fifth line that execu t ing C PUcontrol = s; causes contro l to flow to

which is where the condi tion cond is recomputed int he above expansion for aw ai t . I f the condition

is still not sat isfied , is reset to recompute cond . Otherwise the process 5 will proceed

beyond the aw ait when i t next receives control of the CPU . A fter the dispatcher tests all awaited

condi tions , and moves processes wi th sat is fied condi t ions to the C PU’

s w orkqueue, The firs t

e lement of the C PU’

s w orkqueue is selected as the next process to run, unless the CPU w orkqueue

is empty , in which case the dispatcher re-examines the unsat isf i ed conditions . Since the dispatcher

is enabled , in terrupt response is poss ib le and may resu l t in one of the condi t ions becoming

satisfied .

One may wonder whether a dispatcher can run enab led" The sample dispatcher will work

correct ly together wi th the above expansion of aw ai t . An inte rrupt during the running of the

dispatcher will be handled , but a process whi ch enters a wai t condit ion as the resul t of such an

inte rrupt having been processed will not be considered for resuming operation until the next time

the dispatcher executes the statement at ‘

getw ork’

. On the other hand , in hand ling certain

in te rrupts , an urgent process may be put at the head of the C PU’

s w orkqueue, and thus be

dispatched before any of the processes which were under considera t ion at the time that the

dispatcher was started .

queued subprogram header

Statement forms

( 1) define qd name (a1, an) on fac ;

(2) definef qd name (a1, an ) on fac ;

(3 ) inf ix, prefix and postf ix forms of the above

Descript ion : Entry to the subprogram ‘name ’ is comple ted only when the facility fac is availab le .

While fac is busy for another process,the calling process is queued on fac . When control reaches

the first user-coded statement in the subprogram, face busy and It i s

_22_

the responsibil i ty of the cal ling process to eventua lly re lease the facil i ty when no longer needed . A

queued subprogram must include a sta tement labe led ‘nonexis tent ’ to which control wi l l flow in the

event that fac is not a faci li ty .

Expansion

define name (a ,, a n ) ;i f n( face facilities) then go to nonexistent

“

(disable )i f fac e busy then

CPUcontrol = dispatcher;

fac in busy ;<C PUcontrol,fac> in ho lds ;

end if ;end disable ;end if ;

Note : The e lse-c lause i s necessary to make fac busy to other processe s . Remember that the

queued subrout ine performs control funct ions which ordinari ly are assumed by the use r to be

performed by an operating system ; the queued subroutine is used to construct an operating system .

The ‘ reserve ’ subprogram of section is an example of a queued subprogram . I t is used to

delay a process unti l i t ’s argument , a faci l i ty , i s not busy and can be reserved .

free

Statement form : free fac ;

Descript ion : The faci li ty fac is re leased by the process which issued the free . fac is removed from

busy unless another process is enqueued on fac , in which case tha t process is activated and the

faci l ity reserved for tha t process .

Expansion

(disab le )

<C PUcontrol,fac> outholds ;i f v = 12 thenfac outbusy ;

< v ,fac> in holds ;

Note : The above expansion assumes that the w orkqueue for fac is empty if fac i s not busy . To

guard against o ther code viol at ing thi s assumption,the ‘ el se b lock ’ above should inc lude the

statement : fac in busy ; .

_23_

split

Statement form : split to s (e) for p l ;

Description : I n the above statement , 8 i s a state variab le , such that processpart(s) represents a

new process,p . A new process i s created as follows : p is added to processes , the pair <p1,e> is

stored in p’

s environm ent in such a manner that i t can be retrieved by s

is added to the set state,and an entry is made on the C PU ’

s w orkqueue , indicat ing that the process

p is ready to use the CPU .

Expansion

(disable )m ov erpart(processpart(s) is p) in m overs ;p in processes;8 in state ;

end disab le ;

The fi rs t of the above s ta tements wi l l be a no-opera t ion whenever a new process i s being

created for an already existing mover . When the process being initia ted be longs to a new mover,

the firs t statement insures that the new mover i s a member of m ov ers.

enqueue

Statement form : enqueue e on p for p l ;

Description : The pair <p l ,e> i s p laced at the end of p’

s w orkqueue . Upon adding the pair to p’

s

w orkqueue, the process which execu ted the enqueue is free to cont inue execution . A process

which services enqueued reques ts wil l , upon becoming id le , general ly suspend i ts Opera tion for

later resumption by wai ting for it s w orkqueue to become non-empty . See example

Expansion :

process termination

Statement forms

Descript ion : The process identi fied by p is terminated ; i tems already stacked by i t on other

w orkqueues are e liminated , facilitie s held by i t are re leased , and i ts w orkqueue is dropped . The

statement term ; i s equivalent to kill C PUcontrol; and is used by a process to te rminate i ts ow n

execution .

Recall that e lements in w orkset are of the form where s ident ifie s the i tem on whose

w orkqueue the e lement belongs , p represents the process which has enqueued the request in s’

s

w orkqueue, and r are the arguments being passed by p to s . Thus , i tems in w orkset{s} are of the

form <p ,r> and ancestor(y) for ye w orkset{s} i s a process ident if ier . Thus , the first statement

—24

removes al l i tems enqueued by the process being ki l led,whereas the third s tatement ,

destroys the i tems enqueued for the process being ki lled . A possib le variant to

thi s expansion wou ld recursive ly ki ll the processes which had enqueued work on processes being

kil led .

Expansion

(disable )(Vobjectsehd[w orkset] , Vprocse w orkset{objects} I ancestor(procs) eq p)

rem ov e(objects,procs)end Vx;

free faC ”

p outprocesses ;i f eq 0 then

m ov erpart(p) outm overs ; ;i f processpart(state) eq p then

/ *This i s the case when term i s be ing executed . Having removed a l l objects fromqueues associated with the terminating process , the process removes itse lf from thesta te set , and gives contro l to the

<C PUcontroI, state(C PUcontrol)e lsecontrol continues to the next sequentia l

end i f ;end disab le ;

queue m anagem ent subprogram s and m acros

Statement forms

getfirst(j ) ;

putlast(j ,x)

readfirst( j )

rem ov e(j ,x)

Descript ion : The function readfirst(j ) re turns the first e lement on object j’

s w orkqueue . I f there

are no elements on the w orkqueue ,then rem o v e(j ,x) wil l remove x from j

’

s

w orkqueue i f x is present , i n such a manner that the FIFO orde ring of the remaining enqueued

i tems i s preserved . The function getfirst( j ) combines the act ions of readfirst and remove , by

re turning the first i tem on j’

s w orkqueue and removing the item from the queue .

The subrou tine makes y the successor of x in j’

s w orkqueue i f x i s present ;

otherwise y becomes the last i tem in the w orkqueue . Simi larly , makes y the

predecessor of x or the first i tem in the queue . The special cases of adding to ei ther end of a

w orkqueue are handled by putfirst and putlast, which can be defined by :

define re turn”

define re turn “

_25_

The macro sets x equal to the first i tem in j’

s w orkqueue sat isfying the condition

C (x ) .

These subprograms have rout ine SETL expansions defined by whatever logica l structure is chosen

for the w orkqueues. The only PSETL considerat ion that a rises i s that these subprograms will have

to be be disab led to prevent o ther processes from modifying the w orksetwhile getfirst, putlast, and

remove are in operat ion .

positional macros

Forms

processpart(s)

environm ent ( s )

priv ilege(en)

loctr(en)

code(en)

initialv ar(en)

ancestor(x)

info(x)

m ov erpart(p)

Description : Once a specific st ructure for state has been chosen , the first two macros , to be used

on objects wi th the same structure as state , extract the process portion and environment port ion of

the ir arguments , respective ly . I f for example , state is a pair, we cou ld use the conventions

and

privilege , Ioctr, code , and initialv ar app ly to objects wi th the same structure as an env ironment . I f

en has the structure of an environment , then priv ilege(en) extracts the priv i lege port ion of en ,

loctr(en) extracts the location port ion of en , and initialv ar(en) extracts the pair <p ,e> from en ,where p is the process which ini tiated the process having en as an environment , and e is initializa

tion information passed by p to that process . code(en) ex tracts the s tring of bi ts which is the

executable code within the environment en .

ancestor(x) and info (x) apply to objects of the form occuring on w orkqueues, and respective ly

reference the process which p laced the object on the w orkqueue, and the request being transmit ted

through the w orkqueue . These macros are also applicable to objects re trieved by the initialv ar

macro .

m ov erpart(p) ex tracts , from a process identi fier p , the identi ficat ion of the mover to which it

belongs .

O ther Proposals forHigh Level Language Operating System Primitv es

Dijkstra [Di65 ] , Hoare [Hoa] , and Brinch Hansen [B ] propose severa l dictions for coordinating

para llel processes ; all of these dictions are included in Brinch Hansen ’s book . A comparison of

these dictions wi th those of PSETL follows .

The notation [Hoa, b ] ,

https://www.forgottenbooks.com/join

free v ;v in holds{CPUcontrol} ; / *This statement wil l make i t possilbe for the condi t ion B inthe next statement to be evaluated . B involve s the "vari ab le v , i n the mannerde scr ib ed i n the d i scu s s io n above on cr i t i ca l reg ion s , and un l e ssv eholds {C PUcontrol} , the reference to v (c. f. above ) would be invalid . Yet havingfree’d v

,i t i s availab le to other processes . Once B holds true , the reservation must

must beaw aitB ;v outholds {C PUcontrol} ;go to R ;

end if ;

free v ;

gives the same effect as BrimchHansen ’s

region v do begin aw ai t B

PSETL’

s w orkset can be used to create ‘message buffers ’ [MMc, B ] of a kind described by

Brinch-Hansen . Our w orksets are not specified to be of a-priori l imited capaci ty ; getfirst, putlast,

e tc,would have to take the fini teness into account by using aw aits in the event that the w orkqueues

were ful l .

The genera l semaphore [Di65 ] has already been shown in example to be real izab le in

PSETL . For binary semaphores , the P operat ion is simply the PSETL and the V

operation ,‘ free

BrinchHansen observes that each of the synchronizing mechanisms , semaphores , message buffers ,

cri tica l regions , condit ional cri t ical regions , and event queues can be realized in terms of any of the

other mechanisms of thi s l is t ; however , i t i s only more convenient and natura l to use the various

mechanisms in different si tuat ions . Thus , once the semaphores were shown to be expressib le in

PSETL, i t is not surprising that the other synchroni zing dict ions cou ld be realized in PSETL , too .

Guarantees that a V( sem ) w ill be issued , or tha t a cri tica l region wi l l terminate execu tion are

lacking , al though their need is acknowledged [Hoa , B ] . The cri tica l region , (except for i t s lack of

guaranteed fini te execu tion ) i s an easy and natura l d ic t ion to use in a s tructured programming

language . There is also some danger of deadlock with nested cri tical regions .

The PSETL primitives were chosen to be closer to capabi li t ies of contemporary computers . The

aim was to specify in PSETL process synchronizing dict ions . Thus , the Operating system designer

can speci fy i n detai l i n PSETL, how the synchronizing mechani sms are to be real ized on his

machine .

In the short examples given in the texts of [B ] , [Hoa] , and [D165 ] , the use of paral le l processing

dictions are easily comprehended . However , no large body of code comparab le to the systems in

Chapter I II and Chapter V are given ; thus one cannot compare the readabi l i ty of PSETL with , say ,Pascal [W7 1] augmented by para l le l processing p rimi t ives .

_23_

Donovan and Madnick [DM] do present a complete operat ing system in code , al though it is wri t ten

in assembly language for the IBM System/370. The Dijkstra semaphore is used as the synchroni

zation mechani sm in this sys tem . I n the code given by Donovan and Madnick,the P and V

Opera t ions are physica l ly c lo se enough so that the reader may eas i ly convince himse lf tha t the

critica l sections between these operations have finite execu tion tim e . The code suffers from the

usual assembly language di fficul t ie s : opaqueness of data structures , a mass of detail s imposed by

the language ( in part icular , the appearance of the USING pseudo-in struct ion , whose correctness i s

di fficu l t to ascertain ) , e tc .

-29_

Chapter III

A Sim ple Operating System

I n this chapter , an opera t ing systems will be presented in a fair amount of deta il to i l lustrate

various control mechanisms and mappings commonl y used in operat ing systems , and to make v ivid

the many detail ed design al te rnatives which ari se and must be resolved before an operating system

can actually be implemented . Some machine dependent detail s will enter ; care wil l be taken to

distinguish between these and operating system aspects which are machine independent .

System Objectives

The operat ing system to be presented here i s in tended to run on a single CPU configurat ion

opera ting in a non-in teractive environment in a uniprogram m ing mode . The system to be

presented wil l typify many of the more advanced ‘ second generation ’ systems , as wel l as small , less

ambi tious ‘ thi rd generation ’ systems . In the context of thi s discussion ,‘non-i n teractive ’ wil l be

taken to mean that the system al lows the running of jobs submi t ted by users at the computer

instal lation,but only wi thout assis tance from the user du ring execution . Thi s means tha t al l the

data for the run is avai lab le when the job is submit ted and that the only operat ional decisions

which the user can make are those which he has preprogrammed into his programs orwhich he can

express in a job contro l language .

‘

Uniprogramm ing’ wi ll be taken to imply tha t onl y one user run is in execu tion at a t ime , and that a

user job runs to complet ion without the CPU being tempora ri ly diverted to other user jobs . By‘user job ’

, we mean just the code submi t ted with the job . Indeed , there wi l l be housekeeping to be

performed for each job before and after i ts execution , and this housekeeping wil l be multiprogram

med with the running of other jobs . Note that a designer may be constrained by a small main

memory to implement a uniprogramm ed design . I ndeed severe memory limi ta t ion can make i t

di fficu l t to spare the extra space needed for mul t iprogrammed contro l , and can also make i t

unlike ly that several jobs wi ll fi t into “main memory concurrent ly .

The constra in t to uniprogram m ing which we begin by assuming limi ts the degree to which

hardware u tilization can be optimized . A list of reasonable objectives for a uniprogram m ed system

are : to m inimize job-transi t ion t imes, to al low jobs to be assigned priori tie s which influence the

scheduling scheme , and to provide l ibrary faci l i t ies for programs and data . Jobs wil l be processed

in the order in which they are submit ted , perhaps wi thin priori ty c lasses . The only exception to

th is FIFO scheme wi l l be to uti l ize device mounting t ime , during which the highest priori ty

avai lab le job whose est imated running time is less than the expected mounting time , i s run .

Users wi l l be a l lowed and required to reference inpu t/outpu t devices symbol ica l ly . Severa l

advantages resu lt from such addressing . I f severa l devices of a given type are provided with the

computing system , a job which requ ires a subset of these devices can run whenever a sufficient

number of devices are available ; with absolute referencing , a speci fic subse t must be avai lab le . In

the case of temporary fi les , a variety of devices may be apropos , and symbolic addressing pe rmits

the job to run if any such device i s avai lab le . Furthermore, prem ounting of devices while a job

-30_

using the same class of devices i s running is made possib le by the flexib ility of symboli c referenc

ing .

From the users ’ poin t of view , a s im ple job control mechanism is an important objective . When

the computing system is used in perfect ly typica l ways , m i nimum control specif i cation should be

required from the user . To thi s end , defau l t va lues should be estab li shed for most job descript ion

parameters,moreover , i t should be possib le for each user to establ ish the defau lt values ta ilored to

his personal needs .

Job Control Language 1

Job control language is used to describe various aspects of a job to the operating system,such as

the job ’s est imated running t ime , the fi les i t requires , the parti tioning of the job into steps , and the

dependence of a job step on previous steps . Four types of contro l s tatements wi l l be used by'

our

operating system : a job sta tement to identi fy a job , a job-s tep statement to iden ti fy subsections of

a job , a data fi le s ta tement to ident ify and describe fi les needed by the various job steps , and an

end—of-data sta tement to mark the end of data fi les which are included with the job . These job

control s tatemen ts are part of a language in the sense tha t they a l low communica t ion of the

operat ional characteris tics of a job which would have to be given to an opera tor if there were no

operating system .

Job control language statements , or JCL for short , are imbedded in the sta tements and data which

comprise the job . The general s tructure of a job consists of a job sta tement , fol lowed by severa l

job s teps . Each job step consi s ts o f a job s tep s ta tement , data fi le s tatements , data , and an

end-of-data sta tement .

Each JCL sta tement o the r than an end-o f-data s ta tement wi l l be represen ted by a SETL se t

(which we wi l l use as a mapping)

where st i s a string representing the statm ent’

s labe l , 0 i s a st ri ng identi fying the JCL statement

type , are names of subfie lds , and are parameters associa ted wi th the subfie lds

With the excep tion of the end-of-data sta tement , each type of JCL statement contains severa l

subfie lds which convey in formation . Many of these subfie lds are optional , i n that they are not

mandatory in every use of the JCL sta tement . To make the identi fica tion of subfie lds easy , each

subfie ld wi ll have the form

<snam e,info>

1 The job contro l language for thi s operat ing system is patterned after the job control language

for IBM

_3 1_

where suame is the name of the subfie ld and info is the information being transmit ted in tha t

subfie ld . For example,to estimate 5 minutes running time on a job statement , the subfield

would appear in the statement . Because the subfie lds are identif ied by name , their order in a JCL

statement i s imm aterial .

Descriptions of how to code the various JCL statements fo llow . These detai led descript ions wil l in

fact describe to a great extent the se rvices which this operating system offers i t s users .

The Job S tatem ent

The form of the job statement is

In the above prototype , nm i s a name attched to the job, and are n subfie lds . The subfie lds

which we al low wi l l be representa tive of the informat ion which can be transmit ted in the job

statement in most systems , al though the more e laborate systems al low for a l arger varie ty of

speci fications to be given .

The NAME Subfield

This parameter is-used to identify the user responsible for the job . I t must match one of the names

of valid users stored in the opera ting system . The name parameter i s the only required parameter

on the job statement . A comma or a blank ends the name subfie ld . An example of a val id job

statement is :

The TIME Subfield

This parame ter gives the est ima ted CPU running time for the job . I f thi s time el'

apses during

execution , the operating system will automatical ly terminate the job . The TIME speci fication is

given in units of minutes :

where x is a rea l number representing the number of minutes est imated for the job ’s running time .

The PRIORITY Subfie ld

This parameter is used to determ ine in which priori ty class the job is to be placed for scheduling of

the CPU . There are 10 classes , denoted by the integers 0 through 9 ,class 9 having the highest

priori ty . I f not specified , the priori ty class i s taken from the user profil e ; i f speci fied , the priori ty

_ 32_

used is the lesser of the speci fied priori ty and the maximum allowable priori ty for the user as given

in the user profile . A sample use is :

The Job-Step S tatem ent

The form of the jobstep statement is

In the above pro totype , um i s a name at tached to the jobstep . The fo l lowing subfie lds are

recognised :

The PROC Subf ie ld

This subfie ld identi fies the data fi le which conta ins the program to be execu ted . I f the data file is

a lready catalogued by the system , no fur ther informat ion is requi red ; otherwise , a data fi le

sta tement for the fi le must be given in the JCL for this job step . An example of a valid job step

sta tement i s :

which causes fi le a lpha to be loaded and run .

I f severa l fi les are to be loaded , thei r names are given as a tup le , e .g .

The PROC Subfie ld

This subfield identi fies a data fi le which contains JCL for one or more job steps to be execu ted .

Use of PRO C s ( short for procedures ) enables l ibraries o f JCL to be bui l t up and reduces the

amount of JCL a user must supp ly himself . I f , for example ,‘

SETL’ i s the name of a fi le of JCL

statements to invoke the SETL compi ler , the data for a SETL compi lat ion could be preceeded by :

PRO C s may be thought of as JCL macros . An EXEC statement must have ei ther a PROC

subfield or a PROG subfield , but not both .

The PARM Subfield

This Optional subfie ld passes a tup le of parameters to the job step . I t is coded

_3 3

The main program of the job step can re ference one argument , which will be the paramete r

PARM .

The COND Sub fie ld

This optional subfield is coded

r ,n>>

where r is an ari thmetic re lational operator and n is a po si t ive integer . If the imm ediately preceed

ing step returned a resul t x to the system , and the re lation x r n is t rue , then this step is executed ;

O the rwise the job is te rminated I f the COND subfie ld is not given , the defaul t is‘

ne A sample

job step statement using the COND subfie ld is

The TIIVIE Subf ield

This op tional subfie ld is coded exactly in the same form as the TIME subfie ld for the JOB

statement . I f TIME is used for a job step statement , the maximum time allowed for the step is the

minimum of the TIME sub fie ld for the step and the tota l time remaining for the job . If time runs

out for the s tep , the step is te rminated , and the job proceeds with the next step . If TIME is not

us ed , the step is allowed the total t im e remaining for the job .

The Data File S tatement

Before giving a deta iled descript ion of the data fil e s tatement , i t is necessary to discuss the various

fil e-name spaces which we suppose to exis t in our computing system . At the physical leve l , names

re fer to inpu t/outpu t devices at tached to the computing system , and to dismountab le volumes ,

such as tape ree ls or disc packs . To physically address a fil e on permanently mounted storage , one

must specify the hardware address of the device on which the file is stored . To physically address

a file on dismountable storage , first the vo lume on which the file resides must be specified ; then an

appropri ate device on which the volume can be mounted must be specified . Once the mounting

has been accompli shed , i t suffices to address onl y the device on whi ch the vo lume has been

mounted .

For the user , i t is more convenient to associate names with file s in a hardware independent and

volume independent manner . In the case of dismountable storage , i t is not to the user’s advantage

to permi t him to specify on which of several identical devices to mount his volume since this would

prevent his job from running when the specif ied device type is availab le , but the specif ic device is

not.

The system catalogue provides a map from the user file name space to the physical s torage address

space . Physical addresses may be of several types , some of whi ch identif y the volume on which the

file resides , identif y the areas on the volume allocated to the file , identify the unit on which the

- 34

https://www.forgottenbooks.com/join

3 . The data is included in the job being submit ted . In this case , an aste risk is used as the user file

name , and the data follows the defining FILE sta tement , e. g .

See for the end-of-data Specif icat ion in thi s case .

While a user 11 may give a file the name x , the file is known wi thin the system as In'

this

way , two users invent ing the same fil e name wil l not inadve rt an t ly share the same data . (O f

course , there may be instances when severa l users wish to share data . Addi tional comm and

language to specify such actions are discussed in section

The DEVICE andVOLUME Subfields

The DEVICE subfie ld speci fies the device type to be used for the file , but not the physica l device

address . In our system , we will allow the following types

CARDIN for card readers ,CARDOUT for card punches ,PRINTER for high speed printers ,TAPE for tape drives , assuming only one type of tape drive is availab le ,DISC for disc drives wi th removable disc packs , assuming that only one removable

storage disc drive is available , and

PERM for permanently mounted file s torage .

The VOLUME subfie ld gives a physical identificat ion of the volume on which the file resides , and

identifie s the vo lume to the computer operator . For example , if a user wishes to establish a new

fil e on tape ree l 2048, he might specify

<‘name

<‘volume

In the above example , i f VOLUME were not specified , the system would assign an avai lable tape

ree l .

The DISPOS ITION Subfie ld

This subfie ld i s used to specify whether or not the file is to be ‘ rewound ’ before the s tep starts . I t

also specifies whether or not to catalogue the FILE statement , that is , whether or not the file i s to

be retained by the system after the job step i s comple ted . I f the system re tains the fi le,the

information which re lates physical s torage to the fil e is kept in the catalogue , and in subsequent

runs , the user need give only the file name in JCL statements in order to describe the file to the

system .

‘

NO CAT’ causes the system to purge information concerning the file from its catalogue .

If the file had been stored on a shared volume,the fi le i s lost after the job step is terminated . The

possib le contents of the subfield are :

LEAVE don ’ t rewind

_ 36

REWIND rewind before use the de fau lt value

CAT cata logue the defau l t va lue

NOGAT don ’ t catalogue , or drop from cata logue

If more than one of the above are to be given , they should be the components of a tuple , e.g .

The SPACE Subfield

This subfie ld i s coded

where n i s an in teger which i ndica tes the amount of space to be al located to the fi le . I f thi s

a llocat ion proves to be too small during execution , the system wi ll at tempt to al locate addi tional

space on the same volume . ALL may be given i ns tead of n to indicate al locat ion of an enti re

volume . This is taken as the defau lt for tape .

End-of-File S tatem ent

This statement i s coded

end-O f

After encountering a JCL file statement with the name subfie ld a l l information read

is regarded as part of tha t fi le un ti l the end-of-fi l e s ta tement i s encountered . The end-of-fi le

statement i s a lso used to te rminate a catalogued JCL procedure .

Monitor Services

Services which the operating system can perform on behalf o f the user are invoked by sta tements

of the form :

where ‘ servi ce ’ indicates the act ion to be performed and ‘arguments ’ are addi t ional parameters

describing the service desired . Rather than assuming that such a request invokes a subprogram in

the convent ional manner , we wil l assume that such a statement causes a specia l in terrupt , and tha t

the li st of parameters gets passed to the appropriate interrupt handler through cause .

For severa l reasons we prefer to u se moni to r-in terrupt li nkage,ra the r than the subrou tine cal l ,

when moni tor services are requested by users . Foremost , by using interrupts , no portion of the

operating system need be direct ly addressab le by a user program , as would be the case i f subrout

ine l inkage were used . This a llows the internal structure of the opera ting system and the names of

internal subrou tines to remain invisib le to the user , but he can request tha t the operat ing system

perform act ions on his behalf .

_37_

The only se rvices which we will describe exp lici t ly in this system are step termination requests , and

input-output requests . The table below li s ts the services supported .

Step termination se rvices (Section

endstep abend

Input-output services (Section

read enable

wri te disab le

backspace wait

rewind iointerrupt

space fixup

re lease endfixup

Step Termination

Normal step term ination is invoked by

and abno rmal termination by

where x is a numeric code which indicates the reason for the terminat ion . x i s a lso used as a

parameter by the job contro l interpreter in dete rmining whether or not to skip the next job step .

I n making this decision after a normal termination , a normal termination wil l be taken to be

equiva lent to The code x is re turned to the job contro l in terpre ter via i ts

w orkqueue .

Input/Output

Most operating system environments provide a variety of I/O faci li t ies , i ncluding faci l i tes allowing

the user to speci fy how computing and I/O are to be overlapped . In some mult iprogramming

environm ents , the ability for a user to specify CPU-I/O overlap in such deta il is not important ,

since global e fficiencies can be rea lized by running CPU and channe ls concu rrently , but not

necessari ly a l l for the same process . I n our uniprogramm ing environment user control l ed I/O

overlap is essentia l , since i t represents the only opportuni ty to use para l le l i sm withi n a user

program . Hence our basic I/O facilities must support de tailed control of CPU-channe l overlap . A

user interrupt facili ty therefore i s an integral part of the supervisor se rvices which are provided to

the user ; this facility corresponds to the privi leged PSETL i nterrupt mechanism which is described

in section

Data for I/O operations , such as the st ring to be wri tten on a fi le as the resu l t of a write-request ,or the st ring to be read from a fi le as the resul t of a read-request , are transmit ted between the

Operating system and the request ing process via the requesting process ’s w orkqueue. I/O related

items on the w orkqueue wil l be of the form where b is a blank atom , and‘data ’ i s the

information being transmit ted . A function , buffer , given be low , shows how i tems are fe tched and

stored on the w orkqueue .

_33

definef buf fer b ;( load) / *Fetches the i tem paired with b on this process

’s w orkqueue <b ,data>

w orkqueue, then buf fer b re turnsfindfirst(thisprocess, x , x( l ) eq b ) ;i f x eq 9 thenre turn 12;

e lserem ov e(thisprocess, x) ;return x(2) ;

end if x ;end load ;

( store resu lt ) / *Forms the pa ir <b , resu l t> , and places i t on the process’s w orkqueue,

makingsure that i t i s the only tup le t on the w orkqueue such that hd t eq

L : findfirst(thisprocess, x , x( l ) eq b ) ;i f x ne 9 then

rem ov e(thisprocess, x ) ;go to L ; / * to look for other i tems x with x( l ) eq b */

putlast(thisprocess,re turn ;

end if ;end store ;end buffer ;

where ‘

thisprocess’ i s given by the macro

m acro thisprocess; C PUcontrol endm thisprocess;

The monitor ca l l

f , b ) ;

causes the next record of fi le f to be read and associated with the blank atom b on the cal ling

process ’ s w orkqueue . The read -moni tor reques t only starts the I/O Opera tion . The user can

synchronize his program in several ways wi th the termination of the operation , at which time the

string of characters associa ted with b represents the record just read . A monitor wait service i s

provided for this purpose . For example :

monitor f, b ) ;

/ * compu ting, but not on buffer

f) ; / *Delay unti l operat ion on f i sr= buffer b ; / *get the info just

The wai t service i s described more fu l ly be low . A second method involves a u ser ’s inte rrup t

faci l i ty,whi ch i s also described be low

,and which is i l lustrated by the output spool code in Section

To wri te a record to fil e f , a moni tor cal l of the form

_39_

f , b ) ;

is used . The s tring of characters , 8 , associated with the atom b on the cal ling process’s w orkqueue

i s writ ten on fi le f as the next record . An assignment statement such as

buffer b 8 ;

may be used to place the string 3 on the w orkqueue prior to the‘write ’ . As wi th the read request ,

wri te reques ts only start the operation . One of the synchronization techniques mentioned above

must a lso be used .

The monitor request

causes the fi le to be reposit ioned to the previous record , i.e . , i f f conta ins records r,, rz, rn, and

if f is posi tioned at r,, the result of a backspace wil l leave f positioned at record r ] m ,

The monitor request

moni tor f) ;

reposi tions f to the firs t record of the fi le ( record rI in terms of the above example ) . For files

which are on devices such as card readers or printers , these commands are inappropria te , and cause

an error to be indicated when the opera tion terminates .

The moni tor request

posi tions fi le I to the beginning of a new page , when f is on a printer or simi la r device . I f this

request is i ssued for a device which is not a printer or something simi lar , an iointerrupt code ( see

be low ) indica ting an i l legal I/O request wi l l be re turned .

The user I/O in terrupt system is normally enabled . Two monitor ca l l s tatements are provided wi th

ouroperating system to al ter the state of the user I/O in terrupt system for each program fi le :

pfn) ;

pfn) ;

While a fi le is d isabled,interrupts resu l ting from the termination of an l/o request on pfn are

stacked by the Opera t i ng sys tem,to be re leased FIFO when the in terrup t system for pfn i s

re-enabled by the user .

In some case s i t may be desi rab le to ignore the interrup t information associa ted with an I/O

opera tion . (For example , when rewinding a fi le , the interrupt b i ts are general ly uninterest ing . ) In

particu lar,when a file is disab led , or whi le execu ting a fixup routine ( see below ) , a mechanism to

avoid stacking certain interrupt reports is needed . The ‘ re lease ’ moni tor service cal l ,

pfn) ;

-40

causes stacked in terrupt information for pfn to be discarded , or, i f pfn i s currently act ive , i t wi l l

cause the interrupt in formation resu l ting from the curren t operation to be discarded .

I f a user has speci fied an I/O in terrupt rou tine for a fi le by having execu ted

control wil l be forced to the sta tement whose label i s r on the occurrence of an I/O in terrupt due

to the fi le f , whenever a m onitor(disable) is not in e ffect . At r , the user program can get the cause

of the interruption via the cal l ,

which resu l ts in buffer y be ing se t to in formation concern ing the cau se of the most recent ly

processed user I/O i n terrupt ( i n terrupt s s tacked are no t conside red in determin ing the most

recently processed interrupt ) . buffer y wi l l be a pai r , whose firs t componen t is the program file

identifie r for the fi le which caused the I/O i nte rrup t , and whose second component is machine

dependen t and give s i n forma t ion rega rd in g the comp le ted I/O ope ra t ion . Si nce

wi ll se t buffer y to the in formation re lated to the most recen t fi le to have

caused entry to a use r fixup rou tine or to have sa ti sfied a wai t-reques t , this moni tor cal l should be

one o f the firs t actions taken in an I/O in terrupt rou tine . We wil l use the term ‘ fixup ’ to designate

code execu ted as the result of in terrup tion at the termination of an I/O opera tion on a file . I f no

fixup has been speci fied for a fi le by a user , then a standard system fixup is used .

An I/O fixup rou t ine may be regarded as a co-rou tine of the mains tream program . Al l of the

variab les o f the mains tream program are avai lable to the fixup and vice-versa . When contro l

en ters an I/O fixup , our monitor wi l l save the mainstream location counter , and restore i t when the

user program execu tes :

While in a fixup routine , further user I/O in te rrupts are inhibited and any interrupts which occur

du ring fixup are stacked by our opera ting system,to be released FIFO on execution of

To synchronize CPU and I/O act ivi t ie s ,

i s used to suspend the ca ll ing process un ti l the fi le f is re leased by the system . I f f was not busy

when the ‘wait ’ was executed,the ‘wait ’ behaves l ike a no-operation . O therwise , control goes to

i’

s fixup when the opera tion on f i s conc luded . I f an in terrupt i s a l ready stacked for f , i t i s

uns tacked and contro l reaches f ’s fixup ,regard less o f the s ta te of thein terrupt system . By

disab ling in terrupts and issuing ‘wai t ’s,a user program can handle interrupts in a predictab le order .

Note that wai ting on a fi le f causes the disabled condi tion to be overridden for fi le f only . I f a‘wai t ’ i s issued while in a fixup rou tine

,and the wai t is not a no—op, then the process resumes in the

new fixup , and the o ld fixup is conside red to be concluded .

_4 1_

Finally,a program f ile f is considered to be busy from the po in t at which an I/O operation is

accep ted to the poin t where i ts fixup rout ine i s entered . Thus , i t i s a l lowed to issue an I/O

instruction to a file as part of i t s fixup routine .

System Organization

The structure of our Operating system can be likened to a set of concentric circ les . The innermost

circ le represents programs which have the highest privi lege level and which are the most machine

dependent . Each outer c irc le has a lower privilege level than any circle i t contains , and tends to be

more machine independent , with operating system programs in the outermost shell being indistin

guishable from user programs .

System Nucleus

The innermost circle,or system nucleus , consists of the basi c interrup t handling programs ,

protect ion mechani sms,functions and maps describing the structure and sta tus of the hardware

being control led , and a rudimentary dispa tcher .

The interrupt handling processes are precisely those speci fied in hd tl[interrupt] . In most cases ,

in terrupts are handled by posting information on the w orkqueue of a process operat ing in an outer

circle .

Data sets associated with the nucleus describe the hardware to be contro lled . Thus , i f c a channe l ,

dev ices{c} might give us the hardware addresses of al l devices on channel 0, e tc . Using these

maps,we can express many of the common operating system opera t ions wi thou t becoming

enmeshed in undue deta il involving the precise layout of the tab les in storage .

Resource Allocation

The next highest privilege level of our operat ing system handles resource al location . To this leve l

belong our main library catalogue and routines to search or update this ca ta logue .

Resource al locat ion rou tines accept the description of a device type along with certain restrict ions ,

and return the physical address of a device which satisfie s the descript ion . Given the user defined

name of a file , the catalogue identi fies the physical volume or device which contains the fi le .

The data and routines at this leve l are availab le to processes operat ing in the next lower privi lege

leve l , but not to processes with st ill lower privi lege . Such processes achieve resource al location by

asking a higher level process to request the allocation for them ; the higher level process can then

perform consistency checks and impose address mappings before actual ly requesting al location .

Major Com ponents

The next highest privilege level of our operating system consis ts of the major system components .

Our operating system allows several major activi ties to take place concurrent ly wi th the running of

a user program . These are : communica t ion between machine opera tor and system,reading of

inpu t for subsequent jobs , printing of outpu t from previously run jobs , al location of resources , and

schedu ling . Corresponding to each of these activi tie s there wil l exist a program and one or more

-42

https://www.forgottenbooks.com/join

which the job w ill require ; i t wil l then summarize this information for use by the scheduler . I f CL

procedures are used , the input reader wil l locate the procedures in the library and expand the

procedure reference s into s tandard ICL . On detecting the end of a job , the scheduler wi l l be

noti fied through i ts w orkqueue tha t another job i s ava il ab le for schedul ing considerat ion . The

entire job , considered as a data file , w ill at the same tim e be catalogued for later reference by those

of the program ’s read statements which are directed to the data included in the job .

This mode of buffering jobs on intermediate disc storage assumes two things : tha t disc storage can

be read substantial ly faster than the system input devices (which are often card readers or s low

comm unicat ion li nes) , and that jobs are likely to be presented whi le a backlog of work exists for

the CPU . The read ing of a job on a slow device during a time when there is back log can be

overlapped with the execution of the backlog . Furthermore , the grea ter the backlog , the greater

the se lection of work for the scheduler in i ts at tempt to u ti l ize hardware effect ive ly .

Output Printer

If we assume thatbecause of the re latively s low speed of printers , the time to print the outpu t for a

job tends to be longer than the CPU time needed to execute the job , then we can expect to

increase the performance of our system by writing information intended for the printer onto a fast

I/O device , such as a disc , and by copying the disc fi le to the printer whi le subsequent jobs are

execu ting . Severa l printers may be required on a computing system with a very fast,powerfu l

CPU . Our operating system wil l incorporate such a buffering scheme for printed output .

Whenever a job fini shes executing , the ou tput print ing routine wi l l be alerted . I f a printer is

avai lab le , the. output i s sen t to i t ; otherwise the reques t for prin t ing gets stacked . When the

printing of an output fi le is terminated , the output printer wi ll unstack the request for the highest

priori ty job ; i f several stacked requests for the same prio ri ty class are present , the oldest wil l be

chosen , that is , FIFO queue discipline wil l be maintained within each prio ri ty class .

UserProgram s

User programs operate at the lowest privilege level . Some software which the operating system

provides a lso operates a t thi s leve l ; examples are language processors , sort ing subsystems , and

some port ions of data management systems . These port ions of opera ti ng systems wi l l not be

depicted at this time .

Coded Operating System

Se ts, Maps, and Tables

In this sect ion , we describe the sets , maps and tables which our opera ting system uses to describe

the hardware configuration on which i t runs , the states of the va rious devices which it manages ,

and the jobs which i t controls . These struc tures will appear in the code which fo llows,and wil l

serve as a major communicat ion channe l be tween the various components of our system . Of

course , the specia l se ts described in Chapter II wi ll a lso be present .

—44

G lobal Information

users : The se t users contains the iden tifiers of all bona-fide users of the computing system . Each

e lement of this se t i s a character string .

ow ner : This se t consis ts of pairs of the form where m em ov ers and ueusers. This map is

m anyzone since one user may have several jobs i n the system .

dev ices : This se t contains the hardware addresses of al l I/O devices which are at tached to the

computing system .

channels : This se t contains the hardware addresses of al l data channels avai lable to the computing

system . (We assume that a channel is necessary and suffic ient to establi sh a data path for

transmission of data between a device and main memory . We allow several devices to be

at tached to the compu ter through the same channe l , a l though the channe l can act as a

communicat ion path for only one device at a t ime . )

type : This se t is used to c lassi fy devices . For de dev ices, type (d ) identi fie s the nature of the

device . I n our system , we assume the fol lowing device types : card reader , card punch ,printer , tape drive , disc ( for disc drives which use dismountab le disc packs ) , and perm ( for

disc drives which have a fixed storage surface ) .

v o lum es : This set contai ns one e lement for each storage element avai lab le to the system . Each

e lement is represented by a tuple where ‘ id ’

isthe vo lume ’s external identi ficat ion,t

is the type of device on which i t i s used , and s is the amount of unassigned space on that

volume .

User Oriented Inform ation

budget : For each ueusers, budget(u) i s the remaining time avai lable for jobs submitted by u .

defaul t s : For each 116 users , defaults{u} i s a se t of pairs , giving the user’s specified defaul t values

for various 1CL parameters .

datafiles: For each ueusers, datafiles{u} i s the se t of fi le names of data fi le s accessib le to the user

11.

ca talogue : Members of the se t‘cata logue ’ are of the form where dedatafiles,

v e v olum es, and k i s a set of pairs , each pair consist ing of an att ribute name and a value

associa ted wi th tha t a t tribu te . Examples of at tribu te names are : ex tents , priva te volume ,e tc . The value associa ted with ‘extents ’ i s a l ist of pairs giving the location and size of the

physica l s torage blocks for the fi l e . I n the even t tha t non-contiguous blocks are used to

contain the fi le , the order of the pairs determines the logical ordering of the fi le .

maxprio : For ueusers, m axprio (u) gives the maximum priori ty level which the user u can assign to

his ow n jobs .

Process andMover O riented Inform ation

userprogs : This se t contains those process identi fiers which correspond to active user programs .

esttim e : For each mover m , esttim e(m ) gives the est imated tota l CPU time for the mover as given

by the job s tatement .

tim e left : For each mover m, tim eleft(m ) i s the CPU time remaining for m .

steptim eleft: For each process p , steptim eleft(p) gives the CPU time remaining for the job s tep

associated with p .

iow ait: For each process p, iow ait(p) i s true i f and only i f p is suspended awai ting completion of an

_45_

I/O event .

mainstate: For a process p , m ainstate(p) is the state of process p’

s mainstream execution . If p

handles i ts own interrupts , then m ainstate(p) i s used to return to the main process ing

program when the interrupt fixup routine is completed .

ioint: For a process p , ioint(p) i s true i f and onl y if p’

s locat ion counter points into an I/O

interrupt fixup rou tine . In such case , other I/O interrupts for process pwill automatically be

stacked,and handled FIFO whenever the process p at tempts to re turn from an interrupt

handler to the program ’s ‘mainstream ’

.

For a process p , this w orkqueue i s the queue of stacked I/O interrupts .

programfiles: For process p , program files{p} are the names in program file name space being used

by p .

new allocations : For each mover m , new allocations(m ) i s the se t of user files which are being

cata logued for the firs t time in the job associated with m . I f any of these files are never

used , they are automatica lly removed from the catalogue when the job corresponding to m

finishes .

interrupted: For process p , interrupted(p) is a pair of the form where f i s the most recent

file for which an I/O f ixup routine was entered , and i is the interrupt info rmation associated

with file f .

Channel and Dev ice Oriented Sets

operational : For xe {dev ices channels } , operational(x) is true if and only if x is usable by the

hardware , i.e.

"x is up " .

units: For ce channels, units{c} i s the set of addresses of devices on channel 0. These addresses

are hardware imposed names of the devices , and are used to reference the devices in physical

I/O statements ( see section

filehandledby: For dedev ices, filehandledby(d) identifie s the member of program files on whose

behalf d is be ing used .

position: This is a device dependent se t which for a device (1 returns the posi t ion at which the next

operat ion wil l take place . This se t i s used primaril y for devices {dedev ices I dev icetype(d)eq tem pdisc} .

rightouse : For dedev ices, rightouse(d) i s an atom used by the opera ting system for control ling

macro operat ions on (1. Since macro operat ions may consist of several suboperations, i t i s

the atom which becomes free as the direct resu l t of an I/O in terrupt . The operat ing system

will free a physical device (Ionly when a ful l monitor request on d is comple ted .

m ounted: For dedev ices, m ounted(d) identifies the vo lume logically mounted on device (1, unless

there is no volume on d , in which case

ready : This is the set of devices on which an assigned volume has been mounted by the operator .

A device (1can be used for I/O i f and only if de ready .

Maps w ithDom ain programfiles

dev iceaddress : This se t provides a map from program file name space to device address space .

userfile : This se t provides a map from program file name space to user file name space .

sav ecause : For each reprogram files, sav ecause(r) i s the inform ation concerning the most recent

interrupt caused by file r .

filew ait: For reprogramfiles, filew ait(r) i s true i f and only if the process to which r be longs i s

—46

suspended waiting for an in terrupt signal announcing the comple tion of an I/O operat ion

performed on file r .

fixup : This set provides a map between program file names and user-leve l I/O in te rrupt hand ling

routines .

logicalposition: For reprog'

ram files, i f r i s stored on disc , logicalposition(r) describes the logical

posi t ion wi thin the fi le at which the user ’s program assumes that the read/wri te head is

located . The physical posi t ion of the read/wri te head can then be computed by using this

information in combination with

rel : For re program files, rel(r) i s true if a moni tor re lease is in effect for r ( cf .

di sable : For re program files, di sab le (r ) i s t rue i f the fixup for fi le r i s not to be automatica l ly

executed at the termination of I/O operat ions on file r .

Rem arks on the Uniprogramm ed System

Our operating system is organized as a sequence of subprograms . The first subprograms presented

are the so cal led major components . The coding s ty le used i n these port ions of the opera ting

sys tem c lose ly resemble convent ional SETL programs , and do not employ PSETL extensions

ex tensive ly . As one progresse s a long the sequence of subprograms , PSETL notions p lay an

increasingly important role , and the reader must keep in mind that severa l processes are" i n

execu tion " .

A major di fference between these subroutines and many of the SETL algori thms published to date

is the re lative absence of i te ra tion headers . For most paths through a portion of the operat ing

system , there i s s imply a sequence of computat ions to be performed , and i terations p lay a minor

role ; when they do occur , they have short scope and modes t range . On reflec tion , thi s is des irab le

in an Operating system , especial ly the nucleus , i f the operat ing system overhead is to remain small .

A call for operating system service should only involve the execut ion of a small number of machine

instructions . The most often traversed port ion of the Operating system is i ts interrup t handling

section . The fact tha t our algori thms for in terrupt handling are re lative ly free of i teration gives

hope that these efficiency-crucia l sect ions of code can have efficient rea lizations .

Succinct , comprehensible expression of the data-processing specifications in our sys tem is attained

with SETL . Searches over the system ’s structures are easily expressed in terms of i-condit ionals .

Thus , there is no need , from a speci fication point of view , to maintain maps whose sole purpose is

to invert other maps .

I n general,we have tried to avoid redundant structures in our sys tem . For example , at various

points , we need a map from program fi le names to devices . Such a map could easily have been

cons tructed i n the subprogram ‘assign ’

. However,we compute the map whenever needed in te rms

of other structures as fo l lows

dev iceaddress(pfn)

The advantage of this construction is to simplify the maintenance of the various system structures .

In the above example,we wou ld have had to consider modi fy ing the addi tional map whenever

‘catalogue ’ or ‘

userfile’ changed , in order to keep the maps consistant .

-4 7

SETL’

s stric t adherence to reference-by-value does pose serious problems for operating system

specification . Some objects , such as process environments and files , which must be manipulated ,can be very large . For example , since file vari ab les include all the data in a fil e , rather than a

pointer to the data,i t becomes impractical to const ruct a li st of files , since this impli es generating

copies of all the data in the files . Inpu t spool does require such a construct ion , and i t resort s to

using a list of program file names, together with provisions for re-openi ng and repositioning files .

These representation-dependent computat ions are not in keeping with the spiri t of SETL, but they

are unavoidable i f we don ’t want to specify an unrea li stic copying of files .

The PSETL definition of disab led blocks removes any doubt whether the system will leave the

disabled state,at the expense of great ly restricting the dic tions which can be used in a disabled

block . The lack of subrou tine calls is part icu larly frustrating, and leads to repeti t ive code , as for

example,the time accounting at the beginni ng of the various in terrup t handlers . The lack of

while-blocks sometim es requires V-i terat ion headers which specify an overest imate of the number

of i terations of the block .

Input Reader

The subprogram inputspool is initiated once for each device which the operator designates as a

system input device . Thus as many processes wil l execute "

inputspool as there are system input

devices . Each "

inputspool" process is passed a user file name which has been ini t ia lised to address

the physical input device which that process is to use . The private vari ab le " reader" i s used as the

program fil e name corresponding to the input device . Whenever a new job i s encountered , a new

mover i s created . A user file i s created to hold the job-associated CL .

By reading jobs from external , non-random access sources , such as cards , and storing the jobs on

disc storage , the input processes create a reservoir of work for the scheduler to choose from . This

makes jobs to be run available in a manner im plying the absence of any essential t im e difference in

se lect ing one job over ano ther , and on a medium from which input records can be read at speeds

bet ter matched to processor speeds than a card reader wou ld allow . At the same tim e , the input

readers extract certain key job characteri stics , such as est imated running times and the names of

the required fi le s , and keep these inmain memory . As input is s tored on temporary disc , certain

modificat ions to the source material are made in i t . We allow JCL macros , or‘proc ’s ( see if

such a macro occurs , i t i s expanded by the inpu t reader , which copies the necessary macro

expansion from the user ’ s or from a system l ibrary . Data included in a job deck"

( such as a

source program to be compiled ) are wri tten to separate data fi les , and not inc luded in the disc

storage copy of the job . Hence the disc copy of the job contains only JCL statements .

In order to guarantee that job steps have unique names and stil l allow a single macro to be invoked

several times within a job , the fol lowing technique is used . During JCL expansion , step names are

prefixed by where x represen ts the label on the input JCL ‘exec ’ statement which init ia ted

macro expansion . Thus , the use of unique labe ls in the source deck is su fficien t to guarantee

unique step names after macro expansion . The vari ab le ‘

qualifierprefix’ holds the s tring to be

prefixed to JCL labe ls in accordance with this scheme .

Since input can come from ei ther the system input device or from a JCL macro library,the tup le

‘ source ’ is used as a stack of input sources , with source ( 1) being the current input device . The

predicate #source eq 1 (or equivalent ly , the macro , readingprim arysource) i s used to dist inguish

-48

whether input i s being read from the system reader or a JCL macro library .

The main loop of the input reader starts a t ‘

m ainloop’

. At this point a JCL statement is read and

copied onto a temporary fi le , fol lowing which an appropriate sect ion of code depending on the

JCL command encountered is executed .

Control reaches the labe l ‘

endcard’ when a JCL ‘end ’ sta tement , or the header statement of a

second job in encountered . (A header sta tement not preceeded by an end card serves the dual

purpose of signa ll ing the end of the present job and the beginning of the next . ) I f macro expansion

had been in progress when the end card was read , the previous inpu t source again becomes the

cu rrent inpu t source , and the main loop continues .

I f a JCL error has been encountered during reading of the job , the job is rej ected out of hand . I n

this case , the temporary input fi le , which now also contains error indicat ions , i s sent to ‘

outspool’

for pri nt ing , and al l table en tri es and temporary fi les for the rejected file are purged .

‘exec ’ statements are checked for the ‘proc ’ parame ter . I f present , then the user’s library as wel l as

the system library are searched for the JCL macro . The user ’s library is searched firs t,so that a

user wri t ten JCL macro wil l take precedence over one with the same name supplied by the system .

I t is assumed that the procedure library , both for the user and the sys tem ,i s named ‘

proclib’

In handling fi le statements , various steps may uti l ize the same program file names ; JCL macros ,consis t ing of severa l s teps whose de tai l s are not known to the user , crea te this si tuat ion . To

guarantee unique program fi le names , the program fi le name on the fi le statement is prefixed with

the step identi fie r . The process ing of fi le s ta tements fa l l s into two main c lasses .

I f the user fi le name contains a then a reference is be ing made to a previously encountered file

statement , and a check i s made to insure tha t the re ferenced fi le s ta tement had indeed been

encountered ( see

I f the user fi le name is given as or i f i t is omit ted ( for a scra tch fi le ) , a userfile name is generated

for the fi le . I f the user fi le name i s found in the catalogue , then i tems not speci fied on the fil e

s tatement are given defau l t va lues based on catalogue entries . O therwise , a new catalogue entry is

made , and parameters not speci fied in the fi le statement are defau l ted from the user’s profile .

Final ly , i f the user fi le name had been given as space is assigned for a new fi le , and the input i s

copied into the new fi le , until an end statement i s encountered .

Output Writer

The subprogram ‘

outspool’ i s i ni t ia ted once for each device which has been designated as a system

outpu t device . To il lus tra te the direc t use of moni tor supp lied I/O functions and inte rrup t

faci l i t ies , this subprogram is writ ten using the primi tive moni tor call s described in rather

tha t the common SETL I/O statements . (The usual SETL I/O really invokes subroutines which

must be actual ly coded in much the same style as the output wri ter . ) Given a user fi le ,‘

ufn’

, to be

pri n ted , a program fi le name ,‘

pfn’

, i s assigned to the fi le . The bulk of processing takes p lace in the

fixup rou tines which rece ive contro l on comple t ion of I/O opera t ions . Contro l re turns to

mainstream ei ther when the end of fi le for the inpu t is reached (‘eof ’ i s true) or during a read error

recovery at tempt (‘

eof’ i s false) , in which case mainstream merely re-enters the wait condi tion .

-49

On di sc I/O in te rrupt , i f the record has been successfull y read, another read i s imm edia te ly

ini tiated into the other buffer (dete rmined by and a wai t is entered for the printer .

Thus , control reaches‘

printerfixup’ without ever returning to mainstream . The appropriate buffer

i s printed , and the program waits for the reading of the nex t disc record to be comple ted .

Scheduler

Only one instance of the scheduler exists (as opposed to the mul tiple instances of input readers and

ou tpu t writers) . I tems are placed on the scheduler ’s w orkqueue when an input reader fin ishes

reading a job which is JCL error free , when a non-setup job is needed to overlap mounting t ime

for an already scheduled job , and when a job terminates .

New jobs from an input reader are kept in ‘backlog’ which is ordered accordi ng to job priori ty , and

within each priori ty class , according to age , so that the firs t i tem in‘backlog ’ i s the oldest job

having the highest prio ri ty , and the last i tem is the youngest job having the lowest prio ri ty . Each

i tem in ‘backlog ’ speci fie s the mover for the new job , and i ts temporary input fi le .

In response to a request for a non-setup job , the fir st such job in‘backlog ’ whose running time is

less than the est im ated mounting tim e , if one exists , is se lected and is fow arded to the process‘

jobcontrol’ for execu tion .

For other requests , i f no other user program is running , the fi rs t i tem of‘backlog ’ i s se lected .

Provided that a suffic ient number of devices for the job are present on the system , the job and i ts

input file are fow arded to a newly created process for the new job ’s mover , called‘

jobcontrol’

.

Job Contro l

Job contro l reads the JCL statements for one jobstep of a job , se ts up the fi l es and loads the

required programs . Job contro l is act ivated as a process belonging to the mover forwhich the next

jobstep “i s to be run . The subprogram is passed the user ’s jc l file name and output file name as

parameters . There is st ructural s imilari ty to the input reader , since JCL statements are being read

and inte rpreted , but procedure librari es are no longer involved since the inpu t reader has a lready

expanded all 1CL macros .

For all file statements , if the reference is to a previously defined program fi le , the file description is

ob tained through the map ‘

userfile’ and the cata logue . I f the fi le i s a lready mounted , no thing

further need be done . O therwise an appropriate available device i s selected , a mounting message is

sent to the operator,and one minute is added to the estim ated mounting time for the jobstep .

The end of step is signalled by an end statement , or by the next‘exec ’ statement . I f there is going

to be delay due to device mounting,the scheduler is invoked to se lect a non-se tup job

,and i t i s

passed the estimated mounting delay as a parameter .

Finally , loading of the program is performed . This i s too strongly dependent on the ‘s tandard ’

form of compil er output and structure of the hardware to be shown in complete detai l . However ,the genera l na ture of the loading process i s shown from the s tatement a t ‘

loadloop’ to the i f

statement following the while block . The vari able ‘

progstobeloaded’ is in i t ialized to contain the

names of the programs to be loaded,and ‘missing ’ init ialized to ul . All i tems in ‘

progstobeloaded’

—50

https://www.forgottenbooks.com/join

The ‘mounted ’ command , which indicates that the opera tor has performed a volume-mounting

operation , i s a cue to the system to check whether the action was in compliance with a previously

issued mounting request message . For disc devices , i t may be the case that while the volume had

been dismounted , fil e s had been assigned to it . In such a case , space allocat ion for these files can

now be comple ted-

and the system table which gives the s ize of the largest b lock of contiguous

s torage on the volume is correct ly updated . In any case , the device is marked as being ready ,thereby signalling the job control interpreter that a mount ing action for which i t may be wai ting is

completed , and informing the scheduler which fil es are currently on-line .

Monitor Services

For each moni tor-i n terrupt , a new process to service tha t inte rrup t is created by the monitor

interrupt handler , which then sets i tself up to receive another monitor-inte rrupt .

The process wh ich requested the moni tor se rv ice the requested service and

addi tional parameters are extracted by the new process from info rmation passed to i t by

the monitor interrupt handler via the spli t s tatement . The first if-statement separates most I/O

requests from the others . An illegal reques t is treated as an abnormal step termination .

Step terminations are processed beginning with the code at label ‘

endstepaddr’

. The cause of the

termination is pu t on the w orkqueue of the job contro l interpre ter process which started the

terminat ing step . By not re turning the ca ller to the C PU ’

s w orkqueue, the ca ller does not regain

control of the CPU . The job control interpreter , on the other hand , resumes operat ion since it’s

aw ait ( see‘End of Step ’ sect ion of code in the Job Control Interpreter) is now satisfied .

For I/O requests the program file name , paired with the call er’s process iden tifier

,produces a

unique identi fier , file’

, for the fi le involved in the operation .

‘ file ’ i s used to de termine the device

and channe l which are involved in the I/O operat ion . Certa in contro l requests,wai t

,re lease

,

enab le , and disab le , do not physical ly or logica lly manipulate the device , and these requests are

now interpre ted without further ado .

For the other I/O requests , the user’s program file is first rese rved . I f the file is busy when the

reservation is at tempted , this process will be de layed unti l the previous operat ion on the fi le has

been comple ted .

Operations which mere ly reposition the read-wri te head of disc devices will not resul t in physica l

manipulation of the device , but ra ther , such Operations cause system tables to reflect where the

ca ller believes the read-write head to be located . This strategy i s adopted because the disc drives

are frequently shared among several files . Moving the read-wri te head for one fi le may be futile i f

i t is again moved for another fi le before advantage is taken of i t ’s having been positioned for the

firs t file . Thus , for disc files , we wil l carry out the read-wri te head posi tioning only if needed ,before a read or wri te opera t ion . For such posi tioning requests , no fu rther faci li t ie s must be

rese rved .

For all other cases, we rese rve the device on which the fi le resides and the channel through which

the device comm unicates with the CPU and main memory to prevent concurren t use by com pet

ing processes ) . We also reserve a blank atom,given by for device ‘

iodev ice’

.

The need for this facil i ty ari ses as fo llows : In response to an inte rrupt from an I/O device , we

_52_

want the I/O in terrupt handler to free a facil i ty . I f i t frees the device i tse l f,then a competing

process can begin an opera t ion on the device . But some I/O requests requ ire a sequence of

physica l I/O actions on a device wi thout interveni ng act ions from other I/O requests . (On discs ,for example

,i t may be necessary to i ssue a read-wri te head posi t ioning command ( see the

if-statement following the label ‘ readwri te ’ ) before performing a read or a wri te operation . ) Thus

tw o faci lit ies are needed for each device : one to be used to reserve the device for a process ( the

device identifier,

‘

iodev ice’ serves this purpose ) , and another to coordinate a monitor process with

i ts I/O opera tions se rves this purpose ) ; The I/O in terrupt handler issues

frees to the second of these faci l i t i e s wheneve r an I/O in terrup t occurs ( see the code at labe l

By reserving rightouse(iodev ice) a moni tor process delays i ts execution unti l the current

physical I/O operation has finished . When an I/O moni tor request has been completed ,then the

moni to r service interpretor process frees the other fac i l i ty ,‘

iodev ice’

, thereby a l lowing other

processes to access that device ( see the code at label

_5 3_

Catalogue of Routines

inputspool

Input spool reads jobs from an input source , abstracts job requirements fromJCL statements , and saves the job on disc .

procsearch

procsearch(a,x) returns the value true if file’

a’ contains a JCL procedure named

X .

jobcontrolThis process loads memory with programs for a job step , assigns devices to datafi le s , and enf orces time estim ates .

schedulerThe scheduler maintains a li st of jobs to be run ordered by priority and t ime orarrival . It se lects the oldest , highest p rio ri ty job when no user program is beingrun , or when there is delay wai ting for another job to be set up .

outputspool

This routine fetches fi le names from its w orkqueue and prints the file’s contents

on an output device .

operator message analyzerThis program acts on commands from the operator . I t a l so ini ti al izes theinte rrupt rou tines when the system firs t starts opera tion .

assignunhookThese routines add and de le te to the map between program file name space anduser file name space .

allocateThis routine assigns a disc pack or a tape ree l to a fi le .

re linqui shThis routine adjust s the vo lume-tab le , and the vo lume table of conten ts toindicate that the space of a discontinued file i s now avail ab le for assignment .

m onitorxpt

Monitor services handle interpre tat ion of I/O requests .

ioxpt

The interrupt handler works in conjunction with m onitorxpt in support ingthe user I/O interface .

getw ork

The dispatcher reactiva tes those processes whose aw ait condi t ions have beensatisfied , and i t se lects a process to contro l the CPU ,

giving prio ri ty to systemprocesses .

tim expt

The timer interrupt handler determines whether a user-program ’s est imated steptime has expired , and terminates ove rrunning user program steps .

_ 54_

page 56

page 6 1

page 62

page 66

page 67

page 69

page 84

page 84

scope operatingsystem ;m acro/ *For user file ufu, a program file name pfn i s estab l ished for the running process , and filev arbecomes a file variable representing the fi l e */

is

filev ar: <open pfu, l

endm estab lish ;

macro processparam eter

/ * reference a processes ini t ia l argument* /

endm processparam eter;

m acro fi lesize ;/ *defau l t size of standard system-created fi le s*/

100

endm fi lesize ;

m acro prim arysource ;/ * for the input reader , reference to main inpu t device */

endm prim arysource ;

macro prim aryposition;/ * for input spool posi t ion in the primary fi le next to be read */

endm prim aryposition;

macro currentsource ;

/ * for input spool , the current inpu t program-fi le name */hd hd source

endm currentsource ;

macro currentposition;

/ * for input spool , the current posit ion in the input fi le* /(hd source ) (2)

endm currentposition;

m acro readingprim arysource ;

/ * true iff current source is the system input device * /#source eq 1

endm readingprim arysource ;

m acro thisprocess;/ *A more mnemonic way for a process to refer to i ts own process

C PUcontrol

endm thisprocess;

m acro dev iceaddress(pfn) ; / *device on which program fi le res ides*/

endm dev iceaddress;

/ *The global variables declard be low are described in sect ionglobal

logicalposition,channels,units;

global 2 volumes , program files;global 3

_5 5_

global 4 users , owners , defau lts, catalogue , m axprio , esttim e,

INPUT SPOOL

scope 4 spooling ;/ ‘ This scope contains the procedure which handles inpu t devices such as card readers . I nputspool has two major functions :I . To expand any JCL macros included in jobs .

2. To veri fy that the 1CL is correct . Errors include ill egaluser name

,illegal commands , undefined JCL procedures , and

dupli cated labe ls .

For a job being read by input spool , there are tw o possible outcomes1. One or more ICL errors are discovered . The JCL along withdiagnost ics is printed , and the job i s o therwise discarded .

2. There are no JCL errors . Entries are made in the systemtables for the job , which becomes enqueued on the

/ *Each process which reads input is passed a unique data file name which already corresponds to a physical device acting as a system input reader*/

spoolin: dev ice = processparam eter;

is

source = <inputfi1enam e, 1>

is a vector of program file names which is used during macro expansion as apushdown list of names of open files, and infil e is a lways the current file*/

infile = <open currentsource,1

/*Scan ahead to the next ‘

job’

discard :(while ne

’job ’

) infi le read image ;i f image eq $2 then

/ *End-of-file while looking for the next job . This wil l be inte rpre ted as ending thespooling operat ion on this device , and the process terminates . I f the operatorwishes to resume spooling on this device , he may issue a comm and to start a newspooling process ( see Operator

term ;end if ;

end whil e ;new nam e : / *C heck for legal useri f n is username 6 users) thenmessage ( image+ ‘

rejectzillegal userim age = nl ;

go to discard ;end if ;

will identi fy the new job ’s mover . Note that we can ’ t use the user ’s name for thispu rpose , since he may have several jobs in the

job = new at;

i ni t ia lizestepnam es (vector of all the job

’s step names)v olum esneeded ( set of volumes used by this job )qualifierprefix (prefix to guarantee unique program fi le names )localfilem ap (map from program file names to user file names)newfiles ( se t of files forwhich new catalogue entry i s

stepnam es= nult;v olum esneeded = n1;

qualifierprefix= nulc ;

_ 56

localfilem ap = nl ;

new files = nl ;

/ * Initialize error flag to show no errors found

jclerror= false ;/ *Remember that the job card hasn

’ t ye t been processed . I f another is encounteredi t acts as the te rminator of the current

jobcard for new job *// *Set up a temporary fi le for job

’s JCL , i n which macros areis expandedjclcatnam e)

tem pfiles { expandedjclcatnam e}allocate(expandedjclcatnam e) ; / * fi le to ho ld job */

go to m ainw rite ;

Main Loop of Input Spool Processw /

An input s tatement is read and copied to the expanced JCL fi le . The comm and is thenused to index a branch tab le , which determines where the s ta tement is further

m ainloop : i nfi le read image ; / * read inpu t record*/i f image eq 9 then/ *end-of-fil e treat as an end-s tatement*/go to endcard ;

end if ;m ainw rite : expandedjcl w rite image ;i f / *This se t i s a branch table*/

/ * for command

is loc ne 9 then go to loc ;

i l lega l control card flag and signal error*/jclerror= true ;expandedjcl w ri te command ’

;

go to m ainloop ;end if ;

endcard :

/ *An end s ta tement in a fi le other than the main input fi le means macro .

current program fi le i s closed and the previous one poppedif n readingprim arysource then

*end macro expansion*/unhook(currentsource) ;source = tl source ;infi le <open currentsource ,currentposition> ;

/ * remove stepnam e of the comple ted macro from prefix*/qualifierprefix= if 3c ( i ) e qualifierprefix 0 eq then

else nule ;go to m ainloop ;

end i f ;/ *end-of-fi le or end s ta tement whi le reading main inpu t source , indica t ingfound . I f JCL error had been previously discovered , the job i s

i f jclerror then

/ *Print JCL and error indications* /enqueue expandedjclcatnam e on outspool for username ;unhook

_ 5 7_

‘ Discard the temporary data fi les which had been submit ted with the job unlessdisposi tion was given as

(Vyetem pfiles) unhook‘Discard newly cata logued, but unused

(Vys newfiles)relinquish(y) ;

end Vy;go to discard ;

end if ;*No JCL “ e rrors found with job ju st read . Update sys tem tab les from the saved job

job in m ov ers ;/ *Se tup map showing job

’s owner*/

min‘ volum es needed by job into system

*Newly cata logued entries due to this

enqueue <job ,expandedjclcatnam e> on scheduler for username ;/ ‘ Now loop back to read the next

go to discard ;

Job Statement Processing

jobcard: _if jobcardprocessed then go to endcard

: :

jobcardprocessed = true ; / ‘ signal job card means end of current job*//*In the expanded JCL fil e , defau lted job parameters wil l be fil led in by the following loopto their defaul t values . In later examination of the job statement , we can assume that allparameters have been

(Vye i‘

tim e fpriority’

} I im age (y ) eq 52)

end Vy;/ *Save job statement information in a local variab le . I f the JCL is free of errors , then thesaved information wil l be used to update the system ’s

tem pjobcard = im age ;

if im age (‘ t im e ’ gt budget(usernam e) then/ ‘ The est imated t ime exceeds the t im e allocat ion remaining for this user . We wi ll sendhim an error message , continue to read his job for possib le JCL errors , but not al lowthe job to execute .

jclerror= true ;expandedjob w ri te

‘

Job rej ected because the time estim ate exceeds yourcurrent time

end if ;go to m ainloop ;

Job-Step Statement Processing

execi f eq 82 thenif is lbl ne unlc then

* test for duplicate step names*/if stepnam es then

https://www.forgottenbooks.com/join

userfilenam e = if eq (2

then new at / * scratch file— i nvent user file name*/else

/ *The fully qualif ied program filenam e is the concatenation of the pref-ix and the programfilename given by the

fullprognam e : qualifierprefix

/ *Check that the program fil e name is unique“

i f fullprognam ee jobfiles thenjclerror= true ;expandedjcl w rite program file name in this step .

’

go to m ainloop ; / *quit processing erroneousend if ;i f (Sc(i) euserfi1enam e 0 eq then

/ *External fil e name containing a means that i t is an indirect reference to a programfile name in a previous

if userfilenam ee jobfiles thenfullprognam e in jobfiles;

fully quali fied program file name , and associated user file name in expandedj cl file

,to avoid recomputing the re lat ionship between program and user file names

duri ng job contro l language interpre ta t ion . localfilem ap maps fu lly qual i fiedprogram fil e names into user file names . I t i s needed to handle ind irect referencesto previously declared file s ( see sect ion

localfilem ap(fullprognam e) = localfi1em ap(userfilenam e)expandedjcl w rite

else jclerror= true ;expandedjcl w rite to previously defined file

cannot be

/ * else , i f not a reference to a previously declared file ,fullprognam e in jobfiles;/ *If the data for the file follows thi s FILE sta tement , a blank atom will serve as i t

’s userfile

i f userfilenam e eq then userfilenam e = new at“

/ *Note that the construction in the fol lowing statement , and the definition of the data fi les ta tement of section do not provide for one user to access file s of another user . Thericher comm and language introduced in Chapter V remedies thi s

localfilem ap (fullprognam e) <user'

nam e,userfi1enam e

expandedjcl w rite

/ *If the fi le i s already catalogued , parameters absent in the JCL sta tement are fi lled infrom the catalogue . Later , one needn ’t worry about absent parame ters on the JCL

if ne S2 then(Vse

if image (s) eq 82 thenim age ( s) = catalogue <usernam e

,userfilenam e>

end if ;end Vs;/ *Force volume specification to agree with

/ *For a new file , parameters not specified in JCL are taken from defau lts . I f the userhas not specified defaul ts for volume or space ( the usual case ) , then the al locate routinewil l f ind space for the

(Vseif im age ( s) eq I2 then

— 60

/ *In order to be able to drop newly catalogued files in the event that a job abort s ordoes not even pass inpu t spool ’s JCL validi ty checking , we keep track of such file

<usem am e,userfilenam e> in newf iles ;end Vs;

end if ;checks that a vo lume i s assigned . I f none i s , then i t wi ll find space , and

indicate the vo lume in theallocate/ *"eep track of volumes needed for this

in v olum esneeded;*If the job contains a data file , copy the file onto the

i f eq then

new fileopenclose in tem pfiles;

i f n readingprim arysource then / * resume reading from primary source*/

currentposition= tl infi le ;infil e <open prim arysource,prim aryposition> ;

end if ;rd : i nfil e read line ;i f ne

‘end-oi-file ’ thennewfi le w ri te line ; go to rd ;

end if ;

unhook(new fileopenclose) ;*If we had been reading from a macro l ibrary , then we temporari ly close theprimary source , and continue reading from the

if notreadingprim arysource then / * continue from library */prim aryposition= tl infi le ; *mark posi t ion in primary source*/infile <open currentsource ,currentposition> ;

end if notreadingprim arysource ;

end if image ;go to m ainloop ;

definef

/ *This rou tine searches a JCL macro library for a JCL procedure named x . The libraryconsists of JCL statements . An EXEC statement having a ‘prog ’ parameter x is the firsts tatement in the expansion of the JCL macro x . I f such an EXEC statement i s found ,

procsearch returns true , has the side effect of leaving the library posi tioned to read the nextsequenti al record in the expansion of x , and se ts the variab le

‘

image ’ to the first record inthe macro ’s

(while 11 endoffile(a) )a read y ;

then image : y ;return true "

end while ;retu rn false ;end procsearch;

end spooling ;

—6 1

scope 3 jobsequencing;

JO B CONTROL INTERPRETER

is passed the JCL and output files for a new job . For each step , i t e stabl ishes mappings between program file names and user fi le names , determines whether steps areto be run or skipped , and loads the necessary programs . On encountering a s tep , a secondprocess wi th the same mover as the current mover of the job control in te rpre ter is set up .

The second process has less privi lege than the job cont rol in terpre ter , so that i t cannoti nterfere with the operating system . I t is thi s process that u ltimately executes the job step .

When a ll the JCL for the step has been read and when the necessary code has been loaded ,the in te rprete r makes the second process dispatchable, and i t wai ts for that process tote rminate before start ing to inte rpre t the next job

jobm onitor:

/ *Assign program fi le names to the job’s input and output fil es , posi tioning the outpu t fi le

beyond that port ion already

/ ‘ posi tion at end of output file .

m ov = hd C PUcontrol ;

tim eleft(m ov )"‘Get the process identifier for the user program*/

*See Scheduler for creat ion of

/ * Initia lize error return code to show that no previous error hadN

oécured. The variab le‘ faul t ’ i s used by abend to communicate wi th the job contro l interpreter , and info extractsthe cause of the termination ( see

startstep : stepstarted = false ;

becomes true when a s tep statement i s encountered . A subsequent stepstatement acts as an ‘end ’ for the current

w aittim e = 0; / * Init ial ize device mounting t im ereader : source read im age ;

jump

/ *We know that the JCL is syntact ica l ly correc t , for otherwi se inpu t spool would haveaborted the job . Thus , w e _

don’

t check for val id JCL statemen t types . O f course,thi s

assumes perfect transmission between di sc and main memory , and perfect recording ondisc . The non-JCL items writ ten by input spool a lways follow FILE statements

,and are

read during file sta tement

go to / *branch table for comm ands*/

C XC C

job card can be ignored*/

i f stepstarted then/ *If we encounter two exec statements wi thou t an in tervening end statement , thesecond exec ends the previous step . We must reposi tion the input fi le so that i t wil l bere-read when JCL interpretation resumes . Backspace one

source(2) = if ( source (2)— 2>3n> 1 (hd source) (n) eq er) then u+ 1 el se 1;go to end ;

end if stepstarted;i f ne 9 then

/ *Since JCL macros have been expanded by inputspool, ignore statements wi th‘proc ’

go to reader ;end if im age ;

—62

‘ save EXEC statement information in local storage for later‘ Save name of program to be loaded .

‘

input data to the job step*/min

output w rite im age ;/ *Test condi t ion on JCL statement to determine whether to run this step . The return codefrom the previous step is in info (fault) . eval (not shown ) checks the cond parame teraga inst the error return code

if n eval image thenoutput w rite ‘ step skipped condit ion fa lse ’ ;

skip : source read image ;i f e <

‘ fi le end ’

> or eq 12 thengo to skip ;

elsego to jump ; / *Next step

end i f image ;

stepstarted = true ;

end if ;go to reader ;

/ *Inputspool has inserted a second JCL fi l e sta tement for every fi l e , giving the fu l lyquali fied program fi le name and user fi le

source read pfn,ufn;

/ *The disposi tion of a fi le may change from step to step (e .g . the last step to use a temporary fi le should specify NO C AT to drop the fi le from the system ’s

ufn outnew allocations(m ov ) ;*New fi le no longer

reserv e(allocflag) ; /*Prevent other a llocat ion

if not(3dselectededev ices Im ounted(dselected) eq then/ *If volume is notmounted , se lect an appropriate device and est imate mounting tim e at1 min . Normally , the scheduler has determined that enough devices are avai lable , sotha t the fo l lowing s ta tement wi l l succeed . I f one wi shes to t ake device fai lure intoaccount , more care wil l be needed

dselected = arb {d,de dev ices type (d ) eq and m ounted(d) eq nl } ;m ounted(dselected)dselected out ready ; / *device is no t ready unti l operator says i t

*Send conso le message to the opera tor to mount the appropria te vo lume on thechosen device . I t is understood that he will di smount whatever is curren tly mounted ondevice

operatorm essage

w aittim e = w aittim e+onem inute ;

/ *Even if thi s step requires a vo lume mounting , we continue to interpret JCL until wereach the end-of-step , in case addi tional volume mounting requests are discovered forthis

end if ;ca ta logue (ufn)

‘

dev iceaddress’

) dselected;

/ *Associa te program fi le name with user fi le name */

free allocflag ; / *Allocationgo to reader ;

/ *An‘end ’ statement or an ‘exec ’ statement bring contro l here . I f there is no step started ,

then the end card represents the end of job . O the rwi se , i t i s time to check that a l l isready , and to load the

end : i f n stepstarted then go to endjob"

_63_

/ *If there is a setup delay , t ry to find a non-setup job to run during theif w aittim e gt0 then

quickrun= true ; / *Signal scheduler to try for non-setup jobs .Enqueue the expected time for se tup complet ion on the schedu ler . The scheduler wil luse this time as an upper bound for the completion time of short runs which it will tryto run to overlap the set up time for this

enqueue(w aittim e+clock) on scheduler for scheduler ;(Vxedev w ait) aw aitxeready

“

/*Now all devices are ready . Signal scheduler to cease looking for non-setupquickrun= false ;

/*Wait for non-setup job to finish , if one is running .

‘

userprogs’ is the set of user

processes which the scheduler has set up and which have not concluded . Normally , thisis a s ingleton set consist ing of the user process controlled by the job control analyzerprocess . But while setup is be ing overlapped with a non-setup job , there are two i temsin ‘

userprogs’

. Wai ti ng for ‘

userprogs’ to become l i s the means by whi ch thi s job

control process wai ts for a non-setup job to complete . The scheduler wil l not attemptto start any additional short jobs , since

‘quickrun ’ has been set toaw ait#userprogs eq 1;

end if ;*We go on to load the rou tines needed for the step which is now to be carried

Loader

* ‘

progstobeloaded’ holds names of programs to be loaded for the current step .

‘ fe tch ’ is amach ine dependent routine that reso lves interprogram references and which places in‘missing ’ the names of referenced programs which have not yet been

loadloop : missing = progstobeloaded;‘ I ni t ia lize ‘

loadertable’ the tab le used by the loader to s tore subprogram entry point

locations , and‘

codev ect the bi t s tr ing which the loader wil l bu i ld into the execu tab le

loadertable = nl ;

codev ect= nult;

(while missing ne nl doing progstobeloaded = m issing ; )(Vxeprogstobeloaded)(Vy(i) e

if +x> is c) ne 9 thenx outmissing ;

(not shown here ) moves machine language text for the program xinto the appropriate port ion of memory , and extablishes communica tionbetween x and previously loaded programs . I f x requires other programs tobe present ,

‘ fe tch ’ puts these program names into ‘missing ’ .

‘ fetch ’ storesthe entry point into ‘main ’

, unl ess there i s not sufficient room for the program , in which case

‘main ’ is set to S2. A table of entry po ints for all subprograms is buil t in ‘

loadtable’

. I n the uniprogramm ed case , we assume that theloader has been ini t i a li zed wi th the size of the largest a l lowab le programstring .

‘

codev ect’ i s bui l t into the executab le program by the

fetchcontinue Vx;

end if ;end Vy(i) ;

end Vx;i f nrissing*progstobeloaded is nf ne ul then

/ *Some required programs can ’t beoutput w rite ‘missing Step

*notloaded i s given some numericgo to stepskipped; /

*Treat as an abnormalend if ;

end while ;

— 64

‘ Test whether there was enough room for the program to beif main eq 52 thenoutpu t w rite ‘Not enough space to load this job

go to stepskipped;

end if ;

/ *If and when the program is fu l ly loaded , The new user process i s given a standardenvironment , to which

‘

standardenv ironm ent’ i s assumed to be ini t ial ized

,and whose

descript ion is machine dependent . We assume that ‘ fe tch ’ has p laced the execu tab leprogram in the appropria te area in storage , start ing at

‘origin ’

, and that the ent ry point wascomputed by ‘ fetch ’ and stored in ‘main ’

. initialstate i s set to the ini t ial state for the user

(disable)*main ent ry computed by fetch*/

*Moves loaded code in to environm ent*/initialstate

/ *Assume that the ent ire step time est im ate wi l l betim eleft(m ov ) tim eleft(m ov )budget(user) budget(user)split to initialstate(args) for thisprocess; / * start execut ion of job

End of Step

/ *Await execution termination report from‘abend ’

. I n response to an abend monitor-ca ll ,the numeric code for the termination gets queued on the job control in terpreter

aw ai t getfirst(thisprocess) is fau l t ne 9 ;*A normal terminat ion or abend wi l l sa t i s fy the above wai t condi t ion . Restore thebalance of the step ’s time to the time remaining for this

tim eleft(m ov ) = tim eleft(m ov ) steptim eleft(userprocess) ;budget (user) budget (user) +steptim eleft(userprocess)

stepskipped :

i f info (fault) ne 0 then/ *Abnormal end wri te termination

outpu t w rite step stopped ’

, info (fault) ;end if tirneleft;kill userprocess; / *In any case , remove the user process */(Vfiles6 program files(userprocess) )

/ * re lease a l l program files for the completed jobunhook ( fi les) ; / *If the fi le

’s disposit ion was not‘keep ’

, then space for the fi le wi l l be re leased byend Vfiles;i f tim eleft(m ov ) Ie 0 then

/ *The job has used up al l of i t’s est imated running

outpu t w ri te ‘Time es timatego to endjob ;

end i f ;/ *Even if a step abends , the run may cont inue , as determined by the

‘cond ’ parameter ofthe next ‘exec ’

go to startstep ;

/ *At the end of a job , the output fi le i s passed to outputendjob : close (hd

unhook(outputnam e) ;enqueue outf il e on outspool formov ;unhook(inputnam e) ;(Vyenew allocations(m ov ) )

/ *Remove from the cata logue , al l new fi le s which have not been used during theexecution of this

_65_

relinquish(y) ;*give up

end Vy;userprocess outuserprogs;

/ ‘ I tems enqueued on the scheduler from job control inte rpre ters signify that a user jobterminated . The scheduler will respond by attempt ing to schedule another

enqueue nl on scheduler for thisprocess;term ;

*This job control analyzer process is now completed and thus terminates

SCHEDULER

scheduler i s enqueued whena) input spool has read a new job , whenb ) jobcontrol te rminates a user job , and when0) jobcontrol seeks work to overlap setup

schedule : aw ait

/ *The queue on the scheduler is the communication medium between the schedu ler and itscallers . When the ancestor of an enqueued item is a user , a new job has just been read , andis p laced at the end of the vector ‘backlog’ , which contains all jobs to be run in the orderreceived (except for rearrangements due to operator-i ssued prio ri ty

if ancestor(request) is requestor s users then / * t rue for case a*/i f (3x ( i ) e backlog I then

/ * inse rt new i tem after all jobs hav ing the same or higher priori ty bu t ahead of jobshaving lower priori ty*/

e lseend if ;

end if ancestor ;

if requestor eq thisprocess then/ *True , by convention , for case 0, cf . the lines of code following the labe l ‘end 111 thejob contro l in terpre ter , above . The schedu ler u ses the identi ficat ion of i ts ca l ler todete rmine which of the above cases hold . Case c arises when the scheduler i tsel f is therequestor , case a ari ses when a user is the requestor , and all other cases are case

/ * record time before whi ch job must end*/end if ;i f quickrun and #userprogs eq 1 then

/ *Since (#userprogs) eq 1, no non-setup job has yet been scheduled , and therefore welook for a short non-se tup

if(3x(i) e backlog , Vre Ede dev ices*ready

(m ounted(d) eq r) and le t ime limi t ) then/ *a job exis ts wi th estimated running time less than the estimated setup tim e ,and with all resources ready , i.e . no mounting

<jobid,input> = x;

1z) ;

go to startup ;

go to schedule ;end if (3x;

end if quickrun ;* cases a and b reach this point*/

nextjob :

—66

https://www.forgottenbooks.com/join

Ins tead , we indicate the way that a fair ly convent ional doub le buffering scheme can berepresented in our language .

Each process which prints system outpu t files i s fi rst passed the name of a fi le whicha lready corresponds to a physical

outputspool : dev ice = processparam eter;

/ *Blank atoms to point to I/Ois

top : awai t (getfirst(thisprocess) is ufn) ne 9 ; / *wait for work*/is / *Relate a program file name to the fi le to

be printed , and indicate that this process has an I/O fixup routine at‘

discfixup’

to whi chcontrol wi ll be forced at the end of each disc

useleftbuffer= true ; / * i nit ialize buffer swi tch*/eof = false ; / * initia li ze end of file switch*/

1 *read ini tial record*// *The above moni tor request s tarted a read operat ion . When i t is physica l ly complete

,

control is forced to discfixup . In thi s way , action can be taken on the physical completionof an I/O operat ion . I n this program , the act ion is general ly to start to read the nex trecord , while print ing the record just read . A standard doub le buffering scheme is

nconsecreaderrors = 0;* initia lize reading error count */

The fol lowing idle loop re linquishes control of the CPU (unless an end of fi le hasoccured) . Control is forced to discfixup when the end of a disc operation

idle :/ *discfixup will Set eof to true when the end of file has been reached . The printer is spacedto a new page

,and another reques t for printing is

if n eof then go to idle ; ;

/ * space printer to new page*/unhook(pfn) ; /

* re lease user ’s output file */go to top ; / * look for more work“

Fixup Rout ines

/ *All the rea l work is done in the fixup rou tines . Control no rmally does not reach mainstream unt il the end of the disc file has been encountered . The wai ts in the fixup rou tinesprevent returns to mainstream

,for on satisfying the wai t , contro l is forced to another fixup

Disc Fixup

discfixup‘endoffile ’ i s a macro which is true i f end of file is indicated in the m terrupt

i s a machine dependent/ *Determine cause of I/O

int= buffer intbuf ;

if endoffile(int) theneof = true ; / * file finished*/

* re turn to mainstream*/end if ;

* ‘

ok’ i s a machine dependent macro which is true i f the I/O interrupt bi ts do not indicate

an

_68_

i f n ok(int) then / * disc error fixup follows*/(while nconsecreaderrors It 10)

nconsecreaderrors : nconsecreaderrors-1-1;

/ *presume backspace ok, ignore interrupts“

determines into which buffer toi f useleftbuffer then

pfn, buf l ) ;

pfn, buf2) ;end if ;

pfn) ; /*wait for reread , then re-execute discfixup*/

end whi l e ;i f useleftbuffer then / *print error message on unreadable record */

buffere lse buf ferend if ;

end if 11 0k;useleftbuffer: n useleftbuffer; /

* swi tch buffers*/nconsecreaderrors = 0; / *Previous errors are now

Note : I f the printer i s not busy , which is the case after the ini t ia l read , controlto the printer fixup anyway , and the most recently read disc record is

Printer Fixup

printerfixup

if eof or count gt0 then m onitor(endfixup)”

/ *Read in to the buffer whose conten ts had jus t been printed ou t . Thencontents of the other buffer into which a disc read had just been

if readleftbuffer then

1

end if ;/ *Prevents prin ter interrupt being processed be fore

go to discfixup ;

end ospooling ;

OPERATOR MESSAGE ANALY"ER

scope 2 al locat ion ;/ *This process acts on Operator generated messages . The process warts to read a message ,and then executes a short block of code to sati sfy the request .

—69

I t i s also the first section of code executed when the opera ting system start s running , sotha t i t initializes the interrupt handlers and the

initially(disab le )

/ *Genera te a process state wi th fu l l privileges by copying the state of the curren tprocess . Thi s wil l be used to generate the initia l states of the interrupt

osenv ironm ent*Set up timer-i nterrupt handler“

loctr(osenv ironm ent) tim expt;

interrupt(tim er) osenv ironm ent;*Set up monitor-cal l interrupt

interrupt(m onitor) osenv ironem nt;‘ Set up I/O inte rrupt

loctr(osenv ironm ent) = ioxpt;

*Start the scheduler . ‘

schedstart: is scheduler , osenv ironm ent> ;

split to schedstart for thisprocess;

/ *Start the dispatcher process*/

is dispatcher , osenv ironm ent> ;

splitto dispstart for thisprocess;end disab le ;

*Open the operator ’s console keyboard forestablish<

end initially ;

/ *Now , read from the console keyboard . An eventual start command w ill get input spool

operation : keyboard read msg ;if ehd

is li s t )go to

* i llegal comm and“

keyboard w rite ‘ i l legal command ’

;

go to operation ;end if ;

/ *The operator ’s commands

ordesignate device (1 as a system input or a system output device . These commands are usedto initia te

start/ *The

‘ type ’ tab le classi fie s devices by type (See The device type of uf w ill beei ther ‘cardin ’

, or‘printer ’ . The type of uf must agree wi th the ‘action ’

i f eq / *and device i s idle */and (Vp eprogram files dev iceaddress(p) ne then

is uf in datafiles;

catalogue(uf)

I“

split to ( i f eq‘cardin ’ then inputspool

e lse outspool) (uf) for C PUcontrol ;e lse keyboard w rite ‘ inappropria te device"

go to opera tion ;

/ *The command adds u to the set ofsys tem users , and estab li shes u

’

s defau l ts as given in the profileaddnew user:

/ *Here , we check that i s a tup le of pairs of character strings,

command if the profi l e i s of the wrong form . I n ac tual prac tice , a morewould be

i f type eq tupl and

eat Itype t eq tupl and #t eq 2 and type e eq cstring) then

is u in users ;

keyboard w rite ‘Bad format for defau l ts . Commandend if ;go to operat ion ;

/ *The command elevates userin the backlog to be the first job in the

hipriority

(di sab le ) / * to avoid race condi tion with the schedu ler*/i f (3x ( i) e backlog Iow ner(hd x ) eq then

priority(hd x) = 9 ; /*Highes t priori ty */

end if ;end disable ;go to Operat ion ;

readym ounted :

/ *The command , communica testo the system that the vo lume v has been mounted on device (Iby the operator , and that i ti s ready for use . The system must now comple te any space al location on this volume thatwas left incomple te by the ‘a l locate ’ routine . Since al loca tion may be done as a resu l t ofthi s command ,

‘

allocflag’ must firs t be reserved . (See the storage a l location

reserv e (allocflag) ;i f is (1) eq then

/ *The operator has mounted the vo lume which the operat ing system has been expecting . Now complete any incomple te a l locat ions

,and then indica te tha t the device i s

ready fori f type (d ) eq

‘

tem pdisc’ then / *Comple te a l locat ion of disc fi les on this volume * /

/ *Note that ‘

dev iceaddress’ i s a macro de fined at the beginning of Section

(f ne program files I dev iceaddress(pfn) eq (1and eq 52)

/ *Lack of ex tent fie ld in catalogue entry for the fi le indicates that a llocation ofthe fi le is

i f thencontinue f n;

/ *else there i s an error in the use of the disc pack , because the volume table ofconten ts i s inconsis ten t wi th the sys tem table ,

‘volumes ’ . Note that‘

spacefound’

(code for which is shown below ) updates the catalogue to showthe newly ass igned fi le ‘extents ’ .

‘al locate ’ had earlier decided that sufficient

_7 1_

space exi s ted on thi s vo lume . The reso lut ion of thi s problem i s not shown

end if ;end f n;

end if type (d) :

m ready ;else if ne 9 then

/ *The operator has mounted the wrong volume . Inf orm him of the correct volume tobe

operatorm essage(‘Mount

/“The operator has mounted a volume on a device which did not ho ld a requiredvolum e . Mark the device as being

in ready ;end if mounted ;free allocflag ;go to operation ;

addtim e

/ *The command , allocates addi tionalt units of time to user

(disable )if is u . e users then

budget(u) = budget(u)

keyboard w rite ‘ im proper userend if ;

end disab le ;go to operation ;

dropuser

/ *The comm and , causes the user 11 to be removed fromthe set of authorized system users . Any work in progress for u is purged , as we ll as systemst ructures re lated to

i f is u 6 users then(Vp eprocesses I ow ner(hd p ) eq u) )

Remove all active processes associated with user u . First , make sure that a llu ser fi le s are detached , and not invo lved in I/O operat ions (done by subrou t ine

(Vfileseprogram files(p) )unhook(files) ; /

*Stop I/O action , disconnect file fromend V files ;kill

end Vp ;catalogueIu} = Q ;

u out users ;

keyboard w rite ‘ Improper userend if ;go to Operat ion ;

end operator ;

_72

FILEMAP MAINTENANCE

define/ *This subroutine estab l ishes

‘

program filenam e’ as the program file name for the user

fi le ‘

userfilenam e’

, and speci fie s‘ fix ’ as the loca tion of program filenam e

’

s in terrup t

program filenam e in program files;

fixup(program filenam e) fix ;return ;/ * Initiali ze the maps used for moni tor services re lat ing to I/O on this fi le . (cf . sections

and*Fi le to cause logica l

/ * In terrup t inform ation is not to be/ *Program is not wai ting for I/O on file to

/ *This subrou tine undoes the effec ts of‘ assign ’ and uncatalogues the file if

define unhook(program filenam e) ;/ *If the program fi le , program filenam e , has an uncomple ted operat ion in progress , preventan interrupt from going to the user-program ’ s fixup , by estab l i shing the system

’s standardfixup as the fi le ’s inte rrupt

if n (‘cat ’ e then

/ *Give up space onDelete file from

end i f ;/ * Indicate that the unhooked fi le i s no longer active on the physical device on which itresides . If no program fi le s are assigned to the device , i ndi ca te tha t the device i s no tlogica l ly

if f neprogram files ne m ounted(d) then

end if ;*Note that ‘

dev iceaddress’ i s a macro . See the start of Section

dev iceaddress(program filenam e) $2;

re l (program filenam e) (2;

filew ait(program filenam e) 9 ;

fi le outprogram files;re turn ;

'k /

EXTERNAL STORAGE ALLOCATION

define qd allocate(userfilenam e) on allocflag ;/ *This rou tine assigns a d isc pack or tape ree l to a fi le . Thi s rout ine , as we l l as thefo l lowing one,

i s queued to preven t simu l taneou s a t tempts to al loca te or free space ondevices by different port ions of the operating system . We assume that allocflag i s an atom

_73_

which has been made a member of facilities . I f a vo lume i s a lready assigned , there i snothing to

if ne 9 then go to qui t “

i f catalogue(userfilenam e) 6 discs then

/ *Disc space allocation*/i f eq S2 then

/ *assign a size to the file i f not already done . Note that ‘ files ize ’ i s a macrocatalogue(userfilenam e) = filesize ;

end i f ;

/ *Search mounted packs for avail able(Vde devices I type (d) eq

‘ Try to find sufficient space for the file on the volume mounted on deviceif then

/ *Note that ‘

spacefound’ updates Opera t ing system ’s tab le of space free on

go to qui t ;end if ;

end Vd;

/ *Having failed to find space on any volume mounted on a disc dri ve , we now search forany dismounted pack having sufficient space . I f such a volume is found , assignment ofspace will be made later when the volume is mounted . The request for mounting will comefrom the JCL

if (Sv e v olum es I v (2) eq and

v (3 ) ge thencata logue(userfi1enam e)

‘volume ’) = v ( 1

end if ;go to quit ;

/ *Tape volumeelse if eq

‘ tape ’ then*First , search the tape drives to see if an unassigned reelmounted . I f one is , i t i s assigned to the

if (Ede devices I type (d ) eq‘ tape”and

eq‘empty ’

) thencatalogue(userfilenam e) m ounted(d) ;

go to quit ;end if ;/ *If no mounted , unassigned tape ree l is found , a dismountedree l is assigned . Request for mounting will be issued by theJCL interp reter .

i f (av e v olum es I v (2) eq‘ tape ’ and v (3 )

‘empty ’

) thencatalogue (userfilenam e) v (

qui tfree allocflag; / *Make allocate and re linquish routinesreturn ;

end allocate ;

https://www.forgottenbooks.com/join

m ounted(d) = v olnam e ;

in catalogue(ds)xem ap x( l ) eq

‘

em pty’

l x(3 ) ;return true ;

end if ;end spacefound ;

end al location ;

MONITOR SERVICES

/ *Control goes to m onitorxpt on an interrupt caused by a request for moni tor service . Anew disab led process handles the interrupt by spawning an enabled process to handle therequest

,after which the disab led process term inates i tse lf . See also , section

macro filebeginning ; / *extracts posi tion on disc where fi le s tarts*/

endm filebeginning ;

macro w aitnotbusy(d) ; /*By re

-reserving busystatus(d) the moni tor*// * request handler effects a wai t

’ until (1hasendm w aitnotbusy; /

* finished it ’s I/O

macro m axposition; / *extracts maxim um file size */

endm m axposition;

m acro filepart(parm ) ; *Extract program fi le identifier from arguments to moni torparm ( 1)

endm filepart;

m acro buffpart(parm ) ; / *Extract buffer to be used for moni tor serviceparm (2)

endm buffpart;

macro labelpart(parm ) ; / *Extract location of fixup routine fromparm (2) ;

endm labelpart;

m onitorxpt

(disable )

/ *For an overview of the code which fol lows , cf . sect ion*First , keep track of time used by problem

if resum e s userprogs then/ *Compute the t ime remaining in the u ser ’s jobstep , and charge a fixed ra te ,‘overhead ’

, for the . moni tor service . Alternat ive ly,we could compute the actual

t ime to perform the moni tor service,and charge for i t on complet ion .

‘overhead ’

should be defined by a macro to be the appropriate number of clock ticks to chargefor the average monitor service (often on the order of 1

—76

steptim eleft(resum e) = tim er clock overhead ;end if ;

/ *Having received a moni tor cal l , we spli t of f a new process which wil l fo l low therequested moni tor service through to i ts end , and then at once se t up to receive the nextmoni tor call . We assume that ‘cause ’ i s of the form where fcn specif iesthe moni tor funct ion and parm gives any addi t ional parame ters . Recal l tha t‘

osenv ironm ent’ represen ts an Operat ing system environment , including system priv i

* ‘

lookatrequest’ i s a label

occurring a few lines/ *Start a priv i leged process to i n terpre t the moni tor servi ce request . Attach theprocess to the mover of the requesting

new process) osenv ironm ent;

split to neWprocess(cause ) for resum e ;

We cheat the dispatcher in what fo l lows , by dispatching the newly spawned processourse lves to rep lace the disab led moni tor interrupt hand ler , and at the same t im e , weforce the moni tor interrupt process to start at the head of the disabled b lock the nexttime i t becomes

*Now the dispatcher can ’ t act on

disab le ;

*The newly spawned process which handles the moni tor request start slookatrequest:

/ * save parameters*// * sav.e id . of ca lling process*/

i f / *All I/O reques ts go to*//* the labe l

‘

io’

i s 100 ne S2 then go to IC C"

/ * I llegal moni tor ca l l . Let contro l f low through to the abend moni tor call routine , with‘parm ’ i ndicat ing terminat ion due to an i l legal moni tor call . (Assume that the variab le‘

badparam eter’ indicates this reason for

parm = badparam eter;

go to setabend;

endstepaddr: parm = 0; / *Code to indicate normalsetabend : / *Determine the ancestor of the abending process , and put the cause of te rmination on

the ancestor ’s work queue . (Reca l l tha t the ancestor is the job control analyzer processwh ich had set up the user job

,and awai ts a termination report . ) Thi s act ion wil l awaken the

ancestor which wil l te rminate any I/O which might st ill be in progress for the terminatingprocess

,and which wil l s tart the next job step or terminate the

jcinterpprocess =

enqueue parm on jcinterpprocess for nl ;te rm ;

_77_

fi le / *The name in program file name space is unique because i t isthe pair formed by the unique process identifier and the program-generated name . Thus

,

several processes using the same program name at the same t ime , will be ab le to accessseparate file s . See the construction of the ‘

userfile’ structure duri ng fil e s tatement process

ing in the job controlif not(fileeprogram files) then

/ *I/O request for a non-exi stent program“

f ile . Abend the calling process . Assume thatthe vari able ‘

badfileid’ indicates this reason for

parm = badfileid;

go to setabend ;

end if noniodev ice dev iceaddress(file) ; /

*device on which fil e is mounted . See andand the macro defini tion for

chan arb {cechannels I / *Channe l used for the/ *Control functions that do not require the abi li ty to physical ly manipu late an I/O devicecan now be

if

<‘enable ’ enable> ,

<‘disable ,disab le> } (fcn) is loc ne 9 then go to loo“

/ * control functions : wai t , re lease , enable and disab le are identified by the above‘ i f ’ .

These functions do not require synchroniza tion to avoid race condi tions . The remaining requests

,read

,wri te

,backspace

,rewind

,and space , are handled

reserve ( ffle) ;/ *The

‘ type ’ tab le classifies I/O devices by type . c. f .

i f fcne or then/ *For disc read/wri te operations and for rewind , e tc . operations on other devices ( suchas tapes ) the physica l I/O device on which a fi le is mounted must actua l ly be reserved .

On the other hand , for discs , control operat ions such as backspace and rewind are notphysically carried out ; the new posi tion of the read-wri te head is simply recorded insystem tab les . Physica l posi tioning takes place only when ac tua l ly needed before aread orwri te reques t , since the read-write head may be repositioned due to activi ty foranother fi le sharing this device . Thus , since no physical I/O wil l take place , the deviceneed not be reserved . But for operat ions requiring the use of the physica l device

,w e

*/reserv e(iodev ice) ; /

* reserve physical device*// *A moni tor ca l l may resul t in a sequence of operations on a device ( for example , adisc read requires a head-positioning operation , fol lowed by a read Operat ion) , with therequirement that the device not be operated by other processes during this sequence ofoperat ions . Thus the system ’s I/O in terrupt handler wi l l not free iodev ice when i tcomple te s an operat ion , since this wi l l a l low a competing process to s ieze iodev ice .

Instead , we associate a b lank atom with each device via the map rightouse ,and reserve

that b lank atom , also . Each complet ion of a physica l I/O Operation wil l resul t in thi satom being freed . Thus , the busy status of the blank atom can be used by the moni torservices rou tine to synchronize i tse l f wi th I/O operat ions . On ly when a reques t iscomple ted , wil l the moni tor service process free iodev ice, at which time iodev icebecomes avai lab le for competing

/ *The above-mentioned blankan interrupt is rece ived resul ting from the comple

t ion of the I/O operation on iodev ice ,the quantity filehandledby(iodev ice) wil l be used

by the I/O i n terrupt handl ing process to determine the program fi le for which theOpe ra t i on wa s performed . Because a l l p roce sse s re se rve iodev ice andrightouse(iodev ice) in that order , and re lease them in reverse order , deadlock cannotoccur [Hav ] , so long as I/O operations run to comple t ion and cause an I/O in ter

reserv e(chan) ; / * get control of channe l*/end if ;go to

— 78

(fen) ;

readwri te : / *Treatm eant of‘ read ’ and ‘wri te ’

if type(iodev ice) 6 discs then/ *For discs , we must first posi tion the read/wri te mechanism to where the userbel ieves i t to be . This i s necessary si nce the disc d rives may be shared by severa lprocesses , each of which causes the read/wri te mechanism to be positioned unknownto the o ther processes . I t i s the operating system ’s function to make this invisib le to i tsusers . Note that ‘

m axposition’ and ‘

filebeginning’ are macros introduced at the begin

ning of the moni tor se rvices sect ion ofposit ion : logicalposition(file)+filebeginning ;if logicalposition(file) ge m axposition then

/ *At this point , in a more advanced system , an addi t ional extent could be allocatedto the fil e . In that case , the computat ion of

‘posi tion ’ above becomes more complicated. However , we will mere ly signal an I/O error for this

/ * signa l error if posit ioned*/free rightouse(iodev ice) ; / *beyond area allocated to the fi1e*/go to w rapupiorequest; return to

end if ;/ *physica l operation to posi tion the*/

w aitnotbusy(iodev ice) ;* read-wri te mechanism ; wai t for comple tion */

end if ; * end of special processing for discs*/

/ *In a read or wri te request , the second element of parm gives the blank atom that isassociated on the ca ller ’ s w orkqueue with the data which is transmit ted . See Section

i f fcn eq‘ read ’ then

read , see Sectionis a local area wi thin the I/O service process , into which info rmation

wil l be/ *Operation init iated al low caller to

w aitnotbusy(iodev ice) ;*Delay moni tor serv ice process until operation“

* i s comple te , then return data

findfirst(caller, x , hd x eqi f x eq 12 then

/ *Buffer conta ining output data does not exist . Error/ *Simulate e rror

free rightouse(file) ;go to w rapupiorequest;

end if x ;

w rite(iodev ice,

putfirst(C PU, cal ler) ;w aitnotbusy(iodev ice) ; unt il operat ion is

end if fcn;/ *Control re turns here when physical I/O operation is

go to w rapupiorequest;

backspace : *Treatment of ‘backspace ’

/ * for discs , backspace is not physica lly carried out, i nstead , record whereuser thinks he is posit ioned*/

logicalposition(file) : 0m ax ( logicalposition(file)/ * sim ulate successfu l backspace“

e lse backspace(iodev ice) ;w aitnotbusy(iodev ice) ;

end if ;go to w rapupiorequest;

_7

rewind : / *Treatment of‘ rewind ’

(disab le)

/ *For discs , we have onl y to rewind the fileif type(iodev ice) 6 discs then

else/ *For tapes , a physical rewind operation must be

rew ind(iodev ice) ;w aitnotbusy(iodev ice) ;

end if ;end disab le ;go to w rapupiorequest;

space : / *Treatment of ‘skip record ’

(disab le)

i f type (iodev ice) ediscs thenlogicalposition( file) ( logicalposition(file) 1) mm m axposition;

sav ecause(file) goodio ;

space(iodev ice) ;w aitnotbusy(iodev ice) ;

end if ;go to w rapupiorequest;

end disable ;

/ *Now , the en tire moni tor request i s comple ted , and the iodev ice may be free’d for use by

otherw rapupiorequest: free iodev ice ;transm itiointifany

/ *This point in the code may be reached in two ways1. As the resu l t of a logical I/O operation terminating , or,2. As the resu l t o f a moni tor-enable request to a fi le which has a s tacked interrupt

,in

which case the in terrupt ge ts unstacked (i.e . processed ) . Note that in this latter casethe actual unstacking operat ion is done by ‘enable ’

I f the process ‘ cal ler ’ , which owns the logica l file‘ fi le ’ has been in I/O -wait for the fi le

‘ fi le ’ , then the process is made dispatchable, and the interrupt for‘ fi le ’ i s processed . I f the

I/O-wai t was for another file , then the interrupt for‘ file ’ i s stacked .

O therwise , i f‘ cal ler ’ i s a lready in an I/O fixup , or i f

‘ file ’ i s disab led for in terrupts , theinterrupt is s tacked . In al l other cases

,the interrupt is processed .

I n processing an interrupt , i f‘ fi le ’ had had a moni tor-re lease reques t issued

,the

inte rrupt is ignored . O therwise,the location counter for ‘cal le r ’ i s forced to ‘ fi le ’s fixup

routine , and the main stream environment is saved i f‘ cal ler ’ was not in another I/O fixup

at the time .

I n any case , the logica l fi le‘ file ’ i s now available for further Operations .

Note in connection with the fol lowing code that user in terrupt rou tines are not logicallyinterruptab le except i n the case when a monitor-wait request has been issued in a fixuprou tine . I n tha t case , i f an interrupt had already been stacked for

‘ fi le ’ , or , i f‘ fi le ’ i s busy

and has not had a monitor-re lease request i ssued for i t , when the opera tion on‘ fi le ’

terminates , the fixup rou tine for ‘ fi le ’ i s executed as a co-rou tin'e to the fixup in which thewait request occured. Control does not return to the fixup routine which requested thewai t .

cf . section for some of the maps which are used

(disab le )

f low(disabled(file) or

(iow ait(caller) = false ; ) stack,

stack,

interrupt ,(putfirst(C PU ,caller)in terrupt ;

interrup t :i f rel( file) then

/ *If a re lease request had been made for ‘ file ’ , ignore the*Now we can forget that the re lease had been

/ * Interrupt the process which ownsi f notioint(caller) then

*Process was in m ainstate . Save i t for restorat ion on ‘

endfixup’

m ainstate(caller)end if not ioint(caller) ;

*In any case , force location counter to fixup routine for‘ fi le ’

loctr(state (caller) fixup(fi le )end if rel(file) ;

/ *Wait is no longer*Save file id . and cause of the most recen t I/O

interrupted(caller)stack :i f rel( file) then

else

end if rel(file) ;end flow ;free fi le ; *Monitor operation comple te free programte rm ;end disab le ;

wait : *Treatment of ‘wait ’

(disab le ) / *Find firs t stacked interrupt for the fi le , ifeq fi le ) ;

i f x ne 82 then/ *An in terrupt i s s tacked for this fi le . Force the user process to i t s I/O fixup routinefor thisremove (<caller,io> , fi le/ *Note : The

‘wait ’ service i s the only manner in which an interrupt routine mayin terrup t ano ther interrupt rou ti ne . I n th is case , the interrupt rou tines work asco-rou tines , and the second routine never returns contro l to the

i f n ioint(caller) thenm ainstate(cal ler)

end if ;

interrupted(caller) file,sav ecause(fi le )free fi le ;ioint(caller) true ;

te rm ;end if ;i f filee busy then

iow ait(caller) true ; filew ait(f i le ) true ;*The ca ller ’s process is not re turned to the C PU ’

s w orkqueue. When the awai ted I/Oopera tion ends , then the cal ler wi l l be returned to the C PU

’

s

te rm ;end if ;

_3 1_

endw ait;

te rm ; *Moni tor serv ice action forwait is completed .

‘

end disab le ;

giv einterruptcause

/ *Return via the cal l er ’s w orkqueue, the status information associated w i th the mostrecent ly processed I/O in te rrupt be longing to this caller. I n this sense ,

‘most recent lyprocessed ’ means ei ther having entered a fixup routine , or having satisfied a wai t condi

putfirst(caller,go to endw ait;

enable : / *Treatment of ‘enable file ’

/ * init ia lized in subroutine‘ assign ’

eq fi le ) ;i f x ne 52 then

/ *Release the first inte rrupt which was stacked for while was

go to transm itiointifany;

e lse *No interrupts were stacked for theterm ;

end if ;

disab le : / *Treatment of ‘disab le fil e ’

te rm ;

re lease : / *Treatment of‘ re lease file ’

(disable )/ *Previous interrupts for this fi le are forgotten , and if an operat ion is m progress , theinterrupt resu l ting from the logical end of operation wi ll be discarded wi thout forcingcontrol to the user ’s fixup

reports : { x e w orkset{ x eq fi le } ;(Vx6 reports) remove (<caller,io> ,x)rel(file) = true ;

term ;end disab le ;

endfixup : /*User program exi ts from fixup

if not ioint(caller) then/ *The caller was not in an I/O fixup routine . We elect to ignore the

go to leave ;end if ;

n/ *O ther program fi le s awai t user interrupt processrng . Take the enabled-fi le whichcompleted i t ’s operat ion first , and treat i t as though a wai t had just been issued for

if file ne $2thengo to wait ;

end if ;/ *There are no interrupts stacked for enabled

leave/ *Caller may reum e

term ; *Monitor service

— 82

https://www.forgottenbooks.com/join

DISPATCHER

getw ork: w aitcopy = w aitset; processes wi th awaited condi tions*// *First , we recheck a l l aw ai ted condit ions . cf . for a discussion of the aw ait

loop : i f w aitcopy ne ul thens from w aitcopy;

* re test awai ted condi tion*/C PUcontrol = s; /

* control to process testing condit ion*/i f i sok then 8 out w aitset;

else loctr(state(s) L ;end if ;go to loop ;

end i f ;/ *Now we attempt to find a job to dispa tch . Processes enqueued on ‘CPU ’ are candida tes .

Nonr user processes, i.e. ,

system processes , are giveni f w aitOOpy eq n] then

(disable )findfirst / *gives 3 as output */i f s ne Q thenremoveCPUcontrol 5 ;

e lse i f getfirst(C PU) is s ne 9 then/ *The process just found must be a user-process , s ince our search for non-userprocesses had fai led to find any , and , since we are disab led , no other process couldhave sneaked another process on the CPU w orkqueue . As a check on the softwareand the CPU , we could check that indeed , seuserjobs, but we chose to omit thi scheck for the

/ *Prepare to stop user i f time estimate i s

C PUcontrol = x;

end if ;end disab le ;go to getw ork;

TIMER INTERRUPT HANDLER

tim expt

(disab le )i f resum e euserprogs then

/ *A user ’s program has run out of time . Determine the process-id of the JCLinterpreter corresponding to thi s user program , and notify i t that the user has runout of

enqueue tim eisup on in terpreter for resum e ;/ * Indicate that time has run

/ *A system program was interrupted . Set the t imer to interrupt in one second , andrestore the interrupted process to the head of the dispa tcher ’s

— 84

putfirst(C PU,resum e) ;th er= clock+onesecond

end if ;*G ive contro l to the dispa tcher , and at the same time , se t up the t im er in te rrup trou tine to start at ‘

tim expt’ at the next timer

<CPUcon'

trol, loctr(state(thisprocess) <dispatcher, tim expt) ;

end disab le ;end operatingsystem ;

—85

Chap ter IV

A Multiprogramm ing System

4 .1 System Objectiv es

The second operating system to be described is intended to run on a s ingle CPU configuration

operating in a non-interact ive environm ent in a multiprogramming mode .

‘Multiprogramm ing’ will

be taken to mean that more than one user run may be in progress a t a given time .

‘Being in

progress ’ should be understood to mean that execut ion of a user job has comm enced but not a ll the

user processes associated with the job are concluded .

By adopt ing a mult iprogramm ing design , one makes i t possib le to utilize a greater fract ion of a

comput ing system ’s resources than a single job is likely to require at any given time . Thi s can give

greater throughput from a comput ing system than is achievab le by a uniprogramm ing design such

as that described in Chapter III. (We observ e at thi s point that even the simple uniprogramm ingsystem of Chapter III rea lly utili zes mu ltiprogramming in so far as several processes coexi st in that

system . However , at most one of these is a user process . ) By keeping several processes available

and al lowing them to compe te for resources we increase the l ike lihood of processes be ing en

queued on a resource ; then when one process re leases a resource , i t can be ut ilized at once by

another .

I f i t is unlikely that a user job requ ires as much as half o f main memory , then there will generally

be room for more than one user job to be resident in main memory at the same time . In this case ,

the object ive of overlapping se tup time with the execution of a non-setup job becomes relat ively

less im portant , since the mult iprogramming act ivi ty of our system will probably keep one or more

user jobs in progress during setup anyw ay . Thus ,‘ setup time overlapping ’ wil l not be provided

expli ci t ly in the next system to be described .

We shal l wish to minimize the burden of change imposed upon a user who moves from unipro

gramming to mul tiprogramm ing . I n making this move , the user gets no increase in fuctional power ;

his gain lies in the greater availab ility of computing resources due to their better utiliza tion .

In a mult iprogramming system ,symbolic referencing Of I/O devices becomes mandatory . Several

jobs are now to run concurrent ly,and the probabi l i ty that two jobs can coexis t wi l l decrease

markedly if jobs cou ld demand to use a specific member of a se t of functional ly identical devices .

Mul tiprogramm ing S trategy Considerations

For mu l t iprogramming to succeed in increasing system uti l izat ion , we must have programs

concurrently in storage which are capable of using diverse resources . To take an extreme example ,i f a l l programs use only the CPU , mul tiprogramm i ng cannot possib ly reduce the tota l program

running time . Contrariwise , if we are given a group of programs using severa l resources , then to

the extent that a single program cannot concurrently use resources (e .g . CPU idle wait ing for I/O

— 86

comple tion ) , idle resources become available to other processes . Recaptured cri tical resource idle

time is a measure of the advantage gained by running a se t of jobs in mul t iprogramm ing mode .

We want to enable our scheduler to se lect jobs for concurrent execution in a manner facili ta t ing

the overlapped use of several resources [C ] . Suppose that wi th each job , we are given estimates of

CPU time , disc transmission t ime , and tape transmission time . Then , for the total fam ily of jobs in

the system , we can compute the estimated workload for each of these resources . I t is c lear that the

shortes t es t im a ted time to comple t ion for the to ta l co l l ec t ion of job s i s a t le ast as great as the

est imated workload on the busiest resource . ( I f there are severa l identical elements such as disc or

tape channels,and assuming that the work can be evenly dis tributed among functionall y identical

e lements,we divide the est imated load on the resource by the number of identica l e lements which

can operate concurrently and which are available . )

Now consider some subse t of jobs which can coexist on the computing system , that is to say , a

subset whose tota l memory requirement does not excede the machine ’s memory capacity,whose

tota l tape drive requirement does not excede the tota l number of dri ve s , e tc . For thi s subset,

compute the est imated workload , whi ch wil l be a triple . I f the busiest resource of the subse t is not

the busiest of the entire workload , then the subse t i s out of balance with the total workload , and

running i t wil l sure ly increase the running time for the en tire workload .

To aid in determining a good subse t of jobs to run concurren t ly under mu ltiprogramm i ng , we wish

to at tach a measure m to a subse t of jobs so as to indica te a ttractiveness of concurrent execu tion .

That is , i f P and Q are tw o se ts of jobs , we would like m to have the property that if

then P is a bet ter subse t of jobs for multiprogramming than 0. We will call such a measure a

figure of merit.

I f we make the optimistic assumption that the heaviest loaded resource can be kept busy all the

t ime by means of mul t iprogramming , we can estimate the fract ion of t im e that a subset of jobs wil l

keep each resource busy . For example , suppose that the estimated workloads for CPU , disc and

tape are 10, 5 , and 3 minutes respective ly . Then the shortest time in which the subset can run i s

10minu tes ( i f the CPU can be kept busy) , and the CPU ,di sc channe ls and tape channels would be

busy and 30% of the t im e .

To define out figure of me ri t , we compare these loadings , calcu la ted for a job subse t , with the

loading calcu lated for the entire workload,and penal ize a subse t of jobs for each resource which

(when the workload for the subset i s normalized to make the load on the heaviest used resource

equa l to 1) i s underloaded as compared to the tota l workload (normali zed the same way ) . No

credi t i s given for resources which are loaded more thoroughly in the subse t than in the tota l job

se t . Thus , i f i s the to tal workload of the fu l l se t of available jobs , and

if is the total workload of a subse t S of jobs , with then as a figure of

meri t for the subset S we wi l l take

m ax

— 87

We consider the jobs in priority order , and we add to the collection of ru nning jobs the oldest job

of highest prio ri ty for which the figure of meri t of the enlarged collec t ion is not larger than the

figure of meri t for the current collection of running jobs .

Job Control Language

In keeping with our objective of imposing minimal transi t ion difficu l ties on our users , the 1CL of

sect ion will be used with only minor changes in ourmult iprogramming system .

The TIME parameter on the job statement will be given as an n-tuple , where the first component i s

the es t imated CPU time,and the remaining components are the est imated requirements of the

other system resources .

A SPACE parameter wil l be included on the job statement to speci fy the amount of contiguous

main memory space which the job requires .

Organization

The overal l st ructure of our mult iprogramming system will be simil ar to that of the uniprogram

ming sys tem of Chapter 111. That system already employed mult iprogramming in order to run

several operat ing system processes concu rrent ly wi th at most one user program . Thus , i n order to

multiprogram among severa l user jobs,we expect that the main changes wil l be to the scheduler , so

that i t can provide several user programs for concurrent execu tion .

The input reader must be modified to accept a more comprehensive t ime estimate , and to update

the system’s running est imate of the backlogged workload . Only minimal change to the handling

of job cards is required . The output wri ter is unaffected by multiprogramming considerations .

The scheduler i s the component which is the most affected by mult iprogramming . I t must

recompute the system ’s workload and figure of meri t whenever a new user job i s encountered or a

user job terminates . I t must then determ ine i f jobs exist which can run with onl y the system ’s

unused resources and which would also not degrade the system ’s figure of meri t . I f such a job

exis ts , i t i s sent to job control for execution .

The dispatcher must also be reworked to account for mul tiprogramming . First , system processes ,al l of which are known to use CPU bursts of short duration , wil l be given priori ty over non-system

processes . I f there are no system processes in the C PU ’

s w orkqueue, we wi l l choose the oldest

user process . There are many al ternative dispatching algori thms depending on the operat ing

system ’s objectives . The dispatcher we wil l use tries to get jobs completed in FIFO order .

Among the factors which must be assessed in determining whether a program can be added to a set

of running programs is the amount of main storage which i t requires . The management of main

memory can be a complex matter,and it is strongly dependent on the addressing characteri st ics of

the machine . We wi l l assume that the job sta tement speci fie s the amount of contiguous space

which the job requires,and that object programs are "re locatab le that is , that a program can run

_88

in any port ion of main memory provided that sufficient contiguous space is available . We will also

suppose that a job holds onto a fixed amount of memory from start to finish . Of course this i s by

no means the only stra tegy avail able . We could elect to swap programs between main memory and

disc storage , or to move programs from one part of main memory to another to create large blocks

of contiguous s torage , provided that the machine archi tecture allows programs to be re loca ted

after loading and part ia l execution .

In this system , we assume that the machine archi tecture does not a llow relocation of a program

after partia l execution . The system described in Chapter V does assume that dynamic relocation is

possib le . I t would be a minor matter to incorporate the code at label ‘

getblock’ of sect ion in

the scheduler , which i s responsib le for memory al loca tion in this system .

To allocate resources one must parti t ion main memory and I/O devices among compet ing jobs .

Deadlocks can arise when severa l programs are al located resources from a common pool . Dead

lock occurs when tw o ormore processes are wai t ing for resources held by the others . Neither can

unti l i t gets the additional resources which i t needs . There are several ways to avoid this si tuation,

but one must be aware of the ways in which deadlock can occur in order to avoid i t . I n our system,

had we left resource allocation to the job contro l analyzer , we would have faced the possibil i ty of

deadlock , s ince severa l job control analyzer processes can be in Operation concurrently . I nstead ,thi s function was reserved to the scheduler , of which there is only one instance in the system .

Besides a llocating a port ion of avai lable main memory to a job , oursystem must insure that the job

is confined to i ts al located memory . A component of the environment wil l be used to speci fy the

memory areas avai lable to a process . The boundarie s will be given as a se t of triples of the form

to indica ted that 11 contiguous words of memory beginning at m are accessab le to the

process . An attempt to viola te boundary restric t ions resul ts in a memory-protect interrupt . x

specifie s the types of accesses which the process may make to the memory area . We consider any

combination of the fo llowing types of accesses : execution , read-data , and wri te-data .

I f our programs were carefu l ly constructed by the compi ler to keep data areas separa te from

executab le code , then the loader can speci fy user boundaries to make the execu tab le code have

only "execu te " access , user defined cons tants to have only" read-data access , and user defined

variables to have both " read-data" and "wri te-data" access . Such a mechanism makes i t im possi

ble to execu te data due to a wild branch, or to accidenta lly modify a program or constan t due to

fau l ty indexing , or to modify a constan t by using i t as an argument to a subroutine wi th side

effects . An attempt to violate boundary restrictions resu l ts in a memory-protect interrupt .

When the loader se ts up the user program,the user space which the loader uses as a data area has

both read-data and wri te-data access . The loader then can parti t ion the user space in to execu te

only , read only , and read-wri te areas before the job step execu tes . Of course , this implies that the

programs being loaded carry sufficient information to al low the loader to determine the parti tion

1ng .

We can now fi l l i n a gap in Sec tion regarding the ring s tructure of our operat ing system .

I nnermost ring processes,the interrup t handlers

,start wi th read-wri te-execute access to al l main

memory . I t is conceivable that such processes restric t thei r own access as the nature of their task

-89

develops . Thus , while the monitor inte rrupt handler and I/O in terrupt hand lers have maximum

access privileges , the processes which they invoke shou ld have lim ited memory access . Allocation

routines , scheduler and job contro l do not require wri te access to the specia l se ts described in

Section with the exception of w orkset, nor execution access to the interrupt rou tines .

Since so much of the uniprogramm ed system carri es over to the multiprogramming case , onl y those

rou tines which are extensive ly modi fied wi l l be presen ted i n their enti re ty below . For rou tines

having onl y minor modifications,only the modifications wil l be given .

_90_

https://www.forgottenbooks.com/join

/ *A corresponding decrease of estw ork i s made when a job terminates . See theV-block following the labe l ‘endjob

’

,

end disab le ;enqueue <job ,expandedjcl> on scheduler for username ;i f eq

‘ job ’ then go to new nam e ;

else go to discard ; ;

"k

SCHEDULER

The schedu ler i s enqueued whena ) input spool has read a new job , and whenb ) job contro l terminates a user jobReplaces scheduler , page

schedule : awai t #w orkset{thisprocess} gt0;

i f ancestor(c) 5 users then / * true for case a*/i f (3x(i) e backlog lt then

/ * insert new item after all jobs having the same or higher prio ri ty but ahead of jobshaving lower priori ty*/

elseend if 3x ( i ) ;

end if ancestor(c) ;

/ *Note that in case b , for which no explici t code is provided in what fol lows , we put ani tem on the scheduler w orkqueue to

‘ awaken ’ i t . After ‘awakening ’

, i t may find thataddit ional work can be scheduled

,since the termination of an old job wil l have freed some

resources .

new m erit

i f #backlog eq 0 then/ *There are no jobs to consider for

go to schedule ;end if ;m m erit(w orkload) ;/ *If no resources are underloaded and there are at leas t two user programs runningconcurrently , the scheduler waits to have another request enqueued on it.

i f m eq 0and #userprogs gt 1 thengo to schedu le ;

end if ;/ * find first job for which there are enough resources and which does not i ncrease thefigure of meri t*/

(Vx(i) e backlog)

/ *Set‘

testm erit’

to the figure of meri t of the se t of currently scheduled jobs augmentedby the candidate job ,

‘

job’

. I f the figure of meri t does not improve , i.e . , diminish , thenconsider a di fferent

: z(j ) e i s testw orkload) ;i f testm eritge m then continue(disable ) / * to preserve integri ty of space tables*/

/ *For a po tentia l job to be run , firs t de termine whether there is su fficien t main

i f not(3y(k) e freesize I y ge space(job ) ) thencontinue Vx(i) ;

end if ;

_92_

/ *Now form the se t of devices needed , and for each device , the set of files for thisjob on that

new dev ices = nl ;

(Vv oleresources(job ) )if (Vdev icee dev ices

‘ready m ounted(dev ice) ne v ol) then

*Volume must bedev = arb {de devices I type (d ) eq

and m ounted(d) eq nl } ;i f dev ne 9 then job might be se lected*/

<dev ,v ol> in new dev ices;

else / *Not enough devices for this jobcontinue Vx(i) ; *Look at the next

end if dev ;end if (Vdev ice;

end Vv ol ;/ *Suffi cien t resources , and an improvement of the figure of meri t . Prepare tointerpre t JCL . First , update the tab les to account for the main memory to be usedby the se lected

if freesize(k) eq 0 then

1z) ;end if ;

/ *Create outpu t fi le for the newis output )

leave ’ }al loca te (output) ;

*Create a job contro l analyzersplit to jobm onitor> for thisprocess;

w orkload = testw orkload;

/ * Issue mount ing messages for volumes required by the se lected(Vv olse new dev ices)

m ounted(hd vols i s dev) new dev ices(dev ) ;

end Vv ols;go to new m erit; / *one job found now look for more*/

end disab le ;end Vx(i) ;

*No more jobs can be scheduled atgo to schedu le ;end scheduler ;

JO B CONTROL INTERPRETER

define jobcontrol ;/ *Job contro l now has an addi tional parameter transmi tted through initialv ar, the origin ofthe memory space assigned to the job . The size of the memory space is in the system tablecaUed

‘

spacefl*/

jobm onitor

processparam eter;

_93_

endjob : close (hd output,outputnam e) ; *User ’s output fi le i sunhook(outputnam e) ; /

*Detach i t from job contro lenqueue outfi le on outspool formov ; / *Pass output to outputunhook(inputnam e) ;USC I

’

pI’

O CC SS outuserprogs;

enqueue nl on scheduler for thisprocess; / *Reawaken thejob ’s volumes to be

(disable )*Update the estimated workload* /

(Vye esttim e(job ) )-y; /

*Overal l workload */—y; /

*Multiprogramming—se t workload */end Vy(i) ;

/ *Update the system table of avai lab le memory space by marking the space of the terminated job as free . I f tw o or three blocks of free memory are contiguous , combine them intoone large free

e freeloc x lt origin] ki f i eq 9 theni f origin+space(m ov ) eq freeloc( l ) then

e lse

freeloc = <origin>+ freeloc;end if ;

e lse i f origin then

if eq freeloc(i+ 1) then

end if ;

freeloc(i: <origin>+ freeloc(i:

end if ;term ;

end disab le ;

FILE MAP MAINTENANCE

define unhook(program filenam e) ;

/ * Indicate that the unhooked file i s no longer act ive on the physical device on which i tresides . I f no program fi le s are assigned to the device , indicate tha t the device does no thave a vo lume logica l ly mounted . However , vo lumes required by the scheduler asindicated by resource(job ) , are

if f ne program files ne m ounted(d)and not(m ounted(d) e then

_94_

https://www.forgottenbooks.com/join

Possible Enhancem ent s to the Batch System s

A varie ty of enhancements to the systems presen ted in Chapters I I I and IV can be made wi th

reasonable effort and without changing the systems ’ overall structure .

The input spool reader assumes that JCL is presented in standard SETL fo rmat ( see Appendix A) .

This assumption is made for pedagogical reasons to avoid c lut tering the code with parsing routines

which are only inciden tal to the system ’s structure . To accept conventional inpu t , the SETL read

sta tements a t ‘

m ainloop’ and ‘discard ’ i n inpu t spool should be replaced by the SETL record

statement to get the 1CL sta tement as a string of characters , fol lowed by a cal l to a parsing routine

which converts the string to SETL structures . A more versat i le JCL macro system which allows

addi tional parameters to be passed appears in the interactive system of Chapter V .

The se t of operator commands is qui te limi ted . Rather than just a l lowing a ‘hi priori ty ’ command

to advance a se lected job to the head of the scheduler’s queue , we can a l low the operator to

request the fo llowing :

a ) Reassign priori tie s to jobs in the scheduler’s queue ,

b ) Terminate running jobs ,

0) Remove jobs before beginning execut ion ,

d ) Prevent printing the ou tput of a completed job ,

e ) Terminate the print ing of undesirable output .

Enhancement a ) requires that we overwrite priori ty( j ) for job j based on the operator’s input . To

be e ffective , the schedu ler must a lso be modified to take the priori ty data structure (which is

already being maintained by the system) into account .

Modification b ) requires that we determine the process-id of the job which the operator wishes to

terminate , and simula te a sta tement . Enhancements c ) and d ) merely involve

examining the w orkqueues for the scheduler and outpu t spool , and purging the appropriate i tem .

In case c ) , we also require some bookkeeping opera t ions which purge certain system data

structures of i tems re lated to the cancel led job .

I t is more difficu l t to implement a command allowing the operator to suspend a running job until a

la ter t ime , whi le a l lowing o ther jobs to run . Device-posi tioning must be saved in case other

vo lumes are mounted on a suspended job ’s I/O uni ts , and , i f our multiprogramming system runs on

hardware which does not support moving executing programs from one place in memory to

another , then the job wil l have to occupy the same memory locations when it is resumed .

The operator can also play a greater role in describing the status of the various hardware compo

nents to the operat ing system . By declaring certain components as being unavai lable , the operat

ing system could continue in a degraded mode in which jobs requiring the unavai lable devices

would be de layed , while other jobs could be run . We could also al low the operator to override the

system ’s device a l loca tion given in mounting messages,al though thi s can be tricky , since the

system amy have made addi t ional a l location decisions based on the one which the operator has

overridden .

—96

The device allocation features of our batch systems can be strengthened in several ways . First , a

better choice of device on which to mount a vo lume can be made by try ing to balance the load on

all channels having identica l devices . This i s a re lative ly easy modification,requi ring use of the

‘channe l ’,

‘unit s ’ , and‘

estw ork’ data s tructures . Alternative ly , the operat ing system need not

dictate to the operator which of several ident ical unit s to use for volume mounting . The operator

can indica te hi s choice of uni t via a command , or, i f the hardware genera tes a dis t ingu ished

inte rrupt at the conclusion of mounting , the software can deduce the device chosen without further

interaction by the operator .

Another a l locat ion prob lem arises when a data fil e being wri tten becomes larger than the declared

fi le size . The ‘ readwri te ’ sect ion of the moni tor se rvices rou tine detects thi s condition when the

logica l f i le posi t ion is compared to the maximum fi le size . At this po int , the‘ al locate ’ rout ine

wou ld have to be invoked . Some care in design is needed to avoid endless recursion , since‘al loca te ’ uses I/O . The ‘allocate ’ rou tine should probab ly give preference to free space on the

vo lume (s ) on which the fi le a lready has i ts extent ( s ) . The cata logue ’s structure already permit s

mult iple ex tents for a file (i.e. non-contiguous b locks) , but our systems do not exploi t this .

Severa l al ternat ives exist to the schedu ling and dispatching algori thms used in the systems which

have been presented . In our sample code , al l schedu ling decisions are reserved to the scheduler ,

with very minor interaction from the JCL inte rpre ter in the uniprogramm ing system to achieve

overlap of setup time . Hence , experiments wi th schedulers can probably be carried out with no

structura l change . Dispatching decisions are almost ent ire ly confined to the dispatcher . In some

ins tances,after a moni tor service rou tine comple te s an act iv i ty , i t does reactivate i t s ca l le r by

placing i t direct ly on the CPU w orkqueue . In experimenting wi th dispatchers , some care regarding

such modificat ions of the CPU w orkqueue may be needed .

More difficul t , pervasive changes are required to add consis tency checks to the operat ing systems .

Such checks are almost tota l ly absent in the code presented here , although these checks are the

only software analogue to hardware error detect ion circui try . As an example , the rereading of JCL

by the JCL interpre ter has no error checks , because i t operates on the assumption that input spool

wou ld have rejected the job i f i t con tained JCL errors . This assumpt ion ignores possib le I/O

errors on the one hand , and possib le processing e rrors on the o ther . There are also many instances

in the I/O in terpre ta t ion part of our code where the system data structures are assumed to always

correct ly represent the state of the I/O'

dev ices, al though this can be checked by inte rrogating the

I/O devices’ sta tus

System support functions are lacking . A bootstrap loader i s required to load the first port ion of the

opera t ing system when the conso le load-button is pushed at the start of opera tions . Because of the

extreme machine dependence of such programs , no dict ions have geen put into PSETL to desc ribe

the necessary actions .

I n any actua l opera t ing system i t wi l l from time to time be use fu l to recla im unused space on

shared secondary storage volumes . That is , the fi le s should be rearranged so that a l l the unused

space is contiguous . A program to carry out this function can be wri t ten to run under the operat

ing system,provided it can be given specia l privi lege to access the system ’s catalogue . I t can be

implemented most easily as a ‘ stand-alone ’ program , that i s , a program not mul t iprogrammed with

_97_

other act ivi ty . However , i t can also run mult iprogrammed , but i t must then interact wi th the

scheduling and a llocation routines to avoid dis rupting fi les already in use .

Our systems have been wri t ten as though al l the system ’s data structures were resident in main

memory . Often this is impractica l , and the operat ing system must resort to I/O to access these

st ructures . With some care,our implici t assumption about main memory residence can be removed

without major modi ficat ion of the code . References to non-resident data structures become

subprogram cal l s , and for each such structure a subprogram is requ ired to manage i t . I f thi s

approach is adopted,then some care wi ll be required to conform to our restrict ions on the use of

disabled blocks .

In rea li ty , computing systems have fini te storage resources . In recogni tion of this limi tat ion,users

cannot be allowed to speci fy arbi trari ly many fi les of arb itrary size which are to be cata logued by

the system . A limi t should be set on the tOtal storage which a user ’s fi le s may occupy ; this limit

should be enforced by ‘ allocate ’ . Simi larly , a limit should be placed on the number of fil es which a

user can enter in to the system catalogue,for to do otherwise would require the cata logue to grow

to unmanageable proportions,and the time to access information in the cata logue would become

excessive ly long . Am ong the methods which can be employed to determine each user ’s l imits are :

divide the ava ilab le resources equal ly among al l users , require the system adminis trator to speci fy

maximum allocat ions for each user,assign addi t ional space to users w ho access a high percentage

of their fi les , and require owners of inact ive fi le s to copy them from shared volumes to private tape

and to drop the fi le from the cata logue .

— 98

https://www.forgottenbooks.com/join

management depends on many factors : performance requ irements , limitations on the fraction of

primary storage avail ab le to any one user , and the hardware addressing scheme .

Dev ice Type Access Tim e Capaci ty (bits/dev ice)

106 to 108

107 to 103

107 to 109

107 to 109

Table Typical Memory Hierarchy Device Charac teris tics

Comm and Language

Si nce the user i s interact ing with the system , there i s le ss need for him to put together a sequence

of commands to be performed without further user action . Commands wil l therefore be trea ted as

imperatives,to be executed immediately . The command language wil l be signi ficantly richer than

that defined for our ba tch system ; we wi l l i n troduce a more genera l command structure which

allows each user to also introduce his ow n commands .

A comm and will have the form :

where ename is the command ’s name ( the verb of an imperative , so to speak) , and are

arguments . Corresponding to ‘ename ’,there must exist a fi le in a l ibrary , which consists e ither of

an executab le program , or of a sequence of more primi tive commands . I n the firs t case , the

program is executed and passed the parameters . In the second case , each command in turn gets

executed wi th the arguments substi tu ted for parameters in the l ibrary commands . We wil l also

provide for commands to be invoked from running programs by means of moni to r ca l ls . The

comm and shown above can be invoked from a running program as fol lows

moni tor ( ch ame , a ] , a2, an ) ;

With this facil i ty the user can be spared the trouble of issuing standard commands ; an auxil iary

program can do this for him .

I n the system to be described , the code needed for carrying out the various commands i s no t

genera l ly kept in main memory . Command in terpretation makes use of a loader which moves the

appropriate code to carry out the command to an availab le portion of main memory .

The interactive system to be described avoids many of the JCL—re lated complicat ions which arose

in connection with the previous systems,because commands are analyzed only once . In the batch

system , JCL is first analyzed by‘ input spool ’ , which col lects information about a job into system

tab les . The scheduler uses these tab les to make i ts schedu ling decisions , and the job contro l

- 100

in te rpre ter checks these s ta tements again , perhaps bypassing condi t ional job steps , and also

specifying the devices on which certain fil es should be mounted .

In the in teract ive system , comm ands are executed imm ediate ly after analysis . A reference to a

dismounted f ile w ill cause an opera tor message to be issued , and the user wil l expe rience a delay

until the mounting can take place . However , i n a well designed time-shari ng system ,the vas t

majori ty of active files are always kept ou-li ne . To make this possib le,the operating system must

inc lude code which allocates on-Iine secondary storage among users and which causes inactive files

to be automatica lly moved to archives which either are on-line but have very long access t imes , or

which are off-line . (This aspect of storage hierarchy management is not shown in the code which

follows . )

Having said all this , we now go on to lis t and describe the most signif icant‘prim it ive ’ commands

,

al l of which we assume to be provided with the system .

Logon

The logon command has the form

-name>

where user-name is the st ring of characters by which the user identifie s him se lf to the system . The

logon comm and must be the first comm and issued in a user session . (A" session" i s the interact ive

ana logue to the batch system ’s I f the logon-program finds that the user ’s name is in i ts se t

of valid user names , i t wil l ask the user to produce a password , i.e . a second identifier known to

the user , but presumably not to any other user of the time sharing system . The password provides

an extra measure of securi ty for the i nteractive user against unauthorized use of his files or his

resource budget .

We point out that a password as a means of iden ti ficat ion is necessary , because i t will be inconv en

ient to have users keep the ir user-names secre t . I t wi l l be advantageous to have users comm unicate

among themse lves , and the user-names wil l be the means by which they identify themselves and

the other users with whom they wish to communicate .

I f the password given is correct,the logon-program executes the comm and ‘ se tup ’ . This allows the

user to au tomatica l ly have certain act ions performed on his behalf whenever he start s a session ,

rather than to have him re issue comm ands manually for these actions . Of course , i t i s the user’ s

responsibi l i ty to define a file cal led ‘ setup ’

. I f none exis ts , then no addi tional action is taken by the

logon-program . After ‘ setup ’ is execu ted,the system awai ts a command from the user .

Logoff

The logof f comm and has the simple form

I t is used to end a session,and is a signal to the system that memory space and CPU tim e will no

longer be needed by the user w ho logged-off . I n addi tion , i f there is a hierarchy of devices on

which files are stored , the user’s fi les may be moved to a s lower level of the hierarchy .

— 101

MainMem ory Structure

I f we were to assume that the programs forall active users fi t in to main memory , then certain ve ry

signi fi cant prob lems of memory alloca tion and performance which ari se in connection with

interact ive systems would be hidden . We therefore choose to represen t ‘memory management ’

i ssues explicit ly , and to assume that the total user demand for main memory exceeds the supply .

The memory management scheme chosen for use in connection wi th any part icu lar t im esha ring

system will a lways depend on the nature of the hardware . For simp lici ty in the treatment to

fo llow , assume that our hardware has a base and bound reloca tion mechanism , in which a base B

and a bound L are speci fied . A reference to main memory loca tion x wi l l be treated by the

hardware as a reference to x+B ,provided that x<L . An error interrup t resu lts i f s .

We wil l assume that there i s a component of the environment called re locate which contains the

appropriate pair <B ,L> for the process . The code for a running process p may be moved from

one contiguou s area of memory to ano ther , so long as the fi rs t component of

is adjusted accordingly . Such a re location scheme makes i t possible to

force all running processes to one end of main memory in order to leave a contiguous block of

unused memory of maximum size .

Long running processes may be preempted in order to permit newly started commands to be

executed ( see Such processes may have their main storage contents copied to a slower level

of the memory hierarchy unt il the scheduler tries to resume execu tion of the process , at which time

the memory contents are copied back to an appropriate ly large , available , block of main memory ,but not necessaril y the same area i t had occupied previously .

When the operat ing system exploi ts the memory re location fea ture , i t wi l l move user areas wi thin

main memory , or between main memory and secondary storage . To show this code , we need a

dic tion which a llows us to reference specific loca tions in the main memory . We wil l use a specia l

variab le , m em ory, to represent a ll of main memory as a vector . Consecutive components in the

vector are contiguous loca tions in main memory . References to m em ory are not re located ; thus the

operating system can control memory even if i t s re location base is non-zero . Processes which do

not have system privi lege cannot access m em ory .

The File System

Users , communicat ing with the computing system from a terminal , possibly at a remote si te , wil l

prefer to keep their data in the system ’s memory hierarchy between sessions . Thi s data includes

not only information to be processed by the user ’s programs , but a lso his programs , both in source

and object forms , part ia l resu l ts for future computat ions , and fi les of commands . We will refer to

this col lect ion of information as the ‘ file system ’

.

The file system is the most important component of a t im e sharing system . With its loss , a user

communi ty would have to reconstruct all i ts data and programs to become operational . With the

fi le system intact and a loss of the CPU,a substi tu te CPU would enable the user communi ty to

work ; si nce the users are remote from the CPU , the subst i tu te CPU need not even physical ly

replace the original one . I f al l user programs are in a higher level language in which underlying

— 102

https://www.forgottenbooks.com/join

In the above example,the program file nam e p is associated with user fil e f . The relation between

a program file name and a user file name holds only throughout one session or unt il the program

file name is redefined during the session .

Since comm ands may be executed by running programs , many programs will be designed to issue

file , erase , and def ine comm ands and relieve the user from explici t ly giving such commands from

the term inal .

Comm unication betw een Use rs

In our previous discussions of opera t ing systems , there had been a strong emphasis on the

separat ion of users . The boundaries port ion of an env ironm ent (cf . section was devised to

limit a user’ s reference to his own port ion of main memory ; the re location mechanism (Sec.

likewise restrict s a user to his allocated memory . The fi le naming scheme of sect ion and the

support ing tab le structure of prevent a user from accessing fi les other than his own .

With mult iple users on-Iine ,the use of the comput ing system as a comm unicat ion medium becomes

feasib le . First , we can sim ply allow messages to be passed from one user to another by a simple

command such as

This wou ld result in

‘From u2: text ’

prin ting on ul’

s terminal , where u2 i s the user-name of the user who had given the‘message ’

connnand.

A more interest ing aspect of comm unication is the sharing of files . We provide a command by

which a user may speci fy that a certain file may be used by other users

where f is a user fil e name , 5 is a se t of user names , and c is a se t of codes designating the types of

access which may be made to the fi le,e . g . read , wri te , execu te , or erase . I n the case of execution

access , the fi le is avail able only to the system loader when used by a Sharer . That is to say , read or

write requests wi ll be rejected if issued by a sharer ’s process .

A user u2 w ho i s pe rmit ted access to a file be longing to 111 indicates the name he gives to the

shared fi le by a command such as :

where ufu2 i s the user file name by which user u2 will refer to the file , and ufnl i s the name which

the owner 11] had given to the fi le . The effect of permit and share commands remain in force

across user sessions , unti l permission to share i s wi thdrawn by means of a permit command

specifying no access codes , or by dropping the user file name of a shared file from the cata logue .

- 104

We also allow a user who is sharing a file to permit others to share the file , providing that he only

a llows those types of access which he him self had been permit ted to use .

To support fil e-sharing we must use a more complex catalogue than would otherwise be necessary .

For each file f, i s a se t of pairs of the form where u is a user (other

than the owner) , and r is the set of access rights which user u has to file f . For an unshared file ,i s 111. I f a fi le g resu l ts from sharing user v

‘

s fi le h,then

eq whereas i f g does not resul t from sharing , eq

(2.

Libraries

Related data file s may be organized into a structure which we w ill call a library . A library is a fil e

whose contents is a list of fil e names . This structure facilitates transmission of a set of files to a

subprogram or to another process . Libraries may be shared between users in the same way as

ordinary fi l es are . When a user i s a l lowed to share a library , all the files in i ts index become

accessib le to the Sharer .

The operat ing system itse l f consi sts of several librari es , some of which only i t may access,and

some of which are access ib le to users . The subprograms which interpre t the various opera t ing

system commands are kept in a li brary of re locatab le programs . Programs of use to the general

user communi ty are kept in system l ib rari es to which al l u sers have read and execu te access

privileges . A user who develops a package of routines which he fee ls is useful to others can create

a library and permi t similarly general use of i t .

Certain system rout ines wil l search sequences of libraries for part icu lar files . Examples of such

rout ines are those involved in comm and inte rpretat ion , program loading ( subroutine libraries ) , and

compi lat ion (macro l ib rarie s) . Associated wi th each such rou t ine and each u ser i s a vector of

libra ry names . I ni t ially , the vector may conta in only the name of the system supplied library . By

using a ‘

searchorder’ command , the u ser can rep lace the vec tor wi th one of his own , thereby

causing his l ibrari es to be searched . To avoid hi s having to remember the name of the system ’s

library , an is used instead . Thus , i f a user wants two of his l ibraries to be searched in program

loading, one before the system library and one after i t , he would give the comm and :

<‘

searchorder loader

The e ffect of a searchorder command remains in force unt il ano ther searchorder comm and is

issued for the same function , or unti l the end of the current session , whichever comes first . I f a

user wishes to estab l i sh certain library search orders as a matter of course , then corresponding

commands should be made part of that users ‘ setup ’ file ( see so that they will be issued

au tomatically at the start of each session .

Organization

Our system will be divided into three major portions : a nucleus , privileged system comm ands , and

non-privileged system comm ands . The nucleus i s always present in main memory , has a re location

base of 0 and access to al l main memory . Privi leged commands and non-privileged commands

have a non-zero re location base and thus cannot direct ly access all the system data , but special

- 105

monitor services enab le them to access part of this data . Non-privileged commands are indistin

guishable from user programs .

The Nucleus

The nucleus cons ists of interrupt handling programs which are large ly concerned with scheduling,the t imer , dispatching , creat ion and te rmination of sessions , main memory management and

comm and interpretat ion . There are monitor services which a llow user and less privileged port ions

of the system access to I/O and timer functions , etc . (See for a description of these services) .

In addit ion , there are monitor se rvices which allow privil eged comm ands access to system data .

All unused terminals are monitored by a special nucleus process , which upon reading a li ne from a

te rminal verifies that a valid user has issued a logon comm and . In this case , a mover is created , and

that mover is initi alized to execute the comm and inte rpreter .

The scheduler se lects a subse t of non-waiting processes as eligible to run . Multiprogramm ing takes

p lace only over this subset, under control of the dispatcher , until the scheduler al ters the subset of

e ligi b le processes . This subset is a l tered when a process te rminates or i s created , when demand on

the memory hierarchy changes , orwhen a member of the current set of eli gible processes exceeds a

bound on the amount of serv ice received . When a new process becomes e ligib le , memory

management may be invoked to make room for the process , either by moving main storage areas

for running processes toward the lowest numbered memory locations in order to create a large

block of unused main memory , or by copying the memory of ineli gible processes onto secondary

storage .

The dispatcher allocates C PUs to e ligible processes . A clock and an interval t imer are used to

contro l the amount of uninterrupted CPU time given to a process ; the dispatcher generally gives

short bursts or quanta of CPU servi ce to the eligible programs in round-robin fashion .

The comm and inte rpreter for our t im e sharing system (which comes in to play once logon has been

successfu lly comple ted) uses the user’s vector of command librari es to dete rmine which libraries to

search for the fi le defining a part icular comm and . I f a command fil e consi sts of further comm ands

rather than a program , then the command interpreter i s invoked recursive ly . I f a comm and file is a

program , a block of contiguous memory of appropri ate size is a llocated to the user , the system

loader moves the program into this b lock , and control i s given to the program , which is initially

given high priori ty for scheduling consideration . The base and bound for the program are se t so

that direct reference can only be made to main memory allocated to the program . I f the program

was loaded in response to a p rivileged command , then the program has additional monitor services

avail ab le to manipulate system data .

Priv ileged System Comm ands

Priv i leged system com mands include ‘ logoff ’,the f il e system commands described in and

memory hierarchy management comm ands . These comm ands , being privileged , can use PSETL

disab le blocks to guarantee orderly use of shared se ts , such as the catalogue . In this implementa

tion , these commands are interpreted by subprograms to the command analyzer which are in the

scope of the system nucleus . Thus , the system data structures ( see and are

accessib le to these subprograms .

- 106

https://www.forgottenbooks.com/join

process is running . Initialization ends by executing a ‘ se tup ’

comm and ;this automatica lly executes

the user ’s se tup procedure if one exi s ts , after logon .

In the comm and ana lyzer routine ‘source ’ i s a vector of inpu t fil e identifiers , the first component of

which is the current inpu t file . This vector se rves as a pushdown stack of file names , new names

being added to the head of the s tack whenever a command invokes a fil e of commands ; names are

dropped from the head of the vector whenever the end of a fi le of commands is reached .

With the exception of the simulated read of the se tup com mand , al l comm and reading takes place

a t the labe l ‘

readdata’

. I f the command is read from a command fi le rather than the terminal ,references to parameters are replaced by their values . Parameters are encoded by a followed by

an integer . The integer describes which of the arguments o f the command which invoked the

current input source is to be substi tu ted . The string of arguments from that command are saved as

the first component of ‘

argum entstack’

.

Analysis of a command begins at the label ‘ lookup ’

. I f the command name is that of a buil t-in

command , then the code corresponding to that command is execu ted . O therwise , the l ibraries

pertaining to commands,modules

,and text are searched , in that order , for an object whose name

agrees with the command name .

I f a comm and-fi le is found whose name agrees with the command name , then at label‘

foundc’ that

fi le becomes the new input source for the command analyzer , and the remainder of the original

command gets saved as the firs t component of ‘

argum entstack’ to substi tu te for parameters

encountered in commands read from the new source .

I f a command name is found to refer to an executable main memory image (we sha ll ca ll these

images ‘module a block of main memory of sufficien t size is reserved for the module , and

the modu le is read into main memory . A state descript ion for a user program is created ,and

re loca tion boundaries are se t up to restric t memory references to the block of storage just obtained

for the modu le . A process for the modu le i s ini t ia ted , and the command analyzer ( tha t i s , the

command analyzer instance working for the user whose command was just read ) waits for an i tem

to be placed on i ts w orkqueue .

There are tw o ways in which an i tem can become enqueued on the command analyzer ’s

w orkqueue . When a user process terminates execution ( see the‘abend ’ and ‘

endstep’ moni tor call s

at the end of the code of Sec. the terminating condi t ion is enqueued on the command

analyzer and the ancestor of the terminating condit ion is se t to nl .

When the command analyzer is being invoked recursive ly by a user process , then the arguments for

the command are enqueued on the command analyzer on behal f of the process which issued the

monitor ca ll (see sect ion The current user process i s suspended , and a new user process i s set

up . Then ( at after the recursive command has been obeyed , the former user process i s

reactivated .

To prevent endless recursion of commands and to l imi t the amount of secondary storage space

which a use r can occupy , a maximum of ten leve ls of recursion are al lowed . I f an e leventh i s

requested , execu tion of a l l leve ls of recursion terminate , after which the user may enter a new

command from his terminal .

- 108

I f a tex t-fi le ’s name agrees wi th the comm and name , then an object fi le ( that is, the machine

language outpu t o f a language proce ssor) exi s ts to carry out the command . The dist inct ion

between a tex t fi le and an module file is thi s : the module is an image of the initi al s tate of main

memory of code which can be execu ted . A text-fil e is the output of a compiler , and may have to

be combined wi th compi ler ou tpu t for mi ssing procedures before an execu tab le memory image

exists . Thi s processing is carried out by the loader . When a command refers to a text file , the code

at label ‘

foundt’ prepares to load the system modu le corresponding to the loader, and then causes

the loader modu le to be fe tched . The loader , when i t executes (not shown here ) take s the

command data as input to determine which text fil es are to be loaded .

Main Storage Managem ent

The procedure getblock i s a queued subrou tine which finds and al locates a b lock of main memory

to a process . I f the size of the requested block is too large , then getblock im mediately returns (2.

The getblock procedure uses three vectors to describe storage al locat ion . The vector m em loc gives

the starti ng loca tions for al l memory b locks , the vector memsize gives the sizes of the blocks , and

the vector m em ow n identi fie s the processes which own the blocks .

First getblock at tempts to sa t i sfy the request wi thout re locating any b locks of memory . I f an

unowned b lock of at leas t the reques ted size exis ts, a memory block of the required size i s

al located to the process speci fied by P .

I f a sufficient ly large block of contiguous s torage does not a lready exis t , then the disabled block

fo l lowing the label ‘

addup’ computes the tota l amount of unused storage , and if enough storage

exists,then the a l located blocks of memory are moved to lower addresses in order to col lect all the

unassigned memory into a cont iguous b lock . As each assigned memory block is moved , the

re loca tion port ion of the environment of the process associated with that storage block is adjus ted

to reflec t the new base of the process ’s main storage .

I f insufficient free s torage exists even after compac ting used s torage , then those blocks of main

storage be longing to processes which are considered ine l igib le for schedul ing are marked as

belonging to the reques t ing proce ss , and the contents o f those b locks are saved in secondary

storage . The statement :

m ust= 3y(j ) e extstore I y eq pr ;

se ts j to the number of the block in secondary storage which is devoted to holding the memory

image of a process pr which i s be ing disp laced . The string ‘

secondarystorage’

represen ts the

system fi le which holds the memory images of processes which have been preempted from main

memory,and extstore i s the map which determines where in the secondary storage area a process

’

s

memory image is saved .

I n any case,once a block Of s torage has been found , contro l reaches the block of code label led

‘ fina l ’,where the memory maps are updated to reflec t the assignment just made .

— 109

Scheduling and Timing

An eligible process i s one which can run given main memory space and control of the CPU ,but is

not momentaril y being considered for control of the CPU by the dispatcher . The scheduler uses

two work queues of e li gib le processes . The firs t queue ,‘

hiprio’

, contains the identi fiers of

processes which the system assumes are of high priori ty . System processes , and processes which

had been started as the resu l t of commands issued from a te rminal bu t which have not used more

than a predetermined amount of resources are queued in ‘

hiprio’

. Processes whi ch have exceeded

the threshhold which separates quick runni ng from long running i nteract ions are queued in‘

low prio’

.

The scheduler wai ts unti l ‘

hiprio’ and ‘

low prio’ are not simultaneous ly empty . I t then cal l s a

subroutine , sebed, passing the highest priori ty , non—empty work queue as an argument . Note that

sebed and getblock must not interfere wi th each other during execution . Without care , this could

occur , since getblock looks for eligib le processes which have main memory blocks assigned , and

seizes these b locks to carry out i t s function , whi le sebed must determine i f the process i t has

se lected is already in main memory . To avoid interference , both subroutines are queued on the

same facil i ty ,‘

blockflag’

. I f sched determines that the selected process is not in main memory , i t

call s getblock to reserve a memory area of sufficient size , and adjusts the relocation portion of the

se lected process ’s environment for i ts new memory assignment . Finally , sebed resets the t im e used

in the current time slice to zero ,and i t p laces the schedu led process at the end of the C PU ’

s

w orkqueue . The scheduler attempts to schedu le more processes so long as processes remain in the

queues hiprio or low prio , and so long as memory is avai lable .

Control goes to the block of code labelled ‘

tim expt’ whenever there is a timer interrup t . I f a user

program was in terrupted , the t ime used since the in terrup ted process has been dispatched is

computed and added to the tota l t im e used duri ng the current t im ing period . I f this total exceeds

the time quantum" al lowed for the process then the CPU t ime used during the current timing

period is added to the tota l CPU time used by the process . I f additional quanta remain in the time

slice , a new timing period is begun for the process and the process is placed at the

end of the dispa tcher ’s queue . I f no quanta remain , then the process’s t ime s l ice has ended .

Subsequent tirneslices will consis t of one second , and the process i s placed at the end of the low

priority queue of eligible processes .

The tim er interrupt handler then term inates , which forces contro l to the dispatcher , which wil l , in a

round robin fashion,se lect the next dispatchable process . The purpose of dividing time sl ices into

quanta i s to guarantee that among dispatchable processes , none must wai t an intolerab le amount of

time before gaining access to the CPU . Thus a trivia l request which can execute in one quantum

wil l always appear to respond quickly (once it i s made dispatchable) .

- 110

https://www.forgottenbooks.com/join

The Code

Catalogue of Routines

Log-onThe logon process controls all te rminals which are not in act ive use . I t wi l linitiate a user session for a user who comple tes a logon sequence on any suchterminal .

Comm and AnalyzerEach user session is controlled by a command analyzer process . The commandanalyzer reads and interpre ts user comm ands , and can al so be invoked recursively from a running program .

LogoffLogoff ends user sessions .

Message C omm andsThe message commands are used to send messages from one user to another , andto suppress or accept messages from other users .

File HandlingThese subprograms inte rpret the comm ands pertaining to fil es , including‘permit ’ and ‘ share ’ .

FileThis routine sets up a file description in the catalogue .

DefineThis rout ine estab lishes a program fil e name for a user file name .

ShareThis rou tine makes the necessary entries in the catalogue to a l low oneuser to share a file of a second , so long as the second had previously givenpermission to the first user . The routine i s recursive to allow a ll membersof a library to be shared by mere ly sharing the library file .

PermitThis rou tine i s ca l led when a user gives permission to other users toaccess his files . The routine is recursive to allow all members of a libraryto be permit ted by just naming the library i tse lf .

EraseThis routine removes a file from the catalogue and relinquishes space he ldby the file .

Getblock

Getblock finds and a llocates a b lock of contiguous storage for a process . I t maymove other process ’s storage blocks in main memory or from main to secondarystorage to satisfy the request .

SchedulerThe scheduler se lects the highest p rio ri ty non-dispatchable process , causesmemory space to be allocated to that process , and puts the process a t the end ofthe dispatcher ’s queue for CPU service .

DispatcherThe dispatcher makes those processes in w aitset whose wait condit ion have beensa tisfied , dispatchable . I t then se lects a process to run on the CPU .

Tim er InterruptUser processes whose execu tion time exceeds a threshhold are pu t in to thescheduler ’s low priori ty queue .

Moni tor ServicesThese processes in terpret I/O requests , comm and termination , and recursiveinvocation of the command analyzer by running processes .

- 112

page 115

page 117

page 125

page 127

page 129

page 130

page 132

page 133

page 134

page 134

scope interactiv esystem ;

macro

/"For user file uin, a program fil e name pfn is establi shed for the running process , and filev arbecomes a file variab le representing the fil e*/

is pfn>

filev ar= <open pfu.1> ;

endm establish ;

macro processparam eter;

/ * reference a processes initial argument*/

endm processparam eter;

macro fi lesize ;*defaul t s ize of standard system-created file s*/100

endm fi les ize ;

macro prim arysource ;* for the inpu t reader , reference to main inpu t device*/

endm prim arysource ;

macro prim aryposition;

/* for input spool posi tion in the primary file nex t to be read*/

endm prim aryposition;

macro currentsource ;* for input spool

, the current inpu t program-fi le name*/hd hd source

endm currentsource ;

m acro currentposition;

/ * for inpu t spool , the current posi tion in the inpu t file */(hd source) (2)

endm currentposition;

macro readingprim arysource ;

/ * t rue i ff curren t source is the system input device */#source eq 1

endm readingprim arysource;

macro thisprocess;

more mnemonic way for a process to refer to i ts ow n processC PUcontrol

endm thisprocess;

m acro dev iceaddress(pfn) ; / *device on which program fi le resides*/

endm dev iceaddress;

macro dataread; / * to access data read from term ina l*/buffer bufferfor(term inalnam e)

endm dataread ;

macro dev icepart(x) ; /“program file causingx( l ) / * first component of x , cf .

endm dev icepart;

— 113

m acro w ritetoterm inal(terminal, message ) ;buffer bufferfor(terminal) message ; / *Set up terminal buffer*/moni tor terminal ,

endm w ritetoterminal ;

macro m axm em ;

10000 / *Machine and operat ing system dependent -m axirnum size of a main s torage b lockwhich can be assigned to a user

endm m axm em ;

macro freesecondarystorage(p) / *Releases secondary storage held by process(disable )must : 1 5 ij 5 #extstore I extstore(j ) eq p ;/ *The above s ta tement se ts j to the posi t ion in extstore corresponding userprocess p . I f p is a user process , then j wi l l be

extstore( j ) 52; / *Release secondary storageend disab le ;

endm freesecondarystorage ;

macro tick ; / * short time sl ice quantum */100000 sec for CPU with a

endm t ick ;

m acro onesecond ; / *The number of timer uni ts in one second */1000000 / * assuming a CPU with a Iris .

endm t imer ;

m acro xquant; *Number of quanta we wi l l al low a process a t high priori ty */5

endm xquant;

macro m ov erpart(pr) *extract mover i.d. from a processhd pr

endm m ov erpart;

m acro suspendedprocess;

/ *Most recently suspended user process , gotten from top of

endm suspendedprocess;

m acro recursiondepth;*Depth of recursion when most recently suspended user process

endm recursiondepth;

m acro pair(x) ;*This macro generates a boolean expression which is true i f and only i f x is a tuple of two

( type x eq tuple ) and #x eq 2endm pair ;

/ *The global variables declard be low are described in sectionglobal iow ait, m ainstate , busystatus, sav ecause , filew ait, fixup logicalposition, channels , uni ts ,volumes , program files, devices , type , userprogs, steptim eleft, ready , mounted , dev iceaddress,

sym bolicfile, Operat ional , users , owners , defau l ts , ca ta logue , m axprio , esttim e, t imelef t ,iofixup ,

w orkset, userfile , new allocation,budget ;

*The global variables declared below are described in sectionglobal extstore, m sgon, msg, secondarystorage ;

— 114

https://www.forgottenbooks.com/join

te rmina l interrupt handler .Processing to check logon command and password takes p lace in interrup t routine .

Note that since interrupt rou t ines are logica l ly non-i n terruptab le , there can be no racecondit ions in the fol lowing code

,even if several users attempt to log-ou with the same user

term fixup

/ *We define a function usem am egiv en from term i nals to user names . I t i s defined only forterminals which have received a val id logon-command , and are expect ing a

get cause of inte rrupt*/interruptreport buf fer interruptbuf ; / *See for a discussion of the buffer

/ *prograrnfilenam e which caused interrupt* // *cf . page 113 for the macro

term inalnam e out w aitingset; /* remove terminal from the se t of terminals

which have a log-on readmacro extracts line just read from terminal ’s buffer*/

im age = dataread;

i s a machine dependent macro which generates a true boolean expression i f andonly if the inte rrupt report indicates an

i f error(interruptreport) thenerrorcount(terminalnam e) = errorcount(term inalnam e) 1;

i f errorcount(term inalnam e) le 10 thenw ritetoterm inal(term inalnam e

,

‘

transm ission error , repeate lse / *Excessive ly many

/ *Try to warn user that h is terminal i s notworkingw ritetoterm inal(term inalnam e,

‘

bad terminal or line , removed for/ *cf . for

operator tha t terminal requires

unhook(term inalnam e) ; /*Release fi le name representing terminal“

/ *No longer expect ing a

end if ;else if usernam egiv en(term inalnam e) ne S2then

go to checkpassw ord; *password is expected */else i f not (pair(im age) and hd im age eq

‘ logon ’

) thenw ritetoterm inal(term inalnam e,

‘

im proper

else / *Attempt first step of logon operation verify that user id . i s/ * identify user* /

i f usernam ee (users signedon) then/"We have a val id user , w ho i s not already logged on . Note that since I/O fixupsare not logical ly interruptab le , even if severa l terminals simul taneously issue logonswi th the same user id , only the firs t terminal to have its in terrupt processed wil l beconsidered

username in signedon;

/ * indicate nex t read is to ge t password*/

w ritetoterm inal(term inalnam e,if usernam e eusers then ‘already signed on’

e lse ‘ invalid userend if username ;

end if error ;reread :

m onitor(‘

read

term inalnam e 1n w aitingset;* lndicate that a ‘ read ’ i s again

checkpassw ord*Reset error count , since previous read was

/ *Check theif image ne passw ord(usernam egiv en(term inalnam e) is username ) then

— 116

/ *Wrong password start the logon sequence allw ritetoterm inal(terminalnam e ,

‘

bad password , re-issue logon and t ry/ *Having had a bad logon attempt , we set up the terminal to start a new logon se

‘usernam egiv en(term inalnam e) will b e droppeduse rname out signedon; ‘ Another logon for ‘use rname ’ can now be accepted“

/ *Password ism ov erid = new at; /*mover—id for user*/ow ner(m ov erid) username ;processpart(comm andenv )/ *Here we are assuming that

‘

com m andenv’ is the descrip t ion of the comm and

analyzer ’s ini t ia l environment . Only the processpart must be given a unique init ia lvalue to start the comm and analyzer for the new user w ho has just logged

split to for thisprocess;

end if ;*Remove from map notwait ing for

unhook(terminalnam e) ;

end logon;

COMMAND ANALY"ER

scope comm andanalyzer;

each user who has successfu lly logged on , a command analyzer process has beencreated . This process reads commands from the user’s terminal or from a comm and-macrolibrary , and interpre ts these commands by :

1. obey ing the command direct ly ,2. loading a program ,

3 . accepting com mands from a macro-l ibrary .

When execu ting programs ( case a user process , of lower priv i lege , i s crea ted . Thisless-privi leged process contro ls the CPU during the execution of the user ’s programs . Auser program can also execute commands by using the mon i tor serv ices (cf .

Init ia lize User Defaul ts

com m andsetupterm inalid = processparam eter; get user ’s te rminal identi fier*// *Estab li sh

‘ te rminal ’ as a fil e name for the user ’sis

/ * Identi fie r for lower priv i leged process which wi l l run user

p rograms . All processes for this user session wil l be long to the mover/ *Derive the user

’s/ *Each user is assumed to have a file called

‘profi le ’ , which contains tw o st ructures : theuser ’s defau l ts for required parameters , and the user

’s libra ry searchi f e datafiles then

*The user has defined a profileestab li sh (

/ *The user doesn’t have a profi le f ile . Use the

profileopenclose, userprofile) ;end if ;

— 117

userprofile read defaul t ;userprofile read searchorder;

unhook(profileopenclose) ;*user profile is no longer needed*/

‘ I ni ti a l ize the stack of i nput sources used for recursive invocations of the commandanalyzer . ‘ source ’ i s a vector whose components are pairs, each pair giving the program fil ename of a fi le from which commands are being read and the loca tion within the fi le fromwhich the next command is to be read . Implementation note : In this code , i tems are addedto and taken from the front of vectors which represent

source terminal ,1/“argum entstack

’ i s a vector whose components are vectors of arguments to be used inmacro-command expansion . When a macro is be ing expanded , the components of

argum entstack( 1) are used for parame ter substi tu tion . See the code below , near the labe l

argum entstack: <nult> ;

/ * I ni tia lize procv ec,which is a vector of pairs of the form Each p represents a

process , ini t iated by the command analyzer , which has been suspended whi le a commandissued by i t (i.e . p ) i s being executed . n represents the number of recursive invocations ofthe command analyzer which had already been issued when process p issued the commandbeing in terpreted . n is used near ‘

readdata’

, below , to determine when p’

s command hasbeen

procv ec = nult;

infile = <open currentsource,1> ; / *currentsource is a macro“

/ *extstore i s an auxi l iary data structure used to map active user processes into secondarystorage . When an active process must be swapped out into secondary memory

,the user ’s

posi tion in extstore determines the location in secondary storage reserved for the processimage . The form of extstore i s a vector of process identi fie rs . The posi tion of a process-idin the vector is used by the ‘

getblock’ rou tine to determine where in secondary storage the

user ’ s swap area(disable )i f extstore eq Q then

extstore userprocess> ;

e lse i f I extstore(j )eq 12) then/ *Note that the preceeding ‘ i f ’ cannot fai l to be

end if ;end disable ;/ *In the main loop of the command analyzer

,

‘ image ’ wil l ho ld the l ine read from theterminal . We init ia lize i t to the string ‘ se tup ’ so that the user’s setup command is executedimmediately . cf . Sec .

/ *Simulate reading of ‘ se tup ’ command*/go to lookup ; / * to begin hand ling the

‘ setup ’ command forced in to the i npu t stream just

Main Loop of Command Analyzer

readdata

At this point , a prior command has just comple ted , and we read the next commandfrom the topmost command fi l e or from the terminal

,subs t i tu t ing parameters to get i t s

‘ true ’ form if necessary .

Before reading , however , we must determine whe ther a recursive use of the commandanalyzer , invoked by a running program ,

has beeni f proevce ne nult then / * recursive use of command analyzer‘

/"Recal l that the top element O f procv ec gives 11, the number of recursive invocationsof the command analyzer at the t ime when the most recent program-ini tia ted invocation of the command analyzer was received . I f the leve l of recursion is now n

,then the

interpre tat ion of a run-t ime command is comple ted . The curren t temporary u ser

— 118

https://www.forgottenbooks.com/join

we look for bu il t-in comm ands . All buil t-in commands are treated as subprogramsto the comm and analyzer , and they re turn character strings , which are transmit ted to theuser as a response to his

shorti f

(comm and) is routine ne S2 then/ *Com mand found . Execute bu ilt-in command and wri te the resulting message tothe user ’s terminal if the command was issued direct ly from the user ’s terminal . A llbuil t in comm ands are funct ions callab le by the command analyzer . These functions re turn character

tl image) ; * Inte rpre t command*/i f readingprim arysource then

/ *If the comm and was issued from the terminal , then wri te the resul tingmessage to the user ’s te rminal . I f there were no errors , the resul tingmessage is

terminal w ri te resu l t ;end if ;go to readdata; *Get next

end if ;

/ *Not a buil t-in com mand . The command libraries are searched next (for possible macroexpansion ) , then the module libraries are searched ( for a f il e containing an execu tab leprogram ) , and finally the text library is searched ( for compiler outpu t , which must first beprocessed by a loader (not shown here ) to supply missing

(Vlibtype(i) e library ( j ) e searchorder( libtype) )i f library eq then

/ *Use the system library . A share command is needed to make the system libraryaccessib le to this process , whi ch is running for a user

’s mover . cf . Sec+ libtype) ;

establish(‘

library.

end if ;tem plib read list ;if type li st ne set then

/ * Ignore the library if i t is in the wrongcontinue V libtype ;

end i f type ;unhook(tem popenclose) ;/ *See i f the requ ired comm and is in the li st of library

i f(Scomm andfilenam ee list I com m andfilenam e eq ( libtype+ + comm and ) ) then* library file found*/

go to

(Iibtype) ;end if ;

end Vlibtype ;

/ *The command cannot be found . I t i s nei ther bui l t in, nor a macro command , nor a

modul e , nor a text fil e . Warn the user , and go on to the nextcomm anderror

terminal w ri te ‘ illegal comm andz’ im age ‘ from fi le ’

,ignored ’

;go to readdata;

- 120

foundc: / *Enter here when a com mand refers to a file ofread comm ands from the comm and fil e named by the just-received comm and until an

end-of-file is detected at* remember posi tion wi thin cu rrent file“/

‘ Redefine ‘ in file ’ to refer to the library file which holds the macro-expansion of thecommand just

source = <comm andopenclose,1 + source ; ‘ Update the stack of input*Put the parameters from the cu rrent command on top of the parameter stack .

‘

argum entstack= < im age (2: argum entstack;

go to readdata;

foundm :*Enter here when a comm and refers to an execu tab le

assign is

fetchm odule: m odulefile = <open tem popenclose,1> ;

/ *We assume that modu les are se lf de scrib ing fi le s o f two records . The second recordcontai ns the code to be loaded and execu ted ; the first record give s the length of the

m odulefile read bound ;is a macro giving the size of the largest block of contiguous storage availab le

for assignmen t . I t i s machinei f bound eq 9 or bound It 1 or bound gtm axm em thenterminal w rite ‘bad module size’

+com m and+dec bound ;go to readdata;

end if ;/ *Secure a memory block for the module . This i s a lways possible in principle

,since we

have already checked that the amount of space be ing requested is not excessive,and no

other program wil l be allocated space until this request is fulfill ed . We could test ‘base ne9

’ after the next statement as a software

(disab le )/ *Construct ini t ial state for the program to be

/ *Standard non-priv il eged/ *Location and size of a llocated main memory into

relocate(state(userprocess)/ ‘ Read module i nto assigned memory locations . Recall that m em ory i s a vector representing a l l of main memory . cf . section

m odulefile read/ *Initialize

'

tim ing i nformation . xquant i s a macro giving the number of tim es the userprocess i s to be schedu led at high priori ty in a round robin fashion at the start of a command . Each time scheduled , the process will be al lowed one

‘ t ick ’

, where‘ tick ’ i s defined

via a macro . A typica l va lue might bei f readingprim arysource then

/*The com mand being inte rpre ted was en tered direct ly from the user’s terminal . Start

the user process a t h igh priori ty . For o ther commands , i nvoked recursive ly or byrunn ing processe s

,thi s then-c lause i s skipped , and the previous t iming parameters

remain in effect . Thus , i f the most recently i ssued user command has used a great dealof CPU t ime seconds

,in thi s version ) , the user

’ s processes will cont inue to run atlow priori ty , unt il he enters his nex t com mand from the

/*See macros for

nquant(m ov id) = 1; /* I ndicate this is the first quantum *// *and that no time has been u sed so far*/

*put process at end of schedu ler ’s h i priori tyend if readingprim arysource ;/ *We assume that execution starts at re lative location

= 0;

/ *Place ancestor and init ia l parame ters into the user process environm ent . I nc lude theterminal id. in the set of ini ti al

— 121

split to for thisprocess;

end disable ;unhook(tem popenclose) ;

*Release fi le containing program/ *Wait for the user-process to te rminate . We could , at thi s point , associate , with the user

’sterminal

,a fixup rou tine which

,on recognizing an at tention reques t from the terminal ,

reads a line from the terminal to determine whether the execu tion of the user-commandshould be preem ptorily

waitingaw ait getfirst(thisprocess) is fau lt ne fl ;i f ancestor( fault) eq ul then

/ *Comm and is comple te . Read nextgo to readdata;

/ * Interpre t command for running program issued via a moni tori f #procv ec ge 10 then

/ *Recursion too deep noti fyterminal w rite ‘ recursion too deep , command/ *Release all user processes resul ting from recursive use of the command analyz

(while #procv ec gt 1) *Release al l user processes*/kill userprocess;

freesecondarystorage(userprocess) ; /*Give up swap space for

userprocess: suspendedprocess;

proevce : procv ec(2:end while ;i f #source gt 1 then

unhook(currentsource) ;*When recursion is too deep , the terminal becomes the inpu t source again , andal l other input sources

,which are in the source stack , are dropped . Remember

that the termina l is on the bo ttom of the stack , i.e . , the las t i tem in our indexingscheme for

infile = <open curentsource, currentposition> ;

argum entstack= <nult> ;

end if ;go to readdata;

end if ;

*Recursion is not too/ *The actua l

procv ec : <userprocess,#source procv ec;

process to execu te command , i f(disable ) *Get addi tional storage for newif ( 15 ij 5 #extstore+ 1 extstore(j ) eq 9 ) then

/ *Note : The preceeding ‘ i f ’ cannot fai l to be

end if ;end disable ;substparam s; / * replace parameters with values/go to lookup ; / *Examine and interpret command */

end if ;

foundt

/ *If the command name refers to a compiler outpu t fi le , the loader i s run as the user’s

program . The loader , whose internal detai ls are not shown here , wil l load the text corresponding to the command , supply missing routines ( see a sketch of this in the uniprogrammed system ’s job contro l language inte rpre ter) and then give control to the module justconstructed .

— 122

https://www.forgottenbooks.com/join

if not( (usernam e 6 users) and pair(param ) ) then

return im age+ ‘ comm and rejected , arguments have wrongend if not;

<usernam e,param (2)end ;

definef command*// * I nterpret a share command by calling the system

’s share routine , using arguments takenfrom the com mand being interpreted . username should be a system user , and param shouldbe a

if not (username s users ) or type param ne tuple or#param ne 3 thenreturn im age+ ‘ command rejected , arguments have wrong

end if not;return 1

end ;

definef / * permit comm and“

/ * Inte rpre t a pe rmit comm and by call ing the system’s pe rmit subroutine , using arguments

from the comm and . username should be a system user , and param should be aif not(usernam ee users) or type param na tuple or#param ne 3 thenreturn image-P command rejected , arguments have wrong

end if not;re turnend ;

definef *erase command*// * Interpre t an erase command by calli ng the system

’s erase subprogram . username shouldbe a system user , and param should be a tuple of one

i f not(usernam ee users) or type param ne tup le or#param ne 1 thenre turn image+ ‘ comm and rejected , argument has wrong

end if not;return erase <usernam e,param >

end ;

LOGOFF .t

define / * logoff command ‘ /* Ignore parameters*/

terminal w rite ‘ logoff com mand

(Vpeprocesses{m ov erpart(thisprocess) i s m } )freesecondarystorage(userprocess) ;

*Release swap space for*Release all program file names for thi s user

(f neprogram files{p} )unhook

end if ;i f <m ,p> ne thisprocess then kill

end Vp ;/ *Recal l that the ini t ia l parameter passed to the command inte rpre ter process was thedevice being used as a terminal by the user . That terminal i s now enqueued on the logonprocess as being available for a new

enqueue processparam eteron logon ;te rm ;end ;

- 124

User-to-user messages

definef‘ Interpre t message com mand by calling the system

’s message subrou tine . param must bea pair, and use rname and param ( l ) must be system

if not( (usernam e eusers) and pair(param ) ) thenre turn im age+ comm and rej ected , arum ents have wrong

end if not;if param( 1) 5 users thenre turn m essage(param ( 1

else re turn is not a user of theend if ;end ;

definef

if type text ne string thenre turn ‘Message to be sent is not a character

end if type ;i f receiver s signedon then

if #m sg(receiv er) ge 10 then*Reject request , too many messages already queued on receiver . ‘

re turn -‘Request rejected . Too many messages back logged . Try againend if #msg ;

return nulc;el se re turn ‘user not logged on’

;

end if ;end ;

definef

/ *Inhi-bi t messages from being typed on the user’s te rminal . None of the param eters are

used by thism sgon= false ;

return nulc;end ;

definef

/ *Permit messages to be typed on the user ’s te rm i nal . I f any are presently stacked , theywill start to print when the next comm and is inte rpre ted . None of the parameters are usedby this

m sgon= true ;

retum nulc ;

end ;

FILE HANDLING SUBPROGRAMS

define file(par) ;par is o f the form where fid is a file identi fier of the form <uid,ufn> where

u is a user identi fier and ufu i s a user file name , and where attr i s a set of pairs describ ingfile at tributes*/

i f thengo to badcal l ;

end if not;fid = hd par ;if and fid ( 1) e users and type fid (2) eq string) then

125

go to badcall ;end if not;uid = hd fid ;if catalogueIfid} ne 12 thenre turn ‘ fi le a lready exists , first erase o ld

end if ca ta logue ;i f Bat tr e par (2) I or type at tr ( 1) ne string) then

/ *attribu te list has wrong formatf /go to badcal l ;

end if Sattr;i s assumed to have been ini t ia l ized to a standard de fau l t

catalogue descript ion of a file . Some of the i tems in such a description would indicate thatthe storage device is to be d isc

,and that the file ’s disposi tion is permanent (i.e . keep from

session to session) . cf .(Vattre standardfiledescription)

* t ake standard file description except if parame ter is given by ca l ler*/( i f (3ye par(2) hd y eq hd attr) then y else at tr) in catalogue ( fid) ;

end Vattr;al locate ( fid ) ; / * assign physical s torage to fi le* /re turn nulc;

badcal l : re turn image command rejected , arguments have badend fi le ;

define filedefpfid is a program fi le identifier of the form <pid,pfn> where pid is a process iden tifier

and pfn i s a program fi le name . ufid i s a fi le identifier of the form where uid isa user iden ti fier and ufu i s a user fi le

i f not(pair(pfid) and pfid( 1) e processes and type pfid(2) eq string) thenre turn image ‘ firs t parameter is not a program fil e

end i f not;i f userfile(pfid) i s uf ne 9 then

/ *program fi le name already corresponds to a user fi lei f uf eq ufid then

/ *The requested assignment has a lready been made . Warn the user, and othe rwisedo

return ‘assignment already made ’ ;

had been the program fi le name of another fi le . Disassociate ‘

pfid’ from

thatunhook (pfid) ;

end if ;end if ;i f catalogue (ufid) eq 82 thenre turn ‘ the user fi le name is not in the cata logue . no action

end i f ;/ *Assignment may be

assign(pfid, ufid , standardfixup) ;re turn nule ;

end filedef ;

definef

/ *In order that fi le sharing may be transmi t ted through severa l leve ls of induction , thi srou tine is coded recursive ly . The set done contai ns all the sets fo r wh ich share commandshave been issued in obeying the original share request . This is necessary to avoid end lessrecursion in case a shared library conta ins a reference to i tsel f . This rou tine initial izes done ,

and then uses the auxilliary routine, sharerec to actua lly do theglobal done ; / *For use by inner routine ,/ *Check that parameters are user fi le

if (catalogue(ufid) eq $2) or catalogue(sfid) eq 12 then

— 126

https://www.forgottenbooks.com/join

*Call inner routine to do there turn permitrec(ufid, sharers , rights ) ;

definef

ufid i s a file identi fier of the form ‘ sharers ’ i s a se t of user names which areto be permit ted access to fil e ufid, and

‘ rights ’ i s the set of access rights which the membersof ‘ sharers ’ have . I f members of ‘ sharers ’ already have access to ufid, then we must checkwhether access rights have been reduced , in which case we must restrict access for suchmembers of ‘ sharers ’

,as we ll as to o ther users who were given access to ufid by such

members ofuid = hd ufid; / * file owner*/i f catalogue {nfid} eq 9 thenre turn ‘ fi le does not exist

if eq‘ l ibrary .

’ then/ *When permission is granted to access a l ibrary , give access perm i ssion to al l members , too . All permit ted file names are put in ‘done ’ to avoid endless recursion due tocirular libraries ( cf .

estab li sh (ufid, tem popenclose, temp ) ;temp read l i st ;unhook ( temp ) ;(Vm em bere ( list-done ) )member in done ;perm itrec (<hd

end if ;i f catalogue is perm eq nl then

The easy case . There are no former permissions outstanding for thiscatalogue(ufid ) <suid,rights> ,suid e sharers ] ;

else/ *the messy case*/

end if ;return nule ;

defineufid i s a fi le id. of the form ‘ sharers ’ is a set of user ids . All members of

‘ sharers ’ are restricted to the access rights in the se t ‘ rights ’ , and the members of‘ sharers ’

,

in turn , can only give permission to other users to use fil e ufid wi th access rights which areincluded in the se t ‘ rights ’ . We omi t parameter checking because this rou tine i s ca l led by‘

perm itrec’ with previously checked arguments . As an additional check on ‘

perm itrec’ and

on the integri ty of the catalogue,parameter checking could be

(Vsuide sharers)* former access rights*/

*new rights* // *Now look for users to whom ‘ suid ’ may have given the righ t to use ‘

ufid’

, and makesure that such users ’ rights don ’t exceed ‘ suid ’s rights . In the fo llowing statement , notethat hd [cata logue ] gives a ll the user-fi le identifiers . As coded , the next step involves asearch , which might be very inefficient , over the whole ca ta logue . However , i f theca ta logue were res tructured as a 2-parame ter map catalogue(usernam e, fi l ename )rather than as the present catalogue(<usernam e, thi s object ion would be

(Vm em berehd [catalogue] hd member eq suid andeq ufid)

lim ituse(m em ber, hd

end Vm em ber;end Vsuid;

end lirnituse;end perm itrec;

end permit ;

— 128

definef erase(fid) ;*Check that there is a cataogue entry for

i f catalogue( fid) eq 9. thenreturn im age+

‘

comm and rejected , improper argument’

;

end if catalogue ;/“A shared file can only be erased i f permission had been given to do

if ne 9 and

not(‘

erase’

e thenre turn ‘ fil e canno t be

files = [ fid} is handled ;(disab le )( 15 Vi5 #catalogue)

/ *Ah upper l imi t on the number of i te ra t ions to avoid a whi le-dic t ion in a disab ledb lock . This loop finds all fi le i .d .

’s which refer to the fi le fid by means of sharing . These t ‘ fi le s ’ i s i ni t ia lized to the singleton ‘ fid ’

. During each execut ion of the loop,the se t

‘ fi le s ’ i s augmented by al l fi le i . d .

’s which are shared wi th members of ‘ fi les ’ . Once‘ files ’ fai l s to grow as a resu l t of this process , i t contains a ll fi le identi fiers which referto the fi le being erased . Clearly , the number of i terations cannot excede the number ofca ta logue en tries , and usual ly ju st one or two i terat ions suffice . Much the samecomment concerning effic iency of this loop can be made as was made above

,concern

ing a simi lar loop in the ‘

limituse’

hd[catalogue] I e handled } fi le s is handled) ;i f handled eq ul then

/ *We fai led to find new fi l es shared to members ofquitVi;

end if ;end Vi;end disab le ;/ *Recal l tha t userf ile is a map from program fi le nam es to user file names (cf . section

Al l program fi le names which refer to the file being erased are removed , in caserunning programs attempt to use this fi le . files i s now the set o f all user fil e iden ti fierswhich refer to the fi le being

(Vufid6 fi les )(whi le Spfm apeuserfile I tIpfm ap eq ufid)

*A program fil e name is defined to be the fi le be ingunhook(hd pfm ap) ; /

*Program fi le name is now undefined*/end whi l e Bpfm ap ;i f ufid ne fid thencatalogue {ufid} 9 ; / *Delete shared entry from

end i f ;end Vufid;re l inquish fid ; / *Give up file

’scatalogueIfid} = Q ; /

*Now drop erased fi le fromreturn nule ;end ;

definef* Interpre ta t ion of the ‘

searchorder’

/ *First check that param is a tup le , and‘username ’ i s a system

if not ( type param eq tuple and username e users) thenreturn image+ ‘ command rej ected , improper

end if not;/ *Next check that al l components of

‘param ’ areif 3p( i ) e param I type p ne cstring thenre turn ‘Rejected

, argum ent’

+dec l+‘

is not a string ’ ;end if ;/ *All arguments have correct/ *Next check that a l l l ibraries

liberror= false ; /* Ini t ia l ize indicator that there are missing

(Vlib (i)

— 129

i f lib eq then continue Vlib (i) “

i f + l ib> ) ne 12 then continue Vlib (i) “

liberror= true ;

terminal w rite not exi s t ’ ;end Vlib (i) ;i f liberror thenreturn ‘

searchorder comm and rejected ’

;

re turn nule ;end if ;

end searching ;

end com m andanalyzer;

Get block of Main Storage

definef qd getblock (L ,P ) on blockflag ;L is the length of the desired block , P is the iden tifier of the process

function re turns base B of the block if avai lable , otherwise , 9

share secondarystorage ;/ *The above share s tatement declares secondarystorage to be shared among al l processesexecu ting this

initially get disk pack for swapping programs*/i f secondarystorage ne 12 then qui t ini tial ly ; ;

/ *This ini tially block is done only the first time that thi s routine is entered , not onceper process .

In the next three sta tements,

‘

sw apfile’ becomes the _name of the system ’s fi l e for

swapping memory images between main memory and secondary storage ,‘

sw apspace’

becomes the program file name of that file , and‘

secondarystorage’ represents a ll the

data on

secondarystorage

end initially ;

i f L It 0or L gt m axm em then*Request is for negative space , or too much

free blockflag ;return 12;

end if ;*First , search for an avai lable memory block which is largeif (is(k) ememsize I s ge L and m em ow n(k) eq 9 ) then

/ *A block which is large enough has beenreclaim ed = s;

j = k+ l ;/ *At

‘final ’ , the k‘h block gets assigned to process P . I f the kth block is too large ,the remainder becomes an unassigned block which is contiguous to the km . All theblocks from the jth to the last become contiguous to the kth (or the k+ 15‘, i f the k‘h

was larger than the amount reques ted forgo to fina l ;

end if ;

— 130

https://www.forgottenbooks.com/join

queues , upon which thi s loop pre-empts i t s main storage"Passing the test‘L gt

m axm em’ at the beginning of this subprogram guarantees that eventual ly enough

storage will be

end if ;/ *Determine where in secondary s torage to copy memory content s . The fo l lowingcondit ional must be true for a ll user processes , and is used to set j to the appropriatevalue from which pr ’s secondary storage space can be

must = 3y ( j ) e extstore y eq pr ;secondarystorage( (ji f reclaimed m em size(i) is reclaimed ge L then

/ *Enough memory has beengo to addup ;

end i f ;end Vpr(i) ;

*Not enough storage has beenaw ai t #w orkset(hiprio) gt0;

go to preem ptstorage ;

final :/ *Make assignment of a block of memory of size L , beginning at B , to process P . Notethat if the reclaimed block is grea ter than L in size , the remainder of the recla imedblock is kept as an unassigned block of

/ *If the unused memory b lock just assigned is larger than required ,keep the

portion not required as an unused block and remove i tems between the kth and j‘h inthe old

L It reclaimed then < reclaimed-L> else nult m em size(jz) ;L It reclaimed then <B+L> else nult m em loc( jz) ;

i f L It reclaimed then

/ * Indicate tha t the unused port ion of the recla im ed block has now become a blockin its own right which is avai lable for

e lse / *The reclaimed block was exact ly the right

end if ;free blockflag ;return B ;

nonexistent : return 9 ;end getblock;

Scheduler

*Processes are ini t ia l ly p laced on w orkset(hiprio ) by the command analyzers . Thescheduler se lects the firs t process in w orkset(hiprio) , gets the corresponding memory intomain memory , removes the process from w orkset(hiprio) and places i t at the end of theC PU

’

s w orkqueue . I f there are no high priori ty processes , the same actions are repeatedfor low -priori ty processes . See Section

getm ore

i f #w orkset(hiprio) ne 0 then*Attempt to schedule potentia l ly highly interactive processes

B sched(hiprio) ;i f B ne 52 then go to getm ore

“

end if ;*If we cannot schedule an interactive user

,try a long-running process

— 132

B = sched( low prio )i f B no 9 then go to getm ore; ;await #w orkset(hiprio) #w orkset( low prio ) gt0;go to getm ore;

definef qd sched(queue) on blockflag ;/ *This rou tine and ‘

getblock’ must have exclusive use of the memory assignm ent maps . As

soon as the scheduler has determined whe ther or not the next user to has hi s programin main memory , the

‘

getblock’ routine is free to run*/

‘ first e ligib le user in queue */if p ne 9 theni f n(ix(i) em em ow n x eq p ) then

free blockflag ;

i f B eq $2 then re turn 12“

hd

else free blockflag;end if p ;

/ ‘ time used in current time s lice */

end if ;return(p) ;

nonexistent : re turn 9 ;end ;

Dispatcherit

/ *cf .

getw ork: w aitcopy= w aitset;*Copy se t of wai ting processes*/

loop : i f w aitcopy ne 111thens from w aitCOpy;

C PUcontrol = s; / *Reevaluate condi tion for resuming processi f isok then

i s communicat ion between s and the8 out w aitset;

elseend if ;go to loop ;

end if ;*Give priori ty to system

(disab le )eq

i f 3 ne 9 then

/ *We don ’ t want sys tem routines to be in terrupted often by the timer . I nfo l lowing statement ,

‘

onesecond’ i s a machine dependent macro which speci fie s

number of t icks in a second . ( cf .tim er= clock+onesecond ;

/ *No system processes to dispa tch choose a user

i f 3 eq 12 then go to getw ork"

starttim e = clock; / * for in terrup t handlers*// *Compute when the quantum

— 133

end if ;end disable ;C PUcontrol = s; / *give contro l to the chosen process*/go to getw ork;

Timer Interrupt

tim expt

(disable )i s a machine dependent macro specifying an appropriately large number of

clock ticks (cftim cr= clock longtime ;i f n (priv ilege(resum e ) eq

‘ system ’

) then/ *A user process has exhausted a time quantum . Determine whether addi tional quantaexist in the t ime sl ice

,or whether the process shou ld be put into a low priori ty queue

(cf .i f nquant(m ov erpart(resum e i s mov) ) ltm quant(m ov ) then

1;*No . Count quanta

/ * Ini t ia lize time used in new quantum to

/ *Process put at end of hi-priori ty queue */

/ *Time slices other than the first are at low*Only 1 quantum per time

/ * from now on*/

*but a long one*/end if ;

/*System interrupted . Prepare to resume system

end if ;/ *Give up control to the

<C PUcontrol, loctr(thisprocess)>end disable ;

MONITOR SERVICES

m onitorxpt

(disable )/ *Firs t , keep track of t ime used by user*/

i f resum e s userprogs thenusednow (resum e ) usednow (resum e ) clock starttim e ;

end if ;fcn= hd cause ;i f fcn s

‘wri te ’

,

‘backspace ’,

‘ rewind ’

,

‘ space ’ ,‘wait ’

,

‘enable ’,

‘disab le ’,

‘ re lease ’ ,‘

endfixup’

,

‘ fixup ’

,

‘abend ’

} thenis a label found

loctr(osenv ironm ent) lookatrequest;

/ *Start a privi leged process to interpret the moni tor reques t . Attach this newprocess to the mover of the request ing

is serv icesprocess osenv ironm ent;

split to serv icesprocess (cause) for resum e ;

C PUcontrol, loctr(state(thisprocess)/ *The then portion of this if -statem ent i s meant to trea t the same commands aswere treated by the moni tor services sec t ion of the uniprogram m ing system of

— 134

https://www.forgottenbooks.com/join

Chapter VI

Summary

Classif ication of PSETL Extensions

PSETL represents an at tempt to extend SETL foroperating system description“

. The extentions , as

described in Chapter II,proceded in two directions : the defini tion of global data objects , and the

addi tion of contro l structures .

Fourteen global data objects were defined . Several of these , such as interrupt , resum e , and clock

correspond close ly to hardware fea tures found on most computers . O thers , such as w orkset,

w aitset, facil i ti es , and state are abstractions of objects which operating sys tem software m anipu

la tes . These objects do not correspond close ly to hardware components ; rather , they correspond

to higher level objects which Operat ing systems control . These PSETL objects are sets or tup les

and may be manipu lated as ordinary SETL objects . Thus , algori thms involving such data strue

tures (e .g . a search for a non-busy facil i ty) can use the ful l power of SETL .

Four primi t ive control structures are provided . The initia lly b lock is extended to provide execution

for in i tia l execution of a subprogram by each disticnt process . The disab led-block prov ices for

uninterrup tab le code . The share dec larat ion provides for i nformation sharing between di st inct

processes executing the same body of code . The special vari able C PUcontrol, l ike the previously

mentioned dist inguished data structures,can be used in SETL expressions ; when i t is the object of

a storage operator , the resul t is to swi tch control o f the CPU from one process to another .

Several addi t ional contro l Opera tions ( see sect ion such as aw ai t , enqueue , free , and the

queued subprogram are particular to PSETL , but these can be expanded as macros in terms of the

PSETL data and contro l ex tensions of sect ions and Thus , these are not primit ive ,

al though i t i s convenient to think of them as atomic operations , and they are used free ly in this

text .

The examples in Chapters II I-V serve as test cases for coding in the PSETL defined by this family

of extensions .

Experience w ith PSETL

Before commenting on my experiences using PSETL , some remarks on my previous opera t ing

system experience are appropriate . My experi ence has been limited to opera ting systems for IBM

computers , but range over a wide varie ty of machines . The system inc ludes an experimenta l

opera ting system for the IBM 704 , an experimenta l multiprogramming system for the IBM 7030

(STRETCH ) , FMS and IBSYS for the IBM 7090,an operating system to control coupled IBM

7o4o’

s and 7090’

s, and C P/CMS for IBM System 360 and System 370. All these

Operat ing systems have one characteristic in comm on : they are coded in assembly language .

— 136

When I embarked on coding in PSETL , I was at the same time making my first attempt at using a

high level language for expressing opera ting system algori thms . My ini tia l attempts fe l t c lumsy and

were discarded . Thi s probably would have been the case wi th any higher level language since any

such l anguage , by tending to suppress some detai ls , would present me , the designer and im plem en

tor , with a different , genera l ly cleaner , view of the computing system than I had been used to .

SETL al lows detai led coding decisions to be suppressed or deferred , but in my ini tial at tempts , I

could not overcome my previous training and thus tended to data structures and their manipulation

in minute detail , and the resu ltant code looked too much like assembly language with semi-colons .

I do notwant to leave the impression that PSETL i s c lumsy as a language for expressing operat ing

systems ; i t was only my long experience with assembly language which acted as an init ia l handicap .

Many stuctures which operat ing sys tems use are expressed very natura l ly as maps , and SETL i s

very wel l sui ted to using and manipu lating such s tructures . The code in Chapter V i s better SETL

than the code in Chapter I I I , and reflec ts my increased comfort and abi l i ty to use PSETL .

I f we examine the sample operat ing systems in th is text , we find that approximate ly 10% of the

l ines of code invo lve PSETL dic tions . PSETL dict ions are concentrated in those portions of code

which are involved with the crea tion and contro l of processes , and which concern vita l interproce

dura l mechanisms such as in terrupt handl ing . For many subprograms , ordinary SETL su ffices .

PSETL dictions fa l l natura l ly into three classes : dict ions which reference specia l variables , macro

Operations which start , stop or postpone processes , and dic tions which obtain exclusive control or

exc lusive use of data . The first group of dic tions i s easi ly incorporated into SETL i t i s as though

certain objects were global ly de fined and avai lab le for use . The second group a lso poses l i t t l e

difficul ty , for they na tura l ly appeal when the system programmer requires a means to synchronize

processes . The th ird group , involving exclusiveness , i s the most difficu l t to use , for the need to

exert exclusive contro l is not genera l ly apparent when an algori thm is ini tial ly being coded .

These remarks are best i l lustrated by an example . Consider the func tion cal led ‘

sched’ appearing

in the scheduler sect ion of code in Chapter V . Thi s function receives as input the identi fier of a

w orkqueue of processe s . I f the queue i s empty , the funct ion re turns S2. O therwise , the fi rs t

process i s removed from the queue . I f main memory for that process i s a lready assigned , or can be

assigned , the function re turns the process’s identifier ; otherwi se i t re tu rns 9 . Straightforward code

for this function is :

definef sched( v ) ;/ * remove firs t process from queue */

i f p ne 9 theni f n(3x(i) s m em ow n x eq p ) then/ *if memory is not a lreadyassigned , try to get

i f B eq SI then re turn 9“

* indicate new location of memory in there location portion of thehd

end if ;return p ;

end if ;end sched ;

— 137

However , the rou tine as just shown wil l no t work correctly , since o ther portions of the operat ing

system which use data in comm on with ‘

sched’ may cause in terference . Both ‘

sched’ and ‘

getblock’

use the vector ‘

m em ow n’ and the w orkqueue corresponding to v v could be ei ther ‘

hiprio’ or

Changes to ‘

m em ow n’ and the possib le w orkqueues occur i n disab le b locks in

‘

getblock’

. The execut ion of code between

if n(3x(i) s m em ow n I x eq p ) then

cannot safe ly be interleaved with execution of ‘

getblock’

. Here this can be preven ted in two ways‘

sched’ can be a queued function on the faci li ty b lockflag , as i s

‘

getblock’

, or the code between the

two sta tements ci ted above can be made part o f a a di sab led b lock i f ‘

getb lock’ a lso uses the

w orkqueues which concern us only in in a disab led block . In this case , the queued func tion is

preferab le since i t wi l l s ti l l a l low ‘

sched’ to run concurren tly wi th other disab led b locks in the

system , that is , i t i s inte rruptab le by other processes , and in a mul ti-CPU configuration , i t can run

whi le another CPU is disab led . Furthermore ,‘

getblock’ wil l not require the use of disab led blocks .

We must only be careful to free blockflag so that‘

sched’ can ul timate ly cal l upon ‘

getblock’

, and so

that ‘

sched’ or ‘

getblock’ can be reused . Hence , the fina l form of

‘

sched’ i s :

definef qd sched( v ) on blockflag ;

i f p ne 12 thenif n(3x(i) s m em ow n x eq p ) thenfree blockflag ; / *al low getblock to run */

i f B eq 12 then re turn 12"

hd

re tu rn p ;end if ;

end if ;free blockflag ; / *a ll paths must free blockflag*/return p ;end sched ;

PSETL allowed a simple , straighforw ard expression of the‘

sched’ algori thm as given above in the

first rendi tion . After considering the possible conflic ting use of data , PSETL also al lowed a simple

modi ficat ion to get the desired exc lusive contro l over tw o data st ruc tures . The expressiv i ty of

PSETL was wel l sui ted for this short example,as indeed

,i t has been for a l l the code in this tex t .

A PSETL shortcoming which shows in this example was that correct coding required awareness by

the programmer of possib le confl icting use of data . Then ,with some care , the necessary PSETL

dic tions were used to preven t the confl i ct . PSETL makes i t easy to write such code , but i t does not

go very far in removing the need for awareness of confl ic t ing reference to common data by

possib ly concurrent processes . I n this case , PSETL design fo l lows contemporary computer design

too close ly .

The disable block of PSETL is the one instance where PSETL breaks away from current compute r

de sign with some success . The restric tions on the content s of a di sab le b lock guaran tee the

termination of a disab le condi t ion . Had we extended SETL by means of enab le and di sable

— 138

https://www.forgottenbooks.com/join

from becoming deadlocked [C ES,Hab

,Hav , Hol ] . Perhaps nested reserved blocks should be

barred , i n favor of requiring al l reserved variab les to be speci fied on entry to the b lock . Thi s

avoids piecemeal a l location of faci lities to a process which is a necessary condi tion for deadlock to

arise , but has the drawback of requiring some faci li t ie s to be reserved for an unnecessari ly long

t ime .

Alternative ly , we could require that facilities be a vector , together wi th a ru le that a process

at tempting to sieze a faci li ty x (where x eq facilities(i) ) could only execute

x in busy ;

if the fol lowing condi t ional were true

1 5 3] i f eq

Simi larly , we could require that for free to be executed ,

1 5 ij 5 i f eq

Clearly , this would avoid circu lar wai ting , another necessary condi tion for deadlock . Sti l l ano ther

approach would make the right to use shared data avai lable only for a l imi ted period of time . I n

such an approach , the firs t process to access such a variab le rece ives exc lusive control of tha t

variab le for the associa ted time interval . During this in terval , other processes a t tempting to

reference i t are automatical ly suspended . Fai lure to re lease the variab le wi thin the time interval

resu l ts in an i nterrup t and loss of access to the variab le to o ther suspended processes . I f the

process losing control of a t imed variab le i s in a disabled block , the interrupt and loss of contro l o f

the variab le are de layed unti l the process becomes enabled . This approach avoids non-preemptive

scheduling , which is also a necessary condit ion for deadlock .

The PSETL rule making it i l lega l to use subrou tines from within a disabled block (or the proposed

reserved b lock ) could be eased as fo l lows : Let D be the c lass o f subprograms which have no

backward branches and which have no whi le-blocks . Suppose further tha t in the prologue of each

(compiled ) program , we include a means whereby asubprogram can determine whether i t is in

class D . Entry to class D programs could then be valid in the disabled state provided that the entry

is not recursive . All other subprogram entries would be invalid and would cause a distinguished

interrupt to indicate forced exit from a disabled block .

The SETL name propagation ru les need strengthening . At present , i f a variab le i s to be made

known across unnested scopes , the dic tions global and include must be used . Once the global

dec larat ion is made , there is no mechanism in SETL which prevents an include from being used in

any scope of code . This can make the variab le accessible in portions of the Operating system in

which the programmer of that port ion of the operating system which owns the variab le did no t

mean i t to be accessib le . SETL should make i t possib le to speci fy which processes , or which

scopes may access data , and what kind of access is to be allowed , e .g . re trieval access or assign

- 140

ment access . A process owning data should be able to dynamical ly adjust the access to that data

which it permit s other processes to have .

SETL , being a value-oriented language , imp li es ineffic iencies when large structures are m anipulat

ed , because of the copying which must be done . Code in which these inefficiencies were deli ber

ate ly avoided at the expense of clari ty of expression is found , e .g . , in the comm and analyzers of the

code i n Chapters I I I and V , i n which severa l inpu t sources can be suspended during command

macro expansion . To stack fi le variab les would imply a large copying operation ; therefore , in the

code,the fi le names were s tacked , and the fi le s themselves had to be te-opened on unstacking .

For structures other than fi les there exis t no names or poin ters which can be manipu lated instead

of the s tructure i tse l f . I f PSETL i s to be used for rea l i s t ic expression of opera ting systems,

pointers or reference-by-name wi l l have to be be added to the language .

- 14 1

[B]

[C ]

[C ES]

[C 0]

[DVl

[D165 ]

[D168]

[DM]

[Hab ]

[Hav]

[Hoa]

[H01]

[172]

[173 ]

["]

BIBLIOGRAPHY

Brinch-Hansen , P . ,Operating System Principles Prentice Hall , Englewood Cliffs , N .J.

,

1973

Codd , E . F . ,Multiprogram Scheduling Comm . A CM 3 , 6 , pp . 347-3 50, June 1960;

Comm . ACM 3 , 7 , pp . 4 13-4 18 , July 1960.

Coffman , E . G . , Elphi ck , M . J and Shoshani , A . , System Deadlocks ACM Computing

Surveys , 3 , 2, pp . 67-78, June , 197 1

C orbato , F . J. ,PL/ I as a Tool for Systems Programming Datamation , 15 , 5 , pp . 68-76 ,

May , 1969 .

Denning, P . J Third Genera tion Computing Systems A CM Computing Surveys , 3 , 4 ,

pp . 175-216 , Dec . 197 1.

Dennis , J . and Van Horn , E . , Programming Semantics for Multiprogrammed Computa

tions " , Comm . A CM 9 , 3 , pp . 143-155 , March 1966 .

Dijks tra , E . W. ,Cooperat ing Sequentia l Processes Technologica l Universi ty , Eindho

ven , The Netherlands 1965 (Reprinted in"Programming Languages”, F . G enuys, ed. ,

Academic Press , New York , N .Y . , 1968)

Dijkstra , E . W. ,The Structure of THE Multiprogramming System Comm . ACM 11

, 5 ,

pp . 34 1-346 , May 1968

Donovan , J . and Madnick , S.,Opera ting Systems McGraw , New York , N Y . 1974 .

Habermann , A . N ., Prevention of System Deadlocks Comm . ACM 12

, 7 , pp .373-377 ,

July 1969 .

Hav ender, J W. , Avoiding Deadlock in Mul ti tasking Systems IBM Systems Journal , 7 ,

2, pp . 74-84 , 1968.

Hoare , C . A . R . , Towards a Theory of Paralle l Programming In ternational Seminar on

Operat ing System Techniques,Belfast , Northern Ire land , July-August 197 1.

Holt , R . C . , Some Deadlock Properties of Computer Systems ACM Computing Surveys ,4

, 3 , pp . 179-196 , Sept . 1972.

IBM V i rtual Machine Faci li ty/370: Command Language User’s Guide IBM Publica

t ion GC 20-1804 , 1972

IBM System/360 Opera t ing System : Job Control Language Reference IBM Publ ica

t ion GC 2S-6704 , 1973

"nuth , D . , The Art of Computer Programming Vol . 1, Ch . 2, Addison—Wesley ,Reading , Mass . 1969 .

- 142

https://www.forgottenbooks.com/join

Appendix A

A PRECIS OFTHESETLLANGUAGEl

In the present section,we summarize the principal basic features of the SETL language , as

they have been defined in the preceding pages . I t is hoped that this precis can serve a s a useful

brie f re ference .

Basic Ob jects : Sets and atom s ; se ts have atoms or sets as members . Atoms may

Integers Examples : 0, 2,— 3

Real Examples : 0.9E- 5

Boolean strings Examples : 1b , Ob , 77b , 00b777

Character st rings Examples : ‘aeiou ’

,

‘ spaces

Label (of statement ) Examples : labelz, < labe l :>

Blank (created by function new at) S2 is specia l ‘undefined ’ atom .

Subroutine . Function .

The operator type x returns the type of the object x .

i r rs ora om sBas c o e ato f t

Integers ari thmetic ( remainder)

comparison : eq , ne , It , gt, ge , le

other : max , min, abs

Examples : i s 1, 3 max — 1 is 3 ; abs — 2 i s 2.

Real s : Above ari thmetic operations (wi th exception of

p lus exponentia l , log, and trigonometric functions .

Booleans logica l and (or a ) , or, exor , im plies (or im p) , not

logical constants : t (or true , or 1b ) ;

f (or false , or Ob ) .

Character strings : conversion : dec, oct

Examples : dec ‘

12’ i s 12; oct

‘

12’ i s 10.

Strings (character or boolean )

(catenation) , ( repeti tion ) , a ( i : ) (extraction) ,

( size ) , nulb , nulc (empty s trings ) .

Examples : ‘a ’ ‘b ’ i s ‘ab ’

; 2* 1b4 i s 11001100b ;

2‘ab ’ i s ‘abab ’

,

‘abc ’ ( 1:2) i s‘ab ’

, i s ‘

bc’

,

i s ‘b ’

,

‘abc ’ i s 3 , nulc i s 0.

General : Any two atoms may be compared using eq orne ;

1 Reproduced from [S73a, pp 501 The underl ined objects in the original tex t have beenreplaced by boldface type to agree wi th the typography in thi s work .

- 144

atom a tes t if a i s an atom .

Basic operations sets

6 (membership test ) ; nl (empty set ) ; arb (arbi trary e lement ) ;

(number of e lements ) ; eq , ne (equa li ty tes ts ) ;

incs ( inclusion test ) ; w ith, less ( addit ion and de le tion of element ) ;

npow (k,a) ( set of all subsets of a having exact ly k e lements ) .

( set union) , ( in tersection) , (symmetric difference ) .

Examples : a s {a,b } i s t , a s ul i s f , arb nl is Q ,

arb {a,b } i s e i ther a or b , i s 2, nl i s 0,

{b } w ith a is {a,b } less a i s { b } ,

{a,b } less 0 i s {a,b } incs { a } i s t .

i s

is

Ordered t_uLle§ are treated as SETL objects of di fferent type than sets e .g . tuples may

have some components undefined .

Operat ions on tup les

Tuple former : I f are n SETL objects then

t i s the n—tuple wi th the indica ted components .

#t is the number of components of t

t(izj ) i s the tup le whose components , for l skg j , are t ( i+k— 1)

hd t is t( l )

tl t is t(2: )

i s the concatenation opera tor for tuples

Examples : hd <a,b> is a . tl <a,h> is <b> , which is not the same objec t as b .

[ f t <a,b> and r <a,c> then

T t r T (3 :2) <a,c>

Tuple components may be modified by wri t ing

t(i) x;

An addit ional component may be concatenated to t by wri ting

t(#t 1) x ;

Set-Defini tion : by enumeration : Set-former

xls e

l , I

The range restrictions x s a(y) can have the al te rnate num erical

min (y ) s x s max (y )

when a(y) i s an interval of integers .

I f t i s a tup le,the form x(n) s t can be used , see below ,

iteration headers , fo r addi tional detai l .

Optional forms inc lude

{ x s a C (x) } equivalent to { x , x s a I and

- 145

x s a } equivalen t to x s a I t } Funct iona l appl i ca t ion (of a se t of

ordered pari s , or a programmed , value-returning function ) :

f [a} i s { i f #p gt 2 then tl p e lse p (2) , p s f I i f type p ne tupl

then f e lse (#p) ge 2 and (hd p eq i.e .

i s the se t of a ll x such that <a,x> s f .

f(a) is : i f #f {a} eq 1 then arb f [a} else $2,

i.e . , i s the unique element of f { a } , or is unde fined atom .

f[a] i s the union over x s a of the sets f [x} , i.e . , the im age of a under f .

More genera l ly :

f (a ,b ) i s g(b ) and f [ a ,b ] i s g { b } , where g is f [a] ;

f[a ,b ] i s the union over x s a and y s b of f {x,y}

I f f i s a value-returning function , then

f [ a ,b ] f[al x s a } , e tc .

Constructions like f etc . are also provided .

[opzx s s] e (x ) i s c(xl ) op e(xz) op op e(xn) where s i s { x

This construct ion is also provided in the genera l form

[opzx l s e,,x2s x

,ls

where the range restrict ions may also have the al ternate

numerical form , or the form appropriate for tuples .

Examples : [max : x s i s 4 ,

x s i s 9 ,

x(n) s a]x i s SETL form of 2 a

[opzx s nl ] e (x ) i s Q .

Q uanti fied boolean expressions

3x s a | C (x) s a | C (x)

genera l form is

ixls a

1,x2s a

2 (x1) , Vx3 s

where the range restrict ions may also have the al ternate numerical

form , or the form appropriate for tuples .

Evalua tion of

3x s a C (x )

se ts x to first value found such that C (x ) eq t . I f no such value , x becomes 12.

The al ternate forms :

min 5 ix 5 max , max 2 3x 2 min , max 2 Ex min , x(n) s t , e tc .

of range restric t ions may be used to contro l order of search .

i f bool1then expnl else if bool2 then expn2 else expnn

a orm b abbrevia tes if a no 9 then a else b

— 146

https://www.forgottenbooks.com/join

sions can be used freely withi n other expressions .

Control statements

go to label ;i f cond

lthen block l else i f cond

2then block

2else b lock

if cond1then block

1else e lse i f cond

uthen block

I terat ion headers

(whi le cond ) block ;

(while cond doing blocka) block ; i s equiva lent to (whil e cond ) block blocka;

(Vx1 s a ] , x2 s xrls block ;

I n this last form , the range restriction may have such al ternate numerica l fo rms

min 5 x 5 max , max 2 x 2 min , min 5 x max , e tc . ,

which contro l the iteration order .

I f t i s a tup le , bi t st ring or character string , then the operator of the form

(Vx(n) s t ) block ; is avai lab le . This is an abbreviation for

( 1 S Vn 5 #t t(n) na S2)x t(n) ; block ;

I terators of this form may also be used in set formers ,

compound operators,quantifiers

,etc .

I terator Scopes

The scope of an opera tor or of an else or then block may be ind icated e i ther wi th a

semicolon , wi th parentheses , or in one of the following forms :

end V; end while ; end else ; end if ; e tc . ;

end Vx; end while x ; end i f x ; etc .

Loop Control

quit ; qui t Vx; quit while ; qui t whi le x ;

continue ; continue Vx; continue while ; continue whi le x ;The quit statement terminates an iterat ion ; the continue statement begins the nex t cycle of an

iteration .

Subroutines and functions ( are always recursive )To cal l subroutine :

sub [a] ; i s equiva lent to (Vx s a ) sub (x) “

General ized forms

are also provided .

To define subrout ines and functions

subroutine :

define tex t end sub ;re turn ; used for subroutine re turn

function :

— 148

definef fun text end fun ;

re turn val ; used for function re turn

and prefix forms

define a infsub b ; text end infsub ;definef a inf in b ; tex t end infin;define prefsub a ; text end prefsub ;definef prefun a ; tex t end prefun;

Nam escopes

Scope declarat ions divide a SETL tex t into a nested collect ion of scopes . Scope names

are known in immediate ly adjacent , containing , and contai ned scopes . O ther than this , names are

local to the scope in which they occur , unless propagated by include orglobal statements .

Declarat ion forms

scope name ; end name ;

scopes wi th specified numerica l leve l

scope 11 name ; end name ;

globa l declarat ion

global name l , name

with speci fied numerica l leve l

global 11 names name

include sta tement

include l i st

Example

include bigscope1(scope1'

x, scope2(-z) , scope3 (x, y , bigscope2*;

s igni fie s a l l e lements known in scope , sign i fi e s exc lu sion of those e lements l isted ,

modifies the ‘al ias ’ under which an e lement i s known in scope in which included . Subroutines and

functions are scopes of leve l 0. Macros ( see be low ) are transmit ted between scopes in much the

same way as variab le names . The declarat ion

ow ns routnam el (x1, ,xnl ) , routnam e

2(y,, ,ynz) ,

states that the variables x]

. are s tacked when routnam e1is entered recursive ly , the vari ab les yj are

stacked when routnam ezis e ntered recursive ly , etc .

Macro blocks

To define a block : m acro text endm mac ;

to use :

I ni t ia lizat ion

ini t ia l ly b lock ; (block execu ted on ly first t im e process en tered)

Unformatted character st ri ngA SETL fi le is a pair <sr,n> where st is a character string and n an integer indexing one

of i ts characters .

er i s end record character ; input , output are standard I/O media ;

the function record ( s) ; reads a fi le <st,u> from posit ion 11

t i l l er character or string-end is encountered in the character

- 149

st ring st.

Standard format I/_ O

An interval file f in SETL i s a pair <st,n> consist ing of a character string st and an index

n to one of the characters of st.

f read name l , ,name n ; using standard format reads from file

starting at posi t ion 11

f print expn] , ,expn using standard form transfers external

represen tation of objects to fi le 3 start ing at

posit ion 11 as above2.

The set Is] , ,sn} i s represented as {rp ,rn} , where rji s the external representation pf si. Simi larly , the tup le

,sn> i s represented as <r1, ,rn> .

An external fi le st in SETL is character s tr ing cata logued with the operat ing system suppo rting

SETL under some identifying name catnam e (which is i tsel f a st ring) . The sta tement

x open catnam e ;

makes the string st i nto the value of x . The ca ll

makes the SETL string st into the contents of the externa l fi le named by the string carnam e .

z1h thi s text , we have used w ri te instead of print , since print i s o ften interpre ted as mean ingoutputt ing to a typewri ter terminal or a high speed printer . We want our verb to denote a generaloutput action , and have therefore chosen the word w rite .

— 150

https://www.forgottenbooks.com/join

library 2, 30, 41-42, 47-48, 59 , 6 1, 100,

loader 1, 34 , 65 , 89 , 97 , 100, 103-106 ,

kfl l

Ioctr 9 , 13 , 15 , 26 , 66 , 72, 81, 86 , 89 ,

-134

logofl'

logon

machine dependent 5 , 7 , 16-17 , 19-20,

macro operations 18

Madnick , S. 28

main memory 2-3 , 17 , 30, 34 ,43 , 86-89 ,

-132,

137

map 6—7 , 30-3 1, 3 3 , 40-4 1, 43

memory device 99

message buffers 28

monitor services 17 , 36 , 80, 83 , 97 , 105 ,

m overs 8,

mult iple ex tents 97

multiprocessing 11

mult iprogramming 3 , 5-6 , 37 , 86-90, 96 ,

non-in teractive 30, 86 , 107

non-privil eged 3 , 105 , 107 , 121

on-l ine 99 , 101, 104

operat ing system 1-3 , 86 , 88, 96 , 99 ,

104

operator communication 4 1, 72

output printer 43

pennu -128

physical device 4 , 6 , 34 , 45 , 55 , 76 , 82,

privi leged instruct ion 3 , 17

privi leged process 9 , 13 , 13 , 19 , 21, 81,

problem state 3

process 8

processes 8-9 , 12, 18-19 , 75

processpart 9 , 13 , 24 , 26 ,117

— 152

program fi le name 34 , 42, 103 , 113 ,

PSETL 7 136-140

queued subrou tine 12, 20, 22, 111, 115

116 , 134

read 38, 70, 81

readfirst 12, 25

release 81-82, 87 , 134

re locatable 88, 102, 104-105 , 108-109 ,

reserv e 14 , 23 , 64 , 74 , 80, 82—83

resource allocation 5 , 7 ,4 1, 89

resum e 9 , 19 , 80-81, 88, 90, 13 3 , 134 ,

136

rew ind 38, 81, 83-84 , 134

scheduler 42, 47-50, 5 5 , 58, 64 , 67 , 72,

74 , 87-97 , 100, 102, 106 , 109 , 121, 13 1

132, 137

secondary storage 97 , 99 , 101-102, 106 ,

-13 1

semaphore 14 , 28

se ssion 101-102 , 104 , 106-107 , 114 ,

117 , 119

shared variab le 11, 15

split 13 , 66 , 69 , 72—73 , 81, 117

122,134

step termination 36

symbolic reference 30, 86

synchroniza tion 4 , 13 , 14 , 38

system nucleus 40, 106

term 14 , 24 , 94

tim er 16 , 20, 80, 133

unhook 50, 57 , 67 , 75-76 , 79 ,

120, 122, 124 , 126-129

uniprogram m ing 30, 37 , 86 , 88, 9 1, 97 ,

134

user fi le name 3 3-34 , 103-104 , 125-126

virtua l memory 4 , 6

w ait 70, 76 , 80, 82, 86 , 134

w aitset 13 , 20-22, 115 ,

w orkset 11, 19 , 89 , 136

w rite 38, 7 1-72, 81-83 ,

This book m ay be kept

FO URT EEN DAYS

A fine w ill be charged for each day the bookis kept ov ertim e.

https://www.forgottenbooks.com/join