ADSTAR Distributed Storage Manager (ADSM) Server
README for Version 3, Release 1, Service Level 2.20
Licensed Materials - Property of IBM
(C) Copyright IBM Corporation 1990, 1999. All rights reserved.
This README file describes changes to the ADSM Version 3.1 Server since it's
release.
$$ Changes new to this service level are indicated by "$$"
This Readme is divided into the following sections:
---------------------------
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.
Back to the table of contents
------------
Getting Help
------------
Back to the table of contents
Obtaining Technical Support for ADSM
------------------------------------
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
For ADSM Technical Support Documents, visit the web site:
http://SSDDOM01.storage.ibm.com/techsup/swtechsup.nsf/support/adsmtechdata
Back to the table of contents
To Participate in User Discussions of ADSM
------------------------------------------
To participate in user discussions of ADSM:
+ Subscribe to an Internet listserv forum for ADSM
This is not officially supported by IBM, but IBM support people
do participate in the discussions, along with other ADSM users.
You can subscribe by sending a note to listserv@vm.marist.edu
that contains the following command in the message body:
SUBSCRIBE ADSM-L yourfirstname yourlastname
Posts can then be sent to: adsm-l@vm.marist.edu
Back to the table of contents
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)
Back to the table of contents
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
Back to the table of contents
----------
Trademarks
----------
(*) Trademark of the IBM Corporation in the United States and other
countries.
Back to the table of contents
---------------------
Backup Recommendation
---------------------
Server level 3.1.2.0 and later provides enhanced recovery log fault-tolerance
and new database entries to support enhanced functions. If you start this
server over an existing, pre service level 3.1.2.0 ADSM database, you will
not be able to remove this server program and run the older server over the
existing database/recovery log.
IBM recommends that you perform a full database backup on any ADSM server over
which you plan to install this code, so you can restore the database to the
appropriate level should you decide to remove this code.
Back to the table of contents
--------------------------
New Server Security Option
--------------------------
ADSM has been updated to provide additional control related to the
administrative authority required to issue selected commands that cause the
ADSM server to write information to an external file. A new server option
REQSYSAUTHOUTFILE has been added to control this processing.
REQSYSAUTHOUTFILE YES: Specifies that system authority is required for
administrative commands that cause the server to write to an external file.
The commands and associated parameters that are controlled by this option are:
- MOVE and QUERY DRMEDIA when the CMD parameter has been specified
- MOVE and QUERY MEDIA when the CMD parameter has been specified
- BACKUP VOLHISTORY when the FILENAMES parameter has been specified
- BACKUP DEVCONFIG when the FILENAMES parameter has been specified
- TRACE BEGIN when a file name has been specified
- QUERY SCRIPT when the OUTPUTFILE parameter has been specified
REQSYSAUTHOUTFILE NO: Specifies that system authority is not required for
administrative commands that cause the server to write to an external file
(i.e. there is no change to the privilege class required to execute the
command).
The default is REQSYSAUTHOUTFILE YES.
In addition, when REQSYSAUTHOUTFILE NO has been specified, authorization
changes have been been made to select QUERY commands that cause the ADSM
server to write information to an external file. The commands and their
associated authorization changes are:
- QUERY DRMEDIA or QUERY MEDIA with the CMD parameter require
operator, unrestricted storage or system authority.
- QUERY SCRIPT with the OUTPUTFILE parameter require, operator,
policy, storage or system authority.
The explanation for ANR2035E has been updated to indicate that this message
can be issued as a result of the server option REQSYSAUTHOUTFILE YES.
Note, it is assumed that proper access controls are in place for the
server options file dsmserv.opt.
Authorization to change or delete an ADSM command script have changed.
The UPDATE SCRIPT and DELETE SCRIPT command, have the following additional
controls in place:
- An ADSM administrator with system privilege can change or delete
any script
- If an ADSM administrator does not have system privilege, the
administrator must have previously created or updated the script.
For scripts created after the application of this maintenance, only a system
administrator or the administrator that created the script will be allowed to
update or delete the script. A new message ANR1493E will be issued if the
administrator is not authorized.
Back to the table of contents
-------------------------
New Licensing Information
-------------------------
The following functions are licensed as a separate Enterprise
Administration feature in this server:
Central Configuration
Central Logging
Central Commands
To enable the "Enterprise Administration" license, use a text editor to
cut out the following lines from this readme file into a license
certificate file named 'entadmin.lic' :
*------------------------- cut here -----------------------------------
(LicenseCertificate)
CheckSum=1C88F172ED60F14D3A0796C685041A8A
TimeStamp=896968609
PasswordVersion=4
VendorName=IBM Corporation
VendorPassword=uw7jvac4k3umq
VendorID=6fb1ea8d2ebc.a3.89.a3.25.04.00.00.00
ProductName=ADSM Enterprise Admin
ProductID=21364
ProductVersion=3.1
ProductPassword=nv7d2xagpibikab2raaxnaa
ProductAnnotation=
LicenseStyle=nodelocked
LicenseStartDate=06/03/1998
LicenseDuration=14457
LicenseEndDate=12/31/2037
LicenseCount=1
MultiUseRules=
RegistrationLevel=3
TryAndBuy=No
SoftStop=No
TargetType=ANY
TargetTypeName=Open Target
TargetID=any
DerivedLicenseStyle=
DerivedLicenseStartDate=
DerivedLicenseEndDate=
DerivedLicenseAggregateDuration=
*------------------------- cut here -----------------------------------
To register the license on the server, use the REGISTER LICENSE command
to read the license information into the server:
REGISTER LICENSE FILE=ENTADMIN.LIC
DRM Licensing - Clarification
The DRM license on the source server is the only license required to
store a recovery plan file on another server (i.e. the VIRTUAL VOLUMES
license is not required on the source and target servers, and the
NETWORK license is not required on the target server).
Back to the table of contents
----------------------------
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.
Back to the table of contents
------------------------------------------
Generating SSL Certificates for ADSM users
------------------------------------------
Included with the install package are utilities to create and maintain
certificates. The primary certificate tool is MKKFE. With this
utility a certificate request and key ring file can be created. Once a
certificate request has been created it can be sent off to a Certificate
Authority (CA) for signing. Self signed certificates can be created using
the provided utilites. However, there are some limitations, see the section
on "SSL Support Issues".
CREATING A KEY RING FILE AND CERTIFICATE REQUEST FOR THE SERVER
1. Start the MKKFE application. MKKFE requires the NLSPATH environment
variable to point to the location of the secnls.cat message catalog:
export NLSPATH=/opt/adsmserv/bin/%N
2. Create a new key ring file by pressing n. Name the new file
certkey.kyr. This filename is a requirement of the ADSM server, any
other name will not be recognized.
3. Create a new Certificate request
a.From the main menu press w to work with certificates.
b.To create a new certificate press c, At this point you will be prompted
for a password. This password is for the key ring file. Enter apollo.
Remember to keep the password for later use.
After the password has been entered twice, a prompt will ask if the
password is to expire. Answer no to this question.
c.The type of certificate to create is a PEM certificate, press s. You
will be presented with the following screen.
Compose PEM Certificate Request Menu
Current Certificate Information
Key Name: (none)
Key size: 0
Server Name: (none)
Organization: (none)
Organizational Unit: (none)
City/Locality: (none)
State/Province: (none)
Postal Code: (none)
Country: (none)
M - Modify the Certificate Request Fields
R - Ready To Create Key and Certificate Request
C - Cancel
Enter a command:
press m modify the request.
Enter in all personal information as requested by the program. Below is
a sample session.
Enter a name to use for the key entry:
ADSM Server
1: 508
2: 512
Enter the number corresponding to the key size you want: 2
Enter the server's fully qualified TCP/IP domain name
or press ENTER by itself to leave the field blank.
adsm_server.ibm.com
Enter Organization Name for the certificate
or press ENTER by itself to leave the field blank.
IBM
Enter Organizational Unit Name for the certificate
or press ENTER by itself to leave the field blank.
ADSM
Enter Locality/City Name for the certificate
or press ENTER by itself to leave the field blank.
SomeCity
Enter State/Province Name for the certificate
or press ENTER by itself to leave the field blank.
State/Province must be at least three characters long.
SomeState
Enter Postal Code for the certificate
or press ENTER by itself to leave the field blank.
99009
Enter Country Code for the certificate
or press ENTER by itself to leave the field blank.
Country code must be exactly two characters long.
US
a. The first thing entered is a name for the certificate request. This
name is for use by the key ring file. The second entry is for the key
size. The recommended size is 512. The next fields information about
your company and the location of the ADSM Server. When prompted for the
fully qualified TCP/IP address, don't enter a IP address. The entry is
the name of the machine where the ADSM server resides. For example,
adsm_server.ibm.com.
b. After the above information has been entered, you will be presented with
a summary of what has been modified. If everything is to your liking,
then you are ready to create a certificate request.
c. To create the certificate request press r. When prompted for a file
name type certreq.txt.
d. At this point you will want to mark the created certificate as the
Default Certificate of the key ring. To do this type f. After the
certificate has been marked as trusted root it is now time to receive
the certificate into the key ring file. You will need to return to the
Key Ring Menu to do this. Press x from the Key Menu to return to the
Key Ring Menu.
e. At this point all the work with the server key ring file is done.
Save the key ring by pressing s and exit the application by pressing x.
The certificate request that has been created can now be sent to a
Certificate Authority of your choice to be signed. This process might
require other paper work to be filled out. Check with the CA before
sending your certificate request. Also, some e-mail program might add
extra spaces to the end of a certificate, which will invalidate the
certificate, so be careful when sending and receiving certificate.
If you are using self signed certificates, then proceed to the next step.
RECEIVING THE SIGNED CERTIFICATE INTO THE SERVER KEY RING FILE
Once you have received the signed certificate from the CA, you will need
to receive the signed certificate into the server key ring file.
1. Start the MKKFE application.
2. Open the server key ring file by pressing o. Name the new file
certkey.kyr.
3. Receive the new Certificate.
a. If you are your own CA you will need to receive the CA certificate
before receiving the server certificate. First receive the
certificate into the key ring by
pressing r from the Key Ring Menu. Enter the filename of the CA
certificate request. From the above instructions the file name is
cacert.txt. You will be warned about adding a self-signed certificate
to the key ring file; press y to continue. You will then be prompted
for a name of the key. Enter a name and you will return back to the Key
Ring Menu. The next step is to make the received certificate a trusted
root. This is done by working with the certificate. Press w to work
with the certificate. The certificate will need to be selected at this
point. Press l to list and select the certificate. Press n to proceed
the next certificate until you find the name that you just entered.
Once that name has been found press s to select the certificate. You
will now return back to the Key Menu, where you can make the certificate
a trusted root by pressing t. Return back to the Key Ring Menu, by
pressing x, to continue with the next step.
b. To receive the signed server certificate, press r from the Key Ring
Menu. Enter the filename of the signed certificate, cert.txt for
example. You might receive a warning about the certificate signer
certificate not being part of the Key Ring. This mainly occurs when you
have become your own CA. The next step is to make the received
certificate the default certificate. This is done by working with the
certificate. Press w to work with the certificate. The certificate
will need to be selected at this point. Press l to list and select the
certificate. Press n to proceed to the next certificate until you find the
name that was originally given for the server certificate, this name is
ADSM Server from our example. Once that name has been found press s to
select the certificate. You will now return back to the Key Menu, where
you can make the certificate the default by pressing f. Return back to
the Key Ring Menu, by pressing x, to continue with the next step.
Now save the Key Ring file by pressing s from the Key Ring Menu. You
will be prompted that the file exists; it is OK to overwrite this file.
After the save has completed, exit MKKFE by pressing x.
SETTING UP THE ADSM SERVER FOR SSL
After all of the certificates have been created, copy the created file,
the signed certificate, the key ring file certkey.kyr and the cacert.txt
file if you are your own CA, to the ADSM server executable directory.
Before bringing up the ADSM server, add the COMMETHOD HTTPS to your
dsmserv.opt option file. This will indicate that the server should
bring up the SSL communication method. The port number is set by
HTTPSPORT in the dsmserv.opt. The default port is 1543. Start the ADSM
server. At this point SSL initiation will not occur, since the key ring
password is unknown. Define the key ring filename and passoword using the
DEFINE KEYRING command as shown below. Halt and restart the ADSM server
to start the SSL communication method.
WARNINGS MESSAGE FROM WEB BROWSER
You will receive a message from the web browser when you are your own CA.
This is mainly because the certificate that you have created is
not trusted by the browser. Each browser handles the matter differently.
Netscape will allow you to receive the certificate as a web site
certificate. The received certificate is then compared with the certificate
sent by the ADSM server every time you connect the server. After
setup has completed, you will not be prompted for any more information
in the future, that is if you click the always accept bullet in the
wizard. Internet Explorer handles the matter a little differently. It will
prompt you that the certificate being received is not trusted. You will
continue to get this message every time you connect to the ADSM server
unless you turn the warning message off.
SSL SUPPORT ISSUES
ADSM will support unsecure (non SSL) connection to any web browser capable
of understanding HTML version 2.0 on all ADSM server platforms. However,
certain combination of the secure connections between ADSM server and
web browser can cause problems. It is recommend that you connect with Netscape
Navigator version 4.05 or better to ADSM using Secure Socket Layer (SSL).
ADSM does not support SSL connections from UNIX ADSM servers to the Internet
Explorer web browser using certificates signed by the users own certificate
authority or self signed certificates. SSL connections are only supported
from UNIX ADSM servers to Netscape Navigator, which will accept self signed
certificates. ADSM does support Internet Explorer browser SSL connection to
the ADSM NT servers. Further, ADSM will support any user who goes out and
gets a certificate signed by a trusted Certificate Authority like IBM World
Registry or Versign.
DEFINE KEYRING Command.
Use the DEFINE KEYRING command to define a new key ring filename and password.
The key ring file is created using the MKKFE utility provided with ADSM.
This command will need to be issued before SSL will start correctly. If
this command has not been issued, the initialization of SSL will fail with
a message stating that the filename and/or password is invalid. After the
command has been issued to ADSM, halt and restart the ADSM server for the
SSL communication method to start.
Privilege Class
To issue this command, you must have system privilege.
Syntax
>>-DEFine KEYring--filename---password-----------------------------------><
Parameters
filename
Specifies the file name of the key ring file. This parameter is
required.
This file name must end with the extension .kyr, to indicate a key ring
filename. For example, certkey.kyr is a valid filename. The key ring
file must be place in server root directory.
password
Specifies the password of the key ring file. This parameter is
required.
This is the same password as the one used to create the server keyring
in the MKKFE utility.
Examples
Task
Define the key ring filename of certkey.kyr and password of apollo
Command:
define keyring certkey.kyr apollo
Expected output:
ANR4704I Key ring filename and password have been set. Restart ADSM to use
new
settings.
Back to the table of contents
-----------------------------------------
Notes for use of SNMP sub-agent (dsmsnmp)
-----------------------------------------
ADSM 3.1.2 servers cannot be used with versions of the SNMP subagent
( dsmsnmp ) prior to 3.1.2 and vice versa;
Command output from SNMP subagents which run scripts on ADSM servers
is truncated to 4026 characters. This is a limitation of SNMP agents.
The following files are updated for service level 3.1.2.1:
dsmsnmp
aix.adsm.defs
mib2adsm.tbl
adsmserv.mib
Two MIB variables have been added for control of text output from the
SNMP subagent; These variables allow control over column delimiters and
line delimiters. The two variables are:
ibmAdsmServerLineDelimiter
and
ibmAdsmServerValueDelimiter
These variables default to 0, which operates the same as the original
dsmsnmp, i.e., lines are delimited by carriage return/line feed
sequences and columns are delimited by blanks.
Each variable is an enumerated type ranging from 1-5 and 1-3
respectively (the enumerations are documented in the MIB ).
If ibmAdsmServerValueDelimiter is non-zero, the output in
ibmAdsmM1ReturnValue works as the administrative command line client
-commadelimit and -tabdelimit parameters, separating commas by either
commas or tabs. These are for values 1 and 2 respectively. A value of
3 may be used to delimit by a blank. In these cases, column headings are
suppressed.
For ibmAdsmServerLineDelimiter, the following values are allowed:
crlf (1) - output as the default with carriage return/line feed
separating lines
lf (2) - output with only a line feed between lines
comma (3) - output with only a comma between lines
tab (4) - output with only a tab between lines
blank (5) - output with only a blank between lines
Back to the table of contents
---------------------
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.
Back to the table of contents
-----------------------------
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.
Back to the table of contents
-------------------------------------
$$ Migration by Age from Random Media
-------------------------------------
MIGRATION BY AGE:
Customers are now able to specify how long they want their data to remain in a
disk storage pool with the following
additions to the disk storage pool definition:
MIGDelay=migdelayvalue
Specifies the minimum number of days that a file must remain in a storage
pool migration from the storage pool. The number of days is counted from the
day that the file was stored in the storage pool or retrieved by a client,
whichever is more recent. This parameter is optional. You can specify an
integer from 0 to 9999. The default is 0, which means migration is not delayed.
If you want the number of days to be counted based only on when a file was
stored and not when it was retrieved, use the NORETRIEVEDATE server option.
MIGContinue=migcontinuevalue
Specifies whether you allow ADSM to migrate files that do not satisfy the
migration delay time. This parameter is optional. The default is YES.
Because you can require that files remain in the storage pool for a
minimum number of days, ADSM may migrate all eligible files to the next
storage pool yet not meet the low migration threshold. This parameter allows
you to specify whether ADSM is allowed to continue the migration process by
migrating files that do not satisfy the migration delay time.
Possible values are:
Yes
Specifies that, when necessary to meet the low migration threshold,
ADSM continues to migrate files that do not satisfy the migration
delay time.
If you allow more than one migration process for the storage pool,
some files that do not satisfy the migration delay time may be
migrated unnecessarily. As one process migrates files that satisfy
the migration delay time, a second process could begin migrating files
that do not satisfy the migration delay time to meet the low migration
threshold. The first process that is still migrating files that
satisfy the migration delay time might have, by itself, caused the low
migration threshold to be met.
No
Specifies that ADSM stops migration when no eligible files remain to
be migrated, even before reaching the low migration threshold.
ADSM does not migrate files unless the files satisfy the migration
delay time.
NORETREIVEDATE option:
If you want the number of days to be counted based only on when a file was
stored and not when it was retrieved, use the NORETRIEVEDATE server option.
Specifies that the retrieve date of a file in a disk storage pool not be
updated when the file is restored or retrieved by a client. This option
can be used in combination with the MIGDELAY storage pool parameter to
control when files are migrated. If this option is not specified, files
are migrated only if they have been in the storage pool the minimum number
of days specified by the MIGDELAY parameter. The number of days is counted
from the day that the file was stored in the storage pool or retrieved by a
client, whichever is more recent. By specifying this option, the retrieve
date of a file is not updated and the number of days is counted only from
the day the file entered the disk storage pool.
If this option is specified and caching is enabled for a disk storage pool,
reclamation of cached space is affected. When space is needed in a disk
storage pool containing cached files, space is obtained by selectively
erasing cached copies. Files that have the oldest retrieve dates and
occupy the largest amount of space are selected for removal. When the
NORETRIEVEDATE option is specified, the retrieve date is not updated when a
file is retrieved. This may cause cached copies to be removed even though
they have recently been retrieved by a client.
Syntax:
NORETRIEVEDATE
Parameters: None.
Examples
NORETRIEVEDATE
Back to the table of contents
----------------------------------------------
Drive Cleaning Support for SCSI Tape Libraries
----------------------------------------------
ADSM 3.1.2.1 includes ADSM-controlled cleaning of tape drives in a
SCSI library and partial support in stand-alone (manual) libraries.
This support is intended to be used ONLY for those scsi libraries that
do NOT have their own automatic cleaning in the device hardware.
Automatic cleaning is included in such libraries as the STK 9710 and
IBM 3570 and 3575, and ADSM is not aware or involved with it in any
way. ADSM-controlled cleaning is not as tightly integrated with the
device hardware as a library's own automatic cleaning and may actually
conflict with it. The default for ADSM-controlled cleaning is NONE,
which means cleaning is up to the library hardware or a human
operator.
The automatic cleaning included in some SCSI libraries interferes with
ADSM's use of the library and drives. If this is the case with your library,
turn off the built-in automatic cleaning and use ADSM-controlled cleaning.
** ATTENTION **
Use of ADSM-controlled cleaning involves checking a cleaner cartridge
into the library's volume inventory. Be careful when using the
CHECKIN, CHECKOUT, LABEL, and AUDIT LIBRARY commands to ensure that a
cleaner cartridge is not inadvertently loaded into a drive instead of
a data cartridge. Details on how to prevent mistaking a cleaner
cartridge for a data cartridge are provided below.
Overview for SCSI Libraries
You set up ADSM-controlled drive cleaning with the following three
steps:
1. Define the drives in a library with the new parameter that
defines the frequency of cleaning.
2. Check a cleaner cartridge into the library's volume inventory. ADSM
mounts the cleaner cartridge in a drive when it needs cleaning.
3. When needed, issue or schedule the new command, CLEAN DRIVE. Use
this command when you want ADSM to immediately load a cleaner cartridge into
a drive regardless of the cleaning frequency.
Details on these steps follow.
--------------------------------------------------------------------------------
1. Defining the drives with frequency of cleaning
A new parameter, CLEANFREQUENCY, is added to the DEFINE DRIVE command.
The following is the new DEFine/UPDate command syntax:
>>-DEFine/UPDate DRive--libname--drivename--DEVIce-=-devicename->
.-ONLine--=--Yes------.
>---+---------------------+--+----------------------------+----->
'-ONLine--=--+-Yes-+--' | |
'-No--' '-ELEMent--=--elementaddress-'
'-CLEANFREQuency-=-+-NONE------+
>---+------------------------------+---------------------------><
'-CLEANFREQuency-=-+-NONE------+
|-ASNEEDED -|
| '-value-----'
For the CLEANFREQUENCY parameter, possible values are:
- NONE, meaning ADSM does not track the need for device cleaning.
This is the default. Use for libraries that have their own automatic
cleaning.
- ASNEEDED, meaning that only when a drive reports a cleaning-needed
indicator to the device driver does ADSM load the drive with a
checked-in cleaner cartridge.
- A value from 1 to 9999 that specifies how much data in Gigabytes
should be processed on the drive before ADSM loads the drive with a
cleaner cartridge. ADSM also responds to cleaning-needed indicators
from a drive with this option, as for the ASNEEDED option.
When the drive indicates that it needs to be cleaned or the
GBytes-processed threshold is exceeded, the drive finishes processing
the volume that is mounted on it. As part of the dismount processing,
ADSM loads a cleaner cartridge into the drive (provided that one is
checked into the library inventory) and resets the GBytes-processed
counter.
2. Check a cleaner cartridge into the library's volume inventory
Use the CHECKIN LIBVOL command to check a cleaner cartridge into the
library. The following is the CHECKIN LIBVOL command syntax showing
the new STATUS value of CLEANER and the new CLEANINGS parameter:
>>-CHECKIn LIBVolume--libraryname--volname---------------------->
.-CHECKLabel--=--Yes--------------.
>---STATus--=--+-PRIvate-+--+---------------------------------+->
|-SCRatch-| '-CHECKLabel--=--+-Yes---------+--'
'-CLEaner-' +-No----------+
'-Barcode-----'
.-SWAP--=--No-------.
>----+-------------------+--VOLRange--=--+-volname1-+----------->
'-SWAP--=--+-No--+--' '-volname2-'
'-Yes-'
.-MOUNTWait--=--60---------------.
>---+--------------------------------+-------------------------->
'-MOUNTWait--=--mountwaitvalue---'
.-SEARCH--=--No------------.
>----+--------------------------+------------------------------->
'-SEARCH--=--+-No-------+--'
+-Yes------+
'-Bulk-----'
>----+-----------------------+---------------------------------><
'-CLEANINGS--=--1..1000-'
The STATUS=CLEANER parameter value designates the volume as a cleaner
cartridge and not a data cartridge. Check in a cleaner cartridge
separately from data cartridges using STATUS=CLEANER.
The CLEANINGS parameter is required for cleaner cartridges. Set the
value to the recommended number of uses for the cleaner cartridge
(usually indicated on the cartridge).
The volume name is arbitrary, because the name is never read from the
cleaner. However, if the cleaner has a barcode label, use that value
as the volume name.
CHECKLABEL=YES is invalid for checking in a cleaner.
Although you can check in cleaner cartridges using SEARCH=YES, it is
recommended that you check them in one at a time.
If you check in more than one cleaner cartridge, ADSM uses only one
cartridge until that cartridge is used the number of times indicated
by the CLEANINGS value. ADSM then selects another cleaner cartridge,
and you can check out and discard the first cartridge. When a cleaner
cartridge has five or fewer cleanings left, ADSM issues a warning with
each use.
You cannot update the status of a volume from CLEANER to SCRATCH or PRIVATE,
and vice versa. If you have checked in a volume with the wrong status, you
must check the volume out and check it back in again with the correct status.
This process helps to prevent changing a cartridge to the wrong status.
When you check out the volume, use the REMOVE=YES option of the CHECKOUT
command, so that you can verify the type of cartridge.
You can change the CLEANINGS value by using the UPDATE LIBVOLUME command
with
the STATUS=CLEANER parameter.
3. When needed, issue or schedule the new command, CLEAN DRIVE.
The syntax of the command is:
>>-CLEAN--DRIVE--libraryname--drivename----------------------><
This command is valid only in a SCSI library that has a cleaner
cartridge checked into its inventory. This command marks the drive as
needing to be cleaned. If the drive is not busy at the time, ADSM
loads the cleaner cartridge into the drive immediately. If the drive
is busy, ADSM loads the cleaner cartridge when the drive is unloaded.
Determining How Often A Drive Should Be Cleaned
Consult the manuals that accompany the drives for cleaning
recommendations. In some cases, the manuals describe the cleaning
frequency in terms of hours of use. In this case, use the drive's
bytes per second speed rating to determine a GBytes per hour value for
the drive. Then multiply the GBytes/hour by the recommended hours of
use between cleanings. Use the result as the CLEANFREQUENCY to be set
on the drive definition. Alternatively, you can set the
CLEANFREQUENCY to ASNEEDED to allow the drive to signal when it needs
to be cleaned. In some cases, however, this alternative is not
reliable.
Preventing Problems When Using A Cleaner Cartridge in a SCSI library
When a cleaner cartridge is checked in to the library, ADSM cannot
verify that the cleaner cartridge is in fact a cleaner. Various
ADSM-supported drives and libraries differ in how they handle
cleaners, how they report the presence of cleaners in a drive, and how
the device drivers on different platforms are able or are not able to
open a drive that may contain a cleaner at the time. This variability
means that ADSM cannot uniformly detect a cleaner cartridge. For this
and other reasons, ADSM does not intentionally load the cleaner
cartridge into a drive until the drive needs to be cleaned.
Because of ADSM's limited ability to recognize a cleaner, ensure that
you do not check in a data cartridge with STATUS=CLEANER, and that you
do not check in a cleaner with STATUS=SCRATCH or PRIVATE. For
instance, when running a CHECKIN or LABEL command with SEARCH=YES, do
not allow a cleaner to be placed in a slot that will be detected by
that search process. TO DO SO WILL PRODUCE A NUMBER OF ERRORS,
including I/O errors and long delays on drive loads and unloads, which
may be on the order of 15 minutes.
Cleaners that are already checked in are not a problem when checking
in data cartridges with SEARCH=YES, provided that the cleaners are in
their correct home slots. To help you verify that cleaners are in
their correct home slots, the QUERY LIBVOL command now provides the
element ID of the home slot for all library volumes. Visually verify
the correct storage slots for cleaners before using a search process
to check in volumes or before auditing a library. PLEASE NOTE:
Because AUDIT LIBRARY does not audit a slot that has a cleaner
cartridge checked into it, visually verifying a cleaner's home slot is
especially important before running an AUDIT LIBRARY command.
If a drive needs to be cleaned, ADSM runs the cleaning operation after
dismounting a volume. If the cleaning operation fails or is
cancelled, or if no cleaner is checked in that has any cleanings left,
then the indication that the drive needs cleaning is lost. Monitor
cleaning messages for these problems. If necessary, clean the drive
either by issuing a CLEAN DRIVE command or by manually loading a
cleaner into the drive.
Drive Cleaning Without Checking a Cleaner Into the Library
You can specify a cleaning frequency for a drive without checking a
cleaner cartridge into the library. When a drive needs to be cleaned
based on the clean frequency criteria, ADSM issues this message:
ANR8914I Drive in library needs to be cleaned.
The message is issued whether or not a cleaner is checked into the
library. You can use that message as a cue to manually insert a
cleaner into the drive. You may want to do this if you do not want to
deal with the constraints of having a cleaner checked into the
library's inventory. There is, however, no support for a QUERY
command to indicate that a drive is in the needs-cleaning state. ADSM
cannot determine from the drive that the drive has been cleaned so
that such an indicator could be turned off after cleaning.
Drive Cleaning in a Manual Library
This support is the same as in "Drive Cleaning without Checking in a
Cleaner." There is no library inventory in a manual library, but the
ANR8914I message is issued when a drive needs to be cleaned. The
operator must monitor for these messages and load a cleaner cartridge
into the drive when needed.
Back to the table of contents
--------------------------------
Preserving ACSLS Server hostname
--------------------------------
After the product installation, the user should ensure CSI_HOSTNAME is
properly defined. To do this
Define the environment variable ACSLS_SERVER_HOSTNAME in the system wide
environment file /etc/environment or the system wide profile /etc/profile and
assign it your ACS host name.
Back to the table of contents
---------------------------------
CHECKIN and LABEL command changes
---------------------------------
A new parameter VOLLIST has been added to the CHECKIN and LABEL LIBVOLUME
commands to allow the user to specify a list of volumes for the process.
VOLList=volumespec
Specifies the volume names that are to be used by the CHECKIN or LABEL
commands. volumespec can be a list of volume names or a file that a
list of volume names.
VOLList=vol1,vol2,vol3 ...
specifies the names of the volumes. Each volume name is separateed by
a comma with no intervening spaces. For example:
VOLL=TAPE01,TAPE02,TAPE03
VOLList=FILE:filename
Specifies the path and name of the file that contains a list of volumes.
In the file, each volume name must be on a separate line. Blank lines
and comment lines that begin with an asterisk are ignored.
For example, to use TAPE01, TAPE02 and TAPE03, create a file called
TAPEVOL that contain these lines:
TAPE01
TAPE02
TAPE03
and specify the parameter as follow:
VOLL=FILE:TAPEVOL
The path and filename are case sensitive.
This parameter is optional. However, if specified the
SEARCH=YES option must also be specified. In addition, if specified, the
existing VOLRrange parameter must not specified.
This parameter is supported for SCSI, 3494 or ACSLS libraries.
CHECKOUT command:
To support the bulk volume checkout function from a ACSLS library, two
parameters,
VOLRANGE and VOLLIST have been added to the CHECKOUT LIBVOLUME command to
allow the user to specify a list of volumes or a range of volumes. If either
VOLRANGE or VOLLIST is specified, the existing "volname" for the single volume
checkout function must not specified.
VOLRANGE and VOLLIST are not supported for the 3494 and SCSI libraries. When
specified, REMOVE=BULK is treated the same as REMOVE=YES. REMOVE=BULK is not
supported for single volume checkout for the ACSLS library.
VOLRange=vol1,vol2
Specifies the volume range for this command. The volume format can be
any combination of alphanumeric characters. Basically, it contains prefix,
incremental and sufix areas.
The prefix and sufix areas are optional. If they are used, they are
identical alphanumeric characters between vol1 and vol2. Prefix area
begins at the first character and ends at the first "non-compare" numeric
character. The incremental area are numeric characters which begins after
the prefix area and ends at the next alpha character, if any. The incremental
numerics of vol2 must be greater than the numerics of vol1. The sufix area,
optional, begins at the end of the incremental area and are all alpha
characters.
The possible combination for volume range are:
AnA, nA, An, n or A
"A" means the prefix or sufix area where the alphanumeric characters of
vol1 and vol2 are identical. "n" is the incremental area.
For example:
VOLR=ABC123,ABC234
VOLR=123456,123567
VOLR=123ABC,234ABC
VOLR=A123BC,A234BC
This parameter is optional. However, if specified the VOLLIST parameter
must not specified.
VOLList=volumespec
Specifies a list of volume names to be used by the CHECKOUT command.
volumespec can be a list of volumes or a file that contain a list of volumes.
VOLList=vol1,vol2,vol3 ...
specifies the names of the volumes for the process. Each volume name
is separated by a comma with no intervening spaces. For example:
VOLL=TAPE01,TAPE02,TAPE03
VOLList=FILE:filename
Specifies the path and name of the file that contains a list of volumes.
In the file, each volume name must be on a separate line. Blank lines
and comment lines that begin with an asterisk are ignored. For example,
to use TAPE01, TAPE02 and TAPE03, create a file called TAPEVOL that
contain these lines:
TAPE01
TAPE02
TAPE03
and specify the parameter as follow:
VOLL=FILE:TAPEVOL
The path and filename are case sensitive.
his parameter is optional. However, if specified the VOLRANGE parameter
must not specified.
Back to the table of contents
------------------------------------------------------------
Information on Data Errors in prior levels of ADSM Version 3
------------------------------------------------------------
Overview
--------
ADSM Version 3 AIX servers prior to service level 3.1.1.5 and non-AIX
servers prior to service level 3.1.1.3 have experienced data errors
during movement/reclamation of files stored on sequential-access media.
Information regarding these problems has been distributed in several
different forms. To reduce confusion, this package updates, summarizes,
and simplifies information about these problems.
The ADSM organization has gone to great lengths to ensure that problems
involving data errors are addressed in a forthright and aggressive manner.
While some problems are not likely to be seen by customers, we have
nonetheless issued warnings and provided fixes as soon as possible to
eliminate the remote possibility of affecting customer data.
We have developed commands to identify and manage affected files. Once
identified, these files can be recovered from valid copies the server has
made, or the files can be deleted so that new backups are produced.
NOTE to non-AIX platforms: This PTF contains an updated set of utilities
that checks for any data errors that might have been introduced while the
server was running at the 3.1.1.3 level. Although data errors at the
3.1.1.3 service level have only been observed on AIX, we are providing the
updated utilities on all platforms as a precaution. The updated utilities
contain an abbreviated audit that checks for any problem files.
Back to the table of contents
Frequently Asked Questions
--------------------------
[NONE]
Back to the table of contents
Documentation for Reclaimation Utilities
----------------------------------------
Following information was updated July 1998 >>>
In early 1998, ADSM Development discovered and reported a problem with
data movement/reclamation processing on Version 3 servers. Subsequently,
Development distributed a set of utilities that could be used by ADSM
customers to identify and handle client files that may have been affected
by this error. Please refer to information APAR II11170 to determine
whether the utilities should be run to deal with files affected by this
error.
In July 1998, the utilities were modified to cover APAR IX79165. This APAR
involves a problem which allows aggregate reconstruction to produce files
with an incorrect size. The utilities now identify client files that
have been affected by this problem. The updated utilities are able to
detect ALL files affected by IX79165, regardless of how many reconstructions
might have been performed.
To date, IX79165 has only been observed on AIX Version 3 servers; however,
we recommend that the updated utilities be run on all Version 3 servers
as a precautionary measure.
The modified utilities include an audit with two modes of operation. The
first mode is the 'complete' mode or normal mode. This mode should be used
by customers who should run the utilities for the original data
movement/reclamation problem (see APAR II11170), but have not yet done so.
The updated utilities in this mode will examine all client files for
problems referenced in both II11170 and IX79165.
The second mode is the 'abbreviated' mode and should be used by customers
whose servers are not affected by the problem described in II11170 or who
have already run the utilities to manage files affected by this problem.
The abbreviated audit will typically run faster than the complete audit.
Please see the section titled 'AUDIT RECLAIM COMMAND' for the syntax and
an explanation of the two audit modes. All other commands described in
this document are the same regardless of which audit mode is used.
Important note to customers who have begun using the utilities without
the July 1998 update, but have not yet finished running the entire set
of utilities: If you have not already applied this PTF, please finish
running the entire set of utilities (including the CLEANUP RECLAIM
command) to completion before applying the PTF; you can then apply this
PTF and run the updated utilities using the MODE=ABBREV option.
Alternatively, if you have already applied this PTF, you should run
the updated audit with the MODE=COMPLETE and FORCEREANALYSIS=YES options.
The remainder of this document describes the utilities that are provided to
assist an administrator in managing client files affected by both II11170
and IX79165.
<<< End of July 1998 update
Back to the table of contents
Problem Description
-------------------
ADSM Version 3 introduced a new storage mechanism to improve performance and
reduce overhead. During client backup and archive operations, small files
are automatically packaged into larger objects, called "aggregates," for
management on the ADSM server. As expiration deletes files from the server,
vacant space can develop within aggregates. For data stored on sequential
media, this vacant space is removed during reclamation processing. The
procedure for removing vacant space within aggregates during reclamation is
called "reconstruction," because it entails rebuilding an aggregate without
the empty space.
ADSM Development recently discovered an error in the Version 3 server that
can result in invalid data after an operation in which data is moved/copied
from a sequential-access storage pool volume. Initially, it was believed
that this error occurred only during reconstruction of file aggregates.
Accordingly, updated servers were made available to prevent the problem by
temporarily disabling reconstruction of aggregated files during reclamation
processing. Subsequently, ADSM Development determined that the problem
can actually be introduced during other operations in which files are moved
or copied from sequential-access volumes on a Version 3 server.
These operations include
o Reclamation
o Move data from a sequential-access volume
o Migration from a sequential-access storage pool
o Backup of a sequential-access storage pool
o Restore volume or restore storage pool from a copy storage pool
The error can potentially affect backup, archive, or space-managed files on
Version 3 servers, including files that were initially stored on a Version 1
or Version 2 server and later move/copied from a sequential-access volume on
a Version 3 server.
Many customers initially store files in a disk storage pool and back up the
files to a copy storage pool before allowing the files to migrate to a
sequential-access pool. In this scenario, both copies of the file are valid
at the time of the storage pool backup. If either the primary or copy pool
file later becomes affected by one of the operations listed above, it is
likely that the other copy still contains valid data.
Please see APARs IX74458 and IX76734 for information about the data
movement/reclamation problems and APAR II11170 for information about the
specific Version 3 server levels that are affected.
ATTENTION: Using export and import to transfer file data from one server to
another may result in transfer of files that have invalid data due to data
movement/reclamation on the source server. These problem files would not be
detectable on the target server. We recommend that export and import not be
used to transfer file data among Version 3 servers until you have finished
using the utilities to manage the data move/reclamation problem.
Back to the table of contents
Overview of Reclaimation Utilities
----------------------------------
The utilities obtain the information they need from the ADSM database.
They do not access files in the ADSM storage hierarchy, and therefore do not
require mounting of storage pool volumes.
The following utilities are provided
o An AUDIT RECLAIM command checks the ADSM database for logical files
that may be affected by this problem and stores information about
those objects in a RECLAIM_ANALYSIS table.
o After the audit, the RECLAIM_ANALYSIS table can be queried using the SELECT
command. It may be possible to restore valid copies of these files from
a copy storage pool. Alternatively, the files can be restored/retrieved
to the client for examination or they can simply be deleted.
o A DELETE RECLAIM command can be used to delete logical files in the
RECLAIM_ANALYSIS table from the ADSM database. For backup files that still
exist on the client machine, the next incremental backup should then store a
new copy of the deleted file on the ADSM server.
o A REMOVE RECLAIM command allows you to delete the entry for an individual
logical file from the RECLAIM_ANALYSIS table. Optionally, the file itself
can be deleted from the ADSM server database.
o A CLEANUP RECLAIM command deletes all entries from the RECLAIM_ANALYSIS
table and reactivates reconstruction processing (if reconstruction has
previously been disabled).
The utilities are the only dependable way to identify files that are
affected by this problem. In general, the AUDIT VOLUME command does not
detect affected files and may actually undermine the utilities by marking
files as undamaged that have previously been marked damaged by the
utilities. Once you begin using the utilities by issuing the AUDIT RECLAIM
command, you should not use the AUDIT VOLUME command until you have
completed analysis of this problem and have run the CLEANUP RECLAIM command.
ATTENTION: Do not run the CLEANUP RECLAIM command until you have handled all
files that are suspected to contain errors. Once you issue the CLEANUP
RECLAIM command, you will not be able to use the other utilities.
HOW THE AUDIT WORKS
-------------------
The audit utility works by examining information about physical files
(aggregates and non-aggregates) in the ADSM database. By analyzing this
file information, the audit identifies physical files that have been
affected by the data movement/reclamation problem and determines which
logical files have invalid data. When it detects such a logical file, the
audit stores information about the file in the RECLAIM_ANALYSIS table for
use by the other utilities. In most cases, the audit can determine with
certainty whether a particular logical file is affected. However, there are
situations, described in the following paragraphs, in which detection of
problem files may be inaccurate or impossible.
The audit detects all aggregates that have data errors because of the LAST
reconstruction procedure for that aggregate. However, if an aggregate has
been reconstructed more than one time, the analysis cannot determine whether
the aggregate was affected during a previous reconstruction. As described
in the next section, the audit provides an option for identifying files that
may be affected by multiple reconstructions.
If problem files are transferred from one Version 3 server to another using
export/import, any problem files that existed on the source server would not
be detectable on the target server.
If an HSM client has migrated a file to the server and that same file is
later backed up or archived, the backup/archive copy is created by
duplicating the space-managed file that is already stored on the server.
Even if the space-managed file is valid, it is possible that the new
backup/archive could be invalid if a data movement problem occurs during
duplication operation. In this situation, the invalid backup/archive file
would not be detected by the audit. This situation should not occur
commonly, since the default value for the MIGREQUIRESBKUP management class
attribute is YES, meaning that the backup copy must exist before a file can
be migrated from an HSM client to the server.
Dealing with Possible Multiple Reconstructions
----------------------------------------------
In almost all cases, the audit can definitively detect logical files that
are affected by the data movement/reclamation problem. However, the
server does not have enough information to determine which aggregates have
been reconstructed more than one time (during separate reclamations) and
which of these aggregates might have incurred a problem during a
reconstruction other than the most recent. Because of this uncertainty,
the AUDIT RECLAIM command provides a LASTONLY option that allows the
administrator to specify how the audit should handle the possibility of
multiple reconstructions of the same aggregate.
The default option, LASTONLY=YES, for the AUDIT RECLAIM command causes the
audit to ignore the possibility of errors from reconstruction operations
other than the most recent. With this option, the audit identifies
logical files that were affected by data movement/reclamation operations
other than reconstruction and creates an entry in the RECLAIM_ANALYSIS
table for each of these logical files; each of these entries is assigned a
category of DEFINITE, meaning that the file is definitely affected by the
problem. With this option, the audit also identifies logical files that
were affected by the last reconstruction and categorizes these logical
files as DEFINITE in the RECLAIM_ANALYSIS table. However this option does
not report any aggregates that contain invalid data because of
reconstruction operations prior to the most recent reconstruction.
You can also specify LASTONLY=NO when you run the AUDIT RECLAIM command.
If you do this, the audit identifies the same logical files that would be
identified with the LASTONLY=YES option, and categorizes these logical
files as DEFINITE in the RECLAIM_ANALYSIS table. In addition, the
LASTONLY=NO option identifies any logical files that might have been
affected by earlier reconstructions and stores information about these
files in the RECLAIM_ANALYSIS table with a category of POSSIBLE. Because
the server does not have enough information to absolutely determine which
logical files were affected by earlier reconstructions, it makes a set of
worst-case assumptions. The result is that AUDIT RECLAIM LASTONLY=NO will
identify all logical files that could possibly have been affected by
multiple reconstructions. However, most of the logical files so
identified will not have errors. If you use this option, the number of
logical files categorized as POSSIBLE will be MUCH larger than the number
of logical files categorized as DEFINITE.
Handling Problem Files
----------------------
The AUDIT RECLAIM command also provides an EXAMINECOPIES option that allows
you to specify what should be done when definite or possible problem files
are identified. With the default option, EXAMINECOPIES=NO, suspect logical
files are merely entered in the RECLAIM_ANALYSIS table and given a state of
IDENTIFIED. This option should be used if you have NOT been using the
BACKUP STGPOOL command to back up your storage pool data.
You can also specify an option, EXAMINECOPIES=YES, that causes the audit
to look for additional copies of any primary physical file with a definite
or possible error; by doing so, the audit may locate a copy that is not
affected by the problem. In searching for copies of aggregates, the server
uses the criteria dictated by the LASTONLY parameter discussed above.
The EXAMINECOPIES=YES option should be used if you intend to restore affected
primary files for which a good copy exists.
When the EXAMINECOPIES=YES option is used, additional processing described
below is performed when a definite or possible problem file is found.
This processing causes the audit to run longer, but may allow files to be
regenerated from good copies in other storage pools using the normal storage
pool backup and storage pool restore operations.
If EXAMINECOPIES=YES is used and a physical file with definite or possible
problems is detected, the server's response will depend on whether the
affected file is a copy, cached, or primary file. If a physical file in a
copy storage pool is found to contain invalid data, the copy is deleted.
Similarly, if a cached copy has errors, the cached copy is deleted. Deletion
of a copy pool file or cached file does not affect the corresponding primary
physical file.
If a primary physical file is found to have a possible or definite error,
the server checks for an unaffected copy of the physical file in a copy
storage pool. If a good copy is found, the entire primary physical file is
marked as "damaged" and can later be restored using the RESTORE STGPOOL
command. For such physical files, an entry in the RECLAIM_ANALYSIS table is
also created for each possible or definite problem logical file. The entry
records the state of the logical file as MARKED_DAMAGED, indicating that the
corresponding physical file has been marked as damaged.
If a primary physical file contains invalid data and the server is unable to
locate a copy that is unaffected by the problem, an entry in the
RECLAIM_ANALYSIS table is created for each possible and definite problem
file in the physical file. In this case, the entry records the state of
these logical files as IDENTIFIED.
Back to the table of contents
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'
Back to the table of contents
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.
Back to the table of contents
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.
Back to the table of contents
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------<
Back to the table of contents
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.
Back to the table of contents
------------------------------------
Clarification of fix to APAR IX79626
------------------------------------
Service aids "delete archd " and "delete object force=yes" and
online and offline audit tools were provided in service level 3.1.2.0.
The root cause of the problem, serialization, is fixed by this PTF.
It has been recently discovered that the audit tools are not working
properly. The fix was not available in time to meet the delivery date
for this PTF so both the online and offline audit tools have been disabled.
Back to the table of contents
-------------------------------------------------
$$ Change to MOVE DRMEDIA and MOVE MEDIA Commands
-------------------------------------------------
While moving volumes from the MOUNTABLE state with REMOVE=YES specified, MOVE
DRMEDIA and
MOVE MEDIA commands will now utilize more than one slot in the CAP for an STK
library with ACSLS.
Back to the table of contents
------------------
SSI Initialization
------------------
If you are using the STK Silo with ADSM and your system is setup so that both
ADSM and the ACSLS
client daemon (SSI) are automatically started when the system is re-booted, you
may notice the message
"STATUS_IPC_FAILURE". This message will occur when ADSM attempts to contact the
ACSLS server via
the SSI client and the SSI daemon has not finished its initialization.
This message does not indicate a failure in the ADSM library initialization if
retry is successful in two minutes.
Relief from the issuance of this message may be obtained by changing the
position of the entry in /etc/inittab for starting
the SSI daemon with respect to the autostart entry for ADSM server.
The steps below will move the entry for the ACSLS daemon so that it is started
sooner than the ADSM server.
You must issue the following commands as the root user.
1. Remove the entry for the ACSLS daemon
rmitab autoacs
2. Add the entry for the ACSLS daemon so that it is invoked just before the
entry to start the AIX Windows Desktop Login
mkitab -i dt "autoacs:2:once:"/usr/adsm.devices/bin/rc.acs_ssi quiet
>/dev/console 2>&1"
Note: If you do not have the AIX Windows Desktop installed you will have to
choose another entry. You can list the
entries in your /etc/inittab file with the command lsitab -a. You should
choose an entry with a wait action to
give ACSLS as much time as possible to initialize before the ADSM server is
started. (TCP/IP and NFS
should be started before starting ACSLS.)
Back to the table of contents
----------------------------------
$$ Accounting Environment Variable
----------------------------------
This service level introduces a new environment variable on the UNIX
platforms ( NT already supports
this function through a registry key ).
The environment variable is DSMSERV_ACCOUNTING_DIR. It is used to specify a
directory in which
the accounting file is opened; The accounting file is always dsmaccnt.log.
The variable is supported to allow customers running multiple servers on the
same machine to keep
separate accounting files for each server.
If DSMSERV_ACCOUNTING_DIR does not exist when the server is started, the
current directory
is used for the accounting file. If it does exist, the directory name
specified is used for the file.
Example:
( AIX Korn Shell );
EXPORT DSMSERV_ACCOUNTING_DIR=/u/test/servera
./dsmserv
If accounting is on, the server will open file /u/test/servera/dsmaccnt.log
Back to the table of contents
-----------------------------------
APARS fixed by prior service levels
-----------------------------------
IX79245 DSMSERV AUDITDB PARAMETERS ARE NOT WORKING AS DOCUMENTED
FILE=xx parameter on DSMSERV AUDITDB not directing output to
V2 file.
IX79248 SESSION NUMBER GREATER 99999 WILL NOT BE DISPLAYED PROPERLY
IX75336 SELECT OCCUPANCY ... OUTPUT DOES NOT MATCH QUERY OCCUPANCY OUTPUT
The SQL SELECT FROM OCCUPANCY does not display filespace
information correctly for nodes with multiple filespaces.
IX74446 Server incorrectly reporting missed schedules
ANR2478I MESSAGE IS GENERATED WHEN THE SCHEDULE DOESN'T FINISH
WITHIN START WINDOW. THIS MESSAGE SHOULD ONLY BE ISSUED IF
SCHEDULE HAS NOT STARTED WITHIN START WINDOW.
IX75715 Tivoli event receiver needs hostname slot
ADSM did not pass the HOSTNAME slot to Tivoli.
IX75962 Excessive ANR8216W messages with Tivoli event logging
The Tivoli event receiver did not properly detect when the
Tivoli event server went down.
IX76138 QUERY SESSION hangs the server when it has much output
When issuing a QUERY SESSION command from an admin client, and the
number of sessios is so large that the entire output from the command
cannot fit in a single buffer (over 150 sessions), the server can
hang due to deadlock contention of the Session Mutex.
IX76147 WEB ADMIN DOES NOT SEE DEFINED DRIVES, AND IN CUSTOMER'S CASE,
HIS 3494 LIB.
SQL queries and Web Admin pages return Not Found instead of
no space available when there is insufficient database space
for SQL temporary tables.
This will occur when a Q DB shows 0 in the Maximum Reduction
field.
IX76494 Archive performance degredation
archive query/retrieve performance is degraded from V2
IX76472 SELECT * FROM VOLUMEUSAGE DOES NOT LIST ALL VOLUMES
WHICH CONTAIN DATA.
entries are missing from 'select * from volumeusage' output
IX76739 ANR2751I ISSUED WHEN ANR2756I IS APPROPRIATE
IX76854 OPTICAL SUPPORT. DUE TO BAD SECTOR OR HARDWARE RELATED ISSUES
ADSM WILL NOT ACCESS REST OF THE FILES AND MARK THEM ALL BAD
The problem is that any single I/O error from the drive on a
read operation prevents any other access to that side of the
platter until the platter is dismounted. This impacts the
AUDIT VOL and MOVE DATA commands from being able to access
otherwise good files on the platter because one file had
a bad sector in it.
IX77291 THE DRM -> PREPARE ICONS ON THE WEBADMIN WILL RECOGNISE ONLY THE FIRST
STGPOOL GIVEN IN A LIST.
The PREPARE panel for the Web administrative interface
incorrectly displayed partial storage pool information in
the COPYSTGPOOL and PRIMSTGPOOL fields.
IX77477 AIX ADSM SRV 3.1. GETS ANR8355E,ANR8311E WHEN TRYS TO MOUNT
THE STORAGE TEK (ACSLS 5.1.1) TAPES WITH HEADER TYPE 1.
prelabelled tapes do not have the HDR2 which ADSM expects
IX77638 ADSM ADMIN COMMANDS THAT DO NOT REQUIRE SPECIAL ADMIN AUTHORIZATION
CAN BE ISSUED THROUGH WWW INTERFACT WITHOUT AUTHENTICATION.
The '/HELP/' path link in the server URL for the WEB admin
interface will allow non-administrators to issu query commands.
Commands the require an ADSM administrative authority above
GENERAL will fail.
IX77714 TRYING TO RUN A SCRIPT THAT RUNS AN ADMIN SCHEDULE.
WORKED IN V2 DOES NOT WORK IN V3.
Cannot Schedule Device and Library related Administrative cmds.
IX77766 QUERY OPTION doesn't show AUDITSTORAGE option
NOAUDITSTORAGE OPTION DOES NOT APPEAR IN ADSM SERVER
QUERY OPTION OUTPUT
EVEN THOUGH PARM IS SPECIFIED IN DSMSERV.OPT
IX77783 ANR9999D PSPURROPT.C 1049) OPTICAL DISK NOT VALID FOR THIS PRODUCT
RECEIVED WHEN RUNNING LABEL LIBVOL FOR OPTICAL PLATTER
when ADSM labels an optical platter, it first tries to read
the existing label to ensure that it is not being overwritten.
If no existing label is found, the ANR9999 error message is
issued, which is extraneous since this condition would be
expected.
IX77865 RESTORED FILE ACCOUNT IS WRONG IN ACCOUNTLOG. RESTORED WITH NO
PROBLEM, BUT DISPLAYED "RESTORED FIL =ZERO".
accounting info not updated for restored files
IX78021 AFTER STARTING 'UPDATE DEVC' DURING 'QUERY CONTENT'
WORKING , SERVER HANGS.
IX78125 DSMFMT -G RESULTS IN OUT OF SPACE MESSAGE
The GB value was processed incorrectly.
IX78196 DB Dump was not dumping all pages
When running the dumpdb comand, one or more of the following
messages are issued:
ANR9999D dldump.c(2361): Logical page xxx corrupted -
data string packed structure invelid for record 0
IX78320 Unpredictable crash during Query Backup
unpredictable core dump occurs during query backup
IX78433 ANR9999D XIBF.C(1161):UNKNOWN RESULT CODE (23) FROM BFCREATE CAN BE A
RESULT OF V3 SERVER FILLING UP DISK STGPOOL DURING IMPORT
With a version 3 server when a disk storage pool becomes full
during an import and didn't get the chance to migrate the data
to tape, it will fail with ANR9999D XIBF.C(1161):UNKNOWN RESULT
CODE (23) FROM BFCREATE.
IX78702 QUERY CONTENT causes other commands to hang
After starting 'update devc' during 'query content'
working, server hangs, when 'query content' command take a
big time to work (large output). After system waits (hangs) the
message ANR0481W Session ??? for node ????? terminated -
client did not respond within ?? seconds.
After admin session with 'query content' command is terminated,
then sessions with 'update devc', 'q devc' commands unhangs
and worked properly.
IX78829 Memory leak when creating mutexes (AIX Only)
Every time a mutex is created in the server, an unspecified
amount of memory is leaked. Over time this can cause excessive
paging activity and/or server crash.
IX79016 ADSM SRV 3101, AIX 4.2.1, DRIVE-POLLING THREAD DON'T MARKS THE DRIVE
OFFLINE ADSM DB, ONLY IN DRIVE DESCRIPTOR.
The problem occurs when a drive in the 3949 library has an
error and ADSM begins to poll the drive. If the user marks the
drive offline via the UPDATE DRIVE command, then when the
polling thread finds out the drive is now accessible, the drive
is marked online. However, the drive should still be
marked offline according to earily commands issued.
IX79165 ANR9999D AFERASE.C(493):INVALID LOGSIZERATIO INF
Customer runs through RECLAMATION UTILITIES. Encountered
errors on DELETE RECLAIM and later on RECLAMATION or
EXPIRATION:
ANR9999D aferase.c(493): Invalid logSizeRatio INF (logSize=
0.1240,size=0,0,aggrSize=0.21045) for aggregate 0.21279102
IX79191 REMOVE=BULK WILL NOT RETURN WITH AN INVALID OPTION WHEN USED
WITH AN ACSLS LIBRARY.
CHECKIN LIBVOL ... REMOVE=BULK ... is not supported by ACSLS
libraries and should return an error if attempted.
IX79350 SCHEDULER ISN'T PROCESSING 2/29/2000 CORRECTLY.
Leap year not handled correctly for Y2K.
IX79366 WHILE ADSM IS COMING UP, TAPES IN AN ACSLS LIBRARY
SYSTEM WHICH ARE NOT FOUND WILL
BE CHECKED OUT RESETTING THE 'LOCK' BIT.
While ADSM is coming up, tapes in an ACSLS library system which
are not found will be checked out resetting the 'lock' bit.
By resetting the lock bit, we may be allowing the tape to be
picked up by another application using the ACSLS library.
IX79368 MAXSIZE ROUNDED FOR DISPLAY OF Q STGPOOL
IX79394 ADSM SERVER CHECKIN LIBVOLUME SEARCH=YES AND LABEL LIBVOLUME
SEARCH=YES CAUSE 3995 TO UNLOAD DRIVES FOR STATUS CHECKING
the IES command that is issued by Checkin and Label commands
with the search option causes any mounted volumes to be
ejected from the drives
IX79470 A WRITE PROTECTED TAPE IN AN ACSLS LIBRARY SYSTEM WILL BE
REMOUNTED REPEATEDLY FOR SCRATCH OPERATIONS.
A write protected tape in an ACSLS library system will be
remounted repeatedly for scratch operations.
Other tapes may be mounted durring this processing, as well,
including a usable scratch tape being selected occationally.
IX79566 Q ACTLOG WITH SEARCH OPTION DOESN'T DISPLAY ALL OCCURENCES
OF THE STRING EXPRESSION ON 3.1.1.3 SERVERS.
When doing a QUERY ACTLOG with SEARCH parameter, messages
originating from clients or other servers were not always
included.
IX79579 ANR8449E WHEN TRYING TO MOUNT A SCRATCH VIRTUAL VOLUME.
The name generation routine for scratch names was not
appropriately checking to see if a volume by that name already
existed.
IX79727 EXPORT DOES NOT WRITE THE DATASET NAME IN THE HDR1 FIELD IF THE VOLUME
HAS BEEN PREVIOUSLY USED BY ADSM
The problem arises on the MVS side when importing data that was
exported from a UNIX or NT. The error states that the data set
name was incorrect.
IX79815 AN ANR8311E I/O ERROR MESSAGE WITH RC OF 6 OR 28 IS ERRONEOUSLY
GIVEN WHEN THE VOLUME BECOMES FULL AND END OF TAPE IS REACHED
ADSM erroneously generates an:
ANR8311E AN I/O ERROR OCCURRED WHILE ACCESSING DRIVE
FOR WRITE OPERATION; ERRNO = 6 (or ERRNO=28)
ANR8341I - END OF VOLUME REACHED FOR VOLUME .
when using a library defined with LIBTYPE=EXTERNAL and the
volume becomes full (i.e. reaches the end of media/end-of-tape/
EOT). This message sequence is not indicative of a true error.
IX79974 IF A MOVE FROM DISK OPERATION IS CANCELED OR PREEMPTED,
ADSM COULD ABEND WITH A TMTXN008
An abend can at time occur during the movement of data
from a disk storage pool to another pool and a cancel
is issued or the operation is preempted.
This problem is more likely to happen if I/O errors are
experienced and the move operation is retrying the move.
IX80345 WHEN USING THE SQL SELECT STATEMENT WITH ORDER BY PARM AND THERE IS
MORE THAN ONE COLUMN DISPLAYING DECIMAL,INTERVAL OR DATETIME
SQL queries using the order by clause, with more than one
column with decimal, date/time or interval data can have
incorrect data displayed.
IX80431 WEB ADMIN INTERFACE DOES NOT DISPALY OBJECTS FIELD
INFORMATION IF MULTIPLE SET OS QUOTES ARE USED.
Strings that contain double quotes (") do not preserve the
double quotes when entered from the Administrative WEB
interface. An example is the objects/options fields in the
DEFINE/UPDATE schedule command.
IX80461 DRIVER FOR 7206-110 12 GIG TAPE DRIVE
Drive fails to configure using adsm driver but will configure
using the native AIX driver.
IX80531 ADSM DOESN'T RETURN AN ERROR WHEN THE MOVE MEDIA COMMAND
AND CHECKLABEL=NO OPTION ARE USED TOGETHER.
The users use an undocumented parameter CHECKL with the
MOVE MEDIA command. If CHECKLABEL, instead of CHECKL, is
used with the MOVE MEDIA command, ADSM reports the error.
IX80875 DOCUMENTATION UPDATE REQUEST TO INCLUDE -SERVERNAME OPTION IN LIST OF
IGNORED OPTIONS FOR DEFINE SCHEDULE COPMMAND
IX80940 ANR9999D PKSHMEM.C(310): INVALID ATTEMPT TO FREE MEMORY: CALLED FROM
10201E54 (CSQUERYEVENT).
Specifying "Query Event * type=admin nodes=" leads to attempts
to free memory which has not yet been obtained. The use of
type=admin and nodes= is not compatible.
IX81008 IF A TIVOLI SERVER GOES DOWN AND IS BROUGHT BACK UP ADSM NO LONGER CAN
COMMUNICATE WITH IT.
TIVOLI went down, and ADSM did not attempt to reconnect and
continue sending events to the TIVOLI Event Console.
IX81130 TCP/IP IS CLOSED WHEN ERROR NUMBER 72 IS RECEIVED FROM TCP/IP
If a session request is aborted in a very small window and ECONNABORTED
is returned by AIX, the server will stop listening for TCP/IP sessions.
IX77690 THE MESSAGE "ANRNNNNW UNABLE TO CLEAR THE LOG BELOW XX% OF THE TRIGGER
VALUE. THE RECOVERY LOG IS NOW YY% FULL" SHOULD DISPLAY
The server does not issue a message when running in roll-forward mode
and a database backup does not clear the recovery log below the percentage
specified by the database backup trigger.
IX79262 HIGH CPU UTILIZATION DURING SCHEDULE MANAGER INITIALIZATION.
When the ADSM server is starting, the schedule manager may take
a long time to initialize if there is a large number of
schedled events defined (i.e. lots of clients associated with
one or more schedules). During schedule manager initialization,
you may see one or more of these symptoms:
- High CPU utilization
- Clients will not be able to connect
- No response to administrative commands
Once the schedule manager starts (message "ANR2560I Schedule
manager started.") ADSM will operate normally.
IX76101 ADSM ADMIN GUI ERROR MESSAGE ANR2606E INVALID START DATE WHEN
CODING 29/02/2000 IN THE START TIME BOX FOR SCHEDULED BACKUP
Customer was doing year2000 testing and discovered that coding
29/02/2000 in the admin GUI schedule start time box caused
ANR2606E invalid start date but 29/02 IS a valid date for
year 2000.
IX81433 VOLUME LOCATION FIELD ERASE BY SERVER LEVEL 3 .
QUERY VOLUME F=D for cartridges reveal that the field LOCATION
DIAPPEAR , after the cartridge has been used by server level 3.
The volume was defined at server level 2 , and when its been use
by server level 3 , the LOCATION field of the volume LOST.
IX79264 DELETE MULTIPLE FILESPACES ANR0104E ARCHIVE.DESCRIPTIONS
If the user deletes multiple filespace for a node at the same
time, that is the deletes are running concurrently on the
server, one of more of the delete filespace background threads
may terminate with the following messages:
.
ANR0104E IMARINS(1301): Error .... deleting row from table
"Archive.Descriptions".
ANR0987I Process ... for DELETE FILESPACE running in the
BACKGROUND processed .... items with a completion
state of FAILURE at ....
------
IX76241 WAIT HANG SESSION VERSION 3
A client session on a ADSM V3 server may hang doing a long
split on a database page during backup processing. Externally,
there are no unique symptoms to this problem other than
eventually all client sessions most processes will hang.
IX79265 ABEND0C4 IN ADSM PROC TMABORT+'8E' RUNNING ADSM V3 SERVER.
The adsm MVS V3 server gets an abend0c4 in TMPROC+'8E'.
The is processing a transaction abort from a client but
there was no session started causing this abend.
IX79294 ANR9999D ADMNODE(6648): INVALID NODE TYPE 0 FOR NODE ...
This APAR is to document this message and let customers know
that this message may be ignored. This message is issued as a
result of code added in level 3.1.0.2 and 3.1.1.1 to correct a
problem where server nodes were counted against the number of
clients licensed.
ANR9999D is a diagnostic message which should only be issued
when there is a problem which requires further diagnosis or
corrective action by ADSM Service. In this case, it is an
inappropriate use of the message because the server is
actually correcting an existing problem and no further action
or diagnosis is required.
IX79295 ABEND0C4 ORMADM.C+42CE ENDMOVEDRMEDIATHREAD()+48E REG07
MOVe DRMedia background thread terminates with ABEND0C4 in
load module DSMSERV (ANRSERV) source module ORMADM.C at offset
+42CE, stmt 2926, in function EndMoveDrmediaThread() at offset
+48E.
EndMoveDrmediaThread() calls FreeStorage() to free the storage
used by the move drmedia thread. The last thing that
FreeStorage() frees is the ormDesc structure. Upon return from
FreeStorage(), EndMoveDrmediaThread() attempts to call
pkExitThread() using a pointer in the freed ormDesc structure
as an argument.
IX78196 DUMPDB INCORRECTLY REPORTING ANR9999D DLDUMP(2361)
After upgrading from V2 to V3, customer is finds that DUMPDP
is incorrectly reporitng ANR9999D DLDUMP(2361): logical page
corruption
---
BACKUP DB does not report and errors and show tblscn report
no errors.
IX79381 UNABLE TO CONNECT MORE THAN 200 CLIENT SESSIONS FOR BACKUP. HARD
CODED LIMIT IN TCPCOMM.C FOR HPNS_MAX_SESSIONS
IX79387 SQL ERROR IN THE WEB SHELL ADSM ADMINISTARTION DURING REQUESTING
THE POOL VOLUMES INFO IF POOL NAME LONGER THAN 18 CHARACTERS.
Error using the Web Admin displaying an object with a
long name, when a dependent object is selected for display.
An example: When displaying a storage pool with a long name
select the volumes icon to display the volumes in that
storage pool.
IX79388 PARSING ERROR FROM TIVOLI WHEN IBMADSM_SERVER_EVENT CONTAINS DOUBLE
QUOTATION MARKS
When reporting ADSM SERVER events to Tivoli, a parsing error
occurs if the message to log contains double quotation
marks.
IX79389 HANG OR WAIT OF ADSM SERVER WHEN USING WEBADMIN CLIENT
The ADSM server can hang when using the WEBADMIN client if
there are TCP/IP problems causing the send of data to hang in
TCP/IP. The problem is in the HTTP communications path that
the SMVARS mutex is being held while sending data. A SHOW
THREADS will show most threads waiting on the same MUTEX. A
Q SESSION will show an HTTP session in a SENDW state for a long
time.
IX80115 Q AUDITOCCUPANCY FROM MVS ADSM 3.1.1.3 DISPLAYS INCORRECT DATA.
Query Auditoccupancy shows storage values for nodes which have
no filespaces.
IX79919 NETWARE & WIN32 3.1.0.3 CLIENTS RESTORE FILES WHEN -DIRSONLY
OPTION IS SPECIFIED IF THE DATA IS STORED ON SEQUENTIAL MEDIA.
When the DIRSONLY option is used with a restore from a
client, files are sometimes sent from the server to
the client. The will happen if:
- The No-Query Restore protocol is used
- Directories to be restore have extended atributes that
reside on sequential media in ADSM.
IX80959 WEB ADMIN CLIENT RECONNECTS TO SERVER WITHOUT AUTHENTICATION
When an administrator sign-on times out, the user can gain
access to the server by pressing the cancel button on the
authentication pop-up screen.
IX79282 AUDIT LIBRARY aborts the server
If the SCSI driver is not started on the NT server and I run
an AUDIT LIBRARY, the server will take a dump
IX79537 Incorrect text response SD-3CC and FORMAT=DRIVE fix for ECART
IX79626 WHEN ARCHIVE OBJECTS ARE BEING EXPIRED IF CORRESPONDING DESCRIPTION
ENTRY IS MISSING, EXPIRATION FAILS FOR THAT OBJECT.
The archive descriptions tables were created to enhance
performance for the V3 GUI, archive/retrieve functions.
"Conversion" to the tables occurs on a per node basis:
- when a node attempts to archive a file using the V3 GUI
interface, the node is prompted if it will wait for the
conversion. If OK, entries are created in the archive
description tables.
Errors have been reported when subsequent insertions, updates,
or deletions are made in these tables. Insertion errors are
reported by customers that use tools (e.g. shell scripts) to
generate multiple, concurrent archive sessions for the same
node name. Deletion errors also occur for nodes with large
numbers of archived data.
The errors were due to a serialization problem with the archive
description tables. The locking scheme was changed to fix.
IX77733 WEB ADMIN LOOKS FOR SCHEDULE TO UPDATE ONLY BY NAME IGNORING DOMAIN
The UPDATE SCHEDULE form for updating client schedules through
the WEB interface dose NOT always reference the selected
schedule if schdules having the same schedule name exist in
multiple policy domains.
IX78290 ANR0729E SYNTAX ERROR WHEN IMPORTING A NODE ASSOCIATED TO CLIENT
OPTION SET
During IMPORT of client optionsets, client option value needs
to be surrounded by quotes in order to keep the INCLEXCL option
value as one long string.
IX79415 SELECT ALL* FROM STGPOOLS COMES BACK W/EST_CAPACITY_MB: 0.0
WHEN A STORAGE POOL IS LARGER THEN A TERABYTE.
EST_CAPACITY_MB does not handle terabytes in
"select ... from stgpools"
IX79925 QUERY CONTENT FAILS AGAINST OPTICAL VOLUMES WHICH HAVE AN UNDERSCORE
IN THEIR NAME
The LABEL LIBVOLUME command now allows optical volumes to
contain underscores. The QUERY CONTENT command attempt to
resolve the optical volume the underscore in its name and
did not allow underscores. The QUERY CONTENT failed.
IX80363 ANS1314E (RC14) WHEN DOING PARTIAL OBJECT RETRIEVE WITH OFFSET > 0
AND LENGTH = 0 (STG=TAPE)
When applications retrieving through the ADSM api
perform a partial object retreive with only the
offset (length=0) the retrieve failed. This was
due to an invalid calculation in the retrieval
code.
IX80786 TBUNDO096 ASSERT FAILURE RESTORE.OBJECTS TABLE
If a Restartable Restore session is cancelled early on, it
is possible to receive an assert failure during transaction
processing:
ANR9999D TBUNDO(207): Error 2 on delete from table
Restore.Objects for undo.
IX80900 ADSM RELCAMATION PERFORMANCE RUNS SLOW ON V3 SERVER,
ESPECIALLY WHEN SLOWER DEVICES ARE USED
When ADSM server reconstructs an aggregate with empty
space, it currently requires a position to the beginning
of the frame before retrieving each file. With large
buffers and small files this severly effects performance
as we have to rewind the tape for each retrieval.
IX81040 AIX ADSM 3.1.1.3 "CHECKI LIBV LIB_NAME STAT=SCR CHECKL=NO
VOLR= XXXX,XXXX SEARCH=Y DEVT=XXXX"DOESN'T CHECKIN ALL QUALIFIED VOLS
a linked-list traversal was accessing the wrong list
element (volume) at the time of checkin. This also can
cause volume not in the range to be checked in, as well as
omit volumes that are in the range.
IX81426 ADSM SERVER V3.PTF3 ON NT, LIBRARY ADIC SCALAR 458.
MOVE MEDIA WITH REM=BULK: DOOR IS LOCKED WHEN THE PROCESS HAS COMPLETED.
When checking out a tape in this library using the remove=bulk
option, the library door is quickly unlocked and locked. The
problem is that the door is never unlocked, so the customer
is unable to remove a tape(s) from the entry/exit slot. Effects
HP, SUN, AIX and NT platforms
IX81655 FILES DOES NOT REBIND WHEN MANAGEMENT CLASSES CHANGE DURING BACKUP.
If a client file is assigned to a new management on the client,
this causes the server to perform a re-bind operation. This
re-bind operation assigns the existing files this client
backed-up to a new management class.
However, the re-binding algorithm was not re-binding all
possible files in the case where the new management class
had a retversions of NO_LIMIT.
IX81674 WHEN DOING A CLASSIC RESTORE OF A LARGE FILE SYSTEM,
THE SERVER RUNS OUT OF MEMORY OBTAINING LOCKS.
During a large restoration, the following error(s) are seen:
ANR9999D Memory allocation error.
Warning: insufficient memory to buffer output data; data discard
ANR9999D pkthread.c(528): Insufficient memory available to alloc
"tmLockHolder" object of (40) bytes, Thread 44, File tmlock.c, L
If you are doing a classic restore of a very large filespace,
the server can exhaust its memory during the "query" phase
because locks aren't being released until the entire query
phase is done.
This problem is not witnessed with a NoQueryRestore.
IX81952 RESTORE OR RETRIEVE PROCESSING DEGRADED WHEN DISK STORAGE
POOL UNAVAILABLE, RESTORE ORDER LIST NOT OPTIMAL
During restore or retrieve processing from a client, the server
does not optimize the retrieve order for the files if the
files:
1) Reside in a disk storage pool
2) And one or more of the following conditions exists
for the disk storage pool where the data resides:
- the disk storage pool is set to ACCESS=UNAVAILABLE
- a needed disk volume is not varied on-line
- a given file is marked as damagedin the disk storage pool
IX81990 FILES NOT EXPIRING DURING EXPIRATION
Inactive files are not expiraing according to the copy group
definition for retain extra versions. This may cause excessive
tape usage and the db to grow.
IX82029 EXPORT THREAD HANGS.
The server can deadlock if file data for a particular node is
exported at the same time as a backup, archive, or space-
management session is storing files for the same node. This
problem is caused by contention for the same database lock by
the export and storage operations.
IX82032 ADSM SERVER HANG ON NO QUERY RESTORE
The ADSM V3 server may hang while doing a no query restore
(NQR). A query session shows the hung session is in the run
state.
IX82190 RECLAMATION VOLUME SELECTION UNPREDICATBLE.
The current reclamation volume selection algorithm is not
ordered in a predictable manner. Based on many customer
requests, the algorithm will now first choose the eligible
volume which has the largest percentage of reclaimable
space.
IX82308 ADSM MESSAGES MANUAL AND HELP OUTPUT INDICATES THAT THE NODENAME
AND NOT THE IP ADDRESS SHOULD BE DISPLAYED IN ANR8214W MESSAGE
There is a documentation error in the on-line help and the
messages manual for message ANR8214. This message should refer
to "IP Host Address" instead of "node name".
IX82320 SELECT COMMAND DISPLAYING THE PENDING_DATE MAY REPORT INCORRECT DATA.
IX82401 STORAGE VALIDATION AREA OVERWIRTTEN WITH USER DATA CAUSING
(server) TO LOOP
In certain rare circumstances during a restartable restore
(No-Query Restore) a memory overlay condition could take
place causing a loop or abend. The circumstance
identified is when a file is backed up with a given
management class name. Since the time of backup the
file is re-bound to a new management class name which
is shorter in the number of characters. The failure
can happen during a restartable restore involving the
file.
IX82436 WHEN UPDATING A MGMTCLASS NOT LISTED ON TOP OF THE LIST, THE WEB
ADMIN WILL DISPLAY THE INCORRECT MGMTCLASS DESCRIPTION.
When updating a mgmtclass not listed on top of the list, the web
admin will display the incorrect mgmtclass description. When a
domain have several management classes and when an update is
performed on a management class that is not on top of the list,
the web admin will display the management class description that
belongs to the management class on top of the list.
IX82528 SQL ERROR AND SERVER HALT WHEN ADSM WEB ADMIN CLIENT QUERY FILESPACE
WITH 'DEL' (0X7F) CHARACTER IN FILESPACE NAME
IX82562 ADSM SERVER CORE DUMPS ON WEBADMIN URL PROCESSING (ANR7837S MEM0 001)
The server abends when parsing a url that has been truncated
from the web browser.
IX82629 9740 max drive should be 10
IX82739 ADSM V3 SERVER DOES NOT DISPLAY HELP FOR CLIENT ADMIN MESSAGES.
DOC NEEDS CLARIFICATION ON WHAT ADMIN COMMANDS WILL HAVE HELP.
The server on-line help did not include the information
necessary for providing help for ANS messages to the
ADSM Command Line Administrative Client.
IX83014 ANR0422W ERROR. NODE NAME IS CHANGING ON IT'S OWN UNDER CERTAIN
CIRCUMSTANCES.
The ADSM server may corrupt string values it is processing.
An example is a node name appears incorrect.
IX80101 SELECT * FROM CONTENTS OUTPUT MAY HAVE GARBAGE FILESPACE_NAME FIELD
When "select * from contents" is issued, garbage is
sometimes displayed for the filespace name.
IX81330 CANNOT DEFINE CLIENTACTION WHEN THE OBJECTS FIELD CONTAINS A DIRECTORY
WHICH HAS A SPACE IN THE DIRECTORY NAME.
CANNOT DEFINE CLIENTACTION WHEN THE OBJECTS FIELD CONTAINS A
DIRECTORY WHICH HAS A SPACE IN THE DIRECTORY NAME.
For example:
Able to define a schedule with the following syntax and the
schedule runs successfully:
DEF SCH DOMAIN_NAME SCHED_NAME ACTION=ARCHIVE
OBJECTS='"f: my documents *'"
But cannot apply the same syntax for the objects field when
defining clientaction:
DEF CLIENTA NODENAME DO=DOMAIN_NAME ACTION=ARCHIVE
OBJECTS='"f: my douments *"'
This will error with ANR202E DEFINE SCHEDULE:
Invalid parameter - F: MY.
Tried objects="f: my documents *". The server accepted the
command but the schedule fails. Tried combinations of syntaxes
but all failed.
IX83680 ANR8300E DURING A LABEL LIBVOL OPERATION USING THE
SEARCH=BULK PARAMETER((OP=00006C04, CC=320, KEY=FF, ASC=FF, ASCQ=FF).
IX77909 ANE14--- MESSAGES ARE DISPLAYED ON SERVER INSTEAD OF ANE4---X
Events such as ANE4007W are displayed as ANE14007. Because of
this, these events cannot be forwarded to an external event
handler.
IX83398 DSMSERV CAN COREDUMP WITH IMIXN008 DURRING SERVER TO SERVER
COMMUNICATIONS.
Code was added at the 3.1.2.0 level of ADSM which allowed
multiple volume names to be picked within the same second.
Since the volumenames used in Server to Server communications
contain the time to the second, this would allow multiple
volumes of the same name. When this condition is discovered,
the transaction ends up being aborted twice, creating the
TMTXN008 condition.
IX83777 PROBLEM W/ EXTERNAL LIBRARY MANAGER WHEN ISS
Back to the table of contents
---------------------------------------------
$$ APARS fixed by this service level - part 1
---------------------------------------------
IC20502 ERROR WHEN USING THE V3 ADSM SOLARIS 2.5.1 CLIENT WITH THE SOLARIS
V3 SERVER, SHARED MEMORY COMMMETHOD, AND LARGECOMMBUFF
The problem is that when using the SharedMemory protocol and the
options with the Sun server and client, Sun's default shared mem
is not large enough.
The shared memory max size can be increased by placing the following
in the /etc/system file:
set shmsys:shminfo_shmmax=8388608
<@>
IC22123 CLOSING COMMAND LINE WINDOW WITHOUT QUITTING ADMIN CLIENT SESSION
WILL RESULT IN GARBAGE IN ACTIVITY LOG
Network connections with admin clients were not closed
when the clients were terminated, thus resulting in garbage
being read from communications buffers.
If you start an Admin Client session with a V3 Server running on
HP-UX, garbage will be displayed in the activity log if you
close the terminal window without first quitting your session
with the Server. This problem is only seen with V3 Servers
running on HP-UX, regardless of the platform the Admin Client
session is generated from.
<@>
IC22247 ON OS/2 VERSION 2 SERVER USING 3449 LIBRARY SLOTS 3 AND 4 ARE BOTH
MAPPED TO ELEMENT 4 IN THE LIBRARY.
On an OS/2 server with a 3449 8mm library slots 3 and 4 are both
mapped to element 4 in the library. Show slots has the following
output - note that slots 3 and 4 are missing:
Slot 2, status Full, element number 3, barcode not present, bar
Slot 5, status Full, element number 5, barcode not present, bar
The "Return All Library Inventory" of the lbtest utility shows:
INVENTORY ERROR: 4 is duplicated element address
<@>
IC22324 ADSM NETWARE311 CLIENT 3105 GETS ANS1809E, GETS: ANS1809E, ANS18
AND NT FLUSH ERROR 17 WITH IPX COMMMETHOD BACKUPS. TLI LIBRARY.
IPXSPX commethod errors with netware adsm v3ptf5 clients.
The problem is with Netware tli library functions with
buffer flush.
<@>
IC22462 ADSM SERVER SENDS INVALID PARAMETER TO TIVOLI TEC EVENT RECEIVER
WHEN COMMS METHOD IS NAMEDPIPES.
The Tivoli Event Receiver was unable to parse the value for the
comm_method field of the event, because it contained an embedded
blank and was not enclosed in single quotes.
<@>
IC22494 LABEL LIBVOL DOES NOT WORK WITH AIT AND 8900 DRIVES.
The problem is that the LABEL LIBVOL command attempts to
label tapes in the older 8200 format, which is not
compatible with 8900 and AIT drives.
<@>
IC22675 BACKUP/ARCHIVE CLIENTS CANNOT DELETE THEIR OWN FILESPACE
Backup Archive clients cannot delete their own filespaces
even though they have been given authority to delete their
backed up or archived data. The deletion appears to complete
correctly but the filespace is NOT deleted. On the server
message ANR0984I Process for FILESPACE DELETION is started gets
issued and ANR0987I indicates that the process has completed
with a state of SUCCESS. However, the client can still see the
filespace in a list of those to be deleted.
<@>
IC22721 TZ89 DRIVES CAN NOT LABEL COMPAC IV CARTRIDGES WHEN HARDWARE COTZ89
DRIVES CAN NOT LABEL COMPAC IV CARTRIDGES WHEN HARDWARE COMPRESSION IS ENABLED
When the TZ89 is set to compressed-data mode, it cannot write a
COMPACT-IV type of tape in the lowest DLT format. ADSM by
default initially writes all labels in this format, and does not
distinguish the media type
<@>
IC22852 ANR8300E RECIEVED DURING LABEL LIBVOL SEARCH=BULK ALTHOUGH THE OPERATION
WAS SUCCESSFUL.
The ANR8300 message containing "CC=320" is falsely issued
when running the CHECKIN LIBVOL ... SEARCH=BULK command.
This apar does not address any other CC= values or the
CC=320 unless SEARCH=BULK is specified in the command.
<@>
IC22970 ADSM SERVER 3.1.2.1 DOESN'T REMOVE LAST DB BACKUP VOLUME FROM VOLHISTORY
BY 'DEL VOLHIST TOD=TODAY TOT=NOW TYPE=ALL' COMMAND.
Need to prevent users from accidentally deleting last
data base Backup series.
<@>
IX78238 ANR9999D PVRSERV.C(833): SERVWRITE: ERROR WRITING SERVER VOLUME X.
RC=30 WHEN COMMTIMEOUT VALUE < TIME REQUIRED TO MOUNT TAPE.
The ADSM source server which writes to the virtual volume may
encounter errors writing to the volume in a situation where
the target server is in a media wait condition. Specifically,
because the target server is in a media wait, the source server
may cancel the outbound virtual volume session because the
communications timeout value on the source server is exceeded.
<@>
IX79728 ANR9999D: IMUTIL.C (2555) LOCK ACQUISITION SLOCK FAILED FOR INVENTORY
NODE XXX,RECEIVED DURING EXPORT SERVER
During a long running export command on the server,
the export can fail with the message:
ANR9999D imutil.c(2555) Lock acquisition SLOCK failed
for inventory node X.
Because of the lock acquisition failure, the export
will terminate.
<@>
IX79929 WRONG WORM SCRATCH VOLUME HANDLING MAY CAUSE INFINITE LOOP
After a full WORM optical volume becomes empty, it
should not be allowed to return to scratch.
<@>
IX80749 THE "WAIT=YES" OPTION DOESN'T WORK FOR THE "MOVE DATA" COMMANDS FOR
OFFSITE/COPY STORAGE POOLS. AIX 4.2 ADSM SRV 3.1.PTF 3.
The server processing for volumes that are OFFSITE for the
MOVE DATA command with the WAIT=YES parameter specified does
not work. Specifically, the MOVE DATA processing runs in the
BACKGROUND on the server instead of running in the FOREGROUND.
<@>
IX81490 DURING A "RESTORE DB" PROCESS, IT WAS FOUND THAT THE DEVCONFIG
FILE CONTAINED "ACSDRVID=" FOR A NON-STK LIBRARY. RESTORE FAILS.
Within the ADSM server device configuration file, there may be
an extraneous keyword (ACSDRVID=) on DEFINE DRIVE commands for
non-ACSLS drives. Use of a device configuration file containing
DEFINE DRIVE commands with this extraneous keyword will cause a
database restore to fail.
<@>
IX82231 WEB ADMIN COMMANDS MAY ERROR WITH ANR2000E-UNKOWN COMMAND AND
ANR2020E-INVALID PARAMETERS WHEN RUNNING ON AIX 4.3.0.X.
The server encounters errors parsing commands. An example of
this is the that the Web Admin commands may error with
ANR2000E UNKNOWN COMMAND
ANR2020E INVALID PARAMETER
The commands displayed have randomly have invalid characters
in them that do not match what was originally reported to the
server.
<@>
IX82403 AIX ADSM V3PTF5 SERVER: THE ERROR DURING EXPIRE INVENTORY: ANR9999D
AFTXN.C(747):FILE COUNT WENT NEGATIVE,ANR1181E,ANR2183W
During expiration processing, migration, reclamation, delete
filespace, or other processing that may delete files from
sequential media; the error:
ANR9999D aftxn.c(747): File count went negative for pool
X, Ck1=N, Ck2=Y.
may be encountered. This will cause the transaction in use
by the server function to abort and fail.
<@>
IX82929 ADSM SQL V3PTF5 SRV."SELECT" DOESN'T WORK WITH 3 AND MORE TABLES
ANS8001I RETURN CODE 4. ANR9999D SQLQUERY.C(1004).
"Internal SQL table declaration conflict" received.
<@>
IX83029 INCORRECT MESSAGE WHEN ADSM UNABLE TO INITIALIZE SCSI LIBRARY
The problem is that defining a drive to an ADSM library
failed, in this case with the message "ANR8366 Invalid
attribute for ELEMENT parameter". The error was not due
to the ELEMENT at all, but to the fact that the library
was offline and unable to validate the element value.
<@>
IX83978 DELETE VOLUME RETURNS VOLUMES TO THE SCRATCH POOL WHICH WERE NOT
SET "SCRTCH VOLUME? YES"
Delete volume and restore volume commands return a volume to
scratch even if it was not introduced to the storage pool
through a scratch mount request.
<@>
IX84094 UNABLE TO QUERY SCHEDULED EVENTS. WILL RESULT IN ANR2635E.
Qeuery Event and Query Actlog not allowing for the
begindate\time and enddate\time to be equal as required by
the N/T administrator GUI client.
<@>
IX84124 DLT TAPES USING THE STK-OMI DEVICE DRIVERS ON ENHANCED ADSM DO
NOT CORRECTLY TRANSLATE TO THE V3 DLT DEVICE CLASS.
The Enhanced ADSM product used 256K blocksizes and device
type of STK for their DLT support. In ADSM, DLT support was
originally done with 32K blocksizes. The volume attributes
for the volumes that were written with devtype STK indicate
that these volumes were written with 32k. This is because
the Enh. ADSM product was out of sync with ADSM in terms of
how DLT attributes were stored, and this was missed during
migration testing.
The same case does NOT apply to 4490/9490 drives that were
also written with devtype=STK.
<@>
IX84141 MEMORY ALLOCATION FAILURE WITH LARGE BUFPOOLSIZE (ANR0132E)
On AIX only, if you have a very large server using a lot of
memory, you could end up using all 750MB allocated to the
server. As a result, you will receive memoy allocation failures
and the server may crash.
<@>
IX84177 UNEXPECTED RESULT CODE (17) FROM BFAUDITBITFILE ENTERED IN ACTLOG
FOLLOWED BY INTERNAL SERVER ERROR DETECTED
NEED TO HANDLE LACK OF MOUNT POINTS FOR AUDIT VOLUME WITH
CORRECT MESSAGE INSTEAD OF ANR9999D.
<@>
IX84456 AVAILABLE MOUNT POINT NOT GRANTED WHEN USING MORE THAN ONE DEVICE
CLASS WITHIN A LIBRARY
The problem is that mountlimit setting for one devclass
takes other devclasses that use the same library into account
when counting how many mountpoints the one devclass can have.
For instance, in devclass whose library has five drives but
whose mountlimit is "1", if another devclass also uses that
library, its acquired mounts will cause the first cause the
first devclass to think it has already acquired the one
mount that it is allowed.
<@>
IX84485 ADSM V3 SERVER BACKUP STGPOOL IS RUN SPECIFYING WAIT=YES AND MAX
PROCESSES IS GREATER THAN 1 ONLY 1 BACKUP PROCESSES RUNS
The ADSM server BACKUP STGPOOL command is not working
correctly when MAXPR > 1 is specified with the WAIT=YES
option. Specifically, multiple server processes are not
being used for the backup.
<@>
IX84602 ANR8827ENO ENTRY EXIT PORT FOUND MESSAGE ON LIBRARY WHEN VOLUME
HOME SLOT FOUND EMPTY
When checking volumes out of an ADSM supported library
using the REMOVE=BULK option, if the move from the slot to
the EE station fails for ANY reason, the move is re-attempted
to each of the EE slots. If the move never succeeds, the
message "ANR8827E No Entry/Exit port is available..." is
issued, even though one or more can be empty and available.
One reason the move can fail is that the source slot is
empty (ie. the volume was physically removed without checking
it out of the library).
<@>
IX84637 ANR8778W SCRATCH VOLUME CHANGED TO PRIVATE STATUS TO PREVENT RE-ACCESS
CAN LOOP, FILLING UP THE DB AND CRASHING THE SERVER.
This error is an infinite loop of reporting
ANR8778 SCRATCH VOLUME CHANGED TO PRIVATE STATUS TO PREV...
It occurs when attempting to mount a scratch tape in a few
isolated cases. These are mainly when there are also
reported I/O Errors on the library.
<@>
IX84715 THE ADSM VERSION 3 SERVER IS NOT PROPERLY HANDLING DATA DISPLAYED
IN HEXIDECIMAL FORMAT.
When logging events from one server to another, there is an
error in the output processing algorithms that causes data
that is supposed to be displayed as a Hexidecimal value to
be displayed as a numeric value.
<@>
IX84765 IF A VOLUME CONTAINS FILES WHICH COULD NOT BE RECLAIMED, ADSM SERVER
3.1.2.0 WILL DELETE THE VOLUME FROM THE STORAGEPOOL.
If a volume contains files which could not be reclaimed, ADSM
Server 3.1.2.0 will delete the volume from the storagepool.
Messages from the actlog:
ANR1175W Volume xxxx contains files which could not be reclaimed
ANR1410W Access mode for volume xxxx now set to "unavailable".
ANR1041I Space reclamation ended for volume xxxx.
ANR1341I Scratch volume xxxx has been deleted from storage pool.
<@>
IX84769 CONTACT MAX LENGTH IN SQL OUTPUT IS 128: CAN HOLD AND DISPLAYS 255
CHAR. IN Q NODE F=D.
SQL select does not display a long "contact" for a node
<@>
IX84965 IF THE CENTRAL SCHEDULE (CS) TRIES TO START A SESSION BEFORE THE MAIN
SCHEDULE THREAD FINISHES INITIALIZING ON 3466, RC=22 OCCURS
Wehn the ADSM server is initalizing, there is a window during
which the sessions can be established to the server before the
central scheduling component is initialized. If a client
attempts to start a scheduled session during this window, the
server will display a Mutex Acquisition failure with return
code 22. The server will then crash.
<@>
IX85064 MESSAGES ANR2280I AND ANR2281I ISSUED TWICE UPON DATABASE BACKUP
ANR2280I and ANR2281I issued twice to the console and activity
log on a data base backup.
<@>
IX85125 ADSM V3 SERVER UPDATE DRIVE COMMAND HANGS, CAUSING OTHER SESSIONS AND
PROCESSES TO HANG, THEN POSSIBLY THE WHOLE SERVER
Deadlock can occur when the UPDATE DRIVE command is used and
at least two other processes try to acquire a mountpoint.
<@>
IX85134 AIX SERVER 3.1.2.0 DOES NOT READ SPECTROLOGIC 10000 BARCODE LABELS
barcode was not enabled for Spectralogic library.
<@>
IX85182 SOME ADSM FUNCTION CALLS RETURN AN INVALID ERRNO OR NO ERRNO AT ALL.
If an error is encountered writing to a disk volume the errno
is not reported by ADSM, making diagnostics more difficult.
<@>
IX85278 DISK ACCESS PROBLEMS CAN CAUSE AN EXCESSIVE NUMBER OF ANR9999D
DSRTRV.C MESSAGES IN THE ACTIVITY LOG.
If an error occurs while reading logical blocks from a disk
storage pool, an error message is issued for each block that
could not be read. This can result in a large number of
entries in the activity log.
<@>
IX85298 INVENTORY EXPIRATION DOES NOT EXPIRE AS EXPECTED FROM THE VEREXISTS
PARAMETER IN THE COPYGROUP
The version control for backup objects is not properly
maintaining the versions exists attribute for the copygroup
managing a given file. The error is that the versioning
algorithm is not marking files to be eligible for expiration
when the count of the number of versions for a given file
exceeds the versions exists value. Consequently, more files
are being kept in the server and the files are not being
expired when they should.
Please note that the error is that the server is NOT expiring
data when it should actually be expiring it.
<@>
IX85410 THE SELECT STATEMENT DOES NOT GIVE PREDICTABLE OUTPUT.
The customer issued both a "query occupancy" and a "select
from occupancy". The entry:
Node Name Type Filespace Storage Number of Physical .
Name Pool Name Files Space .
Occupied .
(MB) .
----------- ---- ---------- ---------- --------- --------- --
JEFF.CIT.C- Arch (archive) ARC.DL3 564 2,060.78
appears in the query output, but is missing in the sql output.
<@>
IX85412 DURING A DB RESTORE, A ANR8302E MESSAGE CAN BE DISPLAYED AFTER A
ANR1365I VOLUME CLOSED (END REACHED).
When a volume is closed for the listed devices, a tape
motion of spacing backward and then forward one record is
performed. This is to force the device to mark EOD on the
last record written. Some ADSM operations do not leave the
tape in a state that can perform this operation, such as
RESTORE DB where it is positioned after a tape mark. This
means the RSR/FSR motion fails and is reported, but the
failure is superfluous to the tape processing involved.
This fix also corrects a sometimes seen problem where the
following message is also written to the actlog. This is also
a false message that does not impact the overall process:
ANR8300E I/O error on library xxxxx (OP=00006C03, CC=314, KEY=05
ASC=3B, ASCQ=0E,
SENSE=70.00.05.00.00.00.00.0A.00.00.00.00.3B.0E.00.00.00.00.00.0
00.00.00.00.00.00.00.00.,
Description=The source slot or drive was empty in an
attempt to move a volume). Refer to Appendix B in the 'Messages
recommended action.
<@>
IX85431 ADSM HAS A SEGMENTATION FAULT FOLLOWING ANR8311E ... FOR OFFL
OPERATION, ERRNO=78.
A null referenced pointer is responsible for the abend. It
is referenced immed. after "ANR8797 Drive ... is inaccessible"
is issued.
<@>
IX85513 QUERY DRMMEDIA COMMAND PROCESSING DOES STOP WHEN A VOLUME_UNAVAI
LABLE RETURNS FROM AN EXTERNAL LIBRARY MANAGER
The original logic of QUERY DRMEDIA is same as other ADSM
QUERYs that quit the process (displaying) as long as an
processing error is encountered. The reason is that the
error message issued to the console will mess up the format
of the query output.
In the situation descripted in this APAR, it is reasonable
that ADSM should display other volumes that do not encounter
any error.
<@>
IX85583 ANR8302E I/O ERROR ON DRIVE OP=READ, CC=404, KEY=03, ASC=30, ASCQ=01
WHEN CHECKING IN AN UNLABELED TAPE ON AN ACSLS LIBRARY
I/O error with CC=404, KEY=03, ASC=30, ASCQ=01 when checkin unlabeled tape
into an ACSLS library
<@>
IX85726 ADSM 3.1.2.1 WEB ADMIN DOESN'T ALLOW TO THE ADMINISTRATOR WICH HAS
ONLY POLICY PRIVILEGE CHANGE HIS PASSWORD.
Administrator with out system authority cannot update their
password via the ADSM web administrator interface using the
tree path objects->administrators->{admin name}.
<@>
IX85734 EXPORT NODE FAILS WITH ANR9999D XIBF.C(1408): INVALID HEADER SIZE
FOR OBJECT FOLLOWED BY ANR0569I, ANR0794E
During the export processing of file data, the following
message is received:
ANR9999D xibf.c(1408): Invalid header size for object.
After this message is received the export processing is
terminated with an error.
<@>
IX85810 ADSM VOLUME SHOWS "IN USE" WITH NO PROCESS RUNNING AND NO CLIENT
SESSION ACTIVE.
This problem can cause an infinite loop to occur during
migration of data from a sequential-access storage pool
with an ADSM 3.1.2 server. Under a unique set of
conditions, an error can occur that causes the migration
process to terminate, but leaves the migration thread
unable to reach the low migration threshold. For example,
this could occur if (1) an error prevents a volume from
being migrated, (2) there are no more volumes to migrate, and
(3) the low migration threshold is very low. With this
combination of conditions, migration keeps looping as it
tries to reach the low threshold, but is never able to do
so.
.
This problem results in two adverse effects. First one or
more volumes may be left "in use" even though there are
no sessions or processes using those volumes; the volumes
cannot be used by other server operations. A
second effect is that the server generates a new transaction
during each pass of the loop and does not release the
storage used by that transaction; this results in a serious
memory leak.
<@>
IX85858 ANR8828E SLOT 64 OF LIBR XXXX IS INACCESSIBLE AFTER
MIGRATING TO V3 SERVER
After migrating from V2 to V3 server, customer is getting
ANR8828E slot 64 of libr xxxx is inaccessible with his
robot ATL/ACL 6176.
<@>
IX86239 ANR0986I AT END OF EXPORT NODE PROCESSING IS REPORTING NUMBER OF
"BYTES" INSTEAD OF NUMBER OF "KILOBYTES"
Final statistics of total bytes moved during an export node
was displaying the same numeric value, but in different
magnitudes (ie., 5000000 kbytes also displayed as 5,000,000
bytes).
<@>
IX86372 ADSM AIX SERVER USING GENERIC TAPE DEVICE CLASS FAILS SYSTEM CALL
IN GETMODEL ROUTINE TO CHECK TYPE OF DRIVER BEING USED.
ADSM AIX server using generictape device class receives
anr9999d Unableto obtain model type for drivename, rc=xx.
For generic tape devices the server issues a system call to
determine the driver being used. If this system call should
fail for some reason the above anr9999d message will result.
<@>
IX86414 NOT ABLE TO DELETE NODE AFTER A NEW NODE TYPE=SERVER IS DEFINED
AND THE NODE'S FIRST LOGON ATTEMPT IS DONE BY A B/A CLIENT.
A node type server that was accessed as a backup/archive
client node cannot be removed until the server is halted and
restarted.
<@>
IX86630 ANR9999D BLKDISK.C(1053): SIZE OF FILE (0) NOT A MULTIPLE
OF THE DISK BLOCK SIZE (-1273015296).
The warning message that warns that not all the space
in a disk volume will be used had incorrect values
on AIX 4.2+ systems. The function was not otherwise
affected.
<@>
IX86662 DELGRACEPERIOD HAS LOWER LIMIT OF 5
The minimum value allowed for the grace deletion period is 5.
Because of the delay in deletion this causes (5 days), the
space in use by virtual volumes on the target server may
be high. Specifically, in some customer situations, due to
the way they are managing their data, this value causes
gigabytes of space to be used on the target.
<@>
IX86665 Q ACTLOG USING SEARCH=TXT_STRING: THE TXT_STRING IS IGNORED EXCEPT
WHEN USING THE NODENAME.
Event messages, those messages with 'ANE' prefix, logged to
to the server usually include a node name or server name that
the event originated from, and the session number. These are
enclosed in parethesis. For example:
.
ANExxxxs ( Session: xxx Node: ccccc ) Messages text goes here.
.
The user was trying to use the 'SEARCH' parameter in the
QUERY ACTLOG command to find certain words, such as,
'SEARCH=node:' or 'SEARCH=session' but not getting search
results. The reason for this is the 'PARENTHESIS',
the word 'SESSION:', and the word 'NODE:' are all text
formatted to the message at the time the message is printed
to the console. They are not stored in the database, thus,
not searchable. This is working as expected.
.
However what should be searchable is the message header
the actual session number, the actual node name, and the message
It was found that all of these are indeed searchable except
for the session number. Therefore, with this APAR the
QUERY ACTLOG in the server will be
updated to make sure the session number is also searchable.
The QUERY ACTLOG in the ADSM Server will be updated to ensure
that the session number in event messages ('ANE' messages )
are searchable with the 'SEARCH' parameter.
<@>
IX86691 DSMSERV FORMAT DOES NOT WORK WITH VOLUMES GREATER THAN 4 GB
The AIX server fails in initializing certain size
volumes with a
dsmserv format
command. For example, volumes of size 4096MB fail
but 4457MB succeed.
<@>
IX86736 LINUX CLIENT CAUSING ADSM SERVER INSTABILITY, SERVER NOT CHECKING
CERTAIN VERB SIZE INFO.
Linux client send a verb that is too long in length, causing
the server to crash.
<@>
IX86854 TRANSACTIONS ARE LEFT OVER IF THERE ARE NO RESTARTABLE RESTORE SESSIONS
WHEN A QUERY RESTORE COMMAND IS RUN.
The 'Query Restore' command does not clean up it's transactions
if there are no restartable restore sessions running.
<@>
IX86871 ANR8914I ANR8910I ANR8907E 3570 OR 3575 AUTOCLEANING ENABLED
ADSM-directed tape cleaning is being invoked on 357x libraries
even though these have their own hardware-enabled autocleaning,
and are not configured for ADSM-drive cleaning.
<@>
IX87208 SERVER MACRO CAUSES ACTLOG CORRUPTION, AND SOMETIME THE SERVER HANGS.
NT ADMIN CLIENT MAY CRASH ALSO.
On a V3 server, with an admin client execting a Macro command
for a macro file that is larger than 1024 char. can cause actlog
corruption and sometimes hang the server.
If the command line client is on NT, an Exception Violation can
occur and crash the client.
Query Actlog can also hang if processing data from the period
of the macro execution. A Select statement can retrieve the
actlog data from the actlog table.
<@>
Back to the table of contents
---------------------------------------------
$$ APARS fixed by this service level - part 2
---------------------------------------------
IX87680 ANR2344E WHEN DOING AN UPDATE STG POOLNAME MIGDELAY=NUMBER FOR A DISK
STORAGE POOL
Doing an upd stg archivepool migdelay=1 results in the following
messages
ANR2344E UPDATE STGPOOL: The "?" option is not valid for device
class DISK.
ANS8001I Return code 3.
<@>
PQ16375 ANR9999D CSSESS 'CANNOT REGISTER CLIENT ADDRESS TYPE 1' NT CLIENT
MVS SERVER WITH INTERLINK TCPIP PROMPTED
Clients were unable to use prompted scheduling over
Intelink TCPaccess.
<@>
PQ17134 ADSM CAN CONNECT TO THE WRONG TCP/IP ADDRESS SPACE IF THERE ARE
MULTIPLE TCP/IP ADDRESS SPACES.
After ADSM has initialized with TCP/IP and is listening on it's
specified TCPPort and TCP/IP is recycled, ADSM will attempt to
connect with the TCP image specified in ADSM server option
TCPName. If the specified TCP image has not been restarted
before ADSM tries re-establishing it's TCP/IP communications
and TCP/IP Version 3.1 is active or ADSM server option file
keyword IUCVTCPIP has been specified, ADSM will
attempt to connect with the default TCP image name of TCPIP.
If an image name of TCPIP is available, ADSM will
connect and initialize it's TCP/IP communication support with
that default TCPIP image name.
If TCP/IP V3.2 or higher is available and the IUCVTCPIP server
option keyword is not specified, ADSM will reconnect with the
specified TCP/IP image name as expected and will not attempt
connecting/initializing with the default image name of TCPIP.
Installation's using CLIO/S communication support, regardless of
the TCP/IP Version, will aggravated the condition because ADSM
implicitly specifies the ADSM server option keyword IUCVTCPIP if
CLIOPort option is detected in the ADSM server option file.
<@>
PQ17930 DSMADMC TSO ANS1033E ANS8023E
TSO Admin Client displays an error message indicating the
gethostbyname function failed. Also, the error code value
that appears in the message is incorrect.
<@>
PQ19631 SETOPT ADSM V3 ANR2045E ABEND0C4
ANR2045E message inserts have been corrected.
<@>
PQ20556 3590 TAPE EMULATING 3490 CHANGE IN REPORTED CARTRIDGE LENGTH
Hardware EC changes and newer control units will change the way
that the cartridge length is reported for 3590's in emulation
mode. The tapes were originally reported as ECCST, and will be
reported as CST. If the length parameter has been set to ECCST
in any devclass used to access these devices, it will need to be
changed to CST or ANY when the hardware change is made for new
or empty tapes to be used.
<@>
PQ20701 ANR0101E IDGROUP(283) + ANR9999D HTTREE(1891) AFTER UPGARDEDB FOR
INSTALL OF ADSM MVS 3.1 2.0 WITHOUT RUNNING ANRIDL
When starting the ADSM server in the upgrade DB mode a couple
of ANR9999 messages stating that the interface.task table
could not be opened followed by a message stating a error occure
while quering a group. Yes, there is a problem, but the problem
does not indicate a database failure. The problem is that the
task table for the ADSM interface was not created but the server
is in the process of creating the table. Better known as the
chicken and egg problem.
<@>
PQ21036 ADSM ACCOUNTING RECORDS DISPLAY INCORRECT DATA FOR THE "PRODUCT LEVEL"
& "PRODUCT SUBLEVEL" FIELDS AND MISSING SOME EBCDIC CHAR.
****************************************************************
Accounting records do not appear to have valid version and
level information.
<@>
PQ21142 ADSM QUERY ARCHIVE OR RETRIEVE FROM A V3 CLIENT CAN TAKE A LONG TIME TO
PROCESS.
<@>
PQ21450 ANR0534W COUPLED WITH ANS1311E HAS 2 CIRCUMVENTIONS.
The explanation and user response for message ANR0534W needed
to be expanded to give a better explanation of possible
causes and circumventions.
<@>
PQ21493 USING THE IFNEWER OPTION AND THE NOQUERY RESTORE PROTOCOL CAUSE
UNNECESSARY TAPE MOUNTS AND DATA SENT FROM SERVER TO CLIENT.
Using the ifnewer option and the noquery restore protocol cause
unnecessary tape mounts and data sent from server to client.
The server sends the client all it's files and data. The client
then decides if the files meet the criteria. The client will
keep the files that meet the criteria and trash the others.
<@>
PQ21527 ADSM ADMIN CLIENT ABENDS AFTER SQL COMMAND.
error occurred freeing memory on an SQL error path
<@>
PQ21824 CMS ABEND 000000E0 OCCURS SOON AFTER MESSAGEHCPMHT2153I TAPE NNNN
I/O CANCELLED DUE TO A MISSING INTERRUPTDISPLAYS.
CMS abend 000000E0 occurs soon after messageHCPMHT2153I TAPE
nnnn I/O CANCELLED DUE TO A MISSING INTERRUPTis displayed on
the ADSM server console.
<@>
PQ22059 CRASH AT OFFSET 000003A0 IN PROC DEALLOCATECONVERSATION
Customer receives an intermittent ABEND0C4 in DSMSERV on his MVS
SERVER level 2.1.18. PN84541 closed the timing window, but not completely.
<@>
PQ22399 ANR5035E DYNAMIC ALLOCATION FAILURE, RETURN CODE 4, ERROR CODE -1
ON ADSM MVS 3.1.2.1 LEVEL SERVER.
At the ADSM/MVS 3.1.2.1 server level dynamic allocation failures
may not be handled correctly. This leads to a mount failure
and process/session termination rather than to request for reply
to wait, retry or cancel. The squence of messages received by
the reporting customer are:
IKJ66231I DATA SET ADSM.BFS.V259 NOT ALLOCATED, SYSTEM OR INSTAL
INSTALLATION ERROR+
IKJ56231I DYNAMIC ALLOCATION REASON CODE IS X'000004E5'
IEF391I ADSM ADSM SYS00170 UNABLE TO ALLOCATE - A TAPE
ALLOCATION SUBSYSTEM ELIMINATED ELIGIBLE DRIVES
IEF234E K 0501,009090,PVT,ADSM,ADSM
ANR5035E Dynamic allocation of tape unit 3490 failed, return
code 4, error code -1, info code -1.
ANR9999D PVRCART(1607): Error dynfree'ing ddname , rc 4,
errorcode 860, infocode 1.
<@>
PQ22461 ANR9999D MESSAGES ARE DISPLAYED W/O THE ANR9999D MESSAGE NUMBER ON
ADDITIONAL OUTPUT LINES WHEN MESSAGEFORMAT 2 IS USED.
ANR9999D messages not conforming to ' MESSAGEFORMAT 2 '.
<@>
PQ22570 ANR9999D SMHTTP(1761): ERROR OPENING INPUT FILE COMMANDLINEBEANI
NFO.CLASS
NEEDS TO BE CHANGED TO A WARNING
An ANR9999D error message is displayed when a file is not found
by the ADSM web engine. The problem is that Internet Explorer
thinks that the ADSM CommandLine applet is a JavaBean and
requests a file that does not exist. This error can be ignored.
<@>
PQ22885 ADSM ADMIN SCHEDULE EVENT SHOWS FAILED IF THE SCHEDULE DOES NOT
COMPLETE WITHIN THE SCHEDULE WINDOW
An adsm script is run via an adsm admin schedule. The adsm
script has several "backup stgpool" commands with "wait=yes"
parameters. If the script does not complete within the admin
schedule window, the admin schedule event will show a status
of "FAILED" for that schedule.
<@>
PQ23263 ON VM ADSM V2 SERVER, DB BACKUPS OR DUMPS THAT SPAN TAPES USING
A DEVCLASS W/ 3590 DEVTYPE WILL FAIL ON RESTORE / LOAD OPERATION.
Database backups or database dumps that span tapes
and were done using a devclass with the 3590 devtype
will fail on restore or load operations. The database
restore or database load will fail when it reaches the end
of the first tape. This does not affect full or incremental
backups unless a single backup command requires
multiple tapes. Database restores that require multiple
tapes will not be affected by this problem if each tape has
a different operation number.
This ONLY affects ADSM VM using devclasses with 3590
devtype (devclasses with devtype CARTRIDGE that
include 3590 devices emulating 3490 drives are not affected).
Only backup/restore or dump/load operations are affected.
Import/export and storage pool volumes should not have
this problem.
Finally, only if a single operation spans tapes
(a single backup db type = full, backup db type=incr, or
dsmserv dump command used more than one tape)
should this problem be seen.
<@>
SA77581 ANR - UNABLE TO REINITIALIZE SECOND SIZE OF OPTICAL VOLUME
Customer is backing up monthly data to Optical then executing
MOVE DATA to move to tape. The next time ADSM goes to use the
"empty" Optical volume, it attempts to reinitialize:
ANR8702I Initializing sie xxx of volume xxx.
followed 8 minutes later by
ANR0991I Server shutdown complete
Job Log shows MCH1211 "divide by zero" error from PVRHFS
Apparently only one side of optical was re-intialized; Side A is
blank, Side B has Data although ADSM indicates 0% Utilized.
He can restart ADSM server with no problem.
<@>
IX80737 WHEN A SESSION IS ENDING, ADSM WILL SOMETIMES TERMINATE WITH A
DBTXN077. THIS HAS BEEN SEEN ON AIX AND MVS.
During Scheduled backup operations, the server may abend with
a message inticating that the DBTXN077 assertion failed.
<@>
Back to the table of contents
----------------------------------------
$$ APAR Sysroutes for this service level
----------------------------------------
IC20502: SYSROUTES:
IC22123: SYSROUTES: IC22123(HP)
IC22247: SYSROUTES:
IC22324: SYSROUTES:
IC22462: SYSROUTES:
IX85279(AIX),PQ22073(MVS),IC22462(N/T),IC22714(HP),IC22715(SUN)
IC22494: SYSROUTES:
IX84581(AIX),IC22494(N/T),IC22494(N/T),IC22547(HP),IC22548(SUN)
IC22675: SYSROUTES:
IX86874(AIX(,PQ23354(MVS),IC22675(N/T),IC23064(HP),IC23065(SUN)
IC22721: SYSROUTES: IX86650(AIX),IC22997(N/T,IC22998(HP),IC22721(SUN)
IC22852: SYSROUTES: IX86649(AIX),IC22995(N/T),IC22852(HP),ic22996(SUN)
IC22970: SYSROUTES:
IX86661(AIX),PQ23206(MVS),IC22970(N/T),IC23009(HP),IC23010(SUN)
IX78238: SYSROUTES:
IX78238(AIX),PQ21917(MVS),IC22660(N/T),IC22661(HP),IC22662(SUN)
IX79728: SYSROUTES:
IX79728(AIX),PQ23357(MVS),IC23072(N/T),IC23073(HP),IC23074(SUN)
IX79929: SYSROUTES: IX79929(AIX),IC22946(N/T),IC22947(HP),IC22599(SUN)
IX80749: SYSROUTES:
IX80749(AIX),PQ20571(MVS),IC22305(N/T),IC22306(HP),IC22307(SUN)
IX81490: SYSROUTES: IX81490(AIX),IC22124(N/T),IC22125(HP),IC22126(SUN)
IX82231: SYSROUTES:
IX82403: SYSROUTES:
IX82403(AIX),PQ23395(MVS),IC23086(N/T),IC23087(HP),IC23088(SUN)
IX82929: SYSROUTES:
IX82929(AIX),PQ20633(MVS),IC22329(N/T),IC22330(HP),IC22331(SUN)
IX83029: SYSROUTES: IX83029(AIX),IC22153(N/T),IC22155(HP),IC22156(SUN)
IX83978: SYSROUTES: IX83978(AIX),IC23090(N/T),IC23091(HP),IC23092(SUN)
IX84094: SYSROUTES:
IX84094(AIX),PQ22727(MVS),IC22892(N/T)IC22893(HP),IC22895(SUN)
IX84124: SYSROUTES: N/A
IX84141: SYSROUTES:
IX84177: SYSROUTES:
IX84177(AIX),PQ22736(MVS),IC22896(N/T),IC22897(HP),IC22898(SUN)
IX84456: SYSROUTES: IX84456(AIX),IC22550(N/T),IC22551(HP),IC22552(SUN)
IX84485: SYSROUTES:
IX84485(AIX),PQ23353(MVS),IC23060(N/T),IC23061(HP),IC23062(SUN)
IX84602: SYSROUTES: IX84602(AIX),IC22572(N/T),IC22573(HP),IC22574(SUN)
IX84637: SYSROUTES: IX84637(AIX),IC22567(N/T),IC22568(HP),IC22569(SUN)
IX84715: SYSROUTES:
IX84715(AIX),PQ22704(MVS),IC22879(N/T),IC22880(HP),IC22881(SUN)
IX84765: SYSROUTES:
IX84765(AIX),PQ23393(MVS),IC23083(N/T),IC23084(HP),IC23085(SUN)
IX84769: SYSROUTES:
IX84769(IAX),PQ23044(MVS),IC22958(N/T),IC22959(HP),IC22960(SUN)
IX84965: SYSROUTES:
IX84965(AIX),PQ23356(MVS),IC23069(N/T),IC23070(HP),IC23071(SUN)
IX85064: SYSROUTES:
IX85064(AIX),PQ22708(MVS),IC22887(N/T),IC22888(HP),IC22889(SUN)
IX85125: SYSROUTES: IX85125(AIX),IC22736(N/T),IC22737(HP),IC22738(SUN)
IX85134: SYSROUTES: IX85134(AIX),IC22952(N/T),IC22953(HP),IC22954(SUN)
IX85182: SYSROUTES:
IX85278: SYSROUTES:
IX85278(AIX),PQ24309(MVS),IC23309(N/T),IC23310(HP),IC23311(SUN)
IX85298: SYSROUTES:
IX85298(AIX),PQ22256(MVS),IC22750(N/T),IC22751(HP),IC22752(SUN)
IX85410: SYSROUTES:
IX85410(AIX),PQ23352(MVS),IC23057(N/T),IC23058(HP),IC23059(SUN)
IX85412: SYSROUTES: IX85412(AIX),IC22917(N/T),IC22918(HP),IC22919(SUN)
IX85431: SYSROUTES: IX85431(AIX),IC22949(N/T),IC22950(HP),IC22951(SUN)
IX85513: SYSROUTES:
IX85513(AIX),PQ23045(MVS),IC22961(N/T),IC22963(HP),IC22964(SUN)
IX85583: SYSROUTES: IX85583(AIX),IC23048(N/T),IC23049(HP),IC23050(SUN)
IX85726: SYSROUTES:
IX85726(AIX),PQ22737(MVS),IC22899(N/T),IC22900(HP),IC22901(SUN)
IX85734: SYSROUTES:
IX85734(AIX),PQ24306(MVS),IC23302(N/T),IC23303(HP),IC23304(SUN)
IX85810: SYSROUTES:
IX85810(AIX),PQ23331(MVS),IC23035(N/T),IC23036(HP),IC23037(SUN)
IX86239: SYSROUTES:
IX86239(AIX),PQ23351(MVS),IC23054(N/T),IC23055(HP),IC23056(SUN)
IX86372: SYSROUTES:
IX86414: SYSROUTES:
IX86414(AIX),PQ23332(MVS),IC23038(N/T),IC23039(HP),IC23040(SUN),
IX86630: SYSROUTES:
IX86662: SYSROUTES:
IX86662(AIX),PQ23334(MVS),IC23045(N/T),IC23046(HP),IC23047(SUN)
IX86665: SYSROUTES:
IX86665(AIX),PQ23355(MVS),IC23066(N/T),IC23067(HP),IC23068(SUN)
IX86691: SYSROUTES:
IX86854: SYSROUTES:
IX86871: SYSROUTES: IX86871(AIX),IC23075(N/T),IC23076(HP),IC23077(SUN)
PQ16375: SYSROUTES: N/A
PQ17134: SYSROUTES:
PQ17930: SYSROUTES:
PQ19631: SYSROUTES:
IX84290(AIX),PQ19631(MVS),IC22440(N/T),IC22441(HP),IC22443(SUN)
PQ20556: SYSROUTES:
PQ20701: SYSROUTES:
IX84241(AIX),PQ20701(MVS),IC22428(N/T),IC22429(HP),IC22430(SUN)
PQ21036: SYSROUTES:
IX86228(AIX),PQ21036(MVS),IC22934(N/T),IC22935(HP),IC22936(SUN)
PQ21142: SYSROUTES:
IX86869(AIX),PQ21142(MVS),IC23032(N/T),IC23033(HP),IC23034(SUN)
PQ21450: SYSROUTES:
IX85899(AIX),PQ21450(MVS),IC22884(N/T),IC22885(HP),IC22886(SUN)
PQ21493: SYSROUTES:
IX(87650(AIX),PQ21493(MVS),IC23316(N/T),IC23317(HP),IC23318(SUN)
PQ21527: SYSROUTES:
IX86660(AIX),PQ21527(MVS),IC23005(N/T),IC23006(HP),IC23007(SUN)
PQ21824: SYSROUTES:
PQ22059: SYSROUTES:
PQ22399: SYSROUTES:
PQ22461: SYSROUTES:
IX86870(AIX),PQ22461(MVS),IC23041(N/T),IC23042(HP),IC23043(SUN)
PQ22570: SYSROUTES:
IX86373(AIX),PQ22570(MVS),IC22955(N/T),IC22956(HP),IC22957(SUN)
PQ23263: SYSROUTES:
SA77581: SYSROUTES:
IX86736: SYSROUTES:
IX86736(AIX),PQ24311(MVS),IC23312(N/T),IC23313(HP),IC23313(SUN)
PQ22885: SYSROUTES:
IX86873(AIX),PQ22885(MVS),IC23051(N/T),IC23052(HP),IC23053(SUN)
IX85858: SYSROUTES: IX85858(AIX,IC23319(N/T)IC23320(HP),IC23321(SUN)
IX87208: SYSROUTES:
IX87208(AIX),PQ24308(MVS),IC23305(N/T),IC23306(HP),IC23307(SUN)
PQ21945: SYSROUTES: N/A
IX85858: SYSROUTES: IX85858(AIX,IC23319(N/T)IC23320(HP),IC23321(SUN)
IX87208: SYSROUTES:
IX87208(AIX),PQ24308(MVS),IC23305(N/T),IC23306(HP),IC23307(SUN)
PQ21945: SYSROUTES: N/A
IX87680: SYSROUTES
IX87680(AIX),PQ25068(MVS),IC23510(N/T),IC23511(HP),IC23512(SUN)
Back to the table of contents