Resources management subsystem for a

large corporate information system

by HO-NIEN LIU, WILLIAM S. PECK and PAUL T. POLLARD

Pacific Ga8 and Electric Co. San Francisco, California

INTRODUCTION

In the past quarter century, from MARK 1 (1944:) ENIAC (1946) to IBM-360/195 and CDC-7600, the information processing oommunity has progressed in diametrically opposite directions. On the one hand, the hardwarel and software2 development has been toward a general purpose computer system. On the other hand, the computer users often dedicate a general purpose computer for a special application where only parts of the computer system resources are used.

There are rarely any special computer applications which' will utilize a general purpose computer to its full capacity in a balanced fashion. A corporate in­formation system with its comprehensive application spectrum3 will. exploit the full potential of a general purpose computer system.

To assure a successful marriage between the com~ prehensive corporate information system and a general purpose computer system one must resolve the probelm of how to direct" the different application subsystems to the desirable computer resources. After this problem is resolved, all the application subsystems within the corporate information system will operate in a homo­geneous environment to obtain the optimum efficiency of the system.

The rest of the paper will describe a resource man­agement sUbsystem designed and implemented with the above objective in mind.

SY8tem requirements

The following requirements are essential for an ef·

fective resources management subsystem for a large corporate information system.

441

1. Provide for the Orderly Execution of Program8

All applications and systems programs must function in harmony within a large corporate information system to ensure reliable and ef­ficient operation. For instance:

• Coordinating the execution of various asynchronous subsystems:

• File/data management subsystem • Teleprocessing subsystem • Systems service facilities • Various applications subsystems

• Prevent contention of usage of hardware and software facilities to provide optimal use of these resources.

2. Support of a Variety of Applications Subsystems

A comprehensive corporate information system must contain many operationally independent yet logically interrelated a.pplication subsystems. The resources management subsystem should be able to support applications in a manner best suited to the needs for each individual project without placing undue restrictions on the others. Following are a few representative types of applica.tions.

From the collection of the Computer History Museum (www.computerhistory.org)

442 Fall Joint Computer ClPnference, 1969

• Real-time, high voll1me, random arrival transactions require large numbers of pro­grams to process them. For example, a simple inquiry response application which services the general public.

• Real-time, low volume random arrival transactions require. a small number of rather complex programs to handle them. For example, on-line computation and up­date of the data base requires more proc­essing and safeguard! considerations than does the inquiry type Qf transaction.

• Batch, extra high vblume sequential in­puts require extraordinary complex proc­essing logic. For example, maintaining a master file with several million large records involves the insertio:p., deletion, and up­date of files as well :;LS the detail analysis of the data. It also in:cludes the generation of scores of reports ~nd intermediate files as input to other subsystems.

• Batch, medium or low volume processing uses time-consuming .;nultiple file searching strategy to produccl summary reports. For example, as the! result of exception conditions many in~errelated data are analyzed, summariz~, and reported to aid management' s deci~ion making.

3. Operate in a Multi-Level, Multi-Programming Mode

Because of high volume, real-time applications which process a large number of messages, con­ventional multi-programnl-ing techniques can­not keep abreast of the traffic. Therefore, it is necessary that the systein be operated in a multi-Ievei multi-program~ing, or subtasking environment within a si~gle region of main memory.

For flexibility in operation, the system should also have the following capabilities:

• Ability to suspend a subtask in one region without endangering the operation of the other subtasks in the Same region.

• To transfer a sUbtask out of a region in order to be able to ,schedule a different subtask in its place.

• To change priority dyjnamically to provide the best system throughput.

4. Simplicity ojOperaiion

When operating a real time system with a large network of remote terminals, events occur far more rapidly than the best computer operator can respond to them. Therefore, the l'eSOUfi[~es management subsystem should have facilities to perform the following functions:

.Minimize the job control data required.

.lVIinimize operator decision and interven­tion.

5. Test 1vlode oj Operation

In order to properly test programs to be plac:ed in such a complex environment, a test mode of operation should be provided to perform the following functions:

• Allow program testing in an operational environment.

• Assure data security for those files which are accessed from or directed to the cor­porate data base.

• Assure that no actual updating of any of the corporate data base files occurs either purposely or accidentally.

6. Statistic Acquisition and Reporting

A continuous evaluation of the system should be maintained on a day-to-day basis. Statistics can be gathered during the processing day and reported at the end of the day. This permits responsible personnel to evaluate the system

7. Open-Ended Design

The resources management control program should have an open-ended design for ease of system expansion and modification. This will reduce the impact of changes to the control program on any existing subsystem or appliea­tions program.

System structure

Figure 1 illustrates the hierarchial structure on three leveli;; of multi -programming.

The first level utilizes the' multi-programming capabilities of software supplied by the computer manufacturer. We call it the "host operating system." At this level the resources management subsystems will execute concurrently with other processors, such as COBOL, FORTRAN, or some other major appli­cation subsystems. The second level of multi~pl'o-

