cost reduction of student programming exercises...
TRANSCRIPT
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