|
View previous topic :: View next topic
|
| Author |
Message |
vizaiinti
New User
Joined: 08 Feb 2007
Posts: 11
Location: Hyderabad
|
|
|
|
I need to delete a GDG version using my JCL, existence of which i am not sure about. I.e, at times it may exist and at times it may not.
For a normal PS, i can do it using IEFEBR14 and MOD disposition like the following:
//DELETE EXEC PGM=IEFBR14,
//FILE02 DD DSN=USER.SHARE.AB47921.ADHOCTST.NORMALPS,
// DISP=(MOD,DELETE,DELETE),
// SPACE=(TRK,(15,15))
But the same when tried for GDG base version like the following, I'am facing the JCL error "DISP FIELD INCOMPATIBLE WITH DSNAME"
//DELETE EXEC PGM=IEFBR14,
//FILE02 DD DSN=USER.SHARE.AB47921.ADHOCTST.TSTFILE(0),
// DISP=(MOD,DELETE,DELETE),
// SPACE=(TRK,(15,15))
Please help. Any other utility other than IEFBR14 will also help. |
|
| Back to top |
|
 |
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
What reason is there to delete the zeroeth generation if it exists? IMHO, it should always exist (as well as some other generations) or this is not a good candidate for defined as a gdg.
It sounds like the process design is flawed.
If you explain what will be served by doing this this, we may have suggestions.
As you have mentioned, this works well for non-gdg dataset "housekeeping". If this is to be done, the dataset should most likely not be a gdg. |
|
| Back to top |
|
|
vizaiinti
New User
Joined: 08 Feb 2007
Posts: 11
Location: Hyderabad
|
|
|
|
Dick,
At times the job run may go erroneous(because of data in input file). In such cases we rerun the job, Before doing a rerun we delete all the files(inlucding GDG versions) that were created in the previous errorneous run. Hope this explanation helps. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
As i mentioned before:
| Quote: |
It sounds like the process design is flawed.
|
If you are going to create a new gdg entry during this process, i suggest that you validate the input before creating a +1 generation.
Without even seeing the enbtire process, i predict that if you "go live" with this scheme, it will cause long-term problems.
I also believe the original post is not quite on target. If the process ever completed successfully, there should always be a (0) generation from then on, so the "may or may not exist" should not be a consideration.
My recommendation would be to either discontinue the gdg for this particular use or change the process to create the +1 only on successful runs. You do not want to implement jobstreams that are confusing to run/re-run. |
|
| Back to top |
|
|
vizaiinti
New User
Joined: 08 Feb 2007
Posts: 11
Location: Hyderabad
|
|
|
|
Dick,
Lets forget about the design flaws. Talking technical, I just want to know how we can delete a current GDG version , logic should work irrespective of existence of versions. |
|
| Back to top |
|
|
enrico-sorichetti
Superior Member
Joined: 14 Mar 2007
Posts: 10873
Location: italy
|
|
|
|
| Quote: |
| Lets forget about the design flaws. Talking technical, |
I wouldn' t 
let' s look at the different scenarios...
NON EMPTY GDG SET
1) the job run and produced wrong results
the delete for gdg(0) will delete the right generation
2) the job run, for some reason abended,
the delete for gdg(0) will delete the right generation or the wrong generation
depending on how the jcl was written
... DISP=(NEW,CATLG,CATLG)
or
... DISP=(NEW,CATLG,DELETE
EMPTY GDG SET,
thats what You are complaining about
In order to avoid such a situation the best thing to do
is to allocate the new generation in the dubious jcl with
DISP=(NEW,CATLG,CATLG)
a gdg generation will be there ready to be deleted
still a hint of logic flaw is there ... what if ??? |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Quote: |
| It sounds like the process design is flawed. |
I think that "Missing" would be a better description  |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
Without wasting time testing a solution i believe is unsuited, i'll mention from memory that i do not believe you can delete dsn(0) via iefbr14. My memory is sometimes not 100%. . .
If you are determined to do this or something like this, you can create a list of all of the existing generations and generate jcl or idcams control info to delete the generation by the fully qualified dsn (i.e. dsn.g0123.v00). |
|
| Back to top |
|
|
mmwife
Super Moderator
Joined: 30 May 2003
Posts: 1592
|
|
|
|
| My guess is he's getting the error because you must allocate a "new" generation using (+n), n being > 0. When mod is used and a generation exists all works well and it gets deleted, if it doesn't exist "new" processing is attempted and you can't use (0) for a new GDG. |
|
| Back to top |
|
|
|
|
