Re: Just curious how many Hewlett-Packard Integral computers were sold. We have one here at the SMECC Museum that we are building a display around it for.

[Frank McConnell via cctalk]

On Jan 30, 2021, at 10:09, ED SHARPE via cctalk  wrote:
> Hi Doug! No, we do not have a copy of this HP JOURNAL.  We do not have 
> manuals  either.  We,are lucky to have the unit wonder if you can still order 
> ink for the printer. I do have an unopened ink cartrige.

HP 51604A.  I was surprised a few months ago to find that Staples claims to be 
able to sell new HP cartridges.  Looking earlier today, HP can too!

Seriously, we’re talking about ink cartridges including replacement print heads 
for printers manufactured in 1983.

-Frank McConnell

Re: HP 3000 series 30/33

[Frank McConnell via cctalk]

On Jan 16, 2021, at 10:07, grant via cctech wrote:
> 
> Working to restore a series 30 , looking for any spare boards ,cpu ,bic 
> boards from a series 30/33Just putting it out there ,long shot i 
> knowCheers,Grant Sent from my Galaxy

CPU is 30070-69003 (-60003)
BIC is 31000-69053 (-60053)
Firmware is 30070-69002 (-60002)
Maint interface is 30070-69013 (-60013)

p/ns from a CE parts list document dated Jan 1993

Interestingly there are p/ns for some of the ICs.

PSU 1AB2-6003
RASS 1AB3-6003
RALU 1AB4-6003
PHI 1AA6-6004

-Frank McConnell

Re: when was memory "above" the terminal screen invented?

[Frank McConnell via cctalk]

On Dec 13, 2020, at 18:37, Stan Sieler wrote:
> 
> Hi,
> 
> First, apologies if I asked this years ago (I've searched my archives, no
> hits :)
> 
> When was the concept of memory "above" the screen invented for terminals?
> 
> I.e., previously displayed data that had scrolled up and off the screen ...
> but could be retrieved (usually by scrolling down).

Printing terminals.  Just pull the printed paper up from where it has fallen
behind your Teletype or DECwriter or Silent 700 or Terminet.

