I didn't get any hits when I searched deja for
DSN1COPY dynamic allocation
so either everyone else had no trouble realizing that this happens or
nobody else has ever come across it.
I've used DSN1COPY for years for moving data between z/OS subsystems for
testing, and for refreshing tables from Image Copies for regression testing.
Developers seem to find it less confusing to use the same JCL to move data
between 1 of 14 test environments (x 4 migration levels) that they use for
backing up and restoring DB2 data within the same test environment.
Worked like a charm (using SYSXLATE) for years, until one of the tablespaces
went to a 2nd 2 Gbyte piece dataset. My first attempt, without a DSSIZE
parameter, ran out of space after writing 4 Gbytes of data. VSAM Extended
Addressability is not available using any of the SMS Data Classes at our
site.
Perhaps it is just me, but after hours of thinking about what the Utilities
manual says the only sense I could make of it was that the initial piece
dataset name specified on the SYSU1 DD statement would be used as a model
DSName for dynamic allocation of additional piece datasets, after writing
the number of bytes specified explicitly on the DSSIZE parameter.
That turns to be exactly what happens. It allocated the second piece dataset
dynamically to DDname SYS00001.
Did I miss a clue in the manual about this happening for Standalone Utiities
such as DSN1COPY? It never occured to me that this might happen, since the
first piece dataset has to be specified via JCL. I would have expected it to
be all dynamic allocation or all JCL, not a mix of the 2 allocation methods.
DSN1COPY dynamic allocation
so either everyone else had no trouble realizing that this happens or
nobody else has ever come across it.
I've used DSN1COPY for years for moving data between z/OS subsystems for
testing, and for refreshing tables from Image Copies for regression testing.
Developers seem to find it less confusing to use the same JCL to move data
between 1 of 14 test environments (x 4 migration levels) that they use for
backing up and restoring DB2 data within the same test environment.
Worked like a charm (using SYSXLATE) for years, until one of the tablespaces
went to a 2nd 2 Gbyte piece dataset. My first attempt, without a DSSIZE
parameter, ran out of space after writing 4 Gbytes of data. VSAM Extended
Addressability is not available using any of the SMS Data Classes at our
site.
Perhaps it is just me, but after hours of thinking about what the Utilities
manual says the only sense I could make of it was that the initial piece
dataset name specified on the SYSU1 DD statement would be used as a model
DSName for dynamic allocation of additional piece datasets, after writing
the number of bytes specified explicitly on the DSSIZE parameter.
That turns to be exactly what happens. It allocated the second piece dataset
dynamically to DDname SYS00001.
Did I miss a clue in the manual about this happening for Standalone Utiities
such as DSN1COPY? It never occured to me that this might happen, since the
first piece dataset has to be specified via JCL. I would have expected it to
be all dynamic allocation or all JCL, not a mix of the 2 allocation methods.