Sam I would suggest a license key based on company/product name and date *only*.
CPUid schemes are such a PITA to administer for both customer and vendor. Using expiration dates and sufficiently load warning messages (eg WTOs, prompts in the UI) as the expiration date approaches keeps 99.99% of customers paying the bill on time. Rob Scott Lead Developer Rocket Software 275 Grove Street * Newton, MA 02466-2272 * USA Tel: +1.617.614.2305 Email: [email protected] Web: www.rocketsoftware.com -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Sam Siegel Sent: 26 December 2011 21:20 To: [email protected] Subject: Re: cpu / machine identification 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" > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send > email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
