IBM Mainframe Forum

There is a group here trying or creating 2 gdg datasets on the mainframe from FTP during the day for them to be picked up by the JCL that night or actually a little after midnight. They have tried different expiration periods but the gdg datasets seem to roll off or expire before the job can pick them up. Is this something related to Z/os. They have tried zero expiration date, 1 day expiration date, etc... and the datasets keep rolling off.
The class for the gdg on the mainframe is permanent and going to a permanent dasd pack. Any suggestions???

Thank you , Rick

Hello,

Suggest someone talk with the storage management people and confirm just what exactly is happening to these datasets.

What is the possibility that some other process reads the dataset using OLD,DELETE?

Why specify a short expiration? Suggest that the expiration be set to a week or more and when they are "picked up" by the nightly job, they can be deleted in the step that reads them. Several systems i've worked on have between a few and several hundred new generations cataloged throughout the day and when the "nightly" job runs, the entire gdg is read as input and deleted.

Suggest that a backup copy be made before these are intentionally deleted. . .

ROLLED OUT suggests that the LIMIT parameter may be too low, and that the base is defined as NOSCRATCH.

Also, when some products process a GDS they put it into the ROLLED OUT status. Look at IDCAMS ALTER to register the GDS as ROLLED IN

On both answers it seems like since FTP is creating a retention period that from what I've been told it has to by default that the operating system doesn't deal with it like it does a mainframe dataset created as a gdg.
On a retention of say 5 it won't let the mainfram job delete the gdg's after they are used so we'd bring them in again the next night.
On the retention of 1 yes it's rolling off too soon but anything over that then as stated we can't delete them off and clean up for the next night's processing.
I've never seen anything like this and it has to be FTP messing up what the operating system thinks it can do with the gdg datasets.
But I was thinking may if we did a backup as you noted as soon as the file get's here with RETPD of 1 then take those into the job that might work and let the operating system delete the gdgs in a normal way.

thank rick

Sorry and the GDG base is 15 and only 3 datasets are getting created.