|
View previous topic :: View next topic
|
| Author |
Message |
Selva0202
New User
Joined: 17 Oct 2008
Posts: 18
Location: USA
|
|
|
|
Greetings,
I have a requirement to delete the datasets which are deleted logically, but presented physically.
Can someone let me know how to retrieve the list? 
-Selva |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello Selva and welcome to the forum,
There is no "logical file delete" on the mainframe - the file exists or it does not. It is very important to leran and use the correct terminology.
You may have introduced some inconsistency between the system catalog and the dasd - when bad things are done it is possible to have catalog entries with no file and files with no catalog entry.
These have nothing to do with REXX.
If you more clearly explain what has happened we may be able to offer suggestons on how you might correct the inconsistency(ies). |
|
| Back to top |
|
|
Selva0202
New User
Joined: 17 Oct 2008
Posts: 18
Location: USA
|
|
|
|
Sch,
Thanks for your attention in this,
Please find the below screen snap shot of the GDG version that are listed in 3.4
K.DB.DBP1.FDE2006D.CIN2006S.IC
K.DB.DBP1.FDE2006D.CIN2006S.IC.G5038V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6084V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6085V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6086V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6087V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6088V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6089V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6090V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6091V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6092V00
K.DB.DBP1.FDE2006D.CIN2006S.IC.G6093V00
I found 11 versions.
When Listcat the GDG, I've the Limit 10 as below.
GDG BASE ------ K.DB.DBP1.FDE2006D.CIN2006S.IC
IN-CAT --- SYS1.ICF206
HISTORY
DATASET-OWNER-----(NULL) CREATION--------1992.063
RELEASE----------------2 LAST ALTER------2008.299
ATTRIBUTES
LIMIT-----------------10 NOSCRATCH NOEMPTY
ASSOCIATIONS
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6084V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6085V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6086V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6087V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6088V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6089V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6090V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6091V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6092V00
NONVSAM--K.DB.DBP1.FDE2006D.CIN2006S.IC.G6093V00
NONVSAM ---- K.DB.DBP1.FDE2006D.CIN2006S.IC.G6084V00
IN-CAT --- SYS1.ICF206
What would be reason for this?
Is there a way to retrieve the list of datasets physically present but there is not catelog entry?
Your suggestions are valuable to me...!
-Selva |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
| Quote: |
| What would be reason for this? |
The group has been defined to have a limit of 10 and the last 10 are the generatons from 6084 to 6093. G5038V00 appears to be out of sync and is not under control of the gdg definition.
Are these datasets on dasd or tape/cart?
If they are dasd, you would need to look in the vtoc of the dasd volumes where they might have been allocated (i'd suggest you talk with the dasd storage management people).
If they are tape/cart, you should talk with the tape/cart storage management people as they will be able to tell you which of these datasets are currently on tape/cart.
How is this related to clist/rexx? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
The NOSCRATCH option will not scratch a DASD generation once it rolls off. The deletion of the rogue generation may be performed by HSM or whatever ILM software is used at your site.
If these are tape generations, they may be under cycle control of the TMS and will usually disappear at the next batch housekeeping of the TMS.
As suggested by Dick, go talk to your storage people who will be able to answer your site specific questions. |
|
| Back to top |
|
|
Selva0202
New User
Joined: 17 Oct 2008
Posts: 18
Location: USA
|
|
|
|
Okay, thanks for the valid inforamtion about 'NOSCRATCH'. I think you gave the permanent fix. 
Am tring to fix the problem right now we have.
To identify the list of generations that are not deleted from DASD/TAPE, though it had crossed its limit as specified in GDG.
I thought of doing the following
- Take the list of Generations under a GDG (LISTCAT) by searching the
key word 'NONVSAM' and write it in FILEA.
- Take the list of generations that are shown in 3.4 (Usually it shows more
than what we see when we listcat) and write it in FILEB.
- Compare these two files using ICETOOL
- If the generation exist in both the file then leave, else write it in the
NEWFILE.
- The NEWFILE will have the information about the generations which are not deleted even after the limit exceeded.
- Using IDCAMS delete all the files which had to be deleted.
Can we do the above thru REXX?
- Selva |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
I believe you have based your "fix" on misunderstanding.
3.4 uses the catalog (as does listcat) to retrieve the list of dataset names (unless you have specified some specific volume in 3.4). If you have datasets that have been "orphaned" (on dasd/cart but not cataloges) your approach will leave these files on the volumes where they reside as they will not be identified.
| Quote: |
| Can we do the above thru REXX? |
Yes, you can do pretty much anything with tso/ispf/rexx - all you have to do is write the code.
Sometimes it takes longer and is more error prone to write code for a one-time task. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
What do you get from
LISTCAT ENT('K.DB.DBP1.FDE2006D.CIN2006S.IC.G5038V00') ALL |
|
| Back to top |
|
|
|
|
