COST REDUCTION OF STUDENT PROGRAMMING EXERCISES

by

Paul Gervase Gregory III

Submitted in Partial Fulfillment

of the Requirements for the

Degree of Bachelor of Science

at the

Massachusetts Institute of Technology

Signature of Author................... . ............Department of Electrical Engineering, June, 1975

Certified by..... .

Accepted by..........

arvi sor

ULnairnri, Lveper Lfwental Committee on Theses

1...%0% 1 0 7 r,

-2-

CONTENTS

Acanowledgments

Abstract

Introauction

Oefinition of Costs

Oefinition of Student Running Process

Possioliity of Cost ieduction

3atch Monitor Concept

Evalu3tion of Batch lonitor Approach

Loop Prevention

A Cheaper PL/1 (F) Compiler

Evaluation of Cheaper PL/1I (F)

Appendix

Comp I Ier

A: Jser's Guide for Batch Monitor

pser's Guide for Cheaper Compiler 52Appendix 8:

-3-

LiST OF TABLES AND FIGURES

Fixes Overheao for B3tch lonitor 3t MIT

Spooling Overheaa for Batch Monitor at MIT

PL/i Governing ProceJure Source

Performance Jata for Cheaper Compiler

JCL for Running the Monitor with PL/1

40

-4-

ACKNOWLEDGMENTS

The author wishes to express his gratitude to the many

individuals who made this work both possible and complete by

their assistance and encouragement. In particular, Dick

Caloggero of the Electrical Engineering department and Dick

Steinberg of the Information Processing Center for providing the

necessary development funds; George Newton of the Electrical

Engineering department for providing me with the unique

opportunity to actively partcipate in the teaching process; John

Donovan and Suzan Kruger for letting me use their students as

guinea pigs; the numerous students of 6.251 and 6.083 who were

the guinea pigs; Rick Granger for his performance measurements

of my PL/1 (F) compiler modifications; Stu Madnick for providing

the necessary constant pressure; and Jack Aiello for

support that enabled me to finish.

the moral

-5-

A3STRACT

COSI REDUCTION OF STUDENT

by

PROGRAMMING EXERCISES

Paul Gervase Gregory III

supervised by

Stuart E. Madnick

Assistant Professor of Management Science

This thesis explores the process by which student

programming exercises are processeo in a batch enviroment on IBM

360 or 370 computer systems. Presented are three programs which

may be used to effect a significant reduction in the costs

associated with this running process.

These programs are written in such a fashion as to be

generaliy applicable to a wide variety of student exercises. They

have been thouroughly tested by two years of use in an actual

teachino enviroment.

Use of

Engineering

per stuuent,

these programs by a course in

deoartment resulted in a savings of

for a total savings of $3,000 in one

the Electrical

fifteen dollars

academic year.

-6-

INTRODUCTION

The thorough understanding of a contemoorary programming

languaqe ana proficiency in its use is an Invaluable tool for a

student of comouter science. To this end time Is usually devoted

towards teaching the use of one or more languages in computer

science Programs of stuuy. The mastery of a programming language

is similar to that of a sport like tennis. Although some people

have natural ability and agility, almost no one learns to play

merely by reading a ooak.

A person's style and form benifits

is no substitute for time on the court.

exists between in class presentation of

tne out of class development of basi

normal approach to proficiency building

of progressively harder programming ex

must coce ana test. The object of these

not to teach the details of

implementation or a nachine's structure,

appreciation for the use of the language

from coaching, but there

As in tennis a a balance

style and technique and

c programming skills. The

involves the assignment

ercises which the student

exercises is generally

a particular language's

but rather to instill an

to solve problems.

Programming exercises necessarily require the use of an

actual computer by the students. Associated with this use is a

cost which is nonconseauential and must therefore be considered

in course planning. Tnis thesis deals witn the cost of machine

exercises for computer courses, first identifying the costs and

then outlining steas which may be taken to reduce them without

-7-

sacrificing educational quality. This thesis is a direct

outgrowth of the author's participation in the process of

teaching programming in the Electrical Engineering department at

M IT.

Presented are three programs designed to expedite the

efficient testing of 3 large number of student programs in a

non-interactive batch enviroment on an IBM 360 or 370. Use of

these programs by the Electrical Engineering course for which

they were designei resulted in a $15 reduction of the per student

computer costs, producing a savings of $3,000 for the academic

year (aiscounting oevelopment costs). The total development

costs were 11,500 borne oy the Electrical Engineering department

and 12,000 borne oy the Information Processing Center. These

programs are cur-ently used by the department of Management

Science at MIT.

DEFINITION OF COSTS

Processinq student computer assignments obviously requires

certain resources with associated opportunity costs. Even if a

course aoes not directly pay for its computer usage, surely

someone pays. The costs incured may be broken down into three

crude classes for purposes of discussiont

1. Student Preparation Costs- those costs directly

associatea aith converting a student's program and data

into a computer ediole format, excluding any connected

-8-

computer costs. Tnis may include key punches, card

stock, remote job entry stations and similar eouloment,

&S well as supervision anc maintenance of tnese

facilities.

2. Computinj Costs- those costs directly associated with

tne actual compiting involved. This includes reading in

the orogram, running the program, and finally outputing

the results. Lumped into this category is machine

rental and maintenance, operator salaries, energy costs

(electricity and air conoitioning), space costs such as

janatorial services, and basic systems support.

3. Course Development and Support Costs- those costs made

necessary Oy using a computer in a course, that are

external to tne actual computing costs. These include

orepirlng assignments, grading the assignments, helping

students with assignments, and overseeing the smooth

operation of the student running process.

This thesis ooes not deal with the costs of class one,

taking tinem to be irherent in the process. Similarly, the costs

of class three are barely mentioned, the only gains being from

increased efficency of the student running process reducing staff

reauirements. In order to effectively discuss the second class

of costs, I have assumed that the course in question does not own

the computer involvei, rather is a user of a centralized computer

facil ity.

-q -

For purposes of usag? monitoring and billing, a person's use

of a computer facility is usually divided into the following six

categories,

1. CPU usage- a direct measure of time soent by the

computer actually executing machine instructions for

the user. This is expressed in time units (seconds) and

incluces ooerating system execution overhead.

2. Input and Output (I/0) usage- a direct measure of the

number of 1/0 r3quests issued by a user's program. This

category usually includes only disk or taoe I/O

requests.

3. Main Storage Usage- an imputed quantity proportional to

the opportunity cost of aedicating a fraction of the

machine's raal memory to a user. That is, one user

executing "prevants" otner users. This is calculated by

acaing a fixed time auantity for eacn I/0 request to

the basic CPU time from (1). Then this quantity is

multipliea oy te size of real memory used. This is

often scaled by an exponentially increasing function of

memory size. This oenalizes I/0 bound programs which

use very little CPU time, but tie up memory for a long

time; and large programs which tie uo much memory.

4. Unit Record Equipment Usage- a direct measure of the

number of cards real and Iinas printed by a program.

-1q-

5. Secondary Storage Usage- a direct measure of the

seconoary (disk) storage used by a orogrammer. This

storage is used to hold canned orograms and data

accesseo ny students in execution. This is expressed in

units of (soace used * time).

6. Fixeo Job Fees- fixed charges levied against a job, and

its job steps. These fees allegedly cover operator

handling of tne aeck, the system overhead of

interpreting a job's JCL statements, and other overhead

items. Tnis cnarge is computed by multiplying the

