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(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(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
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(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(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(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(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(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(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
Re: License keys for ISV products(What alternatives are there?)
On 17 Feb 2007 21:25:28 -0800, in bit.listserv.ibm-main you wrote: On Sat, 17 Feb 2007 22:02:15 -0600, 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. Well, there is IBM and then there is $IBM. While the service division might be aware of what hardware an account has on site, the accounting unit within IBM is notorious for not having the software inventory up to date (and probably doesn't have the hardware inventory up to date, too). For example, ShopzSeries can not be used by my present site for DB2 V8 because the IBMers have not successfully updated the account's inventory although they have been trying for many months (maybe 6 or more?). Our site also signed a new ELA back in October that included some new software and we have not been able to download that software from ShopzSeries to date because the ELA's updates have not made it into the inventory. Don't even get me started on the invoices from IBM -- I have only been looking at them for customers since 1985 and I have NEVER seen one be completely correct from IBM. Back around 1967, my boss got so enraged with the IBM billing inaccuracy that he called Tom Watson. I don't know if he got through but he did get a response and at least a temporary relief for the problem. So, no, don't use IBM as an example of a company with a clue how to deal with keys. I suspect IBM does not use keys for that very reason. -- 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?)
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, but the only way IBM could limit your use of different software products using IFAPRD would be if IBM was present during your IPLs and monitored IFAPRD's contents just after the IPL. This has been a very interesting discussion. A few of the vendors have givin very good reasons for having keys. This comes at a time when I was givin the task to renew our Syncsort keys. I found that negotiating the contract was part of the process, which is something I won't have to do, fortuneatly for me. When they get the contract process done, I'll just have to install the keys. By the way, does anyone know if Syncsort's key is a hard fail key? I suspect it is after a grace period. 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 - Original Message - From: Chase, John [EMAIL PROTECTED] Subject: Re: License keys for ISV products(What alternatives are there?) -Original Message- . 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
Re: License keys for ISV products(What alternatives are there?)
In a recent note, Tom Schmidt said: Date: Sat, 17 Feb 2007 23:31:25 -0600 What about sites that cannot allow any system-driven connections to the outside? (See the DIACAP military requirements that Defense contractors have to abide by for details.) Phoning home is not an option, especially for higher-security systems. In these cases the vendor is not trusted, at least not enough for that type of contact. Well, you can't fight the military -- they've got the big guns. But short of that, there seems to be an opportunity for a single well-audited (source code available) component through which every phone home would filter, verifying its parameter list against a data base of permissible message recipients and contents, etc. -- 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?)
By the way, does anyone know if Syncsort's key is a hard fail key? I suspect it is after a grace period. 30 days. And, during that time you have to run SYNCPR (I think that's the spelling), which they supply. - 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?)
--snip-- 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, but the only way IBM could limit your use of different software products using IFAPRD would be if IBM was present during your IPLs and monitored IFAPRD's contents just after the IPL. unsnip-- But why couldn't IFAPRDxx contain a vendor's key in one of the supported fields, instead of a english description of the software, for example? The key could be maintained on the fly (checked daily by the vendor package until expiration; then checked at each invocation) and all the keys would be in one simple, central repository. And why can't vendor code provide timely expiration warnings? And reasonable grace periods after expiration or for DR purposes? Comments were that the accounting department might be a little slow in reacting to a required renewal. Give them their due; they're trying to be protective of company assets, too. And some organizations, like my last one, require that the Legal department ALSO review anything and everything. So Accounting may be willing to cut the check, but Legal may be resting on its laurels and delaying the process. Vendors have an obligation to their shareholders to protect their intellectual property, and try to limit liability in case of abuses; I can accept that. But let's face it, some vendors' pricing practices are downright PREDATORY. First they hook you into using their products, then impose unconscionable price increases after the so-called introductory period. In my personnal experience, one vendor sent 9 marketting reps to my office, when all I had requested was a copy of the proposed contract, which could have been FAXed to me! Bloated marketting staff with nothing to do; I'm sure other areas of staff are similarly bloated; all these things contribute to high prices and loss of fexibility. Compuware built a nice shiny new headquarters building in downtown Detroit, then promptly laid off 5,000 people to cut costs. Too many pencil pushers and not enough technicians! -- 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 08:54:53 -0600, Eric N. Bielefeld [EMAIL PROTECTED] wrote: This has been a very interesting discussion. A few of the vendors have givin very good reasons for having keys. This comes at a time when I was givin the task to renew our Syncsort keys. I found that negotiating the contract was part of the process, which is something I won't have to do, fortuneatly for me. When they get the contract process done, I'll just have to install the keys. By the way, does anyone know if Syncsort's key is a hard fail key? I suspect it is after a grace period. 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. Yes a very interesting discussion indeed . There are arguments from each side I wonder what people would say if Microsoft was putting an expiring license key inside W2k or Office in our professional PC's Although everybody knows forbidden usage happens , keys are normaly used only in private PC's . If it was not so , we would not be able to handle deploiement of thousands of work stations . Software vendors recognise that and do not stop us from installing or running products whether we have 1000 or 25000 PC's .They trust us in our yearly negotiation. Just imagine your 5000 users without workstation one morning ? or 5000 warning messages at the help desk ? Oh boy ! What would happen when you replace the 5000 Netvista with 5000 Dell or NEC I would have to enter 3000 keys for 5000 machines because i have only 3000 users for Pcomm or excell ? I remember an antispam product that let the spam flow during a weekend because the license was expired . The fact is : i do not remember its brand anymore :-)) Trust is something that should go both ways . Why would customers trust marketing rep trying to sell software at 2 times the price it will eventually agree, everytime we need new keys ? Everytime a guy comes with a 300 000 dollars tag , we know we should be able to get it for 150 000. This behaviour is like asking us to pay for more machines or more MIPS than we actually have ! When we are billed for DB2, there is a price multiplied by an MSU consumption and that's it , not much for negociation . But no time wasted for bargaining or keys obtention , no DR problems , smooth business . So i agree that IBM is definietely not the model . Microsoft is not either . But allow me to find it difficult to do business with people who do not trust me and try to rob me . Cut smf records , get them from me and bill me accordingly , i'll allow you to come and see my systems . Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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/18/2007 12:32:37 P.M. Central Standard Time, [EMAIL PROTECTED] writes: I wonder what people would say if Microsoft was putting an expiring license key inside W2k or Office in our professional PC's Although everybody knows forbidden usage happens , keys are normaly used only in private PC's . If it was not so , we would not be able to handle deploiement of thousands of work stations . Software vendors recognise that and do not stop us from installing or running products whether we have 1000 or 25000 PC's .They trust us in our yearly negotiation. I've seen a PC with seven dongles and during an upgrade the 3rd one was dropped and lots of stuff quit working. The shame of it all! There's a license key for all the new M$ stuff and must be reinstalled(most of the time) during upgrades and replacements. Software piracy is a huge industry. -- 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: Bruno Sugliani [EMAIL PROTECTED] Everytime a guy comes with a 300 000 dollars tag , we know we should be able to get it for 150 000. Cut smf records , get them from me and bill me accordingly , i'll allow you to come and see my systems . My product only costs a tiny fraction of the amounts you mentioned. But if I had to visit each customer site everytime a license came up for renewal, the price could easily double to a 5 figure number. IMO, any solution that takes into account keeping costs as low as possible should not require any kind of on-site inspection. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Find out the restaurants participating in Winterlicious http://local.live.com/default.aspx?v=2cp=43.658648~-79.383962style=rlvl=15tilt=-90dir=0alt=-1000scene=3702663cid=7ABE80D1746919B4!1329 From January 26 to February 8, 2007 -- 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 18, 2007 11:20 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) /snip/ Vendors have an obligation to their shareholders to protect their intellectual property, and try to limit liability in case of abuses; I can accept that. But let's face it, some vendors' pricing practices are downright PREDATORY. First they hook you into using their products, then impose unconscionable price increases after the so-called introductory period. In my personnal experience, one vendor sent 9 marketting reps to my office, when all I had requested was a copy of the proposed contract, which could have been FAXed to me! Bloated marketting staff with nothing to do; I'm sure other areas of staff are similarly bloated; all these things contribute to high prices and loss of fexibility. Compuware built a nice shiny new headquarters building in downtown Detroit, then promptly laid off 5,000 people to cut costs. Too many pencil pushers and not enough technicians! Now you're starting a different subthread. Keys to protect intellectual property have not much correlation with the pricing model. Usage-based pricing model is for leased software, not purchased software (like M$ Excel). There is a huge difference between leased versus purchased software licensing models. Purchase software, like M$ Excel, generally have limitations on upgrades, operating system, and support life (bug fixes). You pay once, and get bug fixes on a somewhat timely basis until end of support. Installing the software phones home and identifies itself to be sure that the particular serial-numbered software is not already installed elsewhere. This is a reasonable way to protect against piracy, but it may be a problem for some mainframe sites that want to be isolated from the outside world. Leased software, like much of the mainframe software out there, has some kind usage-based pricing that hopes to correlate the cost of the software to the benefit received. The customer receives bug fixes, new versions, and support for newer operating systems. If the customer does not perceive the benefit as being greater than the cost, then the customer stops paying and the product stops operating. Most CFO's use the concept of a hurdle rate that specifies the rate of return on any investment. The benefit must exceed a certain multiplier applied to the cost of the investment. Usage-based pricing has many challenges. Is it per user, machine capacity, or per transaction (i.e., metered usage). If it is metered usage, how is the usage measured and reported (e.g, intrusiveness and accuracy are primary concerns). If it is machine capacity, how to accommodate periods of low activity versus high activity (end of quarter and end of year processing)? If it is per user, how quickly can the ISV accommodate changes in user quota? The notion of using dongles (a hardware device with a programmatically accessible serial number) is one way to assure that the software is running on the correct machine. The mainframe CPU serial number serves the same purpose. The MAC address for a network card also serves the same purpose, but is harder to verify programmatically on a mainframe. All of the concerns and issues mentioned above must somehow be distilled into a license key implementation that does not add unnecessarily to the sysprog burden. I understand that customers dont want to become dependent on leased software that expires and shuts down during critical times. However, there must be some reasonable cut-off point when negotiations break-down at contract renewal time. If the customer and vendor cannot agree on a new contract, then the product must stop operating. Where will you draw the line; 30 days, 60 days, 180 days, more? How long will customer get a free ride on a mission-critical ISV software? Until a replacement can be found or built? Does the contract allow for defaulting to month-to-month fees until a new long-term contract is negotiated (or the customer has gotten past their critical end-of-quarter processing)? What if there are no acceptable replacement products and the customer is unable or unwilling to build their own replacement? Disaster recovery on unknown machines (why are they unknown?) is a big issue. Many license key implementations are awkward and difficult to manage. Complain to the ISV and be specific about the issues. Pricing models are entirely a different matter that have little correlation to the license key implementation. Let's be clear in this topic when discussing pricing models versus license key implementation. License keys are never going away. However, bad implementations should go away. 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
Re: License keys for ISV products(What alternatives are there?)
On Sun, 18 Feb 2007 19:17:48 +, Dave Salt [EMAIL PROTECTED] wrote: My product only costs a tiny fraction of the amounts you mentioned. But if I had to visit each customer site everytime a license came up for renewal, the price could easily double to a 5 figure number. IMO, any solution that takes into account keeping costs as low as possible should not require any kind of on-site inspection. Yes Dave and i agree with you . (apart that if it doubles to a 5 figure number it is already half a five figure number :-)) ) I never had an onsite inspection from any vendors ( including IBM who asks me to sign on my honor or whatever that i do not fiddle with the records for sysplex pricing for example ) But your product does not endanger a DR plan , your product does not affect the production of 5000 users . Or does it ? I agree on some non critical product , but having a scheduler ,a tape management system ,an automation or a batch preparation tool with a key is what bothers me too much . Bruno Bruno(dot)sugliani(at)groupemornay(dot)asso(dot)fr -- 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: Bruno Sugliani [EMAIL PROTECTED] Yes Dave and i agree with you . (apart that if it doubles to a 5 figure number it is already half a five figure number :-)) ) Hmm; the licensing cost isn't a 2.5 figure number g. It's a 4 figure number, which if doubled would become a 5 figure number. 4 doubles to 5, right? ;-) your product does not endanger a DR plan , your product does not affect the production of 5000 users . Or does it ? That's a good question, and I honestly don't know the answer. SimpList gives mainframe users an alternative to the regular ISPF interface. If it suddenly became unavailable, the regular interface would still be there. In that sense, it's not 'critical'; i.e. people could still go back to using ISPF option 3.4 (or whatever they previously used). In other words, SimpList is nowhere near as mission critical as a tape management system or job scheduler (etc). OTOH, SimpList can dramatically impact the productivity of users. If it suddenly became unavailable, people would have to stop using labels and symbols (etc) and go back to doing things the old way. This is hardly ideal in a disaster situation. To use an analogy, imagine if a disaster occurred and you switched to a site where TSO was available but ISPF was not available. You'd still be able to get things done, but not nearly at the kind of pace you'd like. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Buy what you want when you want it on Sympatico / MSN Shopping http://shopping.sympatico.msn.ca/content/shp/?ctId=2,ptnrid=176,ptnrdata=081805 -- 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: IBM Mainframe Discussion List on behalf of Eric N. Bielefeld Sent: Sun 2/18/2007 9:54 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) snip This has been a very interesting discussion. A few of the vendors have givin very good reasons for having keys. This comes at a time when I was givin the task to renew our Syncsort keys. I found that negotiating the contract was part of the process, which is something I won't have to do, fortuneatly for me. When they get the contract process done, I'll just have to install the keys. By the way, does anyone know if Syncsort's key is a hard fail key? I suspect it is after a grace period. snip Eric, SyncSort will give up to 60 days of warning messages before a contract expires and 7 days afterwards. These messages can be written to the joblog for each sort and the system log twice a day. These messages can be turn off during the 60 days prior the expiration of the control if the customer does not want to see them but it is highly recommended that they do not do this. It is not possilbe to disable these messages during the 7 day grace period after the license has expired. If a CPU change occurs the sort will continue to execute for 45 days. During this period message will be produced warning the customer of the situation. The customer having the ability to control whether the messages are produced or not for all but the final 7 days. 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. Using this method allows the update to be completed without any reassembly/relink/reloading of any modules. Nothing needs to be stopped or restarted. We have tried to make the process as easy as possible. We provide 7x24 support and all analsyst can immediate help in a situation where a customer has a non-functioning product. I am responsible for customer service and technical support. If you are having difficutlies with our product and are not satisfied with the response you are getting from Syncsort, please contact me directly and I will see to it that whatever issue you are experiencing will get resolved as quickly as possible. 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
