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.
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. 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.
:>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.
--
Binyamin Dissen <[EMAIL PROTECTED]>
http://www.dissensoftware.com
Director, Dissen Software, Bar & Grill - Israel
...
--
Joel C. Ewing, Fort Smith, AR [EMAIL PROTECTED]
----------------------------------------------------------------------
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
