What is the use of operating systems?

28034_37_4_249.pdf

What is the use of operating systems?

By P . L . Cloot * Befor e lon g nearl y al l compute r user s wil l b e usin g operatin g system s wit h thei r equipment . Thes

eoperating systems consist of both language processors and supervisor programs, and this papersets out to explain in simple terms

wh y the need for such systems has arisen. Th e ai m o f thi s pape r i s t o sho w tha t compute r operatin g system s are , fro m th e user' s poin t o f view , no t onl y in

-evitable but desirable. It is not intended to be a tech-nical account of operating systems or of particular waysof implementing them, as enough papers and manualsare already availabl

e o n th e subject . Th e proceeding s o f th e Edinburg h Join t Compute r Conferenc e (1964 ) giv e a broa d surve y o f users ' view s o n computers , an d a mor e specialize d boo k ha s recentl y bee n publishe d (Wegner , 1964
) whic h represent s curren t thinkin g i n thi s countr y o n operatin g systems. It is hoped rather that this paper will serv e a s a n introductio n t o th e subjec t fo r thos e wh o nee d t o kno w wha t al l th e fus s i s about .

Anothe

r are a i t i s no t propose d t o tackl e i s tha t con - cernin g th e physica l equipmen t actuall y use d t o imple - men t an y particula r machin e system . Endles s argument s ca n be , an d ofte n are , carrie d o n abou t th e relativ e merit s o f variou s form s o f "hardware. " Al l th e use r i s con - cerne d abou t i s ho w th e overal l syste m behaves , an d whethe r th e hardwar e th e designer s chos e t o implemen t ca n b e manufacture d punctuall y t o b e reliabl e a t a reasonabl e price . (I t i s blithel y assume d i n sayin g thi s tha t th e use r i s confiden t o f hi s abilit y t o mak e effectiv e us e o f the equipment if it is installed in working order on time ! This raises a whole host of other problems, which agai n ar e no t th e subjec t o f thi s paper. )

Problem

s i n usin g a compute r I n orde r t o us e a compute r i t i s necessar y t o hav e a languag e fo r communicatin g intelligenc e t o i t an d a mean s o f ensurin g tha t a progra m writte n i n thi s languag e function s a s intended . Le t u s conside r programmin g language s an d progra m testing , an d the n se e wha t othe r problem s i n usin g a compute r aris e fro m them .

Programmin

g language s I t i s generall y recognized , excep t i n a fe w las t pocket s o f resistance , tha t ther e i s somethin g t o b e gaine d fro m th e us e o f language s o f highe r leve l tha n thos e o f th e com - puter s themselves . Th e programmer' s tim e save d i n writin g an d correctin g a progra m fa r outweigh s an y additiona l compute r tim e use d i n languag e translation . If , i n addition , th e resultin g reductio n i n program testin g tim e i s take n int o account , ther e ma y eve n b e a reductio n i n tota l compute r tim e used . I n fairnes s t o thos e remainin g pocket s o f machine-languag e programmers ,• IBM United Kingdom Limited, Education Centre, 15-17 Lodge th e blam e shoul d probabl y b e place d o n th e compute r designers , sinc e the y hav e eithe r faile d t o produc e ade

-quate language processors or have failed to enlighten theusers as to their advantages. It is disturbing to findcoming from one of our leading mathematical labora-tories such an understatement as this: "A computerwhich obeys, say, five instructions per microsecond isprobably going to consume programs faster than anyreasonable team of programmers can produce them, ifthey have to work in machine code." (Barron andHartley, 1964.) It is, of course, unfair to take thisquotation away from its context,

