I always kept a SERVICE copy of the filesystems that were IBM related and then applied and that is what SMP/E pointed to. Each shop usually has what works best for them, but below are the two main ways that I have done it.
1) Less Work, but Less Control (from SMP/E that is if someone bypasses SMP/E). Have a single set of RESVOLs, DLIBVOLs and USS Filesystem libraries that SMP/E points toward. If you have a stand-along Tech LPAR or Sandbox, have the ability to IPL from this only for validation, but I try to keep this just for SMP/E only! Share SYSRES and/or USS Filesystems where possible. Makes life a lot easier with maintenance. Have two copies per LPAR(s), that can be alternated between during IPLs. A lot of maintenance can be applied live these days; however, there are still ones that still required an IPL. Perform a DFDSS copy of the required volumes and filesystems from the SMP/E target to the LPAR(s) target. For USS, all configuration files, etc. that are normally in /etc & /var are never overwritten by IBM. The sample configuration files are what are updated and then you must apply those changes or merge your updates with the new samples, if required or needed. I also use a Company level filesystem, where you can override the default path, as this makes upgrades even easier. Most of the items that you put in /etc & /var can be overridden by parameters passed during execution or profile settings. 2) More Work/More SMP/E Control Have a Tech set of SMP/E SYSRES, DLIB and USS Filesystems. Applied all initial maintenance (RECEIVE, APPLY, ACCEPT) to this as normal processing Have a separate SMP/E SYSRES, DLIB and USS Filesystems per shared (or single) environment. Once maintenance is validated within the Tech environment, you can run SMP/E compares between the Tech and next environment to dynamically create the required SMP/E input statement to APPLY and/or ACCEPT as needed. For USS, same concept as the first method. The trick is to simply the process as much as possible without loosing control. The smaller the support team, the less SMP/E management you can allow. If you have people that don't follow the rules or too large (multiple teams, etc.) Allowing more control by SMP/E can save you a lot of headache with keeping things in sync. Thanks, Craig -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Tom Conley Sent: Thursday, February 8, 2018 21:07 To: IBM-MAIN@LISTSERV.UA.EDU Subject: [EXTERNAL] Re: Best Practices for z/OS Maintenance On 2/8/2018 3:22 PM, Seymour J Metz wrote: > SMP should not be pointing at the live Unix directories. The real question is > how to merge new/changed files in the target file system with production > files, whether in /etc and /var or elsewhere. > > > -- > Shmuel (Seymour J.) Metz > https://na01.safelinks.protection.outlook.com/?url=http:%2F%2Fmason.gm > u.edu%2F~smetz3&data=02%7C01%7CCraig.Pace%40FOTLINC.COM%7Cf70440474759 > 4fd459a508d56f6a2a02%7C899afa299b73498f8294e6528bc00a38%7C0%7C0%7C6365 > 37424132131227&sdata=NoTyURkvnydFn4sjbHcS0p%2F88l6ug%2BD1H47vbUUF%2By8 > %3D&reserved=0 > > ________________________________________ > From: IBM Mainframe Discussion List <IBM-MAIN@listserv.ua.edu> on > behalf of Dyck, Lionel B. (TRA) <lionel.d...@va.gov> > Sent: Thursday, February 8, 2018 2:36 PM > To: IBM-MAIN@listserv.ua.edu > Subject: Best Practices for z/OS Maintenance > > A question was asked what the best practices are for installing z/OS > maintenance to make sure that the /etc and /var files are not replaced by IBM > maintenance? > > (cross posting to MVS OpenEdition and IBM-Main Listservs) > > Thank you > I'm covering that in my Advanced SMP/E session at zTechU in Orlando and London, if IBM accepts the sessions. Regards, Tom Conley ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ________________________________ This communication contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it. ________________________________ ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
