| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Should z/OS have a "client only" edition? |
« View previous topic :: View next topic » |
| Would you migrate your MQ manager environments off the mainframe if a mainframe client environment was supported? |
| Yes |
|
25% |
[ 1 ] |
| No way |
|
75% |
[ 3 ] |
| Perhaps... |
|
0% |
[ 0 ] |
|
| Total Votes : 4 |
|
| Author |
Message
|
| fswarbrick |
 Posted: Thu Jun 04, 2020 4:37 pm Post subject: Should z/OS have a "client only" edition? |
 |
|
Apprentice
Joined: 07 Jul 2014
Posts: 42
|
As you probably know if you are reading this, MQ on z/OS only supports a full server installation. Unlike most other MQ environments there is no way for (most?) mainframe applications to connect from z/OS to a remote MQ environment (not even another z/OS MQ manager).
While I don't have the numbers ($$) of how much this would save, I have been asked several times if we can "move MQ off of the mainframe". My answer is always, no, not unless we don't have a need for mainframe applications to use MQ. The thing is, we only have one mainframe application that uses MQ. If not for the fact that there is no z/OS MQ client available I think we'd almost certainly have our MQ managers on Linux or Windows.
Note: It's my understanding, though I may well be wrong, that Java/JMS applications have their own client code that is not dependent on having an actual "MQ client binaries environment" installed. If this is true (I know its true for JDBC, so I may just be confusing the two!) then I imagine we "could" use "mainframe Java" to connect to a remote MQ environment. But we don't yet use Java at all (other than perhaps some vendor productions) on z/OS, and I can't see starting now.
I imagine there are a couple of reasons that there is no z/OS MQ client. Probably the same goes for DB2 (which perhaps not coincidentally we have the same issue with!!!).
- IBM believes, perhaps rightly so, that an average "mainframe shop" would always want to have MQ, DB2 and the like, local on the mainframe.
- IBM can charge more money for mainframe systems than for their corresponding "distributed" systems.
Are they justified? If you could have MQ off the mainframe but still access it from z/OS, would you do it? I find that we, as an IT shop and just as a business (non-IT) in general, always seem to find a way to go against the grain. Perhaps this is just another case of that. But if there were other shops in similar circumstances perhaps we could together push IBM to do this?
Maybe just a pipe dream... |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Jun 05, 2020 4:57 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
My 2 cents:
It makes no architectural sense to run dependent subsystems like MQ or DB2 somewhere other than z/OS while the principle application still runs there. When you keep it all in house, you have all the fault tolerance and high speed that z/OS provides. If you re-platform, then in the best case you've brought a network link into the equation while at worst you've got a z/OS application (which your business probably assumes is 100% reliable) downed while you're recovering a distributed component.
I get the cost argument and have heard it from a number of managers who've looked at the little boxes on the blueprint and wondered if you could move some of them. If the push is to reduce license costs, then re-platform the entire application stack. You cut the MIPS on z/OS, leaving that for "critical" applications (and how you define critical is a whole separate question) and running others on cheaper platforms.
If you don't want to get a bunch of new hardware, zLinux is a fun option. Running a queue manager to queue manager connection over Hipersockets is a good way to make the network people walk off muttering profanities.
Straying into the realm of herasy for a moment, you can also re-platform some applications & switch them from MQ to TCP/IP to communicate with their z/OS hosted partners. IBM's zConnect is intended for this use case and we've had good results with it.
Other opinions are equally valid and may be better.
No warranty express or implied is offered surrounding the IBM tools and architectural techniques described hereto nor on any opinion surrounding their fitness for any specific purpose or use case. No liability for loss or damage, direct or indirect, howsoever caused, is accepted. The value of your investments may go up as well as down, your mileage may vary and we're all trapped on the wheel.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jun 05, 2020 5:55 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9442
Location: US: west coast, almost. Otherwise, enroute.
|
If I understand this poll correctly, its sole purpose is to see if the presence/absence of a midrange-equivalent of a client-bindings library is important to z/OS MQ apps?
For my mainframe clients, this is a non-issue. The massively concurrent transactional server capabilities of z/OS they demand, plus the Java/JMS "everything is a client" model, makes the "argument" moot.
_________________
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 |
|
|
| elkinsc |
| Posted: Fri Jun 05, 2020 7:59 am Post subject: CICS Liberty profile |
|
|
Centurion
Joined: 29 Dec 2004
Posts: 138
Location: Indy
|
[z/OS]-based applications can connect as a client on or off platform. We have customers using clients in that environment, especially as some are moving applications that had previously run on other hardware to be under a more controlled environment.
The performance characteristics are, as you would expect, more unpredictable. That's true of any application requesting services from elsewhere, not unique to z - it just seems to come as a surprise to a lot of people. And of course we have already had customers connecting as a client to a z/OS queue manager from a CICS Liberty profile hosted application and discovering the joys of CHIN CPU consumption in poorly behaved clients. Again, nothing new about this.
Is it a good idea? Well really depends on the expectations of the application. |
|
| 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
|
|
|
|
