Author |
Message
|
mcruse |
Posted: Mon Feb 10, 2003 3:58 am Post subject: [Solved] CURDEPTH = 632 but no more messages (2033) |
|
|
 Novice
Joined: 15 Apr 2002 Posts: 13 Location: Germany
|
Hello,
runmqsc shows me 632 messages on a queue. If I want to browse this queue with amqsbcg it tells me that there is no more message. If I use MQMon (MO71) I can browse each message and the descriptor (MQMD)!!!
The size of the messages is about 1000 bytes.
Very strange.
How can I modify amqsbcg to show me also the MQMD for those messages?
There is no source shipped with mqmon
wkr
Markus Cruse |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Feb 10, 2003 6:13 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Strange for sure. But there ought be some explaination for everything.
What are the options you are selecting while you were trying to browse the messages using MQMon. If possible, give a detailed overiew. I just did a quick test and i could not get any messages, assuming that these messages were within Syncpoint. This is the only scenario that i can think of which would cause such an inconsistency.
Also, did you do a dis ql() of the queue you are trying read messages off, each time before you issued runmqsc and ran MQMon to see if there are any ip/opprocs. Which would tell you if there are any other applications that have this queue open, may be doing syncpoing puts/gets.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
mcruse |
Posted: Mon Feb 10, 2003 6:57 am Post subject: |
|
|
 Novice
Joined: 15 Apr 2002 Posts: 13 Location: Germany
|
With runmqsc and "dis q() all" I can see this important values:
IPPROCS(0)
OPPROCS(0)
CURDEPTH(632)
The sample amqsbcg shows me:
AMQSBCG0 - starts here
**********************
MQOPEN - '<queue name>'
No more messages
MQCLOSE
MQDISC
With MQMon (MO71) I can browse all messages and have a look at the MQMD. Some
important values are:
Version :2
Report :0
Message Type :8
Expiry :-1
Format :'MQSTR '
Backout Cnt. :0
Put Date :'20030118'
Put Time :'13282844'
Msg Seq No. :1
Offset :0
MsgFlags :0
Original Len.:-1
No I am very confused. The queue was not opened. There are 632 messages on it.
The sample amqsbcg can't see any message. There is no expiry. No backout count.
My questions are:
Is this because the messages are uncommited?
How can I solve this problem without a restart of the queue manager?
How to code amqsbcg to have a look at the MQMD of those mesages (like MQMon)? |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Feb 10, 2003 7:10 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
If you put these messages on the queue you are working on, as part of a UOW where in MQseries was acting as the Transaction manager/co-ordinator, then i would expect either the ip/opprocs be greater than 1 at all times. But since it isnt. I dont think there would be an outstanding UOW or uncommitted messages.
As i posted earlier, could you narrate your usage of MQMon in detail.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
mcruse |
Posted: Mon Feb 10, 2003 7:53 am Post subject: |
|
|
 Novice
Joined: 15 Apr 2002 Posts: 13 Location: Germany
|
With MQSeries the management of transactions is a part of the TANDEM system. I
am using MQMon at a win 2k system over a SVRCONN. With "Queue List..." and "
Browse..." I can see all the messages on that queue.
I can also browse with MA01 (q).
q -iQueue -b
With amqsbcg and a modified version for our operators it is impossible to browse
the messages.
How can I modify amqsbcg to show me the messages in browse mode? I think MQMon
an q are using another open option or gmo options. |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Feb 10, 2003 8:55 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
I would think if one app(MQMON or MA01) is able to retrieve the messages, others(amqsbcg) should also be able to do the same.
What platform are you on( guess tandem, since you mentioned that). What version of mq. Any errors/FDC's during all this process.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
bduncan |
Posted: Mon Feb 10, 2003 1:00 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
Remember, a 2033 doesn't mean there aren't any messages on the queue. It just means that for the particular MQGET call you just made, no messages on the queue matched the criteria you provided. This is why if you do an MQGET and match for a specific correlation id which isn't on the queue, you get a 2033. Now, we all know amqsbcg isn't matching against correlation id, however, if you look at the amqsbcg source, you'll see it is using MQGMO_DEFAULT. If you look at the following link, you'll see what all the MQGMO parameters are set to if you use this constant: http://www-3.ibm.com/software/ts/mqseries/library/manualsa/csqzak05/csqzak051a.htm
What's important to notice here is that GroupStatus and SegmentStatus are set to MQGS_NOT_IN_GROUP and MQSS_NOT_A_SEGMENT respectively. Which means that if these messages are part of a group or segment, amqsbcg will not see them and return a 2033, whereas I surmise that a professional monitoring tool like MQMON will not have such a restriction. _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
mqonnet |
Posted: Mon Feb 10, 2003 1:28 pm Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Brandon, i am not quite with you on this one. Am i missing something here???
"What's important to notice here is that GroupStatus and SegmentStatus are set to MQGS_NOT_IN_GROUP and MQSS_NOT_A_SEGMENT respectively. Which means that if these messages are part of a group or segment, amqsbcg will not see them and return a 2033, whereas I surmise that a professional monitoring tool like MQMON will not have such a restriction"
My understanding is, irrespective of what type of message you have on a queue, Standard sample "AMQSBCG" would be able to retrive a message on the queue. As you pointed out, in the case of a grouped or a segmented messages too, this should work just fine.
Reason.
Bcg gets the 1st "available" message off the queue, it does not care if it is a logical message forming a big chunk of a physical message(either using grouping or segmentation feature). So, it should just go ahead and retrieve the message. Unless the match options are different. But since bcg uses defaults, it should be just fine.
My theory in this case is, either we are missing/omitting something or something strange somewhere that needs digging. Because, if you are able to retrieve messages(under normal circumstances) using One app, you should be able to retrive it using another. Moreover bcg would always be the most simplest test case than even MQMon.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
bduncan |
Posted: Mon Feb 10, 2003 6:30 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
You cannot make the assumption that because one app can retrieve a message then another app should be able too. This is because we don't have any idea of what parameters MQMON is using when it issues an MQGET. However, we do know what parameters amqsbcg is using. It is using MQGMO_DEFAULT, and if you look in the API reference (http://www-3.ibm.com/software/ts/mqseries/library/manualsa/csqzak05/csqzak0519.htm), you'll see that the groupstatus field can have 3 values:
Quote: |
Flag indicating whether message retrieved is in a group.
It has one of the following values:
MQGS_NOT_IN_GROUP
Message is not in a group.
MQGS_MSG_IN_GROUP
Message is in a group, but is not the last in the group.
MQGS_LAST_MSG_IN_GROUP
Message is the last in the group. |
Note that is says "whether message retrieved is in a group". So if we specify MQGS_NOT_IN_GROUP (which is what MQGMO_DEFAULT does) then it will only retrieve those messages not in a group.
I don't happen to be in front of a queue manager to test this, but I'm quite certain that the standard amqsbcg program will NOT display messages which are part of a group or segment. _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
mcruse |
Posted: Mon Feb 10, 2003 11:30 pm Post subject: |
|
|
 Novice
