Configure your backup job to write to a non-GDG PS disk backup.
Once the backups are done, copy them to a GDG on tape.
The next day, overwrite the PS disk backup.
Our job using ADRDSSU:
//CPYADRDS PROC HLQ=xxxxVLT,VOL1=DUMMY,GENI='(00)',TYPEI=W,
// PREFIX=xxxxVLT,TYPE=W,GENO='(+1)',DISP1='NEW,CATLG,DELETE',
// EXPDT1=90006,UNIT1=DCART,LABEL=001,
// LIB=xxxxxxx.PARMLIB,MEMBER=CPYADRDS
//************ xxxxxxx.PROCLIB(CPYADRDS)
//STEP1 EXEC PGM=ADRDSSU
//SYSPRINT DD SYSOUT=*
//ITAPE DD DISP=SHR,DSN=&HLQ..&TYPEI.&VOL1.&GENI
//OTAPE DD UNIT=&UNIT1,LABEL=(&LABEL,SL,EXPDT=&EXPDT1),
// DISP=(&DISP1),DSN=&PREFIX..&TYPE.&VOL1.&GENO
//SYSIN DD DISP=SHR,DSN=&LIB(&MEMBER)
COPYDUMP -
INDD(ITAPE) /* DUMP TAPE TO BE COPIED */ -
OUTDD(OTAPE) /* NEW DUMP TAPE */
On Tue, Sep 24, 2013 at 5:38 AM, J.P. <[email protected]> wrote:
> Hi everyone and thanks for your creative feedback!
> (sorry for a late reply, I was AFK for a few days..)
>
> So, a few more details about the environment and what problem we're trying to
> solve here:
> Data sets from several sources are produced in a PIT backup process (mostly
> image copies from DB2) to DASD and then to tape. DASD resource constrains
> began to be a problem, as the volume of backup data grew (same old story..).
>
> The goal here is to optimize the process so only the latest backup remains on
> dasd (as much as possible).
>
> The idea with HMIGRATE is that it can be included in the backup jobs, in a
> way that a HMIGRATE command can be sent to HSM before starting the new backup
> of one "component" ("start migrating all old data sets with this name
> template and also start writting the new backup").
>
>> What version of z/OS are you on?
> Hi Liz, we're on V1R12.
>
>> If you want parallel processing, why not use DFDSS or FDR software to do the
>> backups to tape?
> DFDSS puts the control of tape management and data into user space (AFAIK,
> with no TMS). The requirement is that it should be handled by HSM. FDR is not
> available.
>
>> HSM will issue a backup when the data is changed. And AUTOMIGRATION can
>> occur in a manner you might require.
> It's a PIT backup, so different data set names are also a must.
> AUTOMIG is a bit tricky (see below)
>
>> Hi, are you using the WAIT or NOWAIT option?
> Hi Glen, we've tried using NOWAIT (the default).
>
>> I think he wants to run wide on the migrates. So if he submits 10 migrates,
>> he wants them to run concurrently.
> Completly right Liz.
>
>> How many tape drives does he have in his shop.
> Eight, so that would be 4 parallel migs with duplex tapes.
>
>> All he has to do to make that happen is assign a Management Class which will
>> migrate to ML2 after 1 day of non-use.
> Hi David, this is also a bit tricky as with AUTOMIG (see below).
>
>> The OP's statement seems a perfect fit with GDG processing
> Hi Graham, wouldn't that complicate the restore a bit (restore that data set,
> from that tape, from that label) ?
>
> Why not use automatic migration (or letting HSM do what it was designed to
> do:) ?
> Because the backup itself doesn't have a fixed time - it depends on other
> things, and is submitted manualy.
> Also, changing AUTOMIG. or MAXMIGTASKS parameters to suite the backup is
> tricky, because you can't specify them (for an example PRIMARYSPMGMTSTART)
> for a certain day (AFAIK) and putting REQUEST param. for operators to respond
> to is an overkill.
> If AUTOMIG. runs too early - there will be lots of backup data sets that are
> on tape only
> If AUTOMIG. runs too late - DASD will run out of space
>
> There wasn't a problem when DASD could hold 2 full backups :)
>
> 2 ideas are circling around my head ATM:
> * try to think of a way to dispatch HMIGRATE to 4 LPAR's (although backup
> jobs are running on 2)
> * teach operators to change the MAXMIGTASKS appropriately (^^)
>
> Cheers,
> J
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to [email protected] with the message: INFO IBM-MAIN
--
Mike A Schwab, Springfield IL USA
Where do Forest Rangers go to get away from it all?
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
