| Author |
Message
|
| Sam Uppu |
 Posted: Fri Apr 23, 2010 11:46 am Post subject: In a cluster whether SYSTEM.CLUSTER.* queues->PERSISTENT? |
 |
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Hi Guys,
We have an MQ cluster in which 2 are full repositories and around 60 partial repositories.
I am wondering whether any of the SYSTEM.CLUSTER.* queues need to be persistent?.
When the queue manager is created, the below queues are defined with non persistent.
1. SYSTEM.CLUSTER.COMMAND.QUEUE
2. SYSTEM.CLUSTER.REPOSITORY.QUEUE
3. SYSTEM.CLUSTER.TRANSMIT.QUEUE
We are handling non persistent msgs thru MQ.
Whether we need to change any of the above SYSTEM.CLUSTER.* queues to be persistent on full repositories?.
Any of your inputs will help.
Thanks. |
|
| Back to top |
|
 |
| mvic |
| Posted: Fri Apr 23, 2010 12:27 pm Post subject: Re: In a cluster whether SYSTEM.CLUSTER.* queues->PERSIST |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
| Please do not touch any of those queues. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Fri Apr 23, 2010 12:50 pm Post subject: Re: In a cluster whether SYSTEM.CLUSTER.* queues->PERSIST |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mvic wrote: |
| Please do not touch any of those queues. |
This technote is saying those queues need to be persistent.
SYSTEM.CLUSTER.REPOSITORY.QUEUE, SYSTEM.CLUSTER.TRANSMIT.QUEUE and SYSTEM.CLUSTER.COMMAND.QUEUE are all used by the queue manager for persistent messages, so should be defined with persistence of YES.
Please suggest.
Thanks. |
|
| Back to top |
|
|
| mvic |
| Posted: Fri Apr 23, 2010 1:02 pm Post subject: Re: In a cluster whether SYSTEM.CLUSTER.* queues->PERSIST |
|
|
Jedi
Joined: 09 Mar 2004
Posts: 2080
|
Well the technote claims to be specific to z/OS. Being unskilled on that type of environment I will not comment further on this.
As far as Unix and Windows environments are concerned, there is no need to touch the queues you named in the original post. If there were any need to consider this matter (there isn't) I am sure there would be something in the proper MQ manuals about it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Apr 23, 2010 1:57 pm Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Queues are neither persistent nor non-persistent.
Messages have an MQMD field that must be set to by the application to one of these values: persistent, non-persistent, or take on the so-called persistence attribute of the queue.
The persistence attribute of the queue will not change a persistent message to non-persistent; nor will it change a non-persistent message to persistent.
And, yes, do not fiddle with SYSTEM. objects.
_________________
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: Fri Apr 23, 2010 4:31 pm Post subject: Re: In a cluster whether SYSTEM.CLUSTER.* queues->PERSIST |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
| Please suggest. |
I suggest you leave well enough alone, and don't fiddle with SYSTEM objects unless you have a really good reason and ideally the blessing of IBM support.
It's unclear from your original post if this question has come up because you actually have a problem, have a compulsive desire to modify things or believe mistakenly that your handling of non-persistent messages through WMQ is in some way affected by the default settings of these objects.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Apr 26, 2010 8:55 am Post subject: Re: In a cluster whether SYSTEM.CLUSTER.* queues->PERSIST |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| mvic wrote: |
| Please do not touch any of those queues. |
I agree with you and I dont see any of the Online infocenter/ redbooks. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Apr 26, 2010 9:28 am Post subject: Re: In a cluster whether SYSTEM.CLUSTER.* queues->PERSIST |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| Vitor wrote: |
| Sam Uppu wrote: |
| Please suggest. |
I suggest you leave well enough alone, and don't fiddle with SYSTEM objects unless you have a really good reason and ideally the blessing of IBM support.
It's unclear from your original post if this question has come up because you actually have a problem, have a compulsive desire to modify things or believe mistakenly that your handling of non-persistent messages through WMQ is in some way affected by the default settings of these objects. |
Vitor,
You imagined my situation. YES. I actually ran into a problem. We created all the queue managers with default # of logs and circular logging as we are using non persistent msging.
We had MQ version of 7.0.0.1 and we are upgrading to MQ 7.0.1 refreshpack now. For this upgrade we are following the below steps:
1. Suspend the qmgr from cluster
2. stop the qmgr
3. apply the refreshpack 7.0.1
4. start the qmgr
5. resume the qmgr to join the cluster
When we see the status of this upgraded qmgr in full repositories, we still see it as suspended, though it is resumed properly. For this to take effect, we refreshed the partial repository by issuing REFRESH CLUSTER command which we should not do but we didn't have any other option at this time.
When we issued this command, we were seeing some FDCs and also qmgr's AMQ* errors throwing some errors on full repositories.
FDCs: Msg unable to get from SYSTEM.CLUSTER.REPOSITORY.QUEUE.
I opened the pmr with IBM and they mentioned that SYSTEM.CLUSTER.* queues are PERSISTENT and these will be written to MQ logs and suggested to increase the # of primary/ secondar logs to accomodate all the persistent msgs. We had 3 primary + 2 seconday = 20 MB log space. When I look at those queues I realized those are non persistent and IBM support is saying those queues need to be persistent.
As 'mvic' stated above, these queues should not be touched and if that is mandatory to change to persistent, it should have documented in stndard MQ infocenter/ redbooks along with technotes.
I mentioned the same thing to IBM support and waiting for their response on this.
Thanks for your thoughts. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 26, 2010 10:52 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| Quote: |
| FDCs: Msg unable to get from SYSTEM.CLUSTER.REPOSITORY.QUEUE. |
I think this might more have to do with upgrading a PR before upgrading the FRs. However only the PMR will tell what problem you are really running into.
Let us know once it has been resolved...
Have fun 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Mon Apr 26, 2010 11:52 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
| fjb_saper wrote: |
| Quote: |
| FDCs: Msg unable to get from SYSTEM.CLUSTER.REPOSITORY.QUEUE. |
I think this might more have to do with upgrading a PR before upgrading the FRs. However only the PMR will tell what problem you are really running into.
Let us know once it has been resolved...
Have fun |
Infact we upgraded the FRs first and later touched the PRs.
Here is the story:
Upgraded 1st FR.
Have seen the above FDC and AMQ* errors on 1st FR. When we look into the 2nd FR for the status of 1st FR manager, I still see it as suspended though it is resumed properly. Needed to REFRESH CLUSTER on 1st FR. After refresh, 1st FR was looking good though the FDC and AMQ* error was there.
Later moved onto 2nd FR and upgraded. After the upgrade the 2nd FR was looking good.
The next day we started with the partial repository managers to upgrade. As we have 60 queue managers in this cluster, we were doing on daily basis few at a time. When we upgraded one of the PR, we were seeing suspended in both the FRs...waited for 15-20 minutes..still showing as suspended in FRs. Issued the REFRESH CLUSTER on upgraded PR. Now we see that FDC and AMQ* error on 2nd FR (after 9 hours of its upgrade).
When IBM mentioned to increase the # of primary/ seconday logs, I thought that REFRESH CLUSTER sent a huge msg to FR which is not able to fit across 3 primary/ 2 seconday logs. But I dont think that msg is more than 20 MB (3primary + 2 seconday = 20MB).
Then IBM mentioned those SYSTEM.CLUSTER.* queues are persistent and everything will be written to disk(MQ logs). When I go and look into SYSTEM.CLUSTER.* queues, I see them as NON PERSISTENT then I thought whether queue manager will write the msgs to these queues as persistent. I browsed one of the msg on SYSTEM.CLUSTER.REPOSITORY queue and YES, the msgs on SYSTEM.CLUSTER.REPOSITORY.QUEUE are PERSISTENT.
When IBM support mentioned that, I was hard to believe those queues need to be changed to PEESISTENT as Infocenter/ redbooks are *NOT* talking about this. Thatswhat I posted this on this forum to check with you guys. As the queue manager itself writing the msgs as PESISTENT, we no need to ALTER the SYSTEM.CLUSTER.* queues.
I will update you if I hear any thing from IBM.
Thanks. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Apr 26, 2010 7:59 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
Your logs might still be too small due to channel batching.
If the default is in effect (50 msgs) and your 50 cluster msgs make up more than your logs can handle, you're in trouble.
I usually go with plenty of space and set the secondary logs to a big enough number. This way the logs are not permanently eating space (faster backup) but will allow for expansion of the UOW when needed.
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Apr 27, 2010 6:02 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
Today, I got the update from level-3 support from IBM. here it is:
It is not required and not recommended to change the default properties
of any of the system queues unless documented or recommended by IBM
support for some specific requirements. The technote swg21167752 is not
applicable to MQ distributed platforms.
Thanks for your thoughts/ suggestions. |
|
| Back to top |
|
|
| Sam Uppu |
| Posted: Tue Apr 27, 2010 6:46 am Post subject: |
|
|
Yatiri
Joined: 11 Nov 2008
Posts: 610
|
I checked the SYSTEM.CLUSTER.* queues on one of our mainframe queue manager and I see the SYSTEM.CLUSTER.* queues are defined with default PERSISTENCE of YES.
Not sure whether the queue manager creation itself creates these SYSTEM.CLUSTER.* queues as PERSISTENT or we need to ALTER these queues with default PERSISTENCE of YES once the queue manager is created on mainframe?.
Can someone confirm this?.
Thanks. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Tue Apr 27, 2010 7:27 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Take a look at another qmgr, one that SYSTEM. objects have not been altered, to see how persistence is set.
It is highly unlikely that a qmgr component is going to use persistence_as_q_def. Your applications might, however, which for the cluster transmission queue, would set persistence to the persistence setting at the queue.
_________________
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 Apr 27, 2010 7:41 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Sam Uppu wrote: |
Can someone confirm this?.
|
Our z/OS queue managers all have default persistence yes including the one I built about a month ago. To the best of my knowledge no-one's done ALTER on the SYSTEM objects.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
|
|
