| Author |
Message
|
| kishi_25 |
 Posted: Thu Jan 25, 2018 1:08 pm Post subject: Getting Failed message info from DLQ without tools |
 |
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
Hi,
Is there anyway we can get Original destination queue name, QM name for the failed Messages in DLQ. I want to get this information without using any support pacs. I was able to use sampel program amqsbcg to get reason code in Hex format and converted it. Similar to this, is there anyway I can get the Original destination queue name and queue manager name?
Thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 25, 2018 2:05 pm Post subject: Re: Getting Failed message info from DLQ without tools |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishi_25 wrote: |
| Similar to this, is there anyway I can get the Original destination queue name and queue manager name? |
These fields are in the same header as the reason code. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Thu Jan 25, 2018 6:47 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
Agree with you. But, the problem is I can read the Reason code from 5 th and 6th byte in fixed place as below. But, getting the queue name and QMGR name from the below message is difficult as they are not coming in fixed place and also coming as separate section next to Hexa values and truncating in multiple lines.
00000000: 444C 4820 0100 0000 EE07 0000 5445 5354 'DLH ........TEST'
00000010: 2E44 4C51 2020 2020 2020 2020 2020 2020 '.DLQ '
00000020: 2020 2020 2020 2020 2020 2020 2020 2020 ' '
00000030: 2020 2020 2020 2020 2020 2020 514D 4447 ' QMDG'
00000040: 3031 4D31 2020 2020 2020 2020 2020 2020 '01M1 '
|
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 26, 2018 5:33 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishi_25 wrote: |
| But, getting the queue name and QMGR name from the below message is difficult as they are not coming in fixed place |
Yes they are. There are no variable length fields in the MQDLH.
| kishi_25 wrote: |
| also coming as separate section next to Hexa values and truncating in multiple lines. |
The amqsbcg sample application shows 2 sections - the raw hex of the message and the character representation of that hex (fairly standard for a hex viewer). So it even shows the character representation of the reason code, albeit as a couple of dots indicating the hex doesn't map to a printable character.
If you don't want to use a support pac (and I struggle to think why not), modify the amqsbcg sample to a) display the data differently or b) form the basis of a home - grown DLH handler that not only displays the names as complete strings but converts the reason code for you. And enjoy this new wheel you will have invented.
One of the good things about computers is that they can do things for you, eliminating (as an example) the need to look at the hex dump of a message to figure out why it's on a DLQ.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri Jan 26, 2018 7:17 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
| I'm trying to write a shell script, which should read message from DLQ and gets values of MQRC code, Destination queue name and Queue manager name. For this I started with amqsbcg reading DLQ and putting in a file and from there get the values. For reason code, though it's in hex form, getting mqrc is not straight forward as we need to swap and reverse the hex codes. Now, i'm struck with how to get queue and qm values using a script. I can't use the scrip t with combination of RFHUTIL and MQMON as they are in GUI. other option, I'm thinking is to use script to get these values from qload/dmpmqmsg. Looks like amqsbcg is not in a readable format, so it seems to be cusotmizing is not possible with it. is there any other better option? |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri Jan 26, 2018 7:36 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
| Also, it seems we have source code for amqsbcg in other directory with C language. However, i'm looking for other better options instead of customizing it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 26, 2018 3:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
MQ dead-letter header is well-documented, and contains fixed-position and fixed-length fields. Go to google. Search for 'mqdlh+format'.
Yes, on Intel hardware the RC is bytes must be reversed to reveal the hex-equivalent of the decimal ReasonCode.
Are you an experienced shell-script coder? C programmer? Other?
Search google for 'byte manipulation in shell scripts'.
Search google for 'convert hex to decimal in shell script'.
I'd also recommend that you investigate the IBM-supplied Dead-Letter Handler utility that can deal with DLH messages - like retry, move to another queue, ignore, delete, etc., based on the ReasonCode.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri Jan 26, 2018 3:15 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
now, I'm trying with dmpmqmsg/shall script combination, which seems to be some what better in fetching these values. C programming I have done way back  . So, I want to rely on shell script. DLH, which IBM supplied is doing most of the times retrying and has limitations to act on changing destination queue properties . |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Jan 26, 2018 3:17 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| kishi_25 wrote: |
| I'm trying to write a shell script, which should read message from DLQ and gets values of MQRC code, Destination queue name and Queue manager name. |
| kishi_25 wrote: |
| I can't use the scrip t with combination of RFHUTIL and MQMON as they are in GUI. other option, I'm thinking is to use script to get these values from qload/dmpmqmsg. Looks like amqsbcg is not in a readable format, so it seems to be cusotmizing is not possible with it. is there any other better option? |
Yeah. Why don't you try out MQ Batch Toolkit. Its whole purpose is to be driven from a script and it understands MQ headers like the MQDLH.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 26, 2018 4:22 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishi_25 wrote: |
| has limitations to act on changing destination queue properties . |
Really? What limitations?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Fri Jan 26, 2018 7:45 pm Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 29, 2018 6:42 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
None of these are limitations on changing destination queue properties.
Also increasing queue depth for a queue full event is not addressing the root cause, but obviating the symptoms. If the queue is filling up, the most likely causes are the application responsible for reading messages off is either performing below SLA or has crashed. Hence the hander provides the option to retry the messages once the root application problem is corrected. If the application has crashed, increasing the max depth makes things worse because it hides the problem until you either hit the hard limit for queue depth or run out of disc for the queue file.
I'd also question the wisdom of increasing the max message size on a queue just because you're getting a message that exceeds it. Max message size (like max queue depth) exists as a safety feature to deal with malfunctioning applications. If a message suddenly starts sending messages larger than it used to, I (as MQ admin) would want to know why the behavior has changed before I arbitrarily increased the limit.
If this is all you want your script to do, alter the max message size of all your queues to 100Mb, and the max depth to 99999999999. Requires no coding (unless you script the changes) and will achieve the same result.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Jan 29, 2018 7:21 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
While I applaud your technical solution (automating increase in max queue depth and max msg length), it does not address the underlying problem, namely: lack of planning by analysts and developers.
Rather than pursuing your script, I strongly suggest pushing back on the analysts and developers to tell you the precise specifications for max msg size and max queue depth - including growth over time. These are knowable and predictable.
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| kishi_25 |
| Posted: Mon Jan 29, 2018 11:14 am Post subject: |
|
|
Centurion
Joined: 19 Jul 2011
Posts: 100
|
| Agree that, from MQ admin point of view these are not best solutions. But, in practical scenarios, when we had these scenarios occur in cluster environment, it had trickle-down effect for other applications due to messages accumulating xmit queues for maxdepth issue and max length issue msgs land in dlq. So, the solution i'm trying to implement is to do auto fix temporarily in the sense, auto increase of queue depth and max length temporarily and revert back these values after the issue is resolved and it will send an e-mail to related support team to address the root cause next business day. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Jan 29, 2018 11:25 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| kishi_25 wrote: |
| when we had these scenarios occur in cluster environment, it had trickle-down effect for other applications .... it will send an e-mail to related support team to address the root cause next business day. |
If this sort of thing causes a problem in a cluster environment, your cluster environment is set up wrong.
If this is the only means you have of detecting a problem within the MQ estate, or application software, then your site has a problem with it's lack of effective monitoring.
"Next business day" is a long time to wait for a support team to respond, and an optimistic time frame for an application team to trace & resolve a problem. Say they've implemented a change that makes their reading application run slow, or worse have changed an application so it sends longer messages intermittently. How long will that take to find, fix and implement into production?
You're putting a Band-Aid on a broken leg.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
