Re: License keys for ISV products(What alternatives are there?)
>Then it would follow IBM's "trust" model. Okay, I used the wrong term. Would "non-keyed" suit it better? - 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?)
>If you have IBM hardware support; then again IBM knows what you have. This is a very big advantage to them. And, we don't tell the other vendors? Even with the non-keyed software, we tell the vendor what it's running on. I don't understand this comment, at all. - 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 Sat, 17 Feb 2007 23:47:47 -0500, Wayne Driscoll wrote: >You keep claiming that IBM uses the "trust" model, however, that is >simply not true. If IBM simply trusted you, the machine wouldn't have >checks in it to ensure that the built in "spare" capacity couldn't be >enabled without the machine "phoning home" to verify that the upgrade >was legitimate. How about if you allow the vendor code to periodically >connect to a company web site and report on the STIFLE information found >on the machine, to ensure that it was being run a comparable sized >machine? Then it would follow IBM's "trust" model. 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. -- Tom Schmidt Madison, WI -- 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, 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. 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. -- Tom Schmidt Madison, WI -- 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 17, 2007, at 9:53 PM, Jeffrey D. Smith wrote: --- SNIP--- Couple of ideas pop: 1. Reclassify "license refresh" as a non-update. Well in the real world where I was this is what happened. But the people demanding a stable system system went ballistic. They really raised holy H*LL about this (sorry darrin) I can't say I wasn't unsympathetic to them. We should have threatened to turn loose the ca- rep on them though. They would not have forgiven us for that but it would have gotten the point across. 2. Connect the production system to the outside world and let the ISV product talk to the ISV website server thing to verify license and dynamically update the license (e.g., "call home"). I have never seen this in real life does it really happen? Ed 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 -- 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?)
Ted, You keep claiming that IBM uses the "trust" model, however, that is simply not true. If IBM simply trusted you, the machine wouldn't have checks in it to ensure that the built in "spare" capacity couldn't be enabled without the machine "phoning home" to verify that the upgrade was legitimate. How about if you allow the vendor code to periodically connect to a company web site and report on the STIFLE information found on the machine, to ensure that it was being run a comparable sized machine? Then it would follow IBM's "trust" model. Wayne Driscoll Product Developer JME Software LLC NOTE: All opinions are strictly my own. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Saturday, February 17, 2007 6:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) >My needs are >- Expiration date >- Serial number check >- Feature control (that is, it is not all or nothing -- you can be >licensed for the product but not for optional feature X) What you need? What about what the customers need? IBM uses the 'trust' model. Why can't you? - 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?)
On 17 Feb 2007 19:54:18 -0800, in bit.listserv.ibm-main (Message-ID:<[EMAIL PROTECTED]>) [EMAIL PROTECTED] (Jeffrey D. Smith) wrote: Couple of ideas pop: 1. Reclassify "license refresh" as a non-update. An update is an update, and you can't reclassify it as something else. (Paraphrase of old riddle: How many legs does a dog have if you call a tail a leg? Still only 4; calling a tail a leg doesn't make it one.) If you tried to reclassify it and fat-fingered a key, production might stop. Then you get to explain to management how this wasn't really an update. 2. Connect the production system to the outside world and let the ISV product talk to the ISV website server thing to verify license and dynamically update the license (e.g., "call home"). Many of these check the license very early in the IPL sequence, often before any communications is possible. Also, I'd worry about spyware; I don't like the idea of software calling home. The methods I most agree with are fail-safe, grace periods, flat files with multiple keys (for combinations of dates, products, and serial numbers), and a quick response for emergency keys. -- I cannot receive mail at the address this was sent from. To reply directly, send to ar23hur "at" intergate "dot" 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?)
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. -- Radoslaw Skorupka Lodz, Poland -- 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 Ed Gould > Sent: Saturday, February 17, 2007 8:03 PM > To: IBM-MAIN@BAMA.UA.EDU > Subject: Re: License keys for ISV products(What alternatives are there?) > > On Feb 17, 2007, at 1:55 PM, Ted MacNEIL wrote: > > >> Not all products are like that. Maybe then the issue isn't so much > >> that keys are required, but the way they're sometimes implemented > >> by the vendor? > > > > Sometimes? -- all the time. No vendor, that we use, has made keys > > easy to use! > > > > > >> If keys were always received well before the old ones expired, and > >> all you had to do was enter them in a flat file, would that be a > >> big deal? > SNIP-- > > This is a more of a what if issue but I have seen it happen in the > real world. > > I have seen a system "frozen" no updates allowed for *any* reason. > The license expires (my memory says it was a CA product but its > immaterial) what does one do? > > Ed Couple of ideas pop: 1. Reclassify "license refresh" as a non-update. 2. Connect the production system to the outside world and let the ISV product talk to the ISV website server thing to verify license and dynamically update the license (e.g., "call home"). 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?)
On 17 Feb 2007 16:40:21 -0800, in bit.listserv.ibm-main you wrote: >>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. > >You still haven't explained why you are discouraging customers from buying >your products. > >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. > >And, I don't buy your arguments, because of my past experience with key-based >solutions. > >I hope I never need your products, because if I do, I will search for a >competitive product that doesn't shaft me (again) with keys. >I'm not saying yours does at all. I don't even know what it is. >What I am saying is I will not take a chance unless I absolutely have to. >Of course, you wouldn't like me as a customer; I have this annoying habit of >honouring contracts. > >BTW, I was not the only one with an opinion against software keys that chimed >in on this list. > >And, to put it on the other foot, if you don't understand why customers hate >software keys, then there is no use in me trying to explain it to you (or >Dave, or Russell). There are various pains with any software. The keys described by both Dave Cole and Russell Witt seem reasonable. The major problem may be random disaster recovery site where the CPU-ID is not known in advance. The proper management of keys and good disaster recovery plans should take care of all keys needed if the schemes are like those described by David and Russell. There are companies that play games so I can sympathize with vendors like XDC. One of the customers that tried doing that was the US government on some platform (maybe PC). > >PS: the crack about the accounts payable department was a cheap shot; it >didn't add anything to the discussion. As someone who has never worked for an ISV and who has been very lucky in the contracting firms he has chosen (they paid promptly), accounts payable sometimes can get interesting. The quality of work, promptness of payment and games played like taking prompt payment discount for paying within 10 days while actually waiting the full 30 can vary even by division within an organization. > >- >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?)
Judging from the number of responses to this thread, there are obviously many who do think keys are a big deal. It's a big deal because a processor upgrade that takes less than 5 minutes of a System Programmer's time to deal with the hardware and Operating System aspects, requires hours to deal with keys from multiple vendors, each with their own unique methods of acquiring and installing keys, and requires weeks or even months of follow-up until all issues from the last vendor are finally resolved. In the event of a real DR, in the initial days there will be enough serious problems to deal with without having immediate resolution of vendor keys be one of them - especially true for any vendor not equipped to supply keys in a matter of minutes, 24x7. For DR testing, we consider proof of the ability to get must-have keys from vendors in a timely fashion as part of the DR exercise. In our experience, the vendors concept of "timely" key delivery too often falls short of user needs. With the advent of dynamic CPU upgrades, the turn-around for CPU upgrades is now so quick that almost all such upgrades are "unscheduled" when compared to the turn-around for contract negotiations with vendors to support the new CPU. Our CE can "install" the new CPU in a few minutes; we may have to negotiate for months with vendors, even those we have even done business with for decades, before getting a new contract that we consider to have adequate safeguards for us and which is satisfactory to lawyers and bean-counters on both sides. In the mean time we may have to install temporary key after temporary key for months on end, and even after a contract is signed it may still be another month until we can finally get someone to turn loose with a "permanent" key - about time to start the whole process over again! Someone made mention of CA's web site for LMP keys. Last time I checked, 6 months after our last upgrade, it still only had the keys for our old CPU. Most of CA's keys, thank goodness, are fail soft, but not all. CA-Platinum DB2 utilities failed ungracefully without an EKG key at our last DR test. CA is not the only vendor that has trouble keeping all their databases correct on our current CPU - we received a "new" key just last week from another vendor for a CPU serial that was 8 months obsolete (yes they had been notified, and had previously sent us a good key for the current CPU). If vendors feel they have to implement key checking, then as a user I would prefer they all be failsafe (nags). If the vendor insists on implementing a hard failure, then there must be a grace period that at a very minimum should be much longer than the time period for contract re-negotiation. Rubber-stamping of a vendor-offered contract (seldom advantageous to the user) is not an option for us, and I suspect we are not alone. That grace period should automatically be restored when the product runs on valid keys, without any manual resetting required (ZEKE/ZEBB take note), so that the full grace period is assured to be in place if, heaven forbid, one has to deal with a DR for real. Vendors that can't meet these minimal requirements encourage us to look for alternative products. Dave Salt wrote: From: David Day <[EMAIL PROTECTED]> If an ISV doesn't use a key tied to a date and a machine serial number, what other mechanism is there to insure there are no pilfered copies of the ISV's product running somewhere, and the ISV doesn't have a clue? From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal? I don't see it as being a big deal either. When a customer licenses a product, they are given a key. A year later (or shortly before the license expires), the customer receives an invoice. If they pay the invoice, they get a new key. The customer replaces the old key with the new key (e.g. enters it in a flat file or ISPF table or whatever). Nothing needs to be to compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to enter the new key, and the customer is good to go for another year (or whatever the renewal term is). How is that a big deal? The only issue I can see is what happens when an unscheduled change of a CPUID occurs, such as might occur in a disaster situation. If the software is "mission critical" (i.e. needs to be up and running the very minute the switchover to the new CPUID occurs), it should already be licensed to run at the disaster site. Or, the software can display a message such as "This product isn't licensed to run on this CPUID", but will still run anyway (perhaps with limited functionality). This gives the customer time to acquire a new key, and everyone is happy. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm ... -- Joel C. Ewing, Fort Smith, AR[EMAIL PROTECTED] --
Re: License keys for ISV products(What alternatives are there?)
On Feb 17, 2007, at 1:55 PM, Ted MacNEIL wrote: Not all products are like that. Maybe then the issue isn't so much that keys are required, but the way they're sometimes implemented by the vendor? Sometimes? -- all the time. No vendor, that we use, has made keys easy to use! If keys were always received well before the old ones expired, and all you had to do was enter them in a flat file, would that be a big deal? SNIP-- This is a more of a what if issue but I have seen it happen in the real world. I have seen a system "frozen" no updates allowed for *any* reason. The license expires (my memory says it was a CA product but its immaterial) what does one do? 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?
At 2/17/2007 09:21 PM, PGilmartin wrote: Have you ever been caught in the middle between a vendor who believes that an automated expiry warning from the product is all that's needed to cause a payment, and an Accounts Payable department that won't cut a check without an invoice? The user must pay attention to the warning; ask Accounts Payable to send a check; wait for A-P to reply, "No invoice; no check"; plead with the vendor to send an invoice; wait for the vendor to generate an invoice outside standard process; check alternately with vendor and A-P whether invoice has been sent and/or received; plead with vendor for temporary key when latencies add up to more than warning interval. Etc. Suppose further that the vendor has only one competitor, and that competitor has announced end-of-marketing of its product. It is naive for a vendor to think, just because a customers accounts payable procedures might be in conflict with the terms of a license agreement, that they therefore can ignore the A-P requirements. It's more than naive. It is down right stupid. 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. At least that's been our experience. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.xdc.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
IBMLink SIS is FINALLY re-integrated
After many months of being forced to run two SIS searches to get both problem and Q&A data, IBM HAS FINALLY RE-INTEGRATED SIS! Still don't know any of the 5 W's related to THE COMPLETELY IDIOTIC decision to split SIS, but IBM finally did the right thing and put it back the way it was. They don't make any changes to IBMLink without months of design and coding, but somehow, no one at IBMLink knew why they split SIS. At least we were able to convince them to reverse this incredibly stupid change. I sometimes wonder if the IBMLink developers ever even use IBMLink. Thanks to all of you who chimed in, I know they didn't do it just for me. Regards, Tom Conley -- 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, Ted MacNEIL said: > Date: Sun, 18 Feb 2007 00:45:18 + > > PS: the crack about the accounts payable department was a cheap shot; it > didn't add anything to the discussion. > But it may have come from the shooter's own experience, not gratuitously. Have you ever been caught in the middle between a vendor who believes that an automated expiry warning from the product is all that's needed to cause a payment, and an Accounts Payable department that won't cut a check without an invoice? The user must pay attention to the warning; ask Accounts Payable to send a check; wait for A-P to reply, "No invoice; no check"; plead with the vendor to send an invoice; wait for the vendor to generate an invoice outside standard process; check alternately with vendor and A-P whether invoice has been sent and/or received; plead with vendor for temporary key when latencies add up to more than warning interval. Etc. Suppose further that the vendor has only one competitor, and that competitor has announced end-of-marketing of its product. -- 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?
> should not stop working and risk hurting any production activity. That's one of the reasons, I have been pontificating! It happened last weekend to one of our products. And, the vendor gave us temporary keys (30 days), because their records weren't up to date on what we had already paid. And, the guy (on our side), with the records not yet passed to the appropriate people, resigned a month ago. Dave S., if I purchase your product, and it causes me to lose revenue because of expired keys, will you cover my losses? - 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?
In a recent note, Russell Witt said: > Date: Sat, 17 Feb 2007 17:41:58 -0600 > > My own point of view is that an expired license should NOT cause the product > to stop working. Messages, yes; to let you know that the license has expired > and you are running the product without legal authority to do so. But it > should not stop working and risk hurting any production activity. > I can't help thinking of Murphy. Unanticipated program check in the code that issues the warning. Y2K-type problem: hard to test without changing the system clock and/or serial number. -- 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?
In a recent note, Shane said: > Date: Sun, 18 Feb 2007 07:38:42 +1000 > > Some products only get used by individual users, and key updates for > them tend to be flat-file and picked up the next time the product is > "called". Easy. > Except it's the user that gets the expiry message, and that has to > filter up to the correct (contracts) team who have to verify/authorise > payment, and may even get the new key. Then it needs to filter back to > some-one who can do the update. > 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. -- 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?)
Charles Mills wrote: [...] Was it Ronald Reagan who said "trust, but verify"? Hasn't even IBM gone to less and less of a "trust" model? Are not the restrictions on z/OS.e, for example, enforced by technology that is somewhat analogous to keys? Lenin was first with that (dowieriaj no prowieriaj). AFAIR Lenin wasn't capitalist. Software companies must have their incomes and profits, no doubt. It is discussed about the way their enforce it. Sometimes the way is very inconvenient to customer. IBM is big exception in the picture. -- Radoslaw Skorupka Lodz, Poland -- 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?)
From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL IBM uses the 'trust' model. Why can't you? It's easy to advocate the trust model when you have nothing to lose. I'm willing to give the trust model a try, if you're willing to compensate me for any losses. Deal? 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: Disposition of Log data in ISPF Panel
If you can locate the ISPF panel(s) that allow setting of the log options, you could have an installation-customized version of the panel that eliminates all options but "3". To initially set up users, you would either have to somehow "force" each user to select option "3" or locate and change the appropriate character in their profile dataset to set that lock option (hint, the field values are a letter, not the digits 1-4). But,... if your intent is for this to be an audit trail, not a diagnostic tool, forget it. Any sequential dataset that the user can create and log records to, he can also wipe records from. Also I don't think there is any easy way you can prevent the user from using "LOG KEEP" to create a new log file and then just completely deleting the old LOG. One would have to assume that any user savvy enough to be a risk requiring an audit trail would also be savvy enough to purge any incriminating ISPF log entries. Also you would have to daily offload and purge the log datasets if using option 3, to avoid them filling up. We have one case where we have used ISPF LOG retention: One marginally trained, clerical-type, ISPF user was periodically complaining she had created some PDS member months ago and it had since disappeared. SMF data showed no one else touching the dataset. To track down what was really going on, we forced the user's profile into LOG mode "4" (to avoid one dataset filling up), implemented a nightly batch process using batch REXX to archive all the user's daily LOG files into a daily GDG and delete old LOG files, and modified an installation edit macro that is invoked on entering EDIT or VIEW to create an ISPF LOG entry with the dataset/member name (ISPF by default creates a log entry only when a member is saved). Now if a similar complaint occurs, we can verify whether the described member ever was really edited, and if so, whether it was ever saved. We also suggested (once again) several possible ways the user could have failed to save their data. Amazingly enough the problem has yet to re-occur now that the user knows logging is in place. Another problem with ISPF logging is that the data is very limited (e.g., no data on panels used or panel field values), so unless you have installation dialogs written to log things of interest, you get a very limited view of what went on in the ISPF session. This feature appears to be intended more for logging diagnostic information than for an activity audit trail. Jacky Bright wrote: Like deletion of TSO datasets. Issuing TSO commands etc. These activities are recorded in log dataset when user logs off from the system dataset name like .SPFLOG1.LIST When user logs off user gets following option 1. Print data set and delete 2. Delete data set without printing 3. Keep data set - Same (allocate same data set in next session) 4. Keep data set - New (allocate new data set in next session) I want to disable 1 , 2 and 4 option. JAcky On 2/14/07, Binyamin Dissen <[EMAIL PROTECTED]> wrote: On Wed, 14 Feb 2007 12:28:28 +0530 Jacky Bright <[EMAIL PROTECTED]> wrote: :>I want to force all my TSO users to keep TSO Log dataset so that activities :>carried out by all TSO users can be recorded. What activities? :>AS of now all users are able to delete the datasets while logging off from :>the system. Also during the run. The also can turn off logging. :>How to configure this ? What data are you truly trying to collect? -- 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?)
>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. You still haven't explained why you are discouraging customers from buying your products. 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. And, I don't buy your arguments, because of my past experience with key-based solutions. I hope I never need your products, because if I do, I will search for a competitive product that doesn't shaft me (again) with keys. I'm not saying yours does at all. I don't even know what it is. What I am saying is I will not take a chance unless I absolutely have to. Of course, you wouldn't like me as a customer; I have this annoying habit of honouring contracts. BTW, I was not the only one with an opinion against software keys that chimed in on this list. And, to put it on the other foot, if you don't understand why customers hate software keys, then there is no use in me trying to explain it to you (or Dave, or Russell). PS: the crack about the accounts payable department was a cheap shot; it didn't add anything to the discussion. - 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?)
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. I didn't list the customers' needs because I assumed you customers whom I was addressing would know what your needs were; that was the point of my asking you to design a better approach for me. It's easy to criticize -- how about a solution? I hear a lot of input on how to make keys work well for the customer (plenty of notice, no IPL or re-link, easy 24x7 access to emergency keys, no hard cutoff [don't think I would do that one, but I hear you]) and believe me, I will keep it in mind, but I have not heard anyone propose a better solution than keys. Trust is not the answer, because not all customers (nor all of their employees and contractors) are trustworthy, and even fewer are totally diligent -- and many distributors, sadly, seemed to be intentional crooks. The front door lock analogy is a good one: MOST of my neighbors are trustworthy, too. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Saturday, February 17, 2007 4:00 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) >My needs are >- Expiration date >- Serial number check >- Feature control (that is, it is not all or nothing -- you can be licensed for the product but not for optional feature X) What you need? What about what the customers need? IBM uses the 'trust' model. Why can't you? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: License keys for ISV products(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. -- Radoslaw Skorupka Lodz, Poland -- 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?)
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 Russell Witt wrote: ... Something should be done to simplify the keys however. Myself, I think that CA should have something simple (web-based) were all the client has to do is input their site-id and a flat-file is created with all LMP keys licensed in a single file that can easily be downloaded (cut&paste, ftp, whatever) and activated on the CPU. -- 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?)
Something should be done to simplify the keys however. Myself, I think that CA should have something simple (web-based) were all the client has to do is input their site-id and a flat-file is created with all LMP keys licensed in a single file that can easily be downloaded (cut&paste, ftp, whatever) and activated on the CPU. Russ, You already provide this. I glom my CA keys off the web site. Regards, Tom Conley -- 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 needs are >- Expiration date >- Serial number check >- Feature control (that is, it is not all or nothing -- you can be licensed for the product but not for optional feature X) What you need? What about what the customers need? IBM uses the 'trust' model. Why can't you? - 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?)
>Perhaps the problem is with the speed of your accounts payable department? Perhaps not. And, perhaps I have had theses issues at more than one company? And, their speed doesn't make the actual application of the keys easier. - 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?)
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. 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. My own point of view is that an expired license should NOT cause the product to stop working. Messages, yes; to let you know that the license has expired and you are running the product without legal authority to do so. But it should not stop working and risk hurting any production activity. I do remember when LMP (CA License Management Program) was first introduced back in the early 90's. At the time, Charles indicated that if the license was expired the software would stop functioning. Boy, just the threat brought out all kinds of legal wolves. CA-LMP never did actually go into "fail mode", and never did actually stop any mainframe software for an expired license (at least to my knoweldge, I could be wrong). But if the license is expired or the wrong CPU is detected a WTO or message to the user is issued. Something should be done to simplify the keys however. Myself, I think that CA should have something simple (web-based) were all the client has to do is input their site-id and a flat-file is created with all LMP keys licensed in a single file that can easily be downloaded (cut&paste, ftp, whatever) and activated on the CPU. Of course, LMP is strong enough that no re-assemblies are required (or IPL of course). Just re-run the CAS9 proc with the new keys file and everything is taken care of. And of course there should also be a simple DR model where you enter your site-id and an alternate CPU ID(s) and temporary LMP keys would be generated for all licensed products for the new CPU(s). And of course, this web-site would need 24-hour availability with telephone support in case the DR site does not have internet connectivity. Just my opinion; Russell -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] Behalf Of Ted MacNEIL Sent: Saturday, February 17, 2007 4:44 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) >Maybe "all the time" for you. Clearly not all the time for everybody. 15 products that we are paying for, rather than our service provider. 15 different licensing scheme. 15 PITA's for key management. It sounds like we're not going to agree. Keys may be great for the vendor; they suck for the customer! - 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?)
>Maybe "all the time" for you. Clearly not all the time for everybody. 15 products that we are paying for, rather than our service provider. 15 different licensing scheme. 15 PITA's for key management. It sounds like we're not going to agree. Keys may be great for the vendor; they suck for the customer! - 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?)
>>Hasn't happened yet! >You can't change vendors? Unfortunately not. There are two products we have that are niche, and there are no competitors. - 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 keep in mind that if mainframe software maintenance were labor-free, most of the members of this list would not have jobs! If anyone has a better scheme, I'm all ears. IBM-MAIN members, design a software control system for me. How would it work? My needs are - Expiration date - Serial number check - Feature control (that is, it is not all or nothing -- you can be licensed for the product but not for optional feature X) - Relatively difficult to hack (nothing is impossible, of course) Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Saturday, February 17, 2007 11:55 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) >Not all products are like that. Maybe then the issue isn't so much that keys are required, but the way they're sometimes implemented by the vendor? Sometimes? -- all the time. No vendor, that we use, has made keys easy to use! -- 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?)
Perhaps the problem is with the speed of your accounts payable department? Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Cole Sent: Saturday, February 17, 2007 12:51 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: License keys for ISV products(What alternatives are there?) > >If keys were always received well before the old ones expired, and > all you had to do was enter them in a flat file, would that be a big deal? > >Hasn't happened yet! -- 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?)
Few thoughts: 1. The most expensive software is not protected by any key. I mean z/OS, DB2, CICS, IMS and all the IBM code. Some code is even delivered to you without payment, look at IFAPRDxx. 2. Sometimes the keys expire without any warning, it can happen because there's no warning in the product, or the product is not used day by day. Such surprise usually occur according to Murphy's law. 3. IMHO vendors should provide new key in advance, before the current one expires. They should take care about it! (assumed the payments are done). 4. Sometimes the product requires restart to enter new keys. It can be product restart, LNKLST update, or CICS regions restart. The last one is equal to production downtime. 5. DR. Although most vendors provide the key for DR machine, those keys cannot be entered in advance. I would like to have both keys in "key member", so the product would restart in my DR center without any special procedure. -- Radoslaw Skorupka Lodz, Poland -- 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?)
On Sat, 2007-02-17 at 20:45 +, Dave Salt wrote: > There are products that don't require jumping through hoops to enter a key, > and if you ever use one then maybe you'll feel differently about them. And > maybe you could then go back to the other vendors and say "why aren't your > keys as easy to use as this?". I can understand vendors wanting to protect their IP, and generate all the legitimate income they can. The problem I see is the plethora of schemes in use. Some products only get used by individual users, and key updates for them tend to be flat-file and picked up the next time the product is "called". Easy. Except it's the user that gets the expiry message, and that has to filter up to the correct (contracts) team who have to verify/authorise payment, and may even get the new key. Then it needs to filter back to some-one who can do the update. This may be a customer problem, but it's also a vendor problem if they get dropped because all the agro isn't worth the effort. That's the *easy* case - it's all downhill from there. - License STCs that need to be bounced with every key update. In 24x7 production environments ???. Do these people have any idea what that takes to get okay'ed ???. - stop all updates, switch to batch mode, re-cycle. Huh ??? See comment above. - unpack the XMIT'd load module, copy to running system(s) ... I have one customer that I do all of the above (and more) for. Telling the customer to swap out these products is not an option. 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?)
At 2/17/2007 02:55 PM, TMacNeil wrote: >Not all products are like that. Maybe then the issue isn't so much that keys are required, but the way they're sometimes implemented by the vendor? Sometimes? -- all the time. No vendor, that we use, has made keys easy to use! Maybe "all the time" for you. Clearly not all the time for everybody. As I implied in my prior post, maybe you need to lobby your vendor to improve the usability of its licensing management. >If keys were always received well before the old ones expired, and all you had to do was enter them in a flat file, would that be a big deal? Hasn't happened yet! You can't change vendors? Then is there a user's group for your vendor's customers? If not, do you want to start one? If these issues matter so much to you, then put energy into organizing pressure to get your vendors to improve their code. One way to start with the pressure is to stop being vague, stop with the unfocused aspersions, and start naming names. Too busy driving to stop for gas! If you're too busy to do what you need to do, then maybe it's not all that important to you after all. Maybe instead you could put your own reminder into your own calendar program to warn yourself enough ahead of time to get the relicensing ball rolling within your own company. (Now there's a startling thought...) 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?)
From: Ted MacNEIL <[EMAIL PROTECTED]> No vendor, that we use, has made keys easy to use! If that's the case, I understand your frustration. There are products that don't require jumping through hoops to enter a key, and if you ever use one then maybe you'll feel differently about them. And maybe you could then go back to the other vendors and say "why aren't your keys as easy to use as this?". Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Your Space. Your Friends. Your Stories. Share your world with Windows Live Spaces. http://spaces.live.com/?mkt=en-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?)
>Not all products are like that. Maybe then the issue isn't so much that keys >are required, but the way they're sometimes implemented by the vendor? Sometimes? -- all the time. No vendor, that we use, has made keys easy to use! >If keys were always received well before the old ones expired, and all you had >to do was enter them in a flat file, would that be a big deal? Hasn't happened yet! - 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: K E,1 Alternatives
Ed Long wrote: Thanks to everyone who offered their advice. A couple of points: 1: The console is in roll mode; this message is, rightly, considered serious enough to hang on the console. 2: At least of the replies (I'm in digest mode), I've seen so far, no one has explained why the K e,1,10 doesn't work, but apparently should. Is the console in roll mode, or roll delete mode? You can tell by looking at the bottom left of the console. It should say IEE163I MODE= R for roll or IEE163I MODE= RD for roll delete. Roll delete will only scroll deleteable messages, and leave non-deletable messages on the screen. Roll should scroll all messages. You can also use K S,DEL=W to set wrap mode which writes to the bottom of the screen and then starts over at the top rather than scrolling. -- Richard -- 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/17/2007 12:21:36 P.M. Central Standard Time, [EMAIL PROTECTED] writes: If the do, do you want to deal with them? >> Yep and do. Can live without lower parts, chose ventricles on purpose to simulate heart beat. -- 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]> I work for a company that would not screw the vendor. The company should be trusted. Would I screw my reputation because I want 'free' software? I believe you wouldn't steal software, but I'm not so sure about the person who sits next to you or the guy in Timbuktu. My neighbour wouldn't screw me over. Despite this, I still lock my doors every time I leave the house. Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Find what you need at prices youll love. Compare products and save at MSN® Shopping. http://shopping.msn.com/default/shp/?ptnrid=37,ptnrdata=24102&tcode=T001MSN20A0701 -- 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: K E,1 Alternatives
Ed Long wrote: Thanks to everyone who offered their advice. A couple of points: 1: The console is in roll mode; this message is, rightly, considered serious enough to hang on the console. 2: At least of the replies (I'm in digest mode), I've seen so far, no one has explained why the K e,1,10 doesn't work, but apparently should. From MVS System Commands under the description of K E http://publibz.boulder.ibm.com/epubs/pdf/iea2g170.pdf ,Note:, Do not use this command to try to remove a range of, non-deletable messages; you can remove only one, non-deletable message at a time., -- Richard -- 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: K E,1 Alternatives
OK, you made me look. From z/OS 1.4 through 1.8 the commands book has the following under the description of K E,nn,nn "Note: Do not use this command to try to remove a range of non-deletable messages; you can remove only one non-deletable message at a time." Go with the PF key. Bob Ed Long wrote: ... 2: At least of the replies (I'm in digest mode), I've seen so far, no one has explained why > the K e,1,10 doesn't work, but apparently should. -- 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 don't see it as being a big deal either. When a customer licenses a product, they are given a key. A year later (or shortly before the license expires), the customer receives an invoice. If they pay the invoice, they get a new key. Really? Most of the time the customer has to discover the key is expired! Even if you're not sent a new key ahead of time, the product should start warning you before the key expires. If you're encountering situations where you're not being sent a new key ahead of time and the product isn't warning you a key is about to expire, something is seriously wrong. >The customer replaces the old key with the new key (e.g. enters it in a flat file or ISPF table or whatever). Nothing needs to be to compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to enter the new key, and the customer is good to go for another year WRONGO! We have to compile/linked/refresh all of our keys! Not all products are like that. Maybe then the issue isn't so much that keys are required, but the way they're sometimes implemented by the vendor? If keys were always received well before the old ones expired, and all you had to do was enter them in a flat file, would that be a big deal? Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Your Space. Your Friends. Your Stories. Share your world with Windows Live Spaces. http://spaces.live.com/?mkt=en-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(Cole Software's view)
We at Cole Software use licensing keys to protect our z/XDC product. These keys enforce the both the machines and time periods in which our product runs. There are more good reasons to do this than you might think: 1) Intellectual property protection [duh.] 2) Liability protection. [huh?] Let me explain. z/XDC is a powerful tool that can be used (security permitting) by a malicious person to corrupt a system. If a copy is stolen and used to create mischief on a 3rd party system, then that creates a liability *BOTH* for us *AND* our customer: a) It creates a liability problem for us because we don't have a contract with that 3rd party establishing the limits of liability. b) It creates a liability for our customer because he's the one that let the product get stolen in the first place. c) If a lawsuit should occur, just the simple fact of having licensing controls is helpful to our defense. (It shows that we went to extra effort to create protection.) So execution-CPU controls protect the both of us. 3) We sell z/XDC via a lease (not a permanent license) (maintenance included). That lease expires periodically. Our license controls are set to expire after 30 day grace period past the end of the lease. That way, should a corporation decide that they do not want to renew, The expiring license limits the ability of a "rogue" employee to violate corporate's wishes. So the expiration helps the customer (the corporation) to avoid unwanted liabilities to us. 4) We do have a few customers who tend to be "slow pay". Having a technologically enforced expiration date is helpful in those situations (although historically, we're pretty soft-a$$'d about this. We've been known to give extensions for months!) User Friendliness: As for usability concerns, if a product needs to be taken down just so that licensing controls can be applied, then that product needs to be rewritten! With out product, licensing controls can be done on the fly with no interruption of service. To avoid surprise expirations, our product issues an expiration warning starting 21 days before expiration. The lead time for that warning can be change by the customer to whatever time period the customer chooses. Also, 30, 60 or 90 days out [depending upon the customer], our own people will have already been in touch with an expiring customer's purchasing department to help get the renewal paperwork going, both so that we get paid our renewal fees on time and so that the customer's users avoid service interruption. In the event that a customer's bureaucracy has failed to renew the lease in time, our web site has a service by which any customer (expired or otherwise) can obtain temporary license activation codes on an instant 24x7 basis. (Obviously, our web site incorporates certain fraud and abuse controls, and it does report to us details about who has used the service.) Disaster Recovery: Since our licensing codes are CPU sensitive, a problem does arise for DR testing (and real DR). But this problem is resolved by our web site service. A sysprog at a disaster recovery site can get temporary licensing codes over the net 24x7, for the recovery machines. Trust? As regards the trust model, tried that. Didn't even get a T-shirt. I started writing license control support back in the mid '80s when I discovered that one customer, which was licensed to use the product on two computers, actually was using it on 7! When they installed the next release, they howled about how they could no longer use XDC on their "backup" systems. One way or another, though, I guess they made do. They didn't increase their purchase, but they did stay with us another decade and a half. Haven't had much cheating since... Nevertheless, the trust model can work because customers, especially large ones, are not monolithic. It's both hard and risky to get word of licensing cheating down to all of the troops. Sooner or later, someone is going to contact the vendor to resolve a product problem, and that's a likely moment when licensing cheating will be discovered. (I view those moments as sales opportunities. ) But why create a situation where the opportunity to cheat is too easy? Sometimes the "cheating" is entirely inadvertent. Sometimes small products can get lost in the musical CPUs shuffle unless they speak out. Licensing codes are a way in which z/XDC speaks out. The point is, yes licensing codes can be a P.I.T.B., but they do provide *mutually* beneficial protections. And yes, it is definitely incumbent upon the vendor both to write their licensing management software to be as friendly as possible, and to provide as responsive a customer support service as they can. Dave Cole REPLY TO: [EMAIL PROTECTED] Cole Software WEB PAGE: http://www.xdc.com 736 Fox Hollow RoadVOICE:540-456-8536 Afton, VA 22920FAX: 540-4
Re: License keys for ISV products(What alternatives are there?)
>If I stopped locking my doors, I could throw away all my keys and just use the >trust model Bad analogy! The trust model is regarding software. NOT personal safety/security. There is a difference between a home invasion and accessing software. I work for a company that would not screw the vendor. I have been in the field for a few years! The company should be trusted. Would I screw my reputation because I want 'free' software? - 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?)
I'm often the voice of dissent here. Let me throw out a few counter-thoughts. Bruno Sugliani wrote "we don't care (sorry about that) about the sharks robbing the poor salesmen" and he's right, of course. It's not your (the customers') problem if our (the vendors') salespeople have difficulties doing their jobs. But there's a bar in San Francisco with a sign that says "we cheat the other guy and pass the savings on to you." The converse is also true. Every dollar that a software company fails to collect is a dollar less that is available to fund enhancements, support staff, new hardware, and yes, the profits that attract investment in a capitalist economy. To some extent, you suffer from the software company's problems. I basically did and do trust the customers. My theory was that few customers would base a mission-critical process on stolen software, and few would pay 5-digit prices for software that was not for a mission-critical process, so license keys at best prevented people from running copies of our software that they would not have paid for anyway, such as a programmer who loved our product so much that he took a copy with him for personal use when he changed jobs. Such thefts may have impacted our pride, but not our bottom line. As I said in an earlier post, I put the keys in primarily to control trials, not licensed customers. However, trust or not, several customers subsequently came out of the woodwork with "we didn't know that group was running your software on that box." I believed them, but I still cashed their checks and used the money to help fund our company. Contrary to what some of you may think, a small software company is not a license to print money. We struggled many months, and came very close twice to shutting our doors. Another factor in license keys that many of you may not have considered: distributors. Most small software companies sell overseas through distributors. It is my impression that for some reason, the business of distributing foreign software attracts a disproportionate number of outright thieves. The software publisher needs keys to control the activities of the distributor, who otherwise can sell software (to unsuspecting and trustworthy customers) and pocket all of the money. We shared a British distributor with a small software company whose name you would recognize in a heartbeat, and that I think has a reputation with most of you as "nice guys." We jointly discovered that our common distributor had stolen tens of thousands of dollars from us (by selling and pocketing the revenue from feature upgrades that were not protected by our key technology) and hundreds and hundreds of thousands of dollars from this other company, which could ill afford the loss. (It was not because their software was not protected by keys, but rather because they had given him the key generator, that this was possible, but the principle is the same.) Was it Ronald Reagan who said "trust, but verify"? Hasn't even IBM gone to less and less of a "trust" model? Are not the restrictions on z/OS.e, for example, enforced by technology that is somewhat analogous to keys? I would love to see a common, universally-accepted system that was easy to use and presented little burden to all concerned. IBM sort-of tried with their license manager. 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. (That's one reason there is no single common software license form that multiple companies all use -- wouldn't THAT make life easier?) Until something better comes along, I think keys, administered in an intelligent and customer-friendly manner, are the best solution to a problem with no really good answers. Charles -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of David Day Sent: Saturday, February 17, 2007 5:27 AM To: IBM-MAIN@BAMA.UA.EDU Subject: License keys for ISV products(What alternatives are there?) The current discussion on license keys prompts this. If an ISV doesn't use a key tied to a date and a machine serial number, what other mechanism is there to insure there are no pilfered copies of the ISV's product running somewhere, and the ISV doesn't have a clue? From a user's perspective, if l -- 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?)
The key point is it complicates an already complex environment! I can see a use for evaluation keys, but once the contract is signed, give me a permanent key, and use the 'trust' model. I have about 15 keys on my keychain. I can never find the right one; it certainly complicates my environment. If I stopped locking my doors, I could throw away all my keys and just use the trust model.:-) Dave Salt SimpList(tm) - The easiest, most powerful way to surf a mainframe! http://www.mackinney.com/products/SIM/simplist.htm _ Free Alerts : Be smart - let your information find you ! http://alerts.live.com/Alerts/Default.aspx -- 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 don't see it as being a big deal either. When a customer licenses a product, >they are given a key. A year later (or shortly before the license expires), the customer receives an invoice. If they pay the invoice, they get a new key. Really? Most of the time the customer has to discover the key is expired! >The customer replaces the old key with the new key (e.g. enters it in a flat >file or ISPF table or whatever). Nothing needs to be to >compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to >enter the new key, and the customer is good to go for another year WRONGO! We have to compile/linked/refresh all of our 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?)
From: David Day <[EMAIL PROTECTED]> If an ISV doesn't use a key tied to a date and a machine serial number, what other mechanism is there to insure there are no pilfered copies of the ISV's product running somewhere, and the ISV doesn't have a clue? From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal? I don't see it as being a big deal either. When a customer licenses a product, they are given a key. A year later (or shortly before the license expires), the customer receives an invoice. If they pay the invoice, they get a new key. The customer replaces the old key with the new key (e.g. enters it in a flat file or ISPF table or whatever). Nothing needs to be to compiled/linked/refreshed/IPL'd (etc). It just takes a couple of minutes to enter the new key, and the customer is good to go for another year (or whatever the renewal term is). How is that a big deal? The only issue I can see is what happens when an unscheduled change of a CPUID occurs, such as might occur in a disaster situation. If the software is "mission critical" (i.e. needs to be up and running the very minute the switchover to the new CPUID occurs), it should already be licensed to run at the disaster site. Or, the software can display a message such as "This product isn't licensed to run on this CPUID", but will still run anyway (perhaps with limited functionality). This gives the customer time to acquire a new key, and everyone is happy. 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?)
>License agreements, hardware, they pretty much got you by the ventricles. I tend to believe any professional and respected company will not screw their reputation. If the do, do you want to deal with them? By the way, ventricles are part of the heart. I assume you meant a slightly lower set of body parts? - 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: K E,1 Alternatives
Thanks to everyone who offered their advice. A couple of points: 1: The console is in roll mode; this message is, rightly, considered serious enough to hang on the console. 2: At least of the replies (I'm in digest mode), I've seen so far, no one has explained why the K e,1,10 doesn't work, but apparently should. I will try out your suggestions and report back. I appreciate the PF key setup suggestion immensely. Thank you all again. Ed Long <[EMAIL PROTECTED]> wrote: Hi everyone. I recently suffered a console flood caused by the RACFDS running out of space. This is an ADCD z/OS 1.5 system. The out of space condition appears to have occurred due to an oddity in how DB2 archive logs were RACF protected. Each dataset Db2 created caused RACF to create a matching RACF profile. The dataset names of course have Date and Time in them so are unique. It appears to have taken 5.5 years to blow out RACF. I deleted the existing profile and created a generic profile which appears to not cause the problem. Oh, I also deleted all the old profiles. My actual question has to do with the control operator command. On this system, the only form of it that appears to work is K E,1 (delete 1 message). K E,1,10 - according to the Command Reference manual should delete the first 10 action messages; but it gets rejected due to 'invalid range'. My fingers got tired repeating k e,1 for every IRR405I that got generated. Is this correct that only K E,1 should work? Is there a better procedure than this for dealing with the flood, short of punching out and reipling? Will Daiske survive Yankee Stadium? Thanks. Edward Long Edward Long -- 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/17/2007 11:30:57 A.M. Central Standard Time, [EMAIL PROTECTED] writes: IBM works with a 'trust' model. Why can't the rest? >> License agreements, hardware, they pretty much got you by the ventricles. The rest have to provide a service that is better or unique to their area of expertise. It's a cold cruel world. Cottage industries copying everything from CD's to Nuclear weapons spring up daily and with the big-I distribution is only a click away. Sometimes state supported... -- 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
SMF Record Types 63, 67, 68 and 69
Greetings, I am working to finalize another level of DAF. I am thinking about removing support for SMF record Types 63, 67, 68 and 69. These SMF record types were used soley for VSAM catalogs, which stopped functioning on 1/1/2000. Most installtions keep general SMF data for a period of weeks or months, not years. Does anyone have SMF record Types 63, 67, 68 and 69 retained for more than 7 years? Let me know. Cheers... Michael Cheap talk? Check out Yahoo! Messenger's low PC-to-Phone call rates. http://voice.yahoo.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?)
>Sounds like a management opportunity. Change the Service provider or replace >the vendors. Love to. Vendors are niche products. Service provider has a few years to go on the contract, with penalties. But, that wasn't my point. IBM works with a 'trust' model. Why can't the rest? Planning is good. Simplification is better! - 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?)
In a message dated 2/17/2007 10:57:26 A.M. Central Standard Time, [EMAIL PROTECTED] writes: We don't get much of that from our service provider and a couple of (nameless) vendors. >> Sounds like a management opportunity. Change the Service provider or replace the vendors. Then you can do do do 'til the next planning cycle! _http://www.dilbert.com/comics/dilbert/archive/dilbert-20070216.html_ (http://www.dilbert.com/comics/dilbert/archive/dilbert-20070216.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?)
>It complicates upgrades and DR but it's all doable with planning. Planning isn't enough! You also need execution. We don't get much of that from our service provider and a couple of (nameless) vendors. We end up long on planning; short on execution. - 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?)
In a message dated 2/17/2007 7:53:26 A.M. Central Standard Time, [EMAIL PROTECTED] writes: The key point is it complicates an already complex environment! I can see a use for evaluation keys, but once the contract is signed, give me a permanent key, and use the >> It's a value assessment based on risk and functionality. Back in the olden days GRS just couldn't cut it in a JES3 environment especially. So we found MXI(now MIM) from Allen Systems. It was great in many respects. Down side was without electronic delivery or notification the contract office would get the updates a couple weeks in advance then it would trickle down to those who needed to apply them. The really perverse nature is that it would run past the end of expiration until it hit somebody's birthday-usually one of Medici's. Vlad the Impaler, Lizzie Borden also in the mix. As Bruno suggests it can be a motivator/incentive for software cleanup and review that probably should have been done months ago. That's our job. The ISV's want to protect intellectual property and trade secrets. That's there job. It complicates upgrades and DR but it's all doable with planning. My favorite vendor mechanism is IBI's. Keys required but they give a thirty day grace period for DR so usually can get in and get out before really have to do anything. 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. -- 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 17, 2007, at 7:58 AM, Ted MacNEIL wrote: SNIP-- From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal? 1. That's a big IF. 2. In a 7/24 multi-time zone environment, getting the capability to stop all users of a product long enough to apply the keys is problematic. 3. You don't always know until the last minute (usually on a weekend), and some companies (PKWARE, for example), only work M-F/9-5. 4. If you're out-sourced, you sometimes have the service provider: a. Waiting until after they expire to tell you. b. Slow in applying them. c. Making mistakes and applying another customer's keys. The key point is it complicates an already complex environment! I can see a use for evaluation keys, but once the contract is signed, give me a permanent key, and use the 'trust' model. --SNIP- Ted, You are right on the money. We ran into the PKWARE issue 7-9 years ago. *NOT* a company to do business with, IMO. Keep the issue simple and fool proof that is a simple request, no? 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?)
>If an ISV doesn't use a key tied to a date and a machine serial number, what >other mechanism is there to insure there are no pilfered copies of the ISV's >product running somewhere, and the ISV doesn't have a clue? There is the 'trust' model, which IBM uses. >From a user's perspective, if the ISV is timely in his delivery of license >keys, why is it a big deal? 1. That's a big IF. 2. In a 7/24 multi-time zone environment, getting the capability to stop all users of a product long enough to apply the keys is problematic. 3. You don't always know until the last minute (usually on a weekend), and some companies (PKWARE, for example), only work M-F/9-5. 4. If you're out-sourced, you sometimes have the service provider: a. Waiting until after they expire to tell you. b. Slow in applying them. c. Making mistakes and applying another customer's keys. The key point is it complicates an already complex environment! I can see a use for evaluation keys, but once the contract is signed, give me a permanent key, and use the 'trust' model. - 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
License keys for ISV products(What alternatives are there?)
The current discussion on license keys prompts this. If an ISV doesn't use a key tied to a date and a machine serial number, what other mechanism is there to insure there are no pilfered copies of the ISV's product running somewhere, and the ISV doesn't have a clue? From a user's perspective, if the ISV is timely in his delivery of license keys, why is it a big deal? I'm not asking this last question sarcastically, I'd like to know if there are issues with this that I'm not taking into account. --Dave -- 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
Obviously IBM does it, but I believe CA now also asks for monthly SCRT (Subcapacity Reporting Tool) reports from its customers who are under certain types of software contracts. Thus apparently there's ISV precedent. Why don't you do that? It's the same process your customer is (likely) already following, but they'd simply add another "bcc" to the e-mail list when they send in their monthly reports, so it's not imposing on them extra burden (as license keys would). Your product can cut the necessary SMF type 89 records to appear in the report if you want. That's ideal, actually. Failing that, you can reference off another product that your product depends on, such as CICS, IMS, or DB2. Coupled with this, please make sure you're actually delivering additional value to your customers every year (or even perhaps every month), including PTFs (if any, as applicable) and new functions/new releases. That's usually called "software subscription." No SCRT reports, no updates -- and that's a fair bargain for both parties. - - - - - Timothy Sipples IBM Consulting Enterprise Software Architect Specializing in Software Architectures Related to System z Based in Tokyo, Serving IBM Japan and IBM Asia-Pacific E-Mail: [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: New Level of Dataset Audit Facility (DAF) is Coming Soon
LBI support would be nice. All our SMF tape archives are written by DFSORT with blksize > 32K so before I can run DAF the data has to be copied back to DASD first. If DAF would support LBI it would be much more convenient. Thanks. -- Jeff Michael Cleary said the following on 02/16/2007 07:04 PM: Greetings, I am working to finalize another level of DAF. Changes so far since DAF 1.4.7 include: Add keyword DEVADDR Add keyword DEVTYPE Add SMF Record Type 21 support Add SMF Record Type 90 Subtype 01 support Add SMF Record Type 90 Subtype 02 support Add SMF Record Type 90 Subtype 08 support Add SMF Record Type 92 Subtype 11 support Add Virtual SMF Records 001 001 - Virtual APFLST 001 002 - Virtual LNKLST 001 003 - Virtual LOADPARM 001 004 - Virtual LPALST 001 005 - Virtual Master Catalog 001 006 - Virtual PAGE 001 007 - Virtual PARMLIB 001 008 - Virtual RACF 001 009 - Virtual UADS Change DAFSMF QSAM to BUFNO=200 Change DAFSMF VSAM to BUFND=200 RMODE31=BUFF Correct DAF014/15 Correct DASD/TAPE Correct DAF014/15 Process PDSE Statistics Type Correct DAF045 JESx Completion Codes Correct DAF064 No Extent Information Correct DAF080 Jobname UNKNOWN when hex zeroes Correct DAF081 Process All Datasets Correct DAF082 S021 Multiple Errors Correct DAF088 S001 Missing Lengths Correct DAF118 Check FTP Command Validity Correct DAF8XR Display PERMIT ACCESS and ID Correct DAFCSP Test For Comments Correct NFTP S034 Skip If Nothing To Process Enhance numerous SMF Record Types Let me know if you can think of anything else. Cheers... Michael -- 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
On Sat, 2007-02-17 at 09:26 +0100, Birger Heede wrote: > http://www.ibm.com/software/awdtools/lum/ > > You looking for a z/OS port? Nope. ILM was an unmitigated bloody disaster. Somehow I can't see all the ISVs trusting their entire (z/OS) income to Tivoli. 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
http://www.ibm.com/software/awdtools/lum/ You looking for a z/OS port? Birger Heede IBM GBS Shane wrote: But once we have a contract , i do not accept to be taken hostage by a key with a serial number . Hey, how about we get IBM to provide a licensing API. m - maybe not. We've been there before folks - keep the garlic and wooden stakes handy, in case the undead rises again. 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 -- 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