number of joo steps oy a rate and then adding a flat

)ob charge.

This complex system of separate usage charges is designed to

accurately charge a user for his or her total computer usage. By

covering many categories, special cases such as I/0 bound, CPU

bound, large versus small, etc. are all fairly billed. A direct

consequence of this scheme is that if one or more usage

categories can be reduced, while holding others fixed, certainly

the total computing resources used and subsequent billing will be

less.

DEFINITION OF STUDENT RUNNING PROCESS

A typical programming exercise consists of the functional

description of a orogram which t'he student is to write. The

student prepares an input deck containing his or her program.

-11-

This orogram is then tested and the results examined to determine

a grade.

Partially to protec

Oartially to protect the s

preparea program (deck)

system oy a course employei

Lanjua)e and sucn things.

or she orepares a program,

back later for the results

the dark aoout the detai

It does free the course to

system indeoendent asnects

This

must

Once a student's program i

testing process involves the

be performed for eacn program:

1. Inout the stud

the ceck which

t the student from the system and

ystem from the student, a student's

is generally entered into the computer

e, who has Knowledge of Job Control

As far as the student is concerned, he

leaves the deck somewhere, and comes

While keeping the student somewhat In

Is of actual job submission procedures,

aadress itself to only the pure,

of programming.

s prepared, it must be tested.

following four steps, which

ent's program. This entails reading in

the student has prepared.

2. Translate the student's program Into machine Ianguage

(via a compiler or assembler).

3. If no errors were detectea during translation, bind the

program with any external subroutines it may require

ani initiate its execution.

4. Print the outout from translation and ( If a ny )

-12-

execution.

In IBM terminology, a job sigD is, "...that unit of work

associated with one processing program.* (1) The language

translators written oy I3M a3ccept as inout a source program and

output machine lanjuage when they are invoked. No further

processing is oertormed. The loader accepts this machine

language, loads it into memory, and executes it.

Since each job step may specify only one major program to be

executea, two job staps are required to test a student's program.

One to translate tha program and another to execute it. Thus, if

the straightforward and obvious method were used for testing _

students, 2n loo steps would be required.

POSSIBILITY OF COST REOUCTION

The charge associated witn reading a student's deck and

orinting his or her outout falls into category four, unit record

equioment usage. The amount of output a program produces would

seem to be an inherent 4uantity, just like the size of the

orogram aeck. For this reason, the costs associated with steps

one and four of tne ;tudent running process are not amenable to

reduction. Certainly, if a Particular translator could be made

more efficent, the costs of step two could be reduced, this will

(1)"I bM System/360 Operating System, Concepts and Facilities",publication number GCt28-6535, IBM, 1969.

-13-

oe discussed in detail later. There Is a simple efficiency

improvement with 3ttenaant cost reduction which may be realized

from examining the microstructure of steps two and three.

That component of the IBM operating system which reads

Control Language (JCL) statements and starts each job step

called an initiator. Initiators perform the followinq

functions for each Jab step:

Job

is

ten

1. Initialize the user's memory space.

2. Interpret all

system control

3. Decide

results

cond it i

JCL statements and build appropriate

olocks.

if the current step should be executed, based on

from the previous job step's execution (the

on cole facility).

4. Allocate any I/0

requirea by the job

devices and

step.

temporary datasets

5. Determine

execute

error if

6. Load the

error if

the oarticular program

and locate it in the file

it cannot be found.

a user

system.

wishes

Indicate

desired program into memory, indicating an

the available memory space is insufficient.

7. 3egin execution of the desired program.

-14-

8. Interpret any system error conditions encountered by

the program.

9. When the program ha

terminatea, release

datasets or I/O devi

s either normally or abnormally

any temporary resources such as

ces assigned to the step.

10. Release all system control blocks allocated for the

Ioo steo.

This processing is necessarily complex, since a job step may

fy the execution of virtually any type of program, with a

spectrum of possible requirements. It should be noted that

neeas of the student running process are much simpler than

tre general case. There are only two orograms we are concerned

with- the transiator

well defineiz resource

scratch flIes, memory

through five, nine, and

entire student runnin

locate the two programs

be possible to design a

would repeatedly perf

for the students. Due

and the loader. These programs have very

rquirements in terms of I/0 devices,

, etc. Clearly, initiator functions one

ten need only be performed once for the

g process. Similarly, we only need to

in the file system once. Thus, it should

orogram, which invoked by Ql. Job steo,

orm initiator functions six through eight

to the strictly defined nature of the

programs

ooss ile

performin

to be

to make

g these

executed (

this special

steps than t

translator and loader) It should

purpose program more efficient

he initiator.

;pec

oroa

the

-15-

BATCH MONITOR CONCEPT

The program mentioneo above Is called a batch monitor. The

basic idea is to eliminate repetitious overhead normally incurred

by each student, by incurring it ,)-. for all students run in a

baitch. The monitor adds its own overhead to to the execution of

each student, 3S discuissea below, but lob step initiation

overhead is only Incurred once. Assuming the overhead added Dy

the monitor is lower than step initiation overhead, this approach

lowers the marginal cost of running a student program.

The fact that the monitor incurrs Q= tim.1 initialization

overheao, which is not initiator related, may mean that the

average cost of a student program will not be lower than the

no-monitor cost until several student Jobs are run together and

the lower marginal cost brings down the average cost. This "break

even" point and its determination will be discussed later.

The oatch monitor is executed by one lob step, which

contains all the file aefinitions (JCL) for the translator and

loader. For input, tne monitor takes a stream or "batch" of

stucent program aecks, separated bv special delimiter cards.

After its execution is initiated, the monitor performs the

following processing:

1. Interpretation of oarameters entered from the JCL.

These parameters control the optional features of the

monitor, such as lojging of students and their resul ts,

-16-

ano convey

trans I ator

req ui

a no I

red information like the names of the

oader programs.

2. Location of the

file system. Thi

3. Spooling of a st

empty, proceed

monitor inout ti

terminator is

this point the

student program.

4. Invocation of th

is invoked, p3

scratch file. Oa

another scratch

translator

s involves

udent's de

to step ei

le to a d

reached, o

scr a3tch

e translat

ssing it

tput from

file.

and loader programs in the

use of the RLOL macro.

ck. If the input

ght, else copy cards

isk scratch fIlIe,

r there are no more

file contains one

file

from

until

cards.

compI

is

the

a

At

ete

or. The specified translator

the program collected in the

the translator is saved in

5. Return code checking. Examine the translator

cooe to see if errors were encountered. if so,

step three to process the next student.

6. Student execution. Tne program specifi

Is invoked to bind the student's

needed external subroutines, 1o3d it

execute it.

ed as the loader

program with any

into core, and

7. Loader termination

terminates, tne

handling. When

student's program

the

has

loader

f inishea

return

repeat

-17-

executing. Note tnat this may

termination. 4hen the current

step three is raoested to process

8. Monitor termination hand

been orocessed, the

execution. This re-leases

monitor's job step.

be

studen

the nex

ling. When all

monitor must

any resources al

an abnormal

t is finished,

t student.

students have

terminate its

located to the

In adaition to this bare minimum processing, the monitor may

oerform several amenities which expedite the student running

process. These include: keening a log of student names, along

with their translator and loader return codes; printing paging

separators identifying student output; and rewarding of students.

A very flexible general purpose batch monitor has been

implemented and is describea fully in Appendix A.

EVALUATION OF BATCH MONITOR APPROACH

When the batch onitor is used, it incurrs a certain cost in

