====================================================================== Tivoli Storage Manager (TSM) Server Read1st File -- Version 3.7.2.0 PTF IP21902 Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1999. All rights reserved. ====================================================================== Welcome to Tivoli Storage Manager. Contents - What's new - Installation -- Database upgrade -- TSM Versioning || - Tape Library Sharing for SCSI libraries on a SAN || - New server option SEARCHMPQUEUE for backup/restore and archive/retrieve operations || - New parameters added to the DELETE VOLHISTORY command || - Licensing Changes Between Server Versions 3.1.x and 3.7 || - Support for IBM 3590 Model Exx Tape Drives - Known issues | -- Latest Quantum DLT Drive Microcode is required for APAR IY03251 -- HTMLHELP online information issues -- Default program folder name has been changed -- Data Base Page Shadow Function Disabled -- Query Volhistory Command -- Library sharing support -- Changes to the TSM Administrator's Reference -- Changes to the TSM Administrator's Guide -- ADSM V3 DRM Disk Image Dump and Restore Diskettes and Doc. -- CONVERT USSFILESPACE command - Trademarks Changes made for maintenance level 3.7.1.0 are indicated by "|" Changes made for maintenance level 3.7.2.0 are indicated by "||" ====================================================================== What's new ====================================================================== The Tivoli Storage Manager Quick Start Manual provides details for all of the new features in this release. The Quick Start manual is available in the TSM Online Information. ====================================================================== Installation ====================================================================== -- Database upgrade When this setup is run to install TSM over an existing version of TSM the setup program will automatically upgrade the TSM database. Once the database is upgraded to V3.7 it will no longer be accessible from a previous version of TSM. -- TSM Versioning Beginning with Tivoli Storage Manager, version 3, release 7, "versioning" has changed. When a new PTF is released, the maintenance level will be raised by one. Thus 3.7.0.0 is the Initial GA level, and the first PTF will be 3.7.1.0. The last number (fix level) is reserved for individual APAR fixes and special fixtests which are sometimes necessary between PTF levels. || ====================================================================== || Tape Library Sharing for SCSI libraries on a SAN || ====================================================================== || || Terminology used in this document || ================================= || || SAN - Storage Area Network. || || Library Manager - Controls the operations pertaining to the library. || In particular, mount, dismount, volume ownership, || and library inventory. || || Library Client - A server that request library service from a library || manager. The library client cannot perform || library management functions. || || What is supported in this package? || ================================== || || MS Windows NT server and workstation version 4.0 service pack 5 || Tivoli Storage Manager server version 3.7 || || Dell Solution: || QLOGIC 2100F with driver level 6.18 || Dell 35F Bridge driver level Version: 2.2 d9908e || Dell 50F Switch driver level || VxWorks version: 5.3.1 || Firmware version: v1.6a1_dell || Made on: Wed Jan 20 12:51:42 PST 1999 || Dell 130T library with DLT 7000 drives. || || IBM Solution: || QLOGIC 2100F with driver level 6.16 || IBM Storage Area Network Data Gateway Firmware level 2.66.14 || IBM 3570 tape library || || For current configuration information check out: || http://www.tivoli.com/support/storage_mgr/san/solution_device.html || || How to Setup a SAN || ================== || || First setup the library manager, then setup the library clients. || || 1. Format the database and log file with "dsmserv format". || || Example: "dsmserv format 1 log 20 1 db 100" || || Multiple Server can run on the same machine from different || directories using the dsmserv -k option. || || Example: "dsmserv -k server2 format 1 log 20 1 db 100" || || 2. Start the Server. || || Example: "dsmserv" || || For multiple servers on the same machine use the -k option. || || Example: "dsmserv -k server2" || || 3. Register an administrator: || || reg admin || || 4. Grant the administrator authority. || || grant auth class=sys || || 5. Set the server information: || || SET SERVERNAME || SET SERVERPASSWORD || SET SERVERHLADDRESS
|| SET SERVERLLADDRESS || SET SERVERURL http://
: || SET CROSSDEFINE on || || For multiple servers on the same machine make sure the ports are different. || || 6. Verify that the TSM Device Driver is started. To verify this open || "TSM Server Utilities", go to "Service Information" and click the "TSM Services" || tab. Also, obtain device information regarding the library and drives using || Device Information, this information will be needed below. The list may need to be || refreshed for the information to appear if the device driver was not started previously. || || 7. Repeat Steps 1 through 6 for each library client server, and give || each server a different name. || || 8. If the server is a library manager proceed to: || "How to setup a Tivoli Storage Manager server as a library manager" || || If the server is a library client proceed to: || "How to setup a Tivoli Storage Manager server as a library client" || || How to setup a Tivoli Storage Manager server as a library manager || ================================================================= || || 1. Configure the SCSI library as done with previous versions. || Except add "SHARED=YES" to the "DEFINE LIBRARY" command. "SHARED=YES" may also || be used with the UPDATE LIBRary command. || || For Example: || || define library dell130t libt=scsi devi=lb0.0.0.2 shared=yes || update library lb0.0.0.2 shared=yes || || 2. Define the drives in the library || || For Example: || || define drive dell130t drive1 devi=mt0.1.0.2 element=1030 || define drive dell130t drive2 devi=mt0.2.0.2 element=1031 || define drive dell130t drive3 devi=mt0.3.0.2 element=1032 || || 3. Define at least one device class associated with the shared library. || Hint: Use a low mount retention and mount wait time. Set the || mount wait times to different values for each server. || || For Example: || || define devclass tape devtype=dlt mountr=5 mountw=10 libr=dell130t || || 4. Check in the library inventory || || For Example: || label libvol dell130t search=yes labels=barcode checkin=scratch || overwrite=yes || || This lables the tapes and checks them into the library inventory as || scratch volumes. || || -=- OR -=- || || checkin libvol dell130t search=yes checkl=barcode status=scr || || This will checkin all volume into the library inventory as scratch || volumes. || || 5. Setup Storage Pools. || || The library manager is now setup for a SAN. All normal server || funtionality is available to the library manager. || || How to setup a Tivoli Storage Manager server as a library client || ================================================================ || || 1. Define the library manager: || || DEFINE SERVER COMMMETHOD=TCPIP SERVERPASSWORD= HLADDRESS=
LLADDRESS= CROSSDEFINE=YES || || 2. Define a shared library of the same name as on the library manager. || || define libr dell130t libt=shared primarylibmanager= || || 3. Define the drives to the library using the same names on the library || manager. || || For Example: || define drive dell130t drive1 devi=mt0.1.0.2 || define drive dell130t drive2 devi=mt0.2.0.2 || define drive dell130t drive3 devi=mt0.3.0.2 || || 4. Define at least one device class associated with the shared library. || Hint: Use a low mount retention and mount wait time. Set the || mount wait times to different values for each server. || || For Example: || || define devclass tape devtype=dlt mountr=5 mountw=10 libr=dell130t || || || 5. Setup a storage pool associated with the device class for the shared || library. || || The library clients are now setup for operation on a SAN. Most || normal server functionality is available to the library clients. || A library client cannot perform library management operations on a || shared library, such as: checkin, checkout, label, and all libvol operations. || || || Command Updates in this version for SHARED library support || ========================================================== || || DEFINE LIBRARY has added the following options: || LIBType=SHARED || SHARED=YES|NO || PRimarylibmanager= || || UPDATE LIBRARY has the added option: || SHARED=YES|NO || || DEFINE DRIVE notes: || No updates for SCSI, 3494, etc. || Element not required for SHARED library drives || || CHECKIN LIBVOL has added the following options: || OWNER= || || UPDATE LIBVOL has added the following options: || OWNER= || || QUERY commands and SQL tables have been updated with the new parameters || || Web interface has been updated on NT for SHARED libraries || || || ********************************************************************** || * New server option SEARCHMPQUEUE for backup/restore and archive/retrieve operations || ********************************************************************** || The new server option SEARCHMPQUEUE can be used to modify mount request || processing. || When specified the server, when examining the mount point queue for a || mount request to satisify, will first look to dispatch a request that needs an || already mounted volume. The selected request may be dispatched before || other request on the mount point queue even though they have been waiting || longer for a mount point. Without this option specified, the sever will || satisify mount request as first-come, first-served. || ********************************************************************** || * New parameters added to the DELETE VOLHISTORY command * || ********************************************************************** || || The following new parameters have been added to the || DELETE VOLHISTORY command: || || o DEVCLASS=classname || || o DELETELATEST=Yes|No || || Command Syntax: || || || >>--DELete VOLHistory--TODate--=--date--+-----------------+--> || +--TOTime-=-time--+ || || || >--Type--=--+-All---------------------------------------+--->< || |-DBDUMP------------------------------------| || | | || | ..... | || | | || |-DBBackup------+------------------------+--| || | +--DEVclass--=classname--+ | || | | || |-DBsnapshot----+------------------------+--| || | +--DEVclass--=classname--+ | || | | || | +--DELETELatest--=---No--+ | || |-RPFile--------+------------------------+--| || | +--DELETELatest--=-+-No--+ | || | +-Yes-+ | || | | || | +--DELETELatest--=---No--+ | || |-RPFSnapshot---+------------------------+--| || | +--DELETELatest--=-+-No--+ | || | +-Yes-+ | || | | || +-------------------------------------------+ || || || New Parameters: || || o DEVclass=classname || Specifies the device class name that was used to create the || database backups. This optional parameter can be used to || delete database backups created using a server-to-server || virtual volume device class. The type of the device class || must be SERVER. || || This parameter can only be used to delete volume history || entries of type BACKUPFULL, BACKUPINCR, or DBSNAPSHOT. || || A full, incremental or snapshot database backup volume || is eligible to be deleted if all of the following conditions || are met: || - The device class used to create the database backup || volume matches the specified device class || - The volume was created on or before the specified || date/time. || - The volume is not part of the latest full plus || incremental database backup series if the specified || volume type is DBBackup, or snapshot database backup || series if the volume type is DBSnapshot. || || || o DELETELatest=Yes|No || Specifies whether the latest recovery plan file is eligible || for deletion. This optional parameter can only be used to || delete volume history entries of type RPFILE or RPFSNAPSHOT || (i.e. recovery plan files that were created using a || server-to-server virtual volume device class). If this parameter || is not specified, the latest RPFILE and RPFSNAPSHOT entries are || not deleted. || || DELETELatest=No || Specifies the latest RPFILE or RPFSNAPSHOT file is NOT deleted. || || DELETELatest=Yes || Specifies the latest RPFILE or RPFSNAPSHOT file is deleted if || it meets the specified date and time criteria. || ********************************************************************** || * Licensing Changes Between Server Versions 3.1.x and 3.7 * || ********************************************************************** || || The license terms have changed for the Tivoli Storage Manager (TSM) || server Version 3.7. Customers that were in compliance with the || license terms on ADSM server version 3.1.x may find themselves || out of compliance when migrating to TSM 3.7. This notice has been || developed to address the changes to the DRM and server-to-server || virtual volume licenses. || || For the ADSM server version 3.1.x, electronic vaulting of || database and storage pool backups was licensed via the || server-to-server virtual volume license. The || server-to-server virtual volume license was required || on the source and target servers. || || For the TSM server version 3.7, the base TSM server license || includes server-to-server virtual volume capabilities except || for electronic vaulting of database and storage pool backups. || The DRM (Tivoli Disaster Recovery Manager) license now || includes electronic vaulting of storage pool and database || backups. This license is only required on the source server. || || Customers using electronic vaulting of database or || copy storage pool backups on ADSM servers version 3.1.x || should do one of the following when migrating to TSM || Version 3.7: || o Purchase and register the Tivoli Disaster Recovery || Manager license || OR || o Delete the storage pool and database backups that were || created using a server-to-server virtual volume device || class (i.e. device class of type SERVER). || || || Deleting Storage Pool Backups || ---------------------------------- || || If you decide to delete a copy storage pool associated with || a device class of type SERVER, do the following: || || 1. You should consider creating another copy storage pool || associated with a local device class. || || Define a copy storage pool associated with a local device || class and create a full backup of the primary storage || pools that were backed up to the copy storage pool to be || deleted. || || 2. To delete a copy storage pool, you must first delete || all the volumes assigned to the storage pool: || o For each volume defined to the copy storage pool, issue || the 'DELETE VOLUME volname DISCARDDATA=yes' command. || o If the volume deletion process is cancelled or a || system failure occurs, you may have to issue the || DELETE VOLUME command again with the DISCARDDATA=Yes || parameter. || || 3. Use the 'DELETE STGPOOL copyPoolName' command to delete || the copy storage pool. || || || Deleting Database Backups || ------------------------------ || || If you decide to delete the database backups created using || a device class of type SERVER, do the following: || || 1. If the latest database backup series was created using a || device class of type SERVER, you must create a new database || backup series using a local device class. || || 2. Delete the volume history entries for the database backups. || There are two ways to delete the entries: || || o Use the 'DELETE VOLHIST TYPE=DBB TODATE=date TOTIME=time' || command to delete 'old' volume history entries for database || backups. Note that this command will delete ALL the || full and incremental database entries created on or || before the specified date/time. || || o Use the DELETE VOLHISTORY command with the new parameter, || DEVCLASS=classname. This optional parameter can only || be used to delete database backups created using a || server-to-server virtual volume device class. || --------------------------------------------- || Support for IBM 3590 Model Exx Tape Drives || --------------------------------------------- || || ADSM now supports the IBM 3590E Tape drive. || || The 3590E tape drive writes data in a new 256 track data tape format. 3590E drives can not || write in 3590 128 track format however, they can read data from the tapes previously written in || 128 track format on 3590 drives. || || With new 3590E drives available, the existing 3494 libraries with 3590 drives may either be || completely upgraded with 3590E drives or they may have an intermix configuration || (3590 and 3590E drives). || || ADSM administrators must follow certain rules to transition from old 3590 drives to new 3590E || drives and/or maintain both kinds of drives within the same physical library. || || Configurations: || || Microcode level: || 3590E - EC F23200 D01C_502 || || Tape formats for 3590E: || - 3590E-B - uncompressed mode (similar to 3590B) || - 3590E-C - compressed mode (similar to 3590C) || - DRIVE - the most advanced available format || Note: For 3590 and 3590E tape drives the most advanced formats are respectively 3590C and 3590E-C || || 1. All 3590 drives within physical library are upgraded with 3590E drives at the same time. || || Consider an example with one 3590 drive physically defined as mt0.0.0.2. || Assume that there were originally defined devclass, logical library, and || storage pool for 3590 drive. There were also some volumes (tape cartridges) || checked in the library with data written on that drive. || || Replaced 3590 drive with 3590E drive. || || Steps below will allow you to use the new 3590E drives with minimum changes to ADSM server: || || - Run ADSM server (dsmserv); || - Issue ADSM command: UPDate DEVclass devclassname FORMAT=DRIVE || update devclass devclass_3590 FORMAT=DRIVE || - Issue ADSM command: DELete DRive libname drivename || delete drive lib_3590 mt0.0.0.2; || - Issue ADSM command: DEFine DRive libname drivename DEVIce=devicename || define drive lib_3590 mt0.0.0.2 device=mt0.0.0.2; || - Update all previously written on 3590 drive volumes to readonly mode || update volume volname access=readonly; || || || 2. Intermix of 3590 and 3590E drives in a single 3494 library environment. || || Consider an example of a physical library with one 3590 drive defined || as mt3.0.0.2 and a new 3590E drive defined as mt0.0.0.2. || Assume that there were originally defined devclass, logical library, and || storage pool for 3590 drives. || || With addition of a new 3590E drive to the library that already has 3590 || drives in it, new DEVCLASS, new logical LIBRARY, and new STORAGE || pool MUST be defined. || || Defining new devclass, logical library, and storage pool for 3590E drive: || || DEFINE LOGICAL LIBRARY || define library lib_3590E libtype=3494 device=/dev/lmcp0 || privatecategory-lib_3590_private || scratchcategory=lib_3590_private+3 || || DEFINE DEVCLASS || define devclass devclass_3590E devtype=3590 || format=<3590E-C or 3590E-B or DRIVE> || library=lib_3590E || || DEFINE STORAGE POOL || define stgpool stg_3590E devclass_3590E other parameters || || Defining separate devclass for each type of drives will allow the user to || specify the format for the drive and insure that 3590 volumes will not be || mounted on 3590E drives and that 3590E volumes will not be mounted || on 3590 drives. || || Defining a logical library for each type of drives will allow to define two || separate storage pools of scratch volumes. It is necessary to allow write || the label for the volume in the appropriate format. || || Moving a scratch volume from 3590 scratch pool to 3590E scratch pool: || || - ADSM command: CHECKOut LIBVolume libraryname volname REMove=No || - ADSM command: CHECKIn LIBVolume libraryname SEARCH=Yes || || Note: In order to move volume from 3590 scratch pool to 3590E scratch pool || issue above commands and RELABEL the volume after it has been || checked in the 3590 library. || || IN ORDER TO READ THE VOLUME PREVIOUSLY WRITTEN IN 3590 FORMAT || ON 3590E DRIVE (THE STORAGE POOL THAT OWNS THE VOLUME POINTS || TO A DEVCLASS THAT USES 3590E drive): || - UPDATE ACCESS MODE TO THAT VOLUME TO READONLY || update volume volumename access=readonly; || - CHECKOUT THE VOLUME FROM THE LOGICAL 3590 LIBRARY || (THE DEVCLASS' OLD LIBRARY THAT HAD 3590 DRIVES); || - CHECKIN THE VOLUME TO THE LOGICAL 3590E LIBRARY || (THE DEVCLASS' NEW LIBRARY THAT CONTAINS 3590E DRIVES). || || Private volumes defined in private categories: || || The volumes defined in private category have to be marked READONLY in || order to read data from them on 3590E drives. After data is expired || and volume becomes empty its access type is still READONLY because || this volume was directly defined in the private category. In order || to reuse volumes with expired data on 3590E drives the access type of || these volumes must be updated to READWRITE type. The user may update || all volumes to READWRITE type with the following ADSM command: || update volume volumename/ *(all of them) access=readwrite || whereaccess=readonly wherestatus=empty || There are also SQL scripts that will allow the user to query all volumes || with above mentioned attributes. || || Next time the empty volume is mounted on 3590E drive for writing, || it will be AUTOMATICALLY relabeled using 3590E format. This volume || can be used neither for reading nor for writing on 3590 drives. || || Scratch volumes: || || Next time the empty volume is mounted on 3590E drive for writing, || it will be AUTOMATICALLY relabeled using 3590E format. This volume || can be used neither for reading nor for writing on 3590 drives. ====================================================================== Known Issues ====================================================================== | -- Latest Quantum DLT Drive Microcode is required for APAR IY03251 | | Customers should request the latest Quantum DLT microcode level from | their library vendors. For example, for STK customers, it is V95. For ATL | customers, it is level 95. -- HTMLHELP Online Information issues -- Prerequisites This release includes integrated HTMLHELP Online Information including books, readmes, questions and answers and TSM related web links. The HTMLHELP Help Viewer requires that Microsoft Internet Explorer version 3.02 or later be set up on a user's computer. It is not required that Internet Explorer be used as the system's default browser, or that the Internet Explorer icon be visible on the user's desktop. To obtain the latest version of Internet Explorer visit: http://www.microsoft.com/windows/ie Note that TSM will not set up an old version of the Help Viewer over a newer one. If you want to update the help viewer at any time visit: http://msdn.microsoft.com/workshop/author/htmlhelp -- Table of Contents subitem selection For certain entries in the table of contents you may select an item and not notice a change in position for the text displayed. There is a limitation in HTMLHELP that requires topics to be in their own file. If more than one topic is contained in a file then the HTMLHELP viewer will bring you to the right page but you will have to scroll down or search within that page to get to the topic. -- Default Program Folder name has been changed The documentation contains a number of references to the program folder named Tivoli TSM. The actual program folder name is Tivoli Storage Manager. -- Data Base Page Shadow Function Disabled The Data Base Page Shadowing function has been disabled. The DBPAGESHADOW option in the options file will have no effect. This function will be re-enabled at a later time. -- Query Volhistory Command The nodename, backupsetname, and description parameters included in the Query Volhistory command description have been deleted. The inforamtion provided by these parameters can be obtained with the query backupset command. -- Library sharing support A problem can arise where a dismount operation fails on the library client and the volume is not physically dismounted from the device. The following condition must be met for this problem to occur: 1. The library manager is down or cannot be contacted from the library client server 2. The library client attempts to dismount a volume, yet the volume is not physically removed from the drive. Issuing a QUERY MOUNT shows there are no volumes mounted. 3. The library manager can again be contacted within a 15 minute period from the initial failure. 4. Server to server communication is able to resume as normal and the library sharing recovery logic is able to verify the drive is still in use. The end result is that no mount points (QUERY MOUNT returns no volume in mount state) are in use on both the library manager and the library client, and a volume is now stuck in a device. To resume normal operation halt and restart the library client that had the volume last mounted. -- Changes to the TSM Administrator's Reference Commands Related to Expiring Database Backup Volumes and Recovery Plan Files: + SET DRMDBBACKUPEXPIREDAYS days Use this command to specify when a database backup series is eligible to be expired. The value set by this command controls expiration of full plus incremental database backup series and snapshot database backup series. The latest backup series of either type is not deleted. A full plus incremental or snapshot database backup series is eligible for expiration if all the following conditions are met: - The age of the last volume of the series has exceeded the expiration value of the SET DRMDBBACKUPEXPIREDAYS command. - The series is not the latest full plus incremental database backup series or snapshot database backup series. - In addition, for volumes that are not virtual volumes, all the volumes in the series are in the VAULT state. See the MOVE DRMEDIA command for additional information on expiration of database backup volumes that are not virtual volumes. See the EXPIRE INVENTORY command for additional information on expiration of database backup volumes that are virtual volumes. NOTE: This command only applies to environments that are licensed to use the Tivoli Disaster Recovery Manager product . + SET DRMRPFEXPIREDAYS days Use this command to specify when recovery plan files are eligible to be expired. This command and expiration processing only applies to recovery plan files that were created using the DEVCLASS parameter with the PREPARE command (i.e. virtual volumes of type RPFILE and RPFSNAPSHOT). The latest RPFILE and RPFSNAPSHOT files are not deleted. Expiration processing on the source server expires plan files stored on the target server. RPFILE and RPFSNAPSHOT files are associated with a database backup series during the generation of these recovery plan files: - An RPFILE is associated with a full plus incremental database backup series - An RPFSNAPSHOT is associated with a snapshot database backup series. An RPFILE or RPFSNAPSHOT file is eligible for expiration if all the following conditions are met: - The age of the last recovery plan file associated with a database backup series has exceeded the expiration value specified with the SET DRMRPFEXPIREDAYS command. - The recovery plan file is not associated with the most recent database backup series. See the EXPIRE INVENTORY command for additional information. NOTE: This command only applies to environments that are licensed to use the Tivoli Disaster Recovery Manager product. + EXPIRE INVENTORY When the Tivoli Disaster Recovery Manager (DRM) is licensed, the inventory expiration process removes eligible virtual volumes that are used for: - Full, incremental or snapshot database backups, that is virtual volumes of type BACKUPFULL, BACKUPINCR or DBSNAPSHOT respectively. See the SET DRMBACKUPEXPIREDAYS command for details on when these volumes are eligible for expiration. - Recovery plan files, that is virtual volumes of type RPFILE or RPFSNAPSHOT. See the SET DRMRPFEXPIREDAYS command for details on when these volumes are eligible for expiration. These volumes are not processed by expiration processing that occurs during Tivoli Storage Manager initialization. + MOVE DRMEDIA Use the MOVE DRMEDIA command to track database backup volumes and copy storage pool volumes that are to be moved offsite and to identify the expired or empty volumes that are to be moved onsite for reuse. The database backup volumes include volumes used for full, incremental, and snapshot database backups. This command does not process copy storage pool volumes and database backup volumes (full, incremental and snapshot database backup volumes) that are stored stored on another server via electronic vaulting (virtual volumes). NOTE: The state displayed by the QUERY DRMEDIA command for a volume stored on another server via electronic vaulting is REMOTE. Moving Reclaimed or Expired Volumes Back Onsite: ------------------------------------------------ MOVE DRMEDIA uses the following states for copy storage pool and database backup volumes that are to be moved back onsite: VAULT Volumes in this state contain valid data and are at the offsite location. When volume data becomes invalid the volumes automatically transition to the VAULTRETRIEVE state. VAULTRETRIEVE Volumes in this state do not contain valid data and are at the offsite vault. Volumes are to transition to this state from the VAULT state when: - Copy storage pool volumes are empty and have met the REUSEDELAY days in your copy storage pool definition - Database backup volumes are associated with a database backup series that has expired according to the SET DRMDBBACKUPEXPIREDAYS value. COURIERRETRIEVE Volumes in this state do not contain valid data, are with the courier, and being moved back to the onsite location. ONSITERETRIEVE Volumes in this state do not contain valid data, are at the onsite location, and are not managed by DRM. The volume records for the database backup (full, incremental and snapshot) and scratch copy storage pool volumes are deleted from the Tivoli Storage Manager database. The volume records of the private copy storage pool volumes are updated with the READWRITE access mode in the Tivoli Storage Manager database. -- Changes to the TSM Administrator's Guide - On page 389 in the section "Automatic Tuning of Server Options", the reference to TXNGROUPMAX should be removed. The server will not adjust the TXNGROUPMAX value on a node-by-node basis until it obtains the best performance. The tuning of the TXNGROUPMAX option is still a user configurable in the server options file. -- ADSM V3 DRM Disk Image Dump and Restore Diskettes and Doc. - The DRM Stand-alone Disk Image Dump and Restore Diskettes and Documentation have been stabilized at the ADSM Version 3.1.2 level. - The DRM Stand-alone Disk Image Dump and Restore Diskettes and Documentation will not be shipped with Tivoli Disaster Recovery Manager Product. - No maintenance or changes to the Disk Dump and Restore diskettes or documentation will be done to support new client hardware and environments or for changes in the Tivoli Storage Manager Version 3.7 Server. - If a Disk Image Dump and Restore client is used with a Tivoli Storage Manager Version 3.7 server, a warning message will be issued to the server console and written to the server activity log. The message indicates that the Disk Image Dump and Restore function has been stabilized and that no new maintenance or development will be done. - Customers can still restore disk images to the Disk Dump and Restore ADSM 3.1.2 supported hardware environment from the Tivoli Storage Manager server version 3.7. -- CONVERT USSFILESPACE command TSM now provides a utility to correct problems with the names of files and filespaces backed up or archived by an Open Edition MVS client (OEMVS client, now called System 390 UNIX client). Use this utility only if your existing TSM server has data from these clients. New TSM server databases installed with ADSM Server Version 3.1.2.30 or newer are not affected with this problem and do not have to use this utility. Problem Description ------------------- The TSM server displays incorrect character strings for filespaces and filenames in the output of a QUERY CONTENT command for files backed-up or archived by the System390 UNIX client. The problem is, that in the past and until the filespace conversion of the server is complete, System390 UNIX client sends filespace names and file names in a character set incompatible with the server. A new server command, CONVERT USSFILESPACE, corrects these character strings in the server database. You can determine if a server has files that need to be converted by issuing the following SQL commands: SELECT COUNT(*) FROM BACKUPS WHERE NODE_NAME IN () AND SUBSTR(HL_NAME,1,1)<>'/' SELECT COUNT(*) FROM ARCHIVES WHERE NODE_NAME IN () AND SUBSTR(HL_NAME,1,1)<>'/' where node list is a comma delimited list of node names that are of OEMVS platform type. This displays the number of files backed-up or archived that need conversion for the specified nodes. Example: SELECT COUNT(*) FROM BACKUPS WHERE NODE_NAME IN ( 'LISA','JIM', 'KATHY','JARED' ) AND SUBSTR(HL_NAME,1,1)<>'/' ************************************************************** * Note: * * It is recommended to back-up the server database * * before starting the conversion with the BACKUP DB command. * ************************************************************** To perform the conversion do the following : 1. Update the System390 UNIX clients to the latest level (V3.1.0.7) if you have not already done so. 2. Ensure that System390 UNIX client sessions are not running on the server. 3. Use the CONVERT USSFILESPACE command to correct the database entries. Command Details --------------- The CONVERT USSFILESPACE command processes TSM server database entries for filespaces for all nodes of platform type OEMVS and filespace type of HFS. The command corrects the database by converting character strings for file names and filespaces from System390 UNIX clients to the server compatible character set. Once the command is issued, System390 UNIX clients older than version 3.1.0.7 cannot log on to the server again. It is highly recommended to have no node sessions for System390 UNIX clients running on the server during the conversion process. If client sessions for nodes with platform type OEMVS are still running at the time this command is issued, they are cancelled by the server. All nodes eligible for conversion are locked until the conversion process is complete. If the conversion process is cancelled or stopped, the nodes remain locked until the conversion process is allowed to complete. Once the conversion is successfully complete, you will not have to run it again. Note: An administrator can unlock a node while the conversion process is running, or, when the process is not running but conversion is not complete ( ie. due to cancelled process, server stopped, etc ). However, this is not recommended since conversion may not be complete for this node. Any new data backed-up or archived with this node name before conversion is complete may cause unpredictable results for restore or retrieval of data. Privilege Class: To issue this command, you must have system privilege. Syntax >>---CONVert USSFilespace { CONTinue = Yes | No } ----<> Parameters CONTinue=continuevalue No Specifies that you want to start from the beginning of the conversion process and do not want to continue where the last conversion process stopped. This is the default. Yes Specifies that you want to continue from the last conversion. If the conversion process was cancelled or stopped for some reason, this option allows the administrator to continue the conversion from where it left off. Example: Convert all OEMVS filespaces and filenames to the correct character set. Command: CONVERT USSF ====================================================================== Trademarks ====================================================================== Tivoli and The Power to Manage. Anything. Anywhere. are trademarks or registered trademarks of Tivoli Systems Inc. in the United States, other countries, or both. In Denmark, Tivoli is a trademark licensed from Kjobenhavns Sommer - Tivoli A/S. IBM is a trademark of International Business Machines Corporation in the United States, other countries, or both.