Judging from the number of responses to this thread, there are obviously
many who do think keys are a big deal. It's a big deal because a
processor upgrade that takes less than 5 minutes of a System
Programmer's time to deal with the hardware and Operating System
aspects, requires hours to deal with keys from multiple vendors, each
with their own unique methods of acquiring and installing keys, and
requires weeks or even months of follow-up until all issues from the
last vendor are finally resolved. In the event of a real DR, in the
initial days there will be enough serious problems to deal with without
having immediate resolution of vendor keys be one of them - especially
true for any vendor not equipped to supply keys in a matter of minutes,
24x7. For DR testing, we consider proof of the ability to get must-have
keys from vendors in a timely fashion as part of the DR exercise.
In our experience, the vendors concept of "timely" key delivery too
often falls short of user needs. With the advent of dynamic CPU
upgrades, the turn-around for CPU upgrades is now so quick that almost
all such upgrades are "unscheduled" when compared to the turn-around for
contract negotiations with vendors to support the new CPU. Our CE can
"install" the new CPU in a few minutes; we may have to negotiate for
months with vendors, even those we have even done business with for
decades, before getting a new contract that we consider to have adequate
safeguards for us and which is satisfactory to lawyers and bean-counters
on both sides. In the mean time we may have to install temporary key
after temporary key for months on end, and even after a contract is
signed it may still be another month until we can finally get someone to
turn loose with a "permanent" key - about time to start the whole
process over again!
Someone made mention of CA's web site for LMP keys. Last time I
checked, 6 months after our last upgrade, it still only had the keys for
our old CPU. Most of CA's keys, thank goodness, are fail soft, but not
all. CA-Platinum DB2 utilities failed ungracefully without an EKG key
at our last DR test. CA is not the only vendor that has trouble keeping
all their databases correct on our current CPU - we received a "new" key
just last week from another vendor for a CPU serial that was 8 months
obsolete (yes they had been notified, and had previously sent us a good
key for the current CPU).
If vendors feel they have to implement key checking, then as a user I
would prefer they all be failsafe (nags). If the vendor insists on
implementing a hard failure, then there must be a grace period that at a
very minimum should be much longer than the time period for contract
re-negotiation. Rubber-stamping of a vendor-offered contract (seldom
advantageous to the user) is not an option for us, and I suspect we are
not alone. That grace period should automatically be restored when the
product runs on valid keys, without any manual resetting required
(ZEKE/ZEBB take note), so that the full grace period is assured to be in
place if, heaven forbid, one has to deal with a DR for real.
Vendors that can't meet these minimal requirements encourage us to look
for alternative products.
Dave Salt wrote:
From: David Day <[EMAIL PROTECTED]>
If an ISV doesn't use a key tied to a date and a machine serial
number, what other mechanism is there to insure there are no pilfered
copies of the ISV's product running somewhere, and the ISV doesn't
have a clue? From a user's perspective, if the ISV is timely in his
delivery of license keys, why is it a big deal?
I don't see it as being a big deal either. When a customer licenses a
product, they are given a key. A year later (or shortly before the
license expires), the customer receives an invoice. If they pay the
invoice, they get a new key. The customer replaces the old key with the
new key (e.g. enters it in a flat file or ISPF table or whatever).
Nothing needs to be to compiled/linked/refreshed/IPL'd (etc). It just
takes a couple of minutes to enter the new key, and the customer is good
to go for another year (or whatever the renewal term is). How is that a
big deal?
The only issue I can see is what happens when an unscheduled change of a
CPUID occurs, such as might occur in a disaster situation. If the
software is "mission critical" (i.e. needs to be up and running the very
minute the switchover to the new CPUID occurs), it should already be
licensed to run at the disaster site. Or, the software can display a
message such as "This product isn't licensed to run on this CPUID", but
will still run anyway (perhaps with limited functionality). This gives
the customer time to acquire a new key, and everyone is happy.
Dave Salt
SimpList(tm) - The easiest, most powerful way to surf a mainframe!
http://www.mackinney.com/products/SIM/simplist.htm
...
--
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