initializing itself to accept student Input. This cost is a

function of monitor ootions anu includes any job step charge.

After the cost of this initialization is paid, each student saves

the two job step charges, plus the overhead of steps one through

five, nine, and ten of job step initiation. However, each student

is penalizeo with an overhead cost, previously nonexistent. This

is the cost of sooolin; the student's deck onto an intermediate

scratch file before translation.

Without the monitor, each student's deck is read only once.

With the monitor, eacn student's deck is read once and written

once to get it on the scratch file, and then it is read again.

This introduces an overnead factor proportional to the size of a

student's Oeck. For suitably large decks this overhead factor

outweighs the two step charges and initiation overhead savings.

This gives rise to a "break even" student deck size, above

which the monitor is not cheaper. It may still be worthwhile to

operate in this region if some monitor features are being used to

expedite operational efficiency of the running process. A

.uantitative determination of this breaKeven point is necessarily

tied to the type of machine and billing structure being used.

The fixed ano deck-size dependent factors of batch monitor

overhead may be quantitatively aetermined by a relatively simple

experiment. However, this simple exoeriment makes one assumption

which may be unreasonable. This assumption and its affects will

be discussea oelow. The experiment involves setting the

transl ator and loader names to IEFBRI4, a system provided utility

which merely returns once it is invoked. To determine the fixed

overhead, the monitor is executed with all appropriate options

and an empty input stream. The monitor must undergo all fixed

overheao items, including job step initiation, monitor

initialization, monitor termination, and Job step termination.

After the

overheao may

fixed overhead has been determined,

be found by repeating the experiment

the

with

spool ing

one deck

-18-

-19-

of one hundred cards in tne monitor inout stream. Subtracting the

cost of the previous exoeriment yields a high estimate of the

spooling cost per hundred caris, assuming linearity of this cost.

The reason this is a nigh estimate is that it Includes the cost

of invoking tne translator and loader (IEFBR14), which is only

performed once for each stuoent.

This experiment assumes that the user Is charged the same

rate for reaaing the cards, whether they are in card form or In a

disk file. Note that IEF3R14 did not read any cards, but we

Assumeo that the 'werhead was writing the cards on disk, after

reading tnem. It is possible that the cost incured in reading the

caras from the clsk wll be higher than the cost of reading the

cards from the card reader, so to speak. If this is the case, the

spooling overhead figures obtained will be lower than the actual

cost.

If the assumptions are all valid, thougn, the experiment may

be perfomed at any installation using Its accounting procedures

and rates to determine the break even point, or estimate the

gains derivable from use of the batch monitor.

These exoeriments were performed on the MIT Information

Processing Center's Model 168 running OS/MVT. Tables one and two

sumari7e the results obtained using MIT's pricing structure

($12.00 per CPU minute, $1.20 per thousand 1/0 operations, $.1o

per job steo, and exponential memory costs). CPU times are in

secondst

w/o Log 3nd SeparatorsCPU .06 s0.01I/0 59 3.07MEMORY 16K i--Q4subtotal 31.11step charge 1).i.1total 30 .21

Table 1: Fiyed Overhead

w/o Log anc SeparatorsDer hundred cards

CPU .G6 $0.01I/O 6 $0.01MEMORY - iflAitotal i0.03

Table 2: Spooling Overhead

1 w Log and SeparatorsI .12 t0.02

31 $0.07I 24K jl1aa

$0.12SQLZQ

$0.22

for Batch Monitor at MIT

I w Log and SeparatorsI per hundred cards1 .08 $0.02

$0.03

for Batch Monitor at MIT

Using these figures, a simple example can be worked. Suppose

you are given six cecks which average 300 cards, the spooling

overheao shoula be $.9/deck. The fixed overhead, assuming log

and separators, Is 22/6 = $.04/deck. Thus the total monitor

overheau is 4.13/deck. Since the step charges are $.10, you would

expect a savings of 3.07/deck.

If this stream of

this .ain woula not be re

made concerning equality

MIT uses LASP, a system I

a (from a cara read

reasons for this unfair

inefficiency of AS3. A

directed through LASP to

charged for disk I/0,

student decks where actually run at MIT,

alized. The reason is the assumotion

of card reading and disk reading rates.

n which the CPU overhead for reading

er) is not billed fairly. The historical

price structure are rootea in the

flate rate is charged for I/0 operations

the card reader. A similar flat rate is

but the disk I/O rate Is higher, In

addition to the fact th3t you are billed for your CPU overhead in

disk I/0.

LOOP PREVENTION

IBM operating systems enforce execution limits at the job

step level. That is, a programmer may specify limits on execution

time and printed outpat for a job step. When one of these limits

Is exceeded, the job step is terminated in such a fashion that

the terminatec program is not aware. When the batch monitor is

used, many students are to be run under one job step. If

normally, eacn stuient would be allowed Isay) ten seconds of CPU

time, then the catch monitor's job step must be given a time

limit eaual to ten times the number of students.

Now suppose tne first stident, out of a batch of twenty,

codes a program wnicn loops indefinitely. This student is going

to use the job step's time limit before the operating system

terminates the monitor. In addition to being a costly

proposition, this sort of thing tends to happen over and over

again. Since the operating system terminates a step which exceeds

Its time limit in an invisible fashion, there is no way to tell

the student where ne or she was within the orogram, or the values

of any variables. Since the program ostensibly looked correct in

the first place, the student will probably not be certain of the

error.

So the student tends to submit the Program over and over

until the looo goes away. Without the monitor, the student's step

time limit is set to a level which mikes this cost tolerable,

although a definite nuissance. With the monitor, this cost is

insufferable. Th. simplistic approach would seem to involve the

monitor actinj ite tne initiator in monitoring the CPU usage of

the loader when it is invoked for a student. The IBM operating

system makes this aporoach vgry complex, and not fool-proof. Also

this approach will probOly not help the student, much.

The correct aoproach is to execute the student's program

concurrently with a loop preventing governor. This governor would

trap any ootential loops and perform the correct diagnostic

action. This wou ld be a simple program dump with PSW and

registers, for assemoly language oroblems. For problems using a

higher-level lanvuge such as PL/1, this processing is more

complicatea.

A set of subroutines and procedures has been implemented to

effect the correct joverning behaviour, or at least make It easy

to add to existing programs. The essential precept of this

governing aporoacn is that the student's program be executed as a

subroutine of a procedure which establishes handlers for looping

conoitions. I will outline the procedures for assembly language

proolems (they are fairly simple), and enumerate in detail the

oroceoures used for O'L/i problems.

-23-

An assemoly language student assignment should be handled In

the following fashion:

1. All students c

CSECT 13oel.

2. A governing pr

loader Inout

program. Addit

the student's

ode tneir solutions with the same given

ocedure

stream

iona lIy,

program

is coded which is placed In the

physically before the student's

a special CSECT is placed after

in the loader inout stream.

3. This

TASK

govern

opt ion

4. The exit ro

first clos

registers a

later. The

from its st

its end, wn

after the

program is

ing procedure uses the STIMER macro with the

to set jo a CPU timer.

utine specified in the STIMER macro should

e all open files, then obtain the studen t's

nd PAW, following the procedure outlined

n tne student's program should be dumped,

art (remember, we know its CSECT name), to

ich is found from the special CSECT we stuck

student. Following the dump, the studentes

terminated.

5. The student's program

parameters. When the

cancelled.

is called, with

student returns,

any

the

sui tabI e

timer is

