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" ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