an d th e author s d o g o o n t o sa y later : "I t i s tim e tha t softwar e (operatin g sys - tem s a s wel l a s compilers ) an d hardwar e wer e treate d a s equa l contributor s t o th e tota l problem-solvin g objectiv e o f computers, . . ." Even in this country the ratio of the cos t o f programmers ' tim e t o th e cos t o f compute r tim e i s increasing , an d user s wil l eventuall y b e force d t o realiz e tha t i t ma y pa y the m t o improv e th e efficienc y o f thei r staff , if necessary at the expense of computer time. We ma y conclud e tha t high-leve l languages , wit h thei r pro - cessor s an d thei r diagnostics , ar e her e t o stay . I t i s als o necessar y t o realiz e tha t a languag e processor , whic h i s a complicate d progra m t o translat e a high-leve l languag e int o machin e language , mus t reac h a certai n leve l o f efficiency , i n spit e o f th e precedin g comment s o n th e greate r importanc e o f th e efficient - use of program- mers . In the past, some processors have not done this, an d i n particula r hav e no t ha d adequat e diagnosti c facilitie s buil t int o them . Error s i n program s ca n b e classifie d int o tw o groups : clerica l errors , wher e th e programme r ha s instructe d th e machin e t o d o somethin g whic h i s physicall y impossible ; an d logica l errors , wher e th e machin e ha s bee n aske d t o d o somethin g whic h i s valid , bu t no t wha t th e ma n wit h th e proble m intended . I n th e first grou p th e compute r designe r ha s a n obligatio n t o lear n fro m users ' experienc e wha t error s ar e mad e an d t o ensur e tha t thes e ar e diagnose d b y th e processor . (T o tak e a n obviou s exampl e i t i s inadequat e fo r a processo r t o desis t fro m translatio n whe n i t ha s foun d a singl e erro r i n a program : i t shoul d attemp t t o find a s man y a s possibl e eac h tim e i t i s used. ) Th e secon d grou p i s n o concer n o f th e processo r bu t come s i n .th e are a o f th e externa l syste m desig n an d control . Th e designe r ca n stil l hel p her e b y mean s o f aid s t o dynami c progra m testing .Road, London, N. W.$. 24

9Downloaded from https://academic.oup.com/comjnl/article/7/4/249/354078 by guest on 12 June 2023

Operating systems

Progra

m testin g I n th e bes t planne d installations , eve n thos e expectin

gto do entirely routine commercial work, programs dohave to be tested occasionally. If an organization makesno changes in its requirements for too long, it is probablyan indication that its management is moribund. Andeven the best of managers make mistakes or change theirminds once in a while, so modifications will undoubtedlybe required sooner or later.

Developing

, modifyin g an d testin g program s involve

sthe use of these complicated language processors forshort periods, so even the installations with a large,stable workload are bound to have a variety of whatamount to short, complicated jobs to run. For installa-tions where program development is the order of the day,the problem of handling a large number of

ver y short jobsrapidly becomes acute. A s alread y mentione d th e effectivenes s o f th

e individualtest runs can be greatly increased by an efficient dynamictesting system which enables a programmer to performdumps of selected quantities at selected stages in theexecution of a program, to help deduce where his logicalerrors lie. This again is an area in which the designercan profit greatly from users' feedback in deciding whatform of tracing or dumping facilities are going to be mosthelpful.

Whil e discussin g shor t jobs , i t i s probabl y appropriat

eto remember that there are many new short jobs whichwould arise spontaneously, if an adequate means ofhandling them were available. This trend is desirable,as long as these new jobs are economically worth while.It might be as well just to bear in mind Parkinson's lawabout the expansion of work to occupy the computer timeavailable.

Superviso

r program s Havin g establishe d tha t al l installation s wil l hav e som

eshort jobs to process, and many will find that perhaps ahalf of their total running time is composed of short jobs,the question of job set-up time and transition betweenjobs becomes important. This is again an area where thedesigner has an obligation to help, and most users arebeginning to accept that they will profit by allowing thecomputer to control the transition between

jobs

. This isdone by means of a "supervisor program," a part ofwhich will always reside in the high-speed store of themachine. By the use of such programs, a stack of jobscan be given to the machine, separated by control infor-mation for the supervisor to recognize what type of jobfollows. The time saved overall should more than com-pensate for the space occupied by the supervisor in allbut exceptional circumstances. The supervisor programin practice has many other additional functions to per-form, and these will be referred to later.

Th e us e o f a superviso r implie s tha t th e programme r i

sno longer allowed anywhere near the operator's console,and some of the old school may resent this. However,forcing programmers to do their thinking away from themachine can do nothing but good, and may even en-

courag e the m t o loo k ahea d an d anticipat e problem s whic h ma y aris e i n testing . N o on e thes e day s woul

