| Author |
Message
|
| shogan2003 |
 Posted: Fri May 21, 2004 10:46 am Post subject: MQSeries client chl tables : Calling MQ emergency services! |
 |
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
I've searched this site extensively on the helpful suggestions given to those in my situation of using MQCHLLIB & MQCHLTAB instead of MQSERVER. I'm trying to be consistent with the advice imparted on related threads.
I am getting 2058 error when I run the client code.
Maybe some obvious mistake will be noted in the steps I've followed, as set out below :
1. I created a client connection channel SYSTEM.DEF.SVRCONN to match the server channel of the same name.
2. The server is on Solaris and I noted that the file AMQCLCHL.TAB in the queue manager's @ipcc directory was updated.
3. I ftp'd that file across to the client machine (win-2K). In a command window I specified values for MQCHLLIB & MQCHLTAB. I also made sure to set MQSERVER= blank so that it wouldn't take precedence over those env vars.
4. I am aware that some docs state that these env vars should be set on the server. Is that what I should do ?
5. I stopped and restarted the queue manager; I even killed then restarted the runmqlsr listener.
6. I run 'cscript MQGet.vbs' in the command-window but the complaint returned is
-------------------------------------------------------------------------------------
H:\000.Middleware\MQSeries\vbs\MQGet.vbs(133, 5) mqax200: MQAX200.MQQueueManager
::AccessQueue CompletionCode = 2, ReasonCode = 2058, ReasonName = MQRC_Q_MGR_NAME_ERROR
-------------------------------------------------------------------------------------
I haven't altered the vbs code, which previously worked for messages < 4Mb when MQSERVER was specified. Is the accessqueue methid implicitly an MQCONN. If so, would an MQCONN require MQSERVER ?
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
 |
