|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
MQ Message Structure & Tivoli Alert |
« View previous topic :: View next topic » |
Author |
Message
|
PhiliB |
Posted: Mon Nov 20, 2006 6:30 am Post subject: MQ Message Structure & Tivoli Alert |
|
|
Novice
Joined: 16 Sep 2004 Posts: 21 Location: Portsmouth
|
A good day to you all
I have an issue with the creation of a Triggered message and the alert that it is designed to generate. What happens is we have a queue that we wish to alert to when a single message arrives, I have setup triggering to call a c program which itself creates a MQEVENT message (2224) MQ_Q_DEPTH_HIGH, it then forwards this to the Tivoli monitored eventq.
This all works fine however the Tivoli Enterprise console receives the alert but the Queue Manager & Queue fields remain blank. The alert comes through as Q & QMGR 'unspecified'.
I will paste 2 messages below, the first is a genuine HIGH alert and the second is triggered message. The mesages are virtually identical.
I can paste the section of the triggered C program if that would be helpful, please let me know.
So .. could anyone advise why one the first MQ message below provides the detail about the baseqname but the second doesnt.
Many thanks as ever
REAL
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQEVENT '
Priority : 0 Persistence : 0
MsgId : X'414D5120434C535052442E5444412E4D455B44202000B43A'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'CLSPRD.TDA.MQM '
** Identity Context
UserIdentifier : ' '
AccountingToken :
X'0000000000000000000000000000000000000000000000000000000000000000'
ApplIdentityData : ' '
** Origin Context
PutApplType : '7'
PutApplName : 'CLSPRD.TDA.MQM '
PutDate : '20061116' PutTime : '15543176'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 236 bytes
00000000: 0000 0007 0000 0024 0000 0001 0000 002D '.......$.......-'
00000010: 0000 0001 0000 0001 0000 0001 0000 08B0 '...............°'
00000020: 0000 0006 0000 0004 0000 0044 0000 07DF '...........D...ß'
00000030: 0000 0000 0000 0030 434C 5350 5244 2E54 '.......0CLSPRD.T'
00000040: 4441 2E4D 514D 2020 2020 2020 2020 2020 'DA.MQM '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 0000 0004 0000 0044 ' .......D'
00000070: 0000 07D2 0000 0000 0000 0030 434C 532E '...Ã’.......0CLS.'
00000080: 5444 412E 4552 522E 5155 4555 4520 2020 'TDA.ERR.QUEUE '
00000090: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000A0: 2020 2020 2020 2020 2020 2020 0000 0003 ' ....'
000000B0: 0000 0010 0000 0023 0000 0056 0000 0003 '.......#...V....'
000000C0: 0000 0010 0000 0024 0000 0FA0 0000 0003 '.......$... ....'
000000D0: 0000 0010 0000 0025 0000 0FA0 0000 0003 '.......%... ....'
000000E0: 0000 0010 0000 0026 0000 0BB8 '.......&...¸ '
TRIGGERED:-
MQOPEN - 'EVENTQ'
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 819
Format : 'MQEVENT '
Priority : 0 Persistence : 0
MsgId : X'414D5120434C535052442E5444412E4D455B44202000DE01'
CorrelId : X'000000000000000000000000000000000000000000000000'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : 'CLSPRD.TDA.MQM '
** Identity Context
UserIdentifier : 'mqm '
AccountingToken :
X'0335303000000000000000000000000000000000000000000000000000000006'
ApplIdentityData : ' '
** Origin Context
PutApplType : '6'
PutApplName : ' '
PutDate : '20061120' PutTime : '13215559'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 236 bytes
00000000: 0000 0007 0000 0024 0000 0001 0000 002D '.......$.......-'
00000010: 0000 0000 0000 0001 0000 0001 0000 08B0 '...............°'
00000020: 0000 0006 0000 0004 0000 0014 0000 07DF '...............ß'
00000030: 0000 0000 0000 0030 434C 5350 5244 2E54 '.......0CLSPRD.T'
00000040: 4441 2E4D 514D 0020 2020 2020 2020 2020 'DA.MQM. '
00000050: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000060: 2020 2020 2020 2020 0000 0004 0000 0014 ' ........'
00000070: 0000 07E0 0000 0000 0000 0030 434C 532E '...Ã .......0CLS.'
00000080: 5444 412E 4552 522E 5155 4555 4500
2020 'TDA.ERR.QUEUE. '
00000090: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
000000A0: 2020 2020 2020 2020 2020 2020 0000 0003 ' ....'
000000B0: 0000 0010 0000 0023 0000 0000 0000 0003 '.......#........'
000000C0: 0000 0010 0000 0024 0000 1388 0000 0003 '.......$........'
000000D0: 0000 0010 0000 0025 0000 1388 0000 0003 '.......%........'
000000E0: 0000 0010 0000 0026 0000 0000 '.......&.... '
MQ Version 5.3 CSD 5
AIX O/S |
|
Back to top |
|
 |
jefflowrey |
Posted: Mon Nov 20, 2006 6:51 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002 Posts: 19981
|
Wow, that's a long jump to avoid configuring Tivoli to monitor the enqueue rate on the queue. _________________ I am *not* the model of the modern major general. |
|
Back to top |
|
 |
Nigelg |
Posted: Mon Nov 20, 2006 7:18 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
The second msg is a badly-formed PCF msg.
Each msg starts with a PCF header, an MQCFH structure which is x24 bytes long.
In the 1st msg, the next structure is an MQCFST, length x44, type x7DF, 2015, MQCA_Q_MGR_NAME, followed by another MQCFST, length x44, type x7D2, 2002, MQCA_BASE_Q_NAME.
The next structure is the same in the 2nd msg, but the length is x14, not long enough to contain ANY of the qmgr name. Thereafter, the 2nd msg is no longer recognisable as a PCF msg, because where the 3rd structure should be, i.e. StrucLength bytes after the start of the 2nd structure, is the qmgr name and not a valid PCF msg structure type.
Additionally, the 3rd structure (or at least what I suppose is intened to be the 3rd structure) is a type x7E0, 2016, MQCA_Q_NAME, not the same as in the 1st msg.
The assertion that the msgs are 'virtually identical' does not survive close inspection of the msg data.
I recommend reading the PCF manual again to find out how to construct PCF msgs properly. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
Vitor |
Posted: Mon Nov 20, 2006 7:19 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
Or set up a Tivoli agent to monitor the queue directly....  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
nathanw |
Posted: Mon Nov 20, 2006 7:31 am Post subject: |
|
|
 Knight
Joined: 14 Jul 2004 Posts: 550
|
why pay for all that software if yu aint gonna use it? _________________ Who is General Failure and why is he reading my hard drive?
Artificial Intelligence stands no chance against Natural Stupidity.
Only the User Trace Speaks The Truth  |
|
Back to top |
|
 |
PhiliB |
Posted: Mon Nov 20, 2006 8:57 am Post subject: |
|
|
Novice
Joined: 16 Sep 2004 Posts: 21 Location: Portsmouth
|
Thanks Nigel
We added the MQ_Q_NAME_LENGTH & MQ_Q_MGR_NAME_LENGTH to the StrucLength field in pst1 & pst2
i.e (pst1->StrucLength = (MQCFST_STRUC_LENGTH_FIXED + MQ_Q_MGR_NAME_LENGTH);
and this seems to have done the trick, as the alert now contains the correct infomation.
To all those others dont worry i will be speaking to the Tivoli "experts !!" about a more simple monitoring option
Cheers
Phil |
|
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
|
|
|
|