For student assignments written in PL/1,

gloverning package has been developed. This

a very complicated

package consists of

four assembly languaie suoroutines and one PL/1 orocedure. This

oackage is ased in conjunction with a loader option to provide

what has to oe the most aesirable governing for PL/1. The

conaition ERRJR is raised at the point where the student runs out

of time. Although this package is written for the PL/1 (F)

13nguage, it may be easily converted to execute with the PL/1

optimizer. The followinj description assumes a working knowledge

of the F-level PL/I implementation details. (1)

Assembly

USETIMF)

Language Governor Subroutines (SETTIME, CANTIME,

The purpose

programmer with a

fa-cilities of the

complicated interna

simply stated this

amount of time a PL

of these routines is to provide the PL/I

convenient interface to the STIMER timing

operating system. This package is fairly

lly, and strongly tied to OS/MVT or VS. Quite

oackage provides a mechanism for limiting the

/1 orogram will be allowed to use.

To use this oackage a programmer calls an initialization

entry point specifying a primary and secondary time allocation,

both in hundredths of a second. Once the primary time allocation

has been usea the secondary limit is installed and the programmer

defined condition (TIMEOUT) is raised.

(1) For reference, see "I4M System/360 Operating System- PL/I(F)Subroutine Library Program Logic Manual", IBM publication number

GY28-b901.

This condition na3naler should close and re-ooen SYSPRINT to

clear any hanging I/0. If the (TIMEOUT) conaition handler

returns, the timing oackaje will cause the ERROR condition to be

raiseO at whatever point execution vis suspended. It the

seconoary time allotment is used up eitner by the (TIMEOUT) or

subsequent ERP3R nandler, the task is abnormally terminated with

a completion cole of 322.

Anothe&r set of entry points is provided to tell how much

time has been used out of the allotments. One of these entry

points c3ncels the timing as well. Thus if your program doesn't

uSe its whole al lotment (or at least if it doesn't use up the

secondary one) you can find out how much time you did use.

This package

in the following

procedure, below):

is used by a special

manner (refer to

1. First SETTIME is cal led to

student. The values passed

execution time.

PL/1 governing procedure

the source listing of this

establish

to SETTIME

limits for the

may be altered at

2. The governor establishes a (TIMEOUT) handler which

closes SYSPRINT, opens it, prints an Informatory

message for the student, and then returns.

3. The governor establishes a FINISH condition handler

which uses the USETIME entry point to determine how

much time a student has used. This value is printed

wthenever the FINISr condition is raised.

4. The student is

of the govern

raised. Utner

causes the FIN

C Il

or i

wise

ISH

led. If the st

s reachea and

the student

to be raised.

udent returns, the end

the FINISH condition Is

does something that

PL/1 Callable Entry Points:

SETTIME( FIXED BINARY(31), FIXED BINARY(31));

The fir

hundredths of

to 1. second).

limit, again

st argument is the primary time IImit, in

a second (le., a value of £00 corresponds

The secona argument is the secondary time

in hundredths of a secona.

Tnis entry ooint performs initialization for the

timing package. It should be called as soon as possible

in a program to be monitored. Note that the program

calling this entry point m.Us provide a condition

handler for the programmer defined condition (TIMEOUT).

This handler, in turn must close and reopen the file

SYSPRINT, to avoia problems.

CANTIME(FIXED BINARY(31), FIXEU BINARY131));

This entry point cancel

re turns an inJication of

interval rem3ins. The first

s the timing feature and

how much of the original

argument is a switch. Its

-27-

value is one if the Primary allocit

zero if the primary allocation has

Obviously if this value is one you are

secondary limit.

ion was used, and

not been used.

operating in the

The second argument is the number of timer units

remaining in the most recently set interval (the

secondary interval if the first switch is on). A timer

unit is approximately equal to 26.04166 microseconds.

The coce necessiry to determine the amount of time used

is shown in the governor source listing, below.

USETIME(FIXED BINARY(31), FIXED BINARY(31));

This entry point functions exactly as CANTIME,

except that the remaining interval, be it primary or

secondary is reestablished. This entry point is

recommended in case you have a loop in your (TIMEOUT)

or ERROR haniler.

Timer Internals:

When SETTIME is c-lled

EXITRTN as the exit routine and

intervel. Then the secondary

location for later use and the

it issues a STIMER macro naming

the orimary time interval as the

time interval is stored in a known

entry returns.

When CANTIME is called it issues a TTIMER macro instruction

with the CANCEL option. This returns the remaining time Interval

-28-

and cancels tne timing. Next a switch is checked to see if a

previous interval has expired. This switch and the remaining

interval are returne l.

The entry USETIME functions exactly like CANTIME, except

that Oefore returninj it uses an STIMER macro to reestablish the

remaining interval specifying SABEND as the exit routine. This

routine loads 322 into register one and abends.

EXITRTN is cal led by the operating system when the primary

time limit has been exceeded. The first thing this routine does

is issue an STIMER micro instruction to establish the secondary

time limit with SABENU as the exit routine. Then a switch is set

so the CANTIML and USETIME entry points will know that the

primary allocation has been Used.

The rest of this routine is very complicated. This routine

is entered by the operating system stage two exit effector. For

proper results this routine _qggit return to the operating system

or abend. Further, there is no attempt on the operating system's

oart to proviae you information about where your program was when

it ran out.

To satisfy the condition that we return to the ooerating

system we mist first find out where we were and what the

registers were (method described later). Register 13 is used as

the save area pointer by US convention. For a PL/1 procedure or

begin block, bit 0 of this save area (the first bit of the PL/1

-29-

reserved header word) will oe on. If we are in a PL/1 procedure

we perform the following:

1. Using the ISW, which points to the next instruction to

oe executed in the halted program, we save the next 14

bytes of the progjram. A switch is set in EXITRTN for

later use.

2. We move into these "evacuated" 14 bytes a sequence of

instructions which, when executed will cause control to

flow to the label STEP2 in EXITRTN. Care Is taken to

check the alignment of the starting address so the code

will function on a 360.

3. When STEP2 is enterred it checks its switch. Noting

that It was on it restores the Instruction sequence

previously saved.

4. EXITRTN returns to the operating system, only to

receive control back at STEP2.

If this bit is not on, we are in eithe a PL/I run-time

library routine or a system I/0 routine. Either way it is

dangerous to susoend activity, and unlikely that these routines

would loop. What we do is thread back up the save area chain

until we find a save area with the magic bit on.

This save area is the lowest level orocedure or begin block

involved. It is used by the subroutine which was called by the

orocedure. We p1ace the

in this save area. Wnen

return to STE32.

address of STEP2

the suoroutine

into

is

reg Iister

finished

14's slot

it will

IMEOUT).

gnal led.

de is for

then

If this

Just in

SABENO.

3ign3ls the programmer defined condition

conoition returns then the condition ERROR is

case the ERROR condition returns, the next

Finding Registers and PSd in a STIMER Exitt

ethod may

when an STI

and VS rel

OS/MFT wi

The alyori

be used to find the registers and PSW that

MER exit was effected. This code functions

eases one and two. This algorithm may

th the multitasking option, but it hasn*t

thm goes sometning like this:

1. Finding the TCB address. An EXTRACT macro is used with

the FIELOS=(FRS) option to get the address of the

floating point save area for the task. This area is a

orefix to the TCd. Adding 32 (decimal) to this address

gives the start (offset 0) of the TCB.

The first field

is the anchor pointer

