HP3000-L Archives

March 1997, Week 3

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jeff Kell <[log in to unmask]>
Reply To:
Jeff Kell <[log in to unmask]>
Date:
Tue, 18 Mar 1997 22:05:47 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (68 lines)
Nick Demos wrote:
> Well, I guess its war story time.

Alright, if everyone else is going to participate, here's my $0.02:

> My introduction to the HP3000 came in 1977 with the Series II (I knew
> I could gray-hair you guys).

Mine was in 1976, but at the ripe old age of 17.  Had HP2000 in 1975.

> Our design involved making our hardware look to the 3000 like a 1000
> (the programmable controller).  "How many terminals are we talking
> about?" asked Bob.  "About 200" we said.  Bob literally took three
> steps back and said, "You want to do what?"?  Once he was over his
> shock, he put us in touch with the right HP lab people.  We were one
> of the first to create processes.

We were pressed by terminal limits on Series IIs.  Despite advise to the
contrary, we ended up with 64 terms on one Series II.  I devised a system
in '79 that replaced the JSMAIN/CI process tree - one batch job could
run a number of terminals.  Rather than the "process tree" approach of
MPE it did more of a Unix execv() call - separate process for login,
command selection, and applications with the "father" process handling
the transitions.  Our COBOL code was written around an in-house terminal
I/O package which was tweaked to talk to arbitrary files, not just
$stdin/$stdlist (this was before CIOR and stdin/list redirection).  If
any packrats have the 1981 Orlando user group proceedings, lookup my
paper on TERMNET.  Similarly, having these sessions under a common
process allowed us to do IPC before IPC was available using a shared
data segment to pass data between processes.  But I digress...

We have had our share of wonderful powerfail recoveries, including one
when a former Director leaned against the 3000 only to hit the emergency
off switch (local joke to CX, Series II, Series III owners) during a
tour for some politicos.  Have also had water intrusion, but in our case
the flow of water (from a blocked roof drain) was falling on the Topaz
3-phase isolation transformers feeding our systems.

More uniquely, we've had some miraculous recoveries -- cannibalizing
our "academic" system for parts to bring up our "administrative" 3000
during critical times (bulk registration).  I've swapped more disc
drives, memory boards, disc controllers, etc. in my 22 years than I
care to count (though it's not an option these days of integrated disc
drives).

To play devil's advocate, our worst problem with early 3000s was not the
issue of power, but surge protection on the terminal interface hardware.
We burned more than our share of ATC interfaces and boards before going
to home-grown surge protection (TranSorbs on the data lines); of course
the newer hardware has this built in (didn't use to be that way).  When
a thunderstorm approached, we could care less about the integrity of the
system, the priority was to unplug the connectors on the ATC panels
where the RS232 connectors came in.  We knew the system would live, but
our beyond-specification RS232 cable runs in the hundreds of feet tended
to attract static and RFI.

I suppose the strongest "success story" I can relate is that we are
still running code written 20 years ago.  In the COBOL case, everything
has been converted to native mode, but it's the same old code.  Things
that ran on the Series II still run today.

And replacing a huge machine room full of IBM gear with a 3-bay Series II
was pretty remarkable in and of itself :-)  This huge, room-sized CPU
(an IBM 360/30) with a breakneck cycle time of 1 microsecond, 64K of core
memory, and a teletype-ish console.  Remarkable indeed.

Jeff Kell <[log in to unmask]>

ATOM RSS1 RSS2