>> EXIT REPLACE EXITNAME(SYS.IEFUTL) MODNAME(IEFUTL) >> DSNAME(SYS2.LINKLIB)
>This example implies that the new module is loaded from sys2.linklib. Which in turn means that the old exit (that probably had been loaded at IPL >into LPA) is still there in LPA, has just become inactive. It also implies that the new exit cannot be tested by setting a slip trap, for the simple >reason that the slip trap would find the old module that does not get executed anymore via the exit entry point. >Or has that changed with the replace support? Peter? The example goes beyond implying, to stating, that the new exit routine is to be located from sys2.linklib. It could have been loaded from any data set. And it does indeed imply that the old exit routine (rather than the "old exit", to be picky) is still there in LPA and will not get control any longer, at least once any current calls complete (whenever that might be). It does indeed imply that the new exit routine cannot be tested by a SLIP trap based on its name (it can be tested by a SLIP trap based on its address which can be determined, if needed, by DISPLAY PROG,EXIT,EXITNAME=xx,DIAG). As with any SLIP trap (or any CSVQUERY) or any normal LOAD, if LPA is searched, it will find what is there; that might not have any relationship to what is or is not an exit routine. A more typical approach would have been first to add IEFUTL to dynamic LPA, for example via SETPROG LPA ADD. And then the EXIT REPLACE would not need to have identified a data set. The benefit, as Barbara pointed out, is the ability to have diagnostic processes locate the new copy by its name. Peter Relson z/OS Core Technology Design ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
