| Author |
Message
|
| BBM |
 Posted: Fri Jun 20, 2008 6:00 am Post subject: Use of asterisk (*) in client channel connections |
 |
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi,
We are looking to migrate to a new queue manager on Z/OS and would like to use qmgr aliasing on the new queue manager to receive messages addressed with the old qmgr's details.
Apparently MQ clients have a problem with this arrangement and the use of an * preceding the qmgr name in the MQCONN call is necessary for the client to ignore the fact that it's connecting to a qmgr that is not the same name as in the MQCONN call.
For example connecting to qmgr TEST2 with MQCONN specified as TEST1 - you should use MCONN with *TEST1 which would then not care what the true qmgr name is.
The problem we have is that we cannot get this to work - it throws us 2058 messages.
If anyone has any ideas we'd appreciate it, as the documentation is a bit thin on this topic.
Cheers
BBM |
|
| Back to top |
|
 |
| bruce2359 |
| Posted: Fri Jun 20, 2008 1:00 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Do you mean that you are upgrading WMQ on z/OS?
Or you are moving a qmgr from Win/UNIX to z/OS?
Or that you are creating a new qmgr on z/OS, and want it to respond to incoming WMQ clients?
MQCONN '*any' allows WMQ clients to connect to any of those qmgrs in the client channel table with QMNAMEs of any. Are you trying this technique for the first time? Did it work before? What did you change?
_________________
I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Fri Jun 20, 2008 1:23 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Works like this for me:
| Code: |
X:\>amqscnxc -c MyChannelName -x TheMainframe(1415) *MQT1
Sample AMQSCNXC start
Connecting to queue manager *MQT1
using the server connection channel MyChannelName
on connection name TheMainframe(1415).
Connection established to queue manager MQT2
Sample AMQSCNXC end
X:\>amqscnxc -c MyChannelName -x TheMainframe(1415) *
Sample AMQSCNXC start
Connecting to queue manager *
using the server connection channel MyChannelName
on connection name TheMainframe(1415).
Connection established to queue manager MQT2
Sample AMQSCNXC end
X:\>amqscnxc -c MyChannelName -x TheMainframe(1415) MQT2*
Sample AMQSCNXC start
Connecting to queue manager MQT2*
using the server connection channel MyChannelName
on connection name TheMainframe(1415).
MQCONNX ended with reason code 2058
X:\>
|
The actual QM name is MQT2 in the above test. Seems to work as expected. Try the same test (use amqscnxc) to remove any complications that MQ Client Channel Tables introduce.
_________________
Peter Potkay
Keep Calm and MQ On
Last edited by PeterPotkay on Mon Jun 23, 2008 8:12 am; edited 1 time in total |
|
| Back to top |
|
|
| BBM |
| Posted: Mon Jun 23, 2008 3:46 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Great thanks for that - will go away and experiment with amqscnxc.
We are not using client channel tables, just the MQSERVER variable, so i'm a little confused as to why it's failing.
Bruce - we are migrating a queue manager (slowly) to z/OS and are migrating the clients in stages from a Windows queue manager to the new z/OS queue manager.
We are trying to reduce the impact to the clients to almost zero, ie we are using a DNS push to redirect them on migration day. Clearly we will need to ask them to reconfigure with the asterisk if they are to connect to the new queue manager without issue. We are going to move the clients to using the asterisk ahead of time rather than on migration day, hence we are not using the actual z/OS queue manager name - which incidenatlly is not yet known.
I'll report bacck with my findings...
Cheers
BBM |
|
| Back to top |
|
|
| BBM |
| Posted: Mon Jun 23, 2008 5:23 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi - we have the scenario working with amqscnxc.
One more question in the examples you gave above Peter I'm confused that you were able to specify the incorrect port and still connect to the queue manager:
X:\>amqscnxc -c MyChannelName -x TheMainframe(1414) *MQT1
Sample AMQSCNXC start
Connecting to queue manager *MQT1
using the server connection channel MyChannelName
on connection name TheMainframe(1415).
Connection established to queue manager MQT2
Sample AMQSCNXC end
Is this normal behaviour as I couldn't reproduce this.
thanks
BBM |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Mon Jun 23, 2008 8:12 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
Ignore that. I changed the actual names and ports after a I copy and pasted. I fixed my original post.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| BBM |
| Posted: Tue Jul 08, 2008 2:04 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
So my work with the * continues and we've run into another issue with one of our Java clients.
We are getting the following error:
Failed to start source credit.swift.response - MQJMS1017: non-local MQ queue not valid for receiving or browsing
We've checked that the queues are configured correctly and if we change the queue manager parameter back to QIUKLMB from *QIUKLMB the client starts working again.
In short, the only thing we have changed is adding the asterisk and we get the above error which doesn't really make sense to us.
If anyone has any ideas it would be appreciated.
Thanks!
BBM |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 08, 2008 3:48 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| BBM |
| Posted: Tue Jul 08, 2008 4:12 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi Peter,
We have implemented the *qmgrname notation dsicussed earlier.
Unfortunately I have no visibility of the Java app but can ask the app owners to dump any settings as required.
We're not using MQ clustering but are using the asterix for future migration reasons - ie. we want the client to carry on working when we redirect to a different QM.
Are you saying there is a further parameter we need to configure at the client end?
Thanks for your help....
BBM |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 08, 2008 4:40 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
I'm not sure on this one. Upon further reflection that post I refered you to matters primarily for MQPUTs inside an MQ cluster from JMS clients, which is not your scenario.
What is the linked exception that corresposnds with "MQJMS1017: non-local MQ queue not valid for receiving or browsing ", i.e. what is the 4 digit MQRC being returned?
What results do you get when using just * instead of *QIUKLMB?
What results do you get when using blank for the QM Name?
There are 2 places to set the QM name. The first one is in the Queue Connection Factory, where your connection parameters are set (MQCONN).
The other place you will see Queue Manager Name mentioned is on the q object. In that JMS object definition, QMANAGER name is NOT the QM you are connected to. (see the post I referenced earlier). Are they putting *QIUKLMB in the QMANAGER field in the q object? If yes that's wrong and may be causing this error.
Ask them what thet are setting for the queue manager name in the Q object (should be blank) and in the QCF (should be able to use * or *QIUKLMB or blank).
FJ, you can use * and/or blank for the QM name in a QCF, right?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 08, 2008 11:48 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Specify the url for the channel table in your qcf and your rules for specifying the QMGR follow the same rules as for the client Channel table:
i.e. QMGRNaame* or *groupname where the groupname is in the qmgr name on the channel table. The channel names within that group are then polled in alpha order to find a qmgr to connect to.
Enjoy 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 08, 2008 1:32 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
If not using a channel table, can you build a valid QCF specifying only the hostname, port and MQ Channel name, while leaving the QM Name blank or *?
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Tue Jul 08, 2008 2:48 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| PeterPotkay wrote: |
| If not using a channel table, can you build a valid QCF specifying only the hostname, port and MQ Channel name, while leaving the QM Name blank or *? |
If not using a channel table the usual rules apply.
IIRC:If the qmgr is blank it better be the default qmgr.
You could as well leave it blank in case of a client connection (although I have never tried this).
Peter for your case as stated above I'd say:
add the transport attribute to say client
and leave the qmgr blank (empty string or a space or replicate(space, length of qmgr name field) ) no *...
Any other value will be checked against the actual qmgr name you're connecting to. So no wildcards allowed. And remember always case sensitive.
Enjoy
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| PeterPotkay |
| Posted: Tue Jul 08, 2008 4:34 pm Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
|
| Back to top |
|
|
| BBM |
| Posted: Wed Jul 09, 2008 3:30 am Post subject: |
|
|
Master
Joined: 10 Nov 2005
Posts: 217
Location: London, UK
|
Hi - my silence is due to us testing this - heavily..
Current thinking is that we will need to re-code - we got it working with a sample app.. |
|
| Back to top |
|
|
|
|
