James Herod wrote:
>Once a subsystem has been tested with the
>thoroughness of HP-IB over the years, you can be *very sure* that
>incompatibilities with newer bus designs will be confined to the
>interface, and not further down the chain.
>...I agree that this whole "problem" appears to be a case of forced
>obsolescence dictated by HP marketdroids.
 
Again, while HP has done things like this in the past, the refusal to
support HPIB on new boxes isn't one of them. [I see the dead horse cringing
in fear of the lash.] The fact that you can stick some cards together and
have them run does NOT mean that you can support that configuration. HP
_guarantees_ that their systems will run across a specified range of
environmental parameters (voltage, temperature, humidity, vibration, etc.).
Unless they test at the full range of environmental parameters, they'd be
stupid to guarantee success. The line between working and flakey hardware
can be very thin, and while all the pieces in the configuration have been
tested, the fact that you can put the HPIB card onto the CIO bus in this
new chassis doesn't mean that it'll work well:
 
    1. The power supply is different, and probably the power budget as well.
    2. The cooling system is different.
    3. The RFI environment is different.
    4. The NIO bus timing is different.
    5. The cable layout is different.
    6. The power distribution system is different.
    7. The clock distribution system is different.
 
and so on. Before you get too critical of HP on this issue, spend a day
trying to find problems like this:
 
       A proven disc drive was plugged into a proven interface in a
       proven computer. About one time in 1,000 this configuration of
       individually proven components refused to read bit patterns
       that contained zeros in certain bit positions when the computer
       was operated at its maximum specified temperature. Cause: The
       new computer used different bus driver ICs from the older one,
       and the disc interface had a different loading pattern than the
       other interfaces, and the power supply bypassing on the one
       driver IC that supplied the unstable bits was insufficient in
       these circumstances, though it was in accordance with accepted
       engineering practice.
 
This problem took DAYS to find. Every individual piece of equipment
functioned within its specifications, yet the system as a whole did not. Do
you want to be plagued with data-related problems that can only be
duplicated once in 1,000 trials? And when you call out the CE and she tests
each piece individually, everything tests OK?
 
For an example of the kinds of things that can crop up in hardware, read
_The Soul of a New Machine_, by Tracy Kidder. It's an excellent story in
its own right, but it does go into some of the frustration and
unpredictability encountered in trying to get hardware to work 100% of the
time under all design conditions. The fact that each piece works is no
guarantee that the system will.
 
-- Bruce
 
 
 
---------------------------------------------------------------------------
Bruce Toback    Tel: (602) 996-8601| My candle burns at both ends;
OPT, Inc.            (800) 858-4507| It will not last the night;
11801 N. Tatum Blvd. Ste. 142      | But ah, my foes, and oh, my friends -
Phoenix AZ 85028                   | It gives a lovely light.
[log in to unmask]                 |     -- Edna St. Vincent Millay