I think there are cases where the product doesn't have a good error message to generate and defaults to an FDC file. I have had a couple instances (one I believe was when I was using incorrect SSL settings and connecting as a client) where the qmgr threw FDCs which were a result of errors in my application. That' why I sometimes ignore FDCs. I could go to IBM support for each of these, but many times they correlate to some error or problem that is obvious. Ideally mq would generate a more friendly error, but this may not always be possible.
Nick -----Original Message----- From: MQSeries List [mailto:[EMAIL PROTECTED] On Behalf Of Potkay, Peter M (PLC, IT) Sent: Thursday, January 08, 2004 11:55 AM To: [EMAIL PROTECTED] Subject: Re: Do go looking for FDCs when "nothing" is wrong? You know, I was thinking to myself looking at these FDCs "Holy cr*p, this whole place is about to fall apart right before my eyes!!!". But I went and actually looked at all my prod QMs. About 40% have no FDCs. The other 40% have some, but only at the rate of maybe 1 or 2 every 3 months. A couple here and there were weird (like 30 FDCs in a minute a year ago and nothing since). The queue managers that are running on Windows 2000 machines under control of MSCS are loaded with FDCs. Like 10 or 20 a month. I am going to focus on those, even though "nothing" is wrong. Maybe IBM will be able to help me flip a switch somewhere which would cause 90% of those to go away. I just hesitate to do it because nothing seems wrong, and this could turn into a full time job. Oh well, look out bullet, cuz I'm about to bite ya! If I can get it to the point where we only see 1 or 2 FDCs a month, I think an email with the servername in question when an FDC is thrown is a good idea. A great idea would be the ability to actually understand FDCs. A new manual perhaps? Please? :) -----Original Message----- From: Robert Broderick [mailto:[EMAIL PROTECTED] Sent: Thursday, January 08, 2004 2:03 PM To: [EMAIL PROTECTED] Subject: Re: Do go looking for FDCs when "nothing" is wrong? I don't know. I have had sites where I showed up the first day and the file systems were pretty full because of the FDC issues. But as things got under control and the environment stabilized the issue of FDC's showing up became became lees of an issue if non-existent. I don't recall being iat a site where the FDC continued to run "out of hand" after making the environment "well". bobbee >From: Bill Anderson <[EMAIL PROTECTED]> >Reply-To: MQSeries List <[EMAIL PROTECTED]> >To: [EMAIL PROTECTED] >Subject: Do go looking for FDCs when "nothing" is wrong? >Date: Thu, 8 Jan 2004 13:20:17 -0500 > >I just had to ring in on this one. The thing is, the queue manager seems to >have sort of a "hair trigger" in regard to what sort of problems cause it >to write an FDC file. I find them often, and have no way of quickly >determining why it (more commonly they) are there. If I got serious about >hunting them down every time, I could make a career out of It. It doesn't >help any that little or no documentation exists on how to effectively >troubleshoot using one. On more than one occasion I have opened a ticket >with IBM to help me solve a problem where FDC files were produced, and had >a 2nd level support person tell me to send them, but they don't often >contain much useful data. > >I do think it is wise to automate handling them. I need to find the time to >write a script that not only finds them but potentially parses them and >write things like the date / time stamp, program name, and probe >description (just to name a few) to a log file that could be imported into >a spread sheet. Then you could look for trends. If something specific >continues to occur over and over, that would be justification to launch a >science project to determine why, and fix it. > >I would love to know enough about FDC files to write a program, or Perl >script that could parse hundreds of them and write a report based on some >key data. But that's not likely to wind up on my project plan list any time >soon! > > >Cheers > >Bill Anderson >Senior Systems Analyst >SITA Atlanta, GA >770-303-3503 (office) >404-915-3190 (cell) >[EMAIL PROTECTED] >http://www.mconnect.aero/ > >Instructions for managing your mailing list subscription are provided in >the Listserv General Users Guide available at http://www.lsoft.com >Archive: http://vm.akh-wien.ac.at/MQSeries.archive _________________________________________________________________ Tired of slow downloads? Compare online deals from your local high-speed providers now. https://broadband.msn.com Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive This communication, including attachments, is for the exclusive use of addressee and may contain proprietary, confidential or privileged information. If you are not the intended recipient, any use, copying, disclosure, dissemination or distribution is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return email and delete this communication and destroy all copies. Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive Instructions for managing your mailing list subscription are provided in the Listserv General Users Guide available at http://www.lsoft.com Archive: http://vm.akh-wien.ac.at/MQSeries.archive
