This is the infamous Gary Barnes SPR. Gary wrote the SPR after a
particularly
frustrating debugging session.
The SPR was submitted by Gary in 1980 not really expecting an answer.
The SPR was read at a DECUS in 1984 in a session which was part of
the 20th anniversary of 36 bit computers commemoration.
A DEC speaker said that DEC never responded or
published this SPR, but the SPR and this response was
posted on the wall at the Large Systems Group for a year.
I talked the speaker and explained that I worked
with Gary. He let me take a copy back to Gary.
TOPS-20 4(3247) MOUNTR 4(64) Dec/1/80
Problem: MOUNTR was obviously never tested.
MOUNTR is basically a mound of decayed, worm eaten, and fly besotten
fecal matter.
Diagnosis: There is code in there that literally must be executed in
order for it to run properly and DDT break-points and STOP codes
placed in that code never occur. ie There literally exist no Jrsts
or Calls to that code.
The account (Usage) records that it writes are almost completely
wrong. There are more fields which are wrong than fields which are
correct. There are even more fields left erroneously blank than there
are fields which are correct.
There are half word fields used as accumulators for things that could
easily exceed 256K, ie. number of records read and written on a
tape.
It keeps around fake “mount request” blocks after the instigating
dismount request is gone, ie. mount a structure, dismount it, and
you (sometimes) cannot mount it again due to the extraneous blocks
hanging around.
The person who wrote it was obviously not an Ace Macro Hacker even
though his user name was R.ACE. He obviously had never seen or
written Macro before. The comments are often misleading and not
uncommonly wrong, ie the code without the comments would be easier to
understand.
It is easily confused if the operator does something strange (ie
wrong order of commands with tape initializes and setting drives
off-line and such) or if the drives go a little flakey due to device
errors. This usually results in its having to be killed and
restarted. Sometimes INFO has to be restarted also.
The VOLID in the Usage record is usually set to be the logical tape
name that the user happened to use. The Read/Write counts are either
zero or they are astronomically incorrect. The error counts are
truly creative acts of fiction. The label type is incorrect and is
quite often the label type of a tape mounted by another user in the
recent past, usually on another drive.
MOUNTR was obviously tested by the learn-to-swim method. Ie. You
throw the customers into MOUNTR infested water and see how many get
eaten alive before they learn to swim. I have it from our local DEC
office that the Field Test sites complained of grossly incorrect
Usage records to which DEC responded with an “it will be fixed”. I
was also told that the final release has the same errors in the Usage
records.
The programmer involved should be sent to school to learn how to do
things or he should be promoted to a position where he cannot damage
future software.
Cure: Wem are currently rewriting large portions of MOUNTR. We fix
an average of 10 bugs a day for each day that we can stomach working
on this code.
PS: As I was writing this, rather vitriolic, SPR I was informed by
our local DEC’ee that R.ACE, the author of this abomination, has
left DEC for other places. To this I respond, HURRAH HURRAH HURRAH.
reply from DEC
MOUNTR IS A PIECE OF SHIT.
Thank you for your SPR on MOUNTR. Your diagnosis is entirely
correct. MOUNTR was never tested and was intentionally coded poorly.
MOUNTR is part of a test to see just how bad a product can be. Thus
far the test has been highly successful and it will enter phase 2
with the release of GALAXY 4.1 and the mountable device allocator
code in QUASAP.
Now dealing with your SPR in detail we shall address each problem.
-
MOUNTR was never tested, not even once, that it loads at all is
a surprise to all of us here at DEC. You are lucky it assembles. -
MOUNTR is a mound of fly besotten fecal matter, the flies won’t
touch it. -
There is code in MOUNTR which must not be executed for anything to
work at all. This code4 will totally destroy the validity of any
accurate information which happens to be around. Breakpoints and
stop codes placed in these locations will be hit continuously. -
The accounting records are completely wrong. There is code in
MOUNTR to check the correctness of each field before it is written
and change the field if it happens to contain valid information. -
There are 2 bit fields which are supposed to contain numbers in
the range 4-10. -
It not only keeps fake mount request blocks but it changes the
real ones using a complex formula involving the phase of the moon,
number of federal judges in Wyoming and the price of OPEC oil in
pesos. -
You are correct the person who wrote MOUNTR had never seen MACRO
before, as a matter of fact none of us here at DEC can read or
write at all. This answer is being typed by a monkey who is
hitting the keys at random. -
It is easily confused if the operator does something strange. For
example, if the operator picks his nose with a shark’s tooth
MOUNTR will die with an illegal memory write. -
Thank you for your compliment on the error counts being truly
creative acts of fiction. We are rather proud of our-error count
determination formula:
ERROR=PI/2*(numbers of users on system)/(processor serial number)+
(milliseconds since the hostages were taken in Iran)**2
-
The final release had totally different and much worse errors in
the usage records than those errors reported during field test. -
No school in the country would take any of us. We are grade
school dropouts who program to support our alcoholism and
debauchery. -
Good luck rewriting MOUNTR. If you can make it work at all I
will be amazed