PDS 8.6 includes an update in place if the same size. Just schedule a job with the needed change commands. https://www.cbttape.org/freepds.htm
On Sat, Aug 1, 2026 at 6:32 AM Roger Lowe <[email protected]> wrote: > > zOS Change Tracker - https://www.ibm.com/products/zos-change-tracker > > Roger > > On Fri, 31 Jul 2026 13:20:04 +0000, listserv.ua.edu > <[email protected]> wrote: > > >I have multiple SYSPlexes in different data centers, none of which share > >DASD (some data centers have multiple SYSPlexes). All LPARs currently run > >zOS 3.1 which is fairly up to date regarding maintenance. > > > >I have a common PDS (PDS-E actually) which is a commonly named PDS. Let's > >call it AA.BB.CC . All updates to any member of AA.BB.CC should be via a TSO > >user via ISPF edit. Thinking about it, I'd also like to sync members without > >the ISPF timestamp, although if this occurred, not replace like members if > >they didn't have the ISPF timestamp, since there's no way to know which one > >is newest, > > > >The rule is, I have one LPAR where all of the updates should take place, > >although I don't want to depend on that. So all the updates should be made > >on LPAR A. But if someone did update a member on LPAR B in a different > >SYSSPlex, all of the PDS's would get that update as well. > > > >Is there something in zOS FTP, or potentially a product (IBM or vendor), > >which will allow me to "sync" the members? So that no matter which LPAR an > >update to a member happened, all the datasets would get the newest member? > > > >This wouldn't have to be simultaneous ... I can run scheduled batch on one > >or potentially all of the involved LPARS on all of the SYSPlexes on off > >hours. So if the "sync" occurred once at night, that would be sufficient. > >And all of the SYSPlexes are accessible to each other via TCP/IP. > > > >And yes, I could use RACF to lock out updating the dataset on LPARs wher it > >shouldn't be updated, although I'd rather not do that. > > > >Does anybody else do this or have tackled this before? I'm trying not to > >re-invent the wheel here. > > > >---------------------------------------------------------------------- > >For IBM-MAIN subscribe / signoff / archive access instructions, > >send email to [email protected] with the message: INFO IBM-MAIN > > ---------------------------------------------------------------------- > For IBM-MAIN subscribe / signoff / archive access instructions, > send email to [email protected] with the message: INFO IBM-MAIN -- Mike A Schwab, Springfield IL USA Where do Forest Rangers go to get away from it all? ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
