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?
