Portal | Manuals | References | Downloads | Info | Programs | JCLs | Master the Mainframes
IBM Mainframe Computers Forums Index
 
Register
 
IBM Mainframe Computers Forums Index Mainframe: Search IBM Mainframe Forum: FAQ Memberlist Usergroups Profile Log in to check your private messages Log in
 

 

Need Info on Rolled off GDG's

 
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM
View previous topic :: :: View next topic  
Author Message
Pandipperumal R

New User


Joined: 13 Mar 2013
Posts: 5
Location: India

PostPosted: Tue Jul 30, 2013 7:29 pm    Post subject: Need Info on Rolled off GDG's
Reply with quote

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
View user's profile Send private message

David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Tue Jul 30, 2013 7:40 pm    Post subject:
Reply with quote

Why not delete the offending dataset?
Back to top
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Tue Jul 30, 2013 9:05 pm    Post subject:
Reply with quote

Hello,

If the job is to run 50 times a Day, why is the limit only 10?
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Wed Jul 31, 2013 1:14 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Pandipperumal R

New User


Joined: 13 Mar 2013
Posts: 5
Location: India

PostPosted: Wed Jul 31, 2013 7:23 pm    Post subject:
Reply with quote

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
View user's profile Send private message
dick scherrer

Site Director


Joined: 23 Nov 2006
Posts: 19270
Location: Inside the Matrix

PostPosted: Wed Jul 31, 2013 7:56 pm    Post subject:
Reply with quote

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
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Wed Jul 31, 2013 8:12 pm    Post subject:
Reply with quote

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
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Wed Jul 31, 2013 8:37 pm    Post subject:
Reply with quote

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
View user's profile Send private message
daveporcelan

Active Member


Joined: 01 Dec 2006
Posts: 645
Location: Pennsylvania

PostPosted: Wed Jul 31, 2013 8:42 pm    Post subject:
Reply with quote

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
View user's profile Send private message
David Robinson

Active User


Joined: 21 Dec 2011
Posts: 175
Location: UK

PostPosted: Wed Jul 31, 2013 9:45 pm    Post subject:
Reply with quote

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
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Thu Aug 01, 2013 2:29 pm    Post subject:
Reply with quote

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
View user's profile Send private message
expat

Global Moderator


Joined: 14 Mar 2007
Posts: 8593
Location: Back in jolly old England

PostPosted: Thu Aug 01, 2013 2:43 pm    Post subject:
Reply with quote

Pete, I should imagine that the other GENERATIONS shown are also ROLLED OFF
Back to top
View user's profile Send private message
don.leahy

Active Member


Joined: 06 Jul 2010
Posts: 642
Location: Whitby, ON, Canada

PostPosted: Thu Aug 01, 2013 5:16 pm    Post subject:
Reply with quote

Could this be a SCRATCH/NOSCRATCH issue? NOSCRATCH uncatalogs rolled off generations but does not remove them from the VTOC.
Back to top
View user's profile Send private message
Pete Wilson

Active User


Joined: 31 Dec 2009
Posts: 437
Location: London

PostPosted: Thu Aug 01, 2013 6:05 pm    Post subject:
Reply with quote

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
View user's profile Send private message
View previous topic :: :: View next topic  
Post new topic   Reply to topic    IBMMAINFRAMES.com Support Forums -> JCL & VSAM All times are GMT + 6 Hours
Page 1 of 1

 

Search our Forum:

Similar Topics
Topic Author Forum Replies Posted
No new posts IMS Database backup info ashek15 IMS DB/DC 14 Wed Nov 16, 2016 5:29 am
No new posts Utility to extract dsn info from conc... Lynne Schuler PL/I & Assembler 11 Tue Jan 26, 2016 6:36 am
No new posts print out the correct info in LOOP? jackzhang75 CLIST & REXX 7 Wed Dec 23, 2015 10:39 pm
No new posts Need info on SELECT statement subratarec DB2 7 Tue Jun 23, 2015 11:02 pm
No new posts Need info on QUIESCE utility in DB2 subratarec DB2 4 Fri May 22, 2015 12:30 pm


Facebook
Back to Top
 
Mainframe Wiki | Forum Rules | Bookmarks | Subscriptions | FAQ | Tutorials | Contact Us