I think that there is a big misunderstanding:
MQ for Microsoft people stays for Missed Queue.
-Messaggio originale-
Da: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Inviato: lunedì 19 aprile 2004 8.24
A: [EMAIL PROTECTED]
Oggetto: Re: Microsoft MQ ([EMAIL PROTECTED]:20040419419 CENTROSIM)
Good luck, I've never been able to get it to work.
Sid
-Original Message-
From: Arvind Chaudhary [mailto:[EMAIL PROTECTED]
Sent: Monday, 19 April 2004 3:04 PM
To: [EMAIL PROTECTED]
Subject: Re: Microsoft MQ
I am watching this discussion with quite some interest since I thought the
sol
I am watching this discussion with quite some interest since I thought the
solution is quite simple, but now it looks otherwise. Have any of you guys
tried to write a simple service that would read the messages from MSMQ and
put them to WMQ and vice-versa. I think this is quite simple in .Net of
Hi Neil (and info for others)
I finally figured out the problem and it's to do with TTL and you are
absolutely right.
The confusion that arised last night was - when I issued "nslookup" command
it showed the revised IP address but MQ was still using old address (and I
am not a guru on Solaris).
Hi Jim
To my horror I can't find a command to stop/terminate/end the channel
initiator (may be it's due to my Monday syndrome or there is no such
facility) for non-z/OS platforms. I can kill the process, if that is what is
called recycling. There one MQSC command called STOP CHINIT but that say
v
WE had the same problem some time back and found that MQ was caching the
IP address. If I remember correctly, we recycled the channel initiator
and the address was resolved correctly.
Cheers...
Jim Nuckolls
Adiraju, Rao wrote:
Hi Neil
If my understanding goes TTL is applicable at global level and
Hi Neil
If my understanding goes TTL is applicable at global level and not at MQ
manager level. As I mentioned in my original mail, when I look at the DNS
resolution at SOLARIS level it is pointing to the latest IP address which
confirms the TTL value is small and DNS alteration has been detected
Hi Rao,
your initial problem description looks more like a DNS resolver problem
than an MQ problem.
Check with your network support people to find out what is the TTL (Time To
Live) value for the specific DNS entry you are using. Default values for
DNS can be several hours. Application programs w
Rao,
My apologies. Do you have any monitoring on MQ?
QPasa and Candle CC DE XP can be configured to hadle
these failover situations. Nastel may also - just
can't confirm from experience.
The channel may have to be stopped/started to
correct the ip issue. Maybe someone with a deeper
understan
Chris
Call me "Rao".
The spoke is on Windows machine with MQ V5.3 CSD06. And I can't locate any
"adoptmca" parameter on that platform. There is one for Z/OS but not for
windows.
I don't want to DELETE and re-DEFINE channels either because then channel
sequence numbers will be out of whack.
Chee
Adiraju,
What kind of machine is at the other end of the
channel? Could this be an adoptmca issue? Why not
have a "failover" script cycle the channel when it
fails? It could interogate the primary ip and
secondary ip when the channel has a retry event
trigger it. Then make a failover or alert y
Title: Channel Connection name resolution
Fellows
Last night I was testing our Disaster Recovery strategy for MQ and stuck with a problem and need (as well as appreciate) some help from the forum:
Situation:
I have a MQ hub running on Solaris with MQ version 5.3 CSD04. It is talking to a
Peter & Don
Thanks for your suggestions. I am talking of this in a banking environment
in production where most of time the MQ users are indirect users - such as
Swift, Weblogic, CRM products etc.. and I don't have a clue what these
products do in such error situations. Considering some messages c
13 matches
Mail list logo
