README ______ Welcome to the ADSTAR(*) Distributed Storage Manager. This is service level 3.1.2 for the ADSM for AIX server, Version 3 Release 1. This is divided into the following sections: o Overview of new function in this Server o New Licensing information o Where to find Documentation o Notice for WEB browser users o Generating SSL certificates for ADSM servers o Notes for use of the SNMP sub-agent (dsmsnmp) o Information on Data Errors in prior levels of ADSM Version 3 o Migration by age limitation o Version 3 Release 1 APARS fixed by this service level o Getting Help o Trademarks ********************************************************************** * OVERVIEW OF NEW FUNCTION IN THIS SERVER LEVEL * ********************************************************************** This section provide a brief description of the function that has been added to this Enterprise Management server. For more information, please refer to the PDF manuals that were provided on the documentation CD. ---------------------------------------------------------------------- * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * This server provides enhanced recovery log fault-tolerance and new database entries to support enhanced functions. If you start this server over an existing 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. * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * NOTE * ---------------------------------------------------------------------- Central Console The administrative WEB interface to the server has been enhanced for ease of use in navigation and the administration of multiple servers from a single interface. This interface is available from a Netscape version 4+ or Internet Explorer Version 4 browsers. The Netscape browser will require a patch from Netscape to support the JDK 1.1 function in the Java applets in the interface. Please see the section entitled "Notice for WEB browser users" for more information on this. Security for the WEB conversation has been enhanced through the option use of secure sockets layer (SSL) encrypted conversations. Please refer to the section entitled "Generating SSL certificates" for more information. The SSL encryption is not yet available for the MVS server. Central Configuration The central configuration function allows you to establish a server as the master configuration server for your enterprise, and then have others servers automatically inherit their configuration information (such as policy definitions) from the master configuration server. Central Commands The central command function provides a means for you to route server commands for execution across multiple server in your enterprise. The results from the routed commands are displayed at the screen from which the command was specified. Central Logging The event logging function provided in version 3 has been enhanced to support logging client and server events to a central server. This central server can then forward the events to other receivers such as SNMP or Tivoli, store the events in the server database, or log them to the console for monitoring by operations personnel. The Windows NT server has been enhanced to support sending client/server events to the Windows NT event log so they can be displayed by the event viewer. The data structure for the FILE and USER EXIT event receivers has been modified. A description of the data structure for an event can be found in the user exit sample (userExitSample.h). Because of the change, the version field has been updated to 2. You will need to recompile your existing user exit to utilize this new data structure. Server automation Server automation has been enhanced with command scripts that are stored in the server database, allow conditional logic based on command return codes, and can be scheduled for execution using the server's administrative command scheduler. Database and recovery log policy can now be established to automatically add space and extend the database/log when specified utilization is encountered. This frees the administrator from having to monitor database/log utilization on a regular basis. Central Reporting/Monitoring A number of sample SQL queries have been developed and provided to you in the form of command scripts to assist in obtaining useful information from the ADSM server. The SNMP MIB interface now allows you to execute command scripts from SNMP, returning the results from the script. Overflow storage pools To ease the management of automated libraries, this function allows you to checkout volumes from a library based on last use date so that slots can be used for new volumes. Prepare output on another server The prepare function has been enhanced as part of the Disaster Recovery Manager (DRM) feature to store recovery plan files directly on another ADSM server in the enterprise. This information can be queried and retrieved interactively through the WEB administrative interface. Prepare output can only be stored on other 3.1.2 servers, not on 3.1.1 servers. NEW/CHANGED COMMANDS: COPY SERVERGROUP COPY PROFILE DEFINE EVENTSERVER DEFINE GRPMEMBER DEFINE SCRIPT DEFINE PROFASSOIATION DEFINE PROFILE DEFINE SERVER DEFINE SERVERGROUP DEFINE SPACETRIGGER DEFINE SUBSCRIBER DELETE EVENTSEREVR DELETE GRPMEMBER DELETE SCRIPT DELETE PROFASSOCIATION DELETE PROFILE DELETE SERVER DELETE SERVERGROUP DELETE SPACETRIGGER DELETE SUBSCRIBER DELETE SUBSCRIPTION DELETE VOLHISTORY DISABLE EVENTS ENABLE EVENTS LOCK PROFILE MOVE GRPMEMBER NOTIFY SUBSCRIBERS PING PREPARE QUERY ENABLED QUERY EVENTRULES QUERY EVENTSERVER QUERY LICENSE QUERY PROFILE QUERY RPFILE QUERY RPFCONTENT QUERY SERVER QUERY SERVERGROUP QUERY SPACETRIGGER QUERY SUBSCRIBER QUERY SUBSCRIPTION QUERY VOLHISTORY RENAME SCRIPT RENAME SERVERGROUP RENAME STGPOOL RUN SET CONFIGMANAGER SET CONFIGREFRESH SET CROSSDEFINE SET DRMRPFEXPIREDAYS SET SERVERPASSWORD SET SERVERHLADDRESS SET SERVERLLADDRESS SET SERVERURL UNLOCK PROFILE UPDATE SCRIPT UPDATE PROFILE UPDATE SERVER UPDATE SERVERGROUP UPDATE SPACETRIGGER ********************************************************************** * 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 ********************************************************************** * 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. ********************************************************************** * NOTICE FOR WEB BROWSER USERS * ********************************************************************** The web interface for administrative functions requires that your browser have jdk 1.1 support. the following instructions detail how to get this support for Netscape 4.0. Internet Explorer 4.0 has this support: Java 1.1 support is required for using the newly enhanced web interface. Below are instructions on how to upgrade your browser. Netscape Communicator Verify that you are currently running Netscape Navigator 4.03 or better. If you need to upgrade, go to http://home.netscape.com/download/ and follow the instructions to upgrade your current browser. For Windows NT/95 users, go to http://help.netscape.com/filelib.html#smartupdate and press the JDK Update Button (third button under the Win32 heading). This will start an automatic update of your browser. During installation you will be prompted to Grant or Deny a request to install software. Grant the request so installation can occur. Follow the instructions provided. When installation is complete, close Netscape Navigator and reopen the application. To verify that a proper installation has occurred, select Java Console from the Communicator menu. The first line of the Java Console should read Netscape Communications Corporation -- Java 1.1.4. For UNIX users, go to http://developer.netscape.com/software/jdk/download.html#UNIX_INSTALL . Here you will find information on how to download and install the patch for various flavors of UNIX. Internet Explorer You will need Internet Explorer 4.01 or higher for Java 1.1 support. To obtain the latest version of IE 4.0 go to http://www.microsoft.com/ie/download. Follow the provided instruction to install the product. HELP WINDOWS Due to a Javascript support problem in Netscape, if you resize the panel help window the 'close' button may not function correctly. If this should happen, you can always close the window by using the window's close icon. ********************************************************************** * GENERATING SSL CERTIFICATES FOR ADSM SERVERS * ********************************************************************** Included with the install package are utilities to create and maintain certificates. The primary certificate tool is MKKFE.EXE. With this utility a certificate request and key ring file can be created. Once a certificate request has been created it can be sent off to a Certificate Authority (CA) for signing. Self signed certificates can be created using the provided utilites. However, there are some limitations, see the section on "SSL Support Issues". CREATING A KEY RING FILE AND CERTIFICATE REQUEST FOR THE SERVER 1. Start the MKKFE application. 2. Create a new key ring file by pressing n. Name the new file certkey.kyr. This filename is a requirement of the ADSM server, any other name will not be recognized. 3. Create a new Certificate request a.From the main menu press w to work with certificates. b.To create a new certificate press c, At this point you will be prompted for a password. This password is for the key ring file. Enter the password apollo. Remember to keep the password for later use. After the password has been entered twice, a prompt will ask if the password is to expire. Answer no to this question. c.The type of certificate to create is a PEM certificate, press s. You will be presented with the following screen. Compose PEM Certificate Request Menu Current Certificate Information Key Name: (none) Key size: 0 Server Name: (none) Organization: (none) Organizational Unit: (none) City/Locality: (none) State/Province: (none) Postal Code: (none) Country: (none) M - Modify the Certificate Request Fields R - Ready To Create Key and Certificate Request C - Cancel Enter a command: press m modify the request. Enter in all personal information as requested by the program. Below is a sample session. Enter a name to use for the key entry: ADSM Server 1: 508 2: 512 Enter the number corresponding to the key size you want: 2 Enter the server's fully qualified TCP/IP domain name or press ENTER by itself to leave the field blank. adsm_server.ibm.com Enter Organization Name for the certificate or press ENTER by itself to leave the field blank. IBM Enter Organizational Unit Name for the certificate or press ENTER by itself to leave the field blank. ADSM Enter Locality/City Name for the certificate or press ENTER by itself to leave the field blank. SomeCity Enter State/Province Name for the certificate or press ENTER by itself to leave the field blank. State/Province must be at least three characters long. SomeState Enter Postal Code for the certificate or press ENTER by itself to leave the field blank. 99009 Enter Country Code for the certificate or press ENTER by itself to leave the field blank. Country code must be exactly two characters long. US a. The first thing entered is a name for the certificate request. This name is for use by the key ring file. The second entry is for the key size. The recommended size is 512. The next fields information about your company and the location of the ADSM Server. When prompted for the fully qualified TCP/IP address, don't enter a IP address. The entry is the name of the machine where the ADSM server resides. For example, adsm_server.ibm.com. b. After the above information has been entered, you will be presented with a summary of what has been modified. If everything is to your liking, then you are ready to create a certificate request. c. To create the certificate request press r. When prompted for a file name type certreq.txt. d. At this point you will want to mark the created certificate as the Default Certificate of the key ring. To do this type f. After the certificate has been marked as trusted root it is now time to receive the certificate into the key ring file. You will need to return to the Key Ring Menu to do this. Press x from the Key Menu to return to the Key Ring Menu. e. At this point all the work with the server key ring file is done. Save the key ring by pressing s and exit the application by pressing x. The certificate request that has been created can now be sent to a Certificate Authority of your choice to be signed. This process might require other paper work to be filled out. Check with the CA before sending your certificate request. Also, some e-mail program might add extra spaces to the end of a certificate, which will invalidate the certificate, so be careful when sending and receiving certificate. If you are using self signed certificates, then proceed to the next step. RECEIVING THE SIGNED CERTIFICATE INTO THE SERVER KEY RING FILE Once you have received the signed certificate from the CA, you will need to receive the signed certificate into the server key ring file. 1. Start the MKKFE application. 2. Open the server key ring file by pressing o. Name the new file certkey.kyr. 3. Receive the new Certificate. a. If you are your own CA you will need to receive the CA certificate before receiving the server certificate. First receive the certificate into the key ring by pressing r from the Key Ring Menu. Enter the filename of the CA certificate request. From the above instructions the file name is cacert.txt. You will be warned about adding a self-signed certificate to the key ring file; press y to continue. You will then be prompted for a name of the key. Enter a name and you will return back to the Key Ring Menu. The next step is to make the received certificate a trusted root. This is done by working with the certificate. Press w to work with the certificate. The certificate will need to be selected at this point. Press l to list and select the certificate. Press n to proceed the next certificate until you find the name that you just entered. Once that name has been found press s to select the certificate. You will now return back to the Key Menu, where you can make the certificate a trusted root by pressing t. Return back to the Key Ring Menu, by pressing x, to continue with the next step. b. To receive the signed server certificate, press r from the Key Ring Menu. Enter the filename of the signed certificate, cert.txt for example. You might receive a warning about the certificate signer certificate not being part of the Key Ring. This mainly occurs when you have become your own CA. The next step is to make the received certificate the default certificate. This is done by working with the certificate. Press w to work with the certificate. The certificate will need to be selected at this point. Press l to list and select the certificate. Press n to proceed to the next certificate until you find the name that was originally given for the server certificate, this name is ADSM Server from our example. Once that name has been found press s to select the certificate. You will now return back to the Key Menu, where you can make the certificate the default by pressing f. Return back to the Key Ring Menu, by pressing x, to continue with the next step. Now save the Key Ring file by pressing s from the Key Ring Menu. You will be prompted that the file exists; it is OK to overwrite this file. After the save has completed, exit MKKFE by pressing x. SETTING UP THE ADSM SERVER FOR SSL After all of the certificates have been created, copy the created file, the signed certificate, the key ring file certkey.kyr and the cacert.txt file if you are your own CA, to the ADSM server executable directory. Before bringing up the ADSM server, add the COMMETHOD HTTPS to your dsmserv.opt option file. This will indicate that the server should bring up the SSL communication method. The port number is set by HTTPSPORT in the dsmserv.opt. The default port is 1543. Start the ADSM server. At this point SSL initiation will not occur, since the key ring password is unknown. Define the key ring filename and passoword using the DEFINE KEYRING command as shown below. Halt and restart the ADSM server to start the SSL communication method. WARNINGS MESSAGE FROM WEB BROWSER You will receive a message from the web browser when you are your own CA. This is mainly because the certificate that you have created is not trusted by the browser. Each browser handles the matter differently. Netscape will allow you to receive the certificate as a web site certificate. The received certificate is then compared with the certificate sent by the ADSM server every time you connect the server. After setup has completed, you will not be prompted for any more information in the future, that is if you click the always accept bullet in the wizard. Internet Explorer handles the matter a little differently. It will prompt you that the certificate being received is not trusted. You will continue to get this message every time you connect to the ADSM server unless you turn the warning message off. SSL SUPPORT ISSUES ADSM will support unsecure (non SSL) connection to any web browser capable of understanding HTML version 2.0 on all ADSM server platforms. However, certain combination of the secure connections between ADSM server and web browser can cause problems. It is recommend that you connect with Netscape Navigator version 4.05 or better to ADSM using Secure Socket Layer (SSL). ADSM does not support SSL connections from UNIX ADSM servers to the Internet Explorer web browser using certificates signed by the users own certificate authority or self signed certificates. SSL connections are only supported from UNIX ADSM servers to Netscape Navigator, which will accept self signed certificates. ADSM does support Internet Explorer browser SSL connection to the ADSM NT servers. Further, ADSM will support any user who goes out and gets a certificate signed by a trusted Certificate Authority like IBM World Registry or Versign. DEFINE KEYRING Command. Use the DEFINE KEYRING command to define a new key ring filename and password. The key ring file is created using the MKKFE utility provided with ADSM. This command will need to be issued before SSL will start correctly. If this command has not been issued, the initialization of SSL will fail with a message stating that the filename and/or password is invalid. After the command has been issued to ADSM, halt and restart the ADSM server for the SSL communication method to start. Privilege Class To issue this command, you must have system privilege. Syntax >>-DEFine KEYring--filename---password----------------------------------->< Parameters filename Specifies the file name of the key ring file. This parameter is required. This file name must end with the extension .kyr, to indicate a key ring filename. For example, certkey.kyr is a valid filename. The key ring file must be place in server root directory. password Specifies the password of the key ring file. This parameter is required. This is the same password as the one used to create the server keyring in the MKKFE utility. Examples Task Define the key ring filename of certkey.kyr and password of apollo Command: define keyring certkey.kyr apollo Expected output: ANR4704I Key ring filename and password have been set. Restart ADSM to use new settings. ********************************************************************** * NOTES FOR USE OF 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. ********************************************************************** * DOCUMENTATION UPDATES * ********************************************************************** Problem: Routed commands using the serverlist: command syntax cannot be used within scripts. If a routed command using this syntax is used in a script, the command will run on the issuing server, not the targeted server. Solution: A new, additional syntax for routing commands is available. Routed commands can also be indicated by the following syntax: (serverlist) command Example: To route the command QUERY VOLUMES to the defined servers JOE and CHARLIE enter either of the following command: (JOE,CHARLIE) QUERY VOLUMES JOE,CHARLIE: QUERY VOLUMES The rules for the list of server names are the same with the new syntax as with the original. The new syntax can be used inside scripts to route commands. Example: To create and run a script CHECK_VOLUMES that routes the command QUERY VOLUMES to the defined servers JOE and CHARLIE enter the following commands: DEFINE SCRIPT CHECK_VOLUMES '(JOE,CHARLIE) QUERY VOLUMES' RUN SCRIPT CHECK_VOLUMES Updates to the Command Routing information: Administrators can route commands to one server, a server group or a list that contains multiple servers, multiple server groups or a combination of servers and server groups. Each server or server group in a list must be separated with a comma, without spaces. The server, server group, or list must be followed immediately by a colon or enclosed in parentheses, and followed by the command to be processed. Spaces are allowed between the end colon or parentheses and the command to be routed. The end parenthesis or the colon after the server name indicates the end of the routing information. Updates to the UPDATE and DEFINE SCRIPT command, and the information on using scripts: Command routing in a SCRIPT must be done using the parentheses. If command routing is done using the colon syntax, the command will not be routed when the RUN command is issued, and will instead run on the server where the RUN command is issued. ******************************************************************************** * 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. ******************************************************************************** * 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." ******************************************************************************** * Version 3 Release 1 APARS fixed by this service level * ******************************************************************************** IC15385 / IX79245 / IC21169 / IC21171 DSMSERV AUDITDB PARAMETERS ARE NOT WORKING AS DOCUMENTED FILE=xx parameter on DSMSERV AUDITDB not directing output to V2 file. ------ IC19793 DSMLABEL GETS ERROR MESSAGE ANR9726E WHEN LABELING TAPES IN AN DSMLABEL tries to write labels to the 8700LT using the 8200 format, although the 8700LT supports 8200 format for READ only. This problem occurs because the 8700LT identifies itself to DSMLABEL (via SCSI inquiry) as an Exabyte 8505. The native 8505 device supports 8200 format for both READ and WRITE. DSMLABEL writes out 8200-format labels on 8505 devices, but because the 8700LT does not support 8200-format writes, the label attempt fails. ------ IC20538 NETBIOS LISTENER CLOSES WHEN WINAPI FUNCT. NETBIOS(NCB) RETURNS If an error occurs in a session that causes the NetBIOS listen to terminate with rc 24 ( hex 18 ), the server stops listening for sessions with ADSM clients. ------ IC20617 / IC20538 ADSM SERVER SHOWS ABOUT 50-90 ANR8336I MESSAGES PER SECOND AFTER ANR8311E ERROR MESSAGE OCCURED. ------ IX73670 / IX79248 / PQ16908 / IC21176 / IC21177 / IC21178 SESSION NUMBER GREATER 99999 WILL NOT BE DISPLAYED PROPERLY ------ IC21281 TAPE MOUNTS ARE DELAYED ON SOLARIS 3.1.1.3 SERVER CODE FOR SCSI LIBRARIES. TAPE MOUNT DELAYS COULD BE IN EXCESS OF 5 MINUTES. ------ IX75336 / PQ13918 / IC20323 / IC20324 / IC20325 SELECT OCCUPANCY ... OUTPUT DOES NOT MATCH QUERY OCCUPANCY OUTPUT The SQL SELECT FROM OCCUPANCY does not display filespace information correctly for nodes with multiple filespaces. ------ IX74446 / PQ16728 / IC21388 / IC21389 / IC21390 Server incorrectly reporting missed schedules ANR2478I MESSAGE IS GENERATED WHEN THE SCHEDULE DOESN'T FINISH WITHIN START WINDOW. THIS MESSAGE SHOULD ONLY BE ISSUED IF SCHEDULE HAS NOT STARTED WITHIN START WINDOW. ------ IX75715 Tivoli event receiver needs hostname slot ADSM did not pass the HOSTNAME slot to Tivoli. ------ IX75962 Excessive ANR8216W messages with Tivoli event logging The Tivoli event receiver did not properly detect when the Tivoli event server went down. ------ IX76138 / PQ16914 / IC21180 / IC21181 / IC21182 QUERY SESSION hangs the server when it has much output When issuing a QUERY SESSION command from an admin client, and the number of sessios is so large that the entire output from the command cannot fit in a single buffer (over 150 sessions), the server can hang due to deadlock contention of the Session Mutex. ------ IX76147 / PQ18764 / IC21774 / IC21775 / IC21776 WEB ADMIN DOES NOT SEE DEFINED DRIVES, AND IN CUSTOMER'S CASE, HIS 3494 LIB. SQL queries and Web Admin pages return Not Found instead of no space available when there is insufficient database space for SQL temporary tables. This will occur when a Q DB shows 0 in the Maximum Reduction field. ------ IX76494 / PQ16917 / IC21186 / IC21187 / IC21188 Archive performance degredation archive query/retrieve performance is degraded from V2 ------ IX76472 / PQ15813 / IC21183 / IC21184 / IC21185 SELECT * FROM VOLUMEUSAGE DOES NOT LIST ALL VOLUMES WHICH CONTAIN DATA. entries are missing from 'select * from volumeusage' output ------ IX76739 / PQ18017 / IC21549 / IC21550 / IC21551 ANR2751I ISSUED WHEN ANR2756I IS APPROPRIATE ------ IX76854 / IX76928 / IC20599 / IC21189 / IC20597 OPTICAL SUPPORT. DUE TO BAD SECTOR OR HARDWARE RELATED ISSUES ADSM WILL NOT ACCESS REST OF THE FILES AND MARK THEM ALL BAD The problem is that any single I/O error from the drive on a read operation prevents any other access to that side of the platter until the platter is dismounted. This impacts the AUDIT VOL and MOVE DATA commands from being able to access otherwise good files on the platter because one file had a bad sector in it. ------ IX77291 / PQ16920 / IC21190 THE DRM -> PREPARE ICONS ON THE WEBADMIN WILL RECOGNISE ONLY THE FIRST STGPOOL GIVEN IN A LIST. The PREPARE panel for the Web administrative interface incorrectly displayed partial storage pool information in the COPYSTGPOOL and PRIMSTGPOOL fields. ------ IX77477 AIX ADSM SRV 3.1. GETS ANR8355E,ANR8311E WHEN TRYS TO MOUNT THE STORAGE TEK (ACSLS 5.1.1) TAPES WITH HEADER TYPE 1. prelabelled tapes do not have the HDR2 which ADSM expects ------ IX77638 / PQ18205 / IC21603 / IC21604 / IC21605 ADSM ADMIN COMMANDS THAT DO NOT REQUIRE SPECIAL ADMIN AUTHORIZATION CAN BE ISSUED THROUGH WWW INTERFACT WITHOUT AUTHENTICATION. The '/HELP/' path link in the server URL for the WEB admin interface will allow non-administrators to issu query commands. Commands the require an ADSM administrative authority above GENERAL will fail. ------ IX77714 / PQ17474 / IC21391 / IC21392 / IC21393 TRYING TO RUN A SCRIPT THAT RUNS AN ADMIN SCHEDULE. WORKED IN V2 DOES NOT WORK IN V3. Cannot Schedule Device and Library related Administrative cmds. ------ IX77766 / PQ17474 / IC21391 / IC21392 / IC21393 QUERY OPTION doesn't show AUDITSTORAGE option NOAUDITSTORAGE OPTION DOES NOT APPEAR IN ADSM SERVER QUERY OPTION OUTPUT EVEN THOUGH PARM IS SPECIFIED IN DSMSERV.OPT ------ IX77783 / IC21697 / IC21698 / IC21699 ANR9999D PSPURROPT.C 1049) OPTICAL DISK NOT VALID FOR THIS PRODUCT RECEIVED WHEN RUNNING LABEL LIBVOL FOR OPTICAL PLATTER when ADSM labels an optical platter, it first tries to read the existing label to ensure that it is not being overwritten. If no existing label is found, the ANR9999 error message is issued, which is extraneous since this condition would be expected. ------ IX77865 / PQ17047 / IC21244 / IC21245 / IC21247 RESTORED FILE ACCOUNT IS WRONG IN ACCOUNTLOG. RESTORED WITH NO PROBLEM, BUT DISPLAYED "RESTORED FIL =ZERO". accounting info not updated for restored files ------ IX78021 / IX79702 / PQ17471 / IC21380 / IC21381 / IC21382 AFTER STARTING 'UPDATE DEVC' DURING 'QUERY CONTENT' WORKING , SERVER HANGS. ------ IX78125 DSMFMT -G RESULTS IN OUT OF SPACE MESSAGE The GB value was processed incorrectly. ------ IX78196 / PQ15328 / IC20890 / IC20891 / IC20892 DB Dump was not dumping all pages When running the dumpdb comand, one or more of the following messages are issued: ANR9999D dldump.c(2361): Logical page xxx corrupted - data string packed structure invelid for record 0 ------ IX78320 / PQ16921 / IC21191 / IC21192 / IC21193 Unpredictable crash during Query Backup unpredictable core dump occurs during query backup ------ IX78433 / PQ17048 / IC21248 / IC21249 / IC21250 ANR9999D XIBF.C(1161):UNKNOWN RESULT CODE (23) FROM BFCREATE CAN BE A RESULT OF V3 SERVER FILLING UP DISK STGPOOL DURING IMPORT With a version 3 server when a disk storage pool becomes full during an import and didn't get the chance to migrate the data to tape, it will fail with ANR9999D XIBF.C(1161):UNKNOWN RESULT CODE (23) FROM BFCREATE. ------ IX78702 QUERY CONTENT causes other commands to hang After starting 'update devc' during 'query content' working, server hangs, when 'query content' command take a big time to work (large output). After system waits (hangs) the message ANR0481W Session ??? for node ????? terminated - client did not respond within ?? seconds. After admin session with 'query content' command is terminated, then sessions with 'update devc', 'q devc' commands unhangs and worked properly. ------ IX78829 / PQ17049 / IC21251 / IC21252 / IC21253 Memory leak when creating mutexes (AIX Only) Every time a mutex is created in the server, an unspecified amount of memory is leaked. Over time this can cause excessive paging activity and/or server crash. ------ IX79016 / IC21701 / IC21702 / IC21703 ADSM SRV 3101, AIX 4.2.1, DRIVE-POLLING THREAD DON'T MARKS THE DRIVE OFFLINE ADSM DB, ONLY IN DRIVE DESCRIPTOR. The problem occurs when a drive in the 3949 library has an error and ADSM begins to poll the drive. If the user marks the drive offline via the UPDATE DRIVE command, then when the polling thread finds out the drive is now accessible, the drive is marked online. However, the drive should still be marked offline according to earily commands issued. ------ IX79165 / PQ17891 / IC21523 / IC21524 / IC21525 ANR9999D AFERASE.C(493):INVALID LOGSIZERATIO INF Customer runs through RECLAMATION UTILITIES. Encountered errors on DELETE RECLAIM and later on RECLAMATION or EXPIRATION: ANR9999D aferase.c(493): Invalid logSizeRatio INF (logSize= 0.1240,size=0,0,aggrSize=0.21045) for aggregate 0.21279102 ------ IX79191 REMOVE=BULK WILL NOT RETURN WITH AN INVALID OPTION WHEN USED WITH AN ACSLS LIBRARY. CHECKIN LIBVOL ... REMOVE=BULK ... is not supported by ACSLS libraries and should return an error if attempted. ------ IX79350 / PQ17741 / IC21479 / IC21480 / IC21481 SCHEDULER ISN'T PROCESSING 2/29/2000 CORRECTLY. Leap year not handled correctly for Y2K. ------ IX79366 WHILE ADSM IS COMING UP, TAPES IN AN ACSLS LIBRARY SYSTEM WHICH ARE NOT FOUND WILL BE CHECKED OUT RESETTING THE 'LOCK' BIT. While ADSM is coming up, tapes in an ACSLS library system which are not found will be checked out resetting the 'lock' bit. By resetting the lock bit, we may be allowing the tape to be picked up by another application using the ACSLS library. ------ IX79368 / PQ17117 / IC21296 / IC21297 / IC21298 MAXSIZE ROUNDED FOR DISPLAY OF Q STGPOOL ------ IX79394 / IX79476 / IC21292 / IC21294 ADSM SERVER CHECKIN LIBVOLUME SEARCH=YES AND LABEL LIBVOLUME SEARCH=YES CAUSE 3995 TO UNLOAD DRIVES FOR STATUS CHECKING the IES command that is issued by Checkin and Label commands with the search option causes any mounted volumes to be ejected from the drives ------ IX79470 A WRITE PROTECTED TAPE IN AN ACSLS LIBRARY SYSTEM WILL BE REMOUNTED REPEATEDLY FOR SCRATCH OPERATIONS. A write protected tape in an ACSLS library system will be remounted repeatedly for scratch operations. Other tapes may be mounted durring this processing, as well, including a usable scratch tape being selected occationally. ------ IX79566 / PQ18306 / IC21641 / IC21642 / IC21643 Q ACTLOG WITH SEARCH OPTION DOESN'T DISPLAY ALL OCCURENCES OF THE STRING EXPRESSION ON 3.1.1.3 SERVERS. When doing a QUERY ACTLOG with SEARCH parameter, messages originating from clients or other servers were not always included. ------ IX79579 / PQ17434 / IC21383 / IC21384 / IC21385 ANR8449E WHEN TRYING TO MOUNT A SCRATCH VIRTUAL VOLUME. The name generation routine for scratch names was not appropriately checking to see if a volume by that name already existed. ------ IX79727 PQ18529 IC21715 IC21716 IC21717 EXPORT DOES NOT WRITE THE DATASET NAME IN THE HDR1 FIELD IF THE VOLUME HAS BEEN PREVIOUSLY USED BY ADSM The problem arises on the MVS side when importing data that was exported from a UNIX or NT. The error states that the data set name was incorrect. ------ IX79815 / PQ17742 / IC21482 / IC21483 / IC21484 AN ANR8311E I/O ERROR MESSAGE WITH RC OF 6 OR 28 IS ERRONEOUSLY GIVEN WHEN THE VOLUME BECOMES FULL AND END OF TAPE IS REACHED ADSM erroneously generates an: ANR8311E AN I/O ERROR OCCURRED WHILE ACCESSING DRIVE FOR WRITE OPERATION; ERRNO = 6 (or ERRNO=28) ANR8341I - END OF VOLUME REACHED FOR VOLUME . when using a library defined with LIBTYPE=EXTERNAL and the volume becomes full (i.e. reaches the end of media/end-of-tape/ EOT). This message sequence is not indicative of a true error. ------ IX79974 / PQ17743 / IC21485 / IC21486 / IC21487 IF A MOVE FROM DISK OPERATION IS CANCELED OR PREEMPTED, ADSM COULD ABEND WITH A TMTXN008 An abend can at time occur during the movement of data from a disk storage pool to another pool and a cancel is issued or the operation is preempted. This problem is more likely to happen if I/O errors are experienced and the move operation is retrying the move. ------ IX80345 / PQ18018 / IC21552 / IC21553 / IC21554 WHEN USING THE SQL SELECT STATEMENT WITH ORDER BY PARM AND THERE IS MORE THAN ONE COLUMN DISPLAYING DECIMAL,INTERVAL OR DATETIME SQL queries using the order by clause, with more than one column with decimal, date/time or interval data can have incorrect data displayed. ------ IX80431 / PQ18327 / IC21615 / IC21616 / IC21617 WEB ADMIN INTERFACE DOES NOT DISPALY OBJECTS FIELD INFORMATION IF MULTIPLE SET OS QUOTES ARE USED. Strings that contain double quotes (") do not preserve the double quotes when entered from the Administrative WEB interface. An example is the objects/options fields in the DEFINE/UPDATE schedule command. ------ IX80461 / IC21777 / IC21778 / IC21779 DRIVER FOR 7206-110 12 GIG TAPE DRIVE Drive fails to configure using adsm driver but will configure using the native AIX driver. ------ IX80531 / PQ18307 / IC21644 / IC21645 / IC21646 ADSM DOESN'T RETURN AN ERROR WHEN THE MOVE MEDIA COMMAND AND CHECKLABEL=NO OPTION ARE USED TOGETHER. The users use an undocumented parameter CHECKL with the MOVE MEDIA command. If CHECKLABEL, instead of CHECKL, is used with the MOVE MEDIA command, ADSM reports the error. ------ IX80875 DOCUMENTATION UPDATE REQUEST TO INCLUDE -SERVERNAME OPTION IN LIST OF IGNORED OPTIONS FOR DEFINE SCHEDULE COPMMAND ------ IX80940 / PQ18522 / IC21709 / IC21710 / IC21711 ANR9999D PKSHMEM.C(310): INVALID ATTEMPT TO FREE MEMORY: CALLED FROM 10201E54 (CSQUERYEVENT). Specifying "Query Event * type=admin nodes=" leads to attempts to free memory which has not yet been obtained. The use of type=admin and nodes= is not compatible. ------ IX81008 / PQ18610 / IC21732 / IC21734 / IC21736 IF A TIVOLI SERVER GOES DOWN AND IS BROUGHT BACK UP ADSM NO LONGER CAN COMMUNICATE WITH IT. TIVOLI went down, and ADSM did not attempt to reconnect and continue sending events to the TIVOLI Event Console. ------ IX81130 TCP/IP IS CLOSED WHEN ERROR NUMBER 72 IS RECEIVED FROM TCP/IP If a session request is aborted in a very small window and ECONNABORTED is returned by AIX, the server will stop listening for TCP/IP sessions. ------ PQ04985 IX77690 PQ15345 IC20735 IC20734 IC20736 THE MESSAGE "ANRNNNNW UNABLE TO CLEAR THE LOG BELOW XX% OF THE TRIGGER VALUE. THE RECOVERY LOG IS NOW YY% FULL" SHOULD DISPLAY The server does not issue a message when running in roll-forward mode and a database backup does not clear the recovery log below the percentage specified by the database backup trigger. ------ PQ06399 IX79262 PQ16922 IC21194 IC21195 IC21196 HIGH CPU UTILIZATION DURING SCHEDULE MANAGER INITIALIZATION. When the ADSM server is starting, the schedule manager may take a long time to initialize if there is a large number of schedled events defined (i.e. lots of clients associated with one or more schedules). During schedule manager initialization, you may see one or more of these symptoms: - High CPU utilization - Clients will not be able to connect - No response to administrative commands Once the schedule manager starts (message "ANR2560I Schedule manager started.") ADSM will operate normally. ------ PQ11588 ABEND0C4 IN EDCXV AT X'9C78' WHEN SERVER OPTIONS ALLOCATED AS PDS MEMBER AND USER TRIES TO UPDATE SERVER OPTIONS DYNAMICALLY If a PDS member is used for the MVS ADSM server options file instead of the recommended PS file, an ABEND0C4 occurs in EDCXV whenever a admin GUI exits the V3 dynamic server options update panel. ------ PQ12297 IX81146 IC21638 IC21639 IC21640 ANR9999D PVRCART(987): DEVICE 0700 (1888) NOT THERE. ANR9999D PVRCART(1014): RETURN CODE 0 FROM OPEN_DEVICE ------ PQ12426 IX76101 PQ12426 IC20341 IC20342 IC21197 ADSM ADMIN GUI ERROR MESSAGE ANR2606E INVALID START DATE WHEN CODING 29/02/2000 IN THE START TIME BOX FOR SCHEDULED BACKUP Customer was doing year2000 testing and discovered that coding 29/02/2000 in the admin GUI schedule start time box caused ANR2606E invalid start date but 29/02 IS a valid date for year 2000. ------ PQ12456 IX81433 IC21688 IC21689 IC21690 VOLUME LOCATION FIELD ERASE BY SERVER LEVEL 3 . QUERY VOLUME F=D for cartridges reveal that the field LOCATION DIAPPEAR , after the cartridge has been used by server level 3. The volume was defined at server level 2 , and when its been use by server level 3 , the LOCATION field of the volume LOST. ------ PQ13151 PQ16923 AFTER RUNNING "BACKUP VOLHIST", THIS MESSAGE IS ISSUED: "ANR9999D ICVOLHST(3048): ERROR WRITING TO OUTPUT FILE." ADSM EXPORT commands or any ADSM records being written to the volume history exceeding 1024 bytes will be truncated. ADSM uses the IBM "C" sequential file support default parameters which limits record length of the volume history file to 1024. PQ13963 IX79264 IC21198 IC21199 IC21200 DELETE MULTIPLE FILESPACES ANR0104E ARCHIVE.DESCRIPTIONS If the user deletes multiple filespace for a node at the same time, that is the deletes are running concurrently on the server, one of more of the delete filespace background threads may terminate with the following messages: . ANR0104E IMARINS(1301): Error .... deleting row from table "Archive.Descriptions". ANR0987I Process ... for DELETE FILESPACE running in the BACKGROUND processed .... items with a completion state of FAILURE at .... ------ PQ13967 IX76241 IC20402 WAIT HANG SESSION VERSION 3 A client session on a ADSM V3 server may hang doing a long split on a database page during backup processing. Externally, there are no unique symptoms to this problem other than eventually all client sessions most processes will hang. ------ PQ14728 IX79265 IC21201 IC21202 IC21203 ABEND0C4 IN ADSM PROC TMABORT+'8E' RUNNING ADSM V3 SERVER. The adsm MVS V3 server gets an abend0c4 in TMPROC+'8E'. The is processing a transaction abort from a client but there was no session started causing this abend. ------ PQ15066 IX79294 IC21213 IC21214 IC21215 ANR9999D ADMNODE(6648): INVALID NODE TYPE 0 FOR NODE ... This APAR is to document this message and let customers know that this message may be ignored. This message is issued as a result of code added in level 3.1.0.2 and 3.1.1.1 to correct a problem where server nodes were counted against the number of clients licensed. ANR9999D is a diagnostic message which should only be issued when there is a problem which requires further diagnosis or corrective action by ADSM Service. In this case, it is an inappropriate use of the message because the server is actually correcting an existing problem and no further action or diagnosis is required. ------ PQ15304 IX79295 IC21616 IC21691 IC21692 ABEND0C4 ORMADM.C+42CE ENDMOVEDRMEDIATHREAD()+48E REG07 MOVe DRMedia background thread terminates with ABEND0C4 in load module DSMSERV (ANRSERV) source module ORMADM.C at offset +42CE, stmt 2926, in function EndMoveDrmediaThread() at offset +48E. EndMoveDrmediaThread() calls FreeStorage() to free the storage used by the move drmedia thread. The last thing that FreeStorage() frees is the ormDesc structure. Upon return from FreeStorage(), EndMoveDrmediaThread() attempts to call pkExitThread() using a pointer in the freed ormDesc structure as an argument. ------ PQ15328 IX78196 IC20890 IC20891 IC20892 DUMPDB INCORRECTLY REPORTING ANR9999D DLDUMP(2361) After upgrading from V2 to V3, customer is finds that DUMPDP is incorrectly reporitng ANR9999D DLDUMP(2361): logical page corruption --- BACKUP DB does not report and errors and show tblscn report no errors. ------ PQ15478 IX79381 PQ17053 IC21256 IC21257 IC21258 UNABLE TO CONNECT MORE THAN 200 CLIENT SESSIONS FOR BACKUP. HARD CODED LIMIT IN TCPCOMM.C FOR HPNS_MAX_SESSIONS ------ PQ15644 IX79387 IC21266 IC21267 IC21268 SQL ERROR IN THE WEB SHELL ADSM ADMINISTARTION DURING REQUESTING THE POOL VOLUMES INFO IF POOL NAME LONGER THAN 18 CHARACTERS. Error using the Web Admin displaying an object with a long name, when a dependent object is selected for display. An example: When displaying a storage pool with a long name select the volumes icon to display the volumes in that storage pool. ------ PQ15767 IX79388 IC21269 IC21270 IC21271 PARSING ERROR FROM TIVOLI WHEN IBMADSM_SERVER_EVENT CONTAINS DOUBLE QUOTATION MARKS When reporting ADSM SERVER events to Tivoli, a parsing error occurs if the message to log contains double quotation marks. ------ PQ16051 ADSM MVS SERVER GETS ABENDU0301 IN SVMSIGER+'92' WITH SERVER AT 3.1.0.2 LEVEL. Abend X'301' caused by ADSM pkAbort() call in ANRAQMUT() while processing VTAM Lostrm interrupt. *************************************************************** ------ PQ16375 ANR9999D CSSESS "CANNOT REGISTER CLIENT ADDRESS TYPE 1" NT CLIENT MVS SERVER WITH INTERLINK TCPIP PROMPTED NT Client Prompted Scheduling MVS Server using Interlink TCPIP receives ANR9999D CSSESS 403 "cannot register client address type 1" ------ PQ16712 IX79389 IC21272 IC21273 IC21274 HANG OR WAIT OF ADSM SERVER WHEN USING WEBADMIN CLIENT The ADSM server can hang when using the WEBADMIN client if there are TCP/IP problems causing the send of data to hang in TCP/IP. The problem is in the HTTP communications path that the SMVARS mutex is being held while sending data. A SHOW THREADS will show most threads waiting on the same MUTEX. A Q SESSION will show an HTTP session in a SENDW state for a long time. ------ PQ16951 IX80115 IC21436 IC21437 IC21438 Q AUDITOCCUPANCY FROM MVS ADSM 3.1.1.3 DISPLAYS INCORRECT DATA. Query Auditoccupancy shows storage values for nodes which have no filespaces. ------ PQ17000 PROBLEM ON MULTIPLE ADSMS SERVERS WHICH PRODUCE THE FOLLOWING ANR1214I 3920557737, UNREADABLE FILES:0,UNREADABLE BYTES When insert for messages is an Int64 value of 0, garbage or blanks will result in the message. Problem was reported when customer noticed message ANR1214I was displayed with garbage data where inserts of 0 should have been. ------ PQ17158 IX79919 IC21370 IC21371 IC21372 NETWARE & WIN32 3.1.0.3 CLIENTS RESTORE FILES WHEN -DIRSONLY OPTION IS SPECIFIED IF THE DATA IS STORED ON SEQUENTIAL MEDIA. When the DIRSONLY option is used with a restore from a client, files are sometimes sent from the server to the client. The will happen if: - The No-Query Restore protocol is used - Directories to be restore have extended atributes that reside on sequential media in ADSM. ------ PQ17847 IX80959 IC21600 IC21601 IC21602 WEB ADMIN CLIENT RECONNECTS TO SERVER WITHOUT AUTHENTICATION When an administrator sign-on times out, the user can gain access to the server by pressing the cancel button on the authentication pop-up screen. ------ IC20958 IX79282 PQ16947 IC21368 IC21369 AUDIT LIBRARY aborts the server If the SCSI driver is not started on the NT server and I run an AUDIT LIBRARY, the server will take a dump ------ IX79537 IC21693 IC21694 IC21595 Incorrect text response SD-3CC and FORMAT=DRIVE fix for ECART ******************************************************************************** * 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 Trademarks __________ (*) Trademark of the IBM Corporation in the United States and other countries.