I thought the UNCOND DELETE PURGE parms could be used along with the COPY
command
On Wednesday, October 11, 2023 at 05:00:17 p.m. EDT, Mark Zelden
<[email protected]> wrote:
Hi all,
Please read / vote for this RFE.
"Provide abilty for DSS to be able to scratch and reallocate an in use data set
name that is not the actual dataset in use during a logical copy operation"
https://ideas.ibm.com/ideas/ZOS-I-3862
I think you vote here:
https://ibm-z-hardware-and-operating-systems.ideas.ibm.com/ideas/ZOS-I-3862
I was honestly shocked this is not supported in DFDSS. I've been using FDR for
over 30 years for this.
I don't know if you can see the entire text, so I will copy it below to explain
the issue, but in summary:
If you are copying a dataset to a maintenance sysres (target sysres that will
be cloned) and that DSN
is ENQd, the copy will work - unless the dataset needs to be scratched /
reallocated because the
input dataset is larger than the output one that already exists. I've been
supporting clients for
30 years that keep ISV (and IBM non-OS) products as an extension of the sysres
and recently
ran into this at a client that dumped FDR since they had DFDSS and ran into
this problem.
If you know a way around the issue - shoot! IBM says it is not supported. You
can delete the
not in use dataset after rename (if allowed) but that is error prone since you
have to point to
the maintenance volume and I don't want JR. people doing this. One other work
around is
after the logical copy fails, you can run it again as physical since the
dataset is enlarged
on the first try, but just fails in scratch. BTW, "CATALOG" is never used in
this copy since
the datasets are indirectly catalogged.
Now for the RFE main part of the RFE text:
-----------------------------------------------------------------------------------
Putting maintenance onto a "target" / maintenance sysres volume or set has been
an MVS concept and cloning an IPLable sysres set (or swapping IPL sets)
"forever" . Many shops also put other IBM products or ISV products on a
secondary / tertiary sysres and indirectly catalog them so they are on the
sysres set. This is the only way to support rolling IPLs in a sysplex so there
are not application outages (another MVS concept). Since those secondary /
tertiary volumes are a combination of products, adding new datasets is done
via logical copy of a product's target libraries to the target / maintenance
sysres and those datasets are indirectly catalogged using a system symbol like
&SYSR2, &SYSR3, etc. The copy to the "target" system (maintenance sysres)
works fine even if the same named dataset is in use on the live sysres set (be
it in the LNKLST, TSO PROC, STC STEPLIB etc.). EXCEPT... when the dataset
needs to be enlarged as part of the copy process. In that case you get message
ADR497E RC 102 Reason code FP-007 and "ERROR OCCURRED WHILE DELETING
UNCATALOGED DATA SET" and the copy for that dataset fails. However, the
dataset to be "overlaid" (if you will), is not the dataset in use so DFDSS
should have the ability to enlarge it and do the copy. The only solution is to
use the DFSMS special SAF authority to rename a dataset in use
(STGADMIN.DPDSRN.dsn_to_rename) to rename the "target" dataset on the
maintenance volume, then delete it, then rerun the copy job. This could be
very error prone if someone doesn't put in the correct volser on ISPF and they
could rename the "real" in use dataset or perhaps one on a different sysres
set.
-----------------------------------------------------------------------------------
Please vote this one up!
Best Regards,
Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS
ITIL v3 Foundation Certified
mailto:[email protected]
Mark's MVS Utilities: http://www.mzelden.com/mvsutil.html
----------------------------------------------------------------------
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
