| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| MQ Error: AMQ9534 Channel XXX is currently not enabled. |
« View previous topic :: View next topic » |
| Author |
Message
|
| scottm |
 Posted: Tue Oct 25, 2005 7:29 am Post subject: |
 |
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
We went from 5.2 CSD??? to 5.3 CSD06 last year.
But, we upgraded a number of QM's on Dev, Test and Prod, and we only had this issue on two Prod QM's (both having to do with WorkFlow). And after the first month or so, the problem only remainded on one QM. And it was fine for the past 6 months until 3-4 weeks ago when it happened again. But the last 2 weeks it's been fine.
I'm thinking it has to do with the way the QM's are being brought down, but I haven't been able to pinpoint anything. The issues have only been on AIX 5.1 and I'm not in charge of the recycling of the QM's on AIX - our sys admin people are the ones that do this automated recycle as it corresponds with database backups and server reboots.
There's got to be something else going on that I'm not able to see. |
|
| Back to top |
|
 |
| kevinf2349 |
| Posted: Tue Oct 25, 2005 8:13 am Post subject: |
|
|
Grand Master
Joined: 28 Feb 2003
Posts: 1311
Location: USA
|
CSD6 is pretty old.
When you say Workflow is involved in this, does this mean that the channel issues are with cluster channels? Or is this Workflow not in a cluster?
If it is the cluster channels you may want to go to at least CSD7. I believe that CSD7 fixed many clustering issues. |
|
| Back to top |
|
|
| scottm |
| Posted: Tue Oct 25, 2005 9:36 am Post subject: |
|
|
Apprentice
Joined: 13 May 2004
Posts: 44
Location: SE Tennessee
|
CSD06 was the most recent when we started to do our testing for our upgrade. By the time we were finished (because of other applications' delays) I think CSD08 was the most recent. But, since it was all tested with CSD06, we had to put that one in.
At the same time our WorkFlow was also upgraded. The channels in question are on one of the WorkFlow QM's that is part of a cluster, but the channels themselves are just regular receiver channels coming from other QM's in our DMZ.
I agree though that we do need to upgrade the CSD level, or maybe go to v6.0, but we have much bigger issues/projects going on here that we need to address before we can even think about this upgrade. For the the most part our current version is stable and we don't have anyone we can spare to even look at the upgrade. Not to mention the testing that would be needed from the application side, and I know they don't have time right now. |
|
| Back to top |
|
|
| AlainB |
| Posted: Tue Oct 25, 2005 11:26 am Post subject: |
|
|
Voyager
Joined: 31 Oct 2002
Posts: 79
Location: Belgium
|
| Quote: |
| Do you issue a stop for the channels before you stop the qmgr? My bet would be that all is well when they are inactive when you restart but if you don't stop the channels and then kick the queue manager out from under then you are potentially going to have these issues. |
No, we don't issue anything; we have seen this behaviour when we reboot the host where the queue manager is running, mainly because we have business applications no more responding ... on that NT host !
When the host comes up and the queue manager too, we always have the 2 same channels stopped, with the mentionned error present in the error files.
_________________
Alain Buret
Visit http://www.fosdem.org |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Tue Oct 25, 2005 12:33 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
I have a very fuzzy memory of an issue exactly like this, in migrating from 5.2 to 5.3, where channels had to be dropped and recreated to get them started automatically....
But I don't remember the details... and I might be confusing it with an issue with amqmdain on Windows where listeners had to be deleted and recreated.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| mq_developer |
| Posted: Tue Oct 25, 2005 1:16 pm Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
Its a known problem with migration , i dont remember exactly which CSD fixed it .
But at the crux , this is the problem that you are going through .
During the migration of objects from 5.2 to 5.3 , channel synchronization information that is carried from SYSTEM* gets corrupted ( for some reasons , it happens only on a environment where you have large number of channels - that is why you didnt see this behaviour when you upgraded in TEST , DEV and other environments) and every time when you restart MQ , Queue manager leaves the channels in STOPPED status for which synchronization information is corrupted.
Even if you fix STOPPED channels by starting them , solution is temporary , as the corrupted information doesnt get cleared, as far as i remember later CSD are supposed to fix this , you can apply recent CSD's.
And another way to go about this is tidy up the synchronization information , i thought there is a technote for this situation , let me try to find it , otherwise PM me , i can send my notes.
Thanks. |
|
| Back to top |
|
|
| mq_developer |
| Posted: Tue Oct 25, 2005 1:22 pm Post subject: |
|
|
Voyager
Joined: 18 Feb 2002
Posts: 82
|
Here is the technote ...
http://www-1.ibm.com/support/docview.wss?rs=171&context=SSFKSJ&q1=STOPPED&uid=swg21210760&loc=en_US&cs=utf-8&lang=en
Good luck ..
Problem
Your Channel comes up in a "Stopped" status. This occurs even if you have set the status to "INACTIVE" .
Cause
Multiple entries of the channel status for your channel in the 'SYSTEM.CHANNEL.SYNCQ'.
Solution
If APAR IY53917 is NOT applied when the queue manager is started for the first time at WebSphere® MQ v5.3 and the problem occurs, applying this APAR will NOT fix the problem. You can overcome this issue using following steps:
Check that no channels are indoubt using command:
'dis chs(*)'
Resolve any indoubt channels.
Stop all channels with a status of inactive using the command:
'stop chl(name) status(inactive)'
Purge the SYSTEM.CHANNEL.SYNCQ of messages.
Restart the queue manager.
The steps above need to be completed only once. It will not be necessary to apply the above mentioned APAR after this.
The system affected is a migrated one. For example, MQSeries® v5.2 was migrated to WebSphere MQ v5.3. This problem scenario was encountered previously on such systems. This information is documented and fixed in APAR IY53917. This APAR needs to be applied before the queue manager is started for the first time at WebSphere MQ v5.3. |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
