| Author |
Message
|
| Jerry789 |
 Posted: Fri Dec 16, 2016 8:54 am Post subject: User API exit alternative for z/OS? |
 |
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
Hello,
I had succussfully created a User API exit to intercept MQPUT calls. Everything worked like a charm until I got a new requirment to support the same functionality on z/OS. The docs made me nervous...
| Quote: |
| Note: Not supported on IBM MQ for z/OS®. |
Could please anyone guide me what sort of exit or whatever could be used for the same functionality...e.g. intercept MQPUT call and based on some external condition (read via tcp socket) either allow the message to appear within destination queue or discard the message completely.
Many thanks |
|
| Back to top |
|
 |
| Vitor |
| Posted: Fri Dec 16, 2016 9:43 am Post subject: Re: User API exit alternative for z/OS? |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Jerry789 wrote: |
| Could please anyone guide me what sort of exit or whatever could be used for the same functionality...e.g. intercept MQPUT call and based on some external condition (read via tcp socket) either allow the message to appear within destination queue or discard the message completely. |
You need to give a bit more description around this. Why would you need such an exit, even on distributed? Under what sort of conditions do you discard the message and why can't it's arrival on the queue be prevented by more conventional means?
(Traditional MQ wisdom is that if the answer is a user exit, you're asking the wrong question. The perils of such a solution have been discussed many times here)
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Jerry789 |
| Posted: Fri Dec 16, 2016 11:06 am Post subject: |
|
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
| Well, I understand your point and the reason for writing such (existing) user api exit were really carefully evaluated. We wanted to dynamically change the behavior (hence the tcp communication to some other component) and also miminal impact on existing client application. So the question is, can such behavior be achieved with some other "exit" type or a similar technique which is supported on MQ over z/OS? |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 16, 2016 11:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Jerry789 wrote: |
| So the question is, can such behavior be achieved with some other "exit" type or a similar technique which is supported on MQ over z/OS? |
Nothing immediately springs to mind.
It really depends on the criteria you're using. If you're reading the status of a tcp socket it doesn't sound like you're filtering based on message content but on the status of some external system so messages are discarded when the external system on that port says to. Typically that requirement is met by having the external system programmatically put disable the queue (which is a lot easier than an exit) so I still feel you're going to get the best help if you expand a bit on why you settled on an exit.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 16, 2016 11:22 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
This is another good reason to avoid exits. No matter how well written, they've not exactly portable.... 
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Jerry789 |
| Posted: Fri Dec 16, 2016 12:03 pm Post subject: |
|
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
well disabling the queue is not an option (in our case) since the external app is putting another message into the queue (instead the original one). Anyway I'm aware that the productivity of developing an exit is several orders of magnitude worse than a usual client programming...
In our case we have all the infrastructure in place, just the last "piece" is missing for z/OS... |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Dec 16, 2016 12:13 pm Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| Jerry789 wrote: |
| well disabling the queue is not an option (in our case) since the external app is putting another message into the queue (instead the original one). |
Ok, try me with that again.
An external app puts a message into a queue. Your user exit decides to discard it based on the status of a port read. The external app then detects this (somehow) and puts another message onto the queue (which doesn't get discarded even though the port status won't have changed between the two puts? You never said the exit was looking at payload.
Unless you mean that the external application puts message type A onto the queue (which the exit will block) and message type B (which always succeeds). In which case a) you never said the exit was looking at payload and b) serves you right for mixing messages types on a single queue! 
| Jerry789 wrote: |
| In our case we have all the infrastructure in place, just the last "piece" is missing for z/OS... |
You're going to struggle for that last piece. No disrespect is intended, I'm sure you went through all due diligence before building the exit and it's your site on which you are the final arbiter of what gets done but IMHO you've painted yourself into a corner.
Someone smarter than me will probably be along with a solution momentarily.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| Jerry789 |
| Posted: Fri Dec 16, 2016 1:50 pm Post subject: |
|
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
| You're correct the exit is looking at the payload. I forgot to mention that... |
|
| Back to top |
|
|
| bruce2359 |
| Posted: Fri Dec 16, 2016 1:51 pm Post subject: Re: User API exit alternative for z/OS? |
|
|
Poobah
Joined: 05 Jan 2008
Posts: 9469
Location: US: west coast, almost. Otherwise, enroute.
|
| Jerry789 wrote: |
The docs made me nervous...
| Quote: |
| Note: Not supported on IBM MQ for z/OS®. |
|
It would help a bunch if you cited the precise URL, and quote the relevant details, instead of just a snippet.
Which version of MQ? Which version of z/OS? What programming language? Any details will help.
_________________
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 |
|
|
| Jerry789 |
| Posted: Fri Dec 16, 2016 3:34 pm Post subject: |
|
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
Per documentation
http://www.ibm.com/support/knowledgecenter/en/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q027920_.htm
| Quote: |
API exits let you write code that changes the behavior of IBM® MQ API calls, such as MQPUT and MQGET, and then insert that code immediately before or immediately after those calls.
Note: Not supported on IBM MQ for z/OS®. |
...it reads the same for MQ 7.5 to 9.x so I guess it's not a version specific behavior.
Per language...any "C" like language will be ok |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sat Dec 17, 2016 2:44 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
You could always create alias queues to be used by app A and app B.
The app then could put disable the alias q for app A and still put a message on the alias q for app B...
Don't know why you're hung up on using the actual queue... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| Jerry789 |
| Posted: Sat Dec 17, 2016 5:30 am Post subject: |
|
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
well, there are 3 parties, existing producer (app A), existing consumer (app B) both A and B could not be altered. The task is (based on some other external condition) to alter the message the B gets. Hence we developed the 3rd party (C) which consists of api exit awaiting for message from A and if such message should be modified it sends the payload via other mechanism (e.g. tcp) to app C which then puts modified message to be consumed by app B.
This worked fine, until we have a requirment to perform the same approach on z/OS which does not support user api exits.
Using queue alias with put disable whould not allow us to read the actual payload from app A |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Dec 17, 2016 6:54 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
For the z/OS requirement, can you leverage a distributed queue manager between A and B? Even if A and B are both bindings applications that live on z/OS, you can configure extra hops with MQ to send the data from A off to a distributed queue manager for inspecting (with the API exit) and then back to z/OS for B. I know this is not pretty or ideal, but neither are the requirements you are having to work with here.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
| Jerry789 |
| Posted: Sat Dec 17, 2016 9:59 am Post subject: |
|
|
Novice
Joined: 16 Dec 2016
Posts: 11
|
re: distributed queue manager, if I take it, this would mean running another queue manager on a supported platform, right?
Well, that looks like a last resort workaround. Thanks for the idea, I was not aware of this.
Anyway, I presumed (maybe wrong ) that reason for user api exits not being supported under z/OS is due to some other mechanism available and not meaning just complete lack of this functionality... |
|
| Back to top |
|
|
| tczielke |
| Posted: Sat Dec 17, 2016 10:18 am Post subject: |
|
|
Guardian
Joined: 08 Jul 2010
Posts: 941
Location: Illinois, USA
|
My understanding is that z/OS does not offer an alternative to the API exit that exists in distributed. This is one of several examples (e.g. message segmentation, application activity trace) where z/OS is deficient in matching the MQ functionality on distributed.
_________________
Working with MQ since 2010. |
|
| Back to top |
|
|
|
|
