Frank The issue - the word used correctly for once! - with exits - or perhaps just one of the issues with exits - is that they, in effect, become part of the executing code of the "product". And the issue - still using the word in one of its correct meanings - with executing code is that somebody has to maintain it. When you buy a product, you buy a promise that it will do what the salesman said it can do. I presume - although it's not a situation I have encountered in my sheltered existence - that if a product happens actually to exploit an exit provided by another product - presumably with some sort of provision in the implementation that other products can also exploit the same exit - starting to get tricky isn't it? - the "promise" extends to the exit code.
If your installation considers implementing an exit, just as with any "in-house" code, a responsible function within the installation needs to "own" the exit code so that, even if the author is "let go", there will always be someone among the "suits" who takes care that the knowledge needed to support that little exit is also not lost - just as I would expect applies to massive application suites. It's because needing to establish that responsibility in an installation can become rather tricky that some installation do not even contemplate trying to deal with it - your installation seeming to be one. Actually this is an issue with which I - as I mentioned having had a sheltered existence - have not had to deal with directly but it's what I have picked up from those who have and I hope I picked it up more or less correctly. Incidentally, you may be a *new* z/OS application developer but are you not an *old* VSE application developer and isn't there a similar issue in the VSE world? - Interestingly enough regarding exits, VTAM offers some exits as documented in the SNA Customization manual, What's really interesting is that VTAM development has somewhat "muddied the water" by providing "sample" exits which become so popular that VTAM development actually committed to maintenance of the supplied "sample" exits. Two such exits are the ISTEXCCS and ISTEXCSD, essentially dynamic connection definitions - to some extent a function available without needing support from the exit since the exit was introduced - and dynamic LU definitions. There is even some sort of session management exit out there upon which I believe VTAM development smiles benevolently! - On review, I noticed you mentioned CICS. Didn't the CICS autoinstall function start as an exit for customers to use as they thought fit which got transformed into some standard code provided by CICS development - or something like that - not unlike what happened to those VTAM exits? Chris Mason On Fri, 15 Oct 2010 12:28:20 -0600, Frank Swarbrick <[email protected]> wrote: >As a new z/OS applications developer I'm curious as to what types of things use custom user exits et al for. From what I've heard from our sysprogs, our philosophy is to "never" use inhouse written user exits. Of course there are vendor supplied user exits, but the only inhouse user exit I know of that we use is CICS XDLIPRE, and that's only in our test regions. (And interestingly we just this week ran in to issues with XDLIPRE cause AUEP abends!) > >Frank ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
