Simulating the CPUID may violate the license agreement. If you're going to use 
keys, explicitly address the issue.

Shmuel (Seymour J.) Metz

From: IBM Mainframe Discussion List <> on behalf of 
Brian Westerman <>
Sent: Wednesday, March 7, 2018 12:57 AM
Subject: Re: Product license key program

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 

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.


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

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

Reply via email to