Author |
Message
|
Mut1ey |
Posted: Fri Oct 30, 2009 2:00 am Post subject: Any experience of "Home Grown" API exits in Produc |
|
|
Acolyte
Joined: 07 Oct 2005 Posts: 74 Location: England
|
Hi all
I had asked the community about the IBM MirrorQ "sample" in a seperate topic, however it seemed that no-one was, or wanted to admit to, using this. So I shall make the question more general..
Is anybody out there using there own API exit code in a production environment? And if so, what experiences have they had?
Please note that I am not referring to 3rd party commercial offerings, such as those from Cressida, but any in-house developed or IBM sample based solutions.
Thanks |
|
Back to top |
|
 |
exerk |
Posted: Fri Oct 30, 2009 2:31 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Yes. I'm on a site where home-grown exit code is being used - or more accurately, being phased out. In this case it is being replaced by SSL, and the reason is because it is becoming unsupportable to maintain it, and the auto-definition exit it requires, across the number of platforms on which it is deployed. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
Mut1ey |
Posted: Fri Oct 30, 2009 3:17 am Post subject: |
|
|
Acolyte
Joined: 07 Oct 2005 Posts: 74 Location: England
|
Interesting - but one question - is that an API exit or a channel exit? |
|
Back to top |
|
 |
exerk |
Posted: Fri Oct 30, 2009 3:20 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
Sorry, channel. However, the principle remains the same - people move on, WMQ moves on etc., and it becomes difficult to maintain over time. _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bruce2359 |
Posted: Fri Oct 30, 2009 5:54 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
I'd be more specific and say that exits require a substantial amount of time to validate (and modify) as you migrate from one version and release or mq to another.
One exit seems to lead to another and another; extending the time-to-deploy.
The question I pose to management: do you want to change mq behavior (over and over), or change your business practice? _________________ 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 |
|
 |
Cressida |
Posted: Tue Nov 03, 2009 4:11 am Post subject: |
|
|
Disciple
Joined: 13 Jul 2007 Posts: 157
|
We do not agree with the API Exits are bad or taboo comments. It is true that one needs to know what they are doing and how and where and when ... but if you know what you are doing or you go get a professionally developed one, they do provide some added fucntionality and business benefits without changing the busienss logic and practice.
Granted that we at Cressida like them more than some because we have developed several tools around the API Exit (InQuest and SynQuest family of tools) that are professionally done, vendor supported, high performing, etc. .
When one gets a reasonably good vendor behind the Exit then the solution takes away the problem of coding and maintaining API code from the users. A fairly true and strong argument, we would suggest.
Cressida |
|
Back to top |
|
 |
exerk |
Posted: Tue Nov 03, 2009 5:46 am Post subject: |
|
|
 Jedi Council
Joined: 02 Nov 2006 Posts: 6339
|
And as I stated on the other thread - get commercially written ones and shift the responsibility  _________________ It's puzzling, I don't think I've ever seen anything quite like this before...and it's hard to soar like an eagle when you're surrounded by turkeys. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Nov 03, 2009 6:32 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
Deepest apologies. I had not intended to include vendor-supplied exits in my post.
When I was in my management phase, I required cost-benefit analysis of all work involved in deploying an application - including exits, open-source solutions, o/s modifications, etc.. If someone wanted this kind of not-out-of-the box solution, it had to be budgeted for purchase, and on-going maintenace.
This generally killed off in-house written exits in lieu of more traditional and industry-accepted solutions (like SSL, for example).
I have recommended a vendor-supplied authorization exit to clients who did not want to go to SSL at that point in time, but wanted to have some level of password and encryption to enhance their WMQ security.
My position is more clearly stated (I hope) as follows: If you are in the exit development business, you should be writing exits. If you are in the banking or insurance business, you should not be writing exits or o/s software or device drivers. _________________ 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 |
|
 |
zpat |
Posted: Tue Nov 03, 2009 6:38 am Post subject: |
|
|
 Jedi Council
Joined: 19 May 2001 Posts: 5866 Location: UK
|
Mainframes generally have a tradition of being highly customisable and supported by experienced Systems Programmers. This is part of the justification for the expense of mainframes.
I've coded loads of exits (esp for RACF) during my time in a financial services company and they proved extremely valuable, often doing what could not be done any other way.
There is less of a case for doing this on the more commodity platforms such as Unix and Wintel. |
|
Back to top |
|
 |
bruce2359 |
Posted: Tue Nov 03, 2009 7:07 am Post subject: |
|
|
 Poobah
Joined: 05 Jan 2008 Posts: 9469 Location: US: west coast, almost. Otherwise, enroute.
|
zpat: all that you say is true. I've written exits as well (my favorite was a CICS FC exit to call RACF to validate PADS - before RACF had PADS ... nostalgia).
Exits modity the normal/documented/expected behavior and functionality of the system-level code.
I do appreciate the value that exits can bring. The skill-set required to write and maintain exits is beyond most developers (as is demonstrated here in many posts). With the aging of mainframe sysprogs, there will be less and less of this skill set.
My argument against home-grown system-level code (and to some extent vendor-supplied code) is the long-term cost of support - and who pays for it. If management wants an exit, the project cost must include ongoing support.
Like the issue of cellphones on airplanes (what harm can one cellphone do?), one exit is far easier to manage than dozens or hundreds. _________________ 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 |
|
 |
|