On Fri, 28 Jun 2024 16:25:35 +0000 Peter Relson <[email protected]> wrote:
:>Did this ever get resolved? I was away and could not respond at the time. :>I would have started by saying that the APF authorization of SYS1.CMDLIB is pretty much irrelevant. It might be necessary but it is not relevant to the abend. :>Simply put, the abend indicates that the issuer of an SVC that requires APF authorization (usually the MODESET SVC, but could be any SVC that requires APF authorization and there are a dozen or so) was not APF-authorized. :>So we need to backtrack to how that user was supposed to be APF-authorized. And the general answer for a TSO command is that TSO needs to have been "informed" that the PARMLIB command is to be processed in the authorized size of TSO. If it wasn't informed, then the command would run in the unauthorized side and you'd expect MODESET to get SVC 047. :>I would have suggested to look within the definition of what TSO is to consider as an authorized command. PARMLIB is documented as an authorized command (but I don't know if that is "built-in" or needs to be specified). It is in the IKJTSO* parmlib member in the AUTHCMD section. IBM places it there (with other commands) by default. My guess was that the wrong parmlib member was being used, but an IPL cleared it up and interest was lost. -- Binyamin Dissen <[email protected]> http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
