[Simh] EXT :Re: DEC Alpha Emulation

[Clem Cole]

On Mon, Feb 5, 2018 at 1:05 PM, Timothe Litt <litt at ieee.org> wrote:

> On 05-Feb-18 12:01, Clem Cole wrote:
>

> The *word *you left out was probably the issue.
>
​Fair enough ..​



> *We just didn't make adding a node to a cluster difficult and mysterious
> enough.*
>
​Right ;-)​




> So product management's conservatism is understandable, given the risk
> that the SPD won't be re-read when the function of a node changes, and the
> resulting data corruption being laid at DEC's feet.
>
​Point taken, but DEC used the SPD as its primary defense for exactly this
type of problem.​ It was the 'legal' definition of what was and was not
allowed.   But as you point out, that behavior does not always make for
happy customers or sr managers.




>
> So, the counter-argument becomes "how much engineering should be invested
> in allowing a customer to save $100 on the cost of a PCI card?"  And the
> easy answer is one of "none" and "it's not a priority".  Ship only cluster
> capable hardware, and "problem solved".  Not all engineering problems are
> best solved with engineering solutions.  But I'll grant that the
> engineering would be a lot more fun :-)
>
​I hear you and your are 100% correct -- that is exactly the way it would
have been (was) handled​.  The truth is in at least Tru64  (I think is was
Feed Knight - Mr. SCSI) had code that detect when your SCSI bus was being
shared.   It would have been easy to add add a side look up to check the
control being used and if it was not in the official table, produce a boot
message saying -- "*shared bus with unsupported SCSI controller, please
remove sharing or replace controller and reboot."*

​But I could never get marketing to accept that.​

But I agree, the fact is that somebody would have tried to do it.  My point
was that if we detected it (which was not not that hard), then we could
have at least said something.   And in practice if you still ignored it and
it was in all those system logs, it would have been pretty easy to say to
the end customer, *we told you not to do that*.

Then again to your point - I know of a case where a VPN manufacturer as
told its customer not configure their VPN's the way the customer does, but
said customer's IT dept insists on doing it differently anyway - much to
the internal development engineers (@ the customer) distress.  In
this case, its a switch, the customer are being more conservative (and
silly) than the VPN manufacturer has told it to be, but breaking a lot of
things in process that should work.  The local engineers b*tch because
things break that should not -- and they find out it is a local cause by
their own IT dept.   But it is a case where
the manufacturers recommendations are not being considered and things would
work as expected (and tested by the manufacturer) if the SW was configured
as designed.

Clem



ᐧ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.trailing-edge.com/pipermail/simh/attachments/20180205/4d942f0c/attachment-0001.html>