On occasion, I tried the USS diff to evaluate my running /etc against a new serverpac version. And sometimes to compare the previous serverpac version with the new one.
The utility of this exercise varied. > -----Original Message----- > From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> On > Behalf Of kekronbekron > Sent: Tuesday, June 6, 2023 7:36 PM > To: IBM-MAIN@LISTSERV.UA.EDU > Subject: Re: Best practice for /etc and /var when upgrading > > Integrating git is not something we as customers need to take on ourselves > (for system upgrade workflows like this). > It's something best given in a polished manner by IBM, as a part of zOSMF. > And again, getting git ourself is another thing; so the suggestion on IBM > establishing a dependency on git (ex: for zOSMF's use) and working backwards > up to what is required. > Of course, they can choose IBM zOS Change tracker, but it's not free, and is > yet > another thing to learn. > As long as there's a solution that hides the complexities and delivers the > niceness in an interface, that'll be the way to go. > > CA's Mainframe/Chorus Software Manager was ahead of its time. > It or zOSMF needs to be far, far better today than CSM was years ago. > > - KB > > ------- Original Message ------- > On Wednesday, June 7th, 2023 at 7:56 AM, Mark Zelden > <m...@mzelden.com> wrote: > > > > I don't know git so I can't really comment. I did google gif diff and see > > what > you mean > > now by a patch. > > > > For one, it seems like overkill. Two, I don't have git diff on z/OS so > > somehow > I'd have to > > get all my existing /etc (and /var) out there to compare what IBM would put > out there > > that matches the /etc (and /var) you get with a new OS? > > > > To go back to my parmlib example, why would I need to compare > IPO1.PARMLIB sample > > members to my running parmlib members from a system I'm about to > upprade. > > The LNKLST, APF, SVCs, etc are are locally customized for my running system. > However, if > > a new sample member was introduced that could be used if I implemented > some new > > feature, then it may be nice to have that sample in my running parmlib with > the > > "merge" process or "IEBCOPY, no replace" if you will. :) > > > > Not really a good comparison because in this scenario the new parmlib > member would be put > > in the SMP/E target IBM.PARMLIB or in SAMPLIB, but it is the best I could > come up with > > right now. > > > > BTW, A better approach to what the OP said happened in his upgrade (done > by some > > 3rd party) is to not touch it at all and just use your existing /etc and > > /var for > your OS > > upgrade or a copy of it with documented required changes from the upgrade > workflow, > > just like you would handle required parmlib changes. > > > > Regards, > > > > Mark > > -- > > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > > ITIL v3 Foundation Certified > > mailto:m...@mzelden.com > > Mark's MVS Utilities: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht > ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI > juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483- > uHawPpVeYyZWlAbrCog_VLTF%24&data=05%7C01%7CGIBNEY%40WSU.ED > U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790 > c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u1zF6wTztHDEhj1jeBW4YCupjk > 1DpKQjwtgLZgrRxFI%3D&reserved=0 > > > > > > On Wed, 7 Jun 2023 01:53:40 +0000, kekronbekron > kekronbek...@protonmail.com wrote: > > > > > Consider, for example, you upgrade from Ubuntu 20.04 to 22.04, and > have updated the sudoers file. > > > When upgrading, you get a prompt showing a diff between the new > version and your customized version. > > > > > > And quoting a bit from your reply... > > > > > > > compare the distributed /etc to what you already have to see if possible > other changes > > > > may be desired. > > > > > > "compare the..." > > > > > > Normal diff, git diff... > > > > > > /untouched/etc/ > > > /custom/etc > > > > > > (git) diff against both to see what we customized. > > > create a patch > > > > > > /new-untouched/etc/ > > > /new-custom/etc/ > > > > > > Here, I'm saying /new-custom/etc/ can be created by doing a git apply of > the patch from earlier. > > > > > > I mean... creating patches is quite common to keep just the delta, on a > version-controlled repository. > > > > > > If it still doesn't make sense, it would be good to correct my > understanding... without being pointed to the git website :) > > > > > > - KB > > > > > > ------- Original Message ------- > > > On Tuesday, June 6th, 2023 at 9:29 PM, Mark Zelden > m...@mzelden.com wrote: > > > > > > > On Tue, 6 Jun 2023 03:15:46 +0000, kekronbekron > kekronbek...@protonmail.com wrote: > > > > > > > > > I do wonder... with git now available, and this being normal USS, > > > > > maybe > zOSMF can start formally adopting/requiring git. > > > > > Then, moving updates from these files onto newer versions is a matter > of applying git patches on the new ones, where possible. > > > > > Something that the zOSMF UI can accomodate. > > > > > > > > > > Do let me know if this doesn't make sense lol. > > > > > > > > No, that makes no sense. Think of /etc as the SYS1.PARMLIB for z/OS > Unix. Any customization to > > > > existing files should not be touched. That is why it only makes sense to > copy what's new into it > > > > and also compare the distributed /etc to what you already have to see if > possible other changes > > > > may be desired. I can't think of many required changes of the years but > when there are > > > > they are (or should be) in the migration manual or upgrade workflow for > current versions. > > > > > > > > Regards, > > > > > > > > Mark > > > > -- > > > > Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS > > > > ITIL v3 Foundation Certified > > > > mailto:m...@mzelden.com > > > > Mark's MVS Utilities: > https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Furld > efense.com%2Fv3%2F__http%3A%2F%2Fwww.mzelden.com%2Fmvsutil.ht > ml__%3B!!JmPEgBY0HMszNaDT!pk5HXJWpgjdGm1ZKxIR0jXpfieiYVx5kXcbXxI > juUxrbI5Q96ZNuTbnMoBubxwv4x6Hh483- > uHawPpVeYyZWlAbrCog_VLTF%24&data=05%7C01%7CGIBNEY%40WSU.ED > U%7C503456fbfcbe4365386708db67000c1a%7Cb52be471f7f147b4a8790 > c799bb53db5%7C0%7C0%7C638217022129812477%7CUnknown%7CTWF > pbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJX > VCI6Mn0%3D%7C3000%7C%7C%7C&sdata=u1zF6wTztHDEhj1jeBW4YCupjk > 1DpKQjwtgLZgrRxFI%3D&reserved=0 > > > > > > > > ---------------------------------------------------------------------- > > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > > For IBM-MAIN subscribe / signoff / archive access instructions, > > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > > > > > ---------------------------------------------------------------------- > > For IBM-MAIN subscribe / signoff / archive access instructions, > > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
