"Bob Halpern" <[EMAIL PROTECTED]> wrote in message news:<[EMAIL PROTECTED]>... > As a member of the Candle Omegamon CICS team, I visited IBM Hursley involved > with CICS 3.0/3.1 interfaces. It took us hours to gat across the concept > that a monitoring product has to show what is happening behind the API > interfaces. We finally did, and 3.1 came out with more exits. > > > > The problem is that the developers do not see the user side of the issues, > and it the user's responsibility to explain, not IBM's to perceive. > > > >
Well, during the discussion this week, an old example kept on playing through my head and as Bob mentions his example, I will add mine too. Not to get it active again, but merely to show how we sometime experience IBM's support, although I must say this is not regular practice. When I started playing with SDSF Operlog, I was very excited about the new functionality it brought, especially the filters. However after some time I noticed that the MSGID filter did not capture all occurances of a msgid. It appeared that it did not trap msgid's that were WTOR's. Apparently, the position of the msgid was strictly defined at the beginning of the syslog messageline, which of course is not true for WTOR's, where it at position 3, e.g.: 69 IEF235D jobname stepname WAITING FOR VOLUMES. TO CANCEL WAIT REPLY 'NO' I reported it as a problem in Operlog, but much to my surprise, the answer came that the design was as I had noticed: the msgid is at position 1-8 of the syslog line. I still replied, that this of course was something that was overlooked and that IEF235D was really defined as a msgid in the messagemanual, so there was no doubt about what the messageid of the message was and asked again to change the filter. Again came the reply that this was the design of the msgid filter and the design was not going to be changed, period. Fully baffled by this view on the problem, I dropped the issue, but kept un uneasy feeling about this, compared to the good level of IBM support I had experienced before. Development's world can be quite different from the real / users world, my colleague responsible for System Automation regularly has this kind of clashes. Kees. ********************************************************************** For information, services and offers, please visit our web site: http://www.klm.com. This e-mail and any attachment may contain confidential and privileged material intended for the addressee only. If you are not the addressee, you are notified that no part of the e-mail or any attachment may be disclosed, copied or distributed, and that any other action related to this e-mail or attachment is strictly prohibited, and may be unlawful. If you have received this e-mail by error, please notify the sender immediately by return e-mail, and delete this message. Koninklijke Luchtvaart Maatschappij NV (KLM), its subsidiaries and/or its employees shall not be liable for the incorrect or incomplete transmission of this e-mail or any attachments, nor responsible for any delay in receipt. Koninklijke Luchtvaart Maatschappij N.V. (also known as KLM Royal Dutch Airlines) is registered in Amstelveen, The Netherlands, with registered number 33014286 ********************************************************************** ---------------------------------------------------------------------- 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
