This may be off topic... I used SMP(/e) about 35+ years ago, I used to build CICS. I now get my z/OS from ADCD. I download some volumes and have an IPLable system. I could download the DLIBs if I wanted them. Is this the sort of direction we should be going in? If IBM was to provide the volumes every month/3months this might mean that people do not need to use SMP/E unless they need a hot fix, you just download the next set of volumes (or download the CICS volume(s), or the IMS volume(s)) I remember hearing one large customer talk about building a new system every month with all refreshed products on it (based on CST from POK). IPL it, and kill the oldest system. it meant one maintenance window a month - not one for CICS, one for IMS, one for z/OS etc. They said it improved up time, and saved a lot of sysprog time which they used for more testing. It was a brave new world! Colin
On Tue, 20 Jul 2021 at 17:51, Marna WALLE <[email protected]> wrote: > Hi Terri, > When adding an Software Instance that you already have (say, z/OS V2.4), > you are telling z/OSMF the CSI and zones to use. Those DDDEFs, presumably, > will be correct with the data set names, volumes, and paths. Those DDDEFs > will be used as a model on the incoming z/OS CSI DDDEFs. That will save > you hundreds of customizations to do for z/OS V2.5 and beyond. I've seen > many ServerPac saved configurations that are stale, and the CSI DDDEFs are > the correct and current values. Meaning, that the ServerPac saved > configuration can "drift" out of accuracy over time, but the CSI DDDEFs had > better not. That is what I mean by saving time. Especially when you are > basing on a known, accurate, SMP/E configuration. > > For the shipped configuration data sets (like CPAC.*): if you add those > data sets to that Software Instance, then those data sets can be modelled > too. If you choose not to, the worst thing is that the 16 CPAC data sets > shipped with z/OS V2.5, can be modified *en masse* within the z/OSMF > interface. Since they are all shipped with a HLQ of CPAC, it is very easy > to filter, select, move, rename them as a group. With the z/OS V2.5 > Software Instance, they then become known and can be modelled with future > z/OS Portable Software Instances. > > For the catalog: depending on what catalog options you want - new master > cat, existing master cat and the data set names you select - the existing > structure you have on your driving system can be used and detected, should > you wish to use it. If you want a new master cat, you will need to supply > the name and the temporary catalog alias of your choice (aka SSA), just > like in the old ServerPac. If you want all your data sets to begin with > "ZOSV25", and you have that existing HLQ alias going to an existing usercat > today, no problem, that will be used. If you want to create a new master > catalog, and use "MYSSA" as the temporary catalog alias, you'll need to > supply that, just like in the old ServerPac. The catalog structure, I see, > is similar to how the old ServerPac did it. Although, there is a lot more > flexibility, because you can rename any data set, and put it in any catalog > you want, with only VSAM (including zFS) forced to be cataloged. The old > ServerPac had lots of restrictions on what could be renamed, and where it > had to be cataloged. > > -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 > ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
