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 <IBM-MAIN@LISTSERV.UA.EDU> On Behalf Of Michael Babcock Sent: Wednesday, September 20, 2023 6:50 PM To: IBM-MAIN@LISTSERV.UA.EDU 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 lists...@listserv.ua.edu 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
