Hi Marna, Thanks for the response. So remembering my last serverpac install was 2.4 about a year ago, I am going by memory, but also from my past history.
There has always been issue, with a system upgrade, where I am re-using my existing catalog structure, but yet all forced IPL required datasets are not used. These are like CPAC. Datasets. This causes cataloging issues in a few jobs as they are "required". The way around this was to edit the job, change the names, etc and submit. The other thing and maybe I am missing it, was the SSA, I always used SYS1SSA. Which was prefixed to all my SYS1 datasets only. This caused issues with how jobs are built, because I used datasets, like CPAC.PARMLIB, etc and a template to copy things I might need for my upgrade in MY operational datasets. There are at least 2-3 times I had to edit JCL to "fix" these operational changes. Again I understand exactly where I want things and put datasets on alternate volumes just so I have them. I can see why the junior or someone without that experience you might not want to fiddle with layout, but I have gotten my process down to about 3-4 hours for my complete SERVERPAC install. I saved off my configuration, merged with the NEW configuration to any new datasets, changed the Logical to place the datasets where I want them and load. I also see the dataset where you build all the JCL and even though I hope I don’t have too, I could copy this dataset to a backup, edit my changes and submit outside of z/OSMF. Like I said you are forcing a learning curve just like SERVERPAC was eons ago, which I am okay with AS LONG as I don’t lose functionality or flexibility, or maybe under an ADVANCED TAB, use caution, etc. I have many thoughts. Just like you said, you should read my CPAC.OS240860.CONFIG dataset and merge the new serverpac information with it. Since many already do this, and it was a SERVERPAC staple, why not prompt the user for the information and once a user states NEW or UPGRADE, merge with their configuration??? Again maybe you do, but I get the feeling you are throwing that responsibility back, which then causes more time and learning curves.. Ms Terri E Shaffer Senior Systems Engineer, z/OS Support: ACIWorldwide – Telecommuter H(412-766-2697) C(412-519-2592) [email protected] -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Marna WALLE Sent: Monday, July 19, 2021 1:35 PM To: [email protected] Subject: Re: Serverpac installs January 2022 and beyond - Requests External Email Hi Terri, You are correct that within the z/OSMF interface, there is no way to edit a produced job for Deployment. It is intended that no editing is necessary, in that if you need to "tweak" the job, we should be providing that capability within the interface itself. The JCL produced should reflect what you want and also can be saved such that it can be reused for similar deployments, to avoid the same future tweaking. Did you have any specifics on what you wanted to change in z/OSMF, but couldn't? Realize that the data set configuration, volumes, and cataloging capabilities are extremely flexible and should be able to do whatever you want. Even more so than the old ServerPac ISPF dialog. For instance, you can rename any data set you want, put it anywhere you want, and the old dialog had some restrictions on certain data sets. Might there be something in the data set, volume, and catalog capabilities we are missing? I'd like to solve the editing-JCL problem, with a solution for you that allows you to incorporate your intentions right within the GUI much earlier, save that intention, and make it so that you never have to "remember" it again should you do a similar deploy of the product. (I can see how tweaks to the old ServerPac JCL would not be saved in the configuration, and then you would have a need to keep doing those tweaks in the future for every install. That is not the intention here with z/OSMF.) I believe the "work data set prefix" you are referring to is the temporary file system for use as SMPWKDIR on "Define Job Settings". Would you like more information provided for that description to help understand what you are providing? Maybe something like a "Learn more..." to quickly show with more details that we are asking for the beginning qualifier(s) of data set name, that is a temporary zFS (completely handled within the jobs and accurately sized) that will be used as the SMPWKDIR? This should be an easy thing to do, if it would help. On that same checklist location for "Define Job Settings", the jobcard can be supplied, and also the place where you want all the generated jobs saved (like we had in SCPPBENU). Of course, you could run the jobs from that saved data set from ISPF, but again, the intention is that they are run through z/OSMF so the interface can keep track of what you've done and how far you've gone. You could re-submit the same job again, from z/OSMF, should you wish. Or even indicate that the job is complete as your ran it from ISPF and you want to continue on. If I may suggest to all that will install z/OS V2.5 with z/OSMF, it really behooves you to define your prior z/OS release right now as a Software Instance. This will allow you to model z/OS V2.5 from that prior z/OS release and not have to re-specify hundreds of data sets and volume placement. This is very very similar to the old ISPF ServerPac dialog "save and merge configuration". You will still have some unique data sets to deal with, but it will be a lot fewer than the entire z/OS ServerPac. Of course, I'd do that with CICS, Db2, and IMS also. -Marna WALLE z/OS System Install and Upgrade IBM Poughkeepsie ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN ________________________________ [https://go.aciworldwide.com/rs/030-ROK-804/images/aci-footer.jpg] <http://www.aciworldwide.com> This email message and any attachments may contain confidential, proprietary or non-public information. The information is intended solely for the designated recipient(s). If an addressing or transmission error has misdirected this email, please notify the sender immediately and destroy this email. Any review, dissemination, use or reliance upon this information by unintended recipients is prohibited. Any opinions expressed in this email are those of the author personally. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
