IBM Tivoli Storage Manager, Version 7.1

Scenario 3: Modifying the server before the upgrade

A command must be run on the server to prevent one type of problem during the upgrade process. Some modifications to typical server settings can be useful to prepare for the upgrade.

Procedure

From a Tivoli® Storage Manager administrative command line, issue the command:
```
convert ussfilespace
```
This command fixes a problem that might exist in older Tivoli Storage Manager databases. If the problem does not exist in your database, the command is completed and you might see error ANR2034E. This error can be ignored. For more information, see Technote 1408895 (http://www.ibm.com/support/docview.wss?uid=swg21408895). If the problem exists in your database, the command might take some time to run.
Important: Do not skip this step. If your database has the problem and you do not run this command now, the DSMUPGRD PREPAREDB utility fails when you run it. You must then restart the V5 server and run the CONVERT USSFILESPACE command before you continue the upgrade process.
Review the steps for reverting to the earlier version of the server in the section, Reverting from V7.1 to the previous V5 server version.
If you must revert to the earlier version after the upgrade to V7.1, the results of the reversion will be better if you understand the steps and prepare for the possibility now.
Make the following adjustments to settings on your server and clients. These adjustments must be done to make it possible for you to revert to the original server after the upgrade, if problems occur.
1. For each sequential-access storage pool, set the REUSEDELAY parameter to the number of days during which you want to be able to revert to the original server, if necessary.
  For example, if you want to be able to revert to the original server for up to 30 days after the upgrade to V7.1, set the REUSEDELAY parameter to 31 days. Issue the following administrative command:
```
update stgpool sequential_access_storage_pool reusedelay=31
```
2. For each copy storage pool, set the RECLAIM parameter to 100 (meaning 100%). Issue the following administrative command:
```
update stgpool copy_storage_pool reclaim=100
```
3. If you typically use a DELETE VOLHISTORY command to delete database backups, ensure that the command does not delete database backups too frequently. The interval between backups should be at least the same number of days that you set for the REUSEDELAY period for sequential-access storage pools. For example, to delete database backups every 45 days, issue the following administrative command:
```
delete volhist type=dbbackup todate=-45
```
4. For important clients that use the server, verify that the value for the schedlogretention client option is set to retain the client schedule log for a sufficient time. Update the option for clients if needed.
  The entries in the client schedule log might be useful if the server must revert to the original version. If the retention period for the schedule log is too short, the schedule log information might be deleted too soon.
  For example, to prune the log every 45 days and save the log entries, add the following option:
```
schedlogretention 45 S
```
  Add the option to the dsm.sys file within a server stanza.
  
  Add the option to the client options file, dsm.opt.

Feedback