ddream of installing a complete computer system withoutfirst doing a comprehensive systems analysis and antici-pating the problems which its installation might cause.In the same way, but at a much lower level, no program-mer should be writing a program without having thoughtof the implications and possible difficulties in the imple-mentation of his program.

Inpu t an d outpu t

Howeve

r sophisticate d th e inside s o f computer s ma

ybecome, with their thin-films and their nanoseconds, asystem is only of use if it can communicate with the out-side world. It is in the area of input and output thatmost of our future problems will lie, since a significanterror-rate is inevitable where moving parts are concerned.This must be catered for by not only detecting errors, but

also

, wherever possible, by allowing the system to carryon correctly in spite of them. This may involve auto-matic repetition of a faulty operation, or even the auto-matic amputation of a faulty device and its replacementby another. Such operations should be well within thecapabilities of the supervisor programs of today.

Anothe

r functio n o f th e superviso r i s th e interleavin

gof the use that a variety of input and output devicesmakes of the central processing unit. Mechanicaldevices are necessarily slow by comparison with thecentral processor, and the scheduling of the use thatautonomous input-output channels make of it is quite acomplicated procedure, especially when the need tohandle errors is taken into account. To cope with thissituation it is desirable that all input and output opera-tions are handled by the same set of

routines , irrespectiveof the job being done, so again this becomes a functionof th

e supervisor. An extension of this technique, some-times called "multi-programming" or "time-sharing,"allows several programs to reside in a computer simul-taneously, each carrying on independent input-outputoperations while competing for control of the centralprocessor. Some of the ways in which the hardwarecan help the supervisor in such operations will be men-tioned in a later section.

Th e discussion s s o fa r hav e bee n suggestin g tha t ther

eis a need for both language processors (and other special-ized programs) and for a supervisor capable of con-trolling all the component processors of the system, andof handling all input and output. These two together arecommonly referred to as an "Operating System." Thisleads us to the next question, which concerns the overallsize of any computer. The implementation of anoperating system presupposes a certain minimum size ofmachine, since its functions are bound to require somesignificant computing power. It has long been acceptedthat the cost of a job goes down as the size of the com-puter goes up, provided the machine is fully-loaded. Butwhether it

i

s desirable to use as large a machine as possibledepends, from the user's point of view, on whether he gets

25

0Downloaded from https://academic.oup.com/comjnl/article/7/4/249/354078 by guest on 12 June 2023

Operating systems

bette r valu e fo r mone y a s a result . Th e penalt y t o th e individua l use r fo r th e us e o f a larg e machin e i n th e pas t ha s bee n a decreas e i n it s accessibility . Wit h th e adven t o f adequat e operatin g system s thi s shoul d n o longe r apply , sinc e i t i s no w possibl e t o as k th e machin e t o handl e man y job s concurrently , and , fo r example , a shor t tes t ca n b e allowe d t o interrup t a lon g job , hav e exclusiv e us e o f th e machine , an d the n allo w th e interrupte d jo b t o continu e a s thoug h nothin g ha d happene d whe n i t ha s finished. Ad d t o thi s th e valu e t o th e use r o f havin g a machin e capabl e o f usin g powerfu l languag e processor s eve n fo r smal l jobs , an d i t seem s tha t th e reason s fo r usin g a s larg e a compute r a s possibl e ar e toda y stronge r tha n ever .

Specialize

