| Author |
Message
|
| Vitor |
 Posted: Wed Nov 29, 2006 6:31 am Post subject: |
 |
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Nigelg wrote: |
| Quote: |
Under what circumstances would the RESOLVE command be used then?
|
1. When the channel is in-doubt
AND
2. When you know that the msgs are never going to be delivered to the original destination, i.e. the qmgr/machine does not exist any more, and so can not reply to any resync request. |
Wobbling a bit off topic here, I found the following in the Intercommunication manual:
| Quote: |
When a channel refuses to run
If a channel refuses to run:
... (material concerning incorrect initial setup)
It is possible that an in-doubt situation exists, if the automatic synchronization on startup has failed for some reason. This is indicated by messages on the system console, and the status panel may be used to show channels that are in doubt.
The possible responses to this situation are:
Issue a Resolve channel request with Backout or Commit.
You need to check with your remote link supervisor to establish the number of the last message or unit of work committed. Check this against the last number at your end of the link. If the remote end has committed a number, and that number is not yet committed at your end of the link, then issue a RESOLVE COMMIT command.
In all other cases, issue a RESOLVE BACKOUT command.
The effect of these commands is that backed out messages reappear on the transmission queue and are sent again, while committed messages are discarded.
If in doubt yourself, perhaps backing out with the probability of duplicating a sent message would be the safer decision
|
This does seem to imply that there is a remote but possible chance that automatic resync can fail & RESOLVE CHANNEL is provided for this instance.
Do the assembled:
a) agree with this interpretation;
b) believe that it's still valid for the failing channel to be checked for in-doubt status in the situation described in the original post?
c) If not, and RESOLVE CHANNEL is only for use with in-doubt channels where the target is no longer serviceable, how would the decision be made between COMMIT & BACKOUT? What would be the point of COMMIT?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Wed Nov 29, 2006 6:57 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
In general, I think this doesn't help with Kristoffer's problem.
In specific, I've never needed to issue a RESOLVE CHANNEL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Vitor |
| Posted: Wed Nov 29, 2006 7:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| jefflowrey wrote: |
In general, I think this doesn't help with Kristoffer's problem.
|
The wobble has become a swerve. I've started a new thread:
http://www.mqseries.net/phpBB2/viewtopic.php?p=159310
Comments & viewpoints eagerly anticipated.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Thu Nov 30, 2006 12:36 am Post subject: |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
| Vitor wrote: |
Kristoffer - can you confirm (for the paranoid amongst us like me) that you have a DLQ on both of the queue managers involved? |
I have just double checked and we have DLQs specified (and existing) on both queue managers. |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Thu Nov 30, 2006 12:39 am Post subject: |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
| MichaelDag wrote: |
unless there is a default xmitq defined somewhere...  |
Nope, no default transmission queue specified on any of the queue managers. |
|
| Back to top |
|
|
| Nigelg |
| Posted: Thu Nov 30, 2006 2:20 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
The msg is probably non-persistent, and has been discarded when there was a network failure.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Nov 30, 2006 2:25 am Post subject: Re: Messages seems to dissappear in transit between QMs |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Kristoffer wrote: |
Our suspicions points in the direction that the bad network link causes the channel to fail to inactive state, but this shouldn't cause the messages to vanish into thin air since they are persistent all the way.
|
Do you stand by this claim of persistence?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 30, 2006 2:38 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| jefflowrey wrote: |
| Kristoffer - what is the error message that occurs when you try to start the channel from inactivity? |
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Tue Dec 05, 2006 12:00 am Post subject: Re: Messages seems to dissappear in transit between QMs |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
| Vitor wrote: |
| Kristoffer wrote: |
Our suspicions points in the direction that the bad network link causes the channel to fail to inactive state, but this shouldn't cause the messages to vanish into thin air since they are persistent all the way.
|
Do you stand by this claim of persistence? |
Yes. The transmission queue has default persistence set to Persistent. |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Tue Dec 05, 2006 12:03 am Post subject: |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
| jefflowrey wrote: |
| jefflowrey wrote: |
| Kristoffer - what is the error message that occurs when you try to start the channel from inactivity? |
|
The problem with dissappeared messages has occured twice in the last week but both times I've been able to start the channel without any error messages.
The messages have not been found (not on the xmitq prior to my sdr channel start) and had to be resent from the source application.
No suspicios entries in the qmgrs error logs either.  |
|
| Back to top |
|
|
| Nigelg |
| Posted: Tue Dec 05, 2006 12:42 am Post subject: |
|
|
Grand Master
Joined: 02 Aug 2004
Posts: 1046
|
| Quote: |
| The transmission queue has default persistence set to Persistent. |
So what?
If you are using MQPER_AS_Q_DEF and putting to a remote queue, the default persistence used is the DEFPSIST attribute from the QREMOTE definition, not from the xmitq.
Have another look at the persistence of the msgs. Easiest way would be to stop the channel, put a msg, and then browse (amqsbcg) the msg on the xmitq.
_________________
MQSeries.net helps those who help themselves.. |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Tue Dec 05, 2006 12:59 am Post subject: |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
| Quote: |
Have another look at the persistence of the msgs. Easiest way would be to stop the channel, put a msg, and then browse (amqsbcg) the msg on the xmitq. |
I've looked at messages on the XMITQ when the channel is stopped and they show up as persistent. The remote queue definition also has persitence set. |
|
| Back to top |
|
|
| queuemanager |
| Posted: Tue Dec 05, 2006 2:51 am Post subject: |
|
|
Apprentice
Joined: 28 Nov 2006
Posts: 43
Location: Bangalore
|
| It seems messages *are* being recieved by the recieving MCA. If the messages are not reaching the recieving MCA & getting lost in between due to network failure then the sequence number will not be same the next time u try to start the channel & the channel should not start in this scenario. Can u please send the dump of "DISPLAY QMGR" command for all three qmgr? |
|
| Back to top |
|
|
| kevinf2349 |
| Posted: Tue Dec 05, 2006 5:39 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
If you are convinced that you are losing persistent messages (and I still personally think that the missing messages must be NP) then raise a Sev 1 APAR with IBM. That is most definately not what should happen.
Just as a 'by the way' it is almost worthless to look at the default persistency of any queue definition and claim the messages are going to be that persistency. Persistency has been discussed at length on this site fairly recently the bottom line is that the application can set any persistency it pleases. |
|
| Back to top |
|
|
| Kristoffer |
| Posted: Thu Dec 14, 2006 2:22 am Post subject: |
|
|
Novice
Joined: 21 Nov 2006
Posts: 15
Location: Sweden
|
The problem ocurred again a couple of days ago. I wasn't in but my colleague recorded the error message.
The scenario was that the receiver complained that messages that he could confirm were sent from the source system had not been received. Upon checking the channel to to receiving queue manager we could see that it was in status Inactive.
When trying to start it we received this error:
"The MQOPEN call failed. The queue manager issued an MQOPEN call to open a WebSphere MQ object. The call failed. Check the queue manager's error log for more information about the error. (AMQ4063)"
I haven't found anything suspicious in the queue managers error logs. The only entriers for this particular channel are normal start/end ones. |
|
| Back to top |
|
|
|
|
