> We are in the process of implementing the DRM feature on both our MVS and
> SUN ADSM servers. I sure could use some advice and someone to tell me about
> the pitfalls before we fall into them. We are also wondering if anyone has
> automated (via script or ADSM scheduler) the process of backing up the
> primary pools to the DRM pool, backing up the ADSM DB, the PREPARE, the move
> drmedia and notication to the tape library to send tapes offsite/back onsite
> and would be willing to share information/scripts to accomplish these tasks?

We have done this kind of automation for our MVS server. We don't have a Unix
ADSM server.

> I do have some questions:
>
> How do you get the DRM plan offsite with the tapes?

We have a batch job that runs a Rexx script to execute the 'prepare' command
and handle a number of other housekeeping functions. A subsequent job step
uses IDCAMS to copy the recovery plan to a second file on the tape used for
the latest offsite backup of the ADSM database. IDCAMS is used rather than the
more obvious IEBGENER because our tape management software will only allow
APF-authorized programs to append to a tape written by ADSM. The Rexx script
goes through some fairly baroque operations to enable the IDCAMS step to work
without requiring customized JCL for each execution. The script extracts the
name of the recovery plan file from the messages generated by the PREPARE
command and renames the file to a fixed dataset name, which is specified on
the input DD statement for IDCAMS. The script also creates an MVS catalog
entry for an imaginary dataset on the tape used by the latest backup of the
ADSM database. The output DD statement for IDCAMS specifies a volume using a
VOL=REF=... operand pointing to the imaginary dataset.

[Material deleted]

> Do you do reclamation of the offsite storage pools? If you do, how does that
> work?

We have a somewhat involved strategy designed to minimize the amount of tape
activity. We have separate onsite and offsite storage pools for backups of
Oracle databases. These backups almost always expire in two weeks, allowing
the tapes containing them to become empty with no reclamation. However, some
longer lived backups end up in these pools for various reasons. If an onsite
Oracle backup tape is not empty after 15 days, we use 'move data' to transfer
its remaining contents to the onsite pool for long lived backup files. If an
offsite Oracle backup tape is not empty after 17 days, we delete the volume
and run a 'backup stgpool' command. The backup is just a safety measure, since
the corresponding onsite files should have been moved into the long lived
onsite pool two days earlier and then copied to the long lived offsite pool.
We do, in a manner of speaking, reclaim the long lived offsite pool. We delete
low occupancy volumes and then run a 'backup stgpool' command to copy the
remaining contents of the deleted volumes onto fresh volumes. We do this
because the normal reclamation process offers nothing analogous to the
'wait=yes' option of the 'delete volume' command. This makes it very difficult
to integrate the normal reclamation process into a series of scheduled batch
jobs.

> Do you use ADSM scheduling function to perform most of the actions? If so,
> how do you check for successful completion?

We don't use the ADSM scheduling function precisely because the facilities for
checking successful completion are so weak.