| Author |
Message
|
| fishlips |
 Posted: Fri Mar 02, 2012 5:23 am Post subject: |
 |
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| fishlips wrote: |
could it be perhaps:
| Code: |
- WMQ_MSG_BATCH_SIZE
- WMQ_MAX_BUFFER_SIZE
|
Any ideas? Maybe I'll just try setting them to 52,428,800 ? |
This didn't work.
Last edited by fishlips on Fri Mar 02, 2012 5:27 am; edited 1 time in total |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Fri Mar 02, 2012 5:24 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| fishlips wrote: |
| Are there changes I need to make to the code, in order to read messages with the "MQHRF2" format? |
Yes, or if you're using WMQv7 you need to cater for them; v7 introduced message properties which replaced the MQRFH2 header. Much discussion on this in the forum. |
But also to be clear, you're not using the .NET api, you're using XMS (which is no longer a supportpac and now built into the product).
And XMS should handle the RFH2/properties without change to your code. |
|
| Back to top |
|
|
| fishlips |
| Posted: Fri Mar 02, 2012 5:30 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| Vitor wrote: |
you're using XMS (which is no longer a supportpac and now built into the product).
And XMS should handle the RFH2/properties without change to your code. |
Quite right, thanks for clarifying that - good point.
So, let me phrase this as clearly as I can - How, using the XMS API for .NET, can I alter my connection factory to accept larger messages? |
|
| Back to top |
|
|
| fishlips |
| Posted: Fri Mar 02, 2012 5:46 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
Ok, a little more progress. I downloaded the first message on the live queue. It's 4.27MB.
This was too big to upload onto my "test" queue, so I had to increase the max message size on the queue. I did this. I then uploaded the file I'd downloaded from the live queue onto the "test" queue.
My code now fails with the same message, which means the fault is probably within my code - as you say - I need to alter a setting somewhere to permit the downloading of larger DATAGRAM messages.
Any ideas how I do this? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 02, 2012 5:46 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fishlips wrote: |
| So, let me phrase this as clearly as I can - How, using the XMS API for .NET, can I alter my connection factory to accept larger messages? |
In a quick review of the docs for XMS, it seems the most straight forward way is to remove the settings you have for hostname, channel, and port, and set XMSC_WMQ_QUEUE_MANAGER and XMSC_WMQ_CCDTURL.
The CCDTURL points to the client channel table your MQ admin will create, and the WMQ_QUEUE_MANAGER holds the name that matches the QMNAME on the correct channel in the CCDT. |
|
| Back to top |
|
|
| fishlips |
| Posted: Fri Mar 02, 2012 5:52 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
There appears to be a channel in the Channels list, called CLIENT.[QUEUE MANAGER NAME], is this the client channel?
If so, do you know how the API will expect the "XMSC_WMQ_CCDTURL" to look?
The fact that it ends in URL makes it sound as though it will be expecting a specific format? In the same was as the queue name (destination URI) had to specified in the format of "queue:///[queue name]"
Any ideas on format? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Mar 02, 2012 5:56 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
It's a pointer to a file.
So it will be something like "file://root/folder/filename".
If you do a google search for CCDTURL, you should find lots of examples and discussion on using this property with JMS. It's the same property with the same meaning in XMS.
Again, this is a pointer to a file that your MQ admin will create and provide to you. You don't appear to be the MQ admin, you appear to be a developer. If there is *anyone* in the role of MQ Admin at your shop or customer, you should go talk to them in person ASAP about using client channel tables. |
|
| Back to top |
|
|
| fishlips |
| Posted: Mon Mar 05, 2012 2:11 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
| fishlips wrote: |
| Vitor wrote: |
you're using XMS (which is no longer a supportpac and now built into the product).
And XMS should handle the RFH2/properties without change to your code. |
Quite right, thanks for clarifying that - good point.
So, let me phrase this as clearly as I can - How, using the XMS API for .NET, can I alter my connection factory to accept larger messages? |
Ok, well I've had a good scan through the list of available properties for the ConnectionFactory object, and I'm sure as I can be that there isn't a property I can set to alter the maximuum message size. |
|
| Back to top |
|
|
| fishlips |
| Posted: Mon Mar 05, 2012 2:27 am Post subject: |
|
|
Apprentice
Joined: 21 Dec 2011
Posts: 36
|
In fact, I can't see a setting in the entire XMS Definition that can alter the MAXMSG size on any object. Any ideas? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Mar 05, 2012 2:48 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| fishlips wrote: |
In fact, I can't see a setting in the entire XMS Definition that can alter the MAXMSG size on any object. Any ideas? |
Yes.
You need to construct a client channel definition table, with the assistance of your MQ administrator.
You then need to put this file in a known location on the box running the XMS code.
You then need to construct a file:// url that points to this CCDT file and set this value into the aforementioned CCDTURL property of the connection factory.
The maxmsgln will be set on the client channel definition inside the CCDT file. |
|
| Back to top |
|
|
|
|
