Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 21:46:08 -0600 Rick Fochtman [EMAIL PROTECTED] wrote: :-snip-- :I worked at a small financial services company where the sysprog :disabled the SYNCSORT key code. :It eventually came back to bite him and he was asked to leave. :unsnip- :Rightly so. But don't blame the company for one renegade employee. Then don't blame all ISV's because of some renegade ISV's. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 16:50:04 -0600 Joel C. Ewing [EMAIL PROTECTED] wrote: :Binyamin Dissen wrote: : On Sat, 24 Feb 2007 20:25:24 -0600 Joel C. Ewing [EMAIL PROTECTED] wrote: : :Particularly in the case of processor upgrades, or in DR, there is no : :reliable way for us to verify that new keys from the vendors are correct : :and correctly installed until we are running on the new processor. If : :they aren't and a hard failure results, there is a high likelihood that : :this failure will be seen in some way by the end users, even if the : :vendor key support is 24x7. : In the case of a processor upgrade: if you get a hard error during production : due to a bad ISV key, your testing criteria are way too lax. :Really? Explain how one tests a dynamic CPU upgrade consisting of IBM :non-disruptively turning on one or more CP's on your only production :processor complex. At least 75% of our upgrades are now of this nature. That causes a change in the CPU id? Live and learn. : Depending on what the vendor product is examining and how often it :checks, it either sees an instantaneous change in production of the :processor type at the time the new CP is enabled, or it sees that change :when some vendor-specific future event (possibly the next IPL, POR, etc) :occurs. There is no way to reliably test the new keys in advance, even :if the product allows installing the new keys in advance. When :changing to a completely new processor box, it is certainly desirable :and generally possible to have an overlap and have the new machine as a :test bed for new keys, but I can envision cases where there would be :unavoidable constraints that would prevent that overlap (and have lived :through some major push-pull scenarios with no overlap). : In the case of DR: if you do test runs, you will be quite aware of this issue. : If you never do test runs, refer to the processor upgrade above. If you do : not test, this is not likely to be your only problem. Or a major one. :Vendors can always change their key validation logic with maintenance :and release changes and our mix of ISV products drifts as well. Always important to redo the DR test after significant changes (for some value of significant). : Some :products fail without new keys on a DR processor only when running :without VM; others fail in all cases. When we find a vendor product :that has key validation problems at DR testing, the resolution for that :product gets incorporated into our DR procedures. That we have :occasionally encountered new failures in the past during DR testing :tells us there is always the potential for an unexpected failure at an :actual DR. DR testing reduces the exposure, but cannot eliminate it. Granted. : :While I can understand the vendors concerns, my goal is to focus on our : :own system reliability and the needs of our end users; and any hard : :failures in ISV products are an enemy of that goal. : First, work on what you can change - get your accounting people up to speed. : Keep track of the ISV products and expirations, and follow up on them. :Our accounting people have never been a problem, neither have we had any :significant problem tracking ISV product expirations. The problem is :that we do not work in a static environment. It has been contract :negotiation and the reluctance of vendors to adapt reasonably to :changing hardware/software environments that has been the greatest :source of problems, especially when hardware upgrades are to support :application growth that is unrelated to the vendor's product! : Improve those test procedures. :See above. : Am I a little harsh? Perhaps. :A vendor only has to deal with the familiar idiosyncrasies of his own :product's key management. On the customer side we have to deal the :unfamiliar and changeable idiosyncrasies of many vendor products. : Yes, you would like to not have to worry about the ISV key, and the ISV would : love not having to worry about collecting. : But you should be aware that there is a bit of a partnership here. :Granted. Perhaps a vendor should cut much more slack with a company :that has been a consistent paying customer for years by selectively :making key management less onerous for such customers. I am sure they do. Do not vendors supply a means for customers to get an unrestricted full-use temporary key (expires within a week - or less?) to handle the DR bumps in the road? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe /
Re: License keys for ISV products(What alternatives are there?)
Ted, Why are you being willfully ignorant? I have already posted my own personal stories of dealing with one large customer (a major government entity, in fact) who willfully violated their license by running my product on more CPUs than permitted. I have already explained realistic scenarios whereby licensing violations can occur unintentionally. Yet you persist in making such ridiculous statements as those below! The issues are far more diverse than the strawman raised in your second sentence. The world is far more diverse than that seen by your own personal experiences and vision. You need to find some time to buy some gas. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 At 2/25/2007 03:32 PM, TMacNeil wrote: If it were not for keys, some customers wouldn't pay on time (or wouldn't pay at all). THAT is my point of disagreement! Most shops that are mainframe shops are large companies. Large companies do NOT want their names in the press. Ergo, they will do everything they can to pay on time. Yes, we have process problems, but so do the vendors. We have a gross revenue of $30BUS, net of $1.3BUS. Do you think we are going to dick you around for even a $50K contract? Call the press and tell them! But, no, the vendor would rather complicate our environment, introduce single points of failure, and make us look for alternatives. WHICH we are doing! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
At 2/26/2007 03:09 AM, BDissen wrote: :Really? Explain how one tests a dynamic CPU upgrade consisting of IBM :non-disruptively turning on one or more CP's on your only production :processor complex. At least 75% of our upgrades are now of this nature. That causes a change in the CPU id? Live and learn. It causes a change in the model number byte. The machine type and the lo-order four digits of the serial number remain unchanged. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Then don't blame all ISV's because of some renegade ISV's I find it the other way around! The renegades are the ones that make it easy to use. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Do not vendors supply a means for customers to get an unrestricted full-use temporary key (expires within a week - or less?) to handle the DR bumps in the road? Not all. Not enough! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Sunday, February 25, 2007 7:58 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) Would be great if all invoices were paid on time. Would be great if vendors delivered working keys all the time! Would be great if vendors were available 7-24! Neither of the two above have anything to do with timely payments. AND, the scenario I proposed, I lived through. Without naming names, the product in question only had two vendors and one was a work-alike for another. Both vendors have/had M-F/9-5 support. Keys failed on a weekend. Company works in many time-zones. Support didn't. Bill was payed. Keys failed. As I said: Now what? What I did at another site? I reverse engineered their stupid security and basically TURNED IT OFF. Of course, this was pre-DMCA and before the vendors got sticker about reverse engineering or dumping of their code in their licenses. Ah! for the good old days (which really were out numbered by the bad old days). -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Sunday, February 25, 2007 11:04 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) -snip--- I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. --unsnip--- You'd be amazed at the number of vendors that will NOT provide support outside the 9-5 M-F window. I even had a vendor rep hang up on me in the middle of a call because it was now 5:00 PM where he was. Some of those (unprintables) are unionized and unions havee INCREDIBLE power here. Needless to say, our business relationship with that particular vendor ended the next day. We learned how to manage without his package and saved ourselves a bundle of $$$ besides. Names deleted to protect the incompetant. And stoopid!! Had the same problem, likely with another vendor. His train left the station at 5:00 pm Eastern time. He would leave in order to catch his train, even in a sev 1 situation. The company's response was to 1.5 hours for him to get home and they would conference him in. Yes, he was the ONLY person in the company who could help with debugging a problem. And the SOBs would NOT give the source so that I could fix it. And I could have. My joy in this is that he has retired and the company no longer supports direct VTAM communications. And instead of rewriting the mainframe software to use the new SOA interface, they decided to let the experts in the Windows development here do it. They are still cursing and writing work around to bugs in the vendor's interface. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
As for the ad hominem attack about 'willfully ignorant', that I'm NOT. I'm willfully ticked off! I hear all these great schemes that vendors have to manage keys. I'd like to actually see one in action; none of ours do that. As for the stories of large customers that deliberately duck payments; I've never worked for one. And, my last point: Key management is a night-mare. 9-5/M-F doesn't help. You add complexity into an already complex environment. Your product has to be the only one available before I would recommend it, if it has keys. There are too many ways for this to fail, and the fact that other vendors have better solutions is irrelevant. That being said, I still disagree with keys. And, I shall not be responding to any more posts on this. Let the others that disagree post their comments. I've said my fill; I am not going to repeat myself ad nauseum! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Binyamin Dissen Sent: Sunday, February 25, 2007 12:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) On Sun, 25 Feb 2007 18:09:27 + Ted MacNEIL [EMAIL PROTECTED] wrote: :I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. :ITYM one off. :Objected, no. :Refused, yes! Even to support installing the product off hours? If so, I am quite amazed. Have you never worked with an vendor who is effectively a Monopoly? They tell you to bend over and you do it because you have NO CHOICE IN THE MATTER. Yes, there are vendors and niche products like that. I've worked with one. Thankfully, I do longer do. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Sadly, though, this type of cheapskate behavior was SOP there. Most 30-day net invoices were paid around 45 days. I bailed after 2 years when I got a sysprog job. -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Rick Fochtman Sent: Sunday 25 February 2007 19:46 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) -snip-- I worked at a small financial services company where the sysprog disabled the SYNCSORT key code. It eventually came back to bite him and he was asked to leave. unsnip- Rightly so. But don't blame the company for one renegade employee. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(Cole Software's view)
Sorry -- I should have specified not utterly insane unified license key scheme. Jon snip It was called ILM (IBM License Manager). The project crashed and burned. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-snip- Perhaps the problems with keys need to be made painful to a sales person from a problem vendor? If they don't get they point, I'm sure that there are a few enterprising souls that will do the job, and possibly at a lower cost with much more responsiveness to customer issues. After all, how many out of work developers are there that have announced that fact on this news group since January (07)? ---unsnip- Baseball bats for sale; barbed wire wrapping optional. That seems to be the only form of persuasion some of these sales types understand. Alternatively, put them on commission, or partial commission, and dock them for customer complaints! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
Then you have the case of a government entity where you cannot even start the process for a new fiscal year until after the first day of the new fiscal year. If the product license expires on the fiscal year boundary, the chance of getting the entire renewal process completed in 30 (or 40) days is very slim. David Mueller | Systems Programmer -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Tuesday, February 20, 2007 8:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there? Receiving Timely Payments At Cole Software, our own experience is that once a Purchase Order has been cut and an Invoice accepted, by far the majority of our customers pay within 30 days. Occasionally, it might take 40 days, but it doesn't matter. As far as I'm concerned, that's close enough. As a person with a programming background, I didn't know much about account payment procedures. I used to think, hey I send the invoice, I get payment. Simple, right? Wrong! Most accounting departments won't even accept an invoice unless they already have a Purchase Order to match it up to. And to get an accounting department to generate a purchase order, you've got to get another department (our actual customer, the programming department) to generate a Request for Purchase Order (RPO). And all this takes time and for some companies a lot of hand holding on our part. The trick is to get the RPO-PO-invoice freight train rolling early enough so that the A-P Department will accept our invoice early enough that we can get paid reasonably close to the lease expiration date. This is where our Accounts Receivables department plays an important role. At this small company, I am bless to have working for me Kaye Crabill, a person who has had extensive experience with corporate accounting and who has taught our A-R people the ins and outs with dealing with A-P departments. It takes a lot of hand holding on our part, but the benefit is that we almost always receive our payments within 30 (sometimes 40) days. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
Then you have the case of a government entity where you cannot even start the process for a new fiscal year until after the first day of the new fiscal year. If the product license expires on the fiscal year boundary, the chance of getting the entire renewal process completed in 30 (or 40) days is very slim. Having worked with Cole Software quite a bit, I suspect that any organization faced with the aforementioned problem could contact Dave and work something out. Most vendors are used to issues with Accounts Payable. Bob Shannon Rocket Software -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax. Scenario: 1. Vendor delivers key. 2. Key cannot be installed until the upgrade. 3. Upgrade cannot be done until the weekend. 4. Key fails. 5. Vendor support is only available M-F/9-5 (local time). 6. Asia Pacific Region's Monday Day Shift starts mid-day Sunday (local time). 7. Now what? And, where did my testing fail? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Am I a little harsh? Perhaps. Sounds suspiciously like platitude to me. Being patronising to customers with broken systems is rarely appreciated. Vendors with visions of forward sales would do well to be cognisant of this. Shane ... -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 09:02:40 + Ted MacNEIL [EMAIL PROTECTED] wrote: :In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax. :Scenario: :1. Vendor delivers key. :2. Key cannot be installed until the upgrade. :3. Upgrade cannot be done until the weekend. :4. Key fails. :5. Vendor support is only available M-F/9-5 (local time). That is the problem. :6. Asia Pacific Region's Monday Day Shift starts mid-day Sunday (local time). :7. Now what? And, where did my testing fail? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 19:20:29 +1000 Shane [EMAIL PROTECTED] wrote: : Am I a little harsh? Perhaps. :Sounds suspiciously like platitude to me. No. :Being patronising to customers with broken systems is rarely :appreciated. Nobody is suggesting that. : Vendors with visions of forward sales would do well to be :cognisant of this. Would be great if all invoices were paid on time. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Looks like introducing knowingly a single point of failure into a system without any way out . This was my point earlier on I was caught 3 years ago despite warning the vendor of the differences in STSI and STIDP on z/990 but indeed they ignored me and no batch would run i had to call someone in Texas ( sorry guys but the Texas or Florida accent mixed with my own exasperated french accent brought some extra delays to our batch window ) It added latency like some new managers call it :-)) Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr On Sun, 25 Feb 2007 09:02:40 +, Ted MacNEIL [EMAIL PROTECTED] wrote: In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax. Scenario: 1. Vendor delivers key. 2. Key cannot be installed until the upgrade. 3. Upgrade cannot be done until the weekend. 4. Key fails. 5. Vendor support is only available M-F/9-5 (local time). 6. Asia Pacific Region's Monday Day Shift starts mid-day Sunday (local time). 7. Now what? And, where did my testing fail? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html = -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Would be great if all invoices were paid on time. Would be great if vendors delivered working keys all the time! Would be great if vendors were available 7-24! Neither of the two above have anything to do with timely payments. AND, the scenario I proposed, I lived through. Without naming names, the product in question only had two vendors and one was a work-alike for another. Both vendors have/had M-F/9-5 support. Keys failed on a weekend. Company works in many time-zones. Support didn't. Bill was payed. Keys failed. As I said: Now what? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 13:57:34 + Ted MacNEIL [EMAIL PROTECTED] wrote: :Would be great if all invoices were paid on time. :Would be great if vendors delivered working keys all the time! Yes :Would be great if vendors were available 7-24! Yes. :Neither of the two above have anything to do with timely payments. :AND, the scenario I proposed, I lived through. :Without naming names, the product in question only had two vendors and one was a work-alike for another. :Both vendors have/had M-F/9-5 support. :Keys failed on a weekend. :Company works in many time-zones. :Support didn't. :Bill was payed. :Keys failed. :As I said: Now what? Since you recognized the problem in advance, you had the opportunity to request for someone to be on-call during the testing interval. I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-snip--- I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. --unsnip--- You'd be amazed at the number of vendors that will NOT provide support outside the 9-5 M-F window. I even had a vendor rep hang up on me in the middle of a call because it was now 5:00 PM where he was. Some of those (unprintables) are unionized and unions havee INCREDIBLE power here. Needless to say, our business relationship with that particular vendor ended the next day. We learned how to manage without his package and saved ourselves a bundle of $$$ besides. Names deleted to protect the incompetant. And stoopid!! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
From: Ted MacNEIL [EMAIL PROTECTED] 1. Vendor delivers key. 2. Key cannot be installed until the upgrade. Why? If the product is designed properly, you should be able to specify more than one key. If the first key fails, the product tests the second key (and so on) until a working key is found. This allows you to install keys way ahead of time (e.g. long before cutting over to a new CPUID). SimpList allows up to 3 keys; a number of other MacKinney products allow up to 6. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Dont waste time standing in linetry shopping online. Visit Sympatico / MSN Shopping today! http://shopping.sympatico.msn.ca -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. ITYM one off. Objected, no. Refused, yes! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Why? If the product is designed properly, you should be able to specify more than one key. Woulda! Coulda! Shoulda! It wasn't! That's my main objections to keys! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
At 2/25/2007 01:15 PM, TMacNeil wrote: Why? If the product is designed properly, you should be able to specify more than one key. Woulda! Coulda! Shoulda! It wasn't! That's my main objections to keys! Your objection is misplaced, Ted. It should not be against keys. It should be against badly implemented keys, as done by specific vendors. Every one of the objections expressed by you over these past several weeks can be addressed by intelligent programming and careful support on the vendor's part. Not every vendor is guilty of the problems you continually allege. Good programming is an art requiring extreme precision. So is good discussion! Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.colesoft.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-456-6658 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
If the product is designed properly, you should be able to specify more than one key. Woulda! Coulda! Shoulda! It wasn't! That's my main objections to keys! Don't you mean that's my main objection to the way a particular vendor has implemented his keys? I understand that your experience with keys has been less than ideal. But, there are vendors out there who design keys so that: a) A warning message is displayed long before a key expires. b) A new key is sent to you long before a key expires. c) The keys can be entered in a flat file (i.e. nothing to compile/link/refresh etc). d) Multiple keys can be stored so that new keys can be entered way ahead of time. It takes 2 minutes to enter a key in a flat file. It's not a big deal. In an ideal world, it would be nice not to bother with keys. If I lose my keys and lock myself out of my car, it's a pain. Carrying grocery bags and struggling to unlock my front door is a pain. I'd like to throw away all my keys and leave everything unlocked. But that's not the world we live in. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ http://local.live.com/default.aspx?v=2cp=43.658648~-79.383962style=rlvl=15tilt=-90dir=0alt=-1000scene=3702663cid=7ABE80D1746919B4!1329 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Feb 25, 2007, at 11:04 AM, Rick Fochtman wrote: -snip--- I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. --unsnip--- You'd be amazed at the number of vendors that will NOT provide support outside the 9-5 M-F window. I even had a vendor rep hang up on me in the middle of a call because it was now 5:00 PM where he was. Some of those (unprintables) are unionized and unions havee INCREDIBLE power here. Needless to say, our business relationship with that particular vendor ended the next day. We learned how to manage without his package and saved ourselves a bundle of $$$ besides. Names deleted to protect the incompetant. And stoopid!! Rick, Agreed. But that is usually after the fact. we are not included in license negotiations so we are typically get to work on the SH*T that is handed us to install and maintain. I think I have had to deal with the 9-5 product that is being talked about. IIRC we almost had to back out a CPU upgrade because of a key failure. Talk about fingers being pointed (all our way btw). Of course there are others (CA-1 as an example) that provides excellent coverage at 2 AM btw. Its bad enough with a single product / vendor. But (in the case of CA) you can threaten to eliminate all of their products but it will be a multi year and probably high $$ cost to do so. I know we did it with one other vendor, Compuware. We did save money and almost no lost of functionality. As I said one vendor product is usually no problem its the multi product vendor that is usually the issue (hard one). Ed -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 18:09:27 + Ted MacNEIL [EMAIL PROTECTED] wrote: :I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. :ITYM one off. :Objected, no. :Refused, yes! Even to support installing the product off hours? If so, I am quite amazed. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Not every vendor is guilty of the problems you continually allege. I'm not the only one that 'continually' alleges. And, if there are vendors with better practices, I have only met two. I may not have travelled as many miles as some of you, but key management for the mainframe is the second worst idea that I have seen for software asset management. The worst was tier-based pricing. Every vendor I have dealt with has caused us key issues at least once in the last year, except one. We have 15 products that we are paying for directly, rather than through our service provider. 7 of them have keys. Even the 'perpetual' keys have caused us problems. I am (obviously) NOT a fan of them. If I could find a work-alike, I would. (I have for two). In both cases, one is key-based the other is not. We are in the process of evaluating application change management software and I have recommended against two vendors because they are key-based. We have only two vendors that have implemented 'good' key-based solutions. One is SYNCHSORT - the grace period is so long, it doesn't cause us issues. The other will remain nameless because naming it will name the competitor that has lousy support, poor key management, M-F/9-5, and no grace period. We switched to this 'other', because of better support and the potential to develop emergency keys at their support web-site. If I have to have keys, that's the best option out of a bad licence enforcement methodology. Many vendors manage their licencing without the introduction of points of instability into the customers environment. Also, as somebody pointed out, no large company wants bad press! Most mainframe shops are large companies. So, why would they/we want to be outed for bad practices like this? We have been tarred with the brush that has been used on the Windows types and their poor practices. It is irrelevant that not all vendors have such bad ways of implementation. It is relevant that the ones we are forced to use do. Some of it is poor process (A/R or key management), poor implementation, poor communication, or fat fingers. It's nice that some have good implementation. But, we are not their customers. You have to play the hand your dealt. The better draw comes when you can get rid of the keys. Who, in their right mind, wants to add single points of vulnerability in an already complex environment? Especially, one where management is seriously looking for alternatives, at many companies. You keep up with complex/confusing implementations, and we can argue about the temperature of a burning house! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Dave Salt Sent: Sunday, February 25, 2007 10:47 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) From: Ted MacNEIL [EMAIL PROTECTED] 1. Vendor delivers key. 2. Key cannot be installed until the upgrade. Why? If the product is designed properly, you should be able to specify more than one key. If the first key fails, the product tests the second key (and so on) until a working key is found. This allows you to install keys way ahead of time (e.g. long before cutting over to a new CPUID). SimpList allows up to 3 keys; a number of other MacKinney products allow up to 6. Dave Salt Even in that scenario, how do you know that the key for the new CPUID will actually work when the CPU is upgraded? There should be some kind of key test mode thing to be sure the key will work on an anticipated CPUID. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ see my résumé at my website (yes, I am looking for employment) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Don't you mean that's my main objection to the way a particular vendor has implemented his keys? Many more than one vendor! I understand that your experience with keys has been less than ideal. But, there are vendors out there who design keys so that: Only two (soon to be three), so far. a) A warning message is displayed long before a key expires. Not many, in my experience. b) A new key is sent to you long before a key expires. Since when? We've always had to ask! Even SYNCSORT. c) The keys can be entered in a flat file (i.e. nothing to compile/link/refresh etc). Only one vendor, so far. And, we are only in the evaluation phase, so it's not in production, yet. d) Multiple keys can be stored so that new keys can be entered way ahead of time. None of our vendors; including the one we are evaluating. It takes 2 minutes to enter a key in a flat file. It's not a big deal. Have you ever heard of the large bureacracy called 'Change Control'? The most ironic aspect of IT. The number one responsibility of C/C is to slow down the rate of change. The number one task of IT is to facilitate change. In an ideal world, it would be nice not to bother with keys. This analagy is weak and irrelevant to the discussion at hand. Computers are not garages. Software products are not cars! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Even to support installing the product off hours? If so, I am quite amazed. The product was/is key to our environment, but only cost $5K/annum. Not worth the vendor's time/$. There are few alternatives, and if they lose us, it's not like they lose a large revenue stream. We have since switched to a work-alike product that the vendor has a self-service web-site to get a temporary key (4 days), so we can move on. If you MUST have keys, this is a better choice. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Don't you mean that's my main objection to the way a particular vendor has implemented his keys? Many more than one vendor! Okay, lot's of vendors have bad keys. Lot's of restaurants are unhygienic. This doesn't mean all restaurants are unhygienic. If it were not for keys, some customers wouldn't pay on time (or wouldn't pay at all). This means ISV's would need to take customers to court (at significant cost, both in terms of time and money), or they'd have to increase the prices paid by other customers. Either way, these costs would be passed on to other customers (e.g. you). So, whether you like them or not, keys save your company money. In an ideal world, it would be nice not to bother with keys. This analagy is weak and irrelevant to the discussion at hand. Computers are not garages. Software products are not cars! A metal key is used to protect a metal car. A software key is used to protect a software product. Property is property, and keys are designed to protect property. I'm sorry you don't see the analogy. Dave Salt SimpList - the easiest. most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ http://local.live.com/default.aspx?v=2cp=43.658648~-79.383962style=rlvl=15tilt=-90dir=0alt=-1000scene=3702663cid=7ABE80D1746919B4!1329 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
If it were not for keys, some customers wouldn't pay on time (or wouldn't pay at all). THAT is my point of disagreement! Most shops that are mainframe shops are large companies. Large companies do NOT want their names in the press. Ergo, they will do everything they can to pay on time. Yes, we have process problems, but so do the vendors. We have a gross revenue of $30BUS, net of $1.3BUS. Do you think we are going to dick you around for even a $50K contract? Call the press and tell them! But, no, the vendor would rather complicate our environment, introduce single points of failure, and make us look for alternatives. WHICH we are doing! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Test, processor upgrade? It's a pull/push at deep dark thirty, test hah. 3090 to mp2003-c to z800-0a1(0b1) and now Z9bc on the horizon. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Binyamin Dissen Sent: Saturday, February 24, 2007 11:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) On Sat, 24 Feb 2007 20:25:24 -0600 Joel C. Ewing [EMAIL PROTECTED] wrote: :Particularly in the case of processor upgrades, snip In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Why would anyone buy a product that has 9-5 service and keys to make it work? I would think just a tiny amount of investigation would uncover that fact. Of course, if the product is sold to another vendor, you maybe won't get 24-7 support, but you can then make plans to get rid of it. Eric Bielefeld Sr. z/OS Systems Programmer Lands End Dodgeville, Wisconsin 414-475-7434 - Original Message - From: Rick Fochtman [EMAIL PROTECTED] Newsgroups: bit.listserv.ibm-main To: IBM-MAIN@BAMA.UA.EDU Sent: Sunday, February 25, 2007 11:04 AM Subject: Re: License keys for ISV products(What alternatives are there?) -snip--- I would find it hard to believe that the unnamed vendor with 9-5 support would have strongly objected for a one of weekend support. --unsnip--- You'd be amazed at the number of vendors that will NOT provide support outside the 9-5 M-F window. I even had a vendor rep hang up on me in the middle of a call because it was now 5:00 PM where he was. Some of those (unprintables) are unionized and unions havee INCREDIBLE power here. Needless to say, our business relationship with that particular vendor ended the next day. We learned how to manage without his package and saved ourselves a bundle of $$$ besides. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Binyamin Dissen wrote: On Sat, 24 Feb 2007 20:25:24 -0600 Joel C. Ewing [EMAIL PROTECTED] wrote: :Particularly in the case of processor upgrades, or in DR, there is no :reliable way for us to verify that new keys from the vendors are correct :and correctly installed until we are running on the new processor. If :they aren't and a hard failure results, there is a high likelihood that :this failure will be seen in some way by the end users, even if the :vendor key support is 24x7. In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax. Really? Explain how one tests a dynamic CPU upgrade consisting of IBM non-disruptively turning on one or more CP's on your only production processor complex. At least 75% of our upgrades are now of this nature. Depending on what the vendor product is examining and how often it checks, it either sees an instantaneous change in production of the processor type at the time the new CP is enabled, or it sees that change when some vendor-specific future event (possibly the next IPL, POR, etc) occurs. There is no way to reliably test the new keys in advance, even if the product allows installing the new keys in advance. When changing to a completely new processor box, it is certainly desirable and generally possible to have an overlap and have the new machine as a test bed for new keys, but I can envision cases where there would be unavoidable constraints that would prevent that overlap (and have lived through some major push-pull scenarios with no overlap). In the case of DR: if you do test runs, you will be quite aware of this issue. If you never do test runs, refer to the processor upgrade above. If you do not test, this is not likely to be your only problem. Or a major one. Vendors can always change their key validation logic with maintenance and release changes and our mix of ISV products drifts as well. Some products fail without new keys on a DR processor only when running without VM; others fail in all cases. When we find a vendor product that has key validation problems at DR testing, the resolution for that product gets incorporated into our DR procedures. That we have occasionally encountered new failures in the past during DR testing tells us there is always the potential for an unexpected failure at an actual DR. DR testing reduces the exposure, but cannot eliminate it. :While I can understand the vendors concerns, my goal is to focus on our :own system reliability and the needs of our end users; and any hard :failures in ISV products are an enemy of that goal. First, work on what you can change - get your accounting people up to speed. Keep track of the ISV products and expirations, and follow up on them. Our accounting people have never been a problem, neither have we had any significant problem tracking ISV product expirations. The problem is that we do not work in a static environment. It has been contract negotiation and the reluctance of vendors to adapt reasonably to changing hardware/software environments that has been the greatest source of problems, especially when hardware upgrades are to support application growth that is unrelated to the vendor's product! Improve those test procedures. See above. Am I a little harsh? Perhaps. A vendor only has to deal with the familiar idiosyncrasies of his own product's key management. On the customer side we have to deal the unfamiliar and changeable idiosyncrasies of many vendor products. Yes, you would like to not have to worry about the ISV key, and the ISV would love not having to worry about collecting. But you should be aware that there is a bit of a partnership here. Granted. Perhaps a vendor should cut much more slack with a company that has been a consistent paying customer for years by selectively making key management less onerous for such customers. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Why would anyone buy a product that has 9-5 service and keys to make it work? Because it's the only one that does what you need? I would think just a tiny amount of investigation would uncover that fact. Because it's the only one that does what you need? Of course, if the product is sold to another vendor, you maybe won't get 24-7 support, but you can then make plans to get rid of it. Because it's the only one that does what you need? Plus, the only replacement has the same support! - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 25 Feb 2007 20:32:18 +, Ted MacNEIL wrote: If it were not for keys, some customers wouldn't pay on time (or wouldn't pay at all). THAT is my point of disagreement! Most shops that are mainframe shops are large companies. Large companies do NOT want their names in the press. Ergo, they will do everything they can to pay on time. Yes, we have process problems, but so do the vendors. You are wrong. I could name two large companies who have stolen mainframe software who were later caught out because the method of doing keys changed. Not all companies are ethical regardless of their size. And many welcome any publicity good or bad. Lloyd -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
I worked at a small financial services company where the sysprog disabled the SYNCSORT key code. It eventually came back to bite him and he was asked to leave. Later, Ray -- M. Ray Mullins Roseville, CA, USA http://www.catherdersoftware.com/ http://www.mrmullins.big-bear-city.ca.us/ http://www.the-bus-stops-here.org/ German is essentially a form of assembly language consisting entirely of far calls heavily accented with throaty guttural sounds. ---ilvi French is essentially German with messed-up pronunciation and spelling. --Robert B Wilson English is essentially French converted to 7-bit ASCII. ---Christophe Pierret [for Alain LaBonté] -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Lloyd Fuller Sent: Sunday 25 February 2007 17:02 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) On Sun, 25 Feb 2007 20:32:18 +, Ted MacNEIL wrote: If it were not for keys, some customers wouldn't pay on time (or wouldn't pay at all). THAT is my point of disagreement! Most shops that are mainframe shops are large companies. Large companies do NOT want their names in the press. Ergo, they will do everything they can to pay on time. Yes, we have process problems, but so do the vendors. You are wrong. I could name two large companies who have stolen mainframe software who were later caught out because the method of doing keys changed. Not all companies are ethical regardless of their size. And many welcome any publicity good or bad. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-snip-- I worked at a small financial services company where the sysprog disabled the SYNCSORT key code. It eventually came back to bite him and he was asked to leave. unsnip- Rightly so. But don't blame the company for one renegade employee. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Sunday, February 25, 2007 12:27 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) At 2/25/2007 01:15 PM, TMacNeil wrote: Why? If the product is designed properly, you should be able to specify more than one key. Woulda! Coulda! Shoulda! It wasn't! That's my main objections to keys! Your objection is misplaced, Ted. It should not be against keys. It should be against badly implemented keys, as done by specific vendors. Every one of the objections expressed by you over these past several weeks can be addressed by intelligent programming and careful support on the vendor's part. Not every vendor is guilty of the problems you continually allege. snip Amen. Most all of these objections are to/for a vendor that has problems with logic and support of their most valuable asset, their customers. Here, where I've just become a full-time (from contract) employee, a discussion was had to find a way to improve key processing to stop customers who are abusing (violating) the terms of the licensing agreement. Number one on the list was to NOT cause problems for customers that are in compliance. And this IBM-Main discussion had been reviewed by at least three people prior to that meeting. One of the most interesting things I see are companies that spend mega-bucks to gain new customers. If they would spend half that on taking care of customer issues, they wouldn't have to spend so much on getting new customers to replace the ones they've lost. Perhaps the problems with keys need to be made painful to a sales person from a problem vendor? If they don't get they point, I'm sure that there are a few enterprising souls that will do the job, and possibly at a lower cost with much more responsiveness to customer issues. After all, how many out of work developers are there that have announced that fact on this news group since January (07)? Regards, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(Cole Software's view)
Jon Brock wrote: ... A unified license key scheme could avoid some of the pain associated with the subject. It was called ILM (IBM License Manager). The project crashed and burned. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Since probably the most important function of a System Programmer is to provide a stable Operating System platform for production applications (typically requiring a number of ISV products), and to do this while juggling software release changes, software maintenance, and changes in hardware, it is not surprising that system programmers (and enlightened managers) would be irked at anything that makes that task more difficult, and especially at any product whose license key management introduces additional points of failure into the process. If a hard failure occurs in a critical ISV product because of a bad license key, this potentially affects many application, large numbers of end users, and costs the company real money. It makes no difference whether the outage is caused by an ISV failure to supply correct keys or by some error on our part in the installation process, the effect on the end user is equally bad. Particularly in the case of processor upgrades, or in DR, there is no reliable way for us to verify that new keys from the vendors are correct and correctly installed until we are running on the new processor. If they aren't and a hard failure results, there is a high likelihood that this failure will be seen in some way by the end users, even if the vendor key support is 24x7. While I can understand the vendors concerns, my goal is to focus on our own system reliability and the needs of our end users; and any hard failures in ISV products are an enemy of that goal. Eric N. Bielefeld wrote: ... I think its interesting that so many sysprogs on the list hate keys so much. I think a lot of it is just poor business practices when you can't get a key in time. Yes, there are a few vendors who are only available 9-5 M-F, which could be a problem in a real disaster, but most of the major ones can respond 24 by 7. Eric Bielefeld Sr. z/OS Systems Programmer Lands End Dodgeville, Wisconsin 414-475-7434 ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sat, 24 Feb 2007 20:25:24 -0600 Joel C. Ewing [EMAIL PROTECTED] wrote: :Particularly in the case of processor upgrades, or in DR, there is no :reliable way for us to verify that new keys from the vendors are correct :and correctly installed until we are running on the new processor. If :they aren't and a hard failure results, there is a high likelihood that :this failure will be seen in some way by the end users, even if the :vendor key support is 24x7. In the case of a processor upgrade: if you get a hard error during production due to a bad ISV key, your testing criteria are way too lax. In the case of DR: if you do test runs, you will be quite aware of this issue. If you never do test runs, refer to the processor upgrade above. If you do not test, this is not likely to be your only problem. Or a major one. :While I can understand the vendors concerns, my goal is to focus on our :own system reliability and the needs of our end users; and any hard :failures in ISV products are an enemy of that goal. First, work on what you can change - get your accounting people up to speed. Keep track of the ISV products and expirations, and follow up on them. Improve those test procedures. Am I a little harsh? Perhaps. Yes, you would like to not have to worry about the ISV key, and the ISV would love not having to worry about collecting. But you should be aware that there is a bit of a partnership here. -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Unfortunately, at least for the four site IDs I manage, it is not kept up to date. The last site I checked two weeks ago was two versions out of date. -Original Message- From: Bob Rutledge [mailto:snip] Sent: Saturday, February 17, 2007 4:05 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) Russell, It is already as you think it should be. I've been downloading my LMP keys from SupportConnect and its predecessors for a Long Time--the file is indeed keyed off site-id. Bob -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
License keys for ISV products(What alternatives are there?
At the risk of starting a whole new discussion, let me propose a possible mechanism that MIGHT be acceptable to most, if not all, vendors. 1. IBM provides a mechanism to fetch a single entry from IFAPRDxx, based on a product identifier, E.G. SYNCSORT VxRx.x. The entry would include a USERDATA field of a length up to xx bytes; let's say 32 bytes. Allow any character that can be entered from a 3270-type terminal or terminal emulator. 2. Vendors provide the contents of that entry at time of product installation or renewal. Encrypted dates, CPU serial numbers, etc. would all be acceptable. 3. Vendor products allow for update of that field anytime between 30 days before renewal and some agreeable term after renewal date. Start messaging hourly well in advance of the expiration and continue to do so until the key is renewed or the product expires. After expiration, issue a message at every invocation for the grace period until the key is renewed or the software finally expires. 4. Vendor products allow for disparity in CPU serial numbers for some agreeable, but reasonably short, period, to allow for a DR situation, provided all other licensing terms are obeyed. This to allow for REASONABLE DR testing (1-3 days), but not sharing a copy of the software with unlicensed users. 5. Systems Programmers would be required to notify vendors and get new key values in the event of a DR situation lasting longer than an agreed-upon test period. 6. Vendors provide not less than 45 days written notice of renewal requirements, to provide a buffer in the event of a slow-pay Accounting Department. I know that there's a lot of blue sky in this suggestion, but give it some serious thought. It might help eliminate the variety, and sometimes forgotten, update mechanisms and provide some assurance that keys MIGHT be updated in a timely fashion. I don't suggest that I have the only answer; just a possibility. G -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access to the internet at DR site was Re: License keys for ISV products(What alternatives are there?)
We added Internet access just last year to our BRS contract with IBM; software key access was one of the reasons. Another reason was that it allowed me to access our home system in case I was needed while I was at the BR test. It also gave access to software manuals if needed. 'Net access is too valuable these days not to have available. Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access to the internet at DR site was Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Jon Brock We added Internet access just last year to our BRS contract with IBM; software key access was one of the reasons. Another reason was that it allowed me to access our home system in case I was needed while I was at the BR test. It also gave access to software manuals if needed. 'Net access is too valuable these days not to have available. Indeed, one could say that Internet access is as essential as electricity nowadays. -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
My experience some years ago with a vendor well known to this list was that our A-P department took the view that a net 30 contract meant they should pay 30 days after receipt of the invoice, and not a day earlier. I think that is an accurate interpretation. The last time I worked for a user, they would flag the invoice for payment on exactly the net date after receipt. I once got a phone call from IBM complaining about non-payment, and wasted a day finding someone in accounts payable who could explain it to me. The call from IBM was actually their error. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
Possibly the only way to bring these A-P departments into line is to have a notice in the invoice that says failure to pay promptly means that the product will stop working. Then the invoice should specify immediate payment, not net 30 or whatever. -- Bruce A. Black Senior Software Developer for FDR Innovation Data Processing 973-890-7300 personal: [EMAIL PROTECTED] sales info: [EMAIL PROTECTED] tech support: [EMAIL PROTECTED] web: www.innovationdp.fdr.com -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
Net 30 is sometimes specified in the license. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Tuesday, February 20, 2007 11:14 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there? Possibly the only way to bring these A-P departments into line is to have a notice in the invoice that says failure to pay promptly means that the product will stop working. Then the invoice should specify immediate payment, not net 30 or whatever. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Bruce Black Sent: Tuesday, February 20, 2007 12:14 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there? Possibly the only way to bring these A-P departments into line is to have a notice in the invoice that says failure to pay promptly means that the product will stop working. Then the invoice should specify immediate payment, not net 30 or whatever. -- Bruce A. Black It's a bit hazy now, but from my recall of my accounting class in college, net 30 means full payment is due within 30 days, not after 30 days. Many A-P departments now interpret it as postmarked on day 30, so they get another 7 days (or so) float from snail mail. Jeffrey D. Smith Principal Product Architect Farsight Systems Corporation 700 KEN PRATT BLVD. #204-159 LONGMONT, CO 80501-6452 303-774-9381 direct 303-484-6170 FAX http://www.farsight-systems.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
In [EMAIL PROTECTED], on 02/19/2007 at 12:40 PM, Tony Harminc [EMAIL PROTECTED] said: My experience some years ago with a vendor well known to this list was that our A-P department took the view that a net 30 contract meant they should pay 30 days after receipt of the invoice, and not a day earlier. The vendor took the view that they would send out the new licence key upon receipt of payment. Needless to say, this almost always meant that we had to request emergency keys to tide us over. I've been in that situation, but I've never believed that any resulting outage was the vendor's fault. It's true that companies like SAS Institute sometimes make allowances for broken A-P departments, but that does not alter the fact that A-P is broken. I think a decoupling of the keys issue and the payments is called for, and indeed in the real world this happens much of the time. Or they should make the due date 45 days prior to expiration, or they should charge more but provide and early payment discount. But IMHO the real solution is to get upper management involved in holding A-P's feet to the fire. The flip side is that when the customer tells the vendor to include xyz on the invoice, it is the vendor's responsibility to do so. If A-P doesn't pay an invoice because the vendor couldn't be bothered to include necessary cross-reference data, then I blame the vendor, not A-P. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products
In [EMAIL PROTECTED], on 02/19/2007 at 08:39 AM, McKown, John [EMAIL PROTECTED] said: Our biggest problem at our last DR with CA (not their fault) How is an inflexible policy not their responsibility? was (1) no authorized email account available at the DR site and (2) the idiot FAX machine was broken. For some reason, CA said that they were not allowed to tell the EKG code over the phone. Not the problems that we had, but just as serious. IMHO a vendor contemplating the use of keys must devise an airtight scheme for emergency updates and must test it under worst-case scenarios. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/19/2007 at 08:52 AM, Paul Gilmartin [EMAIL PROTECTED] said: But the distribution list for such warnings might ideally include Accounts Payable personnel who can't even spell TSO. The messages from others suggest that what is needed is a message to someone to lean on A-P, rather than a message to A-P. Electronic communication should be regarded as a utility, like telephone service, where interoperation is essential. If the multitude of cellular telephone services can (mostly) interoperate with each other and with land-based providers, why can't the standard (a standard with only one participant?) TSO/E services interoperate with RFC *821/*822? They can, if you set them up that way. It's not appropriate to do so at every organization. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/19/2007 at 09:35 AM, Mark Zelden [EMAIL PROTECTED] said: License keys are a fact of life just like spam. Get over it. You could say the same thing about arson, battery, counterfeiting, DOS attacks, etc. I don't consider it to be a healthy attitude. Improvements come from those who don't get over it, but instead fight evils that they see. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products
Many vendors will negotiate to provide master keys without specification of a CPUID in the key. Put your legal and contracts people on it. They both may reasonably require that you have appropriate controls on the keys. This sort of thing is best raised as a requirement before you sign a contract. If you don't ask they cannot say yes. Best Regards, Sam Knutson, GEICO Performance and Availability Management mailto:[EMAIL PROTECTED] (office) 301.986.3574 Think big, act bold, start simple, grow fast... -Original Message- at 03:00 PM, McKown, John [EMAIL PROTECTED] said: CA's EKG code for disaster testing is fairly nice. The code may be nice, but that doesn't help if you can't get a new key in a timely fashion. Have they fixed the problems that they were having half a decade ago? From your account it doesn't seem so. The problems may be different, but if a customer can't get up at a DR site because the vendor won't supply a new key within the contracted interval, then the protection scheme is unacceptable and possibly a serious legal liability. Our biggest problem at our last DR with CA (not their fault) was (1) no authorized email account available at the DR site and (2) the idiot FAX machine was broken. For some reason, CA said that they were not allowed to tell the EKG code over the phone. Like a FAX is more secure??? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology This email/fax message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of this email/fax is prohibited. If you are not the intended recipient, please destroy all paper and electronic copies of the original message. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Russell, You don't give up, but the battle is lost. g I know many sites with unsupported CPCs. Unsupported at all. I also know companies which provide HW support for IBM CPCs. Even IBM doesn't know about installed CPCs. Even IBM doesn't know about real usage of cold backup machines. Even IBM does not control what OS is run on the machine: free Linux or expensive z/OS. What IBM knows is partial view. It's more than nothing, but it's not complete picture. Last but not least: mainframes are usually used by large companies. Large often means stock exchange quotation, banking, insurance, etc. No of the companies would like to be sued for software piracy. They can't afford it beacuse of the reputation. -- Radoslaw Skorupka Lodz, Poland Russell Witt wrote: Just because you bought the CPC from a broker; you still have maintenance. Granted, there might be some companies that rely strictly on third-party hardware support; but not many. If you have IBM hardware support; then again IBM knows what you have. This is a very big advantage to them. Russell -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of R.S. Sent: Saturday, February 17, 2007 6:13 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) Russell Witt wrote: One reason you can NOT compare IBM to any ISV is that IBM knows what hardware you have; how many box's you have and what size they are. They know because they sold them to you and you don't have any alternative then to buy from them (one reason for the ongoing suit). So, they don't have to worry about you running it on some extra systems. It's not true. It wasn't true. I hope it won't be true. In the past there were Amdahl, Hitachi, Comparex, Olivetti and other vendors which IBM didn't know about their sales. Nowadays you some of the non-IBM CPCs are still in use, and last but definitely not least - you can purchase IBM CPC from broker. Even if all your CPCs are from IBM, they're not sure what machine is cold reserve, what's for DR, and what products are run on this machine, not the other. So, IBM don't know as well. The ISV doesn't know any of this. How often do you invite your ISV into your data center to analyze what size machines you have and what they are each running. Not that the average ISV sales person could tell the difference between a processor and an air conditioner. That's why there is no need to invite anyone to my server room. We can analyze everything on paper. BTW: The most important thing to analyze is license agreement. There are so many gotchas prepared by ISV! Again, IBM is not likely to negotiate the price for software (however it *IS* subject to negotiate), but I'm pretty sure, there is not gotcha in IBM license agreement. -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.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.2007 r. kapita zakadowy BRE Banku SA (w caoci opacony) wynosi 118.064.140 z. W zwizku z realizacj warunkowego podwyszenia kapitau zakadowego, na podstawie uchwa XVI WZ z dnia 21.05.2003 r., kapita zakadowy BRE Banku SA moe ulec podwyszeniu do kwoty 118.760.528 z. Akcje w podwyszonym kapitale zakadowym bd w caoci opacone. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Focussing on the client site administrator aspect, things that used to annoy me were - Licence expiration warnings that modified return codes in production batch jobs - Licence expiration warnings that went unnoticed - The variety of expiration warning messages being issued - The variety of places where theses messages were being sent to - The variety of methods required to update licence expiration keys [*1] [*1 While I didn't have any objections against licence keys at all] What I'd like to see (or would have liked to see since I'm no longer in a position where I do installs): - unified (i.e. vendor-independent) message ids for licence related things (so as to easily automate them) - site customisable per-product thresholds for licence expiration warnings (in addition to those being used/issued by product internal mechanisms) - the capability to ask each product when it will expire - a tiny little licence management ISPF application (focussing on the 'information/warning' aspect) Just a few of those cents that came to my mind immediately. All of them from the small system environment point of view. Robert Bardos Ansys AG, Zurich, Switzerland -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/17/2007 at 04:18 PM, Charles Mills [EMAIL PROTECTED] said: Ted, if you haven't gotten why the trust model is inadequate from my past posts, and David Cole's, and Dave Salt's, and Russell Witt's, then my explaining it again probably won't do the trick either. Which trust model? Why is it more unreasonable for you to trust the customer than for the customer to trust you? Yes, there are dishonest customers, but there are also vendors who fail to deliver what they promise. Given a choice between three companies, one of which asks me to trust him, one of which posts a performance bond and one of which doesn't use a key at all, I'll pick the latter over the first two. I haven't seen any of the second type, Trust is not the answer, because not all customers (nor all of their employees and contractors) are trustworthy, Just as not all vendors are trustworthy. and even fewer are totally diligent See above. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/17/2007 at 11:41 AM, Ed Finnell [EMAIL PROTECTED] said: The silver bullet would be a magic decoder ring on the HMC that says this can run and this can't. That doesn't solve the problem for either the customer or the vendor. Consider DR. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/17/2007 at 07:27 AM, David Day [EMAIL PROTECTED] said: From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal? That's the wrong question. How can the user *know* that the ISV will *always* be timely in his delivery of license keys. It's the lack of assurance that's the big deal. That's not just hypothetical; CA failed on that big time during Y2K testing. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products
In [EMAIL PROTECTED], on 02/16/2007 at 04:22 PM, Bruno Sugliani [EMAIL PROTECTED] said: But we don't care ( sorry about that ) about the sharks robbing the poor salesmen I wouldn't go that far. I certainly care more about being able to use the software I pay for than I do with whether someone else takes advantage of a trial offer, but I do have sympathy for the vendor who is being exploited by a phony trial of his product. It took me 5 hours to replace 2 z/990 by 2 x z9 but it has taken 3 weeks of my time ( and it is not over ) to get keys for various product . IMHO that's a sign of vendor incompetence rather than the mere existence of licensing key. IMHO, if the vendor can't issue new keys in a timely fashion then it should disable the checking until such time as the support operation is able to discharge its responsibilities. BTW, I have in the past requested extensions of trial periods, especially for shareware. It's usually resulted in my acquiring the software. However, I would not boycott a vendor for refusing to extend a trail period, I'd just forget about acquiring the specific product. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/17/2007 at 10:40 AM, Charles Mills [EMAIL PROTECTED] said: We jointly discovered that our common distributor had stolen tens of thousands of dollars from us Was it Ronald Reagan who said trust, but verify? He quoted an old Russian saying. Even if a more technologically acceptable system were to be developed, it would also face anti-trust hurdles, because the US Department of Justice looks very unfavorably on any vendor collusion with regards to terms of doing business. Would that that were true. The DOJ basically let m$ off the hook and has turned a blind eye on noncompliance. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
In [EMAIL PROTECTED], on 02/17/2007 at 06:52 PM, Paul Gilmartin [EMAIL PROTECTED] said: It might help if the installation process prompted for an E-mail address of contact to notify automatically prior to expiry. Less help on z/OS than on other systems, because z/OS has less consistent a protocol for sending E-mail than most other systems. The flip side is that the support personnel at most z/OS shops have TSO userids, so you can send notifications through the standard TSO/E services. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products
In [EMAIL PROTECTED], on 02/16/2007 at 03:00 PM, McKown, John [EMAIL PROTECTED] said: CA's EKG code for disaster testing is fairly nice. The code may be nice, but that doesn't help if you can't get a new key in a timely fashion. Have they fixed the problems that they were having half a decade ago? From your account it doesn't seem so. The problems may be different, but if a customer can't get up at a DR site because the vendor won't supply a new key within the contracted interval, then the protection scheme is unacceptable and possibly a serious legal liability. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Shmuel Metz (Seymour J.) Sent: Sunday, February 18, 2007 12:24 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products In [EMAIL PROTECTED], on 02/16/2007 at 03:00 PM, McKown, John [EMAIL PROTECTED] said: CA's EKG code for disaster testing is fairly nice. The code may be nice, but that doesn't help if you can't get a new key in a timely fashion. Have they fixed the problems that they were having half a decade ago? From your account it doesn't seem so. The problems may be different, but if a customer can't get up at a DR site because the vendor won't supply a new key within the contracted interval, then the protection scheme is unacceptable and possibly a serious legal liability. Our biggest problem at our last DR with CA (not their fault) was (1) no authorized email account available at the DR site and (2) the idiot FAX machine was broken. For some reason, CA said that they were not allowed to tell the EKG code over the phone. Like a FAX is more secure??? -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In a message dated 2/19/2007 8:02:36 A.M. Central Standard Time, [EMAIL PROTECTED] writes: That doesn't solve the problem for either the customer or the vendor. Consider DR. Seems like if RSA cards are portable between cell phones should be able to specify a backup decoder ring-waving his wand and chanting the runes. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Sun, 18 Feb 2007 19:02:38 -0500, Reda, John [EMAIL PROTECTED] wrote: snip We offer multiple ways for the customer to install and maintain their license keys. The recommended method is having the keys in a sequential data set. This way modifications to the license keys can be as easy as updating a single data set. snip John, We migrated to the key data set some time ago. I don't think it was documented when / how often the data set was checked. Is it for every sort invocation? I don't think I found evidence that it was. Thanks, Mark BTW... as far as the rest of this discussion, I totally sympathize with the vendors. As someone who consulted full time for many years and also worked with a vendor directly whose product was abused due to no license control, I understand. While a lot of the abuse was not intentional (data center consolidations, then copying libraries from one environment to the other), a good deal of it was also done just because someone could. For example, it is very easy for a sysprog to copy a product like FDR from one system to another because they are more familiar with it than DFDSS (I saw lots of examples like this in data centers that went though consolidations). It would be nice if there was a common method of doing this, but not all vendors needs and pricing models are the same nor are the way their products work. Some vendors now do LPAR (size) pricing, some do only site licensing, some license by the box, the size of the box and the number of engines. You might as well ask for common installation method for all products too. I'm not holding my breath. License keys are a fact of life just like spam. Get over it. What you need to do is create good documentation for the products that require them, note whether they are date sensitive, CPU sensitive, or both and document exactly how to update them - including who to contact for scheduled updates and emergency updates (phone numbers, web sites, etc.). Manage that information / documentation how ever it suits your environment, but it does need to be managed in a modern data center. -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
I realize this is heresy, but I like the way CA does it. Parts of it, anyway. We get warnings before a key expires. Once we get a new key, we add it to our options file in Common Services (formerly CA-90's, etc.) and rerun CAS9 -- no pain, no downtime. I have no problem with vendor implementing a license key strategy as long as it is done properly. Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In a recent note, Shmuel Metz (Seymour J.) said: Date: Sun, 18 Feb 2007 13:40:13 -0500 It might help if the installation process prompted for an E-mail address of contact to notify automatically prior to expiry. Less help on z/OS than on other systems, because z/OS has less consistent a protocol for sending E-mail than most other systems. The flip side is that the support personnel at most z/OS shops have TSO userids, so you can send notifications through the standard TSO/E services. But the distribution list for such warnings might ideally include Accounts Payable personnel who can't even spell TSO. Electronic communication should be regarded as a utility, like telephone service, where interoperation is essential. If the multitude of cellular telephone services can (mostly) interoperate with each other and with land-based providers, why can't the standard (a standard with only one participant?) TSO/E services interoperate with RFC *821/*822? -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, February 19, 2007 9:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) In a recent note, Shmuel Metz (Seymour J.) said: Date: Sun, 18 Feb 2007 13:40:13 -0500 It might help if the installation process prompted for an E-mail address of contact to notify automatically prior to expiry. Less help on z/OS than on other systems, because z/OS has less consistent a protocol for sending E-mail than most other systems. The flip side is that the support personnel at most z/OS shops have TSO userids, so you can send notifications through the standard TSO/E services. But the distribution list for such warnings might ideally include Accounts Payable personnel who can't even spell TSO. Electronic communication should be regarded as a utility, like telephone service, where interoperation is essential. If the multitude of cellular telephone services can (mostly) interoperate with each other and with land-based providers, why can't the standard (a standard with only one participant?) TSO/E services interoperate with RFC *821/*822? -- gil Because: (1) TSO SEND et al. likely antedate those RFCs and (2) TSO development is, at best, minimized. I've not seen any really new TSO facilities in years. I don't really like email notification. For some reason, it rarely gets to me. And I do most of the key related maintenance. Again, CA does the best for this because I can get my current keys off of their web site. I know that others have said that they cannot due to CA not having all the keys there. I guess I'm lucky. The only problem is at DR. At our site, you can have a mainframe connected PC or an Internet connected PC. But not a single PC which can do both. And the distributed people grab all of the Internet connected PCs for there stuff. Why? Because they reload the OS from CDs (DVDs), but then go off to the MS site for any updates. Sounds weird to me, but what do I know? I'm just a mainframer. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(Cole Software's view)
Dave Cole writes emails as well as he writes software. But a small reinforcement. Trust? A while back I worked for an ISV and was responsible for the code program for what was then the number one product on both total sales and velocity for the company. A Very Large Computer User (VLCU) has multiple datacenters. It seems that the sysprogs shared install tapes. Then they called in for temp auth codes. One of our support people noticed the pattern and reported it. The lawyers had lunch. The settlement did not require SEC reporting but the number of licences VLCU had went way up. The rumor was they had to licence the product for every datacenter (some of which had extremely high security and were therefore unauditable). In troubled waters, build a bridge, pour oil, or hire the biggest shark. As one of my high school teachers (think Yoda in a nun's habit) used to say when your homework was missing due to canine misbehavior, Believe everybody, trust nobody. User Friendliness: Disaster Recovery: The ISV our group works with at the moment is very small. Their support seems to have the ability to generate authcodes at home. We have called all hours of the day and night. No problem. Good people. I do wish they had something I put into my routine. You could put every authcode statement for every product our company had into one file. My routine sorted through them looking for one which was valid. If multiple were valid, it authorized the greatest functionality it could consistent with what the caller requested. It didn't care if some of the authcodes were expired or for other machines or for other products. It would be very helpful today to have one file for all plexes (we have 16), not have to remove expired codes, not have to replace new codes with the one that will be used next month. Update one place and broadcast to all plexes in daily maintenance. pup IBM Mainframe Discussion List IBM-MAIN@BAMA.UA.EDU wrote on 02/17/2007 01:43:23 PM: User Friendliness: Disaster Recovery: Trust? Dave Cole - The information contained in this communication (including any attachments hereto) is confidential and is intended solely for the personal and confidential use of the individual or entity to whom it is addressed. The information may also constitute a legally privileged confidential communication. If the reader of this message is not the intended recipient or an agent responsible for delivering it to the intended recipient, you are hereby notified that you have received this communication in error and that any review, dissemination, copying, or unauthorized use of this information, or the taking of any action in reliance on the contents of this information is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail, and delete the original message. Thank you -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(Cole Software's view)
If we only dealt with 1 ISV, then we'd have few, perhaps no, problems too. But we deal with (at the last count) 57 ISVs, who supply us with several hundred products. Each ISV has it's idiosyncracies, some don't use keys at all, some are very easy to contact and deal with, some others are less so. It all adds up to quite a bit of overhead. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kirk Talman Sent: Monday, February 19, 2007 10:24 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(Cole Software's view) The ISV our group works with at the moment is very small. Their support seems to have the ability to generate authcodes at home. We have called all hours of the day and night. No problem. Good people. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(Cole Software's view)
This is where Charles' idea shows merit. A unified license key scheme could avoid some of the pain associated with the subject. Jon snip If we only dealt with 1 ISV, then we'd have few, perhaps no, problems too. But we deal with (at the last count) 57 ISVs, who supply us with several hundred products. Each ISV has it's idiosyncracies, some don't use keys at all, some are very easy to contact and deal with, some others are less so. It all adds up to quite a bit of overhead. /snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Mark Zelden Sent: Monday, February 19, 2007 10:35 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) John, We migrated to the key data set some time ago. I don't think it was documented when / how often the data set was checked. Is it for every sort invocation? I don't think I found evidence that it was. Thanks, Mark BTW... as far as the rest of this discussion, I totally sympathize with the vendors. As someone who consulted full time for many years and also worked with a vendor directly whose product was abused due to no license control, I understand. While a lot of the abuse was not intentional (data center consolidations, then copying libraries from one environment to the other), a good deal of it was also done just because someone could. For example, it is very easy for a sysprog to copy a product like FDR from one system to another because they are more familiar with it than DFDSS (I saw lots of examples like this in data centers that went though consolidations). It would be nice if there was a common method of doing this, but not all vendors needs and pricing models are the same nor are the way their products work. Some vendors now do LPAR (size) pricing, some do only site licensing, some license by the box, the size of the box and the number of engines. You might as well ask for common installation method for all products too. I'm not holding my breath. License keys are a fact of life just like spam. Get over it. What you need to do is create good documentation for the products that require them, note whether they are date sensitive, CPU sensitive, or both and document exactly how to update them - including who to contact for scheduled updates and emergency updates (phone numbers, web sites, etc.). Manage that information / documentation how ever it suits your environment, but it does need to be managed in a modern data center. -- Mark Zelden Mark, As long as we have a valid license key we will not look at the key data set. Once you enter a warning period we will go to the data set looking for a better key to use once an hour. It is possible to force the sort to go to the key data set by passing the KEYUPDATE parameter to the sort. This is useful if you install a new key and want to make sure that it gets into use immediately otherwise it could take up to 1 hour for the new key to get put into use if you are in a warning period. This whole area is a bad one. There are valid points to be made on both sides. ISVs should be able to collect what is rightfully theirs. With just about every product that I know about the customer has agreed to the licensing terms up front. At the same time, if the process required to abide by the terms of the license agreement are such that it is not worth it for customers to use the product, they will go else where and the ISV will end up with less revenue not more. It is up to each ISV to decide how they want to manage their license agreements and up to each customer if they are willing to agree to the terms. I agree that not all ISVs handle license keys as good as they should but at the same time there are others that do a reasonable job in this area. Just because some vendors don't do a good job doesn't mean that everyone with a license key is bad and should be avoided. We have tried to be as flexible as possible. Our first attempt at implementing license keys was not flexible and was not well received. We listen to our customers and tried to accommodate as many of their concerns as we could while still feeling that we were getting something of value for the time, effort and aggravation that having license keys requires. When IBM announced License Manager several years ago we made it clear very quickly that we were interested and would participate. We understood the value of having a common process for handling license keys but unfortunately License Manager did not make it. Sincerely, John Reda Software Services Manager Syncsort Inc. 201-930-8260 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
David Cole wrote: RPOs, POs and invoices are all necessary parts of the A-P process, and the better a vendor understands, cooperates with and *assists* in the process, the more often: - The licensing will be renewed on time, - Payment will be made on time, - And licensing keys will be updated on time. My experience some years ago with a vendor well known to this list was that our A-P department took the view that a net 30 contract meant they should pay 30 days after receipt of the invoice, and not a day earlier. The vendor took the view that they would send out the new licence key upon receipt of payment. Needless to say, this almost always meant that we had to request emergency keys to tide us over. Now as an ISV employee, I see many Fortune 500 companies that have A-P departments who, as a matter of policy, push the limits much further, and more often. I think a decoupling of the keys issue and the payments is called for, and indeed in the real world this happens much of the time. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
Jon, I agree with you. CA's license key method is about as painless as I have seen. One gripe I have is with a different vendor, (SAS, are you listening?). I got my SAS key and applied it to my production LPAR but got busy and forgot to apply it to the sandbox. Several months later I needed to run a SAS job on the sandbox and the job went down with a U999, no errors, no messages to indicate that the key had expired, just an abend. To me, that is definitely the wrong way to enforce a key! Rex -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Jon Brock Sent: Monday, February 19, 2007 9:52 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) I realize this is heresy, but I like the way CA does it. Parts of it, anyway. We get warnings before a key expires. Once we get a new key, we add it to our options file in Common Services (formerly CA-90's, etc.) and rerun CAS9 -- no pain, no downtime. I have no problem with vendor implementing a license key strategy as long as it is done properly. Jon -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Tony Harminc [ snip ] Now as an ISV employee, I see many Fortune 500 companies that have A-P departments who, as a matter of policy, push the limits much further, and more often. You could probably attribute that to the continuous compounding of interest. The longer I take to pay your invoice means that that money stays in my bank account longer, earning more interest for me. Makes financial sense for the payer. Indeed, that was the main reason cited by a former employer for refusing to implement direct deposit of payroll checks. They budgeted the projected interest they would earn during the float period between us cashing or depositing our checks, and their bank clearing them. Oh, it wasn't a small business, either. It was a governmental entity: Oklahoma City Public Schools. When I left there in early 1996, it was rumored that direct deposit of payroll checks was going to be reconsidered soon -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
On 19 Feb 2007 10:40:52 -0800, [EMAIL PROTECTED] (Chase, John) wrote: Indeed, that was the main reason cited by a former employer for refusing to implement direct deposit of payroll checks. They budgeted the projected interest they would earn during the float period between us cashing or depositing our checks, and their bank clearing them. Oh, it wasn't a small business, either. It was a governmental entity: Oklahoma City Public Schools. When I left there in early 1996, it was rumored that direct deposit of payroll checks was going to be reconsidered soon That sounds like an effective way of determining how a company values its employees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
In a recent note, Tony Harminc said: Date: Mon, 19 Feb 2007 12:40:20 -0500 I think a decoupling of the keys issue and the payments is called for, and indeed in the real world this happens much of the time. IOW, the key is renewed whether you pay or not? Perhaps the A-P policy droids paycheck should be coupled to the key renewal. Rats! I suspect there are labor laws that say you can't refuse to pay someone merely because he doesn't do his job. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, February 19, 2007 12:47 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there? In a recent note, Tony Harminc said: Date: Mon, 19 Feb 2007 12:40:20 -0500 I think a decoupling of the keys issue and the payments is called for, and indeed in the real world this happens much of the time. IOW, the key is renewed whether you pay or not? Perhaps the A-P policy droids paycheck should be coupled to the key renewal. Rats! I suspect there are labor laws that say you can't refuse to pay someone merely because he doesn't do his job. -- gil What I'd love is to be a hard-a** some day. I almost did it at one place. They were in financial difficulties so they were always late paying. Once a mission critical software package just stopped (after many days of warnings which were relayed to management). Management came over and said to call them to insist that they had paid, but that the check had been mailed to the wrong address and just now got returned to them. So I did. I told the vendor: I have been told that the check is in the mail.. You can guess the tone of voice that I used. I got reamed royally by my team leader. I reamed him right back and told him to lie to the vendors in the future. Never-the-less, the vendor did give us a 1 week key. Never talked to another vendor at that shop, which went out of business within the year. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
Getting OT here but my experience managing a SW company was that direct deposit EASILY paid for itself by not having employees running to the bank on payday. Let's say you pay someone $80K/year. That's roughly $40/hour, and roughly $3077 per pay bi-weekly pay period. 30 minute run to the bank: $20 Three days' interest on $3077 at 5% per annum: $1.26 Of course, as Howard suggested, if you don't value your employees, then that run to the bank is free, isn't it? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Howard Brazee Sent: Monday, February 19, 2007 10:45 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there? On 19 Feb 2007 10:40:52 -0800, [EMAIL PROTECTED] (Chase, John) wrote: Indeed, that was the main reason cited by a former employer for refusing to implement direct deposit of payroll checks. They budgeted the projected interest they would earn during the float period between us cashing or depositing our checks, and their bank clearing them. Oh, it wasn't a small business, either. It was a governmental entity: Oklahoma City Public Schools. When I left there in early 1996, it was rumored that direct deposit of payroll checks was going to be reconsidered soon That sounds like an effective way of determining how a company values its employees. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
I think what we are hearing is that my earlier suggestion that maybe the problem is your AP department was not a red herring after all. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of McKown, John Sent: Monday, February 19, 2007 10:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there? What I'd love is to be a hard-a** some day. I almost did it at one place. They were in financial difficulties so they were always late paying. Once a mission critical software package just stopped (after -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
In [EMAIL PROTECTED], on 02/18/2007 at 08:54 AM, Eric N. Bielefeld [EMAIL PROTECTED] said: IFAPRDxx really isn't a key. You have to turn it on for each product to use it, but there is no key that only works on your CPU. I'm not sure just what IBM's reasoning behind IFAPRD is, Presumably protection from inadvertent license violation. -- 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 [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Mon, 19 Feb 2007 13:33:26 -0500 Shmuel Metz (Seymour J.) [EMAIL PROTECTED] wrote: :In [EMAIL PROTECTED], on 02/18/2007 : at 08:54 AM, Eric N. Bielefeld [EMAIL PROTECTED] said: :IFAPRDxx really isn't a key. You have to turn it on for each product :to use it, but there is no key that only works on your CPU. I'm not :sure just what IBM's reasoning behind IFAPRD is, :Presumably protection from inadvertent license violation. Does IBM custom build the IFAPRD** for each customer? Or are most products turned off, requiring the customer to activate those that were licensed? Or, perhaps, all are on and the customer has to deactivate them? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Access to the internet at DR site was Re: License keys for ISV products(What alternatives are there?)
On 19 Feb 2007 07:59:00 -0800, in bit.listserv.ibm-main you wrote: -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Paul Gilmartin Sent: Monday, February 19, 2007 9:53 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) In a recent note, Shmuel Metz (Seymour J.) said: Date: Sun, 18 Feb 2007 13:40:13 -0500 It might help if the installation process prompted for an E-mail address of contact to notify automatically prior to expiry. Less help on z/OS than on other systems, because z/OS has less consistent a protocol for sending E-mail than most other systems. The flip side is that the support personnel at most z/OS shops have TSO userids, so you can send notifications through the standard TSO/E services. But the distribution list for such warnings might ideally include Accounts Payable personnel who can't even spell TSO. Electronic communication should be regarded as a utility, like telephone service, where interoperation is essential. If the multitude of cellular telephone services can (mostly) interoperate with each other and with land-based providers, why can't the standard (a standard with only one participant?) TSO/E services interoperate with RFC *821/*822? -- gil Because: (1) TSO SEND et al. likely antedate those RFCs and (2) TSO development is, at best, minimized. I've not seen any really new TSO facilities in years. I don't really like email notification. For some reason, it rarely gets to me. And I do most of the key related maintenance. Again, CA does the best for this because I can get my current keys off of their web site. I know that others have said that they cannot due to CA not having all the keys there. I guess I'm lucky. The only problem is at DR. At our site, you can have a mainframe connected PC or an Internet connected PC. But not a single PC which can do both. And the distributed people grab all of the Internet connected PCs for there stuff. Why? Because they reload the OS from CDs (DVDs), but then go off to the MS site for any updates. Sounds weird to me, but what do I know? I'm just a mainframer. Could you take a laptop with a wireless connection? Failing that, can you make the case for having either one PC dedicated to mainframe use and the Internet or at least one PC with Internet connection dedicated to mainframe. At less than a thousand dollars for a laptop or PC, this seems like a trivial cost for DR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
On Mon, 19 Feb 2007 22:22:08 +0200, Binyamin Dissen [EMAIL PROTECTED] wrote: Does IBM custom build the IFAPRD** for each customer? Or are most products turned off, requiring the customer to activate those that were licensed? A sample IFAPRDxx comes pre-customized with ServerPac based on your order / licenses. Mark -- Mark Zelden Sr. Software and Systems Architect - z/OS Team Lead Zurich North America / Farmers Insurance Group: G-ITO mailto:[EMAIL PROTECTED] z/OS and OS390 expert at http://searchDataCenter.com/ateExperts/ Systems Programming expert at http://expertanswercenter.techtarget.com/ Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
See below... Binyamin Dissen wrote: Does IBM custom build the IFAPRD** for each customer? Yes. Every z/OS ServerPac or CBPDO order includes a custom-built IFAPRDxx member. Or are most products turned off, requiring the customer to activate those that were licensed? So far as I know, only z/OS elements use IFAPRDxx at this time. (Other things potentially could but I am not currently aware of any that do, or I've forgotten.) All licensed z/OS elements should be turned on, and all unlicensed ones turned off. Or, perhaps, all are on and the customer has to deactivate them? If you activate another z/OS element, you should contact IBM beforehand. If you deactivate one, we don't mind so much if you drag your feet or forget. ;-) snip -- John Eells z/OS Technical Marketing IBM Poughkeepsie [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
On 19 Feb 2007 09:40:41 -0800, in bit.listserv.ibm-main you wrote: David Cole wrote: RPOs, POs and invoices are all necessary parts of the A-P process, and the better a vendor understands, cooperates with and *assists* in the process, the more often: - The licensing will be renewed on time, - Payment will be made on time, - And licensing keys will be updated on time. My experience some years ago with a vendor well known to this list was that our A-P department took the view that a net 30 contract meant they should pay 30 days after receipt of the invoice, and not a day earlier. The vendor took the view that they would send out the new licence key upon receipt of payment. Needless to say, this almost always meant that we had to request emergency keys to tide us over. Now as an ISV employee, I see many Fortune 500 companies that have A-P departments who, as a matter of policy, push the limits much further, and more often. Possibly the only way to bring these A-P departments into line is to have a notice in the invoice that says failure to pay promptly means that the product will stop working. Frankly too many governments and companies are playing games that penalize the honest vendor and cause prices to rise for those who honor the terms of the agreement. I think a decoupling of the keys issue and the payments is called for, and indeed in the real world this happens much of the time. Emergency keys and the aggravation they cause may be the only way to get some bureaucracies to move. Unfrotunately this puts the sysprog in the middle of a fight. Possibly those of us on the IT side need to get the rules for paying for upgrades and period payments in writing so that we can be aware of what needs to be done to minimize the problems. Tony H. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Saturday, February 17, 2007 6:45 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) SNIP I have lived the pain, to the point of production failing, and losing revenue from expired keys. There a legal venues when a contract is not being honoured. SNIP So here I am, a start-up vendor. You have decided that me taking you to court for breach (non-payment) is a good thing, because you don't want to pay for the software that we've been supporting... 3 years later, in a FED court (because of us not being in the same state, or whatever) we still haven't been paid, but we're having to fork out money for a lawsuit after having shutdown the company. From my perspective, as a vendor, an ounce of prevention is worth more than the grief and headache of such a lawsuit (let's see, there are the depositions, the meetings with attorneys to respond to various motions (rather than doing things that generate CASH FLOW), the experts who have to look at our financials and determine how much you have hurt us, then hopefully we can demonstrate fraud (very tough), etc. -- It does happen, I WAS an officer in a company that is in the middle of this -- however, not in mainframe software, no one in mainframes would do this, right?). Later, Steve Thompson -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access to the internet at DR site was Re: License keys for ISV products(What alternatives are there?)
Where do you recover? Every place I know of has PC's for access in the hot sites. Doug snip I don't really like email notification. For some reason, it rarely gets to me. And I do most of the key related maintenance. Again, CA does the best for this because I can get my current keys off of their web site. I know that others have said that they cannot due to CA not having all the keys there. I guess I'm lucky. The only problem is at DR. At our site, you can have a mainframe connected PC or an Internet connected PC. But not a single PC which can do both. And the distributed people grab all of the Internet connected PCs for there stuff. Why? Because they reload the OS from CDs (DVDs), but then go off to the MS site for any updates. Sounds weird to me, but what do I know? I'm just a mainframer. Could you take a laptop with a wireless connection? Failing that, can you make the case for having either one PC dedicated to mainframe use and the Internet or at least one PC with Internet connection dedicated to mainframe. At less than a thousand dollars for a laptop or PC, this seems like a trivial cost for DR. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html Doug Fuerst Consultant BK Associates Brooklyn, NY (718) 921-2620 (Office) (718) 921-0952 (Fax) (917) 572-7364 (Cell) [EMAIL PROTECTED] -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access to the internet at DR site was Re: License keys for ISV products(W...
In a message dated 2/19/2007 3:19:22 P.M. Central Standard Time, [EMAIL PROTECTED] writes: Where do you recover? Every place I know of has PC's for access in the hot sites. Guess the 'big one' would be an EMP detonation. Probably maybe no internet at all. The other one that comes to mind is cold site with nothing except power. Murphy at his finest. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: Access to the internet at DR site was Re: License keys for ISV products(What alternatives are there?)
On Mon, 19 Feb 2007 16:48:27 -0400, Clark Morris wrote: Could you take a laptop with a wireless connection? Failing that, can you make the case for having either one PC dedicated to mainframe use and the Internet or at least one PC with Internet connection dedicated to mainframe. At less than a thousand dollars for a laptop or PC, this seems like a trivial cost for DR. Why is this any less straightforward than: If your primary site requires Internet access, however intermittently and for even such minor(?) purposes such as updating license keys, then your SLA with the DR provider must specify similar Internet access at the DR site. -- gil -- StorageTek INFORMATION made POWERFUL -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?
I think what we are hearing is that my earlier suggestion that maybe the problem is your AP department was not a red herring after all. Maybe! Maybe not. Our company does NET-30, and our vendors accept that. And, of the 15 we manage ourselves, rather than through our service provider, only 4-5 have keys and only one gives us a grace period. One doesn't even warn us. It just stops. If this is such a prevalent problem, shouldn't the customer and the vendor come to some sort of compromise? Besides the draconian measure of stopping dead on key expiry? Especially, with the companies that only supply that support 9-5/M-F? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
SCRT definitely only reports the IBM sub-capacity products for which it is programmed. No ISV products are reported by SCRT today. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(What alternatives are there?)
-Original Message- From: IBM Mainframe Discussion List On Behalf Of Ed Finnell [ snip ] The silver bullet would be a magic decoder ring on the HMC that says this can run and this can't. Doubt we'll see that anytime soon. IFAPRDxx ? -jc- -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
