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
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
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
On Tue, 6 Mar 2018 21:02:37 +0000, Savor, Thomas (Alpharetta)
>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
>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.
>For IBM-MAIN subscribe / signoff / archive access instructions,
>send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN