ADSM-L

FW: Some questions about pools.

1996-01-12 16:44:16
Subject: FW: Some questions about pools.
From: Andrew Mark Raibeck <raibeck AT CONNIX DOT COM>
Date: Fri, 12 Jan 1996 16:44:16 -0500
Mark Brown asks:

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter follows =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
We are running the ADSM server on MVS/ESA.

1) How many disk pools do you use before moving the data to tape?

2) How long do you keep the tape for (5 years)?

3) What threshold have you set on the server before it starts moving
   data from one pool to the next. I would think 95% full is too high?
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Forwarded letter ends =
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Where I used to work, I had two disk pools: one for backups and another =
for archives. The reasons for this were:

1) The disk backup pool was considered a staging area for each night's =
backups. A buffer, if you will, for performance. During the day, the =
backup versions in the pool were migrated to tape, freeing up enough =
space to house the next night's backups.

2) Before ADSM V2 became available, I wasn't inclined to migrate archive =
versions to tape. The reason for this was that presumably these archive =
versions were the only versions of those files available, so I wanted to =
treat them accordingly. While it is fairly easy to back up the disk =
archive pool using DFSMSdss, backing up archive versions on tape would =
be a little more complex. So for the time being, all archive versions =
were kept on DASD. But now that V2 is available, I set up the archive =
pool to migrate to tape as well. By the way, I should mention that =
archive isn't used as much as backup, so the archive pool isn't all that =
large (around 3 GB).

As far as retention of tapes goes: this is really driven by management =
class, not an absolute retention period. For example, if there are three =
backup versions on a tape, and if they expire within 7, 15, and 35 days =
respectively, then the tape will expire in 35 days (assuming the tape =
isn't reclaimed before then). If you have a tape management system (i.e. =
TMC or RMM) I recommend:

1) implementing the DELETIONEXIT option in the server options file,
2) setting up a tape volume exit (this sort of goes hand-in-hand with =
(1) above,
3) setting up the tape pool to call for scratch tapes,
4) and setting up the device class with a retention of 99365.

This way, once an ADSM tape is effectively emptied, ADSM will pass the =
volser to the tape volume exit, which will tell the tape management =
system that the tape can be used as scratch again. ADSM will also delete =
the volume from its inventory.

Migration thresholds: the archive pool is much less busy than the backup =
pool, so I was content to leave its low and high thresholds at 70% and =
90%, respectively.

For the backup pool, the settings are 10% and 80%, respectively. =
However, I don't rely on these to handle migration for me, mostly =
because I wanted to control *when* migration ran. For example, it may =
not be very convenient for migration to kick off right in the middle of =
your backups. In my case, this was due to performance implications and =
available tape drive resources. Rather, the I use the thresholds on the =
backup pool more as a safety valve. Here's what I set up instead:

1) I sized the backup pool so that it would be large enough to house one =
night's worth of backups, with a little extra room to spare. To obtain =
statistics on how much data was backed up over the course of a 24-hour =
period, I wrote a SAS routine that read in the SMF records that the ADSM =
server generates. I included this SAS code in a group of 5 utilities I =
wrote that are on the ftp server (index.storsys.ibm.com) in the =
/adsm/nosuppt directory. The file is a self-extracting executable (from =
DOS) that contains information about the tools, source code, and sample =
output.

2) During the afternoon, I used ADSM V2's administrative command =
scheduling facility to schedule a command to reset the high migration =
threshold to 11%. This would effectively force migration of the disk =
pool to tape, making enough space to house the next night's worth of =
backups.

3) Later on, I scheduled another administrative command to bump the high =
threshold back up to 80%.

Hope this helps,

Andy Raibeck
<Prev in Thread] Current Thread [Next in Thread>