Joined: 22 Apr 2006 Posts: 6258 Location: Mumbai, India
Till yesterday everything was fine and, all of sudden, today they told us "'DELETE GDG, FORCE' Command" will be locked down in the LPAR I work.
When I asked them they say,
Unfortunately, much of the IBM documentation is not very clear on the hazards of using ‘DELETE GDG FORCE’ commands. The documentation extracts below all come from z/OS v1r9 IBM manuals.
The clearest documentation on the effects of ‘DELETE GDG FORCE’ commands are found in DFSMShsm manuals. We have highlighted key statements in red.
Here is a section from the DFSMShsm Implementation and Customization Guide (p. 398):
Access Method Services DELETE GDG FORCE Command
Assume that you have a generation data group with generation data sets that have migrated, and you wish to delete the group. If you use the Access Method Services DELETE GDG FORCE command to delete the catalog entries for the generation data group and its generation data sets, IDCAMS does not invoke DFSMShsm. You must then issue the DFSMShsm DELETE command for each of the now-uncataloged migration copies.
I really feel like a JCLM, not sure if some one has faced this already - would like to know what they think, is it a good idea, in real?
Joined: 14 Mar 2007 Posts: 8629 Location: Back in jolly old England
A lot of places restict the use of FORCE to storage and sysprog people.
One place they said it was because it focused the mind that you really did want to do this. For me it's not a problem as I have a REXX that will delete all of the generations and then the base definition.
As from a storage view, it is better that there are no uncataloged datasets held in the MCDS, however a HSM audit will highlight these datasets and offer the code to delete the HSM entries. On a downside, an audit can take up to 48 hours to complete.