ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » IBM MQ Java / JMS » JMSAdmin and URI formatted queue names

Post new topic  Reply to topic
 JMSAdmin and URI formatted queue names « View previous topic :: View next topic » 
Author Message
omhopper
PostPosted: Wed Aug 29, 2007 1:38 pm    Post subject: JMSAdmin and URI formatted queue names Reply with quote

Novice

Joined: 08 Jun 2007
Posts: 17

We are using URI formatted queue names in our .bindings file so that one of our applications can dynamically respond to different queue managers. The application reads the JMSReplyTo from the request message and looks for that entry in the JNDI.

We can get the JMS attributes if we know the full URI :

dis q(queue://QM1/TESTQUEUE)
and
dis q(queue://QM2/TESTQUEUE)

But queues defined this way don't show up using wildcards. Say I want to know all my defs that reside on QM1 ... dis q(queue://QM1/*) ... doesn't work.

Has anyone else run into this problem and been able to resolve it?
_________________
Thanks.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Aug 29, 2007 2:37 pm    Post subject: Re: JMSAdmin and URI formatted queue names Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20698
Location: LI,NY

omhopper wrote:
We are using URI formatted queue names in our .bindings file so that one of our applications can dynamically respond to different queue managers. The application reads the JMSReplyTo from the request message and looks for that entry in the JNDI.

We can get the JMS attributes if we know the full URI :

dis q(queue://QM1/TESTQUEUE)
and
dis q(queue://QM2/TESTQUEUE)

But queues defined this way don't show up using wildcards. Say I want to know all my defs that reside on QM1 ... dis q(queue://QM1/*) ... doesn't work.

Has anyone else run into this problem and been able to resolve it?


BAD DESIGN.
The only reason to have the reply to queue in the JNDI of the server application would be to add a bunch of default attributes to the replyto queue. (Talking to a non JMS application)

For the .bindings file there is no sense in using URI formatted names... as this is just a level of indirection.
You can but what's the point? If you are using URI format you might just as well not use JNDI at all ...

Note that the 6.0 qcf has the attribute by default to keep the targetClient from the request...

If you need the attributes and have a URI form (usually a JMSDestination) you will get them from the URI that is returned when querying the destination.
i.e. queue.getQueueName() or topic.getTopicName() or when invoking the toString() method...

If you need to get the queue list from a qmgr you should look into pcf messages (support pack MS0B)


_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
omhopper
PostPosted: Wed Aug 29, 2007 3:16 pm    Post subject: Reply with quote

Novice

Joined: 08 Jun 2007
Posts: 17

Sorry, I forgot to indicate the replyto queues are being read by non-JMS applications. Our situation is as follows, requester is a CICS application that can be running on either of two z/OS partitions. Each partition has its own queue manager (QM1 and QM2) in my previous example. There are multiple CICS environments on each z/OS partition.

On LPAR1, QM1 runs with CICSA, CICSB, CICSC.
On LPAR2, QM2 runs with CICSX, CICSY, CICSZ.

Different application teams are working in each CICS region, possibly changing the business logic that handles the responses, but not changing the message format itself.

So on our Windows queue manager (WINQM) there is one application, that uses JMS to read the requests, handles all the requests from all the CICS regions. This system gets the JMSReplyTo value (which it reads in queue://QM/QUEUE format) from the request, and uses that as the destination for the response. This allows them to respond to requests from either of the requesting queue managers.
_________________
Thanks.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Aug 29, 2007 3:32 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20698
Location: LI,NY

Don't see what your problem is.
Don't even understand why you are viewing the reply to queue.
Code:
Destination replytoq =  rqmsg.getJMSReplyto();
if (replytoq == null) throw new Exception("no replyto info");
Message rpmsg = session.createTextMessage();
Sender sdr = session.createSender(null);
rpmsg.setText(myreply);
sdr.send(replytoq, rpmsg);


No need to even know what the replyto queue was...
You might however want to consider pass through such attributes as persistence, expiry, and priority....
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
omhopper
PostPosted: Wed Aug 29, 2007 3:37 pm    Post subject: Reply with quote

Novice

Joined: 08 Jun 2007
Posts: 17

This wasn't meant to be an application question, but an administration question.

If I want to use the jmsadmin tool to see all of the JNDI definitions for QM1 or QM2, I can't do it using the "normal" command line techniques.

If I want to see all queues that begin with TEST, I can do dis q(TEST*) and get TESTQ, TESTQUEUE, and TESTWHATEVER.

However, if I try dis q(queue://QM1/*) the jmsadmin does not show any responses. I can only get the queue attributes when I use the entire queue name.

This is true of the MQExplorer also. It won't show the destinations that have been defined in URI format.
_________________
Thanks.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Wed Aug 29, 2007 3:49 pm    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20698
Location: LI,NY

omhopper wrote:
This wasn't meant to be an application question, but an administration question.

If I want to use the jmsadmin tool to see all of the JNDI definitions for QM1 or QM2, I can't do it using the "normal" command line techniques.

If I want to see all queues that begin with TEST, I can do dis q(TEST*) and get TESTQ, TESTQUEUE, and TESTWHATEVER.

However, if I try dis q(queue://QM1/*) the jmsadmin does not show any responses. I can only get the queue attributes when I use the entire queue name.

This is true of the MQExplorer also. It won't show the destinations that have been defined in URI format.

This is due to the way you defined the queues in the .bindings file. I already mentioned that if you use URI's there is no point....

Don't remember where I found the reference but it should be in the manual, the '/' is not supported for a multilevel JNDI name in the file implementation for the initalcontext...
The way to do this is to create a subcontext.
You will have to navigate to the corresponding subcontext from the root context in the app...
Code:
// ctx is my initial context @ root level
Context qm1ctx = (Context) ctx.lookup("QM1");


You can then define all the queues for QM1 in that particular subcontext...

But if QM1 and QM2 use the same queue name I would just define them without the QMname.
By default the URI "queue:///MYQUEUE" gets resolved to the queue MYQUEUE on the qcf's qmgr

Enjoy
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » IBM MQ Java / JMS » JMSAdmin and URI formatted queue names
Jump to:  



You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.