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: http://www.mzelden.com/mvsutil.html > > > 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: http://www.mzelden.com/mvsutil.html > > > > > > ---------------------------------------------------------------------- > > > 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
