A long while back Chris wrote: >Scott said >> ... there are many <products> that 'front-end' <IEFJSREQ>, ostensibly >to >> provide that product an unvarnished view of what's flowing over the >SSI. >> >> The supported programmatic way to do this is to install a IEFJFRQ >program >> exit and ensure that your exit is always at the front of the queue. > >Aw c'mon Scott, using the dynamic exit facility is a no-brainer! >Ensuring that your exit is always at the front of the queue is a little >more challenging :-) > >Somebody has to be first and everybody else wants to be. The world might >end abruptly if their product wasn't the first to see what flows over >every last SSI call. > ><sigh> > >Some things change. Some don't.
And Shmuel added these 2 cents: >Sigh! What is the supported programmatic way to do this when there is >more than one program involved? They can't both be at the front of the >queue. > >The first rule of systems programming should be: whatever you're >doing, don't assume that you're the only one with a need to do it. And Scott took a long summer vacation and hasn't really looked back on the archives for a while so he's getting around to it now... Obviously there's no answer if more than one thing needs to be first. But I've seen plenty of dumps where various vendors all have stolen the vector to the SSI and replaced it with a call to their front end which of course was stolen by someone else's front end and so on... So, if you want to 'front end the SSI' and 'make sure you are first' you really need to do xx things: 1) Add your exit routine for the IEFJFRQ exit, specifying POS=FIRST. 2) Add an exit routine for the CSVDYNEX exit point. Watch for instances of programs attempting to install _their_ exit as POS=FIRST for IEFJFRQ. When this happens, signal an asynchronous process TO DO STUFF YOU SHOULDN'T DO IN THE EXIT ROUTINE Asynchronous process: When signaled, use CSVDYNEX to delete your current active IEFJFRQ exit routine. Then use CSVDYNEX to reinstall your exit POS=FIRST. Disclaimer: If two or more processes use this algorithm, the system will perform no useful work.. Of course, one can always alter the above algorithm to give up after some number of iterations (and inform TPTB of the need for multiple 'first' guys). Is that easy enough, Chris? Or is there a need to have a r/o exit point prior to the r/w exit point to ensure than anyone who needs to can see the SSI request before the unwashed masses get their grubby hands on it? Scott Fagen z/OS Core Technology Design IBM Poughkeepsie ---------------------------------------------------------------------- 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
