| Author |
Message
|
| LordGladstone |
 Posted: Tue Jun 26, 2007 3:28 am Post subject: MQRC_DATA_LENGTH_ERROR |
 |
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
Websphere MQ 5.3 for Windows.
I have a client application that is trying to do an MQPUT and is failing with RC 2010 when the input data exceeds 4MB.
The client channel is defined maxmsgl 100MB
The information I have found suggests using client channel table to define the client connection channel instead of using MQSERVER
I tried
defining a client connection using MQ explorer, with the same name as the client channel, and setting maxmsgl to 100MB
setting mqchltab and mqchllib environment variables
but get the same error.
When I took out the MQSERVER env variable, the applcation was not able to connect to the queue manager |
|
| Back to top |
|
 |
| Vitor |
| Posted: Tue Jun 26, 2007 3:39 am Post subject: Re: MQRC_DATA_LENGTH_ERROR |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| LordGladstone wrote: |
| When I took out the MQSERVER env variable, the applcation was not able to connect to the queue manager |
This implies there's a problem with the channel table environment variables & it can't see the table. Check these first.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| LordGladstone |
| Posted: Tue Jun 26, 2007 3:53 am Post subject: |
|
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
| The env variables look OK, but I have them in user rather than system. Is this correct ? |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2007 4:10 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| LordGladstone wrote: |
| The env variables look OK, but I have them in user rather than system. Is this correct ? |
It depends how your application is being run. If you can't connect then it certainly sounds a lot like Windoze is not applying them to the environment in which the application is opperating.
(You may notice a slight bias here against a well known graphical opperating system!)
Put the TAB file in the default location and be certain MQSERVER is not defined (MQSERVER outranks the table). Then try and connect, either with your application or AMQSPUTC. IF you can't connect, there's a problem with the tab file.
If that's not possibe, try wrapping the test application of your choice in a script which sets the variables.
Once you've got that working, try your large message again.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| LordGladstone |
| Posted: Tue Jun 26, 2007 4:36 am Post subject: |
|
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
With the MQSERVER variable removed, I have just tried the following
C:\Documents and Settings\mqmadm>set MQCHLLIB=E:\Program Files\IBM\WebSphere MQ\
Qmgrs\Q!ELABAP38!1\@ipcc
C:\Documents and Settings\mqmadm>set MQCHLTAB=AMQCLCHL.TAB
C:\Documents and Settings\mqmadm>amqsputc QL.TEMP
Sample AMQSPUT0 start
MQCONN ended with reason code 2059
Q.ELABAP38.1 is the default queue manager
The client connection I defined has a conname of localhost(1414)
If there is a problem with the channel table, how can I rectify it ?
[/img] |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Jun 26, 2007 4:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Usually this means that there isn't a channel that has a matching qmgr name to the qmgr name that you specified.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2007 4:46 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
1) Search the forum for 2059. It's probably the most common reason code and strategies for fixing it have been discussed endlessly. But:
2) If you can connect via MQSERVER but not with the table, review the commands you used to create the client table. Ensure there are no typos (especially names), that sort of thing. Many 2059s are caused by network & listener problems, all of which will not be the case is MQSERVER allows connection.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| LordGladstone |
| Posted: Tue Jun 26, 2007 4:56 am Post subject: |
|
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
| I didnt do anything to create the channel table - it just got created when the queue manager was created |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2007 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| LordGladstone wrote: |
| I didnt do anything to create the channel table - it just got created when the queue manager was created |
I think I've spotted your problem! 
The one that's created with the queue manager contains only the default objects (the channel equivalent of the SYSTEM objects if you like). It can't contain anything specific because it can't know how you're going to configure the queue manager (the listener port you're going to use for example).
Use the instructions in the Clients manual to create a table entry for your queue manager & try again.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| LordGladstone |
| Posted: Tue Jun 26, 2007 5:20 am Post subject: |
|
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
| But when I browse the table I can see my client channels already in there |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2007 6:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| LordGladstone wrote: |
| But when I browse the table I can see my client channels already in there |
Then it must be working then....
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2007 6:20 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| LordGladstone wrote: |
| But when I browse the table I can see my client channels already in there |
So what you're saying is that you've taken any action to specify queue manager specific information in the client table but the queue manager has managed to propogate this from it's internal configuration, creating a working client channel table.
I put it to you that you can see your SVRCONN channel in the tab file. If you consult the manual I referred you to, you'll see this is not all the information needed to establish a connection. Critically (as jefflowrey points out) it does not contain a queue manager name.
Unless this information is indeed present, which indicates the file is corrupt (possible if you're been browsing it with the wrong kind of editor that's messed with the binary information) and needs to be recreated.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| LordGladstone |
| Posted: Tue Jun 26, 2007 6:43 am Post subject: |
|
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
Well I dont think the SVRCONN channel is there, but the client conn is there, with the correct queue manager name
I havent told you yet that the client application is running on the same wndows machine as the server queue manager - I dont know if that makes a difference.
This wasnt working before and after I browsed the table file (using notepad) so I doubt it is corrupted |
|
| Back to top |
|
|
| Vitor |
| Posted: Tue Jun 26, 2007 6:49 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| LordGladstone wrote: |
I havent told you yet that the client application is running on the same wndows machine as the server queue manager - I dont know if that makes a difference.
|
Makes not a scrap of difference, except to eliminate a possible problem with the physical network. 
Clients run perfectly happily on the same machine as a server; they're blind to the route the connection is taking.
So you've got a client table with a valid client connection despite not taking any action to define it because you can see the definition. The file has not been corrupted by any action of yours, and you can eliminate server side connection errors because you can establish a connection using the MQSERVER method. You can also eliminate hard "cable" errors, as it's on the same machine.
I repeat my earlier advice to search the forum for 2059. This will give you an insight into the various reasons for this code, happily many of these you will be able to eliminate for the reasons I outline above.
Good Hunting! 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| LordGladstone |
| Posted: Tue Jun 26, 2007 7:01 am Post subject: |
|
|
Novice
Joined: 07 Jun 2006
Posts: 19
|
I now think that Iam having a problem reading the table, because I have noticed that when the amqsputc fails, I get this error:
26/06/2007 15:59:05
AMQ9519: Channel 'SYSTEM.DEF.CLNTCONN' not found.
EXPLANATION:
The requested operation failed because the program could not find a definition
of channel 'SYSTEM.DEF.CLNTCONN'.
ACTION:
Check that the name is specified correctly and the channel definition is
available.
even though this channel is defined and is present in the channel table |
|
| Back to top |
|
|
|
|
