If you use CPUID and get the value that varies by LPAR, be sure to
exclude from validation the digit that is LPAR-dependent - having
different authentication codes for a PROD vs. TEST LPAR means there is
no way to test an authentication code without going live; and I second
the need to support multiple CPUIDs, both to cover upgrades and allow
multiple licensed CPUs at a site to use shared product files.
If validation is a must, suggest "Nag" alerts with continued full
functionality at least a month in advance when license expiration
approaches, or for the duration of the license on an incorrect CPUID to
minimize client exposure during CPU upgrades or actual DR and minimize
busywork with DR testing. But don't flood system console with nag
messages (especially highlighted ones), and if a highlighted console
message, preferably at most one a day and in 8-5 time frame would be
appreciated rather than someone getting an unnecessary midnight call.
Then there's always the "radical" approach of just using external means
(e.g., letters, bills) to remind of license renewal requirements.
Mainframe shops are used to paying for software, and none that I have
dealt with would have condoned deliberate circumvention of licensing
requirements.
Depending on the nature of the product, inability to get maintenance for
an unlicensed product could be sufficient to eventually disable the
product. Since most z/OS shops must update z/OS at least every two
years to keep current, perhaps building in a product maintenance
requirement to update the maximum supported release of z/OS would be
sufficient to force eventual product expiration if it is not under a
maintenance contract.
J C Ewing
On 12/26/2011 03:19 PM, Sam Siegel wrote:
zMan - Thanks for the reply. It is a new product - No customers yet.
I would like enough licensing to keep honest people honest and an
operationally oriented reminder for the annual renewal.
Sam
On Mon, Dec 26, 2011 at 1:11 PM, zMan<[email protected]> wrote:
Gahh, "IF BibBox, Inc....".
On Mon, Dec 26, 2011 at 4:11 PM, zMan<[email protected]> wrote:
On Mon, Dec 26, 2011 at 2:22 PM, Sam Siegel<[email protected]> wrote:
Hello List - I'm attempting to create a licensing mechanism for a bit
of software. I would like to be able to use a unique and
non-modifiable identifier as part of the mechanism.
The CSRSI callable service and STSI instruction provide a variety of
hardware related identifiers.
CSRSI returns fields called si00pccacpid and si11v1cpcsequencecode.
These
appear directly related to PCCACPID (PCCA control block) and Sequence
Code
(STSI basic machine configuration)..
Is there any preference to using one field over the other? What are the
advantages and disadvantages of using each field?
Are there other fields (in same or other control blocks) that should be
used?
Please feel free to treat this as an open ended question related to
licensing mechanism and provided any related advice and tips based on
experience.
OK, I gotta ask -- what's the problem you're trying to solve? You
don't trust your customers? In over a quarter century in the mainframe
software business, I've come across ONE customer running software on
an unlicensed box, and it was an oversight -- and a nice full-price
bluebird for the sales rep. I don't believe "CPUIDs" are worth the
hassle.
Having said that, I would expect that any CPUID processing would work
off, well, the CPUID. That's what customers understand.
SAS Institute used to have a nice CPUID system for their C compiler
that would issue a warning and print out what company the sucker was
licensed to, but would continue to operate if the CPUID was wrong.
This allowed emergency operation, while clearly keeping any real
company from running it on the wrong box (though I suppose of BigBox,
Inc. licensed it on one and ran it on two, it would be harder to
notice; the case I'm thinking of was when we were running the
Merrill-Lynch copy on another company's machine, WITH permission from
SAS; every time we invoked the compiler, it would whine and say
"Licensed to Merrill-Lynch").
Now, with systems management stuff that doesn't have a real UI that
gets invoked all the time, it's harder. The best I've seen allowed:
- multiple key entries in the CPUID file, so you didn't have to worry
about swapping files at expiration: you just added new entries and
eventually deleted the old ones. And you could keep all your CPUIDs in
a common file, shared (or replicated) across systems.
- Warned starting 30 days before expiration, on the operator's
console: "XYZ will expire in 30 days" (29, 28...).
- If it had a valid license (i.e., one with time on it but on the
wrong machine) would run in "emergency mode", whining on the
operator's console every 10 minutes or so, but still running (this
allowed for DR).
- Supported "universal" temporary keys, that could be
read/emailed/FAXed by support at 3AM if you really screwed up and were
dead in the water despite the above.
Now, this also meant that there were folks carrying beepers and temp
keys, so they could do that after-hours support.
Are you prepared to deal with all this? Is it worth it?
As you can tell, I'm not a fan of such mechanisms. But it's not my
decision (doh), so I'm trying to help :-)
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
--
zMan -- "I've got a mainframe and I'm not afraid to use it"
...
--
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
