Tom As for adding keys to your software, yes, I believe it's a good thing, but you have to remember that simply locking up your software really, really tight is not a good solution. They idea is to balance protecting your software but not putting the screws in so tight that the client can't use it properly.
It's really really easy to get the CPU serial number programmatically, and IBM even has a service you can call to get the machine information from an authorized or non-authorized environment. You can get it from COBOL as well as via C. As for protection, many vendors simply "scramble" the characters of the CPUID and the "expiration date" they want to assign among either a bunch of useless characters or keep single bytes all over the place within your program, then you get the CPU serial (and machine type information if you want to use that also), and the current date, then you simply compare the values you know (the CPUID and other data you authorized in your program), with the values you just got from the system you are executing on. If they don't match (serial number, etc.) then you can just send a message that you have expired or just end without saying anything (which is very unhelpful). Then if that matches, you compare the dates, and if it's within the end date you allowed, then you just go on as if nothing happened. If you are getting close to the date (i.e. the last 30 days) then you can put out a "warning" message that you will expire soon. You can (and probably should) add code to allow "grace" period. Now, if you want to get really fancy, you can take the information that you normally would have kept within your code, and instead place it in a key record (some encrypted record that you provide to the user to make available to your program, either in a dataset or as a parm to the execution. You program should then have some decryption code that checks the provided key information against the execution time information (CPUID, MACHINE Type, current date), just like the previous method, except that you have externalized the "key" and can replace it very easily for your client. The encryption method can be a secure one (128bit or 256 bit secure method or you can devise your own encryption code, even something as simple as inverting each character by some known amount and also having scrambled up the order of the information is probably more than enough to do what you want. After all, most sites are not really trying to steal your code, and besides a really concerted and smart person with enough time can break your encryption anyway, but the idea is really just to remove the temptation to keep copies of your code and/or sell them to other people. I have literally seen probably 100 (or more) different ways of implementing the code, and everyone has their favorites and everyone thinks that theirs is the best (but I know mine is), and there is no real "right" way to do it. If you need help setting up the code to get the information from the system during execution, let me know and I'll help you, as for coming up with the encryption code, you probably want to do that yourself so that you know that no one else will give your method away. But if you need help I can help you there as well. It's really very simple once you know where to get the information at run time. What you will notice is that once you are able to get the data from the system, it becomes more addictive and you will want to start getting things like the jobname of the job that is executing you, or the owning userid and such. The skys the limit once you start down that road. Just remember that you don't need to go overboard. You certain can if you want, but protection doesn't have to be overly complex to be effective. Brian ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN