Sounds almost like we work for the same company. It is all about cost, nothing about quality. This is why Wintel is "the best thing in the market". On Jul 28, 2013 9:07 AM, "Bernd Oppolzer" <bernd.oppol...@t-online.de> wrote:
> I understand Charles' attitude fully and respect it; > it's driven by the experiences he made in the past. > I for myself have made other experiences, and so > for the moment I (still) act differently, but that is subject > to change in the future, too. > > I would like to tell you about a talk I had with the guy who > is responsible for the compiler at our site; I met him by > accident on a bike tour some hours ago. It's weekend, > after all. > > As I predicted, he is not willing to act on this problem, > because we do not have this option HGPR active, and so we > don't have a problem with this. At our site, we also have > a strong cost/benefit thinking - in fact, it's worse: the managers > only look at the cost and don't even see that for different cost > you may get different benefit. They always choose the solution > with minimal cost - and ignore the possible benefit. (Often you > cannot tell the benefit beforehand, but most of the time you know > the cost). So the quality of service is going down from day to day ... > which leads to higher cost in the end ... but they don't see that. > > I believe this kind of problem is not limited to IT; you see it > everywhere in the industry. > > Kind regards > > Bernd > > > > Am 28.07.2013 15:37, schrieb Charles Mills: > >> Okay, everyone is beating me up for not reporting this problem. Let me >> tell you the story that put me off to PMRs. >> >> In January of 2012 or so I sent a note to IBMMAIN saying that that >> CEE3DMP was printing garbage and then S0C4ing. You can probably find my >> post if you search. At the urging of this group I opened a PMR on February >> 3. >> >> Here was the first battle I had to fight. The program in question is a >> STC that installs exits and so I implemented Signal handling so that in the >> event of a problem it could shut down gracefully. To test that code I added >> an undocumented MODIFY command to force a S0C4. I encountered the problem >> while testing that intentional S0C4/signal handling code. That was how I >> could reproduce the problem. I went around and around with the level 1 >> folks saying "we found your problem -- you are trying to store into low >> core" and me saying "I am doing that on purpose to force this problem. Look >> at the PMR description. I know what causes the original S0C4 -- it's the >> garbage and the S0C4 in CEE3DMP that I am PMRing" and they would come back >> and say "your problem is you are trying to store into low core." >> >> After I got past that IBM wanted dump after dump after dump from me. They >> did not reproduce the problem -- it was all "change this option, try it >> again, and send us the dump." I sent them a total of nine different tersed >> dumps and similar files over the course of three months. Not a trivial >> thing with an STC that is intertwined with the z/OS kernel. Finally they >> said "okay, we have this figured out, we're going to work on it" and then >> in OCTOBER they sent me a local fix to test. I tested it and confirmed that >> they had fixed it. >> >> Then IBM came back to me and said "do you really, really, REALLY need >> this fixed?" and I said "no, of course not, I've been living for eight >> months with it not fixed." They said "good, because if we really issue a >> PTF for this, we need to do regression testing and everything which is a >> lot of work. How about if we just roll the fix into the next release of LE >> (z/OS 2.0!)." At that point I said "sure, whatever." Whereupon IBM said "by >> the way, there's no guarantee your local fix won't go away if we happen to >> issue some other PTF that impacts it." >> >> Needless to say I am not very encouraged to open PMRs based on that >> experience. >> >> I think those of you who say "don't you care about the customers?" have >> it totally backwards. Of course I care about the customers. If someone >> posted here "that CorreLog SIEM agent is okay but it seems to S0C4 from >> time to time" I would be all over it. I would track the OP down, find out >> what he was doing, duplicate the problem, and fix it. I would not wait >> until the customer jumped through some particular process hoop before I >> acknowledged the problem, or prove how much the S0C4 was hurting their >> production. I care about MY customers, and I care about IBM's customers, >> but you can't push a piece of string: I can't care about IBM's customers >> more than IBM does. >> >> What IBM SHOULD be doing IMHO -- and I was shocked that for the first >> time in my experience they did it in the case of the error of this thread >> -- is have someone, an ombudsman, monitoring this list and with authority >> to open problems and get them fixed. I am very, very pleased to see that >> that is what is happening in this one particular case. >> >> Note that I was very forthcoming with information here even after my >> particular problem went away. I am not selfish. I posted the listings that >> enabled some very clever people to find the problem for IBM. I am very >> willing to contribute effort to solving problems on behalf of the >> community. I have just come to the conclusion that the PMR process is >> simply not sufficiently cost/benefit effective to work for me. >> >> Thanks for listening. >> >> Charles >> > > ------------------------------**------------------------------**---------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
