We are in the process of migrating from a single data center with a 5.5
TSM server to a pair of data centers with 6.2 TSM servers. All of the TSM
servers will run under mainframe Linux. During the first stage of the
transition, we will have a TSM server instance at one of the new data
centers sharing tape drives and a 3494 tape library located in the old data
center with the TSM server located there. We will have a TSM server instance
dedicated to acting as a library manager. The library manager will have to
run TSM 6.2 because Tivoli requires the code level for a library manager to
be at or above the code level of a library manager client. The mainframe in
the old data center does not have enough memory to run its current workload
and a new LPAR with enough memory for TSM 6.2. As a result, the library
manager will have to be at the new data center. This puts us in an awkward
position if there is a fire or other disaster at the new data center; the
TSM 5.5. server and the tape library will still be available, but the
library manager will not.

We have set up a test environment with the two TSM 6.2 server instances,
a TSM 5.5 test system, and one tape drive. We have set up the library manager
and successfully tested operations that mount specific volumes, operations
that mount scratch volumes, and operations that cause volumes to return to
the scratch pool.

This morning we tested the contingency plan for reverting to operation with
the TSM 5.5 server and no library manager. We had never removed then non-shared
library definition the TSM 5.5 test server used before the start of work on
the new data centers. We shut down both TSM 6.2 instances, defined the tape
drive in the non-shared library and defined a path to the drive.

The 3494 has an internal database that keeps track of numerical categories
assigned to volumes. Each library defined to TSM has its own pair of
categories: one for private volumes and one for scratch volumes. There are
a number of categories used by the 3494 itself, including an entry category
for volumes inserted into the 3494 and not yet assigned to a TSM library.

The process for getting scratch volumes into the non-shared library was as
follows:
1.Use the mtlib utility to ask the 3494 for a list of volumes with the
  scratch category for the shared library.
2.Use the mtlib utility to change each of these volumes to the entry
  category.
3.Check the volumes into the non-shared library as scratch volumes.

The process for getting private volumes into the non-shared library was a
bit more complicated:
1.Use the mtlib utility to ask the 3494 for a list of volumes with the
  private category for the shared library.
2.Use a 'query volume' command and a select against the volhistory table to
  create a list of volumes containing data from the TSM 5.5 server.
3.Find the volumes present in both lists.
4.Use the mtlib utility to change each of volumes from step 3 to the entry
  category.
5.Check the volumes from step 3 into the non-shared library as private
  volumes.

Once all of the volumes were checked in we updated the tape device class to
use the non-shared library.

We successfully executed an 'audit volume' command that mounted a specific
volume and a full database backup that mounted a scratch volume. We then
attempted to execute the command 'del volhist todate=-1 type=dbb' to remove
an older database backup and put the volume containing the backup back
into scratch status. The session executing the command hung. I eventually
cancelled the session. The volume history record was gone, but a 'query
libvol' command listed the volume as private, and the mtlib utility
reported that the volume was in the private category for the non-shared
library. I was able to use the 'update libvol' command to change the volume
to scratch status.

Does anyone know how to fix this?