Re: Ever see automatic 30-day trials for mainframe software?
You can take a look at a couple IBM examples for inspiration such as: - Enterprise COBOL Developer Trial - CICS Transaction Server for z/OS Developer Trial Another possibility available for certain types of products is to provide Internet access (preferably via an encrypted connection) to an evaluation system. Create an ID for the evaluator (or multiple IDs for multiple evaluators) and let them take a spin. Then disable the IDs after a warning period. That avoids much of the hassle of supporting evaluations. Watermarking (Licensed to ACME Corporation, Contract ACME001) is an interesting idea, though I think the best place to put watermarks is in logs, traces, dumps, etc. that a customer would sometimes submit for support purposes. I'm a big fan of sub-capacity licensing terms, and that tends to help support evaluations. Many potential customers are willing to license, say, 3 MSUs for one month for a relatively small amount of money before committing to 300 MSUs. If you've got the license agreement in place, it's then straightforward to increase the quantity on that basis. Timothy Sipples VCT Architect Executive (Based in Singapore) E-Mail: sipp...@sg.ibm.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Makes me curious of the lists opinion on if z/OS LPARs are usually able to contact an internet site, or are commonly isolated? I seem to have formed the impression that it's quite common to have a path out/in (typically via firewalling...) is that impression accurate? It would seem to me that having a product work during initialization, then contacting a license server using, say, the CPUID just as vendor keys often do, to see if this is a licensed install would potentially be an option too? Of course only useful where a network path to the provider is permitted so would be back to manual registration keys for those where it is not... And not suggesting that is hackproof either, and I note the anecdotes that some sites have done the wrong thing, although if they had to actively hack I suspect 'they' would pause. Enabling more automation through connectivity rather than the expiring keys that I also remember would seem a nicer solution. Thoughts? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Bill Soper wrote: It would seem to me that having a product work during initialization, then contacting a license server using, say, the CPUID just as vendor keys often do, to see if this is a licensed install would potentially be an option too? What will you do if your bread-and-butter system can't get working around 08:00 because the vendor or the route to the vendor is down? Your users are waiting and phones are ringing and you [only one with know-how] are on leave today... Of course only useful where a network path to the provider is permitted so would be back to manual registration keys for those where it is not... If contacting the vendor is futile, then use a temp key valid for few days. That temp can be downloaded periodically replacing the old temp. Good questions, but messy to apply... Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
This has been an interesting discussion. I understand why vendors lock software to specific machines and dates. Especially in the non-corporate world. But I had another evil thought. I wonder how many z/OS system exist which are not connected to the Internet. Not accessible to the Internet, but can access the Internet, to do things such as software delivery such as IBM's SMPE can do. Evil idea: 1) Have an execution key which encodes the valid CPUID and run date interval (upper and lower date). 2) If the key is good, just run - but tell the user if the key is going to expire within 30 days, via a nice WTO. 3) if the CPUID validates, but the date is expired: 3.1) IP connect to support site to log key expiration and then run normally. Don't tell the user anything. 3.2) if you can't connect to the support site the key expiration is less than 31 days, issue a strong warning via a WTO. 3.3) if you can't connect to the support site the key expiration is greater than 30 days, refuse to run. 4) if the CPUID is invalid the program _can_ IP connect to the vendor site. 4.1) Use GeoIP to validate the incoming IP's country of origin. 4.1.1) If in a good country, allow software to run. Vendor documents and sues user's company. 4.1.2) if in a bad country, execute nasty user code (see below) 5) if the CPUID is invalid the program cannot IP connect to the vendor site, execute nasty user code. Nasty user code: Write some code which burns some CPU, the amount to burn would need to be something that the nasty user would expect. Then go through a fairly long chain of branches (to complicate branch tracing), and finally abend with an S0C4-4 trying to overlay low core. If the user is indeed a thief, then what is the likelihood that they will have an expert which could resolve this problem? And they can't call your support because that would give them away. Evil quotient: too little; just right; too extreme. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 03/28/2014 07:39 AM, John McKown wrote: This has been an interesting discussion. I understand why vendors lock software to specific machines and dates. Especially in the non-corporate world. But I had another evil thought. I wonder how many z/OS system exist which are not connected to the Internet. Not accessible to the Internet, but can access the Internet, to do things such as software delivery such as IBM's SMPE can do. Evil idea: 1) Have an execution key which encodes the valid CPUID and run date interval (upper and lower date). 2) If the key is good, just run - but tell the user if the key is going to expire within 30 days, via a nice WTO. 3) if the CPUID validates, but the date is expired: 3.1) IP connect to support site to log key expiration and then run normally. Don't tell the user anything. 3.2) if you can't connect to the support site the key expiration is less than 31 days, issue a strong warning via a WTO. 3.3) if you can't connect to the support site the key expiration is greater than 30 days, refuse to run. 4) if the CPUID is invalid the program _can_ IP connect to the vendor site. 4.1) Use GeoIP to validate the incoming IP's country of origin. 4.1.1) If in a good country, allow software to run. Vendor documents and sues user's company. 4.1.2) if in a bad country, execute nasty user code (see below) 5) if the CPUID is invalid the program cannot IP connect to the vendor site, execute nasty user code. Nasty user code: Write some code which burns some CPU, the amount to burn would need to be something that the nasty user would expect. Then go through a fairly long chain of branches (to complicate branch tracing), and finally abend with an S0C4-4 trying to overlay low core. If the user is indeed a thief, then what is the likelihood that they will have an expert which could resolve this problem? And they can't call your support because that would give them away. Evil quotient: too little; just right; too extreme. I seem to recall a case where the vendor wanted to change contract terms at renewal in a way that was unacceptable to our corporate management and it took several months of negotiations past the formal expiration of license between our lawyers and theirs before a renewal agreement was finally reached. We had been a customer for at least a decade, had other products from the vendor, and it was clear it was in both party's interest that some agreement would eventually be reached; but we lived on temporary keys for several months. Any sort of automated validation system would have to be flexible enough to allow for unusual cases like this. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On Fri, Mar 28, 2014 at 9:06 AM, Joel C. Ewing jcew...@acm.org wrote: snip I seem to recall a case where the vendor wanted to change contract terms at renewal in a way that was unacceptable to our corporate management and it took several months of negotiations past the formal expiration of license between our lawyers and theirs before a renewal agreement was finally reached. We had been a customer for at least a decade, had other products from the vendor, and it was clear it was in both party's interest that some agreement would eventually be reached; but we lived on temporary keys for several months. Any sort of automated validation system would have to be flexible enough to allow for unusual cases like this. -- Joel C. Ewing, Bentonville, AR jcew...@acm.org Yes. I forgot to mention temp keys and DR keys which, if would guess, would be valid on _any_ processor until a given date, encoded in the key. Any valid key results in execution without IP connection to the outside world. I also like a previous poster's mention that a key file can contain any number of keys and the program will run quietly so long as at least one checks as valid. And, of course, stops checking keys once a valid keys is read. But all of this is just if the software is key locked. Personally, I don't like such. But, then again, I am an FSF member. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
It sure seems like Chicago-Soft has achieved a license mechanism for QuickRef with near-minimal inconvenience: On their website you specify a CPU and request a key(1). They send an email with a binary attachment. You transfer that attachment to a z/OS dataset on DASD. It's never taken me more than 5 minutes. (1) Since they don't currently offer trials, they perform some contract verification tasks before you can request the key. But that wouldn't be necessary for a trial. On those occasions where their lawyers and ours haven't seen eye-to-eye, they have still given me temporary 30 or 60 day keys until the i's get crossed and the t's get dotted. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On Fri, Mar 28, 2014 at 6:44 AM, Bill Soper sop...@au1.ibm.com wrote: Makes me curious of the lists opinion on if z/OS LPARs are usually able to contact an internet site, or are commonly isolated? There are some systems that are totally disconnected. Maybe 1-10%? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 3/26/2014 11:38 PM, Ed Jaffe wrote: On 3/26/2014 9:20 AM, Charles Mills wrote: Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. Our trial software expires n days after download. The key is stored in a load module. It would not be difficult to use the SHSCRIPT function of SMP/E to create a module in a z/OS UNIX directory with expiry date relative to install date. Food for thought for the future. :) However, I really don't like the idea of an expiry date relative to first execution. Implementation could get messy. Also, what about the shop that tries to locate the end date and zap it? You may say it doesn't happen but I have heard tales... -Steve Comstock -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Steve Comstock wrote: Also, what about the shop that tries to locate the end date and zap it? You may say it doesn't happen but I have heard tales... True. I also heard it via grapevine. Some software does integrity checks [CRC check?] on that date to prevent zapping. Rather, you can replace [1] a jump/branch to that part which examines that date, so no checking can be done at all. However, that will also fails if the checking part sets [sometimes periodically] a flag in memory which says I'm now licensed/legal and each functions of that software check that flag. There are self modifying code [on PC] which modifies the storage areas where the program is loaded and then in that storage the keys/dates/etc are only revealed/checked. So what is written in the program on disk is not always the same when loaded in memory. I think that self modifying trick can't be done with REUS=RENT programs except those in key=0 on z/OS. [2] Groete / Greetings Elardus Engelbrecht [1] - with some NOPs. [2] - debuggers can override it, even with REFRPROT set. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On Thu, Mar 27, 2014 at 12:38 AM, Ed Jaffe edja...@phoenixsoftware.comwrote: On 3/26/2014 9:20 AM, Charles Mills wrote: Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. Our trial software expires n days after download. The key is stored in a load module. It would not be difficult to use the SHSCRIPT function of SMP/E to create a module in a z/OS UNIX directory with expiry date relative to install date. Food for thought for the future. :) However, I really don't like the idea of an expiry date relative to first execution. Implementation could get messy. Much easier to have an expiry date relative to the download date. What occurs to me to do is have a customized module. The web site asks the person for the CPUID of the z machine. This is used to encrypt one of the CSECTs. The CPUID is also recorded on the vendor's site so that the application cannot simply be downloaded multiple times (limit to something like n times from the date/time of the first download for a maximum of n days, then deny another download for the same CPUID after those n days. The code would decrypt the CSECT at execution time using the running system's CPUID. Then validate some offset in the CSECT to make sure it has the proper eye catcher to validate that the decryption gave back the proper information. A different, worse?, way would be to distribute that CSECT as object code. At execution time decrypt the object code and invoke the Binder API to convert it on-the-fly into executable code. I don't know if the Binder API can do a load and go like this or not. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
John McKown wrote: I don't know if the Binder API can do a load and go like this or not. It can. You can invoke Binder from a program using ATTACH EP=IEWBLDGO and LOAD EP=IEWBLDGO. SubCapacity job does that similar thing. You use EXEC PGM=LOADER with your list of software used and a SYSLIN which contains a copy of the module in pre-formatted text lines. Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Speaking for myself only, I agree 100% with Phil. I HATE with a passion mainframe vendor software with license keys, codes, all the myriad ways they use to make my life difficult, adds work to my team, and puts my company at risk if a vital piece of our infrastructure fails for licensing problems. If it was up to me, when we do our software evaluation process, any product that has these restrictions goes to the bottom of the list of products that we're going to look at. Just my $.02 Mark Jacobs On 03/27/14 10:24, Phil Smith wrote: Steve Comstock wrote: Also, what about the shop that tries to locate the end date and zap it? You may say it doesn't happen but I have heard tales... OK, I know this is going to turn into a religious issue, but here's my $0.02. In 30+ years I've never seen this. I've seen ONE case where a customer was using licensed software illegitimately (on an extra CPU)-and that was an oversight: when it was recognized, it was a full-price bluebird for the sales rep, who was NOT unhappy at all. I realize there are issues with Certain Countries whose reputation suggests that such practices might be common, but without hard proof, I'm not inclined to invest a lot of effort-initial and ongoing-in a CPUID protection scheme; it just doesn't seem worth it. And if the alternative is that those countries simply wouldn't buy the software anyway, then it's really not a cost to the vendor. YMMV. Of course any sysprog worth his or her salt could hack such a scheme in minutes; this is the same as having unalarmed windows on your locked house: any thief who's interested can get in via a broken window. The question is whether it's also worthwhile to lock the front door and stop the casual intruder (and yes, I realize that seems to be arguing against my thesis-but locking your front door is low-cost and low-impact, as opposed to building, maintaining, and staffing 24x7 a CPUID mechanism). SAS C used to have a nice, simple scheme: the compiler would say SAS C LICENSED TO company whenever it ran. You could run it on the wrong CPU, but it would whine (I forget whether it also said Hey, dude, wrong CPU!). The theory (I assume) was that no serious company would run software that basically yelled Look! Stolen! every time, but in a pinch, you could get critical work done. Seemed elegant to me. As ever, I'd ask the question: What problem are you trying to solve with a CPUID scheme? That is, what's the REAL problem THAT YOU ARE HAVING? Or is it a theoretical problem? If the latter, consider the cost before investing: is your software so magical that it never needs support? If it does tend to need some support, then you'll find the cheaters eventually, and have 'em over a barrel price-wise... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN -- Mark Jacobs Time Customer Service Tampa, FL The quiet ones are the ones that change the universe... The loud ones only take the credit. Londo Mollari - Babylon 5 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Steve Comstock wrote: Also, what about the shop that tries to locate the end date and zap it? You may say it doesn't happen but I have heard tales... OK, I know this is going to turn into a religious issue, but here's my $0.02. In 30+ years I've never seen this. I've seen ONE case where a customer was using licensed software illegitimately (on an extra CPU)-and that was an oversight: when it was recognized, it was a full-price bluebird for the sales rep, who was NOT unhappy at all. I realize there are issues with Certain Countries whose reputation suggests that such practices might be common, but without hard proof, I'm not inclined to invest a lot of effort-initial and ongoing-in a CPUID protection scheme; it just doesn't seem worth it. And if the alternative is that those countries simply wouldn't buy the software anyway, then it's really not a cost to the vendor. YMMV. Of course any sysprog worth his or her salt could hack such a scheme in minutes; this is the same as having unalarmed windows on your locked house: any thief who's interested can get in via a broken window. The question is whether it's also worthwhile to lock the front door and stop the casual intruder (and yes, I realize that seems to be arguing against my thesis-but locking your front door is low-cost and low-impact, as opposed to building, maintaining, and staffing 24x7 a CPUID mechanism). SAS C used to have a nice, simple scheme: the compiler would say SAS C LICENSED TO company whenever it ran. You could run it on the wrong CPU, but it would whine (I forget whether it also said Hey, dude, wrong CPU!). The theory (I assume) was that no serious company would run software that basically yelled Look! Stolen! every time, but in a pinch, you could get critical work done. Seemed elegant to me. As ever, I'd ask the question: What problem are you trying to solve with a CPUID scheme? That is, what's the REAL problem THAT YOU ARE HAVING? Or is it a theoretical problem? If the latter, consider the cost before investing: is your software so magical that it never needs support? If it does tend to need some support, then you'll find the cheaters eventually, and have 'em over a barrel price-wise... ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
A bit OT for this, but I buy e-books (PDF) from a publisher who has some really good stuff. It is not DRM'ed. But what the publisher does is take my order on the Web. And I must pay for it with a credit card. No big deal. But that means that he knows my name. A short time later, I get an email with a URL to download my book(s). And on each page of that book is a lower border which says somthing like: This book was purchased by John McKown for his use. Please don't steal! No, it won't stop a criminal. But, really, how many criminals are going to buy a customized book and resell it? Especially a technical programming book. I think it is rather clever. -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
W dniu 2014-03-27 15:37, Mark Jacobs pisze: Speaking for myself only, I agree 100% with Phil. I HATE with a passion mainframe vendor software with license keys, codes, all the myriad ways they use to make my life difficult, adds work to my team, and puts my company at risk if a vital piece of our infrastructure fails for licensing problems. If it was up to me, when we do our software evaluation process, any product that has these restrictions goes to the bottom of the list of products that we're going to look at. Agreed. Two points: 1. IBM does not use license keys. Even for products from aquisition. 2. Who do use mainframes? Usually large companies (*). I doubt that any serious company would want to run unlicensed software. (*) Exceptions apply. I know private person having parallel sysplex. Just for fun. Legal. (very small machines, z/OS.e) -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Ever see automatic 30-day trials for mainframe software?
It is common in the PC world for software to be offered for a 30-day trial that works automatically. You download the software, install it, and it somehow knows when it was installed and quits 30 days later unless purchased. Typically, it knows by hiding some magic file or registry entry somewhere that has the original install date. On the mainframe side, I don't think I've ever seen an automatic 30-day trial, largely because magic hidden files are of course greatly frowned upon in this space. Mainframe 30-day trials in my experience require vendor administration to generate some sort of 30-day key. Obviously, there would be advantages to a vendor if they could offer a freely-downloadable trial of mainframe software that expired automatically. No one is going to install mainframe software on a whim, but eliminating the administrative burden of issuing a 30-day key has a distinct advantage. (Please, let's for the sake of argument not digress into the are keys good or bad? debate. For certain mainframe software, keys are here to stay, like it or not, and that's a different topic.) Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) Thanks, Charles -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
I just happen to be installing a SAS upgrade as I am writing. A (90 day) temp key is provided (with the distribution - no request needed) to support the installation (SAS used to install SAS). On/before the end of that period a regular perm key must be installed. snip Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Charles Mills wrote: It is common in the PC world for software to be offered for a 30-day trial that works automatically. You download the software, install it, and it somehow knows when it was installed and quits 30 days later unless purchased. Typically, it knows by hiding some magic file or registry entry somewhere that has the original install date. They're also called 'nagware'. They're nagging constantly, interrupting your work, with 'buy me' prompt or something like that. Some of those software were really clever that if you adjust your clock, they will disable themselves properly... On the mainframe side, I don't think I've ever seen an automatic 30-day trial, largely because magic hidden files are of course greatly frowned upon in this space. Mainframe 30-day trials in my experience require vendor administration to generate some sort of 30-day key. True. You get also temp keys for DRP or switch over to new footprint. Whatever it is, you have to involve your vendor. Obviously, there would be advantages to a vendor if they could offer a freely-downloadable trial of mainframe software that expired automatically. No one is going to install mainframe software on a whim, but eliminating the administrative burden of issuing a 30-day key has a distinct advantage. Indeend! I really would like that, but over the years I never see such animals. It is either licensed (vendor supplied) or freebies at your own extreme risk (CBTTAPE for example). ... For certain mainframe software, keys are here to stay, like it or not, and that's a different topic. The more expensive the software, the more weird are the keys and the [slow, slower, slowest] administration of it. ;-D Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) No. Never. But I wonder about IBM-MAIN members own software. How are THEY working with licensing and key management? Groete / Greetings Elardus Engelbrecht -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
The CICS Betas released over the last few releases (I believe betas were/are available for 4.2, 5.1 5.2) have built in expiry dates. IBM states that the betas Contain a disabling device that will prevent it from being used after the test period ends. http://www-01.ibm.com/software/htp/cics/openbeta/ -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Charles Mills Sent: Wednesday, March 26, 2014 10:36 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Ever see automatic 30-day trials for mainframe software? It is common in the PC world for software to be offered for a 30-day trial that works automatically. You download the software, install it, and it somehow knows when it was installed and quits 30 days later unless purchased. Typically, it knows by hiding some magic file or registry entry somewhere that has the original install date. On the mainframe side, I don't think I've ever seen an automatic 30-day trial, largely because magic hidden files are of course greatly frowned upon in this space. Mainframe 30-day trials in my experience require vendor administration to generate some sort of 30-day key. Obviously, there would be advantages to a vendor if they could offer a freely-downloadable trial of mainframe software that expired automatically. No one is going to install mainframe software on a whim, but eliminating the administrative burden of issuing a 30-day key has a distinct advantage. (Please, let's for the sake of argument not digress into the are keys good or bad? debate. For certain mainframe software, keys are here to stay, like it or not, and that's a different topic.) Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) Thanks, Charles -- 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
Re: Ever see automatic 30-day trials for mainframe software?
Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mullen, Patrick Sent: Wednesday, March 26, 2014 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ever see automatic 30-day trials for mainframe software? The CICS Betas released over the last few releases (I believe betas were/are available for 4.2, 5.1 5.2) have built in expiry dates. IBM states that the betas Contain a disabling device that will prevent it from being used after the test period ends. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 26 March 2014 12:20, Charles Mills charl...@mcn.org wrote: Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. It depends to a great extent on the nature of the product. If it contains/provides its own database of some sort, then there's no need for a magic hidden file; it can just store the key info and install date in some obscure corner of the database. Likewise, if the program is APF authorized by its nature, there are plenty of legitimate places it can store the info - most obviously in the security system, and as dataset or file metadata. But it all depends on what you're trying to accomplish. I imagine it's a matter of convenience for you and prospective customers. But if you are seriously worried about unauthorized use (say, beyond the time of a trial), then there are all sorts of other considerations that have been discussed at some length here in the past. These days even the act of hiding key and data info somewhere may provide you (in the US, at least) with a DMCA stick to threaten your customers with should they attempt to figure out where and how you've hidden things. But I'm sure you wouldn't want to even think of that. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
Haven't seen anything. Possibilities would be a date in the program and if past that date the program stops. Site would need to keep updating the download to reflect a later date. Or detect the create date of the library the program is installed in, or save the install date into a member, possibly store as packed data or time stamp to hide the value. On Wed, Mar 26, 2014 at 11:20 AM, Charles Mills charl...@mcn.org wrote: Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Mullen, Patrick Sent: Wednesday, March 26, 2014 9:07 AM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ever see automatic 30-day trials for mainframe software? The CICS Betas released over the last few releases (I believe betas were/are available for 4.2, 5.1 5.2) have built in expiry dates. IBM states that the betas Contain a disabling device that will prevent it from being used after the test period ends. -- 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
Re: Ever see automatic 30-day trials for mainframe software?
W dniu 2014-03-26 16:36, Charles Mills pisze: [...] Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) Yes. How does it work? It depends, I've seen various methods. One of them is to record some data in magic file. -- Radoslaw Skorupka Lodz, Poland --- Tre tej wiadomoci moe zawiera informacje prawnie chronione Banku przeznaczone wycznie do uytku subowego adresata. Odbiorc moe by jedynie jej adresat z wyczeniem dostpu osób trzecich. Jeeli nie jeste adresatem niniejszej wiadomoci lub pracownikiem upowanionym do jej przekazania adresatowi, informujemy, e jej rozpowszechnianie, kopiowanie, rozprowadzanie lub inne dziaanie o podobnym charakterze jest prawnie zabronione i moe by karalne. Jeeli otrzymae t wiadomo omykowo, prosimy niezwocznie zawiadomi nadawc wysyajc odpowied oraz trwale usun t wiadomo wczajc w to wszelkie jej kopie wydrukowane lub zapisane na dysku. This e-mail may contain legally privileged information of the Bank and is intended solely for business use of the addressee. This e-mail may only be received by the addressee and may not be disclosed to any third parties. If you are not the intended addressee of this e-mail or the employee authorized to forward it to the addressee, be advised that any dissemination, copying, distribution or any other similar activity is legally prohibited and may be punishable. If you received this e-mail by mistake please advise the sender immediately by using the reply facility in your e-mail software and delete permanently this e-mail including any copies of it either printed or saved to hard drive. mBank S.A. z siedzib w Warszawie, ul. Senatorska 18, 00-950 Warszawa, www.mBank.pl, e-mail: kont...@mbank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237, NIP: 526-021-50-88. Wedug stanu na dzie 01.01.2014 r. kapita zakadowy mBanku S.A. (w caoci wpacony) wynosi 168.696.052 zote. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
I once did this with a VSE software product. However, when I created the z/OS version of that product I decided the advantage of the automatic trial period was just not worth the risk in an MVS environment. There are easy enough ways to determine when something has been installed for a period of time, but the trick is to be able to determine that when the product is completely reinstalled. The current date can be checked against something like the creation date in a library DSCB or a PDS directory entry stat. But, the real problem is that you need to leave some track that will persist beyond the complete removal of the product and a reinstall from scratch. That is a big problem in a secure environment, and if you do find a way it would be still be considered unethical by most people. I don't know what type of product you are considering this for but something else to consider is the competitors for the product. Some product areas see very fierce competition. I also ran into the situation where a competitor downloaded my product and ran it on their system with the automatic trial period. I quickly lost my enthusiasm for that technique. All in all, in my opinion it is just not worth it. Authorization keys are a necessary evil for most ISVs but the tricks you would have to play to automate it and still maintain control are not worth the potential problems. Chuck Arney Arney Computer Systems Web: http://zosdebug.com Facebook: http://www.facebook.com/arneycomputer -Original Message- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of R.S. Sent: Wednesday, March 26, 2014 3:15 PM To: IBM-MAIN@LISTSERV.UA.EDU Subject: Re: Ever see automatic 30-day trials for mainframe software? W dniu 2014-03-26 16:36, Charles Mills pisze: [...] Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On Mar 26, 2014, at 10:36 AM, Charles Mills wrote: Has anyone ever seen mainframe software that automatically expired 30 days after installation? If so, any rough idea how that worked? (Presumably, not a magic hidden file LOL.) Charles: I have. Its *USUALLY* hidden in the key . Its been a while so I cannot remember exact cases. At one time (IIRC) it took an IPL to update the key. I am pretty sure that has been eliminated. As to Good/Bad it really depended on the product. *SOME* products are an easy install, others take 30 days just to read the installation manual. Then there are what I call throw away products. They are just that, throw away (I won't go into names). Those are a waste of time IMO and e shouldn't be discussing them on here. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 27/03/2014 2:36, Charles Mills wrote: On the mainframe side, I don't think I've ever seen an automatic 30-day trial, largely because magic hidden files are of course greatly frowned upon in this space. Mainframe 30-day trials in my experience require vendor administration to generate some sort of 30-day key. The idea of magic hidden files might be frowned upon, but I think that is more due to the description. If you store data for use by your program in an obscure location, using standard, documented interfaces I don't see it as a problem. I worry more about software requiring authorized libraries and software that installs hooks into system services than software that might store a piece of data somewhere for its own use. The difficlty is working out a location that would work on all customer systems. An idea might be something along the lines of storing a date and hash into the application load library on installation, then storing a hash of the hash somewhere in storage on first run so that if you reinstalled you also had to re-IPL (or find and delete the stored value). The aim is not to create something foolproof and unhackable, it is really to remind the customer that they are supposed to be paying for the software, and make it at least inconvenient to bypass. PC 30 day trials are similar - you can probably use registry monitors etc. to find where the data is stored and delete it, and some people might do that, but the aim is to remind the honest customer to purchase. I think the real reason most mainframe software requries you to contact the vendor for a trial is price. With high prices comes the assmption that a sales person will be involved (and vice versa - if a sales person is involved prices need to be set at a level that will support them!) The last thing sales people want is to have people interested in the software, but not know who they are. So the real reason for having to contact the vendor and request a key is to provide a lead for a sales person - not because of technical difficulties implementing a trial period. Andrew Rowley -- and...@blackhillsoftware.com +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
The Sterling Software division I worked for did this, on VM, not MVS. The CPUID file was very robust, had in it: - Soft expiration (start warning) - Expiration (warn loudly) - Hard expiration (stop working) The file could contain keys for multiple CPUs, so you didn't have to keep track of which one was for which CPU, and if it read one that was expired, the parser would keep reading. So while there was hygienic value in keeping the file clean, it didn't hurt if you didn't. It also supported timed emergency keys, that would run on any CPU. So the on-call person had a list of those, updated every week (with a several-week timeout, so a missed update wasn't a crisis, either). And of course a short-term key could be easily (and automatically) generated for a given CPU serial number. The CPUID consisted of human-readable hex groupings with blanks between them, ignored extra/missing blanks, linends, blank lines, and comments, and was thus easy to read over the phone, FAX, cutpaste, etc. All very civilized; aside from the fact that customers would let things get to crisis state and call at 3AM Sunday, it worked very well. (As opposed to another place I worked, where the CPUID for a Linux machine was a human-readable blob of hex with no spaces-impossible to read reliably-and the stupid thing that processed it insisted on no spaces and on Linux-style linends, so if you got one emailed to you on Windows and FTPed it, it wouldn't work until you dos2unix-ed it, which was just dumb. And it had no redundancy, no tolerance for anything. Really, really irritating.) ObAnecdote: A friend once wandered into his data center (remember having one of those nearby?) and looked at the operator's console, saw product WILL EXPIRE IN 3 DAYS! CONTACT STERLING SOFTWARE! He said something gentle along the lines of What the *!#$? Why are you ignoring that? The operator glanced at it and said, Oh, product always says that. Um, no - only for the last 27 days! I believe that operator was soon looking for a job. Or at least should have been. ...phsiii -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
In 3253568952062076.wa.elardus.engelbrechtsita.co...@listserv.ua.edu, on 03/26/2014 at 10:55 AM, Elardus Engelbrecht elardus.engelbre...@sita.co.za said: They're also called 'nagware'. They're nagging constantly, Those are the ones that I decide not to buy. interrupting your work, The smart vendors whine when you initially start the application and then leave you alone until the next time you start it; oddly enough, those are usually the ones that I decide are worth buying. I've also had products that I couldn't evaluate adequately within the permitted period; the vendor invariably gave me an extension and in every case that I recall ultimately got my money. Some of those software were really clever that if you adjust your clock, they will disable themselves properly... If I have to go through that much hassle, the evaluation is over - thanks but no thyanks. True. You get also temp keys for DRP or switch over to new footprint. Whatever it is, you have to involve your vendor. ObPogo Alas, sometimes the problem is not the vendor. It is either licensed (vendor supplied) or freebies at your own extreme risk (CBTTAPE for example). Paying for software is no guaranty of adequate support, and some of the best software support that I have gotten has been for free software. Thank you, Bruce and all the others. -- Shmuel (Seymour J.) Metz, SysProg and JOAT ISO position; see http://patriot.net/~shmuel/resume/brief.html We don't care. We don't have to care, we're Congress. (S877: The Shut up and Eat Your spam act of 2003) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On Mar 26, 2014, at 6:44 PM, Andrew Rowley wrote: On 27/03/2014 2:36, Charles Mills wrote: On the mainframe side, I don't think I've ever seen an automatic 30-day trial, largely because magic hidden files are of course greatly frowned upon in this space. Mainframe 30-day trials in my experience require vendor administration to generate some sort of 30-day key. The idea of magic hidden files might be frowned upon, but I think that is more due to the description. If you store data for use by your program in an obscure location, using standard, documented interfaces I don't see it as a problem. I worry more about software requiring authorized libraries and software that installs hooks into system services than software that might store a piece of data somewhere for its own use. Andrew: This is not quite the same but something remotely similar. A LONG time ago (GT 40) years a vendor who thought he as clever needed to store a jobname in low memory. This was fine except MVS needed 2 PSA's (or more) so the the problem arose that you had to assemble the nuc with a DC of 640 ((max 80 job names). At the beginning it was OK. e started having issues when the #'s of UCB's reached over 1200 (or some number my memory is fuzzy here). Then to add to the issue the product did not always clear the entry in the table and it would fill up if we didn't IPL for a few days. One of the sysprogs had to write a program to see if the job was still running and if not clear the entry. We had major management screaming at us as they couldn't order any more DASD and operations screaming at us because of the JOBNAME issue. We just old them to talk to the vendor as we didn't write the code. I think the vendor finally fixed the jobname issue as the problem seem to disappear after maintenance but the UCB was a PIA for quite some time as we seemed to be the only customer ho complained. The vendor as little if any help. CA bought them out 2 years or so later. Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 27/03/2014 14:40, Ed Gould wrote: This is not quite the same but something remotely similar. A LONG time ago (GT 40) years a vendor who thought he as clever needed to store a jobname in low memory. That's why I specified using standard, documented interfaces. It might be as simple as name/token services. I'm not sure what options you have to store something that lasts longer than the address space if you are not APF authorized, but in that case you shouldn't be able to do damage either. There are many products out there that hook into the systems in ways that are not documented or supported by IBM to perform thier core functionality. This is equally as dangerous (or more) than something simply storing a value somewhere. Most sysprogs would have some experience with one or another vendor product causing a problem with its hooks. That core function is probably more reason to be cautious with an evaluation than the method of tracking the evaluation period. Andrew Rowley -- and...@blackhillsoftware.com +61 413 302 386 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
Re: Ever see automatic 30-day trials for mainframe software?
On 3/26/2014 9:20 AM, Charles Mills wrote: Right. Good input. Thanks. I have shipped software with a hard-coded expiration date. What I am looking for is a floating expiration date that would be 30 days after installation, whether installed today or a year from today. Our trial software expires n days after download. The key is stored in a load module. It would not be difficult to use the SHSCRIPT function of SMP/E to create a module in a z/OS UNIX directory with expiry date relative to install date. Food for thought for the future. :) However, I really don't like the idea of an expiry date relative to first execution. Implementation could get messy. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
