| Author |
Message
|
| MQ dummy |
 Posted: Tue Jan 27, 2015 8:31 pm Post subject: MQ support across two platforms by two seperate suppliers |
 |
|
Newbie
Joined: 27 Jan 2015
Posts: 2
|
My role is project management in an orgnaisation with many offices. Currrently one external provider supports MQ across the mainframe and three servers. Due to contractual issues the organisation wants to have the current provider support the mainframe side and bring in another provider to support MQ from the server end. My question is whether it is feasable to split support for MQ between the messaging start/end points? If the one provider cannot see the servers and the other the mainframe can either provider perform the MQ support role adequately? Many thanks
MQ dummy |
|
| Back to top |
|
 |
| PaulClarke |
| Posted: Tue Jan 27, 2015 11:17 pm Post subject: |
|
|
Grand Master
Joined: 17 Nov 2005
Posts: 1002
Location: New Zealand
|
Clearly the more an Administrator can see of the MQ real estate the easier it is for them to control the system and solve problems when things go wrong. However, your situation doesn't strike me as that different from two (or more) Enterprises communicating together and that works just fine. In fact, MQ is used extensively for inter-company communication as well as intra-company. In the inter-company case you clearly have two (or more) Administrators each only seeing a piece of the MQ network. The success or failure of this is probably how well the various administrators communicate with each other.
Cheers,
Paul.
_________________
Paul Clarke
MQGem Software
www.mqgem.com |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 28, 2015 5:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Basic MQ Administration security, and basic zOS security, will prevent group A from administering qmgrs 1,2, and 3 while letting group B administer them, and vice versa.
Depending on how solid your requirements are that group A not touch anything that's controlled by group B, you may have to implement more advanced MQ and platform security.
Also, I think you'll find that most distributed (non zOS) MQ administrators don't really know how to administer zOS queue managers. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 28, 2015 5:58 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
Also, I think you'll find that most distributed (non zOS) MQ administrators don't really know how to administer zOS queue
managers. |
Installation of MQ on z/OS is dramatically different from the Windows/UNIX MQ installation. Day-to-day admin tasks are quite similar across all MQ platforms.
_________________
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: Wed Jan 28, 2015 6:03 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
The z/OS security (via RACF) allows a much greater level of granulaity than on the distributed side. Most noteably, the z/OS install has no equivalent of the mqm "super user". So it's fairly easy to allow distributed administrators read access even to sensitive parts of the z/OS estate for trouble shooting or even limited tasks.
Even with total isolation it's feasible to have 2 teams doing support, and it's common for a specialist team to handle z/OS, given the rather specialised nature of the OS.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jan 28, 2015 6:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| bruce2359 wrote: |
| mqjeff wrote: |
Also, I think you'll find that most distributed (non zOS) MQ administrators don't really know how to administer zOS queue
managers. |
Installation of MQ on z/OS is dramatically different from the Windows/UNIX MQ installation. Day-to-day admin tasks are quite similar across all MQ platforms. |
What's a pageset? What's CMDSCOPE? What's QSGDISP? What's a STGCLASS and why do I need to ALTER it?
There are a hundred little things about zOS MQ administration that do not apply to distributed. |
|
| Back to top |
|
|
| zpat |
| Posted: Wed Jan 28, 2015 6:16 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
We have MQ links to 3rd parties and it works out fine. I occasionally have to ask them to do things, like reset sender channel sequence numbers etc.
It's very helpful to have a loopback queue (a remote queue my side sending to a remote queue their side sending back to a local queue my side).
That way I can test channel connectivity in both directions at any time.
For security you want the usual SSL precautions and make sure the receiver channel MCA user has restricted rights.
_________________
Well, I don't think there is any question about it. It can only be attributable to human error. This sort of thing has cropped up before, and it has always been due to human error. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Wed Jan 28, 2015 7:26 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| mqjeff wrote: |
What's a pageset? What's CMDSCOPE? What's QSGDISP? What's a STGCLASS and why do I need to ALTER it?
There are a hundred little things about zOS MQ administration that do not apply to distributed. |
I wouldn't categorize pageset and storage-class management as day-to-day activities.
_________________
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 |
|
|
| MQ dummy |
| Posted: Wed Jan 28, 2015 1:32 pm Post subject: |
|
|
Newbie
Joined: 27 Jan 2015
Posts: 2
|
| My sincere thanks to you all for replying. I think the note Paul made is a key point as to whether our organisation can split MQ support at the mainframe and server levels "..The success or failure of this is probably how well the various administrators communicate with each other..". and we will need to manage the relationship carefully and be clear with both parties as to what our expectations are, and, have clear escalation points where any problems/conflicts arise. Again thank you for your time and sharing your expertise - it has been most helpful. |
|
| Back to top |
|
|
|
|
