On Mon, Feb 5, 2018 at 1:05 PM, Timothe Litt <l...@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 ᐧ
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh
