ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ API Support » [Solved] CURDEPTH = 632 but no more messages (2033)

Post new topic  Reply to topic
 [Solved] CURDEPTH = 632 but no more messages (2033) « View previous topic :: View next topic » 
Author Message
mcruse
PostPosted: Mon Feb 10, 2003 3:58 am    Post subject: [Solved] CURDEPTH = 632 but no more messages (2033) Reply with quote

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
View user's profile Send private message
mqonnet
PostPosted: Mon Feb 10, 2003 6:13 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mcruse
PostPosted: Mon Feb 10, 2003 6:57 am    Post subject: Reply with quote

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
View user's profile Send private message
mqonnet
PostPosted: Mon Feb 10, 2003 7:10 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mcruse
PostPosted: Mon Feb 10, 2003 7:53 am    Post subject: Reply with quote

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
View user's profile Send private message
mqonnet
PostPosted: Mon Feb 10, 2003 8:55 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
bduncan
PostPosted: Mon Feb 10, 2003 1:00 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
mqonnet
PostPosted: Mon Feb 10, 2003 1:28 pm    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
bduncan
PostPosted: Mon Feb 10, 2003 6:30 pm    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
mcruse
PostPosted: Mon Feb 10, 2003 11:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
mcruse
PostPosted: Tue Feb 11, 2003 4:53 am    Post subject: Reply with quote

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
View user's profile Send private message
mqonnet
PostPosted: Tue Feb 11, 2003 5:59 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
mqonnet
PostPosted: Tue Feb 11, 2003 6:08 am    Post subject: Reply with quote

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
View user's profile Send private message Send e-mail Visit poster's website
bduncan
PostPosted: Tue Feb 11, 2003 9:10 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
bduncan
PostPosted: Tue Feb 11, 2003 9:13 am    Post subject: Reply with quote

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
View user's profile Send private message Visit poster's website AIM Address
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ API Support » [Solved] CURDEPTH = 632 but no more messages (2033)
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.