| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQCSMF Question |
« View previous topic :: View next topic » |
| Author |
Message
|
| kevinf2349 |
 Posted: Thu Jul 31, 2008 12:40 pm Post subject: MQCSMF Question |
 |
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
We are z/OS 1.9, MQ 6.0.
We collect all type 115 & type 116 SMF records for our MQ systems and I am running the support pack (MP1B) sample programs but I am getting some strange results that I am having trouble understanding.
I have actually sent a question to IBM about this but thought I would ask it here too.
On the MQGET stats I understand the disparity in the MQGETs can be caused by wait intervals popping without a message available (2033 reason code). This is not at issue, but what I don't understand is that in these circumstances, even after a valid MQGET is registered the bytes transfered is 0. Now I understand that 0 length messages are possible, but I really doubt this is happening 'across the board'.
Also we don't see any bytes transfered for any dynamic queues....but this could be because of the issue above.
We also see an awful lot of 'non productive' MQGETs for our workflow queues...about one every 20 seconds but we are following this up elsewhere.
Has anyone got any thoughts on why this is happening? |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Thu Jul 31, 2008 1:34 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...even after a valid MQGET is registered the bytes transfered is 0... |
I suppose as MQ sees it, an MQGET that results in a 2033 is a valid get. The call did everything it's supposed to do (as defined in the APR), but found no message to give you.
I'm guessing that you have applications that do MQGETs with waitinterval, and repeat this forever or for some number of loops (isn't this the recommeded coding technique?).
_________________
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 |
|
|
| kevinf2349 |
| Posted: Thu Jul 31, 2008 1:53 pm Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
Hmmm It could be, but the valid MQGET number is one less than the MQGET value. It says that there were 2 MQGETs but only 1 Valid MQGET.
I guess it could see a 2033 as a valid return, but that then begs the question....what is an invalid MQGET?  |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 31, 2008 2:39 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
I'm away from big iron right now... But here's a reference:
Message manager data records
The format of the message manager statistics record is described in assembler macro thlqual.SCSQMACS(CSQDQMST).
The data gives you counts of different WebSphere MQ API requests.
I can only hope that there's an explanation.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp?topic=/com.ibm.mq.csqsav.doc/csqsav0472.htm
[EDIT] This from the WMQ Monitoring manual:
GetCount
Description: The number of successful destructive get requests for persistent and
nonpersistent messages.This parameter is an integer list indexed by
persistence value, see Note 2 on page 306
Identifier: MQIAMO_GETS.
Datatype: MQCFIL.
Included in PCF
group:
QStatisticsData.
Returned: When available.
GetFailCount
Description: The number of unsuccessful destructive get requests.
Identifier: MQIAMO_GETS_FAILED.
Datatype: MQCFIN.
Included in PCF
group:
QStatisticsData.
Returned: When available
[EDIT]
There are similar entries for successful/unsuccessful browses, puts, put1s. Still, what does it mean?
_________________
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 |
|
|
| bruce2359 |
| Posted: Fri Aug 01, 2008 6:33 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
This is from the APG manual:
Some cases where the MQGET call fails
If certain attributes of a queue are changed using the FORCE option on a command between issuing an MQOPEN and an MQGET call, the MQGET call fails and returns the MQRC_OBJECT_CHANGED reason code. The queue manager marks the object handle as being no longer valid. This also happens if the changes apply to any queue to which the queue name resolves. The attributes that affect the handle in this way are listed in the description of the MQOPEN call in the WebSphere MQ Application Programming Reference. If your call returns the MQRC_OBJECT_CHANGED reason code, close the queue, reopen it, then try to get a message again.
If get operations are inhibited for a queue from which you are attempting to get messages (or any queue to which the queue name resolves), the MQGET call fails and returns the MQRC_GET_INHIBITED reason code. This happens even if you are using the MQGET call for browsing. You might be able to get a message successfully if you attempt the MQGET call at a later time, if the design of the application is such that other programs change the attributes of queues regularly.
If a dynamic queue (either temporary or permanent) has been deleted, MQGET calls using a previously-acquired object handle fail and return the MQRC_Q_DELETED reason code. Browsing messages in logical order
Chapter
_________________
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 |
|
|
|
|
|
| |
|
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
|
|
|
|
