Despite this existing, for a 'hot topic/area' like this, I'm sure big shops will wait for official solutions from IBM/Broadcom/Rocket/etc.
Honestly, z/OS is an absolute marvel and it kills me to see werido solutions being built on top of z/OS, claiming to be the new interface to Z. Look at a few Ansible scripts for example... it's 100 times simpler to just script a solution with JCLs, REXX, and what-not. Instead, we have this monstrosity called ported Python with ZOAU, and then Ansible on top. YAML annoys me to no end. It's incredibly ridiculous to see a simple SMPE job being wrapped in layers upon layers of what-the-hell just so 'new people' can call it from Python and call it DevOps. Sorry, I don't mean to talk ill about people's work; it's just that it's hard to see this happen knowing that IBM and the mainframe software folks are capable of far more. - KB ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, August 6th, 2021 at 7:18 PM, Lionel B. Dyck <lbd...@gmail.com> wrote: > If you check out ZIGI (the z/OS ISPF Git Interface) it has an option to > support a 'Read Only' z/OS repository. This is a repository that is designed > to manage z/OS datasets (PS, PDS, PDSE) in Git but with the restriction that > updates to the z/OS datasets is prevented. It will identify updates to the > z/OS datasets and then copy the updates into the OMVS Git repository for git > management. > > Check it out at https://github.com/zigi > > Lionel B. Dyck <>< > > Website: https://www.lbdsoftware.com > > Github: https://github.com/lbdyck > > “Worry more about your character than your reputation. Character is what you > are, reputation merely what others think you are.” - - - John Wooden > > -----Original Message----- > > From: IBM Mainframe Discussion List IBM-MAIN@LISTSERV.UA.EDU On Behalf Of > Pew, Curtis G > > Sent: Friday, August 6, 2021 8:35 AM > > To: IBM-MAIN@LISTSERV.UA.EDU > > Subject: Re: Rocket's Git and GitHub Enterprise > > On Aug 5, 2021, at 11:32 PM, kekronbekron > 000002dee3fcae33-dmarc-requ...@listserv.ua.edu wrote: > > > > I periodically copy over the current libraries and push the changes to > > > GitHub. > > > > Do you mean push to GitHub and then 'build/deploy/copy over the current > > (PARMLIB) libraries using some build workflow? > > I have a script in my repository that runs commands like “rm sys1.parmlib/*; > cp "//'sys1.parmlib'" sys1.parmlib” (where “sys1.parmlib” is a directory in > the repository.) After running it I commit the changes and then push to > GitHub. > > > > It’s not perfect, but I can get some idea of when a change was made or > > > find an older version of a member that isn’t working right. > > > > > > Why is it not perfect, what would you want to work better? > > “Perfect” would be if git could manage the actual PDS(E)s, but that seems > like a lot to ask for. > > > ---------------------------------------------------------------------------------------------------- > > Pew, Curtis G > > curtis....@austin.utexas.edu > > > --------------------------------------------- > > 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
