|
View previous topic :: View next topic
|
| Author |
Message |
Pandipperumal R
New User
Joined: 13 Mar 2013
Posts: 5
Location: India
|
|
|
|
Hi,
Issue background:
we are getting a job abend due to the GDG's being rolled out but not being removed from the catalogue.
for example, consider the following scenario
The GDG'S are in the following sequence.
abc.xxx.G1437V00- (this is a rolled off gdg which is out of sequence)
abc.xxx.G9418V00
abc.xxx.G9419V00
These gdg's are created by job which runs for more than 50 times a day,hence the limit is reached soon and when the current version of the file becomes abc.xxx.G1436V00 in the next cycle and when the job tries to create a +1 version the job is failing due to the below error
ALLOCATION FAILED DUE TO DATA FACILITY SYSTEM ERROR
UNEXPECTED CATALOG ERROR FOR DATA SET
abc.xxx.G1437V00
RETURN CODE IS 8 REASON CODE IS 8 IGG0CLA3
The GDG limit is 10 and it is created with noempty and scratch options.
Kindly let us know in case you require more information.
Thanks in advance. |
|
| Back to top |
|
 |
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
| Why not delete the offending dataset? |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
If the job is to run 50 times a Day, why is the limit only 10? |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 581
Location: London
|
|
|
|
Agree that you need to delete the rolled-off GDS. For IDC3009I RC=8,RSN=8 you get the following:
Explanation: A request to place a record by key into a
catalog resulted in a duplicate key error from VSAM.
Sounds like in appropriate use of a GDG. Wouldn't it make more sense to DISP=MOD to the file over the day and then copy the whole dataset to a single GDG at the end of the day, and zero out the MOD fle to start again? |
|
| Back to top |
|
|
Pandipperumal R
New User
Joined: 13 Mar 2013
Posts: 5
Location: India
|
|
|
|
I agree that we need to delete the rolled off GDG's.. but i have three main questions
1) why the rolled off gdg's are not deleted automatically ?
2) why the job is getting abended when it tries to create a + 1 version (as the rolled off version are no longer considered to be the part of that particular GDG) ?
3) what can be done to facilitate the automatic deletion of the rolled off gdg's. |
|
| Back to top |
|
|
dick scherrer
Moderator Emeritus
Joined: 23 Nov 2006
Posts: 19244
Location: Inside the Matrix
|
|
|
|
Hello,
One approach that should solve your issues/concerns is to use 2 gdgs or one gdg and a non-gdg.
The first has a +1 added as many times as needed thru the day. The limit would be set to 100 or whatever. It is not clear at all why 10 was used.
Once a day, the entire first gdg is copied to a new gdg or non-gdg that contains the entire day. The original generations are deleted as part of the consolidation copy. |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
1) What probably happened is the GENERATION abc.xxx.G1437V00 was being used by another process (or TSO user) at the time the next GENERATION (+1) was created that would have rolled off and deleted that GENERATION. Once that happens, it will NOT be deleted automatically.
2) Because that cataloged dataset name already exists. It can not create a +1 GENERATION with the same name.
3) They are automatically deleted, unless the GENERATION to be deleted is in use. You must manually delete this outlier.
You would be best served to re-evaluate your process based on suggestions above if this is a major issue for you.
Also if you note my use of GENERATION in all caps. This is so you notice it. Also notice I never used the term 'version'. Why?, it is not correct here. You need to understand the difference between the two, and never use the wrong term again.
Vegas line is, 2 to 1 against this. |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
| daveporcelan wrote: |
| 1) What probably happened is the GENERATION abc.xxx.G1437V00 was being used by another process (or TSO user) at the time the next GENERATION (+1) was created that would have rolled off and deleted that GENERATION. Once that happens, it will NOT be deleted automatically. |
This is interesting. I've just tried this and the behaviour is as you describe. An earlier generation was not deleted when a new (+1) was created as it was in use.
But I recall from working elsewhere that we had jobs waiting on datasets, trying to create a (+1) when DFHSM was migrating an earlier generation. I always understood that the enqueue was taken on the base. Is there a parameter setting that determines this? |
|
| Back to top |
|
|
daveporcelan
Active Member
Joined: 01 Dec 2006
Posts: 792
Location: Pennsylvania
|
|
|
|
David,
I do not know. I postulated the behavior and then tested my theory before posting.
Maybe the storage management experts can ring in here. |
|
| Back to top |
|
|
David Robinson
Active User
Joined: 21 Dec 2011
Posts: 199
Location: UK
|
|
|
|
The behaviour seems to differ depending on how the earlier generation is accessed. If it's a TSO user browsing the earlier generation, then a new (+1) is created and the earlier generation being browsed becomes disassociated from the group.
If the earlier generation is referenced in a batch job, then the job creating the (+1) will wait on datasets as the enqueue is taken on the base.
This explains the behaviour that I had seen previously with DFHSM, and perhaps, why the TS saw different behaviour.
Why there should be a difference I'm not sure. Perhaps someone more knowedgeable than be may have an idea? |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 581
Location: London
|
|
|
|
If DFHSM is migrating or recalling any generation from the base it enqueues on the base unless a particular PATCH is applied to DFHSM which prevents that happening.
I agree it's most likely that the rolled-off generation is probably a result of it being enqueued at a point where a new generation was being created and it prevented the older one being deleted.
Does seem a bit strange it's getting a duplicate key on G1437V00 when it is only up to generation G9419V00 though. |
|
| Back to top |
|
|
expat
Global Moderator
Joined: 14 Mar 2007
Posts: 8797
Location: Welsh Wales
|
|
|
|
| Pete, I should imagine that the other GENERATIONS shown are also ROLLED OFF |
|
| Back to top |
|
|
don.leahy
Active Member
Joined: 06 Jul 2010
Posts: 765
Location: Whitby, ON, Canada
|
|
|
|
| Could this be a SCRATCH/NOSCRATCH issue? NOSCRATCH uncatalogs rolled off generations but does not remove them from the VTOC. |
|
| Back to top |
|
|
Pete Wilson
Active Member
Joined: 31 Dec 2009
Posts: 581
Location: London
|
|
|
|
Don - the OP said it has SCR/NEMP specified - [quote]The GDG limit is 10 and it is created with noempty and scratch options
expat - you could well be right! Full LISTCAT would show that. Or a DIAGNOSE. |
|
| Back to top |
|
|
|
|
