Hi Esmee,
Not strictly dfhsm, but you should also consider your actual tape environment.
Assuming you have at least 2 separate librarys you need to ensure that your
copy volumes are directed to a 2nd library.
If you have virtual tape libraries I would also consider it good practice to
have seperate storagegroups/pools within the librarys so that dfhsm migration
and backup tapes end up on different physical volumes when migrated off of
cache on to back end stacked tapes.
There are 2 points to that:-
(a) if you have mass dataset recalls which are on dozens of virtual tapes,
having a seperate pool for mig tapes will reduce the amount of back end tape
mounts going on.
(b) You can (and do) end up losing physical stacked volumes every now and then,
losing possilbly thousands of virtual volumes, so it would simplify recovery.
If you only have one big virtual library for everything in your datacentre,
then having separate pools for master and alternate tapes would be pretty
essential; also worthwhile for each plex to be distinct.
These are generalisations as it always depends on each individual companys
setups and working practices.
If you are in a multi grid setup you may not think it worthwhile.
kind regards,
Dave
***********************************************************************************************
> Each recycle process only takes only 50% more drives: three instead of
> two.
>
>Unless it has recently changed, one annoying thing about DFHSM in a
>tape-drive constrained environment is there is no easy way to put an
>absolute upper bound on the maximum number of drives needed concurrently
>by all DFHSM tasks. Yes, you can separately restrict the number of
>daily backup tasks, daily ML2 movement tasks, and migration recall
>tasks; but this doesn't really address the unpredictable concurrent
>demand from asynchronous ML2 recall requests and demand backup requests
>that may go directly to tape; and those requests can occur at
>inconvenient times, like when ML2 migration, or auto-backup to tape, or
>recycle is in progress. If you want to more-tightly restrict the total
>number of drives used by unscheduled DFHSM tasks during scheduled tasks
>with high drive demand, there is no easy way to do just that, and the
>greater drive requirements with duplexing can make this more of an issue.
> I would never use DFHSM with today's high-capacity cartridges without
>duplexing, but in some environments duplexing may require adding
> additional drives.
> JC Ewing
>On 02/26/2013 12:30 PM, Staller, Allan wrote:
> 1) be aware that duplexing for backup and migration are separate commands.
> 2) recycle, ml2 migration and volume backup will now take twice as many tape
> drives as before. You may have to change the limits on
> the number of backup tasks, migration tasks and recycle tasks you run
> concurrently to fit within physical constraint (# of tape drives available).
> 3) Plan on a program of recycling all existing media to get them duplexed.
> You can use tapecopy, but recycle will most likely be more efficient.
>
> HTH,
>
> <snip>
> We are looking at implementing DUPLEXING for DFHSM. My question is, besides
> the parms in ARCCMD9A which needs to be update are there other parms that
> need to be modified?
> </snip>
>
> ...
--
Joel C. Ewing, Bentonville, AR jcew...@acm.org
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
