| Author |
Message
|
| mq_abcd |
 Posted: Fri Jan 07, 2005 9:07 am Post subject: Analysing FDC |
 |
|
Acolyte
Joined: 13 Jun 2004
Posts: 69
|
Hi guys,
this is the FDC file generated on my box
Is this file has any kind of info
Can we analyse this info??
Can anyone tell why these files are created though my queue manager has not faced any issues.
Thanks
+-----------------------------------------------------------------------------+
| |
| WebSphere MQ First Failure Symptom Report |
| ========================================= |
| |
| Date/Time :- Friday January 07 11:22:59 EST 2005 |
| Host Name :- mwmqm02 (SunOS 5. |
| PIDS :- 5724B4103 |
| LVLS :- 530.5 CSD05 |
| Product Long Name :- WebSphere MQ for Sun Solaris |
| Vendor :- IBM |
| Probe Id :- XC338001 |
| Application Name :- MQM |
| Component :- xehAsySignalHandler |
| Build Date :- Sep 27 2003 |
| CMVC level :- p530-05-L030926 |
| Build Type :- IKAP - (Production) |
| UserID :- 00008000 (mqm) |
| Program Name :- runmqsc |
| Process :- 00002697 |
| Thread :- 00000002 |
| Major Errorcode :- xecE_W_UNEXPECTED_ASYNC_SIGNAL |
| Minor Errorcode :- OK |
| Probe Type :- MSGAMQ6209 |
| Probe Severity :- 3 |
| Probe Description :- AMQ6109: An internal WebSphere MQ error has occurred. |
| FDCSequenceNumber :- 0 |
| Arith1 :- 2 2 |
| Arith2 :- 2697 a89 |
| Comment1 :- SIGINT |
| |
| |
+-----------------------------------------------------------------------------+
MQM Function Stack
xehAsySignalMonitor
xehHandleAsySignal
xcsFFST
MQM Trace History
{ xppInitialiseDestructorRegistrations
} xppInitialiseDestructorRegistrations rc=OK
{ xcsFreeMem
} xcsFreeMem rc=OK
{ xehAsySignalMonitor
-{ xppPostAsySigMonThread
-} xppPostAsySigMonThread rc=OK
-{ xehHandleAsySignal
--{ xcsRequestThreadMutexSem
--} xcsRequestThreadMutexSem rc=OK
--{ xcsFFST
Component Dumps (Thread 00000002)
------------------------------------- |
|
| Back to top |
|
 |
| Anirud |
| Posted: Fri Jan 07, 2005 10:13 am Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
Have you recently upgraded from WMQ 5.2 to 5.3?
The program responsible is runmqsc
You will need to set environment variable EXTSHM=ON in the .profile of the accounts which use runmqsc. |
|
| Back to top |
|
|
| clindsey |
| Posted: Fri Jan 07, 2005 10:57 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
You do not need to set EXTSHM for this problem.
The async signal that was caught was signal 2 (SIGINT).
Someone started runmqsc and then exited with control-c rather that 'end'.
Charlie |
|
| Back to top |
|
|
| Anirud |
| Posted: Fri Jan 07, 2005 11:42 am Post subject: |
|
|
Master
Joined: 12 Feb 2004
Posts: 285
Location: Vermont
|
My Bad. I overlooked the probeID.
Recently, we moved a queue manager from one box to another and it was generating FDC's with program name Runmqsc. I worked on that this morning and thought this was the same case.
Sorry for the misleading info.
Regards.
Anirud. |
|
| Back to top |
|
|
| mq_abcd |
| Posted: Mon Jan 10, 2005 8:42 am Post subject: |
|
|
Acolyte
Joined: 13 Jun 2004
Posts: 69
|
Thanks guys,
Can anyone refer me to some documentation
which could help me analyse these files myself.
Thanks again. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Jan 10, 2005 9:11 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There isn't documentation, per se, that I know of.
What we usually do is look at the headers, particularly the probe ID, major error code, minor error code, program name, and description.
If the major and minor error codes don't make sense, we'll use the probeID as a search value at IBM.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| bbburson |
| Posted: Mon Jan 10, 2005 9:17 am Post subject: |
|
|
Partisan
Joined: 06 Jan 2004
Posts: 378
Location: Nowhere near a queue manager
|
| jefflowrey wrote: |
| If the major and minor error codes don't make sense, we'll use the probeID as a search value at IBM. |
...or at mqseries.net.  |
|
| Back to top |
|
|
|
|