in the TCB (that is, at offset 0)

for the Request Block (RB) chain.

2. The first RB on this chain is the IRB created

stage two exit effector for the STIMER exit

The RBGRSAVE field of this IR3 (offset 32

by the

routine.

decimal)

This m

active

OS/MVT

under

tried.

were

under

work

been

-31-

contains

stored In

the reoisters of the Interrupted program,

the order U-15.

3. The RBLINK field of this IRR (offset 28 decimal, low

order three bytes) points to the previous RB on the RB

chain. This is the PRS for the student. The RBOPSW

fiel of this PR3 contains the PSW current when the

timer ran out. The low order word (offset 20 decimal)

of this field contains the address of the next

instruction to be executed when the STIMER exit routine

returns to the operating system.

The Control Stealing Package

These routines provide the

governor program to "steal" control

support necessary for

from a student's program

has been compiled with

requires assembly languag

ostensibly name his or

call statement can not be

the "OPTIONS(MAIN)" clause

e subroutines since the

her procedure anything,

coded In the monitor.

. This process

student could

hence a simple

The linkage editor

containing the governor,

package. Using linkage

identified as the entry

editor LIBRARY statement i

Is used to create a load module

timing package, and control stealing

editor control statements STEAL is

point for this load module. A linkage

used to stop resolution of the

external references to IHEMAIN, IHENTRY, GOVERN, and IHESAFQ.

the

that

-32-

When the student is to De executed, his or her compiler

output is appended to this load module as input to the linkage

loader. Use of the loaaer parameter "EP=STFAL*, causes the STEAL

routine to be entered by the loader when loading is complete. It

saves the parameters passed, saves the address of the student's

main procedure, which is contained in the CSECT IHEMAIN, and

places the address of STAGE2 in this CSECT.

Then the routine LHENTRY

initialization entry point for

creates the PL/1 enviroment and

contained in IHEMAIN. This is th

initializer knows the "name" of t

is called. This

the PL/I run time

then branches to t

e mecnanism whereby t

he main procedure.

is

Iibrary.

he addr

he run t

This causes STAGE2 to be enterred, with the PL/1 enviroment

created. STAGE2 creates a String Jope Vector (SOV) for the

parameters saved by SiEAL, and calls the PL/1 routine GOVERN.

This routine is the actual governor, which processes parameters,

establishes default error handlers, and execution limits.

When the governor is ready to start a student, it calls the

entry point PAYBACK. This routine retrieves the student's address

which STEAL garnered from IHEMAIN, places this address in

register 15, and branches to It.

When the student is finished,

condition causes control to return

oost processing necessary. Now a slight

or when an

to GOVERN, it

crock enters

exceptional

performs any

into olay.

the

It

ess

ime

-33-

Since we

orocedure,

However,

different

want the IHEMAIN CSECT to point to the student's

the GOVERN procedure majt a.1t use OPTIONS(MAIN).

the procedJre epilogue for a main procedure is slightly

from that of a subroutine.

If GUVERN's epilngum is atlowea to gain control, it will

receive a protection check (system completion code of OC4). The

entry point 6AILOUT has been provided to get around this problem.

This entry point causes control to be passed to the PL/1 run time

library routine IHESAFQ. This routine closes all files, frees all

automatic storage and returns to the operating system (loader, in

our case).

PL/1 Callable Entry Points:

PAYBACK - This entry

stuoent's main

governor wishes

causes control to be passed to

procedure. It takes any arguments

to pass to the student's program.

BAILOUT - This

finished

student's

entry is called by

processing and

program.

the governor when it

wishes to terminate

The following governing procedure may be used with any

student program written in PL/1 (F). It is designed to function

with student orojrams which have been written with

*OPTIONS(MAIN)*. If the student programs are being run as

subroutines of some "grader" program, this grader should be

the

the

is

the

modifiec to use tnie timing nackage described above.

Governing Procedure Source

/* GOVERNING PROCEDUR E ESTABLISHES LIMITS FOR STUDENT PROGRAMS,USING THE TIMING AND CONTROL STEALING PACKAGES. THE LIMITSESTA3L ISHEJ ARE FOR CPU TIME AND LINES PRINTED ON SYSPRINT.THIS PROGRAM ACCEPTS THE FOLLOWING EXECUTION TIME PARAMETERSt

MAXPAGES-

MAXTIME-

STLIMIT-

LINESIZE-

PAGESIZE-

NUMBER OF SYSPRINT PAGES ALLOWED.JEFAULT IS 15.

MAXIMUM AMOUNT OF CPU TIME A STUDENT MAY USEIEFORE HE OR SHE IS INTERRUPTED, INHUNDREDTHS OF A SECOND. DEFAULT IS 500,.5 SECOND.

AMOUNT OF TIME A STUDENT IS ALLOWED IN HISOR HER ERROR HANDLER AFTER MAXTIME HAS BEENEXCEEDED. DEFAULT IS 100 (1. SECOND).

SYSPRINT LINE SIZE, IN CHARACTERS. DEFAULTIS 120 CHARACTERS.

SYSPRINT PAGESIZE, IN LINES, DEFAULT IS 50.

AN EXAMPLE PARAMETER STRING WOULD 8E:

PARM=* MiAX TIME =2 00, STL IMIT=50, MAXPAGES=5'

SINCE THE STEAL PACKAGE IS USE0, IF THIS GOVERNOR IS USED WITHTHE LOAUER THE LOADER PARAMETER *EP=STEAL* MUST BE GIVEN.

GOVERN: PROCEOURE(PARMS);DECLARE

PARMS CHAR(100) VARYING,MAXPAGES FIXED BIN INIT(i5),STLIMIT FIXED SIN(31) INIT(100),NUMPAGES FIXED BIN INIT(0),IPARMS CHAR(101) VARYING,SWITCH FIXED BIN(31),INTERVAL.REMAINING FIXED BIN(31),MULT FLOAT DEC(8) STATIC INTERNAL INIT(2.604i66E-3),TIMEUSED FLOAT DEC(8),INTERVAL FIXED DEC(8,2),LINESIZE FIXED t3IN INIT(120),PAGESIZE FIXED 3IN INIT(50),MAXTIME FIXED 3IN(31) INIT(500),SETTIME ENTRY(FIXEO BIN(31), FIXED BIN(31)),USETIME ENTRY(FIXEO BIN(31), FIXED BIN(31)),BAILOUT ENTRY,IHESARC ENTRY(FIXED BIN(31));

-35-

/* PARAMETER PROCESSING BLOCK */3EGIN;

ON ERROR PJT FILE(SYSPRINT) SKIP EDIT(**** ERROR *** THE PARAMETER STRING: ,'' ,PARtMS,

* asCONTAINS AN UNRECOGNIZAILE PARAMETER*) (A,SKIP,A,A,A);IPARMS = PARMS i i

GET STRING(IPARMS) DATA (MAXPAGESMAXTIMESTLIMIT,LINESIZE,PAGESIZE);

ENO;

/* OPEN SYSPRINT WITH SPECIFIED PARAMETERS */OPEN FILE(SYSPPINf) STREAM OUTPUT PRINT PAGESIZE(PAGESIZE)LINESIZE(LINESIZE);

/* SET UP CONDITION HANOLERS */ON FINISH BEGIN;

