Time to post this classic; I don't recall who wrote it. Note that the
references are pretty obscure now...
-----
VAXen, my children, just don't belong some places. In my business, I am
frequently called by small sites and startups having VAX problems. So when
a friend of mine in an Extremely Large Financial Institution (ELFI) called
me one day to ask for help, I was intrigued because this outfit is a
really major VAX user - they have several large herds of VAXen - and
plenty of sharp VAXherds to take care of them.
So I went to see what sort of an ELFI mess they had gotten into. It seems
they had shoved a small 750 with two RA60s running a single application,
PC style, into a data center with two IBM 3090s and just about all the
rest of the disk drives in the world. The computer room was so big it had
three street addresses. The operators had only IBM experience and, to
quote my friend, they were having "a little trouble adjusting to the VAX",
were a bit hostile towards it and probably needed some help with system
management. Hmmm, hostility... Sigh.
Well, I thought it was pretty ridiculous for an outfit with all that VAX
muscle elsewhere to isolate a dinky old 750 in their Big Blue Country, and
said so bluntly. But my friend patiently explained that although small, it
was an "extremely sensitive and confidential application." It seems that
the 750 had originally been properly clustered with the rest of a herd and
in the care of one of their best VAXherds. But the trouble started when
the Chief User went to visit his computer and its VAXherd.
He came away visibly disturbed and immediately complained to the ELFI's
Director of Data Processing that, "There are some very strange people in
there with the computers." Now since this user person was the Comptroller
of this Extremely Large Financial Institution, the 750 had been promptly
hustled over to the IBM data center which the Comptroller said, "was a
more suitable place." The people there wore shirts and ties and didn't
wear head bands or cowboy hats.
So my friend introduced me to the Comptroller, who turned out to be five
feet tall, 85 and a former gnome of Zurich. He had a young apprentice
gnome who was about 65. The two gnomes interviewed me in whispers for
about an hour before they decided my modes of dress and speech were
suitable for managing their system and I got the assignment.
There was some confusion, understandably, when I explained that I would
immediately establish a procedure for nightly backups. The senior gnome
seemed to think I was going to put the computer in reverse, but the
apprentice's son had an IBM PC and he quickly whispered that "backup"
meant making a copy of a program borrowed from a friend and why was I
doing that? Sigh.
I was shortly introduced to the manager of the IBM data center, who
greeted me with joy and anything but hostility. And the operators really
weren't hostile - it just seemed that way. It's like the driver of a Mack
18 wheeler, with a condo behind the cab, who was doing 75 when he ran over
a moped doing its best to get away at 45. He explained sadly, "I really
warn't mad at mopeds but to keep from runnin' over that'n, I'da had to
slow down or change lanes!"
Now the only operation they had figured out how to do on the 750 was
reboot it. This was their universal cure for any and all problems.
After all it works on a PC, why not a VAX? Was there a difference?
Sigh.
But I smiled and said, "No sweat, I'll train you. The first command you
learn is HELP" and proceeded to type it in on the console terminal. So
the data center manager, the shift supervisor and the eight day-operators
watched the LA100 buzz out the usual introductory text. When it finished
they turned to me with expectant faces and I said in an avuncular manner,
"This is your most important command!"
The shift supervisor stepped forward and studied the text for about a
minute. He then turned with a very puzzled expression on his face and
asked, "What do you use it for?" Sigh.
Well, I tried everything. I trained and I put the doc set on shelves by
the 750 and I wrote a special 40 page doc set and then a four page doc
set. I designed all kinds of command files to make complex operations into
simple foreign commands and I taped a list of these simplified commands to
the top of the VAX. The most successful move was adding my home phone
number.
The cheat sheets taped on the top of the CPU cabinet needed continual
maintenance, however. It seems the VAX was in the quietest part of the
data center, over behind the scratch tape racks. The operators ate lunch
on the CPU cabinet and the sheets quickly became coated with pizza
drippings, etc.
But still the most used solution to hangups was a reboot and I gradually
got things organized so that during the day when the gnomes were using the
system, the operators didn't have to touch it. This smoothed things out a
lot.
Meanwhile, the data center was getting new TV security cameras, a halon
gas fire extinguisher system and an immortal power source. The data center
manager apologized because the VAX had not been foreseen in the plan and
so could not be connected to immortal power. The VAX and I felt a little
rejected but I made sure that booting on power recovery was working right.
At least it would get going again quickly when power came back.
Anyway, as a consolation prize, the data center manager said he would have
one of the security cameras adjusted to cover the VAX. I thought to
myself, "Great, now we can have 24 hour video tapes of the operators
eating Chinese takeout on the CPU." I resolved to get a piece of plastic
to cover the cheat sheets.
One day, the apprentice gnome called to whisper that the senior was going
to give an extremely important demonstration. Now I must explain that what
the 750 was really doing was holding our National Debt. The Reagan
administration had decided to privatize it and had quietly put it out for
bid. My Extreme Large Financial Institution had won the bid for it and
was, as ELFIs are wont to do, making an absolute bundle on the float.
On Monday the Comptroller was going to demonstrate to the board of
directors how he could move a trillion dollars from Switzerland to the
Bahamas. The apprentice whispered, "Would you please look in on our
computer? I'm sure everything will be fine, sir, but we will feel better
if you are present. I'm sure you understand?" I did.
Monday morning, I got there about five hours before the scheduled demo to
check things over. Everything was cool. I was chatting with the shift
supervisor and about to go upstairs to the Comptroller's office. Suddenly
there was a power failure.
The emergency lighting came on and the immortal power system took over the
load of the IBM 3090s. They continued smoothly, but of course the VAX,
still on city power, died. Everyone smiled and the dead 750 was no big
deal because it was 7 AM and gnomes don't work before 10 AM. I began
worrying about whether I could beg some immortal power from the data
center manager in case this was a long outage.
Immortal power in this system comes from storage batteries for the first
five minutes of an outage. Promptly at one minute into the outage we hear
the gas turbine powered generator in the sub-basement under us
automatically start up getting ready to take the load on the fifth minute.
We all beam at each other.
At two minutes into the outage we hear the whine of the backup gas turbine
generator starting. The 3090s and all those disk drives are doing just
fine. Business as usual. The VAX is dead as a door nail but what the hell.
At precisely five minutes into the outage, just as the gas turbine is
taking the load, city power comes back on and the immortal power source
commits suicide. Actually it was a double murder and suicide because it
took both 3090s with it.
So now the whole data center was dead, sort of. The fire alarm system had
its own battery backup and was still alive. The lead acid storage
batteries of the immortal power system had been discharging at a furious
rate keeping all those big blue boxes running and there was a significant
amount of sulfuric acid vapor. Nothing actually caught fire but the smoke
detectors were convinced it had.
The fire alarm klaxon went off and the siren warning of imminent halon gas
release was screaming. We started to panic but the data center manager
shouted over the din, "Don't worry, the halon system failed its acceptance
test last week. It's disabled and nothing will happen."
He was half right, the primary halon system indeed failed to discharge.
But the secondary halon system observed that the primary had conked and
instantly did its duty, which was to deal with Dire Disasters. It had
twice the capacity and six times the discharge rate.
Now the ear splitting gas discharge under the raised floor was so massive
and fast, it blew about half of the floor tiles up out of their framework.
It came up through the floor into a communications rack and blew the cover
panels off, decking an operator. Looking out across that vast computer
room, we could see the air shimmering as the halon mixed with it.
We stampeded for exits to the dying whine of 175 IBM disks. As I was
escaping I glanced back at the VAX, on city power, and noticed the usual
flickering of the unit select light on its system disk indicating it was
happily rebooting.
Twelve firemen with air tanks and axes invaded. There were frantic phone
calls to the local IBM Field Service office because both the live and
backup 3090s were down. About twenty minutes later, seventeen IBM CEs
arrived with dozens of boxes and, so help me, a barrel. It seems they knew
what to expect when an immortal power source commits murder.
In the midst of absolute pandemonium, I crept off to the gnome office and
logged on. After extensive checking it was clear that everything was just
fine with the VAX and I began to calm down. I called the data center
manager's office to tell him the good news. His secretary answered with,
"He isn't expected to be available for some time. May I take a message?"
I left a slightly smug note to the effect that, unlike some other
computers, the VAX was intact and functioning normally.
Several hours later, the gnome was whispering his way into a demonstration
of how to flick a trillion dollars from country 2 to country 5. He was
just coming to the tricky part, where the money had been withdrawn from
Switzerland but not yet deposited in the Bahamas. He was proceeding very
slowly and the directors were spellbound. I decided I had better check up
on the data center.
Most of the floor tiles were back in place. IBM had resurrected one of the
3090s and was running tests. What looked like a bucket brigade was
working on the other one. The communication rack was still naked and a
fireman was standing guard over the immortal power corpse. Life was
returning to normal, but the Big Blue Country crew was still pretty shaky.
Smiling proudly, I headed back toward the triumphant VAX behind the tape
racks where one of the operators was eating a plump jelly bun on the 750
CPU. He saw me coming, turned pale and screamed to the shift supervisor,
"Oh my God, we forgot about the VAX!" Then, before I could open my mouth,
he rebooted it. It was Monday, 19-Oct-1987. VAXen, my children, just
don't belong some places.
-- Dave
On 2018-10-16 20:37, Paul Koning via cctalk wrote:
>
>
>> On Oct 16, 2018, at 1:23 PM, William Pechter via cctalk <cctalk(a)classiccmp.org> wrote:
>>
>> DEC Tape II was the serial driven TU58.
>> The TK50 was CompacTape or something like that. It was the predecessor of a number of square tapes...
>>
>> See DLT on Wikipedia https://en.m.wikipedia.org/wiki/Digital_Linear_Tape
>>
>> Bill
> I used DLT on RSTS systems, with a Qbus interface. Those were modest speed hosts and buses, but I never remember data late or overrun issues, and we drove those tapes quite hard in full time streaming mode for backup and software distribution. Longer blocks, too (2k or so) which would make any buffering issues more severe.
Just few words here, as I'm not sure anymore we are talking about the
same thing ...
there were
TK50Z as an external drive, on "SCSI"
TZ30 internal drive, on "SCSI", using TK50 tapes
TK50 on QBUS with an TQK50 controller which really didn't stream to often
TK50 on QBUS with an TQK70 controller, which doubled the memory of the
TQK50, which was capable of streaming ...
For more information on J. C. R. Licklider, see these books
Cyber reader
ISBN 0-7148-4071-8
The Innovators: How a Group of Hackers, Geniuses and Geeks
Created the Digital Revolution
ISBN 1-4711-3879-8
The Dream Machine: J. C. R. Licklider and the Revolution That
Made Computing Personal
ISBN 0-670-89976-3
The computing universe: a journey through a revolution
ISBN 0-521-76645-1
Detailed BibTeX entries, with table of contents information, can be
found at
http://www.math.utah.edu/pub/tex/bib/master.htmlhttp://www.math.utah.edu/pub/bibnet/authors/t/turing-alan-mathison.htmlhttp://www.math.utah.edu/pub/bibnet/authors/b/babbage-charles.html
(change .html to .bib for a BibTeX file).
A Library of Congress search found another book, by Licklider himself:
Libraries of the future
xvii + 219 pp
Bolt, Beranek, and Newman, Inc., Cambridge, MA (1965)
LCCN: Z699 .L5
Given its age and small publisher, I suspect that it may be hard to
find; I have not seen it myself.
-------------------------------------------------------------------------------
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: beebe(a)math.utah.edu -
- 155 S 1400 E RM 233 beebe(a)acm.org beebe(a)computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------
I just saw this headline. Microsoft co-founder Paul Allen dead of cancer,
aged 65. Relevancy to TUHS as Microsoft has been both a competitor to and
supporter of both Unix and (much more recently) Linux.
Allen also funded the Living Computer Museum in Seattle, where one can log
into a real PDP-11/70 running 7th Edition Unix.
- Dan C.
Dan Cross:
Allen also funded the Living Computer Museum in Seattle, where one can log
into a real PDP-11/70 running 7th Edition Unix.
And see a real live PDP-7, and many other marvellous artifacts.
Their basic idea is to be a museum of history that runs. Well
worth a visit when in Seattle.
Norman Wilson
Toronto ON
> From: Norman Wilson
> Unfortunately all the quick hacks and poorly-considered tweaks of the
> past have long since been cast in stone by widespread convention
There seem to be two kind of people in the world; i) those who cannot bring
themselves to change anything, and ii) those who change all sort of things,
usually with no good reason (perhaps just to be different).
The world of Unix seems to be thickly stocked with both.
Noel
Dave Horsfall:
Before I started using /home (Slowaris had yet to appear), I used /u/*
instead (I didn't want to pollute /usr with home directories).
===
I'm late to the party, but I'll chime in too:
The first UNIX system I ever used, ca. 1980, had users' home
directories in /u. I suspect it was that way (as suggested
in some earlier messages) just for storage management: separate
file system from /usr.
I've carried /u around with me ever since to other systems
I've set up from scratch, except in my home environment
where I've made a radical departure: everything that isn't
part of the base OS is in a tree rooted at /con, so home
directories are /con/u. /con was `constant,' inspired
by /var, meaning stuff that should be preserved when the OS
is reinstalled--everything else should come from installation
media or configuration management.
But in any case there's nothing especially novel about moving
users' home directories out of /usr, and since it's UNIX,
nothing that says there has to be any standard at all. On
the systems I am currently paid to help run, most users have
home-directory names like /h/u12/c4/00/c4ntest. There is no
attempt to glue together a single name hierarchy; we have in
excess of 17000 users so that would be something of a mess.
(I guess enormous directories aren't the resource pigs they
used to be, though symlinks are just as bad as they have
ever been.) There's the ~user shell syntax for those who like
that; I don't, but I have a little shell script in my personal
bin directory so I can do things like ls `home c4ntest`; it all
just works.
I once thought of writing a paper entitled `/usr and /etc
considered harmful,' in which I would have proposed:
a. It no longer matters a whit whether the (real) root file
system can fit into a 5MB slice of the disk or the like, so
just merge everything that spilled into /usr in the tiny-disk
days back into the root where it belongs.
b. /etc is largely junk. Executables have long since moved
into /sbin. Pretty much everything else that's there belongs
(according to the original scheme, not the latter-day complications
inflicted by those who didn't understand) in /lib.
Unfortunately all the quick hacks and poorly-considered tweaks
of the past have long since been cast in stone by widespread
convention, so it's fruitless to try to clean any of this up.
Norman Wilson
Toronto ON
Leah Neukirchen:
I tried contacting David Tilbrook several times and got no replies.
I think some people around Toronto still use qed, but they seem to be
very secretive about it.
====
David is likely well-retired by now, but I don't really know.
Even though I walk within a block of his house fairly often,
we've never really been consistently in touch.
But he was responsible for a distinct branch of the qed that
originated at the University of Toronto in the late 1970s
(same one Rob supplied). Certainly worth tracking down.
I don't know your definitions of `people around Toronto' or
`secretive.' I still use qed daily; my copy is one I've been
carrying around, and occasionally tweaking, since my time at
Caltech (where I got it from Rob). I'll send Arnold a copy.
I'm really tired both of having to recompile it (and deal with
yet another bit of obsolete-C assumption that no previous
compiler or C library has shown up) now and then, and with
its private variant of regular expressions, so I keep threatening
(mainly to myself) to rewrite it in Python, but I have no idea
whether I'll ever get around to that. If I do I suspect I'll
throw away some of the programmability hooks, which I never use,
and perhaps extend it here and there (I really want nesting
globals, and they're not that hard to do--I did them in my
half-baked personal mail reader, which has an ed-like interface).
I don't know offhand of anyone else around Toronto using my
branch of qed. I do know of a couple of friends in California,
one who left Caltech before I did but is now back there, another
elsewhere in Los Angeles, who still use my version at least
occasionally. It wouldn't surprise me if there were people
around Toronto who use Tilbrook's branch, since it was part
of his qef toolkit and he introduced several companies to it
when consulting for them; but I don't know of any specifics.
None of which is as archaeologically interesting as the
non-UNIX qeds, of course.
Norman Wilson
Toronto ON
