================================================================================ README Welcome to the Tivoli Storage Manager, Version 3, Release 7. This is AIX server Maintenance Level 3.7.2.0 Licensed Materials - Property of IBM 5697-TSMAX (C) Copyright IBM Corporation 1990, 1999. All rights reserved. US Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp ================================================================================ This README is divided into the following sections: o Installation notes o Last minute changes to Documentation $$2 o DRM recovery plan file corrections $$2 o New server option SEARCHMPQUEUE for backup/restore and archive/retrieve operations o ADSM V3 DRM Disk Image Dump and Restore Diskettes ... o DRM recovery plan file explode sample AWK script modification $$2 o New parameters added to the DELETE VOLHISTORY command $$2 o Licensing Changes Between Server Versions 3.1.x and 3.7 o Data Base Page Shadow Function Disabled o New QUERYAUTH Server Option o AIX APAR IX89878 fix is required for ... $$1 o Latest Quantum DLT Drive Microcode is required for APAR IY03251 $$1 o Changes made to STK library device support o 8mm Drives, GENERICTAPE device type and Data Base Backup o Support for IBM 3590 Model Exx Tape Drives o CONVERT USSFILESPACE utility $$2 o Tape Library Sharing for SCSI libraries on a SAN $$1 o Tivoli instrumentation files mis-located for AIX server $$1 o Fixes to defects discovered during testing $$1 o APARS fixed in the 3.7.0.0 release $$1 o APARS fixed by service level 3.7.1.0 $$2 o APARS fixed by service level 3.7.2.0 o Where to find Documentation o Getting Help o Trademarks $$1 Changes made for maintenance level 3.7.1.0 are indicated by "$$1" $$2 Changes made for maintenance level 3.7.2.0 are indicated by "$$2" ********************************************************************** * Installation Notes * ********************************************************************** o The Tivoli Storage Manager server installation is designed for both new installations and as a replacement (migrate installation) to the ADSTAR Distributed Storage Manager (ADSM). - Tivoli Storage Manager installs into the path /usr/tivoli/tsm o If ADSM is installed, a migrate install will be performed. - ADSM will be deinstalled. - If the ADSM log and database are in /usr/lpp/adsmserv/bin, the file pointing to them (dsmserv.dsk) will be copied to the Tivoli Storage Manager server installation directory (/usr/tivoli/tsm/server/bin). Also, if a dsmserv.opt file is found in /usr/lpp/adsmserv/bin it is copied to /usr/tivoli/tsm/server/bin. - An "upgradedb" will be executed. o 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. ********************************************************************** * Last minute changes to Documentation * ********************************************************************** o Late changes to the Tivoli Storage Manager for AIX Quick Start. - On page 3 - The example for 'Step 6'(command scripts) is incorrect. It should be: dsmserv runfile /usr/tivoli/tsm/server/webimages/scripts.smp Note: The documentation avaiable via CD ROM is correct. - On page 3 - The example for 'Step 7'(web interface) is incomplete. You must also enter the following command: dsmserv runfile /usr/tivoli/tsm/server/webimages/dsmserv.idl - On page 6 - The example for 'Step 13'(command scripts) is incorrect. It should be: dsmserv runfile /usr/tivoli/tsm/server/webimages/scripts.smp - On page 7 - The example for 'Step 3'(shell in the ksh family) is incorrect. It should be: export DSMSERV_DIR=/usr/tivoli/tsm/server/bin - On page 8 - The 1st example for 'Running Mulitple Servers on a Single Machine' is incorrect. It should be: mkdir /usr/local/newserv cp /usr/tivoli/tsm/server/bin/dsmserv.opt /usr/local/newserv/dsmserv.opt - On page 8 - The 2nd example for 'Running Mulitple Servers on a Single Machine' is incorrect. It should be: dsmserv runfile /usr/tivoli/tsm/server/webimages/dsmserv.idl - On page 8 - The 3rd example for 'Running Mulitple Servers on a Single Machine' is incorrect. It should be: dsmserv format 1 logvol2 2 dbvol2 dbvol3 - On page 9 - The section on verifying your installation should include the following text: Configure the backup-archive client by doing the following: 1. Copy the sample client system options file (dsm.sys.smp) and the sample client user options file (dsm.opt.smp). The sample files are in /usr/tivoli/tsm/client/ba/bin/ 2. Edit the options files to include the options listed below: dsm.opt: servername server_name dsm.sys: servername server_name commmethod tcpip tcpport port_address tcpserveraddress server_address nodename client Note: The server names specified in dsm.opt and dsm.sys must match. See the "Tivoli Storage Manager Installing the Clients" manual for more information. - On page 9 - Step 2 (starting the backup-archive client GUI) should read: 2. Start the backup-archive client graphical user interface by entering the following command: dsm The default name and password for the backup-archive client created at server installation are: Name client Password client - On page 16 - Step 1 (examples for extending the database and recovery log are incorrect. They should be: extend db 500 extend log 25 - On page 75 - Under the heading "Internet" the machine name should be: ftp.software.ibm.com TSM information is in the /storage/adsm directory. o Query Volhistory Command The nodename, backupsetname, and description parameters included in the Query Volhistory command description have been deleted. The information provided by these parameters can be obtained with the QUERY BACKUPSET command. o Changes to the Tivoli Storage Manager 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. o Changes to the Tivoli Storage Manager Administrator's Guide - 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. $$2 ********************************************************************** $$2 * DRM recovery plan file corrections $$2 ********************************************************************** $$2 $$2 Tivoli Storage Manager Development has recently discovered that several $$2 DRM messages are missing from the message catalog or are corrupted. $$2 This can result in the creation of a recovery plan file in which one or $$2 more generated macros are invalid. For example your plan file might contain $$2 an entry like $$2 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* $$2 $$2 begin COPYSTGPOOL.VOLUMES.AVAILABLE macro $$2 $$2 */ $$2 $$2 end COPYSTGPOOL.VOLUMES.AVAILABLE macro $$2 $$2 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* $$2 or like $$2 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* $$2 $$2 begin COPYSTGPOOL.VOLUMES.DESTROYED macro $$2 $$2 t were not destroyed. */ $$2 $$2 $$2 end COPYSTGPOOL.VOLUMES.DESTROYED macro $$2 $$2 *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-* $$2 $$2 AFTER APPLYING THIS SERVICE LEVEL, IF YOU ARE USING DRM, YOU SHOULD RE-CREATE $$2 YOUR RECOVERY PLAN FILE. $$2 $$2 ********************************************************************** $$2 * New server option SEARCHMPQUEUE for backup/restore and archive/retrieve operations $$2 ********************************************************************** $$2 The new server option SEARCHMPQUEUE can be used to modify mount how the $$2 server selects mount requests from the mount request queue. $$2 When specified, the server first looks to dispatch a request that needs an $$2 already mounted volume. The selected request may be dispatched before $$2 other requests on the mount point queue even though the other requests $$2 have been waiting longer for a mount point. Without this option specified, $$2 the server satisifies mount requests as first-come, first-served. ********************************************************************** * ADSM V3 DRM Disk Image Dump and Restore Diskettes and Documentation* ********************************************************************** - 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. ********************************************************************** * DRM recovery plan file explode sample AWK script modification ********************************************************************** The sample awk script (planexpl.awk.smp), used to break out the stanzas from a disaster recovery plan file, has been modified. The sample awk script will now prepend the plan prefix, used to generate the plan file, to the individual stanza filenames. $$2********************************************************************** $$2* New parameters added to the DELETE VOLHISTORY command * $$2********************************************************************** $$2 $$2 The following new parameters have been added to the $$2 DELETE VOLHISTORY command: $$2 $$2 o DEVCLASS=classname $$2 $$2 o DELETELATEST=Yes|No $$2 $$2 Command Syntax: $$2 $$2 $$2 >>--DELete VOLHistory--TODate--=--date--+-----------------+--> $$2 +--TOTime-=-time--+ $$2 $$2 $$2 >--Type--=--+-All---------------------------------------+--->< $$2 |-DBDUMP------------------------------------| $$2 | | $$2 | ..... | $$2 | | $$2 |-DBBackup------+------------------------+--| $$2 | +--DEVclass--=classname--+ | $$2 | | $$2 |-DBsnapshot----+------------------------+--| $$2 | +--DEVclass--=classname--+ | $$2 | | $$2 | +--DELETELatest--=---No--+ | $$2 |-RPFile--------+------------------------+--| $$2 | +--DELETELatest--=-+-No--+ | $$2 | +-Yes-+ | $$2 | | $$2 | +--DELETELatest--=---No--+ | $$2 |-RPFSnapshot---+------------------------+--| $$2 | +--DELETELatest--=-+-No--+ | $$2 | +-Yes-+ | $$2 | | $$2 +-------------------------------------------+ $$2 $$2 $$2 New Parameters: $$2 $$2 o DEVclass=classname $$2 Specifies the device class name that was used to create the $$2 database backups. This optional parameter can be used to $$2 delete database backups created using a server-to-server $$2 virtual volume device class. The type of the device class $$2 must be SERVER. $$2 $$2 This parameter can only be used to delete volume history $$2 entries of type BACKUPFULL, BACKUPINCR, or DBSNAPSHOT. $$2 $$2 A full, incremental or snapshot database backup volume $$2 is eligible to be deleted if all of the following conditions $$2 are met: $$2 - The device class used to create the database backup $$2 volume matches the specified device class $$2 - The volume was created on or before the specified $$2 date/time. $$2 - The volume is not part of the latest full plus $$2 incremental database backup series if the specified $$2 volume type is DBBackup, or snapshot database backup $$2 series if the volume type is DBSnapshot. $$2 $$2 $$2 o DELETELatest=Yes|No $$2 Specifies whether the latest recovery plan file is eligible $$2 for deletion. This optional parameter can only be used to $$2 delete volume history entries of type RPFILE or RPFSNAPSHOT $$2 (i.e. recovery plan files that were created using a $$2 server-to-server virtual volume device class). If this parameter $$2 is not specified, the latest RPFILE and RPFSNAPSHOT entries are $$2 not deleted. $$2 $$2 DELETELatest=No $$2 Specifies the latest RPFILE or RPFSNAPSHOT file is NOT deleted. $$2 $$2 DELETELatest=Yes $$2 Specifies the latest RPFILE or RPFSNAPSHOT file is deleted if $$2 it meets the specified date and time criteria. $$2********************************************************************** $$2* Licensing Changes Between Server Versions 3.1.x and 3.7 * $$2********************************************************************** $$2 $$2 The license terms have changed for the Tivoli Storage Manager (TSM) $$2 server Version 3.7. Customers that were in compliance with the $$2 license terms on ADSM server version 3.1.x may find themselves $$2 out of compliance when migrating to TSM 3.7. This notice has been $$2 developed to address the changes to the DRM and server-to-server $$2 virtual volume licenses. $$2 $$2 For the ADSM server version 3.1.x, electronic vaulting of $$2 database and storage pool backups was licensed via the $$2 server-to-server virtual volume license. The $$2 server-to-server virtual volume license was required $$2 on the source and target servers. $$2 $$2 For the TSM server version 3.7, the base TSM server license $$2 includes server-to-server virtual volume capabilities except $$2 for electronic vaulting of database and storage pool backups. $$2 The DRM (Tivoli Disaster Recovery Manager) license now $$2 includes electronic vaulting of storage pool and database $$2 backups. This license is only required on the source server. $$2 $$2 Customers using electronic vaulting of database or $$2 copy storage pool backups on ADSM servers version 3.1.x $$2 should do one of the following when migrating to TSM $$2 Version 3.7: $$2 o Purchase and register the Tivoli Disaster Recovery $$2 Manager license $$2 OR $$2 o Delete the storage pool and database backups that were $$2 created using a server-to-server virtual volume device $$2 class (i.e. device class of type SERVER). $$2 Information on these tasks follows. $$2 $$2 Deleting Storage Pool Backups $$2 ---------------------------------- $$2 $$2 If you decide to delete a copy storage pool associated with $$2 a device class of type SERVER, do the following: $$2 $$2 1. You should consider creating another copy storage pool $$2 associated with a local device class. $$2 $$2 Define a copy storage pool associated with a local device $$2 class and create a full backup of the primary storage $$2 pools that were backed up to the copy storage pool to be $$2 deleted. $$2 $$2 2. To delete a copy storage pool, you must first delete $$2 all the volumes assigned to the storage pool: $$2 o For each volume defined to the copy storage pool, issue $$2 the 'DELETE VOLUME volname DISCARDDATA=yes' command. $$2 o If the volume deletion process is cancelled or a $$2 system failure occurs, you may have to issue the $$2 DELETE VOLUME command again with the DISCARDDATA=Yes $$2 parameter. $$2 $$2 3. Use the 'DELETE STGPOOL copyPoolName' command to delete $$2 the copy storage pool. $$2 $$2 $$2 Deleting Database Backups $$2 ------------------------------ $$2 $$2 If you decide to delete the database backups created using $$2 a device class of type SERVER, do the following: $$2 $$2 1. If the latest database backup series was created using a $$2 device class of type SERVER, you must create a new database $$2 backup series using a local device class. $$2 $$2 2. Delete the volume history entries for the database backups. $$2 There are two ways to delete the entries: $$2 $$2 o Use the 'DELETE VOLHIST TYPE=DBB TODATE=date TOTIME=time' $$2 command to delete 'old' volume history entries for database $$2 backups. Note that this command will delete ALL the $$2 full and incremental database entries created on or $$2 before the specified date/time. $$2 $$2 o Use the DELETE VOLHISTORY command with the new parameter, $$2 DEVCLASS=classname. This optional parameter can only $$2 be used to delete database backups created using a $$2 server-to-server virtual volume device class. $$2********************************************************************** $$2* Tape Library Sharing for SCSI libraries on a SAN $$2********************************************************************** $$2 $$2 Terminology used in this document $$2 ================================= $$2 $$2 SAN - Storage Area Network. $$2 $$2 Library Manager - A Tivoli Storage Manager server that controls the $$2 operations pertaining to the library, in particular, $$2 mount, dismount, volume ownership, and library inventory. $$2 $$2 Library Client - A TSM server that requests library service from a library $$2 manager. The library client cannot perform $$2 library management functions. $$2 $$2 What is supported in this package? $$2 ================================== $$2 $$2 AIX 4.3.2 or better $$2 ATAPE 5.0 or better $$2 Tivoli Storage Manager server version 3.7 $$2 $$2 IBM Solution: $$2 Emulex LP7000E HBA using latest device driver $$2 IBM Storage Area Network Data Gateway Firmware level 2.66.14 or better $$2 A Tape library listed below: $$2 IBM 3570 tape library $$2 IBM 3575 tape library $$2 IBM 3590 tape library not in a 3494 or 3495 $$2 $$2 For current configuration information check out: $$2 http://www.tivoli.com/support/storage_mgr/san/solution_device.html $$2 $$2 How to Set up a SAN $$2 =================== $$2 $$2 First set up the library manager, then set up the library clients. $$2 $$2 1. Format the database and log file with "dsmserv format". $$2 $$2 Example: "dsmserv format 1 log 20 1 db 100" $$2 $$2 Multiple Servers can run on the same machine from different $$2 directories using the dsmserv -k option. $$2 $$2 Example: "dsmserv -k server2 format 1 log 20 1 db 100" $$2 $$2 2. Start the server. $$2 $$2 Example: "dsmserv" $$2 $$2 For multiple servers on the same machine use the -k option. $$2 $$2 Example: "dsmserv -k server2" $$2 $$2 3. Register an administrator: $$2 $$2 reg admin $$2 $$2 4. Grant the administrator authority. $$2 $$2 grant auth class=sys $$2 $$2 5. Set the server information: $$2 $$2 SET SERVERNAME $$2 SET SERVERPASSWORD $$2 SET SERVERHLADDRESS
$$2 SET SERVERLLADDRESS $$2 SET SERVERURL http://
: $$2 SET CROSSDEFINE on $$2 $$2 For multiple servers on the same machine make sure that the ports are different. $$2 $$2 6. Verify that the TSM Device Driver is started. To verify this on NT, open $$2 "TSM Server Utilities", go to "Service Information" and click the "TSM Services" $$2 tab. Also, obtain device information regarding the library and drives using $$2 Device Information, this information will be needed below. The list may need to be $$2 refreshed for the information to appear if the device driver was not started previously. $$2 On AIX, use SMIT to verify that the devices are available. $$2 $$2 7. Repeat Steps 1 through 6 for each library client server, and give $$2 each server a different name. $$2 $$2 8. For the server that is the library manager proceed to: $$2 "How to setup a Tivoli Storage Manager server as a library manager" $$2 $$2 For each server that is a library client proceed to: $$2 "How to setup a Tivoli Storage Manager server as a library client" $$2 $$2 How to set up a Tivoli Storage Manager server as a library manager $$2 ================================================================== $$2 $$2 1. Configure the SCSI library as done with previous versions. $$2 Except add "SHARED=YES" to the "DEFINE LIBRARY" command. "SHARED=YES" may also $$2 be used with the UPDATE LIBRary command. $$2 $$2 Example: $$2 $$2 define library 3570 libt=scsi devi=/dev/rmt1.smc shared=yes $$2 update library 3570 shared=yes $$2 $$2 2. Define the drives in the library $$2 $$2 Example: $$2 $$2 define drive 3570 drive1 devi=/dev/rmt4 element=16 $$2 define drive 3570 drive2 devi=/dev/rmt5 element=17 $$2 $$2 3. Define at least one device class associated with the shared library. $$2 Hint: Use a low mount retention and mount wait time. Set the $$2 mount wait times to different values for each server. $$2 $$2 Example: $$2 $$2 define devclass tape devtype=3570 mountr=5 mountw=10 libr=3570 $$2 $$2 4. Check in the library inventory $$2 $$2 Example: $$2 label libvol 3570 search=yes labels=barcode checkin=scratch $$2 overwrite=yes $$2 $$2 This labels the tapes and checks them into the library inventory as $$2 scratch volumes. $$2 $$2 -=- OR -=- $$2 $$2 checkin libvol 3570 search=yes checkl=barcode status=scr $$2 $$2 This will check in all volumes into the library inventory as scratch $$2 volumes. $$2 $$2 5. Set up Storage Pools. $$2 $$2 The library manager is now set up for a SAN. All normal server $$2 funtionality is available to the library manager. $$2 $$2 How to set up a Tivoli Storage Manager server as a library client $$2 ================================================================= $$2 $$2 1. Define the server that is the library manager: $$2 $$2 DEFINE SERVER COMMMETHOD=TCPIP SERVERPASSWORD= $$2 HLADDRESS=
LLADDRESS= CROSSDEFINE=YES $$2 $$2 2. Define a shared library of the same name as on the library manager. $$2 $$2 define libr 3570 libt=shared primarylibmanager= $$2 $$2 3. Define the drives to the library using the same names on the library $$2 manager. $$2 $$2 Example: $$2 define drive 3570 drive1 devi=/dev/rmt1 $$2 define drive 3570 drive2 devi=/dev/rmt2 $$2 $$2 4. Define at least one device class associated with the shared library. $$2 Hint: Use a low mount retention and mount wait time. Set the $$2 mount wait times to different values for each server. $$2 $$2 Example: $$2 $$2 define devclass tape devtype=3570 mountr=5 mountw=10 libr=3570 $$2 $$2 $$2 5. Set up a storage pool associated with the device class for the shared $$2 library. $$2 $$2 The library clients are now setup for operation on a SAN. Most $$2 normal server functionality is available to the library clients. $$2 A library client cannot perform library management operations on a $$2 shared library, such as: checkin, checkout, label, and all libvol operations. $$2 $$2 $$2 Command Updates in this version for SHARED library support $$2 ========================================================== $$2 $$2 DEFINE LIBRARY has added the following options: $$2 LIBType=SHARED $$2 SHARED=YES|NO $$2 PRimarylibmanager= $$2 $$2 UPDATE LIBRARY has the added option: $$2 SHARED=YES|NO $$2 $$2 DEFINE DRIVE notes: $$2 No updates for SCSI, 3494, etc. $$2 Element not required for SHARED library drives $$2 $$2 CHECKIN LIBVOL has added the following options: $$2 OWNER= $$2 $$2 UPDATE LIBVOL has added the following options: $$2 OWNER= $$2 $$2 QUERY commands and SQL tables have been updated with the new parameters $$2 $$2 Web interface has been updated on AIX for SHARED libraries ********************************************************************** * 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. ********************************************************************** * New QUERYAUTH Server Option * ********************************************************************** A new option has been added to the server options file for specifying the level of authority that is required for issuing server QUERY or SELECT commands. Refer to the information on QUERYAUTH parameter in the sample server options file for more details. ********************************************************************** * AIX APAR IX89878 fix is required for ... * ********************************************************************** Customers using AIX 4.3 and raw volumes for their database, recovery log, or storage pool volume may encounter a BUF087 server assertion. This only happens under certain conditions when writing to the raw disk device. The cause of the error is in the AIX 4.3 operation system. Any customer wishing to use raw disk devices (/dev/r???) for a server volume, must apply the AIX maintenance for IX89878. $$1 ********************************************************************** $$1 * Latest Quantum DLT Drive Microcode is required for APAR IY03251 * $$1 ********************************************************************** $$1 $$1 Customers should request the latest Quantum DLT microcode level from $$1 their library vendors. For example, for STK customers, it is V95. $$1 For ATL customers, it is level 95. ********************************************************************** * 8mm Drives, GENERICTAPE device type and Database Backup * ********************************************************************** Database backups to 8mm tape will fail if the GENERICTAPE device type is used in a device class definition instead of the 8mm device type. The GENERICTAPE device type causes the AIX native device driver to be used. The 8mm device type uses the Tivoli Storage Manager (TSM) device driver. Only database backup is affected. The workaround is to use the TSM device driver instead. The device definition can be updated using the UPDATE DRIVE library drivename device=/dev/mtx command to specify the TSM device name( /dev/mtx where x is numeric ) after using SMIT to configure the drive as a TSM TAPE device. ********************************************************************** * Support for IBM 3590 Model Exx Tape Drives * ********************************************************************** TSM 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). TSM 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: Device Driver level: Atape.4.4.0.0 (ftp://service.boulder.ibm.com/storage/devdrvr/AIX) Microcode level: 3590E - EC F23200 D01C_502 NOTE: To convert a 3590E volume to 3590 must have microcode level EC D19328 D01A_2FC 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 /dev/rmt0. 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 TSM server: - Using SMIT utility or manually, remove /dev/rmt0 device example: rmdev -l 'rmt0' '-d; - Using SMIT utility or manually, define the 3590E device example: mkdev -c tape -t '3590' -s 'scsi' -p 'scsi0' -w '0,0' -l 'rmt0'; - Run TSM server (dsmserv); - Issue TSM command: UPDate DEVclass devclassname FORMAT=DRIVE update devclass devclass_3590 FORMAT=DRIVE; - Issue TSM command: DELete DRive libname drivename delete drive lib_3590 drive_3590; - Issue TSM command: DEFine DRive libname drivename DEVIce=devicename define drive lib_3590 drive_3590 device=/dev/rmt0; - 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 on /dev/rmt0 and a new 3590E drive defined on /dev/rmt1. 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 scratchcategory=lib_3590_scratch privatecategory=lib_3590_scratch+3 DEFINE DEVCLASS define devclass devclass_3590E devtype=3590 format=3590E-C library=lib_3590E format=3590E-B format=DRIVE 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: - TSM command: CHECKOut LIBVolume libraryname volname REMove=No - TSM 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 TSM 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. ********************************************************************* * CONVERT USSFILESPACE command * ********************************************************************* Tivoli Storage Manager (TSM) 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). If this is a new Tivoli Storage Manager server installation for V3.7 you are not affected with this problem and do not have to use this utility. You are affected if you migrate from ADSM Version 3.1 and have data from a System 390 UNIX client of a level earlier than 3.1.0.7 in your database, and, have not completed the conversion ( CONVERT USSFILESPACE command ) prior to migrating. Problem Description ------------------- The ADSM 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 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 $$1 ********************************************************************** $$1 * Changes made to STK library device support * $$1 ********************************************************************** $$1 THe following changes have been made for STK library device support $$1 $$1 o Compile STK toolkit library with AIX 4.2 compiler. It was discovered $$1 that this library, compiled on AIX 4.1.4 was incompatable with an $$1 AIX 4.2 environment $$1 <@> $$1 o Timeout value increased to 15 minutes $$1 <@> $$1 o Modifications made to improve performance of ACSLS during initialization $$1 <@> $$1 ********************************************************************** $$1 * Tivoli instrumentation files mis-located for AIX server * $$1 ********************************************************************** $$1 Due to a packaging oversight the Tivoli "instrumentation" files necessary $$1 for Tivoli "GEM" and Tivoli "Inventory" product use with Tivoli Storage $$1 Manager are restored to the wrong location. If you intend to use either $$1 "GEM" or "Inventory" with Tivoli Storage Manager you will have to correct $$1 this oversight manually. $$1 $$1 The steps to make the correction are: $$1 (You must be root user) $$1 1. create the directory /etc/tivready/monitorslfs $$1 2. cd /etc/tivready/monitorslf $$1 3. cp the instrumentation file to this new directory $$1 o cp ./AIX_ADSM_Server.slf /etc/tivready/monitorslfs/AIX_ADSM_Server.slf $$1 o cp ./trinstex.sh /etc/tivready/monitorslfs/trinstex.sh $$1 o cp ./trstatex.sh /etc/tivready/monitorslfs/trstatex.sh $$1 ********************************************************************** $$1 * Fixes to defects discovered during testing * $$1 ********************************************************************** $$1 During the course of testing some "deadlock"/"crash"/"hang" conditions $$1 were discovered. These have been corrected in this maintenance package. $$1 The symptoms are described below $$1 o ANR9999D pkthread.c(762) ...txnP->waitingForLock $$1 $$1 Two Pumpagg jobs are started to go to two different nodes in the same domain $$1 ("pumpagg" is a file aggregation/reclamation/expiration test scenario> $$1 (VIRTMAN and VIRTMAN2), whose copy group is set to go to virtual volumes. $$1 These pumgagg jobs execute fine for a while, but eventually the server crashes $$1 with the following error: $$1 $$1 ANR9999D pkthread.c(762): Run-time assertion failed: "txnP->waitingForLock == $$1 NULL", Thread 38, File tmlock.c, Line 500. $$1 <@> $$1 o Deadlock state reached through pumpagg & server crashes $$1 $$1 Four pumpagg jobs are started to go to two different virtual device classes $$1 (two to each), and A deadlock state was reached. The deadlock was resolved $$1 when one of the sessions was cancelled. $$1 <@> $$1 o Pumpagg causes tbundo.c(256): Error 1, and server crashes $$1 $$1 Pumpagg is run to a file device class, and after about 100 cycles, $$1 the server reports the following error message, and shuts down: $$1 $$1 ANR9999D tbundo.c(256): Error 1 on insert from table Inventory.Attributes $$1 for undo. $$1 ANR7838S Server operation terminated. $$1 ANR7837S Internal error TBUNDO012 detected. $$1 <@> $$1 o Server crashes when 'audit library' is run $$1 <@> $$1 ********************************************************************** $$1 * APARS fixed in the release 3.7.0.0 * $$1 ********************************************************************** $$1 $$1 IY03618 3.1.2.40 SERVER ABENDS WHEN ATTACHED TO A STK 9310 LIBRARY $$1 RUNNING ACSLS $$1 $$1 Server may crash with TMTXN008 ABEND if there is an error updating $$1 the inventory list during ACSLSL initialization. $$1 $$1 The release also includes fixes for the following device driver fixes. $$1 The device driver README files also include this information. $$1 $$1 IC24458 ILLEGAL REQUEST DURING READ ELEMENT STATUS AFTER STK 9710 $$1 FIRMWARE UPGRADE $$1 Additional data were returned from the Read Element Status command, $$1 causes incompatible storage allocation between the new firmware and $$1 the current ADSM device driver. The fix resolves the differences $$1 for 9710, 9714 and 9740 firmware upgrades. $$1 $$1 IY03314 ELAINT IS RECOGNIZED AS EXB8505 AND THEREFORE CANNOT LABEL $$1 TAPES WITH THE LABEL LIBVOL COMMAND $$1 The "Label Libvol" command fails with an I/O error when using $$1 Exabyte Eliant 820 drive. $$1 ********************************************************************** $$1 * APARS fixed by service level 3.7.1.0 * $$1 ********************************************************************** $$1 $$1 IY03199 - ADSM AIX SERVER 3.1.2.22 SERVER INCORRECTLY IDENTIFIES 3590E $$1 VOLUMES AS 4MM VOLUMES TO SUBSEQUENT SERVERS. $$1 ( Database Repair Command for 3590E early support customers ) $$1 $$1 ADSM development has discovered a problem in the 3.1.2.22 ADSM server $$1 where it incorrectly identifies 3590E volumes as 4MM volumes to subsequent $$1 servers. This problem only affects customers on 3.1.2.22 with 3590E $$1 drives. Subsequent servers will not recognize a 3590E volume introduced $$1 to a storage pool while running the 3.1.2.22 server. $$1 $$1 ADSM development is providing a special server command to repair the $$1 database so that customers can access the affected volumes. $$1 $$1 Although there is no loss of data, as a precaution, you should $$1 backup your ADSM database before performing the repair insructions below. $$1 $$1 1. Backup your ADSM database. $$1 2. Apply this server update (do not commit the update until you are satisfied that $$1 the repair is successfull.) $$1 3. Add the option DISABLESCHEDS YES to your server options file. $$1 4. Start the server. $$1 4.1 Enter disable sessions at the ADSM prompt. $$1 4.2 Delete the 3590E drive definitions. $$1 4.3 Redefine the 3590E drives. $$1 4.4 If the current format of the 3590 device classes is not DRIVE, $$1 update the format to DRIVE, 3590E-B or 3590E-C. $$1 For example, UPDATE DEVCL <3590 device class> FORMAT= $$1 4.5 Display a list of the affected volumes, by running the SHOW FORMATDEVCLASS $$1 command. $$1 For example SHOW FORMATDEVCLASS <3590 device class> $$1 4.6 Repair the database, by running the SHOW FORMATDEVCLASS command again with the $$1 UPDATEFORMAT option. $$1 For example, SHOW FORMATDEVCLASS <3590 device class> UPDATEFORMAT $$1 5. After the command completes, halt the server. $$1 6. Remove DISABLESCHEDS YES from the options file. $$1 7. Restart the server and continue running. $$1 <@> $$1 PQ30157 EXPIRATION DM0001S TXNLOCK16 ABENDU0301 $$1 $$1 There is a possibility of the server crashing $$1 with a TXNLOCK15 or TXNLOCK16 message $$1 when a move data operation ( migration, reclamation, $$1 move data ) is run concurrently with a deletion $$1 operation ( expiration, delete filespace, delete volume ). $$1 <@> $$2 ********************************************************************** $$2 * APARS fixed by service level 3.7.2.0 * $$2 * APARS may apply to both ADSM and Tivoli Storage Manager. * $$2 * The APAR associated with Tivoli Storage manager will be indicated * $$2 * by a suffix of "37". For example IC25588(SUN37) * $$2 ********************************************************************** $$2 $$2 IC24035 WHEN UPDATING NODE WITH A WILDCARD, IF A NODE FAILS THE COMMAND $$2 $$2 SYSROUTES: IC25585(AIX37),PQ33700(MVS37),IC25586(NT37),IC25587(HP37), $$2 IC25588(SUN37) $$2 $$2 Insufficient messages issued when an UPDATE NODE updating $$2 multiple nodes fails because a node is in use. $$2 $$2 <@> $$2 IC24676 ANR8829I REMOVE VOL FROM SLOT 30 OF LIBRARY $$2 $$2 SYSROUTES: IY05373(AIX),IC24676(NT),IC25135(HP),IC25136(SUN),IC25589(AIX37), $$2 IC25590(NT37),IC25592(HP37),IC25591(SUN37) $$2 $$2 In the ANR8829I message, the ADSM server does not display $$2 the element address of the Entry/Exit slot where it placed $$2 the volume just checked out from the library with the $$2 the CHECKOUT LIBVOLUME command and the REMOVE=BULK option. $$2 The server reports the same element address (element address $$2 of 30) each time. $$2 $$2 <@> $$2 IC24886 FORCED PASSWORD CHANGE OPTION NOT WORKING IN ENTERPRISE MANAGEM $$2 $$2 SYSROUTES: IC25593(AIX37),PQ33702(MVS37),IC25594(NT37),IC25596(HP37), $$2 IC25595(SUN37) $$2 $$2 The FORCEPWRESET attribute of an administrator was not being $$2 passed from the configuration manager server to the managed $$2 server. $$2 $$2 The FORCEPWRESET attribute of an administrator was not being $$2 passed from the configuration manager server to the managed $$2 server. $$2 $$2 <@> $$2 IC25105 WHEN REMOVING A NODE NAME THAT WAS REGISTERED W/ USERID= PARM, $$2 $$2 SYSROUTES: IY07426(AIX),PQ34661(MVS),IC25910(NT),IC25911(HP),IC25912(SUN), $$2 PQ34663(VM),IC25105(AIX37),PQ34664(MVS37),IC25913(NT37), $$2 IC25914(HP37),IC25915(SUN37) $$2 $$2 When removing a node name that was registered with non default $$2 administrator id no warning message is issued indicating $$2 that the admin user id not removed. $$2 $$2 <@> $$2 IX87208 SERVER MACRO CAUSES ACTLOG CORRUPTION, AND SOMETIME THE SERVER $$2 $$2 SYSROUTES: IX87208(AIX),PQ24308(MVS),IC23305(NT),IC23306(HP),IC23307(SUN), $$2 IC25597(AIX37),PQ33703(MVS37),IC25598(NT37),IC25600(HP37), $$2 IC25599(SUN37) $$2 $$2 A query actlog on an extra long command line failed. $$2 Possible symptoms include hangs or traps. $$2 $$2 <@> $$2 IX88345 THE FORMAT OF THE ANR8808E MESSAGE IS NOT BEING DISPLAYED CORRE $$2 $$2 SYSROUTES: IC25601(AIX37),PQ33706(MVS37),IC25602(NT37),IC25604(HP37), $$2 IC25603(SUN37) $$2 $$2 The message ANR8808 had an imbedded tab character and other $$2 incorrect spacing in the message. These errors in the $$2 message cause it to not format correctly to the server $$2 console or to an admin client. The formatting errors $$2 do not prevent the message from being issued - it just $$2 does not display well. $$2 $$2 <@> $$2 IY00827 DEFINE SCHED OR UPDATE SCHED PARAMETER CMD='CHECKING LIBVOL...' $$2 $$2 SYSROUTES: IC25605(AIX37),IC25606(NT37),IC25607(HP37) $$2 $$2 Commands are not recognized as eligible for scheduling. $$2 $$2 <@> $$2 IY02812 THE SET CONFIGREFRESH COMMAND FAILS TO CONTACT CONFIGURATION MA $$2 $$2 SYSROUTES: IC25678(NT37) $$2 $$2 ADSM Server Monitor thread was not properly initialized when $$2 the Server is started as a Windows NT service. $$2 $$2 <@> $$2 IY03035 ISSUING HELP COMMANDS FROM THE COMMAND LINE OF THE WEB ADMIN IN $$2 $$2 SYSROUTES: IC25608(AIX37),PQ33710(MVS37),IC25609(NT37),IC25611(HP37), $$2 IC25610(SUN37) $$2 $$2 Issuing HELP commands from the command line of the WEB Admin $$2 interface may cause the ADSM server to crash. $$2 $$2 <@> $$2 IY03374 UNDER CERTAIN ERROR CONDITIONS WITH 3494, AN RC 11 IS RETURNED $$2 $$2 SYSROUTES: IY03374(AIX),IC25258(NT),IC25259(HP),IC25260(SUN),IC25612(AIX37), $$2 IC25613(NT37),IC25615(HP37),IC25614(SUN37) $$2 $$2 This APAR documents a problem that occurs only on 3494 $$2 libraries when the customer's USEREXIT forks a process. $$2 $$2 Background information leading up to the problem: $$2 When ADSM calls close() to close a file handle to a drive, $$2 the close() call returns a return code of 0 (success). $$2 However, because the forked process inherited ADSM's open $$2 file handles, the device driver never receives the close() $$2 call. When ADSM calls open() to open a new file handle to $$2 the same drive, the open() call returns a return code of 11. $$2 $$2 Description of the problem: $$2 After receiving the errno=11, ADSM does not correctly $$2 handle the error situation. As a result, ADSM may close $$2 another process's file handle in error if there are at least $$2 11 open file handles. The number of open file handles depends $$2 on the customer's environment and the amount of activity $$2 at the time when the USEREXIT forked the new process. $$2 $$2 <@> $$2 IY03390 SERVER HANG DURING BACKUP STORAGEPOOL IF WAIT=YES OPTION IS USE $$2 $$2 SYSROUTES: IC25629(AIX37),PQ33718(MVS37),IC25630(NT37),IC25632(HP37), $$2 IC25631(SUN37) $$2 $$2 The processing for BACKUP STORAGEPOOL with the WAIT=YES $$2 parameter may hang and/or abend the server. $$2 $$2 <@> $$2 IY03519 DEFINES AND UPDATES MADE WITH THE WEB ADMIN DO NOT UPDATE THE D $$2 $$2 SYSROUTES: IC25617(AIX37),PQ33715(MVS37),IC25618(NT37),IC25621(HP37), $$2 IC25619(SUN37) $$2 $$2 Using the web interface to update or define device related $$2 information, the device configuration file is not updated. $$2 $$2 <@> $$2 IY03614 ADSM NOT FREEING MEMORY (TCPSENDSSL) PROPERLY. $$2 $$2 SYSROUTES: IC25622(AIX37),PQ33717(MVS37),IC25623(NT37),IC25625(HP37), $$2 IC25624(SUN37) $$2 $$2 Web Admin client does not free memory correctly $$2 $$2 <@> $$2 IY03618 3.1.2.40 SERVER ABENDS WHEN ATTACHED TO A STK 9310 LIBRARY RUNN $$2 $$2 SYSROUTES: IY03618(AIX),IC25397(NT),IC25398(SUN),IC25626(AIX37),IC25627(NT37), $$2 IC25628(SUN37) $$2 $$2 Server can core during initialization while initializing $$2 the ACSLS library. Core will occur if an error occurs $$2 while updating the inventory list. The core is $$2 a TMTXN008 error. $$2 $$2 <@> $$2 IY03818 ADSM UNNECESSARILY DISMOUNTS VOLUMES AT END-OF-TAPE PROCESSING $$2 $$2 SYSROUTES: IC25633(AIX37),PQ33719(MVS37),IC25634(NT37),IC25636(HP37), $$2 IC25635(SUN37) $$2 $$2 During the storing of large client files, if the volume $$2 became full the ADSM server would fail the mount of the $$2 next volume because the mountwait flag from the client $$2 had been reset to false; even though at the beginning $$2 of the session the client had set the flag to true. $$2 $$2 <@> $$2 IY04323 FORMAT=DETAILED DOES NOT WORK FOR CLEANUP ARCHDIR COMMAND, ONLY $$2 $$2 SYSROUTES: IC25637(AIX37),PQ33720(MVS37),IC25638(NT37),IC25640(HP37), $$2 IC25639(SUN37) $$2 $$2 "clean archdir format=" accepts "detail" but not "detailed" $$2 $$2 <@> $$2 IY04631 ERROR ADSM_DD_LOG2 (5680E405) LOGGED DURING TAPE DRIVE CLEANING $$2 $$2 SYSROUTES: IC25679(AIX37),IC25680(NT37),IC25682(HP37),IC25681(SUN37) $$2 $$2 ADSM_DD_LOG2 message is entered into the AIX error log $$2 for a DD_CLEANER_INST condition. An ADSM_DD_LOG2 message $$2 is a permanent hardware message type. This is incorrect. $$2 $$2 <@> $$2 IY04652 ADSM CHECKIN LIBRARY VOLUME AND QUERY PROCESS CAN RESULT IN DEA $$2 $$2 SYSROUTES: IC25641(AIX37),IC25642(NT37),IC25644(HP37),IC25643(SUN37) $$2 $$2 Server deadlocks when query process is issued immediately $$2 after a checkin, checkout, label, or audit $$2 $$2 <@> $$2 IY04929 ANR4391I MESSAGES FLOODING THE ACTIVITY LOG RESULTING IN DATABA $$2 $$2 SYSROUTES: IY04929(AIX),PQ32928(MVS),IC25401(NT),IC25402(HP),IC25403(SUN), $$2 PQ32929(VM),IC25756(AIX37),PQ33721(MVS37),IC25645(NT37), $$2 IC25647(HP37),IC25646(SUN37) $$2 $$2 The problem is a status message, ANR4391, can flood the $$2 server's activity log. This flood of messages then triggers a $$2 backup database in the middle of expiration. $$2 $$2 <@> $$2 IY05321 EXPIRATION PROCESS MAY HANG WHEN ATTEMPTING TO EXPIRE OBJECTS T $$2 $$2 SYSROUTES: IY05321(AIX),PQ32966(MVS),IC25420(NT),IC25421(HP),IC25422(SUN), $$2 PQ32967(VM),IC25757(AIX37),PQ33722(MVS37),IC25648(NT37), $$2 IC25650(HP37),IC25649(SUN37) $$2 $$2 During expiration processing, the server may hang. This hang $$2 is only possible with expiration running. Typically, $$2 clients will hang when connecting to the server because $$2 of this and other server operations may also hang. $$2 $$2 <@> $$2 IY05562 DEADLOCK SITUATION DURING EXPIRATION MAY OCCUR WHEN PROCESSING $$2 $$2 SYSROUTES: IY05562(AIX),PQ32968(MVS),IC25423(NT),IC25424(HP),IC25425(SUN), $$2 PQ32969(VM),IC25758(AIX37),PQ33723(MVS37),IC25651(NT37), $$2 IC25653(HP37),IC25652(SUN37) $$2 $$2 During expiration processing, the locking performed by the $$2 algorithm to serialize access to server resources may not $$2 be correct in cases where expiration is processing both $$2 backup and archive files in the same deletion batch. This $$2 can result in a "deadlock" on the server and the deadlock $$2 detector will eventually detect this and end one of the $$2 transactions involved. $$2 $$2 <@> $$2 IY05678 ADSM AIX SERVER ISSUES CLOSE() AGAINST WRONG FILE HANDLE BECAUS $$2 $$2 SYSROUTES: IY05678(AIX),IC25437(NT),IC25436(SUN),IC25654(AIX37),IC25655(NT37), $$2 IC25656(SUN37) $$2 $$2 Background information leading up to the problem: $$2 When ADSM calls close() to close a file handle to a drive, $$2 the close() call returns a return code of 0 (success). $$2 However, because the forked process inherited ADSM's open $$2 file handles, the device driver never receives the close() $$2 call. When ADSM calls open() to open a new file handle $$2 to the same drive, the open() call returns a return code $$2 of 11. $$2 $$2 Description of the problem: $$2 After receiving the errno=11, ADSM does not correctly handle $$2 the error situation. As a result, ADSM may close another $$2 process's file handle in error if there are at least 11 $$2 open file handles. The number of open file handles depends $$2 on the customer's environment and the amount of activity $$2 at the time when the new process is forked. $$2 $$2 <@> $$2 PQ26477 ABEND0C4 DEFINE UPDATE STGPOOL RECLAIMSTGPOOL VSPRINTF() $$2 $$2 SYSROUTES: IY05686(AIX),PQ26477(MVS),IC25267(NT),IC25283(HP),IC25284(SUN), $$2 PQ32559(VM),IC25657(AIX37),IC25658(NT37),IC25660(HP37),IC25659(SUN37) $$2 $$2 ABEND0C4 DEFINE UPDATE STGPOOL RECLAIMSTGPOOL VSPRINTF() $$2 $$2 <@> $$2 PQ27180 ABEND0C4 ANRAQMUT PROTOCOL VIOLATION ANR0444W $$2 $$2 SYSROUTES: IY05691(AIX),PQ27180(MVS),IC25272(NT),IC25724(HP),IC25725(SUN), $$2 PQ32544(VM),IC25661(AIX37),IC25662(NT37),IC25664(HP37),IC25663(SUN37) $$2 $$2 occasional server crash $$2 $$2 <@> $$2 PQ28443 INTERLINK FUNCTION NOT BEING INCLUDED AT LINK-EDIT TIME WXITCPE $$2 $$2 SYSROUTES: IC25665(AIX37),PQ33724(MVS37),IC25666(NT37),IC25668(HP37), $$2 IC25667(SUN37) $$2 $$2 At execution of the TSO Admin Client module, an attempt to $$2 connect to the Server results in a failure; return code $$2 of -59 is noted in a message. When tracing is active with $$2 the COMM option, the message "WXITCPER is NULL" is displayed $$2 to indicate that a required function was not included when $$2 the client was built. $$2 $$2 <@> $$2 PQ28620 ADSM/MVS EXPIRATION RECLAMATION HANG $$2 $$2 SYSROUTES: PQ28620(MVS),PQ32550(VM),PQ33725(MVS37) $$2 $$2 During reclamation if expiration deletes all remaining $$2 active data from a volume when the server goes to $$2 reclaim the next volume the server may abend. $$2 $$2 During reclamation if expiration deletes all remaining $$2 active data from a volume when the server goes to $$2 reclaim the next volume the server may abend. $$2 $$2 <@> $$2 PQ29705 ANR5083 IUCV CONNECTION TERMINATED - ERROR XX ACCEPTING CONNECT $$2 $$2 SYSROUTES: PQ29705(VM) $$2 $$2 Abend 12D during IUCV communication session with CMS client $$2 $$2 <@> $$2 PQ29708 QUERY ACTLOG SEARCH= $$2 $$2 SYSROUTES: PQ33726(MVS37) $$2 $$2 An invalid character in the activity log causes a loop. $$2 $$2 <@> $$2 PQ31373 ADSM/TSM DOC INDICATES ABBREVIATION FOR DEFINE MACHINE IS DEF M $$2 $$2 SYSROUTES: IC25669(AIX37),PQ33727(MVS37),IC25670(NT37),IC25672(HP37), $$2 IC25671(SUN37) $$2 $$2 Server does not allow for using an abbreviation of MA for $$2 the DEFINE MACHINE, UPDATE MACHINE, DELETE MACHINE or $$2 QUERY MACHINE commands. MA is the abbreviation which is $$2 documented in our command reference. $$2 $$2 <@> $$2 PQ31769 ADSM SERVER NETWARE RESTORE ANR9999D SMNQR(235): INVALID OBJECT $$2 $$2 SYSROUTES: IC25673(AIX37),PQ33728(MVS37),IC25674(NT37),IC25676(HP37), $$2 IC25675(SUN37) $$2 $$2 During no query restore operations, the restore may $$2 fail with an ANR9999D SMNQR(235) Invalid Object Header $$2 State in retrieve operation for session..... $$2 A logic error occurred in the server did not reset $$2 certain control information following a sink error. $$2 As a result the above message was issued due to the $$2 object header size being incorrect. $$2 $$2 <@> $$2 PQ31959 LABELS ON EMPTY OUTPUT TAPES THAT ARE MOUNTED BUT NOT WRITTEN T $$2 $$2 SYSROUTES: PQ33731(MVS37) $$2 $$2 Tape label can be overwritten on unused tape volumes. $$2 $$2 <@> $$2 IC25316 UPDATE SUMMARY TABLE STATISTICS NOT CORRECT. $$2 $$2 SYSROUTES: IC25316(AIX37),PQ34783(MVS37),IC25951(NT37),IC25952(HP37), $$2 IC25953(SUN37) $$2 $$2 UPDATE SUMMARY TABLE STATISTICS NOT CORRECT. $$2 $$2 <@> $$2 IC25327 CALLS MADE TO LOCALTIME LIBRARY ROUTINE ARE NOT THREAD SAFE: CA $$2 $$2 SYSROUTES: IY07602(AIX),PQ34867(MVS),IC25979(NT),IC25980(HP),IC25902(SUN), $$2 PQ34868(VM),IC25981(AIX37),PQ34869(MVS37),IC25982(NT37), $$2 IC25983(HP37),IC25327(SUN37) $$2 $$2 Enabling and starting a server trace could cause the server to $$2 hang or abort. $$2 $$2 <@> $$2 PQ31998 ANR9999D BDMVS(1540): ERROR 001C0A0C OCCURRED DURING I/O WHILE $$2 $$2 SYSROUTES: PQ31998(MVS37) $$2 $$2 Page fixing a batch of I/O buffers was specifying a batch size $$2 of 1 rather than 16. This meant the first page of the I/O $$2 page of the I/O buffers was fixed and the remaining 15 may $$2 not be fixed. Code was added to the database backup component $$2 to ensure a full batch size was specified on the page fix $$2 request. $$2 $$2 <@> $$2 PQ32470 ANR9999D PK390(2159): UNABLE TO OPEN IMAGES 'ADSM.V3R1M0.SANRIM $$2 $$2 SYSROUTES: PQ32470(MVS),PQ34331(MVS37) $$2 $$2 Web engine issues an ANR9999D message when a file is not found. $$2 $$2 $$2 <@> $$2 PQ32867 TIVOLI STORAGE MANAGER MVS SERVER DUMPDB PROCESSING FAILS WITH $$2 $$2 SYSROUTES: PQ3286(MVS37) $$2 $$2 <@> $$2 IC25165 SERVER ABENDS WHEN RUNNING SERVER IN UTILITY MODE AND USING TAP $$2 $$2 SYSROUTES: IC25165(AIX37),IC25903(NT37),IC25904(HP37),IC25905(SUN37) $$2 $$2 The Tivoli storage manager can abend when running in utility $$2 mode. Typically this has been found when restoring or loading $$2 the server from the command line using the commands dsmserv $$2 load or dsmserv restore. The problem occurs when using multiple $$2 sequential volume to restore the database. The server abend $$2 after the first volume is dismounted. $$2 $$2 $$2 <@> $$2 IC25166 SERVER ABENDS AFTER DISMOUNT FAILS DURING NORMAL SERVER OPERATI $$2 $$2 SYSROUTES: IC25166(AIX37),IC25817(NT37),IC25819(HP37),IC25818(SUN37) $$2 $$2 There is a chance that the TSM server can abend when a $$2 volume is dismounted from a drive and the dismount fails. $$2 This problem can be found if the stack trace back found $$2 in a core file contains FinishMp with a call to $$2 pkBroadcastSignal. The problem is that the signal $$2 being broadcast is NULL and nobody is waiting on the $$2 signal. $$2 $$2 $$2 <@> $$2 IC25167 SERVER DEADLOCKS ON A MOUNT/DISMOUNT OPERATION $$2 $$2 SYSROUTES: IC25167(AIX37),IC25906(NT37),IC25907(HP37),IC25908(SUN37) $$2 $$2 There is a potential that the server can deadlock $$2 when one thread is requesting a mount point (you $$2 will see a call to pvrAcquireMountPoint) and another $$2 thread dismounting a volume is trying to signal the $$2 ss mount queue (you will see a call to asNotifyMPAgent). $$2 The problem is that the mount point thread is waiting $$2 on the PVR mutex to be release and the dismount thread $$2 is waiting on the SS mutex. The problem can be found $$2 by looking at the output of a show threads command. $$2 The server will appear to be hung out on sequential $$2 volumes. $$2 $$2 <@> $$2 IY05753 HIGH CPU USAGE CAN RESULT IN THE BUFFER PRE-FETCHER UTILIZING L $$2 $$2 SYSROUTES: IY05753(AIX),PQ34881(MVS),IC25988(NT),IC25989(HP),IC25990(SUN), $$2 PQ34882(VM),IC25991(AIX37),PQ34883(MVS37),IC25992(NT37), $$2 IC25993(HP37),IC25994(SUN37) $$2 $$2 Data base buffer prefetcher can use too much memory if the $$2 thread servicing the prefetch requests can not service the $$2 requests as fast as the other threads in the server can create $$2 the requests. $$2 $$2 <@> $$2 IY06424 ANR9999D ERROR POSITIONING SERVER VOLUME FOR VIRTUAL VOLUMES AF $$2 $$2 SYSROUTES: IY06424(AIX),PQ34665(MVS),IC25916(NT),IC25917(HP),IC25918(SUN), $$2 PQ34666(VM),IC25919(AIX37),PQ34667(MVS37),IC25920(NT37), $$2 IC25921(HP37),IC25922(SUN37) $$2 $$2 If the default management class on the target server for the $$2 node representing the source server is changed, any data $$2 for virtual volumes previously stored on the target server $$2 will not be addressable. Specifically, the virtual volumes $$2 on the source server will exhibit errors positioning on the $$2 virtual volumes that have archive files bound to the previous $$2 default management class. $$2 $$2 <@> $$2 IY07203 RETRIEVING FILES THAT SPAN SIDES OF OPTICAL MEDIA FAILS. $$2 $$2 SYSROUTES: IY07203(AIX),IC25923(NT),IC25924(HP),IC25925(SUN),IC25926(AIX37), $$2 IC25927(NT37),IC25928(HP37),IC25929(SUN37) $$2 $$2 When a file that is stored on optical media and spans sides $$2 media there is a possiblity that retrieving the file may $$2 fail. $$2 $$2 <@> $$2 IY07274 SNMP SUBAGENT ONLY WORKS WHEN TRACING IS ENABLED $$2 $$2 SYSROUTES: IY07274(AIX),IC25909(AIX37) $$2 $$2 The SNMP subagent may not complete initialization unless $$2 the -trace flag is used when invoking dsmsnmp. $$2 This applies only to the AIX version. $$2 $$2 <@> $$2 IY07355 PARTIAL OBJECT RETRIEVE MAY SEND LESS BYTES THAN REQUESTED $$2 $$2 SYSROUTES: IY07355(AIX),PQ34878(MVS),IC25985(NT),IC25986(HP),IC25987(SUN), $$2 PQ34879(VM),IC25954(AIX37),PQ34790(MVS37),IC25955(NT37), $$2 IC25956(HP37),IC25957(SUN37) $$2 $$2 Partial object retrieves would fail given certain offsets. $$2 $$2 <@> $$2 IC25380 DIRECTORY FIELD IS LIMITED TO 30 CHARACTERS WHEN UPDATING THE FILE DEV $$2 CLASS VIA THE TSM 3.7.1.0 WEB ADMIN. $$2 $$2 SYSROUTES: IC26087(AIX37),PQ35273(MVS37),IC25380(NT37),IC26088(HP37),IC26089(SUN37) $$2 $$2 DIRECTORY FIELD IS LIMITED TO 30 CHARACTERS WHEN UPDATING THE FILE DEV $$2 CLASS VIA THE TSM 3.7.1.0 WEB ADMIN. $$2 $$2 <@> $$2 IC25995 TSM SERVER DSMSERV RESTORE DB FAILS FROM VIRTUAL VOLUME OR SEQUENTIAL MEDIA. $$2 NT GENERATES DR. WATSON. AIX CORE DUMPS $$2 $$2 SYSROUTES: IC26101(AIX37),PQ35314(MVS37),IC25995(NT37),IC26102(HP37),IC26103(SUN37) $$2 $$2 When performing a RESTORE DB to a point in time (specifying $$2 TODATE and TOTIME on the command), the server can $$2 cause a segmentation violation and crash. $$2 $$2 <@> $$2 PQ32871 TIVOLI STORAGE MANAGER DUMPDB PROCESSING COMPLETES SUCCESSFULLY $$2 $$2 SYSROUTES: PQ32871(MVS37) $$2 $$2 A78 abend at completion of DUMP DB $$2 $$2 <@> $$2 PQ33325 ABEND 0CX USING SELECT COUNT (*) FROM MOUNT $$2 $$2 SYSROUTES: PQ33325(MVS),PQ33639(VM),PQ33958(MVS37) $$2 $$2 An ABEND if the SELECT xxx FROM MOUNT command is issued, and $$2 xxx does not include the STATUS column. $$2 $$2 <@> ********************************************************************** * WHERE TO FIND DOCUMENTATION * ********************************************************************** The BOOK CD contains the Tivoli Storage Manager Version 3 Release 7 Server and Client on-line library, in HTML and PDF format, for AIX, MVS, Windows NT, Sun Solaris and HP-UX. If you wish to use the PDF format, you can obtain the Adobe Acrobat Reader from the following site. http://www.adobe.com/prodindex/acrobat/readstep.html To install the Adobe Acrobat Reader on your platform, run the appropriate installation file, and follow the on-line installation instructions. Use the Adobe Acrobat Reader to view the index.pdf file. This file contains links to the 28 product pdf files. Click on the book title you want to view. To navigate back to the index.pdf file, press and hold the right mouse button, move the cursor to the "Go Back" selection, and release the mouse button. ******************************************************************************** * Getting Help * ******************************************************************************** - To receive technical support for Tivoli Storage Manager: + Contact your administrator. This should be your first step when having problems with Tivoli Storage Manager. + Your administrator will know how to contact IBM for Technical Support on your behalf. + For the latest information about Tivoli Storage Manager, visit the home page on World Wide Web. The URL is: http://www.tivoli.com/storage - To participate in user discussions of Tivoli Storage Manager: + Subscribe to an Internet listserv forum. This is not officially supported by IBM, but IBM support people do participate in the discussions, along with other users. You can subscribe by sending a note to listserv@vm.marist.edu that contains the following command in the message body: SUBSCRIBE ADSM-L yourfirstname yourlastname Posts can then be sent to: adsm-l@vm.marist.edu - Anonymous FTP server .................... IBM also supports an anonymous FTP server where you can find PTF maintenance and other related materials. Three other anonymous servers are unofficially maintained by non-IBM volunteers. These servers are: service.boulder.ibm.com (primary - Colorado, IBM) ftp.rz.uni-karlsruhe.de (mirror - Germany) ftp.wu-wien.ac.at (mirror - Austria) ftp.cac.psu.edu (mirror - Pennsylvania) - Performance Tuning for Tivoli Storage Manager The Tivoli Storage Manager V3.7 Performance Tuning Guide will be available on the home page. Point your web browser to this address: http://www.tivoli.com/storage Trademarks __________ (*) Trademark of the IBM Corporation in the United States and other countries.