DATABASE DECREASE alternative

, , ,
1

Adabas (743 z/OS) manual says backup/decrease/adafrm (presumably deleting/redefining data sets across volsers first)/restore for decrease.

That will take too long. What’s more once adafrm then if backup media/hardware problems then you are totally ruined.

Is this alternative supported by SAG and/or used as best-practice by you good folk?

  1. backup
  2. decrease
  3. BR14 SHR,UNCATLG (or IDCAMS delete noscratch)
  4. IDCAMS define nonvsam vol=ser list (not including vol=sers being removed (which are not used according to FST).
  5. (optionally) backup again.

This is safer than deleting your production database from your expensive raid disk and becoming totally reliant on flimsy piece of tape in the CART.

Are there any issues doing this?

Is the EOF marker a consideration? IDCAMS will sort that out - yes? Or maybe its not an issue?

Comments from people who actually do this (or actively avoid it!) appreciated.

2

I had a couple of databases that I wanted to decrease. What I did was create a new database from scratch, with adafrm and adadef, do an adasav on the old database, and use adasav to restore to the new database. Run an adarep first on the old database and use it to create the adadef job.

If memory serves me, in the “adasav restore” I had to list each file with “adasav restore fmove=nnn”, because when I just did “adasav restore”, the adarep showed the database size as being the old database, not the new one. I guess the “adasav restore” copies the general control block as well as the files.

After doing this, just rename the data, assoc, and work, and try it. You can rename things back if there’s a problem. I thought it was a pretty safe way to go. In my adasav I use drives=4 and bufno=12, it made it complete in about 10% of the time (clock time) that it took without these parameters. Using these parms made the CPU% go quite high, but it was during off hours.

3

I had a couple of databases that I wanted to decrease. What I did was create a new database from scratch, with adafrm and adadef, do an adasav on the old database, and use adasav to restore to the new database. Run an adarep first on the old database and use it to create the adadef job.

If memory serves me, in the “adasav restore” I had to list each file with “adasav restore fmove=nnn”, because when I just did “adasav restore”, the adarep showed the database size as being the old database, not the new one. I guess the “adasav restore” copies the general control block as well as the files.

After doing this, just rename the data, assoc, and work, and try it. You can rename things back if there’s a problem. I thought it was a pretty safe way to go. In my adasav I use drives=4 and bufno=12, it made it complete in about 10% of the time (clock time) that it took without these parameters. Using these parms made the CPU% go quite high, but it was during off hours.

4

Thanks. I’ve used similar for creating test environments with a subset of files. Our db is too large to use that for decrease.

I did the decrease following the procedure in my original post. It worked just fine.