> Hello,
>          I have been running TSM 4.1 on z/OS for a year and a half now,
> (started on OS390 2.7).   I wanted to take advantage of and follow the
> standard usage of our tape systems so I set up the TSM tape system in a way
> that I now question.  I would like people to let me know if they are doing
> things like I am or not.  If you would like to explain what you do, ood but
> please just let me know if I am out on my own with this.  I am trying to
> determine if it is worth my time to change things.  It is a little odd but
> here I go...
>             I set up my 6 9840 tape drives with two different DEVICE
> definitions.  I called one ONSITE9840 and the other OFFSITE9840.  I did this
> because our entire CA1 Tape handling and STK SILO handling is based on the
> high level qualifier of the data set name on the first file of the tape.
> So I gave the 2 device classes different high level qualifiers, told the CA1
> and STK software what I was doing and the normal running production system
> that put tapes in a vault pattern that has the offsite tapes go to our DR
> site with all the other tapes needed at DR was taken care of.  No other
> special handling.   It also took care of ejecting the tapes that were going
> offsite from the tape Silo system.  No extra handling.  I did have to add a
> step there to have TSM mark those tapes as OFSITE , that was it.   I then
> would have my tape COPYPOOL use the OFFSITE9840 and the disk backuppoool
> migrate to the TAPEPOOL that used the ONSITE9840.
>             The problems that seem to come from this is TSM thinks it has
> more tape drives than it does.  SO TSM may start to do a disk to tape
> migration but it really doesn't have the tape drives available, yet (because
> they are busy making OFFSITE copies of backups).   This of course makes
> scheduling much more difficult.   And it has gotten ugly at times with
> server consolidations and the fact that I am running in ROLLFORWARD mode
> with version 4.1 and the 5GB log.  So I am wondering if my life would be
> better if I really only defined to TSM the proper number of tape drives and
> let it handle some of its scheduling affairs, and I wrote all the procedures
> to handle the tapes coming and going affairs.  (which of course will change
> the playing field for my schedules....)
>           SO DO YOU SET UP YOUR TSM TAPE HANDLING ON OS390  z/OS LIKE THIS ?

We have a similar set-up with two device classes specifying different
prefixes for dataset names. The batch jobs that manage TSM housekeeping
update the mountlimit parameters for the two device classes several times
during the course of each daily processing cycle. This enables us to keep
the total number of mounts requested for both device classes less than or
equal to the total number of installed tape drives. This approach works
most of the time. We do get occasional failures when a batch job attempts
to reduce the on-site mount limit from 2 to 1 and both drives have on-site
tapes mounted. This can happen because on-site tape reclamation runs
longer than expected or because two clients run restores. We also lose
some flexibility in allocating tape drives. The most frequent problem
in this regard occurs when the mount limits are set to 1 for each device
class (to support off-site tape reclamation) and one or more clients
request restores. We end up using only one drive for the restores. At
the worst we lose the opportunity to have two drives reading data, if
there are two independent restores or a SQL/BackTrack restore set up
for multiple streams. At best we lose the opportunity to mount the next
tape on an idle drive while the previous tape is dismounting.

I think there is a possible middle ground between relying on the vault
pattern dataset and doing everything yourself. I studied the CA-1 manuals
when I was first setting up ADSM. As nearly as I can recall, it is
possible to create a batch update stream that will set the outcode field
in the CA-1 database records for specified volumes. CA-1 will then treat
these volumes just as like volumes with dataset names matching entries in
the vault pattern dataset. I was not able to sell this approch to the
system programmers. They seemed very nervous about the batch update
utility for the CA-1 database.

The transition from your current configuration to a configuration with
a single tape device class might be very difficult. It is not possible
to either change the device class for an existing storage pool or change
the dataset name prefix for an existing device class.