Don't forget about sites needing to replace a mainframe with a newer
model, or upgrading their existing hardware to faster processors or
more processors within the unit (I.E. same device type but different

On Tue, Mar 6, 2018 at 11:57 PM, Brian Westerman
<> wrote:
> The problem with just using a date, is that the software could be moved to 
> any machine and duplicated any number of times and you would never know about 
> it to keep it from being unlawfully duplicated without payment.
> This doesn't mean that you don't trust your clients.  In effect, while some 
> might argue, it's really just like locking your car or your home or having a 
> bike lock.
> Lets say that you generate your software and the people at company "X" pay 
> the license until January of 2020.  In the mean time, 40 people who used to 
> work for company "X", decide that it's soooo good that they want to take it 
> to their new site with them.  That would be great if you got revenue from 
> that movement, but you can't unless they call you and tell you that they 
> moved the software and their "new" company would like to license it.  Also, 
> maybe the people at company "X" decide that they want to defray the cost of 
> the software they licensed from you, so they sell copies on the internet to 
> other sites.  It will run until January of 2020, so there is nothing to keep 
> it from happening.  I'm not saying that every client is dishonest, but it 
> only takes one person to make it bad for you.  Admittedly, this is probably a 
> bit far fetched, but it's late and I'm tired. :)
> On the other hand, if you had a check in your module for the CPU Serial 
> number, (and machine type or LPAR name, or any of several limiting factors), 
> the client is in no way harmed or inconvenienced, because it will operate as 
> before with no impediments, save that the software can't be "moved" without 
> your permission.
> This should not cause any problems with DR testing or a real disaster because 
> most, (if not all) DR sites run under VM and will simulate the serials and MT 
> for just this purpose.  You can also check for running under VM and disallow 
> it (or generate warnings), but that is not normally necessary and gets away 
> from the point I'm making.
> Also, your key code needs to take into account that the site might have 
> multiple physical processors (separate mainframes), so you want to make sure 
> that your "key" code supports multiple entries.  This will also be useful for 
> those sites that use "friend" arrangements for their DR sites (other 
> companies who share each other's sites as Disaster Recovery sites for each 
> other).
> You can/should also add code that temporarily allows the product to function 
> when the key doesn't match, for use as a trial or for when "stuff" happens 
> that the site for some reason needs to use the code on another box 
> "temporarily".  You can limit it for a period of time, or number of uses, or 
> whatever you think is reasonable, it's your software, you make the rules, 
> while generating messages that let the site know in no uncertain terms that 
> the the license is not "currently valid".
> There are lots of nice features you can add to the key process, and you can 
> do as many vendors have and set up a web page to generate "emergency" keys 
> for, well.... emergencies.  The reason is because "stuff happens" and no one 
> is happy if the product can't be used for some reasonable reason and they 
> can't contact the vendor until the next day because no one happens to be on 
> call that night.
> If you are going to implement keys, you might as well do it right and make 
> sure you test-test-test the process before you send it out to your client(s). 
>  It's a good way to lose them if you mess up something like this.  All sites 
> will understand the necessity of you having keys in your software, but no one 
> will understand if it isn't rock solid.  It's such a little nit to implement 
> correctly, but all it takes is one error in the key generation program to 
> ruin your day.
> Brian
> On Tue, 6 Mar 2018 21:02:37 +0000, Savor, Thomas (Alpharetta) 
> <> wrote:
>>Never thought about Using CPUID and/or machine type as part of a software key.
>>Generally speaking we try to stay away from tying application to any kind of 
>>Our application is typical Cobol/Asm, Batch/CICS and VSAM/DB2 system.
>>Cobol 5 was first change in years that required major changes to our 
>>Usually a change to the Operating System has no effect on application 
>>executing properly.
>>But having said that, since I didn’t know really what makes up a key and how 
>>they work, this is an interesting change in direction and thinking.
>>Thanks for the ideas.
>>And thanks for the ofrer of help....I will almost certainly need it.
>>Tom Savor
>>For IBM-MAIN subscribe / signoff / archive access instructions,
>>send email to with the message: INFO IBM-MAIN
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to with the message: INFO IBM-MAIN

Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?

For IBM-MAIN subscribe / signoff / archive access instructions,
send email to with the message: INFO IBM-MAIN

Reply via email to