I have enjoyed the thread started by Charles about his need to have one of his APF authorized programs invoke a non-APF program and do so with complete safety. As people here know, I enjoy coming in from left field (or maybe even the parking lot, at times). But "now for something compeltely different" in the way of an approach. It may well be overkill for Charles' need. It is a variation on what the TSO TMP does. I am assuming two things. First is that the code is running as a batch job, or a started task. That is, not TSO, IMS, CICS, or other. Second, the weird part, is that I assume z/OS UNIX is set up. Yes, this will make use of some z/OS UNIX facilities.
Here goes. The APF routine starts via the normal EXEC PGM=. As part of it's set up, it first DUBS itself as a UNIX process (BPX1SDD). Before doing anything else, such as OPEN'ing files et all. It does a BPX1FRK to "fork" and so get a second copy (child) of itself running in a separate address space. I have not done a test, so I don't know if the child inherits the APF authorization or not. If it does, the child will need to MODESET to key 0, flip off the APF bit, then MODESET back to TCB key (key 8, most likely). Now, the child just waits around for the APF parent to tell it to run something. The parent and child can share memory segments as needed using something like BPX1MAT or IARVSERV. What is nice is that the memory can be allocated in such a way as to isolate the shared memory from the rest of the parent's / child's memory space. So neither can accidently overwrite the others' memory outside of that area. And the mapping can be changed as needed. Of course, there will need to be some real work on infrastructure done should the child need to read a DD allocated to the parent. That is because the DDs are not propagated. What I would suggest is that the DDs be part of the parent. And the parent will OPEN them in whatever mode (READ or WRITE). For each DD, the parent will set up an unnamed bi-directional pipe. It opens this pipe before the BPX1FRK and the child reads or writes to it. This goes back over to the parent which is set up to read or write the proper DD. Yes, this is a lot of work. OTOH, perhaps the DSN / DD association could be passed to the child who would do a DYNALLOC. The child can run the required subroutine using the UNIX BPX1ATM (attach_execmvs) function. This function honors the STEPLIB environment variable. Or the child code could get the DSNs from the parent, do a DYNALLOC on them, OPEN the DD, and use the OPEN DD as a TASKLIB using a normal z/OS ATTACHX macro. Yes this is a lot of effort. And likely wildly overkill for most purposes. But it might be interesting in the case of a started task which needs to run untrusted "user" code on behalf of another address space. Just thinking out loud. -- If you sent twitter messages while exploring, are you on a textpedition? He's about as useful as a wax frying pan. 10 to the 12th power microphones = 1 Megaphone Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
