|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Subject: Re: New_AIXV4_Fixes
From: AIX Service Mail Server (aixserv
austin.ibm.com)Date: Tue Nov 28 2000 - 02:15:41 CST
- Next message: AIX Service Mail Server: "Re: New_AIXV4_Fixes"
- Previous message: AIX Service Mail Server: "Re: Security"
- Next in thread: AIX Service Mail Server: "Re: New_AIXV4_Fixes"
- Maybe reply: AIX Service Mail Server: "Re: New_AIXV4_Fixes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
APAR: IC16826 COMPID: 5639A4600 REL: 410
ABSTRACT: PCSWS DIES WHEN AN EHLLAPI APPLICATION CALLS COPY_PS WITH EAB
PROBLEM DESCRIPTION:
Error in memory management function causes PCSWS to fail when
an EHLLAPI application calls copy_ps with EAB and XLATE option.
PROBLEM CONCLUSION:
The memory management function has been
changed for PCOM NT version because a pointer cannot be passed
to another process under NT environment. ComputeColor routine
in pcswacps.c/pcswsapi.dll still send pointer in the parameter
block and pass it to pcsws process to get color information
based on the field/color attributes. It should pass the memory
handle instead of memory pointer.
------
APAR: IC26470 COMPID: 5697TSMAX REL: 110
ABSTRACT: UPDATE SCRIPT WHILE SCRIPT RUNNING - HANG ADMIN SESSIONS
PROBLEM DESCRIPTION:
Customer has some long running scripts (i.e. BACKUP STGPOOL
WAIT=YES). He starts Web Admin session to do a update to script
which get exclusive lock on CC_LOCK_UNIVERSE but then is waitin
for exclusive lock on ADM_LOCK_COMMANDS. The long running
scripts are already holding a Shared lock on ADM_LOCK COMMANDS.
As result Web Admin sessions will not start and even TCPIP Admin
Session appear to hang - everything is waiting for the long runn
scripts to end.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM users.
****************************************************************
* PROBLEM DESCRIPTION: *
An attempt to update or delete a script while the script is
running will cause the update or delete command to hang until
the script is complete. The thread running the UPDATE or
DELETE for the script could be holding other locks, causing
performance degradation on the server.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF when available.
****************************************************************
Modified the server to prevent an UPDATE or DELETE function
against a script while one or more instances of that script
are currently running on the server. A new message ANR1495E
will be issued when that happens, and the UPDATE or DELETE
will fail.
------
APAR: IC26487 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANE4987E MESSAGE BEING MISSING
PROBLEM DESCRIPTION:
ANE4987E MESSAGE BEING MISSING
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM V3.7 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
While using event logging on the server, the user was
receiving the following error message on the server console:
"Error retrieving message 14987 for 1 from EN_US".
The message is missing from the server message catalogue
file.
The server should have issued ANE4987E:
Example:
ANE4987E ( Session: nn, Node: nodename ) Error processing
'filename' : the object is in use by another process
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
ANE messages are client error displayed on the server.
The client was issuing ANS4987E on the client but the server
did not have the corresponding message on the server message
repository.
PROBLEM CONCLUSION:
The server message repository has been updated to fix the
problem.
------
APAR: IC26500 COMPID: 5697TSMAX REL: 110
ABSTRACT: QUERY OPTION COMMAND FAILS TO DISPLAY STATUS OF NOPREEMPT OPTION
PROBLEM DESCRIPTION:
The command 'query option' does not report the status of the
server option 'NOPREEMPT'
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM V3.7 Server users.
****************************************************************
* PROBLEM DESCRIPTION: *
'QUERY OPTION' command does not display status of 'NOPREEMPT'
server option.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
The status of the 'NOPREEMPT' server option was not being
displayed in the output of the 'QUERY OPTION' command.
PROBLEM CONCLUSION:
Server code has been updated to include the status of the
'NOPREEMPT' option in the output of the QUERY OPTION command.
Note that as documented, the 'NOPREEMPT' option does not have
additional values with it. The user either specifies the
keyword 'NOPREEMPT' in the server's option file, or, does not
have the keyword in the server's option file.
Thus, with this code update the server will include in the
output
of the QUERY OPTION command either one of the following:
Server Option Option Setting
NOPREEMPT ( No ) <-- if NOPREEMPT is
not specified in
the server option
. file.
or,
Server Option Option Setting
NOPREEMPT ( Yes ) <-- if NOPREEMPT is
specified in the
server option file.
------
APAR: IC26600 COMPID: 5697TSMAX REL: 110
ABSTRACT: CHANGING THE PREFIX ON A SERVER DEVICE CLASS CAN RESULT IN
PROBLEM DESCRIPTION:
Changing the volume prefix for a devclass type of SERVER can
result in being unable to recover data from volumes created with
the original prefix.
The 'Reconcile Volumes' command will report that there are
invalid volumes detected and attempts to restore data from the
affected volumes can result in messages similar to:
ANR9999D pvrserv.c(600): Error positioning SERVER volume
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of ADSM and TSM who use virtual volumes to store data
on another server.
****************************************************************
* PROBLEM DESCRIPTION: *
If the virtual volume prefix was changed using the UPDATE
DEVCLASS command, existing data may become inaccessible.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************
PROBLEM CONCLUSION:
The RECONCILE VOLUMES command is modified to recognize and
correct inconsistent virtual volume prefixes.
------
APAR: IC26638 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANR9999D ANR0530W CONCURRENT SERVER TO SERVER SESSIONS FOR SAME
PROBLEM DESCRIPTION:
When running multiple concurrent server-to-server sessions for
the same server node, one of more of the concurrent sessions
may abort with the error messages in the following example.
ANR0406I Session 323 started for node ADSMSERV (AIX-RS/6000)
(Tcp/Ip ....).
ANR0406I Session 324 started for node ADSMSERV (AIX-RS/6000)
(Tcp/Ip ....).
....
ANR9999D IMUTIL(2869): Lock acquisition (sLock) failed for
Inventory node 11.
ANR0530W Transaction failed for session 324 for node ADSMSERV
(AIX-RS/6000) - internal server error detected.
For more information on the function in question, please refer
to the ADSM Administrator's Guide, Chapter 4, "Storing Data on
Another Server" or the topic "Using Virtual Volumes".
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This apar affects ADSM V312 and TSM V370 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
When using virtual volumes between a source and target server,
there is a timing issue where a locking failure on the
target server may occur.
****************************************************************
* RECOMMENDATION: *
Please apply the ptf containing this fix once it is available.
****************************************************************
The server algorithm managing lock constructs on the target
server has been modified to correct the situation where the
lock acquisition failure occurred.
PROBLEM CONCLUSION:
An algorithm used by the target server for locking could result
in a locking situation where a lock could not be granted.
This is timing specific and only may occur if multiple inbound
sessions for virtual volume operations are in use on the
target server.
------
APAR: IC26672 COMPID: 5697TSMAX REL: 110
ABSTRACT: TSM DISPLAYS A NEGATIVE BUFFER REQUESTS
PROBLEM DESCRIPTION:
TSM 3.7.2 has been seen to display a negative Total Buffer Reque
seen below:
tsm: NSM_101>q db f=d
Available Space (MB): 28,328
Assigned Capacity (MB): 28,328
Maximum Extension (MB): 0
Maximum Reduction (MB): 12,344
Page Size (bytes): 4,096
Total Usable Pages: 7,251,968
Used Pages: 4,093,649
Pct Util: 56.4
Max. Pct Util: 56.5
Physical Volumes: 6
Buffer Pool Pages: 16,384
Total Buffer Requests: -1,916,139,261
Cache Hit Pct.: 0.00
Cache Wait Pct.: 0.00
Backup in Progress?: No
Type of Backup In Progress:
Incrementals Since Last Full: 0
Changed Since Last Backup (MB): 19.75
Percentage Changed: 0.12
Last Complete Backup Date/Time: 03/01/00 09:00:10
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All V3.7 TSM Servers
****************************************************************
* PROBLEM DESCRIPTION: *
TSM Server displays a negative value for buffer requests in the
output of a Query DB command.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
The buffer request was being stored internally as a signed
integer. Once the high order bit becomes 1, the number becomes
negative. This causes the buffer requests to be invalid. The
server is changed to use an unsigned integer.
PROBLEM CONCLUSION:
Server code has been updated to fix the problem.
------
APAR: IC26881 COMPID: 5697TSMAX REL: 110
ABSTRACT: "LABEL LIBVOLUME" W/ OVERWRITE=YES CAN OVERWRITE THE LABELS OF
PROBLEM DESCRIPTION:
Under some circumstances, issuing the command "label libv search
=y overwrite=y" will overwrite the label of a volume that has
valid data and does belong to a storage pool.
Normally, if the library inventory is correct, the issuing of
this command will cause the process to skip over all known
volumes and only select those volumes not currently known by
the TSM server (via a "q libv").
However, if the library inventory is not current, it is possible
for the "label libv" process to select a tape that is part of
a storage pool and overwriute the label effectively destroying
the data.
In the PVR MMS trace, it shows the following for the command:
"label libv (libname) search=y labels=p checkin=pri(scr)
overwrite=y" where the library inventory was out of sync and
the tape selected was part of a storagepool w/ data.
pvrgts.c(3909): Read VOL1 block from drive MT3.0.0.2 (MT3.0.0.2)
pvrgts.c(3949): Read HDR1 block from drive MT3.0.0.2 (MT3.0.0.2)
pvrgts.c(3989): Read HDR2 block from drive MT3.0.0.2 (MT3.0.0.2)
pspvr.c(1812): ReadFile failed with error code 1101 read 0
mmstxn.c(211): Acquiring MMS universe lock (sLock).
mmstxn.c(211): Acquiring MMS universe lock (sLock).
pvr.c(2082): Matching volume name "ADSM21" (devClass=3).
mmsscsi.c(12156): From ObtainMediaType: devType=0 mediaType=0
mmsscsi.c(13433): Opening drive MT3.0.0.2 (MT3.0.0.2) in library
LB5.0.0.2 waiting upto 120 seconds for drive to respond.
mmsscsi.c(3355): Waiting for drive MT3.0.0.2 (MT3.0.0.2) to beco
ready in library LB5.0.0.2.
pvrgts.c(2625): Testing readiness of drive MT3.0.0.2 (MT3.0.0.2)
pspvr.c(2049): PvrTapeIoctl: function = 0x8402C044
pspvr.c(2054): PvrTapeIoctl: STIOCTOP op = 6, count = 1
smcancel.c(593): Cancelling session 29 due to timeout.
pvr8mm.c(1745): using 8mm format 0x1
pvrgts.c(2742): Writing Label to drive MT3.0.0.2 (MT3.0.0.2)
pvrgts.c(3712): WriteLabelBlocks to drive MT3.0.0.2 (MT3.0.0.2):
VOL1ADSM30
HDR1
HDR2U3276800000 0
pspvr.c(2049): PvrTapeIoctl: function = 0x8402C044
pspvr.c(2054): PvrTapeIoctl: STIOCTOP op = 6, count = 1
pvrtape.c(874): Setting mode for drive MT3.0.0.2 (MT3.0.0.2); fo
............
The actlog, "q vol" and "q libv" show:
ANR8809I 009: Please provide the label name for the volume
in slot element 2 of library LB5.0.0.2 by issuing REPLY
LABEL=xxx within 60 minutes, where n is the re quest I
and xxx is the desired label name.
ANR8809I 009: Please provide the label name for the volume
in slot element 2 of library LB5.0.0.2 by issuing REPLY
LABEL=xxx within 59 minutes, where n is the re quest I
and xxx is the desired label name.
ANR0407I Session 29 started for administrator ADMIN
(WinNT) (Tcp/Ip 9.113.221.123(1787)).
ANR2017I Administrator ADMIN issued command: QUERY REQ
ANR8352I Requests outstanding:
ANR8809I 009: Please provide the label name for the volume
in slot element 2 of library LB5.0.0.2 by issuing REPLY
LABEL=xxx within 59 minutes, where n is the re quest I
and xxx is the desired label name.
ANR2017I Administrator ADMIN issued command: REPLY 009
label=adsm30
ANR8499I Command accepted.
ANR8810I Volume ADSM30 has been labeled in library
LB5.0.0.2.
ANR0407I Session 30 started for administrator ADMIN
.........
tsm: SERVER1>q libv
Library Name Volume Name Status Last Use Home Element
LB5.0.0.2 ADSM22 Scratch 3
LB5.0.0.2 ADSM24 Private DbBackup 1
LB5.0.0.2 ADSM30 Private 2
tsm: SERVER1>q vol
Volume Name Storage Device Estimated Pct Volu
Pool Name Class Name Capacity Util Stat
(MB)
ADSM21 8MMPOOL1 8MMCLASS1 4,678.0 4.0 Filli
D:\DB\DATA.DSM BACKUPPOOL DISK 200.0 1.4 On-Li
...........................
All this shows is that ADSM21 is a valid tape with data and
it was overwritten by the "label libv" command thus destroying
the data.
LOCAL FIX:
1. Make sure that after any inventory changes were made that
the "checkout libv" command was used or..
2. The "audit libr" cammand is used to sync the inventory.
3. Use "dsmlabel" and "checkin libv" instead of "label libv".
.......
This problem only occurs if the library inventory is out of
sync.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
1) ADSM 3.1.2.X and TSM 3.7X customers on the AIX, HP, SUN and
NT platforms.
2) Issue the LABEL LIBVOLUME command with the OVERWRITE=YES
option.
****************************************************************
* PROBLEM DESCRIPTION: *
The ADSM/TSM server may re-label a volume defined to a storage
pool or in the volume history file under the following
conditions:
1) The user specified the OVERWRITE=YES option in the LABEL
LIBVOLUME command.
2) The volume defined to the storage pool or in the volume
history file was either checked out or moved to a
previously empty slot within the library.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The ADSM/TSM server does not allow a user to re-label a volume
defined to a storage pool or in the volume history file under
any circumstance.
TEMPORARY FIX:
Do not specify the OVERWRITE=YES option on the LABEL LIBVOLUME
command.
In general, customers should not use the OVERWRITE=YES option
unless they are absolutely sure they wish to re-label the
tapes.
Without the OVERWRITE=YES option, the ADSM/TSM server will
display the existing internal tape label. After verifying
that he/she wishes to overwrite the data on the given volume,
the customer can re-issue the LABEL LIBVOLUME command with
the OVERWRITE=YES option.
------
APAR: IC26898 COMPID: 5697TSMAX REL: 110
ABSTRACT: ACTIVITY SUMMARY TABLE IS NOT UPDATED CORRECTLY IN CASE OF BACKU
PROBLEM DESCRIPTION:
Activity summary table is not updated correctly in case of backu
p stg has failed due to ANR1217E (insufficient number of mount
points available). To recreate:
1. Make sure insufficient mount points are available (e.g. by
setting drives offline)
2. Start backup storage pool
3. Wait for ANR1217E
4. The ANR0985I messages indicates backup stg has completed with
completion state FAILURE
5. select * from summary reports backup stg as successful
From the code (3.7.2.0) it looks a backup stgpool is only
considered as unsuccessful if cpyCtlP->totAbortTxns |= 0
(bf/bfcputil.c line 894) holds. Since the process already
failed at the very beginning due to insufficient
mountpoints no file was copied and no transaction was
aborted.
LOCAL FIX:
Check the actlog for correct results.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem can affect customers who perform storage pool
backup using the Tivoli Storage Manager 3.7 or 4.1 server.
****************************************************************
* PROBLEM DESCRIPTION: *
In certain situations, the SUMMARY table can show that
a storage pool backup operation was successful even
though message ANR0985I reported that a backup process
failed.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Storage pool backup has been modified so that the SUMMARY
table will show that the backup operation was not successful
if any of the backup processes failed.
PROBLEM CONCLUSION:
The server has been modified so that the SUMMARY table will
indicate that a storage pool backup operation was not
successful if any of the backup processes failed.
------
APAR: IC26903 COMPID: 5697TSMAX REL: 110
ABSTRACT: ADSM DISMOUNT FAILURE RETRY LOGIC IN EMM ENVIRONMENT HALTS
PROBLEM DESCRIPTION:
In an External Media Manager environment ADSM should not be
using a dismount failure retry logic. Errors messages that
maybe present during failure:
ANR9999D mmsext.c(2822): Error writing 'DISMOUNT LIB1 H00612 '
to exit. (-1/21)
ANR9999D mmsext.c(691): unable to close file, rc = -1.
ANR8769E External media management function DISMOUNT returned
result=**Undefined**.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using the External Media Management Environments
(LIBTYPE=EXTERNAL) and TSM 3.7.2.0 PTF on AIX, SUN, HP and NT
platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
TSM 3.7.2.0 incorrectly retries dismount failures for
LIBTYPE=EXTERNAL (External Media Management Environment).
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM server does not retry a dismount failure when
LIBTYPE=EXTERNAL (External Media Management Environment).
------
APAR: IC26929 COMPID: 5697TSMAX REL: 110
ABSTRACT: WEB ADMIN ONLINE HELP FOR DEFINE SERVER IS INCORRECT IN OPTION
PROBLEM DESCRIPTION:
Extend and correct Web Admin Online Help corresponding Administr
ators Reference GC35-0369-00 in the topic
DEFINE SERVER
--> Grace Deletion Period
* The minimum value is 0
* The default value is 5
* The maximum value is unlimited
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem affects users of Tivoli Storage Manager V3.7
Web admin interface on all platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
Web help file specified incorrect value for grace deletion
period.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Per customers description, value was changed in Web help to
match other documentation.
PROBLEM CONCLUSION:
The Web help files containing the incorrect information were
updated.
------
APAR: IC26938 COMPID: 5697TSMAX REL: 110
ABSTRACT: THE 'QUERY BACKUPSETCONTENTS' COMMAND DOES NOT WORK WHEN
PROBLEM DESCRIPTION:
The documentation for the 'Query Backupsetcontents' command
indicates that the word 'backupsetcontents' may be abbreviated
to 'backupsetc'. This syntax does not work and fails with:
tsm: ADSM>q backupsetc greg GREGBACKUPSET.*
ANR2000E Unknown command - QUERY BACKUPSETC.
ANS8001I Return code 2.
This was recreated on the TSM 3.7.3.0 server level.
LOCAL FIX:
Use the complete word 'backupsetcontents'.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Users of the Tivoli Storage Management server command
QUERY BACKUPSETCONTENTS.
****************************************************************
* PROBLEM DESCRIPTION: *
The command QUERY BACKUPSETCONTENTS cannot be invoked using the
documented minimum abbreviation of Q BACKUPSETC.
****************************************************************
* RECOMMENDATION: *
Apply the appropriate fixing PTF.
****************************************************************
PROBLEM CONCLUSION:
The Tivoli Storage Management server has been modified to
accept Q BACKUPSETC as a valid abbreviation of QUERY
BACKUPSETCONTENTS.
------
APAR: IC26944 COMPID: 5697TSMAX REL: 110
ABSTRACT: ADSM DEVICES WITH THE DEVICE NAME FORMAT OF /DEV/MTX STOP
PROBLEM DESCRIPTION:
Upgrading from an earlier level of ADSM or TSM to 3.7.3.0 can
cause previously defined ADSM/TSM devices to stop working.
The failure is caused by an undocumented change to ODM
definitions. The existence of the problem can be determined
by issuing the command 'lsdev -Cc tape' at an AIX commandline
prompt - results like the following are an indication the
problem exists:
lsdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device mt0.
mt0 Defined 30-60-00-1,0 N/A
The previously configured devices cannot be deleted. They
will not show up under the SMIT -> DEVICES -> TIVOLI STORAGE
MANAGER DEVICES ->REMOVE A TAPE DRIVE. They will show up
under SMIT -> DEVICES -> TAPE DRIVE -> REMOVE A TAPE DRIVE, but
attempts to delete them will result in the following message:
rmdev: 0514-521 Cannot find information in the predefined device
configuration database for the customized device mt0.
The command 'lsdev -Cc adsmtape' will have to be used to view
devices created with the TSM 3.7.3.0 devices.rte fileset.
LOCAL FIX:
One solution to get the physical drives configured and
working again is to use the SMITTY -> DEVICES -> TIVOLI
STORAGE MANAGER DEVICES -> TAPE DRIVE -> ADD A TAPE DRIVE
to create new mtX devices, then use TSM 'Update Drive' command
to update the device names for the drives configured for
the TSM library
The 'odmdelete -o CuDv -q name=mtX' can be used to
delete the definitions in the ODM.
Where X is the appropriate number.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of TSM who have existing TSM hardware definitions
and upgrade to TSM 3.7.3.0.
****************************************************************
* PROBLEM DESCRIPTION: *
TSM hardware definitions prior to 3.7.3.0 upgrade are
invalidated.
****************************************************************
* RECOMMENDATION: *
Install the latest available TSM release.
****************************************************************
Install latest level of TSM to prevent this problem.
------
APAR: IC26979 COMPID: 5697TSMAX REL: 110
ABSTRACT: TSM 3.7.3 DOES NOT POLL DRIVES INDEFINITELY WHEN 3494 SHARED YES
PROBLEM DESCRIPTION:
The TSM 3.7.3 server does not poll drives indefinitly when the
3494SHARED YES option is specified in the dsmserv.opt file and
there is another application's volume loaded in the drive.
TSM polls the drive for 10 minutes and then marks the drive
off-line.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers with a 3494 library using TSM 3.7.3.0 on the AIX,
HP, SUN and NT platforms. To encounter this problem:
1) Customers must have the 3494SHARED YES option specified in
the dsmserv.opt file.
2) Customers must be sharing the 3494 library between
multiple applications.
****************************************************************
* PROBLEM DESCRIPTION: *
TSM 3.7.3.0 does not poll a drive indefinitely when the
3494SHARED YES option is specified in the dsmserv.opt file,
and there is another application's volume loaded in the
drive. The TSM server polls the drive for 10 minutes and
then marks it off-line if the other application is still
using the drive.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM 3.7.3.0 will poll a drive indefinitely when the
3494SHARED YES option is specified in the dsmserv.opt file,
and there is another application's volume loaded in the
drive.
The TSM server will poll the drive for 10 minutes when it
cannot communicate with the 3494 Library Manager or the
drive is unavailable to the Library Manager. The server
will mark the drive off-line if it still cannot communicate
with the 3494 Library Manager or the drive is still
unavailable to the Library Manager.
------
APAR: IC26995 COMPID: 5697TSMAX REL: 110
ABSTRACT: TSM 3.7.3.0 SERVER DOES NOT ALLOW THE USER TO UPDATE OR DELETE A
PROBLEM DESCRIPTION:
The TSM 3.7.3.0 Server will poll a shared tape drive if it
believes that there is a cartridge loaded in the specified drive
that is in use by another application. If the TSM Server marks
the drive off-line, after polling the drive for a period of
time, the user cannot update or delete the drive until the
TSM Server is recycled. This problem only exists in the 3.7.3.0
Server code.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using TSM 3.7.3.0 on the AIX, HP, SUN and NT
platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
When the server believes there is a cartridge loaded in the
drive, TSM 3.7.3.0 does not allow a user to update a drive
via the UPDATE DRIVE commmand with the ONLINE option,
or to delete a drive that is off-line via the DELETE DRIVE
command.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM 3.7.3.0 allows a user to delete a drive that is off-line
via the DELETE DRIVE command.
TSM 3.7.3.0 allows a user to update a drive via
the 'UPDATE DRIVE' command with the 'ONLINE' option
under the following conditions:
1) The 'ONLINE' is the only option specified in the command.
2) The 'ONLINE' together with the 'CLEANFREQ' option are
specified in the command.
NOTE: The server will fail the UPDATE DRIVE command if the
user specifies any other combination of the options.
------
APAR: IC27032 COMPID: 5697TSMAX REL: 110
ABSTRACT: TIVOLI CONSOLE REPORTS TSM SERVER NAMES IN LOWERCASE REGARDLESS
PROBLEM DESCRIPTION:
TSM server names appear in the Tivoli event console as lowercase
despite being set in the HOSTNAME environment variable and
dsmserv.opt 'setservername' options as uppercase.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of Tivoli Storage Manager 3.7.0 and above who use
event logging to the Tivoli Event Console.
****************************************************************
* PROBLEM DESCRIPTION: *
Tivoli Storage Manager changed the hostname of the host on which
it was running to lower case when sending events to the Tivoli
Event Console.
****************************************************************
* RECOMMENDATION: *
Apply the appropriate PTF.
****************************************************************
PROBLEM CONCLUSION:
Tivoli Storage Manager has been to changed leave the hostname
as is.
------
APAR: IC27039 COMPID: 5697TSMAX REL: 110
ABSTRACT: ISSUING THE "SELECT MIGR_SECONDS FROM STGPOOLS" STATEMENT WILL
PROBLEM DESCRIPTION:
Issuing the following SELECT statement will cause the TSM Server
to abend:
SELECT MIGR_SECONDS FROM STGPOOLS
The problem only occurs if there are copy stgpools defined on
the Server, apparently because copy stgpools cannot migrate data
and do not contain a value for this field.
This problem has been recreated on TSM 3.7.x Servers running on
AIX and Windows NT.
LOCAL FIX:
Look at the ouptut from 'QUERY STGPOOL F=D' or 'SELECT * FROM
STGPOOLS' to obtain this information.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This effects users of Tivoli Storage Manager 3.7.X.X on all
platforms (AIX, NT, SUN, HP, MVS).
****************************************************************
* PROBLEM DESCRIPTION: *
Issuing the command SELECT MIGR_SECONDS FROM STGPOOLS causes the
server to abend if a copy storage pool is defined.
****************************************************************
* RECOMMENDATION: *
Install PTF when available.
****************************************************************
The problem with entering the command SELEC MIGR_SECONDS FROM
STGPOOLS causing the server to abend is fixed. Install the
latest PTF to correct the problem.
------
APAR: IC27050 COMPID: 5697TSMAX REL: 110
ABSTRACT: SERVER STARTUP MIGRATION PROCESS CAN FAIL WITH CORE IF AN
PROBLEM DESCRIPTION:
Symptom: Well starting the server:
ANR9999D Mutex release failure, errno=1; thread 30
(tid 0). ANR7838S Server operation terminated.
0x1000A784 TrapSyncError
0x1000AD50 pkReleaseMutex
0x1037643C DfMigrationAgent
0x1000BDC8 StartThread
0xD041335C _pthread_body
ANR7833S Server thread 1 terminated in response to program abort
....
ANR7833S Server thread 72 terminated in response to program abor
IOT/Abort trap
Core trace back reads:
IOT/Abort trap in pthread_kill at 0xd041ff9c ($t84)
0xd041ff9c (pthread_kill+0x250) 2c040000 cmpi cr0,0x0,r4
(dbx) where
pthread_kill(??, ??) at 0xd041ff9c
_sigsetmask(0x356f3, 0x3607b010, 0x300b6240, 0x0, 0x361195a8, 0x
(dbx) registers
$r0:0xffffffff $stkp:0x3607acc0 $toc:0xffffffff $r3:0x00
$r4:0xffffffff $r5:0xffffffff $r6:0xffffffff $r7:0xff
$r8:0xffffffff $r9:0xffffffff $r10:0xffffffff $r11:0xff
$r12:0xffffffff $r13:0x0fa0002e $r14:0x000355ed $r15:0x0f
$r16:0x0003561c $r17:0x0fa20045 $r18:0x0003564d $r19:0x0f
$r20:0x00035693 $r21:0x0fa40030 $r22:0x000356c2 $r23:0x0f
$r24:0x000356f3 $r25:0x00000000 $r26:0xf006eed0 $r27:0x36
$r28:0x000000f0 $r29:0xf006ede0 $r30:0x00001e54 $r31:0x00
$iar:0xd041ff9c $msr:0x0000d032 $cr:0x2a00442a $link:0xfff
$ctr:0xffffffff $xer:0xffffffff
Condition status = 0:e 1:le 4:g 5:g 6:e 7:le
[unset $noflregs to view floating point registers]
in pthread_kill at 0xd041ff9c ($t84)
0xd041ff9c (pthread_kill+0x250) 2c040000 cmpi cr0,0x0,r4
Problem has been traced to dfmigr.c where pkReleaseMutex fails
to check to see if it is holding a mutex prior to attempting to
release it.
LOCAL FIX:
Disable migration checking durring server startup. Remove the
offending entry in the Df.Clusters table.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM users.
****************************************************************
* PROBLEM DESCRIPTION: *
TSM server can crash after ANR9999D Error obtaining attributes
for pool because of trying to release a mutex that is not held.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Fixed problem of mutex not being held.
------
APAR: IC27060 COMPID: 5697TSMAX REL: 110
ABSTRACT: UPGRADING THE TSM SERVER TO 3.7.3.0 MAY CAUSE THE TSM SERVER TO
PROBLEM DESCRIPTION:
In some cases, upgrading the TSM server on AIX (other OS's may
also have issues, but none are reported) from 3.7.* to 3.7.3.0
may hang in the upgrade process. The hang initially occurs
during the install process where the TSM server is being started
for the purposes of upgrading the DB and updating the WenAdmin.
However, if the TSM server is started in the forground, it
will be seen that the server startup is hung in the mount of the
recovery logs.
The message it hangs on is:
ANR0306I Recovery log volume mount in progress
Initial tracing of dbtxn, dblog and lvm showed the following:
<0>lvmckpt.c(1149): DB LP table checkpointed into 4 page(s) on d
/dbaa1dk15/db for CkptNum=234955.
<0>lvmckpt.c(1149): LOG LP table checkpointed into 1 page(s) on
/dbaa1dk15/db for CkptNum=234955.
<0>lvmckpt.c(1149): LOG2 LP table checkpointed into 1 page(s) on
/dbaa1dk15/db for CkptNum=234955.
<0>lvmckpt.c(354): Checkpoint 234955 written to 6 of 6 disks.
<0>lvmckpt.c(579): Disk definition file rewritten to file 'dsmse
<0>lvmread.c(263): Read mode set to VERIFY for LOG logical volum
<0>lvmwrite.c(308): Write mode set to PARALLEL for LOG logical v
olu **The trace ends here**
It was determined that the recovery log was not corrupt, but
that a TSM was scanning the log incorrectly causing the restart
to fail.
LOCAL FIX:
Development has identified the algorithm which is causing the
issue and a testfix is forthcoming. Otherwise, the customer
must regress the TSM server to its previous level to restartit.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM 3.7.3 users.
****************************************************************
* PROBLEM DESCRIPTION: *
When the server is started, the consistency checks performed
on the log are incorrect and may lead to a hang condition or
erroneous reports of log corruption, resulting in the log
being needlessly truncated.
****************************************************************
* RECOMMENDATION: *
Apply the applicable PTF when available.
****************************************************************
PROBLEM CONCLUSION:
The server is changed to perform correct consistency checks
in the log during startup.
------
APAR: IC27072 COMPID: 5697TSMAX REL: 110
ABSTRACT: ISSUING THE 'CHECKOUT LIBVOLUME' COMMAND WITH THE CAP PARAMETER
PROBLEM DESCRIPTION:
When issuing the CHECKOUT LIBVOLUME command against an ACSLS
library, specifying the CAP parameter can cause the TSM Server
to abend. The CAP parameter allows the TSM administrator to
specify which EEPort to eject volumes to.
This problem only exists in the TSM 3.7.2 & 3.7.3 Server code.
LOCAL FIX:
Do not include the CAP option when checking volumes out of the
ACSLS library.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
TSM 3.7.2.0 and 3.7.3.0 customers on the AIX, SUN and NT
platforms with ACSLS libraries.
****************************************************************
* PROBLEM DESCRIPTION: *
The TSM server may abend if the CAP parameter is specified
in the CHECKOUT LIBVOLUME command.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The TSM server correctly handles the CAP parameter in the
CHECKOUT LIBVOLUME command.
------
APAR: IC27097 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANS4035E ERROR DOES NOT INDICATE THAT FILES ARE UNAVAILABLE
PROBLEM DESCRIPTION:
When a restore fails due to files needed for the restore
residing on volumes which have been set to an access of
'destroyed' the error messages in the activity log do not
reflect this.
ANR9999D smnqr.c(1265): Bitfile 2635875 not found for retrieval.
ANR0540W Retrieve or restore failed for session 112 for
node GREG (AIX) - data integrity errordetected.
ANE4035W (Session: 112, Node: GREG) Error processing
'/home/greg/dsm.opt': file currently unavailable on server
Identifying the volume(s) required for the restore and the
specific reason the file is unavailable on the server would
be helpful in determining the exact cause of failure and what
needs to be done to allow a successful restore.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
all TSM server users
****************************************************************
* PROBLEM DESCRIPTION: *
destroyed volumes are not indicated during restore
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available
****************************************************************
A client attempts to restore all files in a (sub)directory,
which results in a no query restore request to the server.
If a file is on a sequential volume that is destroyed, the
server reports that the file was not restored, but it doesn't
report the volume that is in error (random access volumes are
reported). This information would be useful to customers.
PROBLEM CONCLUSION:
Messages anr1420, 22 and 24 are now issued when a sequential
volume is damaged, unavailable or offsite. The messages will
appear during classic restore, no query restore and retrieve.
Note that apar IY01570 has changed the behavior of no query
restore to restore as many files as are found on "good"
volumes, and skip those on bad volumes. This apar was
available from TSM V3.7, and was not available to the ADSM
3.1.2 server.
------
APAR: IC27123 COMPID: 5697TSMAX REL: 110
ABSTRACT: BACKUPSETS DON'T EXPIRE PROPERLY
PROBLEM DESCRIPTION:
1) Generated backupset, using GENERATE BACKUPSET <nodename>
<backupsetname> <filespacename> RET=1
2) Changed the date on the server to reflect 2 days later than
the currnet date
3) Cycled the AIX server, then brought the ADSM server back up.
date reflects today+2.
4) Issued expire inventory from ADSM command line.
5) Issued query backupset. The backupset is still there,issued
q volhist type=backupset. The volume was still there. There is
no evidence the backupset was expired.
6)issue delete backupset <nodename> <backupsetname> Received mes
sage stating backupset was deleted
7)Issue query backupset, the backupset is gone. Issued query vol
the volume is now scratch.
|
Deleting backupsets works, it appears normal expiration doesn't.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Tivoli Storage Manager 3.7 & 4.1 server users who create
backupsets with finite retention periods
****************************************************************
* PROBLEM DESCRIPTION: *
Backupsets with finite retention periods do not
expire.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF. Alternatively,
backup sets may be deleted with delete backupset
command.
****************************************************************
Backupset with finite retention periods do not expire.
Server logic has been fixed to ensure that they expire.
PROBLEM CONCLUSION:
Certain code did not check for objects which might
have been backupsets. That has been corrected.
TEMPORARY FIX:
Use the Delete Backupset command to delete backupsets
manually.
------
APAR: IC27126 COMPID: 5697TSMAX REL: 110
ABSTRACT: THE EXPORT NODE COMMAND WILL CAUSE THE SERVER TO ABEND IF A
PROBLEM DESCRIPTION:
The EXPORT NODE command will cause the TSM Server to abend if a
filedata type of ARCHIVE or SPACEMANAGED is specified. The
command completes successfully with any of the remaining
filedata types are specified. The traceback from the core dump
may resemble the following:
IOT/Abort trap in signal.pthread_kill [/usr/lib/libpthreads.a
0xd0234df4 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1)
(dbx) where
signal.pthread_kill(??, ??) at 0xd0234df4
signal._p_raise(??) at 0xd02343ac
fgets(??, ??, ??) at 0xd0013bac
realloc_y(??, ??, ??) at 0xd000d330
TrapHandler(??, ??, ??) at 0x1000ccec
pkAbort(??) at 0x1000e9a4
pkLogicAbort(??, ??, ??, ??) at 0x1000e65c
tbDestroyTemp(??) at 0x10084bac
SortProcessKeys(??, ??, ??, ??) at 0x102e3ea0
BuildSortTable(??, ??) at 0x102e4e58
imExportObjects(??) at 0x102e7a6c
SmQryExportObjects(??, ??, ??) at 0x102eb2d0
DoExportImportVerbs(??, ??, ??, ??, ??, ??) at 0x103381a4
SmAdminSession(??) at 0x10338f94
DoAdminGeneral(??) at 0x102df6d4
smExecuteSession(??, ??, ??, ??, ??, ??, ??, ??) at 0x102e292
XiSessionThread(??) at 0x103016f4
StartThread(??) at 0x1000cd9c
pthread._pthread_body(??) at 0xd0229340
This behavior has been re-created on AIX and NT Servers running
the TSM 3.7.3 Server code.
LOCAL FIX:
Use FILEDATA=ALL to export any archived and/or space managed
data for a given node.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM version 3.7 platforms
****************************************************************
* PROBLEM DESCRIPTION: *
The EXPORT NODE command will cause the TSM Server to abend if a
filedata type of ARCHIVE or SPACEMANAGED is specified. The
command completes successfully with any of the remaining
filedata types are specified.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available
****************************************************************
On Export, the TSM Server is not handling Filedata types of
Archive and SpaceManaged correctly.
PROBLEM CONCLUSION:
The Export Node function is corrected to handle the Archive
and Spacemanaged filedata types correctly.
TEMPORARY FIX:
To Export Archive or Spacemanaged data user could set
FILEDATA=ALL, then on import specify Archive or spacemanaged
------
APAR: IC27154 COMPID: 5697TSMAX REL: 110
ABSTRACT: 3.7.3 SERVERS WILL NOT CHANGE THE STATUS OF A DRIVE FROM LOADED
PROBLEM DESCRIPTION:
3.7.3 Servers fail to change the drive status from Loaded to
Empty after a clean drive operation completes.
LOCAL FIX:
Restart the TSM server to clear the drive status.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
1) TSM 3.7.3.0 customers on the AIX, HP, SUN and NT platforms.
2) Issue the CLEAN DRIVE command or use TSM's drive cleaning
feature.
****************************************************************
* PROBLEM DESCRIPTION: *
TSM 3.7.3.0 does not change its state of the drive to empty
after the drive cleaning completes. TSM tracks the state of
a drive as it uses that drive for a tape operation. Because
the state of the drive indicates the drive is still in use,
TSM does not select that drive for another tape operation.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM 3.7.3.0 changes the state of the drive to empty
after the drive cleaning completes.
------
APAR: IC27235 COMPID: 5697TSMAX REL: 110
ABSTRACT: GENERATE BACKUPSET MAY CAUSE THE TSM SERVER TO CORE DUMP
PROBLEM DESCRIPTION:
The TSM server can core dump when a Generate Backupset is
performed for a node and more than 20 filespaces are processed.
The default for filespaces in the Generate Backupset command is
all of the client node filespaces. A client node may have data
stored on the TSM server for 10 filespaces, but have 20
additional filespaces which do not get backed up - a Query File-
space will show 30 filespaces for this node. Performing a
Generate Backupset without specifying the filespaces will result
in 30 filespaces being processed and may result in a core dump.
This behavior has been observed on the TSM 3.7.3.0 server code.
LOCAL FIX:
Limit the number of filespaces to 20 or less when performing a
Generate Backupset command.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Users for the Tivoli Storage Manager Version 3.7 server.
****************************************************************
* PROBLEM DESCRIPTION: *
While running the GENERATE BACKUPSET command the server may
crash or have unpredicatable results.
Typically, this occurs just after the first OUTPUT volume
is mounted while the server process is initializing the
tape volume.
****************************************************************
* RECOMMENDATION: *
Please apply the ptf containing this fix once it is available.
****************************************************************
The server GENERATE BACKUPSET algorithm was incorrect. There
was an error in how it handled the filespaces being processed
for the command. If there were more than 20 filespaces
to process, during the initialization of the first output
volume the server could crash because the algorithm was
not managing an in memory list of filespace information
appropriately.
PROBLEM CONCLUSION:
The server GENERATE BACKUPSET command was not processing
correctly when more than 20 filespaces needed to be
supported.
TEMPORARY FIX:
To prevent this from occurring UNTIL the ptf containing this
fix is available, do not generate a backupset that requires
more than 20 filespaces to be processed. This can be
accomplished by specifying 20 or fewer filespaces on the
GENERATE BACKUPSET command.
------
APAR: IC27297 COMPID: 5697TSMAX REL: 110
ABSTRACT: WELL RUNNING SQL SELECT QUERY TSM SERVER CAN ABEND WITH
PROBLEM DESCRIPTION:
sql select statements may fail to send "end marker" to
SmAdminOutput (smadmin.c) resulting in a abend with internal
error SMADMIN001.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This APAR effects all platforms (NT, AIX, HP, SUN, MVS) of the
Tivoli Storage Managment Server version 3.7.X.X and higher
(4.1.0.0)
****************************************************************
* PROBLEM DESCRIPTION: *
The problem is that the server abort when an admin session
recieves bad data on a private stream. This results
in the server aborting with abort message containing the word
SMADMIN001.
****************************************************************
* RECOMMENDATION: *
Install PTF when available.
****************************************************************
What this all boils down to is that the server aborts with an
error message with the word SMADMIN001 at the end of the message
This error can occur for many reasons, but it is mainly occurs
because something was passed into the admin session's private
stream that should not have been passed in. Instead of dumping
the entire server, the code will abort the command with an
error message to the Admin session (mainly the admin client)
stating some internal error happened on the server. The client
will respond with a ROLLBACK to undo any action that the command
may have done. The server will recover and wait for the next
command issued by the client. This is only a temporary problem
that is resolved when the command completes executing.
------
APAR: IC27336 COMPID: 5639B1700 REL: 550
ABSTRACT: USING BNM/2 SOCKET SERVICE, PACKETS ARE DROPPED BY THE ROUTER
PROBLEM DESCRIPTION:
Using a new developed BNM/2 socket service the
following problem occurs:
The BNM/2-Server with the socket server BNMTCPIP is located in
LAN 1. The ATMs with the client-software are located in LAN 2
Lan 1 and LAN 2 are connected with routers and a 64Kb/s line.
The capacity of the router connection isused by ftp and
Netbios-traffic. Packets are dropped by the router. To test the
correct recovery behavior the service BNMTCPIP is
closed. The ATMs are offline. Starting the service BNMTCPIP we
expect every ATM to connect within 3 to 5 minutes. In all cases
only 2 or 3 ATM connect in this time. The last
of 11 ATMs connect after 90 minutes.
netstat -l log file shows the value for OVER QUEUED is
increasing strong.
PROBLEM SUMMARY:
USING BNM/2 SOCKET SERVICE, PACKETS ARE DROPPE
d,THE VALUE FOR OVERQUEUED INCREASES
PROBLEM CONCLUSION:
Provided the modified sockets.sys
TEMPORARY FIX:
Provided the new stack package
------
APAR: IC27348 COMPID: 5697TSMAX REL: 110
ABSTRACT: USING DEVCLASS OF "GENERICTAPE" IN TSM 3.7.3 SERVER,APPENDING TO
PROBLEM DESCRIPTION:
Customer using "generictape" device type on the TSM 3.7.3
server will receive an ANR8311E w/ errno = 5 on UNIX and
A variation on NT.
The error condition occurs only when a tape previously written
to once and is rewound/dismounted. When the tape is called to
append any data to it, the operation fails.
The following is the Actlog error message and a portion of
the server trace capturing the error:
07/07/00 15:15:06
ANR8337I GENERICTAPE volume 700000 mounted in drive
LIB9840 (/dev/rmt0).
ANR8311E An I/O error occurred while accessing drive
LIB9840 (/dev/rmt0) for READ operation, errno = 5.
ANR1411W Access mode for volume 700000 now set to
"read-only" due to write error.
pvr.c(6105): PVR I/O agent (37) finished OPEN request; rc=0.
pvr.c(5642): PVR I/O agent (37) waiting for next request.
pvr.c(5663): PVR I/O agent (37) processing POS request.
pvrgts.c(787): Positioning tape volume 700000 to 8011.16.
pvrgts.c(3900): Positioning from block 0 to block 8011.
pstapiop.c(165): PvrPsTape entered with handle 16 op 17
count 8011 block 0
pstapiop.c(248): PvrPsTape FSR 8011
pvr.c(6105): PVR I/O agent (37) finished POS request; rc=0.
pvr.c(5642): PVR I/O agent (37) waiting for next request.
pvr.c(5663): PVR I/O agent (37) processing SEEKAPPENDPOS request
pvrgts.c(1824): Seeking append position for tape volume
700000 from 8011.16.
pstapiop.c(399): PvrPsErr entered, op=R, errno=5
pstapiop.c(404): PvrPsErr entered, errno=5, flags=0,0,
bytes=262144, read/written=0
pstapiop.c(453): PvrPsErr AIX errno = 5, server rc = 1
pvr.c(6105): PVR I/O agent (37) finished SEEKAPPENDPOS
request; rc=30.
pvr.c(5642): PVR I/O agent (37) waiting for next request.
pvr.c(1545): Closing volume "700000", mp=0, reuse=1, devClass=3.
pvr.c(5663): PVR I/O agent (37) processing PREPARECLOSE request.
pvrgts.c(1592): Preparing to close volume 700000; logging 0 kbyt
pvr.c(6105): PVR I/O agent (37) finished PREPARECLOSE request; r
................
In NT, the error value is 1104 instead of "errno=5".
This is translated to
"ERROR_NO_DATA_DETECTED - No more data is on the tape"
.........
In limited testing, the failure could not be recreated on 3.7.2
server code
LOCAL FIX:
1. Do not use generictape if possible
2. Use TSM 3.7.2 instead
3. Wait for fix
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using generictape device classes on the following
servers.
TSM 3.7.3 and 4.1.0 AIX and HP
TSM 3.7.3 NT
****************************************************************
* PROBLEM DESCRIPTION: *
When using a generic tape device class appending to tapes
fails with errno=5 on HP and AIX, and rc=1104 on NT.
This only occurs if the tape is dismounted before it is
appended to.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
Better detected the state of the drive when appending to
volumes.
------
APAR: IC27364 COMPID: 5697TSMAX REL: 110
ABSTRACT: EXCLAMATION MARK CHARACTER '|' TRANSFERED TO SERVER AS SPACE ' '
PROBLEM DESCRIPTION:
Problem is reported with special character exclamation mark '|'
contained in the pathname of files to be backed up. When doing a
define or update schedule from web admin, this pathname is
entered in the field 'objects':
Objects: d: mydata |temp *
Server receives the command option as
objects=d: mydata temp *
Apparently the '|' character is replaced by a space (or some hex
code which displays as such). The problem seems to affect all
fields (not only 'objects'), incl. the command line of the web
admin. So all entry panels of the web admin probably have the
same behavior.
Server platforms I used: NT 4 (3.7.1) and AIX (3.7.3)
Browser I used: Netscape 4.7 on NT
LOCAL FIX:
Use the command line admin to work with objects (directories and
files) containing such characters.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This apar effect all users of Tivoli Storage Manager version
3.7.X.X and 4.1.0.0 on NT, SUN, AIX, HP, and MVS.
****************************************************************
* PROBLEM DESCRIPTION: *
The web administrator interface does not accept the ! mark of
as part of input to any parameter where the character is valid.
For example, when defining a client schedule the client object
to be backed up is c:\!TEMP!. This results in the client object
being set for this schedule as c:\ TEMP .
****************************************************************
* RECOMMENDATION: *
Install PTF when available.
****************************************************************
The web administrator interface now accepts the ! mark as a
valid character in any input text box. The server will not
replace it a space and correct issue the command against the
TSM server.
------
APAR: IC27402 COMPID: 5697TSMAX REL: 110
ABSTRACT: ONLY 1 SIDE IS BEING UTILIZED ON WORM AND OPTICAL PLATTERS
PROBLEM DESCRIPTION:
Customer reported that since upgrading from 3.1.2.40 to
3.7.0.0 then 3.7.3.0 they are unable to use both sides of
the optical platters and therefore their storage is cut in
half.
The customer was able to recreate the problem but could not
trace the issue,
However, the problem was recreated in the lab by the device
development team and was able to determine that the problem
lies in a change made to the PVR code.
If the platters were written to before upgrading to 3.7, they
show in "q libv" as having 2 sides and the data is accessable.
However, all new volumes will only report having 1 side and
all volumes returned to scratch will also only use one side,
If "label libv" was used to label the optical or worm platters
when at 3.7, the platters need to be relabelled when the fix
is provided.
Platters labelled with "dsmlabel" will not have this problem.
Once fix is applied, both sides will only be used whe the
volume is returned to scratch and reused.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
TSM 3.7.3 and 4.1 customers using two-sided OPTICAL and WORM
media on AIX, SUN, and NT platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
TSM 3.7.3.0 server does not correctly detect an OPTICAL or
WORM media as two-sided when mounting a scratch platter.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM server detects when an OPTICAL or WORM media is two-sided.
For OPTICAL or WORM media introduced into the storage pool
since upgrading to TSM 3.7.3.0, TSM will only use one side of
the media.
For OPTICAL media, the customer can after applying the fix
peform the following steps:
1) Move the data to other OPTICAL media.
2) Relabel the OPTICAL media after it is returned to SCRATCH.
The next time the OPTICAL media is selected TSM will use
both sides of the platter.
If the customer used the DSMLABEL utility to label the
OPTICAL platters, there is no other action required.
If the customer does not remember or used the LABEL LIBVOLUME
command, the customer should re-label all OPTICAL platters
in the SCRATCH status.
------
APAR: IC27423 COMPID: 5697TSMAX REL: 110
ABSTRACT: MOUNT WINDOW TERMINATES IF YOU MOUNT AN INCORRECT TAPE IN THE
PROBLEM DESCRIPTION:
If a mount window is started (dsmadmc -mount) and you mount
an incorrect volume into the drive, the mount window terminates
with
ANR9999D smmcons.c(295): Received type 05 message
from mount output for mount console session 3 -
session will be closed.
This has been tested on the 3.7.2.01 admin client.
LOCAL FIX:
Make sure to mount the correct tape.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V3 and Tivoli Storage Manager servers using
mount consoles and event server logging.
****************************************************************
* PROBLEM DESCRIPTION: *
If an incorrect tape is mounted in response to a call
for scratch, an event is being sent to mount consoles
which they are unprepared for. The console sessions
are terminated.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF when available.
****************************************************************
Mount consoles are fixed to not terminate
when an event arrives.
PROBLEM CONCLUSION:
Mount consoles will not be terminated when an incorrect
volume is mounted.
------
APAR: IC27435 COMPID: 5697TSMAX REL: 110
ABSTRACT: TSM SERVER CRASHES WITH DR. WATSON ERROR, EXCEPTION:ACCESS
PROBLEM DESCRIPTION:
Tivoli Storage Manager 3.7.2 and 3.7.3 Server crashes with Dr.
Watson error messages. The contents of the pop up message are:
Exception:access violation(0xc0000005), Address:0x1033190c
Additional address locations(based on server level) are 10138ccc
and 10152d30. Server crashes and must be restarted. Messages
are also reported to the Dr. Watson Log, and the NT Event Viewer
The call stack from the dump shows the following:
0x0298ab1c 0x101e8795 ADSMDLL!tbFetchNext+0x30c(0x0590ADB8)
0x0298c440 0x101c9951 ADSMDLL!ImIsArchDirReferenced+0x405(0x0600
0x0298ea04 0x101e2184 ADSMDLL!ImDeleteObjectFast+0x531(0x0600A9D
0x0298ff44 0x1000608a ADSMDLL!DeleteFilesThread+0x3e4(0x00137590
0x059aafe0 0x000000ac ADSMDLL!startThread+0x6a(0x00000022)
Additional Symptoms:
This can also result in either a BUF006 or a
LATCH002 assertion failure. For either one of
these two failures an inventory expiration will
be running with DeleteFilesThread calling
ImDeleteObjectFast calling ImIsArchDirReferenced
which calls tbFetchNext. The thread getting the
BUF006 or the LATCH002 assertion might not be this
thread, but the thread getting getting the
asertion will be operating on the same table that
this thread is operating on.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V312 and TSM V37 server users
****************************************************************
* PROBLEM DESCRIPTION: *
The server may encounter a segmentation violation or server
crash during expiration.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing this fix once it is available.
****************************************************************
The server expiration algorithm could in some cases cause the
server to crash with a segmentation violation. There error
was that a memory structure used by expiration to track
information about the server database was not managed
correctly. This could result in the server crash when
that memory structure was evaluated.
PROBLEM CONCLUSION:
The server expiration algorithm has been altered to correct
the management/handling of the in-memory structure.
------
APAR: IC27473 COMPID: 5639B2201 REL: 310
ABSTRACT: ISSUING THE UPDATE DRIVE COMMAND WITHOUT SPECIFYING THE DEVICE
PROBLEM DESCRIPTION:
Issuing the UPDATE DRIVE command without specifying the device
name in the command, could cause the 3494 library manager to
lose the information for this drive. As a result, any
subsequent attempts by the TSM Server to access this drive may
fail with the following errors:
ANR8301E I/O error on library 3494 (OP=005C6D37, SENSE=N/A,
CC=00000023).
ANR8848W Drive DRIVE1 of library 3494 is inaccessible; server
has begun polling drive.
The 3494 library manager assigns a device number to each drive
and issuing the UPDATE DRIVE command without specifying the
device name for that drive (i.e. device=/dev/rmt1) may cause the
the existing device number assigned to that drive by the 3494 to
be modified or deleted. The completion code of 23 in the error
message above indicates that the device does not exist in the
library. In order to recover from this condition the user must
delete and redefine the drive to TSM, or recycle the TSM Server.
This problem exists in the 3.1.x and 3.7.x Server code, but only
affects drives in a 3494 library.
LOCAL FIX:
Include the device parameter when issuing the UPDATE DRIVE
command.
Correct syntax:
UPDATE DRIVE 3494LIB DRIVE1 device=/dev/rmt1 ONLINE=YES
Incorrect syntax:
UPDATE DRIVE 3494LIB DRIVE1 ONLINE=YES
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM 3.1.2.X and TSM 3.7X customers on the AIX, HP, SUN and
NT platforms using 3494 libraries.
****************************************************************
* PROBLEM DESCRIPTION: *
After an UPDATE DRIVE command without the DEVICE parameter,
the TSM server looses the device number for the given drive.
The TSM server needs that device number to specify the
drive when communicating to the 3494 Library Manager.
The TSM server may abend when attempting to communicate to the
3494 Library Manager to perform a mount/demount activity or to
obtain information about the given drive. Otherwise, there
may be I/O errors in the activity log; that is, ANR8301E
messages with a completion code of 0x023.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The TSM server maintains the correct device number for
the given drive after an UPDATE DRIVE command whether
or not the DEVICE parameter was specified.
TEMPORARY FIX:
Until the fix is available:
1) Include the DEVICE parameter in the UPDATE DRIVE command.
2) Delete and then re-define the drive to TSM.
------
APAR: IC27497 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANR9999D AFMIGR.C(2805): ERROR DELETING TRANSACTION FOR 0 BYTES
PROBLEM DESCRIPTION:
During reclamation of copy storage pool volume using ADSM/TSM
server to server virtual volumes ANR9999D afmigr.c(2805): Error
deleting transaction for 0 bytes reclamation is received. The
problem appears to occur against a newly defined virtual
volume that was to be used as the output for a full virtual
copy storage pool volume being reclaimed. However this new
output volume was really never used because the needed primary
storage pool volumes were not available (checked out of the
library in this case). When this reclaim failed the newly
defined volume was not delete but left a full and 100%
reclaimable. A query content showed nothing on the volume.
This problem can and has been recreate by doing the following:
1) A copy storage pool virtual volume on the source server needs
to be reclaimed.
2) The primary storage pool volume with the data needed for the
reclaim is checked out of the library.
3) When reclamation starts a new copy storage pool volume is
created/defined on the source server and a message to checkin
the needed primary pool volume is issued.
4) If the needed primary storage pool volume is not checked in
by primary storage pool volume as unavailable, and retry in 60
seconds.
5) At this point the new copy storage pool virtual volume is
still defined as an empty volume on the source server.
6) At the 60 reclaim retry point the reclamation begins and
complete successfully this time using getting the data from the
copy storage pool and using the new volume defined in point 3 as
7) After this reclamation has completed a reclamation for this
new volume suddenly kicks off and the anr9999d from afmigr is
received.
LOCAL FIX:
Updating checked out volumes to a status of unavailable
should keep reclamation from trying to use them during
reclamation and avoid the creation of the problem virtual
volume.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All 3.1.2.x and 3.7.x servers using offsite reclaimation.
****************************************************************
* PROBLEM DESCRIPTION: *
The problem occurs when both on and off site reclaimation are
running at the sametime and both need the same volume. When
this occurs one of the reclaimations will fail with an error
reporting zero bytes moved, and on the Sun and NT platform the
server will abort.
****************************************************************
* RECOMMENDATION: *
Set on and off site storage pool reclaimation thresholds such
such that they don't run at the sametime for a short term work
around.
A fix will be available fixtest 3.1.2.58 and patch 3.7.3.20
and ptf 4.1.1.0.
****************************************************************
Reclaimation has been changed to deal with the situation where
both on and off site processing need the same input volume.
PROBLEM CONCLUSION:
Reclaimation processing was not correctly handling the situation
where both on and off site reclaimation processes needed the
same input volume.
This situation can be avoided by adjusting reclaimation
thresholds such that on and offsite won't occur at the same
time.
------
APAR: IC27508 COMPID: 5697TSMAX REL: 110
ABSTRACT: ADSM SERVER CAN FAIL WITH CORE WHEN BACKUP STG WAIT=YES IS
PROBLEM DESCRIPTION:
It has been found that issuing backup stg wait=yes can cause a
failure in pkDestroyCondition with the following stack:
IOT/Abort trap in NLtmtime.detype [/usr/lib/libpthreads.a] at 0x
0xd0242d14 (detype+0x30) 61240000 ori r4,r9,0x0
(dbx) where
NLtmtime.detype(??, ??) at 0xd0242d14
NLstrtime.NLstrtime(??, ??) at 0xd024294c
__modinit.__loadinit(??, ??) at 0xd029fca0
AbortServer() at 0x10006288
pkAbort(??) at 0x10006f4c
TrapSyncError(??) at 0x10004b4c
pkDestroyCondition(??) at 0x10004c84
BfFreeCopyControl(??) at 0x1012c394
BfEndBackupThread(??, ??) at 0x1012bac8
AfBackupPoolThread(??) at 0x101a575c
StartThread(??) at 0x10006190
_spinlock_create(??) at 0xd0238f58
This problem was introduced at the 3.1.2.56 level.
LOCAL FIX:
Work around is to run backup stg with "wait=no"
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
The ADSM 3.1.2.56 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
The 'BACKUP STGPOOL' command with 'WAIT=YES' specified can
encounter a race condition causing the server to crash.
****************************************************************
* RECOMMENDATION: *
This will be fixed in the next official ptf for the
ADSM 3.1.2 server. If a "patch" is available referencing
this apar, then apply that patch.
****************************************************************
The BACKUP STGPOOL processing with "WAIT=YES" specified has
been altered to correct this problem and prevent the
server from crashing.
PROBLEM CONCLUSION:
The "patch" code for the fix IY03390 was not complete. There
were additional fixes needed. The problem caused a race
condition that could cause the server to crash.
Apar IY11007 was opened to document this. This problem
ONLY exists in server patch code for 3.1.2.56.
TEMPORARY FIX:
Execute the "BACKUP STGPOOL" command with "WAIT=NO".
------
APAR: IC27519 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANR7837S TBUNDO096 ANR9999D TBUNDO.C RESTORE DB UNDO PASS
PROBLEM DESCRIPTION:
During a database restore after copying all the database pages
and after performing the Sequential media log redo pass,
the restore fails with these messages from the console
ANR4642I Sequential media log undo pass in progress.
ANR9999D tbundo.c(207): Error 2 on delete from table DS.Overflow
for undo.
Note the error may occur on tables other than DS.Overflow
The dsmserv.err contains these messages.
ANR7838S Server operation terminated.
ANR7837S Internal error TBUNDO096 detected.
ADSM Development believes that this problem is caused
by high server activity during database backup.
Because of the high activity necessary recovery log
information was not written to the backup db file.
LOCAL FIX:
Early prevention would be to run database
backups when the load on the Adsm server is low.
If customer experiences this problem the only option
is to restore from an earlier database backup.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This apar affect ADSM server Version 3 users. It also affects
Tivoli Storage Manager Version 3.7 server uservs.
****************************************************************
* PROBLEM DESCRIPTION: *
During the restore of a database backup, this may sometimes
result in a TBUNDO096 server assertion. This assertion
typically reports an error "2" deleting an entry from a
given database table. This error does not always happen
against the same database table but it is always an error
code of "2" for the operation.
****************************************************************
* RECOMMENDATION: *
Please apply the ptf containing this fix once it is available.
****************************************************************
The server BACKUP DB algorithm/process can in some
circumstances not copy all the needed transaction/recovery
log information from the server onto the tape being used to
backup the database. AS a result of the transaction
inforation being missing from the database backup tape, the
server RESTORE DB algorithm may not be able to perform the
REDO and UNDO passes from the media. This results in an
inconsistent transaction state in the server database and
causes the server to assert with a TBUNDO096 assertion
error.
The restore database processing fails to complete and results
in a database that must be restored to an earlier point in
time.
PROBLEM CONCLUSION:
The server BACKUP DB process may in some cases not capture all
the needed transaction information to maintain transactional
consistency in the server database. The only way to detect
if the database backup is missing this information is to
actually RESTORE the database using the database backup and
see if a TBUNDO096 error is encountered. If it is encountered
than it is likely that this problem was encountered.
------
APAR: IC27532 COMPID: 5697TSMAX REL: 110
ABSTRACT: ABEND0C4 AUDITDB ANR4257E DELETEARCHIVE FORCEMODE=YES
PROBLEM DESCRIPTION:
AUDITDB FIX=YES fails with ABEND0C4 and error message
ANR4257E A correctable data-integrity error
The problem is imutil.c function, ImDeleteArchiveObject.
ImGetArchiveRow call fails and forcemode is set, execution
continues to the memcpy call which program checks attempting
to copy data based on information from failed
ImDeleteArchiveObject call.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Tivoli Storage Manager users for V3.7.0, 3.7.1, and 3.7.1. This
affects all server platforms for the referenced server levels.
****************************************************************
* PROBLEM DESCRIPTION: *
The server "AUDITDB" process could cause the server to
crash.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing this fix once it is available.
****************************************************************
The fix for this was available in server level V3.7.3 for the
Tivoli Storage Manager Server. Apply this ptf to resolve
this fix. The problem had been fixed as a result of another
change to this code.
PROBLEM CONCLUSION:
The server algorithm used by AUDITDB to delete archive entries
could encounter and error in processing that could cause the
server to crash. The fix for this is a available in the
3.7.3 level Tivoli Storage Manager server. The readme
for the server will be updated to reflect this the next
time a readme is issued.
------
APAR: IC27543 COMPID: 5697TSMAX REL: 110
ABSTRACT: RECLAMATION PROCESS APPEARS TO "HANG" AND WILL NOT END ON ITS OW
PROBLEM DESCRIPTION:
Reclamation process appears to "hang" and will not end on
its own. The hung process does not respond to cancel
process requests. A server bounce is necessary in order
to remove process.
During reconstruction (reclamation of aggregates) one of
the two threads (read or write) has an error while the 2nd
thread is active and working. Due to signaling discrepancies,
the working (2nd) thread does not receive the signal to
become idle and instead continues to wait for the next buffer.
LOCAL FIX:
Restart the server.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM & TSM v3 servers (3.1.0, 3.1.2, 3.7)
****************************************************************
* PROBLEM DESCRIPTION: *
During reconstruction (reclamation of aggregates), if either of
the read or write threads has an error, it is possible that the
other thread does not receive the signal to end. Symptoms: a
reclamation process starts, but does not end nor does it appear
to be moving data. The recl. process also will not respond to
a cancel process request.
****************************************************************
* RECOMMENDATION: *
Apply Fix when available.
****************************************************************
Reclamation hangs and is not cancellable. A server restart is
required to remove the process.
PROBLEM CONCLUSION:
Problem was resolved by adding a state check of the other thread
(either read or write) involved in the reclamation process.
This check prevents the first thread from waiting indefinitely.
------
APAR: IC27552 COMPID: 5697TSMAX REL: 110
ABSTRACT: SECURE WEB PROXY FAILS ON HP WITH INTERNAL SERVER ERROR
PROBLEM DESCRIPTION:
DSMPROXY fails when installed on HP. Error message
is "Premature end of script headers" when using
Apache and clicking on the tree expansion link
adjacent to "Network object". Customer found the
problem using Netscape Fasttrack which would core
dump when the error occurred.Test environment was
HP-UX11 and would give the error when contacting
a TSM server in any environment.
LOCAL FIX:
No fix available for the proxy running on HP, but it does
run normally on the other platforms it supports.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This APAR effect all users of the Secure Web Administrator
Proxy on NT, AIX, HP, and SUN.
****************************************************************
* PROBLEM DESCRIPTION: *
The reported problem is that the web proxy abends when a
a request for an item in the Web administrator interface
object tree is expanded (e.g. Expand the Network View). As it
turns out this problem can occur on any requested web page
being proxied from the Tivoil Storage Manager server.
****************************************************************
* RECOMMENDATION: *
Re-install (uninstall the old and install the new package) the
Secure Web Administrator Interface when package is available.
****************************************************************
The problem of dsmproxy abend has been fixed. Install the
latest version to fix the problem.
------
APAR: IC27598 COMPID: 5697TSMAX REL: 110
ABSTRACT: 3.7.3.3 FIXTEST ABENDS WHEN DELETE VOLUME OR SPACE RECLAMATION
PROBLEM DESCRIPTION:
TSM 3.7.3.3 on Solaris abends whenever ssDeleteVolume is
called.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of ADSM servers 3.1.2.50
****************************************************************
* PROBLEM DESCRIPTION: *
Server abends if an aggregate alias is deleted during
reclamation processing.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
Adsm server now accounts for the deletion of aggregates
aliases during reclamation processing.
------
APAR: IC27629 COMPID: 5697TSMAX REL: 110
ABSTRACT: SERVER WITH TWO LIBRARIES WILL OCCASIONALLY HANG OR CRASH WITH
PROBLEM DESCRIPTION:
With multiple ACSLS libraries configured on an ADSM server
library calls may hang with the following messages observed:
ANR8856E ACSAPI sequence(584) request(0) timed out, elapsed
time=##:##:##
ANR8855E ACSAPI(acs_query_drive) response with
unsuccessful status, status=STATUS_IPC_FAILURE
ANR8855E ACSAPI(acs_dismount) response with unsuccessful
status, status=STATUS_IPC_FAILURE
When in hang status the customer may experience a core dump,
tracebacks on the core dump show a failure in the acs_api
IOT/Abort trap in pthread_kill at 0xd0351cf4 ($t7931)
0xd0351cf4 (pthread_kill+0x130) 30810038 ai r4,r1,0x38
(dbx) pthread_kill(??, ??) at 0xd0351cf4
signal.raise(??) at 0xd035192c
abort.abort() at 0xd0250c98
AbortServer() at 0x10006248
TrapHandler(??, ??, ??) at 0x10005f5c
cl_qm_create(??, ??, ??, ??) at 0x104bad50
cl_qm_mcreate(??, ??, ??, ??) at 0x104ba968
write_q_add(??, ??, ??, ??) at 0x104ba140
cl_ipc_send(??, ??, ??, ??) at 0x104ba454
cl_ipc_write(??, ??, ??) at 0x104c34d0
acs_ipc_write(??, ??) at 0x104c326c
acs_send_request(??, ??) at 0x104c1e18
acs_query_drive(??, ??, ??) at 0x104c4744
Acsls_query_drv(??, ??, ??, ??, ??, ??) at 0x104b8484
AcslsSetLibDevice(??, ??, ??) at 0x104b2ffc
MmsLtsSetLibDevice(??, ??, ??, ??) at 0x10097600
DriveIsAvailable(??) at 0x10086cc0
MmsCheckAvailableDrives(??, ??, ??) at 0x1008c2c8
PvrStealIdleMp(??) at 0x1007f3a0
pvrOpen(??, ??, ??, ??, ??, ??, ??, ??) at 0x1009e934
OpenActiveVol(??, ??, ??) at 0x101502a8
AsOpenVol(??, ??, ??) at 0x10151054
AsAcquireInputVol(??, ??, ??, ??, ??) at 0x1014ea7c
AsOpenSeg(??, ??, ??, ??, ??, ??, ??) at 0x10251774
DoOpenSeg(??, ??, ??, ??, ??, ??, ??) at 0x10244324
ssCopy(??, ??, ??, ??, ??, ??, ??, ??) at 0x10248fb4
AfCopy(??, ??, ??, ??, ??, ??, ??, ??) at 0x10145700
BfCopy(??, ??, ??, ??, ??, ??, ??, ??) at 0x10237208
MoveBatch(??) at 0x1023e370
MoveCluster(??) at 0x1023fb50
MoveVolumeCollocated(??) at 0x1023ff00
AfMoveVolume(??) at 0x10241e84
DoMigration(??) at 0x10262e58
AfMigrationThread(??) at 0x102655fc
StartThread(??) at 0x10006150
_pthread_body(??, ??) at 0xd0347f3c
**The last adsm routine to be called is acs_query_drive, this
calls the acs_query drive (which is part of the acs api).
In the acs_api the failure occurs at the cl_qm_cretate
LOCAL FIX:
To avoid this problem avoid defining more than one library
on the adsm server.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users with ACSLS library defined
****************************************************************
* PROBLEM DESCRIPTION: *
The server occasionally hang or crash.
The root of the problem is in the STK toolkit code where
the common library component is not multithread safe.
This problem can occur with only one ACSLS library but
the symptom is more apparent and noticeable when more than
one ACSLS libraries are configured.
****************************************************************
* RECOMMENDATION: *
IBM has pursued afix from STK and is still continuing with
this effort. In the mean time, this APAR fix allows the
user to set environment variable BLOCK_ACS_API to optionally
serialize the ACS API calls. The variable is set with:
export BLOCK_ACS_API=1, or
export BLOCK_ACS_API=YES, or
export BLOCK_ACS_API=yes
****************************************************************
The performance impact of the API serialization is
undetermined since it varies with the configuration
and the mount activities. If the user has not
experienced crash or hang conditions, setting this
variable is not necessary
------
APAR: IC27646 COMPID: 5697TSMAX REL: 110
ABSTRACT: TSM 3.7.3 AND 4.1.0/4.1.1 SCHEME FOR TEC MESSAGING ADVERSELY
PROBLEM DESCRIPTION:
After load the 3.7.3, 4.1.0 or 4.1.1 TSM baroc file, TEC server
performance becomes significantly degraded. The "unique event
class per TSM message" model generates too many new and unique
event classes, thereby preventing the TEC engine from operating
efficiently. Performance is especially affected when the event
"_event of_class _class outside" structure is used in a TEC
rule.
LOCAL FIX:
If the event "_event of_class _class outside" structure is used
the user should exclude the followign two classes to improve
performance: IBMTSM_BASE_SERVER and IBMTSM_BASE_CLIENT
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM servers v3.7.3 and later that use the "unique event
class per TSM message" scheme to send messages to a TEC server.
****************************************************************
* PROBLEM DESCRIPTION: *
The baroc file associated with the unique event class per
message scheme creates too many entries into the databases for
the TEC server and adversely affects the performance at the TEC
server. TSM performance is not affected.
****************************************************************
* RECOMMENDATION: *
Apply fix when available.
****************************************************************
New baroc file from TSM generates too many entries into TEC
tables. This significant increase in entries slows down TEC
server performance by creating a large number of new comparisons
PROBLEM CONCLUSION:
The unique event class per TSM message model was revised. The
TSM server will now generate event class for TEC messages based
upon the source of the message, not the message number. For
example: TSM_SERVER_ANR2017 becomes TSM_SERVER_EVENT. All
information contained within the event (including the message
number) remains unchanged.
------
APAR: IC27691 COMPID: 5697TSMAX REL: 110
ABSTRACT: MOUNT POINT NOT AVAILABLE DEVCLASS WORM DRIVE OPTICAL ONLY 3.7.3
PROBLEM DESCRIPTION:
PROBLEM: TSM 3.7.3 will return no mount point available
when attempting to use WORM media.
The server code is not tracking the fact that optica
l devices can read or write WORM media.
Recreate none: This issue can be recreated using any optical
device and a devclass of WORM.
Note: This issue is isolated to 3.7.3.X and will be add
ressed in version 3.7.3.8 for NT.
ANR4571E DataBase backup/restore terminated insufficient number
of mount points
This is not the only error that will be associated to this issue
all errors indicating insufficient number of mount points may
be related.
-Key points: TSM code level and WORM media.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
TSM 3.7.3 users on the AIX, SUN and NT platforms with
OPTICAL drives that can also read and write WORM media.
****************************************************************
* PROBLEM DESCRIPTION: *
The TSM 3.7.3 server does not track correctly OPTICAL drives
that can also read and write WORM media.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The TSM 3.7 server will now track correctly OPTICAL drives
that can also read and write WORM media.
------
APAR: IC27710 COMPID: 5697TSMNT REL: 110
ABSTRACT: WEBADMIN: THE 3590 DEVICE CLASS OBJECT IS MISSING
PROBLEM DESCRIPTION:
The 3590 device class object is missing in the OBJECT_VIEW-
SERVER_STORAGE-DEVICE_CLASSES tree. For this reason, it can
not be defined using the GUI (CLI works of course). -
The reason for this defect is, that the object's settings
have not been included in the interface definition file
dsmserv.idl.
LOCAL FIX:
Use the CLI, until the fix is available
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This APAR effects user of TSM version 3.7.3.0 and lower on the
NT server platform
****************************************************************
* PROBLEM DESCRIPTION: *
The 3590 Device Class does not appear in web administrator
interface tree under Object View->Server Storage->Device Class
in the 3.7.3.0 ptf on the NT server platform.
****************************************************************
* RECOMMENDATION: *
Install the latest PTF when available.
****************************************************************
The problem regarding the missing device class of 3590 on the
web administrator interface tree presented by a TSM 3.7.3.0
server has been fixed. Please remember to run the dsmserv
runfile dsmserv.idl command against your server when the
ptf is available. This will guarantee that the fix will be
correctly installed on your TSM server.
------
APAR: IC27723 COMPID: 5697TSMAX REL: 110
ABSTRACT: DEVELOPMENT APAR TO INFORM THAT DATABASE PAGE SHADOWING IS ENABL
PROBLEM DESCRIPTION:
The TSM V3.7 server introduced a new function for protecting the
server database. The feature is call "database page shadowing".
This provides a mirror file forthe last batch of pages written
to the server database. This function wasannounced to be availa
ble in the TSM V3.7 server. The function wasnot available at GA
of the TSM V3.7 product and was disabled from customer use.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All TSM V3.7 and TSM V4.1 server users. *
****************************************************************
* PROBLEM DESCRIPTION: The TSM V3.7 server introduced a new *
* function for protecting the server *
* database. The feature is called *
* "database page shadowing". This *
* provides a mirror file for the last *
* batch of pages written to the *
* server database. This function *
* was announced to be available *
* in the TSM V3.7 server. The *
* function was not available at *
* GA of the TSM V3.7 product and *
* was disabled from customer use. *
****************************************************************
* RECOMMENDATION: Apply the PTF containing this fix once *
* it is available. *
****************************************************************
The server database page shadowing feature has been enabled and
is being provided for general customer use. The server options
"DBPAGESHADOW <YES|NO>" and "DBPAGESHADOWFILE <filename>" are
now enabled as valid server options. The function will now
initialize and can be used on the TSM V3.7 and TSM V4.1 server.
PROBLEM CONCLUSION:
The server database page shadow feature has been corrected and
is being made available for general use in the product. This
feature was announced as part of the TSM V3.7 server.
------
APAR: IC27731 COMPID: 5697TSMAX REL: 110
ABSTRACT: AUDIT SHARED LIBRARY WITH NO VOLUMES CHECKED IN CAN CAUSE DR
PROBLEM DESCRIPTION:
Audit library on a shared library that has no volumes checked
in to tsm can result in dr watson access violation.
The event log message shows
ANR9999d Pkthread.c 1882 code=c0000005
LOCAL FIX:
Ensure that at least one volume is checked in for Tsm use
prior to running the audit library. If query libvol for the
library returns no entries, check in a scratch volume prior
to running the audit library.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This APAR effect users of Tivoli Storage Manager 3.7.X.X on
HP, AIX, SUN and NT.
****************************************************************
* PROBLEM DESCRIPTION: *
Auditing a SCSI library with no volumes defined abends the
server.
****************************************************************
* RECOMMENDATION: *
Install PTF when available. The problem has been fixed in
4.1.0.0.
****************************************************************
The temporary work around is to define at least one volume
(either scratch or private) to the library using the CHECKIN
LIBVOL commmand before auditing the library.
------
APAR: IC27739 COMPID: 5697TSMAX REL: 110
ABSTRACT: EXPORT ALLOWS TAPES TO BE REUSED
PROBLEM DESCRIPTION:
During a lengthy EXPORT of a 650GB filespace expecting to use 65
tape volumes, operator inadvertantly mounted a previously used
volume three times which was not detected. The subsequent IMPORT
was unsuccessful.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM v3.1.2 servers and TSM v3.7 servers.
****************************************************************
* PROBLEM DESCRIPTION: *
During export node using manual library, the server
allows mount and overwrite of a tape volume that has already
been used by the same export transaction.
****************************************************************
* RECOMMENDATION: *
Apply a fixing PTF when available.
****************************************************************
During export node command that required
several volumes, the code allowed the
operator to mount the tape volume already
written by the same export node command
and use it as a scratch volume overwriting
the data. The code was fixed to check whether
the volume has already been used by this
export node command. If the code detects
that the volume has already been used,
the volume will be dismounted and the
server will prompt the user for another
scratch volume.
PROBLEM CONCLUSION:
The code was fixed to check for tape volumes that have
already been used by the same export node command.
------
APAR: IC27752 COMPID: 5697TSMAX REL: 110
ABSTRACT: IF ADSM DEVICES BEGIN NUMERICALLY HIGHER THAN 0 (IE. /DEV.MT6 OR
PROBLEM DESCRIPTION:
If the special device names on an ADSM/TSM server startwith
a numeric value higher that "0" (ie. /dev/lb9, /dev/mt12) and
the ADSM server is upgraded, the device names may be reset to
/dev/lb0, /dev/mt0 which will prevent the devices from initial-
izing to the ADSM server.
This condition can when originally there were devices starting
at "0". but they were later removed leaving the numericially
higher devices in place.
During the upgrade of the "adsm.devices.rte", an ODMGET command
copies the current device information and then the devices are
deleted.
During the redefine process, the device special file names are
created with the lowest available value ("0") and use the
ODMGET output for the adaper and scsi ID's.
Now, the devices are all recreated, but at the incorrect name
for ADSM to initailize to.
Here is a SMIT log example of the process:
installp: APPLYING software for:
adsm.devices.rte 3.1.2.50
. . . . . << Copyright notice for adsm.devices >> . . . . . . .
Licensed Materials - Property of IBM
5765-C4300
(C) Copyright International Business Machines Corp. 1990, 1997.
All rights reserved.
US Government Users Restricted Rights - Use, duplication or disc
restricted by GSA ADP Schedule Contract with IBM Corp.
. . . . . << End of copyright notice for adsm.devices >>. . . .
removing device lb16 ...
lb16 deleted
removing device lb14 ...
lb14 deleted
removing device lb15 ...
lb15 deleted
removing device op27 ...
op27 deleted
Large number of devices removed (lb12-lb16 and op14-op31)
removing device op28 ...
op28 deleted
removing device op30 ...
op30 deleted
removing device op31 ...
op31 deleted
Attempting to restore ADSM device configuration...
lb0 Defined
lb1 Defined
lb2 Defined
lb3 Defined
op0 Defined
op1 Defined
op2 Defined
Large number of devices defined
op18 Defined
op19 Defined
ATTENTION
The following devices, previously used by ADSM, could not be con
lb166,0 lb146,0 lb156,0 lb126,0 op292,0 op141,0 op152,0 o
op174,0 op185,0 op190,0 op201,0 op212,0 op223,0 op234,0 o
op250,0 op261,0 op273,0 op284,0 op300,0 op315,0
Examine your system hardware setup and perform any further
ADSM device configuration operations through the System
Management Interface Tool (SMIT).
<< end of attention >>
...............................
LOCAL FIX:
Use "update drive" and "update libr" commands to point to the
new device names.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Anyone updating the product via a PTF with devices previously
defined to ADSM or TSM on the AIX platform.
****************************************************************
* PROBLEM DESCRIPTION: *
Devices defined to ADSM or TSM with addresses starting higher
then 0. For example a device defined as MT16 may be redefined
as MT0 when a UPDATE is done on AIX.
****************************************************************
* RECOMMENDATION: *
Install the PTF.
****************************************************************
Previously defined devices that are removed due to a PTF
UPDATE will now be redefined with the same name on AIX.
------
APAR: IC27865 COMPID: 5697TSMAX REL: 110
ABSTRACT: NEW COMMAND TO FORCE ARCHIVE CONVERSION
PROBLEM DESCRIPTION:
The TSM server has secondary tables to provide efficient
search by description for archive entries. These tables
are readily available to the GUI client. They become
available to a command line client if the node signs on
to the server from a GUI at least once. They are not
available to API clients. API clients also have need to
search by description.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
TSM 370 and higher servers on all platforms
****************************************************************
* PROBLEM DESCRIPTION: *
API clients also have need to query archive by description
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available
****************************************************************
From ADSMV3.1, converting a node to the archive description
tables was triggered by signing on from a GUI. A new command
is introduced to give administrators the ability to initiate
this conversion.
PROBLEM CONCLUSION:
The new command is:
where:
<nodeName> is required
Wait - may be No or Yes, and defaults to No. Yes is avail-
able to administrative clients. It may not be issued
from the system console.
Policy level authority is required to issue this command.
------
APAR: IC27895 COMPID: 5697TSMAX REL: 110
ABSTRACT: 'BACKUP STORAGEPOOL WAIT=Y' RETURNS RC=0, AFTER IT FAILED
PROBLEM DESCRIPTION:
The backup stgpool process was preempted by a higher priority
process (e.g. a client restore session), when all tape drives
were in use (ANR1440I). Msg ANR0985I indicated a completion
state of failure and msg ANR1214I indicated, that not a
byte was backed up.
The problem was recreated with AIX4.3.2, server 3.1.2.30
LOCAL FIX:
check msg ANR0985I for the completition state of SUCCESS
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V312 Servers for all server platforms.
TSM V37 and V41 for all server platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
The BACKUP STGPOOL command with the WAIT=YES parameter
specified does not return a valid return code in cases where
the process failed. The command returns return code 0
regardless of the outcome of the command.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing this fix once it is available.
****************************************************************
The server BACKUP STGPOOL processing has been modified to
properly report if the process failed. If it failed, the
server will now report a non-zero return code to indicate
the failure.
PROBLEM CONCLUSION:
The server process was not able to determine the outcome
of the backup stgpool process for the purpose of sending
a meaningful return code. The process has been altered to
now report a non-zero return code if there is a failure.
------
APAR: IC27932 COMPID: 5697TSMAX REL: 110
ABSTRACT: TSM WEB HELP JAVASCRIPT LINKS TO GLOSSARY TERMS BROKEN.
PROBLEM DESCRIPTION:
Javascript links to glossary terms were broken when help files w
ere updated in support of product enhancements.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of the Tivoli Storage Manager Administrative
Web Interface in versions 3.7 and 4.1
****************************************************************
* PROBLEM DESCRIPTION( Abstract of problem ) *
Javascript links to glossary terms within the Web help system
were broken.
****************************************************************
* RECOMMENDATION: *
No recommendation at this time
****************************************************************
PROBLEM SUMMARY:
Javascript links to glossary terms were broken when help files
were updated in support of product enhancements.
PROBLEM CONCLUSION:
The broken glossary term links were fixed and now operate
correctly.
------
APAR: IC27938 COMPID: 5697TSMAX REL: 110
ABSTRACT: NEW DEVICE SUPPORT IN TIVOLI STORAGE MANAGER SERVER FOR AIX
PROBLEM DESCRIPTION:
This is a development APAR to inform users of new TSM AIX
device support for ADIC Scalar 100, HP proton autoloader,
ATL P2000, HP SureStore 818, MagFile 40.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: TSM V3.7 and V4.1 server user on AIX only *
****************************************************************
* PROBLEM DESCRIPTION: *
New device support for Tivoli Storage Manager V3.7 and V4.1
servers on AIX .
****************************************************************
* RECOMMENDATION: *
Apply the PTF for new device support.
****************************************************************
Tivoli Storage Manager server for AIX has been updated with
device support for ADIC Scalar 100, HP Proton
autoloader, ATL P2000, HP SureStore 818, MagFile 40
------
APAR: IC28009 COMPID: 5697TSMAX REL: 110
ABSTRACT: RUNNING A SCRIPT WITH A UNC NAME IN IT RETURNS THAT THIS IS
PROBLEM DESCRIPTION:
When running an adsm/tsm script that contains a UNC name,
adsm/tsm returns that the line is invalid.
example> run test
<contains "delete fi nodename \\naples\c$">
ANR1465E RUN: Command script TEST, line 1,
parameter is invalid: del fi nodename
\\naples\c$.
ANR1463E RUN: Command script TEST completed in error.
ANS8001I Return code 4.
However, this command "del fi nodename \\naples\c$ is a
valid command.
This has been tested on NT and AIX both at 3.7.1.0,3.1.2.40
and 3.1.2.50.
LOCAL FIX:
Run the command on the admin command line.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and TSM users who use server scripts.
****************************************************************
* PROBLEM DESCRIPTION: *
Server scripts which contain dollar signs ($) that are not
associated with parameters were failing during parameter
substitution.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************
PROBLEM CONCLUSION:
The TSM server is modified to not attempt parameter
substitution when encountering dollar signs not followed by
numerics in a server script.
------
APAR: IC28018 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANR1401W MOUNT REQUEST DENIED FOR VOLUME ISSUED WHEN USING FILE:
PROBLEM DESCRIPTION:
Use of the FILE: paramter on the DSMSERV LOADDB salvage utility
does not work. Message ANR1401W mount request denied is issued.
The message indicates that the name of the volume we could not
mount erroneously contains the 'FILE:' characters at the start.
The FILE: parm should allow you to identify a file which
contains a list of all the volumes (volsers) to which the server
database has been dumped using DSMSERV DUMPDB. If you use a
File Devclass then this can be many volumes. In our case we had
over 150 file volumes holding the database dump.
Problem was reported on ADSM 3.1.2.40 but has been recreated
on TSM 3.7.1 NT server.
Not sure if the problem exists with real tapes or only with
File Devclass 'volumes'.
LOCAL FIX:
If possible, specify the full volume names in the VOL= parameter
rather than VOL=FILE:<volumelist.txt>
You can seperate the volsers with commas.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
NT Users using DUMPDB or LOADDB
****************************************************************
* PROBLEM DESCRIPTION: *
The VOLUMENAMES=FILE:filename parameter of DSMSERV DUMPDB and
DSMSERV LOADDB did not function properly, it did not open
the specified filename to obtain volume names.
****************************************************************
* RECOMMENDATION: *
Install the PTF
****************************************************************
The VOLUMENAMES=FILE:filename parameter will now open the
specified file and use the volumenames in the file.
PROBLEM CONCLUSION:
The VOLUMENAMES=FILE:filename parameter will work correctly.
------
APAR: IC28066 COMPID: 5697TSMAX REL: 110
ABSTRACT: VOLUME AND MOUNTPOINT ARE NOT FREED WHEN ANR8469E DISMOUNT
PROBLEM DESCRIPTION:
If message 'ANR8469E Dismount of <device type> volume <volume
name> from drive <drivename> in library <library name> failed.'
is received from an external library manager the volume and
mountpoint will not be freed. This prevents further use of the
volume and mountpoint until after the TSM server is halted and
restarted, regardless of any action taken to manually dismount
the volume and free the mountpoint.
LOCAL FIX:
Halt and restart the TSM server.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM 3.7 Server users and above
****************************************************************
* PROBLEM DESCRIPTION: *
Failed dismounts to External Library Manager are not cleaned up
properly.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available
****************************************************************
When a dismount fails an error is received from an ELM - the
customer issues a command directly to the ELM to dismount the
volume and this is successful. However, TSM still believes the
volume is still mounted and the only way to clear the condition
is to shutdown and restart TSM.
PROBLEM CONCLUSION:
Change the code when the dismount fails to release the drive.
------
APAR: IC28076 COMPID: 5697TSMAX REL: 110
ABSTRACT: VERSION 3 BACKUP CLIENT GUI CAN NOT EXPAND DIRECTORIES
PROBLEM DESCRIPTION:
Summary: Native win32 version3 backup client gui can not expand
directories of archived data under the following situation.
The data was archived under version 2 server/client. V2 client
was obsoleted. Client and archives were maintained on ADSM (now
To eliminate extra node for both client and server to maintain,
and corresponding filespace is exported. V2 node on server is r
to temp name. Existing V3 client w/o archives is renamed to sam
as exported V2 client. V2 client archives are imported. From c
archives are visible from V3 client. From GUI, they are not.
Detailed recreate:
Archive files using version 2 client/server with nodename venus.
Upgrade server to version 3.
Export nodename and filespace.
Delete nodename and filespace.
Import nodename and filespace.
Start the win32 gui and try to expand the directories for the
archived files.
This may be common to all clients as it also happens
on Sun clients at 3.1.0.7
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and Tivoli Storage Manager servers
****************************************************************
* PROBLEM DESCRIPTION: *
GUI does not display imported version 2 archive files
****************************************************************
* RECOMMENDATION: *
apply fixing ptf whan available
****************************************************************
Customer had files archived by a Version 2 client. They
were exported, and imported to a Version 3 server. These
Version 2 archive files do not display on a Version 3 GUI.
PROBLEM CONCLUSION:
The server sent an incorrect flag to the GUI. The GUI then
did not expand the archive tree correctly.
------
APAR: IC28083 COMPID: 5697TSMAX REL: 110
ABSTRACT: DOUBLE SIDED MEDIA NOT TRACKED PROPERLY DURING RECONSTRUCTION
PROBLEM DESCRIPTION:
Double-sided media (optical, in this case) are not properly
handled during reconstruction of a bitfile that scans the sides
of an optical platter and the following error messages are sent:
ANR9999D asrtrv.c(563): End reached prematurelyon vol XXXX
...and after running audit reclaim;
ANR9999D ssrecons.c(2210): Invalid magic number found inframe
header
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All 3.1.2 and later servers using double sided media such as
optical.
****************************************************************
* PROBLEM DESCRIPTION: *
During reclamation of aggregates, the second side of double
sided media is not tracked. This can potentially cause
erroneous "invalid magic number" errors.
****************************************************************
* RECOMMENDATION: *
Apply latest patch or PTF when available.
****************************************************************
"Invalid magic number" error messages may be triggered because
of not tracking the sides of double-sided media. The error
will typically arise during reclamation / reconstruction. The
fix provides the necessary logic to recognize when to wait if
a bitfile spans both sides of a d.sided volume.
------
APAR: IC28091 COMPID: 5697TSMAX REL: 110
ABSTRACT: EXPORT NODE EXPORTS ALL CLIENT OPTION SETS REGARDLESS WHETHER TH
PROBLEM DESCRIPTION:
Export node exports all client option sets regardless whether th
ey are assigned to that node or not. To recreate:
1. define a client option set
2. define at least 1 client option in that set
3. register a new node (no client option set assigned)
4. create a filespace for that new node
5. export the node. the client option set gets exported
6. delete the client option set
7. import the node. the client option set gets imported.
This behavior doesn't reflect the export node definition
from the admin reference.
The behavior could be recreated on an 3.1.2.50 server level.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM 3.1.2, and TSM 3.7 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
"Export Node" exports all client Option Sets regardless of
of whether they are assigned to that node or not.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available
****************************************************************
The Export Node command will always export all Client Option
sets and client options defined on the server.
PROBLEM CONCLUSION:
The Export Node command was changed to only export those
Client Option Sets and Client Options that are associated
with the node(s) being exported.
------
APAR: IC28097 COMPID: 5697TSMAX REL: 110
ABSTRACT: ADSM WILL NOT INITIALIZE WITH ACSLS AFTER ADSM HAS BEEN HALTED
PROBLEM DESCRIPTION:
This was reported on AIX ADSM server 3.1.2.50 with STK 9710 and
ACSLS.
PVR MMS trace loops with "mmsacsl2.c(2841): (1)Return delayed,
finding a matching sequence".
Before installing level 3.1.2.50, customer stopped ADSM server
without stopping the ssi/mini_el daemons. During restart of
ADSM, the Actlog never receives error messages ANR8851E
Initialization failed for ACSLS library name; will
retry in delay time minute(s). or ANR8852E Initialization
failed for ACSLS library name.
Within the PVR MMS trace you will see these messages before
the loop:
mmsacsl2.c(200): (1)acs_query_server, st=STATUS_IPC_FAILURE,
rc(999).
mmsacsl2.c(2603): (1)Sequence inserted into list
entry(1),time=955359038.
mmsacsl2.c(2526): (1)Sequence waiting for response.
LOCAL FIX:
Restart ADSM and ssi/mini_el daemon.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM users with ACSLS library defined.
****************************************************************
* PROBLEM DESCRIPTION: *
Looping may occur as the result of STATUS_IPC_FAILURE
during the ACSLS library initialization.
****************************************************************
* RECOMMENDATION: *
Ensure SSI daemon is fully initialized before
starting dsmserv. This checking can be done
by using lbtest option 51 through 56.
****************************************************************
Fix applied in retrieving the ACS response logic when
IPC_FAILURE occurs immediately after the invocation
of query_server API.
TEMPORARY FIX:
Ensure SSI is fully initialized before starting
dsmserv.
------
APAR: IC28103 COMPID: 5697TSMAX REL: 110
ABSTRACT: ANR4359W CAN OCCUR DURING RECONCILE VOLUME PROCESS WHEN 0 LENGTH
PROBLEM DESCRIPTION:
ANR4359W incorrectly results during reconcile volume process
when a client sends a zero length file to server storage. The
server writes a self describing data header to server storage
with the clients estimated file size. The problem happens when
there is perceived discrepancy between the size of the object
in the virtual volume archive, and the descriptor in server
storage. This problem is benign, with no risk of data loss.
ANR4359W is being reported in error.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM Server V312 and TSM server versions 3.7 and 4.1 users
of server-to-server virtual volumes.
****************************************************************
* PROBLEM DESCRIPTION: *
The source server may report an error against a virtual volume
when performing a "RECONCILE VOLUME" process. In particular,
message ANR4359W is issued indicating the size on the target
volume does not match the size on the source volume.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing this fix once it is available.
****************************************************************
The server "RECONCILE VOLUME" process was incorrectly reporting
that the size of the virtual volume as stored on the target
server does not match the attributes for the volume on the
source server. In fact, the volume on the target server is
correct and the ANR4359W message is being issued incorrectly.
PROBLEM CONCLUSION:
The "RECONCILE VOLUME" process was issuing a warning message
ANR4359W incorrectly. The attributes of the target volume
were actually correct and the data stored in the virtual
volume is correct and not damaged. In this case, the
algorithm has been changed to accurately compare the size
values and to only issue the ANR4359W message in cases where
the size values between the source and target servers is
actually incorrect.
------
APAR: IC28114 COMPID: 5697TSMAX REL: 110
ABSTRACT: MULTIPLE VOLUME REMOUNT REQUEST OF FULL VOLUME IN
PROBLEM DESCRIPTION:
TSM server continue to request remount of cartridge that has
reached an end of volume in a manual library. The server issues
an ANR8341I End-of-volume (EOV) message. The cartridge is
dismounted from the device. A mount request for the cartridge
that has reached EOV is issued by ADSM after volume has been
dismounted, "ANR8326I 002: Mount CARTRIDGE volume..." The
operator in some instance has had to remount the same volume 6
successive times. No, errors are recorded in actlog.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM servers with tape storage pools defined.
****************************************************************
* PROBLEM DESCRIPTION: *
If the first segment that is written to a volume*
causes the volume to reach EOV, we fail to write this segment
because the mount wait flag is false even though it had to
be true to mount this volume from the previous write. We
unmount this volume and then remount this same volume to
finish filling it before we allow the mount of the next volume.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
Prevented the premature dismount of the volume.
PROBLEM CONCLUSION:
Volumes will no longer be prematurely dismounted.
------
APAR: IC28125 COMPID: 5697TSMAX REL: 110
ABSTRACT: WHEN A DURATION IS SET FOR THE EXPIRE INVENTORY THE RESTART
PROBLEM DESCRIPTION:
When a duration is set for expire inventory the restart
checkpoint is reset to zero instead of where it ended.
WORK ARROUND
A circumvention would be to run the expire inventory via a
scheduled admin command and then schedule a "cancel expiration"
for the expiration process a few hours later. Canceling the
process will set a restart checkpoint for the next time
expiration is run.
This is not a platform specific problem since it involves a
common section of the 3.1.2.x code.
LOCAL FIX:
A circumvention would be to run the expire inventory via a
scheduled admin command and then schedule a "cancel expiration"
for the expiration process a few hours later. Canceling the
process will set a restart checkpoint for the next time
expiration is run.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V312 and TSM V37 and V41 servers performing expiration
and using the "DURATION" parameter on the expiration command.
****************************************************************
* PROBLEM DESCRIPTION: *
When running expiration with the "DURATION" parameter, the
expiration will not set the restart position properly if
the expiration process ends as a result of the DURATION
being exceeded.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing the fix for this apar once it is
available.
****************************************************************
The server expiration process has been altered to allow the
restart position to not be reset in the event that expiration
ends due to the duration being exceeded.
PROBLEM CONCLUSION:
The expiration process uses a restart position to keep track
of where to start from one expiration run to the next.
However, this was not working correctly when the DURATION
parameter was specified, the restart position would always
be reset to the very beginning of the expiration process.
The fix prevents the reset from occurring and will allow
subsequent expiration processes to restart where it left off.
------
APAR: IC28133 COMPID: 5697TSMAX REL: 110
ABSTRACT: MSGANR8355E I/O ERROR READING LABEL FOR VOLUME
PROBLEM DESCRIPTION:
ANR8341I End-of-volume reached for 3590 volume 000684.
ANR8336I Verifying label of 3590 volume 000684 in drive
RMT16 (/dev/rmt16).
ANR8355E I/O error reading label for volume 000684 in
drive RMT16 (/dev/rmt16).
ANR8468I 3590 volume 000684 dismounted from drive RMT16
(/dev/rmt16) in library 3494_B0.
Problem only happens with D/T3570 and D/T3590 devices.
LOCAL FIX:
There is probably no problem with the tape. Run AUDIT VOLUME
FIX=NO to verify TSM can read the tape label.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using 3570 and 3590 devices on the
HP, AIX, and SUN platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
The problem may appear intermittently depending on the
operating system level.
The problem only occurs after TSM reached the end-of-volume
while writing data to the tape cartridge.
If TSM immediately dismounts the volume, there may be an
erroneous ANR8355E message while verifying the internal
tape label.
If TSM leaves the volume mounted and there are drive or media
problems when TSM attempts to read the data, TSM may not
issue an ANR8302E or ANR8311E message.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM better tracks error situations to avoid issuing erroneous
messages and to issue messages when there are errors.
Impact: Low
Customer can issue AUDIT VOLUME with FIX=NO to determine if
there is any problem with the media and data.
------
APAR: IC28134 COMPID: 5697TSMAX REL: 110
ABSTRACT: THE WEB ADMIN CLIENT SHOWS INVALID OPTIONS FOR CLIENT OPTIONSET
PROBLEM DESCRIPTION:
THE CLIENT OPTIONS SHOWN FROM THE WEB ADMIN CLIENT PULL DOWN MEN
U FOR SLECETION IN AN OPTION SET IS DIFFERENT THAN THE OPTIONS
SHOWN BY 'HELP CLIENTOPT' COMMAND. SOME OF THE OPTIONS ARE SHOW
FROM THE PULL DOWN MENU THAT ARE INVALID. ALSO THE VERBOSE AND
QUIET OPTIONS IN CLIENT OPTION SET REQUIRES VALUES AS 'YES/NO'
IF NO VALUE IS SPECIFIED WHILE DEFINING VERBOSE/QUIET, GENERATES
ERROR MESSAGE.
LOCAL FIX:
USE YES/NO AS THE OPTION VALUE WHEN DEFINING VERBOSE/QUIET IN
CLIENT OPTION SET
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem affects users of the TSM Webadmin interface on NT,
Sun, HP, AIX, and MVS.
****************************************************************
* PROBLEM DESCRIPTION: *
Missing Client options in the TSM Webadmin interface
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
There were missing client options in the TSM webadmin interface
files(IDL).
PROBLEM CONCLUSION:
Added the missing client options to the TSM webadmin interface
files(IDL).
------
APAR: IC28151 COMPID: 5697TSMAX REL: 110
ABSTRACT: SERVER DATABASE DEADLOCK SITUATION WHEN TRYING TO WRITE VOLUME
PROBLEM DESCRIPTION:
ANR0390W A server database deadlock situation has been
encountered: lock request for transaction x:xxxxxxxx
will be denied to resolve the deadlock.
ANR9999D ICUTIL(1515): Lock acquisition (sLock)
failed for icvhVolumeType 4.
ANR4513E A database lock conflict was encountered
in processing sequential volume history information.
ANR4510E Server could not write sequential volume history
information to 'ADSM.SER1.VOLHIST.DATA'.
Slip dump on the ANR9999D ICUTIL message was analyzed and was
determined that there were a number of migration and
reclamation processes running at the time of the failure.
A migration process holds IC_LOCK_VOLTYPE volume
type=icvhStgNew. The SsAuxThread for this process is waiting
for the IC_LOCK_VOLTYPE volume type=icvhStgDelete under that
same transaction. One of the reclamation processes holds the
IC_LOCK_VOLTYPE volume type=icvhStgDelete and requested the
IC_LOCK_VOLTYPE volume type=icvhStgNew. If this request were
granted, it would result in a deadlock.
LOCAL FIX:
ADSM will continue processing without any user intervention.
or
Prevent migration and reclamation processes from running at the
same time.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and TSM users.
****************************************************************
* PROBLEM DESCRIPTION: *
The server encountered a deadlock situation while trying to
refresh volume history files.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when applicable.
****************************************************************
PROBLEM CONCLUSION:
The server is corrected to no longer deadlock when refreshing
volume history files.
------
APAR: IC28158 COMPID: 5697TSMAX REL: 110
ABSTRACT: CONVERT USSFILESPACE FAILS WITH ANR9999D IMUSSFS: NO OBJECT
PROBLEM DESCRIPTION:
Customer runs CONVERT USSFILESPACE and fails with:
ANR9999D IMUSSFS(1071): No object found in backup
objects Table for nodeId (xx), fsId(xx), object Id High(x)
object Id Low(xxxxxxx)
The Nodes are locked until the conversion is complete.
Subsequent command CONVERT USSFILESPACE continue=yes fail with
the same message on different object Ids.
LOCAL FIX:
Stop the conversion process. Restore data base prior to the
conversion processes.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM/TSM V3.1.2, V3.7, and V4.1 Server users that want to
use CONVERT USSFILESPACE server utility.
****************************************************************
* PROBLEM DESCRIPTION: *
CONVERT USSFILESPACE FAILS WITH ANR9999D IMUSSFS: NO OBJECT
FOUND IN BACKUP OBJECTS TABLE FOR NODEID.
****************************************************************
* RECOMMENDATION: *
When encountering the error described. It is recommended to not
continue the conversion. It is recommended to first apply the
the fixing PTF, start the server, and reissue the
' CONVERT USSFILESPACE ' from the start ( do not use the
'CONTINUE' option. ).
****************************************************************
Customer runs CONVERT USSFILESPACE and fails with:
ANR9999D IMUSSFS(1071): No object found in backup
objects Table for nodeId (xx), fsId(xx), object Id High(x)
object Id Low(xxxxxxx)
The Nodes are locked until the conversion is complete.
The problem is that while the server was considering
which files to convert, it did not expect
an empty string, which can be appropriate. Thus, the
server failed the conversion. The server has been updated
to appropriately handle this case and continue the conversion.
PROBLEM CONCLUSION:
The server code has been updated to fix the problem.
------
APAR: IC28181 COMPID: 5697TSMAX REL: 110
ABSTRACT: LABEL LIBVOL COMMAND WITH ADIC SCALAR 458 LIBR RETURNS UNCLEAR
PROBLEM DESCRIPTION:
Win NT 4.0,running TSM Server 3.7.2. w/ ADIC Scalar 458 library.
If the following command is run from the Admin command line:
label libv scalar458 search=bulk checkin=scratch
labelsource=barcode
Then TSM errors out with the following error message:
ANR8819E No barcode reader detected in library <library>
However, this command appears to fail only if the search=bulk
parameter is used, and volumes are attempted to be labeled if
brought in directly from the EE port on the library. This
problem does not occur if TSM attempts to label volumes from the
library slots directly. Thus, the message shown above does not
contain language to properly identify this error, and should
be changed to a message which more accurately describes the
problem with this particular label libvol operation.
LOCAL FIX:
Workarounds include manually inserting volumes into the library
itself, or loading the volume to the library first. Then use
the label libvol function to scan the barcode of the volume(s)
and read the labels from it.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using TSM 3.7 on the AIX, HP, SUN and NT platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
The ANR8819E message should state "unable to read the barcode
label(s) in library <library name>", instead of "no barcode
reader detected in library <library name>".
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The ANR8819E message was changed.
------
APAR: IC28186 COMPID: 5697TSMAX REL: 110
ABSTRACT: TIVOLI STORAGE MANAGER SERVER MAY HANG DURING UNLOAD PROCESSING.
PROBLEM DESCRIPTION:
During unload db processing on a TSM server the unload may
hang. The reporting customer experienced this problem on a TSM
NT 3.7.2 server. Diagnostic code revealed that the unload
processing was waiting on a thread that did not exist. This
appears to have been caused by the array holding the threads
being too small.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V3.7 and TSM V4.1 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
The server "dsmserv unload db" process may hang. This appears
towards the end of the processing, typically, after a number
of status messages have been issued indicating the progress
of the unload process.
****************************************************************
* RECOMMENDATION: *
Please apply the ptf containing this fix once it is available.
****************************************************************
The server unload db algorithm was not correctly keeping track
of all the server resources used to perform the unload db
operation. Because of this error tracking the resources
used, the server may hang because a system call does not
return because it was given an incorrect value.
PROBLEM CONCLUSION:
The server unloaddb process has been corrected. The resource
tracking done by unload db has been fixed to prevent this
hang condition.
------
APAR: IC28196 COMPID: 5697TSMAX REL: 110
ABSTRACT: EXPORT OF BACKINT FILESPACES DOES NOT EXPORT ALL DATA IF THE DAT
PROBLEM DESCRIPTION:
Export of backint filespaces does not export all data if the dat
a was sent using multiplexing > 1. To recreate:
1. Archive a couple of files using backint configured to use
multiplexing = 2.
2. Export the according nodename using filedata=all option
3. Import the same node
4. You will see less files imported than the original filespace
had
The problem could be recreated using server version 3.1.2.40
and 3.7.1.0. The problem does not occur using server version
3.1.2.20.
LOCAL FIX:
Use multiplexing = 1 for backint.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V312 server users and TSM V3.7 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
During export, if a file is expected to actually have file
data (an inventory attribute reports the estimated
size from the client that is a non-zero value), the export
process skips writing the export record for the file. The
algorithm only writes the export record for files expecting
file data once file data is encountered. In this case, the
export record describing the file was not written because
there was no actual file data.
****************************************************************
* RECOMMENDATION: *
Apply the ptf that resolves this situation once it is available.
****************************************************************
The export queue'ing algorithm has been modifies to write
the export file description record in cases where the file
was expected to have file data although there was no actual
file data.
PROBLEM CONCLUSION:
The export algorithm has been modified to correct this
situation.
------
APAR: IC28201 COMPID: 5697TSMAX REL: 110
ABSTRACT: DEF DEVCLASS DOES NOT SHOWS NEW OPTIONS 3590E-B AND 3590B-C IN
PROBLEM DESCRIPTION:
DEFINE DEVICE CLASS COMMAND DOES NOT SHOW NEW FORMATS FOR 3590
DEVICE (3590E-B AND 3590E-C) BUT IT IS POSSIBLE TO DEFINE A
DEVICE CLASS WITH ANY OF THESE FORMATS. ALSO THE ON LINE HELP
DOES NOT SHOW THESE FORMATS. THIS PROBLEM HAS BEEN VERIFIED IN
ADSM 3.1.2.40, 3.1.2.50, TSM 3.7.0 AND 3.7.1. FOR ADSM 3.1 THE
README FILE README.SRV REPORTS THESE NEW FORMATS, BUT NOT FOR
TSM 3.7 (IN TSM 3.7 THE ONLINE HELP IS CORRECT)
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem affects users of TSM 3.7 on NT, AIX, and Sun with
3590 devices.
****************************************************************
* PROBLEM DESCRIPTION: *
Customers using the TSM webadmin interface cannot define a 3590
devclass with a tape format of 3590E-B or 3590E-C
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available
****************************************************************
Customers using the TSM Webadmin interface cannot define a 3590
devclass with a tape format of 3590E-B or 3590E-C.
PROBLEM CONCLUSION:
The webadmin files(IDL) were updated to supply support for the
3590 tape formats.
------
APAR: IC28308 COMPID: 5697TSMAX REL: 110
ABSTRACT: SHIP VEHICLE APAR FOR TIVOLI STORAGE MANAGER V3.7.4 FOR AIX
PROBLEM DESCRIPTION:
SHIP VEHICLE APAR FOR TIVOLI STORAGE MANAGER V3.7.4 FOR AIX
PROBLEM SUMMARY:
SHIP VEHICLE APAR FOR TIVOLI STORAGE MANAGER
V3.7.4
------
APAR: IC28419 COMPID: 5698TSMAX REL: 410
ABSTRACT: SESSION HANGS WHEN MIXED DRIVE TYPES IN 349X/ACSLS LIBRARY
PROBLEM DESCRIPTION:
If a customer has mixed drive types in a 3494/ACSLS library,
TSM 4.1 server will enter an infinite loop when attempting
to select a drive for a tape operation. The session appears to
hang. The problem only happens when the customer has two
drives in the library -- one of each drive type.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
TSM 4.1 users on AIX/HP/SUN/NT with mixed drives in the
3494 or ACSLS libraries.
****************************************************************
* PROBLEM DESCRIPTION: *
If a customer has mixed drive types in a 3494/ACSLS library,
TSM 4.1 server will enter an infinite loop when attempting
to select a drive for a tape operation. The session appears to
hang. The problem only happens when the customer has two
drives in the library -- one of each drive type.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available
****************************************************************
TSM server correctly selects the drive for a tape operation
in a 3494/ACSLS library with mixed drive types.
------
APAR: IC28459 COMPID: 5697TSMAX REL: 110
ABSTRACT: MOUNT FAILURES WHEN RUNNING CHECKIN/LABEL/CHECKOUT AND OTHER
PROBLEM DESCRIPTION:
On a 3494 or ACSLS library, there is potential for mounts to
fail when there is a CHECKIN, LABEL or CHECKOUT LIBVOLUME
command running and other tape activity.
Example messages from a 3494 scenario:
ANR8749E Library order sequence check on library ADSM3494.
ANR1404W Scratch volume mount request denied - mount
failed.
ANR8301E I/O error on library ADSM3494 (OP=004C6D32,
SENSE=00.00.00.6D).
LOCAL FIX:
Run the CHECKIN, LABEL, and CHECKOUT LIBVOLUME commands at a
time where there is no other tape activity. Update the
storage pool to UNAVAILABLE to perform these processes.
PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
TSM 3.7 and 4.1 users on AIX/SUN/HP/NT with 3494 or ACSLS
libraries.
****************************************************************
* PROBLEM DESCRIPTION: *
On a 3494 or ACSLS library, there is a potential for mounts to
fail when there is a CHECKIN, LABEL, or CHECKOUT LIBVOLUME
command running and other tape activity. The mounts fail
because the same drive is reserved for multiple processes.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
TSM server does not reserve the same drive for multiple
processes.
------
APAR: IR43807 COMPID: 5697F4800 REL: 410
ABSTRACT: FWHSCNT COMMAND FIAL WITH IOCTL: CAES SIOCSFWCSIMX
PROBLEM DESCRIPTION:
fwhscnt command with any flag -a, -g or -s returns error
# fwhscnt -s
IP Counter Setting:
ioctl: caes SIOCSFWCSIMX error
# fwhscnt -a
ioctl: caes SIOCGFWCSIMX error
# fwhscnt -g
ioctl: caes SIOCGFWCSIMX error
PROBLEM SUMMARY:
Obsolete code not completely removed.
PROBLEM CONCLUSION:
Code added to make obsolete code work.
------
APAR: IR44089 COMPID: 5697F4800 REL: 410
ABSTRACT: PROBLEMS WITH DYNAMIC FTP BREAKING CONNECTION PREMATURELY
PROBLEM DESCRIPTION:
Dynamic ftp breaking connections prematurely
PROBLEM SUMMARY:
Customer is using Dynamic FTP and it appears
that the firewall is terminating dynamic FTP data connections
prematurely and the connection isn't closing properly. The
connections are left in the CLOSED_WAIT2 statte on the MVS host
and hanging the client (Netscape or ws_ftp).
PROBLEM CONCLUSION:
Code has been updated to properly close the
connections.
------
APAR: IR44269 COMPID: 5697F4800 REL: 410
ABSTRACT: UNABLE TO ACTIVATE FUNCTION %S" OR "$1S" WHEN REGEN RULES
PROBLEM DESCRIPTION:
Unable to activate function %s" or "$1s" appears in rc.out and
when reactivating filters.
LOCAL FIX:
FW00127
PROBLEM SUMMARY:
New module was not added to inventory and thus
was missing from the PTF image.
PROBLEM CONCLUSION:
New module was added to inventory.
------
APAR: IR44271 COMPID: 5697F4800 REL: 410
ABSTRACT: ALIAS ON LOOPBACK CAUSES ALL ALIASES TO DISAPPEAR FROM CONFIG
PROBLEM DESCRIPTION:
IR43440 is fixed for the customer reporting the problem. However
we found that if the loopback is aliased, the fix does not work.
PROBLEM SUMMARY:
When the loopback is aliased. The fix for
marking aliases as secure or non-secure does not work.
PROBLEM CONCLUSION:
Fix known limitation in IR43440.
------
APAR: IW00462 COMPID: 5697C8320 REL: 120
ABSTRACT: DELETE RETAIN KEY UNDER DUAL ACCESS CONTROL DOES NOT WORK.
PROBLEM DESCRIPTION:
The Delete Retain Key under Dual Access Control does not work.
In the observed scenario an error was received when the user
tried to delete the old certsign certificate/key. When an
attempt was made to delete the crlsign certificate/key a success
message was shown but the private key was not deleted.
PROBLEM SUMMARY:
Delete Retain Key does not work under dual
access control.
PROBLEM CONCLUSION:
Defect in code; required key record password
------
APAR: IW00468 COMPID: 5697C8320 REL: 120
ABSTRACT: APAR FOR SETCACLIENT PTF FOR 1.2.2.4
PROBLEM DESCRIPTION:
This APAR is for the SETCAClient portion of Payment Registry to
allow the creation of refresh 1.2.2.4. It is reporting the
following problem against the client which was also reported
against the server portion under IW00462:
The Delete Retain Key under Dual Access Control does not work.
In the observed scenario an error was received when the user
tried to delete the old certsign certificate/key. When an
attempt was made to delete the crlsign certificate/key a success
message was shown but the private key was not deleted.
PROBLEM SUMMARY:
"Delete Retained Key does not work under Dual A
ccess Control"
PROBLEM CONCLUSION:
Delete Retained Key functionality under Dual
Access is added on setca server side where a keyrecord password
field is prompted on "certmanager" client GUI when delete button
is clicked for a retained key and upon submission of correct key
record password setca server deletes the retained private key.
------
APAR: IY10778 COMPID: 5765C3403 REL: 430
ABSTRACT: M80 HARDWARE MULTI-THREADING SUPPORT
PROBLEM DESCRIPTION:
This APAR delivers hardware multi-threading (HMT) support for
the 7026 model M80 system.
This is a packaging APAR only. It will not appear in the list
of APARs on the SMIT "Update Software by Fix (APAR)" panel, nor
will the 'instfix' command show this APAR as being installed
after the updates delivered by this package are installed.
To install all updates from this package that apply to installed
filesets on your system, use the command:
smit update_all
PROBLEM SUMMARY:
Packaging only.
PROBLEM CONCLUSION:
Packaging only.
------
APAR: IY11331 COMPID: 576552900 REL: 240
ABSTRACT: SETUP_SERVER COULD DO SOME SIMPLE CHECKING TO AVOID SOME
PROBLEM DESCRIPTION:
Setup_server could do sme simple checking to avoid some problems
with the spot.
PROBLEM SUMMARY:
"setup_server" allows files in the lppsource directory that
lack universal read permission. This can cause hard-to-
detect problems later in the installation.
In addition, it should verify that the file "bos" exists in
lppsource, and abort the installation if it doesn't.
PROBLEM CONCLUSION:
The setup_server module now will verify that all files in
lppsource have o+r permission, and set it if they don't.
Also, all the directories leading up to lppsource will be
set with proper read permissions. If, for some reason, the
chmod command to do this fails, an appropriate diagnostic
will be issued.
The bos file's presence in lppsource will be checked. If it
is absent, the fact will be noted and the setup_server run
aborted.
------
APAR: IY11575 COMPID: 576552900 REL: 240
ABSTRACT: IF_LS CALLING IF_ATTACH() MORE THAN ONCE FOR THE SAME INTERFACE/
PROBLEM DESCRIPTION:
The panic (i.e., crash) is caused by if_ls calling if_attach()
more than once for the same interface/adapter.
Problem occoured if adding ip alias for SP Switch just after
adding default route for css0 (/etc/inittab) so that if_ls
calling if_attach() is called twice.
e.g (for the css)
rcroute:2:once:/mse_test/rc.route > /dev/console 2>&1
rclocal:2:once:/mse_test/rc.alias > /dev/console 2>&1
You should still delay adding the alias till the previous action
has completed successfully
LOCAL FIX:
You should still delay adding the alias (or any similar action
which calls if_ls (calls if_attach() ).
if_attach() shouldn't be called twice on the same interface
without a "time" delay.
PROBLEM SUMMARY:
code change to if_ls avoids multiple calls to if_attach()
for the same interface (thus avoiding a kernel panic)
PROBLEM CONCLUSION:
code change to if_ls avoids multiple calls to if_attach()
for the same interface (thus avoiding a kernel panic)
------
APAR: IY12580 COMPID: 576552900 REL: 240
ABSTRACT: SYSCTLD CAUSED SIGSEGV IN STRCPY.STRCPY() AT MIDNIGHT.
PROBLEM DESCRIPTION:
sysctld sometime caused segmentation vioration in strcpy.strcpy
and dumped core at midnight when cleanup.logs.nodes running.
Failing function stack in the core was as follow.
strcpy.strcpy() at 0x100080cc
Tcl_SetVar2(??, ??, ??, ??, ??) at 0x1000fa58
Tcl_SetVar(??, ??, ??, ??) at 0x1000fc28
Tcl_SetCmd(??, ??, ??, ??) at 0x1000e1e4
Tcl_Eval(??, ??) at 0x1000c320
Tcl_IfCmd(??, ??, ??, ??) at 0x10016e10
Tcl_Eval(??, ??) at 0x1000c320
Tcl_WhileCmd(??, ??, ??, ??) at 0x1001c85c
Tcl_Eval(??, ??) at 0x1000c320
Tcl_IfCmd(??, ??, ??, ??) at 0x10016e10
Tcl_Eval(??, ??) at 0x1000c320
Tcl_ForeachCmd(??, ??, ??, ??) at 0x10011dd0
Tcl_Eval(??, ??) at 0x1000c320
InterpProc(??, ??, ??, ??) at 0x10010244
Tcl_Eval(??, ??) at 0x1000c320
svc_tcl_eval(??) at 0x10031980
sysctl_svc(??) at 0x100306a8
svc_dispatch(??) at 0x10000b34
sysctld.svc_run() at 0x10000c78
main(??, ??) at 0x100002f0
Same problem had reported for PSSP V3.1.1 by APAR IY12578.
PROBLEM SUMMARY:
When large logs are being trimmed by either
cleanup.logs.nodes or cleanup.logs.ws, it is possible for
sysctld to core dump. The core dumps are intermittent and
are caused by the access of memory that was not allocated
successfully.
PROBLEM CONCLUSION:
logmgt.cmds was modified to use physical storage, instead
of memory when trimming log files. Checks were also added
to only proceed with the trimming of the log files if there
is enough space in the file system. As a result of these
changes sysctld will not need to allocate memory to hold
the trimmed log file and the success of the allocation of
any memory will be verified prior to accessing it.
------
APAR: IY12688 COMPID: 576552900 REL: 240
ABSTRACT: HMRMD DOES ONLY EXPECT THE DEFAULT KRBTKFILE /TMP/TKT0
PROBLEM DESCRIPTION:
hmrmd does only expect the default KRBTKFILE /tmp/tkt0
In an customer environment where KRBTKFILE is set to
some other file, eg. to create a new one for each root
login using:
export KRBTKFILE=/tmp/tkt_$$
klist -t || kinit root.admin
in roots .profile
hmrmd does not start and haemd my lock hmrmd.
Refer to PSSP 3.1 APAR IX88757
Workaround:
unset KRBTKFILE
kinit root.admin
/tmp/tkt0 will be created and used by hmrmd.
Remember this ticket will expire and repeating
the kinit once a month is necessary.
PROBLEM SUMMARY:
When using a KRBTKFILE of other then /tmp/tkt0, hmrmd
will be unable to connect to hardmon. As a result,
perspectives will be unable to show certain data for the
nodes.
PROBLEM CONCLUSION:
Modified both the hmrmd and splogd daemons to function
properly when the KRBTKFILE is set to something other then
/tmp/tkt0.
------
APAR: IY13175 COMPID: 576552900 REL: 240
ABSTRACT: IF_LS KERNEL EXTENSION CAUSES PERF. PROB ON NON-POWER NODE WITH
PROBLEM DESCRIPTION:
Performance problems can occur on non-power nodes (e.g POWERPC),
when transferring large amounts of data over the SP-Switch.
A kernel trace shows a looping of "resume interrupt process" and
"PROGRAM CHECK", which is burning up a lot of CPU. The problem
is that the instruction is a POWER instruction, which must be
emulated.
PROBLEM SUMMARY:
On non-POWER machines (e.g. POWERPC) a performance
problem can occur when the SP switch is under a very
heavy load.
PROBLEM CONCLUSION:
The switch IP kernel extension, if_ls, has been changed
to remove POWER instructions which must be emulated
on non-POWER machines (e.g. POWERPC), as emulating
instructions can cause a performance problem.
------
APAR: IY13276 COMPID: 576552900 REL: 240
ABSTRACT: IF_LS ATTEMPTS TO SEND PACKETS WITHOUT CORRECTLY CHECKING THE
PROBLEM DESCRIPTION:
In PSSP 3.1.1, AIX 4.3.3.02environment it has been detected
next error:
if_lscan attempt to send packets without correctly checking
the css interface flags.
This problem produces a dump when rebooting the node.
PROBLEM SUMMARY:
A node crash can occur when the switch kernel
extension, if_ls, attempts to send packets
before its data structures are initialized.
PROBLEM CONCLUSION:
The switch if_ls kernel extension has been
changed to
prevent a node crash from occuring when the IP driver
attempts to send before initializing its data
structures.
------
APAR: IY13726 COMPID: 576552900 REL: 240
ABSTRACT: SETUP_SERVER FAILS ON CWS INSTALLED WITH PSSP 3.2, IF IT IS
PROBLEM DESCRIPTION:
setup_server fails at at CWS installed with PSSP 3.2, if this
CWS is kerberos client of another CWS installed with PSSP 3.1.1
(or any other PSSP code below 3.2), because setup_server tries
to execute /usr/lpp/ssp/kerberos/etc/krunitrc at the kerberos
server. Since krunitrc is a new command in PSSP 3.2, it does
not exist at the kerberos server.
LOCAL FIX:
Copy /usr/lpp/ssp/kerberos/etc/krunitrc from PSSP 3.2 CWS to
the CWS, that is kerberos server.
PROBLEM SUMMARY:
When a PSSP 3.2 CWS is setup as a kerberos client of a
kerberos server that exists on a PSSP 2.4 or PSSP 3.1.1
system, setup_CWS will fail on the PSSP 3.2 CWS.
setup_CWS invokes /usr/lpp/ssp/kerberos/etc/krunitrc on
the kerberos server, but the script does not exist on
PSSP 2.4 and PSSP 3.1.1 systems. As a result the srvtabs
will not be able to be created on the PSSP 3.2 CWS.
PROBLEM CONCLUSION:
/usr/lpp/ssp/kerberos/etc/krunitrc will now be shipped
as part of PSSP 2.4 and PSSP 3.1.1. This will allow
a PSSP 3.2 CWS to be a kerberos client of a kerberos
server on a PSSP 2.4 or PSSP 3.1.1 system.
------
APAR: IY13930 COMPID: 576552900 REL: 240
ABSTRACT: SWITCH MICROCODE HAS NO SOURCE CONTROL INFO (NO 'WHAT' STRINGS)
PROBLEM DESCRIPTION:
Switch microcode has no source control info (no 'what' strings),
so the source file levels that the microcode is built on cannot
be determined.
PROBLEM SUMMARY:
The switch microcode binaries have no source control
information (no 'what' strings). The version number
cannot be determined from the object file and thus it
is difficult to determine what level of microcode the
customer has on his or her system.
PROBLEM CONCLUSION:
Source control information ('what strings') has been added
to the following microcode binaries:
/usr/lpp/ssp/css/tb3ucode
/usr/lpp/ssp/css/tb3ucode_DEBUG
/usr/lpp/ssp/css/tb3dump
/usr/lpp/ssp/css/tb3mx_ucode
/usr/lpp/ssp/css/tb3mx_ucode_DEBUG
/usr/lpp/ssp/css/tb3mxdump
/usr/lpp/ssp/css/tb3pci_ucode
/usr/lpp/ssp/css/tb3pci__ucode_DEBUG
/usr/lpp/ssp/css/tb3pcidump
------
APAR: IY13933 COMPID: 576552900 REL: 240
ABSTRACT: FS_DAEMON_BCAST_CMD() BUG CAUSES NODES TO ALWAYS SYNC SWITCH TOD
PROBLEM DESCRIPTION:
fs_daemon_bcast_cmd(KLOAD_ROUTES) does not correctly manage the
pkt field "sync_tod", causing some nodes (specifically, those
following a switch router - if one - in the list of active
nodes) to sync their TBIC TODS on every KLOAD_ROUTES. An
unavoidable race condition exists when >1 node on a chip syncs
it's TOD: if a switch chip receives >1 send-set-TOD cmd at
one time, a service CRC can result (typically, but not always,
recovered by the primary). Limiting the sync TOD operation to
required times greatly limits this exposure.
PROBLEM SUMMARY:
The code change eliminates unnecessary sync-TOD operations,
thus greatly reducing the number of send-set-TOD collisions
on leaf chips. (These collisions drive fault recovery on
the primary due to a service error from the chip.)
PROBLEM CONCLUSION:
The code has been fixed to set the sync_tod field for each
packet, because the pkt storage is reused.
------
APAR: IY14223 COMPID: 5648C9802 REL: 430
ABSTRACT: SDK 1.3.0 PTF 2 : CA130-20001025
PROBLEM DESCRIPTION:
Fixes since PTF 1 (ca130-20000824):
(Note: The Descriptions here have been truncated.)
+--------+------+---------------------------------------------+
|Build |Defect|Description |
+--------+------+---------------------------------------------+
|20000902|14688 |ListRseBundle getstring, getStringArray |
+--------+------+---------------------------------------------+
|20000918|13830 |JCChart does not show Pie charts correctly |
+--------+------+---------------------------------------------+
|20000918|14690 |Link 12755: SecureRandom data not ramdom with|
+--------+------+---------------------------------------------+
|20000918|22798 |JIT induced failure in Tivoli NetView for OS/|
+--------+------+---------------------------------------------+
|20000930|22600 |Caps lock does not work |
+--------+------+---------------------------------------------+
|20001018|23299 |command line removed from javacore |
+--------+------+---------------------------------------------+
------
APAR: IY14252 COMPID: 5765E2600 REL: 500
ABSTRACT: GENERAL MAINTENANCE FOR VATOOLS
PROBLEM DESCRIPTION:
This APAR is to allow for the updates of the files that make
up the vatools component of the VisualAge C++ Compiler.
PROBLEM SUMMARY:
Same as submitter's text
PROBLEM CONCLUSION:
This APAR is to allow for the updates of the
files that make up the vatools component of the VisualAge
C++ Compiler.
------
APAR: IY14273 COMPID: 576552900 REL: 240
ABSTRACT: SETUP_SERVER FAILURE WITH RETURN CODE OF 2 IN SUB
PROBLEM DESCRIPTION:
Defect 68863
There is an added function called check_lppsource that
was added to PSSP through APAR IY12866 (ssp.basic.3.2.0.4
or later). This function checks the supported NIM
LPPSOURCES listed on the NIM master or CWS to make sure
there are appropriate filesets avaialable, permissions
set correct, etc for Node installations.
There is a problem with the current implemtation of
this function. It currently fails when there is an
lppsource_name defined by NIM that does not have the
directory setup on the CWS.
Sample:
/usr/sbin/lsnim -t lpp_source
lppsource_aix433 resources lpp_source
lpp_source_ssp resources lpp_source
lpp_source_ssp was not created by setup_server, it was
created by Admin running 'smitty nim' ...
setup_server then fails this
setup_server: 0016-624 The lppsource directory
/spdata/sys1/install/lpp_source_ssp does not exist on
the control workstation, exiting.
setup_server: 0016-478: Error(s) found while trying
to change file modes.
Tickets destroyed.
setup_server: Processing incomplete (rc= 2).
A workaround should be a change line 876 in setup_server
from
$return_code = $SEVERE;
to
$return_code = $ATTENTION;
PROBLEM SUMMARY:
***********************************************************
* USERS AFFECTED: Users installing the PSSP system. *
* *
***********************************************************
* PROBLEM DESCRIPTION: *
*When a lppsource directory is defined by NIM, but doesn't*
*exist, setup_server issues the 0016-624 error message and*
*returns with return code 2 (abort). In practice, this *
*condition can happen when an install is done, and the *
*installer, to conserve space, has removed an old *
*lppsource tree. The abort is an overkill. Such *
*directories should be ignored and the installation *
*continued. *
***********************************************************
* RECOMMENDATION: *
* A corrected version of setup_server is provided in a *
* PTF release. *
***********************************************************
------
APAR: IY14529 COMPID: 5765E2600 REL: 500
ABSTRACT: VISUALAGE C++ 5.0.0.4 RUNTIME PTFS
PROBLEM DESCRIPTION:
VISUALAGE C++ 5.0.0.4 RUNTIME PTFS
PROBLEM SUMMARY:
Same as submitter's text.
PROBLEM CONCLUSION:
VISUALAGE C++ 5.0.0.4 RUNTIME PTFS.
------
APAR: IY14532 COMPID: 5697F6400 REL: 630
ABSTRACT: MESSAGECENTER PTF4 UPDATES
PROBLEM DESCRIPTION:
Updated MCIT Features
PROBLEM SUMMARY:
Updates to MessageCenter PTF 4
PROBLEM CONCLUSION:
Updates applied see info file for details
------
APAR: IY14555 COMPID: 5765C3403 REL: 430
ABSTRACT: HMT: SHIP README.HMT BY 11/22/00
PROBLEM DESCRIPTION:
README file for HMT support.
PROBLEM CONCLUSION:
README file for HMT support
------
APAR: IY14618 COMPID: 576552900 REL: 240
ABSTRACT: LATEST PSSP 2.4 FIXES AS OF NOVEMBER 2000.
PROBLEM DESCRIPTION:
Latest PSSP 2.4 fixes as of November 2000.
PROBLEM SUMMARY:
This is a packaging apar for PSSP 2.4 fixes as
of November 2000.
PROBLEM CONCLUSION:
This is a packaging apar for PSSP 2.4 fixes
as of November 2000.
------
APAR: PQ42777 COMPID: 5765C4200 REL: 320
ABSTRACT: SPTNQ/DPTNQ MAY PRODUCE INCORRECT RESULTS FOR N>4
PROBLEM DESCRIPTION:
ESSL quadrature subroutines SPTNQ and DPTNQ may produce wrong
answers for N>4 due to an internal variable which was not
initialized.
PROBLEM SUMMARY:
SPTNQ and DPTNQ may produce wrong answers for N>4 due to
an uninitialized internal variable.
PROBLEM CONCLUSION:
Codes updated to initialize internal variable.
------
APAR: PQ42778 COMPID: 5765C4200 REL: 320
ABSTRACT: FFT PERFORMANCE ENHANCEMENTS WITH SMP LIBRARY
PROBLEM DESCRIPTION:
ESSL FFT subroutines were not scaling well in SMP mode.
Internally, the number of threads to use was being incorrectly
calculated.
PROBLEM SUMMARY:
FFT subroutines do not scale properly in SMP
mode.
PROBLEM CONCLUSION:
FFT subroutines needed updating to properly
choose the number of threads in SMP mode.
------
APAR: PQ42779 COMPID: 5765C4200 REL: 320
ABSTRACT: ESSL ERROR MONITOR ISSUED MESSAGES WHEN PRINTING WAS SUPPRESSED
PROBLEM DESCRIPTION:
ESSL will print error messages that should have been suppressed
when the error count exceeded 32767.
PROBLEM SUMMARY:
ESSL was printing error messages when error
message printing was suppressed.
PROBLEM CONCLUSION:
The problem was that after 32767 messages,
the count of errors became negative which allowed the messages
to print. The error count is now capped at 256.
------
APAR: PQ42780 COMPID: 5765C4200 REL: 320
ABSTRACT: ADD NEW IOPT VALUES FOR SPPF AND DPPF TO LEAVE OUTPUT IN
PROBLEM DESCRIPTION:
In ESSL 312, a new output format for SPPF and DPPF was
introduced. A customer requested the ability to have the output
remain in lower-packed storage mode.
PROBLEM SUMMARY:
ESSL 312 introduced a new output format in
SPPF and DPPF. A customer requested an option to have the
output in the original lower-packed storage mode.
PROBLEM CONCLUSION:
IOPT=10 and IOPT=11 were added to SPPF and
DPPF. These correspond to IOPT=0 and IOPT=1 except that the
output will be left in lower-packed storage mode when using
IOPT=10 or IOPT=11.
------
APAR: PQ42781 COMPID: 5765C4200 REL: 320
ABSTRACT: LINPACK TPP SMP PERFORMANCE IMPROVEMENT ON S80 AND PSERIES 680
PROBLEM DESCRIPTION:
Performance enhancements needed for TPP benchmark(ESSL
subroutine DGETRF) on S80 and pSeries 680.
PROBLEM SUMMARY:
Performance improvements needed for TPP
benchmark on S80 and pSeries 680
PROBLEM CONCLUSION:
Improved the performance of DGETRF
------
APAR: PQ43035 COMPID: 5765C4200 REL: 320
ABSTRACT: FIX MISSING GLOBAL SYMBOLS FOR DBSTRF AND DBSSV WHEN USING
PROBLEM DESCRIPTION:
When using error recovery from C or C++, subroutines DBSTRF and
DBSSV do not have their revised global symbols exported.
ESVDBSTRF_ER and ESVDBSSV_ER are the missing symbols.
PROBLEM SUMMARY:
When using error recovery from C or C++ with
DBSTRF or DBSSV, the following global symbols are not found:
ESVDBSTRF_ER and ESVDBSSV_ER
PROBLEM CONCLUSION:
The global symbols list needed to be updated
with the missing symbols.
------
- Next message: AIX Service Mail Server: "Re: New_AIXV4_Fixes"
- Previous message: AIX Service Mail Server: "Re: Security"
- Next in thread: AIX Service Mail Server: "Re: New_AIXV4_Fixes"
- Maybe reply: AIX Service Mail Server: "Re: New_AIXV4_Fixes"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]