d applicatio n area s I n additio n t o th e mor e conventiona l applicatio n area s o f commercia l an d technica l computin g ther e ar e som e specialize d area s whic h requir e highl y specialize d system s t o contro l them . On e suc h are a i s tha t o f dat a trans - missio n wit h it s problem s o f messag e assembly , erro r handling , on-lin e contro l fro m remot e location s an d s o on . Anothe r are a i s tha t o f proces s control , wit h it s problem s o f analogue-digita l conversion , mathematica l model-building , 24-hou
r servic e an d th e frightenin g possibilitie s o f th e immediat e physica l consequence s o f errors . I n hi s openin g addres s t o th e Edinburg h Conferenc e Si r Edwar d Playfai r suggeste d tha t thes e migh t presen t anothe r reaso n fo r no t usin g on e bi g compute r (Playfair , 1964)
: "Are we sure that we shall in due course want to mov e thing s an d t o produc e statistic s fro m th e sam e cen - tra l processor ? Th e requirement s o f complicatio n an d reliabilit y ar e different. " Thi s argumen t ha s certainl y bee n vali d i n th e past , an d ma y wel l stil l b e s o a t thi s poin t i n time , bu t i n du e cours e i t ough t t o los e it s validit y i f th e compute r i s t o b e exploite d t o th e full . A s lon g a s w e regar d a manufacturin g proces s a s quit e separat e fro m contro l o f th e stock s require d i n th e process , whic h agai n ar e separat e fro m th e sale s order s fo r th e product , the n w e ar e justifie d i n usin g separat e technique s fo r pro - cessin g each . Bu t onc e w e mechaniz e th e dat a proces - sin g i n thes e areas , o r i n th e area s o f accounting , payroll , work-scheduling , produc t desig n o r an y othe r suc h activities , w e hav e a potentia l mean s o f applyin g bette r managemen t contro l t o ou r organization . Computer s ar e alread y bein g use d a s tool s o f managemen t i n al l o f thes e area s separately , bu t no t man y organization s hav e integrate d thei r purchasin g wit h thei r stoc k contro l o r thei r payrol l wit h thei r productio n recording , i n spit e o f th e obviou s connections . Onc e al l th e significan t aspect s o f a n organization' s operation s hav e bee n mechanized , ther e exist s i n th e compute r syste m a mode l o f tha t organization , and , provide d managemen t kno w wha t question s t o ask , an d adequat e information-retrieva l technique s hav e bee n de - veloped , the n th e compute r ca n becom e a significan t con - tributo r t o th e overal l contro l functio n o f management .

Furthe

r tha n this , on e o f th e mos t importan t activitie s o fmanagement is prediction, and the very fact that a model o f th e significan t aspect s o f th e organizatio n exist s in - troduce s th e possibilit y o f simulation , an d make s economi c test s o f variou s managemen t policie s a rea l one .

Extensiv

e activit y i n thes e area s i s clearl y som e wa y of f yet , bu t i t doe s mea n tha t ultimatel y i t ma y wel l b e desirabl e t o perfor m man y widel y differen t type s o f operatio n o n compatibl e computers . Th e problem s o f reliabilit y an d complicatio n ma y wel l hav e bee n differen t fo r differen t classe s o f wor k i n th e past , bu t th e difference s ar e diminishing .

Probabl

y b y no w an y reade r o f thi s pape r wh o i s con - cerne d wit h research , developmen t o r technica l desig n problem s i s beginnin g t o fee l neglected . Bu t thi s i s no t reall y so , a s eve n hi s problem s ar e a t bes t par t computa - tion , par t dat a processing . H e wil l certainl y expres s hi s problem s i n som e languag e suc h a s ALGO L o r FOR - TRA N (le t u s no t worr y abou t trivia l diversion s a s t o whic h i s better ; neithe r i s perfect , an d mos t problem s ca n b e expresse d adequatel y i n either) , s o hi s compute r wil l hav e t o handl e a grea t dea l o f languag e translatio n a s wel l a s technica l computation . I n an y case , i t i s prob - abl y wort h investigatin g ho w man y designer s workin g i n industr y produc e wha t the y thin k ar e ne w designs , whe n a n adequat e informatio n storag e an d retrieva l syste m woul d enabl e the m t o find a simila r desig n produce d thre e year s before . Eve n i n situation s wher e designer s hav e n o illusion s abou t thei r wor k bein g original , i t i s a t presen t les s troubl e t o star t agai n tha n t o searc h i n hop e o f finding anythin g usefu l i n history . I t appear s tha t al l potentia l compute r users , irrespec - tiv e o f thei r clas s o f problem , ma y wel l find themselve s usin g wha t amount s basicall y t o identica l equipment , bot h i n term s o f hardwar e an d o f "software, " a s th e operatin g syste m an d it s component s ar e sometime s called . Obviousl y on e o f th e reason s fo r thi s i s t o mak e i t possibl e fo r manufacturer s t o produc e enoug h com - puter s t o kee p u p wit h th e demand . Anothe r one , les s immediatel y obvious , i s i n th e are a o f real-tim e applica - tions , where a second machine which is necessary for reliabilit y nee d n o longe r b e anythin g lik e th e sam e siz e a s th e first, a s lon g a s th e sam e program s ca n ru n o n either . Fo r thi s universa l approac h t o b e acceptabl e suc h computer s mus t b e extremel y flexibl e a t th e hard - war e leve l i n bot h siz e an d power . However , a s tim e goe s o n thi s burde n o f flexibilit y become s mor e an d mor e on e o f th e function s o f a n operatin g system , an d som e o f thes e function s wil l no w b e considered . Th e function s o f a n operatin g syste m Th e function s whic h a n operatin g syste m mus t b e abl e t o handl e t o tackl e al l th e area s o f activit y whic h hav e bee n discusse d ar e a s follows : 1 . Automati c handlin g o f a variet y o f processors . Thes e mus t includ e standar d languag e processors , othe r standar d routine s suc h a s sortin g program s an d program s fo r settin g u p addressin g structure s fo r direct-acces s storag e devices . I n additio n i t mus t b e possibl e fo r a n J25