ON ERROR GO TO EXIT;CALL USETIME(SWITCH, INTERVALREMAINING); /* GET TIME LEFT */TIMEUSED = FLJAT(DECIMAL(INTERVALREMAINING,8,0),8);TIME _USED = TIMEJSEO * MULT; /* TIME USEU IN HUNDREDTHS */INTERVAL = - FIXEJ(TIME_USED,8);INTERVAL = INTERVAL + OECIMAL(MAXTIME,8,0);IF SWITCH -= 0

THEN INTERVAL = INTERVAL + DECIMAL(STLIMIT,8,0);PUT FILE(SYSPRINT) SKIP EDIT (*STUDENT PROGRAM USED *,

INTERVAL/100.0, * SECONDS.*) (SKIP(2),A,F(8,2),A);CALL IHESARC(FIXE(BINARY(INTERVAL,31),31));

EXIT:CALL BAILOUT; /* AVO10 EPILOGUE */

END;

ON ENdPAGE(SYSPRINT) BEGIN;PUT PAGE; /* RESET COUNTER */NUMPAGES = NUMPAGES + 1; /* BUMP COUNTER #/

IF NUM _PAGES > MAXPAGESTHEN 00;

PUT FILE(SYSPRINT) SKIP(2) EDIT( MAX PAGE LIMIT EXCEEDED, EXECUTION STOPPED') (A);

EN JEND;

UN CONOITION(TIMEOUT) BEGIN;CLOSE FILE(SYSPRINT);OPEN FILE(SYSPRINT) STREAM OUTPUT PRINT PAGESIZE(PAGESIZE)

LINESIZE(LINESIZE) ;PUT FILE(SYSPRINT) EDIT (**** EXECUTION TIME LIMIT EXCEEDED,',

ERROR SIGNALLED.') (SKIP(2),A,A)END;

PUT FILE(SYSPRINT) EIT(**** STUDENT PROGRAM SUCCESSFULLY LOADED.') (SKIPA);

CALL SETTIME(MAXTIMESTLIMIT);

-36-

CALL PAYBACK; /* START UP STUDENT */SIGNAL FINISH; /* AVJI0 EPILOGUE WHEN STUOENT RETURNS */

END GOVFRN;

A CHEAPER PL/1 (F) COMPILER

The

especial

comoi I er

of CPU

typical I

IBM PL/1 (F-level) compiler is very expensive to use,

y for small programs. Close examination or the

s costs discloses that it is fairly efficient in its use

time, but horrendous in Its usage of disk I/O. With a

small stucent program (< 200 cards), and a well chosen

region size (128K-oytes);

comoi I er

recuestin

is the result of pr

9 Q2C2iam segments

most of the disk I/0 performed by

ogram fetches. That is,

instead of data.

the I/O

t he

is

When this comp

it run in a 44K Pa

on a 64K macnine

comPller was brok

These phases are lo

iIer was

rtit ion,

running

en down

acied ,is n

written a design requirement was that

that being the largest user partition

OS. To meet this requirement the

into about 125 small overlay phases.

eeded, under tne control of special

subroutines in the compiler root ohase. This loading is

accomplishea oy either a LINK; or LOA0 and OELETE combination of

operating system macros.

The modifications which I made center around changing this

overlay structure, making for fewer phases (segments) of greater

length. To allow relatively easy changing of this structure, I

have used a combination of the linkage editor overlay supervisor

-37-

and the LOAD, DELETE, and LINK facilities of OS. The linkage

editor is used in conjunction with overlay control statements to

produce a comoiler lo3a module. Any rarely used Phases such as

those reauired only for soecial features or handling disasterous

errors, are excludea from this linkage edit.

When the phase control routines in the compiler root want a

certain phase, a table of aodress constants Is checked. If the

appropriate jddress constant is zero, indicating the phase was

not linked in, the old method of obtaining the phase Is used. If

the constant is not zero, a standard OS CALL is used to access

the phase through tha overlay supervisor. This approach allows

the best of ooth worlas.

The overlay structure may easily be modified to suit

different objectives, while rarely used phases do not add to the

overheac of segment swapping. To aid in the determination of

optimal overlay strategy, a special option *TRACEFLOW' has been

added. This option exoects a file TRACE, with attributes similar

to SYSPRINT. A formatted, annotated dump of control flow

indicating wnen phases and segments were actually loaded is

produced on this file. This option produces much output, hence

should De used with care.

In addition to the structural changes, the initialization

process of toe compiler has been drastically streamlined. In the

case of batch comoilations, very little initialization is

necessary after the first deck. Several new features have been

-38-

added to made The compiler more convenient

accurate spill file metering and size estimat

description of these enhancements and their use

ly modifications are contained in

annotated inpat to IEt3UPDTE, the IBM text

These changes aoly directly to the IBM so

compiler modules: IEMAA, IEMAB, IEMAC,

IFMBW, IEMFV, IEMJZ, IEMLV, IEMQU, IEMQX,

the modifications apply to IEMAA ana IEMA3.

. This includes

ion. A complete

is In Appendix 3.

two boxes w

maintenance

urce for the f

IEMAK, IEMAL,

and IEMXA. The

0

0

rth of

til ity.

I lowing

IEMAN,

bulk of

It should be stressed that absolutely a2 modifications have

been mace to those p3rts of the compiler that participate in code

generation or oarsing. Thus, the modified compiler produces

g tly the same coca as the unmodified complier, at a lower

cost. Extreme caution should be exercised when changing tne

compiler overlay structure, since some routines make assumptions

about the availability of a module, and bypass the phase

acauisition routines of the root. This usually produces very

subtle bugs. The way to find these is to use TRACEFLOW and

compare loacing activity to the old overlay structure published

In the IbM compiler ?LM. (1)

(1) Appendix A, Dage 383 of "IBM System/360 Operating System-PL/I(F) Comoiler Program Logic Manual", IBM publication numberGY28-6800.

-j9-

EVALUATION OF CHEAPER PL/1 (F) COMPILER

The overlay structure I finally produced requires a minimum

partition of about 112K. It successfully compiles small (around

150 statement) programs in 128K without opening the spill file. A

general rule of thamo is to add 60K to whatever region size

worked for the IBM complier without opening spill files. If you

are trying a meoiam size compilation for the first time, try

160K.

According to results obtained Dy Granger and Donovan, (1)

the modified compiler is in all cases ten to fifteen percent

cheaper than the unmoaifled version. The gains are greatest for

small decks and odtcned compilations. The modifications act to

cut CPU time, disk I/0, and core residence time. The CPU

reduction is from reduced operating system entry/exit sequences

ana I/O processing.

Since these modifications drastically reduce the fixed

overhead for a PL/1 compilation, the savings are most dramatic

where small (< 101 card) decks are concerned, running as high as

60 percent. Granjer and Donovan compared the modified compiler

to the unmodified F-level and tne 13M optimizer with OPT(0) and

OPT(2) specifieo. Their results were obtained on an IBM Model

165, running IVT 21.7. The only parameters reported were CPU time

(in minutes), disk I/0 operations, and core residency time (in

(1) "The Demise of PL/i(F)", Richard H. Granger and John J.Donovan.

-40-

minutes).

thousan d

less than

he prices useJ

0 operations,

OK, t.50 per k

were

and

i Iobyt

17.00 oer c

since all

e-hour for

Pu minute, $1.00

core requirements

core residence.

results which

sumarized in ta

that althougn

optimizing comp

However, for

to compilation

the

nle

mor

I er

stud

time

y obtained for a typical 150 card pr

tnree, oelow. In fairness, it should

e expensive in the compilation p

proauces cooe which is cheaper to

ent runs execution time is negligible

.

ogram are

