Hoping someone can help me here, as I've grepped the 'net to no avail.
Back when USENET was supreme and dinosaurs strode the earth, there was a
hilarious article involving a DEC box (long forgotten it) that was used to
instrument underground atomic tests. In one scene, the box was atop a
truck which was right over the hole; they both went skywards, but the data
was recovered by taking out the core memory boards and plugging them into
another box.
Does anyone remember it? It does sound rather suss...
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
> From: Don North
> Track 0 is not used by standard DEC software
I wonder why DEC did't use track 0. The thing is small enough (256KB in the
original single-density) that even 1% is a good chunk to throw away. Does
anyone know? (I had a look online, but couldn't turn anything up.)
If I had to _guess_, one possibility would be that track 0 is the innermost
track, where the media is moving the slowest, and as a result it's more
error-prone. Another is that IBM used track 0 for something special, and DEC
tried to conform with that. But those are pure guesses, I would love to know
for sure.
Noel
> From: Don North <north(a)alum.mit.edu>
> .. the hardware bootstrap reads track 1 sectors 1, 3, 5, 7
Ah, thanks for that. Starting to look at the code, I had missed the
interleave.
So does DEC do anything with track 0, or is it always just empty?
Noel
So, I'm winding up to boot Unix V6 from an RX02 floppy. So I need two things:
- Details of how DEC ROM bootstraps boot from RX02's. I vaguely recall seeing
documentation of this somewhere (e.g. which sectors it loads, etc), but now I
can't find it. Don North has dumps of the RX02 ROM's, but I'm too lazy to read
through the code and figure out how they work. Is there some documentation
which covers it? I did a quick Google search, but if there is anything out
there, my Google-fu was inadequate.
- Did anyone ever do an RX02 driver for the V6 disk bootstrap? (Well, I guess
a V7 driver would work, too.) Note: what I need is _not_ either i) the Unix OS
driver for the RX02 (I found one of those already), or ii) a driver for the v7
standalone second-stage bootstrap (which would probably be in C). The thing
I'm looking for would be called rx.s, or something like that. Yes, I could
write it, but again, I'm lazy! :-)
Noel
> From: Jacob Goense <dugo(a)xs4all.nl>
> There is the issue with the non-existing man command.
My page on "Bringing up V6 Unix on the Ersatz-11 PDP-11 Emulator" has a
section on man:
http://mercury.lcs.mit.edu/~jnc/tech/V6Unix.html#man
It's pretty straight-forward.
Noel
So, in a fit of brain-fade, I originally sent this to the Classic Computers
list, when it was probably really more appropriate for this one. (Apologies to
those who are subscribed to both, and are thus seeing this again.)
So, I'm trying to do what VTServer was invented for - load Unix into an actual
PDP-11, over its serial line, when one doesn't have machine-readable Unix on
any mass storage for the machine.
However, all the initial code that VTServer loads ('mkfs', etc) is V7-specific
(V6 has a slightly different file system format) - and I want to install V6.
Has anyone ever tweaked the programs which VTServer loads to do V6-format
filesystems? I did a quick Google, but didn't see anything.
Another option is to do something more V6-like, and copy a small bootable V6
file-system image over the serial line; that may be an easier way to go.
No biggie if not, it won't be much work to adapt things, but I figured I'd try
to avoid re-inventing the wheel...
Note that the installation procedures for V6 and V7 are wholly different,
something which confused a number of people on CCTalk.
The 'Setting up Unix' documents are more checklists, they don't go into a lot
of detail as to what is actually happening, so I have prepared two pages on the
Computer History wiki:
http://gunkies.org/wiki/Installing_UNIX_Sixth_Editionhttp://gunkies.org/wiki/Installing_UNIX_Seventh_Edition
which go into more detail on what is actually happening.
Noel
> I'll start with getting VTServer to run under V6 (my only Unix, don't
> have anything later :-)
So, I just got VTServer runnin under V6: it successfully loaded a memory
diagnostic from the 'server', into the 'client', using 'vtboot' on the
latter. (Both running on emulated machines, for the moment - I thought I'd
take all the hardware-related variables out of the equation, until I have the
software all running OK.)
It didn't require as much work on VTServer as I thought it might: I had to
convert the C to the V6 dialect (no '+=', etc), and some other small things
(e.g. convert the TTY setup code), but in general, it was pretty smooth and
painless.
Note that it won't run under vanilla V6, which does not provide 8-bit input
and output on serial lines. I had previously added 'LITIN' and 'LITOUT' modes
(8-bit input and output) to my V6; since the mode word in stty/gtty was
already full, I had to extend the device interface to support them. I didn't
add ioctl() or anything later, I did an upward-compatible extension to
stty/gtty. (I'm a real NIH guy. :-)
My only real problem in getting VTServer running was with LITIN; I did it
some while back, but had never actually tested it (I was only using LITOUT,
for my custom program to talk to PDP-11 consoles, which also did downloads,
so needed 8-bit output). So when I went to use it, it didn't work, and it was
a real stumper! But I did eventually figure out what the problem was (after
writing a custom program to reach into the kernel and dump the entire state
of a serial line), and get it working.
(I had taken the shortcut of not fully understanding how the kernel serial
line code worked, just tried to install point fixes. This turned out not to
work, because of a side-effect elsewhere in the code. Moral of the story: you
can't change the operation of a piece of software without complete
understanding of how it works...)
Is there any interest in all this? If so, I can put together a web page with
the V6-verion VTServer source, along with the modified V6 serial line stuff
(including a short description of the extended stty/gtty interface), etc.
> so if you turn up whatever you used to boot V6, it would probably still
> be useful.
So I guess my next step, if I don't hear shortly from someone who has
previously used VTServer to install V6, is to start on actually getting
a V6 file system created.
I'm still vacillating over whether it would be better to go V6-style (and
just transfer a complete, small existing V6 filesystem), or V7-style (and
get stand-alone 'mkfs', etc running with V6-format file systems). Anyone
have an opinion?
Noel
> From: Clem Cole
> I miss my AAA
Well, I'm not sure I actually _miss_ mine (my old eyes prefer black on white),
but I definitely have fond memories of it. It was such a huge thing when I
finally managed to snag one to replace my (IIRC) VT52.
You could actually have three useful windows in Emacs!! And the detached
keyboard was definitely more ergonomic.
Noel
Time to post this again; warning: you need to uderstand the obscure
references... I've actually worked in places like this.
-----
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 RA60's running a single application,
PC style, into a data center with two IBM 3090's 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 Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
_______________________________________________
Applix 1616 mailing list
Applix-L(a)object-craft.com.au
https://www.object-craft.com.au/cgi-bin/mailman/listinfo/applix-l