> (Sometimes called "scrollback", or "offscreen memory".)
> 
> (BTW, I'm talking about terminal-local memory, not a scrollback implemented
> by the computer to which the terminal is connected.)
> 
> The HP 2640A, 1974, had (IIRC) several pages of memory available ... the
> user could scroll
> backwards and see what had been on the screen before it scrolled off (as
> long
> as it hadn't been lost by having too much subsequent output).

That was, kind of sort of, the on-screen effect, but it could vary.

Between 1977 and 1981 I used 2640B terminals which had been purchased
without many options.  They didn’t have lower case characters (these
were displayed as upper case characters, and sometimes hilarity ensued),
and they had about 1KB of display memory.

Now you may be thinking that 24 rows of 80 characters is more like 1920
characters which would require a little more than 1KB of display memory,
and you would be correct.

The tricky bit about the 264X display controller is that it is reading
display memory as a linked list of fixed-size short chunks (under 20
bytes) and the last one has an end-of-line indicator in it (it is an
ASCII terminal and byte values 0x80-0xff are interpreted as display
controls).  So a short line of text doesn’t take up as much display
memory.  Which means you can have more of them in display memory.

So your 2640B with 1KB display memory has scrollback if most lines that
you have in memory are short, but can only fill its screen halfway if
all lines are long.

> I suspect the DEV VT100, 1978, had it, but I can't find definitive proof
> online (sure, I can find VT102 emulators that have scrollback, but reading
> an old VT102 manual doesn't make it clear that it has it.)

I think the VT100 did not.  I’m not sure it matters.  The 2640A would
predate the VT100.

I wonder if the termcap da and/or db flags would turn up some older 
terminals with the same feature.  (These indicate display above and 
display below.)

-Frank McConnell

Re: Microsoft C 6.0 manuals

[Frank McConnell via cctalk]

On Oct 7, 2020, at 8:29, Chuck Guzis via cctalk wrote:
> 
> On 10/7/20 7:23 AM, Tomas By via cctalk wrote:
>> On Wed, 07 Oct 2020 16:18:15 +0200,  wrote:
>>> Would then not be on MSDN cds from around that time?
>> 
>> 
>> I don't think so. I did spend some effort to locate on of those that I
>> had some reference to, but it turned out to be nothing. (And I have
>> checked at least ten MSDN CDs for this material.)
> 
> I don't know if I hung onto the MSC 6.0 manuals, but am looking at what
> amounts to a sizeable portion of a bookshelf that deals with 7.0.
> That's a lot of paper.  Just the "Comprehensive Index and Errors" book
> looks to be somewhere around 400-500 pages.
> 
> I don't believe that MSC was part of MSDN back then.  At least I don't
> recall seeing it on my CD collection, although ISTR that there were
> services packs for it there.

My recollection is that MS Visual C 1.0 came with a big box of paper manuals.
MS Visual C 1.5 was the first one where you had to take it on CD-ROM.  At the
time (early 1994) MSDN was a serial with approximately quarterly single
CD-ROM issues whose content varied.  This was all in the Time Before PDF so
proprietary reading/searching software was involved.  

-Frank McConnell

Re: Exploring early GUIs

[Frank McConnell via cctalk]

On Sep 17, 2020, at 19:18, Michael Kerpan wrote:
> Something in another recent thread about LISP machines got me wondering:
> how many early graphical systems are well emulated (or emulated at all)? I
> know that there are more or less functional emulations of Alto, Star, and
> Lisa out there, but what about the various LISP machines or the early
> workstations (Sun 68K, Apollo, etc) Also, assuming that there are emulators
> for some of these systems out there, has any software to run on them and
> been archived?

Something in the "early graphical" space that I think may be difficult or 
impossible to emulate: the Culler-Fried Online System.  I think it was built 
around an IBM 360 and operated at one site (UCSB) late 1960s into 1970s with 
the goal of running a particular educational/research application programming 
environment, CHM has one of the dual keyboards, and I am not at all certain 
that software exists.  Not so early to timesharing (late 1960s) but using 
storage scopes for graphical output terminals.

Al has a couple manuals in .  
So we can get some idea of what it was like.

-Frank McConnell

Re: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany

[Frank McConnell via cctalk]

On Sep 16, 2020, at 13:21, J. David Bryan via cctalk wrote:
> 
> On Wednesday, September 16, 2020 at 8:19, Lee Courtney via cctech wrote:
> 
>> Al - it would be a Very Good Thing to get those APL ROMS dumped when
>> possible.
> 
> It would be good as well to dump the Series III main instruction set ROMs, 
> assuming they're socketed.  Bitsavers has a Series II microcode listing, 
> and there are some notes available on the microcode changes from the II to 
> the III, but there is no existing Series III listing.

It is my belief that the Series II microcode listing was a part of the standard 
manual set that you got with an HP 3000 Series II.  We had one at the high 
school (where the 3000 started out as a Series II and was upgraded in its 
chassis to a Series III).  Also that the Series III’s microcode listing was not 
part of the Series III’s standard manual set.  We didn’t get an update for it 
at the high school either.

-Frank McConnell

Re: Notes on HP3000 WCS Microcode, Series 37 on ebay in Germany

[Frank McConnell via cctalk]

On Sep 16, 2020, at 5:30, Rodney Brown via cctalk wrote:
> 
> HP 3000 Series 37 on ebay in Germany (7954A, 9144AR, 30457A, 700/92 (German 
> keyboard))
> 
> https://www.ebay.com.au/itm/HP-3000-Series-37-Computer-System-RETRO-SELTEN-RARE-ca-1985-1987/283988656899
> 
> Thanks to David Collins at the HP Computer Museum, I now have 11 different 
> versions of the HP 3000 Series 64 [,68,70] microcode SYSWCS64.PUB.SYS
> and 3 different versions respectively of each of SYSWCS37 and WCSLE1 and 
> WCSLE2.
> I've put notes up at 
> https://en.wikipedia.org/wiki/User:RDBrown/HP3000-WCS-Microcode

SYSWCS37 is for a Series 37 (and probably 37XE too which is the 
expanded-chassis model, the XE is mostly the SIMB expander).  I think WCSLE1 is 
for a "Micro 3000 XE” (and probably also “Micro 3000” which I think was same 
thing in a single chassis; faster than Series 37) and WCSLE2 is for the Micro 
GX/LX/RX (repackaging with CPU, RAM, PIC/GIC on one card) but may be wrong 
about that.  I know I have seen documentation of this, and recently.  Ah!  HP 
Channels, Dec 1986, probably from the HP Computer Museum site.

> It's possible that one of the SYSWCS64 files may match the assembly listing 
> on bitsavers, but that listing could allow guessing the architecture, 
> assuming horizontal microcode and matching against the HP 3000 stack machine 
> instruction set it implements.

There is a Series 64 Reference/Training Manual PDF on bitsavers, that will shed 
some light on the architecture.  It’s fancy: ECL, dual ALUs (driven by wider 
microcode word), central system bus bridged to up to three IMB-style I/O buses 
(room in the architecture for a fourth I think), memory cache.  Writable 
control store too (this was not usual for the 3000 product line).  In 
retrospect it looks like they threw everything they had at making a 3000 that 
would go kinda sorta fast and count have a lot of I/O devices (mostly GICs and 
ATPs) connected.  The ATP was another Series 64 innovation, which was also made 
to fit on the Series 37 as the TIC and later Micro 3000s as the ATP/M; I think 
it had a dedicated 6809-like processor for each port’s data transmission needs 
and another 6809-like processor for every several ports’ flow and modem control 
lines, and I think most of what it did was put something between the terminal 
and the 3000 that didn’t need to interrupt the 3000 until there was enough 
received data to actually complete a read request or initiate a break.



I am thinking the “Series 68” upgrade was new front panel plastic and a tape 
with a new microcode file that implemented changes enabling system table 
expansions for MPE V/E.  “Series 70” was similar (some frequently used MPE 
routines were implemented as microcode) but also included hardware changes 
(memory cache increased from 8K to 128K).

> Only the Series 37 rates a mention in the HP Journal, though the common data 
> between the SYSWCS37, WCSLE1 and WCSLE2 suggests they may share a common 
> microcode. Guessing the architecture would be more of a puzzle, unless more 
> documentation is found.

Yes.  Not very well documented but clearly from the same family, they all use 
the “Synchronous IMB” or SIMB bus.  One interesting note from one of the HPJ 
articles is that the console interface that runs at power-up (before microcode 
is loaded from disc/tape) is not a separate microprocessor like it is on series 
64/68/70 (and I think 4x/5x), it is a microprogram from a 16-bit-wide ROM that 
drives only 16 of the microinstruction word bits.

> J. David Bryan's SIMH work gives a running MPE V for anyone to try.

Microcoded in C!  Note that as it simulates a Series III at present, the MPE is 
MPE V/R, which is really a roll-up of MPE IV for the Series II/III.  MPE V/P 
had disc caching, MPE V/E had expanded system tables and got updates for a 
while.

MPE V/E T-MIT was the first release supporting “Mighty Mouse” (Series 37).  
BUT, one of the special Series 37 instructions is one to tell the microcode 
whether MPE V/P or MPE V/E is being run!  I’m sure development started before 
the release of MPE V/E and this came in handy for that.

-Frank McConnell

Re: Dilithium Press (Computer Books)

[Frank McConnell via cctalk]

On Jul 14, 2020, at 10:21, Vincent Slyngstad via cctalk wrote:
> 
> On 7/14/2020 6:53 AM, Zane Healy via cctalk wrote:
> > Out of curiosity, does anyone know anything about this publisher? They 
> > apparently existed in the late 70’s and early 80’s.  They were apparently 
> > located in Beaverton, Oregon in the same business park, on Nimbus, where 
> > Norvac Electronics was.  They obviously published some very strange 
> > computer books, including what looks to be a teen romance. I find myself 
> > with an embarrassingly nice little collection of the books, that my Dad 
> > apparently had.  Considering I think he touched a computer twice in his 
> > life, they’re something of a mystery.
> >
> > Best title, “Nailing Jelly to a Tree”, which is apparently a book on 
> > Software.
> >
> > The publisher sounds vaguely familiar, and I think I might have one or two 
> > other books from them in my collection.
> 
> Cool question!  I remember them as a publisher of computer books back in the 
> day.  Never realized they were local (I live about a block from there now!).

Y'all may want to take an hour to listen to this.  I haven’t.  The text at 
least names someone as co-founder.

https://ataripodcast.libsyn.com/antic-interview-293-merl-miller-dilithium-press

-Frank McConnell

Re: Location of ARPANET Protocol Handbook or its successor, online

[Frank McConnell via cctalk]

On Jul 2, 2020, at 19:49, Will Senn via cctalk wrote:
> 
> On 7/2/20 9:38 PM, Frank McConnell via cctalk wrote:
>> On Jul 2, 2020, at 18:55, s shumaker via cctalk wrote:
>>> NTRL has 3 published versions listed with two available as pdf downloads;
>>> 
>>> go here and search on the author name
>>> 
>>> https://ntrl.ntis.gov/NTRL/
>>> 
>>>  Steve
>> Searching on author Feinler confirmed my recollection of a successor 
>> document, the “DDN Protocol Handbook” in three volumes.  (Volume 1 available 
>> as PDF from this source.)  These collect RFCs and other documents, often 
>> with MIL-STD numbers.  Not entirely replaceable from the IETF’s RFC filepile.
>> 
>> -Frank McConnell
>> 
> Frank,
> 
> Great find. Thanks!

The one you are looking for describes the NCP-era ARPANET.  The “DDN Protocol 
Handbook” describes the IP/TCP-era DDN.

-Frank McConnell

Re: Location of ARPANET Protocol Handbook or its successor, online

[Frank McConnell via cctalk]

On Jul 2, 2020, at 18:55, s shumaker via cctalk wrote:
> NTRL has 3 published versions listed with two available as pdf downloads;
> 
> go here and search on the author name
> 
> https://ntrl.ntis.gov/NTRL/
> 
>  Steve

Searching on author Feinler confirmed my recollection of a successor document, 
the “DDN Protocol Handbook” in three volumes.  (Volume 1 available as PDF from 
this source.)  These collect RFCs and other documents, often with MIL-STD 
numbers.  Not entirely replaceable from the IETF’s RFC filepile.

-Frank McConnell

Re: Future of cctalk/cctech

[Frank McConnell via cctalk]

On Jun 16, 2020, at 23:27, Christian Corti via cctalk  wrote:
> 
> On Wed, 17 Jun 2020, Doug Jackson wrote:
>> We could consider moving to Google groups hosting.
> 
> No... no no no no no. Never.
> Either become a (real) NNTP group or stay as a mailman list.

Oh good, here comes the discussion of which protocol stack this bikeshed should 
run.

(You can get INN to work with uucp!)

-Frank McConnell

Re: Scanning incomplete and updated documents

[Frank McConnell via cctalk]

On Apr 17, 2020, at 9:02, Alan Perry via cctalk wrote:
> As I noted, the two sets of appendices are mostly completely different. There 
> are 9 appendices that look like they are from the primary document and 5 that 
> look like they are from inserted pages. Both sets start numbering from "A". 
> There is one title shared between the two sets.
> 
> But the really interesting thing is that the copyright date on the "primary" 
> document is AFTER the date in the footers of the "inserted" pages.

Do not underestimate the powers of humans to make errors when creating or 
applying updates.

> FYI - the document is Computervision CADDStation System Software Installation.
> 
> So, any recommendations on what I should do?
> 
> Also, any recommendations on a software tool to slice and dice PDFs that is 
> inexpensive?

Depends what you want to do.  On a Mac, I use Preview which is the default PDF 
viewer; it allows me to cut, copy and paste scanned pages from one PDF to 
another.

I also do some things with Perl and CAM::PDF which makes writing filter-like 
programs that do page-level operations fairly easy, e.g. I have one that 
deletes the odd-numbered pages from a stdin-supplied PDF and writes the 
resulting PDF to stdout and I think it’s about 12 lines total.  Anyone care to 
guess what my use case for this is?

-Frank McConnell

Re: Scanning incomplete and updated documents

[Frank McConnell via cctalk]

On Apr 16, 2020, at 21:32, J. David Bryan via cctech wrote:
> 
> On Thursday, April 16, 2020 at 8:52, Alan Perry via cctech wrote:
> 
>> 1. One document is a software installation manual in a loose leaf
>> binder with other documents. It has a title page, tables of contents,
>> etc., several chapters, and then it gets interesting. It has several
>> appendix sections (starting at A), an index, then more appendix
>> sections (starting at A as well), and then another index. The document
>> title and its font match of the second set of appendix sections and
>> second index matches the table of contents and chapters. 
> 
> I've scanned roughly 450 manuals.  What you describe might be the result of 
> a manual update.  Some updates include replacement pages, with the intent 
> that the replaced pages are discarded.  I've encountered manuals, though, 
> where both the old and new pages were kept, perhaps to retain a record of 
> the changes.

TRVTH.  I used to do exactly this when HP sent updates.  I put replaced
pages at the back of the manual, and usually did not refer to them thereafter.
When the binder filled up, that’s when I might consider discarding them.

HP had the habit of printing the update date and sometimes update number near
the bottom of the updated pages.

>> Should I create two different pdfs with different appendix sections or 
>> create a single pdf with both sets?
> 
> Where both old and new pages were present, and where they could be 
> differentiated clearly, I made a separate PDF for each manual printing.  
> That is, I'd have two PDFs with the same part number with different print 
> dates -- one containing the old (original) pages, and the other containing 
> the new (replacement) pages.  See, for example:

Sometimes I have come across shrink-wrapped manuals and later updates, and
scanned them as found.  I wouldn’t want to deny other people the opportunity
to apply updates to manuals, you know?

-Frank McConnell

Re: Scanning incomplete and updated documents

[Frank McConnell via cctalk]

On Apr 16, 2020, at 23:37, J. David Bryan wrote:
> On Thursday, April 16, 2020 at 23:18, Frank McConnell wrote:
> 
>> Sometimes I have come across shrink-wrapped manuals and later updates,
>> and scanned them as found.  I wouldn´t want to deny other people the
>> opportunity to apply updates to manuals, you know?
> 
> Oh yes, especially the ones that would say, "Insert the six paragraphs
> below between the third and fourth lines of page 23."  :-)

The folks who did the 3000 manuals didn’t do that very often.  What we
got were almost always update packets that simply replaced pages in their
manuals.  Once I think I remember getting a sticker to be stuck over the
replaced text on a page.

> I used to despise HP when they would send updates that consisted of
> instructions to modify existing manual pages instead of sending replacement
> pages.  I recall one update, maybe for the HP 64000 logic station mainframe
> service manual, that instructed me to change a dozen or so schematics --
> simple things, like "replace feedback resistor R23 with the active filter
> circuit shown below."  That one got stuck in the front of the outdated
> manual, as I just couldn't bring myself to butcher the pages as they
> required
> 
> When it came to manual updates, the Logic Systems Division was aptly named.

The 3000 folks I think had to make some effort to get beyond paste-up
to where they were doing their manuals and updates in something, and it didn’t
happen until the not-so-early 1980s.  Sometimes I thought the thing was
TDP/3000 and the camera-ready copy came out of a 2680A or 2688A printer.  I
don’t really know how they got there or how it worked, and by the end of the
1980s I think they had moved away from TDP/3000 to something else.

-Frank McConnell

Re: HPE OpenVMS Hobbyist license program is closing

[Frank McConnell via cctalk]

On Mar 11, 2020, at 8:08, Al Kossow via cctalk wrote (after Ethan O'Toole
I think):
>> Years ago us SGI hobbyists were able to talk to SGI about this and a huge 
>> problem SGI had with any kind of hobbyist
>> license for IRIX or turning it free is it's fully of licensed 3rd party 
>> stuff. But maybe now that's it's expired, or all
>> the companies things were licensed from are gone.
> 
> Release of Classic HP3000 died for the same reason from the same company.

And yet, classic-3000 MPE (V/R, V/P, V/E) does not involve licensed third
party stuff.  At least I think it does not, I think the OS is uniquely
developed by HP(E).

MPE/iX does, I know I’ve been told that it includes a Streams
implementation from Mentat which I understand was licensed on a
per-copy royalty basis.  That makes a zero-price license (even more of)
a money-losing proposition.  

It also makes release of classic-3000 MPE dangerous in that people may
assume that the release applies to MPE/iX as well, and that could leave
HP liable for additional per-copy royalties in future.

I think MPE/iX is not quite like OpenVMS in that there is no per-installation
authorization key for the OS.  The OS does check a machine ID in "stable
storage" that is expected to indicate that the machine is an HP3000 (as
opposed to an HP9000), and there are some other features that I believe
indicate the class of HP3000 and I think MPE/iX and add-on software may
check this for other purposes too.  