Joined: 15 Apr 2002 Posts: 13 Location: Germany
|
Yes I agree with Bduncan because the support pac's q and mqmon can display the
messages. It must be a open option or a get message option which is different
between amqsbcg and the support pac's.
But the source of the support pac's is not shipped
The putting application is a old one and I do not have the source (unavailable). |
|
Back to top |
|
 |
mcruse |
Posted: Tue Feb 11, 2003 4:53 am Post subject: |
|
|
 Novice
Joined: 15 Apr 2002 Posts: 13 Location: Germany
|
Thank you for your help. I have fixed the problem by using MQGMO_BROWSE_FIRST
with my firs MQGET and then MQGMO_BROWSE_NEXT for the others.
I do not know exactly why the browse cursor did not point to the first message
after the MQOPEN. Mybe they call it "works as designed" or "it is not a bug it is
a feature".
ciao
Markus Cruse |
|
Back to top |
|
 |
mqonnet |
Posted: Tue Feb 11, 2003 5:59 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Brandon,
I am afraid i have to differ with your point of view and you can as well test the same. I was sure of what i said, but just tested it as well to see if it works and it did.
You CAN browse a queue that has grouped or segmented messages on it just fine using the standard supplied "amqsbcg" sample program. I totally agree with you regarding the group status etc not being set in amqsbcg, but you have to bear in mind that all these options take effect only if you modify the MATCH_OPTIONS to say, i only want messages in group. But since amqsbcg uses the defaults which is "3/match only msgid and correl id", amqsbcg retrieves ANY AVAILABLE message on queue. Irrespective of the message being a physical message or a logical message part of a physical one.
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
mqonnet |
Posted: Tue Feb 11, 2003 6:08 am Post subject: |
|
|
 Grand Master
Joined: 18 Feb 2002 Posts: 1114 Location: Boston, Ma, Usa.
|
Just to add a little note to my previous post.
GroupStatus MQGS_NOT_IN_GROUP ' ' , is similar to saying
MsgId MQMI_NONE Nulls .
Which means i(application) am initializing these fileds to nulls or blanks using the default structures, so as to allow the QM to fill in whatever it gets from an "available" message on the queue.
I agree with your comment that we dont know what MQMon is using as arguments while issuing an MQGET. But since it is working, that forced me to believe that AMQSBCG would also work for sure. Reason being. amqsbcg uses the Basic basic values or rather all the defaults. And MQMon would either use defaults or anything beyond defaults. Which means AMQSBCG is always using a subset of what MQMon is using and hence amqsbcg should have always gotten what MQmon did.
My 2 cents..
Cheers.
Kumar _________________ IBM Certified WebSphere MQ V5.3 Developer
IBM Certified WebSphere MQ V5.3 Solution Designer
IBM Certified WebSphere MQ V5.3 System Administrator |
|
Back to top |
|
 |
bduncan |
Posted: Tue Feb 11, 2003 9:10 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
Hmm... You may be right about this Kumar. But I'll still try to test it for myself when I have a chance. When I read a little more out of the API reference, the definition of MQMO_NONE points out:
Quote: |
MQMO_NONE
No matches.
This option specifies that no matches are to be used in selecting the message to be returned; therefore, all messages on the queue are eligible for retrieval (but subject to control by the MQGMO_ALL_MSGS_AVAILABLE, MQGMO_ALL_SEGMENTS_AVAILABLE, and MQGMO_COMPLETE_MSG options).
|
Which makes no mention of MQGS_NOT_IN_GROUP. _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
bduncan |
Posted: Tue Feb 11, 2003 9:13 am Post subject: |
|
|
Padawan
Joined: 11 Apr 2001 Posts: 1554 Location: Silicon Valley
|
And Markus, I'm glad to hear that you got it working. I was under the impression that the browse cursor was always set back to the first message on the queue whenever the MQOPEN occurs. It's odd that it seemed to stay pointing to whatever message (presumeably pointing to the spot right after the last message) it was pointing to on a previous execution of some application... hmm... _________________ Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
Back to top |
|
 |
|