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
