| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Changing CLUSSDR channel definition after use |
« View previous topic :: View next topic » |
| Author |
Message
|
| ChrisW |
 Posted: Tue Feb 05, 2002 7:44 am Post subject: |
 |
|
Voyager
Joined: 20 May 2001
Posts: 78
Location: UK
|
I have just added an OS/390 Queue Manager to a cluster. The cluster also contains two repositories and two other Queue Managers. I made a mistake on the original CLUSSDR definition, missing the CONVERT(YES) to handle EDBDIC/ASCII conversion. However, by the time that was noticed in testing, additional cluster sender channels were active to all other Queue Managers in the cluster.
I then corrected the base definition and first stopped and started the initial CLUSSDR to the repository. This had no effect and the command interface would not let me stop the others. I then waited for all channels to disconnect and tried the initial MQPUT again. Still no conversion.
I am not sure what to try next. Maybe delete and redefine the CLUSSDR channel? All suggestions welcome. |
|
| Back to top |
|
 |
| bduncan |
| Posted: Tue Feb 05, 2002 2:45 pm Post subject: |
|
|
Padawan
Joined: 11 Apr 2001
Posts: 1554
Location: Silicon Valley
|
Hmm. Interesting problem. From my experience, there's only one sure-fire way of fixing this, and that is to remove the OS/390 machine from the cluster (ensuring all cluster definitions are wiped out) and placing it back in. To do this, you should follow a procedure laid out in excruciating detail in the Clusters Manual. Basically (and you should look in the manual, I may have left something out) you need to:
1) alter any clustered queues you may have on the OS/390 to no longer be members of the cluster.
2) stop the cluster receiver channel coming from repository that you manually defined when you added this OS/390 to the cluster. Once it has stopped, alter it so that it is no longer in the cluster. Once you have altered it, delete it. Notice that the cluster sender channel is still running during this whole process. This way, the OS/390 can inform the repository that the cluster receiver channel is going away, and at the same time not receive any new information from the repository.
3) now alter the cluster sender channel you manually defined to the repository to no longer be part of the cluster. Anytime you want to make something not part of the cluster anymore, just set its CLUSTER attribute to ' ', i.e., CLUSTER(' ') now stop the sender channel, and delete it.
4) back on the repository machine, issue a RESET CLUSTER command and boot the OS/390 machine out of the cluster. At this point, none of the machines in the cluster should see anything from your OS/390. Some "ghost" queues may still exist (if you had clustered queues on the OS/390) on machines in the cluster, but what we really care about is getting rid of the channel definitions so you can redefine them.
5) Now, recreate your cluster sender/receiver channels on the OS/390, using the CONVERT option. Everything should work now...
_________________
Brandon Duncan
IBM Certified MQSeries Specialist
MQSeries.net forum moderator |
|
| Back to top |
|
|
| ChrisW |
| Posted: Fri Feb 08, 2002 5:12 am Post subject: |
|
|
Voyager
Joined: 20 May 2001
Posts: 78
Location: UK
|
Brandon,
Thanks for your reply. I followed the procedures in the manual to remove a queue from a cluster and then remove a queue manager from a cluster. This was achieved by the following (all on the OS/390 Queue Manager):
1. ALTER QL(queue-name) CLUSNL(' ') for all cluster queues
2. SUSPEND QMGR CLUSTER(cluster-name)
3. STOP CHL(cluster-receiver)
4. ALTER CHL(cluster-receiver) CHLTYPE(CLUSRCVR) CLUSNL(' ')
5. DELETE CHL(cluster-receiver)
6. STOP CHL(cluster-sender)
7. DELETE CHL(cluster-sender)
The Queue Manager was then checked to ensure that it was no longer in any clusters and that communication had taken place with the repositories. The cluster was then recreated successfully with the correct parameters this time.
While doing this I was looking at a seperate performance problem and thought that changing the BATCHSIZE to 1 would improve things. Same problem! Sounds like a requirement for IBM to me! Further comments welcome. |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
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
|
|
|
|
