| Author |
Message
|
| MQFly |
 Posted: Mon Apr 20, 2015 8:07 am Post subject: DLQ reasons for Solaris, MQRC 0x000000bc |
 |
|
Newbie
Joined: 20 Apr 2015
Posts: 8
Location: Toronto, ON
|
Hi guys,
Is anyone knows where I can get MQRC codes for Solaris MQ?
There is the string with error code:
X 5246 4820 0000 0002 0000 00BC 0000 01110 0000 4B84 D5153 5452 <RFH ................MQSTR>
MQRC code is 0000 00BC, but I can't find something about this code.
I have no access to the queue manager with MQExplorer.
regards, |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Mon Apr 20, 2015 8:31 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
the command mqrc will give you the meaning of any mqrc code on any platform.
If you want to translate a hex value into a number, you need to know the endianness of the platform producing the hex number. |
|
| Back to top |
|
|
| PaulClarke |
| Posted: Mon Apr 20, 2015 8:55 am Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Are you sure this is a reason code?
From what little you have told us this looks like an MQRFH2 structure with 000000BC being the length of the structure.
Regards,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Apr 20, 2015 12:01 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi MQFly,
Why don't you look up MQRFH2 structure in the Knowledge Center or cmqc.h file.
i.e.
| Code: |
struct tagMQRFH2 {
MQCHAR4 StrucId; /* Structure identifier */
MQLONG Version; /* Structure version number */
MQLONG StrucLength; /* Total length of MQRFH2 including all */
/* NameValueLength and NameValueData */
/* fields */
MQLONG Encoding; /* Numeric encoding of data that follows */
/* last NameValueData field */
MQLONG CodedCharSetId; /* Character set identifier of data that */
/* follows last NameValueData field */
MQCHAR8 Format; /* Format name of data that follows last */
/* NameValueData field */
MQLONG Flags; /* Flags */
MQLONG NameValueCCSID; /* Character set identifier of */
/* NameValueData */
}; |
Hence, bytes 9 to 12 are the structure length which Paul already mentioned.
And if your message was in the DLQ (as mentioned in the subject) then it would have a MQDLH structure in front of your message.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Apr 20, 2015 12:04 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Also, generally, the MQRC is returned to the program that issues an MQ call.
The only place it generally appears in a message, unless I remember wrong, is in a message on the Dead Letter Queue. |
|
| Back to top |
|
|
| MQFly |
| Posted: Mon Apr 20, 2015 12:11 pm Post subject: |
|
|
Newbie
Joined: 20 Apr 2015
Posts: 8
Location: Toronto, ON
|
oh, nice to hear from MQ grand masters!
sorry, have to be more clear..
mqjeff is right, main problem is how to translate that number 0x000000BC to mqrc code.
| Quote: |
bash-3.2$ mqrc 0x000000BC
No matching return codes |
does not work..
will try to find out translation mechanism for Solaris |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Mon Apr 20, 2015 12:31 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| MQFly wrote: |
| sorry, have to be more clear.. |
No. You need to read Paul's or my posts. AGAIN.
| MQFly wrote: |
does not work..
will try to find out translation mechanism for Solaris |
You can look until the cows jump over the moon, but you posted MQRFH2 structure which does NOT have a reason code in the structure.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| MQFly |
| Posted: Tue Apr 21, 2015 3:01 pm Post subject: |
|
|
Newbie
Joined: 20 Apr 2015
Posts: 8
Location: Toronto, ON
|
Thanks, Roger
you and Paul right, this message doesn't have DLH, because remote application put it in DLQ under some logical reason and bytes 9-12 doesn't show us reason code in this case. It is just message structure.
Thanks for the lesson.
Just in case, who can have the same question..
this is the original message in DLQ, which has format MQHRF2, but not MQDEAD:
| Quote: |
MQOPEN - 'FS.TFS.*.*.RSP.DEAD.LETTER'
MQGET of message number 1
****Message descriptor****
StrucId : 'MD ' Version : 2
Report : 0 MsgType : 8
Expiry : -1 Feedback : 0
Encoding : 273 CodedCharSetId : 1208
Format : 'MQHRF2 '
Priority : 0 Persistence : 1
MsgId : X'414D51204653514D202020202020202055235D5720225209'
CorrelId : X'414D51204D46514D20202020202020205516C7D620217FA2'
BackoutCount : 0
ReplyToQ : ' '
ReplyToQMgr : '*QM '
** Identity Context
UserIdentifier : 'tfsprod '
AccountingToken :
X'0532353133360000000000000000000000000000000000000000000000000006'
ApplIdentityData : ' '
** Origin Context
PutApplType : '6' - is #define MQAT_AIX 6
PutApplName : 'mqdrsp '
PutDate : '20150407' PutTime : '14335140'
ApplOriginData : ' '
GroupId : X'000000000000000000000000000000000000000000000000'
MsgSeqNumber : '1'
Offset : '0'
MsgFlags : '0'
OriginalLength : '-1'
**** Message ****
length - 991 bytes
00000000: 5246 4820 0000 0002 0000 00BC 0000 0111 'RFH ............'
00000010: 0000 04B8 4D51 5354 5220 2020 0000 0000 '....MQSTR ....'
..
|
remote application mqdrsp from AIX put message there.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Apr 21, 2015 4:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| MQFly wrote: |
you and Paul right, this message doesn't have DLH, because remote application put it in DLQ |
Applications should not put messages to the QM's Dead Letter Queue.
Applications should not even have access to the QM's Dead Letter Queue.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Apr 21, 2015 9:55 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| PeterPotkay wrote: |
Applications should not even have access to the QM's Dead Letter Queue. |
Peter, I do beg to differ here(slightly)
If an application uses a BOQ and the BOQ becomes full then the messages are put on the DLQ. The user who has 'put' rights for the input queue AND BOQ needs to have 'put' rights to the DLQ. If you don't you get poison messages.
I know that the chances of this happening is pretty rare but it can happen.
It actually happened to a system that I was slighlty involved with almost a year ago. A application wrote a message to a queue that was read by an application that would FTP the data to a remote host. The credentials on the remote server were changed thus stopping all FTP operations.
No one bothered to look at the various alerts for several hours. By this time the BOQ was full and because there was no access to the DLQ the input queue became full and .... you can guess the rest.
You are perfectly correct in that no applicaton should ever DIRECTLY write to the DLQ. All writes to the DLQ should be done under MQ control and not under Application Control.
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 22, 2015 3:14 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| smdavies99 wrote: |
| PeterPotkay wrote: |
Applications should not even have access to the QM's Dead Letter Queue. |
Peter, I do beg to differ here(slightly)
If an application uses a BOQ and the BOQ becomes full then the messages are put on the DLQ. The user who has 'put' rights for the input queue AND BOQ needs to have 'put' rights to the DLQ. If you don't you get poison messages.
I know that the chances of this happening is pretty rare but it can happen.
It actually happened to a system that I was slighlty involved with almost a year ago. A application wrote a message to a queue that was read by an application that would FTP the data to a remote host. The credentials on the remote server were changed thus stopping all FTP operations.
No one bothered to look at the various alerts for several hours. By this time the BOQ was full and because there was no access to the DLQ the input queue became full and .... you can guess the rest.
You are perfectly correct in that no applicaton should ever DIRECTLY write to the DLQ. All writes to the DLQ should be done under MQ control and not under Application Control. |
MQ does not backout messages, applications do. So if you are proposing using the DLQ as sort of a secondary backout queue, you are proposing the app is giving put access directly to the DLQ.
I say no access for apps to the DLQ, size the apps' Input queue and backout queue appropriately, and if they fill both of them due to their apathy, the app get's what it deserves.
If the messages are arriving from a remote QM, then MQ (not an app) will spill the new messages to the DLQ if the input queue filled.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Wed Apr 22, 2015 4:56 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Nice view but flawed.
If an application is written in JMS and there is no backout queue defined but there is a backout threshold, the application will need +put +inq access to the DLQ. And the messages on the DLQ will have a dead letter queue header with code backout threshold exceeded....
This is standard behavior of the JMS/XMS app.
Now if we are talking about any other app in any other language (C, COBOL, PL1, Java base, etc...), it is the responsibility of the APP to add the DLQ header if it puts anything onto the DLQ.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| MQFly |
| Posted: Wed Apr 22, 2015 8:25 am Post subject: |
|
|
Newbie
Joined: 20 Apr 2015
Posts: 8
Location: Toronto, ON
|
Hm,
from my understanding, DLQ is a local queue and any application, which has access to the manager can put messages there directly if it designed for that.
I meant, DLQ has been used as backout queue by JMS application, in my case. But application was not designed to put DLH once put messages there for some reasons. Have no idea why.
right now it's clear for me.. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Wed Apr 22, 2015 2:16 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| fjb_saper wrote: |
Nice view but flawed.
If an application is written in JMS and there is no backout queue defined but there is a backout threshold, the application will need +put +inq access to the DLQ. And the messages on the DLQ will have a dead letter queue header with code backout threshold exceeded....
This is standard behavior of the JMS/XMS app.
Now if we are talking about any other app in any other language (C, COBOL, PL1, Java base, etc...), it is the responsibility of the APP to add the DLQ header if it puts anything onto the DLQ. |
Nice view but flawed, you couldn't have said it better 
WMB automatically will backout messages like JMS does.
Both WMB and JMS are "apps" that are backing out the messages, not MQ.
Set up the backout queue properly! Don't spend time giving access to the DLQ, spend that time making sure the BO queue and threshold are correct. And if they fill the BO queue, oh well. Why should they then fill the DLQ or more likely, fill the disk space and cause the whole QM to take a dirt nap?
Sorry, you are not getting access to the DLQ if its up to me.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Thu Apr 23, 2015 5:58 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| fjb_saper wrote: |
| It is the responsibility of the APP to add the DLQ header if it puts anything onto the DLQ. |
Nice view but flawed, you couldn't have said it better
WMB automatically will backout messages like JMS does.
Both WMB and JMS are "apps" that are backing out the messages, not MQ.
Set up the backout queue properly! Don't spend time giving access to the DLQ, spend that time making sure the BO queue and threshold are correct. And if they fill the BO queue, oh well. Why should they then fill the DLQ or more likely, fill the disk space and cause the whole QM to take a dirt nap?
Sorry, you are not getting access to the DLQ if its up to me. |
So you prefer preventing access to the DLQ than having programs written the correct way? Because we all know once developers can get away with it, there is no turning back...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
