On Mon, Jul 7, 2014 at 8:03 AM, Paul Gilmartin <[email protected]> wrote: <snip> >>As I understand it, what happens is this: >> >>One: to run APF authorized basically means that the APF bit is set >>"on" in the JSCB. When you (or the initiator in the case of >>STEPLIB/JOBLIB) does an OPEN, the code in OPEN will look at each (or >>only) library concatenated to the DD being OPEN'ed. If _every_ DSN in >>the concatenation is marked as APF authorized, then OPEN will set a >>bit in the DEB for the open DD which says "this DD is APF authorized". >>Now, when you do a program fetch (LOAD/LINK/...), the z/OS code >>responsible for doing that will basically do: "IF JSCBAPF IS TRUE AND >>DEBAPF IS FALSE THEN ABEND S306". ... >> > I don't see the rationale of this design. IMO, a more rational design would > mark each extent entry in a DEB individually as belonging to an authorized > or to an unauthorized data set. Then the decision to S306 or not S306 > could be made based on whether the actual data set in which the module > was found was APF authorized. Why not?
I guess that would be possible. One "problem" is that the DEB does not have one entry per data set. It has one entry per extent per data set. It does not have any indication in the DEB entry relating back to a specific DSN. Just to an extent on a single DASD volume. (which is why we can have problems when another job extends a DSN while we are running. We don't know about the new extent.) But the real reason is that APF is _designed_ to be an "all or none" environment. Either the environment _is_ APF authorized or it is _NOT_. Every program which runs in an APF environment (TASKLIB is APF authorized and initial program is AC=1), runs with APF authorization _ON_. Even if it is (a subroutine and) marked AC=0 by the binder. One reason for this is that APF authorization is based on a single bit in the JSCB. In almost all cases, there is a single JSCB for the entire environment in which the program is running. That means that every task in the user's environment runs under a single JSCB (again, normally). This is why the JSCBAPF bit cannot be turned on and off, depending on whether the program running is AC=1 or AC=0. In a multitasking APF environment, one task could be running an AC=0 program while another task is running an AC=1 program. Should the APF bit be "on" or "off"? It must be both. But it can't be both (it is not a quantum variable <grin/>). IBM has decided that invoking a non-APF allowed program (resides in a non-APF library) in an APF environment is a system security and reliability problem. A possible solution to this would be an APF bit in each TCB, or even better, in each RB. The APF bit in the RB would be turned "on" if the JSCBAPF bit is "on" _and_ the program running is bound with AC=1. Hum, oh dear, what about if the code running was brought in with a LOAD macro and invoked with a SYNCH macro? Now, to set the RBAPF bit, the SYNCH macro would need to scan the load list to find out which program is actually running and whether it was bound AC=1. Oh, my, suppose that my main program is "intelligent" and "compiled" something into some GETMAIN'ed memory. Now there is not load list entry for the SYNCH to find. Well, I guess then we'd need to copy the current RBAPF bit to the new RBAPF bit in the RB for the SYNCH. Ouch, it is getting to be complicated. Which means expensive and difficult to program, and having more CPU overhead. I really wish that I knew exactly what Michael hopes to accomplish. As best as I recall, it was that he had an APF authorized TSO command, which was properly authorized. And he wanted to do invoke a "PROFILE NOWTPMSG". Which failed because the PROFILE command is not in the TSOAUTH command list. And there is not equivalent API to affect the WTPMSG setting. IMO, FWIW, is that if the user has PROFILE WTPMSG on, then my program should not turn it off. And vice versa. The simplest way to accomplish this is to just not do a WTO with ROUTCDE=11 on it. But, again, I don't know what Michael is doing well enough to know if this is reasonable. Perhaps he should use some other ROUTCDE, if it is his code doing it. > > -- gil -- There is nothing more pleasant than traveling and meeting new people! Genghis Khan Maranatha! <>< John McKown ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
