| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Does MQOO_INQUIRE read entire message (reading in _chunks_? |
« View previous topic :: View next topic » |
| Author |
Message
|
| aeberle |
 Posted: Wed Jul 16, 2008 10:46 am Post subject: Does MQOO_INQUIRE read entire message (reading in _chunks_? |
 |
|
Newbie
Joined: 16 Jul 2008
Posts: 2
|
| Is there a way (on Z/os [CICS]) to determine the size of a message without having to overhead of actually reading the message? I know you can peek at a message using the MQOO_INQUIRE parameter. However I suspect that it will actually read the message to set the attributes. I would like to avoid that if at all possible. I am looking for a way to determine the size of an MQ message without having the cost/overhead of reading the entire message each time just to get a size. One possible alternative I have found is to try and allocate a large buffer and then catch when an MQRC_TRUNCATED_MSG_ACCEPTED message is thrown and allocate an even larger buffer and try to read again (actually at this point I should know the message size.) Is there a better way to do this? I would have liked to have been able to use 'arbitrary segmentation' but it appears that this functionality is available on all platforms except z/os. Thanks in advance for any insight. |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Wed Jul 16, 2008 12:57 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| I know you can peek at a message using the MQOO_INQUIRE |
MQINQuire lets you inquire on the values of attributes of objects, like queues and qmgr.
You are on a mainframe, where resources abound.
The MQGET call (browse or destructive read) returns the actual message length. This would require far less overhead (mainframe and mid-range) than recursive MQGET calls and managing application buffers of various sizes until you don't get the truncated message accepted reason code.
Allocate a buffer as large as the largest message you can MQGET; then the MQGET call tell you how long the message is.
Edit: Please read the WMQ Application Programming Reference manual, and the WMQ Application Programming Guide, the sections on MQGET and MQINQ to get an understanding of what these API calls do.
_________________
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 |
|
|
| aeberle |
| Posted: Thu Jul 17, 2008 5:16 pm Post subject: |
|
|
Newbie
Joined: 16 Jul 2008
Posts: 2
|
| Quote: |
| The MQGET call (browse or destructive read) returns the actual message length. This would require far less overhead (mainframe and mid-range) than recursive MQGET calls and managing application buffers of various sizes until you don't get the truncated message accepted reason code. |
I guess I am not 100% clear what you are stating. There would not be a need to have recursive MQGET calls. When a GET fails with a truncation error then the attributes would be set to indicate message size and I could allocate an appropriate size buffer at that time.
It sounds like you might be saying that MQINQuire might be able to provide me with the attributes and not have the overhead of reading the message in the process. I can't remember if MQ stored the attributes in an envelope of sorts of if only could determine message size by actually reading/parsing the message. That, to me, would be far too much overhead. However if inquiring for the attributes just reads the attributes then that sounds much more appealing.
It's been quite a few years since I have coded for MQ. Thanks for the suggestion on the reference manual. I've forgotten the names of most of manuals I used to use. I'll check out MQINQuire and MQGET.[/quote] |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Thu Jul 17, 2008 8:24 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| There would not be a need to have recursive MQGET calls. When a GET fails with a truncation error then the attributes would be set to indicate message size and I could allocate an appropriate size buffer at that time. |
First, MQINQ can tell you about current depth of a queue (how many messages), but not the size of message(s) in the queue.
If you code your application to do an MQGET with ACCEPT_TRUNCATED_MESSAGE with a too-small buffer, only to discover that the MQGET only delivers the truncated part of the message; then you must create a bigger buffer in your program AND do another (recursive) MQGET.
The first MQGET will return the actual message length AND as much data as your buffer will allow. One MQGET does it all.
Again, I'd suggest making your application buffer as big as the largest message you are likely to encounter. One and only one MQGET will ever be needed.
I don't understand your issue/concern with overhead. Overhead from what? Reading or parsing what? When you do an MQGET, you get the message descriptor (MQMD) and the application data.
Your original post subject asked Does MQOO_INQUIRE read entire message (reading in _chunks_?)
MQINQ lets you inquire on attributes of mq objects. A message is not an object.
If you are asking if MQGET gets a message in chunks, the answer is no. As I read your narrative, it seems that you expect a single MQGET call to deliver the truncated portion; and, when a new buffer appears, it will continue to deliver more of the message. MQGET doesn't work that way.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Sat Jul 19, 2008 8:50 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| bruce2359 wrote: |
If you code your application to do an MQGET with ACCEPT_TRUNCATED_MESSAGE with a too-small buffer, only to discover that the MQGET only delivers the truncated part of the message; then you must create a bigger buffer in your program AND do another (recursive) MQGET. |
The message is gone. You can't issue another MQGET, because you told MQ that you would accept the truncated message.
You want to use the option that rejects the truncated message. It will stil return the size of the message, but the message stays on the q. Now you can issue a second MQGET with the correct buffer size.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jul 19, 2008 11:10 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9470
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| The message is gone. |
I was thinking about MQGMO_BROWSE. Actual message length gets returned, the message remains in the queue, AND the application must issue another MQGET with an appropriately sized buffer.
In any case, with a too-small buffer, the application will need to do multiple (recursive, repetitive, redundant) MQGETs to ultimately get all the message. There's needless overhead for you.
Which gets back to the point: there is needful overhead (like MQGET and MQPUT calls themselves), and needless overhead - like the MQINQ as described in the original post.
I've observed a number of applications that do an MQINQ to determine if there are messages in the queue; and then do an MQGET to consume them. This sounds logical, I guess; but the MQINQ is redundant - therefore needless (overhead).
_________________
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
|
|
|
|
