ADSM-L

Re: Cartridge Drive Utilisation

1996-09-06 02:47:21
Subject: Re: Cartridge Drive Utilisation
From: "Andrew M. Raibeck" <araibeck AT VNET.IBM DOT COM>
Date: Thu, 5 Sep 1996 23:47:21 PDT
Dianne Sharp asks:

>1.  We have one backup disk pool, but it is not very large (only 2-4GB).
> We will be backing up over 20GB nightly.  Therefore, we will be
> migrating data to cartridge quite often during the night.  We only have
> 6 cartridge drives and they are used regularly during the night for
> Mainframe backups and other Production processing.  Is there any way of
> controlling when migration can and can't take place based on time, or
> are there commands that we can issue, preferably through an automated
> batch job or something, that can disable and enable migration at certain
> points of the night?

Hmmm... to be honest, I think this setup will cause you a lot of frustration
sooner or later... probably sooner. It's one thing to try to get 10 pounds
into a 5 pound bag. It's another thing when you try to fit 25 - 50 pounds
into the same 5 pound bag. More likely than not, the bottom of the bag is
going to rip open. My point: I think you're really short-changing yourself
on ADSM resources.

To answer your question, you can control when migration occurs by using the
UPDATE STGPOOL command. To force migration to occur, issue:

     UPD STG poolname HI=1 LO=0

To turn migration off, issue:

     UPD STG poolname HI=75 LO=50     <== or whatever your "normal"
                                          thresholds are

You can create batch jobs to run the TSO Admin client in batch mode, then
schedule these jobs with a scheduler, like CA-7, assuming you want them to
be time-of-day triggered. With the batch job, you can issue the UPDATE
STGPOOL commands I described above. Or, you can issue the Q STG command to
query the storage pool, storing the output in a data set. Then the next step
of your batch job can run a REXX program to interpret the output, and
subsequently submit another batch job to issue the UPDATE STGPOOL command
if the utilization of the pool exceeds your required thresholds (or do
nothing if the threshold isn't met). Or, you can use MVS automation tools
like AOC to periodically issue the commands you want.

I can mail you sample TSO Admin client batch JCL if you like.

The problem with this scheme, though, is the constraint on resources. Some
issues to consider:

     - How many tapes can you use for migration (when they are available)?

     - Will migration be able to keep up with the incoming backups? In other
       words, if the boat is leaking, can you bail water fast enough to keep
       it from filling up and sinking? For instance, it *may* be possible to
       keep up with the inflow of backups if you back up one client at a
       time, and have two drives available for migration. On the other hand,
       10 clients backing up concurrently will probably fill the disk pool
       faster than two drives can empty it.

     - If tape drive availability is time-of-day based, will the time you
       have the drives available coincide with when the pool needs to be
       emptied? What if the pool fills up but the job to initiate migration
       hasn't run yet?

     - If the ADSM server is doing migration, backup performance may be
       impacted.

A lot of users set up their disk storage pool such that it has enough
capacity to house one night's worth of backups. Once the backups are
complete, they then use the UPDATE STGPOOL commands to turn migration
on and off, to migrate the data to tape, freeing up space for the next
night's backups.

> 2.  Reclamation is another concern.  If we have reclamation turned on,
> can we control when it happens?  I'm worried that if it kicks in and
> then a migration process is scheduled, that it might hold up backups
> that are currently running.
> uld it be better to set the threshold to 100% and just change it when
> u want this to run?   This is a bit messy because you'd have to
> member to change it back again - unless this is also something that
> n be automated somehow.

Yes, adjusting the threshold at different times of day is probably the
best way to go. Again, you can use batch jobs to automate this. In fact,
I suggest that while inventory expiration is running, you have your
reclaim threshold at 100%. Inventory expiration can cause reclamation of
tape volume to kick off as the utilization of tapes drops. Having
reclamation turned off can help prevent this from happening. Otherwise
you might end up reclaiming data from a tape that a few minutes later is
deleted by the inventory expiration process.

Sample scenario:

09:00 PM - 02:00 AM -- Nightly incrementals
04:00 AM - 06:00 AM -- Inventory expiration
08:00 AM - 03:00 PM -- Migration (probably won't take that long)
08:00 AM - 08:00 PM -- Reclamation (can run with migration if drives are
                       available)

Inventory expiration can be controlled by setting EXPINTERVAL 0 in the server
options file, and using a batch job to issue the EXPIRE INVENTORY command.

This is just a sample scenario that I made up just now... your needs may
differ. But it shows how the different functions can be executed with respect
to one another. Theoretically, you should be able to run most or all of
these concurrently. But practically speaking, available resources and
contention for the data within ADSM storage suggest that you implement
something like I described above. I'm sure that many people here have other
variations on this.

Hope this helps,

Andy

P.S. Yes, with V2, you will be able to schedule the Admin commands via the
ADSM scheduler, rather than having to implement batch jobs.
<Prev in Thread] Current Thread [Next in Thread>