| Author |
Message
|
| sebastia |
 Posted: Mon Dec 13, 2010 4:15 am Post subject: z/OS in a MQ cluster |
 |
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
I have found that (almost) all my customers having a z/OS host in a MQ cluster ... never have this "z" host as Full Repository.
Is there any literature (or url or pointer to) describing any reason for this practice ?
Thanks a lot. Sebastian. |
|
| Back to top |
|
 |
| exerk |
| Posted: Mon Dec 13, 2010 5:06 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
If it's of any help, at my current site we migrated all FRs to z/OS as it's the platform where queue managers stay up virtually 24/7. The frequent explanation I have heard for not putting them on z/OS are because it's more difficult to 'bounce' a queue manager on that platform.
_________________
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 |
|
|
| fatherjack |
| Posted: Mon Dec 13, 2010 5:33 am Post subject: |
|
|
Knight
Joined: 14 Apr 2010
Posts: 522
Location: Craggy Island
|
| exerk wrote: |
| If it's of any help, at my current site we migrated all FRs to z/OS as it's the platform where queue managers stay up virtually 24/7. |
I've done this as well for exactly that reason.
| exerk wrote: |
| The frequent explanation I have heard for not putting them on z/OS are because it's more difficult to 'bounce' a queue manager on that platform. |
And I've heard that excuse before as well. But quite why in a production environment the same stringent operational and change control procedures don't apply no matter what the platform I can never understand. Unless of course its the old "if its not on the maniframe its not real computing" mentality  )
_________________
Never let the facts get in the way of a good theory. |
|
| Back to top |
|
|
| sebastia |
| Posted: Mon Dec 13, 2010 5:44 am Post subject: |
|
|
Grand Master
Joined: 07 Oct 2004
Posts: 1003
|
2 questions ...
a) can you describe what "bounce" means in MQ envir ?
My English-Spanish dictionary says it means "jump" ... but it is quite meaningless in MQ envir ... jejeje
b) you can move ONE FR into z/OS ... ok ?
Not both ... I supose ...
Sebastian. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 13, 2010 5:48 am Post subject: Re: z/OS in a MQ cluster |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| sebastia wrote: |
I have found that (almost) all my customers having a z/OS host in a MQ cluster ... never have this "z" host as Full Repository.
Is there any literature (or url or pointer to) describing any reason for this practice ? |
They're insane.
A z/OS host is an ideal candidate for a FR, and (almost) all of my customers which have z/OS use it as such. Certainly after I've been there any time.
Even customers where the distributed systems don't actually communicate with the z/OS (because there's no business reason) have the z/OS sitting as the 2nd repository, with a queue manager that does nothing but be an FR. If you want a url start with this which says:
| Quote: |
| The most important consideration is that the queue managers chosen to hold full repositories need to be reliable and well managed. For example, it would be far better to choose queue managers on a stable OS/390® system ... |
Clearly this needs to be updated as z/OS hasn't been called OS/390 for a few years now but the principle holds.
A FR needs to be highly available. A z/OS queue manager, correctly set up, is as highly available as you get.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Dec 13, 2010 5:49 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| sebastia wrote: |
2 questions ...
a) can you describe what "bounce" means in MQ envir ?
My English-Spanish dictionary says it means "jump" ... but it is quite meaningless in MQ envir ... jejeje |
"restart".
| sebastia wrote: |
b) you can move ONE FR into z/OS ... ok ?
Not both ... I supose ... |
You could, but even given the 24/7 reliability of zOS one tends to want to keep the cluster available during significant outages and not require that two LPARs be IPLed without requiring that one of them be up while the other is down. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 13, 2010 5:50 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| The frequent explanation I have heard for not putting them on z/OS are because it's more difficult to 'bounce' a queue manager on that platform. |
IMHO it's just more difficult to come up with a convincing reason to request a bounce on z/OS. This sits badly with the distributed platform, Java writing, "bounce it & see if that fixes the problem" mentality.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 13, 2010 5:53 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| You could, but even given the 24/7 reliability of zOS one tends to want to keep the cluster available during significant outages and not require that two LPARs be IPLed without requiring that one of them be up while the other is down. |
But if you have 2 LPARs, especially if hosted separately, you might consider this. I've seen scenarios where the Regression Test /Performance Test/Last Step before Live LPAR hosts the 2nd FR for production.
I've also seen 1 FR on z/OS, one on distributed. It's all about site architecture. I'm just sayin'
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Dec 13, 2010 5:53 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Vitor wrote: |
| bounce it & see if that fixes the problem |
Have you tried turning it off and on again? |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Dec 13, 2010 5:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| mqjeff wrote: |
| Vitor wrote: |
| bounce it & see if that fixes the problem |
Have you tried turning it off and on again? |
"Hello, This Is IT" 
I was actually asked once by a development manager if I could "bounce the mainframe", just to see if that fixed a problem they were having with the Windows based WAS they were working on. I didn't like the guy much so told him if he wanted to do the whole mainframe rather than just the mainframe queue manager he'd need to speak to the sys progs. Grumbling that "it's just development", off he went.
Then the chief sys prog went off on one. I didn't laugh. In front of anyone. 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 13, 2010 6:05 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
Technically (administratively) bouncing (restarting) a qmgr is no more difficult on z/OS as it is on any other platform.
The underlying issue for a z/OS qmgr is that it is likely that there are dozens, hundreds or thousands of connected apps (users) on a z/OS qmgr; and dramatically less on midrange qmgrs.
The 'z' in z/OS stands for zero-outages, meaning that there are near zero reasons to re-boot (IPL) a z/OS image. It is not uncommon to find a z/OS image with hundreds or thousands of end-users logged on/in to a single z/OS image.
z/OS is the mot robust and reliable of the platforms where WMQ runs, so it makes for an ideal FR.
_________________
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 |
|
|
| exerk |
| Posted: Mon Dec 13, 2010 8:09 am Post subject: |
|
|
Jedi Council
Joined: 02 Nov 2006
Posts: 6339
|
| bruce2359 wrote: |
| ...The underlying issue for a z/OS qmgr is that it is likely that there are dozens, hundreds or thousands of connected apps (users) on a z/OS qmgr... |
Hence my statement "...difficult to 'bounce' a queue manager on that platform..."
I've found that the biggest problem is not stop/starting a queue manager (unless it doesn't come back up of course! ) but dependent sub-systems?.
Big caveat here - I'm not a Mainframer (as you can tell) but I was informed the last time I needed a bounce of a z/OS-based queue manager that it couldn't be done as IMS would need also need a restart...
_________________
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 |
|
|
| Vitor |
| Posted: Mon Dec 13, 2010 8:17 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| exerk wrote: |
| I've found that the biggest problem is not stop/starting a queue manager (unless it doesn't come back up of course! ) |
Wash your mouth out with soap! Or better still, SOAP.....
| exerk wrote: |
| I was informed the last time I needed a bounce of a z/OS-based queue manager that it couldn't be done as IMS would need also need a restart... |
It's fair to say that because z/OS is highly available, there's a lot of cross-dependence between sub-systems. Because they don't expect one of their number to go down unless they're being deliberately closed, they expect to be closed at the same time.
As has been stated before, it's not that it's hard to bounce z/OS (restarting IMS is not a big deal any more than restarting CICS is a big deal), it becomes an issue with the number of users typically attached to the system and the impact on them as the queue manager (and related sub systems) are restarted.
As I've stated before, you also need a very convincing reason to make a z/OS person do this. "My application's acting funny" is never a good reason, especially if the application in question is not on the z/OS machine.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Mon Dec 13, 2010 11:15 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Big caveat here - I'm not a Mainframer (as you can tell) but I was informed the last time I needed a bounce of a z/OS-based queue manager that it couldn't be done as IMS would need also need a restart... |
It is not likely that a restart of a qmgr will require an IMS restart. It is more likely that some IMS app has MQ code in it; or that some MQ app has some IMS code in it. This is an application issue, and not an mq (or IMS issue.
_________________
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 |
|
|
| PeterPotkay |
| Posted: Mon Dec 13, 2010 5:44 pm Post subject: Re: z/OS in a MQ cluster |
|
|
Poobah
Joined: 15 May 2001
Posts: 7722
|
| Vitor wrote: |
A FR needs to be highly available. |
I've read comments from IBM MQ Cluster experts that specifically contradict that. If you have 2 and only 2 Full Repositories, why would either one *need* to be Highly Available? I'm not saying its a bad thing if they are, just that I don't think they need to be. If one goes down the cluster will continue to function just fine.
As to why you would not want your FRs on z/OS...one reason is that when it comes time to start upgrading MQ on all the QMs in a cluster, you want to upgrade the FRs first. In general, where is it easier to upgrade MQ - on z/OS, or on distributed?
So if you assume for a moment that a FR does not need to be Highly Available, and that it is easier in most cases to upgrade MQ on distributed versus z/OS, its not such a crazy discussion to choose between the following 2 options for your FRs:
Option A: 2 z/OS Queue Mangers that happen to also support a bunch of apps.
Option B: 2 dedicated Unix servers, possibly virtualized somehow to make the sell easier to the big wigs as to why you want two extra servers for your MQ cluster. These 2 virtual Unix servers (each hosted on 2 separate underlying host servers to eliminate single points of failure between the 2) each host a QM that each act as a FR and supporting no applications whatsoever directly.
In this comparison between z/OS QMs and virtualized Unix QMs, I dunno, I kinda like Option B.
If you could get dedicated z/OS QMs to act as your FRs with no apps on them, and you grew up on z/OS and never logged onto a Unix server, I could see how you would want your FRs on z/OS. And I could not say you were wrong.
I just don't think its as whacky as everyone initially thinks when someone chooses a non z/OS QM over a z/OS QM for a particular task.
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
|
|
