On 21 August 2018 at 08:23, Peter Relson <[email protected]> wrote: > 1) Is BRANCH=XM supported? > Ans: Since it is not in the books, no. That is the stock answer for anything.
Yeah, I know... Though there has been the occasional thing that has lacked only the doc, or is documented only in the macro, so worth asking. > If you need this function, then please submit an RFE. It's a would-be-nice. I can program around it. OTOH if it's been there for 15 years, is it really likely to go away? > You can probably get away with checking the JSCBAUTH bit. > There is actually a complex definition of the APF state, and that's what > MODESET checks. > Perhaps someone knows the history behind it. It appears to have allowed > for a lot of future extension that never happened. I do remember some decades ago speculating on the fact that while the linkage editor AC(n) option supports only 0 and 1, the result does go into a one-byte field in the LM/PO. Hints of Multics and multi-level privileges...? > 4) Design-wise, is there a reason that APF authorization of the caller > is not a criterion that can be applied when the PC routine is set up > with ETDEF? > Ans: Yes (for the most part). APF authorization is not a hardware state. > PC's (and things identified by ETDEF, in general) have no way of looking > at software-defined structures. You make a good point. I was thinking that SVCs can be set up in advance to accept or reject non-APF callers, but that of course isn't done by the hardware. And there is no "PC FLIH" analogous to the SVC one. I suppose JSCBAUTH could be copied to some known-to-hardware location, as various formerly software-only things have been over the years. But not in my lifetime, I suspect. Thanks, Peter. Tony H. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