Which means that if the companies and people who are due per-copy royalties
get the idea that they can goose that revenue stream through legal threats,
HP(E) maybe can't provide a very good guesstimate of how many additional
copies (for which royalties have not been paid) are out there.  There might
be some arguments made that the payment should be based on manufacturing 
counts of PA-RISC HP3000s and HP9000s.  It could get expensive.

Well, that's my guess of why then-HP didn't want to go there, and I don't
think HPE today would think any differently.  There may yet be a revenue
stream from MPE/iX licenses as its paying users upgrade to newer hardware
and the Stromasys emulator.

> HP has no motivation to spend time/money to release this. Also, the only way 
> CHM
> was able to release what we did (HP1000, 68K 9000 and Apollo) was having
> us release it only for non-commercial research/hobby purposes.

That was well done.  I just wish y'all had got FOCUS 9000 included in that.
Earlier than 68K and maybe HP didn’t have the bits any more but I think
some folks have some bits.  May be AT but no more so than the
68K 9000 bits.

-Frank McConnell

Re: HP 9000 Series 360 Thin LAN

[Frank McConnell via cctalk]

On Feb 21, 2020, at 10:19, Roger Addy via cctech wrote:
> I am using an HP 9000 Series 360 with a "Thin LAN" coax card to run a piece 
> of equipment. The LAN connection is not currently being used.  I'm wondering 
> if it's possible to connect it to a modern ethernet network?  If so, what 
> could I do with it? I found an adapter on Amazon. I would like to be able to 
> transfer files and possibly print.  The file systems are not compatible 
> except for maybe ASCII files.  Anyone have any thoughts?  Even if I could 
> transfer files into another HP 9000 system it would be beneficial.

It's classic 10Mb/s 10BASE2 Ethernet over RG-58A/U.  You can use a repeater to 
bridge to 10BaseT twisted-pair Ethernet or 10BASE5 "thick" Ethernet.  It is 
also easily (if non-standardly) adaptable to 10BASE5 "thick" Ethernet with a 
passive BNC to N barrel adapter on short segments of each, the on-the-wire 
modulation is close enough to work.

-Frank McConnell

Re: Larry Tesler - Computer Pioneer

[Frank McConnell via cctalk]

On Feb 20, 2020, at 20:52, Al Kossow via cctalk wrote
(after Murray McCullough):
>> Heard of death today of Larry Tesler
> 
> Does ANYONE bother to read the list before posting?

Am thinking of LISTSERV, which includes a SET NOMAIL option 
to save one the trouble.  Wonder if you can do that with
Mailman?  (Looks.)  Yup.

-Frank McConnell

Re: HPIB HDA low-level format?

[Frank McConnell via cctalk]

On Dec 29, 2019, at 17:59, r.stricklin via cctalk wrote:
> Is there a way to get an HP-IB disk unit with an ST412 or ESDI type HDA 
> inside to perform a low-level format?
> 
> I think this is what 'mediainit' is maybe supposed to do (based on being able 
> to change the interleave) but I don't see any way to map bad blocks (etc.) 
> using it. The -r 'recertify' option is apparently only valid for tape.
> 
> I have a 7946A with a Vertex V170 that needs some new blocks marked bad. 
> There's nothing on it I need to keep, but if I use 'mediainit' on it, it 
> fails pretty quick with an I/O error. From the sounds it makes, it's hitting 
> the first defect (at block 64) and giving up.

Once upon a time, I had pretty much this same problem.  
This on an HP 9000/320 with HP-UX 7.05, and a 7946
with a Vertex V170.  Copy-pasta below from an e-mail
that I wrote about it back in 1992:

(begin copy-pasta)

I think I've fixed my dead 7946 disk drive!  I sent away for the 7946
service manual (it's p/n 07940-90903 if you're interested; $20+s/h for
us non-HP-employees), and did a strings `which mediainit`.  This
"research" led me to the following incantation (comments in square
brackets are mine):

# mediainit -vGD /dev/rdsk/2s0[ G == guru mode  D == debugging mode ]
WARNING:  You have invoked guru mode, a mode requiring  extensive device
command  set  knowledge  in order to  properly  respond to prompts  that
follow, and from which you could seriously  compromise  device integrity
by responding improperly.  Are you SURE you want to proceed? (y/n) y
mediainit: initialization process starting
mediainit: locking the volume
mediainit: performing a describe command
mediainit: interleave factor 1 chosen
suppress running diagnostic? (y/n) y
   [ if you run the diagnostic it will fail ]
initialize options? (defaults to 0) 2
   [ 0 == normal initialization, keep spares, etc ]
   [ 1 == retain factory spares only (forget field spares) ]
   [ 2 == completely reinitialize the HDA, forget all spares, etc ]
volume ert passes? (defaults to 2) 2
   [ this is recommended in the service manual ]
clear logs option? (defaults to 1) 1
   [ probably a good idea - the "drive logs" are gibberish if you've
 used the drive on a PC ]