1Downloaded from https://academic.oup.com/comjnl/article/7/4/249/354078 by guest on 12 June 2023

Operating systems

installatio n t o includ e an y processo r o f it s own , an d arrang e fo r suitabl e additiona l contro l informatio n t o b e recognized . Th e superviso r mus t b e abl e t o handl e th e transitio n betwee n processors , an d als o carr y ou t an y accountin g function s require d i n installatio n manage - ment . 2 . Identification of input and output units. When program s ar e writte n i n high-leve l language s i t i s desir - abl e t o avoi d specifyin g th e physica l for m o f a n inpu t o r outpu t devic e withi n th e program . Th e device s availabl e i n on e installatio n ma y change ; th e numbe r o f dat a channel s availabl e ma y change ; i t ma y b e require d t o ru n program s a t othe r installations ; librar y routine s use d i n man y installation s mus t b e easil y adaptabl e t o th e equip - men t available . T o cop e wit h thes e situations , th e super - viso r mus t b e abl e t o establis h correspondence , a t th e tim e a jo b i s run , betwee n th e symboli c devic e name s use d i n th e progra m an d th e physica l unit s actuall y available . I t i s desirabl e tha t thes e name s shoul d b e independen t o f th e type s o f device s available , s o tha t a jo b ma y b e ru n equall y easil y usin g fo r dat a files magneti c tapes , cor e storage , magneti c discs , o r whateve r els e tha t ma y b e available . 3 . Control of input and output operations. To enable severa l autonomou s input-outpu t channel s t o operat e concurrentl y th e initiatio n an d terminatio n o f suc h operation s mus t b e controlled b y a progra m commo n t o al l jobs . Thi s Input-Outpu t Contro l Syste m mus t b e abl e t o handle : (a) erro r detectio n an d erro r recover y procedures ; (b) data-transmissio n an d process-contro l terminals ; (c ) th e sharin g o f th e centra l processo r b y severa l input-outpu t channels ; {d) th e sharin g o f th e centra l processo r b y severa l program s (whe n thi s ca n b e justified) . Th e erro r contro l shoul d b e abl e t o handl e tw o classe s o f error : hardwar e condition s (wit h automati c erro r loggin g fo r th e engineers ' benefit) , an d programmin g conditions , suc h a s incorrect labellin g o f files, o r end-of-ree l condi - tion s o n tap e units . 4 . Operating System Editing. An operating system whic h se t ou t t o b e al l thing s t o al l me n woul d b e s o cum - bersom e tha t n o on e woul d us e it . I t i s therefor e essen - tia l tha t a n editin g facilit y b e provided , s o tha t th e operatin g syste m ma y b e modifie d t o contai n onl y thos e feature s neede d b y a particula r user . Further , th e edito r progra m wil l b e neede d periodicall y a s th e requirement s o f a n installatio n change , an d a s ha s alread y bee n said , i t i s a ba d sig n i f a n installation' s requirement s d o no t chang e fo r to o long . Wha t pric e th e operatin g system ? Al l thes e facilitie s canno t b e provide d a t n o cost , s o i

tis as well to consider what their provision does cost.The programming effort the designer must make isinescapable, and should be just as much a part of hisinvestment in product design as the calculations that gointo his electronic circuits. It is no longer acceptable for

hi m t o regar d th e provisio n o f softwar e a s a luxur y t o b

eadded if possible at a later stage, and already the moreshrewd purchasers of computer systems are looking at thesoftware just as hard as the hardware.

Th e othe r facto r i n th e cos t o f providin g operatin

gsystems is the one most often complained of, the amountof high-speed storage they occupy. This complaint onthe part of the user is as groundless as it is understand-

able

. If only the designers would exclude the storageoccupied by the system from the amount they offer theuser, the problem would not arise. Obviously theamount of storage occupied by the system will vary, butthe amount offered should be reduced at least by theminimum the operating system may require.

Ho w th e hardwar e ca n hel p I f operatin g system s ar e t o b e implemente d effectively , thei r function s mus t b e appreciate d a t th e tim e whe n th e hardwar e i s designed . Feature s necessar y t o mak e a n operatin g syste m eas y t o implemen t ar e these : 1

. Automatic interruption of the central processor.The hardware must be able to cause an interruptionof the program currently being executed, irrespec-tive of what is being done, and without the know-ledge of

th

e writer of the interrupted program. Theevents which require this are, for example, the com-pletion of an input or output operation, the dis-covery of an error, or a request from a remoteterminal for servicing. Such interruption facilitiesbring with them many detailed problems whichmust be considered, such as the method of deter-mining which interruption should have priority iftwo are waiting to be processed.

2

. Storage protection. It must be possible to preventa programmer from, interfering with parts of themachine which are not concerned with his program,and especially with parts where the operating sys-tem resides. It must be possible for the systemitself to override these restrictions, while anyattempt to do so by a user should cause an interrup-tion as described in item 1. It is helpful if it pro-duces a message saying what he has done wrong,before returning control to the operating system toterminate

th e job. The programmer should also beable to specify his own protected areas. 3

. Error detection. Errors of all sorts, whether in-valid data input, machine errors or program errorsmust be detected reliably, and correction or by-passaction undertaken, so that the running of the systemis not interrupted unnecessarily. If the machinecan assist the maintenance engineer by telling himwhere it feels poorly, so much the better. A greatdeal can now be done in this direction with built-inhardware diagnostic programs, which automaticallycheck the correct functioning of the various com-ponents of a system. It is an interesting paradoxthat the importance of error-checking increases as

25

2Downloaded from https://academic.oup.com/comjnl/article/7/4/249/354078 by guest on 12 June 2023

Operating systems

th e readabilit y o f equipmen t increases . Wherea

sthere was a time when no one really expected com-puters to give the right answers all the time, we nowhave a right to expect that, if we get an answer at all,it can be relied upon.

4

. Relocation. Languages which take no account ofthe machine configuration, and which also allowpieces of program which have been written andtranslated on separate occasions to be run together,make necessary an efficient means of relocation.This is particularly important for programs whichexceed the size of

th

e available machine and have tobe run in several phases. Sections of coding maybe executed from any part of the store, and theprogrammer cannot (and should not) know where.So the operating system - or more particularly theloader - must be able to load different sections of aprogram into whatever locations are required.This function has until recently been performedentirely by programming in the loader program - but it is an operation in which the whole system canbe made much more efficient if the hardware andsoftware designers work together.

5

. For a computer to be universally acceptable, itsmachine-language instruction codes must be com-mon throughout a complete range of size of com-puter. It is no longer good enough to expect theuser to embark on a marathon re-programmingoperation simply because his business has expandedenough to require a larger computer. Compati-bility at the level of high-level languages is a goodstart, but compatibility at machine-language levelis even better. Clearly it will be worthwhile toprovide some optional features on some versions ofa machine: exclusively commercial users who arevery pleased with their powerful editing instructionsdo not take kindly to having to subsidize standardfloating-point hardware for the benefit of theirtechnical friends. But now that the engineeringtechniques available make it possible to modify thecomputer instruction set very easily (by producingan economic form of read-only storage systemsimilar in concept to the wired store in EDSAC 2(Wilkes, Renwick and Wheeler, 1957) or the Man-chester University slug store (Kilburn and Grims-

dale

, 1960), the basic framework of a central pro-cessing unit can be common to all application areas.Another point not to be overlooked in this area ishistorical compatibility. The designer cannotpenalize all his existing customers (who have prob-ably provided a lot of his resources to develop newcomputers!) by developing machines on whichexisting programs will not run. So compatibilitybetween the past and the future is equally impor-tant.

6 . Standar d interfac e fo r inpu t an d output . I

tappears that coming generations of central pro-cessing units can still vary, but that is nothing to thevariations we can expect in input-output devices.

W e alread y hav e t o cate r fo r everythin g fro m

aTelex line at a few characters/sec, to a radio link athundreds of thousands. To do this, to makeallowance for visual and audio devices which arethe latest arrivals, and at the same time to allow forfuture devices which have not yet been thought of,the only possible solution is to define a "standard-interface." As long as all devices conform to aformal set of conditions, the input-output channelson a computer can handle whatever devices may beconnected.

Man y computer s have , o f recen t years , ha d severa l o

fthe features just listed, but not until the recent announce-ments of compatible computer ranges like the IBMSystem/360 or the

I.C.T . 190
0 hav

e systems become avail-able which should have all these features simultaneously.This does not mean, of course, that the end of the trailhas been reached, either for hardware or for software.It

is

, rather, the beginning, since it should now be possibleto incorporate improvements in hardware without theuser even being aware of it.

I t i s no t a s eas y t o mak e change s i n programmin

glanguages without the user's knowledge as it is in hard-ware, and although he may be excused for not wel-coming changes, he must accept the fact that computerlanguages are living languages just like spoken languages.They must therefore develop to take account of changingcircumstances. Being defined more formally, we havemore control over when changes should take place, butchanges there must be. Once this is accepted, then theuse of an operating system does a great deal to simplifysuch problems for the user.

Th e operatin g syste m an d th e use r Man y o f th e operation s whic h use d t o b e regarde d a sthe proper sphere of th

e program, or more accurately, theprogrammer, are, with machines at the stage of develop-ment now reached, becoming functions of the hardware.It was suggested recently that computers may reach thestage one day where "efficient equipment 'is grown' toreplace those portions of

th

e stored programs which havebeen proved successful or optimized in some sense"(Carr, 1964). This may well take some time, but alreadysome programmers fear that the removal of some of theirresponsibilities is reducing their importance. This fearis not justified if the programmer faces his real

job

, whichis to solve problems. He should be grateful for anydevelopments which allow him more freedom to devotehis time to improving his techniques in the area he shouldbe studying, namely problem solving.

Today'

s programme r mus t certainl y accep t th e fac t tha

the no longer understands the purpose of many instruc-tions which appear in a program he has written. But hehas long since given up expecting to understand how thehardware of his computer functions, so why should heworry about the software, especially as the line betweenthem is becoming so flexible? There will always be a

25

3Downloaded from https://academic.oup.com/comjnl/article/7/4/249/354078 by guest on 12 June 2023

Operating systems

nee d fo r skille d professiona l programmer s t o develo p operatin g system s an d t o pus h th e availabl e equipmen t t o th e extrem e limi t o f it s capabilities , bu t thei r jo b i s n o longe r th e sam e a s tha t o f th e programmer . I f a pro - gramme r (o r a man-with-a-problem , a s h e shoul d perhap s b e called ) doe s fee l th e nee d t o descen d fro m hi s high-leve l languag e t o a n assembl y languag e h e wil l find i n tha t languag e man y feature s whic h ar e o f ver y littl e us e t o him . The y ar e onl y ther e fo r th e benefi t o f compiler - writer s an d othe r professiona l programmers , an d rightl y so , since they should be the most frequent users of such level s o f language . N o argumen t i s reall y a s simpl e a s this , and there may well be situations in which a problem- programme r need s detaile d knowledg e o f hi s computer to avoi d makin g inefficien t us e o f it . Thi s wil l stil l matte r unti l computer s ar e give n awa y fre e i n exchang e fo r th e wrapper s fro m si x input-outpu t devices , an d tha t wil l no t b e fo r a littl e whil e yet . Th e chance s ar e tha t th e bes t systems-programmer s wil l b e discontente d problem -programmers, since they will be in the very best position t o appreciat e th e users ' rea l needs . A s a direc t resul t o f th e us e o f operatin g system s i t i s possibl e economicall y t o tur n th e man-with-a-proble m int o a problem-programme r abl e t o communicat e easil y wit h an extremely powerful problem-solving tool. It may appea r a t th e momen t tha t h e i s bein g kep t furthe r awa y fro m hi s ne w too l b y th e operatin g syste m tha n hi s pre - decesso r was . Thi s ma y b e true , bu t h e i s nevertheles s a s a use r alread y gettin g bette r servic e fro m it , an d al l th e hardwar e an d softwar e ar e no w availabl e t o mak e i t appea r tha t eac h use r ha s exclusiv e us e o f th e system . I t wa s a mos t fitting conclusio n t o th e Edinburg h Con - ferenc e tha t Dr . Wilke s shoul d hav e show n thi s s o clearl y i n hi s demonstratio n o f th e us e o f th e MI T Compatibl e

System

. I t i s t o b e hope d tha t i t wil l no t tak e to o lon g fo r th e economi c situatio n t o allo w u s t o pu t man' s tim e a t a highe r premiu m tha n tha t o f a machine .

Reference

s

BARRON

, D. W., and HARTLEY, D. F. (1964). "The Influence of Automatic Programming on Machine Design", (UKAC report,

p . 21). CARR

, J. W. Ill (1964). "The Future of Programming and Programmers," The Computer Bulletin, Vol. 8, No. ], p. 9.

KILBURN

, T., and GRIMSDALE, R. L. (1960). "A digital computer store with very short read time," Proc. I.E.E., Vol. 107B, p.567.

PLAYFAIR

, Sir EDWARD (1964). "Computers and psychology," The Computer Journal, Vol. 7, p. 1. UKA C repor

t on 1964 Edinburgh Conference: "The Impact of Users' Needs on the Design of Data Processing Systems,"

Organize

d b y th e B.C.S., Brit.I.R.E. and I.E.E.

WEGNER

, P. - Editor (1964). Introduction to System Programming. Academic Press, London.

WILKES

, M. V., RENWICK, W., and WHEELER, D. J. (1957). "The design of the control unit of an electronic digital computer,"

Proc. I.E.E., Vol . 105
, p . 121
. Boo k Revie w

Management

Standards for Data Processing, by DICK H.

BRANDON

, 1963; 404 pages. (London: D. Van Nostrand

Co. Ltd., 93s.)

I n the past few years, the literature of Data Processing has grow n almos t to a flood. Most of it has poured over the specialist - analyst , programmer , engineer - dealin g wit htechnical matters pertinent t o hi s field. Much of the rest has bee n directe d at managements, explaining the intricacies of th e subject , and quieting their fears of its impact. Ther e has , however, been little of direct service to the harasse d D.P . executiv e whos e dail y lot it is to turn the eccen-tricies o f hi s wayward (if brilliant) brood into the targetsachieved an d work accomplished that alone can justify the existenc e of a computer installation. Mr. Brandon's bookwill d o much to ease his sufferings. Clearly the content has bee n distille d fro m experience , and will prove to be an in- valuabl e guid e pas t th e pit s an d trap s whic h li e i n wai t for eventhe most experienced o f those who seek to set up an efficient,productive, controlled data processing organization. Th e them e o f th e book is Control, and its development is concerne d wit h the establishing of standards to which everyaspect o f D.P. work can be subjected. To this end, all the softwar e component s (and a little of the hardware) are meticulousl y dissected , classifie d and coded, and their rela-tionships with on e another carefully defined. From the skeleto n thus expose d Mr. Brandon builds up a series of suggeste d technique s by which the D.P. group can be startedon the right path, an d kept from wandering too far from it.

System

s Analysis , Programming , Operation s Performanc eEvaluation ar e th e major topics with which the book deals,and each i s stuffed with formulae and numerical information.It would b e unwise to apply the former to any specific case(other than th e originating one) as they stand, but they do serv e a s a most useful starting point. Th e essenc e of control in most organizations lies in adequate(but minimal) documentation, an d i t i s heartening to readMr. Brandon's constant iterations o n this matter. Th e boo k i

s specially recommended for systems analystsand programmers. They would then look with less disfavourupon

th e efforts of their superiors to guide their creative talentsinto narrower channels. C . E . HARDING 25

4Downloaded from https://academic.oup.com/comjnl/article/7/4/249/354078 by guest on 12 June 2023