From the collection of the Computer History Museum (www.computerhistory.org)

gramming is accomplished by the regional supervisors (resources management subsystems) or the so-called "subtasking facility." This means that many inde­pendent programs (subtasks) can be run concurrently within a region or partition of the host operating system. The third level of multi-programming is achieved by means of reentrant module (or pure code). If a module will not self-modify any part of its code during processing, the module ,Is capable of parallel processing of multiple numbers of transactions.

System logic flow

As an overview of the P. G. and E.'s corporate in­formation system refer to Figure 2. You will notice that the manufacturer's operating system facility serves as the host to control the overall opera,tion. On the left of the figure is the front end of the tele­processing subsystem performing such functions as polling, addressing of the terminal network, message queuing and dispatching, terminal hardware error and security checking, etc. The next major part of the TP subsystem is the input message editing (TPCHUG) and output message editing package. This package makes all the message processing programs indepen; dent of terminal hardware. At the base of the figure, the file management subsystem4 centralizes control of all I/O functions; it exchanges information from the information system data base and therefore, makes the data independent of applications programs (or message processing programs). Beneath the operating system we find the resources management subsystem functioning as the regional supervisor for all the sub­tasks within the on-line region and, therefore, we can support different application subsystems in the same region. We can also open another region for on-line message processing and share the file management, teleprocessing and resources management subsystems.

(I) REGION (PARTITION)

(II) SUBTASK

(III ) PROCESS QUEUE

Figure I-Hierarchical control on three levels of multi­programming

Resources Ma.nagement Subsystem 443

RESOURCE MANAGEMENT SUBSYSTEM

il

Figure 2-Host operating system

On the right side of the figure, we can open a number of background regions for computing or batch type jobs, or we can have batch executive subsystem (BESS) control the subtasking in the batch region. The rest of this section will briefly describe how a typical on­line region or a batch region works under the resources management subsystem.

The on-line system

The Controller of On-Line Processing (COP) is designed to control the execution of the on-line portion of the system. Figure 3 graphically depicts how the computer's main memories are allocated during the on-line processing day.

• Initialization of the On-Line System

At the start of each on-line day, two subsystems must be initialized. COP coordinates the actions of these two subsystems in preparation for the on-line execution of message processing programs.

• At first, the teleprocessing subsystem must open the lines to the remote terminals and initialize the queues where the messages will await their turn to be transmitted and processed.

• In the meantime, the initialization routines of COP are busy establishing the necessary con­trol blocks and data pools (see Appendix I).

• A program control block will be built for each message processing program. A master control block will be built for each transaction response pool (TRP). The number of TRPs to be used is specified by a parameter that is brought in with other start-up control data such as the number of event control blocks (Figure 4) .

• Subsequently, COP will cause the file manage­ment subsystem to build file/data control

From the collection of the Computer History Museum (www.computerhistory.org)

444 Fall Joint Computer Conference, 1909

-----------------------------------------------------

~ Manufacturer J Rcslt/tYl/ Olf'"dhilg J'fjf/CIII

!J~ ~~ IlJSk COtl/rol ~ Blocks

.~ ~ RCIfIPIc ~rlllilla/, Lille alltl AllJJ.tt9gd CtJIII!PI , ~.S

