IBM Mainframe Forum

I would like to create Backup with PGM=ADRDSSU.
I'd like to use a DASD file (not tape because the backup is very small et it's every day. So i would like to save tape file by using DASD File).
With the tape fil, we used RETPD parameters, and CA1 managed it.
But with DASD file, CA1 can not managed the file beaucause it's not tape.

Si i have to create a daily JCL (by TWS) to delete the DASD File whne they will be expired.

I have two options :

1) Using IDCAMS with mask option



By running it every day, it will delete expired dataset btu not the unexpired one
i will have theis message for the unexpired one :

IDC3023I UNEXPIRED PURGE DATE
IDC3009I ** VSAM CATALOG RETURN CODE IS 84 - REASON CODE IS IGG0CLFM-0

But i will have many error messages like that. And surly, there is a IDCAMS limit for the number of file to delete....


2) The other option is Using ADRDSSU to delete file

By using Create date.

But to do this i have to put the Retpd parameters in the DSname file for example, if RETPD=45,
my file will be called :



to delete those file, i will use



I would like to have your advices about using the fisrt or second way to make it.

Thnk's for your help (and sorry for my english...)

The use of EXPDT or RETPD for disk data sets (not files) is discouraged in most mainframe shops. It really does not work the way most people seem to expect and it creates major storage management problems as it interferes with most normal storage management procedures.

Similarly, placing dates into data set names is also, usually, a poor idea. The mainframe has had, for more than 50 years, the concept of Generation Data Groups. For the most part this is far superior to placing dates into data set names, a *nix idea that is used because *nix does not have the concept of Generation Data Groups. Your out dated backups will automatically be deleted if they are created in a Generation Data Group; you don't have to do anything other than defining the Generation Data Group index properly. See this IBM article.

I use ADRDSSU so infrequently (on the order of less than once a decade) that I cannot comment on your using it to delete data sets by their creation date idea. I think I can guarantee it will not work if it is combined with expiration dates.

Further to Steve's reply: use ADRDSSU to do the dump. Dump to a GDG. Create the GDG without a RETPD but set your GDG up to hold at least 45 generations. Place those GDGs wherever your storage management group says. After that it is all automatic.

I too would prefer the GDG solution, though the ADRDSSU should work. Just keep in mind that if you run 2 backup jobs in one day then 2 GDS are created, so you must have exess number of entries in the GDG. Or make sure that you delete the newest created GDS if you have to rerun the job.
Whatever you do, forget the RETPD for dasd datasets.
You could of course set up a SMS management class, but that would be overkill.

Hello and thank's for your advices.
But RETPD=45 is an example. Moste of ou batch's production the RETPD=400

I know GDG but the maximum limit is 255. So for a 400 days retention is too low...and as you said, Willy Jensen, il the bacth runs twice a day, GDG can't be the solution...

Please clarify. You want to have your backup job handled the ame way as the production jobs? Do they create dasd datasets?, in which case I will assume a SMS management class that you could use too.

Hello Willy jensen,

yes it's production jobs.

ut there are jobs that runs many times a day.
So to save Tapes, we waant to use DASD dataset instead of tape with ADRDSSU.

Actually, we use that :



and i 'd like to use that :

samb01 wrote:I know GDG but the maximum limit is 255. So for a 400 days retention is too low...and as you said, Willy Jensen, il the bacth runs twice a day, GDG can't be the solution...

From z/OS v2.2, you can define "extended" format GDG's which allow up to 999 generations.

samb01 wrote:Hello and thank's for your advices.
But RETPD=45 is an example. Moste of ou batch's production the RETPD=400

I know GDG but the maximum limit is 255. So for a 400 days retention is too low...and as you said, Willy Jensen, il the bacth runs twice a day, GDG can't be the solution...

So what? You clearly stated that you want a limit of 45 for this application.

You want to save tapes? Are you not using virtual tapes? Who really cares how many pseudo tapes you're using?!

So if you are talking about production jobs, meaning many jobs, then I will recommend
1. extended GDG
2. proper SMS management class with HSM dasd housekeeping.
Actually I might exchange the order, because for (2) you do not have to change the datasetnames and create a bunch of GDGs.