| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQ Error Analysis |
« View previous topic :: View next topic » |
| Author |
Message
|
| skytorch |
 Posted: Thu Jun 27, 2002 5:53 am Post subject: MQ Error Analysis |
 |
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
Hi,
I've MQ application running on Tru64 Unix. The app is simply sending and receiving messages from several app queues.
Although from application level it seems working fine (return code is ok, messages are flowing properly), I can see some AMQ6125, AMQ6183 (MQ internal error) messages logged into <mq>/errors dir. In the FFST report files, I don't get enough info to find out why.
What could the reasons and what may be the actions to analyze this ?
Did anyone encouter and resolve this before ?
Thanks in advance.
Sky |
|
| Back to top |
|
 |
| mrlinux |
| Posted: Thu Jun 27, 2002 6:27 am Post subject: |
|
|
Grand Master
Joined: 14 Feb 2002
Posts: 1261
Location: Detroit,MI USA
|
Can you post the one of the headers from the FDC files ????
_________________
Jeff
IBM Certified Developer MQSeries
IBM Certified Specialist MQSeries
IBM Certified Solutions Expert MQSeries |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Jun 27, 2002 6:40 am Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
These are usually pretty meaningless, but some clues can be gleaned from FDC files. There are really intended for IBM use.
You need to post at least the top part (in a box) of the FFST text. The function stack trace is usually not so useful.
Useful things to look for :
Program name and User ID. Time and Date - see if there is a pattern. The FDC file name in Unix matches the process ID that wrote the FDC file. If the process did not exit then it will continue to append to the FDC file, so it can get pretty big.
The "Probe ID" is the internal error code thingie. There is a XC130000 error (something like that) which is actually an application program error that MQ traps, as it needs to clean up.
There is usually some error message text that can shed some light.
Reading tealeaves can often give you more information  |
|
| Back to top |
|
|
| skytorch |
| Posted: Thu Jun 27, 2002 7:35 am Post subject: |
|
|
Apprentice
Joined: 10 Jun 2002
Posts: 47
Location: New York City
|
Thanks for the replies. The following is first part of one of FDC files under <mq>/errors dir. The error is consistent whenever my app started.
When I created queues, channels, I tried to take default settings. And the application is simply putting and retrieving messages.
Thanks.
Sky
+-----------------------------------------------------------------------------+
| |
| MQSeries First Failure Symptom Report |
| ===================================== |
| |
| Date/Time :- Thursday June 27 08:52:13 EDT 2002 |
| Host Name :- sulu |
| PIDS :- 5765-E38 |
| LVLS :- 510 |
| Product Long Name :- MQSeries for Compaq Tru64 |
| Vendor :- IBM |
| Probe Id :- XC268010 |
| Application Name :- MQM |
| Component :- xehAsySignalMonitor |
| Build Date :- Mar 15 2000 |
| UserID :- 00000023 (admin) |
| Program Name :- lwriter |
| Process :- 00172340 |
| Thread :- 00000002 |
| Major Errorcode :- xecF_E_INVALID_PARAMETER |
| Minor Errorcode :- OK |
| Probe Type :- INCORROUT |
| Probe Severity :- 2 |
| Probe Description :- AMQ6125: An internal MQSeries error has occurred. |
| |
+-----------------------------------------------------------------------------+
MQM Function Stack
xcsFFST |
|
| Back to top |
|
|
| dgolding |
| Posted: Thu Jun 27, 2002 9:50 pm Post subject: |
|
|
Yatiri
Joined: 16 May 2001
Posts: 668
Location: Switzerland
|
...here's a tip, if the first function called in the trace is xcsFFST, then it is a fair bet that it is a program error that MQ is trapping, like segment violation.
Here's a snippet I found from the Vienna list server:
< begin snippet>
In order to solve these problems, I suggest exporting
AMQ_ABORT_ON_EXCEPTION=TRUE. If this variable is set in the environment in
which the application is running, the MQSeries exception handler will abort
the process after cutting the FDC. This will produce a core file which we
can investigate to determine conclusively who is at fault and what needs to
be done to solve the problem. If the failing program is an MQSeries
program we can examine the core file, but if it is a customer program they
will need to use dbx, gdb, or their favourite debugger to dump the stacks
for each thread in the process. We can examine cores from customer
applications only when we have their compiled application as well as all
libraries on which it depends. If their application is linked with
MQSeries, Tuxedo, Oracle, CORBA, and half a dozen other things, forget it.
If it's a straight MQSeries application we may be able to work on it
provided that we have the binary program, the core file, and a system at
the same OS and maintenance level. If not, things get very tricky very
quickly.
<end of snippet>
Give this a try, and poke the core file about with your favourite debugger, to try and find what's happening...
HTH
Don |
|
| Back to top |
|
|
| bower5932 |
| Posted: Fri Jun 28, 2002 8:45 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I checked out your probeid on an internal database, and it looks like this is a defect that is supposed to be fixed. I tried looking at the readme for the CSD, and I couldn't find the number that I was looking for. If you haven't installed the latest CSD, I'd suggest giving it a try. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
