Author |
Message
|
ramzi |
Posted: Tue May 13, 2008 3:29 am Post subject: Changing data length in a message exit |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
Hi all,
in the WebSphere MQ information center:
Quote: |
A message exit can modify the contents of the message and change its length. A change of length might be the result of compressing, decompressing, encrypting, or decrypting the message. It might also be the result of adding data to the message, or removing data from it. |
Let's say my exit add N Bytes of data to the message, my question is:
- should it also add N to the agent buffer length (*pAgentBufferLength += N) to prevent any AMQ9196 error ?
Quote: |
AMQ9196
Data length is larger than the agent buffer length.
Severity:
30 : Severe error
Explanation:
The data length <insert_1> set by exit <insert_3> is larger than the agent buffer length. The user exit returned data in the supplied agent buffer, but the length specified is greater than the length of the buffer. Message AMQ9190 is issued giving more details, and the channel stops.
Response:
Investigate why the user exit program set a data length that is not valid. Correct the error. |
Thanks !
Ramzi
Last edited by ramzi on Thu May 15, 2008 5:04 am; edited 1 time in total |
|
Back to top |
|
 |
Nigelg |
Posted: Tue May 13, 2008 7:55 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004 Posts: 1046
|
You can add data to the agent buffer up to the AgentBufferLength, and return the new length in DataLength. If you want to use more space than that, return MQXR2_USE_EXIT_BUFFER in ExitReason2. and return a pointer to the data in ExitBufferAddr; you still use DataLength to return the length of your own buffer. You should also set ExitBufferlength so that you know when the exit is next invoked how much space you have used.
This is rather an advanced topic. Please read the Intercomms manual carefully. _________________ MQSeries.net helps those who help themselves.. |
|
Back to top |
|
 |
ramzi |
Posted: Thu May 15, 2008 3:37 am Post subject: |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
Nigel, thanks for your answer.
Quote: |
You can add data to the agent buffer up to the AgentBufferLength, and return the new length in DataLength. If you want to use more space than that, return MQXR2_USE_EXIT_BUFFER in ExitReason2. and return a pointer to the data in ExitBufferAddr; you still use DataLength to return the length of your own buffer. You should also set ExitBufferlength so that you know when the exit is next invoked how much space you have used. |
In the exit, I will rather make sure that the additional data length + the original DataLength does not exceed AgentBufferLength.
Quote: |
This is rather an advanced topic. Please read the Intercomms manual carefully. |
Indeed, it looks very tricky. |
|
Back to top |
|
 |
ramzi |
Posted: Thu May 15, 2008 9:47 am Post subject: |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
|
Back to top |
|
 |
ramzi |
Posted: Fri May 16, 2008 5:17 am Post subject: |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
Quote: |
Agent buffer
For a channel message exit, on invocation of the exit this contains:
* The transmission queue header (MQXQH), which includes the message descriptor (which itself contains the context information for the message), immediately followed by
* The message data
If the message is to proceed, the exit can do one of the following:
* Leave the contents of the buffer untouched
* Modify the contents in place (returning the new length of the data in DataLength; this must not be greater then AgentBufferLength)
* Copy the contents to the ExitBufferAddr, making any required changes
|
Let's assume that I add data to the message payload, making DataLength greater than AgentBufferLength.
This mean that I will need to copy the message into a new allocated buffer, and return its address in ExitBufferAddr.
- Is the allocated memory for this exit buffer freed by the Exit caller ?
- If not, "where" (in the exit code) should I free the memory allocated for this Exit managed buffer ?
- Please confirm that making a copy of the message is mandatory before adding some data to it and use ExitBufferAddr
- In other words, please confirm that ExitBufferAddr must not contain a pointer to any AgentBuffer data. It must be a pointer to a copy (or modified copy) of these data.
- Please correct me if I'm wrong or not precise enough
Thanks for your answers. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Fri May 16, 2008 6:59 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
|
Back to top |
|
 |
ramzi |
Posted: Mon May 19, 2008 12:39 pm Post subject: |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
Hi Roger,
your post should be moved in that forum.
Do you have any thoughts on memory management of an ExitBuffer ? |
|
Back to top |
|
 |
