18 Aug
2010
18 Aug
'10
7:33 p.m.
This is a bit off topic, I guess, and a repeat, but ClassicCmp is still
probably the best place to ask.
My company runs a bunch of HP83000 mainframes (F330 models) in
product testing. We're tied to Agilent SmarTest v5.x-6.03 running on
HP/UX v10.20 for test vectors.
SmarTest interfaces with the test frame via an Agilent-branded fiber
optic PCI adapter. The card is marked E2777B, p/n A3850-0583. It's a
buffered serial adapter on a PCI bridge and that's all we know about it.
SmarTest will run on HP/UX 11i, but the interface drivers will not
load. We don't have source to the drivers in question, the card itself
is, as far as we can discover, entirely undocumented, and neither HP nor
Agilent has any interest in maintenance or further development.
My company will pay a fair boatload of cash for an 11i-compatible
driver. If you're interested and have the background & skills to tackle
this, contact me off-list.
Doc Shipley
18 Aug
18 Aug
7:46 p.m.
On 8/18/10 3:33 PM, Doc Shipley wrote:
This is a bit off topic, I guess, and a repeat, but
ClassicCmp is still
probably the best place to ask.
My company runs a bunch of HP83000 mainframes (F330 models) in product
testing. We're tied to Agilent SmarTest v5.x-6.03 running on HP/UX
v10.20 for test vectors.
SmarTest interfaces with the test frame via an Agilent-branded fiber
optic PCI adapter. The card is marked E2777B, p/n A3850-0583. It's a
buffered serial adapter on a PCI bridge and that's all we know about it.
SmarTest will run on HP/UX 11i, but the interface drivers will not
load. We don't have source to the drivers in question, the card itself
is, as far as we can discover, entirely undocumented, and neither HP nor
Agilent has any interest in maintenance or further development.
My company will pay a fair boatload of cash for an 11i-compatible
driver. If you're interested and have the background & skills to tackle
this, contact me off-list.
I looked into this at length when you mentioned it about a year ago,
and I concluded that you're basically screwed. :-(
Your only option, as far as I can see, is to try to reverse-engineer
that drivers and fix whatever's preventing it from loading under 11i.
-Dave
--
Dave McGuire
Port Charlotte, FL
7:59 p.m.
On 8/18/10 2:46 PM, Dave McGuire wrote:
On 8/18/10 3:33 PM, Doc Shipley wrote:
That's the general idea. Jonathan's the only one here that possibly
could do that, and he's already working 70-hour weeks....
One option we've discussed and that would be perfectly acceptable is
ditching the Agilent adapter altogether. The comms protocol for the
HP83000 is well-documented, and the transport looks to be standard 25Mhz
multi-mode FC. If we could make some other FC adapter look right to the
software, that would be even better than a new driver for an aging
adapter that costs $5k on eBay....
Doc
This is a bit off topic, I guess, and a repeat,
but ClassicCmp is still
probably the best place to ask.
My company runs a bunch of HP83000 mainframes (F330 models) in product
testing. We're tied to Agilent SmarTest v5.x-6.03 running on HP/UX
v10.20 for test vectors.
SmarTest interfaces with the test frame via an Agilent-branded fiber
optic PCI adapter. The card is marked E2777B, p/n A3850-0583. It's a
buffered serial adapter on a PCI bridge and that's all we know about it.
SmarTest will run on HP/UX 11i, but the interface drivers will not
load. We don't have source to the drivers in question, the card itself
is, as far as we can discover, entirely undocumented, and neither HP nor
Agilent has any interest in maintenance or further development.
My company will pay a fair boatload of cash for an 11i-compatible
driver. If you're interested and have the background& skills to tackle
this, contact me off-list.
I looked into this at length when you mentioned it about a year ago,
and I concluded that you're basically screwed. :-(
Your only option, as far as I can see, is to try to reverse-engineer
that drivers and fix whatever's preventing it from loading under 11i.
8:09 p.m.
On 8/18/10 3:59 PM, Doc Shipley wrote:
That's the general idea. Jonathan's the only one here that possibly
could do that, and he's already working 70-hour weeks....
He's as sharp as they come, but I assure you he's most definitely not
the only person on earth who is capable of single-stepping in assembler
to reverse engineer a chunk of code. ;)
This is a bit off topic, I guess, and a repeat, but
ClassicCmp is still
probably the best place to ask.
My company runs a bunch of HP83000 mainframes (F330 models) in
product
testing. We're tied to Agilent SmarTest v5.x-6.03 running on HP/UX
v10.20 for test vectors.
SmarTest interfaces with the test frame via an Agilent-branded fiber
optic PCI adapter. The card is marked E2777B, p/n A3850-0583. It's a
buffered serial adapter on a PCI bridge and that's all we know about it.
SmarTest will run on HP/UX 11i, but the interface drivers will not
load. We don't have source to the drivers in question, the card itself
is, as far as we can discover, entirely undocumented, and neither HP nor
Agilent has any interest in maintenance or further development.
My company will pay a fair boatload of cash for an 11i-compatible
driver. If you're interested and have the background& skills to tackle
this, contact me off-list.
I looked into this at length when you mentioned it about a year ago,
and I concluded that you're basically screwed. :-(
Your only option, as far as I can see, is to try to reverse-engineer
that drivers and fix whatever's preventing it from loading under 11i. One option we've discussed and that would be
perfectly acceptable is
ditching the Agilent adapter altogether. The comms protocol for the
HP83000 is well-documented, and the transport looks to be standard 25Mhz
multi-mode FC. If we could make some other FC adapter look right to the
software, that would be even better than a new driver for an aging
adapter that costs $5k on eBay....
"Standard 25MHz multi-mode FC"? There are precious few standard fiber
communications modulation methods and "wire"-level protocols, and if
they designed a proprietary one to artificially keep costs high and lock
out competitors (which is the only real reason why they'd have done it)
then there's almost no chance of them having used any of the common ones.
Unless of course by "FC" you meant FibreChannel, which means it could
speak the standard FC protocol but implement a proprietary subcommand
set within the FC-delivered SCSI protocol. In that case, it could
likely be reverse-engineered with a FibreChannel protocol analyzer. I
suspect, however, that you know how much those cost.
What major chips are on the board? Anything standard, or all proprietary?
-Dave
--
Dave McGuire
Port Charlotte, FL
5317
days inactive
5317
days old
3 comments
2 participants
participants (2)
-
doc＠vaxen.net -
mcguire＠neurotica.com