We used to have some products (think it may have been ZEKE, ZEBB) that
used to provide several days of grace at DR site, but had a
particularly inconvenient way of managing the days of grace which meant
you could never be sure how long you might have for a real DR: If you
used the days of grace, unlike other vendors it didn't reset
automatically once you were running under a valid license key. You had
to manually reset it and could only do that, I think, once within a
12-month interval. So if you had a hardware change that forced you to
use several days of grace at your production site while getting new
keys, and didn't remember to do the manual reset or had already used a
reset too recently, you could get a nasty surprise of fewer days of
grace if an actual DR occurred. A very bad design from customer's
viewpoint.
It always seemed to me that not only should the vendor allow the product
to run for days with an invalid key to support DR with minimal fuss,
but if they were clever they might even allow that grace time to
increase to a month or more based on how many years a customer stays
with the product -- in other words, encourage customer retention by
rewarding long-term customers with greater convenience on key/license
issues.
I recall some vendor that always wanted to change some terms in the
contract when it came up for renewal, which always involved several
months of haggling with our Director and corporate lawyers and several
months of having to install multiple temporary keys before there would
finally be a signed contract and a "permanent" key. It's not like we
were a new customer -- we had been with the product for many years, but
still the same song and dance every time even though both sides had to
know from the history there would eventually be a contract. I guess the
vendor thought our corporate lawyers would somehow be influenced to
settle for worse terms if the SysProgs had to do extra work to keep the
product running -- the lawyers didn't work with us and couldn't have
cared less. I was left with a bad impression of that vendor -- always
on the lookout for a replacement product. Being too inflexible on key
management eventually costs the vendor.
Another thing to keep in mind, during DR there are scenarios where
computer clock time could cover more days than wall clock time. We had
a situation where some processes needed to run daily and the effect of
failing to run was unknown but expected to be bad. One way we handled
that if a disaster happened on day x and you recovered the system on day
x+1 was to bring up the system with z/OS clock set to day x, run those
mandatory processes for day x that weren't finished, shutdown the system
and bring it back up on actual time to run day x+1 workload. In effect
the Operating system could see a time span covering up to 48 hours in
the initial 24-hour interval of recovery, so a one-day grace period by
z/OS time would have given us less than a real day of grace in the event
of DR.
Joel C. Ewing
On 04/20/2017 12:06 PM, Dyck, Lionel B. (TRA) wrote:
> A self-service site is good but it still requires that time be consumed
> getting the temp license code when that time could be better used in
> returning service to the customer and then, after service is restored,
> getting and updating the temporary license codes. Anything that delays
> return to service should be avoided unless there is value. True there is
> value in having working license codes so that products will continue to work
> BUT there is no reason the product can't continue for a few days with warning
> messages to provide time for the DR team to restore service and then, after
> they catch their breath and perhaps get some rest, then they can go to the
> self-service site for a license code.
>
> Just my $0.02
>
> --------------------------------------------------------------------------
> Lionel B. Dyck
>
>
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of David Cole
> Sent: Thursday, April 20, 2017 11:35 AM
> To: [email protected]
> Subject: [EXTERNAL] Re: Vendor Licensing Frustrations
>
> Lional,
>
> We provide a self-serve website for do-it-yourself creation of short term
> licensing codes. What is your View about that?
>
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS: <mailto:[email protected]>[email protected]
>
> Home page: www.colesoft.com
> LinkedIn: www.xdc.com
> Facebook: www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
>
>
>
>
>
>
> At 4/20/2017 12:21 PM, Tom Brennan wrote:
>> Dyck, Lionel B. (TRA) wrote:
>>> Two vendors that I contacted suggested that we contact them before the
>>> DR to get temporary license codes. If anyone can provide a psychic
>>> hotline to contact to know when a DR will occur it would be
>>> appreciated.
>> Then call them every day just in case there might be a disaster :)
> Dave Cole
> ColeSoft Marketing
> 414 Third Street, NE
> Charlottesville, VA 22902
> EADDRESS: <mailto:[email protected]>[email protected]
>
> Home page: www.colesoft.com
> LinkedIn: www.xdc.com
> Facebook: www.facebook.com/colesoftware
> YouTube: www.youtube.com/user/colesoftware
>
>
--
Joel C. Ewing, Bentonville, AR [email protected]
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