be noted

hase, the

execute.

compared

CALEaQ2L-

CPUDiSK i/0MEMORYCOST

Table Three:

QLlai---leial

.162 .194516 719

;2.18 $2.77

Performance Data

.074413

$1.25

for Cheaper

IBM-F

.082828

$1.80

Comol I er

I have perform

and unmodified comp

of the3e decks con

but manipulated li

oerformed much I/0

on an IBM Model 168

accounting procedur

structure was dif

minute, $1.20 per t

ed similar comparisons between the modified

ilers, using representative student decks. One

tained 76 cards and performed very little I/0,

nked lists; the other was 348 cards and

and list processing. The tests were performed

running OS MVT release 21.8, using the same

es as used by Granger and Donovan. The pricing

ferent, however. The rates were $12.00 per CPU

housand disk I/O operations, and $.65 per

K-byte hour for memory. The results

per

were

The

--

obtained were!

Sm311 Deck Larger Deck

CPJ .14 .021 .028 .036OISK 1/0 530 877 367 906MEMORY L .32 kzlJ .. A

COST 33.88 11.37 i1.08 $2.21

-42-

APPENJ IX A: USEUS GUIDE FOR BATCH MONITOR

Tnis appendix descrioes a gene

designed to expedite the processing of

orogram assignments. Ihis is a comOlex,

may be use a for vir tually any two

driven from a large set of execution ti

greater flexioliity.

ral purpose batch monitor

a large number of student

generalized program which

step computing task. It is

me parameters, to allow

Basically, this program reads an input stream of student

decks, performing the same processing for each deck. Decks are

preceded by a "eJot" card specifying the student's name, and

terminated by a "6E0J" card. The processing performed for each

deck is fairly simple, as follows:

1. Each student's deck

by SYSWORK. This

control cards.

2. if the

by a

sepoarat

later.

is spooled onto a dataset

spooling process strips off

de f I ned

the two

separator option is specified, a program named

parameter is linked to, to print student

ors. This routine*s input specifications appear

3. A parameter-de fined

the student. The

translator program is

alternate ddname list

invoked for

(1) option is

(1) See, for example, either page 47 of "Assembler(F)Programmer*s Guide", 131 publication number GC26-3756, orpage 62 of "PL/I(F) Programmer s Guide", I3M publicationnumber GC28-6594.

-43-

used oy this call, tnerefore the translator must be IBM

compatible. The adnamre SYSIN is changed to SYSWORK,

the daname SYSLI3 is changed to TLIB, and the ddname

SYSLIN is chanljed to SYSGO. 1hese changes avoid

confusion with Ioader and run-time datasets, which

would resul t fr om all of the JCL for two steps

appearing at once.

4* The translator's return code is compared to a parameter

to see If the student will be allowed to run. If not,

the loader phase is skipped.

5. If the student's translater return code was alright,

the loader is attached to run the student. Parameters

may be specified for the loader and the student, and

the loader proqram's name is a parameter.

6. If the rewarding option has been specified, the loader

completion code is examined. Except for the case of

loader errors, this is a return code from the student*s

program. If this value is equal to a supplied

parameter, a program is linked to. This allows grading

programs to indicate a student's score, for possible

rewaroing. The input aescription for this routine is

qiven late-.

7. If the logging option is specified, the student's name

from his or her "'JOB" card is saved, along with

-'p4-

translator 3nd loader return codes. This information is

formatted on the file SYSLOG.

8. This concludes processing of the current student.

one is repeated for the next student, until the

stream is empty.

Step

input

This monitor is very tolerant

errors, including omission. All but

aire correctly handled. The loader pr

stuoent abena will not affect the moni

was codec. The monitor is reentrant,

Link Pack Area to &top student damage.

of student control

the most pathalogical

ogram is attached,

tor, unless the STEP

so may be installed

The monitor accepts many options, which are detailed below.

Some of these options may contain subfields, for instance to pass

the translator two parameters 'LOAD' and *NODECK*, you would code

"TP=(LOAD,NO9ECK)*. The parentheses are necessary for correct

monitor parameter parsing, but are not passed to the translator.

Wnenever a program name is called for, it goes without saying

that this length must be less than or equal to eight characters

in length. The monitor options, with their abbreviations, and

default values, areI

SEP, SEERAT3R- If specified, the paging separat

turned on. This causes a special module to

to to orint output separators for a s

default for this ootion is on.

or option is

be LINKed

tudent. The

card

cases

so a

option

in the

-45-

NOSEP, NG0SEPERATOR- If

output separator fea

SN, SNAME- Specifies the

current STEPL 13 or

print separators, if

defaul t for this par

soecified, turns of the student

ture.

name of a load modul

LINKLIB, which will be

the SEP option is In ef

ameter is SEPRTN.

e in the

Invoked to

fect. The

LOG- If specified, ciuses the student log to be

This reouires tne monitor file SYSLOG. The

this option is on.

maintained.

default for

NOLOG- If specified, turns off the logging option.

LC, LINECNT- An uns

lines to be pr

default is 55.

igned integer specifying the number

inted per page of the SYSLOG dataset.

REW- If specified, indicates the student rewarding option is

in effect. The default for this option is off. This

option uses the following two parameters.

RS, REwAROSCDRE- An unsigned integer specifying the loader

return code which will cause the rewarding module to be

invoked. The default is 100.

RN, RNAME- Name of module invoked to perform student

rewarding when the student's loader return code matches

the remarding score. Same restrictions as SNAME. The

defaul t is REWAR9.

of

The

NOREW- It specifled,

teature.

turns off tne student rew3rding

TN, TNAME- Specifies name of translator proiram. This name

should exist either In the JOLI or STEPLIB; or in

LINKLI3. The aefault is ASMBLRF.

TP, TPARMS- A parentnesized list of

the translator. The deafilt

(LDAD,N00ECK).

options to be passed

for this parameter

MR, MAXRET-

allIowea

higher

LN, LNAME- N

TNAME.

An unsigned

translator

than this wil

am1e of Ioade

Tne default i

integer specifying the maximum

return coae. Students with a value

I not be loaded. The default is 4.

r

s

program. Same restrictions

IEWLORGO.

as

LP, LPARMS- A oaren

the loader oro

GPI, GPARMS-

gr ader

is (),

thes iz

gram.

ed list of ootions to be passed to

The default Is (NOPRINT).

Parenthesized parameter string passed

, subject to the ZS parameter below. The

ie. null.

to the

defaul t

ZS, ZSCORE- A character string which will be appended to the

specifiea GP string whenever the current student had a

control card error. This allows the monitor to

communicate to graaing programs. This Parameter should

be parenthesizel and Its default is (8ADJCL=1).

to

is

-47-

These

field of

batch moni

mentioned:

oarameters may be specified in any order in

the EXEC statement for the monitor's job

tor requires tne following files, with qual

the PARM

step. The

if icat ions

MONIN- Always required, contains the student decks with

their monitor control cards. This file should have the

JCB attributes RECFM=FB, LRECL=80, and BLKSIZE= some

multiple of 3j.

SYSWORK- Always required, used to spool the student decks.

Should have DC03 attributes similar to MONIN, but not

necessarily the same block size.

SYSLOG- Requirec if the

should have the

and LLKSIZE= n*125

LOG option is in effect.

JCB attributes RECFM=VBA,

+4 (ie. 129, 2004, etc.).

This file

LRECL=125,

SYSPRINT- Reqired if the SEP or REW options are in effect.

