1972 ucsc version of the "explor" graphics system

refer purchase orders for this distribution tape to:
clay carter
computer center
univ. of calif.
santa cruz, calif.  95060

refer praise to:
dan ross
information and computer sciences
univ. of calif.
santa cruz, calif.  95060

refer criticism to:
ken knowlton
bell laboratories
murray hill, n.j.  07974

this tape is:  800 bpi  9-track  standard ibm label
the data sets on this tape are:
1.  dsn=readme.first.lrec80
    you are reading it now.
2.  dsn=source.lrec80.apr1172
    approx. 4300 card images, in blocks of 3520 bytes = 44 card images.  this
    data set contains the source code and jcl for the 5 job steps which create
    the "explor" system.  the jcl is appropriate to the computer configuration
    at ucsc.  at the time the jcl was written, we were reading the source code
    from a card deck.  undoubtedly you will need to modify the jcl for
    installation on your own computer.
3.  dsn=student.deck.lrec80.feb2272
    approx. 65 card images, in blocks of 3520 bytes = 44 card images.  a copy of
    this data set should be punched on cards and distributed to each student
    using the "explor" system.  before distribution, any local jcl changes
    should be incorporated into this deck.

the 2 data sets which will be stored permanently on disk are ics160.loadmod,
which contains all the code, and ics160.fmts, which contains fortran format
statements for the various error messages.  these format statements are stored
on disk to conserve core storage.  they are read into core and interpreted by
fortran whenever their corresponding errors are detected.

in order to prevent ics160.loadmod and ics160.fmts from being scratched, they
are given expiration dates of 99365.  one consequence of this is that the
computer operator's permission is required whenever either of these data sets is
opened for writing.  although the fortran code in fact only reads from these
data sets, the fortran direct access statements used for ics160.fmts allow the
possibility of writing.  we did not want to annoy the operator each time a
student ran this program, so we arranged the student's deck to copy ics160.fmts
into a temporary data set.  the operator's permission is not required to allow
writing in the temporary data set.

the jcl for copying the format cards into ics160.fmts, and for copying from
ics160.fmts to the temporary data set, specifies lrecl=80 for card images.
after the temporary data set has been created, the jcl is changed to lrecl=3520
in order to reduce the number of direct access read operations needed during
program execution.  the fortran code unblocks the formats back into 80-byte card
images, and may use any 2 consecutive card images within a single block for a
format specification.

at one time during program development we were having disk hardware trouble, but
we suspected the direct access code.  therefore we changed the direct access
statements to comments and substituted sequential access statements, which are
less efficient.  if you wish to change back to direct access, the relevant
statements are in subroutines "init" and "q4mat".

it was our original intention to provide facilities in the code which would make
conversational operation easy to implement.  we lacked the remote terminals
which would have allowed us to complete the coding for conversational use.  you
will find references to conversational operation scattered throughout the code.
in particular, subroutine "qnowut" contains 2 kluges which substitute for a
user's conversational response.  the first has the user respond "h" to the
question:  "what do you want to do now?"  the second has the user respond "c" to
a repetition of the same question.

even without conversational capability, judicious use of subroutines "nowat" and
"histry" can be a powerful debugging aid.  these subroutines are part of the
"$trace" package.

we link edited all the subroutines into a single load module, which later is
included in its entirety in the user's load module, in order to simplify the
bookkeeping associated with program development.  once the program has
stabilized at your installation, you may wish to link edit the subroutines into
a library instead.

whenever you recompile this program such that its execution changes in any way,
be sure to update format card number 61.
