Author |
Message
|
exerk |
Posted: Tue Dec 29, 2009 1:43 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
bruce2359 wrote: |
Yep.
QMID is an internally generated unique name that consists of the queue manager name plus the time the queue manager was created.
For z/OS, the time is expressed as 16 hex digits, for example
RTPH.BDA2D50C17934846. |
So, does V7.x on z/OS now display QMID's as 'readable'? I've only ever seen them as you've described  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Dec 29, 2009 1:54 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9470 Location: US: west coast, almost. Otherwise, enroute.
|
Uh... I don't have a z/OS v7 image at my fingertips; and I didn't pay much attention to qmid on v7. In all, I can't say with any certainty if the qmid on WMQ for z/OS has changed its look, or not. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
akm.mohan |
Posted: Tue Dec 29, 2009 2:08 pm Post subject: |
|
|
Apprentice
Joined: 07 Oct 2008 Posts: 41
|
Yes QMID is queue manager name plus the time the queue manager was created
Here, what I did is I just removed the QMGR1 from the existing cluster and deleted all the channels.
Then I defined the cluster sender and rcvr channels to QMT2 to refer the FR.
and created the clusrcvr channel to QMT1.
So then I was expecting the autodefined cluster-sender channel has to be defined.
TO.QMT1 has been defined automatically.
So here why it was not defined the auto-defined clussdr chanenl to QMT2? |
|
Back to top |
|
 |
akm.mohan |
Posted: Tue Dec 29, 2009 2:16 pm Post subject: |
|
|
Apprentice
Joined: 07 Oct 2008 Posts: 41
|
To be more clear
the TO.QMGR1 sender channel on mainframe (QMT1 and QMT2) show in
"suspended" state. However it seems takeing the work. We don't know
the impact. I can see two problems:
1. If we use QMT1 as the primary full repository, "auto defined" does
not work for TO.QMT2 channel.
2. The mainframe to server sender channel (TO.QMGR1) shows in
suspended state. |
|
Back to top |
|
 |
exerk |
Posted: Tue Dec 29, 2009 2:18 pm Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
As I stated before:
1. Are you sure that you have correctly altered each FR to define each as an FR?
2. Have you correctly defined the required CLUSSDR/CLUSRCVR objects in each of the FR's? The CLUSSDR in QMT1 should point to the CLUSRCVR in QMT2 and vice-versa.
3. Were both FR's cluster channels running correctly before you proceeded further?
4. Have you defined cluster instances of the same queue in each of the FR queue managers?
5. Are both cluster queue instances set to DEFBIND(NOTFIXED) ?
If you are having problems, rebuild the cluster from scratch and make absolutely sure that the two FR's are corresponding before proceeding further. Also, as stated by another poster, watch for typo's. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Dec 29, 2009 2:18 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9470 Location: US: west coast, almost. Otherwise, enroute.
|
Quote: |
Here, what I did is I just removed the QMGR1 from the existing cluster |
How exactly did you remove the QMGR1 from the existing cluster?
Quote: |
and deleted all the channels. |
How exactly did you delete all the channels? Did you follow the instructions in the WMQ Clusters manual on deleting a cluster object?
Quote: |
Then I defined the cluster sender and rcvr channels to QMT2 to refer the FR. and created the clusrcvr channel to QMT1. |
What do you mean when you say that you defined a cluster sender and receiver channels to QMT2? Each qmgr in a cluster must have a cluster-receiver that points back to itself, AND a cluster sender channel to a full-repository.
Quote: |
So then I was expecting the autodefined cluster-sender channel has to be defined.
TO.QMT1 has been defined automatically.
So here why it was not defined the auto-defined clussdr chanenl to QMT2?
(I gather that English is not your primary language.) |
I'm sorry, but I have no idea what this means.
Have you read the WMQ Clusters manual? It offers step-by-step instructions on creating a cluster. Did you follow these instructions exactly? _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
Vitor |
Posted: Tue Dec 29, 2009 2:47 pm Post subject: |
|
|
 Grand High Poobah
Joined: 11 Nov 2005 Posts: 26093 Location: Texas, USA
|
akm.mohan wrote: |
the TO.QMGR1 sender channel on mainframe (QMT1 and QMT2) show in
"suspended" state. However it seems takeing the work. |
This is a documented behaviour and working as designed.
I, like others, am alarmed by your bland statement :
akm.mohan wrote: |
I just removed the QMGR1 from the existing cluster and deleted all the channels |
You don't just remove a queue manager from a cluster; you carefully follow the documented proceedure. Just doing stuff (like deleting channels out of sequence) is going to cause problems. Much like the problems you seem to be experiencing.
I think you've broken it. Delete everything, start again using proper procedures and build it back up. The advice you've been given to read the Clusters manual is sound. _________________ Honesty is the best policy.
Insanity is the best defence. |
|
Back to top |
|
 |
