J.P. Another possibility, if you write the backups to a storage group reserved for backups, would be to use HSM's INTERVALMIGRATION option on the specific storage group. This option runs interval migration on the hour every hour except when PRIMARY SPACE MANAGEMENT is running. This is done by setting the AUTO MIGRATE setting to I. This setting means datasets are eligible for migration during primary space management and interval migration. N.B. the Management Class for these datasets would have to have PRIMARY DAYS set to 0 and obviously a NO BACKUP setting.
You can set the INTERVALMIGRATION tasks to four by specifying: INTERVALMIGRATION(4) Richard -----Original Message----- From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf Of Mike Schwab Sent: Tuesday, September 24, 2013 6:26 PM To: [email protected] Subject: Re: HMIGRATE in parallel 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 ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
