On Tue, 17 Mar 2015 08:40:51 -0500, John McKown <john.archie.mck...@gmail.com> wrote:
>On Tue, Mar 17, 2015 at 8:18 AM, Shmuel Metz (Seymour J.) ><shmuel+ibm-m...@patriot.net> wrote: >> In <5c91d5e7-95b6-439d-87a7-111003a2f...@comcast.net>, on 03/16/2015 >> at 10:52 PM, Ed Gould <edgould1...@comcast.net> said: >> >>>Legally "no" but it can be done . >> >> You can, legally, turn APF off and later turn it off. It should be >> done the way porcupines make love: very carefully. > >IMO, it would be easier to just use ATTACHX with the JSCB= pointing to >a copy of the current task's JSCB with the APF bit flipped off. Of >course, the copy really needs to be in subpool 253 (key 0, below the >line). The OP might even want a TASKLIB= if he wants to do a DYNALLOC >to specify the DSNs to be searched, perhaps given in a configuration >file of some sort. OK, likely overkill in this case. Another >interesting parameter might be SZERO=NO to not share subpool zero to >avoid "memory leaks" if, as I have seen, the ATTACH'd program doesn't >bother to clean up all its memory because "the system will do that >automatically". I've especially noticed this in the past because CLOSE >didn't always free the I/O buffers when a DCB was closed. That still doesn't protect that APF-authorized program's key 8 storage from tampering by the non-authorized program. In other words, all that effort still leaves a major integrity hole open. Sharing your APF-authorized environment with untrusted code is _not_ simple, and even a complex implementation may not make it truly safe. -- Walt ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
