| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| MQMessage Length |
« View previous topic :: View next topic » |
| Author |
Message
|
| darrylcook |
 Posted: Fri Sep 26, 2008 2:07 am Post subject: MQMessage Length |
 |
|
Newbie
Joined: 19 Dec 2006
Posts: 6
|
Hi all,
We run a client server application using MQ as the transport mechanism between the client and server.
We have a single server program that reads the messages off the Q. In this program the logic is as follows:
Browse the first message on Q (to get message length) options are max msg length=0 (i.e no message data is physically retrieved).
Perform a GETMAIn to get buffer storage
MQGET message-under-cursor into buffer
This is done so that the correct amount of storage is allocated for reading the message.
On closer inspection of the calls the browse returns a data length of say 400 bytes, so I allocate the appropriate storage and in the MQGET (of the same message) after the call the the data length is set to 200. I think this is because on the browse as no data is retrieved, no conversion takes place, but on the GET as data is retrieved a conversion takes place.
But...
When I change the browse to actually retrieve the data I then get a message length of 200 bytes returned by the browse, but when I issue the subsequent GET (msg under cursor), the message is returned to the program but the message data length is set to 400.
Can anyone explain whats going on?
I have options set on the browse as
MQGMO-ACCEPT-TRUNCATED-MSG
MQGMO-BROWSE-FIRST
MQGMO-LOCK
MQGMO-WAIT
MQGMO-CONVERT
and on the MQGET
MQGMO-ACCEPT-TRUNCATED-MSG
MQGMO-CONVERT
MQGMO-SYNCPOINT
MQGMO-MSG-UNDER-CURSOR |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Sep 26, 2008 6:29 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
This design (brose first, establish the required buffer, then get destructively) has been discussed here at length. The browse call is totally unnecessary. You are doing two calls when one will work perfectly.
Set your buffer to the maximum message length your application expects, then just do the destructive get.
_________________
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 |
|
|
| darrylcook |
| Posted: Fri Sep 26, 2008 6:37 am Post subject: |
|
|
Newbie
Joined: 19 Dec 2006
Posts: 6
|
Um, all very well if you are not restricted on what resources you can have, but this app sits in CICS and there will be many instances of the transaction running at any one time, so just allocating the max storage you MAY need is not sufficient here.
The real question is why do the two gets, one browse, one get return different data lengths. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Sep 26, 2008 6:48 am Post subject: Re: MQMessage Length |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Sep 26, 2008 7:03 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| ...but this app sits in CICS and there will be many instances of the transaction running at any one time |
You are writing an application with the dual intents of satisfying some business requirement ,AND performance tuning for the existing hardware/software environment.
I expected you to say you are doing this on a Windows or UNIX box. CICS, and MVS (z/OS), have the resources to manage hundreds or thousands of concurrent applications.
On any platform, your two API calls where one will do, doubles the requirement for processor cycles in order to reduce the demand for virtual storage - to perhaps reduce paging rates? Is it worth the trade-off?
What real problem are you addressing? Is there a problem?
_________________
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 |
|
|
| bower5932 |
| Posted: Fri Sep 26, 2008 7:55 am Post subject: |
|
|
Jedi Knight
Joined: 27 Aug 2001
Posts: 3023
Location: Dallas, TX, USA
|
| I'd certainly suggest going with a buffer size that would handle most of your requests. 200 bytes vs. 400 bytes doesn't seem worth the trouble (overhead) of going back a second time. 200 bytes vs. 2 million bytes might. |
|
| Back to top |
|
|
| dkeister |
| Posted: Fri Sep 26, 2008 8:15 am Post subject: |
|
|
Disciple
Joined: 25 Mar 2002
Posts: 184
Location: Purchase, New York
|
Actually, you do not have to browse.
Simply do the get with buffer set to value (e.g. 200 characters)
If the message is too large, you will get an error returned with MQRC 2080 (MQRC_TRUNCATED_MSG_FAILED).
And the data length parameter from the MQGET will contain the length of the message that you were attempting to get. Then use that value to set your buffer length and reissue an MQGET. You can then work with that message.
You can also remember that length and use it for subsequent MQGETs or reset it to some predetermined value, or just (joke) set some random value... As was pointed out to me in one of the other posts... memory is now cheap. But the extra logic is minimal and you would probably want the default message length to be able to handle most messages on the first try...
_________________
Dean Keister |
|
| 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
|
|
|
|
