Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Clean-up the unwanted datasets
- Thread starter selva0202
- Start date
SJ: yes, this is almost certainly MVS or related.
selva0202: Does your DASD management software not handle this? This is really a system-level problem, and thus not within the realm of competency for an application-level language.
Frank Clarke
--Is it time for another Boston Tea Party?
selva0202: Does your DASD management software not handle this? This is really a system-level problem, and thus not within the realm of competency for an application-level language.
Frank Clarke
--Is it time for another Boston Tea Party?
oucheeeeee
Technical User
- Jul 8, 2008
- 9
I think more importantly, you need to stop this from getting worse by ensuring your GDG definitions are specifying SCRATCH instead of NOSCRATCH.
When you specify SCRATCH on your GDG definition, as soon as a generation rolls off the end (dependent on LIM=) it scratches the catalog entry as it rolls. This way, the generation rolls off the end and is deleted.
If you specify NOSCRATCH, the generation still rolls off the end of the GDG BUT IS NOT DELETED.
Before you decide to delete all these 'orphaned generations' you need to ensure that NOSCRATCH was defined by mistake (most likely, someone just copied someone elses definition without knowing what the keywords meant). Otherwise, you are going to be deleting what could be valid (audit req.) data.
To check the definitions - find the base on 3.4 (it will have ?????? for volume name as it is only a catalog entry not a dataset) - So if your Generation is say ABC.ABC.G01v0873, the base will be ABC.ABC
then LISTC ENT(/) ALL against that dataset - check the attributes to see whether it is SCR or NSCR?
The same command can be used to work out which generations are orphan
Cheers,
Ouch
When you specify SCRATCH on your GDG definition, as soon as a generation rolls off the end (dependent on LIM=) it scratches the catalog entry as it rolls. This way, the generation rolls off the end and is deleted.
If you specify NOSCRATCH, the generation still rolls off the end of the GDG BUT IS NOT DELETED.
Before you decide to delete all these 'orphaned generations' you need to ensure that NOSCRATCH was defined by mistake (most likely, someone just copied someone elses definition without knowing what the keywords meant). Otherwise, you are going to be deleting what could be valid (audit req.) data.
To check the definitions - find the base on 3.4 (it will have ?????? for volume name as it is only a catalog entry not a dataset) - So if your Generation is say ABC.ABC.G01v0873, the base will be ABC.ABC
then LISTC ENT(/) ALL against that dataset - check the attributes to see whether it is SCR or NSCR?
The same command can be used to work out which generations are orphan
Cheers,
Ouch
- Status