| JasonE |
| Posted: Fri May 21, 2004 10:54 am Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
Your MQCONN specifies a QMgr name. This is looked up in the channel table, we find a channel definition, and use it. Assuming we can connect to the other end, we then check that the other end is the qmgr you specifried.
Are you sure :
1. mqchllib and mqchltab point to the correct channel table
(Look at the trace  or perhaps filemon (www.sysinternals.com) to see what is being accessed)
2. Your MQCONN qmgr name matches to a CLNTCONN channel with QMName specified
3. Your MQCONN qmgr name is the same as the remote end
(If you dont specify a name in the mqconn, then the qmname in the clntconn must also be blank)
And if the worst comes to the worst, take a trace - It's obvious from the trace 
(Now, why am I doing this at nearly 8pm on a Fri from home...!) |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 21, 2004 10:57 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Quote: |
I am aware that some docs state that these env vars should be set on the server. Is that what I should do ?
|
Either at the system level or in a dos window is fine. Whatever you set in the dos window will override the system variable for the dos session only.
| Quote: |
I stopped and restarted the queue manager; I even killed then restarted the runmqlsr listener.
|
Totally unnecessary.
My guess is that you defined the CLNTCONN channel with a QM name specified, and your code is not specifying the QM name on the CONN call. Or you defined the CLNTCONN channel without a QM name, and your app is supplying the QM name. This will fail also, even if you give the right QM name.
The value supplied in the MQCONN call must match the value in the channel table when it comes to the QM name.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Fri May 21, 2004 11:15 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
Thanks for the prompt replies. For anyone interested, here are the client channel and the code extract. I shall re-read the suggestions.
===============================================
CHANNEL(SYSTEM.DEF.SVRCONN) CHLTYPE(CLNTCONN)
TRPTYPE(TCP) DESCR( )
QMNAME(DEV.HUB.01) MODENAME( )
TPNAME( ) SCYEXIT( )
MAXMSGL(104857600) SCYDATA( )
USERID( ) PASSWORD( )
CONNAME(172.21.13.20) HBINT(300)
SSLCIPH( ) LOCLADDR( )
ALTDATE(2004-05-21) ALTTIME(18.39.56)
SSLPEER()
SENDEXIT( )
RCVEXIT( )
SENDDATA( )
RCVDATA( )
===============================================
And the code specifies the queue manager.
Set MQSess = CreateObject("MQAX200.MQSession")
Set qMgr = CreateObject("MQAX200.MQQueueManager")
'MQSess = Server.CreateObject("MQAX200.MQQueueManager")
set Queue = qMgr.AccessQueue("DEV.HUB.ABC.IN", 2 , "DEV.HUB.01") ' 2=MQOO_INPUT_SHARED
set msgGet = CreateObject("MQAX200.MQMessage")
'msgGet.MessageId = msgPut.MessageId
set gmo = MQSess.AccessGetMessageOptions()
'gmo.Options = 64 ' 0x400 : MQGMO_ACCEPT_TRUNCATED_MSG'
gmo.Options = 65536 ' 0x10000 : MQGMO_ACCEPT_COMPLETE_MSG'
Queue.Get msgGet
get_msg = msgGet.ReadString(msgGet.MessageLength)
msgLen = len(get_msg)
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Fri May 21, 2004 11:23 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
I've never used tracing before...! At least not purely for MQSeries
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri May 21, 2004 11:25 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
your channel has the QM name in it, but your code does not specify the QM name when it creates the QM object.
The 2 gotta match, otherwise you get no hit in the table and you get the error.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Fri May 21, 2004 11:40 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
Ta for last piece of advice
I ran strmqtrc on the client and here's a crucial extract from the generated..now let's see if that is becaue of the incomplete info I've specified in the vbs code ?
RetCode = 20009516, rc1 = 1001, rc2 = 0, Comment1 = 'h:\adapters\AMQCLCHL.TAB', Comment2 = '', Comment3= '', File= 'F:\CSD\BUILD\SOURCE\lib\client\amqrcdfa.c', Line= '1302'
00000292 20:35:23.567068 2024.1 ----}! rrxError (rc=rrcE_FILE_ERROR)
00000293 20:35:23.568516 2024.1 ---}! rrxGetNextChannelDef (rc=rrcE_FILE_ERROR)
00000294 20:35:23.568938 2024.1 ---{ rrxCloseChannelDef
00000295 20:35:23.569031 2024.1 ----{ cccFreeMem
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Fri May 21, 2004 11:44 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
And here's the code again...I do really want to implement your advice but it isn't clear to me where (else) should I specify the queue manager in the code . Duh..doh ?
strQmgr = "DEV.HUB.01"
strQ = "DEV.HUB.ABC.IN"
Set MQSess = CreateObject("MQAX200.MQSession")
Set qMgr = CreateObject("MQAX200.MQQueueManager")
'MQSess = Server.CreateObject("MQAX200.MQQueueManager")
set Queue = qMgr.AccessQueue("DEV.HUB.ABC.IN", 2 , "DEV.HUB.01") ' 2=MQOO_INPUT_SHARED
set msgGet = CreateObject("MQAX200.MQMessage")
'msgGet.MessageId = msgPut.MessageId
set gmo = MQSess.AccessGetMessageOptions()
'gmo.Options = 64 ' 0x400 : MQGMO_ACCEPT_TRUNCATED_MSG'
gmo.Options = 65536 ' 0x10000 : MQGMO_ACCEPT_COMPLETE_MSG'
Queue.Get msgGet
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| JasonE |
| Posted: Fri May 21, 2004 1:42 pm Post subject: |
|
|
Grand Master
Joined: 03 Nov 2003
Posts: 1220
Location: Hursley
|
| I think (not at work, cant check) rather than createobject the mqqueuemanager object, call the mqsession object accessqueuemanager method passing the qmgr name which will return an mqqueuemanager object constructed with than qmgr name |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Sat May 22, 2004 12:18 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
Hi gents
I'm definitely going to contribute to this site. So many generous and leared folk. And such patienc. I take back all I said about 'real' developers.
I think it's a problem concerning the client channel table. The trace extract below finds the file but there's something amiss, maybe with the channel definition ? Will check the table once again.
By the way, the trace below was run against an attempt to run 'amqsputc'. So my question is : does amqsputc ONLY work with env varMQSERVER ?
I assume someone has got vbscrips running on MQSeries client machines to work with the client channel table definition, niot just with MQSERVER.
Sample of vbscript working with MQSeries can be found, otherwise I wouldn't have got to this stage, but any samples welcome.
Please email me. SeanH
------------------------------------------------------------------------------------
GetEnv[MQCHLTAB] = 'AMQCLCHL.TAB'
----} xcsGetMem (rc=OK)
---} cccGetMem (rc=OK)
---{ rrxGetFirstChannelDef
---} rrxGetFirstChannelDef (rc=OK)
---{ rrxGetNextChannelDef
----{ rrxError
RetCode = 20009516, rc1 = 1001, rc2 = 0, Comment1 = 'h:\adapters\AMQCLCHL.TAB', Comment2 = '', Comment3= '', File= 'F:\CSD\BUILD\SOURCE\lib\client\amqrcdfa.c', Line= '1302'
----}! rrxError (rc=rrcE_FILE_ERROR)
---}! rrxGetNextChannelDef (rc=rrcE_FILE_ERROR)
---{ rrxCloseChannelDef
------------------------------------------------------------------------------------
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Sat May 22, 2004 12:42 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
Defined two new channels with the name TEST.CONN, as detailed below.
Created a listener process runmqlsr on the server machine against port 1416.
Still encountering 2058 error. How can I specify that TEST.CONN should be used ?
By the way, I couldn't find a way of deleting the old client conn channel SYSTEM.DEF.SVRCONN. I I invoked DELETE CHL(SYSTEM.DEF.SVRCONN) it only removes the channel of type SVRCONN.
===============================================
CHANNEL(TEST.CONN) CHLTYPE(SVRCONN)
TRPTYPE(TCP) DESCR()
SCYEXIT() MAXMSGL(104857600)
SCYDATA() HBINT(300)
SSLCIPH() SSLCAUTH(REQUIRED)
MCAUSER(mqm) ALTDATE(2004-05-22)
ALTTIME(09.32.54) SSLPEER()
SENDEXIT( )
RCVEXIT( )
SENDDATA( )
RCVDATA( )
AMQ8414: Display Channel details.
CHANNEL(TEST.CONN) CHLTYPE(CLNTCONN)
TRPTYPE(TCP) DESCR( )
QMNAME(DEV.HUB.01) MODENAME( )
TPNAME( ) SCYEXIT( )
MAXMSGL(104857600) SCYDATA( )
USERID( ) PASSWORD( )
CONNAME(172.21.13.20(1416)) HBINT(300)
SSLCIPH( ) LOCLADDR( )
ALTDATE(2004-05-22) ALTTIME(09.34.26)
SSLPEER()
SENDEXIT( )
RCVEXIT( )
SENDDATA( )
RCVDATA( )
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Sat May 22, 2004 1:20 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
Any ideas on what I am doing wrong ?
--------------------------------------------------------------------------------------
The old error I encountered in the TRC file was matched by entries in the AMQERR01.LOG on the client machine :
returned error code 1001 for h:\adapters\AMCLCHL.TAB
* * * * *
I am now using another queue manager and & channels TEST.CONN twice (of type SVRCONN & CLTCONN) on that qmgr, using port 1415 and killed the listener on the first qmgr. I've ftp'd over the clnt connection table to the client machine (overwriting the file) and checked that the file only contains references to the second qmgr.
The behaviour now for amqsputc and my piece vbscript is that they just die without indicating an error on screen.
The trace does not reveal any errors. The extract below shows that an MQCONNX call is made. Am assuming there is still a missing piece to the jigsaw. Like all jigsaw puzzles, there's always a piece which slips behind the sofa.
-------------------------------------------------------------------------------------
MQCONNX ''
----{ MCSGetDefaultThreadModel
No thread model in environment or registry, use automatic (MTS) [pthconn=0 hconn=-999 hobj=-998 (-998) cc=-997 rc=-996]
----} MCSGetDefaultThreadModel (rc=OK)
: : : : :
GetEnv[MQCHLLIB] = 'h:\adapters'
Using MQCHLLIB env var of h:\adapters
GetEnv[MQCHLTAB] = 'AMQCLCHL.TAB'
Using env var MQCHLTAB for name of channel file of AMQCLCHL.TAB
----{ cccGetMem
-----{ xcsGetMem
component:20 function:0 length:316 options:0 *pointer:00E04D90
-----} xcsGetMem (rc=OK)
----} cccGetMem (rc=OK)
---} rrxOpenChannelDef (rc=OK)
---{ cccGetMem
----{ xcsGetMem
component:20 function:131 length:2400 options:0 *pointer:00BB9018
----} xcsGetMem (rc=OK)
---} cccGetMem (rc=OK)
---{ rrxGetFirstChannelDef
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Sat May 22, 2004 5:14 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| shogan2003 wrote: |
By the way, I couldn't find a way of deleting the old client conn channel SYSTEM.DEF.SVRCONN. I I invoked DELETE CHL(SYSTEM.DEF.SVRCONN) it only removes the channel of type SVRCONN.
|
Usually the channel commands take a CHLTYPE() argument.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| shogan2003 |
| Posted: Sat May 22, 2004 5:49 am Post subject: |
|
|
Centurion
Joined: 03 Jul 2003
Posts: 133
Location: London
|
I had tried DELETE CHL(..) CHLTYPE(CLTNCONN).
I'll try to connect via tables again tomorrow. Off to get some sunshine now and watch the demonstration.
_________________
MQSI2 certified specialist
MQSeries certified specialist |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Sat May 22, 2004 2:49 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
A Client Channel table is searched alphabetically by channel name, looking at channels that have the same QM name (or lack thereof) supplied in the MQCONN call.
Since you are supplying no QM name in your MQCONN call, and all your CLNTCONN channels in the table do have a QM name, none are even attempted to be used, and you get the 2059.
So, if it were me, the easiest thing to do is create a CLNTCONN channel with no QM name specified, since it seems that your program finds it easier to issue the MQCONN call without a QM name.
Maybe create one called MY.CLIENT.CHANNEL.A1 (with no QM name) that points at server 1. Then create another one called MY.CLIENT.CHANNEL.A2 (with no QM name), that points at server 2. The assumption here is that server1 is your primary server you want to go to first, and if it is down, you want to go to server2. And you want to connect to the default QM on either server (since you are not giving a QM name).
This is the way client channel tables are most powerful. You have 2 or more servers, each with a default QM that has all the same queues. You create channels alphabetically (with no QM name) in the order you want to attempt to connect. Try server1, if not available, try server2, etc.
I suppose you could also code QM1 in your MQCONN call, create channels in a channel table all with QM1 in the def, and then have multiple backup servers each with the same named QM. But that kinda breaks the rule of their should be only one QM in your system with a particular name. And what if you send a request from QM1a expecting a reply? How will it know to come back to QM1a, and not QM1b. Nah, if you are gonna use channel tables to their fullest, use the prior paragraph's method.
As far as deleting the other CLNTCONN channels, I don't know why you are having the problem. Its the same as deleting any other MQ object. Probably just some typo in your syntax.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
