======================================================================= IBM ADSM for Windows NT -- Read1st File Includes information for: ATTENTION: Fixtest Version 3.1.2.57 ADSM for Windows NT Server Version 3.1.2.50 PTF IP21879 Win32 Client Version 3 Release 1, Level 0.7 PTF IP21618 (Intel) PTF IP21619 (DEC Alpha) Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1990, 1999. All rights reserved. Welcome to the ADSTAR(*) Distributed Storage Manager. Changes made for serverice level 3.1.2.50 are inidcated by "|" I. ADSM SERVER o 3.1.2.57 Fixtest Issues | o New server options | o New Parameters for the QUERY SESSION command | o New parameters for the SETOPT Command o Archive directory cleanup fix for pre-V3 entries o Correct to final inactive copy delete by expiration processing o Long File Name support for ADSM Novell Netware clients o CONVERT USSFILESPACE Utility o Support for IBM 3590 Model Exx Tape Drives o Tivoli Ready Enablement o 8900 8 MM Tape Drive Support for 8500 formats o Password expiration enhancement o CANCEL EXPIRATION command o Archive Description Rebinding o DRM scripts for Y2K support o New Parameter for Expire Inventory Command o Backup Recommendation o New server security option o New Licensing information o Notice for WEB browser users o Notes for use of the SNMP sub-agent (dsmsnmp) o Migration by age limitation o Migration by Age from Random Media o Drive Cleaning support for SCSI tape libraries o CHECKIN and LABEL command changes o Information on Data Errors in prior levels of ADSM Version 3 | o APARS fixed by this service level (3.1.2.50) II. ADSM CLIENT o Before You Install Your ADSM Client o Installing the ADSM Client o Late-Breaking News o Getting Help o Trademarks o APARs fixed by this PTF III. ADSM INFORMATION o Where to find Documentation o Getting Help o Trademarks Items in this README which have been added or changed since the last EMERGENCE FIX or Normal service level are marked with change bars ('|') in the left column. ======================================================================== FIXTEST ISSUES: Testing has focused on the corrections made for the following items. ------------------------------------------------------------------------- Licensed Materials - Property of IBM (C) Copyright IBM Corporation 1990, 1999. All rights reserved. ------------------------------ ATTENTION -------------------------------- This is a service PATCH based on certified service level 3.1.2.50. ------------------------------------------------------------------------ Testing has focused on the corrections made for the following items. ------------------------------------------------------------------------- o IY06424 - ANR9999D ERROR POSITIONING SERVER VOLUME FOR VIRTUAL VOLUMES AFTER DEFAULT MANAGEMENT CLASS CHANGES If the default management class on the target server for the node representing the source server is changed, any data for virtual volumes previously stored on the target server will not be addressable. Specifically, the virtual volumes on the source server will exhibit errors positioning on the virtual volumes that have archive files bound to the previous default management class. ----------- o IY07203 - RETRIEVING FILES THAT SPAN SIDES OF OPTICAL MEDIA FAILS. When a file that is stored on optical media and spans sides media there is a possiblity that retrieving the file may fail. ----------- o IY07233 - WEB ADMIN SUGGESTS INCORRECT BEGINDATE WHEN SELECTING 'OBJECT VIEW' / 'SERVER' / 'ACTLOG' When selecting 'OBJECT VIEW' / 'SERVER' / 'ACTLOG' from Web Admin, the suggested begin and end dates are for the current month plus one. Example: on 01/06/2000 the suggested date is 02/06/2000 ----------- o IY07355 - PARTIAL OBJECT RETRIEVE MAY SEND LESS BYTES THAN REQUESTED Partial object retrieves would fail given certain offsets. ----------- o IY07452 ANR8469E DISMOUNT OF VOLUME VOLUMENAME FROM DRIVE DRIVENAME IN LIBRARY LIBRARYNAME FAILED If a customer restarts the server while there are tapes mounted in the drives, the server is not able to empty the drives. ----------- o IY07501 ADSM HANGS DURING EXPIRATION. The server may hang during expiration processing. This problem occurs when any of the following messages are issued AND the server has to evaluate different policy information for files within the current selected group for expiration. The messages that are seen than may indicate the hang are the following: ANR0830W, ANR0831W, ANR0832W, ANR0833W, ANR0886E, or ANR0887E. ----------- o PQ31769 ADSM SERVER NETWARE RESTORE ANR9999D SMNQR(235): INVALID OBJECT HEADER STATE IN RETRIEVE OPERATION FOR SESSION During no query restore operations, the restore may fail with an ANR9999D SMNQR(235) Invalid Object Header State in retrieve operation for session..... A logic error occurred in the server did not reset certain control information following a sink error. As a result the above message was issued due to the object header size being incorrect. ----------- o IY05753 HIGH CPU USAGE CAN RESULT IN THE BUFFER PRE-FETCHER UTILIZING LARGE SUMS OF REAL MEMORY Data base buffer prefetcher can use too much memory if the thread servicing the prefetch requests can not service the requests as fast as the other threads in the server can create the requests. ----------- IY07513 MEMORY LEAK IN ADMNODES_CLOSE A SQL query of nodes will cause a small memory leak. ----------- IY07515 THERE IS A MEMORY LEAK IN ADMQUERYNODE Over an undetermined amount of time QUERY NODE can use memory for building a domainlist, but is never freed. We free the mem ory upon failure of the query, but we don't otherwise ----------- IY07663 SOME CLIENT SESSIONS BECOME "STUCK" ON THE SERVER. THEY CAN NOT BE CANCELED, SERVER RESTART NEEDED TO CLERE THESE SESSIONS Clients performing backup/archive operations can hang if an error occurs during a read verb opertion on the server. ----------- IY06778 MULTITHREADED EXPIRATION RUNS VERY SLOWLY, BITFILES EXAMINED INCREMENT VERY SLOWLY The expiration algorithm has been altered to improve it's performance while expiring archive files and directories. In addition, a new parameter has been added to the "EXPIRE INVENTORY" command. The parameter is "SKIPDIRS". The minimum abbreviation is the first two letters of the parameter or just "SK". The parameter accepts either a "YES" or "NO" for the value. So, to specify this parameter on the "EXPIRE INVENTORY" command, examples are: "EXPIRE INVENTORY SKIPDIRS=YES" In this case, expiration would run and for any DIRECTORY type objects stored on the server, expiration would skip those objects. So, even if the directory was eligible to be expired based upon the policy criteria, the object would be skipped because this parameter was specified. "EXPIRE INVENTORY SKIPDIRS=NO" In this case, expiration will process as it does today - it will expire any possible files or directories based upon the appropriate policy restraints. By allowing expiration to skip directories this will help customers to keep reclamation processing working. Typically, the file objects are likely to be taking up space on sequential media (where this is the storage pool configuration that a customer is using.). By allowing expiration to expire the file objects, we free up more of the sequential media space and allow reclamation to continue having tapes to reclaim. ----------- IY03390 SERVER HANG DURING BACKUP STORAGEPOOL IF WAIT=YES OPTION IS USED The processing for BACKUP STORAGEPOOL with the WAIT=YES parameter may hang and/or abend the server. ----------- IY03818 ADSM UNNECESSARILY DISMOUNTS VOLUMES AT END-OF-TAPE PROCESSING During the storing of large client files, if the volume became full the ADSM server would fail the mount of the next volume because the mountwait flag from the client had been reset to false; even though at the beginning of the session the client had set the flag to true. ----------- IC25868 ADSM SERVER IGNORES THE SEARCH=BULK PARAMETER ON THE LABEL LIBVOLUME COMMAND FOR 3494 LIBRARIES The server does not correctly perform the following command syntax checking for the CHECKIN LIBVOLUME command: 1) The SWAP parameter is only valid with the SEARCH=NO option. 2) The SEARCH=BULK option only applies to SCSI libraries. 3) The CHECKLABEL=BARCODE option only applies to SCSI libraries. 4) On SCSI libraries, the customer must specify CHECKLABEL=YES or CHECKLABEL=BARCODE when using SEARCH=YES. For the LABEL LIBVOLUME command: 1) The SEARCH=BULK option only applies to SCSI libraries. ----------- PQ36581 ANR9999D ANR0530W CONCURRENT SERVER TO SERVER SESSIONS FOR SAME SERVER NODE When using virtual volumes between a source and target server, there is a timing issue where a locking failure on the target server may occur. ----------- IY09418 DOUBLE SIDED MEDIA NOT TRACKED PROPERLY DURING RECONSTRUCTION Double-sided media (optical, in this case) are not properly handled during reconstruction of a bitfile that scans the sides of an optical platter and the following error messages are sent: ANR9999D asrtrv.c(563): End reached prematurelyon vol XXXX ...and after running audit reclaim; ANR9999D ssrecons.c(2210): Invalid magic number found inframe header ----------- IY09602 SERVER MAY CRASH IN TBPREFETCHTHREAD() IF A SECOND TBVAR STRUCTURE GETS CREATED Server may crash in TbPrefetchThread() due to a NULL pointer write which got returned from HashFindPrefetch(). The problem is caused by the initialization of the TBVars structure. There is a timing window wherethis problem can occur because it is possible for a second TBVars structure to be created, in effect, losing the pointer to the previous hash list. ----------- PQ36886 SERVER DATABASE DEADLOCK SITUATION WHEN TRYING TO WRITE VOLUME HISTORY - MIGRATION & RECLAMATION ARE RUNNING AT THE SAME TIME. ANR0390W A server database deadlock situation has been encountered: lock request for transaction x:xxxxxxxx will be denied to resolve the deadlock. ANR9999D ICUTIL(1515): Lock acquisition (sLock) failed for icvhVolumeType 4. ANR4513E A database lock conflict was encountered in processing sequential volume history information. ANR4510E Server could not write sequential volume history information to 'ADSM.SER1.VOLHIST.DATA'. Slip dump on the ANR9999D ICUTIL message was analyzed and was determined that there were a number of migration and reclamation processes running at the time of the failure. A migration process holds IC_LOCK_VOLTYPE volume type=icvhStgNew. The SsAuxThread for this process is waiting for the IC_LOCK_VOLTYPE volume type=icvhStgDelete under that same transaction. One of the reclamation processes holds the IC_LOCK_VOLTYPE volume type=icvhStgDelete and requested the IC_LOCK_VOLTYPE volume type=icvhStgNew. If this request were granted, it would result in a deadlock. ----------- IC25945 OPEN DEVICE DESCRIPTORS INHERITED BY CHILD EMM PROCESS A problem has been encountered with the Solaris version 3.1.2.50 of the ADSM server. The server is using an ADIC library defined as an external library. Whenever ADSM creates an EMM process to initiate a mount, any open tape device in the adsm server are inherited by this child process. This is a problem when an open device is later dismounted and then reused by adsm, as the EMM process holds the device open and the new open fails with EBUSY (device busy) until the EMM process completes and exits or is killed. If adsm forks the external library manager in psExtLibProcessInitialize() it closes all file handles having file descriptors between 3 and 63 (which is the value of OPEN_MAX defined in limits.h). This is to prevent the child process from inheriting these handles and runing into the problem described above. However, there can be handles above OPEN_MAX if the ulimits are changed to a higher value. ----------- IY08870 ANR9999D AFMIGR.C(2805): ERROR DELETING TRANSACTION FOR 0 BYTES MOVED RECLAMATION, PROCESSING COPY STORAGE POOL VIRTUAL VOLUME During reclamation of copy storage pool volume using ADSM/TSM server to server virtual volumes ANR9999D afmigr.c(2805): Error deleting transaction for 0 bytes reclamation is received. The problem appears to occur against a newly defined virtual volume that was to be used as the output for a full virtual copy storage pool volume being reclaimed. However this new output volume was really never used because the needed primary storage pool volumes were not available (checked out of the library in this case). When this reclaim failed the newly defined volume was not delete but left a full and 100% reclaimable. A query content showed nothing on the volume. This problem can and has been recreate by doing the following: 1) A copy storage pool virtual volume on the source server needs to be reclaimed. 2) The primary storage pool volume with the data needed for the reclaim is checked out of the library. 3) When reclamation starts a new copy storage pool volume is created/defined on the source server and a message to checkin the needed primary pool volume is issued. 4) If the needed primary storage pool volume is not checked in by primary storage pool volume as unavailable, and retry in 60 seconds. 5) At this point the new copy storage pool virtual volume is still defined as an empty volume on the source server. 6) At the 60 reclaim retry point the reclamation begins and complete successfully this time using getting the data from the copy storage pool and using the new volume defined in point 3 as 7) After this reclamation has completed a reclamation for this new volume suddenly kicks off and the anr9999d from afmigr is received. ----------- IC26881 LABEL LIBVOLUME W/ OVERWRITE=YES CAN OVERWRITE THE LABELS OF VOLUMES THAT ARE PART OF A STORAGE POOL AND HAVE DATA. The ADSM/TSM server may re-label a volume defined to a storage pool or in the volume history file under the following conditions: 1) The user specified the OVERWRITE=YES option in the LABEL LIBVOLUME command. 2) The volume defined to the storage pool or in the volume history file was either checked out or moved to a previously empty slot within the library. ----------- This service PATCH also includes fixes for the following defects which were found during the current development cycle : o 23633 - vols not labeled w/ ACSLS 5.3.2 o timer - Increase 3494 drive sharing polling loop timeout value ----------- =============================================================== END FIXTEST Issues =============================================================== *********************************************************************** I. ADSM SERVER | ---------------------------------------------------------------------- | New server options | ---------------------------------------------------------------------- | LOGWARNFULLPERCENT | | Specifies the log utilization threshold at which warning messages | will be issued. | | Syntax | +------------------------------------------------------------------+ | | LOGWARNFULLPercent | percent | | +------------------------------------------------------------------+ | | Parameters | percent Specifies the percentage of log utilization | at which warning messages will begin. | After messages begin, they will be issued for | every 2% increase in log utilization until | utilization drops below this percentage. | | The default value is 90% | The mininum value is 0% | The maximum value is 98% | | Examples | LOGWARNFULLPERCENT 60 | | ====================================================================== | THROUGHPUTTIMETHRESHOLD | | Specifies time threshold for a session after which it may be cancelled | for insufficient throughput. | | Syntax | +------------------------------------------------------------------+ | | THROUGHPUTTimethreshold minutes | +------------------------------------------------------------------+ | | Parameters | minutes Specifies the threshold for examining client | sessions and cancelling them if the throughput | threshold is not met ( see the | THROUGHPUTDATATHRESHOLD option ). | This threshold does not include time spent | waiting for media mounts. | The time threshold | starts at the time a client sending data | the server for storage ( as opposed to | setup or session housekeeping data ). | A value of 0 prevents examining client sessions | for insufficient throughput. | | The default value is 0 | The mininum value is 0 | The maximum value is 99999999 minutes | | Examples | THROUGHPUTTIMETHRESHOLD 90 | Wait until 90 minutes ( plus media wait time ) | after a session has started to | examine it as a candidate for cancellation due to low | throughput. | | ======================================================================= | THROUGHPUTDATATHRESHOLD | | Specifies throughput threshold that a client session must achieve to | prevent being cancelled after THROUGHPUTDATATHRESHOLD minutes ( plus | media wait time ). The time threshold starts at the time a | client sending data the server for storage ( as opposed to setup or | session housekeeping data ). | | Syntax | +------------------------------------------------------------------+ | | THROUGHPUTDatathreshold kilobytespersecond | +------------------------------------------------------------------+ | | Parameters | kilobytespersecond Specifies the throughput that client | sessions must achieve to prevent cancellation | after THROUGHPUTTIMETHRESHOLD minutes have elapsed. | This threshold does not include time spent | waiting for media mounts. | A value of 0 prevents examining client sessions | for insufficient throughput. | Throughput is computed by adding send and receive | byte counts and dividing by the length of the | session. The length does not include time spent | waiting for media mounts and starts at the time | a client sends data to the server for storage. | | The default value is 0 | The mininum value is 0 | The maximum value is 99999999 kilobytes per second. | | Examples | THROUGHPUTTIMETHRESHOLD 90 | THROUGHPUTDATATHRESHOLD 50 | Wait until 90 minutes ( plus media wait time ) | after a session has started sending data for storage to | examine it as a candidate for cancellation due to low | throughput. If a session is not achieving 50 thousand bytes | per second in transfer rates, it will be cancelled. | | Note: Interactive sessions, i.e. command line and graphical interface | clients, will be affected by these parameters | as calculations are cumulative across multiple operations. | When a session is cancelled for being over the throughput time | threshold and under the throughput data threshold, the following | new message will appear: | ANR0488W Session xx for node yy ( zz ) terminated - transfer rate is less | than ww kilobytes per second and more than vv minutes have | elapsed since first data transfer. | xx = session number | yy = node name | zz = platform name | ww = transfer rate in kilobytes per second | vv = elapsed time since first data transfer | | ======================================================================= | QUERY SESSION COMMAND Changes | | Query SEssion [sessionnumber] [Format=Standard|Detail|Gui] | [ MINTIMethreshold=minutes ] | [ MAXTHRoughput=kBs ] | | The MINTIMethreshold and MAXTHRoughput parameters act as filters on the | QUERY SESSION output for client nodes. | They can be used to setup time and throughput thresholds with which to | automatically cancel sessions which have become a bottleneck to the server | by using the THROUGHPUTTIMETHRESHOLD and THROUGHPUTDATATHRESHOLD options. | | minutes - Only display sessions which have had at least this number of | minutes elapse from the time of first sending data to | the server for storage. | Minimum value is 1. Maximum value is 99999999. | kBs - Only display sessions which are transferring data at a rate less | than this parameter ( kilobytes per second ). | Minimum value is 0. Maximum value is 99999999. | | ======================================================================= | SETOPT COMMAND Changes. | | The SETOPT command access the following new parameters: | | LOGWARNFULLPERCENT | THROUGHPUTDATATHRESHOLD | THROUGHPUTTIMETHRESHOLD | | using the same values as described in the option sections above. | The same limits apply. The new parameter values take | effect immediately, and the parameters are written to the server options | file, as are all options modified with the SETOPT command. -------------------------------------------------------------- Correct to final inactive copy delete by expiration processing -------------------------------------------------------------- A problem has been identified with ADSM server expiration that impacts customers using the following server levels: 3.1.2.23 3.1.2.24 3.1.2.30 Please note that 3.1.2.23 and 3.1.2.24 were fixtest levels that had to be explicitly retrieved off index.storsys.ibm.com. The 3.1.2.30 level is the latest service level for the server available as of June 30, 1999. The problem documented by APAR PQ29033, is caused by a change made to expiration processing for improved performance. An unintended side effect of the change is that data that should be managed by the RETAIN ONLY parameter in the copy group may instead be managed by the RETAIN EXTRA parameter. This can cause incorrect deletion of file versions from the server. The expiration processing error occurs only under a specific combination ofconditions. 1) No active versions of a file exist on the server. 2) All of the inactive versions of the file have been inactive for at least the number of days equal to the RETAIN EXTRA parameter value. 3) Expiration is not run frequently. To help prevent the error from affecting the data on a server, you can do the following: 1) Prevent expiration processing from running. Set the server option "EXPINTERVAL" to zero (0). This disables automatic expiration. This requires the server to be halted and restarted in order to acknowledge the new expiration interval. Also any scheduled server administrative commands to run expiration should be disabled. 2) Set the "RETAIN EXTRA" value to "NOLIMIT" in the needed copygroups and reactivate the server policy sets. This will prevent expiration from incorrectly deleting files until the fixed server is available. This would also allow limited expiration to be performed. Specifically, expiration would still be done for backup files that exceed the "VERSIONS EXIST" policy attribute. To make this change, issue the following commands: - "update copygroup xxx yyy zzz RETEXTRA=nolimit" where xxx is a domain name, yyy is a policy set name, and zzz is a management class name. - "activate policyset xxx yyy" where xxx is the domain name and yyy is the policy set name referenced in the "update copygroup" command above. ****************************************************** The following example illustrates the problem. Assume the following situation: - source directory: "/data" - files in directory: "file1" - Policy attributes for test: --> Versions exist: 4 versions --> Versions deleted: 2 versions --> Retain Extra: 5 days --> Retain Only: No limit - Expiration processing is run irregularly and not every day (** Please note in the example below that the date format mm/dd/yy is used) The following sequence of events occurs: 1) On 07/20/99, the client performs an incremental backup of the directory (command: incremental /data/) - This results in two entries stored on the server, one for the directory and one for the file. Please note that the entry for "file1" is the active version of the file at this point. The timestamp for "file1" is 07/20/99 12:00:00. 2) The client updates "file1" 3) The client again performs an incremental backup of the directory (command: incremental /data/) - This results in one entry being sent to the server. In this case, the version of "file1" that was already on the server becomes inactive, and becomes the "oldest" inactive copy. The latest version of "file1" is now the active copy of the file with a timestamp of 07/20/99 13:00:00. 4) The client deletes "file1" from the directory. 5) For the third time, the client again performs an incremental backup of the directory (command: incremental /data/) - Because "file1" has been deleted from the client filesystem, the server marks the latest version of "file1" as inactive. The server now has two inactive versions of "file1". this happens on 07/20/99 sometime after 13:00:00. 6) Five days pass. Expiration processing is not run during this time. 7) Expiration is run on 07/25/99 at 14:00:00. With the current error in the server's expiration processing, the server incorrectly deletes both inactive versions of "file1". The server should recognize that the version with the timestamp 07/20/99 13:00:00 should be retained because it is the last copy of the file on the server (RETAIN ONLY parameter set to NOLIMIT). However, because of the error in the server, the server groups the inactive files together without evaluating whether one or more files may need to be managed by using the RETAIN ONLY parameter. The server incorrectly evaluates whether to delete the inactive files based only on the value of the RETAIN EXTRA parameter. Because both versions of "file1" have been inactive for 5 days (RETAIN EXTRA parameter), the server deletes them both. ********************************************************** Other factors that contribute to the processing error in this example are: - Expiration was run only periodically - in the example above, it was only run on 7/25/99. It was not run between 7/20/99 and 7/25/99. - All the versions of the file were eligible for deletion under the "RETAIN EXTRA" parameter. ********************************************************** The following example illustrates a situation where the server would handle the file versions correctly: - source directory: "/data" - files in directory: "file1" - Policy attributes for test: --> Versions exist: 4 --> Versions deleted: 2 --> Retain Extra: 5 --> Retain Only: No_Limit - Expiration is run each day at 20:00:00 and it runs to completion. The following sequence of events occurs: 1) On 07/20/99, the client performs an incremental backup of the directory (command: incremental /data/) - This results in two entries stored on the server. One for the directory and one for the file. Please note that the entry for "file1" is the active version of the file at this point. The timestamp for "file1" is 07/20/99 12:00:00. 2) The client updates "file1" 3) The next day, the client again performs an incremental backup of the directory (command: incremental /data/) - This results in one entry being sent to the server. In this case, "file1" that was already on the server is inactivated and becomes the "oldest" inactive copy. The latest version of "file1" is now the active copy of the file with a timestamp of 07/21/99 13:00:00. 4) The client deletes "file1" from the directory 5) On 7/22/99, the client performs an incremental backup of the directory (command: incremental /data/) - This results in the active version of "file1" being deactivated as there is no longer a version of the file on the client filesystem. Please note that there are now no active copies of the data on the server. Please note that this happens on 07/22/99 sometime after 13:00:00. 6) Expiration runs normally on 07/25/99 at 20:00:00, in this case, the oldest inactive file (the file with timestamp 07/20/99 12:00:00) is deleted. It is eligible for deletion because the "RETAIN EXTRA" value of 5 days indicates that this file should not be kept after 5 days. Please note that at this point, the copy of "file1" with the timestamp 07/21/99 13:00:00 is not eligible for expiration. 7) Expiration runs normally on 07/26/99 at 20:00:00. In this case, it determines that the copy of "file1" with timestamp 07/21/99 13:00:00 is the ONLY version of the file on the server. It now correctly manages the file using the "RETAIN ONLY" parameter and will keep the file indefinitely. Reasons why expiration worked properly in this case: 1) All the versions of the file were not eligible for expiration at the time that expiration was run. 2) Expiration was run on a regular interval. ********************************************************* Long file name for ADSM Novel Netware clients ********************************************************* Ths service level of the ADSM server supports a function that enables long name support for ADSM Novel Netware clients. The function allows the Netware client to rename file that have been backed up to their long name representation instead of DOS files names (8.3). Please refer to the README file for the Netware client for more details on this. The client function is available in service level 7 (PTF7) for the version 3 product. ------------------------------- 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: Microcode level: 3590E - EC F23200 D01C_502 Tape formats for 3590E: - 3590E-B - uncompressed mode (similar to 3590B) - 3590E-C - compressed mode (similar to 3590C) - DRIVE - the most advanced available format Note: For 3590 and 3590E tape drives the most advanced formats are respectively 3590C and 3590E-C 1. All 3590 drives within physical library are upgraded with 3590E drives at the same time. Consider an example with one 3590 drive physically defined as mt0.0.0.2. Assume that there were originally defined devclass, logical library, and storage pool for 3590 drive. There were also some volumes (tape cartridges) checked in the library with data written on that drive. Replaced 3590 drive with 3590E drive. Steps below will allow you to use the new 3590E drives with minimum changes to ADSM server: - Run ADSM server (dsmserv); - Issue ADSM command: UPDate DEVclass devclassname FORMAT=DRIVE update devclass devclass_3590 FORMAT=DRIVE; - Issue ADSM command: DELete DRive libname drivename delete drive lib_3590 mt0.0.0.2; - Issue ADSM command: DEFine DRive libname drivename DEVIce=devicename define drive lib_3590 mt0.0.0.2 device=mt0.0.0.2; - Update all previously written on 3590 drive volumes to readonly mode update volume volname access=readonly; 2. Intermix of 3590 and 3590E drives in a single 3494 library environment. Consider an example of a physical library with one 3590 drive defined on mt3.0.0.2 and a new 3590E drive defined on mt0.0.0.2. Assume that there were originally defined devclass, logical library, and storage pool for 3590 drives. With addition of a new 3590E drive to the library that already has 3590 drives in it, new DEVCLASS, new logical LIBRARY, and new STORAGE pool MUST be defined. Defining new devclass, logical library, and storage pool for 3590E drive: DEFINE LOGICAL LIBRARY define library lib_3590E libtype=3494 device=/dev/lmcp0 privatecategory-lib_3590_private scratchcategory=lib_3590_private+3 DEFINE DEVCLASS define devclass devclass_3590E devtype=3590 format=3590E-C format=3590E-B format=DRIVE library=lib_3590E DEFINE STORAGE POOL define stgpool stg_3590E devclass_3590E other parameters Defining separate devclass for each type of drives will allow the user to specify the format for the drive and insure that 3590 volumes will not be mounted on 3590E drives and that 3590E volumes will not be mounted on 3590 drives. Defining a logical library for each type of drives will allow to define two separate storage pools of scratch volumes. It is necessary to allow write the label for the volume in the appropriate format. Moving a scratch volume from 3590 scratch pool to 3590E scratch pool: - ADSM command: CHECKOut LIBVolume libraryname volname REMove=No - ADSM command: CHECKIn LIBVolume libraryname SEARCH=Yes Note: In order to move volume from 3590 scratch pool to 3590E scratch pool issue above commands and RELABEL the volume after it has been checked in the 3590 library. IN ORDER TO READ THE VOLUME PREVIOUSLY WRITTEN IN 3590 FORMAT ON 3590E DRIVE (THE STORAGE POOL THAT OWNS THE VOLUME POINTS TO A DEVCLASS THAT USES 3590E drive): - UPDATE ACCESS MODE TO THAT VOLUME TO READONLY update volume volumename access=readonly; - CHECKOUT THE VOLUME FROM THE LOGICAL 3590 LIBRARY (THE DEVCLASS' OLD LIBRARY THAT HAD 3590 DRIVES); - CHECKIN THE VOLUME TO THE LOGICAL 3590E LIBRARY (THE DEVCLASS' NEW LIBRARY THAT CONTAINS 3590E DRIVES). 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 NT ------------------------------------------- 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 Tivoli Inventory, a directory on the ADSM server containing the ADSM Server Tivoli Ready signature file, dsmserv.exe, should be specified as a scanned directory in the Tivoli Inventory Profile used for software inventory scanning. This file is placed on the ADSM Sever as part of the installation. 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 following URL: http://www.support.tivoli.com/tme10gem/tivoli-ready 4) To enable the ADSM Server for 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 NT AMP file is: 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 ADSM 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 Enhancement ------------------------------- 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 a dministrator(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 delete 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----+ +-FIX=No|Yes----- | | +-JOBid=jobId-+ 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 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. --------------------------------------------- NOTES FOR USE OF THE 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 --------------------------- 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 ---------------------------------------------- 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. --------------------------------- 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. This parameter is optional. However, if specified the VOLRANGE parameter must not specified. ------------------------------------------------------------ Information on Data Errors in prior levels of ADSM Version 3 ------------------------------------------------------------ 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 -------------------------- * 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 RECLAMATION 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. WARNING: 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 THE 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. WARNING: 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. | -------------------------------------- | APARS fixed by service level 3.1.2.50 | -------------------------------------- | | IC23460 BACKUP SESSION WOULD FAIL WITH ANR0522W MESSAGE WHEN THE INPUT | While attempting to mount an output volume in a sequential- | access storage pool, the server may detect an error that | prevents usage of that particular volume. For example, an | error could occur in reading the volume label for an | intended output volume. When this occurs, the server usually | attempts to continue processing using another output volume. | However, when executing one code path, if the server detects an | error while mounting an output volume, the operation terminates | without trying other volumes. | | | IC24186 ADSM SERVER MAY ABEND INTERMITTENTLY WHEN USING THE SHARED MEMO | When share memory clients connect/disconnect from the ADSM | server, a list of sessions is maintained. However. update | to this list is not protected from multiple, simultaneous | updates, causing list corruption. | | | IC24676 ANR8829I REMOVE VOL FROM SLOT 30 OF LIBRARY | In the ANR8829I message, the ADSM server does not display | the element address of the Entry/Exit slot where it placed | the volume just checked out from the library with the | the CHECKOUT LIBVOLUME command and the REMOVE=BULK option. | The server reports the same element address (element address | of 30) each time. | | | IX89263 TILDE ( ) IN OBJECT NAME CAUSES INCORRECT OUTPUT | Form defaults that contain tilde character are incorrectly | displayed. The data can become corupt if the form is submited | without having the form data being corrected (by adding the | missing tilde character). For example, c:proga~1...* | becomes c:proga1...*. | | Form defaults that contain tilde character are incorrectly | displayed. The data can become corupt if the form is submited | without having the form data being corrected (by adding the | missing tilde character). For example, c:proga~1...* | becomes c:proga1...*.| | | | IY00238 ANR7837S INTERNAL ERROR KACZ003 DETECTED. | Under rare circumstances the server may abend during a | client backup/archive session with a KACZ003 signal. | | | IY00407 ADSM ADMIN COMMAND LINE CLIENT FAILS LOGIN WITH PASSWORD AUTHEN | The ADSM server does not report insufficient recovery log | space problems in a consistent manner. | | | IY00851 TEMPORARY FILES USED FOR SHM COMMUNICATION ARE NOT DELETED WHEN | Temporary files used by Shared Memory Protocol on AIX are not | always cleaned up. | | IY00887 ADSM WILL GENERATE ERRORS IF A RANDOM ACCESS STORAGE POOL IS DE| | | IY00978 WHEN CONFIGURING EXB230DLIBRARY, ADSM SERVER STATES THAT EXTEND | Problems: Library only needs basic license but code mistakenly r | advanced license | All Version 3 ADSM Device Dirver USers for the library | | Problems: Library only needs basic license but code mistakenly r | advanced license | All Version 3 ADSM Device Dirver USers for the library | | Problems: Library only needs basic license but code mistakenly r | advanced license | All Version 3 ADSM Device Dirver USers for the library | | | IY01493 ADSM SERVER MESSAGES CONCERNING POLLING OF INACCESSABLE DEVICES | The ADSM does not inform user when it starts and stops | polling devices. | | The opening text implies there are other problems: | "In reality it has been the library that was not | accessable and the server had been polling the | drive and is not no longer doing so. This code and | the associated messaging need to be reworked to handle | the inaccessability of a library and the polling of | the drives as originally designed." | | ADSM did detect a problem with the library. The user | response section for ANR8840E contains the following: | "Verify the library is online. Verify cable connections | between the library and the server." | | Instead of failing the operation right away, ADSM polls | the drives. The drives are the resources ADSM needs to | complete the operation. When it can communicate with the | drive, ADSM by extension can communicate with the library. | The current algorithm does handle the inaccessibility of | drives and libraries. | | IY01699 RECLAMATION FAILS WITH ANR9999D AFMIGR(2857) RESULT CODE 4 INTE | Reclamation fails with ANR9999D AFMIGR(2857) Result Code 4. | | IY01929 3590E SUPPORT WAS NOT PUT INTO MMSEXT.C.,THE DLT_8000 SUPPORT I | The interface in ADSM server to external library manager wasn't | updated with 3590E drive model support. | | IY02334 UPDATE LIBVOL CMD ALLOWS DB_BACKUP, DUMP OR EXPORT VOLUMES TO B | The user can update DB Backup, DUMP, EXPORT and Recovery | Plan File volumes to SCRATCH via the UPDATE LIBVOLUME | command. | | IY02438 WHEN AN ERROR IS DETECTED ON A TAPE VOLUME (3570 & 3590 DRIVES) | On 3570/3590 drives, ADSM marks a volume read-only to | prevent further writes if the internal drive diagnostics | have detected excessive media failures. Any other server | operations that use this volume will not start because | ADSM believes the volume is still in use. | | If the activity log contains ANR8830E and ANR8831W messages, | then the customer has encountered this problem. | | IY03236 WEB ADMIN: PASSWORD EXPOSED IN MSGS ANR2017I, ANR2148E, ANR2160 | Due to an error in the web administrator interface, when an | administrator is registered, the grant authority command exposes | the administrator password. The password is then stored in the | activity log. | | IY03313 CANNOT RESTORE FILES ON SUN | ADSM server cannot access data on Exabyte 8500 and Mammoth | drives due to missing ERP entries. | | IY04086 ACSLS LIBRARY INITIALIZATION WILL FAIL WITN ANR0104E ERROR 2 DE | The ACSLS initialization fails with the following errors: | | ANR8455E Volume VOLUMEX could not be located during audit | of library LIBRARY. Volume has been removed from the | library inventory. | | ANR999D mmacsls.c (7642): unable to delete inventory entry | for volume in library . . | ANR0104E mmslib.c(4096):Error 2 deleting row from table | "MMS.Lib.Inventory" | | where "VOLUMEX" contains the volume name and random | character(s). | | PQ26477 ABEND0C4 DEFINE UPDATE STGPOOL RECLAIMSTGPOOL VSPRINTF() | ABEND0C4 DEFINE UPDATE STGPOOL RECLAIMSTGPOOL VSPRINTF() | | PQ27180 ABEND0C4 ANRAQMUT PROTOCOL VIOLATION ANR0444W | occasional server crash | | PQ28538 SYSTEM HANG (DUMP) WHILE ADDING A NEW CLIENT OPTION (DEFINE CLI | String upper case function on non-NULL terminated string | result in server loop. | | PQ28620 ADSM/MVS EXPIRATION RECLAMATION HANG | | During reclamation if expiration deletes all remaining | active data from a volume when the server goes to | reclaim the next volume the server may abend. | | During reclamation if expiration deletes all remaining | active data from a volume when the server goes to | reclaim the next volume the server may abend. | | SA83714 ANR WEB ADMIN ICONS DO NOT DISPLAY WITH UPPERCASE ENGLISH | | IY03374 UNDER CERTAIN ERROR CONDITIONS WITH 3494, AN RC 11 IS RETURNED | This APAR documents a problem that occurs only on 3494 | libraries when the customer's USEREXIT forks a process. | | Background information leading up to the problem: | When ADSM calls close() to close a file handle to a drive, | the close() call returns a return code of 0 (success). | However, because the forked process inherited ADSM's open | file handles, the device driver never receives the close() | call. When ADSM calls open() to open a new file handle to | the same drive, the open() call returns a return code of 11. | | Description of the problem: | After receiving the errno=11, ADSM does not correctly | handle the error situation. As a result, ADSM may close | another process's file handle in error if there are at least | 11 open file handles. The number of open file handles depends | on the customer's environment and the amount of activity | at the time when the USEREXIT forked the new process. -------------------------------------------- APARS fixed by service level (3.1.2.42) ------------------------------------------- o Fix for APAR IY03251 o Fix for APAR IY00869 o Fix for APAR IY03199 (Database Repair Command for 3590E early support customers) o Fix for APAR PQ30157 o Fix for APAR IC24611 o Fix for APAR IY03618 o Fix for APAR IY00238 o Fix for Defect 22130 o Fix for Defect 20878 -------------------------------------------- APARS fixed by service level (3.1.2.41) -------------------------------------------- IY02546 ARCHIVE DIRECTORY CLEANUP UTILITY FAILS WITH ANR9999D The duplicate archive directory cleanup utility introduced by IX89638 fails when entries archived by a pre-Version 3 server are encountered. IY02372 VERSION 3.1.2.30 SERVER DOES NOT RECOGNIZE SONY AIT DRIVES The server does not correctly find AITC drives when there are requests to mount volumes in read-only mode. IY02438 WHEN AN ERROR IS DETECTED ON A TAPE VOLUME (3570 & 3590 DRIVES), ADSM MAY NOT RELEASE THAT TAPE: THE VOLUME WILL REMAIN "IN USE" A volume remains in use after ADSM marks it read-only due to excessive media failures reported by the drive diagnostics. IY01929 3590E SUPPORT INCORRECTLY ADDED FOR EXTERNAL LIBRARY MANAGER The External Library Manager Mount Requests fail on DLT drives. There is a syntax error in hte devicetypes parameter of the Mount Request. Service level 3.1.2.41 also includes fixes for the following device driver fixes. The device driver README files also include this information. IC24458 ILLEGAL REQUEST DURING READ ELEMENT STATUS AFTER STK 9710 FIRMWARE UPGRADE Additional data were returned from the Read Element Status command, causes incompatible storage allocation between the new firmware and the current ADSM device driver. The fix resolves the differences for 9710, 9714 and 9740 firmware upgrades. 20713 LABEL LIBVOL FAILS ON ELIANT 820 DRIVES The "Label Libvol" command fails with an I/O error when using Exabyte Eliant 820 drive. -------------------------------------------- APARS fixed by this service level (3.1.2.40) -------------------------------------------- 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. 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. IY00628 THE OUPUT OF A 'QURESTORE IS VERY SLOW - LARGE GAPS IN TRACE - HIGH CPU ERY CONTENT ' RESULTS IN GARBARGE IN THE "CLIENT'S NAME FOR FILE" FIELD IS BACKED UP WITH OPENEDITION CLI If data is backed up using an Open Edition client, a query backup will display correst filenames, but a query content on the server will print garbarge(ebcdic?) for the "client name for file" field. 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. IY0281 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. *********************************************************************** *********************************************************************** II. ADSM CLIENT Welcome to the ADSM Version 3 Client for Win32! The contents of this README file is listed below. You can use the FIND function of your favorite editor to locate information on a specific topic by using that topic's name as the search argument. For example, topic 2, "Installing the ADSM Client" has a sub-topic called "Uninstalling the Client". You can do a FIND on "Installing the ADSM Client" or "Uninstalling the Client" for further information on either topic (do not include the quotes as part of the search argument). This Readme is divided into the following sections: 1. Before You Install Your ADSM Client - Warnings - Client Components - Software Requirements - Hardware Requirements - Migration Information from Version 2 to Version 3 - Application Program Interface (API) - Enterprise Management Web Backup Archive Client 2. Installing the ADSM Client - Installing the Client - Setup - Uninstalling the Client 3. Late-Breaking News - What's New - Documentation Updates - Known Problems and Limitations 4. Getting Help - Online Help - Platform Specific Documentation - Product Documentation - Technical Support 5. Trademarks 6. APARs fixed by this PTF -------------------------------------- 1. Before You Install Your ADSM Client -------------------------------------- Warnings -------- - ************* If your current client version is 3.1.0.3 or lower, * IMPORTANT * existing filespace names will be migrated from volume ************* label names to Universal Naming Convention (UNC) names. While the migration is transparent, it will affect the way filespace names are specified, especially from the command line Backup-Archive client. It is IMPORTANT that you review the specifics of this change in the README.OLD file before installing and/or using this level of the client for the first time. - If you have file names with international characters (umlauts, accents, etc.) and you are upgrading from client version 3.1.0.5 or below (including version 2.1.0.x), then after applying this PTF you may experience the symptoms of APAR IC21764. The symptoms include many "ANS1304W Active object not found" messages during incremental backup for files with international characters in their names. A utility to fix this problem is available on our FTP site index.storsys.ibm.com. The directory is /adsm/fixtest/v3r1/win32/intel. The file names are: * IC21764L2.README.FTP * IC21764L2.README.1ST * IC21764L2.EXE You should not use this utility unless you are certain that you need to use it. In general, it is recommended that you use this utility only at the direction of IBM Service. If you think you are experiencing this problem, you should contact IBM before attempting use this utility. If you do have to use this utility, you must first read the information contained in IC21764L2.README.FTP and IC21764L2.README.1ST files. If in the past you have already run this utility and upgraded to version 3.1.0.6 of the client, then you do not need to run the utility again. Users who are installing ADSM on a machine for the first time (i.e. the machine has never been backed up before with version 3.1.0.3 or below) will not be affected by this problem, and do not need to run the utility. - In the installation image, SETUP.EXE has been moved from: ADSMCLI\WIN32\ to: ADSMCLI\WIN32\\DISK1 where is either INTEL or DECALPHA. - Prior to installing this package, you MUST shut down any existing ADSM applications that may be running. This includes (but is not limited to) the following: * ADSM Scheduler Service * ADSM Client Acceptor Service * ADSM Remote Client Agent Service If you try to install this package while the ADSM Scheduler Service is running, you will get a message stating that a read-only file was encountered. The program will ask if you want to replace anyway. If you say yes, the install will fail as the files cannot be overwritten while they are in use. If you say no, you run the risk of not having current versions installed. If you try to install this package while the ADSM Client Acceptor Service and/or ADSM Remote Client Agent Service is running, the installation will hang. The services may be stopped via the NET STOP command from an MS-DOS command prompt or via the Services applet (located in the Control Panel). - You must have Windows NT Administrator authority to install the ADSM Scheduler, ADSM Client Acceptor, and ADSM Remote Client Agent services on Windows NT. - If you uninstall any or all of the ADSM components, you MUST reboot the system before attempting to install any or all of the ADSM components. - Clients installed into the same directory must be uninstalled together; you cannot independently uninstall the backup-archive or administrator clients in this case. - To install from the '\adsmcli\win32' directory on the CD-ROM, you need approximately 30MB of free space in the Windows TEMP environment path and 2 MB of free space in the Windows SYSTEM directory. If the TEMP directory is on the same partition as the SYSTEM directory, you need 32MB of free space on that partition. The Install program checks for free space when it starts and exits with a message to the user if there is a problem. - If you are installing the ODBC component, you need an additional 1M of SYSTEM directory space. The install program checks for this amount of space, and lets the user know if there is a problem. - If you use the Lotus SmartCenter feature of Lotus SmartSuite, make sure you exit/stop this feature prior to installing. - Once the Window 32-bit Version 3 client has backed up or archived a file, all active files for that client cannot subsequently be restored or retrieved by a Version 2 client, regardless of the ADSM server version. See the Migration Section in the README.OLD file for more details. - Shell Extension Conflict (Windows NT 4.0 platform only) There is a rare possibility that during installation a message will be displayed indicating a Shell extension conflict. This is a result of a bug in the installation software used on most Windows 32-bit platforms. One product that we know encounters this conflict is IBM AntiVirus V2.5.2. The problem string will be displayed in the Warning message. The install then exits. There are a couple of ways to circumvent this conflict with the install: 1) Get a fixed level of the offending product and install it prior to installing ADSM. Example: If IBM AntiVirus Version 2.5.2 is the conflict, first install IBM AntiVirus Version 3 (or later), then install ADSM. 2) Uninstall the offending product (e.g. IBM AntiVirus Version 2.5.2), then install ADSM Version 3, then re-install the offending product. - Japanese characters are not displayed properly by the installation program. Use English characters for directory path and folders. - If a previous version is detected the path to that version becomes the default installation directory. - A warning is displayed if you install an additional copy of ADSM into a location other than the previous copy. - If a client has never been installed but there is an existing component it will be the default installation directory. - If the installation program detects existing ADSM environment variables which may conflict with the installation, a warning dialog is issued. - To completely UN-INSTALL a manual cleanup of options files that were generated by the clients is required after uninstall. These default files are located in the baclient and/or saclient directories. - The ADSM installation program creates one of two "sentinel" files following the completion of the installation program. The file will be created in the "base" directory of the ADSM installation (usually c:\win32app\ibm\adsm). If the installation completes successfully, then the file: "adsm.ok" is created. If the installation completes unsuccessfully, then the file "adsm.err" is created. Other programs may watch for creation of this file to determine if "silent" installations have completed. - View the README.OLD file for advanced installation considerations, including information on how to perform "silent" installs. Client Components ----------------- The table below indicates the components that are included with the ADSM Version 3 Client for Win32. The YES/NO column indictes whether the component is included. The CLI column indicates whether a Command Line Interface exists, and the GUI column indicates whether a Graphical User Interface exists. An 'x' under the CLI or GUI column indicates that the component has that kind of interface. For example, the Administrative Client CLI is available on both Intel and DEC Alpha platforms, while the GUI interface is available only on for Intel. +------------------------------------------------------------------------+ | | INTEL | DEC ALPHA | | COMPONENT NAME | YES/NO CLI GUI | YES/NO CLI GUI | +------------------------------------------------------------------------+ | Backup-Archive Client | YES x x | YES x x | | | | | | Administrative Client | YES x x | YES x | | | | | | Application Programming | YES | YES | | Interface (API) | | | | | | | | Web Client | YES x | NO | | | | | | ODBC | YES | NO | +------------------------------------------------------------------------+ See the text file PACKING.LST, located in directory \ADSMCLI\WIN32\, for a list of installed client files. Software Requirements --------------------- The ADSM Win32 Backup-Archive Client requires one of the following operating systems: - Windows 95(**) - Windows 98(**) - Windows NT(**) 3.51 (SP5 is recommended) - Windows NT(**) 4.0 (SP3 or higher is recommended) Hardware Requirements --------------------- Any appropriately configured Intel(**) 80386 or higher hardware platform with at least 16 MB of memory. The disk storage requirements for several installation options are listed below. For the purposes of this list, 1 MB is assumed to be 1,000,000 bytes. ADSM WINNT\SYSTEM32 INTEL DIRECTORY DIRECTORY TOTAL ---------------------------------------------------------------------- Full install (all languages) 75.5 MB 1.2 MB 76.7 MB Full install (one language) 27.7 MB 1.2 MB 28.9 MB Typical install 26.1 MB 1.2 MB 27.3 MB Compact install 11.0 MB 1.2 MB 12.2 MB ADSM WINNT\SYSTEM32 DEC ALPHA DIRECTORY DIRECTORY TOTAL ---------------------------------------------------------------------- Full install (all languages) 51.8 MB 1.3 MB 53.1 MB Full install (one language) 23.0 MB 1.3 MB 24.3 MB Typical install 21.5 MB 1.3 MB 22.8 MB Compact install 10.9 MB 1.3 MB 12.2 MB Migration Information from Version 2 to Version 3 ------------------------------------------------- See historical readme file README.OLD. Application Program Interface (API) ----------------------------------- See readme file API.TXT. Enterprise Management Web Backup Archive Client ----------------------------------------------- See readme file WEBCLI.TXT. ----------------------------- 2. Installing the ADSM Client ----------------------------- Installing the Client --------------------- 1. Run setup.exe from the '\adsmcli\win32\\disk1' directory on the CD-ROM. 2. You may now specify a directory to install ADSM. 3. You may now choose a Compact, Custom or Typical install: a. Compact: installs the Backup-Archive client and the Web client. This installation option requires 18MB of disk space. b. Custom: installs the components you select. c. Typical: installs the following: - Backup-Archive Client - Administrative Client - Web Client - Scheduler and Web Client services (NT only) - ODBC support - HTML help - Multimedia A Full install (all components) requires 33MB of disk space. 4. If you select Custom install, you can select which ADSM language support files to install. Regardless of which install method you choose, the U.S. English language files are *always* installed. 5. Select the Program Folder where you want the ADSM icons to be installed. 6. If you have chosen to install both the backup-archive client and the administrative client, you will be given the option to install both clients into a single directory or separate directories. If you choose to install into a single directory then the clients will share an options file. Clients installed into a single directory must be uninstalled at the same time; you cannot independently uninstall the backup-archive or administrative clients, unless they are in separate directories. Note: Existing options files are preserved and the new options file is saved in the appropriate directory with a name of dsm.new. Setup ----- Additional Setup Considerations ------------------------------- - APPC support requires Microsoft SNA Server Version 3. Note that Microsoft SNA Server Version 3 requires an intermediate Windows NT server. See diagram below: +---------------+ +------------+ +--------+ | MS SNA client |______________| Windows NT |__________________| ADSM | | (ADSM client) | | Server | | Server | +---------------+ TCPIP, +------------+ SNA LU 6.2 +--------+ IPX/SPX, Named Pipes, or Banyan Vines Refer to the Microsoft SNA Server documentation for information on how to configure your system for SNA LU 6.2 communications. - A Windows NT user must possess the following rights to backup/restore files: Backup Files Restore Files Manage Auditing and Security Logs - When accessing domain resources such as network drives and UNC names, the ADSM service must log on using a domain account that has the above rights. - Please view DSMCUTIL.TXT for instruction on installing/configuring ADSM services on Windows NT. Uninstalling the Client ----------------------- From the "ADSM for Windows NT" menu item, click "Uninstall ADSM Components". This will allow you to choose which components to uninstall. For a completed automated, silent uninstall, run the uninstal.exe program found in the "shared" directory with the /silentall command-line parameter: UNINSTAL /SILENTALL WARNING: This feature automatically stops all running ADSM services, and removes all previously installed versions of ADSM found in the registry. Uninstalling commences immediately upon execution; there are no confirmation prompts. WARNING: After uninstalling ADSM components, you MUST reboot the system before attemtping to install any ADSM components. --------------------- 3. Late-Breaking News --------------------- What's New ---------- - New archive processing has been added to do the following (requires server level 3.1.2.30 to exploit): 1. With the same description, directories are no longer re-archived with every additional archive. 2. New directory expiration processing prevents directories from expiring before dependent files, regardless of the expiration date. 3. By default directories will now bind to the default management class rather than the one with the longest retention. - The ADSM Win32 client has been enhanced to support Windows NT clusters. Please refer to the "Documentation Updates" section of this README file for details. Documentation Updates --------------------- The following text was added to all the Backup-Archive Using books in the Automating ADSM Tasks chapter: When a scheduled command is processed the schedule log may contain the following entry: Scheduled event 'eventname' completed successfully This is merely an indication that ADSM successfully issued the scheduled command associated with the 'eventname'. No attempt is made to determine the success or failure of the command. You should assess the success or failure of the command by evaluating the return code from the scheduled command in the schedule log. The schedule log entry for the command's return code is prefaced with the following text: Finished command. Return code is: Configuring the ADSM B/A (Backup-Archive) Client in a Microsoft Cluster Server (MSCS) Environment RECOMMENDED CLIENT CONFIGURATION IBM's recommendation is to install ADSM locally on each node of a MSCS cluster and to configure an instance of the ADSM Backup-Archive Scheduler Service for 1) each cluster node to manage all local disks and 2) each cluster group which contains Physical Disk resources. For example, cluster MSCS-CLUSTER contains two nodes, NODE-1 and NODE-2, and also contains two cluster groups which contain Physcial Disk resources, GROUP-A and GROUP-B. In this case, four instances of the ADSM B/A Scheduler Service will be installed, each managing a unique ADSM NODENAME, i.e., NODE-1, NODE-2, GROUP-A and GROUP-B. This is done to ensure availability of proper resources to the ADSM B/A client when disks are moved (or failed) between cluster nodes. NEW CLIENT OPTION A new client option, CLUSTERNODE, has been introduced to help manage ADSM nodes which are used to process cluster disk resources. This option will ensure that backup data is managed logically by ADSM regardless of which physical cluster node initiates the backup of a cluster disk resource. This option should only be used for ADSM nodes which process cluster disk resources, and not by ADSM nodes which process local resources. This parameter is coded in dsm.opt as follows: CLUSTERNODE YES INSTALLING THE ADSM B/A CLIENT SOFTWARE Install the ADSM B/A client software normally on a local disk on each cluster node. The executables should reside in the same location on each local drive, e.g., C:\Program Files\IBM\ADSM\Baclient. CONFIGURING ADSM B/A CLIENT TO PROCESS LOCAL NODES This step will configue ADSM to process the local drives (e.g., C:) for the individual cluster nodes, e.g., NODE-1 and NODE-2. Although no special special configuration is needed in this step, some notes are included below: Configure the dsm.opt file on each local node normally to process the local disk drives. Keep in mind the followin B/A Client options: NODENAME - if no nodename is specified, the ADSM nodename will default to the local machine name, e.g., NODE-1 or NODE-2. DOMAIN - if no domain is specified, the domain will default to ALL-LOCAL and will process all local drives which are not owned by the cluster. CLUSTERNODE - do not specify this option when processing local drives. Configure the ADSM B/A Scheduler Service to backup the local cluster nodes as usual. CONFIGURING ADSM B/A CLIENT TO PROCESS CLUSTER DISK RESOURCES This step will configure ADSM to process the disks owned by the cluster. IBM recommends managing the cluster disk resources at the group level, i.e., manage each group which contains Physical Disk resources as a unique node in ADSM. This ensures that all disk resources are correctly managed by ADSM, regardless of which cluster node owns the resource at the time of backup. CONFIGURING ADSM B/A CLIENT TO PROCESS CLUSTER DISK RESOURCES - STEP 1: IDENTIFY THE CLUSTER GROUPS WHICH NEED TO BE MANAGED BY ADSM. Use the Cluster Administrator program to determine which groups contain Physical Disk resources that need to be processed by ADSM. A unique nodename must be registered on the ADSM server for each group. For example, cluster MSCS-CLUSTER contains the following groups and resources: MSCS-CLUSTER - GROUP-A - Physical Disk Q: (quorum) - Physical Disk R: - GROUP-B - Physical Disk S: - Physical Disk T: Two nodenames will be registered in this example by the ADSM adminstrator: MSCS-CLUSTER-GROUP-A and MSCS-CLUSTER-GROUP-B. There are no rules regulating the ADSM nodenames exept that they must be unique. To register the nodenames, the ADSM administrator will issue the ADSM administrative command: REGISTER NODE MSCS-CLUSTER-GROUP-A CONFIGURING ADSM B/A CLIENT TO PROCESS CLUSTER DISK RESOURCES - STEP 2: CONFIGURE THE CLIENT OPTIONS FILE (DSM.OPT) FOR EACH CLUSTER GROUP. Configure a client options file for each cluster group. It is recommended that the option file be physically located on one of the disk drives owned by the cluster group, e.g., the option file which governs node MSCS-CLUSTER-GROUP-A should reside on one of the drives owned by GROUP-A, either Q: or R:. Configure the dsm.opt file for each cluster group. ** These options need to be explicitly coded ** : NODENAME - code the unique nodename chosen above. DOMAIN - specify the drive letters for the drives which are managed by the group. CLUSTERNODE - this option must be specified as YES. PASSWORDACCESS - this option must be specified as GENERATE. ERRORLOGNAME - a unique error log name SCHEDLOGNAME - a unique schedule log name The dsm.opt file, at minimum, used to manage GROUP-A would be: NODENAME MSCS-CLUSTER-GROUP-A DOMAIN Q: R: CLUSTERNODE YES PASSWORDACCESS GENERATE ERRORLOGNAME Q:\ADSM\dsmerror.log SCHEDLOGNAME Q:\ADSM\dsmsched.log Repeat this step for all groups which need to be managed by ADSM. CONFIGURING ADSM B/A CLIENT TO PROCESS CLUSTER DISK RESOURCES - STEP 3: CONFIGURE THE ADSM B/A SCHEDULER SERVICE FOR EACH CLUSTER GROUP. Configure a ADSM B/A Scheduler Service for each cluster group. Each service needs to have a unique name and must be installed on each node of the cluster so that the service is available for failover. To install the ADSM B/A Scheduler Service for GROUP-1A from machine NODE-1, make sure that NODE-1 currently owns GROUP-A and then issue the ADSM command: dsmcutil install SCHEDuler /NAME:"ADSM Scheduler Service : GROUP-A" /CLIENTDIR:c:\adsm\baclient /OPTFILE:Q:\ADSM\DSM.OPT /NODE:MSCS-CLUSTER-GROUP-A /PASSWORD:n /VALIDATE:no /AUTOSTART:yes /STARTNOW:yes This will install the service on NODE-1. Now, using Cluster Administrator, move GROUP-A to NODE-2. From NODE-2, issue the same dsmcutil command above to install the service on NODE-2. Repeat this procedure for each cluster group. CONFIGURING ADSM B/A CLIENT TO PROCESS CLUSTER DISK RESOURCES - STEP 4: CREATING A GENERIC SERVICE RESOURCE FOR FAILOVER. In this step, the newly created scheduler service will be tied to the cluster group. This will allow the service to correctly fail over between the nodes and also manage the automatic password changes so that both nodes are notified of the new password. A Generic Service resource should be added to each cluster group which needs to be managed by ADSM. Using the Cluster Administrator, select the GROUP-A folder under the MSCS-CLUSTER\Groups folder and select File->New->Resource from the pulldown menu and fill in the following information: New Resource dialog: NAME RESOURCE TYPE Generic Service GROUP GROUP-A Possible Owner dialog: make sure that all cluster nodes appear as possible owners. Dependencies dialog: add all Physical Disk resources as Resource Dependencies. Generic Service Parameters dialog: SERVICE NAME name used in dsmcutil command above, e.g., ADSM Scheduler Service : GROUP-A STARTUP PARAMETERS Registry Replication dialog: add the key corresponding to the nodename: SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\ in this example: SOFTWARE\IBM\ADSM\CurrentVersion\BackupClient\Nodes\MSCS-CLUSTER-GROUP-A Now, select the new resource from the Cluster Administrator utility and select File->Bring Online from the pulldown menu. This step needs to be repeated for each cluster group which needs to be managed by ADSM. At this point, the service to backup the disks in the cluster group is a resource in the same group; the group can be moved (failed) to the other node in the cluster and ADSM will continue to process the disks correctly. The following note was added to the ADSM Using the Microsoft Windows Backup-Archive Clent book in the backup and restore chapter with a reference to it from the archive and retrieve chapter: Note: A file name collision will occur if you attempt to restore or retrieve a file whose name is the same as an existing file's short name. For example, if a file named abcdefghijk.doc with a shortname of abcdef~1.doc exists, and you attempt to restore or retrieve a file explicitly named abcdef~1.doc into the same directory. The collision will occur because the name of the file you are restoring is in conflict with the short name for abcdefghijk.doc. ADSM will handle this situation according to the REPLACE option that is in effect. This situation can occur even if the files are being restored to an empty directory. For example, files abcdef~1.doc and abcdefghijk.doc may have originally existed in the directory, with abcdefghijk.doc having a short name of abcdef~2.doc. During the restore, if abcdefghijk.doc is restored first, it will be assigned a short name of abcdef~1.doc by the Windows operating system. When ADSM subsequently attempts to restore abcdef~1.doc the duplicate file name situation will occur. If this should occur you can perform any of the following actions: * Restore or retrieve the file with a real short file name to a different location. * Stop the restore or retrieve and change the name of the existing file. * Disable short file name support on Windows. * Do not use file names that would conflict with the short file naming convention, for example abcdef~1.doc. Known Problems and Limitations ------------------------------ - ADSM can only support files whose names contain characters that are within the "native" code page for the machine that ADSM is running on. For example, in order to back up files whose names contain Korean language characters, the ADSM client must be running on a Korean Windows NT system. In order to back up files whose names contain Latin 2 (Czech, Hungarian, etc.) characters, ADSM must be running on a Latin 2 system. - Mac file support is available only for files with U.S. English characters in their names (i.e. names that do not contain accents, umlauts, Japanese characters, Chinese characters, etc.). - In order to back up Mac files, the following client option must be in effect: USEUNICODEFILENAMES YES If you are not backing up Mac files, then the following option must be in effect: USEUNICODEFILENAMES NO Note that the default value is NO for all languages except English. - A file name collision will occur if you attempt to restore or retrieve a file whose name is the same as an existing file's short name. For example, if a file named abcdefghijk.doc with a short name of abcdef~1.doc exists, and you attempt to restore or retrieve a file explicitly named abcdef~1.doc into the same directory. The collision will occur because the name of the file you are restoring is in conflict with the short name for abcdefghijk.doc. ADSM will handle this situation according to the REPLACE option that is in effect. This situation can occur even if the files are being restored to an empty directory. For example, files abcdef~1.doc and abcdefghijk.doc may have originally existed in the directory, with abcdefghijk.doc having a short name of abcdef~2.doc. During the restore, if abcdefghijk.doc is restored first, it will be assigned a short name of abcdef~1.doc by the Windows operating system. When ADSM subsequently attempts to restore abcdef~1.doc, the duplicate file name situation will occur. If this should occur you can perform any of the following actions: * Restore or retrieve the file with a real short file name to a different location. * Stop the restore or retrieve and change the name of the existing file. * Disable short file name support on Windows. This option needs to be considered carefully. Some items for consideration include: - Applications that do not understand long file names (like 16-bit Windows or DOS applications) will not be able to access the files if the short name does not exist. - Files accessed via the network by DOS or 16-bit Windows(Windows 3.1x) users will not be able to access the files if the short name does not exist. If you have these or other, similar situations, or if you are uncertain how this would affect you, then turning off short file name support is not recommended. * Do not use file names that would conflict with the short file naming convention, for example abcdef~1.doc. - The Client Scheduler icon dsws.ico had a light-colored background. In most cases, it is not noticeable because it blends in with the background of the "Start" menu and "IBM ADSM" folder. It only becomes apparent if the "Start" menu and/or folder background color is changed, or if you dragged the icon to the desktop. Note that this is a cosmetic issue only and has no effect on the operation of ADSM itself. In this PTF, the Client Scheduler icon has been replaced with a newer dsws.ico file that does not have the light-colored background. However after installing the client, the icon may still appear to have the light background. If you find this to be the case and you would like to fix it, you need to do the following: 1) Locate the file "ShellIconCache" (it has no extension) in the \WINDOWS directory (\WINNT for NT users). It is a hidden file so if you are using Explorer, you will have to turn on the option to display hidden files. Command line users can use the DIR command with the /ah option to display the file, i.e. "dir ShellIconCache /ah". 2) Delete the file. Command line users will need to first turn off the "hidden" attribute with the command "attrib -h ShellIconCache". Then the file can be deleted with the "del ShellIconCache" command. 3) Reboot the system. This will cause the ShellIconCache file to be rebuilt, and the Client Scheduler icon should now appear correctly. Note: The Client Scheduler icon is located in the ..\baclient directory. However the ADSM install program creates the Client Scheduler shortcut in the "IBM ADSM" folder only for Windows 95 and 98 users. - Users running on systems that are neither Latin 1 (English, German, etc.), nor Far East (Japanese, Korean, etc.) may see that the ADSM GUI menu names are question marks (??????). This is probably because support for the Latin 1 code page is not enabled. In order to enable this support, you will need to modify the registry. IMPORTANT: The registry editor is not very forgiving of mistakes. If you are not accustomed to editing the registry, ask your NT administrator to make this change for you. To enable support for the Latin 1 code page, do the following: 1) Start the registry editor. 2) Navigate to the following registry key: HKEY_LOCAL_MACHINE\ SYSTEM\ CurrentControlSet\ Control\ Nls\ CodePage 3) In the right-hand pane of the registry editor, locate the name "850". It should have a null (empty) value. Change the value of the "850" name to the following: c_850.nls 4) close the registry editor. The ADSM GUI should now display the menus correctly. - The maximum line length of the command line interface's online help has been increased from 72 characters to 78 characters in this PTF. If you experience word wrapping or splitting when using the online help, increase the width of your command line window to 80 columns (or more), then redisplay the help text. If your operating system allows you to set a default command line window size, it should be set to display a minimum of 80 columns. - On Windows NT 3.51, the Administrative Client GUI can fail when switching back and forth between selections in the "Show Media Information" dialog. - See the README.OLD file for known problem and limitations from prior ADSM Version 3 PTFs. --------------- 4. Getting Help --------------- - See the Getting Started tutorial for an overview of ADSM. - There are two helpful files in the \adsmcli\win32 directory: whatsnew.v3 documents the new Version 3 client functions - See the following file for helpful information: {cdrom}:\adsmcli\win32\whatsnew.v3 documents the new Version 3 client functions. Online Help ----------- - To display task help in the Backup/Archive GUI, open the Help menu and select the Tasks item. - To display context-sensitive help for an object, put cursor focus on the object and press the F1 or Help key. Note that there is no context- sensitive help for static display fields. You can get help on these fields from the help for the window. - To display help for a window, click the Help button. You can also get help for a window from the Help for ADSM Windows help topic. Platform Specific Documentation ------------------------------- [NONE] Product Documentation --------------------- - The following ADSM Version 3 client publications are available on the ADSM server product CD and are available through your IBM representative: SH26-4080 ADSM V3R1 Installing the Clients SH26-4082 ADSM V3R1 Trace Facility Guide SH26-4081 ADSM V3R1 Using the Application Program Interface SH26-4078 ADSM V3R1 Using the Microsoft Windows Backup-Archive Client SH26-4079 ADSM V3R1 Using the Apple Macintosh Backup-Archive Client SH26-4077 ADSM V3R1 Using the Novell Netware Backup-Archive Client SH26-4076 ADSM V3R1 Using the OS/2 Backup-Archive Client SH26-4075 ADSM V3R1 Using the UNIX Backup-Archive Client SH26-4084 ADSM V3 Using the 0S/2 Lotus Notes Backup Agent SH26-4083 ADSM V3R1 Using the UNIX HSM Clients SH26-4085 ADSM V3R1 AFS/DFS Backup Clients SX26-6019 ADSM V3R1 Reference Cards for the Backup-Archive Clients The books are available in Adobe Acrobat Reader format (.pdf), HTML (.htm), and on some platforms IBM BookManager (.boo) formats and are shipped on the ADSM server product CD. If the system administrator has set the BOOKS option in the options file, you can read the on-line publications by clicking on the Help menu; View Books item. If they are not available using the ADSM backup-archive graphical user interface, then contact your system administrator. You can still read the on-line books by starting the on-line book reader outside of ADSM. - Two other helpful publications are: ADSM Version 3 Technical Guide, order number SH24-2236-0 ADSM Version 3 Performance Tuning Guide, available from the ADSM home page, URL http://www.ibm.com/storage/adsm - Online Documentation A copy of ADSM manual 'Using the Microsoft Windows Backup-Archive Client' is now shipped with the ADSM Client. This manual is provided in two formats: HTML and PDF. If you have a web browser like Netscape or Internet Explorer, you can view the HTML manual. If you have Adobe Acrobat Reader, you can view the PDF manual. The manuals that are installed depend on the type of installation you perform: * Compact: No manuals are installed. * Typical: The HTML manual is installed. * Custom: The HTML manual will be installed by default. You can change this in the "Select Components" dialog that is displayed after you choose the Custom installation. When the "Select Components" dialog appears, you can do the following: o To prevent any manuals from being installed, clear the "Online Help Files" checkbox. o To install only the HTML manual, do not do anything to the "Online Help Files" component. The HTML manual is installed by default. o To install the PDF manual, select the "Online Help Files" component, then press the "Change..." button. You will be presented with a "Select Sub-components" dialog. Check or clear the PDF and HTML book options as desired, then press "Continue" when done. After you have selected the manuals you want, follow the prompts to complete the installation. To view the manuals, use the shortcuts located in the "IBM ADSM" folder. - The following ADSM Version 3 client publications are available on the ADSM server product CD and are available through your IBM representative: SH26-4080 ADSM V3R1 Installing the Clients SH26-4082 ADSM V3R1 Trace Facility Guide SH26-4081 ADSM V3R1 Using the Application Program Interface SH26-4078 ADSM V3R1 Using the Microsoft Windows Backup-Archive Client SH26-4079 ADSM V3R1 Using the Apple Macintosh Backup-Archive Client SH26-4077 ADSM V3R1 Using the Novell Netware Backup-Archive Client SH26-4076 ADSM V3R1 Using the OS/2 Backup-Archive Client SH26-4075 ADSM V3R1 Using the UNIX Backup-Archive Client SH26-4084 ADSM V3 Using the 0S/2 Lotus Notes Backup Agent SH26-4083 ADSM V3R1 Using the UNIX HSM Clients SH26-4085 ADSM V3R1 AFS/DFS Backup Clients SX26-6019 ADSM V3R1 Reference Cards for the Backup-Archive Clients The books are available in Adobe Acrobat Reader format (.pdf), HTML (.htm), and on some platforms, IBM BookManager (.boo) formats and are shipped on the ADSM server product CD. If the system administrator has set the BOOKS option in the options file, you can read the on-line publications by clicking on the Help menu; View Books item. If they are not available using the ADSM backup-archive graphical user interface, then contact your system administrator. You can still read the on-line books by starting the on-line book reader outside of ADSM. - Two other helpful publications are: - SH24-2236 ADSM Version 3 Technical Guide - ADSM Version 3 Performance Tuning Guide, available from the ADSM home page at http://www.storage.ibm.com/adsm. Technical Support ----------------- - To receive 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/adsm - To participate in user discussions of ADSM you can subscribe to the ADSM-L list server. This is an ADSM user forum maintained by Marist College and subscribed to by more than 1,500 ADSM users (at the time of this writing). While not officially supported by IBM, ADSM developers and other IBM support staff also participate on an informal, best-effort basis. Because this is not an official IBM support channel, you should contact IBM Technical Support if you require a response specifically from IBM. Otherwise there is no guarantee that IBM will respond to your question on the list server. You can subscribe by sending a note to the following e-mail address: listserv@vm.marist.edu The body of the message must contain the following: SUBSCRIBE ADSM-L yourfirstname yourlastname The list server will send you a response asking you to confirm the subscription request. Once you confirm your subscription request, the list server will send you further instructions. You will then be able to post messages to the list server by sending e-mail to: ADSM-L@vm.marist.edu - Anonymous FTP server IBM supports an anonymous FTP server where you can find PTF maintenance and other ADSM-related materials. Four 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) sunsite.unc.edu/pub/packages (mirror - North Carolina) - For additional information about ADSM technical support go to the ADSM technical support Web Site. The URL is: http://SSDDOM01.storage.ibm.com/techsup/swtechsup.nsf/support/adsmtechdata ------------- 5. Trademarks ------------- The following terms are trademarks of the International Business Machines Corporation in the United States or other countries or both: ADSTAR AIX BookManager IBM Operating System/2 OS/2 OS/Warp The following terms are trademarks of other companies: Adobe Acrobat Adobe AFS Transarc Corp. Lotus Lotus Development Corporation Lotus Notes Lotus Development Corporation Microsoft Microsoft Corp. Windows Microsoft Corp. Windows NT Microsoft Corp. Internet Explorer Microsoft Corp. Netscape Netscape Communications Corp. Novell Novell, Inc. NetWare Novell, Inc. Hewlett-Packard Hewlett-Packard Company HP-UX Hewlett-Packard Company Motif Open Software Foundation, Inc. X Windows Massachusetts Institute of Technology X/Open X/Open Company Limited NFS Sun Microsystems, Inc. OpenWindows Sun Microsystems, Inc. Solaris Sun Microsystems, Inc. Sun Sun Microsystems, Inc. Sun Microsystems Sun Microsystems, Inc. SPARC SPARC International, Inc. UNIX is a registered trademark in the United States and other countries licensed exclusively through the X/Open Company Limited. -------------------------- 6. APARs fixed by this PTF -------------------------- For APARs fixed in previous maintenance releases, see README.OLD. PTF IP21618 (Intel) - Version 3, Release 1, Level 0.7 PTF IP21619 (DEC Alpha) --------------------------------------------- IC19431 - ADSM CLIENT FILES ARE NOT EXPIRED IF INVALID MC IS DETECTED. IC21101 - When backspace or arrow keys are used to move the cursor to the previous line of a multi-line command, the cursor is positioned one character too far to the right. This affects the Admin command line interface on Windows 95 and 98 on Intel only. IC21811 - When trying to restore data from another node via the GUI, inactive directorys may not display correctly. IC22039 - ANR2483E NO SQL CURSOR IS CURRENTLY OPEN ERROR IS RECEIVED BY ADSM SERVER WHEN USING ODBC. (WINDOWS 32-BIT INTEL ONLY) IC22040 - CANNOT RETRIEVE ARCHIVE FILES USING WINDOWS GUI CLIENT IF A LARGE NUMBER OF FILES ARE ARCHIVED. NEED PROGRESS INDICATOR. IC22085 - V3PTF5 BA client's "Q OPT" "-subdir" option is overwritten by any backup/archive command with "-subdir" option. IC22237 - The GUI B/A client failes to restore(retrieve) file to another location if destination path longer than about 40 characters. IC22290 - ADSM V3 ADMIN CLIENT IN BATCH MODE PROMPTS FOR PASSWORD, WAITING FOR A RESPONSE (AS IF INTERACTIVE) RATHER THAN RETURNING ERROR IC22325 - V3.1.0.5 ADSM GUI DOES NOT FUNCTIONING WHEN FIRST TIME EXECUTED AFTER NETWORK COMPUTER NAMECHANGED AND PASSWORDACCESS GENERATE IC22356 - Restartable restores not restarting with all the original options. -IFN missing. IC22588 - ADMIN GUI IS PASSING AN EXTRA PARAMETER TO THE Q EVENT COMMAND (WINDOWS 32-BIT INTEL ONLY) IC22610 - V3.1.0.5 ADSM GUI displays the Netware directories under the volume level although the drive is mapped to a directory level. IC22732 - PULLDOWN MENUS ( FILE EDIT ACTIONS UTILITIES AND HELP ) DO NOT OPEN UNDER WINNT 3.51 WITH 3.1.0.6 ADSM CLIENT IC22746 - No custom silent install option for Windows 32-bit client IC22780 - MAC VOLUME PERMISSIONS ON NT ARE NOT ALL RESTORED WHEN THE MAC VOLUME IS SET TO READ ONLY IC22800 - Access denied restoring NTFS security attributes on files and permissions are not restored correctly on NT client. IC22855 - THE WIN32 BIT ADMIN GUI INCORRECTLY SORTS 'LAST BACKUP START' (WINDOWS 32-BIT INTEL ONLY) IC22894 - DELETE ARCHIVE -PICK allows directory objects to be deleted: the retrieve GUI then can't display objects archived below that dir IC23017 - ADSM NT 3.1.0.6 "DSMCUTIL INSTALL" FAILS WITH "UNABLE TO LOCATE/OPEN NLS MESSAGE REPOSITORY" IF LANG ISN'T AMENG. IC23022 - ANS1838E WILL OCCUR WHEN THE SCHEDULER SERVICE STARTS IF THE DSM.OPT FILE IS LOCATED IN A DIR WHICH HAS A SPACE IN THE NAME. IC23100 - DURING RESTORE, MESSAGES "HLCLOSE(): COMPRESSION OF '' FAILED, DEVICEIOCONTROL: WIN32 RC=6" APPEAR IN DSMERROR.LOG IC23107 - FRENCH LOCALE ADSM CLIENT 3.1.0.6 SHOWS STATISTIC INTO THE DSMSCHED.LOG FILE WITH WRONG CHARACTERS. IC23221 - THE ADMIN GUI BUILDS INCORRECT UPDATE COMMAND WHEN CHANGING THE NODE PASSWORD AND CONTACT INFORMATION AT THE SAME TIME. (WINDOWS 32-BIT INTEL ONLY) IC23533 - No query restore from sequental drive will fail if all the drives are marked offline IC23619 - UNABLE TO RESTORE FULL PATH TO NETWORK DRIVE IF NEW DIR IS SPECIFIED. ACCESS DENIED. IC23735 - Internal APAR to create PTF 7 and document new function IC23737 - If file is changing during scheduled backup from macro ADSM aborts macro execution with RC=4 IC23738 - Delete Archive deletes the files and directories below the specified directory, but not the specified directory itself. IC23739 - If connection is lost during a sched backup, a message in the dsmsched.log file is created that is >2048 characters. VI fails. IC23761 - ADSM b/a GUI client abends with Segmentation fault ( coredump ), ANS5007W in dsmerror.log when archive function invoked and no active archive copygroup defined.CLI client has no such problem. IC23762 - CANNOT USE THE AIX B/A CLIENT GUI TO SEARCH FOR A RETRIEVAL OF A FILE AT A DIRECTORY LEVEL. IT EITHER RETURNS "NO MATCHING FILES" OR "INVALID START DIRECTORY". IC23849 - Command line Administrative client does not display fraction part of float values correctly . IC23854 - API RETURN CODE FILE (DSMRC.H) MISSING SOME CODES. IC23855 - Using the GUI statistics are sent to server along with every file being processed. *====================================================================== * III. ADSM INFORMATION *====================================================================== *====================================================================== * Where to Find Documentation *====================================================================== The BOOK CD contains the ADSM Version 3 Release 1 Server and Client ESP/Beta books, in PDF format, for AIX, MVS, Windows NT, Sun Solaris, and HP-UX. This CD contains the following: readme.txt (this file) ar32e301.exe (Adobe Acrobat Reader installation file for Windows 95, Windows NT) aro2e30.exe (Adobe Acrobat Reader installation file for OS/2) adsmesp.pdf (main pdf file with links to books in the pdfs directory) pdfs (a directory which contains all 28 product pdf files) To install the Adobe Acrobat Reader on your platform, run the appropriate installation file, and follow the on-line installation instructions. Additional platform and language Adobe Acrobat Reader installation files are available at the following web site: http://www.adobe.com/prodindex/acrobat/readstep.html Use the Adobe Acrobat Reader to view the adsmesp.pdf file. This file contains links to the 28 product pdf files. Click on the book title you want to view. To navigate back to the adsmesp.pdf file, press and hold the right mouse button, move the cursor to the "Go Back" selection, and release the mouse button. *====================================================================== * Getting Help *====================================================================== - To receive technical support for 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: + 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 - Frequently Asked Questions: For the latest list of ADSM Frequently Asked Questions (FAQ) please point your web browser to the following URL: http://www.storage.ibm.com/storage/software/adsm/adfaq.htm *====================================================================== * Trademarks *====================================================================== (*) Trademark of the IBM Corporation in the United States and other countries.