sparing mode byte? (defaults to 1) 1
   [ I don't know what this means, but I took the default ]
mediainit: initializing media
mediainit: pre-setting drive
mediainit: clearing logs
mediainit: running a 2 pass volume error rate test
mediainit: reading error rate test log for head 0
mediainit: testing suspect sector 4 on head 0, cylinder 576
mediainit: sparing sector 4 on head 0, cylinder 576
mediainit: re-testing entire track on head 0, cylinder 576
mediainit: reading error rate test log for head 1
mediainit: reading error rate test log for head 2
mediainit: reading error rate test log for head 3
mediainit: reading error rate test log for head 4
mediainit: reading error rate test log for head 5
mediainit: reading error rate test log for head 6
mediainit: reading run time log for head 0
mediainit: reading run time log for head 1
mediainit: reading run time log for head 2
mediainit: reading run time log for head 3
mediainit: reading run time log for head 4
mediainit: reading run time log for head 5
mediainit: reading run time log for head 6
mediainit: initialization process completed
#

... it may be a good idea to spare some of the other things (like the
hard errors listed on the top of the drive), but I don't know how to
turn bytes-from-index numbers back into CS/80 sectors.  You may be
able to turn them up as errors by running more ERT passes.  I should 
probably put the drive on a 3000 and look at the spared-sector lists
with CS80UTIL.

As they say, "your mileage may vary."  But my drive now powers up 
without a flashing red error light; sooner or later I'll newfs it and
play with it.  

(end copy-pasta)

-Frank McConnell

Re: 3270 controller simulation

[Frank McConnell via cctalk]

On Nov 18, 2019, at 16:42, Al Kossow via wrote:
> On 11/18/19 4:37 PM, Al Kossow via cctalk wrote:
>> 
>> 
>> On 11/18/19 3:15 PM, Chris Zach via cctalk wrote:
>>> I have some old boards and documentation for Unibus cards that would talk 
>>> X.25, BISYNC and I think SNA. Any value?
>> 
>> yes, it would be good to get this archived on bitsavers
>> should talk to ethan about his stuff as well
> 
> I find it interesting that the field of comms interoperability with IBM 
> mainframes was huge up until TCP/IP
> took over, and all traces of the software implementations have disappeared or 
> were consolidated into a couple
> like Micro Focus.

Many of the TCP/IP companies have disappeared/consolidated into Micro Focus 
too, even the ones who moved up the stack toward network clients and servers.  
Pretty impressive for a company who used to be known for PC-hosted COBOL 
compilers.

Micro Focus acquired Attachmate WRQ who comprised Attachmate who had previously 
acquired The Wollongong Group (TCP/IP stacks and applications for 
MS-DOS/Windows PCs, among other things) and WRQ who had been in the terminal 
emulation business since the 1980s (first product PC2622 emulated an HP 2622 
terminal).  Micro Focus also had previously acquired NetManage (TCP/IP stacks 
and applications for Windows PCs) who had previously acquired Wall Data (5250 
emulator, maybe 3270 too) and FTP Software (TCP/IP stacks and applications for 
MS-DOS/Windows PCs).  I’m thinking Novell who acquired Excelan (TCP/IP 
coprocessor hardware/software) is also somewhere in there via Attachmate WRQ.

I mean, really, who’s left?  Distinct?  (Though they seemed aimed more at 
protocol libraries licensable to developers, now they seem to be in the 
TN3270/TN5250/VT420 for Windows business.)  Beame & Whiteside got et by 
Hummingbird who I guess are now somewhere in OpenText.

-Frank McConnell

Re: Question about modems

[Frank McConnell via cctalk]

On Nov 13, 2019, at 10:41, Nigel Johnson wrote:
> 
> 
> On 13/11/2019 13:36, Chuck Guzis via cctalk wrote:
>> There are other "oddball" combinations, such as 8E1 and 8O1, which sends
>> a 9-bit data frame.  You can see datasheets on some UARTs as well as MCU
>> UARTs that support the 9 bit packet.
> According to the diagram of the Smartmodem there is no UART, the 1488s and 
> 1489s go directly to the Z80.

Somebody has to do speed and word format sensing, to pull off something
like the Smartmodem.

Hayes Technical Reference pointed at earlier has a table of supported 
data word formats in section A.1.1, page A-2.

Start bits, data bits, parity, stop bits
1, 7, even/odd, 1 or more
1, 7, none, 2
1, 7, mark/space, 1 or more
1, 8, none, 1 or more

That’s all!

-Frank McConnell

Re: Question about modems

[Frank McConnell via cctalk]

On Nov 13, 2019, at 6:40, allison wrote:
> 
> On 11/13/19 9:17 AM, geneb via cctalk wrote:
>> On Wed, 13 Nov 2019, Jim Brain via cctalk wrote:
>> 
>>> Did Hayes modem really do that?  I thought most later modems self
>>> detected parity and speed and thus would have switched both the comm
>>> on the serial port and the data sent to the other side in the same
>>> parity (if the terminal was 7E1, the modem would configure as 7E1 and
>>> send 7 bit data to the other side.
> 
> No, well maybe a few of the winmodems did.
> 
> Generally all the modems I have (ISA,S100 and external serial) you need
> to set the baud rate, parity and word length to match the modem (is it
> has at or similar protocal) and also to match the other end (usualy the
> same).

I remember old dumb modems that just turned 1s and 0s into different 
frequencies on the audio channel.  Think Bell 103 here, and acoustically
coupled modems where your fingers do the dialing.  No concept of parity
in the modem, it was just another bit passed through.

Anyway, maybe this is an authoritative reference:

http://bitsavers.org/pdf/hayes/Hayes_44-012_Technical_Reference_For_Hayes_Modem_Users_1993.pdf

Section 1.4, page 1-53 (PDF page 64 of 160):

(begin copy-pasta)

Modem commands begin with an AT prefix that gets the modem's attention.
The speed and character format at which the DTE sends this prefix tells the
modem the speed and format for responding to commands, and at which
speed to attempt the connection.

(end copy-pasta)

Similar language in the July 1991 version of the manual (also on bitsavers
in that directory).

-Frank McConnell

Re: HP vintage boards being sold as scrap - WON

[Frank McConnell via cctalk]

On Sep 29, 2019, at 19:32, Guy Dunphy via cctalk  wrote:
> 
> At 10:03 PM 27/09/2019 -0500, JRJ wrote:
>> Thanks for the tip.  (Part of not recognizing that is that I had never
>> made the connection between the 2108B/2112B and the "1000" series
>> before, until I read about it in this thread, and did some poking
>> around.  The HP's have not been one of my priorities in over a couple of
>> decades, and most of of that focus was on my older HP2114B.)
>> 
>> JRJ
> 
> That's always mystified me too. "1000 series" for model numbers like 2108B, 
> 2112B, 2113E, etc.
> Weird corporate thinking. Maybe too much printed material with "1000" on to 
> change?
> Or some other company had trademarked "2000 series” ?

“2000” was occupied by the timeshared BASIC system product line.

-Frank McConnell

Re: HP3000/917LX available in Vacaville

[Frank McConnell via cctalk]

On Sep 29, 2019, at 7:48, David Collins wrote:
> “3000-L” ?  Is that another group?

Different from this one.  hp300...@raven.utc.edu, emphasis on the “3000-L” part.

LISTSERV Web page with desciption and archives at 
.  Has been around longer 
than the archives show, I think I’ve been subscribed from one address or 
another since the early 1990s.

-Frank McConnell

Re: phone systems, old and less-old

[Frank McConnell via cctalk]

On Sep 18, 2019, at 11:32, jwest--- via cctalk wrote:
> 
> I know some peeps here are phone pholks…..See www.ezwind.net/phonestuff 
>  
> 
> 
> 
> One is an old “bell system western electric”. It seems to have a few 66 
> blocks just under the cover, a power supply, and some kind of modules that 
> plug in.

I think you might have a 1A2 key system there (this based on the 400Ds up top). 
 Kind of want but do not need.  I see other (and closer) interest has been 
expressed and that is good.

> The other is a Nortel Networks ICS. It feels way too light, not sure if 
> anything is in it. There is another piece of Nortel gear on the wall, seems 
> to be some kind of wireless? thingy called Nortel Networks Call Pilot 100.

That is why you want the 1A2.  It looks substantial hanging on the wall with 
those 25-pair cables to the key sets.  It feels substantial while you’re 
working to get it hung on the wall.  And it whirs and clicks in ways that the 
fully electronic key systems and PBXs don’t.  

-Frank McConnell

Re: I'm sharing a toy

[Frank McConnell via cctalk]

On Aug 8, 2019, at 16:52, Zane Healy wrote:
> 
> On Aug 8, 2019, at 4:29 PM, Frank McConnell via cctalk 
>  wrote:
>> One of the things I have found with the Pi is, the low end micro SD cards 
>> (P*tr**t and K*ngst*n would match the ones that did this) are lossy storage. 
>>  It’s not that they wear out, it’s that they lose bits.  Switching power 
>> supply to one sufficient for the Pi did not solve this problem, they 
>> continued to lose bits.
>> 
>> -Frank McConnell
> 
> With my RPi2B, my wife tripped a breaker, and scrambled the card.  That was a 
> Lexar SD card.  Of course that was also one of the critical systems in my VMS 
> Cluster.  I’ve moved to VM’s, on my VMware cluster, for all my OpenVMS 
> systems.  My one Rpi3B runs Multics, the other TOPS-20.  I’m thinking about 
> rebuilding the RPi2B as a PDP-11.

No interruptions of power to running systems, just cards left idle after 
shutdown -P for some days/weeks/months while I worked on others.

At first I was running from a weak (5V 1A) power supply and thought that cute 
lightning-bolt icon on-screen was its way of indicating that it was writing to 
its flash storage.  I switched to a recommended power supply that met the 
stated requirements and still had data loss in further experiments with 
(freshly re-installed and left idle) cards that had lost bits previously.

-Frank McConnell

Re: I'm sharing a toy

[Frank McConnell via cctalk]

On Aug 7, 2019, at 22:18, Adam Thornton wrote:
> 
> https://mvsevm.fsf.net
> 
> Currently, the TOPS-10 guest account (42,42) and the Unix v7 account dmr have 
> no passwords.
> 
> Please treat the dmr account respectfully.
> 
> I will get to account requests…eventually, probably.  TImeliness is not 
> guaranteed.  All systems are hosted on Raspberry Pis (the 36-bit ones on a Pi 
> 3B+ and the 16-bit and 32-bit ones on a Pi 2B+) on Debian Buster.  Absolutely 
> no guarantee of availability or usability is made.

Thanks.  I had a brief look around the 36-bit systems last night.  

One of my tests for a Pi 3 B was to build and run the SIMH HP3000 on it.  Being 
able to do that means having git to get the SIMH source, gcc and gmake to 
build, (curl|wget) to get the MPE V/R bits, unzip to extract.  The 
prerequisites were what I wanted for other Pi stuff and this was a good 
workflow to find out what was missing from the Jessie Lite image (yes it was 
that long ago, in Stretch and Buster I think I have found all those packages 
are already present).

One of the things I have found with the Pi is, the low end micro SD cards 
(P*tr**t and K*ngst*n would match the ones that did this) are lossy storage.  
It’s not that they wear out, it’s that they lose bits.  Switching power supply 
to one sufficient for the Pi did not solve this problem, they continued to lose 
bits.

-Frank McConnell

Re: Scanning question

[Frank McConnell via cctalk]

On Jul 18, 2019, at 14:50, Warner Losh via cctalk  wrote:
> So, I have a bunch of old DEC Rainbow docs that aren't online. I also have
> a snapscan scanner that I use for bills and such.

I do this kind of thing, with a ScanSnap S1500M (M means Mac), 
but mostly don't mind that the process is destructive to the 
books.  Really, the only things that survive this process are
the things that start out looseleaf, and as I’m trying to get
some silverfish food out of my life, most of them get recycled
too.

Really there is a ScanSnap for the text block and a flatbed for
the covers.  I scan covers and/or dust jackets first, on the
flatbed, usually 300dpi color.  Sometimes front cover with spine
if I think the design is interesting.

Books come apart.  Yes, glue bound books get crumbly bindings
after 30 years or so and come apart easily.  Newer glue bound
books come apart less easily because the binding is still gummy
and gooey.  You will still want a paper cutter or shear to clean
up the gutter by about 1/8 inch (would perhaps use 4mm if my paper
cutter had a metric scale) and make its edge less ragged and less 
gooey.

The ScanSnap wants to scan a bunch of sheets/pages and make a PDF
for you.  It can do an automatic post-scan OCR if you let it, and
that works well for account statements and other short documents.  
Its OCR (which I think is a version of AABBY that Fujitsu/PFUCA
licensed for use with the ScanSnap software) is not real good
at recognizing multiple columns or tables, it gets the characters
but not the layout.

The ScanSnap can also try to figure out whether a page image should
be scanned as black-and-white, as grayscale, or as color.  There
are ways to control this if you’re not happy with its choices 
through defining scanning profiles that influence and limit its
choices.  So I scan black-and-white text as 400dpi or 600dpi (judgment
call).  You may find you want to scan one book piecewise so you
can use black-and-white for the text-only parts and grayscale or 
color for the photo plates.

http://bitsavers.org/pdf/hp/portablePlus/45559-90001_Portable_PLUS_Technical_Reference_Manual_Aug1985.pdf

is an example of one (a looseleaf manual) that I did with a
ScanSnap, and I think I did it all in black-and-white at 400dpi.
You can see the holes punched for the three-ring binder.  
Al would put white over them to hide them, but that's because
his scanner yields per-page TIFFs where he can get at that.
I have got some shell/Perl/netpbm code that does things like
that with his sort of scanner filepiles like that, but haven’t
got round to something to turn a ScanSnap-produced PDF into a
bunch of per-page TIFFs.

You can use Adobe Acrobat Pro to gather a bunch of PDFs (and PNGs
and TIFFs) into a single PDF, put down page numbers, put down
bookmarks that mirror the table of contents.  Eric Smith's tumble
can do some of these things but I also use Acrobat Pro 8 (which was
bundled with the S1500M) for OCR.  Its OCR is based on something 
other than AABBY (I.R.I.S. I think) and does better at multiple
columns of text.

I do not expect OCR to be perfect, ever.  I hope it will be good 
enough for me to find things I remember reading, and thus far
it has worked reasonably well at that.  (This via macOS Spotlight.)
What is presented for view in Preview is the page image as scanned
and there is the possibility to re-OCR the PDF with newer software.

ScanSnap software looked much the same on Windows and macOS, and
may yet; haven’t seen recent versions of the Windows software.
There are differences in how they encode page images in PDFs, e.g.
on macOS the software will encode a black-and-white scanned page
image using a compression that is lossless but doesn't actually
compress very well, and I think this is because macOS code is 
used to construct the PDF.  I use an Acrobat Pro “preflight”
configuration to convert these to what is basically TIFF G4
encoding with run-length lossless compression that is better
at reducing PDF file size.  On Windows, the generated PDF also 
uses the run-length compression.

-Frank McConnell

Re: Hewlett Packard 2601A Printer

[Frank McConnell via cctalk]

On May 29, 2019, at 11:33, Glen Slick wrote:
> 
> On Tue, May 28, 2019 at 9:58 PM MEBA via cctalk  wrote:
>> 
>> I have an old daisy wheel printer by Hewlett-Packard, their 2601A. We got
>> this from an estate cleanout and I would like to sell it. It has been
>> powered up and the power light comes on and the carriage moves to the
>> starting position. It is a large, very heavy machine. I have it on ebay for
>> $150 (https://www.ebay.com/itm/223533138720)  but that was just a shot in
>> the dark. There is a better description and more pictures in the listing.
>> Any reasonable offer considered. I have no way to ship this item from here
>> but will drop it off at the ups store. The buyer will have to make their own
>> arrangements for packing and shipping with ups.
>> 
> 
> http://www.hpmuseum.net/display_item.php?hw=326
> 
> The 2601A was a 40 character-per-second daisy wheel printer. It was a
> wide-carriage printer that could also print on multipart forms. HP
> OEM'd this printer from Diablo (model 630). The 2601A came standard
> with an RS-232-C interface and did not offer an HP-IB option.

40 characters per second if you choose your characters and their sequencing
well.  I’m remembering them being connected to terminals and microcomputers
(HP 150, HP Vectra PC) at 9600 bps and needing some sort of flow control.
I am thinking there was a jumper on the serial I/O board that needed to be
set just so.  And yes, they are mostly Diablo 630 printers.

They’re nice daisywheel printers.  Loud enough that HP sold an enclosure.
Fancy enough that HP sold a simple tractor feed kit and a fancy cut-sheet
feed unit with two input bins.  The enclosure was big enough for either.

-Frank McConnell

Re: HP/UX 8 and hosts vs DNS

[Frank McConnell via cctalk]

On May 26, 2019, at 21:09, Cameron Kaiser wrote:
> I've been doing more work on my 9000/350 now that I have actual space to
> do work on it in. Although the 10b2 is flaky, I can usually coax it to work.
> 
> However, the damn thing won't query DNS even though I have a populated
> /etc/resolv.conf. It can ping the name server, and if the name server's
> name is in /etc/hosts it will resolve it (and even telnet to it), but it
> won't talk to it for anything else.

I read this far and thought "someone put nameserver host names in resolv.conf".

-Frank McConnell

Re: MPE release history (was: Re: VMS versions)

[Frank McConnell via cctalk]

On May 8, 2019, at 1:07, David Collins via cctalk  wrote:
> 
> The HP Computer Museum website now has a link to the version history file 
> referenced below.
> 
> http://www.hpmuseum.net/exhibit.php?content=3000-MPE%20(Software)
> 
> Happy to update it if there is more info or corrections. 

Thanks.  I do think there is something bogus in it: the assertion that MPE V/R 
was a thing in 1983.  Yes, it was mentioned in an issue of Computer News, but 
(looking at that via the HP Computer Museum web site too, and thanks for that 
too) I think that was a statement about the future unbundling of DS/X.25 in MPE 
V/R.  Also that MPE V/R was a long time in coming.  We ran Q-delta-2 on a 
Series III for a long time while the Series 64 became a 68 and maybe a 70, but 
did upgrade it to MPE V/R when that came out.

MPE V/R was “MPE IV in MPE V drag”.  It had the MPE V name but its internals 
and system table structures were those of MPE IV.  (We had some home-grown code 
that looked in the JMAT for the next job number.)

-Frank McConnell

Re: MPE release history (was: Re: VMS versions)

[Frank McConnell via cctalk]

On May 6, 2019, at 23:11, r.stricklin via cctalk wrote:
> On May 6, 2019, at 5:02 PM, Frank McConnell via cctech wrote:
>> Likewise, there used to be an article about MPE release history.  Links I 
>> know for it are:
>> 
>>  (20 
>> Aug 2014)
>>  (28 
>> Apr 2016)
>> 
>> Naturally it’s been wiped, and archive.org *doesn’t* have a copy, even 
>> though they have other pages under that t5/General directory in both cases.
> 
> I saved a copy in 2012. There are files attached to some of the posts in that 
> forum thread which collate the results and, amazingly, are still accessible: 
> 
> http://community.hpe.com/hpeb/attachments/hpeb/itrc-19/2080/1/294077.html
> http://community.hpe.com/hpeb/attachments/hpeb/itrc-19/2081/1/336662.htm
> 
> Grab them while you still can.

Thanks.  Grabbed.  Those have most of the information I was missing being able 
to find easily online: dates and version IDs for classic-3000 MPE releases.  I 
wish I could still get the discussion text that led up to them because they 
don’t entirely fit with my memory.

The mid-1980s were kinda busy with MPE IV Q-MIT and its delta releases, which 
culminated in MPE V/R for the Series II/III and 30/33 (I ran it on a Series 
III), and MPE V/P which didn’t last very long, and then MPE V/E which had a 
future.  Sometimes I have trouble remembering what happened when.  I don’t 
remember more than one MPE V/R release (E.01.00) and it happened some time 
after MPE IV Q-Delta-2.

-Frank McConnell

Re: VMS versions

[Frank McConnell via cctalk]

On May 6, 2019, at 15:48, Antonio Carlini via cctalk wrote:
> 
> On Mon, May 6, 2019, 5:17 PM Zane Healy  wrote:
>> 
>> It would be nice to see this through 8.4-2L1 (I think that’s the latest
>> version).
>> 
>> Zane
>> 
> 
> There used to be an article about OpenVMS release history, naturally it's 
> been wiped.

Likewise, there used to be an article about MPE release history.  Links I know 
for it are:

 (20 Aug 
2014)
 (28 Apr 
2016)

Naturally it’s been wiped, and archive.org *doesn’t* have a copy, even though 
they have other pages under that t5/General directory in both cases.

-Frank McConnell

Re: Looking for: 68000 C compilers

[Frank McConnell via cctalk]

On Feb 12, 2019, at 14:16, Warner Losh via cctalk  wrote:
> 
> On Tue, Feb 12, 2019 at 2:55 PM Ethan Dicks via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>> On Wed, Feb 6, 2019 at 10:08 AM Phil Pemberton via cctalk
>>  wrote:
>>> Does anyone have copies of any of the following -- or any other C
>>> compilers for the 68K which were around at that time?
>>> 
>>>   * Lattice C
>> 
>> Entirely randomly, I just opened a box I received today.  Expected in
>> the box was the DEC Rainbow.  Unexpected was an original box of
>> Lattice C 2.15 for 8086 - docs and original floppies plus safety
>> backups.   Also a surprise - it's all in a Lifeboat Associates binder.
>> 
> 
> Cool beans. Is it copy protected? Sometimes I think it would be cool to
> have an archive of early commercial s/w for the Rainbow somewhere...

I remember moving Lattice C v2 from IBM PC diskettes to an HP 150. It was 
MS-DOS applications and compiler and linker worked on the 150. No copy 
protection.

-Frank McConnell

Re: SunOS 2.4 Expliot (Re: Old Sparcstations

[Frank McConnell via cctalk]

On Dec 6, 2018, at 10:39, Jeffrey S. Worley wrote:
> The Sparcstation 4/330 I reworked the NVRAM chip on….

> I wanted root.

Was there something in the way of you booting single-user?

I am thinking Suns of that era let you into a boot ROM (via BREAK on serial 
console, or L1+A on Sun keyboard and framebuffer console) from which you could 
enter a command like "boot -s” which would boot to a single-user shell.

And physical console access is a good place to start for the win.  It is less 
effective than it once was, but remains a good first choice.

-Frank McConnell

Re: Text encoding Babel. Was Re: George Keremedjiev

[Frank McConnell via cctalk]

On Nov 25, 2018, at 15:44, Sean Conner wrote:
>  I even heard of a high school in Tennessee who said computer languages
> fulfill the "foreign language requirements" ... who'da thunk?

I have been told that in the 1960s taking a course in FORTRAN programming 
fulfilled the foreign language requirement at UC Berkeley.

-Frank McConnell

e-mail, character sets, encodings (was Re: George Keremedjiev)

[Frank McConnell via cctalk]

Very old mail programs indeed have no understanding whatsoever of character 
sets or encoding.  They simply display data from the e-mail file on stdout or 
equivalent.  If you are lucky, the character set and encoding in the e-mail 
match the character set and encoding used by your terminal.

The early-to-mid-1990s MIME work was in some part about allowing e-mail to 
indicate its character set and encoding, because at that point in time there 
were many character sets and multiple encodings.  Before that, you had to 
figure them out from your correspondent's e-mail address and the mess on your 
screen or printout.

And really it's not just about the mail program, it's about the host operating 
system and the hardware on which it runs and which you are using to view 
e-mail.  Heavy-metal characters are likely to look funny on a terminal built to 
display US-ASCII like an HP 2645.  Your chances get better if the software has 
enough understanding of various Roman-language text encodings and you are using 
an HP 2622 with HP-ROMAN8 character support and the connection between your 
host and terminal is eight-bit-clean.  But then you get something that uses 
Cyrillic and now you're looking at having another HP 2645 set up to do Russian. 
And hoping your host software knows how to deal with those character sets and 
encodings too!

-Frank McConnell

On Nov 25, 2018, at 9:55, ED SHARPE via cctalk wrote:
> 
> seems only the  very old   mail programs  do not adapt  to all character 
> sets? 
> 
> 
> In a message dated 11/25/2018 6:19:52 AM US Mountain Standard Time, 
> cctalk@classiccmp.org writes:
> 
>  
> 
> 
>> On Nov 21, 2018, at 4:46 PM, Bill Gunshannon via cctalk 
>>  wrote:
>> 
>> 
>>> On 11/21/18 5:19 PM, Fred Cisin via cctalk wrote:
>>> Ed,
>>> It is YOUR mail program that is doing the extraneous insertions, and 
>>> then not showing them to you when you view your own messages.
>>> 
>>> ALL of us see either extraneous characters, or extraneous spaces in 
>>> everything that you send!
>>> I use PINE in a shell account, and they show up as a whole bunch of 
>>> inappropriate spaces.
>>> 
>>> Seriously, YOUR mail program is inserting extraneous stuff.
>>> Everybody? but you sees it.
>>> 
>> 
>> I don't. I didn't see it until someone replied with a
>> 
>> copy of the offending text included.
>> 
>> 
>> bill
>> 
> same here. i didnt see them until some replies included the text.
> 
> kelly
> 

Re: Portable terminals

[Frank McConnell via cctalk]

On Sep 10, 2018, at 12:18, Al Kossow wrote:
> As sad as it sounds, I'm thinking now it may make sense to gut the 
> electronics and just use the case, lcd
> and kb to make a dumb terminal. At least then you don't have to screw around 
> with serial dongles.

This makes me wonder how much serial dongle you’re willing to screw around with.

2001’s Toshiba laptop with Windows Me (Harder) came with no serial ports except 
the USB kind (in spite of the specifications given on the seller’s web page).  
It did have two PCMCIA slots in which I installed PCMCIA serial cards.  Yes, 
two, I sometimes used it as a pass-through monitor for SLIP/PPP traffic.

I like the HP 200LX for portable serial terminal purposes, and have never 
stretched the built-in Datacomm app’s VT100 emulation to the point of noticing 
incorrect emulation.  But it meant having to carry at least the peculiar cable 
that brought its port out to DE9S (suitable for connection to PC/AT serial 
port), and probably a couple DE9P-to-DB25 adapters (for “printer” and “modem”), 
and maybe a breakout box too.

I liked the 100LX too.  Similar hardware and software.  I cannot recall any 
improvements to the Datacomm app in the 200LX.

The 95LX has two problems.  It’s basically a three-wire serial interface with 
no hardware flow control.  And it is designed to run on battery power, and it 
shows sometimes.  I had trouble getting it to work with a Telebit Qblazer (also 
battery-powered) until I got out the soldering iron and made up a single 
adapter to go between the two instead of a chain or two or three adapters.  One 
side or the other or maybe both just didn’t have enough oomph to punch through 
all those connectors.

-Frank McConnell

Re: Oddball Terminals (Was: Re: VT100's)

[Frank McConnell via cctalk]

On Sep 7, 2018, at 12:00, Al Kossow via cctalk wrote:
> interesting.. the vt71t has inverted-T cursor keys

And CAPS LOCK in the home row to the left of the A key.  The VT220 made it 
w-i-d-e.  Can we now fix the blame for the two of the three worst ideas in 
computer keyboard design on d|i|g|i|t|a|l?  (#3 would be sending CONTROL to 
live in the spacebar row and I think maybe we need to blame IBM for that.)

-Frank McConnell

Re: HP Series 9000 early 1980’s computer hardware

[Frank McConnell via cctalk]

On May 17, 2018, at 15:48, Warner Losh wrote:
> On Thu, May 17, 2018 at 4:15 PM, Frank McConnell via cctalk 
> <cctalk@classiccmp.org> wrote:
> HP-UX for them is very interesting from a historical perspective in that the 
> Unix kernel is a complete rewrite.  It is hosted on top of HP’s “SUN OS” 
> operating system (there is also a single-user BASIC system for the 9020, also 
> hosted on SUN OS) and written in HP’s MODCAL language.  The filesystem is 
> HP’s Structured Directory Format.  The userland is largely made up of ports 
> from AT System III (and later System V) and 4BSD.
> 
> HP-UX did a fairly extensive kernel rewrite, but implemented substantially 
> the same system call interface. This was apparent in a number of ways (the 
> binary format was different from other machines in ways I can't quite recall, 
> not quite COFF). They did ship mostly programs from BSD and SysV, though 
> through quirks of the legal minefield of the early days of Unix, they did it 
> under their System III license, at least in the early days... Don't know if 
> that ever changed to a System V license or not since they didn't have a 
> System V kernel...

I am thinking HP did at least four flavors of HP-UX.

First was HP-UX for the first-generation 9000s that became the Series 500.  I 
think it took System III as a baseline and reimplemented in MODCAL, and later 
added System V support.

Second was HP-UX for the 9836 (later Series 200).  That is a 68010 system and I 
think was a System III port.

Third was HP-UX for Series 300.  These are 680x0 systems for x>=2 and I think 
their HP-UX was a System III port later upgraded to System V.

Fourth was HP-UX for Series 800.  These are PA-RISC minis and I think their 
HP-UX was a 4BSD port with System V features for compatibility with series 300.

I’m not sure where the Integral fit in.  That was a single-user 68000, probably 
closest to series 200, with no MMU.
 
> So when it is running HP-UX it looks like Unix, with some exceptions.  One is 
> that if you open and read a directory from your C program there are no 
> entries for . (current) or .. (parent) directories; these are done in SDF’s 
> directory entry and not present in the actual Unix directory.  Yes, ls -a 
> shows them: it is faking them to make it look more like Unix!
> 
> I think they must have fixed this, or it wasn't true for readdir(). I ported 
> the OI toolkit to HP-UX once upon a time and the file dialog boxes just 
> worked, and we had . and .. in there…

Were you really working with a Series 500?  I don’t think anyone ever ported X 
libraries to them.  No usable TCP/IP stack on them unless you bought the 
Wollongong product.  (I am thinking HP had one for it too, for their NS/9000 
products, but it was IEEE 802.3 framing with 802.2 LLC header and not 
interoperable with Ethernet II.)

Series 300/400 (Motorola 680x0 for x >= 2) ran an HP-UX that I think is a 
System V derived kernel, or at least the later releases were, with a 4BSD TCP 
stack.  Series 800/700 ran an HP-UX that I think was a new port from 4BSD, but 
with System V features added for compatibility with the Series 300.
 
> -Frank McConnell (supported Wollongong’s TCP/IP on these)
> 
> Danger! The Sea Monster Comes!

Yup, my real thing there was supporting Wollongong’s WIN/TCP for MPE/V, which 
wasn’t really Wollongong’s TCP/IP but was instead Telnet, FTP, and SMTP clients 
and services on top of HP’s NetIPC TCP API.  Telnet and FTP were mostly 4BSD 
ports to CCS C/3000 and NetIPC and MPE.

(And in this message, y’all are getting all the wonder of Apple Mail promoting 
characters to Unicode and the horrible Gmail quoting with spaces.  I hope it’s 
understandable.)

-Frank McConnell

Re: HP Series 9000 early 1980’s computer hardware

[Frank McConnell via cctalk]

The 9000 Series 500 is very different from later 9000s.

I don’t think there more than one speed of CPU, although there was an early and 
later CPU with the later CPU having a floating-point unit onboard.  What you 
get out of a 9000 Series 550 over a Series 520 (aka 9020) is mostly more I/O 
slots, as I recall the 9020 had a short I/O cage.  But I think the processor 
cage is the same size and can host about the same sets of cards.

The CPU is a 32-bit stack machine, very like a wide classic-3000, and there can 
be up to three CPUs in a system.  There is an IOP that front-ends a CIO-type 
I/O bus (same bus and some of the same peripheral cards used in early PA-RISC 
systems) and I think you can have two IOPs in a system.

HP-UX for them is very interesting from a historical perspective in that the 
Unix kernel is a complete rewrite.  It is hosted on top of HP’s “SUN OS” 
operating system (there is also a single-user BASIC system for the 9020, also 
hosted on SUN OS) and written in HP’s MODCAL language.  The filesystem is HP’s 
Structured Directory Format.  The userland is largely made up of ports from 
AT System III (and later System V) and 4BSD.

So when it is running HP-UX it looks like Unix, with some exceptions.  One is 
that if you open and read a directory from your C program there are no entries 
for . (current) or .. (parent) directories; these are done in SDF’s directory 
entry and not present in the actual Unix directory.  Yes, ls -a shows them: it 
is faking them to make it look more like Unix!

-Frank McConnell (supported Wollongong’s TCP/IP on these)

On May 17, 2018, at 13:48, Ed Sharpe wrote:
> 
> actually we are lacking 9000 gear for smecc. where is it located? we are in 
> AZ...
> HP Computer Museum overseas is awesome... The site has saved us mauna time 
> with the excellent documents there.
> 
>  ed#
> 
> Sent from AOL Mobile Mail
> 
> On Thursday, May 17, 2018 David Collins via cctalk  
> wrote:
> I agree with Al. Chas approached the HP Computer Museum on this and as much 
> as they would be great to add to the collection, the shipping costs to 
> Australia and the fact that the museum is more in a consolidation mode than 
> acquisition meant we weren’t able to take them in. 
> 
> Hopefully someone close by to him would like to have these units!
> 
> David Collins
> 
> Sent from my iPad
> 
>> On 18 May 2018, at 1:35 am, Al Kossow via cctalk  
>> wrote:
>> 
>> Series 500 machines are quite rare. Someone should save these.
>> 
>>> On 5/16/18 10:00 PM, Lawrence Wilkinson via cctalk wrote:
>>> 
>>> I own several HP 9020 work stations along with peripheral gear associated 
>>> with that series.
>> 
>> 

Re: Unknown CDC unit , looks like a drum memory ?

[Frank McConnell via cctalk]

On May 17, 2018, at 11:47, Fred Cisin wrote:
> 
> On Thu, 17 May 2018, Ed Sharpe via cctalk wrote:
>> yep we see them  but   we  did not  type them intentionally  
> 
> https://quoteinvestigator.com/2015/06/13/we/
> 
>> may way to adjust  your  mail reader reader as  they do not  show up in   
>> any of the  mail readers  we have access to.
>> Ed# 
> 
> If your email program is crapping, it is not the responsibility of everybody 
> else to "adjust" their mail readers to filter out the crap.
> This group has been remarkably tolerant of NON-ASCII content.
> 
> Many already have configurations that do such filtering, and are not seeing 
> all of the mess.
> Others just assume that your mail client, or your keyboard is BROKEN.
> Would cleaning the contacts of your space bar reduce the bounce and noise it 
> produces?
> Perhaps also repair the rest of the punctuation keys, if the keyboard has 
> any, and at least one of the shift keys.
> 
> That is assuming that it is a keyboard, and not a telegraph key, nor OCR of 
> crayon drawings.

My guess is (and has been for a while) "dictated to Cortana".  And his Cortana 
is sometimes hard of hearing because the mic got buried under something.

We live in interesting times in which the future is here but not evenly 
distributed.  For many modern e-mail user programs, the default character set 
for plain text is no longer US-ASCII or some local national variation but 
Unicode.  And the e-mail composer works hard to notice that its user has typed 
a quotation mark so it can promote it into some other Unicode quotation mark 
(e.g. " gets turned into LEFT DOUBLE QUOTATION MARK).  It then gets sent as 
text/plain, but with UTF-8 encoding; and some but not all combinations of mail 
readers and display devices can show Unicode characters in UTF-8 encoding.

So if you insist on reading your e-mail with a VT100 or even an HP 700/92, some 
e-mail is looking funny and more will; but some of the newer terminal emulators 
(e.g. Terminal.app on macOS) are capable of displaying Unicode from a received 
UTF-8 stream, and that is why reports of success with Alpine vary: people 
running it from a terminal that understands UTF-8 see the non-breaking space 
characters as blanks, while those who run it from a terminal that understands 
only US-ASCII see them as something else.

Right at the moment I am using Apple Mail and it is one of those things that 
does character promotion, and sometimes I have uses for that.  I think I may 
have fixed this message, but that fixing is a conscious effort and takes some 
work to retype those quotation marks and move away from them with some care, 
and then check again before you send because sometimes it re-scans and 
re-promotes.

-Frank McConnell

Re: Old newsreader source code

[Frank McConnell via cctalk]

On May 8, 2018, at 9:23, Seth Morabito wrote:
> I'm experimenting with setting up UUCP and Usenet on a cluster of 3B2/400s, 
> and I've quickly discovered that while it's trivial to find old source code 
> for Usenet (B News and C News), it's virtually impossible to find source code 
> for old news *readers*.
> 
> I'm looking especially for nn, which was my go-to at the time. The oldest 
> version I've found so far is nn 6.4, which is too big to compile on a 
> 3B2/400. If I could get my hands on 6.1 or earlier, I think I'd have a good 
> chance.
> 
> I also found that trn 3.6 from 1994 works well enough, though it is fairly 
> bloated. Earlier versions of that might be better.
> 
> Does anyone have better Google-fu than I do? Or perhaps you've got earlier 
> sources squirreled away?

It occurred to me (and before I saw Peter Corlett’s post) to go looking for 
some of the old CD-ROMs that have been uploaded to archive.org, and I found 
this one:

https://archive.org/details/CDROM_March92

"Source Code CDROM”

I think it has two versions of nn, 6.4 (from 1990, in UNIX_C/USENET) and 6.3 
(from 1989, in USENET/COMPSRCS/UNIX/VOLUME19).  Which makes me think that older 
versions will likely predate the CD-ROM era if they can be found at all.  I get 
the idea that nn may not have escaped from Europe until that comp.sources.unix 
release of 6.3 in 1989.

> As an aside: If you were active on Usenet in 1989, what software were you 
> using?

rn on SunOS, from about 1986 or 1987, on differing hosts.  In all cases other 
folks installed it and I did not notice what versions were involved.  Continued 
with it until 1992 when I switched to GNUS on a SPARCstation.  Between 1994 and 
1997 I ran strn on a Sun 3/60 which was also running C News with news delivery 
via uucp, but switched to Gnus when I built a new system with a PC and FreeBSD.

-Frank McConnell

Re: HP 3000/37 console

[Frank McConnell via cctalk]

On May 7, 2018, at 21:36, Mike Loewen wrote:
>   Does anyone know if a non-HP terminal will work as the console for a HP 
> 3000 Series 37?  The power-on self-test uses ENQ/ACK to speed sense, but the 
> manual also implies that it will sense speed from a .  On my 37, the TIC 
> self-test passes up to the point where it talks to the terminal, but fails to 
> to speed sense.

You can fake it by typing control-F (ACK) repeatedly from when you apply power 
to the 3000 until it starts sending text.  But you will need to keep doing it 
as the firmware console code will keep doing ENQ/ACK every line or so for flow 
control after speed sensing.

I just did this with an HP 3000 Micro GX, and Reflection 1 VT on an HP Portable 
Plus.  It can be made to work but is not my idea of a good time.  Good thing 
there is Reflection 1 HP in that Portable Plus too.

-Frank McConnell

Re: looking for a mother board for a hp 3000-37

[Frank McConnell via cctalk]

On Feb 25, 2018, at 21:57, Jerry Wright wrote:
> Anyone have such a piece or know someone that might. 
> 
> Board number is 30457-60001
> Might take the whole thing if the price is right.

"mother board" is not how I would describe that part number.  That is the CPU 
PCA and is one of several cards that goes in a backplane slot along with 
memory, PIC, TIC,   Backplane PCA is 30474-60006.

-Frank McConnell

Re: Searching for Sun2 and Sun3 bits and bobs- a long-running project approaches completion!

[Frank McConnell via cctalk]

On Feb 24, 2018, at 18:57, Ian wrote:
> 
> Glen, thanks for the response.
> 
> The keyboard I’m looking for which I need for the 2/120 looks like this: 
> https://www.flickr.com/photos/alanc/4013376694/in/photostream

That is a Sun Type 2 keyboard.

> Part #: 540-1006-01
> 
> It terminates with a registered jack and not a d-sub. 
> 
> Perhaps maybe some late mode Sun2s used the one you pointed at... I have one 
> for the Sun3. I’m not sure.
> 
> I also know the mouse for the Sun2/120 looks like the one for the 3, but is 
> in black and again terminated with a registered jack that connects to the CPU 
> directly, and not via the keyboard as on the keyboard you posted.

The Sun 2/120 had the two RJ connectors for keyboard and mouse and the Type 2 
Keyboard and Type 2 Mouse (which you correctly describe) fit them.

I am thinking that there was a passive adapter box that went between the 15-pin 
D connector on later Suns and the two RJ connectors.  Maybe for the Sun 2/50.  
It also allowed one to use the Type 2 keyboard and mouse on the Sun 3/60 (and 
probably other models too).

Type 2 and Type 3 are electrically the same, the big differences are the 
connectors and that the Type 3 keyboard is where the mouse signals are split 
out.

> I’m sure somewhere, some rotten keyboard collector is using the keyboard I 
> need with their Dell PC because the keys click with some vaguely unique 
> hysteresis curve or something…

I remember preferring the Type 2 keyboard to the Type 3 keyboard, and for a 
while using a Type 2 keyboard and mouse with a Sun 3/60 through one of the 
passive adaptor boxes.  I do not recall why I preferred the Type 2 keyboard.

And the keyboard collectors want "decent mechanical switches".



And look at this page, and the 12th picture, for another Type 2 keyboard:



I have to wonder whether that is a sort of thing the keyboard collectors get up 
to.

-Frank McConnell

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 18, 2018, at 9:39, Grant Taylor via cctalk  
> wrote:
> 
> On 01/17/2018 11:33 AM, Noel Chiappa via cctalk wrote:
>> E.g. it probably only supports class A addresses, for instance, which is 
>> going to influence the code for picking the first-hop router.
> 
> I was not aware that there was code that supported /only/ Class A (/8) 
> addresses and /not/ Class B (/16) or Class C (/24) addresses.
> 
> I /thought/ that everything was either classful (as in supports all three 
> classes: A, B, and C) or classless (as in supports CIDR).
> 
> Is my networking history missing something else?

In the course of this discussion I have been reminded that BBN did a TCP/IP for 
the HP3000 that ran under MPE IV. It is described in IEN 167 and if you read 
that carefully you will realize that they got started on MPE III; MPE message 
files (think record-structured pipes) first appeared in late MPE III but were 
not documented until MPE IV.

Trawling the Intertubes for, well, anything about this I turned up a sort of 
progress report.



It begins on page 66 of 81, on page 68 of 81 it describes changes to the 
routing table.  "Currently, this table has one entry for each of the possible 
256 networks, and accesses are very fast." and I'll just leave you with that.

-Frank McConnell

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 18, 2018, at 9:27, Grant Taylor via cctalk <cctalk@classiccmp.org> 
> wrote:
> 
> On 01/17/2018 01:12 PM, Frank McConnell via cctalk wrote:
>> So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
>> (V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is late 
>> enough for it to be able to do IP over Ethernet (vs. V-delta-4 and before 
>> which could only do IEEE over 802.3).  And it has an FTP client.
> 
> Please clarify what you mean by "IP over Ethernet", specifically what frame 
> type?
> 
> Are you talking about Ethernet II frames?

What I meant to write in that latter part was "IP over IEEE 802.3".  HP's LAN 
business started out big on big-S Standards, as in an IEEE Standard was 
preferred over a document circulated by three other computer companies.  That 
document would be Ethernet II.  So HP's initial attempts at TCP/IP were done 
with IEEE 802.2 framing and SAP 6, and used HP’s Probe protocol for local 
address discovery.  And TCP/IP was done as a stopgap, the stated plan was to 
support the OSI stack when it was ready.

HP did eventually (by the end of the 1980s) come to grasp that the customers 
really wanted Ethernet (II) so they could at least ping the 3000 to see if it 
was up.  Support for that (and ARP) arrived in the version of NS Transport for 
MPE V/E V-delta-5.

>> So you might think I'd be able to move files between it and a modern FreeBSD 
>> box, right?  I mean, it's all just Ethernet, right?
> 
> Ethernet != Ethernet

OK, "IP over Ethernet II".  But most folks these days won’t be thinking about 
the other kinds.  Maybe even most folks on this list.

> I'm wondering if it might be possible to use an old NetWare 4.x / 5.x box as 
> a router to convert from one Ethernet frame type to another Ethernet frame 
> type.  I.e. from IP over Ethernet II frames to IP over 802.3 frames.

If you want something that was correct for the period, use a Cisco AGS router.  
(I think later Cisco routers will do too.)  It can do the routing and can also 
proxy HP’s Probe address-resolution protocol.

The Wollongong Group had a software routing product, WIN/ROUTE, and they worked 
it over a bit to make another product WIN/ROUTE2 which could do the 
802.3/Ethernet routing.  Can't remember whether it required 3C503 cards.

> I actually don't know if Linux can do this or not.  My typical go to tool 
> might not help here.  :-/
> 
>> Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") 
>> in V-delta-9 and before, such that it tears down the connection with a 
>> failure if a packet is received with IP type-of-service not zero. And the 
>> FreeBSD FTP server sets a socket option that gets FreeBSD to send that sort 
>> of packet.
>> At a previous employer, I went round with HP a bit on behalf of a mutual 
>> customer and got HP to issue a patch for NS Transport that corrects this 
>> behavior on the MPE side.  Clearly, I don't have that patch on this system.
> 
> I think we all have experiences like that.  Some sort of custom code that we 
> didn't care about at the time (beyond fixing the problem) that we would now 
> like to get our hands on years later.

Upgrading to MPE Release 40 FOS with Platform 3P SUBSYS would do; the patch did 
make it into later releases of NS Transport (which would be on the SUBSYS tape).

>> FreeBSD is FreeBSD, and I can build its FTP server from source and change it 
>> so it works in this situation; but I think this should give y'all some idea 
>> of the hilarity that can ensue when you exhume a 1980s TCP/IP and put it on 
>> your network.
> 
> I wonder if there are other tricks that can be used to work around this 
> without needing to recompile services.  I.e. use IPTables (or FreeBSD's 
> counterpart that I don't know the name of) to change the type-of-service to 
> something other than 0.

Been a while since I did that sort of thing but it was with ipfw, a divert 
socket, and a program to modify the diverted packets and hand them back down to 
the kernel.

Really, commenting out the setsockopt() call in ftpd seemed the easiest thing 
to do at the time, but I’d need to do it over now and might go for this sort of 
approach.

> Here's a link with a lot of gory details on NetWare's support of multiple 
> Ethernet frame types.
> 
> Link - Migrating Ethernet Frame Types from 802.3 Raw to IEEE 802.2
> - https://support.novell.com/techcenter/articles/ana19930905.html
> 
> Here are the four frame types that NetWare supports:
> 
> - Ethernet II
>- I think this is what we are using for just about everything today.
> - IEEE 802.3 "raw"
>- I'm speculating that this is the frame type that Frank is referring to 
> above.
> - IEE

Re: Reviving ARPAnet

[Frank McConnell via cctalk]

> On Jan 17, 2018, at 10:18, Warner Losh via cctalk  
> wrote:
> 
> On Wed, Jan 17, 2018 at 5:40 AM, Noel Chiappa via cctalk <
> cctalk@classiccmp.org> wrote:
> 
>>  http://minnie.tuhs.org/cgi-bin/utree.pl?file=BBN-V6
>> 
>> (The latter includes NCP as well as TCP/IP.)
>> 
> 
> I'm curious: does it inter-operate with modern TCP/IP implementations?

This is a more serious question than one might think, but I know you (Warner) 
have been around long enough to have gone to Interop when it was about 
improving network interoperability.

So here's a real example: I have an HP 3000 Micro GX with MPE G.A3.09 
(V-delta-9) which is very 1990.  And it has a LANIC, and V-delta-9 is late 
enough for it to be able to do IP over Ethernet (vs. V-delta-4 and before which 
could only do IEEE over 802.3).  And it has an FTP client.

So you might think I'd be able to move files between it and a modern FreeBSD 
box, right?  I mean, it's all just Ethernet, right?

Where it falls apart is that there's a bug in HP's TCP/IP ("NS Transport") in 
V-delta-9 and before, such that it tears down the connection with a failure if 
a packet is received with IP type-of-service not zero.  And the FreeBSD FTP 
server sets a socket option that gets FreeBSD to send that sort of packet.

At a previous employer, I went round with HP a bit on behalf of a mutual 
customer and got HP to issue a patch for NS Transport that corrects this 
behavior on the MPE side.  Clearly, I don't have that patch on this system.

FreeBSD is FreeBSD, and I can build its FTP server from source and change it so 
it works in this situation; but I think this should give y'all some idea of the 
hilarity that can ensue when you exhume a 1980s TCP/IP and put it on your 
network.

-Frank McConnell