GDG versions not being selected for backup/migrate

Randy Wood · New User Joined: 17 Apr 2014 Posts: 1 Location: USA

We have a problem with old versions of a GDG not being selected by SMS for backup/migrate because of contention with a job that is running to create a new version. This is a typical "Read version +0, write version +1 scenario. I've been told by our MainFrame support vendor that SMS will not select prior versions of a GDG for backup/migrate if the BASE is in use. This has created a real problem because of the dataset size (~15K cyl per version). Before we re-design the application or degrade performance by moving the dataset to tape I want to know if there is an alternate solution within SMS. Anyone run into this before? If so, how did you resolve it?

expat · Posted: Thu Aug 28, 2014 1:37 pm

Only once, same sort of thing with generations not being migrated.

Used a REXX job to follow the one creating the GDS to determine the generations that needed migration and then issue HMIG ML2 commands.

If backups are not being taken then the job can issue HBACKS WAIT, or use ARCBAKDS to take backups and then migrate.

Pete Wilson · Posted: Sat Aug 30, 2014 2:12 pm

I don't think it makes any difference if the GDS's are being AutoMigrated or Command Migrated, the same issue applies.

There is a PATCH for DFHSM that will allow Migration of GDS's where the base is being held but it does have some potential side issues so should be properly understood. I'm not sure if applies to Backup as well, but why backup GDS's anyway. Backing up a backup?

Read about the PATCH here:
http://www-01.ibm.com/support/docview.wss?uid=isg1OA24059
Issue the following patch command if you want to enable or
disable this alternate serialization method for migration
of GDS data sets:

PATCH .MCVT.+595 BIT(.....x..)
x = 0 old method of enqueueing is desired
x = 1 new method of enqueueing is desired (default)

I've had the same issue with DFDSS COPY and RESTORE where you're copying or restoring multiple generations of the same base from different jobs. Only way I found around that was to specify a reasonably long WAIT(x,n) value so it retries the restore.