(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"
