Usually when I did a new zOS upgrade I used the /var filesystem that shipped with that release, as well as the /etc file system. Made whatever necessary changes to the new /etc that we needed and moved along. Cloned the new /var and /etc file systems to each system in the sysplex.
Mark Jacobs Jesse 1 Robinson<mailto:jesse1.robin...@sce.com> February 9, 2018 at 2:41 PM Thanks. That seems obvious, but I generally use the SMPE dialog, which lists only one DDDEF at a time. I did a batch LIST DDDEF and found the same result: no reference to /etc or /var. I feel much better. OTOH I think we're remiss in looking for new or modified /etc or /var values in a new release to incorporate in our local file systems. Is this just a matter of IEYEBALL inspection? . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com<mailto:robin...@sce.com> -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jousma, David Sent: Friday, February 09, 2018 11:17 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: (External):Re: Best Practices for z/OS Maintenance Just did the LIST DDDEF. As suspected, there are no references in my V2.3 target zones for anything /etc or /var or /Service/etc or /Service/var _________________________________________________________________ Dave Jousma Manager Mainframe Engineering, Assistant Vice President david.jou...@53.com<mailto:david.jou...@53.com> 1830 East Paris, Grand Rapids, MI 49546 MD RSCB2H p 616.653.8429 f 616.653.2717 -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Jesse 1 Robinson Sent: Friday, February 09, 2018 1:32 PM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: Re: Best Practices for z/OS Maintenance **CAUTION EXTERNAL EMAIL** **DO NOT open attachments or click on links from unknown senders or unexpected emails** I would like to investigate this issue here, but I don't know how to find a DDDEF that might point to the /etc or /var file system. As I said previously, our /etc and /var file systems in production are 'permanent' in that they are not updated by our maintenance migration. But I am concerned about the situation on the (only) system where we actually run SMPE. . . J.O.Skip Robinson Southern California Edison Company Electric Dragon Team Paddler SHARE MVS Program Co-Manager 323-715-0595 Mobile 626-543-6132 Office ⇐=== NEW robin...@sce.com<mailto:robin...@sce.com> -----Original Message----- From: IBM Mainframe Discussion List [mailto:IBM-MAIN@LISTSERV.UA.EDU] On Behalf Of Art Gutowski Sent: Friday, February 09, 2018 9:53 AM To: IBM-MAIN@LISTSERV.UA.EDU<mailto:IBM-MAIN@LISTSERV.UA.EDU> Subject: (External):Re: Best Practices for z/OS Maintenance SMP/E LIST DDDEF will confirm that assumption. It's been a while since I've had to do z/OS maintenance, but I've learned not to take anything for granted with SMP/E, and especially with z/OS UNIX filesystems. IF you find any DDDEFs pointing to /etc or /var, they would need to be changed to some variation of /service as you hopefully do with your version FS. If you manage multiple target and distribution pairs, I highly recommend using automount to ensure SMP/E mounts the matching version root FS for the target zone and SYSRES. A colleague (who frequents this list), set this up at a prior shop of ours. It was not trivial. He had a ServiceLink Q&A open with IBM for weeks, and there was much discussion among the team and extensive testing. However, once the various maps were defined (we had to support multiple versions of languages as well), the DDDEFs were updated, and we modified our cloning process to keep up, everything worked flawlessly. IJS, I would not take the lack of errors as a golden stamp of approval. We were burned badly by this assumption - our SYSRES and version FS (and SMP/E) got out of sync, and we had no obvious indication. If memory serves, we had to dig through the SMP/E LOG (the job SYSOUT was probably long gone) to find that SMP/E had done exactly what it was told to do: apply UNIX elements to the wrong path/filesystem. Art ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu<mailto:lists...@listserv.ua.edu> with the message: INFO IBM-MAIN Please be alert for any emails that may ask you for login information or directs you to login via a link. If you believe this message is a phish or aren't sure whether this message is trustworthy, please send the original message as an attachment to 'phish...@meredith.com<mailto:phish...@meredith.com>'. -- Mark Jacobs Time Customer Service Global Technology Services The standard you walk past is the standard you accept. Lt. Gen. David Morrison This electronic message, including any attachments, may contain proprietary, confidential or privileged information for the sole use of the intended recipient(s). You are hereby notified that any unauthorized disclosure, copying, distribution, or use of this message is prohibited. If you have received this message in error, please immediately notify the sender by reply e-mail and delete it. ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