mvic |
Posted: Tue Dec 29, 2009 3:01 pm Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
akm.mohan, several people have given their quality time to trying to understand and advise on your problem.
Please take more care to get the details of your posts right. We can all make mistakes, I have made my fair share (and you can edit your post to correct an error).
However sometimes if you take time to use the correct terminology (eg. over when the auto-defined clussdrs are created) and write the problem out in detail you can end up solving your own problem.
I still do not understand from the data provided:
- how this is a valid cluster, see my previous posts. Did you perhaps put a typo in the CLUSSDR name for the full repos?
- what the topology is, with respect to the cluster queue you are using.
Both of these points, if there is something wrong in their configuration, could stop messages flowing to the queue manager you expect them to flow to. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Dec 29, 2009 3:01 pm Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9470 Location: US: west coast, almost. Otherwise, enroute.
|
It has been my experience (other may offer theirs) that WMQ clusters EITHER work spectacularly well, OR are a constant source of problems. Both are caused by sysadmin behavior (or behaviour).
Nearly all problems result from sysadmins 1) not reading the WMQ Clusters manual, and therefore 2) not understanding how clusters work, and 3) not following the explicit instructions on working with cluster objects.
WMQ clusters is/are an advanced topic. _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
akm.mohan |
Posted: Wed Dec 30, 2009 7:01 am Post subject: |
|
|
Apprentice
Joined: 07 Oct 2008 Posts: 41
|
First, I am really thanks for all your valuable time..
Some one stated that To.QMT1 is missing.. its there its first definition which i posted...and QMGR1 to QMT1 is working fine there is no issue with that...
Mvic, As you stated, we can all make mistakes, I agree with that , but here its not our mistake somehow cluster is not working fine(or may be..). This was not happend on yesterday.. I tried my level best and posted here. and also this cluster is not a brand new. since 2008, it has been working fine. Suddenly what happend we don know, all the traffic is going to QMT1 from QMGR1.
So I have gone thru each and every channel to where its pointing to..finaly I found that one sender channel is missing from QMGR1 to QMT2, thats why traffic is not going to QMT2. So I have gone thru WMQ cluster manual from IBM and found that we don't need to create the cluster sender channel, there would be a Auto-Definition of cluster sender channel which will be pointing to QMT1. so In my senario, its not there.
so what I did, I already mentioned, I removed the QMGR1 from the existing cluster, to do this, I have gone thru the IBM cluster manual.. and also I am not brand new person to work with cluster...as an MQ admin it includes in my responsibilities. so please find the below link which I followed to remove the qmgr from cluster.
http://publib.boulder.ibm.com/infocenter/wmqv6/v6r0/index.jsp
webspheremq
+Qmgr clusters
+Advanced tasks
+ task10-removing a qmgr from a cluster
followed from suspend qmgr (becaz its PR)
Correct me If I did wrong!
Then I added this QMGR1 into the cluster pointing to the QMT2 full repository (earlier it was pointing to QMT1) by following the procedure from the same link (First tasks-adding a qmgr into the existing cluster)
So far.. if QMGR1 refers to QMT2(instead of QMT1) all the transactions are balancing between QMT1 and QMT2.
And MVic, Auto-Definition of channels is the correct terminology only I found it from the IBM manual,( in your eg: you have to read complete sentense that means when the auto-defined clussdrs are created by qmgr or automatically) I didn't get you what you are suggesting me...but I agree with you, to be more clear to all, we need to put proper terminolgy ...
I have opened a PMR to IBM will see how it works for us.. I will keep posted here..
Do we have any option to enable the Auto-Definition..or do we need to do something... I don see any option like this from the manual. Only issue is with Auto definition ....
Thank you guys for all your help.. and imm responses. |
|
Back to top |
|
 |
bruce2359 |
Posted: Wed Dec 30, 2009 7:10 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9470 Location: US: west coast, almost. Otherwise, enroute.
|
I asked you: How exactly did you delete all the channels?
When asked asked a question, please post an answer to that question. Please do NOT post a link to a place in a manual that says how to do something. We want to know with certainty what you did.
So, once more, exactly how did you delete all of the channels?
1.
2.
3.
4.
... _________________ I like deadlines. I like to wave as they pass by.
ב''ה
Lex Orandi, Lex Credendi, Lex Vivendi. As we Worship, So we Believe, So we Live. |
|
Back to top |
|
 |
