BobL said: * I have to disagree on Compuware products. We have a bunch, and the License administration application works fine. We just go into the panels, set DR mode, and we're good for 14 (?) days. For us at least, it's a very workable solution for DR.*
Spoken like a systems programmer! The License panel asks for Port Number, Host Name, Host Address, TCP STC name. Remember that the DR user is not always you. I had to look all this up, because it's not my gig. But our guys who deal with vendors and licences hate the process. On Tue, Mar 6, 2018 at 3:56 AM, Lester, Bob <[email protected]> wrote: > Hi Wayne, > > I have to disagree on Compuware products. We have a bunch, and the > License administration application works fine. We just go into the panels, > set DR mode, and we're good for 14 (?) days. For us at least, it's a very > workable solution for DR. > > Thanks! > BobL > > -----Original Message----- > From: IBM Mainframe Discussion List [mailto:[email protected]] On > Behalf Of Wayne Bickerdike > Sent: Sunday, March 4, 2018 1:25 PM > To: [email protected] > Subject: Re: Product license key program [ EXTERNAL ] > > We always have issues during DR with licence keys. > > Worst vendor is Compuware, convoluted process and activation procedure. > > We like to expose "novice" users to the DR process, it's a test of > documentation and process, not systems skills. > > One vendor had the cheek to tell us to give more warning. I told them we > are testing you as much as DR. > > Don't mind CA, they don't disable just give warnings. > > On Mon, Mar 5, 2018 at 6:55 AM, Seymour J Metz <[email protected]> wrote: > > > 1. BTDT,GTS - I'm not talking ideology or abstract theory, but history. > > Vendor promises are worthless when push comes to shove. > > > > 2. In the incidents I was referring to we *did* get the keys in advance; > > they didn't work and the vendor failed to respond within the > > contractually > > guarantied time window. That's why I asked about how you handled > > DR tests. > > > > 3. I'm not concerned with the customer who has delayed renewing, I'm > > concerned with the customer who is fully paid up and doesn't get > > what he paid for. > > > > 4. "To indemnify for or from what exactly?" The cost of the DR > > facilities that could be > > tested because of the bad keys would have been a start. > > > > 5. "what associated risk? The risk that they will not pay their > > license fee and therefore > > lose the use of the software?" > > > > More straw dummies. Stop trying to put words in my mouth. > > > > 6. "you are assuming that the Key or the requirement thereof will > > somehow, through the > > fault of the "key", cause an outage. ". > > > > No, *you* are assuming that I don't have empirical evidence. See > > item > > 2 above. > > > > 7. "4) What about it? They paid for the key, it's implemented, and > > it works." > > Were that true I wouldn't have commented. We paid for the keys, it > > was implemented > > and it *didn't* work. > > > > 8. "and not a generation issue or some other purely human factor?" > > From the customer perspective the vendor is a black box; he doesn't > > care whether the outage cased by the vendor was due to hardware, > > software or human error. > > > > 9. "I don't think most vendors try to tell the client what metrics to > > use in > > evaluation (aside from CA maybe:))" > > > > CA never had the nerve to patronizingly dismiss our concerns. They > > accepted > > them as legitimate and addressed them as best they could. > > > > 10. "6) What danger inherent in the enforcement method? " > > See item 2 above. > > > > 11. "The key works or it doesn't, if it doesn't, either it expired, the > > software has been altered or changed or it never worked in the > > first place. " > > How do you propose that the customer tests whether a DR key works > prior > > to going to the DR site and testing? > > > > 12. " I really don't mean to sound flippant, but sending software out > > without keys > > would be similar (maybe only to me) as Ford sending out all of > > their cars without > > an ignition key or secure button. " > > Only to you; Ford doesn't try to lock its customer out of the car. > > > > Bottom line: keys are bad because historically they have caused > > problems for legitimate users, often problems that the vendor had > > promised wouldn't occur. > > > > -- > > Shmuel (Seymour J.) Metz > > https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7Es > > metz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMjoS > > vFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3ccs > > 7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e= > > > > ________________________________________ > > From: IBM Mainframe Discussion List <[email protected]> on > > behalf of Brian Westerman <[email protected]> > > Sent: Saturday, March 3, 2018 1:22 AM > > To: [email protected] > > Subject: Re: Product license key program > > > > Hi Shmuel, this is just a friendly discussion, and I know I tend to > > have a odd sense of humor sometimes, so please don't take any of what > > I mean as levity as something personal. I really am trying to > > understand your point. If you can convince me that there is some > > inherent danger in using keys, then I will address the problem and see > > about coming up with something that removes the danger but still > > provides protection for the vendor. Just because vendors have used > > keys for years (and years) doesn't make it right, nor does it make it > > wrong, that's why I'm trying to understand your side of this. I > > think I'm fairly smart, and if I had to come up with a substitute for > > keys, I could probably do it, but I'm sure you understand that I don't > > want to waste time on something that might be unnecessary. > > > > I have heard people complain from time to time about keys, but > > normally it's because of something not related to the keys themselves > > like it was "inconvenient" to get their purchasing department to send > > the check on time. That stuff happens, but it's not the fault of the > > keys, and in fact, sadly it tends to make vendors feel better about > > having the key there in the first place because it's the "reminder" to > > the client to "pay their bills" on time. I'm sure you can understand > > that vendors deal with that event all the time, and it's sad to say, > > but like your local plumber, we/they have "heard it all before". > > Sometimes giving the extra 30 days and allowing the client to get a > > temporary 14 day key after that still isn't enough, and we, (as do > > most other vendors) have procedures to extend it even more, but at some > point you have to be able to "draw the line". > > > > Is that ins some way unreasonable? If so, why? > > > > Now to the meat of things: > > > > You said "Are you willing to put an indemnification clause in your > > contracts?". To indemnify for or from what exactly? > > > > One point on indemnification,and contracts in general, is if both > > parties of a are not contract equally, or more to the point equitably, > > or no "special" compensation for that inequality is clearly defined > > (this is simple contract law, and yes, unfortunately I do have a law > > degree and my son is a practicing lawyer), then the clause is invalid, > > thus, if the site wants to be indemnified, they would have to likewise > > indemnify the vendor or provide some "special" compensation for that > > accommodation. The "special" compensation is not just the "price of > > the product", so don't say they are "(over) compensated already, so > that's the compensation part":). > > For instance, (and this event has happened many times to many > > vendors), if a site were to allow (through their actions or even due > > to no "action" at all), the vendor's software to be used at another > site, even an "alternate" > > site of their own (but that's getting off the point), and "anything" > > is "damaged" or "damages" are incurred, including loss of revenue for > > the vendor (because of the theft of the software), then the site would > > have to accept full responsibility. > > > > I can't think of any site that would ever agree to that. Likewise, > > expecting any vendor to agree to indemnify a site for unforeseen and > > unspecified damage(s), is never going to be able to be enforceable. > > Any unenforceable part of a contract is (by simple definition) not > > enforceable and therefore invalid. > > > > Why place a clause into a contract that has no chance at all of being > > enforceable? it cheapens the contract and the ability of either > > party, especially the one who wrote it in the first place to enforce it. > > > > also, in response to your numbered points: > > > > 1) what associated risk? The risk that they will not pay their > > license fee and therefore lose the use of the software? The risk of > > the Key "not working"? I'm not trying to be obtuse, I just don't see > > what the actual "risk" here is. > > > > 2) Okay, I must have misunderstood, sorry for that part. > > > > 3) you are assuming that the Key or the requirement thereof will > > somehow, through the fault of the "key", cause an outage. I guess > > that brings me back to the risk part above, how does the key in and of > > itself present any danger. I can understand if the key were to fail > > (which I have never heard of any spontaneous key failures anywhere), > > or if the client were to fail to complete the license (i.e. not pay) > > and it expires, but how is that the fault of the vendor or the key. > > Obviously there must be some other criteria that you are using that I > > have been overlooking. What are the circumstances that would apply in > this case? > > > > 4) What about it? They paid for the key, it's implemented, and it works. > > Are you saying what happens if it doesn't "work"? That would be the > > same as if you have a product that does some specific "thing" and for > > some reason it stopped doing that "thing". Do you expect the vendor > > to fix it, yes, of course you do. Why would a key be any different? > > Again, I have never heard of a key just spontaneously stopping for no > > reason, so I am searching for tangible justification here. > > > > 5) Again, I don't see the aspect of "chance" in this. Have you EVER > > experienced, or ever heard of it happening that was verifiable, of a > > Key failure that was caused by the key or the mechanism itself and not > > a generation issue or some other purely human factor? Maybe if a new > > version of the software was sent that didn't work with the old key, > > but that's again grasping on my part, and would fall into the "human > > error" part. So it brings me back to ... Have you ever experienced a > > spontaneous key failure that was not related to expiration or error > > from other than the actual Key or the Key process itself? Again, this > > is just one of those things that I have never heard of happening. > > Keys just don't stop working without a logical reason. I suppose that > > the key could get damaged by a hardware failure or something, but I > > don't see how that would be the fault of the vendor of the software. > > Again, I'm probably missing something important, so please give me an > > example that I can use to try to understand this better. > > > > 6) What danger inherent in the enforcement method? I think it's > > relatively simple and uncomplicated and not fraught with any real risks. > > The key works or it doesn't, if it doesn't, either it expired, the > > software has been altered or changed or it never worked in the first > > place. I think this is another one of those areas where you probably > > honestly do know what you are talking about, but I am unable to get > > your meaning from the one sentence response. > > > > I am not trying to misrepresent your position, I am trying to > > understand it from the vendor side or even from your side, but I can't > > see your side if you don't make it clearer for me. I'll admit that > > sometimes I can be pretty stupid, just ask my wife she will tell you, > > but I honestly am trying to see your point(s), I just haven't got there > yet. > > > > I don't think most vendors try to tell the client what metrics to use > > in evaluation (aside from CA maybe:)), and I agree with you that ALL > > VENDORS need to disclose everything up front. The same should be true > > of the client, but sometimes (not very often, but enough times) the > > client is not very "up front" with the vendor. That was the point I > > was making by telling you of the problem we had with the guy that took > > our software to another site and expected us to make it work for him > there. > > > > I still would like to know what the risks are that keys impose on the > > customer. I really don't mean to sound flippant, but sending software > > out without keys would be similar (maybe only to me) as Ford sending > > out all of their cars without an ignition key or secure button. > > Again, this is taking an extreme view again, but when you buy your > > car, do you ask GM (et.al.) to sign a indemnification clause because > > you might lose your keys, or the key might get bent in the lock, or > > your dog eats them? There could be lots of consequential damages from > > not being able to use your car, related to the key, but not the fault > > of GM. (remember this is a far fetched (entirely a joke) reference), > > but, based on the information I have gleaned from your posts so far it's > (almost) reasonable to ask. > > > > > > I'm looking for something tangible that tells me what the "bad" part > > of keys are. If it's just you personally don't like them or feel that > > they are otherwise inherently bad for no particular reason, then I can > > live with that, but I don't want to go off assuming that there is no > > basis for your complaint. > > > > I don't know how many vendors, even the company I work for, are > > willing to have their technical people spend the time to discuss this > > with you personally, but that's why I'm putting this effort in to try > > to understand your side of this. Believe me, I have lots of stuff to > > do, and I'm not getting paid for this part at all, so it's just me and > > you and I'm asking you to try to explain to me why keys are "bad". > > Again, if it's just that you just plain don't like them, then that's > > completely fine, I would just like to know. > > > > Brian > > > > > > > > On Thu, 1 Mar 2018 22:04:06 +0000, Seymour J Metz <[email protected]> > wrote: > > > > > 1. The people who object to keys do so because of the associated risk. > > > > > >2. 'You can't over simplify the issue and decide categorically that > > >all > > vendors > > > that want to "protect" their software are bad. ' implies that > > somebody has made > > > such a claim; that's the straw dummy in question. > > > > > > 3. The collateral damage is the inability to use the software that > > > they > > are paying for > > > and the outage to everything dependent on that software. > > > > > > 4. The issue is not the licensing terms; the issue is what happens > > > to a > > customer who > > > has paid the fee. > > > > > > 5. No, our difference is that I believe that the customer has no > > obligation to play > > > Russian Roulette. > > > > > > 6. The issue isn't the rules, it's the danger inherent in the > > enforcement method. > > > > > >" If you can do it without losing your temper or being condescending" > > > > > >PKB. Don't misrepresent my position if you want me to be polite. > > > > > >"or if you want to be sarcastic " > > > > > >PKB. If you don't want sarcastic responses, then don't make sarcastic > > posts. > > > > > >"and/or virulent " > > > > > >There's nothing wrong with refusing to buy a product that doesn't > > >suit my > > needs. You get to set whatever rules you want for the use of your > > software, provided that you disclose them up front, but you don't get > > to tell the customer what metrics to use in evaluating his requirements. > > > > > >"because I still really do want to try to understand your points." > > > > > >Then pay attention when I write that keys impose a risk on the > > >customer, > > and that the customer gets to decide how significant that risk is. Are > > you willing to put an indemnification clause in your contracts? > > > > > > > > >-- > > >Shmuel (Seymour J.) Metz > > >https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7E > > >smetz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KMMj > > >oSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjcwY3 > > >ccs7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e= > > > > > >________________________________________ > > >From: IBM Mainframe Discussion List <[email protected]> on > > >behalf > > of Brian Westerman <[email protected]> > > >Sent: Wednesday, February 28, 2018 1:51 AM > > >To: [email protected] > > >Subject: Re: Product license key program > > > > > >You lost me Shmuel, > > > > > >I don't think I misrepresented the people who object to keys, at > > >least > > not on purpose. I don't understand the straw dummy reference and I > > honestly don't understand the objection to a vendor using keys for > > their product(s). > > > > > >What collateral damage is cause by a vendor's use of keys in their > > software? The keys are there to "lock" the software to the system it > > was licensed for. If the software is moved, or used in other creative > > means without permission from the vendor (who we must remember, owns > > the software), then it (theoretically) won't work on that "other" > > platform. I guess I'm missing the damage part of that. Do you mean > > disaster recovery keys? I think every vendor has that covered by now, > > but maybe they don't, and again, it's their software, if they don't > > want to allow that use, and they let you know up front, then whats the > damage? > > > > > >There are many parts (I guess types of keys makes more sense) of > > >vendors > > keys that I don't agree with, and I don't personally think that > > software in and of itself should cost more for one processor than > > another, regardless of processor size, but that's just my personal > > feeling. If a vendor wishes to price their software that way, then it's > completely their decision. > > > > > >Possibly our difference of opinion is because I see the vendor's > > >product > > as belonging to the vendor, not unlike my "locking your car or house" > > analogy. It's not like the vendor is locking other software, just > > their own. At least I hope so. If the vendor wants to lock their > > software so that it isn't "misused", (and specifying what "misused" > > means is 100% the software vendor's decision). Then, as they "own" > > the software, it's up to them to say what those rules are. They need > > to be up front on the rules, even if they are unreasonable rules, > > otherwise the contract for the software would be invalid anyway under > > the "meeting of the minds" concept of contract law. > > > > > >If a site "purchased" the software instead of licensed (or rented) > > >it, > > then I believe you are 100% correct that the software vendor loses the > > right to lock it up. I don't think many vendors sell their software > > that way though, it would not be cost effective for either party. > > > > > >So, I really do want you to educate me on this. If you can do it > > >without > > losing your temper or being condescending, then I would like to do it > > here, publicly, so that others can understand as well. > > > > > >On the other hand, if you can't discuss it calmly, or if you want to > > >be > > sarcastic and/or virulent about it, then feel free to send me the > > discussion points offline, because I still really do want to try to > > understand your points. > > > > > >Sincerely, > > > > > >Brian > > > > > > > > > > > > > > >On Tue, 27 Feb 2018 21:44:45 +0000, Seymour J Metz <[email protected]> > > wrote: > > > > > >>You can, and did, misrepresent the position of those who object to > > license keys. The issue isn't protecting the software; the issue is > > the means used to do so and the collateral damage from those means. > > >> > > >>If you have someone willing to steal your product, then he will also > > >>be > > willing to patch it to bypass the license check? Illegal, sure, and I > > hope that you nail anybody who does so, but still inevitable. > > >> > > >>As for support of stolen copies, that's a separate issue from > > >>preventing > > the product from running. Use of keys et al in the support process > > doesn't have the same potential for collateral damage. > > >> > > >>Microsoft? They have a vested interest in lying about their reasons; > > they want to force bundling, and have been very successful at it. > > >> > > >>Of course, after inventing straw dummies and openly being facetious > > >>you > > ar likely to get sarcastic replies; if you didn't want sarcasm then > > you should have used honest and polite argument. > > >> > > >>-- > > >>Shmuel (Seymour J.) Metz > > >>https://urldefense.proofpoint.com/v2/url?u=http-3A__mason.gmu.edu_-7 > > >>Esmetz3&d=DwIBaQ&c=huW-Z3760n7oNORvLCN2eJBo4X7nIGCr9Ffht-z0f4k&r=1KM > > >>MjoSvFEwY7ZoooplFIrKcOeeTJVI4X6Bc3o6vdK4&m=1l6hpNNXgTiCCpbDJWg8VLAjc > > >>wY3ccs7JKJn3oF8I2A&s=Ap59KzoG5pNDC3N598NDZ-cKLXf4Aac-cJgMJiZzTDk&e= > > >> > > >>________________________________________ > > >>From: IBM Mainframe Discussion List <[email protected]> on > > behalf of Brian Westerman <[email protected]> > > >>Sent: Monday, February 26, 2018 9:27 PM > > >>To: [email protected] > > >>Subject: Re: Product license key program > > >> > > >>If someone violates a copyright, there are legal and I think > > >>criminal > > penalties. But I doubt the FBI will get involved if you decided not > > to pay CA for using Panvalet. > > >> > > >>You can't over simplify the issue and decide categorically that all > > vendors that want to "protect" their software are bad. Just like > > people, there are indeed some bad vendors, whether or not they have > > product "protection" doesn't enter into the equation. > > >> > > >>How would a vendor even know that someone didn't take a "personal" > > >>copy > > of their unprotected code from site A to site B? Does that happen, it > > sure does. > > >> > > >>Microsoft did a study several years back on how much time they spent > > fixing problems and helping people who had pirated copies of their > > code, and it was something on the order of 38%. That didn't mean that > > 38% of the people running Windows were running pirated copies, just > > that during their study, 38% of the people who called gave pirated copy > codes. > > >> > > >>They were losing more money on the support of the code for the > > >>pirated > > versions than was deemed "acceptable". The same problem can (and > > likely > > is) true for other vendors. Several of our Syzygy products come with > > parts that are not protected by keys or code. We frequently get calls > > from people who are not out customers to fix (usually the same problem > > over and over again) problems with the unprotected code who are not > > very happy when we inform them that we can't offer them support for > > the code without them being an actual client, but that doesn't stop them > from trying. > > >> > > >>We had a person, just a few months ago, (who is a member of this > > >>list > > and knows who I am talking about), who called with a "problem" for our > > SyzInfo program (it's a small program we send to sites to display > > their site information, CPU, LPAR, SYSPLEX, MEMORY info, etc., a lot > > of interesting information) because they just got a z13 and our code > > supposedly didn't support it yet. It worked, but didn't give > > "completely valid" results. We actually added support for the box > > over 18 months before it came out, so we were fairly perplexed. When > > asked for his site-ID, he gave it, (it turned out to be one from his > > old site) and we emailed him the new code for his whole product matrix > > (4 complete products and support modules). Then we received a call > > from him to tell us that the new products would "no longer" operate on > > his CPU. When we asked for the CPU type and serial, he gave us his > > old serial from the old shop, so the client support people re-verified > > and sent out a new copy even though there was no real changes made. > > He told us that it still didn't work so we asked him to execute > > SyzInfo and send a screen print of the results. Instead of the screen > > print, he "supposedly" cut/pasted the results which showed that the > > product thought exactly what was running was what we shipped. He > > escalated the problem (which sent it to me), to be resolved, and I > > asked him to re-execute SyzInfo for the screen print and got the same > cut/paste thing, but it was different from the original one he sent the day > before. > > The new one had several of the values transposed and the CPU was now a > > EC12 not a z13 as he had originally reported having the problem with > > in the first place. I called him and got one of his co-workers who > > told me that they were not running our code, and he had no idea what I > > was talking about. It turned out that they were running a z13 and > > never had a EC12 (they upgraded from a z10 recently). I explained > > what had just happened and was told that he would talk to his boss and > > that they would handle the "problem". > > >> > > >>We never heard back from the person or that site again, but they > > >>still > > participate on this site. When I contacted their old site to ask if > > things were okay, I was told that they were going great and they had > > no problems whatsoever, but that the person I was asking about no > > longer worked there and had not for well over 2 years. > > >> > > >>Now, I realize that it's just one occurrence of a bad person, which > > >>does > > not make every one bad, but in our case, we expended probably 30 > > man-hours of time on a problem that didn't even exist. How many of > > those could a small company, or even a large one absorb? > > >> > > >>I would like to say this is a one-time occurrence, but I can't. > > >>Similar > > events happen several times a year, but normally it doesn't get to me > > to fix because they discover much sooner that something was amiss. > > >> > > >>Our products have built-in protection, actually they all have 3 > > >>separate > > protection mechanisms. We offer free trials that can go up to several > > months when necessary, and every product has a built-in allowance of > > extra time after the expiration date and we warn well in advance of > > the time left. Some of the products even tell you every time they > > execute how many days are left, which of course can be turned off > > (except for the last 30 days). > > >> > > >>Most vendors don't have a way to enforce voluntary compliance, but I > > believe that the vast majority of them have some sort of protection > > built into their products. And while most people believe that IBM > > does not keep track of product use, they would be wrong. Is it > > possible to get around the protections? You bet. We believe here, > > and I'm sure that most other vendors also believe, that he vast > > majority if not all of our clients are extremely trustworthy, and > > likewise we hope they think we are trustworthy as well. > > >> > > >>Wasn't it Ronald Reagan who said, "trust, but verify". :) Who > > >>would I > > be to argue with the great communicator? I worked for him for 6 > > years, he was no dummy. > > >> > > >>So, I also agree that this shouldn't be another long drawn out fight > > over "to key or not to key", and I also realize that there are some > > sites who might not run our products because they are protected. I > > don't think it's too many because we have over 700 clients. > > >> > > >>I realize this is going to sound facetious, but when I first read > > >>some > > of the rants from people complaining about how they are not trusted I > > can't help but wonder if they lock their homes and cars. Do they put > > the WPA2 passwords on their routers? Do they have a pin on their > > phone? And if so, is it just that they believe that everyone should > > trust them, but they need not trust everyone else? > > >> > > >>I don't expect any non sarcastic responses to this, and I probably > > wouldn't read them anyway, (yes I will, but I probably won't admit > > it), but sometimes I wonder about how people can divide their lives up > > so simply and exactly that everyone else who doesn't do something > > "their way" is "wrong". Is that a sure sign that I'm getting old that > > I have a hard time understanding why there seems to be no such thing > > as grey any more. If you're not 100% "good" then you're "bad", or > > more likely, if you're not 100% "like me" then you're "bad". > > >> > > >>What happened to diversity? And why get so virulent about it? > > >> > > >>Hopefully this won't start a full rant from anyone, but I'm sure it > > will, especially from the guy who I told you about above. > > >> > > >>Brian > > >> > > >>-------------------------------------------------------------------- > > >>-- For IBM-MAIN subscribe / signoff / archive access instructions, > > >>send email to [email protected] with the message: INFO > > >>IBM-MAIN > > >> > > >>-------------------------------------------------------------------- > > >>-- For IBM-MAIN subscribe / signoff / archive access instructions, > > >>send email to [email protected] with the message: INFO > > >>IBM-MAIN > > > > > >--------------------------------------------------------------------- > > >- For IBM-MAIN subscribe / signoff / archive access instructions, > > >send email to [email protected] with the message: INFO > > >IBM-MAIN > > > > > >--------------------------------------------------------------------- > > >- For IBM-MAIN subscribe / signoff / archive access instructions, > > >send email to [email protected] with the message: INFO > > >IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, send > > email to [email protected] with the message: INFO IBM-MAIN > > > > > > -- > Wayne V. Bickerdike > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > This e-mail transmission may contain information that is proprietary, > privileged and/or confidential and is intended exclusively for the > person(s) to whom it is addressed. Any use, copying, retention or > disclosure by any person other than the intended recipient or the intended > recipient's designees is strictly prohibited. If you are not the intended > recipient or their designee, please notify the sender immediately by return > e-mail and delete all copies. OppenheimerFunds may, at its sole discretion, > monitor, review, retain and/or disclose the content of all email > communications. > > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > -- Wayne V. Bickerdike ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
