Run some test cases, at least one for an SMS volume, at least one for a
non-SMS volume:
List the catalog entry for the old DSN
List the catalog entry for the new DSN (expect failure)
List the VTOC for the old DSN
List the VTOC for the new DSN (expect failure)
Rename the dataset
List the catalog entry for the old DSN (expect failure for an SMS
dataset)
List the catalog entry for the new DSN (expect failure for a non-SMS
dataset)
List the VTOC for the old DSN (expect failure)
List the VTOC for the new DSN
Uncatalog the old DSN (expect failure for SMS dataset)
List the catalog entries for both old and new DSNs
Catalog the new DSN (expect failure for SMS dataset)
List the catalog entries for both old and new DSNs
Draw conclusions about who does what to whom.
Are any of the datasets VSAM in disguise, such as PDSE or ZFS?
> -----Original Message-----
> From: IBM Mainframe Discussion List [mailto:[email protected]] On
> Behalf Of Thomas David Rivers
> Sent: Thursday, April 13, 2017 9:31 AM
> To: [email protected]
> Subject: Re: unCATALOG after a RENAME
>
> Hmm...
>
> Now I have examples of SMS-managed un-CATALOG failing, and
non-SMS-managed
> un-CATALOG failing. But, I can't seem to reproduce the failure
in-house.
>
> I thought perhaps that my order-of-operations was wrong?
>
> Here's what the code is doing:
>
> RENAME (rename the file on the VTOC)
> CATALOG UNCAT (uncatalog the old name)
> CATALOG (catalog the new name)
>
> Is that not the proper order to do things?
>
> If it is the proper order, what is expected of that CATALOG UNCAT step?
> Should a failure simply be ignored?
>
> I've spent a few days reading thru DFSMS books and looking for
> examples; but
> haven't found a definitive answer to these questions. The documentation
> for RENAME in DFSMS Advanced Services doesn't seem to indicate that the
> un-CATALOG/CATALOG would be needed for non-SMS files, but seems like
> it would be?
>
> If someone has a pointer to some definitive doc on "this is the proper
way
> to rename a non-VSAM file" it would be much appreciated.
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
