Thanks Rob! That’s the explanation I needed! However, I did create a ISF*.** profile with a UACC of ALTER but it still didn’t work because I didn’t have NOFAILRC4 (I assume).
On Thu, Sep 21, 2023 at 2:52 AM Rob Scott <[email protected]> wrote: > Michael > > Although we strongly recommend JESSPOOL (and OPERCMDS) being active, you > can use successfully use SDSF without it. > > The big difference in z/OS 2.5 is that SDSF will no longer fall back to > any legacy ISFPRMxx authority keywords on the GROUP statements when SAF > returns RC=4. > > How SDSF handles SAF RC=4 (returned when the ESM cannot make a > determination - for example the class not active or no matching profile) is > governed by the AUXSAF(FAILRC4/NOFAILRC4) keyword on the CONNECT statement > in ISFPRMxx. > > The default value of FAILRC4 means that SDSF will translate RC=4 from SAF > into a "denied" response, whereas NOFAILRC4 will translate to "allowed". > > So you could keep JESSPOOL inactive and use AUXSAF(NOFAILRC4) on your > rescue system and this will help overcome most obstacles, however there is > another way : > > SDSF has the concept of "destination operator" within the product dating > back decades to the time when companies had print operations staff that > needed to manage individual destinations regardless of the output-creating > userid. > Profiles in the SDSF class of ISFOPER.DEST.destname would allow print > operators to manage output on individual destinations without specific > authority to the spool object. > > On top of individual destination authority, there is a profile > ISFOPER.ANYDEST.jesname in the SDSF class which, when the user has READ > authority, performs a RECVR handshake with JES on the JESSPOOL RACROUTE > request to grant access to the output. So you could permit your sysprogs > on the rescue system to this profile and keep JESSPOOL class active while > allowing you to implement other profiles so that it is consistent with > non-rescue system (if so desired). > > One thing to note is that JESSPOOL and OPERCMDS classes are not owned by > SDSF, we check profiles in these classes on the user's behalf to enhance > the user experience, however the owning components will make their own > authority decisions when SDSF passes thru any request for data/action (and > also when access is attempted outside of SDSF - for example from a SYSOUT > archiving product or automated operations). > > I do have a "How SDSF Security Works" presentation that is available on > IBM Education github : > https://github.com/IBM/IBM-Z-zOS/tree/main/zOS-Education/zOS-V2.5-Education > > > Rob Scott > Rocket Software > > -----Original Message----- > From: IBM Mainframe Discussion List <[email protected]> On Behalf > Of Michael Babcock > Sent: Wednesday, September 20, 2023 6:50 PM > To: [email protected] > Subject: SDSF and JESSPOOL > > EXTERNAL EMAIL > > > > > > We have a rescue system that we just brought up on z/OS 2.5. I > couldn't access SDSF so I defined the appropriate groups, modified > ISFPRMxx and restarted SDSF, logged off and back on. I could then get into > SDSF. I could NOT access ANY output whatsoever. I kept getting NO > DISPLAYABLE DATA. We did not have the JESSPOOL class active on that > system. Now the SDSF security migration guide says that JESSPOOL class > activation is not REQUIRED, but until I activated that class, I could > not access any output. Is the book wrong or did I have something not > quite set right? > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, send email > to [email protected] with the message: INFO IBM-MAIN > > ================================ > Rocket Software, Inc. and subsidiaries ■ 77 Fourth Avenue, Waltham MA > 02451 ■ Main Office Toll Free Number: +1 855.577.4323 > Contact Customer Support: > https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport > Unsubscribe from Marketing Messages/Manage Your Subscription Preferences - > http://www.rocketsoftware.com/manage-your-email-preferences > Privacy Policy - > http://www.rocketsoftware.com/company/legal/privacy-policy > ================================ > > This communication and any attachments may contain confidential > information of Rocket Software, Inc. All unauthorized use, disclosure or > distribution is prohibited. If you are not the intended recipient, please > notify Rocket Software immediately and destroy all copies of this > communication. Thank you. > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
