The Sterling Software division I worked for did this, on VM, not MVS. The CPUID
file was very robust, had in it:
- Soft expiration ("start warning")
- Expiration ("warn loudly")
- Hard expiration ("stop working")
The file could contain keys for multiple CPUs, so you didn't have to keep track
of which one was for which CPU, and if it read one that was expired, the parser
would keep reading. So while there was hygienic value in keeping the file
clean, it didn't hurt if you didn't. It also supported timed "emergency" keys,
that would run on any CPU. So the on-call person had a list of those, updated
every week (with a several-week timeout, so a missed update wasn't a crisis,
either). And of course a short-term key could be easily (and automatically)
generated for a given CPU serial number.
The CPUID consisted of human-readable hex groupings with blanks between them,
ignored extra/missing blanks, linends, blank lines, and comments, and was thus
easy to read over the phone, FAX, cut&paste, etc. All very civilized; aside
from the fact that customers would let things get to crisis state and call at
3AM Sunday, it worked very well.
(As opposed to another place I worked, where the CPUID for a Linux machine was
a human-readable blob of hex with no spaces-impossible to read reliably-and the
stupid thing that processed it insisted on no spaces and on Linux-style
linends, so if you got one emailed to you on Windows and FTPed it, it wouldn't
work until you dos2unix-ed it, which was just dumb. And it had no redundancy,
no tolerance for anything. Really, really irritating.)
ObAnecdote:
A friend once wandered into his data center (remember having one of those
nearby?) and looked at the operator's console, saw "<product WILL EXPIRE IN 3
DAYS! CONTACT STERLING SOFTWARE!"
He said something gentle along the lines of "What the *!#$&? Why are you
ignoring that?"
The operator glanced at it and said, "Oh, <product> always says that." Um, no -
only for the last 27 days!
I believe that operator was soon looking for a job. Or at least should have
been.
...phsiii
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
