<<Well, I disagree.  Our experience has been that when you mix old
peripherals with new processors, you uncover timing issues that you
didn't know existed.  A good portion of our processor development time is
spent in certifying existing peripherals.  In this case, there is a
meaningful new item involved -- a new processor with different
characteristics, especially I/O speed.>>
 
Again, I don't see it; I thought that that was precisely the purpose of
the HP-PB bus, the CIO adapter, etc.: to decouple the processor from the
peripherals. By this logic, you could say that a SCSI peripheral that
worked fine on a 9x7 box might not work on a 9x9KS box, because it uses a
different CPU (though everything else is the same). If a peripheral that
conforms fully to the SCSI specification, attached to an
similarly-conforming adapter, fails to work when plugged into a new box,
you don't blame the adapter or the peripheral; you figure out what's
wrong with your new box.
 
<<Somehow, I kinda think we will still be having a similar conversation.
As in, "Why doesn't this new system support HPIB?"  To tell the truth, I
really don't see much distinction here -- HP does not support HPIB on our
latest box.>>
 
The difference is that, on this box, it works. If a new box won't allow
you to plug in any kind of HP-built HPIB interface, the point is moot. If
a third party chooses to create an HPIB interface for such a box, support
is up to them. The situation here is quite different: HP-built,
HP-supported (on other boxes) HPIB interfaces work fine on this box. It's
the difference between "You can't drive to the movie because the car
won't start" vs. "You can't drive to the movie because I say so"-the
first is pretty self-explanatory, the second begs the question "Why not?"
 
<<1)  HPIB was not tested on these systems.  Our testing includes
verification of not only "normal" use but also "stressed" usage.  Do
these HPIB peripherals recover from powerfail? Have we tested all to
corner cases?  etc. As I've said, new processors sometimes open up timing
windows that can mask serious (e.g. undetected data corruption) problems.
We cannot guarantee your data integrity if you use untested
peripherals.>>
 
If a new processor unveils a flaw in a 5-component system, where only the
first component has changed, and the middle 3 components are specifically
designed to decouple the first component from the last, I'd say that the
problem is more likely in the intermediate components.
 
<<2)  Performance:  HPIB was developed in the 1960s and your 9x9KS
processor was developed in the 1990s.  They are a poor match.>>
 
From my perspective, my re-HPIB-ized 2563B is a much better match to the
959KS/200 than a 9600BPS serial line.
 
Your other reply pointed out that a variety of serial printers work fine
on a 9x9KS with a DTC. As I mentioned, that requires additional hardware.
I guess that SCSI is, in fact, the only stand-alone option for the box.
 
<<Remember, your peripherals are the lifeblood of your system.>>
 
I agree; that's why I want them to work! ;-)
 
<<The bottom line is the HPIB peripherals are untested and unsupported.
 I'm glad you are happy with your HPIB peripherals -- they were built to
last, but you are taking a risk in using them.>>
 
Understood. That's why the only one involved is the printer, a relatively
non-data-critical device.
 
I think this dialog may have gotten off track. I didn't start this to
convince anyone that HP is pulling a fast one on us, and I don't expect
you to convince me that the decision is correct or not, technically or
otherwise. And, despite the rhetorical "what does 'not supported' mean?"
question in the original post, I don't expect you (or anyone else from
HP) to provide some kind of official reason for the non-support, because
I don't think there is one. I think it's a cost/benefit issue, driven at
least partly by the marketing people. As such, technical issues are
really secondary; the primary issue is whether or not HP can "get away
with it". This is not to imply any kind of evil intent or subterfuge;
it's just a case of making a choice that some percentage of the user base
will accept, some percentage will vociferously complain about, and the
majority will ignore. If the complaining percentage is small enough, both
in numbers and in purchasing power, then the choice worked; if not, a
reversal or modification is likely. And such a reversal/modification is
again not a technical issue; it's a matter of finding the answer to the
question "What will the users accept?"
 
I appreciate your input and your time.
 
Steve Dirickson         WestWin Consulting
(360) 598-6111  [log in to unmask]