A day late and a dollar short. :-) Although you did get me a REXX exec or two to help since ISFACR would not work in my sysplexes at all except a small monoplex. I didn't end up using them though as it turned out and starting from scratch and implementing security was a much better approach for me than converting ancient ISFPRMxx parms (that were originally assembled parms) into RACF definitions.
Shouldn't this APAR (or APARs) be rolled down to z/OS 2.4 considering z/OS 2.5 forces external security? The conversion / migration has to be done prior to z/OS 2.5. About about my experience with a large client environment: Mostly I had to worry about SDSF class profiles since OPERCMDS was protected in all my sysplexes. WRITER had a mix and JESSPOOL was protected on about half of 9 sysplexes. However, everyone pretty much had read access to everything in spool and only SYSPROGs and operators had "all" access, so that was not hard to figure out. One system had payroll jobs protected and I was all set up to implement that via RACF protection in JESSPOOL, but then I found out that payroll was not run on the mainframe in 15 years and didn't do it. For the SDSF part, I used ISF.SISFEXEC(ISFRAC) as a starting point and did everything from scratch keeping in mind all the things I read from the migration manual and some of the things I saw in ISFACR from the one monoplex it worked on. While this kept me up at nights for months when I found out after I started working on z/OS 2.5, after the first sysplex was done it turned out to not be "a big deal" since I had a good templates to work from. So I do recommend reading that migration manual and really understanding what this conversion means. One of my "lessons learned" for other or for future migrations, was to "read about destination operator authority" because JESSPOOL rules will not work as you intend and the ISFRAC sample enabled that for operators / sysprogs, I went from as many as 60 groups in ISFPRMxx in on sysplex down to 3 per the samples, but honestly you can get away one a single group as the parms are almost meaningless once you are using full external security or at z/OS 2.5. My 3 groups look the exact same in all my sysplexes except for DADFLT which I modeled after existing "sysprog", "operator", "other" groups in ISFPRMxx prior to conversion. Another thing I did was get rid of all hard coded panels / displays that were 20+ years old. Most were secondary displays so no one really noticed except that the defaults have mixed case column headings. One sysplex did have some primary panels and I had one group of users (print operators) complain right after the conversion that removed the custom panels, but part of the implementation plan included instructions on how to use "arrange", so in the end they were fine and agreed to leave it as is after I explained the benefits and the 20 additional fields they had their display now. (Even found a very old post from Skip Robinson explaining the same thing I told them). My only real complaint about all of this is that it caught me by surprise. The requirement was announced at the last possible time it could - the last quarterly announcement for z/OS 2.4 enhancements (I think) as a statement of direction. I always look at those announcements for enhancements but don't normally pay close attention to the statements of direction if in there. I would have thought something "this big" would have been in the z/OS 2.4 announcement in the "Statements of direction" section and that would have given me 2 years to plan and execute. As it was, for me it delayed z/OS 2.5 migrations for 6-9 months depending on the sysplex. Mostly in getting a game plan for all the sysplexes I was supporting and doing the first migration in a big sysplex outside of sandbox. Once I did the first one, the others were done within a few months. BTW, I did have 2 ACF2 monoplex LPARs to migrate also. I translated the ISFACR sample to ACF2 and Broadcom also had several documents / web pages about the migration. In some ways, they did a better job explaining it and simplifying it than IBM did. One last thing: I created all the RACF definitions and prep via PDS members to be executed at migration time. The RACF admins just had to type "ex" next to the PDS members. Part of the problem with this conversion is you need someone that understands SDSF ISFPRMxx / SDSF external security and RACF (or ACF2 / TOP SECRET). These days that is probably difficult in many shops. I work with a number of good sysprogs that are basically clueless when it comes to RACF (not a big surprise given separation of duties going back to the 1980s). Regards, Mark -- Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS ITIL v3 Foundation Certified mailto:[email protected] Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html On Mon, 4 Dec 2023 08:57:41 +0000, Rob Scott <[email protected]> wrote: >Peter > >The latest APAR for the new sample and REXX is : > >PH55420 > >Included is a starter set sequence f RACF commands to implement a simple SDSF >security setup assuming three types of users : sysprogs, operators and general >users. >Also included is a REXX exec that takes SDSF “NTBL/NTBLENT” statements from >ISFPRMxx and converts them to profile definitions for JESSPOOL resources. > >We find that the above is sufficient for most customers to get started. > >All SDSF presentations from Share and GSE can be found at the IBM education >github : > >https///github.com/IBM/IBM-Z-zOS/tree/main/zOS-Education/ > >Checktut the 2.5 and 3.1 folders and look for the “SDSF Security – How does it >work on z/OS 2.5+” slide deck. > >We also found that once customers understand what SDSF is doing under the >covers for the various panels and actions, the migration makes much more sense. > >I hope the above is helpful > >Rob Scott >Rocket Software > >From: IBM Mainframe Discussion List <[email protected]> On Behalf Of >Peter >Sent: Sunday, December 3, 2023 4:09 PM >To: [email protected] >Subject: Re: zOSMF install - SDSF ISFPRMxx > >EXTERNAL EMAIL > > > >Well I was ab e tf find a utility developed by rocket software ISFACR and >it helped me to generate some commands which were required as part of my >migration > >found that already my system had OPERCMDS enabled but other Classes were >not activated. > >The generated command also deletes the existing OPERCMDS profile which I >will skip and run others if it is required > > > >On Sun, Dec 3, 2023, 8:39 AM Peter ><[email protected]<mailto:[email protected]>> wrote: > >> Hello Rob >> >> Thank you so much for your response >> >> Could you please point to your presentation on migrating off from ISFPRMXX >> to RACF ? >> >> Fortunately our shop is very small and we don't have any archiving tool or >> any automation tool. >> >> Peter >> >> On Sat, Dec 2, 2023, 9:55 PM Rob Scott >> <[email protected]<mailto:[email protected]>> wrote: >> >>> Peter, >>> >>> Can I strongly suggest you instigate a project to activate OPERCMDS (and >>> JESSPOOL if not already active). >>> >>> ISFPRMx just controls actions within SDSF and does not preclude any >>> semi-capable programmer from writing code to issue operator commands (or >>> access SYSOUT using the JES SSI). >>> >>> Starting with z/OS 2 5, SDSF no longer uses ISFPRMxx to control security >>> as everything now only goes through SAF authority. We use the SDSF class >>> for product controls, and also make OPERCMDS and JESSPOOL checks on the >>> user's behalf when processing actions taken within the product. >>> >>> Please be aware that converting your systems to correctly use OPERCMDS >>> and JESSPOOL can be a lengthy process, and you should allow many weeks for >>> testing and validation. >>> >>> The OPERCMDS and JESSPOOL classes being activated can affect a broad >>> range of other products including sysout archiving and automated operations. >>> >>> I do have some presentations about SDSF security and can point you in the >>> right direction if you want. >>> >>> As a further note, the old ISFACR tool that was written 25+ years ago to >>> aid in SAF security migration is showing its age a bit. We have some more >>> recent (and much simpler) tools and processes now. >>> >>> Rob Scott >>> Rocket Software >>> >>> Sent from Samsung Mobile on O2 >>> Sent from Outlook for >>> Android<https://aka.ms/AAb9ysg<https://aka.ms/AAb9ysg>> >>> ________________________________ >>> From: IBM Mainframe Discussion List >>> <[email protected]<mailto:[email protected]>> on behalf >>> of Peter <[email protected]<mailto:[email protected]>> >>> Sent: Saturday, December 2, 2023 9:31:26 AM >>> To: [email protected]<mailto:[email protected]> >>> <[email protected]<mailto:[email protected]>> >>> Subject: zOSMF install - SDSF ISFPRMxx >>> >>> EXTERNAL EMAIL >>> >>> >>> >>> >>> >>> Hello All >>> >>> Good morning >>> >>> I have planned to install zOSMF in our test LPAR. Our SDSF uses its own >>> security features using ISFPRMXX and I can see zOSMF has its own IZUSEC >>> jobs where it activates OPERCMDS class. We never activated OPERCMDS >>> instead >>> we manage using ISFPRMXX PARMLIB member. >>> >>> Is there anyone who have installed zOSMF with above scenario? >>> >>> Peter >>> >>> ---------------------------------------------------------------------- >>> For IBM-MAIN subscribe / signoff / archive access instructions, >>> send email to [email protected]<mailto:[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<https://my.rocketsoftware.com/RocketCommunity/RCEmailSupport> >>> Unsubscribe from Marketing Messages/Manage Your Subscription Preferences >>> - >>> http://www.rocketsoftware.com/manage-your-email-preferences<http://www.rocketsoftware.com/manage-your-email-preferences> >>> Privacy Policy - >>> http://www.rocketsoftware.com/company/legal/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]<mailto:[email protected]> >>> with the message: INFO IBM-MAIN >>> >> > >---------------------------------------------------------------------- >For IBM-MAIN subscribe / signoff / archive access instructions, >send email to [email protected]<mailto:[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
