ASG
IBM
Zystems
Cressida
Icon
Netflexity
 
  MQSeries.net
Search  Search       Tech Exchange      Education      Certifications      Library      Info Center      SupportPacs      LinkedIn  Search  Search                                                                   FAQ  FAQ   Usergroups  Usergroups
 
Register  ::  Log in Log in to check your private messages
 
RSS Feed - WebSphere MQ Support RSS Feed - Message Broker Support

MQSeries.net Forum Index » User Exits » User API exit alternative for z/OS?

Post new topic  Reply to topic Goto page 1, 2  Next
 User API exit alternative for z/OS? « View previous topic :: View next topic » 
Author Message
Jerry789
PostPosted: Fri Dec 16, 2016 8:54 am    Post subject: User API exit alternative for z/OS? Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Dec 16, 2016 9:43 am    Post subject: Re: User API exit alternative for z/OS? Reply with quote

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
View user's profile Send private message
Jerry789
PostPosted: Fri Dec 16, 2016 11:06 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Dec 16, 2016 11:21 am    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Dec 16, 2016 11:22 am    Post subject: Reply with quote

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
View user's profile Send private message
Jerry789
PostPosted: Fri Dec 16, 2016 12:03 pm    Post subject: Reply with quote

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
View user's profile Send private message
Vitor
PostPosted: Fri Dec 16, 2016 12:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
Jerry789
PostPosted: Fri Dec 16, 2016 1:50 pm    Post subject: Reply with quote

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
View user's profile Send private message
bruce2359
PostPosted: Fri Dec 16, 2016 1:51 pm    Post subject: Re: User API exit alternative for z/OS? Reply with quote

Poobah

Joined: 05 Jan 2008
Posts: 9394
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
View user's profile Send private message
Jerry789
PostPosted: Fri Dec 16, 2016 3:34 pm    Post subject: Reply with quote

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
View user's profile Send private message
fjb_saper
PostPosted: Sat Dec 17, 2016 2:44 am    Post subject: Reply with quote

Grand High Poobah

Joined: 18 Nov 2003
Posts: 20696
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
View user's profile Send private message Send e-mail
Jerry789
PostPosted: Sat Dec 17, 2016 5:30 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Sat Dec 17, 2016 6:54 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
Jerry789
PostPosted: Sat Dec 17, 2016 9:59 am    Post subject: Reply with quote

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
View user's profile Send private message
tczielke
PostPosted: Sat Dec 17, 2016 10:18 am    Post subject: Reply with quote

Guardian

Joined: 08 Jul 2010
Posts: 939
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
View user's profile Send private message
Display posts from previous:   
Post new topic  Reply to topic Goto page 1, 2  Next Page 1 of 2

MQSeries.net Forum Index » User Exits » User API exit alternative for z/OS?
Jump to:  



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
Protected by Anti-Spam ACP
 
 


Theme by Dustin Baccetti
Powered by phpBB © 2001, 2002 phpBB Group

Copyright © MQSeries.net. All rights reserved.