| Author |
Message
|
| pnicolay |
 Posted: Fri Dec 03, 2010 2:14 am Post subject: |
 |
|
Apprentice
Joined: 29 Nov 2010
Posts: 26
|
No, I don't get the AMQ2058 anymore since I changed my new Queuemanager as follows...
| Code: |
connProps.Add(MQC.TRANSPORT_PROPERTY, MQC.TRANSPORT_MQSERIES_CLIENT);
MQManager = new MQQueueManager("MYQM", connProps); |
Now the C# client locks up on the new Queuemanager statement.
When using the amqsput/amqsputc I get the following...
| Code: |
C:\Program Files\IBM\WebSphere MQ\bin>amqsput MYTESTQ MYQM
Sample AMQSPUT0 start
MQCONN ended with reason code 2058
C:\Program Files\IBM\WebSphere MQ\bin>amqsputc MYTESTQ MYQM
Sample AMQSPUT0 start
(locks up) |
|
|
| Back to top |
|
 |
| ramires |
| Posted: Fri Dec 03, 2010 3:22 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
with this:
C:\Program Files\IBM\WebSphere MQ\bin>amqsput MYTESTQ MYQM
Sample AMQSPUT0 start
MQCONN ended with reason code 2058
you are trying to connect to a local queue manager MYQM and open a queue
MYTESTQ. You don't have a queue manager MYQM on that box, so the 2058 is expected.
To use the second option, amqsput client version, (amqsputc) you need an environment variable defining a channel to a queue manager, SET MQSERVER=something. Did you set MQSERVER? |
|
| Back to top |
|
|
| pnicolay |
| Posted: Fri Dec 03, 2010 3:31 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010
Posts: 26
|
| ramires wrote: |
| To use the second option, amqsput client version, (amqsputc) you need an environment variable defining a channel to a queue manager, SET MQSERVER=something. Did you set MQSERVER? |
No, not MQSERVER... but MQCHLLIB and MQCHLTAB. |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Dec 03, 2010 3:34 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| ok, thats also an option. Can you telnet to the qmgr host and port? |
|
| Back to top |
|
|
| pnicolay |
| Posted: Fri Dec 03, 2010 3:42 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010
Posts: 26
|
As stated various times before... it works fine using MQEnvironment (for specifying all the required parameters), as well as from a Java client program... so there's nothing wrong with the queuemanager or configuration.
It's only when I try to use a CDT that it goes wrong. |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Dec 03, 2010 3:52 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| Can you do a trace? Its only you using that CDT file? |
|
| Back to top |
|
|
| pnicolay |
| Posted: Fri Dec 03, 2010 4:03 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010
Posts: 26
|
I'm testing the C# stuff for someone elses project, for all the rest we use Java without a single issue.
I did a trace (total time 6 seconds) ... and got 241 MB... which I read quickly but personally I don't see anything that pops out as suspicious (except that 95% of the trace data is the same, probably due to that lock which I guess is an internal loop). |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Dec 03, 2010 4:18 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| I did a small test here, defining a client connection channel with an invalid port. Tested amqsputc and it also locks. In a trace its possible to find the host and port number. Can you find them? |
|
| Back to top |
|
|
| pnicolay |
| Posted: Fri Dec 03, 2010 4:43 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010
Posts: 26
|
I can find the following (quite some stuff omitted)...
| Code: |
MQCONNX 'MYQM'
xcsGetEnvironmentString[MQCHLLIB] = 'C:\test'
xcsGetEnvironmentString (rc=OK)
GetEnv[MQCHLLIB] = 'C:\test'
xcsGetEnvironmentString[MQCHLTAB] = 'AMQCLCHL.TAB'
xcsGetEnvironmentString (rc=OK)
GetEnv[MQCHLTAB] = 'AMQCLCHL.TAB'
xcsGetEnvironmentString[MQSERVER] = NULL
xcsGetEnvironmentString (rc=xecE_E_ENV_VAR_NOT_FOUND)
Using ChannelDefinitionDirectory / MQCHLLIB value of C:\test
Using ChannelDefinitionFile / MQCHLTAB value of AMQCLCHL.TAB
rrxGetFirstChannelDef
Data:-
53 59 53 54 45 4D 2E 44 45 46 2E 43 4C 4E 54 43 : SYSTEM.DEF.CLNTC
4F 4E 4E 20 : ONN |
... where the last part of rrxGetFirstChannelDef and that reference to SYSTEM.DEF.CLNTCONN keeps on repeating. To me this looks like a bug where he's not getting to the next entry in the CDT file ? |
|
| Back to top |
|
|
| ramires |
| Posted: Fri Dec 03, 2010 8:46 am Post subject: |
|
|
Knight
Joined: 24 Jun 2001
Posts: 523
Location: Portugal - Lisboa
|
| You can open a problem with IBM support. They will help you with diagnosis. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Fri Dec 03, 2010 9:41 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
I seem to remember seeing that the CHL TBLE still had problems in .NET at this version. Open a PMR and let us know how you fare. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Fri Dec 03, 2010 4:05 pm Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| pnicolay wrote: |
DEFINE CHANNEL ('TEST.CHL') CHLTYPE(CLNTCONN)
TRPTYPE(TCP)
CONNAME('MYHOSTNAME')
MAXMSGL(104857600)
QMNAME('MYQM') |
By not specifiying a port number in the CONNAME, MQ will default to 1414. Hence, that is why it is locking up. What is actually happening is the TCP call is timing out - probably 60 seconds is the default.
Update your CONNAME with the correct hostname and port number and things will work.
i.e.
| Code: |
DEFINE CHANNEL ('TEST.CHL') CHLTYPE(CLNTCONN)
TRPTYPE(TCP)
CONNAME('10.10.10.10(1417)')
MAXMSGL(104857600)
QMNAME('MYQMGRNAME') |
Also, CCDT files created on WMQ v7 cannot be used with WMQ v6 Clients. There were new keywords added for CLNTCONN channels in WMQ v7, so there is a updated structure. Hence, it is not backwards compatible. So, be very careful were you create the CCDT file.
Note: SupportPac MO72 is a great tool for dealing with CCDT files.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| pnicolay |
| Posted: Sat Dec 04, 2010 9:19 am Post subject: |
|
|
Apprentice
Joined: 29 Nov 2010
Posts: 26
|
| RogerLacroix wrote: |
| By not specifiying a port number in the CONNAME, MQ will default to 1414. Hence, that is why it is locking up. |
I know... but the listener is active on the default port. Also in the trace files I never see my client channel that should be used, instead it is looping on the first one. Looking on iSeries it is also clear that no TCP/IP connection attempt is made.
| RogerLacroix wrote: |
| Also, CCDT files created on WMQ v7 cannot be used with WMQ v6 Clients. |
The CCDT file is created by iSeries running WMQ v6... and used on Windows with WMQ v7 client.
Based on what I've seen in the trace... I guess this is a bug and will open a PMR with IBM next week. |
|
| Back to top |
|
|
| RogerLacroix |
| Posted: Sat Dec 04, 2010 10:24 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
| pnicolay wrote: |
| The CCDT file is created by iSeries running WMQ v6 |
How did you copy the file to Windows? Did you ftp as a "binary" file or ASCII file? It must be copied as a binary file.
| pnicolay wrote: |
When using the amqsput/amqsputc I get the following...
| Code: |
C:\Program Files\IBM\WebSphere MQ\bin>amqsput MYTESTQ MYQM
Sample AMQSPUT0 start
MQCONN ended with reason code 2058
C:\Program Files\IBM\WebSphere MQ\bin>amqsputc MYTESTQ MYQM
Sample AMQSPUT0 start
(locks up) |
|
You should download SupportPac MO72, create a CCDT file and then test it with amqsputc to make sure you have the correct parameters. It will take you 2 minutes to prove whether or not your connection parameters for the CCDT entry are correct. I use MO72 all the time, it is an awesome tool. 
amqsputc connects in "client mode" and amqsput connects in "bindings mode". Note: Bindings mode never uses a CCDT file.
Regards,
Roger Lacroix
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 04, 2010 11:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| RogerLacroix wrote: |
You should download SupportPac MO72, create a CCDT file and then test it with amqsputc to make sure you have the correct parameters. It will take you 2 minutes to prove whether or not your connection parameters for the CCDT entry are correct. I use MO72 all the time, it is an awesome tool.
amqsputc connects in "client mode" and amqsput connects in "bindings mode". Note: Bindings mode never uses a CCDT file.
Regards,
Roger Lacroix |
 MO72 has the added advantage that it also lets you create a CCDT table for a previous version of MQ. (check parameters). It is indeed an awesome tool 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
