| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Any Gotchas!? MQ for zLinux |
« View previous topic :: View next topic » |
| Author |
Message
|
| bruce2359 |
 Posted: Thu Jan 08, 2009 3:49 pm Post subject: |
 |
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| Distrust of these distributed programmers and the code they write. This distrust leads to the fear that they will somehow cripple the qmgr(s) which would practically bring the organization's production to a standstill until we recover. |
Is this a threat by the midrange programmers? Or are you saying that management doesn't trust midrange programmers? Both are easily resolved.
As to the other issue: Are you comparing z/OS to z/Linux? These are very different operating systems, with very different capabilities. Yes, IBM supports z/Linux; but z/Linux is not z/OS.
_________________
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 |
|
 |
| belchman |
| Posted: Fri Jan 09, 2009 6:30 am Post subject: |
|
|
Partisan
Joined: 31 Mar 2006
Posts: 386
Location: Ohio, USA
|
Its not management's distrust, it's mine. I am the one that is on the carpet if all access to a z/OS queue manager is blocked.
We have apps that will reconnect over and over if they get a 2033 without freeing the last conn... thusly they use all the conns and prohibit any more access to that gateway instance... I would hate to see that or something worse happen on z/OS.
If they do not understand that a 2033 is not an error, and if they do not understand why you have to free resources, I am nervous about connecting them to the z/OS qmgr... because if that is blocked, we are practically 100% down... if the block a gateway, we are < 100% down.
No I do not have the power to get that changed.
_________________
Make three correct guesses consecutively and you will establish a reputation as an expert. ~ Laurence J. Peter |
|
| Back to top |
|
|
| zpat |
| Posted: Fri Jan 09, 2009 6:50 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5867
Location: UK
|
This is really just a lifecycle quality control issue for MQ applications.
1. Document basic MQI standards, sample code etc. Educate developers.
2. Verify that any new application does not exhibit killer behaviour by inspecting the source code and/or observing it on a testing mainfame QM.
3. Promote only applications known to be safe into production.
Risking only part of your critical MQ infrastructure does not sound like a good idea - how about risking none of it?
This change of topology is your chance to insist on certain standards - take it. |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Jan 09, 2009 8:06 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
I am synpathetic with your plight. I worked at just such a place. This is politics at its best/worst; and has little to do with technology, as you have discovered.
I will argue that it is not your responsibility (fault) if bad applications deny service. The qmgrs are not yours, they belong to the organization. The same is true of applications - they belong to the organization.
On the other hand (or maybe not) I feel very strongly that it is your/our responsibility to protect our systems from badly designed and written applications. I have, in my sordid past, disabled quite a few applications. I further feel that we should not invent band-aid solutions that mask problem applications.
So, I push(ed) the problem back to those that created it. Of course, management and users would complain loudly and bitterly about my so-called interference with their applications.
My defense to management and users (offered quitely and level-headedly, and often in white-paper format) was/is that I am protecting the organizations IT infrastructure and valuable data. I added that programmers know how to write better code, but choose not to. If bad coding continues to put the revenue stream at risk, I am obligated by best-practice (auditor language) to intervene.
In my case, I found internal auditors looking for something to audit. The external auditors were always looking for something to justify their fees, too. I made use of their political clout to force the organization to do the right thing.
There is a cost associated with badly written code. Just look at your configuration. Why have many qmgrs when fewer will work?
_________________
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: Fri Jan 09, 2009 10:37 am Post subject: |
|
|
Poobah
Joined: 15 May 2001
Posts: 7723
|
Nowadays the MQ base code allows an MQ Admin to protect a z/OS QM from loopy MQ Client apps taking all the connections to the QM.
Back in the day, short of writing your own exit, there was no way to protect yourself.
The shops that do not allow direct client access are probably the ones that have had MQ on the mainframe from the early days, have the same MQ Admins, and have an alternate solution in place that works well enough (MQ Client Concentrator on a Unix / Windows server). In these cases, myself included, inertia more than anything else is preventing a change and allowing MQ Clients to go to the mainframe directly
_________________
Peter Potkay
Keep Calm and MQ On |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Sat Jan 10, 2009 8:18 am Post subject: |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9482
Location: US: west coast, almost. Otherwise, enroute.
|
| Quote: |
| This is really just a lifecycle quality control issue for MQ applications. |
Are you saying that midrange application developers held to a different standard than mainframe developers?
_________________
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 |
|
|
| fjb_saper |
| Posted: Sat Jan 10, 2009 10:19 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20767
Location: LI,NY
|
| bruce2359 wrote: |
| Quote: |
| This is really just a lifecycle quality control issue for MQ applications. |
Are you saying that midrange application developers held to a different standard than mainframe developers? |
I've seen disturbing behavior:
If it works half ways, slam it in, we'll worry about it if it breaks (first blame it on somebody else, environment, infrastructure) and change it (never, because it used to work (somewhat) so it's gotta be somebody else's fault) 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
|
|
|
|
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
|
|
|
|