mvic |
Posted: Wed Dec 30, 2009 7:21 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
akm.mohan wrote: |
Some one stated that To.QMT1 is missing.. its there its first definition which i posted...and QMGR1 to QMT1 is working fine there is no issue with that... |
I am using your defs in your post: Dec 29, 2009 8:16 pm GMT
QMGR1 thinks its full repos is on a channel called TO.MQT1.
No CLUSRCVR named TO.MQT1 is included in your defs.
This looks like it is a typo, and you intended to type TO.QMT1.
Can you please respond to that point.
Unsurprisingly no second FR has been notified to QMGR1, unsurprising since it looks like QMGR1 couldn't reach even one FR because of the above problem.
If I have got any of the above wrong, then apologies but you will have to post the proof that I am wrong. I am only going on the defs you posted.
Next:
There will probably have been error messages indicating some problems: did you check?
I also had points in my post: Tue Dec 29, 2009 9:09 pm GMT: which were not noticed. |
|
Back to top |
|
 |
akm.mohan |
Posted: Wed Dec 30, 2009 9:17 am Post subject: |
|
|
Apprentice
Joined: 07 Oct 2008 Posts: 41
|
There is a typo: QMT1 is the right one
Unfortunately we don't have any logs
(I guess this forum is misrounting to removing/adding qmgr from the cluster from original issue(becaz this
has been done after issue only to check how it works if we point to another qmgr..it works.)
SUSPEND QMGR CLUSTER(AUTOCLUS)
1 : SUSPEND QMGR CLUSTER(AUTOCLUS)
AMQ8557: SUSPEND QUEUE MANAGER accepted.
DIS CLUSQMGR(QMGR1) SUSPEND
AMQ8441: Display Cluster Queue Manager details.
CLUSQMGR(QMGR1) CLUSTER(AUTOCLUS)
CHANNEL(TO.QMGR1) SUSPEND(YES)
:
ALTER CHANNEL(TO.QMGR1) CHLTYPE(CLUSRCVR) CLUSTER('')
3 : ALTER CHANNEL(TO.QMGR1) CHLTYPE(CLUSRCVR) CLUSTER('')
AMQ8016: WebSphere MQ channel changed.
:
DISPLAY CHANNEL(TO.QMGR1) CLUSTER
4 : DISPLAY CHANNEL(TO.QMGR1) CLUSTER
AMQ8414: Display Channel details.
CHANNEL(TO.QMGR1) CHLTYPE(CLUSRCVR)
CLUSTER( )
:
STOP CHANNEL(TO.QMGR1)
25 : STOP CHANNEL(TO.QMGR1)
AMQ8019: Stop WebSphere MQ channel accepted.
:
DELETE CHANNEL(TO.QMGR1)
26 : DELETE CHANNEL(TO.QMGR1)
AMQ8015: WebSphere MQ channel deleted.
:
DISPLAY CHANNEL(TO.QMGR1)
27 : DISPLAY CHANNEL(TO.QMGR1)
AMQ8147: WebSphere MQ object TO.QMGR1 not found.
:
STOP CHANNEL(TO.QMT1)
30 : STOP CHANNEL(TO.QMT1)
AMQ8019: Stop WebSphere MQ channel accepted.
:
DELETE CHANNEL(TO.QMT1)
31 : DELETE CHANNEL(TO.QMT1)
AMQ8015: WebSphere MQ channel deleted.
:
DISPLAY CHANNEL(TO.QMT1)
32 : DISPLAY CHANNEL(TO.QMT1)
AMQ8147: WebSphere MQ object TO.QMT1 not found.
:
REFRESH CLUSTER(AUTOCLUS)
33 : REFRESH CLUSTER(AUTOCLUS)
AMQ8558: REFRESH CLUSTER accepted.
After removing the qmgr from the existing cluster, then we added this qmgr into the same cluster by
refering to QMT2 FR. and did the refresh cluster in QMT1 and QMT2.Then we can see the Auto-Definition of
channels to QMT1.
Then round trip was successful. all the transactions are balancing between the QMT1 and QMT2. |
|
Back to top |
|
 |
mvic |
Posted: Wed Dec 30, 2009 10:09 am Post subject: |
|
|
 Jedi
Joined: 09 Mar 2004 Posts: 2080
|
akm.mohan wrote: |
Then round trip was successful. all the transactions are balancing between the QMT1 and QMT2. |
Excellent news.
akm.mohan wrote: |
Unfortunately we don't have any logs |
Surprising. What is the output from:
Code: |
ls -l /var/mqm/qmgrs/QMGR1/errors
grep 2009 AMQERR01.LOG
grep AMQ94 AMQERR01.LOG |
|
|
Back to top |
|
 |
|