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 model).
On Tue, Mar 6, 2018 at 11:57 PM, Brian Westerman <brian_wester...@syzygyinc.com> 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) > <thomas.sa...@fiserv.com> wrote: > >>Brian, >> >>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 >>machine. >>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 >>application. >>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. >> >>Thanks, >> >>Tom Savor >> >>---------------------------------------------------------------------- >>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 -- 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