~s.,)"""

~~~ ~~

COnt/1)1 PI ()n-Line ProCfJfJI/lg (()()p) Svlitas5 Llflkage (SLINK

1st Processiflg f[gq!~~ _____________

1St BIJMP ~ w: Messaqe 5et r-- -i---------- --- ----. .~ PCHIJ&) I $I11aflsactioY ~ rt £dtlOr & Ollfpllf R~sPPflse ,P~

c:s( TPMSeOUT) TRP

~ [{f OVTPlif PW71?)

~ oam Control Manager ~ (OCM) .~ Biill<ecOiilJ' q7iiITpiice itfJ Pro~$i!7g -.J , mNOREC) Program ~ --'- -- --- ----------iff781JMP

froqram CPrlITPI BlockS ~-;- --------- --------- ----------- iftJ7RP /Jader control BIocK.J ---------------Pata Control Blocks

~ .~

Ahl{ othcr off-line w()fk nS:: ~~.§! ~~

Figure 3-Main memory usage during on-line processing

blocks, record descriptors, and data buffer pools. When all the on-line file~ are opened and ready for processing, the file management subsystem will notify COP, and COP in turn will wait until the teleprocessing subsystem has com· pleted its initialization prdcesses.

.As soon as the telepropessing routines have signaled their start of prbcessing, COP repeats 3: sequence of actions to !prepare message proc­essing subtasks for multi~thread on-line opera­tion. COP does this by establishing one sub­task for each TRP and by signaling the operating system to start the teleprocessing get-a-message program (TPCHUG).. .

• Figure 5 shows a path from COP to TPCHUG, but this path is not taken until all subtasks have been established. For example, assume that five streams of messages will be processed concurrently. COP will signal the operating system five times that a subtask is to be es­tablished starting with TPCHUG. and before

Program Confrol BlOC/(8

Marter ContnJl Blocks g

Tft1I1JdCf/OIl! R8Jpo!J.fe ftJOl!

Erent Con/rtl Bloc1s(ECB) For (ljnfr()/ Ptogrc1f!1 COP

1RlllJtJcfion / ~eJPonfe PotJIs (TIR P)

Pam COntrol BI()ckS {or All On-Line

Pr()Cesr/flg

t[;ti1ItJI1.G9c1itJlJ if a.r..rfll1et1Io8 TRP for its t9chve life ill tI7~ CfJIIIPvter:r /!I81i! mClfl()11f

tCte8f&rI aI il1lfializati()n I1m"& lor tiel! QolIJ J'd1tJ De VJ6Y/ IJtth7f olJ-I/i!~ J'lfs#l!!.

Figure 4-Control blocks for on-line processing

releasing control to any of these subtaslks, ClOP will again signal the operating system that five more subtasks are to be established starting with Subtask Linkage (SLINK). All ten of these subtasks are conditionally e)cecuta,ble based on ten event control blocks which will be marked by COP. COP marks the five event control blocks for TPCHUG to show that the five associated TRPs are free, ready to ac­cept input messages. SLINK's event control blocks are marked so that SLINK will wait until a message in a TRP is ready to be proc­essed .

• COP will now wait· for anyone of five event control blocks to be marked by TPCHUG .. I t is while COP is waiting that Path 1. is taken and TPCHUG gets control for the first time; and the system is now active.

• Active On-Line System

TPCHUG makes use of the system support rou­tine FINDREC to locate the place in the TRP

From the collection of the Computer History Museum (www.computerhistory.org)

on-Line C08Ol..

UNKAf?E SECTION

PRociovIl£ lJIYI$IfJ¥ ENTER LINKA6£

1ISIIJI8/1J1Mt E~C()IJOJ.

ENT9. UNK48£ <> CALL 8111fhJtr {/JIM/: .... c> lJI!E! (;()fJOL

£NTER LINKAeE <)I CiLL PCMtJEr lAIN#, .... <>~R~

ENTMLlNKAK c:> CAll. PCMPIIf flJINI. ..... r:::> ENTER a11kr

EKTlRUNKAK <>(;ALL 8IIMPImI (/JIN~ ....

[NTl:R COBOL

ENP

Figure 5-Flow of program control during on-line processing

where the incoming message and its internal for­mat are to be placed. TPCHUG will do the fol­lowing things:

• Get an incoming message from the waiting queue if one is available. If it is not, it will wait until there is one so that other subtasks may be executed.

• Place the message in the TRP. • Edit and translate the message into the in­ternal format.

• Mark COP's event control block for this TRP to show that a message is available for proc­essing.

• Wait until TPCHUG's event control block is again' posted by COP to show the TRP is again ready to accept a message.

When TPCHUG waits, Path 2 back to COP is effectively taken. COP will then check its event cont;ol blocks to' determine which TRP requires serVICe. The following actions are taken by COP:

Resources Management Subsystem 445

8 Via a program control list constructed by TP­CHUG, COP will determine the next module to be applied to the current message in a TRP .

.. Mark SLINK's event control block for this TRP to show that action is to be taken.

f) Wait for the event control blocks to be marked by TPCHUG or SLINK.

Path 3 is now completed and SLINK will gain control when this subtask is made active. At this time the following functions will be performed:

• The required applications program will be loaded, if it is not already in core memory.

• Control will be given to the appropriate pro­gram SO that it may execute.

'. Upon return from the program, SLINK will mark COP's event control block to show that the program has completed its processing.

• Wait upon its event control block for this TRP.

Paths 4, 5, and 6 have been taken, and the same sort of thi,ng occurs for Paths 7, 8, 9 and 10. The mrin difference is that when TPMSGOUT hoos finished putting the response(s) on the out­put waiting queue,. COP's event control block is complete and the TRP is now free to be used again .

• Termination of the On-Line Day

Messages may be in waiting queues or in various stages of processing when termination of the on­line system occurs. COP must assure that the teleprocessing subsystem has received all incoming messages, the input waiting queues have all been emptied and all messages have completed proc­essing before the file management routines close the files and COP releases the subtasks. While the teleprocessing programs are emptying the output waiting queues of messages and trans­mitting them, COP is editing the statistics which have been gathered that day and producing a report from them. After all processing has been completed, control is returned to the operating system.

Batch system

• Initialization

Control information must be gathered and set up in main storage to effect the proper sequence of jobs to be run during a particular batch job stream. The aforementioned control information will contain such things as:

From the collection of the Computer History Museum (www.computerhistory.org)

446 Fall Joint Computer Conference, 1969

--------------------------~-------------------------------------------------------,-------

/ BL..OCKn: \

I / BL.OCK2 \ r I

/ BLOCK,l \ Program Name: Core &pace RequIted

ReserJled Ar84 ABENO COI7r1Jtlon Cixle

InhIbiting CondlhooCOt/ar Jolt Control ClK/8

Proqrc9m Level: Contlihont91 Input-file f/l'1

Locallon of R/~ #"1 CondltlonallnM file *"2 LOC8holJ of Rle 'B

Tht/B il Me bloCK for fam program or,J'Orf fIIeI 1119/1 be eyecuted 1/1 #li.r ClIo/e. ;

Ordered bll Pngrr.91t! i.tfol anti InI!IP/f CM~.

Figure 6-BESS program control blocks

• Program Name. • Resultant" condition code, if job fails to run. • Condition code or codes ;resulting from other jobs which this job depends on in order to know whether or not to execute.

• Program level denoting whether or not this job can run concurrently with· other jobs based on core usage, sequeilce of jobs to run and shared use of data files.

• Names and device locations of conditional files; i.e., files which might or might not be present during anyone job within a job stream.

• Processing During the so-called batch processing, depending on the information supplied for control during initialization time, jobs will be scheduled either alone or as subtasks, depending on core require­ments, availability of data fil~s, and shared access of data files.

• Termination Upon completion of all the 'jobs which could be processed, the operator or o~her appropriate per-

FReGIIA~ NAME

CCPft IT Il:fb"'" IHeRl" IH811l""

C('I' SC901bd IEF8Al't IEfbRH IEFtRl" Il:fB1I1" UMReocc At.."",.

It.FCR~AT 10'"' SYSTEMS/RESOURCES MANAGEMENT ANAL 'lSI SCF 8ATCH PROGRA~ ACTIVITY

JOB/STEP NAME OLETEST I

RESULT TYPE TlMEIMINI-SIZE u: ~EL tUDE CCI'PLE TI ON ALLOTEO/ACTUAL/WAlT 0991( 00 8 A81:NO 000C2 000.1l C6(1I CC 1 t.e INPUT 05211 00 Z NORMAL 05211 00 2· NORMAL C~2" CC A 'BHe 000C5 05211 OC A A8fNO 0013E 0 .. 011 00 3 '"'OIlM .. L C HK CC 6 NOR"AL 01011 CO 9 NORMAL CHI! C2 .. SKIP 1 CEeI( CC; 5"0 ,"PUT 0101( 7 hOT AVAIL

000.11 000.11 2 000.11 000. lit 000 .... 000.13 000.13

0"-29-'69

JOS-" L lBRARY

1

o o Z 1 o o o

TUT AL R",", 11"E eccc "IM.lE S

- "LL 111'H Allf ilEAL TIME, ANt OVERLAP WITHIN LEVELS -- A,nAt TillE IS "1t.LTES.SECCt.tS ••• JUb LI8RARY NLM8ER IS CONCA1EhATICt. t.UMBEII OF LIBRARY FOR PROGRAM

Figure 7-BESS status report

sonnel will be notified as to the status of all the jobs. Such information as:

• J oha which were not run due to data not being available.

• J oba which were not run to oompletion <iue tq a program failure.

• Jobs which were run to completion. • Other information which wiilhelp key person­nel to effectively evaluate their choice ole action.

System facilities

This section will describe some system support facilities ~mplemented to enhance the reliability of the system.

On-line system's facilities

• Program Test Mode of Operation

Any new or updated version of a message prOCeEl8-ing p~ogram which is to be added· to. 1che live system is first run in the test mode even thou!~h the program has gone through unit systom aud high level testing.

If it is an updated version of an operati.on pro­gram, it will have the last copy available ~LS back­up on the library. If it is to update files it will not be permitted to. do so directly, . but 1Jpda~13d records will be saved, verified, and then added to the files in batch runs. Should the progJram f~Lil during the test the old reliable copy will be brought in and normal processing will continue.

With new programs, no backup copy is available so if it fails, it is dropped from the sYEltem. A new program also I;l.ffects the rest of the system in that while it· is executing, any production

From the collection of the Computer History Museum (www.computerhistory.org)

programs that might faiJ will be refreshed and information processed by the new program will also be included in the output.

• Trouble Procedures

Trouble procedures and error defaults have been developed.

• Excess Elapsed Time

Should a' program be in memory top long (elapsed time) to process a message, its priority will be raised so that it can get a greater share of the CPU's time.

• Excess Processing Time

Before control is turned over to a processing program, a timer is set by SLINK to the num­ber of machine cycles to be allocated to -this program for its processing. The number of machine cycles allocated is based upon operating history plus a safety factor. If a program should exceed the number of machine cycles allocated 'to it, ~n interrupt will occur and control will be returned to COP.

When a program is terminated due to exceEf.Sive operating time or has . abnormally ended, a snapshot of the TRP and all associated control blocks is taken. An error message is returned to the terminal from where the transaction was entered and the control block for the program is marked to show that an error has occurred. If the program is used by more than one type of transaction, or is critical to system operation, a fresh copy will be brought into memory. If the pro­gram is not normally resident, a fresh copy will be brought in before it is used again.

If a program that exceeds the processing time is run­ning in the test mode, it will not be used again, but a backup version will be used instead. If two successive errors occur, the program will be marked unavailable and the type of transaction that precipitated the error will be rejected until manual action is taken to reinstate them.

-Accumulation of Statistics

During the operation of the on-line system, COP is gathering statistics about the various programs. These statistics are recorded in ·the appropriate program control block and a report produced at the end of the day (Figure 8). COP is also recording each TRP so that they may be analyzed after the day's run. .

Resources Management Subsystem 447

Batch Executive Sub-System (BESS)

• Improved Throughput

Some operational batch jobs that ran under 360-'OS-MVT(Multi-programming with Variable num­ber of T-a.sks) were compared to multi-tasking under BESS and l\IVT. They showed a 60 percent savings of time under BESS.

This can be attributed to:

.Subtasking By running two or more of the jobs concur­rently as subtasks to BESS within an MVT reglon, it then makes it possible to take the greatest advantage of the computer's resources.

"Reduction of Job Control Information

All the jobs are run as subtasks t~ BESS and not as individual jobs. This eliminates. the need for a great deal of the job control language cards for each program. The control informa­tion required by BESS is minima:! and takes less time and space to read, interpret, and use (Figure 6). Only one control record per program is required.

e Sharing of Record Accesses

Each time a record is read from a direct access or sequential storage device, it can be shared by two or more programs that are run as con­current subtasks to BESS. There are restric­tions such as only one program may update the file and all must look at the records in the same order or fashion. This savings of record access times is appreciable for large files ina corporate data bank.

• Job Scheduling

The programs to be run are dependent upon the data that was collected during the on-line day. BESS will determine which programs are to be run and in what order.

• Conditional Rims

Part of the control information supplied BESS is the input file (or files) which must contain data if the program is to be executed. If data is present, BESS will schedule the program for execution. If the data is not present, BESS will not schedule the program.

Another part of the control information is a

From the collection of the Computer History Museum (www.computerhistory.org)

448 Fall Joint Computer C~nference, 1969

----------------------------------------------------------P~('FIC G~S ~NC [lfCT~TC C~MPANY

PROGRA~ lI~f~ ~f. V~PSl(~ C~11Tr~L Tf~~S ~ULrlPLF TYPF AV~JL'~lE AMT JOB NA~o1ES US[C .. Hr!\;[)S I[HH 1.'~q~)FII,(V REFKf:C;I-1t-r. HH.r'~~cTIr~<; rCf'fp."r E~r rAV C~RE ll~RARV

(GU P 1,)·1 1 ccce:,' ( c ''In C I\jrl 'H-L~C.~~l[ VF $ 011) 16 .3 cef lr::CC! c(r(( c;r r'l 721-,;9 "C (\ ~l p[usrA~U' Vf ~ C?Q'C4 ~ C(F2('\('101 II,C C[F1COCI ';:1'.1 (.'"""'\,) C'~~ ( , 112f.:g NC 0 NO RFUSEAPU" 'fE ~ crF/.CI('Ol ~C ((H('OOI N~ CGf'.;2C(,Cl r-.jn

«(1\:?0C')1 f\C ((1\41)0')1 11,0 C('PFRP C( C Cl ece C'lt:'f:S N[ 0 I\C P fl:I\JT P AflJT YES ~H 144 0 rs T M'()(; 1 ~r·1 ('? rrr

'. \., I\J(J C "Ie KfL.SI:/lPL[ vES 054~6 3 C0u1001~ rf'C(C rcc Nfl C NC P·H.SF"PU YES 06'.32 3 F/lSt<p.-rr.2 I,:,cr(f- rcr Nfl C "C (H L.~[ YES 04776 3 VI ~r; r I\l" CCCCl C C ,:' NO. C 1\[ ~[LSrr.:'tf VF.S 0'3~20 ~ TJ=aCLS :10(~C L r:CC C ~ 1 e~ '1 NO C "( (1\(- LSf YES 014·80 1 TP;;TSI= C;~i C (: (' CfC C~Ct::l:9 NO C "C RfLSf(lPLE vES 013,76 1 T I=c'GST "C T P:li 0 ~ S C't'0C ~ C f' ( r~] 1::169 f\C ~ NO PFCS("RLF VFS CO~IFlA 1 T F:;frv (: (' : ',~ ( ref c'?ru·c" NO C !\C r"E L~r VfS 006Q6 1 TFO'f.:Ri< Cr Cr::J ecc NO C 1\( RFFt-.'TRAt-.T VES OO~~2'. '3 TFii'F~T ~C Tp:iJllf\ nrJ(lL 4'('(; C"31769 f\G 0 Nn ~[lJC;Eh'3LF VI: S O~~~ 12 1 T r;; LCG ':':;·:-::C ere NO c "c IHl!5FArHF YES 01904 1 TFiitJCC rCGCC .... , ......... r:;C6fG NO c f\( 1~ F L C; f ~ PI ( YES 01 ~n6 1 Tfa:Cf( !\C lP;:"SG~ ecru' c;r' I\JO 0 Nfl RFFr-.:T~ANT '1E S ccooe '3 T ?<£TRM ((':'(7- r(c (317(:<; 1\( 0 t-.c ~PJSft\eLf v FS 02944 1 T p.: 1-1J c: ." .... ,-. 2 ~ CO: ~2::~'tG 'l'F S C vfS PFF"TR~"T YES I')rp17 1 TPtJS(CUT ncr: It. CCC C~ tel'S 'VF.S c VfS RE["T~h"T VES 03128 0 THsr crrcc eee NO c ~C RFLSf:tFHE YES "lOtJ2A 3 1 FWT Ii C:~ (' (' 7 CCC C :: 1f~:f c; Nn C 1\( I-!frt-.1PAt-.T YES 005Q;,? 1-I

Figure 8-COP status report

set of inhibit codes for the program. Each pro­gram that does not run correctly to completion will cause a condition code to be set and if the particular combinations ~f inhibit codes for a program are satisfied, it! will not be run. This saves the time of loadiIig and attempting to execute a program that should not be executed.

• Maximun Use of Resources !

Each program's control' information contains a level code which show~ two things. The first is the order of executiop.. A program with a level code of three cannqt be run until all pro­grams with level codes j less than three have been run or rescheduled; The second function of the level code is to designate groups of pro-

grams which may be run concurrently without conflict. With this information, BESS can execute as many subtasks as the computer's resources permit.

• Other Features

This approach to controlling batch runs has two other major assets.

• Better Error Control

If a· program abnormally terminates, BBSS will regain control and can invoke e:rror pro­cedures to salvage as much as possible from the run. By doing so, all other parallel jobS! can (:on­tinue running without interruption and most of

From the collection of the Computer History Museum (www.computerhistory.org)

the work can still be done while a fix is being im­plemented to correct the error.

• Piggy Back Programs

There are a variety of programs that are run only once or very rarely. These programs do not update the files but only look at the tecords to perform some analysis. These programs can ride piggy back on some other run in the system under BESS. The added time is negligible compared to the cost of passing the voluminous files used in a large corporate information system.

.Reduction of Testing Time for .Application Subsystem

An application subsystem within a corporate information system often contains a goodly number of interrelated program modules.

During the system integration testing, if only one of the modules fails, it will cause the whole job to fail. Therefore, to test all the modules in a combined environment can be very time­consuming.

However, under BESS each module can be classified as a subtask. If a subtask fails, the entire job will not terminate and BESS can proceed to test the remaining modules. Figure 7 shows a report by BESS to facilitate the analysis of the testing.

System Implementation

The Resources Management Programs have been written in IBM-360 Operating System Assembly Language (ALC).

1. It is fully interfaced with the IBl\1-360 operating system MVT.

• The applications programs and the systems programs operate as independent subtasks of the regional resource manager; abnormal termination of a subtask will not stop the rf'maining subtasks in the region.

• The package is not tied to any particular release of O/S; hence, if a new version is released, there should be little effect on this package.

2. The Resources Management packages take full advantage of existing operating system facilities and make extensive use of the sub­tasking and master scheduler facilities.

Resources Management Subsy&tem 449

3. It is intended to interface with all the operating system supported languages (COBOL and ALC interface have been implemented) .

4. The entire package . has been designed to be dynamic in nature; that is,all pl'ograms are load modules. They are not linkage edited into the applications program; thus, the pack­age. may be redesigned and improved without any appreciable effect on the applications pro­grams.

5. The entire package has been programmed in re-entrant code.

6. The hardware anticipated over the next several years includes 'two large central processors with a million bytes of main memory, supported by smaller satellite computers and a score of multi-drive disk storage units. The system is being designed to support several hundred terminals, most of which are expected to be high speed CRT display units.

APPENDIX I

.On·Line System Control Block8

The on-line system makes use of the control blocks established during initialization time. These blocks are:

• Program Control Block (Figure 9)

This control block contains the program identi­fication, the storage address within the library, operating system controls, on-line control data, and counters to record the number of times the program was used. It permits the on-line system to bring a needed program in from the library

· in an efficient manner. This block is also used by COP to collect statistics about the program and determine its current status.

• The Master Control Block for the TRP (Figure 10)

This block contains pointers to various other control blocks as well as containing the two evenf control blocks which apply to the subtasks as­sociated with the TRP. One pointer shows the location of the TRP, one points to the task con­trol block ·located in the operating system's region, and another to the event control block that will be marked to tell COP when a program has completed processing in this TRP . The next one can either be a pointer to the processing pro­gram or its identifier depending upon conditions at the time. Two event control blocks are next

From the collection of the Computer History Museum (www.computerhistory.org)

450 Fall Joint Computer Co~erence, 1969

----------------------~--------------~-------------------------------------

/ BL-OCI< n i \

I 1 / BLOCK ;I \ I I

/ BL.OCK 1 \ Program Identlfic8tion

Peripheral .stOltJge JrirlreJtJ of Prof/r8m COnfrol,r {/.rcd D# ffJe Opelafing cJ'q~m On -Li fie Control lA1ItJ:

!

RefteslJer Cov~r ABENP cOII~r: Nof Ar8l/a{)lo Inri: Orihtol Resiticllcli Ina A/ulti-7i"t9nsa&fiol/ Inri. CofO RCSldcfll In~

AI/oClifed Proccsslnq:7Tme Program {/Jaqe Coupfef

1 7l7erIJ if one b/~vk for each proqm}p iIW mal{ b9 rtlll ill the on-line Jf/Jftm. :

2. ToeJ'8 /;locK'! am b(//If ~od](jtJlf J( liJIl!a/!zat/()l1l1mo. 8. llJel/ mal{ be btlilt r/llrillq tile ()/l-llhe rial{ qlj o/XJrdlor

tilrtchon or In /I1e eJefl1 of JI/SlCIf/ I7JQlfi/l1ct/O/J.

Figure 9--Program control blocks used by the controller of on-line proc,essing (COP)

and they are the ones u~ed by TPCHUG and SLINK, respectively. The next pointer is to TPCHUG's task control block and the last to a list of addresses which in turn point to the param­eters and records to be u~ed or updated by the message processing progra$.

"The Transaction/Response Pools (Figure 11)

These pools of data and controls are the heart of the on-line system. Their number determines how many messages can be processed concurrently. The first part of the TR~ contains control infor· mation to help FINDREd in locating the various records and spaces within' the pool. These con­trols also help COP to loc,ate programs and other control blocks that are required. Because COP is re-entrant, it cannot store information in an area reserved for itself, sq all controls for a given message must be maintained in the TRP apart from all others; therefore, no "cross talk" will

I BLOCt< n \

I I / BL.OCf< 2 I

BL...OCK·l

PolllIQr /0 the TR P IOCQt/on POinter It) II/e l?isk C()IJtr()1 Block o!proceJ.JirA;'

Pointer 10 tl7e Ellent Control Block (or COP l POinter (}f Ide/7f ofiIJepr()CtjJJJilq pfog;

Pollller trJ table of /JQIa COMol Blook-f 7he Bent control Block wll/ell TPCHIJ(J 1Y9i/J'

llJe Event Conlrol BI()ci forltJe pro~/ilg pro~~ POINer to lPCHl/u.f TCB fOr 4SJ'OCIiltet/ JI/#tq.f/

Poinw toao'tl/~ lift ()f J'vlJ/QSK fJIlmmelelJ In

1. llJerc if' me co/lllrJl IJI()C;K Iord9c/J TRPll7l1le 01lstem. 2. lhese blocks ar81J1J/1! at /iJit/a/izfJltb/l tIme atb/lq ;.v/Ih

tlJe TR P;Y find ore vpriaterJ 8J IJfJ%Ieti r/f/fln, 1m ()Il-llil~ rlall'

Figure 10-Master control blocks for transaction/response pools (TRP's)

occur between concurrently processing' subta,~ks.

The latter part of the TRP is used for the mes­sage, its response(s) and overflow control if more room should be needed. Currently, 41096 bytes of memory for a TRP have been adequate to handle 98 percent of the messages proc:essed" Ex­pansion is provided by going to an overflow area if more room is needed. Figure 12 shows the rela­tionship between the control blocks and TRPs.

GLOSSARY

BESS

Batch Executive Sub-System

BUMP

Branch to UtilitY'Modules and Programs This is a small module appended to each high-level language program to :

From the collection of the Computer History Museum (www.computerhistory.org)

Fbinl8rfo neff o~n /WA(d p(infer

'" Pool contro~; Number ofrecorOJ'in '/hiJ 7RP ftJin/er -10 next. 'record to Proc8SJ' poi!Jler . Numb of output ffJC(J((k fIvm /affprog ""!'''' !/vmlJero/rwrrif pr;r;8SSed.

POinters: 70 FIN/JREC Progmfll n:m list of {YOgr3II111i1ff109 -~ [!o reo/rtl! will/Ii! !I1lj TRP

Proc&J'ing~program NamB List

PointerJ to SUbf8ik /{I/d/fJeIe!ir

J'Ive lted forTPCHV6; mooVf, alll/ PI/W!Yf)CCSlin, fJl{KjmlTlS

I sf Rea;rrI- Trlnsaction I/Ilformalled 2nti Rwrri-T/;JntoctltYl fOrm8l!Bti ani Recortl-RBJP()/IJt #/

OJler#oPl Co/ltrol I. foci! /t;;nSqC/ion Ihd tJI/Ns1IIe JlItIi»J Ii JS{lill(J(/ hJ 8 TRP. Z. A TRP if tI6rIlC8IfKi too Ir8flfaclion,iiJ' reJfJ(Y1SM ami ~/i'AJ

,ffI/JIa.rks dV1'11JII1M life Of 1M InJIistICtlPIJ willi//) 1ht1.fVtf/8111. a. 4~ t1 mp if h!tt, #Ii tllSlJ/N81Y hie 1Ie.rtlt8lJJdCftiJIJ.

Figure ll-Transaction/response pool (TRP)

I sf f'ntt:8Jfill, Ptl9rtllll NQ/ffl ylfllimlJfilll PrIp4111 Niml

t> lsi' !vlll8sK n;ftJ/I1BI8r t> 2ntI.rv~fK I19rA~

II

Figure 12-Control block relationship in the on-line system

.,J

• find the various system support modules within a dynamic environment .

• establish the linkage between the program and the system support module.

COP

Controller of On-Line Processing

Resour~s Management Subsystem 451

DCM

Data Control Manager A subsystem which controls the data base for the Management Information System.

DCMGET

An on-line DCM subroutine which retrieves selected information from the data base for applications programs. It makes the applications programs in­dependent af. the data base structure.

DCMPUT

An on-line DCM subroutine which selectively up­dates the data base for applications programs.

ECB

Event Control Block A small block of memory that contains indicators to show if a program is waiting for an event to oc­cur, if the event has occurred and the completion code associated with the event, when posted.

FINDREC

A resources management on-line subroutine that does dynamic space allocation and locates data within the transaction/response pools.

Multi-tasking

The interleaved or time-shared execution of two or more program tasks within a single CPU; multi­programming.

On-Line.

Pertaining to the responsiveness of a computer system. To respond in a timely fashion to user's needs who have direct access to the computer via data entry devices, terminals and displays; real-time.

SLINK

Subtask Linkage An on-line resources management program that is a constant subtask to COP and links to each process­ing program.

Sub8Y8tem

A system of interrelated programs that is subordinate in control and execution to another system.

Subtask

An executable program that has all the attributes of a task but is subordinate to and under the control of another task.

From the collection of the Computer History Museum (www.computerhistory.org)

452 Fall Joint Computer Conference, 1969

--------------------------~----------------------------------------------------------------Task

One of 'two or more programs, or series of programs which execute concurrently in a single CPU.

TPCHUG

A teleprocessing program that is a constant sub­task to COP. It reads transactions from the input waiting queue, edits them, and. translates them into their processing format.

TPMSC:OUT

A teleprocessing subroutine that converts a response to a terminal's format and pla~es it into the output waiting queue.

TRP

Transaction Response Pool A block of memory which contains a single raw trans­action (message), some of its' control information, its intermediate forms and its' response(s). A TRP is assigned to one transaction ~t a time for its active life within the CPU. It contains all data associated with the transaction in chronologicu,l sequence so it is useful for debugging.

ACKNOWLEDGMENT

The authors wish to thank Mr. J. R. Kleespies for his encouragement and support; Mr. W. D. Ayers and Mr. R. T. St. Germain for their dedicated efforts in design and programming; Miss Agnes Wolf and Mrs. L. J. Fiore for their meticulous typing; lVlr. Leo Karl of IBM for initial analysis and Messrs. F. J. Thomason and J. W. Nixon of Haskins & Sells for their invaluable advice.

REFERENCES

1 S ROSEN Electronic computers: A historical 4urvey

ACM Computing Surveys VoliN 0 1 March 1969 2 R F ROSIN

Supervisory and monitor systems ACM Computing Surveys VoliN 0 1 March 1969

3 J DIEBOLD Thinking ahead: Bad decision on computer use Harvard Business Review Jan-Feb 1969

4 H LIU A file management system jor a large corporate injormatWn system data bank Proc FJCC Vol 33 1968

The following references are selected by the authors for geners,l background information, but are not mentioned in the 1Gext.

5 J MARTIN Programming real-time computer systems Prentice-Hall 1965

6 J MARTIN Design oj real-time computer systems Prentice-Hali 1967

7 M G JINGBERG Notes on testing real-time systems programs IBM Systems Journal Vol 4 No 1 1965

8 J D ARON Real-time systems in perspective IBM Systems Journal Vol 6 No 1 1967

9 J W HAVENDER Avoiding deadlock in mu,ltitasking systems l~M Systems Journal Vol 7 No 2 1968

10 B I WITT Job and task management IBM Systems Journal Vol 5 No 1 1966

11 D D KEEFE Hierarchical control programs jor systems evaluation IBM Systems Journal Vol 7 No 2 1968

12 W C McGEE On dynamic program relocation IBM Systems Journal Vol 4 1965

13 IBM system/a60 operating system MVT Control Program Logic Summa-ry Form Y28-6658

14 IBM system/a60 operating system MVT Supervisor Form Y28-6659

15 IBM system/a60 operating system MVT Job Management Form Y28-6660

16 IBM system/a60 operating system Supervisor and Data /Management Services Form C28-0046

From the collection of the Computer History Museum (www.computerhistory.org)