No, no, no offense taken at all. I am harder to offend than that! Was using "beat up" in jest. Longer reply to follow.
Charles Composed on a mobile: please excuse my brevity Lizette Koehler <stars...@mindspring.com> wrote: >Charles, > >First let me apologize if it seemed I was beating you up. That was not my >intent. Unfortunately in email the reader cannot always determine how the >words are being said. It was more of a help a vendor out type commentary. >Not do it or else type commentary. But if I did offend - I am sorry. > >I am also sorry you have had some issues in the past. I think most on this >list can quote similar events. Not with just IBM but other vendors as well. >And as for IBM, they have to recreate the problem in a vanilla IBM only >software. They do not always have OEM software in their testing environment. >Therefore, they rely on the reporter to help with the diagnosis sometimes. >And I guess the bottom line is - sometimes software will work and sometimes it >has problems. > >When it doesn’t work then it becomes - how important is it to get it fixed and >how repeatable the failure. > >FIN (Fixed in next) is sometimes acceptable. Fix it now is sometimes >acceptable in others. You have to decide which is more important at the time. > >I usually will continue with the vendor until the resolution is found; I then >determine which way I go. > > >I believe that all Vendor Support groups want to fix issues as quickly as they >can. Based on priority, willingness of the customer to work with them, and the >complexity of the code that needs to be validated and/or corrected; it can be >an extraordinary effort. Then they have to balance that with how many >customers are reporting it, is it isolated or more common. A lot of factors >go into working on reported issues. Having worked both sides - IBM level 2 >support and customer, I can understand some of the constraints IBM has with >correcting problems. Some are really easy to identify and fix. Others are >head scratchers. And if there are OEM products involved, they have to get >documentation from the customer and have the customer validate through parm >changes or other data collection. > >I just finished working on a problem with EMC on their storage array. It took >a couple of months and it turned out this particular issue when back a couple >of code levels for them. But they were not aware of it until I had my issue. >I spent time sending in a lot of RMF and LOGREC data on my issue, but they >found it and eventually fixed it. They have also retrofitted it to the older >release. But it was an effort on both of our parts to resolve this. > >One more story. I was support our DR testing when Top Secret would not come >up at IPL time. Took an S0C4-04. This is around 5pm. I looked at the >summary dump and called in a Sev1 to CA. They were able to quickly identify >the issue and provide a work around (there was a ptf but we could not apply it >at DR). So the secondary workaround - disable PDS Member Security. It turned >out that 9 months before another shop running ACF2 had the same issue. They >ran the problem with CA for several months (I think about 4) before CA was >able to determine that a new instruction was used that only ran on z9 and >above. We were running on a z890 at DR but a z9 in our home. If that other >shop had not pursued and fixed, our DR test would have failed. So I am very >grateful they did what they had to do to get it fixed. > >I understand that some shops do not have the time to pursue issues with >vendors. I always hope they have the foresight to open the case, collect some >doc, and then if needed, defer to pursue. Then there is a record in the >vendor's shop and if more show up, they are likely to pursue more quickly. Or >if the support team is bored, they have something to work on that might be >interesting. > >I hope your future interactions are better. > > >Lizette > >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Charles Mills >Sent: Sunday, July 28, 2013 6:38 AM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Looking for help with an obscure C integer problem > >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 >-----Original Message----- >From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On >Behalf Of Paul Gilmartin >Sent: Saturday, July 27, 2013 10:06 PM >To: IBM-MAIN@LISTSERV.UA.EDU >Subject: Re: Looking for help with an obscure C integer problem > >On Sat, 27 Jul 2013 14:59:15 -0500, Ed Gould wrote: >> >>This is in my opinion a fuzzy error. Where the C issue is a classic >>bug(probably) your SR Policy is a gray area and it is harder to define >>a right/wrong answer (although probably you are right). >>Spelling & such is a issue but not a real bug. It is a soft issue, in >>my opinion and a lot harder to get IBM interested. >> >I certainly did not say that my "SR Policy" thread was motivated by the >response to a report of a spelling error. >In fact, it was a report of the misbehavior I discussed in the >"Buffering: stdout ..." thread. I suppose you're free to deem it cosmetic or >not as you choose. > >The good news is that IBM has reproduced the problem, even while prodding me >for a statement of business impact (which I supplied, acknowledging that I was >working on a PoC). > >---------------------------------------------------------------------- >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
