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 » User Exits » exits to capture how applications are connecting to QMGR

Post new topic  Reply to topic
 exits to capture how applications are connecting to QMGR « View previous topic :: View next topic » 
Author Message
abdul.mbr
PostPosted: Fri Jun 20, 2014 9:41 am    Post subject: exits to capture how applications are connecting to QMGR Reply with quote

Newbie

Joined: 19 Aug 2011
Posts: 8

Hello,

We are moving mq qmgrs from AIX to Linux and in this process, we are trying to find out how applications are connecting to the queue managers, meaning, using QCFs, bindings, APIs etc. But mainly we are trying to find out if applications are connecting and putting to the queue manager using the i/p address, the hostname or the queue manager name(alias to the hostname).

Our plan is to move the applications connecting using the ip address to change to use the alias.
Is there anyway we can find out how the applications are connecting? We have close to 150/200 different applications using the queue managers and not all of them are supportive.

Please help.
Back to top
View user's profile Send private message
fjb_saper
PostPosted: Fri Jun 20, 2014 11:43 am    Post subject: Reply with quote

Grand High Poobah

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

Give a fair warning to the apps owners... can be an email blast...

Move the qmgr to a different host, set the alias name (qmgrname) for the host in DNS and tell nobody...

Wait and see who comes complaining...
Then move up one environment and repeat until you run out of environments...


_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
fjb_saper
PostPosted: Fri Jun 20, 2014 11:51 am    Post subject: Reply with quote

Grand High Poobah

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

What I was basically trying to tell you here is that you have absolutely no means to know that information at the destination.

DNS resolution is done at the source.
Either through /etc/hosts or DNS server lookup...
By the time the communication is established with your queue manager the ip has been resolved at the source. A reverse DNS lookup would not help either... but for the fact to show if the alias is in registered with the DNS server... and you can do this through nslookup...

Also there is no telling if the source user used the short name resolution or the long name resolution, unless both do not resolve to the same address... (blunder or conscious indirection??)

Have fun
_________________
MQ & Broker admin
Back to top
View user's profile Send private message Send e-mail
tczielke
PostPosted: Sat Jun 21, 2014 8:28 am    Post subject: Re: exits to capture how applications are connecting to QMGR Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

abdul.mbr wrote:
Hello,

Is there anyway we can find out how the applications are connecting? We have close to 150/200 different applications using the queue managers and not all of them are supportive.

Please help.


A client side trace would show this. For example, if I wanted to see how the amqsputc program was making a client connection, I could do the following (at v7):

strmqtrc -t all -p amqsputc

An AMQxxxx.0.TRC filed would be created in /var/mqm/trace (with xxxx = the pid number), and then if you do a dspmqtrc on that .TRC file, you should be able to see if an MQSERVER environment variable was being used, a CCDT and subsequent CONNAME (I did not verify the CCDT, but I assume it would be there if used), etc.

With a lot of these posts to MQSERIES.NET there is usually the answer of how to do what the poster is asking, and why are you trying to do that. The above gives an option for how. But I would also ask why an administrator would need to do this (I am assuming you are an MQ administrator) in the first place. I would think this type of work needs to fall on the application team that supports the application. I know you mentioned these are unsupported applications, but clearly some application person now needs to be assigned to do the relevant investigation/changes?
Back to top
View user's profile Send private message
abdul.mbr
PostPosted: Mon Jun 23, 2014 5:17 am    Post subject: Reply with quote

Newbie

Joined: 19 Aug 2011
Posts: 8

Thanks for the replies,guys.

Re: the email blast, this is the easiest way. But the app teams are not very responsive to mails. We had a similar situation earlier, and it took us 1 year to basically weed out each and every app and guide them to move.
This time, the server team is not that patientespecially since we are using an AIX alias to point to a Linux server.

Re: App team taking care of it and traces,
wouldn't setting up traces generate really large files and put the whole server and queue manager in jeopardy?
The app teams like i set are using code from a long time back and some of it is hardcoded. So, either they don't want to or either don't know what to change and where. So, instead of digging it up and fixing it, they are just chalenging us to find a way. If there's no other way, we will juts wring their wrists to do it.

Thank you once again.
Back to top
View user's profile Send private message
tczielke
PostPosted: Mon Jun 23, 2014 5:27 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
Location: Illinois, USA

Yes, tracing would generate a lot of data and would not be very practical unless you are looking at a specific client app that you wanted to investigate. I would not recommend doing this as a holistic approach, but did want you to be aware of the possibility from an administrator stand point, that you could get the information this way.

The application team saying this is too hard to do is an unfair argument on their part. It is their code and their responsibility to change this when you are changing servers. It is hard for me to go out in my yard in the 90 degree heat and humidity of an Illinois summer and trim all of my bushes, but I do it anyway because it is my responsibility as a home owner to do it. Tell them, there is no easy way to track down this information, and they just need to do it. Or to quote the Chicago Bulls basketball coach, Tom Thibodeau, "Do your job!".
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Page 1 of 1

MQSeries.net Forum Index » User Exits » exits to capture how applications are connecting to QMGR
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.