On Wed, 30 Sep 2020 20:35:11 +1000, Andrew Rowley wrote: >On 30/09/2020 6:03 pm, Seymour J Metz wrote: >> The DSS manual say that when you specify a directory, it does not dump the >> files under that directory. That's very different from the behavior of, >> e.g., tar. > >I guess I shouldn't be surprised, given how often IBM don't do things >the way I hoped. > It seems even less useful than the analogous DUMPing a catalog but not the associated data sets.
On Wed, 30 Sep 2020 08:09:12 +0100, Sean Gleann wrote: > >'...use 'pax'...' That's what we do now and it is precisely the thing I'm >trying to move away from. We have data files for a specific system that >consist of a 'z/OS files component' and a 'USS files component'. Both are >dumped in separate independent jobs, and we see a danger that the two >resulting 'dump' files could conceivably get out of synchronisation. > Ouch! But you need to assure likewise that the various "z/OS *files*" aren't out of sync with each other. Perhaps Flash copy of all the z/OS files *and* the z/FS *aggregate*. And you still may need to quiesce other operations in order to get a consistent point-in-time view. You need Logical Unit of Work encapsulation with a scope that DFSMS simply doesn't provide. Does it help to "pax -w ... >z/OS data set" and include that in the DUMP manifest? Same job; different step. This leads me to wonder about the co-isolation of PDSE DESERV and STOW DISC. Do those serialize in a way that ensures a consistent point-in-time view of PDSE membership by other jobs? Pipe dream: Logical Unit of Work isolation of multiple catalog updates replacing multiple data set entries in a manner that appears atomic to other jobs. -- gil ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
