Somewhere in our migration to z/OS 1.9 (pretty sure it wasn't this way on 1.7), our IEFUJV exit started getting invoked for OMVS address spaces. Since this exit tries to enforce TIME= and account numbers on job cards, it fails our OMVS address spaces.
We coded, in SMFPRM, SUBSYS(OMVS,NOEXITS) as a work-around. This solved the immediate problem but introduced another. Now, file predecessors in our job scheduling software don't work when the dataset is closed by FTP. The vendor confirms that they dynamically install IEFU83 for SYS, SYSJES2, and SYSTSO to monitor SMF records (14/15) to determine when a dataset has closed and mark the file predecessor complete. Coding SMFPRM to pick up the IEFU83 exit point for the OMVS: SUBSYS(OMVS (IEFU83) doesn't work because it seems to pick up IBM's IEFU83. We probably need to code the vendor's module name on an exit statement for SYSOMVS.IEFU83 and we're working on that, but I have had other questions: 1. If we let EXITS default at the SYS level, and we code EXITS at the SUBSYS level, SUBSYS seems to "inherit" the other exits when we do D SMF,O; is that correct? 2. If so, does that mean we need to code SYS(NOEXITS) and then SUBSYS (EXITS(IEFwhatever, IEFwhatever)) for each SUBSYS? 3. Some doc seems to imply that when multiple IEFU83 exit modules are defined, they _all_ get invoked. Which one's return code is honored? 4. Our exits are named IEFxxxxx because we've had them for years, from before the EXIT statement existed. Is current "best practice" to give them installation-specific names and add EXIT statements in PROGxx for them? Our ultimate goal is to make sure our IEFUJV doesn't get invoked for OMVS address spaces, but it's sure been confusing trying to figure out the hierarchy of the exits. ---------------------------------------------------------------------- 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
