On Sun, 25 Feb 2007 16:50:04 -0600 "Joel C. Ewing" <[EMAIL PROTECTED]> wrote:
:>Binyamin Dissen wrote: :>> On Sat, 24 Feb 2007 20:25:24 -0600 "Joel C. Ewing" <[EMAIL PROTECTED]> wrote: :>> :>Particularly in the case of processor upgrades, or in DR, there is no :>> :>reliable way for us to verify that new keys from the vendors are correct :>> :>and correctly installed until we are running on the new processor. If :>> :>they aren't and a hard failure results, there is a high likelihood that :>> :>this failure will be seen in some way by the end users, even if the :>> :>vendor key support is 24x7. > :>> In the case of a processor upgrade: if you get a hard error during production :>> due to a bad ISV key, your testing criteria are way too lax. :>Really? Explain how one tests a dynamic CPU upgrade consisting of IBM :>non-disruptively turning on one or more CP's on your only production :>processor complex. At least 75% of our upgrades are now of this nature. That causes a change in the CPU id? Live and learn. :> Depending on what the vendor product is examining and how often it :>checks, it either sees an instantaneous change in production of the :>processor type at the time the new CP is enabled, or it sees that change :>when some vendor-specific future event (possibly the next IPL, POR, etc) :>occurs. There is no way to reliably test the new keys in advance, even :>if the product allows "installing" the new keys in advance. When :>changing to a completely new processor box, it is certainly desirable :>and generally possible to have an overlap and have the new machine as a :>test bed for new keys, but I can envision cases where there would be :>unavoidable constraints that would prevent that overlap (and have lived :>through some major push-pull scenarios with no overlap). :>> In the case of DR: if you do test runs, you will be quite aware of this issue. :>> If you never do test runs, refer to the "processor upgrade" above. If you do :>> not test, this is not likely to be your only problem. Or a major one. :>Vendors can always change their key validation logic with maintenance :>and release changes and our mix of ISV products drifts as well. Always important to redo the DR test after significant changes (for some value of "significant"). :> Some :>products fail without new keys on a DR processor only when running :>without VM; others fail in all cases. When we find a vendor product :>that has key validation problems at DR testing, the resolution for that :>product gets incorporated into our DR procedures. That we have :>occasionally encountered new failures in the past during DR testing :>tells us there is always the potential for an unexpected failure at an :>actual DR. DR testing reduces the exposure, but cannot eliminate it. Granted. :>> :>While I can understand the vendors concerns, my goal is to focus on our :>> :>own system reliability and the needs of our end users; and any hard :>> :>failures in ISV products are an enemy of that goal. :>> First, work on what you can change - get your accounting people up to speed. :>> Keep track of the ISV products and expirations, and follow up on them. :>Our accounting people have never been a problem, neither have we had any :>significant problem tracking ISV product expirations. The problem is :>that we do not work in a static environment. It has been contract :>negotiation and the reluctance of vendors to adapt reasonably to :>changing hardware/software environments that has been the greatest :>source of problems, especially when hardware upgrades are to support :>application growth that is unrelated to the vendor's product! :>> Improve those test procedures. :>See above. :>> Am I a little harsh? Perhaps. :>A vendor only has to deal with the familiar idiosyncrasies of his own :>product's key management. On the customer side we have to deal the :>unfamiliar and changeable idiosyncrasies of many vendor products. :>> Yes, you would like to not have to worry about the ISV key, and the ISV would :>> love not having to worry about collecting. > :>> But you should be aware that there is a bit of a partnership here. :>Granted. Perhaps a vendor should cut much more slack with a company :>that has been a consistent paying customer for years by selectively :>making key management less onerous for such customers. I am sure they do. Do not vendors supply a means for customers to get an unrestricted full-use temporary key (expires within a week - or less?) to handle the DR bumps in the road? -- Binyamin Dissen <[EMAIL PROTECTED]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