Also used by tr-anslator and student. 0C3 attributes may

be any commonly used translator compatible attributes.

SYSGC- kequired by translator to outout machine code. Same

DCB restrictions as MONIN.

TLIA- Required if stjdents are to use macros

incIuce fles (PL/1). Should point

correct attributes for translator.

(assembler) or

to a POS with

-48-

SYSLIN- Provides inpit

defines a set of

'YSGO's dat3set

ex3mole, below).

file for loader program. Usually

oncatenated tile definitions,

3oearing somewhere (refer to

SYSLIB- Used

Ioader.

oataset

to soeci

If PL/

"'SYS1. PL

a dynamic linking library for

is used this should point to

I1."

Any other files recuired by the

stuaent should oe freely declared,

conflict with the recuired file names.

for stuaent use.

The following example depicts

process PL/1 assiqnments. A prellnkeJ I

the governing procedjre wnich watches

Therefore, the stuoent is second in th

allocation step cuts down overhead in t

translator, loader,

as long as they do

Note that SYSIN is

or

not

free

the monitor being used to

oad module is used to hold

the student's execution.

e concatenating order. The

he monitor step.

JOL for Running the Monitor with PL/I

/A EXEC PGM= IEFBR14/001 00 SN=&&GOISP=(NEWPASS),UNIT=SYSOA,

// SPACE=(TRK,(10,4)),// DC=(RECFM=F83,LRECL=80,3LKSIZE=1600)/002 DO DSN=&&WK,0ISP=(NEW,PASS),UNIT=SYSOA,

//SPACE=( TRKP(10,P4)1 ,// DCCB=(RECFM=FB,LRECL=80,8LKSIZE=2000)//003 D OSN=&&TIDISP=(NEWPASS),UNIT=SYSOA,// SPACE=(TRK,(10,4)),/ OCB=(RECFM=FB,LRECL=80,BLKSIZE=i6OO)//M EXEC PGM=MONITOR,// PARM=( TP=(LD,N0,NL,NE),TN=IEMAA,SEP*,1/ * LP=(NDPRINT,EP=STEAL)*)//STEPLIB DOD SN=U.M20153.11272.MONITOR.LOAD0ISP=SHR

this

w it h

the

the

the

- 4~9 -

//1//SYSLCG//SYSWDRK//1//SYSPRINT//SYSLI //SYSUT1I////SYSGO////SYSLOUT//SYSLIN//////SYSIN/ / MDNIN 00 0

DO DSN=U.M20153.11272.COPY. MITPLI,0ISP=SHRDD SYSOUT=A,DCB=(RECFM=VBA,LRFCL=125,BLKSIZE=2004)D DSN=*.A.D29,VL=REF=*.A.CD2,

DCd= 4 .A.dj2,0ISP=(OLO,PASS)D SYSOUT=A,JCB=(RECFM=VBA,LRECL=125,8LKSIZE=2004)DD USN=SYSI.PLJLIB,0ISP=SHRDO JSN=*.A.0D3,VDL=REF=*.0.3,

DISP=(OLD,PASS)00 DSN=*.A.Dj,V0L=REF=*.A.0D,

DCB=*.A.OD1,DISP=(OLD,PASS)DD DUMMYOD JSN=U.M2 0153.11272.PLIMP.LOA0(P1) ,DISP=SHR00 DSN=*.A.001,VOL=REF=*.A.DD,

DC3=*.A.DDj,DISP=(OLD,PASS)0D JSN=U.M20153.i272.PL1MP.DATA(P1),DISP=SHRDATADC3=

$Job name of student o

II deck for student one

(REFM=FBLRECL=80,8LKSIZE=2000)ne, in free form

$EOJ$JO name of student two

deck for student twoI-EJ

JEiOJ

repeated for otier students

The monitor requires from eight to twenty k-bytes of

storage, depending on the options specified and buffer sizes

(file block sizes). This should be taken into account before

assigning a region size. Any parameter errors will cause the

monitor to terminate, with an explanatory message.

-50-

Separator Routine Inout Soecifications

The separator routine is invoked to print output separators

on the file SYSPRINT, if the SE? ootion Is in effect. This

routine is invoked dynamically by the monitor, via the LOAD

macro. The name used is gleaned from the SN parameter. Then the

routine is BALR'ed to for each student.

Upon

address,

points to

entry to tn

register 14

a five word

is routine, register 15 contains a base

contains a return address, and register one

parameter list, as followsZ

1. Pointer to 00B for SYSPRINT. This 3CB is opened, with

any DCG attributes compatible with tne translator being

used. If the user leaves the 0C3 information off of the

SYSPINT 0J card, tne default attributes of RECFM=VBA,

LRECL=125, 3LKSIZE=129 are supplied.

2. Contains the adiress of a

iuentifier, jleaned from the

character

student*s

string student

$JOB card.

3. Length of the student identifier from above.

4. Pointer to 80 coaracter control card one, which was

supplied by student.

5. Pointer to 80 character control card two.

The supplied default separator routine prints the student's

control cards at the top of an even page, then the student

identifier in block letters.

Rewarding Routine Input Speclfications

If the rewar

LINK'ed to when a s

rewarding score. Th

parameter RN.

ding option is in effect, tnis routine is

tudent*s loader return code matches a supplied

e name used in the LINK request is supplied as

Upon

address,

points to

address

of this f

entry to

register

a one wor

of an open

ile may be

tnis routine, register 15 contains a base

14 contains a return address, and register one

a parameter list. This word contains the

)CB for the file SYSPRINT. The DC3 attributes

any translator compatible combinations.

The suppiled default

page, prints a coniratu

and copies it onto tne

dataset specified oy RE

LRECL=121, and BLKSIZE=

nandles any popular SYSPR

rewarding module skips to the top of a

latory message, opens the file REWAROIN,

SYSPRINT file. It assumes that the

WAROIN has the 0CB attributes RECFM=FBA,

some multiple of 121. It correctly

INT 0GB attribute combination.

APPENDIX B: USE3R' GJIDE FOR CHEAPER COMPILER

The modified com pi

unmodifiea compile-, witn

it is to create 3 PDS wri

modules. Then take whatev

and acd a STEPLIB or JO3L

compiler's PDS.

ler is operationally identical to the

a few exceptions. The best way to use

ch contains the modified compiler's load

er JCL you use for the standard compiler

IB 00 statement refering to the modified

The modified compiler accepts four new options, controlling

two new featires. These options are:

TF, TRACEFLOW- If

apefinition for

for this fi

BLKSIZE= n*125

specified, a3

control flow i

is off.

specified, the user must provide a file

the TRACE print file. The DCB attributes

le should be RECFM=VBA, LRECL=125, and

+4, like 129 or 2004. If this option is

formatted, annotated dump of compiler

s orinteu. The default for this option

NOTF, NOTRACEFLOW- This option turns off the tracing

option.

OFF, OFFSET- Tnis option causes a statement offset map to

be produced, irregardless of other compiler options.

NOOFF, NOOFFSET- Tnis option suppresses the printing of a

statement offset map.

In addition,

'"PROCESS" cards.

default options

specify '*PROCESS;

upor invocation wi

If

charact

elect

neater

changes have been made to the handling of

If you specify '*PROCESS('")", the system

will e used for the compilation. If you

", the same options supolied to the compiler

II be used.

a T is coded

ers (usuall'Iy column

to a fresh page is

1 istinjs.

in the column identified for control

one), the title line is reset and an

Inserted. This may be used to provided