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