RogerLacroix |
Posted: Mon May 19, 2008 7:20 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hi,
ramzi wrote: |
Do you have any thoughts on memory management of an ExitBuffer ? |
Yes. I have spent many, many years and lots of blood, sweat & tears gaining that knowledge.
Above, Nigelg gave you some very good information (which is what I would have said). Use the information that Nigelg gave you and research manuals, web, etc. to design a solution that will work for you.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
ramzi |
Posted: Tue May 20, 2008 12:38 am Post subject: |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
Hi Roger,
I did some research and found a great exemple on memory management of an ExitBuffer. This is the cryptexit from the IBM SG24-5306 redbook:
http://www.mqseries.net/phpBB2/viewtopic.php?t=39178
(look for cryptexit at the bottom of page).
I guess everybody here already knew about it  |
|
Back to top |
|
 |
Vitor |
Posted: Tue May 20, 2008 12:42 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
ramzi wrote: |
I guess everybody here already knew about it  |
Possibly.
Very few of us would attempt to use the knowledge unless we were really, really desperate and an exit was the only answer. Absolutely the only answer.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
RogerLacroix |
Posted: Tue May 20, 2008 8:24 pm Post subject: |
|
|
 Jedi Knight
Joined: 15 May 2001 Posts: 3264 Location: London, ON Canada
|
Hi,
ramzi wrote: |
I guess everybody here already knew about it  |
Not really. I've been doing exit / plugin programming on the mainframe & distributed platforms since before MQ was released. It takes a long time to gain a true understanding of multi-threaded parrallel programming concepts.
You think MQ exit programming is tough, try doing it in assembler and having the code walk-through many control-blocks on z/OS.
Remember the following points:
- Don't rely on the variable to be what you think it is. MCA is threaded, hence, many MCA thread and will be executing at the same time. Each thread must maintain its own context.
- What you create, you must delete/free. Even if you get an error, you must cleanup.
- Memory leaks will be your biggest enemy.
Regards,
Roger Lacroix
Capitalware Inc. _________________ Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
Back to top |
|
 |
David.Partridge |
Posted: Tue May 20, 2008 11:33 pm Post subject: |
|
|
 Master
Joined: 28 Jun 2001 Posts: 249
|
> try doing it in assembler
Don't all real programmers code on the bare metal in machine code - assembler's are for wimps
Fully re-entrant code with serialisation where necessary - only way to fly - if you make a discipline of always writing your code with the possibility it will need to run with those requirements, you'll have far fewer contact admin surprises. It's no harder to do it that way once you understand how to do it, and can even result in more efficient code.
If using C or C++, make extensive use of Lint or similar, and turn on the highest warning level your compiler can go to. _________________ Cheers,
David C. Partridge |
|
Back to top |
|
 |
Vitor |
Posted: Wed May 21, 2008 12:28 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
RogerLacroix wrote: |
You think MQ exit programming is tough, try doing it in assembler and having the code walk-through many control-blocks on z/OS.
|
I'm having flashbacks and nightmares simultaniously!  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
Vitor |
Posted: Wed May 21, 2008 12:31 am Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
David.Partridge wrote: |
Don't all real programmers code on the bare metal in machine code - assembler's are for wimps
|
You're scaring me....
And if you're the David Partridge who worked at Peel Park late 1990s, refreshingly unchanged.
If not, just refreshing.  _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
ramzi |
Posted: Fri May 23, 2008 8:52 am Post subject: |
|
|
 Novice
Joined: 16 Aug 2004 Posts: 19 Location: France
|
Hello again !
How is the length of an AgentBuffer set by WMQ?
I guess that if the system hosting the QM is in a heavy load situation, AgentBufferLength will be equal to DataLength when the exit is called. No additional space.
Then the use of an ExitBuffer will be mandatory to add data.
Otherwise there are good chances that AgentBufferLength will be > than DataLength.
According to the documentation:
Quote: |
AgentBufferLength (MQLONG) – input
Length of agent buffer.
This can be greater than DataLength on invocation.
For channel message, send, and receive exits, any unused space on invocation can be used by the exit to expand the data in place. If this is done, the DataLength parameter must be set appropriately by the exit. |
Is there any case where AgentBufferLength < DataLength ? |
|
Back to top |
|
 |
|