ADSTAR Distributed Storage Manager (ADSM) Server Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1990, 1999. All rights reserved. This Readme is divided into the following sections: Service Level Where to find Documentation Getting Help - Obtaining Technical Support for ADSM - To Participate in User Discussions of ADSM - Anonymous FTP Server - Performance Tuning for ADSM Trademarks $$ CONVERT USSFILESPACE Utility $$ Support for IBM 3590 Model Exx Tape Drives $$ Tivoli Ready Enablement $$ 8900 8 MM Tape Drive Support for 8500 formats $$ Password Expiration Improvements $$ CANCEL EXPIRATION Command $$ Archive Description Rebinding $$ DRM Scripts for Y2k support $$ New Parameter for Expire Inventory Command Backup Recommendation New Server Security Option New Licensing Information Notice for WEB browser users Generating SSL Certificates for ADSM users Notes for use of SNMP sub-agent (dsmsnmp) Documentation Updates Migration by Age - Limitation Migration by Age from Random Media Drive Cleaning Support for SCSI Tape Libraries Preserving ACSLS Server hostname CHECKIN and LABEL command changes Information on Data Errors in prior levels of ADSM Version 3 - Overview - Frequently Asked Questions - Documentation for Reclaimation Utilities - Problem Description - Overview of Reclaimation Utilities - AUDIT RECLAIM Command - DELETE RECLAIM Command - REMOVE RECLAIM Command - CLEANUP RECLAIM Command - Possible Procedure for use of Utilities Clarification of fix to APAR IX79626 Change to MOVE DRMEDIA and MOVE MEDIA Commands SSI Initialization Accounting Environment Variable APARS fixed by prior service levels - APARS Fixed prior to Service Level 3.1.2.20 - APARS fixed in Service Level 3.1.2.20 - part 1 - APARs fixed in Service Level 3.1.2.20 - part 2 $$ APARS fixed by service level 3.1.2.30 - $$ SYSROUTES ------------- Service Level ------------- README for ADSM for AIX, Version 3, Release 1, Service Level 2.30 This README file describes changes to the ADSM Version 3.1 Server since it's release. $$ Changes new to this service level are indicated by "$$" --------------------------- Where to find Documentation --------------------------- The latest version of all ADSM publications can be viewed online or downloaded to your site from the following web site. http://www.tivoli.com/storage/adsm/pubs/admanual.htm You can order hardcopies of all manuals from the following web site. http://www.elink.ibmlink.ibm.com/pbl/pbl ------------ Getting Help ------------ Obtaining Technical Support for ADSM ------------------------------------ + Contact your ADSM administrator. This should be your first step when having problems with ADSM. + Your ADSM administrator will know how to contact IBM for Technical Support on your behalf. + For the latest information about ADSM, visit the ADSM home page on World Wide Web. The URL is: http://www.storage.ibm.com/software/adsm/adsmhome.htm To Participate in User Discussions of ADSM ------------------------------------------ To participate in user discussions of ADSM: + Subscribe to an Internet listserv forum for ADSM This is not officially supported by IBM, but IBM support people do participate in the discussions, along with other ADSM 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 ADSM-related materials. Three other anonymous servers are unofficially maintained by non-IBM volunteers. These servers are: index.storsys.ibm.com (primary - California, IBM) ftp.rz.uni-karlsruhe.de (mirror - Germany) ftp.wu-wien.ac.at (mirror - Austria) ftp.cac.psu.edu (mirror - Pennsylvania) Performance Tuning for ADSM --------------------------- The ADSM V3 Performance Tuning Guide will be available on the ADSM home page. Point your web browser to this address: http://www.storage.ibm.com/adsm ---------- Trademarks ---------- (*) Trademark of the IBM Corporation in the United States and other countries. ------------------------------- $$ CONVERT USSFILESPACE Utility ------------------------------- ********************************************************************* * CONVERT USSFILESPACE command * ********************************************************************* ADSM 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 ADSM server has data from these clients. New ADSM 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 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)<>'/' 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 ADSM 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 --------------------------------------------- $$ 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: Device Driver level: Atape.4.4.0.0 (ftp://index.storsys.ibm.com/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 ADSM 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 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 drive_3590; - Issue ADSM 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: - 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. -------------------------- $$ Tivoli Ready Enablement -------------------------- With the purchase of an IBM software product that carries the Tivoli Ready logo, you have the ability to manage your IBM software products through the Tivoli Enterprise management products, allowing you to automatically discover, monitor, and inventory one or more Tivoli Ready applications. How to Get Started ================== IBM software products that are Tivoli Ready can be managed through either the Tivoli Enterprise Console (TEC), or through Tivoli Global Enterprise Manager (GEM). Supported TME configurations include managing IBM applications that are installed on TME managed nodes, PC managed nodes and endpoints in a distributed environment. On the following Tivoli web site, a free Tivoli Ready Enablement package is available for Tivoli customers to download. http://www.support.tivoli.com/tme10gem/tivoli-ready Additional information about this program is available from the following IBM web site: http://www.software.ibm.com/tivoli-ready Tivoli Ready Support for ADSM Server for AIX ============================================ This Tivoli Ready instrumentation, when configured, provides you with the ability to: - graphically view the health of the ADSM Server through Tivoli Global Enterprise Manager 2.2 or Tivoli Enterprise Console (TEC) 3.1 or higher consoles. - inventory the ADSM Server using Tivoli Inventory version 3.2. To install and configure your instrumentation follow the steps described below: 1) To enable the ADSM Server for AIX Tivoli Inventory, your Tivoli administrator needs to copy the ADSM Server signature file to a directory within the ADSM Server machine that is defined in the current Tivoli Inventory Profile to be scanned. The ADSM Server Tivoli Ready signature file is: tivready.dsm This file is copied as part of the installation process. 2) Your Tivoli administrator needs to install and configure the Tivoli GEM 2.2 Tivoli Ready Enablement on all the machines that you intend to monitor. To download the Tivoli Ready Enablement and detailed instructions on how to install it and use it, refer to the following URL: http://www.support.tivoli.com/tme10gem/tivoli-ready 3) The Tivoli GEM 2.2 Tivoli Ready Enablement is installed with a set of default configuration values. For detailed information on customizing your configuration refer to the GEM 2.2 Tivoli Ready Enablement Release Notes at the following URL: http://www.support.tivoli.com/tme10gem/tivoli-ready 4) To enable the ADSM Server for Sun Tivoli Global Enterprise Management (GEM) version 2.2, your Tivoli administrator needs to import the .amp file into the GEM as described in the GEM 2.2 documentation. Your ADSM Server for AIX AMP file is: AIX_ADSM.amp This file is found in the /tivready subdirectory on the ADSM Server CD and in the /tivready subdirectory in the ADSM Server installation directory. Tivoli/Plus for ADSM Support ============================ Tivoli/Plus for ADSM provides integration for Tivoli Enterprise Server. It provides tasks to manage the Server and monitors to run by Tivoli Distributed Monitoring that sends notifications to the TEC console and the TMR server when thresholds are exceeded. For more information on Tivoli/Plus for ADSM, refer to the following web site: http://www.software.ibm.com/software/adsm/ Support Information =================== For more information on obtaining support for Tivoli Ready Enablement, refer to the following Tivoli web site: http://www.support.tivoli.com/tme10gem/tivoli-ready In addition, please refer to the following IBM web site for product- specific updates to Tivoli Ready Enablement components (such as AMP and Inventory signature updates): http://www.software.ibm.com/tivoli-ready For more information on obtaining support for the ADSM Server, refer to the following web site: http://www.software.ibm.com/software/adsm/ ------------------------------------------------ $$ 8900 8 MM Tape Drive Support for 8500 formats ------------------------------------------------ ADSM now supports the 8900 Tape Drive's ability to read the older 8500 and 8500C formats. IN ORDER TO READ THE VOLUME PREVIOUSLY WRITTEN IN 8500 or 8500C FORMAT ON A 8900 DRIVE: - THE STORAGE POOL THAT OWNS THE VOLUME MUST POINT TO A DEVCLASS THAT USES 8900 DRIVES. - UPDATE THAT DEVCLASS SO THAT THE FORMAT IS 8500 or 8500C update devclass devclassname FORMAT=8500 update devclass devclassname FORMAT= 8500C - UPDATE ACCESS MODE TO THAT VOLUME TO READONLY update volume volumename ACCESS=READONLY Because the 8900 drives must be cleaned after reading the older formats, it is recommended that you read all the volumes with the older formats at one time and then clean the 8900 drive. Otherwise, you will encounter I/O errors when the drive is reading a volume with the 8900 format. ----------------------------------- $$ Password Expiration Improvements ----------------------------------- This release provides the ability to give different password expiration periods to different nodes and administrators. It is no longer necessary to have a single password expiration period that applies to all nodes and administrators in the system. In addition, password expiration can now be disabled for specific nodes and administrators. Externals Details: SET PASSEXP command now supports two new keyword options, NODE=nodelist and ADMIN=adminlist. ---- SET PASSExp expiration ------------------------------------------ | | | | +-Node=nodelist-+ +-Admin=adminlist-+ If either Node= or Admin= is specified, expiration applies only to the specified node(s) and/or admin id(s). Otherwise, the global expiration period is updated. NOTE: changing the global password expiration period will change the period for all nodes and admin ids that have not been assigned specific expiration periods. Nodelist and adminlist are comma separated lists of valid node names or administrator ids. The valid range of values for expiration has been changed from 1-9999 to 0-9999 whenever NODE= or ADMIN= is specified. A value of zero means that passwords never expire for the specified node(s) and administrator(s). An expiration period of zero remains invalid if NODE= and ADMIN= are not specified. REGISTER NODE and UPDATE NODE both support a new keyword option, PASSEXP=expiration. Using this option will cause the specified node(s) to use the the specified expiration period. If the option is not specified, the node's password expiration period will use the global expiration period (REGISTER), or will remain unchanged (UPDATE). The valid range of values for expiration is 0-9999. A value of zero for expiration means that the node's password will never expire. ---- REGISTER NODE node password -------------------------------------- | | +-PASSExp=expiration-+ ---- UPDATE NODE node password -------------------------------------- | | +-PASSExp=expiration-+ REGISTER ADMIN and UPDATE ADMIN also support the new keyword option. They behave the same as the corresponding REGISTER or UPDATE NODE command. The password expiration period for administrator "SERVER_CONSOLE" may not be updated. ---- REGISTER ADMIN admin password -------------------------------------- | | +-PASSExp=expiration-+ ---- UPDATE ADMIN admin -------------------------------------- | | +-PASSExp=expiration-+ QUERY NODE and QUERY ADMIN (FORMAT=DETAILED) now display the node or admin's password expiration period. If the node or admin does not have a specific expiration period, the query commands display no value. QUERY ADMIN displays no value for administrator "SERVER_CONSOLE". The NODES and ADMINS SQL tables each have a new column named PASSEXP. The value returned for this column is the same that is displayed by the corresponding query command. A NULL value is returned for administrator "SERVER_CONSOLE", or if no explicit password expiration period has been set. This allows SQL queries to be generated that distinguish between nodes & admins with explicitly set password expiration periods and those without. WEB ADMIN: The web admin interface displays the value of a node or admin's password expiration period, and supports the definition and updating of node and admin's expiration period using the node and admin objects, respectively. CENTRAL CONFIGURATION: For central configuration, an administrator's private password expiration period is replicated to all managed servers, provided the managed servers are at a high enough maintanence level to support this feature. If a managed server does not support private password expiration periods, managed administrators will be replicated without the password expiration period. EXPORT and IMPORT: Export and Import support the propogation of password expiration periods for nodes and administrators. Export will produce export tapes that contain password expiration information. Because this is new information not understood by earlier versions of the server, export tapes produced by this level of the server will not be importable by earlier versions. Import will create nodes and administrators with the appropriate password expiration periods. If the export tape contains password expiration information, the information will be used as appropriate. If the tape does not contain password expiration information (i.e., it was produced by an earlier version of the server), then nodes and administrators will be defined using the default, global password expiration period. DATABASE AUDIT: Database audit will check for consistency in new data base tables added for this enhancement. MESSAGES: Two new informational messages were added for the SET PASSEXP command: ANR2199I Password expiration period for node set to days. Explanation: The number of days that the node's password can be used before it must be changed has been set to the value indicated with the SET PASSEXP command. System Action: None. User Response: None. ANR2299I Password expiration period for administrator set to days. Explanation: The number of days that the administrator's password can be used before it must be changed has been set to the value indicated with the SET PASSEXP command. System Action: None. User Response: None. Ten new messages for were added for DB AUDIT: ANR4434E Password expiration found for unknown client node Explanation: A database audit process finds a password expiration period for a client node, but the client node is not defined correctly in the server database. System Action: Audit processing continues. User Response: If the audit command has not been issued with FIX=YES specified, reissue the audit function specifying FIX=YES so that the error can be corrected. ANR4435I Password expiration period deleted for unknown client node . Explanation: A database audit process finds a password expiration period for a client node, but the client node is not defined correctly in the server database. Because FIX=YES has been specified for the audit command, the audit function deletes the password expiration period. System Action: Audit processing continues. User Response: None. ANR4436E Invalid password expiration for client node Explanation: A database audit process finds an invalid password expiration period for a client node. System Action: Audit processing continues. User Response: If the audit command has not been issued with FIX=YES specified, reissue the audit function specifying FIX=YES so that the error can be corrected. ANR4437I Invalid password expiration period deleted for client node Explanation: A database audit process finds an invalid password expiration period for a client node. Because FIX=YES has been specified for the audit command, the audit function deletes the password expiration period, causing the default, global password expiration period to take effect for the client node. System Action: Audit processing continues. User Response: After the AUDIT command completes, use the QUERY NODE command to examine the node that was updated. Use the UPDATE NODE command to set the correct password expiration period for the node. ANR4438E Password expiration found for unknown administrator Explanation: A database audit process finds a password expiration period for an administrator, but the administrator is not defined correctly in the server database. System Action: Audit processing continues. User Response: If the audit command has not been issued with FIX=YES specified, reissue the audit function specifying FIX=YES so that the error can be corrected. ANR4439I Password expiration period deleted for unknown administrator Explanation: A database audit process finds a password expiration period for an administrator, but the administrator is not defined correctly in the server database. Because FIX=YES has been specified for the audit command, the audit function deletes the password expiration period. System Action: Audit processing continues. User Response: None. ANR4440E Invalid password expiration for administrator Explanation: A database audit process finds an invalid password expiration period for an administrator. System Action: Audit processing continues. User Response: If the audit command has not been issued with FIX=YES specified, reissue the audit function specifying FIX=YES so that the error can be corrected. ANR4441I Invalid password expiration period deleted for administrator . Explanation: A database audit process finds an invalid password expiration period for an administrator. Because FIX=YES has been specified for the audit command, the audit function deletes the password expiration period, causing the default, global password expiration period to take effect for the administrator. System Action: Audit processing continues. User Response: After the AUDIT command completes, use the QUERY ADMIN command to examine the administrator that was updated. Use the UPDATE ADMIN command to set the correct password expiration period for the administrator. ANR4442E Extended attribute is not a valid attribute type. Explanation: A database audit process finds an extended attribute type that is not supported. System Action: Audit processing continues. User Response: If the audit command has not been issued with FIX=YES specified, reissue the audit function specifying FIX=YES so that the error can be corrected. ANR4443I Invalid extended attribute has been deleted. Explanation: A database audit process finds an extended attribute type that is not supported. Because FIX=YES has been specified for the audit command, the audit function deletes extended attribute. System Action: Audit processing continues. User Response: None. ---------------------------- $$ CANCEL EXPIRATION Command ---------------------------- The expiration algorithm has been modified to allow the process to use multiple server threads. This allows the server to search and deleted more quickly as these tasks are shared between two server threads instead of being done by a single server thread as they had in the past. In support of this new expiration algorithm, a new command has been added. The command is "CANCEL EXPIRATION". This will cancel an expiration process if there is one currently running. Please note that this does NOT require the process id to be specified. By not needing the process id, this command can be scheduled using the server administrative command scheduling utility to help manage expiration processing and the time it consumes. The server expiration algorithm performance was degraded as a result of a valid fix. This fix was necessary to prevent the skipping of files for expiration and potential database growth as these files were not expired appropriately. To offer relief to this performance degradation in the expiration process, the expiration algorithm and server have been changed as follows: 1) The algorithm itself has been altered to allow it to use multiple threads. This will allow the process to spread the work of searching for files to expire and the actual deletion of files between these multiple threads. 2) The command "CANCEL EXPIRATION" has been added. This allows for the cancelling of an expiration process without knowing what the process id for expiration is. 3) The expiration algorithm is now restartable. If the process is cancelled and subsequently restarted, it will restart where it left off instead of always from the beginning of the expiration management table in the server database. So as to better manage expiration, if expiration takes too long to run in a given customer environment, this fix should offer relief and better management of the expiration process. For example, if it is desired to ONLY have expiration run for 2 hours each day from 8:00 at night to 10:00 at night. A server administrative scheduled command can be set up to start expiration each night at 8:00. And than to manage having expiration ONLY run for 2 hours, another scheduled command can be entered to issue the "CANCEL EXPIRATION" command each night at 10:00. By doing this the customer can manage having expiration run just 2 hours a night. Also, since expiration is now restartable, the expiration process over the course of these 2 hour nightly runs, will be able to progress through the ENTIRE expiration management database table instead of always restarting from the beginning. By providing this combination of new function in expiration and the new CANCEL EXPIRATION command, the expiration processing can be explicitly controlled by the needs of the customer environment and offer relief to the change in expiration performance. -------------------------------- $$ Archive Description Rebinding -------------------------------- Each time a client issues an archive request, the server enters a complete set of directory levels in its database. This results in duplicate entries for the same archive directory levels. Also, if an archive copygroup specifies a long retention period (like 7 years or no limit), archive directories never expire even though there are no files that reference it. This redundancy results in extra database usage and increased search and expiration times. Service level 3.1.2.30 which includes the fix for APAR IX89638 corrects this problem and includes other changes to improve archive processing. Also included is a utility to remove duplicate archive directories. DUPLICATE ARCHIVE DIRECTORY REMOVAL UTILITY: An archive directory is defined to be unique by: node, file- space, directory/level, owner and description. The duplicate directory removal utility will retain the oldest unique direc- tory and remove all younger duplicates. The utility is started as a process, may be canceled by the existing CANCEL PROCESS and later resumed. Archive cleanup jobs may be queried, and a cancel command exists to remove a job from the list of resumable cleanup jobs. Syntax: CLEAN ARCHDIRectories: starts duplicate archive directory re- moval for all nodes or a list of nodes, or resumes a cleanup job that was canceled. ---- CLEAN ARCHDIRectories --------------------------------------- | | | | +-nodeList----+ +-Format=Standard| | | | Detailed--+ +-JOBid=jobId-+ -------------------- | +-FIX=No|Yes ---- where: nodeList is a comma separated list of node names jobId is a resumable cleanup job if nodeList or JOBid= are not specified, a new job that cleans all nodes is assumed The Standard Format of the command is the default and prevents messages for each duplicate directory from being issued. If Detailed is specified, messages are issued. FIX=no every archive directory entry for the nodeList or all nodes will be displayed. This is the default. =yes duplicate directories will be removed Query ARCHDIRClean: the standard format of the command lists information about a job. The detailed format additonally lists information for each node associated with a job. ---- Query ARCHDIRClean -------------------------------------- | | | | +-jobId-+ +-Format=Standard| | Detailed--+ CANcel ARCHDIRClean: removes an archive cleanup job from the server. ---- CANcel ARCHDIRClean ---- jobId -------------------------- OTHER CHANGES: Changes have also been made that remove archive directories when they are eligible for expiration and not referenced, and the same performance enhancement introduced in v3.1 for backup and archive has been implemented for expiration and filespace dele- tion. In addition, the client will not bind archive directories to the management class with the longest retention, and it will not continue to archive duplicate directories (available from client ptf 3.1.0.7). ARCHIVE USAGE NOTES/TIPS: - the cleanup utility may be run multiple times for the same node. If no duplicates are found, nothing is removed. - description is one field that defines a unique archive directory: it is a factor that determines the number of archive directory entries in the database. Customers that use the archive function extensively should consider including the description field with each archive request, especially when the default value is not appropriate to to their needs. ------------------------------ $$ DRM Scripts for Y2k support ------------------------------ A typical ADSM configuration will have new backups being created in the year 2000 and existing 1999 backup copies expiring. You can use ADSM/DRM to ensure you have a copy of your 1999 ADSM environment offsite and can return to it for x amount of time into the year 2000. The sample Y2K related scripts are included in the y2kscr.smp file on the anonymous ftp server at index.storsys.ibm.com in the directory /adsm/fixes/v3r1/samples. ADSM Server Scripts Description ________________________________ o drm_prep script (ADSM/DRM year 2000 dr preparation ADSM script) The objective of this ADSM server script is to automate the preparation of a 1999 offsite copy of the your ADSM environment (i.e. backup stgpool, backup database, move drmedia, and prepare). o drm_dbcopyst script (ADSM/DRM year 2000 dr volume retention script) The objective of this script is to cross-check the DRM database retention value against the copy storage pool re-use delay value (i.e. if these values are different, database or copy storage pool tapes could be returning to scratch prematurely). o fsnobackup script (ADSM year 2000 report of client nodes / filespaces that have not been backed up for x days) The objective of this script is to identify nodes that have not been backed up for a certain interval of time (i.e. identify nodes that are exposed to being down-level if they have to be restored in the year 2000). The date used in these comparisons would be the last-backup-date in the filespace table. --------------------------------------------- $$ New Parameter for Expire Inventory Command --------------------------------------------- The Expire Inventory Command has been improved with the addition of the DURATION parameter. The Expire Inventory command will automatically terminate after the number of minutes you specify with the DURATION parameter. The parameter is optional and if not used, EXPIRE INVENTORY will run to normal completion. If DURATION is used, the value specified must be a positive integer less than 2147483648. Example: EXPIRE INVENTORY DURATION=120 will cause inventory expiration processing to terminate after 2 hours. --------------------- Backup Recommendation --------------------- Server level 3.1.2.0 and later provides enhanced recovery log fault-tolerance and new database entries to support enhanced functions. If you start this server over an existing, pre service level 3.1.2.0 ADSM database, you will not be able to remove this server program and run the older server over the existing database/recovery log. IBM recommends that you perform a full database backup on any ADSM server over which you plan to install this code, so you can restore the database to the appropriate level should you decide to remove this code. -------------------------- New Server Security Option -------------------------- ADSM has been updated to provide additional control related to the administrative authority required to issue selected commands that cause the ADSM server to write information to an external file. A new server option REQSYSAUTHOUTFILE has been added to control this processing. REQSYSAUTHOUTFILE YES: Specifies that system authority is required for administrative commands that cause the server to write to an external file. The commands and associated parameters that are controlled by this option are: - MOVE and QUERY DRMEDIA when the CMD parameter has been specified - MOVE and QUERY MEDIA when the CMD parameter has been specified - BACKUP VOLHISTORY when the FILENAMES parameter has been specified - BACKUP DEVCONFIG when the FILENAMES parameter has been specified - TRACE BEGIN when a file name has been specified - QUERY SCRIPT when the OUTPUTFILE parameter has been specified REQSYSAUTHOUTFILE NO: Specifies that system authority is not required for administrative commands that cause the server to write to an external file (i.e. there is no change to the privilege class required to execute the command). The default is REQSYSAUTHOUTFILE YES. In addition, when REQSYSAUTHOUTFILE NO has been specified, authorization changes have been been made to select QUERY commands that cause the ADSM server to write information to an external file. The commands and their associated authorization changes are: - QUERY DRMEDIA or QUERY MEDIA with the CMD parameter require operator, unrestricted storage or system authority. - QUERY SCRIPT with the OUTPUTFILE parameter require, operator, policy, storage or system authority. The explanation for ANR2035E has been updated to indicate that this message can be issued as a result of the server option REQSYSAUTHOUTFILE YES. Note, it is assumed that proper access controls are in place for the server options file dsmserv.opt. Authorization to change or delete an ADSM command script have changed. The UPDATE SCRIPT and DELETE SCRIPT command, have the following additional controls in place: - An ADSM administrator with system privilege can change or delete any script - If an ADSM administrator does not have system privilege, the administrator must have previously created or updated the script. For scripts created after the application of this maintenance, only a system administrator or the administrator that created the script will be allowed to update or delete the script. A new message ANR1493E will be issued if the administrator is not authorized. ------------------------- New Licensing Information ------------------------- The following functions are licensed as a separate Enterprise Administration feature in this server: Central Configuration Central Logging Central Commands To enable the "Enterprise Administration" license, use a text editor to cut out the following lines from this readme file into a license certificate file named 'entadmin.lic' : *------------------------- cut here ----------------------------------- (LicenseCertificate) CheckSum=1C88F172ED60F14D3A0796C685041A8A TimeStamp=896968609 PasswordVersion=4 VendorName=IBM Corporation VendorPassword=uw7jvac4k3umq VendorID=6fb1ea8d2ebc.a3.89.a3.25.04.00.00.00 ProductName=ADSM Enterprise Admin ProductID=21364 ProductVersion=3.1 ProductPassword=nv7d2xagpibikab2raaxnaa ProductAnnotation= LicenseStyle=nodelocked LicenseStartDate=06/03/1998 LicenseDuration=14457 LicenseEndDate=12/31/2037 LicenseCount=1 MultiUseRules= RegistrationLevel=3 TryAndBuy=No SoftStop=No TargetType=ANY TargetTypeName=Open Target TargetID=any DerivedLicenseStyle= DerivedLicenseStartDate= DerivedLicenseEndDate= DerivedLicenseAggregateDuration= *------------------------- cut here ----------------------------------- To register the license on the server, use the REGISTER LICENSE command to read the license information into the server: REGISTER LICENSE FILE=ENTADMIN.LIC DRM Licensing - Clarification The DRM license on the source server is the only license required to store a recovery plan file on another server (i.e. the VIRTUAL VOLUMES license is not required on the source and target servers, and the NETWORK license is not required on the target server). ---------------------------- Notice for WEB browser users ---------------------------- The web interface for administrative functions requires that your browser have jdk 1.1 support. the following instructions detail how to get this support for Netscape 4.0. Internet Explorer 4.0 has this support: Java 1.1 support is required for using the newly enhanced web interface. Below are instructions on how to upgrade your browser. Netscape Communicator Verify that you are currently running Netscape Navigator 4.03 or better. If you need to upgrade, go to http://home.netscape.com/download/ and follow the instructions to upgrade your current browser. For Windows NT/95 users, go to http://help.netscape.com/filelib.html#smartupdate and press the JDK Update Button (third button under the Win32 heading). This will start an automatic update of your browser. During installation you will be prompted to Grant or Deny a request to install software. Grant the request so installation can occur. Follow the instructions provided. When installation is complete, close Netscape Navigator and reopen the application. To verify that a proper installation has occurred, select Java Console from the Communicator menu. The first line of the Java Console should read Netscape Communications Corporation -- Java 1.1.4. For UNIX users, go to http://developer.netscape.com/software/jdk/download.html#UNIX_INSTALL. Here you will find information on how to download and install the patch for various flavors of UNIX. Internet Explorer You will need Internet Explorer 4.01 or higher for Java 1.1 support. To obtain the latest version of IE 4.0 go to http://www.microsoft.com/ie/download. Follow the provided instruction to install the product. HELP WINDOWS Due to a Javascript support problem in Netscape, if you resize the panel help window the 'close' button may not function correctly. If this should happen, you can always close the window by using the window's close icon. ------------------------------------------ Generating SSL Certificates for ADSM users ------------------------------------------ Included with the install package are utilities to create and maintain certificates. The primary certificate tool is MKKFE. With this utility a certificate request and key ring file can be created. Once a certificate request has been created it can be sent off to a Certificate Authority (CA) for signing. Self signed certificates can be created using the provided utilites. However, there are some limitations, see the section on "SSL Support Issues". CREATING A KEY RING FILE AND CERTIFICATE REQUEST FOR THE SERVER 1. Start the MKKFE application. MKKFE requires the NLSPATH environment variable to point to the location of the secnls.cat message catalog: export NLSPATH=/opt/adsmserv/bin/%N 2. Create a new key ring file by pressing n. Name the new file certkey.kyr. This filename is a requirement of the ADSM server, any other name will not be recognized. 3. Create a new Certificate request a.From the main menu press w to work with certificates. b.To create a new certificate press c, At this point you will be prompted for a password. This password is for the key ring file. Enter apollo. Remember to keep the password for later use. After the password has been entered twice, a prompt will ask if the password is to expire. Answer no to this question. c.The type of certificate to create is a PEM certificate, press s. You will be presented with the following screen. Compose PEM Certificate Request Menu Current Certificate Information Key Name: (none) Key size: 0 Server Name: (none) Organization: (none) Organizational Unit: (none) City/Locality: (none) State/Province: (none) Postal Code: (none) Country: (none) M - Modify the Certificate Request Fields R - Ready To Create Key and Certificate Request C - Cancel Enter a command: press m modify the request. Enter in all personal information as requested by the program. Below is a sample session. Enter a name to use for the key entry: ADSM Server 1: 508 2: 512 Enter the number corresponding to the key size you want: 2 Enter the server's fully qualified TCP/IP domain name or press ENTER by itself to leave the field blank. adsm_server.ibm.com Enter Organization Name for the certificate or press ENTER by itself to leave the field blank. IBM Enter Organizational Unit Name for the certificate or press ENTER by itself to leave the field blank. ADSM Enter Locality/City Name for the certificate or press ENTER by itself to leave the field blank. SomeCity Enter State/Province Name for the certificate or press ENTER by itself to leave the field blank. State/Province must be at least three characters long. SomeState Enter Postal Code for the certificate or press ENTER by itself to leave the field blank. 99009 Enter Country Code for the certificate or press ENTER by itself to leave the field blank. Country code must be exactly two characters long. US a. The first thing entered is a name for the certificate request. This name is for use by the key ring file. The second entry is for the key size. The recommended size is 512. The next fields information about your company and the location of the ADSM Server. When prompted for the fully qualified TCP/IP address, don't enter a IP address. The entry is the name of the machine where the ADSM server resides. For example, adsm_server.ibm.com. b. After the above information has been entered, you will be presented with a summary of what has been modified. If everything is to your liking, then you are ready to create a certificate request. c. To create the certificate request press r. When prompted for a file name type certreq.txt. d. At this point you will want to mark the created certificate as the Default Certificate of the key ring. To do this type f. After the certificate has been marked as trusted root it is now time to receive the certificate into the key ring file. You will need to return to the Key Ring Menu to do this. Press x from the Key Menu to return to the Key Ring Menu. e. At this point all the work with the server key ring file is done. Save the key ring by pressing s and exit the application by pressing x. The certificate request that has been created can now be sent to a Certificate Authority of your choice to be signed. This process might require other paper work to be filled out. Check with the CA before sending your certificate request. Also, some e-mail program might add extra spaces to the end of a certificate, which will invalidate the certificate, so be careful when sending and receiving certificate. If you are using self signed certificates, then proceed to the next step. RECEIVING THE SIGNED CERTIFICATE INTO THE SERVER KEY RING FILE Once you have received the signed certificate from the CA, you will need to receive the signed certificate into the server key ring file. 1. Start the MKKFE application. 2. Open the server key ring file by pressing o. Name the new file certkey.kyr. 3. Receive the new Certificate. a. If you are your own CA you will need to receive the CA certificate before receiving the server certificate. First receive the certificate into the key ring by pressing r from the Key Ring Menu. Enter the filename of the CA certificate request. From the above instructions the file name is cacert.txt. You will be warned about adding a self-signed certificate to the key ring file; press y to continue. You will then be prompted for a name of the key. Enter a name and you will return back to the Key Ring Menu. The next step is to make the received certificate a trusted root. This is done by working with the certificate. Press w to work with the certificate. The certificate will need to be selected at this point. Press l to list and select the certificate. Press n to proceed the next certificate until you find the name that you just entered. Once that name has been found press s to select the certificate. You will now return back to the Key Menu, where you can make the certificate a trusted root by pressing t. Return back to the Key Ring Menu, by pressing x, to continue with the next step. b. To receive the signed server certificate, press r from the Key Ring Menu. Enter the filename of the signed certificate, cert.txt for example. You might receive a warning about the certificate signer certificate not being part of the Key Ring. This mainly occurs when you have become your own CA. The next step is to make the received certificate the default certificate. This is done by working with the certificate. Press w to work with the certificate. The certificate will need to be selected at this point. Press l to list and select the certificate. Press n to proceed to the next certificate until you find the name that was originally given for the server certificate, this name is ADSM Server from our example. Once that name has been found press s to select the certificate. You will now return back to the Key Menu, where you can make the certificate the default by pressing f. Return back to the Key Ring Menu, by pressing x, to continue with the next step. Now save the Key Ring file by pressing s from the Key Ring Menu. You will be prompted that the file exists; it is OK to overwrite this file. After the save has completed, exit MKKFE by pressing x. SETTING UP THE ADSM SERVER FOR SSL After all of the certificates have been created, copy the created file, the signed certificate, the key ring file certkey.kyr and the cacert.txt file if you are your own CA, to the ADSM server executable directory. Before bringing up the ADSM server, add the COMMETHOD HTTPS to your dsmserv.opt option file. This will indicate that the server should bring up the SSL communication method. The port number is set by HTTPSPORT in the dsmserv.opt. The default port is 1543. Start the ADSM server. At this point SSL initiation will not occur, since the key ring password is unknown. Define the key ring filename and passoword using the DEFINE KEYRING command as shown below. Halt and restart the ADSM server to start the SSL communication method. WARNINGS MESSAGE FROM WEB BROWSER You will receive a message from the web browser when you are your own CA. This is mainly because the certificate that you have created is not trusted by the browser. Each browser handles the matter differently. Netscape will allow you to receive the certificate as a web site certificate. The received certificate is then compared with the certificate sent by the ADSM server every time you connect the server. After setup has completed, you will not be prompted for any more information in the future, that is if you click the always accept bullet in the wizard. Internet Explorer handles the matter a little differently. It will prompt you that the certificate being received is not trusted. You will continue to get this message every time you connect to the ADSM server unless you turn the warning message off. SSL SUPPORT ISSUES ADSM will support unsecure (non SSL) connection to any web browser capable of understanding HTML version 2.0 on all ADSM server platforms. However, certain combination of the secure connections between ADSM server and web browser can cause problems. It is recommend that you connect with Netscape Navigator version 4.05 or better to ADSM using Secure Socket Layer (SSL). ADSM does not support SSL connections from UNIX ADSM servers to the Internet Explorer web browser using certificates signed by the users own certificate authority or self signed certificates. SSL connections are only supported from UNIX ADSM servers to Netscape Navigator, which will accept self signed certificates. ADSM does support Internet Explorer browser SSL connection to the ADSM NT servers. Further, ADSM will support any user who goes out and gets a certificate signed by a trusted Certificate Authority like IBM World Registry or Versign. DEFINE KEYRING Command. Use the DEFINE KEYRING command to define a new key ring filename and password. The key ring file is created using the MKKFE utility provided with ADSM. This command will need to be issued before SSL will start correctly. If this command has not been issued, the initialization of SSL will fail with a message stating that the filename and/or password is invalid. After the command has been issued to ADSM, halt and restart the ADSM server for the SSL communication method to start. Privilege Class To issue this command, you must have system privilege. Syntax >>-DEFine KEYring--filename---password----------------------------------->< Parameters filename Specifies the file name of the key ring file. This parameter is required. This file name must end with the extension .kyr, to indicate a key ring filename. For example, certkey.kyr is a valid filename. The key ring file must be place in server root directory. password Specifies the password of the key ring file. This parameter is required. This is the same password as the one used to create the server keyring in the MKKFE utility. Examples Task Define the key ring filename of certkey.kyr and password of apollo Command: define keyring certkey.kyr apollo Expected output: ANR4704I Key ring filename and password have been set. Restart ADSM to use new settings. ----------------------------------------- Notes for use of SNMP sub-agent (dsmsnmp) ----------------------------------------- ADSM 3.1.2 servers cannot be used with versions of the SNMP subagent ( dsmsnmp ) prior to 3.1.2 and vice versa; Command output from SNMP subagents which run scripts on ADSM servers is truncated to 4026 characters. This is a limitation of SNMP agents. The following files are updated for service level 3.1.2.1: dsmsnmp aix.adsm.defs mib2adsm.tbl adsmserv.mib Two MIB variables have been added for control of text output from the SNMP subagent; These variables allow control over column delimiters and line delimiters. The two variables are: ibmAdsmServerLineDelimiter and ibmAdsmServerValueDelimiter These variables default to 0, which operates the same as the original dsmsnmp, i.e., lines are delimited by carriage return/line feed sequences and columns are delimited by blanks. Each variable is an enumerated type ranging from 1-5 and 1-3 respectively (the enumerations are documented in the MIB ). If ibmAdsmServerValueDelimiter is non-zero, the output in ibmAdsmM1ReturnValue works as the administrative command line client -commadelimit and -tabdelimit parameters, separating commas by either commas or tabs. These are for values 1 and 2 respectively. A value of 3 may be used to delimit by a blank. In these cases, column headings are suppressed. For ibmAdsmServerLineDelimiter, the following values are allowed: crlf (1) - output as the default with carriage return/line feed separating lines lf (2) - output with only a line feed between lines comma (3) - output with only a comma between lines tab (4) - output with only a tab between lines blank (5) - output with only a blank between lines --------------------- Documentation Updates --------------------- Problem: Routed commands using the serverlist: command syntax cannot be used within scripts. If a routed command using this syntax is used in a script, the command will run on the issuing server, not the targeted server. Solution: A new, additional syntax for routing commands is available. Routed commands can also be indicated by the following syntax: (serverlist) command Example: To route the command QUERY VOLUMES to the defined servers JOE and CHARLIE enter either of the following command: (JOE,CHARLIE) QUERY VOLUMES JOE,CHARLIE: QUERY VOLUMES The rules for the list of server names are the same with the new syntax as with the original. The new syntax can be used inside scripts to route commands. Example: To create and run a script CHECK_VOLUMES that routes the command QUERY VOLUMES to the defined servers JOE and CHARLIE enter the following commands: DEFINE SCRIPT CHECK_VOLUMES '(JOE,CHARLIE) QUERY VOLUMES' RUN SCRIPT CHECK_VOLUMES Updates to the Command Routing information: Administrators can route commands to one server, a server group or a list that contains multiple servers, multiple server groups or a combination of servers and server groups. Each server or server group in a list must be separated with a comma, without spaces. The server, server group, or list must be followed immediately by a colon or enclosed in parentheses, and followed by the command to be processed. Spaces are allowed between the end colon or parentheses and the command to be routed. The end parenthesis or the colon after the server name indicates the end of the routing information. Updates to the UPDATE and DEFINE SCRIPT command, and the information on using scripts: Command routing in a SCRIPT must be done using the parentheses. If command routing is done using the colon syntax, the command will not be routed when the RUN command is issued, and will instead run on the server where the RUN command is issued. ----------------------------- Migration by Age - Limitation ----------------------------- Migration by age from disk will not be available in service level 3.1.2.0 The MIGDELAY and MIGCONTINUE parameters on the storage pool definition are only operational for sequential storage pools and not for disk storage pools at this time. These parameters will be enabled for disk storage pools in a later service level. ---------------------------------- Migration by Age from Random Media ---------------------------------- MIGRATION BY AGE: Customers are now able to specify how long they want their data to remain in a disk storage pool with the following additions to the disk storage pool definition: MIGDelay=migdelayvalue Specifies the minimum number of days that a file must remain in a storage pool before the file becomes eligible for migration from the storage pool. The number of days is counted from the day that the file was stored in the storage pool or retrieved by a client, whichever is more recent. This parameter is optional. You can specify an integer from 0 to 9999. The default is 0, which means migration is not delayed. If you want the number of days to be counted based only on when a file was stored and not when it was retrieved, use the NORETRIEVEDATE server option. MIGContinue=migcontinuevalue Specifies whether you allow ADSM to migrate files that do not satisfy the migration delay time. This parameter is optional. The default is YES. Because you can require that files remain in the storage pool for a minimum number of days, ADSM may migrate all eligible files to the next storage pool yet not meet the low migration threshold. This parameter allows you to specify whether ADSM is allowed to continue the migration process by migrating files that do not satisfy the migration delay time. Possible values are: Yes Specifies that, when necessary to meet the low migration threshold, ADSM continues to migrate files that do not satisfy the migration delay time. If you allow more than one migration process for the storage pool, some files that do not satisfy the migration delay time may be migrated unnecessarily. As one process migrates files that satisfy the migration delay time, a second process could begin migrating files that do not satisfy the migration delay time to meet the low migration threshold. The first process that is still migrating files that satisfy the migration delay time might have, by itself, caused the low migration threshold to be met. No Specifies that ADSM stops migration when no eligible files remain to be migrated, even before reaching the low migration threshold. ADSM does not migrate files unless the files satisfy the migration delay time. NORETREIVEDATE option: If you want the number of days to be counted based only on when a file was stored and not when it was retrieved, use the NORETRIEVEDATE server option. Specifies that the retrieve date of a file in a disk storage pool not be updated when the file is restored or retrieved by a client. This option can be used in combination with the MIGDELAY storage pool parameter to control when files are migrated. If this option is not specified, files are migrated only if they have been in the storage pool the minimum number of days specified by the MIGDELAY parameter. The number of days is counted from the day that the file was stored in the storage pool or retrieved by a client, whichever is more recent. By specifying this option, the retrieve date of a file is not updated and the number of days is counted only from the day the file entered the disk storage pool. If this option is specified and caching is enabled for a disk storage pool, reclamation of cached space is affected. When space is needed in a disk storage pool containing cached files, space is obtained by selectively erasing cached copies. Files that have the oldest retrieve dates and occupy the largest amount of space are selected for removal. When the NORETRIEVEDATE option is specified, the retrieve date is not updated when a file is retrieved. This may cause cached copies to be removed even though they have recently been retrieved by a client. Syntax: NORETRIEVEDATE Parameters: None. Examples NORETRIEVEDATE ---------------------------------------------- Drive Cleaning Support for SCSI Tape Libraries ---------------------------------------------- ADSM 3.1.2.1 includes ADSM-controlled cleaning of tape drives in a SCSI library and partial support in stand-alone (manual) libraries. This support is intended to be used ONLY for those scsi libraries that do NOT have their own automatic cleaning in the device hardware. Automatic cleaning is included in such libraries as the STK 9710 and IBM 3570 and 3575, and ADSM is not aware or involved with it in any way. ADSM-controlled cleaning is not as tightly integrated with the device hardware as a library's own automatic cleaning and may actually conflict with it. The default for ADSM-controlled cleaning is NONE, which means cleaning is up to the library hardware or a human operator. The automatic cleaning included in some SCSI libraries interferes with ADSM's use of the library and drives. If this is the case with your library, turn off the built-in automatic cleaning and use ADSM-controlled cleaning. ** ATTENTION ** Use of ADSM-controlled cleaning involves checking a cleaner cartridge into the library's volume inventory. Be careful when using the CHECKIN, CHECKOUT, LABEL, and AUDIT LIBRARY commands to ensure that a cleaner cartridge is not inadvertently loaded into a drive instead of a data cartridge. Details on how to prevent mistaking a cleaner cartridge for a data cartridge are provided below. Overview for SCSI Libraries You set up ADSM-controlled drive cleaning with the following three steps: 1. Define the drives in a library with the new parameter that defines the frequency of cleaning. 2. Check a cleaner cartridge into the library's volume inventory. ADSM mounts the cleaner cartridge in a drive when it needs cleaning. 3. When needed, issue or schedule the new command, CLEAN DRIVE. Use this command when you want ADSM to immediately load a cleaner cartridge into a drive regardless of the cleaning frequency. Details on these steps follow. -------------------------------------------------------------------------------- 1. Defining the drives with frequency of cleaning A new parameter, CLEANFREQUENCY, is added to the DEFINE DRIVE command. The following is the new DEFine/UPDate command syntax: >>-DEFine/UPDate DRive--libname--drivename--DEVIce-=-devicename-> .-ONLine--=--Yes------. >---+---------------------+--+----------------------------+-----> '-ONLine--=--+-Yes-+--' | | '-No--' '-ELEMent--=--elementaddress-' '-CLEANFREQuency-=-+-NONE------+ >---+------------------------------+--------------------------->< '-CLEANFREQuency-=-+-NONE------+ |-ASNEEDED -| | '-value-----' For the CLEANFREQUENCY parameter, possible values are: - NONE, meaning ADSM does not track the need for device cleaning. This is the default. Use for libraries that have their own automatic cleaning. - ASNEEDED, meaning that only when a drive reports a cleaning-needed indicator to the device driver does ADSM load the drive with a checked-in cleaner cartridge. - A value from 1 to 9999 that specifies how much data in Gigabytes should be processed on the drive before ADSM loads the drive with a cleaner cartridge. ADSM also responds to cleaning-needed indicators from a drive with this option, as for the ASNEEDED option. When the drive indicates that it needs to be cleaned or the GBytes-processed threshold is exceeded, the drive finishes processing the volume that is mounted on it. As part of the dismount processing, ADSM loads a cleaner cartridge into the drive (provided that one is checked into the library inventory) and resets the GBytes-processed counter. 2. Check a cleaner cartridge into the library's volume inventory Use the CHECKIN LIBVOL command to check a cleaner cartridge into the library. The following is the CHECKIN LIBVOL command syntax showing the new STATUS value of CLEANER and the new CLEANINGS parameter: >>-CHECKIn LIBVolume--libraryname--volname----------------------> .-CHECKLabel--=--Yes--------------. >---STATus--=--+-PRIvate-+--+---------------------------------+-> |-SCRatch-| '-CHECKLabel--=--+-Yes---------+--' '-CLEaner-' +-No----------+ '-Barcode-----' .-SWAP--=--No-------. >----+-------------------+--VOLRange--=--+-volname1-+-----------> '-SWAP--=--+-No--+--' '-volname2-' '-Yes-' .-MOUNTWait--=--60---------------. >---+--------------------------------+--------------------------> '-MOUNTWait--=--mountwaitvalue---' .-SEARCH--=--No------------. >----+--------------------------+-------------------------------> '-SEARCH--=--+-No-------+--' +-Yes------+ '-Bulk-----' >----+-----------------------+--------------------------------->< '-CLEANINGS--=--1..1000-' The STATUS=CLEANER parameter value designates the volume as a cleaner cartridge and not a data cartridge. Check in a cleaner cartridge separately from data cartridges using STATUS=CLEANER. The CLEANINGS parameter is required for cleaner cartridges. Set the value to the recommended number of uses for the cleaner cartridge (usually indicated on the cartridge). The volume name is arbitrary, because the name is never read from the cleaner. However, if the cleaner has a barcode label, use that value as the volume name. CHECKLABEL=YES is invalid for checking in a cleaner. Although you can check in cleaner cartridges using SEARCH=YES, it is recommended that you check them in one at a time. If you check in more than one cleaner cartridge, ADSM uses only one cartridge until that cartridge is used the number of times indicated by the CLEANINGS value. ADSM then selects another cleaner cartridge, and you can check out and discard the first cartridge. When a cleaner cartridge has five or fewer cleanings left, ADSM issues a warning with each use. You cannot update the status of a volume from CLEANER to SCRATCH or PRIVATE, and vice versa. If you have checked in a volume with the wrong status, you must check the volume out and check it back in again with the correct status. This process helps to prevent changing a cartridge to the wrong status. When you check out the volume, use the REMOVE=YES option of the CHECKOUT command, so that you can verify the type of cartridge. You can change the CLEANINGS value by using the UPDATE LIBVOLUME command with the STATUS=CLEANER parameter. 3. When needed, issue or schedule the new command, CLEAN DRIVE. The syntax of the command is: >>-CLEAN--DRIVE--libraryname--drivename---------------------->< This command is valid only in a SCSI library that has a cleaner cartridge checked into its inventory. This command marks the drive as needing to be cleaned. If the drive is not busy at the time, ADSM loads the cleaner cartridge into the drive immediately. If the drive is busy, ADSM loads the cleaner cartridge when the drive is unloaded. Determining How Often A Drive Should Be Cleaned Consult the manuals that accompany the drives for cleaning recommendations. In some cases, the manuals describe the cleaning frequency in terms of hours of use. In this case, use the drive's bytes per second speed rating to determine a GBytes per hour value for the drive. Then multiply the GBytes/hour by the recommended hours of use between cleanings. Use the result as the CLEANFREQUENCY to be set on the drive definition. Alternatively, you can set the CLEANFREQUENCY to ASNEEDED to allow the drive to signal when it needs to be cleaned. In some cases, however, this alternative is not reliable. Preventing Problems When Using A Cleaner Cartridge in a SCSI library When a cleaner cartridge is checked in to the library, ADSM cannot verify that the cleaner cartridge is in fact a cleaner. Various ADSM-supported drives and libraries differ in how they handle cleaners, how they report the presence of cleaners in a drive, and how the device drivers on different platforms are able or are not able to open a drive that may contain a cleaner at the time. This variability means that ADSM cannot uniformly detect a cleaner cartridge. For this and other reasons, ADSM does not intentionally load the cleaner cartridge into a drive until the drive needs to be cleaned. Because of ADSM's limited ability to recognize a cleaner, ensure that you do not check in a data cartridge with STATUS=CLEANER, and that you do not check in a cleaner with STATUS=SCRATCH or PRIVATE. For instance, when running a CHECKIN or LABEL command with SEARCH=YES, do not allow a cleaner to be placed in a slot that will be detected by that search process. TO DO SO WILL PRODUCE A NUMBER OF ERRORS, including I/O errors and long delays on drive loads and unloads, which may be on the order of 15 minutes. Cleaners that are already checked in are not a problem when checking in data cartridges with SEARCH=YES, provided that the cleaners are in their correct home slots. To help you verify that cleaners are in their correct home slots, the QUERY LIBVOL command now provides the element ID of the home slot for all library volumes. Visually verify the correct storage slots for cleaners before using a search process to check in volumes or before auditing a library. PLEASE NOTE: Because AUDIT LIBRARY does not audit a slot that has a cleaner cartridge checked into it, visually verifying a cleaner's home slot is especially important before running an AUDIT LIBRARY command. If a drive needs to be cleaned, ADSM runs the cleaning operation after dismounting a volume. If the cleaning operation fails or is cancelled, or if no cleaner is checked in that has any cleanings left, then the indication that the drive needs cleaning is lost. Monitor cleaning messages for these problems. If necessary, clean the drive either by issuing a CLEAN DRIVE command or by manually loading a cleaner into the drive. Drive Cleaning Without Checking a Cleaner Into the Library You can specify a cleaning frequency for a drive without checking a cleaner cartridge into the library. When a drive needs to be cleaned based on the clean frequency criteria, ADSM issues this message: ANR8914I Drive in library needs to be cleaned. The message is issued whether or not a cleaner is checked into the library. You can use that message as a cue to manually insert a cleaner into the drive. You may want to do this if you do not want to deal with the constraints of having a cleaner checked into the library's inventory. There is, however, no support for a QUERY command to indicate that a drive is in the needs-cleaning state. ADSM cannot determine from the drive that the drive has been cleaned so that such an indicator could be turned off after cleaning. Drive Cleaning in a Manual Library This support is the same as in "Drive Cleaning without Checking in a Cleaner." There is no library inventory in a manual library, but the ANR8914I message is issued when a drive needs to be cleaned. The operator must monitor for these messages and load a cleaner cartridge into the drive when needed. -------------------------------- Preserving ACSLS Server hostname -------------------------------- After the product installation, the user should ensure CSI_HOSTNAME is properly defined. To do this Define the environment variable ACSLS_SERVER_HOSTNAME in the system wide environment file /etc/environment or the system wide profile /etc/profile and assign it your ACS host name. --------------------------------- CHECKIN and LABEL command changes --------------------------------- A new parameter VOLLIST has been added to the CHECKIN and LABEL LIBVOLUME commands to allow the user to specify a list of volumes for the process. VOLList=volumespec Specifies the volume names that are to be used by the CHECKIN or LABEL commands. volumespec can be a list of volume names or a file that a list of volume names. VOLList=vol1,vol2,vol3 ... specifies the names of the volumes. Each volume name is separateed by a comma with no intervening spaces. For example: VOLL=TAPE01,TAPE02,TAPE03 VOLList=FILE:filename Specifies the path and name of the file that contains a list of volumes. In the file, each volume name must be on a separate line. Blank lines and comment lines that begin with an asterisk are ignored. For example, to use TAPE01, TAPE02 and TAPE03, create a file called TAPEVOL that contain these lines: TAPE01 TAPE02 TAPE03 and specify the parameter as follow: VOLL=FILE:TAPEVOL The path and filename are case sensitive. This parameter is optional. However, if specified the SEARCH=YES option must also be specified. In addition, if specified, the existing VOLRrange parameter must not specified. This parameter is supported for SCSI, 3494 or ACSLS libraries. CHECKOUT command: To support the bulk volume checkout function from a ACSLS library, two parameters, VOLRANGE and VOLLIST have been added to the CHECKOUT LIBVOLUME command to allow the user to specify a list of volumes or a range of volumes. If either VOLRANGE or VOLLIST is specified, the existing "volname" for the single volume checkout function must not specified. VOLRANGE and VOLLIST are not supported for the 3494 and SCSI libraries. When specified, REMOVE=BULK is treated the same as REMOVE=YES. REMOVE=BULK is not supported for single volume checkout for the ACSLS library. VOLRange=vol1,vol2 Specifies the volume range for this command. The volume format can be any combination of alphanumeric characters. Basically, it contains prefix, incremental and sufix areas. The prefix and sufix areas are optional. If they are used, they are identical alphanumeric characters between vol1 and vol2. Prefix area begins at the first character and ends at the first "non-compare" numeric character. The incremental area are numeric characters which begins after the prefix area and ends at the next alpha character, if any. The incremental numerics of vol2 must be greater than the numerics of vol1. The sufix area, optional, begins at the end of the incremental area and are all alpha characters. The possible combination for volume range are: AnA, nA, An, n or A "A" means the prefix or sufix area where the alphanumeric characters of vol1 and vol2 are identical. "n" is the incremental area. For example: VOLR=ABC123,ABC234 VOLR=123456,123567 VOLR=123ABC,234ABC VOLR=A123BC,A234BC This parameter is optional. However, if specified the VOLLIST parameter must not specified. VOLList=volumespec Specifies a list of volume names to be used by the CHECKOUT command. volumespec can be a list of volumes or a file that contain a list of volumes. VOLList=vol1,vol2,vol3 ... specifies the names of the volumes for the process. Each volume name is separated by a comma with no intervening spaces. For example: VOLL=TAPE01,TAPE02,TAPE03 VOLList=FILE:filename Specifies the path and name of the file that contains a list of volumes. In the file, each volume name must be on a separate line. Blank lines and comment lines that begin with an asterisk are ignored. For example, to use TAPE01, TAPE02 and TAPE03, create a file called TAPEVOL that contain these lines: TAPE01 TAPE02 TAPE03 and specify the parameter as follow: VOLL=FILE:TAPEVOL The path and filename are case sensitive. his parameter is optional. However, if specified the VOLRANGE parameter must not specified. ------------------------------------------------------------ Information on Data Errors in prior levels of ADSM Version 3 ------------------------------------------------------------ Overview -------- ADSM Version 3 AIX servers prior to service level 3.1.1.5 and non-AIX servers prior to service level 3.1.1.3 have experienced data errors during movement/reclamation of files stored on sequential-access media. Information regarding these problems has been distributed in several different forms. To reduce confusion, this package updates, summarizes, and simplifies information about these problems. The ADSM organization has gone to great lengths to ensure that problems involving data errors are addressed in a forthright and aggressive manner. While some problems are not likely to be seen by customers, we have nonetheless issued warnings and provided fixes as soon as possible to eliminate the remote possibility of affecting customer data. We have developed commands to identify and manage affected files. Once identified, these files can be recovered from valid copies the server has made, or the files can be deleted so that new backups are produced. NOTE to non-AIX platforms: This PTF contains an updated set of utilities that checks for any data errors that might have been introduced while the server was running at the 3.1.1.3 level. Although data errors at the 3.1.1.3 service level have only been observed on AIX, we are providing the updated utilities on all platforms as a precaution. The updated utilities contain an abbreviated audit that checks for any problem files. Frequently Asked Questions -------------------------- FREQUENTLY ASKED QUESTIONS * What is the nature of the data errors? The ADSM server performs various internal operations that move or copy data from one storage location to another. In certain situations, when a file is transferred from a sequential-access volume to another location, the target file may be invalid. * Is my ADSM server affected by these problems? Version 3 servers at levels prior to 3.1.1.5 may contain files with invalid data. * Are Version 1 or Version 2 ADSM servers affected by these problems? No. * Can files be affected that have never been stored on sequential-access storage pool volumes? No. * Weren't these problems corrected prior to 3.1.1.5? In April 1998, PTFs were distributed for all server platforms to correct the original data movement/reclamation problem. The service levels of these PTFs were 3.1.0.2 (MVS) and 3.1.1.1 (non-MVS platforms). More recently, a different Version 3 reclamation problem has been identified. To date, customers have reported this problem only on AIX servers, but we have not excluded the possibility that Version 3 servers on other platforms might also be affected. At this time, we have been unable to recreate the problem in our lab on any server platform, but are continuing to investigate. Service level 3.1.1.5 eliminates this most recent problem and is now available on AIX. * I upgraded from a Version 1 or Version 2 server to Version 3. Will files stored on the early server versions be affected by these problems? In PTF 3.1.0.2 (MVS) and 3.1.1.1 (non-MVS), a problem was corrected that could cause data errors in files that were stored to a Version 1 or 2 server and later moved or copied using a Version 3 server. If you used a Version 3 server that did not contain this fix, it is possible that Version 1 or Version 2 files could be affected. * Can space-managed files be affected by any of these problems? In PTF 3.1.0.2 (MVS) and 3.1.1.1 (non-MVS), a problem was corrected that could cause data errors in space-managed files. If you used a Version 3 server prior to this fix, it is possible that space-managed files were affected. * Is the 3466 Network Storage Manager affected by these problems? The Network Storage Manager may be affected if it has ever operated with ADSM Version 3 at a service level prior to 3.1.1.5. * I am using the ADSM Version 3 server. What can I do now to ensure that data errors are not introduced during data movement/reclamation operations? To avoid possible loss of data, you should apply the latest service level to your Version 3 servers as soon as possible. For AIX, service level 3.1.1.5 is now available and corrects all known data movement/reclamation problems. For all other platforms, service 3.1.1.3 is the latest level and corrects all problems that are known to exist on these platforms. * Why is service level 3.1.1.5 currently available only on AIX? Delivery of this service level was expedited on AIX to correct the recently discovered problem with data errors during reclamation on AIX servers. Although this problem has not been observed on other server platforms, a future PTF will be provided on each platform to eliminate the possibility of similar errors. * I'm still on ADSM Version 2. Is it safe for me to migrate to Version 3? The ADSM development and support groups are confident that it is safe and prudent to migrate to ADSM Version 3, provided that the most current level of maintenance is applied after installation. ADSM Version 3 provides many features that customers have requested and will be a valuable part of your installation. * I'm on ADSM version 2. How do I migrate to Version 3 without being affected by these problems? Install the base ADSM version 3 package and upgrade the database (this is done as part of the install on some platforms). Then install the PTF for level 3.1.1.3 (all server platforms except AIX) or 3.1.1.5 (AIX servers). You are now at the requisite level. For non-AIX servers, a future PTF will contain an updated set of utilities that checks for any data errors that might have been introduced while the server was running at the 3.1.1.3 level. Although data errors at the 3.1.1.3 service level have only been observed on AIX, we will provide the updated utilities on other platforms as a precaution. The updated utilities will contain an 'abbreviated' audit that checks for any problem files. * I do not currently use ADSM, but want to begin. What version should I use? We recommend that you use ADSM Version 3 because it provides many attractive features that are not found in previous versions. However, it is important that you apply the current maintenance level. For AIX servers, this is level 3.1.1.5. For other platforms, the latest service level is 3.1.1.3. For non-AIX servers, a future PTF will contain an updated set of utilities that checks for any data errors that might have been introduced while the server was running at the 3.1.1.3 level. Although data errors at the 3.1.1.3 service level have only been observed on AIX, we will provide the updated utilities on other platforms as a precaution. The updated utilities will contain an 'abbreviated' audit that checks for any problem files. * Can anything be done to deal with files that have already been affected by these problems? A set of utilities has been developed to identify and handle files that have been affected by these problems. These utilities are included in the latest Version 3 PTF. The utility functions are run by issuing commands on the ADSM console or from an administrative client. The utilities have been updated in service level 3.1.1.5 and later. The updated utilities check for all known types of data errors caused by data movement/reclamation, including the most recent problem. * What do the utilities do? The utilities include an audit command which identifies and gathers information about any files that are affected by these problems. An SQL SELECT command can then be used to view this information. Existing commands can be used to restore affected files from a copy storage pool, if valid copies are stored in the copy pool. A delete command is also provided for deleting database references to affected files. * Rather than using the reclamation utilities, can I use the AUDIT VOLUME command to detect any files that have been affected by these problems? No. The reclamation utilities are the only dependable way to detect these problems. * I have already run the utilities that were included with service level 3.1.1.2 or 3.1.1.3. Is there anything else I should do? In July 1998, the utilities were modified to detect files that have been affected by the reclamation problem that has recently been observed on AIX servers. AIX servers should be upgraded to 3.1.1.5 as soon as possible to eliminate the possibility of additional data errors because of this problem. You should then re-run the utilities, using the "abbreviated" audit mode. Although this reclamation problem has only been observed on AIX, a fix will be provided in the next PTF for other servers to ensure that they are not affected by a similar problem. When the next PTF becomes available on your server platform, you should apply this service. As a precautionary measure, after you have applied this PTF, we recommend that you run the updated utilities using the 'abbreviated' audit mode. * I have started using the utilities included with service level 3.1.1.2 or 3.1.1.3, but have not yet finished and issued the CLEANUP RECLAIM command. What should I do? You should finish running the utilities, including the CLEANUP RECLAIM command. Then apply the PTF with the updated utilities and run these utilities with the 'abbreviated' audit mode. * Specifically, what utilities are provided to help manage files that may have been affected by these problems? o An AUDIT RECLAIM command checks the ADSM database for files that may be affected and stores information about those objects in a RECLAIM_ANALYSIS table. o After the audit, the RECLAIM_ANALYSIS table can be queried using the SQL SELECT command. It may be possible to restore valid copies of these files from a copy storage pool. Alternatively, the files can be restored/retrieved to the client for examination or they can simply be deleted. o A DELETE RECLAIM command can be used to delete logical files in the RECLAIM_ANALYSIS table from the ADSM database. For backup files that still exist on the client machine, the next incremental backup should then store a new copy of the deleted file on the ADSM server. o A REMOVE RECLAIM command allows you to delete the entry for an individual logical file from the RECLAIM_ANALYSIS table. Optionally, the file itself can be deleted from the ADSM server database. o A CLEANUP RECLAIM command deletes all entries from the RECLAIM_ANALYSIS table and sets values in the ADSM database to show that the utilities have been completed. * What is the "abbreviated" audit mode mentioned above? The utilities were updated in July 1998 to check for files affected by the most recent reclamation problem. The revised utilities include an audit with two modes of operation. The first mode is the 'complete' mode or normal mode. This mode is intended for customers whose servers may have been exposed to the original data movement/reclamation problem. This includes all Version 3 servers that have run at any level prior to 3.1.0.2 (MVS) or 3.1.1.1 (non-MVS). For these servers, the 'complete' audit should be performed, unless an earlier version of the utilities has already been run. The updated utilities in 'complete' mode will examine client files for the original data movement/reclamation error as well as checking for the most recent reclamation problem. The second mode is the 'abbreviated' mode and should be used by customers whose servers are not affected by the original data movement/reclamation problem or who have already run the utilities to manage files affected by this problem. This mode only checks for the most recent data movement/reclamation problem and typically runs faster than the complete audit. * Can the utilities be executed while other ADSM processes are running? The AUDIT RECLAIM command can yield inaccurate or incomplete results if it runs at the same time as certain other processes. To avoid this situation you must make sure that the following operations are not running while the AUDIT RECLAIM command is running: Inventory expiration Storage pool migration Reclamation of sequential volumes MOVE DATA command BACKUP STGPOOL command RESTORE STGPOOL command RESTORE VOLUME command DELETE FILESPACE command DELETE VOLUME with DISCARDDATA=YES AUDIT VOLUME * Does the AUDIT RECLAIM command require that tapes be mounted? The reclamation audit examines information in the ADSM database to detect files that have data errors caused by the data movement/reclamation problems. The audit does not access files in your storage pools and therefore does not require the mounting of tapes. * How long will it take to run the reclamation audit? This will depend primarily on how many physical files are stored on your server. If the audit is long-running, it can be cancelled and restarted where it left off. This allows you to interleave audit processing with other server operations. * My server stores mostly backup files. Is there a simple procedure to identify and delete any files with errors so they can be backed up during the next incremental backup? The following basic steps can be used. 1. Issue the following command and wait for the background process to complete AUDIT RECLAIM 2. To display information on any files that the audit detected as having data errors, issue the following case-sensitive SQL query from an administrative client SELECT * FROM RECLAIM_ANALYSIS 3. Issue the following command and wait for the background process to complete DELETE RECLAIM FILETYPE=BACKUP 4. Issue the following command CLEANUP RECLAIM * I regularly back up files to a copy storage pool. If my primary storage pools contain files that have been affected by these problems, is it possible to recover the files from a copy storage pool? The following basic steps can be used. 1. Issue the following command and wait for the background process to complete AUDIT RECLAIM EXAMINECOPIES=YES This command marks affected files as damaged if a good copy is found in a copy pool. 2. To display information on any files that the audit detected as having data errors, issue the following case-sensitive SQL query from an administrative client SELECT * FROM RECLAIM_ANALYSIS 3. Use the RESTORE STGPOOL command to restore files that were marked as damaged in the previous step. For example, to restore files residing in primary storage pool TAPEPOOL, you could issue the following command RESTORE STGPOOL TAPEPOOL 4. Issue the following command and wait for the background process to complete DELETE RECLAIM This command deletes any files that could not be restored in the previous step. 5. Issue the following command CLEANUP RECLAIM * Where can I get more detailed information about the utilities? A detailed document describing the utilities is available in the PTF readme file. For your convenience, this document is provided below. * Where can I get more information about how to use the SQL SELECT command? The detailed utilities document provides additional examples of SQL queries for obtaining information about affected files. This document is provided below. Documentation for Reclaimation Utilities ---------------------------------------- Following information was updated July 1998 >>> In early 1998, ADSM Development discovered and reported a problem with data movement/reclamation processing on Version 3 servers. Subsequently, Development distributed a set of utilities that could be used by ADSM customers to identify and handle client files that may have been affected by this error. Please refer to information APAR II11170 to determine whether the utilities should be run to deal with files affected by this error. In July 1998, the utilities were modified to cover APAR IX79165. This APAR involves a problem which allows aggregate reconstruction to produce files with an incorrect size. The utilities now identify client files that have been affected by this problem. The updated utilities are able to detect ALL files affected by IX79165, regardless of how many reconstructions might have been performed. To date, IX79165 has only been observed on AIX Version 3 servers; however, we recommend that the updated utilities be run on all Version 3 servers as a precautionary measure. The modified utilities include an audit with two modes of operation. The first mode is the 'complete' mode or normal mode. This mode should be used by customers who should run the utilities for the original data movement/reclamation problem (see APAR II11170), but have not yet done so. The updated utilities in this mode will examine all client files for problems referenced in both II11170 and IX79165. The second mode is the 'abbreviated' mode and should be used by customers whose servers are not affected by the problem described in II11170 or who have already run the utilities to manage files affected by this problem. The abbreviated audit will typically run faster than the complete audit. Please see the section titled 'AUDIT RECLAIM COMMAND' for the syntax and an explanation of the two audit modes. All other commands described in this document are the same regardless of which audit mode is used. Important note to customers who have begun using the utilities without the July 1998 update, but have not yet finished running the entire set of utilities: If you have not already applied this PTF, please finish running the entire set of utilities (including the CLEANUP RECLAIM command) to completion before applying the PTF; you can then apply this PTF and run the updated utilities using the MODE=ABBREV option. Alternatively, if you have already applied this PTF, you should run the updated audit with the MODE=COMPLETE and FORCEREANALYSIS=YES options. The remainder of this document describes the utilities that are provided to assist an administrator in managing client files affected by both II11170 and IX79165. <<< End of July 1998 update Problem Description ------------------- ADSM Version 3 introduced a new storage mechanism to improve performance and reduce overhead. During client backup and archive operations, small files are automatically packaged into larger objects, called "aggregates," for management on the ADSM server. As expiration deletes files from the server, vacant space can develop within aggregates. For data stored on sequential media, this vacant space is removed during reclamation processing. The procedure for removing vacant space within aggregates during reclamation is called "reconstruction," because it entails rebuilding an aggregate without the empty space. ADSM Development recently discovered an error in the Version 3 server that can result in invalid data after an operation in which data is moved/copied from a sequential-access storage pool volume. Initially, it was believed that this error occurred only during reconstruction of file aggregates. Accordingly, updated servers were made available to prevent the problem by temporarily disabling reconstruction of aggregated files during reclamation processing. Subsequently, ADSM Development determined that the problem can actually be introduced during other operations in which files are moved or copied from sequential-access volumes on a Version 3 server. These operations include o Reclamation o Move data from a sequential-access volume o Migration from a sequential-access storage pool o Backup of a sequential-access storage pool o Restore volume or restore storage pool from a copy storage pool The error can potentially affect backup, archive, or space-managed files on Version 3 servers, including files that were initially stored on a Version 1 or Version 2 server and later move/copied from a sequential-access volume on a Version 3 server. Many customers initially store files in a disk storage pool and back up the files to a copy storage pool before allowing the files to migrate to a sequential-access pool. In this scenario, both copies of the file are valid at the time of the storage pool backup. If either the primary or copy pool file later becomes affected by one of the operations listed above, it is likely that the other copy still contains valid data. Please see APARs IX74458 and IX76734 for information about the data movement/reclamation problems and APAR II11170 for information about the specific Version 3 server levels that are affected. ATTENTION: Using export and import to transfer file data from one server to another may result in transfer of files that have invalid data due to data movement/reclamation on the source server. These problem files would not be detectable on the target server. We recommend that export and import not be used to transfer file data among Version 3 servers until you have finished using the utilities to manage the data move/reclamation problem. Overview of Reclaimation Utilities ---------------------------------- The utilities obtain the information they need from the ADSM database. They do not access files in the ADSM storage hierarchy, and therefore do not require mounting of storage pool volumes. The following utilities are provided o An AUDIT RECLAIM command checks the ADSM database for logical files that may be affected by this problem and stores information about those objects in a RECLAIM_ANALYSIS table. o After the audit, the RECLAIM_ANALYSIS table can be queried using the SELECT command. It may be possible to restore valid copies of these files from a copy storage pool. Alternatively, the files can be restored/retrieved to the client for examination or they can simply be deleted. o A DELETE RECLAIM command can be used to delete logical files in the RECLAIM_ANALYSIS table from the ADSM database. For backup files that still exist on the client machine, the next incremental backup should then store a new copy of the deleted file on the ADSM server. o A REMOVE RECLAIM command allows you to delete the entry for an individual logical file from the RECLAIM_ANALYSIS table. Optionally, the file itself can be deleted from the ADSM server database. o A CLEANUP RECLAIM command deletes all entries from the RECLAIM_ANALYSIS table and reactivates reconstruction processing (if reconstruction has previously been disabled). The utilities are the only dependable way to identify files that are affected by this problem. In general, the AUDIT VOLUME command does not detect affected files and may actually undermine the utilities by marking files as undamaged that have previously been marked damaged by the utilities. Once you begin using the utilities by issuing the AUDIT RECLAIM command, you should not use the AUDIT VOLUME command until you have completed analysis of this problem and have run the CLEANUP RECLAIM command. ATTENTION: Do not run the CLEANUP RECLAIM command until you have handled all files that are suspected to contain errors. Once you issue the CLEANUP RECLAIM command, you will not be able to use the other utilities. HOW THE AUDIT WORKS ------------------- The audit utility works by examining information about physical files (aggregates and non-aggregates) in the ADSM database. By analyzing this file information, the audit identifies physical files that have been affected by the data movement/reclamation problem and determines which logical files have invalid data. When it detects such a logical file, the audit stores information about the file in the RECLAIM_ANALYSIS table for use by the other utilities. In most cases, the audit can determine with certainty whether a particular logical file is affected. However, there are situations, described in the following paragraphs, in which detection of problem files may be inaccurate or impossible. The audit detects all aggregates that have data errors because of the LAST reconstruction procedure for that aggregate. However, if an aggregate has been reconstructed more than one time, the analysis cannot determine whether the aggregate was affected during a previous reconstruction. As described in the next section, the audit provides an option for identifying files that may be affected by multiple reconstructions. If problem files are transferred from one Version 3 server to another using export/import, any problem files that existed on the source server would not be detectable on the target server. If an HSM client has migrated a file to the server and that same file is later backed up or archived, the backup/archive copy is created by duplicating the space-managed file that is already stored on the server. Even if the space-managed file is valid, it is possible that the new backup/archive could be invalid if a data movement problem occurs during duplication operation. In this situation, the invalid backup/archive file would not be detected by the audit. This situation should not occur commonly, since the default value for the MIGREQUIRESBKUP management class attribute is YES, meaning that the backup copy must exist before a file can be migrated from an HSM client to the server. Dealing with Possible Multiple Reconstructions ---------------------------------------------- In almost all cases, the audit can definitively detect logical files that are affected by the data movement/reclamation problem. However, the server does not have enough information to determine which aggregates have been reconstructed more than one time (during separate reclamations) and which of these aggregates might have incurred a problem during a reconstruction other than the most recent. Because of this uncertainty, the AUDIT RECLAIM command provides a LASTONLY option that allows the administrator to specify how the audit should handle the possibility of multiple reconstructions of the same aggregate. The default option, LASTONLY=YES, for the AUDIT RECLAIM command causes the audit to ignore the possibility of errors from reconstruction operations other than the most recent. With this option, the audit identifies logical files that were affected by data movement/reclamation operations other than reconstruction and creates an entry in the RECLAIM_ANALYSIS table for each of these logical files; each of these entries is assigned a category of DEFINITE, meaning that the file is definitely affected by the problem. With this option, the audit also identifies logical files that were affected by the last reconstruction and categorizes these logical files as DEFINITE in the RECLAIM_ANALYSIS table. However this option does not report any aggregates that contain invalid data because of reconstruction operations prior to the most recent reconstruction. You can also specify LASTONLY=NO when you run the AUDIT RECLAIM command. If you do this, the audit identifies the same logical files that would be identified with the LASTONLY=YES option, and categorizes these logical files as DEFINITE in the RECLAIM_ANALYSIS table. In addition, the LASTONLY=NO option identifies any logical files that might have been affected by earlier reconstructions and stores information about these files in the RECLAIM_ANALYSIS table with a category of POSSIBLE. Because the server does not have enough information to absolutely determine which logical files were affected by earlier reconstructions, it makes a set of worst-case assumptions. The result is that AUDIT RECLAIM LASTONLY=NO will identify all logical files that could possibly have been affected by multiple reconstructions. However, most of the logical files so identified will not have errors. If you use this option, the number of logical files categorized as POSSIBLE will be MUCH larger than the number of logical files categorized as DEFINITE. Handling Problem Files ---------------------- The AUDIT RECLAIM command also provides an EXAMINECOPIES option that allows you to specify what should be done when definite or possible problem files are identified. With the default option, EXAMINECOPIES=NO, suspect logical files are merely entered in the RECLAIM_ANALYSIS table and given a state of IDENTIFIED. This option should be used if you have NOT been using the BACKUP STGPOOL command to back up your storage pool data. You can also specify an option, EXAMINECOPIES=YES, that causes the audit to look for additional copies of any primary physical file with a definite or possible error; by doing so, the audit may locate a copy that is not affected by the problem. In searching for copies of aggregates, the server uses the criteria dictated by the LASTONLY parameter discussed above. The EXAMINECOPIES=YES option should be used if you intend to restore affected primary files for which a good copy exists. When the EXAMINECOPIES=YES option is used, additional processing described below is performed when a definite or possible problem file is found. This processing causes the audit to run longer, but may allow files to be regenerated from good copies in other storage pools using the normal storage pool backup and storage pool restore operations. If EXAMINECOPIES=YES is used and a physical file with definite or possible problems is detected, the server's response will depend on whether the affected file is a copy, cached, or primary file. If a physical file in a copy storage pool is found to contain invalid data, the copy is deleted. Similarly, if a cached copy has errors, the cached copy is deleted. Deletion of a copy pool file or cached file does not affect the corresponding primary physical file. If a primary physical file is found to have a possible or definite error, the server checks for an unaffected copy of the physical file in a copy storage pool. If a good copy is found, the entire primary physical file is marked as "damaged" and can later be restored using the RESTORE STGPOOL command. For such physical files, an entry in the RECLAIM_ANALYSIS table is also created for each possible or definite problem logical file. The entry records the state of the logical file as MARKED_DAMAGED, indicating that the corresponding physical file has been marked as damaged. If a primary physical file contains invalid data and the server is unable to locate a copy that is unaffected by the problem, an entry in the RECLAIM_ANALYSIS table is created for each possible and definite problem file in the physical file. In this case, the entry records the state of these logical files as IDENTIFIED. AUDIT RECLAIM Command --------------------- This command analyzes the database and identifies logical files that are suspected to contain invalid data as a result of the Version 3 data movement/ reclamation problem. For each such logical file, information is stored in the RECLAIM_ANALYSIS table for later processing. This command runs as a background process that can be cancelled with the CANCEL PROCESS command. You can display information about this process using the QUERY PROCESS command. IMPORTANT: The AUDIT RECLAIM command can yield inaccurate or incomplete results if it executes at the same time as certain other processes. To avoid this situation you must make sure that the following operations are not performed while the AUDIT RECLAIM command is running. Inventory expiration Storage pool migration Reclamation of sequential volumes MOVE DATA command BACKUP STGPOOL command RESTORE STGPOOL command RESTORE VOLUME command DELETE FILESPACE command DELETE VOLUME with DISCARDDATA=YES AUDIT VOLUME If you cancel the audit process, it can be restarted and will resume where it left off during the previous audit. This allows you to interleave audit processing with other server operations. However, if you run AUDIT RECLAIM with the EXAMINECOPIES=YES option, you should not use the AUDIT VOLUME command until you have run the CLEANUP RECLAIM command. If you do so, the AUDIT VOLUME command may mark files as undamaged that have already been marked damaged by the AUDIT RECLAIM command. For more information regarding this command, read the previous section entitled "HOW THE AUDIT WORKS." Privilege Class: Requires system privilege. Syntax: AUDit RECLAIM |--FORCEreanalysis=No---| |--LASTonly=Yes--| AUDit RECLAIM >---------------------------------------------> |--FORCEreanalysis=Yes--| |--LASTonly=Yes--| |--FORCEreanalysis=No--| |--LASTonly=No--| |--EXAMinecopies=No---| |--MODE=COMPlete--| >------------------------------------------------< |--EXAMinecopies=Yes--| |--MODE=ABBRev--| |--EXAMinecopies=No---| |--MODE=COMPlete--| Parameters FORCEreanalysis=forcevalue Indicates whether information from a previous reclaim audit should be discarded and the audit repeated. This parameter is optional. The default value is NO. Yes Specifies that previous reclaim audit results will be deleted from the database and a new audit will be started. Database information on logical files with possible or definite errors will be discarded and regenerated by auditing all physical files again. No Specifies that if a reclaim audit has previously been performed, the existing audit results will be preserved. This allows a previous audit, which was cancelled or which failed before completion, to be resumed without the need to audit physical files that have already been audited. To avoid inconsistent data in the RECLAIM_ANALYSIS table, if you resume a previous reclaim audit, you should use the same choices for the LASTONLY and EXAMINECOPIES parameters as were used during the previous audit. LASTonly=lastvalue Specifies whether the audit should consider reconstruction operations prior to the most recent reconstruction for each aggregate. This parameter is optional. The default value is YES. Yes Specifies that the audit will only consider the most recent reconstruction of each aggregate. With this option, logical files that were affected by data movement/reclamation operations other than reconstruction will be entered in the RECLAIM_ANALYSIS table with a category of DEFINITE. Logical files that have invalid data from the last reconstruction procedure will also be entered in the RECLAIM_ANALYSIS table with a category of DEFINITE. This option will not detect logical files that have invalid data from earlier reconstructions. No Specifies that the audit should consider the possibility that aggregates may have been reconstructed more than one time. With this option, the audit will identify files that definitely have invalid data from the last reconstruction procedure or which were affected by other data movement/reclamation operations; these logical files will be entered in the RECLAIM_ANALYSIS table with a category of DEFINITE. A worst-case set of assumptions will also be used to identify files that could have invalid data from earlier reconstructions; these files will be entered in the RECLAIM_ANALYSIS table with a category of POSSIBLE. With this option, the audit will identify all logical files that could possibly be affected by the reconstruction problem, but most of the logical files categorized as POSSIBLE will not actually have invalid data. EXAMinecopies=examinevalue Specifies whether the audit should examine other copies of physical files that have invalid data. This parameter is optional. The default value is NO. Yes Specifies that the audit will examine other copies of any physical files that it identifies as having possible or definite errors. A detailed description of this option is provided in the section entitled "Handling Problem Files." This option marks affected primary physical files as damaged if a restorable copy can be found. You should not use this option unless you intend to restore the damaged files using the RESTORE STGPOOL command. No Specifies that the audit will not examine other copies of any physical files that it identifies as having possible or definite errors. The logical files in the affected physical file will be entered in the RECLAIM_ANALYSIS table with a state of IDENTIFIED. Following information was added July 1998 >>> MODE=mode Specifies the mode in which the audit will be run. This parameter is optional. The default value is COMPLETE. COMPlete Specifies that the audit will be run in complete mode. This mode should be used on servers that may be affected by the original data movement/reclamation problem (see APAR II11170) unless the utilities have already been run to completion. When run in complete mode, the audit will examine all client files for problems referenced in both II11170 and IX79165. ABBRev Specifies that the audit will be run in abbreviated mode. This mode should be specified if server is not affected by the original data movement/reclamation problem (see APAR II11170) or if the utilities have already been run to deal with this problem. When the audit is run in abbreviated mode, it checks only for the error IX79165. In abbreviated mode, the audit only examines aggregates and will typically run faster than in complete mode. NOTE: Options MODE=ABBREV and LASTONLY=NO cannot both be specified, since the abbreviated audit checks for an error that can be detected even if multiple reconstructions have been performed. <<< End of July 1998 addition NOTE: Options LASTONLY=NO and EXAMINECOPIES=YES cannot both be specified, since this combination would result in deleting copy pool files and marking primary files as damaged, even though these files only have possible errors. VIEWING AUDIT RESULTS --------------------- The SQL SELECT query can be used to display the contents of the RECLAIM_ANALYSIS table. The SQL language provides a high degree of flexibility in sorting, consolidating and analyzing the contents of the table. For detailed analysis, you may want to refer to a book or manual on the SQL SELECT language. Some very brief examples will be used below to illustrate the functions that can be performed. The information in the RECLAIM_ANALYSIS table is also accessible through the ADSM ODBC driver for analysis with product such as Lotus Approach or Microsoft Access. Each row in the RECLAIM_ANALYSIS table represents a client file that has been identified by the AUDIT RECLAIM process. The following columns, or fields, are defined for each file. Information about these columns can also be displayed using the following SQL query: SELECT * FROM COLUMNS WHERE TABNAME='RECLAIM_ANALYSIS' Columns in the RECLAIM_ANALYSIS table ------------------------------------- CATEGORY Identifies the degree to which the audit has determined that the file is affected by the data movement/reclamation problem. This column can have one of two possible values. A value of 'DEFINITE' is associated with files that are certain to contain invalid data. A value of 'POSSIBLE' is associated with files that are not known to have invalid data, but which may have been affected by reconstruction operations other than the most recent. NODE_NAME Identifies the name for the client node from which the file was backed up, archived, migrated. FILESPACE_NAME Identifies the name of the filespace on the client to which the file belongs. ENTRYTYPE Identifies the type of file on the server. This column can have one of three possible values: 'Archive' - indicates that the object was archived from the client 'Backup(Active)' - indicates that this copy is the latest backup copy that was sent from the client (the ACTIVE backup copy) 'Backup(Inactive)' - indicates that this is an inactive backup copy of the object 'Space Managed' - indicates that the file was migrated from an HSM client HL_NAME Identifies the high-level name for the client object LL_NAME Identifies the low-level name for the client object OBJTYPE Identifies the type of object. Two possible values can be displayed for this column: 'FILE' - the object is a client file 'DIR' - the object is a client directory ID Specifies the identifier for the client file. This identifier can be used to remove individual files with the REMOVE RECLAIM command. AUDIT_STATE Identifies the audit state for the object. This column can have one of two possible values: 'Marked Damaged' - indicates that the object was marked damaged during the audit process because an unaffected copy can be restored using the RESTORE STGPOOL command. 'Identified' - indicates that the object was identified but not marked damaged during the audit Example Queries --------------- This section will illustrate how the SQL SELECT statement can be used to obtain information about client files identified by the AUDIT RECLAIM process. The SQL SELECT command can be issued from any administrative command line client. It cannot be issued from the server console. The general format for a simple SELECT query is the following: SELECT columnlist FROM RECLAIM_ANALYSIS The columnlist is a comma-separated list of the columns that should be displayed from the descriptions above. An asterisk (*) can be used to indicate that all columns should be displayed in the order defined above. Other 'aggregate' functions can also be specified. Please refer to your SQL documentation for more details. A predicate may involve a comparison or evaluation based on column contents to determine which rows are to be displayed from the table. The examples below should clarify the basics. The simplest command displays all columns and all rows in the RECLAIM_ANALYSIS table: SELECT * FROM RECLAIM_ANALYSIS To display all rows that contain information on files that are definitely affected by the data movement/reclamation problem, the following query could be used: SELECT * FROM RECLAIM_ANALYSIS WHERE CATEGORY='DEFINITE' To display the filespace name, high-level name, and low-level name for each ARCHIVE file belonging to node SMITH that was definitely affected by the data movement/reclamation problem, the following query could be used: SELECT FILESPACE_NAME,HL_NAME,LL_NAME FROM RECLAIM_ANALYSIS WHERE CATEGORY='DEFINITE' AND NODE_NAME='SMITH' To display all archive or active backup files that were identified by the audit, the following query could be used: SELECT NODE_NAME,FILESPACE_NAME,HL_NAME,LL_NAME FROM RECLAIM_ANALYSIS WHERE ENTRYTYPE='Archive' or ENTRYTYPE='Backup(Active)' To display a count of the files that are definitely affected by the problem, the following query could be used: SELECT COUNT(*) FROM RECLAIM_ANALYSIS WHERE CATEGORY='DEFINITE' To display a count of the files that were POSSIBLY affected by a reconstruction, the following query could be used: SELECT COUNT(*) FROM RECLAIM_ANALYSIS WHERE CATEGORY='POSSIBLE' DELETE RECLAIM Command ---------------------- This command is used to delete logical files stored on the server that may have errors due to the data movement/reclamation problem. These files must have been previously identified using the AUDIT RECLAIM command. Logical files are deleted only if they have an entry in the RECLAIM_ANALYSIS table and satisfy the filter criteria specified for the DELETE RECLAIM command. Once the files have been deleted, clients will no longer be able to access these files using ADSM. Deletion of active backup files for a client will cause the files to be backed up again during the next incremental backup operation for that client, provided that the files still reside in the client's file system. As logical files are deleted from the server, the corresponding entries in the RECLAIM_ANALYSIS table are also deleted. If the DELETE RECLAIM command processes a file whose state is MARKED_DAMAGED and the corresponding primary physical file is no longer marked damaged, the deletion process removes the entry from the RECLAIM_ANALYSIS table, but does not delete the logical file. In such a situation, the delete process assumes that the physical file has been restored from a copy storage pool and now contains valid data. To determine which files will be deleted if this command is issued, you should use the equivalent SELECT command to view information about the files you plan to delete. The command generates a background process that can be queried with the QUERY PROCESS command. The command can be cancelled with the CANCEL PROCESS command. Privilege Class: Requires system privilege. Syntax: DELete RECLAIM ---nodename-----------------------------------> |--FILESpace=filespacename--| |--FILEType=ALl-----------| |--CATegory=DEFINITE--| >-----------------------------------------------------------> |--FILEType=ALl-----------| |--CATegory=ALl-------| |--FILEType=ARchive-------| |--CATegory=DEFINITE--| |--FILEType=Backup--------| |--CATegory=POSSible--| |--FILEType=BACKUPActive--| |--FILEType=ALLActive-----| |--FILEType=INactive------| |--FILEType=SPacemanaged--| |--STate=IDENTified-----| >----------------------------+ |--STate=ALl------------| |--STate=IDENTified-----| |--STate=MARKEDdamaged--| nodename Specifies a list of client node names for which files are to be deleted. The items in the list are separated by commas, with no intervening spaces. Pattern-matching expressions can be used to specify the names. This parameter is required. FILESpace=filespacename Specifies a list of filespaces for which files are to be deleted. The items in the list are separated by commas, with no intervening spaces. Pattern-matching expressions can be used to specify the names. This parameter is optional. If not specified, files for all filespaces are deleted. FILEType=type Specifies the type of logical files that should be deleted. This parameter is optional. The default value is ALL. ALl Specifies that archive and backup files with entries in the RECLAIM_ANALYSIS table should be deleted. Space-managed files are not deleted. ARchive Specifies that only archived files should be deleted. Backup Specifies that only backup versions, whether active or inactive, should be deleted. BACKUPActive Specifies that only active backup versions should be deleted. ALLActive Specifies that all archive copies and active backup versions should be deleted. Space-managed files are not deleted. INactive Specifies that only inactive backup versions should be deleted. SPacemanaged Specified that only space-managed files should be deleted. CATegory=category Specifies the category of logical files that should be deleted. This parameter is optional. The default value is DEFINITE. ALl Specifies that files with all categories should be deleted. DEFINITE Specifies that only files with a category of DEFINITE should be deleted. These are files that are known to contain invalid data. POSSible Specifies that only files with a category of POSSIBLE should be deleted. These are files that do not contain known errors but which could contain invalid data due to a reconstruction operation other than the last reconstruction, should the aggregate have been reconstructed more than once. STate=state Specifies the state of logical files that should be deleted. This parameter is optional. The default value is IDENTIFIED. ALl Specifies that files with all states should be deleted. However, files with state of MARKED_DAMAGED are not deleted unless the primary physical file is still marked damaged. IDENTified Specifies that only files with a state of IDENTIFIED should be deleted. These are files that were identified, but not marked damaged, during the reclaim audit. MARKEDdamaged Specifies that only files with a state of MARKED_DAMAGED should be deleted. These are files that were marked damaged during the reclaim audit because they can be restored using the RESTORE STGPOOL command. These files are not deleted unless the primary physical file is still marked damaged. If you are not using the BACKUP STGPOOL command to make backup copies of your files, or if you used EXAMINECOPIES=NO on the AUDIT RECLAIM command, you will not have any files in the RECLAIM_ANALYSIS table in this state. REMOVE RECLAIM Command ---------------------- This command is used to remove the entry for a single client file from the RECLAIM_ANALYSIS table. The table entry must have been created during a previous AUDIT RECLAIM operation. Optionally, this command also deletes all other references to the logical file from the server. Privilege Class: Requires system privilege. Syntax: |--DELObject=No---| REMove RECLAIM --identifier----------------------+ |--DELObject=No---| |--DELObject=Yes--| Parameters: identifier Specifies an identifier for the file to be removed from the database. This identifier can be obtained by using the SELECT command to view the contents of the RECLAIM_ANALYSIS table. The identifier consists of two numeric parts, separated by a period. This identifier is obtained from the ID column in the RECLAIM_ANALYSIS table. DELOject=value Specifies whether the object should be removed from the server. This parameter is optional. The default value is NO. No Specifies that the entry for the specified object will be removed from the RECLAIM_ANALYSIS table, but the object itself will not be deleted from the server. Yes Specifies that the specified object will be deleted from the server, and its entry will be removed from the RECLAIM_ANALYSIS table. CLEANUP RECLAIM Command ----------------------- This command is used to remove the RECLAIM_ANALYSIS table that was created by the AUDIT RECLAIM command. This command should only be issued if you are satisfied with the recovery actions that you have taken, and do not plan to execute any other reclaim analysis utilities. Once you issue the CLEANUP RECLAIM command, you will not be able to run the other reclaim analysis utilities. The command generates a background process that can be queried with the QUERY PROCESS command. The command can be cancelled with the CANCEL PROCESS command. Privilege Class: Requires system privilege. Syntax: CLEANup RECLAIM------< Possible Procedure for use of Utilities --------------------------------------- Various approaches can be used to manage files that may be affected by the data movement/reclamation problem. The utilities described above can be used to identify files with invalid data so that as many files as possible can be handled using normal storage pool backup and restore operations. Following is a possible procedure for resolving the data movement/reclamation problem: 1) Install this corrective level of the ADSM Server on your server platform. 2) Decide whether you want the audit to ignore the possibility of errors from reconstruction operations other than the most recent reconstruction for each aggregate. In making this decision, consider factors such as how often files are deleted through expiration, whether it is likely that the same data could have been reclaimed multiple times, and how critical it is to identify every logical file that could possibly be affected by reconstruction errors. Also keep in mind that a server fix was provided to disable reconstruction in late January; if your Version 3 server usage prior to applying this fix was minimal, your exposure to possible reconstruction errors should be low. These considerations should help you to select the value of the LASTONLY option for the AUDIT RECLAIM operation. In most cases, the default option of LASTONLY=YES should be used to avoid identifying an unmanageable number of files with possible reconstruction errors. 3) Decide whether you want the audit to merely identify logical files affected by the problem or whether it should examine other copies that might not be affected. Consider whether your primary storage pools are backed up to one or more copy storage pools, whether the backup is usually performed from a disk or a sequential-access pool, and the feasibility of obtaining copy pool tapes from an offsite location. These considerations should help you to select the value for the EXAMINECOPIES option for the AUDIT RECLAIM operation. 4) Use the AUDIT RECLAIM command to audit physical files stored on your server. If errors occur or if the audit has to be cancelled, the audit can be continued from the point at which it left off. 5) Use the SQL SELECT query on the RECLAIM_ANALYSIS table to determine which files may have been affected by the problem. 6) If you have used the EXAMINECOPIES option, restore your primary storage pools to replace physical files that have been marked as damaged. Then use normal storage pool backup to create new copies of any physical files that were deleted from your copy storage pools. 7) Issue the following command to delete backup files with entries in the RECLAIM_ANALYSIS table. This command deletes all backup files that were not successfully restored with the RESTORE STGPOOL operation. For files that are deleted, incremental backup will again store those files that still reside on the client. DELETE RECLAIM STATE=ALL FILETYPE=BACKUP 8) For remaining files in the RECLAIM_ANALYSIS table, attempt to locate the files on the client or retrieve the files and examine the file for possible errors. If the original file still resides on the client, store it again to the server. Otherwise, we recommend that you do not delete it from the server because the whole file may not have been affected, or the file may not be affected at all (e.g., if the file is in the POSSIBLE category). 9) When you are satisfied with the action you have taken to recover from this error, use the CLEANUP RECLAIM command to remove all entries from the RECLAIM_ANALYSIS table. This command also reactivates aggregate reconstruction, if it has been disabled. When in doubt, please contact your service representative for assistance with these procedures. ------------------------------------ Clarification of fix to APAR IX79626 ------------------------------------ Service aids "delete archd " and "delete object force=yes" and online and offline audit tools were provided in service level 3.1.2.0. The root cause of the problem, serialization, is fixed by this PTF. It has been recently discovered that the audit tools are not working properly. The fix was not available in time to meet the delivery date for this PTF so both the online and offline audit tools have been disabled. ---------------------------------------------- Change to MOVE DRMEDIA and MOVE MEDIA Commands ---------------------------------------------- While moving volumes from the MOUNTABLE state with REMOVE=YES specified, MOVE DRMEDIA and MOVE MEDIA commands will now utilize more than one slot in the CAP for an STK library with ACSLS. ------------------ SSI Initialization ------------------ If you are using the STK Silo with ADSM and your system is setup so that both ADSM and the ACSLS client daemon (SSI) are automatically started when the system is re-booted, you may notice the message "STATUS_IPC_FAILURE". This message will occur when ADSM attempts to contact the ACSLS server via the SSI client and the SSI daemon has not finished its initialization. This message does not indicate a failure in the ADSM library initialization if retry is successful in two minutes. Relief from the issuance of this message may be obtained by changing the position of the entry in /etc/inittab for starting the SSI daemon with respect to the autostart entry for ADSM server. The steps below will move the entry for the ACSLS daemon so that it is started sooner than the ADSM server. You must issue the following commands as the root user. 1. Remove the entry for the ACSLS daemon rmitab autoacs 2. Add the entry for the ACSLS daemon so that it is invoked just before the entry to start the AIX Windows Desktop Login mkitab -i dt "autoacs:2:once:"/usr/adsm.devices/bin/rc.acs_ssi quiet >/dev/console 2>&1" Note: If you do not have the AIX Windows Desktop installed you will have to choose another entry. You can list the entries in your /etc/inittab file with the command lsitab -a. You should choose an entry with a wait action to give ACSLS as much time as possible to initialize before the ADSM server is started. (TCP/IP and NFS should be started before starting ACSLS.) ------------------------------- Accounting Environment Variable ------------------------------- This service level introduces a new environment variable on the UNIX platforms ( NT already supports this function through a registry key ). The environment variable is DSMSERV_ACCOUNTING_DIR. It is used to specify a directory in which the accounting file is opened; The accounting file is always dsmaccnt.log. The variable is supported to allow customers running multiple servers on the same machine to keep separate accounting files for each server. If DSMSERV_ACCOUNTING_DIR does not exist when the server is started, the current directory is used for the accounting file. If it does exist, the directory name specified is used for the file. Example: ( AIX Korn Shell ); EXPORT DSMSERV_ACCOUNTING_DIR=/u/test/servera ./dsmserv If accounting is on, the server will open file /u/test/servera/dsmaccnt.log ----------------------------------- APARS fixed by prior service levels ----------------------------------- APARS Fixed prior to Service Level 3.1.2.20 ------------------------------------------- IX79245 DSMSERV AUDITDB PARAMETERS ARE NOT WORKING AS DOCUMENTED FILE=xx parameter on DSMSERV AUDITDB not directing output to V2 file. IX79248 SESSION NUMBER GREATER 99999 WILL NOT BE DISPLAYED PROPERLY IX75336 SELECT OCCUPANCY ... OUTPUT DOES NOT MATCH QUERY OCCUPANCY OUTPUT The SQL SELECT FROM OCCUPANCY does not display filespace information correctly for nodes with multiple filespaces. IX74446 Server incorrectly reporting missed schedules ANR2478I MESSAGE IS GENERATED WHEN THE SCHEDULE DOESN'T FINISH WITHIN START WINDOW. THIS MESSAGE SHOULD ONLY BE ISSUED IF SCHEDULE HAS NOT STARTED WITHIN START WINDOW. IX75715 Tivoli event receiver needs hostname slot ADSM did not pass the HOSTNAME slot to Tivoli. IX75962 Excessive ANR8216W messages with Tivoli event logging The Tivoli event receiver did not properly detect when the Tivoli event server went down. IX76138 QUERY SESSION hangs the server when it has much output When issuing a QUERY SESSION command from an admin client, and the number of sessios is so large that the entire output from the command cannot fit in a single buffer (over 150 sessions), the server can hang due to deadlock contention of the Session Mutex. IX76147 WEB ADMIN DOES NOT SEE DEFINED DRIVES, AND IN CUSTOMER'S CASE, HIS 3494 LIB. SQL queries and Web Admin pages return Not Found instead of no space available when there is insufficient database space for SQL temporary tables. This will occur when a Q DB shows 0 in the Maximum Reduction field. IX76494 Archive performance degredation archive query/retrieve performance is degraded from V2 IX76472 SELECT * FROM VOLUMEUSAGE DOES NOT LIST ALL VOLUMES WHICH CONTAIN DATA. entries are missing from 'select * from volumeusage' output IX76739 ANR2751I ISSUED WHEN ANR2756I IS APPROPRIATE IX76854 OPTICAL SUPPORT. DUE TO BAD SECTOR OR HARDWARE RELATED ISSUES ADSM WILL NOT ACCESS REST OF THE FILES AND MARK THEM ALL BAD The problem is that any single I/O error from the drive on a read operation prevents any other access to that side of the platter until the platter is dismounted. This impacts the AUDIT VOL and MOVE DATA commands from being able to access otherwise good files on the platter because one file had a bad sector in it. IX77291 THE DRM -> PREPARE ICONS ON THE WEBADMIN WILL RECOGNISE ONLY THE FIRST STGPOOL GIVEN IN A LIST. The PREPARE panel for the Web administrative interface incorrectly displayed partial storage pool information in the COPYSTGPOOL and PRIMSTGPOOL fields. IX77477 AIX ADSM SRV 3.1. GETS ANR8355E,ANR8311E WHEN TRYS TO MOUNT THE STORAGE TEK (ACSLS 5.1.1) TAPES WITH HEADER TYPE 1. prelabelled tapes do not have the HDR2 which ADSM expects IX77638 ADSM ADMIN COMMANDS THAT DO NOT REQUIRE SPECIAL ADMIN AUTHORIZATION CAN BE ISSUED THROUGH WWW INTERFACT WITHOUT AUTHENTICATION. The '/HELP/' path link in the server URL for the WEB admin interface will allow non-administrators to issu query commands. Commands the require an ADSM administrative authority above GENERAL will fail. IX77714 TRYING TO RUN A SCRIPT THAT RUNS AN ADMIN SCHEDULE. WORKED IN V2 DOES NOT WORK IN V3. Cannot Schedule Device and Library related Administrative cmds. IX77766 QUERY OPTION doesn't show AUDITSTORAGE option NOAUDITSTORAGE OPTION DOES NOT APPEAR IN ADSM SERVER QUERY OPTION OUTPUT EVEN THOUGH PARM IS SPECIFIED IN DSMSERV.OPT IX77783 ANR9999D PSPURROPT.C 1049) OPTICAL DISK NOT VALID FOR THIS PRODUCT RECEIVED WHEN RUNNING LABEL LIBVOL FOR OPTICAL PLATTER when ADSM labels an optical platter, it first tries to read the existing label to ensure that it is not being overwritten. If no existing label is found, the ANR9999 error message is issued, which is extraneous since this condition would be expected. IX77865 RESTORED FILE ACCOUNT IS WRONG IN ACCOUNTLOG. RESTORED WITH NO PROBLEM, BUT DISPLAYED "RESTORED FIL =ZERO". accounting info not updated for restored files IX78021 AFTER STARTING 'UPDATE DEVC' DURING 'QUERY CONTENT' WORKING , SERVER HANGS. IX78125 DSMFMT -G RESULTS IN OUT OF SPACE MESSAGE The GB value was processed incorrectly. IX78196 DB Dump was not dumping all pages When running the dumpdb comand, one or more of the following messages are issued: ANR9999D dldump.c(2361): Logical page xxx corrupted - data string packed structure invelid for record 0 IX78320 Unpredictable crash during Query Backup unpredictable core dump occurs during query backup IX78433 ANR9999D XIBF.C(1161):UNKNOWN RESULT CODE (23) FROM BFCREATE CAN BE A RESULT OF V3 SERVER FILLING UP DISK STGPOOL DURING IMPORT With a version 3 server when a disk storage pool becomes full during an import and didn't get the chance to migrate the data to tape, it will fail with ANR9999D XIBF.C(1161):UNKNOWN RESULT CODE (23) FROM BFCREATE. IX78702 QUERY CONTENT causes other commands to hang After starting 'update devc' during 'query content' working, server hangs, when 'query content' command take a big time to work (large output). After system waits (hangs) the message ANR0481W Session ??? for node ????? terminated - client did not respond within ?? seconds. After admin session with 'query content' command is terminated, then sessions with 'update devc', 'q devc' commands unhangs and worked properly. IX78829 Memory leak when creating mutexes (AIX Only) Every time a mutex is created in the server, an unspecified amount of memory is leaked. Over time this can cause excessive paging activity and/or server crash. IX79016 ADSM SRV 3101, AIX 4.2.1, DRIVE-POLLING THREAD DON'T MARKS THE DRIVE OFFLINE ADSM DB, ONLY IN DRIVE DESCRIPTOR. The problem occurs when a drive in the 3949 library has an error and ADSM begins to poll the drive. If the user marks the drive offline via the UPDATE DRIVE command, then when the polling thread finds out the drive is now accessible, the drive is marked online. However, the drive should still be marked offline according to earily commands issued. IX79165 ANR9999D AFERASE.C(493):INVALID LOGSIZERATIO INF Customer runs through RECLAMATION UTILITIES. Encountered errors on DELETE RECLAIM and later on RECLAMATION or EXPIRATION: ANR9999D aferase.c(493): Invalid logSizeRatio INF (logSize= 0.1240,size=0,0,aggrSize=0.21045) for aggregate 0.21279102 IX79191 REMOVE=BULK WILL NOT RETURN WITH AN INVALID OPTION WHEN USED WITH AN ACSLS LIBRARY. CHECKIN LIBVOL ... REMOVE=BULK ... is not supported by ACSLS libraries and should return an error if attempted. IX79350 SCHEDULER ISN'T PROCESSING 2/29/2000 CORRECTLY. Leap year not handled correctly for Y2K. IX79366 WHILE ADSM IS COMING UP, TAPES IN AN ACSLS LIBRARY SYSTEM WHICH ARE NOT FOUND WILL BE CHECKED OUT RESETTING THE 'LOCK' BIT. While ADSM is coming up, tapes in an ACSLS library system which are not found will be checked out resetting the 'lock' bit. By resetting the lock bit, we may be allowing the tape to be picked up by another application using the ACSLS library. IX79368 MAXSIZE ROUNDED FOR DISPLAY OF Q STGPOOL IX79394 ADSM SERVER CHECKIN LIBVOLUME SEARCH=YES AND LABEL LIBVOLUME SEARCH=YES CAUSE 3995 TO UNLOAD DRIVES FOR STATUS CHECKING the IES command that is issued by Checkin and Label commands with the search option causes any mounted volumes to be ejected from the drives IX79470 A WRITE PROTECTED TAPE IN AN ACSLS LIBRARY SYSTEM WILL BE REMOUNTED REPEATEDLY FOR SCRATCH OPERATIONS. A write protected tape in an ACSLS library system will be remounted repeatedly for scratch operations. Other tapes may be mounted durring this processing, as well, including a usable scratch tape being selected occationally. IX79566 Q ACTLOG WITH SEARCH OPTION DOESN'T DISPLAY ALL OCCURENCES OF THE STRING EXPRESSION ON 3.1.1.3 SERVERS. When doing a QUERY ACTLOG with SEARCH parameter, messages originating from clients or other servers were not always included. IX79579 ANR8449E WHEN TRYING TO MOUNT A SCRATCH VIRTUAL VOLUME. The name generation routine for scratch names was not appropriately checking to see if a volume by that name already existed. IX79727 EXPORT DOES NOT WRITE THE DATASET NAME IN THE HDR1 FIELD IF THE VOLUME HAS BEEN PREVIOUSLY USED BY ADSM The problem arises on the MVS side when importing data that was exported from a UNIX or NT. The error states that the data set name was incorrect. IX79815 AN ANR8311E I/O ERROR MESSAGE WITH RC OF 6 OR 28 IS ERRONEOUSLY GIVEN WHEN THE VOLUME BECOMES FULL AND END OF TAPE IS REACHED ADSM erroneously generates an: ANR8311E AN I/O ERROR OCCURRED WHILE ACCESSING DRIVE FOR WRITE OPERATION; ERRNO = 6 (or ERRNO=28) ANR8341I - END OF VOLUME REACHED FOR VOLUME . when using a library defined with LIBTYPE=EXTERNAL and the volume becomes full (i.e. reaches the end of media/end-of-tape/ EOT). This message sequence is not indicative of a true error. IX79974 IF A MOVE FROM DISK OPERATION IS CANCELED OR PREEMPTED, ADSM COULD ABEND WITH A TMTXN008 An abend can at time occur during the movement of data from a disk storage pool to another pool and a cancel is issued or the operation is preempted. This problem is more likely to happen if I/O errors are experienced and the move operation is retrying the move. IX80345 WHEN USING THE SQL SELECT STATEMENT WITH ORDER BY PARM AND THERE IS MORE THAN ONE COLUMN DISPLAYING DECIMAL,INTERVAL OR DATETIME SQL queries using the order by clause, with more than one column with decimal, date/time or interval data can have incorrect data displayed. IX80431 WEB ADMIN INTERFACE DOES NOT DISPALY OBJECTS FIELD INFORMATION IF MULTIPLE SET OS QUOTES ARE USED. Strings that contain double quotes (") do not preserve the double quotes when entered from the Administrative WEB interface. An example is the objects/options fields in the DEFINE/UPDATE schedule command. IX80461 DRIVER FOR 7206-110 12 GIG TAPE DRIVE Drive fails to configure using adsm driver but will configure using the native AIX driver. IX80531 ADSM DOESN'T RETURN AN ERROR WHEN THE MOVE MEDIA COMMAND AND CHECKLABEL=NO OPTION ARE USED TOGETHER. The users use an undocumented parameter CHECKL with the MOVE MEDIA command. If CHECKLABEL, instead of CHECKL, is used with the MOVE MEDIA command, ADSM reports the error. IX80875 DOCUMENTATION UPDATE REQUEST TO INCLUDE -SERVERNAME OPTION IN LIST OF IGNORED OPTIONS FOR DEFINE SCHEDULE COPMMAND IX80940 ANR9999D PKSHMEM.C(310): INVALID ATTEMPT TO FREE MEMORY: CALLED FROM 10201E54 (CSQUERYEVENT). Specifying "Query Event * type=admin nodes=" leads to attempts to free memory which has not yet been obtained. The use of type=admin and nodes= is not compatible. IX81008 IF A TIVOLI SERVER GOES DOWN AND IS BROUGHT BACK UP ADSM NO LONGER CAN COMMUNICATE WITH IT. TIVOLI went down, and ADSM did not attempt to reconnect and continue sending events to the TIVOLI Event Console. IX81130 TCP/IP IS CLOSED WHEN ERROR NUMBER 72 IS RECEIVED FROM TCP/IP If a session request is aborted in a very small window and ECONNABORTED is returned by AIX, the server will stop listening for TCP/IP sessions. IX77690 THE MESSAGE "ANRNNNNW UNABLE TO CLEAR THE LOG BELOW XX% OF THE TRIGGER VALUE. THE RECOVERY LOG IS NOW YY% FULL" SHOULD DISPLAY The server does not issue a message when running in roll-forward mode and a database backup does not clear the recovery log below the percentage specified by the database backup trigger. IX79262 HIGH CPU UTILIZATION DURING SCHEDULE MANAGER INITIALIZATION. When the ADSM server is starting, the schedule manager may take a long time to initialize if there is a large number of schedled events defined (i.e. lots of clients associated with one or more schedules). During schedule manager initialization, you may see one or more of these symptoms: - High CPU utilization - Clients will not be able to connect - No response to administrative commands Once the schedule manager starts (message "ANR2560I Schedule manager started.") ADSM will operate normally. IX76101 ADSM ADMIN GUI ERROR MESSAGE ANR2606E INVALID START DATE WHEN CODING 29/02/2000 IN THE START TIME BOX FOR SCHEDULED BACKUP Customer was doing year2000 testing and discovered that coding 29/02/2000 in the admin GUI schedule start time box caused ANR2606E invalid start date but 29/02 IS a valid date for year 2000. IX81433 VOLUME LOCATION FIELD ERASE BY SERVER LEVEL 3 . QUERY VOLUME F=D for cartridges reveal that the field LOCATION DIAPPEAR , after the cartridge has been used by server level 3. The volume was defined at server level 2 , and when its been use by server level 3 , the LOCATION field of the volume LOST. IX79264 DELETE MULTIPLE FILESPACES ANR0104E ARCHIVE.DESCRIPTIONS If the user deletes multiple filespace for a node at the same time, that is the deletes are running concurrently on the server, one of more of the delete filespace background threads may terminate with the following messages: . ANR0104E IMARINS(1301): Error .... deleting row from table "Archive.Descriptions". ANR0987I Process ... for DELETE FILESPACE running in the BACKGROUND processed .... items with a completion state of FAILURE at .... ------ IX76241 WAIT HANG SESSION VERSION 3 A client session on a ADSM V3 server may hang doing a long split on a database page during backup processing. Externally, there are no unique symptoms to this problem other than eventually all client sessions most processes will hang. IX79265 ABEND0C4 IN ADSM PROC TMABORT+'8E' RUNNING ADSM V3 SERVER. The adsm MVS V3 server gets an abend0c4 in TMPROC+'8E'. The is processing a transaction abort from a client but there was no session started causing this abend. IX79294 ANR9999D ADMNODE(6648): INVALID NODE TYPE 0 FOR NODE ... This APAR is to document this message and let customers know that this message may be ignored. This message is issued as a result of code added in level 3.1.0.2 and 3.1.1.1 to correct a problem where server nodes were counted against the number of clients licensed. ANR9999D is a diagnostic message which should only be issued when there is a problem which requires further diagnosis or corrective action by ADSM Service. In this case, it is an inappropriate use of the message because the server is actually correcting an existing problem and no further action or diagnosis is required. IX79295 ABEND0C4 ORMADM.C+42CE ENDMOVEDRMEDIATHREAD()+48E REG07 MOVe DRMedia background thread terminates with ABEND0C4 in load module DSMSERV (ANRSERV) source module ORMADM.C at offset +42CE, stmt 2926, in function EndMoveDrmediaThread() at offset +48E. EndMoveDrmediaThread() calls FreeStorage() to free the storage used by the move drmedia thread. The last thing that FreeStorage() frees is the ormDesc structure. Upon return from FreeStorage(), EndMoveDrmediaThread() attempts to call pkExitThread() using a pointer in the freed ormDesc structure as an argument. IX78196 DUMPDB INCORRECTLY REPORTING ANR9999D DLDUMP(2361) After upgrading from V2 to V3, customer is finds that DUMPDP is incorrectly reporitng ANR9999D DLDUMP(2361): logical page corruption --- BACKUP DB does not report and errors and show tblscn report no errors. IX79381 UNABLE TO CONNECT MORE THAN 200 CLIENT SESSIONS FOR BACKUP. HARD CODED LIMIT IN TCPCOMM.C FOR HPNS_MAX_SESSIONS IX79387 SQL ERROR IN THE WEB SHELL ADSM ADMINISTARTION DURING REQUESTING THE POOL VOLUMES INFO IF POOL NAME LONGER THAN 18 CHARACTERS. Error using the Web Admin displaying an object with a long name, when a dependent object is selected for display. An example: When displaying a storage pool with a long name select the volumes icon to display the volumes in that storage pool. IX79388 PARSING ERROR FROM TIVOLI WHEN IBMADSM_SERVER_EVENT CONTAINS DOUBLE QUOTATION MARKS When reporting ADSM SERVER events to Tivoli, a parsing error occurs if the message to log contains double quotation marks. IX79389 HANG OR WAIT OF ADSM SERVER WHEN USING WEBADMIN CLIENT The ADSM server can hang when using the WEBADMIN client if there are TCP/IP problems causing the send of data to hang in TCP/IP. The problem is in the HTTP communications path that the SMVARS mutex is being held while sending data. A SHOW THREADS will show most threads waiting on the same MUTEX. A Q SESSION will show an HTTP session in a SENDW state for a long time. IX80115 Q AUDITOCCUPANCY FROM MVS ADSM 3.1.1.3 DISPLAYS INCORRECT DATA. Query Auditoccupancy shows storage values for nodes which have no filespaces. IX79919 NETWARE & WIN32 3.1.0.3 CLIENTS RESTORE FILES WHEN -DIRSONLY OPTION IS SPECIFIED IF THE DATA IS STORED ON SEQUENTIAL MEDIA. When the DIRSONLY option is used with a restore from a client, files are sometimes sent from the server to the client. The will happen if: - The No-Query Restore protocol is used - Directories to be restore have extended atributes that reside on sequential media in ADSM. IX80959 WEB ADMIN CLIENT RECONNECTS TO SERVER WITHOUT AUTHENTICATION When an administrator sign-on times out, the user can gain access to the server by pressing the cancel button on the authentication pop-up screen. IX79282 AUDIT LIBRARY aborts the server If the SCSI driver is not started on the NT server and I run an AUDIT LIBRARY, the server will take a dump IX79537 Incorrect text response SD-3CC and FORMAT=DRIVE fix for ECART IX79626 WHEN ARCHIVE OBJECTS ARE BEING EXPIRED IF CORRESPONDING DESCRIPTION ENTRY IS MISSING, EXPIRATION FAILS FOR THAT OBJECT. The archive descriptions tables were created to enhance performance for the V3 GUI, archive/retrieve functions. "Conversion" to the tables occurs on a per node basis: - when a node attempts to archive a file using the V3 GUI interface, the node is prompted if it will wait for the conversion. If OK, entries are created in the archive description tables. Errors have been reported when subsequent insertions, updates, or deletions are made in these tables. Insertion errors are reported by customers that use tools (e.g. shell scripts) to generate multiple, concurrent archive sessions for the same node name. Deletion errors also occur for nodes with large numbers of archived data. The errors were due to a serialization problem with the archive description tables. The locking scheme was changed to fix. IX77733 WEB ADMIN LOOKS FOR SCHEDULE TO UPDATE ONLY BY NAME IGNORING DOMAIN The UPDATE SCHEDULE form for updating client schedules through the WEB interface dose NOT always reference the selected schedule if schdules having the same schedule name exist in multiple policy domains. IX78290 ANR0729E SYNTAX ERROR WHEN IMPORTING A NODE ASSOCIATED TO CLIENT OPTION SET During IMPORT of client optionsets, client option value needs to be surrounded by quotes in order to keep the INCLEXCL option value as one long string. IX79415 SELECT ALL* FROM STGPOOLS COMES BACK W/EST_CAPACITY_MB: 0.0 WHEN A STORAGE POOL IS LARGER THEN A TERABYTE. EST_CAPACITY_MB does not handle terabytes in "select ... from stgpools" IX79925 QUERY CONTENT FAILS AGAINST OPTICAL VOLUMES WHICH HAVE AN UNDERSCORE IN THEIR NAME The LABEL LIBVOLUME command now allows optical volumes to contain underscores. The QUERY CONTENT command attempt to resolve the optical volume the underscore in its name and did not allow underscores. The QUERY CONTENT failed. IX80363 ANS1314E (RC14) WHEN DOING PARTIAL OBJECT RETRIEVE WITH OFFSET > 0 AND LENGTH = 0 (STG=TAPE) When applications retrieving through the ADSM api perform a partial object retreive with only the offset (length=0) the retrieve failed. This was due to an invalid calculation in the retrieval code. IX80786 TBUNDO096 ASSERT FAILURE RESTORE.OBJECTS TABLE If a Restartable Restore session is cancelled early on, it is possible to receive an assert failure during transaction processing: ANR9999D TBUNDO(207): Error 2 on delete from table Restore.Objects for undo. IX80900 ADSM RELCAMATION PERFORMANCE RUNS SLOW ON V3 SERVER, ESPECIALLY WHEN SLOWER DEVICES ARE USED When ADSM server reconstructs an aggregate with empty space, it currently requires a position to the beginning of the frame before retrieving each file. With large buffers and small files this severly effects performance as we have to rewind the tape for each retrieval. IX81040 AIX ADSM 3.1.1.3 "CHECKI LIBV LIB_NAME STAT=SCR CHECKL=NO VOLR= XXXX,XXXX SEARCH=Y DEVT=XXXX"DOESN'T CHECKIN ALL QUALIFIED VOLS a linked-list traversal was accessing the wrong list element (volume) at the time of checkin. This also can cause volume not in the range to be checked in, as well as omit volumes that are in the range. IX81426 ADSM SERVER V3.PTF3 ON NT, LIBRARY ADIC SCALAR 458. MOVE MEDIA WITH REM=BULK: DOOR IS LOCKED WHEN THE PROCESS HAS COMPLETED. When checking out a tape in this library using the remove=bulk option, the library door is quickly unlocked and locked. The problem is that the door is never unlocked, so the customer is unable to remove a tape(s) from the entry/exit slot. Effects HP, SUN, AIX and NT platforms IX81655 FILES DOES NOT REBIND WHEN MANAGEMENT CLASSES CHANGE DURING BACKUP. If a client file is assigned to a new management on the client, this causes the server to perform a re-bind operation. This re-bind operation assigns the existing files this client backed-up to a new management class. However, the re-binding algorithm was not re-binding all possible files in the case where the new management class had a retversions of NO_LIMIT. IX81674 WHEN DOING A CLASSIC RESTORE OF A LARGE FILE SYSTEM, THE SERVER RUNS OUT OF MEMORY OBTAINING LOCKS. During a large restoration, the following error(s) are seen: ANR9999D Memory allocation error. Warning: insufficient memory to buffer output data; data discard ANR9999D pkthread.c(528): Insufficient memory available to alloc "tmLockHolder" object of (40) bytes, Thread 44, File tmlock.c, L If you are doing a classic restore of a very large filespace, the server can exhaust its memory during the "query" phase because locks aren't being released until the entire query phase is done. This problem is not witnessed with a NoQueryRestore. IX81952 RESTORE OR RETRIEVE PROCESSING DEGRADED WHEN DISK STORAGE POOL UNAVAILABLE, RESTORE ORDER LIST NOT OPTIMAL During restore or retrieve processing from a client, the server does not optimize the retrieve order for the files if the files: 1) Reside in a disk storage pool 2) And one or more of the following conditions exists for the disk storage pool where the data resides: - the disk storage pool is set to ACCESS=UNAVAILABLE - a needed disk volume is not varied on-line - a given file is marked as damagedin the disk storage pool IX81990 FILES NOT EXPIRING DURING EXPIRATION Inactive files are not expiraing according to the copy group definition for retain extra versions. This may cause excessive tape usage and the db to grow. IX82029 EXPORT THREAD HANGS. The server can deadlock if file data for a particular node is exported at the same time as a backup, archive, or space- management session is storing files for the same node. This problem is caused by contention for the same database lock by the export and storage operations. IX82032 ADSM SERVER HANG ON NO QUERY RESTORE The ADSM V3 server may hang while doing a no query restore (NQR). A query session shows the hung session is in the run state. IX82190 RECLAMATION VOLUME SELECTION UNPREDICATBLE. The current reclamation volume selection algorithm is not ordered in a predictable manner. Based on many customer requests, the algorithm will now first choose the eligible volume which has the largest percentage of reclaimable space. IX82308 ADSM MESSAGES MANUAL AND HELP OUTPUT INDICATES THAT THE NODENAME AND NOT THE IP ADDRESS SHOULD BE DISPLAYED IN ANR8214W MESSAGE There is a documentation error in the on-line help and the messages manual for message ANR8214. This message should refer to "IP Host Address" instead of "node name". IX82320 SELECT COMMAND DISPLAYING THE PENDING_DATE MAY REPORT INCORRECT DATA. IX82401 STORAGE VALIDATION AREA OVERWIRTTEN WITH USER DATA CAUSING (server) TO LOOP In certain rare circumstances during a restartable restore (No-Query Restore) a memory overlay condition could take place causing a loop or abend. The circumstance identified is when a file is backed up with a given management class name. Since the time of backup the file is re-bound to a new management class name which is shorter in the number of characters. The failure can happen during a restartable restore involving the file. IX82436 WHEN UPDATING A MGMTCLASS NOT LISTED ON TOP OF THE LIST, THE WEB ADMIN WILL DISPLAY THE INCORRECT MGMTCLASS DESCRIPTION. When updating a mgmtclass not listed on top of the list, the web admin will display the incorrect mgmtclass description. When a domain have several management classes and when an update is performed on a management class that is not on top of the list, the web admin will display the management class description that belongs to the management class on top of the list. IX82528 SQL ERROR AND SERVER HALT WHEN ADSM WEB ADMIN CLIENT QUERY FILESPACE WITH 'DEL' (0X7F) CHARACTER IN FILESPACE NAME IX82562 ADSM SERVER CORE DUMPS ON WEBADMIN URL PROCESSING (ANR7837S MEM0 001) The server abends when parsing a url that has been truncated from the web browser. IX82629 9740 max drive should be 10 IX82739 ADSM V3 SERVER DOES NOT DISPLAY HELP FOR CLIENT ADMIN MESSAGES. DOC NEEDS CLARIFICATION ON WHAT ADMIN COMMANDS WILL HAVE HELP. The server on-line help did not include the information necessary for providing help for ANS messages to the ADSM Command Line Administrative Client. IX83014 ANR0422W ERROR. NODE NAME IS CHANGING ON IT'S OWN UNDER CERTAIN CIRCUMSTANCES. The ADSM server may corrupt string values it is processing. An example is a node name appears incorrect. IX80101 SELECT * FROM CONTENTS OUTPUT MAY HAVE GARBAGE FILESPACE_NAME FIELD When "select * from contents" is issued, garbage is sometimes displayed for the filespace name. IX81330 CANNOT DEFINE CLIENTACTION WHEN THE OBJECTS FIELD CONTAINS A DIRECTORY WHICH HAS A SPACE IN THE DIRECTORY NAME. CANNOT DEFINE CLIENTACTION WHEN THE OBJECTS FIELD CONTAINS A DIRECTORY WHICH HAS A SPACE IN THE DIRECTORY NAME. For example: Able to define a schedule with the following syntax and the schedule runs successfully: DEF SCH DOMAIN_NAME SCHED_NAME ACTION=ARCHIVE OBJECTS='"f: my documents *'" But cannot apply the same syntax for the objects field when defining clientaction: DEF CLIENTA NODENAME DO=DOMAIN_NAME ACTION=ARCHIVE OBJECTS='"f: my douments *"' This will error with ANR202E DEFINE SCHEDULE: Invalid parameter - F: MY. Tried objects="f: my documents *". The server accepted the command but the schedule fails. Tried combinations of syntaxes but all failed. IX83680 ANR8300E DURING A LABEL LIBVOL OPERATION USING THE SEARCH=BULK PARAMETER((OP=00006C04, CC=320, KEY=FF, ASC=FF, ASCQ=FF). IX77909 ANE14--- MESSAGES ARE DISPLAYED ON SERVER INSTEAD OF ANE4---X Events such as ANE4007W are displayed as ANE14007. Because of this, these events cannot be forwarded to an external event handler. IX83398 DSMSERV CAN COREDUMP WITH IMIXN008 DURRING SERVER TO SERVER COMMUNICATIONS. Code was added at the 3.1.2.0 level of ADSM which allowed multiple volume names to be picked within the same second. Since the volumenames used in Server to Server communications contain the time to the second, this would allow multiple volumes of the same name. When this condition is discovered, the transaction ends up being aborted twice, creating the TMTXN008 condition. IX83777 PROBLEM W/ EXTERNAL LIBRARY MANAGER WHEN ISS APARS fixed in Service Level 3.1.2.20 - part 1 ---------------------------------------------- IC20502 ERROR WHEN USING THE V3 ADSM SOLARIS 2.5.1 CLIENT WITH THE SOLARIS V3 SERVER, SHARED MEMORY COMMMETHOD, AND LARGECOMMBUFF The problem is that when using the SharedMemory protocol and the options with the Sun server and client, Sun's default shared mem is not large enough. The shared memory max size can be increased by placing the following in the /etc/system file: set shmsys:shminfo_shmmax=8388608 <@> IC22123 CLOSING COMMAND LINE WINDOW WITHOUT QUITTING ADMIN CLIENT SESSION WILL RESULT IN GARBAGE IN ACTIVITY LOG Network connections with admin clients were not closed when the clients were terminated, thus resulting in garbage being read from communications buffers. If you start an Admin Client session with a V3 Server running on HP-UX, garbage will be displayed in the activity log if you close the terminal window without first quitting your session with the Server. This problem is only seen with V3 Servers running on HP-UX, regardless of the platform the Admin Client session is generated from. <@> IC22247 ON OS/2 VERSION 2 SERVER USING 3449 LIBRARY SLOTS 3 AND 4 ARE BOTH MAPPED TO ELEMENT 4 IN THE LIBRARY. On an OS/2 server with a 3449 8mm library slots 3 and 4 are both mapped to element 4 in the library. Show slots has the following output - note that slots 3 and 4 are missing: Slot 2, status Full, element number 3, barcode not present, bar Slot 5, status Full, element number 5, barcode not present, bar The "Return All Library Inventory" of the lbtest utility shows: INVENTORY ERROR: 4 is duplicated element address <@> IC22324 ADSM NETWARE311 CLIENT 3105 GETS ANS1809E, GETS: ANS1809E, ANS18 AND NT FLUSH ERROR 17 WITH IPX COMMMETHOD BACKUPS. TLI LIBRARY. IPXSPX commethod errors with netware adsm v3ptf5 clients. The problem is with Netware tli library functions with buffer flush. <@> IC22462 ADSM SERVER SENDS INVALID PARAMETER TO TIVOLI TEC EVENT RECEIVER WHEN COMMS METHOD IS NAMEDPIPES. The Tivoli Event Receiver was unable to parse the value for the comm_method field of the event, because it contained an embedded blank and was not enclosed in single quotes. <@> IC22494 LABEL LIBVOL DOES NOT WORK WITH AIT AND 8900 DRIVES. The problem is that the LABEL LIBVOL command attempts to label tapes in the older 8200 format, which is not compatible with 8900 and AIT drives. <@> IC22675 BACKUP/ARCHIVE CLIENTS CANNOT DELETE THEIR OWN FILESPACE Backup Archive clients cannot delete their own filespaces even though they have been given authority to delete their backed up or archived data. The deletion appears to complete correctly but the filespace is NOT deleted. On the server message ANR0984I Process for FILESPACE DELETION is started gets issued and ANR0987I indicates that the process has completed with a state of SUCCESS. However, the client can still see the filespace in a list of those to be deleted. <@> IC22721 TZ89 DRIVES CAN NOT LABEL COMPAC IV CARTRIDGES WHEN HARDWARE COTZ89 DRIVES CAN NOT LABEL COMPAC IV CARTRIDGES WHEN HARDWARE COMPRESSION IS ENABLED When the TZ89 is set to compressed-data mode, it cannot write a COMPACT-IV type of tape in the lowest DLT format. ADSM by default initially writes all labels in this format, and does not distinguish the media type <@> IC22852 ANR8300E RECIEVED DURING LABEL LIBVOL SEARCH=BULK ALTHOUGH THE OPERATION WAS SUCCESSFUL. The ANR8300 message containing "CC=320" is falsely issued when running the CHECKIN LIBVOL ... SEARCH=BULK command. This apar does not address any other CC= values or the CC=320 unless SEARCH=BULK is specified in the command. <@> IC22970 ADSM SERVER 3.1.2.1 DOESN'T REMOVE LAST DB BACKUP VOLUME FROM VOLHISTORY BY 'DEL VOLHIST TOD=TODAY TOT=NOW TYPE=ALL' COMMAND. Need to prevent users from accidentally deleting last data base Backup series. <@> IX78238 ANR9999D PVRSERV.C(833): SERVWRITE: ERROR WRITING SERVER VOLUME X. RC=30 WHEN COMMTIMEOUT VALUE < TIME REQUIRED TO MOUNT TAPE. The ADSM source server which writes to the virtual volume may encounter errors writing to the volume in a situation where the target server is in a media wait condition. Specifically, because the target server is in a media wait, the source server may cancel the outbound virtual volume session because the communications timeout value on the source server is exceeded. <@> IX79728 ANR9999D: IMUTIL.C (2555) LOCK ACQUISITION SLOCK FAILED FOR INVENTORY NODE XXX,RECEIVED DURING EXPORT SERVER During a long running export command on the server, the export can fail with the message: ANR9999D imutil.c(2555) Lock acquisition SLOCK failed for inventory node X. Because of the lock acquisition failure, the export will terminate. <@> IX79929 WRONG WORM SCRATCH VOLUME HANDLING MAY CAUSE INFINITE LOOP After a full WORM optical volume becomes empty, it should not be allowed to return to scratch. <@> IX80749 THE "WAIT=YES" OPTION DOESN'T WORK FOR THE "MOVE DATA" COMMANDS FOR OFFSITE/COPY STORAGE POOLS. AIX 4.2 ADSM SRV 3.1.PTF 3. The server processing for volumes that are OFFSITE for the MOVE DATA command with the WAIT=YES parameter specified does not work. Specifically, the MOVE DATA processing runs in the BACKGROUND on the server instead of running in the FOREGROUND. <@> IX81490 DURING A "RESTORE DB" PROCESS, IT WAS FOUND THAT THE DEVCONFIG FILE CONTAINED "ACSDRVID=" FOR A NON-STK LIBRARY. RESTORE FAILS. Within the ADSM server device configuration file, there may be an extraneous keyword (ACSDRVID=) on DEFINE DRIVE commands for non-ACSLS drives. Use of a device configuration file containing DEFINE DRIVE commands with this extraneous keyword will cause a database restore to fail. <@> IX82231 WEB ADMIN COMMANDS MAY ERROR WITH ANR2000E-UNKOWN COMMAND AND ANR2020E-INVALID PARAMETERS WHEN RUNNING ON AIX 4.3.0.X. The server encounters errors parsing commands. An example of this is the that the Web Admin commands may error with ANR2000E UNKNOWN COMMAND ANR2020E INVALID PARAMETER The commands displayed have randomly have invalid characters in them that do not match what was originally reported to the server. <@> IX82403 AIX ADSM V3PTF5 SERVER: THE ERROR DURING EXPIRE INVENTORY: ANR9999D AFTXN.C(747):FILE COUNT WENT NEGATIVE,ANR1181E,ANR2183W During expiration processing, migration, reclamation, delete filespace, or other processing that may delete files from sequential media; the error: ANR9999D aftxn.c(747): File count went negative for pool X, Ck1=N, Ck2=Y. may be encountered. This will cause the transaction in use by the server function to abort and fail. <@> IX82929 ADSM SQL V3PTF5 SRV."SELECT" DOESN'T WORK WITH 3 AND MORE TABLES ANS8001I RETURN CODE 4. ANR9999D SQLQUERY.C(1004). "Internal SQL table declaration conflict" received. <@> IX83029 INCORRECT MESSAGE WHEN ADSM UNABLE TO INITIALIZE SCSI LIBRARY The problem is that defining a drive to an ADSM library failed, in this case with the message "ANR8366 Invalid attribute for ELEMENT parameter". The error was not due to the ELEMENT at all, but to the fact that the library was offline and unable to validate the element value. <@> IX83978 DELETE VOLUME RETURNS VOLUMES TO THE SCRATCH POOL WHICH WERE NOT SET "SCRTCH VOLUME? YES" Delete volume and restore volume commands return a volume to scratch even if it was not introduced to the storage pool through a scratch mount request. <@> IX84094 UNABLE TO QUERY SCHEDULED EVENTS. WILL RESULT IN ANR2635E. Qeuery Event and Query Actlog not allowing for the begindate\time and enddate\time to be equal as required by the N/T administrator GUI client. <@> IX84124 DLT TAPES USING THE STK-OMI DEVICE DRIVERS ON ENHANCED ADSM DO NOT CORRECTLY TRANSLATE TO THE V3 DLT DEVICE CLASS. The Enhanced ADSM product used 256K blocksizes and device type of STK for their DLT support. In ADSM, DLT support was originally done with 32K blocksizes. The volume attributes for the volumes that were written with devtype STK indicate that these volumes were written with 32k. This is because the Enh. ADSM product was out of sync with ADSM in terms of how DLT attributes were stored, and this was missed during migration testing. The same case does NOT apply to 4490/9490 drives that were also written with devtype=STK. <@> IX84141 MEMORY ALLOCATION FAILURE WITH LARGE BUFPOOLSIZE (ANR0132E) On AIX only, if you have a very large server using a lot of memory, you could end up using all 750MB allocated to the server. As a result, you will receive memoy allocation failures and the server may crash. <@> IX84177 UNEXPECTED RESULT CODE (17) FROM BFAUDITBITFILE ENTERED IN ACTLOG FOLLOWED BY INTERNAL SERVER ERROR DETECTED NEED TO HANDLE LACK OF MOUNT POINTS FOR AUDIT VOLUME WITH CORRECT MESSAGE INSTEAD OF ANR9999D. <@> IX84456 AVAILABLE MOUNT POINT NOT GRANTED WHEN USING MORE THAN ONE DEVICE CLASS WITHIN A LIBRARY The problem is that mountlimit setting for one devclass takes other devclasses that use the same library into account when counting how many mountpoints the one devclass can have. For instance, in devclass whose library has five drives but whose mountlimit is "1", if another devclass also uses that library, its acquired mounts will cause the first cause the first devclass to think it has already acquired the one mount that it is allowed. <@> IX84485 ADSM V3 SERVER BACKUP STGPOOL IS RUN SPECIFYING WAIT=YES AND MAX PROCESSES IS GREATER THAN 1 ONLY 1 BACKUP PROCESSES RUNS The ADSM server BACKUP STGPOOL command is not working correctly when MAXPR > 1 is specified with the WAIT=YES option. Specifically, multiple server processes are not being used for the backup. <@> IX84602 ANR8827ENO ENTRY EXIT PORT FOUND MESSAGE ON LIBRARY WHEN VOLUME HOME SLOT FOUND EMPTY When checking volumes out of an ADSM supported library using the REMOVE=BULK option, if the move from the slot to the EE station fails for ANY reason, the move is re-attempted to each of the EE slots. If the move never succeeds, the message "ANR8827E No Entry/Exit port is available..." is issued, even though one or more can be empty and available. One reason the move can fail is that the source slot is empty (ie. the volume was physically removed without checking it out of the library). <@> IX84637 ANR8778W SCRATCH VOLUME CHANGED TO PRIVATE STATUS TO PREVENT RE-ACCESS CAN LOOP, FILLING UP THE DB AND CRASHING THE SERVER. This error is an infinite loop of reporting ANR8778 SCRATCH VOLUME CHANGED TO PRIVATE STATUS TO PREV... It occurs when attempting to mount a scratch tape in a few isolated cases. These are mainly when there are also reported I/O Errors on the library. <@> IX84715 THE ADSM VERSION 3 SERVER IS NOT PROPERLY HANDLING DATA DISPLAYED IN HEXIDECIMAL FORMAT. When logging events from one server to another, there is an error in the output processing algorithms that causes data that is supposed to be displayed as a Hexidecimal value to be displayed as a numeric value. <@> IX84765 IF A VOLUME CONTAINS FILES WHICH COULD NOT BE RECLAIMED, ADSM SERVER 3.1.2.0 WILL DELETE THE VOLUME FROM THE STORAGEPOOL. If a volume contains files which could not be reclaimed, ADSM Server 3.1.2.0 will delete the volume from the storagepool. Messages from the actlog: ANR1175W Volume xxxx contains files which could not be reclaimed ANR1410W Access mode for volume xxxx now set to "unavailable". ANR1041I Space reclamation ended for volume xxxx. ANR1341I Scratch volume xxxx has been deleted from storage pool. <@> IX84769 CONTACT MAX LENGTH IN SQL OUTPUT IS 128: CAN HOLD AND DISPLAYS 255 CHAR. IN Q NODE F=D. SQL select does not display a long "contact" for a node <@> IX84965 IF THE CENTRAL SCHEDULE (CS) TRIES TO START A SESSION BEFORE THE MAIN SCHEDULE THREAD FINISHES INITIALIZING ON 3466, RC=22 OCCURS Wehn the ADSM server is initalizing, there is a window during which the sessions can be established to the server before the central scheduling component is initialized. If a client attempts to start a scheduled session during this window, the server will display a Mutex Acquisition failure with return code 22. The server will then crash. <@> IX85064 MESSAGES ANR2280I AND ANR2281I ISSUED TWICE UPON DATABASE BACKUP ANR2280I and ANR2281I issued twice to the console and activity log on a data base backup. <@> IX85125 ADSM V3 SERVER UPDATE DRIVE COMMAND HANGS, CAUSING OTHER SESSIONS AND PROCESSES TO HANG, THEN POSSIBLY THE WHOLE SERVER Deadlock can occur when the UPDATE DRIVE command is used and at least two other processes try to acquire a mountpoint. <@> IX85134 AIX SERVER 3.1.2.0 DOES NOT READ SPECTROLOGIC 10000 BARCODE LABELS barcode was not enabled for Spectralogic library. <@> IX85182 SOME ADSM FUNCTION CALLS RETURN AN INVALID ERRNO OR NO ERRNO AT ALL. If an error is encountered writing to a disk volume the errno is not reported by ADSM, making diagnostics more difficult. <@> IX85278 DISK ACCESS PROBLEMS CAN CAUSE AN EXCESSIVE NUMBER OF ANR9999D DSRTRV.C MESSAGES IN THE ACTIVITY LOG. If an error occurs while reading logical blocks from a disk storage pool, an error message is issued for each block that could not be read. This can result in a large number of entries in the activity log. <@> IX85298 INVENTORY EXPIRATION DOES NOT EXPIRE AS EXPECTED FROM THE VEREXISTS PARAMETER IN THE COPYGROUP The version control for backup objects is not properly maintaining the versions exists attribute for the copygroup managing a given file. The error is that the versioning algorithm is not marking files to be eligible for expiration when the count of the number of versions for a given file exceeds the versions exists value. Consequently, more files are being kept in the server and the files are not being expired when they should. Please note that the error is that the server is NOT expiring data when it should actually be expiring it. <@> IX85410 THE SELECT STATEMENT DOES NOT GIVE PREDICTABLE OUTPUT. The customer issued both a "query occupancy" and a "select from occupancy". The entry: Node Name Type Filespace Storage Number of Physical . Name Pool Name Files Space . Occupied . (MB) . ----------- ---- ---------- ---------- --------- --------- -- JEFF.CIT.C- Arch (archive) ARC.DL3 564 2,060.78 appears in the query output, but is missing in the sql output. <@> IX85412 DURING A DB RESTORE, A ANR8302E MESSAGE CAN BE DISPLAYED AFTER A ANR1365I VOLUME CLOSED (END REACHED). When a volume is closed for the listed devices, a tape motion of spacing backward and then forward one record is performed. This is to force the device to mark EOD on the last record written. Some ADSM operations do not leave the tape in a state that can perform this operation, such as RESTORE DB where it is positioned after a tape mark. This means the RSR/FSR motion fails and is reported, but the failure is superfluous to the tape processing involved. This fix also corrects a sometimes seen problem where the following message is also written to the actlog. This is also a false message that does not impact the overall process: ANR8300E I/O error on library xxxxx (OP=00006C03, CC=314, KEY=05 ASC=3B, ASCQ=0E, SENSE=70.00.05.00.00.00.00.0A.00.00.00.00.3B.0E.00.00.00.00.00.0 00.00.00.00.00.00.00.00., Description=The source slot or drive was empty in an attempt to move a volume). Refer to Appendix B in the 'Messages recommended action. <@> IX85431 ADSM HAS A SEGMENTATION FAULT FOLLOWING ANR8311E ... FOR OFFL OPERATION, ERRNO=78. A null referenced pointer is responsible for the abend. It is referenced immed. after "ANR8797 Drive ... is inaccessible" is issued. <@> IX85513 QUERY DRMMEDIA COMMAND PROCESSING DOES STOP WHEN A VOLUME_UNAVAI LABLE RETURNS FROM AN EXTERNAL LIBRARY MANAGER The original logic of QUERY DRMEDIA is same as other ADSM QUERYs that quit the process (displaying) as long as an processing error is encountered. The reason is that the error message issued to the console will mess up the format of the query output. In the situation descripted in this APAR, it is reasonable that ADSM should display other volumes that do not encounter any error. <@> IX85583 ANR8302E I/O ERROR ON DRIVE OP=READ, CC=404, KEY=03, ASC=30, ASCQ=01 WHEN CHECKING IN AN UNLABELED TAPE ON AN ACSLS LIBRARY I/O error with CC=404, KEY=03, ASC=30, ASCQ=01 when checkin unlabeled tape into an ACSLS library <@> IX85726 ADSM 3.1.2.1 WEB ADMIN DOESN'T ALLOW TO THE ADMINISTRATOR WICH HAS ONLY POLICY PRIVILEGE CHANGE HIS PASSWORD. Administrator with out system authority cannot update their password via the ADSM web administrator interface using the tree path objects->administrators->{admin name}. <@> IX85734 EXPORT NODE FAILS WITH ANR9999D XIBF.C(1408): INVALID HEADER SIZE FOR OBJECT FOLLOWED BY ANR0569I, ANR0794E During the export processing of file data, the following message is received: ANR9999D xibf.c(1408): Invalid header size for object. After this message is received the export processing is terminated with an error. <@> IX85810 ADSM VOLUME SHOWS "IN USE" WITH NO PROCESS RUNNING AND NO CLIENT SESSION ACTIVE. This problem can cause an infinite loop to occur during migration of data from a sequential-access storage pool with an ADSM 3.1.2 server. Under a unique set of conditions, an error can occur that causes the migration process to terminate, but leaves the migration thread unable to reach the low migration threshold. For example, this could occur if (1) an error prevents a volume from being migrated, (2) there are no more volumes to migrate, and (3) the low migration threshold is very low. With this combination of conditions, migration keeps looping as it tries to reach the low threshold, but is never able to do so. . This problem results in two adverse effects. First one or more volumes may be left "in use" even though there are no sessions or processes using those volumes; the volumes cannot be used by other server operations. A second effect is that the server generates a new transaction during each pass of the loop and does not release the storage used by that transaction; this results in a serious memory leak. <@> IX85858 ANR8828E SLOT 64 OF LIBR XXXX IS INACCESSIBLE AFTER MIGRATING TO V3 SERVER After migrating from V2 to V3 server, customer is getting ANR8828E slot 64 of libr xxxx is inaccessible with his robot ATL/ACL 6176. <@> IX86239 ANR0986I AT END OF EXPORT NODE PROCESSING IS REPORTING NUMBER OF "BYTES" INSTEAD OF NUMBER OF "KILOBYTES" Final statistics of total bytes moved during an export node was displaying the same numeric value, but in different magnitudes (ie., 5000000 kbytes also displayed as 5,000,000 bytes). <@> IX86372 ADSM AIX SERVER USING GENERIC TAPE DEVICE CLASS FAILS SYSTEM CALL IN GETMODEL ROUTINE TO CHECK TYPE OF DRIVER BEING USED. ADSM AIX server using generictape device class receives anr9999d Unableto obtain model type for drivename, rc=xx. For generic tape devices the server issues a system call to determine the driver being used. If this system call should fail for some reason the above anr9999d message will result. <@> IX86414 NOT ABLE TO DELETE NODE AFTER A NEW NODE TYPE=SERVER IS DEFINED AND THE NODE'S FIRST LOGON ATTEMPT IS DONE BY A B/A CLIENT. A node type server that was accessed as a backup/archive client node cannot be removed until the server is halted and restarted. <@> IX86630 ANR9999D BLKDISK.C(1053): SIZE OF FILE (0) NOT A MULTIPLE OF THE DISK BLOCK SIZE (-1273015296). The warning message that warns that not all the space in a disk volume will be used had incorrect values on AIX 4.2+ systems. The function was not otherwise affected. <@> IX86662 DELGRACEPERIOD HAS LOWER LIMIT OF 5 The minimum value allowed for the grace deletion period is 5. Because of the delay in deletion this causes (5 days), the space in use by virtual volumes on the target server may be high. Specifically, in some customer situations, due to the way they are managing their data, this value causes gigabytes of space to be used on the target. <@> IX86665 Q ACTLOG USING SEARCH=TXT_STRING: THE TXT_STRING IS IGNORED EXCEPT WHEN USING THE NODENAME. Event messages, those messages with 'ANE' prefix, logged to to the server usually include a node name or server name that the event originated from, and the session number. These are enclosed in parethesis. For example: . ANExxxxs ( Session: xxx Node: ccccc ) Messages text goes here. . The user was trying to use the 'SEARCH' parameter in the QUERY ACTLOG command to find certain words, such as, 'SEARCH=node:' or 'SEARCH=session' but not getting search results. The reason for this is the 'PARENTHESIS', the word 'SESSION:', and the word 'NODE:' are all text formatted to the message at the time the message is printed to the console. They are not stored in the database, thus, not searchable. This is working as expected. . However what should be searchable is the message header the actual session number, the actual node name, and the message It was found that all of these are indeed searchable except for the session number. Therefore, with this APAR the QUERY ACTLOG in the server will be updated to make sure the session number is also searchable. The QUERY ACTLOG in the ADSM Server will be updated to ensure that the session number in event messages ('ANE' messages ) are searchable with the 'SEARCH' parameter. <@> IX86691 DSMSERV FORMAT DOES NOT WORK WITH VOLUMES GREATER THAN 4 GB The AIX server fails in initializing certain size volumes with a dsmserv format command. For example, volumes of size 4096MB fail but 4457MB succeed. <@> IX86736 LINUX CLIENT CAUSING ADSM SERVER INSTABILITY, SERVER NOT CHECKING CERTAIN VERB SIZE INFO. Linux client send a verb that is too long in length, causing the server to crash. <@> IX86854 TRANSACTIONS ARE LEFT OVER IF THERE ARE NO RESTARTABLE RESTORE SESSIONS WHEN A QUERY RESTORE COMMAND IS RUN. The 'Query Restore' command does not clean up it's transactions if there are no restartable restore sessions running. <@> IX86871 ANR8914I ANR8910I ANR8907E 3570 OR 3575 AUTOCLEANING ENABLED ADSM-directed tape cleaning is being invoked on 357x libraries even though these have their own hardware-enabled autocleaning, and are not configured for ADSM-drive cleaning. <@> IX87208 SERVER MACRO CAUSES ACTLOG CORRUPTION, AND SOMETIME THE SERVER HANGS. NT ADMIN CLIENT MAY CRASH ALSO. On a V3 server, with an admin client execting a Macro command for a macro file that is larger than 1024 char. can cause actlog corruption and sometimes hang the server. If the command line client is on NT, an Exception Violation can occur and crash the client. Query Actlog can also hang if processing data from the period of the macro execution. A Select statement can retrieve the actlog data from the actlog table. <@> APARs fixed in Service Level 3.1.2.20 - part 2 ---------------------------------------------- IX87680 ANR2344E WHEN DOING AN UPDATE STG POOLNAME MIGDELAY=NUMBER FOR A DISK STORAGE POOL Doing an upd stg archivepool migdelay=1 results in the following messages ANR2344E UPDATE STGPOOL: The "?" option is not valid for device class DISK. ANS8001I Return code 3. <@> PQ16375 ANR9999D CSSESS 'CANNOT REGISTER CLIENT ADDRESS TYPE 1' NT CLIENT MVS SERVER WITH INTERLINK TCPIP PROMPTED Clients were unable to use prompted scheduling over Intelink TCPaccess. <@> PQ17134 ADSM CAN CONNECT TO THE WRONG TCP/IP ADDRESS SPACE IF THERE ARE MULTIPLE TCP/IP ADDRESS SPACES. After ADSM has initialized with TCP/IP and is listening on it's specified TCPPort and TCP/IP is recycled, ADSM will attempt to connect with the TCP image specified in ADSM server option TCPName. If the specified TCP image has not been restarted before ADSM tries re-establishing it's TCP/IP communications and TCP/IP Version 3.1 is active or ADSM server option file keyword IUCVTCPIP has been specified, ADSM will attempt to connect with the default TCP image name of TCPIP. If an image name of TCPIP is available, ADSM will connect and initialize it's TCP/IP communication support with that default TCPIP image name. If TCP/IP V3.2 or higher is available and the IUCVTCPIP server option keyword is not specified, ADSM will reconnect with the specified TCP/IP image name as expected and will not attempt connecting/initializing with the default image name of TCPIP. Installation's using CLIO/S communication support, regardless of the TCP/IP Version, will aggravated the condition because ADSM implicitly specifies the ADSM server option keyword IUCVTCPIP if CLIOPort option is detected in the ADSM server option file. <@> PQ17930 DSMADMC TSO ANS1033E ANS8023E TSO Admin Client displays an error message indicating the gethostbyname function failed. Also, the error code value that appears in the message is incorrect. <@> PQ19631 SETOPT ADSM V3 ANR2045E ABEND0C4 ANR2045E message inserts have been corrected. <@> PQ20556 3590 TAPE EMULATING 3490 CHANGE IN REPORTED CARTRIDGE LENGTH Hardware EC changes and newer control units will change the way that the cartridge length is reported for 3590's in emulation mode. The tapes were originally reported as ECCST, and will be reported as CST. If the length parameter has been set to ECCST in any devclass used to access these devices, it will need to be changed to CST or ANY when the hardware change is made for new or empty tapes to be used. <@> PQ20701 ANR0101E IDGROUP(283) + ANR9999D HTTREE(1891) AFTER UPGARDEDB FOR INSTALL OF ADSM MVS 3.1 2.0 WITHOUT RUNNING ANRIDL When starting the ADSM server in the upgrade DB mode a couple of ANR9999 messages stating that the interface.task table could not be opened followed by a message stating a error occure while quering a group. Yes, there is a problem, but the problem does not indicate a database failure. The problem is that the task table for the ADSM interface was not created but the server is in the process of creating the table. Better known as the chicken and egg problem. <@> PQ21036 ADSM ACCOUNTING RECORDS DISPLAY INCORRECT DATA FOR THE "PRODUCT LEVEL" & "PRODUCT SUBLEVEL" FIELDS AND MISSING SOME EBCDIC CHAR. **************************************************************** Accounting records do not appear to have valid version and level information. <@> PQ21142 ADSM QUERY ARCHIVE OR RETRIEVE FROM A V3 CLIENT CAN TAKE A LONG TIME TO PROCESS. <@> PQ21450 ANR0534W COUPLED WITH ANS1311E HAS 2 CIRCUMVENTIONS. The explanation and user response for message ANR0534W needed to be expanded to give a better explanation of possible causes and circumventions. <@> PQ21493 USING THE IFNEWER OPTION AND THE NOQUERY RESTORE PROTOCOL CAUSE UNNECESSARY TAPE MOUNTS AND DATA SENT FROM SERVER TO CLIENT. Using the ifnewer option and the noquery restore protocol cause unnecessary tape mounts and data sent from server to client. The server sends the client all it's files and data. The client then decides if the files meet the criteria. The client will keep the files that meet the criteria and trash the others. <@> PQ21527 ADSM ADMIN CLIENT ABENDS AFTER SQL COMMAND. error occurred freeing memory on an SQL error path <@> PQ21824 CMS ABEND 000000E0 OCCURS SOON AFTER MESSAGEHCPMHT2153I TAPE NNNN I/O CANCELLED DUE TO A MISSING INTERRUPTDISPLAYS. CMS abend 000000E0 occurs soon after messageHCPMHT2153I TAPE nnnn I/O CANCELLED DUE TO A MISSING INTERRUPTis displayed on the ADSM server console. <@> PQ22059 CRASH AT OFFSET 000003A0 IN PROC DEALLOCATECONVERSATION Customer receives an intermittent ABEND0C4 in DSMSERV on his MVS SERVER level 2.1.18. PN84541 closed the timing window, but not completely. <@> PQ22399 ANR5035E DYNAMIC ALLOCATION FAILURE, RETURN CODE 4, ERROR CODE -1 ON ADSM MVS 3.1.2.1 LEVEL SERVER. At the ADSM/MVS 3.1.2.1 server level dynamic allocation failures may not be handled correctly. This leads to a mount failure and process/session termination rather than to request for reply to wait, retry or cancel. The squence of messages received by the reporting customer are: IKJ66231I DATA SET ADSM.BFS.V259 NOT ALLOCATED, SYSTEM OR INSTAL INSTALLATION ERROR+ IKJ56231I DYNAMIC ALLOCATION REASON CODE IS X'000004E5' IEF391I ADSM ADSM SYS00170 UNABLE TO ALLOCATE - A TAPE ALLOCATION SUBSYSTEM ELIMINATED ELIGIBLE DRIVES IEF234E K 0501,009090,PVT,ADSM,ADSM ANR5035E Dynamic allocation of tape unit 3490 failed, return code 4, error code -1, info code -1. ANR9999D PVRCART(1607): Error dynfree'ing ddname , rc 4, errorcode 860, infocode 1. <@> PQ22461 ANR9999D MESSAGES ARE DISPLAYED W/O THE ANR9999D MESSAGE NUMBER ON ADDITIONAL OUTPUT LINES WHEN MESSAGEFORMAT 2 IS USED. ANR9999D messages not conforming to ' MESSAGEFORMAT 2 '. <@> PQ22570 ANR9999D SMHTTP(1761): ERROR OPENING INPUT FILE COMMANDLINEBEANI NFO.CLASS NEEDS TO BE CHANGED TO A WARNING An ANR9999D error message is displayed when a file is not found by the ADSM web engine. The problem is that Internet Explorer thinks that the ADSM CommandLine applet is a JavaBean and requests a file that does not exist. This error can be ignored. <@> PQ22885 ADSM ADMIN SCHEDULE EVENT SHOWS FAILED IF THE SCHEDULE DOES NOT COMPLETE WITHIN THE SCHEDULE WINDOW An adsm script is run via an adsm admin schedule. The adsm script has several "backup stgpool" commands with "wait=yes" parameters. If the script does not complete within the admin schedule window, the admin schedule event will show a status of "FAILED" for that schedule. <@> PQ23263 ON VM ADSM V2 SERVER, DB BACKUPS OR DUMPS THAT SPAN TAPES USING A DEVCLASS W/ 3590 DEVTYPE WILL FAIL ON RESTORE / LOAD OPERATION. Database backups or database dumps that span tapes and were done using a devclass with the 3590 devtype will fail on restore or load operations. The database restore or database load will fail when it reaches the end of the first tape. This does not affect full or incremental backups unless a single backup command requires multiple tapes. Database restores that require multiple tapes will not be affected by this problem if each tape has a different operation number. This ONLY affects ADSM VM using devclasses with 3590 devtype (devclasses with devtype CARTRIDGE that include 3590 devices emulating 3490 drives are not affected). Only backup/restore or dump/load operations are affected. Import/export and storage pool volumes should not have this problem. Finally, only if a single operation spans tapes (a single backup db type = full, backup db type=incr, or dsmserv dump command used more than one tape) should this problem be seen. <@> SA77581 ANR - UNABLE TO REINITIALIZE SECOND SIZE OF OPTICAL VOLUME Customer is backing up monthly data to Optical then executing MOVE DATA to move to tape. The next time ADSM goes to use the "empty" Optical volume, it attempts to reinitialize: ANR8702I Initializing sie xxx of volume xxx. followed 8 minutes later by ANR0991I Server shutdown complete Job Log shows MCH1211 "divide by zero" error from PVRHFS Apparently only one side of optical was re-intialized; Side A is blank, Side B has Data although ADSM indicates 0% Utilized. He can restart ADSM server with no problem. <@> IX80737 WHEN A SESSION IS ENDING, ADSM WILL SOMETIMES TERMINATE WITH A DBTXN077. THIS HAS BEEN SEEN ON AIX AND MVS. During Scheduled backup operations, the server may abend with a message inticating that the DBTXN077 assertion failed. <@> ---------------------------------------- $$ APARS fixed by service level 3.1.2.30 ---------------------------------------- IX89534 WEB ADMIN ERROR IN LABEL LIBVOLUME COMMAND When using the label libvol's parameter volrange or vollist via the ADSM Web Administrator Interface fails. The problem is the value information is not associated with the name parameter. <@> IX89544 CLIENT PLATFORM NAME PASSED TO THE SERVER IS TOO LONG, CAUSING THE ADSM SERVER TO CORE DUMP. ADSM client was sending a platform name that is longer than what ADSM server is expecting. So when using the platform name, ADSM server may crash due to the extra long platform name. <@> IX84425 WILL RECEIVE ANS1474E 'AN ERROR OCCURRED USING THE SHARED MEMORY PROTOCOL" WHEN PASSWORD EXPIRES. During client/server communications the server can close a shared memory protocol session before the client is ready for it to close. As a result, the client may still be expecting a message when the session is closed. As a result, the client issues message ANS1474E. <@> IX86299 WHEN DOING CLEAN DRIVE LIBRARYNAME DRIVENAME, PROCESS TAKES 15 MINUTES. <@> IX86321 ON ADSM V3 SERVER, "MOVE DATA" PROCESS FINISHED WITH COMPLETION OF SUCCESS EVEN THOUGH A MEDIA FAULT WAS DETECTED. NO DATA MOVED During a move data an error occurred during the reading of a file. Message ANR0985I indicated the process was successful when in fact it was not. <@> IX87017 CLIENT SESSION HANGS. SOME SESSIONS DOES NOT SHOW UP IN Q SESSION. NEW CLIENT SESSIONS MAY HANG ALSO On a V3 server and V3 client, if a backup is started and then a restore start for the same client, and then the restore is interupted for some reason, a deadlock situation may occur. <@> IX87338 DSMSERV CAN ABEND / CORE WITH A BUF043 An error can occur on ADSM servers which causes the server to run out of buffer space and core / abend with a BUF043. The DSMSERV.ERR file will have the following messages in it: 02/07/1999 10:01:01 ANR7838S Server operation terminated. 02/07/1999 10:01:01 ANR7837S Internal error BUF043 detected. This appears to happen after a DBBackup begins. . As a side effect, DBBackups may not complete thereby allowing the log to fill. <@> IX87389 A CRASH WITH UPDATE LIBVOL CAN OCCUR ON THE 3.1.2.1 DSMSERV IF THE VOLUME BEING UPDATED WAS CREATED AT AN OLDER LEVEL. A crash with UPDATE LIBVOL can occur on the 3.1.2.1 ADSM server if the library is a scsi library and the volume being updated is one that existed before the v3121 service was applied. <@> IX87406 'SHOW EVENTS' OPTION ON THE ADSM WEBADMIN GETS BROWSER ERRORS. IE4, NETSCAPE 4.08 AND COMMUNICATOR 4.5 SHOW SAME PROBLEMS. The problem is the browser's Java Virtual Machine does not have the correct support for the standard code pages. According to JDK documentation, these code pages should exist. However, Sun is requiring a separate license for the code page converts and some browser vendors are not including the support file. So when an ADSM server is running with an ISO code page and the ADSMConsole applet (Show events from the web option menu) tries to sync the codepages up, the request fails and an error message is produced. <@> IX87630 AUDIT DB DOES NOT CORRECT MISSING VOLUME ENTRIES AUDIT DB DOES NOT CORRECT MISSING VOLUME ENTRIES if an entry for the AS.Volume.Status table is missing. You will receive the following messages: ANR9999D asaudit.c(2333): Error 2 retrieving AS.Volume.Status entry for volume 20785. ANR9999D asaudit.c(1619): Error 267 checking volume occupancy. ANR4142I AUDITDB: Database audit process terminated in error. Since the audit terminates you will never be able to bring a system up after a load db which requires the audit unless there is a db backup. <@> IX87643 IMPORT NODE FAILS WHEN PROCESSING CLIENT OPTION SETS CONTAINING INCLEXCL OPTION Import not correctly processing Client Optionset INCLEXCL options when the option value contains embedded double quotes. To recreate: 1. define client option for 'INCLEXCL', e.g. def cliento testclo inclexcl "exclude *: WINNT Web *" force=yes 2. Assign a node to the option set 3. Export that node with option 'FILED=NONE' 4. Import the node again.You should receive following message: ANR0729E IMPORT NODE: Syntax error from command 'UPDATE CLIENTOPT TESTCLO INCLEXCL "exclude *: WINNT Web *" FORCE=Yes SEQNUMBER=0'. <@ IX87853: IF RECOVERY LOG COMMULATIVE CONSUMPTION IS GREATER THAN 1GB THEN A SELECT * FROM LOG WILL HAVE A BLANK FOR THIS FIELD. Customer issued: select * from log "query log" shows a value greater than 1 gb, but the "select" statement returned a blank. The precision of the CONSUMPTION_MB field has been extended to display terabytes. <@> IX88337 UNABLE TO DELETE A VOLUME WITH DISCARD = YES. ANR0104E ASALLOC.C (XXXX) ERROR 2 DELETING ROW FROM TABLE "AS.SEGMENTS". During deletion processing, errors can be encountered that can prevent the deletion from completing. In this case, an ANR9999D message is received that states the following: ANR9999D asalloc.c(xxx): Error 2 deleting row from table AS.Segments. This error can be received during expiration, delete volume processing, reclamation, delete filespace processing, or any other server processing that deletes files from the server. <@> IX88509 ALL DRIVES NOT BEING UTILIZED UNDER CONDITIONS OF HEAVY USAGE. When using ADSM with an external library manager, there is a potential problem where drives may not be utilized fully. This occurs when workload is heavy and the number of sessions needing drives is greater than the mountlimit defined for the devclass of the library. <@> IX88531: IMPROVE PERFORMANCE OF ALLOCATION OF 3590 DRIVES IN THE 3494 ADSM/6000 (5765-564) checks all available drive on a 3494 for availibility before using one of them. This results in unneeded wait time for mounting a volume. Today ADSM does 2 times a check for each available drive and one additional check on the selected drive. This results in our customer installation (with 4 drives) in mounttimes from 20 to 35 seconds for starting the roboter mechanics. Each check needs about 2 seconds , for our 4 drives is this 4 * 2 * 2 sec + 2 sec = 18 seconds only for checking the drives. If the customer would install 2 additional drives the mount times will be increased to 6 * 2 * 2 sec + 2 sec = 26 seconds. <@> IX88685 ADSM NOT CAPABLE OF READING TAPES WRITTEN BY THE 8500 MODEL TAPE DRIVE WITH THE 8900 MODEL TAPE DRIVE ADSM does not allow users to read cartridges written with 8500 and 8500C drives on their 8900 drives. <@> IX89120 API IS STARTING MORE THEN ONE SESSION. ADSM MOUNTS TAPES FOR EACH IF IT HAS A FREE MOUNT POINT. IBM INTERNAL DEFECT OPENED. API is starting more then one session before ADSM server has completely closed the first session. Because there are 2 sessions, ADSM allocates 2 mount points. So the result is that the "segments" are written in a "flip flop" manner across the 2 tapes. One session uses 1st tape, 2nd sessions uses 2nd tape. 1st session completes while 2nd session is still running. 3rd sessions uses 1st tape. 4th sessions uses 2nd tape and so on back and forth. In some cases, since there are multiple files "segments" backed up with 2 or more sessions, there is a significant amount of "flip flopping" going on. <@> IX89123: ADSM HANG WHEN STARTING DSMADMC. CPU UTILIZATION ALMOST 100%. DIRECTLY RELATED TO AIX V4.3.1 APAR IX88108. ADSM hangs and uses close to 100% cpu when attempting to store data to the ADSM server via an external library manager. <@> IX89599 ADSM V3 SERVER TERMINATES IF AN OPEN PARENTHESIS, ( IS ISSUED FROM AN ADSM ADMIN COMMAND LINE CLIENT One valid command syntax for server command routing to multiple ADSM servers is to prefix the command with the servername(s) in parentheses: (server1, server2) query status If the command entered is simple the open paren '(' then the ADSM server traps. <@> IX89604 ADSM RETRIEVE ORDER PROCESSING NOT OPTIMUM WHEN THE DISK STGPOOL IS NOT AVAILABLE FOR READONLY OR READWRITE STATES The retrieve order selection algorithm used when files are on DISK volumes was incorrect. The algorithm may either cause a non-optimized retrieve order for the files or it may cause the file to be reported as not available on the server <@> IX89637 RESTARTED RESTORE DOES NOT RESTORE UNVISITED FILES FOR PIT Client starts a (no query) restore specifying point in time. The restore is canceled. Later, the restore is restarted. The restarted process should resume restoring from the last check pointed object. But it does not restore the remaining objects. <@> IX89638 SERVER SHOULD NOT HOLD DUPLICATE OR UNREFERENCED ARCHIVE DIRECTORIES. If an archive copygroup specifies a long retention period (like 7 years or no limit), archive directories never expire even when all files that referenced them have been deleted or expired. Also, the Version 3 server holds multiple instances of the same archive directory. The server should not hold duplicate or unreferenced archive directories. <@> IX89672 EXPIRATION MAY TAKE AN EXCESSIVE AMOUNT OF TIME WITH THE PROCESSING OF VIRTUAL VOLUMES During expiration processing of virtual volume objects on a target server, the process control list used by expiration is not correctly filtering duplicate entries out of the list. Because of this, expiration may take an excessive amount of time as virtual volume objects are evaluated repeatedly. <@> IX89728 WITH ADSM SERVER 3.1.2.20 SERVER/CLIENT EVENTS ARE NOT LOGGED ON SNMP RECEIVER. AIX ADSM subagent (dsmsnmp) loops when contacted by an ADSM server. <@> IX88918 THE FIELD TO INPUT 'CLIENT OPTION VALUE' IS TOO SHORT IN THE WEB ADMIN CLIENT'S 'DEFINE A CLIENT OPTION' SCREEN. On the web administrator interface the define clientopt command has a field that is too small to correctly enter enough information. The parameter is client option value. The current length of the field is 30. <@> IX89553 THE OPERATIONS DROP-DOWN MENU IN THE 'CLIENT OPTIONS' SCREEN HAS AN ERROR IN THE TEXT "DELETE Q CLIENT OPTION" When using the Web Admin client an incorrectly worded option is displayed in the operations drop-down menu. The text is "Delete q client option" and should probably be "Delete a client option" You can get to this screen by selecting 'Object view' on the main Web admin screen ->select 'Clients' -> 'Client Option Sets' -> select an option set then click on the 'Client options' link. Select a client option then open the operations drop-down menu. <@> IY00281 RESTORE IS VERY SLOW - LARGE GAPS IN TRACE - HIGH CPU Customers experience long waits to restore objects when the no query or point in time restartable restore methods are used. Changes have been made to the backup query routine similar to those made for archive query (see apar PQ21142). This should improve performance for restartable restores from disk and point in time restores. <@> IX89554 WEB ADMIN DOUBLE QUOTES DON'T WORK: MUST USE SINGLE QUOTES Attempting to UPDATE STGPOOL and null out the value in NEXTPOOL. Documentation indicates must use double quotes(""), but it only works when use single quotes('') <@> IY00115 ANR9999D PSPVROPT.C (1064) OPTICAL DISK NOT VALID FOR THIS PRODUCT RECEIVED WHEN LABELING OPTICAL PLATTERS ADSM server issues an extraneous diagnostic message when labeling an unlabeled optical disk. <@> IY00126 DEFINITION MISSING IN AIX.ADSM.DEFS Prior to this line in /etc/mib.defs: ibmAdsmSevereMessage ibmAdsmMIBMessages.1 Aggregate read-only mandatory (both of the last two lines are on one line in the file) insert this line: ibmAdsmMIBMessages ibmAdsmMIBTraps.1 Aggregate read-only mandatory (The above two lines are on the same line in the file). <@> IY00628 THE OUPUT OF A 'QUERY CONTENT ' RESULTS IN GARBARGE IN THE "CLIENT'S NAME FOR FILE" FIELD IS BACKED UP WITH OPENEDITION CLI 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. <@> IY00629 ADSM V3 EXPIRATION PROCESSING PERFORMANCE IS SLOW. OTHER ADSM PROCESSES MAY STALL OR STALL EXPIRATION WAITING ON LOCKS. The server expiration algorithm performance has been degraded relative to expiration performance prior to this server level. The performance degradation is the result of the fix for IX81990. This fix corrected a situation in expiration where it could skip deleting files that were actually eligible for expiring. This skipping of files could cause the server db utilization to grow. This fix caused the performance to degrade because MORE database entries needed to be evaluated to insure that all necessary files were being evaluated and expired as needed. The fix for apar IX81990 is valid and the increased number of files to be evaluated can not be avoided. <@> PQ24144 USING MICROSOFT ACCESS TO LINK THE ACTLOG TABLE AND USING THE DATE_TIME CRITERIA IN THE QUERY WILL ERROR WITH ANR2910E. ODBC specifications that use the {t, {d, {ts or {fn statements are not recognized by the ADSM server. <@> PQ25365 ANR0104E ASVOLUT(1592): ERROR 2 DELETING ROW FROM TABLE ANR9999D AFMIGR(472): ERROR CHECKING PENDING VOLUMES FOR If a volume is emptied while a process or user is using or waiting to use the volume, the volume can wind up in an incorrect state in the database. <@> IC22333 VERSION 3 NT SERVER UTILITIES VOLUME FORMATING GUI FAILS TO MAKE THE VOLUME IF THE NAME GIVEN IS NOT 8.3 COMPLIANT The utilities GUI for defining new disk pool volumes does not accept file names that violate 8.3 naming conventions. . A file name of xxxxxxxxx.dsm (9 places before the .) will cause an error "filename already exists". the same for xxxx.xxxxx (more than 3 characters after the .) A special case is some commands with an _ underscore in the name will produce an error message box with these errors: ANS5100I Session established with server windows NT ANS5101I Server command: define volume diskpool datax.dsm ANR2404E Define Volume: Volume VERSION 3 NT SERVER UTILITIES VOLUME FORMATING GUI FAILS TO MAKE THE VOLUME IF THE NAME GIVEN IS NOT 8.3 COMPLIANT ANS5103I Highest return code was 14 The name of the volume C: winnt system32 DATAX.dsm is always the same no matter what was entered for the name in the field. <@> IC23556 ADSM V3 SERVER HANGS FOR NO APPARENT REASON. RELATED TO DEVICE ERROR MESSAGE, NO SCRATCH TAPES, ETC. NOT CONSISTENT. <@> IC23794 RESTORE FAILURE ON OPTICAL DRIVE WITH ANR999D PSPVROPT.C(XXX): PVRODSKREAD: NONRECOVERABLE ERROR ODSKRC=8 Users can backup and restore files except not able to restore the last file that has been written to the platter. The following messages will be displayed on the console: pspvropt.c(569): PvrODskRead: Nonrecoverable error odskRC = 8 pvrodsk.c(1399): Illegal block offset for ODSK volume WORM01: pos=nnnnnnnnn <@> IC23898 "DSMSERV DISPLAY" COMMANDS CAUSES CORE DUMP ON SUN SOLARIS AND "APPLICATION ERROR" ON ADSM NT SERVER.LEVEL V3.1.2.20 During a restore attempt of a Sun Solaris ADSM server at v3.1.2.20, it was determined that the volume history file was not present. When attempting to use the "dsmserv display dbb" command to search for a dbbackup tape in a 3494, the customer received a core dump... <@> PQ20338 ADSM PREEMPTION PROCESSING INVOLVING SEQUENTIAL VOLUME (TAPE) PROCESSING CAN HANG SESSION, PROCESS AND THE SERVER IF HALTED. A session auxiliary thread can "hang" under certain conditions when a tape mount request is canceled before the mount is satisfied. This will cause a session or process to "hang" until the server is halted. At termination, the ADSM server address space will go into a wait state until the session "hang" is cleared. This will never happen at termination so the only way to terminate the server is to cancel the ADSM server job. <@> PQ22686 CP COMMAND DEFINE GRAF DISABLED RESULTING IN A LOOP IN ADSM VM V3 SERVER. A loop existed when defining GRAF devices for the 3270 dial-in support. The loop was the result of the GRAF operand not being valid for the CP DEFINE command. The operand was disabled to prevent the definition of GRAF devices on the the customer's VM system. <@> PQ23494 MVS 3.1.2.1 WEBADMIN MAY LOOP WHEN ADSM COMMUNICATION DRIVER RETURNS A "1" INSTEAD OF A "-1". Loop during Web client session over TCPaccess when error occurs on TCPaccess read(). <@> PQ23528 ADSM MVS 3.1.2.0 SERVER MAY PROGRAM CHECK WITH ABEND SOC4 WHEN RECLAIMING A COLLOCATED VOLUME AT UPDATERELOCATEBITFILE. <@> PQ24435 ABEND0C4 RECLAMATION ANR1175W ADJUSTCOUNTER PVRCLOSEMP COPYMPDESC The ADSM/MVS or ADSM/VM Server may program check in one of the collowing functions, AdjustCounter, PvrCloseMp or CopyMpDesc during reclamation. The follow message usually precedes the program check and subsequent ABEND. . ANR1175W Volume .... contains files which could not be reclaimed. THIS IS A DUP OF PQ23528 <@> PQ26773 ADSM INFOSPEED COMMUNICATION SUPPORT New communication method. See ADSM for MVS server PTF service level 3.1.2.30 README file in ADSM.SAMPLIB(ARN3310) <@> IC23919 THE SESSION STATISTICS FOR CLIENTS ARE NOT DISPLAYED PROPERLY VIA THE WEB ADMIN. The session statistics for Clients are not displayed correctly when viewed via the Web Admin interface. Issuing QUERY NODE F=D from an Administrative command line session will show the statistics for each node's last session with the ADSM Server. These statistics can also be viewed from the Web Admin, however, the results are inacurrate. <@> IY00039 ADSM CLIENT RESTORE/RETRIEVE FAILS WITH ANS4032E ON DATA THAT WAS EXPORTED FROM ONE V3 SERVER AND IMPORTED TO ANOTHER If data was exported using server level 3.1.2.20 and it subsequently imported, when a client tries to retrieve or restore a file they will receive the following message on the client: ANS4032E Error processing 'fileName': file is not compressed. <@> IX87842 FILES ARE NOT RESTORED TO THE RIGHT LOCATION ON A HSM MANAGED FILESYSTEM UNDER CERTAIN CIRCUMSTANCES Files are not restored to the right location on a hsm managed filesystem if it is migrated and after moving the file within the filesystem, performing an incremental, deleting the file a no-query-restore is performed. <@> IX87647 THE SSI EXECUTABLE SUPPLIED WITH ADSM CAN CORE DUMP ON AIX 4.3 The ssi supplied executable can coredump on startup when run on an AIX 4.3 system. The renders the dsmserv executable unable to contact the ACSLS environment. <@> $$ SYSROUTES ------------ APAR Sysroutes for Service Level 3.1.2.30 IC23794: IC23935(N/T),IC23794(SUN) IC23500: IX89534(AIX),IC23748(N/T),IC23749(HP),IC23500(SUN) IC23556: IC23667: IX89544(AIX),PQ26136(MVS),IC23750(N/T),IC23751(HP),IC23667(SUN) IX84425: IX86299: IX86299(AIX),IC23752(N/T),IC23753(HP),IC23754(SUN) IX86321: IX86321(AIX),PQ26137(MVS),IC23755(N/T),IC23756(HP),IC23757(SUN) IX87017: IX87017(AIX),PQ26140(MVS),IC23758(N/T),IC23759(HP),IC23760(SUN) IX87338: IX87338(AIX),PQ26943(MVS),IC23936(N/T),IC23937(HP),IC23938(SUN) IX87389: IX87389(AIX),IC23481(N/T),IC23482(HP),IC23483(SUN) IX87406: IX87406(AIX),PQ26147(MVS),IC23763(N/T),IC23764(HP),IC23675(SUN) IX87630: IX87630(AIX),PQ25523(MVS),IC23604(N/T),IC23605(HP),IC23606(SUN) IX87643: IX87643(AIX),PQ26944(MVS),IC23939(N/T),IC23940(HP),IC23942(SUN) IX87853: IX87853(AIX),PQ24924(MVS),IC23478(N/T),IC23479(HP),IC23480(SUN) IX88337: IX88337(AIX),PQ27250(MVS),IC24012(N/T),IC24013(HP),IC24014(SUN) IX88509: IX88509(AIX),IC23766(N/T),IC23767(HP),IC23768(SUN) IX88531: IX88531(AIX),IC23769(N/T),IC23770(HP),IC23771(SUN) IX88685: IX88685(AIX(,IC23772(N/T),IC23773(HP),IC23774(SUN) IX89120: IX89120(AIX),PQ26149(MVS),IC23775(N/T),IC23776(HP),IC23777(SUN) IX89123: IX89599: IX89599(AIX),PQ27279(MVS),IC24023(N/T),IC24024(HP),IC24025(SUN) IX89604: IX89604(AIX),PQ26947(MVS),IC23943(N/T),IC23944(HP),IC23945(SUN) IX89637: IX89637(AIX),PQ26948(MVS),IC23946(N/T),IC23947(HP),IC23948(SUN) IX89638: PQ14789: IY00628(AIX),PQ14789(MVS),IC24015(N/T),IC24016(HP),IC24017(SUN) PQ22686: PQ23494: PQ23825: IX88918(AIX),PQ23825(MVS),IC23601(N/T),IC23602(HP),IC23603(SUN) PQ23827: IX89553(AIX)PQ23827(MVS),IC23778(N/T),IC23779(HP),IC23780(SUN) PQ24630: IY00281(AIX),PQ24630(MSV),IC23955(N/T),IC23956(HP),IC23957(SUN) PQ25365: PQ25675: IX89554(AIX),PQ25675(MVS),IC23781(N/T),IC23782(HP),IC23783(SUN) SA80257: SA80726: SA80989: IC23794: IC23935(N/T),IC23794(SUN) IX89672: IX89728: IY00115: IY00126: PQ23528: PQ26279: IY00629(AIX),PQ26279(MVS),IC24018(N/T)IC24019(HP)IC24020(SUN) IC23898: PQ20338: PQ24144: PQ26773: IC23919: IC22333: IY00039: IX87842: IX87647: