APAR: IC24886 COMPID: 5639A0901 REL: 310
ABSTRACT: FORCED PASSWORD CHANGE OPTION NOT WORKING IN ENTERPRISE

PROBLEM DESCRIPTION:
Under an Enterprise Management configuration when administrator
are registered from the Ent. Manager with the forced password
reset on the first login, the Managed servers did not honor the
option.
Test environment:
NT servers, 3.1.2.20 (Manager), 3.1.2.20 (managed server)
New admin defined through the configuration manager.
Notify the Managed server.
Check to see if the admin was on the managed server--it was.
Logged into the managed server and it did not force a password
reset eventhough the option was set on the configuration
manager.
Logged into the configuration manager using the same admin and
it did force me to reset.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of ADSM Server V3.1.2 and higher who are using
Enterprise Management.
****************************************************************
* PROBLEM DESCRIPTION: *
The FORCEPWRESET attribute of an administrator was not being
passed from the configuration manager server to the managed
server.
****************************************************************
* RECOMMENDATION: *
Apply the appropriate PTF when available.
****************************************************************
The ADSM Server has been changed to pass the FORCEPWRESET
attribute of an administrator to all managed servers.
Note that the administrator's password cannot be changed on the
managed server; it must be changed on the configuration manager
server. When an administrator attempts to log on to a managed
server with an expired password, the following message will
appear on the managed server's console:
ANR1714W The password for administrator <admin_id> has expired.
The password for this administrator must be updated on the
configuration manager server <server_name>.

------

APAR: IC25581 COMPID: 5639B2201 REL: 310
ABSTRACT: SERVER MAY CRASH DURING A VOLUME MOUNT OF A 3590 VOLUME IF THE S

PROBLEM DESCRIPTION:
Server may crash during a volume mount of a 3590 volume if the s
erver is not licensed for 3590 support. You will see the followi
ng traceback:
#0 0xef7634d4 in __sigprocmask ()
#1 0xef75b070 in _resetsig ()
#2 0xef75a934 in _sigon ()
#3 0xef75d548 in _thrp_kill ()
#4 0xef5ba4e8 in abort ()
#5 0x7e52c in AbortServer ()
#6 0x7efd0 in TrapHandler ()
#7 0xef762f28 in __libthread_segvhdlr ()
#8 <signal handler called>
#9 0xa28a54 in NtpOpLoadDisplay ()
#10 0x9d5e44 in NtpOpen ()
#11 0x5e55e8 in AgentThread ()
#12 0x7e630 in StartThread ()
The problem may also occur in FindBestFormat() instead of NtpOpL
oadDisplay() depending on the FORMAT setting of the device class
The problem seems to be that MmsMountVolume() can return rc=0
even if no volume has been mounted, and so the mmsDriveDesc
remains uninitialized.

LOCAL FIX:
Bring the server in compliance with license terms

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM NT, SUN, HP and AIX servers that are not compliant with
the licensing requirements for device support.
****************************************************************
* PROBLEM DESCRIPTION: *
The server may abend if the customer is not compliant with
the licensing requirements for device support.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The server will correctly report when a customer is not
compliant with the licensing requirements for device support.

------

APAR: IC27077 COMPID: 5697TSMAX REL: 110
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: IX88345 COMPID: 576556402 REL: 310
ABSTRACT: THE FORMAT OF THE ANR8808E MESSAGE IS NOT BEING DISPLAYED

PROBLEM DESCRIPTION:
The format of the ANR8808E message is not being displayed
correctly.
On 3.1.2.1:
02/23/1998 08:58:37 ANR8808E Could not write label xx on the ...
                     drive xx (/dev/rmtx) of library xx because
                     ... is already labeled with xx which i
s
                     still defined in storage pool or volume ...
(the "..." are for words that didn't fit on one line)
On 3.1.2.13:
03/01/99 16:20:41 ANR8808E Could not write label ASDF01 on ...
                   drive TAPE1 (/dev/mt0) of library 7331LIB ...
                   ... already labeled with TEST01 which is
<blank line>
                   defined in a storage pool or volume history.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
The TSM server platforms HP, SUN, AIX, and NT are affected
by this apar.
****************************************************************
* PROBLEM DESCRIPTION: *
The message ANR8808 had an imbedded tab character and other
incorrect spacing in the message. These errors in the
message cause it to not format correctly to the server
console or to an admin client. The formatting errors
do not prevent the message from being issued - it just
does not display well.
****************************************************************
* RECOMMENDATION: *
Apply the ptf that includes this apar fix once it is
available.
****************************************************************
The server message ANR8808 has been modified to remove the
imbedded tab character and other spacing problems.

PROBLEM CONCLUSION:
The server message ANR8808 had been altered incorrectly
resulting in incorrect spacing. The error in the message
caused it to not display well.

------

APAR: IY00827 COMPID: 576556402 REL: 310
ABSTRACT: DEFINE SCHED OR UPDATE SCHED PARAMETER CMD='CHECKING LIBVOL..."

PROBLEM DESCRIPTION:
Error was observed on AIX 4.3.2 (ADSM 3.1.2.20). Problem was
reproducable. Steps involved in reproducing the problem:
1. access to any AIX 4.2.X (or greater) box running ADSM
   3.1.2.20.
2. at admin command line-attempt to define any admin schedule
   with CMD="checkin libvol..."
3. error ANR 2775E DEFINE SCHEDULE or UPDATE SCHEDULE parameter
   CMD='checkin libvol...' not eligible for scheduling
   (ANS8001I return code 3)
  The same command will work on a solaris (2.5.1) box running
   ADSM 3.1.2.20 (problem appears to be specific to AIX 4.2 or
   4.3)

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
NT, HP and AIX server users scheduling administrative
commands such as CHECKIN LIBVOL
****************************************************************
* PROBLEM DESCRIPTION: *
Commands are not recognized as eligible for scheduling.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Server was changed to ensure command attributes were
picked up correctly.

PROBLEM CONCLUSION:
Server code was changed to ensure that command attributes
were correctly picked up.

------

APAR: IY03035 COMPID: 576556402 REL: 310
ABSTRACT: ISSUING HELP COMMANDS FROM THE COMMAND LINE OF THE WEB ADMIN

PROBLEM DESCRIPTION:
Help commands, issued from the command line of the Web Admin
interface, may cause the ADSM Server to abend. The traceback
from the core dump will resemble the following:
IOT/Abort trap in signal.pthread_kill [/usr/lib/libpthreads.a]
at 0xd02240b4 ($t120)
0xd02240b4 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1)
(dbx) where
signal.pthread_kill(??, ??) at 0xd02240b4
signal._p_raise(??) at 0xd022366c
raise.raise(??) at 0xd0013bac
abort() at 0xd000d330
AbortServer() at 0x10005f4c
TrapHandler(??, ??, ??) at 0x10005ca4
QueueData(0x6df484, 0x30883560, 0x7d0) at 0x100101fc
outWrite(??, ??, ??) at 0x1001258c
OutputHelp(??, ??, ??) at 0x10412240
AdmHelp(??) at 0x10412f00
AdmCommandLocal(??, ??, ??, ??, ??) at 0x100f0500
admCommand(??, ??, ??, ??, ??) at 0x100f112c
HtRunCommands(??, ??, ??) at 0x103426e4
htPostForm(??, ??, ??) at 0x10342d5c
SmHttpCommandThread(??) at 0x102a613c
StartThread(??) at 0x10005e54
pthread._pthread_body(??) at 0xd0219300
To recreate this problem:
   1. Log into the ADSM Server via the Web Admin interface
   2. From the Options taskbar, select "Show command line"
   3. From the command line, issue a HELP command (i.e. HELP
      QUERY ACTLOG, HELP QUERY VOLHIST, etc.). The problem is
      intermittent and therefore may require the HELP command to
      be issued a number of times before the abend occurs.
This problem has been recreated with the 3.1.2.20 version of the
ADSM Server running on AIX 4.3.X. This problem has not yet been
reproduceable on the NT, SUN or AIX 4.2.X platforms.

LOCAL FIX:
Do not issue any HELP commands from the command line of the Web
Admin interface.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All Tivoli Storage Manager Server levels, including
ADSM V3.1.2.x
****************************************************************
* PROBLEM DESCRIPTION: *
Issuing HELP commands from the command line of the WEB Admin
interface may cause the ADSM server to crash.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF when available.
****************************************************************
Issuing HELP commands from the command line of the WEB admin
interface may cause the ADSM server to crash.

PROBLEM CONCLUSION:
An internal buffer was being overwritten by 1 byte, causing a
pointer to become invalid.

------

APAR: IY03249 COMPID: 576556402 REL: 310
ABSTRACT: LOOP IN ADSM CS ADMIN SCHEDULER WHEN ADMIN SCHEDULE RUNS LONGER

PROBLEM DESCRIPTION:
In this case, customer has an admin schedule which runs a
script. This script runs multiple commands with wait=yes. This
is a long running script. This script runs for a 4-5 hours
while its schedule window is set to 1 hour.
When this script is started via an admin schedule, all other
admin schedules which are scheduled to run after that particular
schedule do NOT run and stay in a PENDING state until the long
running admin schedule completes and causes the CS ADMIN
SCHEDULER to loop.

LOCAL FIX:
There are 2 ways to fix this problem :
  1. use the "update schedule ..active=no" command on the
     long running schedule while it runs.
  2. Increase the schedule window for the long running schedule
     so that it completes within the window.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem can affect ADSM V3.1 or TSM V3.7 administrators
who use the administrative command scheduling facility.
****************************************************************
* PROBLEM DESCRIPTION: *
This problem can occur if a long-running administrative
command is scheduled and the command does not complete before
the end of the startup window. For example, this might occur
if the schedule involves one or more server processes that are
run in the foreground using the WAIT=YES option. If the startup
window ends while the command is still running, the server may
go into a tight loop and prevent other administrative
commands from being executed. This loop could also interfere
with other server operations.
****************************************************************
* RECOMMENDATION: *
This problem is fixed in a future PTF that should be applied
by customers who may be affected.
****************************************************************
The server may enter a loop if the startup window for an
administrative schedule expires while that schedule is
still running.

PROBLEM CONCLUSION:
Customers who schedule long-running administrative commands
that do not complete during the startup window may find that
other schedules are prevented from running. These customers
should apply the PTF when it becomes available.

TEMPORARY FIX:
This problem can be circumvented by extending the startup window
for long-running schedules so that the schedules are able to
complete before the end of the startup window. An alternative
circumvention would be to use the Update Schedule command to
deactivate each long-running administrative schedule once it
begins running.

------

APAR: IY03390 COMPID: 576556402 REL: 310
ABSTRACT: SERVER HANG DURING BACKUP STORAGEPOOL IF WAIT=YES OPTION IS USED

PROBLEM DESCRIPTION:
SERVER HANG DURING BACKUP STORAGEPOOL IF WAIT=YES OPTION IS USED
If a backup stg process is started in foreground the according
SmAdminCommandThread uses the function bfWaitRemainingCopyProcs
for synchronization with the backup threads. If this function
is called with an invalid handle it can loop (or even abend)
thru the global list of copy-control-blocks.Since it is holding
a mutex on BFV when processing this list it can block other
threads.

LOCAL FIX:
Use wait=no option on backup stg commands.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V310 and ADSM V312 server users. Also Tivoli Storage
Manager V370 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
The processing for BACKUP STORAGEPOOL with the WAIT=YES
parameter may hang and/or abend the server.
****************************************************************
* RECOMMENDATION: *
Apply the ptf that resolves this fix once it is available.
****************************************************************
The BACKUP STORAGEPOOL processing with the WAIT=YES parameter
has been altered. Specifically, the algorithm used to manage
waiting for completion when the WAIT=YES parameter is
specified has been altered to prevent a possible hang
condition or server abend. The nature of the problem
depends on timing between multiple threads on the server
and memory that is shared between those threads.

PROBLEM CONCLUSION:
The BACKUP STORAGEPOOL processing with the WAIT=YES parameter
was not sharing memory properly between threads. Because
of this memory sharing error the process could cause the
server to hang or else abend depending upon the state
and usage of the memory.

------

APAR: IY03519 COMPID: 576556402 REL: 310
ABSTRACT: DEFINES AND UPDATES MADE WITH THE WEB ADMIN DO NOT UPDATE

PROBLEM DESCRIPTION:
Any define or update that when done with the commandline
admin client would cause the devconfig file to be updated
do NOT cause the update if done through the web admin interface.
Tested define devclass and define drive, also update devclass
and update drive.
both NT and AIX servers tested at 3.1.2.40
If the define or update is done at the commandline the devconfig
file is update with the new parameters without doing a backup
devconfig command.
If the define or update is done with the web admin interface
the changes do show on the server however the devconfig
file is NOT updated. The backup devconfig option in the web
window does work correctly.

LOCAL FIX:
Do a backup devconfig from the options menu after changes of
this nature are made with the web interface.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This apar effects all users of ADSM, Tivoli ADSM and Tivoli
Storage Manager version 3.1.2.X or 3.7.X.X on all platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
Using the web interface to update or define device related
information, the device configuration file is not updated.
****************************************************************
* RECOMMENDATION: *
The current work around is to issue the command BACKUP DEVCONFIG
to force the device configuration to be updated. When the PTF
is available, apply the PTF to correct the fix.
****************************************************************
The problem with the device configuration not being updated when
device configuration has changed has been fixed. Install the
PTF when available.

------

APAR: IY03599 COMPID: 576556402 REL: 310
ABSTRACT: MANUAL DRIVES AND LIBRARIES DO NOT DISPLY IN THE WEB ADMIN WHEN

PROBLEM DESCRIPTION:
If customer uses the French language for the server messages
and attempts to display MANUAL libraries or drives they
recieve a no objects found. Following this path:
object view
     Server Stoage
          Libraries and drives
               Manual library or Manual Drive
If there are manual libraries or drives defined they display
correctly in the admin GUI and on the command line even in
the French language. Also using english they also display
correctly in the web admin interface. Only in the web admin
with French language do they fail to show.
This has been tested on 3.1.2.20, .30, and .40

LOCAL FIX:
use the normal GUI or command line admin client to work
with manual libraries or drives when using the French language.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of ADSM V3 Servers and TSM V3.7 Servers.
****************************************************************
* PROBLEM DESCRIPTION: *
'MANUAL' drives and libraries do not display in the WEB Admin
when server in French.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
The problem occurs only when the server is running in French
due to a translation issue on the server.
The WEB Admin was trying to match on a library type of
of 'MANUAL'.However, the server was incorrectly using
a French translated word, 'MANUEL' in its matching scheme.
It is correct for the server to only use the word 'MANUAL'
not 'MANUEL' in this case since it is a keyword for
library types.
The server has been updated to match on the correct keyword.

PROBLEM CONCLUSION:
Server code has been updated to match with the correct keyword.

------

APAR: IY03614 COMPID: 576556402 REL: 310
ABSTRACT: ADSM NOT FREEING MEMORY (TCPSENDSSL) PROPERLY.

PROBLEM DESCRIPTION:
Customer is receiving ANR9999D error which is causing the ADSM
server to crashed. Cust has AIX 4.3.2 with V3.1.2.40 ADSM server
Based on the provided doc, it only happens when registering a
new Web NODE.
ANR9999D pkshmem.c(309): Invalid attempt to free memory; called
         from 10436DE0 (tcpSendSSL).

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
all V3 ADSM servers
****************************************************************
* PROBLEM DESCRIPTION: *
Web Admin client does not free memory correctly
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available
****************************************************************
The customer had a Web admin client talking to a 3.1.2.20
server on an AIX 4.3.2 system. An error occurred, and the
server crashed while attempting to free memory used for
communication.

PROBLEM CONCLUSION:
Errors were found either freeing the communication buffer
or closing the secure socket in the Web communication code
code for AIX, HP, NT and SUN. Also the common module that
services Web admin clients did not check if an error occurred
while sending data: it continued sending data even though the
communication link may have failed. There problems have been
fixed.

------

APAR: IY03818 COMPID: 576556402 REL: 310
ABSTRACT: ADSM UNNECESSARILY DISMOUNTS VOLUMES AT END-OF-TAPE PROCESSING

PROBLEM DESCRIPTION:
When ADSM attempts to write a large file to the end of a tape th
that is approximately 100% full it dismount the tape, remounts t
the same tape,writes to the tape and continues to the next tape.
This dismount is unnecessary and degrades throughput.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of ADSM server who use sequential media
to store large files.
****************************************************************
* PROBLEM DESCRIPTION: *
During the storing of large client files, if the volume
became full the ADSM server would fail the mount of the
next volume because the mountwait flag from the client
had been reset to false; even though at the beginning
of the session the client had set the flag to true.
****************************************************************
* RECOMMENDATION: *
Apply ptf when available.
****************************************************************
The server now will look to see if it is allocating
a continuation volume because it just filled a volume
and needs to continue to another volume. In this case
it will continue even though the waitMount state flag
is false. This flag is set to true during the mounting
of the first volume and reset by the client during
subsequent transactions. We are now going to assume that
the client is willing to wait if continuation volumes are
needed.

PROBLEM CONCLUSION:
Volumes will no longer be dismount/remounted when the
eov is reached.

------

APAR: IY04315 COMPID: 576556402 REL: 310
ABSTRACT: WHEN YOU USE LANGUAGE FRENCH, THE WEB ADMIN DOES NOT DISPLAY THE

PROBLEM DESCRIPTION:
When using LANGUAGE FRENCH, the Web Admin gui does not display
the estimated capacity of sequential volumes. There is no
problem when using the command line. EXAMPLE....
object view->server storage->storage pool->
sequential access storagepools->volumes-> select one volume
and the est capacity is not displayed (there is a hyphen
instead of the value.)I have recreated on WINNT 4.0 3.1.2.40
server,and customer has recreated on AIX3.1.2.40 server.
NOTE: After additional testing, the above issue seems to
be related to the SQL engine. The missing fields are also
apparent from the command line when using the select command.
This was also tested on other lang, such as Italian and
Spanish.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V3.x servers, and TSM V3.7 servers at PTF 2 or earlier.
****************************************************************
* PROBLEM DESCRIPTION: *
When server running with LANGUAGE other than English, some
values in SELECT commands and in some output views from
WEB Admin Client does not display.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
When the server is running in a LANGUAGE other than English,
some values ( such as Estimated Capacity, Pct Util, Pct Migr,
Pct Logical, Max Pct Util, Cache Hit Pct, Cache Wait Pct, etc.)
 are not being displayed ( user's may see a
'-' hyphen) in the output from some SELECT commands or
viewing detailed information from the WEB Admin Client.
The problem is that the SQL Engine in the server is not
handling the number format for the different locales
appropriately.
NOTE:
Values are appropriately displayed from the 'QUERY' commands
issued from the server console command line, or WEB ADMIN
command line.

PROBLEM CONCLUSION:
Server code has been updated so that these values will
be displayed.

------

APAR: IY04323 COMPID: 576556402 REL: 310
ABSTRACT: FORMAT=DETAILED DOES NOT WORK FOR CLEANUP ARCHDIR COMMAND, ONLY

PROBLEM DESCRIPTION:
Ran the CLEANUP ARCHDIR command with FORMAT=D parameter adding
letters until I got to DETAIL. All attempts were successful.
Used FORMAT=DETAILE and FORMAT=DETAILED, both failed with
invalid parameter error. Readme for 3.1.2.40 states DETAILED
should work just like with a QUERY command.

LOCAL FIX:
Use any variation of this param between F=D and FORMAT=DETAIL.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
all ADSM v3 servers
****************************************************************
* PROBLEM DESCRIPTION: *
"clean archdir format=" accepts "detail" but not "detailed"
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available
****************************************************************
"clean archdir format=" accepts from 1 to 6 letters of
the word "detailed". It does not understand the 7th and
8th letters.

PROBLEM CONCLUSION:
Fixed the keyword constant.

------

APAR: IY04631 COMPID: 576556402 REL: 310
ABSTRACT: ERROR ADSM_DD_LOG2 (5680E405) LOGGED DURING TAPE DRIVE CLEANING

PROBLEM DESCRIPTION:
Permanent hardware error gets logged whenever tape drive
cleaning is performed: ADSM_DD_LOG2 (5680E405).
This logging is confusing to customers, as drive cleaning is
not a permanent hardware error. There should only be indication
that the drive is not ready for use while it is being cleaned.

LOCAL FIX:
ignore message

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Users who insert a cleaning cartridge into a DLT tape drive.
****************************************************************
* PROBLEM DESCRIPTION: *
ADSM_DD_LOG2 message is entered into the AIX error log
for a DD_CLEANER_INST condition. An ADSM_DD_LOG2 message
is a permanent hardware message type. This is incorrect.
****************************************************************
* RECOMMENDATION: *
REC_LINE.1
****************************************************************
DD_CLEANER_INST conditions will now be logged as
ADSM_DD_LOG6 messages. ADSM_DD_LOG6 is a warning/informational
message.

PROBLEM CONCLUSION:
DD_CLEANER_INST conditions will no longer be logged as
ADSM_DD_LOG2 messages for DLT tape drives.

TEMPORARY FIX:
Ignore the ADSM_DD_LOG2 message type for the DD_CLEANER_INST
condition.

------

APAR: IY04652 COMPID: 576556402 REL: 310
ABSTRACT: ADSM CHECKIN LIBRARY VOLUME AND QUERY PROCESS CAN RESULT IN

PROBLEM DESCRIPTION:
During ADSM checkin libvol processing under specific timing
conditions if a query process is issued a deadlock situation
on a process mutex can result. At this point processing on the
server begins to hang up as no other processes can begin. In
time the whole server may hang. The original customer reporting
the problem also experienced hardware problems on the drive
being used for the checkin which give this timing problem more
opportunity to occur.

LOCAL FIX:
Don't issue a query process when a checkin libvol is running.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
adsm servers on nt, aix, sun, and hp
****************************************************************
* PROBLEM DESCRIPTION: *
Server deadlocks when query process is issued immediately
after a checkin, checkout, label, or audit
****************************************************************
* RECOMMENDATION: *
Apply ptf when available
****************************************************************
Server should no longer deadlock during query process.

------

APAR: IY04693 COMPID: 576556402 REL: 310
ABSTRACT: ADSM SERVER DISPLAYS A MISLEADING ERROR MESSAGE WHEN

PROBLEM DESCRIPTION:
When /usr is out of disk space and the dsmserv process is
started, dsmserv displays:
Cannot write to adsmserv.lock : the ADSM server is already runni
ng.
This is missleading and should read:
Cannot write to adsmserv.lock or the ADSM server is already runn
ing.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All using an ADSM UNIX platform server. AIX, Solaris, HP/UX.
****************************************************************
* PROBLEM DESCRIPTION: *
If the dsmserv.lock file is unable to be created, locked or
written to, the message indicates the server is already
running. There are other reasons for the failure such as
permissions, full filesystems, no inodes, etc.
****************************************************************
* RECOMMENDATION: *
Add fixing PTF when available.
****************************************************************
Added strerror() call to get explanation for errno and include
that text in the message.

------

APAR: IY04825 COMPID: 576556402 REL: 310
ABSTRACT: LOGGING IN WITH INCORRECT PWD, AFTER PWD HAS EXPIRED, MESSAGE

PROBLEM DESCRIPTION:
When attempting to access the ADSM server via the NT Admin
client after the Admin password has expired, and using the
incorrect password, the user is prompted for the new password
instead of a valid message telling the user that the password
then entered was invalid.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
all ADSM and TSM server users
****************************************************************
* PROBLEM DESCRIPTION: *
Server tests for password expiration before authenticating
an admin. client.
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available.
****************************************************************
An admin client attempted to sign-on to an ADSM server with
an invalid password. The session was rejected because the
password happened to be expired. It should have authenticated
the client first.

PROBLEM CONCLUSION:
For admin, console and mount clients, the ADSM 3.1.2 and TSM
3.7 servers now authenticate the password first, then check
for password expiration.
For backup/archive clients, the ADSM 3.1.2. server also authen-
ticates before testing for password expiration. The TSM 3.7
server also authenticates first, but the "password expired"
message may be displayed on the server console before the
"invalid password" message.

------

APAR: IY05307 COMPID: 576556402 REL: 310
ABSTRACT: A COMBINATION OF EXCESSIVELY LONG MANAGEMENT CLASS NAMES OR

PROBLEM DESCRIPTION:
A Server hang condition can result if the connecting client's
assigned policy domain contains a large number of mgntclass and
copygroup entries. The problem was observed in an environment
where over 1000 mgntclasses and copygroups with names exceeding
22 characters each were all bound to a single policy domain.
The result was a failure of the server to return data after the
client began PSQry transaction. The server attemps to return
a verb that exceeds the MAX_VERB_LENGTH . This results in
an ANR7834S Thread 13 terminating on signal 11 (segmentation
violation) The sever hangs and has to be killed externally with
signal -9 to recover.
Additional information regarding this problem is that error:
ANR7837S Internal error SMSESS003 detected.
may be seen on the console if the server is running in the
foreground or may be found in the dsmserv.err file.
The server may crash instead of hang, the crash may produce a
core dump with a traceback that is similar to:
A trace with txn and session flags should show the server
failing after receiving a PSQry:
Recv Verb: Session 3, Length=16, Code=00A0, Type=PSQry.

LOCAL FIX:
Reduce the number of managment classes and the length of the
management class names.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All 312 and 370 platforms
****************************************************************
* PROBLEM DESCRIPTION: *
A domain with an extremely long policy set will cause the
server to hang or abend when a backup/archive client connects.
The long policy set can be created by and extremely large
number of management classes, a large number of management
classes with long descriptions for the management classes or
copy groups.
****************************************************************
* RECOMMENDATION: *
Install the PTF
****************************************************************
On the 3.1.2 level of the server, a message will be issued
(ANR0917) that indicates the policy is too long, and the
client session will fail with a message indicating a policy
could not be found.
On the 3.7.0 level and beyond of the server, the action will
depend on the client. If the client has the associated PTF
installed, the long policy will be successfully processed. For
clients without the PTF, the behavior will be identical to
the 3.1.2 version.

PROBLEM CONCLUSION:
On the 3.1.2 level of the server, a message will be issued
(ANR0917) that indicates the policy is too long, and the
client session will fail with a message indicating a policy
could not be found.
On the 3.7.0 level and beyond of the server, the action will
depend on the client. If the client has the associated PTF
installed, the long policy will be successfully processed. For
clients without the PTF, the behavior will be identical to
the 3.1.2 version.

------

APAR: IY05341 COMPID: 576556402 REL: 310
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: IY05435 COMPID: 576556402 REL: 310
ABSTRACT: CONFIGURATION REFRESH FAILS FOR ADMINS HAVING RESTRICTED AUTHORI

PROBLEM DESCRIPTION:
Configuration refresh fails for admins having restricted authori
ties. To recreate:
- define an admin on your config manager
  e.g. reg admin test test
- set authority to a class different to system
  e.g. grant auth test call=policy domain=test
- make a profile association for this admin
  e.g. define profassoc test admins=test
- Subsribe on a managed server to this profile
- Perform a notify subsribers on the config manager
- On the managed server you will see the following message:
10/28/99 15:19:12 ANR3152I Configuration refresh started with
                      manager BACH.
10/28/99 15:19:12 ANR9999D admadmin.c(3297): Missing row for
10/28/99 15:19:13 ANR3151E Configuration refresh failed with
                      manager BACH.
I could recreate this problem on 3.1.2.40 servers. Using a
3.7.0.1 server as managed server reveals the same problem.

LOCAL FIX:
Define the admins locally.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem may affect customers who use the enterprise
configuration feature in certain service levels of the ADSM
3.1.2 server.
****************************************************************
* PROBLEM DESCRIPTION: *
A memory-overlay problem was introduced in level 3.1.2.30 of
the ADSM server. This problem occurs only during configuration
refresh processing of profiles with associated administrator
definitions. The program error occurs on the configuration
manager, but the symptoms can occur either on the configuration
manager or on a managed server. If an NT server is used as
a configuration manager, this error can cause the configuration
manager to abort. If an AIX server is used as a configuration
manager, the error can cause refresh processing to fail and
an error message such as the following is produced on the
managed server.
  ANR9999D admadmin.c(3297): Missing row for admin .
Symptoms of this problem could be unpredictable and may
vary depending on the platform of the configuration manager.
****************************************************************
* RECOMMENDATION: *
This problem was identified and fixed as an internal defect
in the ADSM 3.1.2.50 server PTF. Customers who use
enterprise configuration should update their configuration
managers to 3.1.2.50 or later.
****************************************************************
A memory overlay problem can cause unpredictable results
during refresh processing of profiles that have associated
administrator definitions. This problem affects ADSM server
levels begining with 3.1.2.30, and is fixed in 3.1.2.50.
Tivoli Storage Manager V3.7 is not affected by this problem.

PROBLEM CONCLUSION:
Customers who use the ADSM 3.1.2 server as a configuration
manager should apply service level 3.1.2.50 or later.

TEMPORARY FIX:
This problem can be circumvented by using the
DELETE PROFASSOCIATION command to remove all profile
associations for administrator definitions.

------

APAR: IY05753 COMPID: 576556402 REL: 310
ABSTRACT: HIGH CPU USAGE CAN RESULT IN THE BUFFER PRE-FETCHER UTILIZING LA

PROBLEM DESCRIPTION:
In a condition where the ADSM server is running under very high
CPU load the buffer prefetcher can become starved and begin to
consume large sums of physical memory. The ultimatly results in
a depletion of real memory and excessive paging that will
eventually result in and ADSM server failure.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM 3.1.2 and 3.7.0 users.
****************************************************************
* PROBLEM DESCRIPTION: *
Data base buffer prefetcher can use too much memory if the
thread servicing the prefetch requests can not service the
requests as fast as the other threads in the server can create
the requests.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Added limits on the number of outstanding prefetch requests.
Also added a new server option NOBUFPREfetch which will
disable the buffer prefetcher if this keyword is found in the
server options file.
ADDITIONAL KEYWORDS: PreFetcher

------

APAR: IY05795 COMPID: 576556402 REL: 310
ABSTRACT: UNDER RARE CONDITIONS DURING OFFSITE RECLAMATION PROCESSING THE

PROBLEM DESCRIPTION:
During ADSM server offsite reclamation processing the ADSM
server may hang. If the physical volume being reclaimed is
offsite such that the server is using the primary storage pool
copy of the objects and one of those objects still exists as a
cached copy on a disk pool, then an aggregate lock may be
obtained which is not released. This lock is obtained in share
mode by the search thread of expiration processing. When the
actual data movement thread then needs the exclusive lock it
cannot be obtained and the process will hang. Because this
process can in turn hold other locks (which it cannot free)
other processes and session can hang behind it. Eventually the
whole server can appear to be hung.

LOCAL FIX:
Turn off caching in your disk storage pools. Before all cached
data we would be overwritten to ensure that this problem
could not occur the whole diskpool whould need to be filled.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM users
****************************************************************
* PROBLEM DESCRIPTION: *
There is a possibility that offsite reclamation may hang due
to a locking problem. This is unlikely to happen. In one
error path there are locks that could be obtained without
being released.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF when available.
****************************************************************
Fixed the error path to make sure the locks are released.

------

APAR: IY06004 COMPID: 576556402 REL: 310
ABSTRACT: ANR9999D MESSAGE INCORRECT: EXPIRATION CONTINUES

PROBLEM DESCRIPTION:
During expiration, receive several of these messages:
  ANR9999D imutil.c(2869): Lock acquisition (xLock) failed
  for Inventory node 257.
  ANR9999D imexp.c(4222): Object 0.118599291 could
  not be deleted - expiration will continue.
As the expiration does complete and further diagnostics
is not required; these should be more meaningfull messages
perhaps warning messages.

LOCAL FIX:
Messages can be ignored - expiration will continue

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM Version 312 server users and Tivoli Storage Manager
Version 3.7 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
Expiration processing may issue an ANR9999D message
indicating that a given file could not be deleted if an
error was encountered while trying to delete the file.
There may also be ANR9999D messages issued from imutil.c
indicating that locks in the inventory could not be
obtained. In this case, expiration kept on processing
and completed. These messages are extraneous.
****************************************************************
* RECOMMENDATION: *
Apply the ptf that resolves this fix once it is available.
****************************************************************
The ANR9999D messages issued for failed lock acquisition
which are indicated by "ANR9999D (imutil.c)" for
lock acquisition failed.
Specifically for expiration, message ANR0484W was added.
The message text is as follows:
ANR0484W Expiration failed to delete <FILE TYPE> file
<FILE NAME> for node <NODE NAME> and filespace <FILESPACE
NAME> - file will be skipped.
Explanation: The expiration process was unable to delete the
indicated file. The file will be skipped by expiration.
System Action: The expiration process continues.
User Response: Re-try expiration to determine if the cause
of the deletion failure was an intermittent problem or if
it is a permanent problem. If after a subsequent expiration
attempt the file still fails, please contact your service
representative.

PROBLEM CONCLUSION:
The expiration process has been altered to issue an official
message in the case where the expiration process is not
running with the quiet option set to on. The lock
acquisition failure messages have been converted to
trace messages.

------

APAR: IY06156 COMPID: 576556402 REL: 310
ABSTRACT: DELETE VOLUME HISTORY WHEN USING THE TOTIME PARAMETER CAN GIVE

PROBLEM DESCRIPTION:
Unexpected results can occur when attempting to delete volume
history records from an ADSM/Tivoli Storage Manager server
using the totime parameter if the records being deleted are
from a date prior to a time change. For example:
- After a forward change in time (spring)
  A query volhist will show a time of 10:00
  A delete volhist totime=10:00 (for the given day) will not
    delete the entry
  A delete volhist totime=11:00 (for the given day) will delete
    the entry
For a change back in time (fall)
  A volume history entry shows a time of 10:00
  A del volhist totime=9:00 (for the given day) will delete the
    entry even though the time was correct.
It appears that the relative time being stored for the date/time
of the volhist entry when compared against a time converted
from a different "hour in the day" reference (before or after
a time change) is going to be plus or minus 60 minutes off
depending upon whether the time change was forward or backward.
The server needs to account for this time change in some way
so that the time in the output from a query volhist is
relative to the current days time.

LOCAL FIX:
Don't use the totime option if it is not absolutely necessary.
If is it necessary make sure to add 60 minutes if the entry is
prior to a time change forward or subtract 60 minutes if the
entry is prior ot a time change back.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V312 Servers and TSM V3.7 Servers.
****************************************************************
* PROBLEM DESCRIPTION: *
'DELETE VOLUME HISTORY' when using the 'TOTIME' parameter can
give inconsistent results after Daylight savings time change.
****************************************************************
* RECOMMENDATION: *
Apply Fixing PTF when available.
****************************************************************
The Server was not accounting for Daylight Savings Time when
converting a local time to Universal Time.

PROBLEM CONCLUSION:
The ADSM/TSM Server code has been updated to fix the problem.

------

APAR: IY06424 COMPID: 576556402 REL: 310
ABSTRACT: ANR9999D ERROR POSITIONING SERVER VOLUME FOR VIRTUAL VOLUMES AFT

PROBLEM DESCRIPTION:
For virtual server volumes it is documented that the archive
copy group of the default management class for the source server
specifies the storage pool for the data from the source server.
If this management class changes (eg from STANDARD to MARSA_MC)
the virtual volumes are no longer accessible. The following
message will get reported:
ANR9999D pvrserv.c(600): Error positioning SERVER volume
DRS.BFS.xxxxxxxxx to x:x.
An AUDIT volume will report
ANR2335W Audit Volume has encountered an I/O error for
volume DRS.BFS.xxxxxxxxx while attempting to read: Node
xxxx, Type Archive, Filespace /xxxxxxxxxx, File Name
/xx/xx/xx/xxxxx/ xxxxxxxx.xxxxxx.
No error is reported at the target server.
A session trace from the source server will report:
smserv.c(4517): ARCHIVE QUERY failed, NO MATCH.
A trace with traceflags ARCHD ARCHQ ARCHQD on the target server
shows:
<42>smtrans.c(552): Recv Verb: Session 844, Length=110,
                    Code=0046, Type=ArchQry.
<42>imarqry.c(388): sess: node(MARSA), nodeId(a), owner(MARSA)
<42>imarqry.c(392): qry: nodeId(a), fsId(1), objType(2),
                    owner(MARSA)
<42>imarqry.c(398): hl(MARSA/DRS.BFS.920985009), ll(BFS.OBJ.4)
<42>imarqry.c(401): descr( X)
<42>imarqry.c(402): isConverted(0), qryByObject(1), type(0),
                    cgId(1), mcId(30), ordering(1)
<42>imarqry.c(406): insLower(0/0/0 0:0.0),
                     insUpper(255/255/255 255:255.255)
<42>imarqry.c(414): expLower(0/0/0 0:0.0),
                     expUpper(255/255/255 255:255.255)
<42>imarqry.c(530): (a:1) objType(2), hl(23), ll(9), columns(6)
<42>imarqry.c(2279): (a:1) objType(2),
                     hl(MARSA/DRS.BFS.920985009), ll(BFS.OBJ.4)
<42>imarqry.c(2282): (a:1) objId(0.19c5b) descr(3)
<42>imarqry.c(647): (a:1) changing arch search from objType (2)
                     to (2)
<42>imarqry.c(963): (a:1) examined directories(0), files(1),
                    descriptions(0)
<42>smtrans.c(641): Push Verb: Session 844, Length=6, Code=0013,
                    Type=EndTxn.
The hex object 19c5b translates to 105563
   adsm> show invo 0 105563
   OBJECT: 0.105563 (Archive):
     Node: MARSA Filespace: ADSM.SERVER.
    MARSA/DRS.BFS.920985009 BFS.OBJ.4
     Type: 2 CG: 1 Size: 0.788266904 HeaderSize: 213
  ARCHIVE OBJECTS ENTRY:
  ADSM.SERVER : MARSA/DRS.BFS.920985009 BFS.OBJ.4 (MC: STANDARD)
  Inserted 03/09/99 13:29:02
  EXPIRING OBJECTS ENTRY:
     Copy Type: Archive
     MC: 15 CG: 1
     BaseDate: 03/09/99 13:29:02
The mangement classes used for the QUERY (30X) and stored with
the object (15X) translate to MARSA_MC and STANDARD.

LOCAL FIX:
manipulate the DOMAIN to have the MC active that was active
when the virtual volume got generated.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V312 Server users and TSM V37 Server users where
virtual volumes are being used and the default management
class for the node on the target server has been changed.
****************************************************************
* PROBLEM DESCRIPTION: *
If the default management class on the target server for the
node representing the source server is changed, any data
for virtual volumes previously stored on the target server
will not be addressable. Specifically, the virtual volumes
on the source server will exhibit errors positioning on the
virtual volumes that have archive files bound to the previous
default management class.
****************************************************************
* RECOMMENDATION: *
Apply the ptf that resolves this problem once it is
available.
****************************************************************
The ADSM Server and the TSM server have been modified to
allow virtual volume processing to work where the
default management class on the target server has been changed.

PROBLEM CONCLUSION:
The virtual volume process does not work when the default
management class on the target server is changed. The virtual
volume processing was always looking for files under the
current default management class while files could have
actually been bound to a different management class.

------

APAR: IY06778 COMPID: 576556402 REL: 310
ABSTRACT: MULTITHREADED EXPIRATION RUNS VERY SLOWLY, BITFILES EXAMINED

PROBLEM DESCRIPTION:
Multithreaded expiration perfomance is very slow.
Recreate:
After tuning on bufpool and isolating the DB volumes,
expiration continues to perform poorly. When all activity
is stopped and only expiration is run for a 10 minute period
the 'examined' count only rose by 3 with no addtional objects
being deleted. During a 4 minute period the database had
354,383 requests of which 82% were in cache but only 1 archive
object was examined.
During most periods of activity, processes and sessions run to
completion while expiration continues to run slowly; this
results in an incrementally increasing size of database (since
data is not being expired in a timely manner)
Review of IMEXP trace shows the following:
15:54:29.780 <114>imexp.c(1565): Expiration Examining the folowi
   (41)(2)(2)(1)(24)(99/9/25 20:58)(0.181778857)
16:44:18.957 <114>imexp.c(1565): Expiration Examining the folowi
   (41)(2)(2)(1)(24)(99/9/25 20:58)(0.181778858)
17:31:41.670 <114>imexp.c(1565): Expiration Examining the folowi
   (41)(2)(2)(1)(24)(99/9/25 20:58)(0.181778859)
18:14:58.209 <114>imexp.c(1565): Expiration Examining the folowi
   (41)(2)(2)(1)(24)(99/9/25 20:58)(0.181778860)

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM Version 3 server users OR Tivoli Storage Manager
Versions 3.7 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
Expiration may run slowly when expiring ARCHIVE files.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing this fix once it is available.
****************************************************************
The expiration algorithm has been altered to improve
it's performance while expiring archive files and directories.
The first change to the algorithm is a new parameter
on the "EXPIRE INVENTORY" command. The parameter is
"SKIPDIRS". The minimum abbreviation is the first
two letters of the parameter or just "SK". The
parameter accepts either a "YES" or "NO" for the
value. So, to specify this parameter on the
"EXPIRE INVENTORY" command, examples are:
"EXPIRE INVENTORY SKIPDIRS=YES" In this case,
expiration would run and for any DIRECTORY type objects
stored on the server, expiration would skip those objects.
So, even if the directory was eligible to be expired based
upon the policy criteria, the object would be skipped because
this parameter was specified.
"EXPIRE INVENTORY SKIPDIRS=NO" In this case, expiration
will process as it does today - it will expire any
possible files or directories based upon the appropriate
policy restraints.
By allowing expiration to skip directories this will help
customers to keep reclamation processing working. Typically,
the file objects are likely to be taking up space on
sequential media (where this is the storage pool configuration
that a customer is using.). By allowing expiration to
expire the file objects, we free up more of the sequential
media space and allow reclamation to continue having tapes
to reclaim.
The other change to the expiration algorithm is in the
underlying object deletion code that the server uses.
After evaluating the deleting algorithm, it was determined
that there were a number of database calls and operations
that were redundant. By re-structuring the code and
streamlining this algorithm, many of these redundant
operations were eliminated.

PROBLEM CONCLUSION:
The expiration algorithm was experiencing a performance
degradation while expiring archive objects. In particular,
the algorithm was slowing down while trying to
determine if "directory" archive objects could be deleted.
The expiration algorithm has been modified to allow
it to skip directory objects. By skipping directory
objects, we circumvent the problem that was causing the
expiration process to slow down.
The problem with deleting archive directories, is that we do
not delete the object if there are still files dependent
upon that directory reference. So, to delete an archive
directory, we needed to see if ANY files referenced that
directory using another set of database calls. This
other set of database calls is where the extra time was
being spent.
The server development group is currently prototyping
a new method of tracking archive directories and archive
descriptions themselves. Until this new method is available
all that is possible is to circumvent the cause of the problem
which is what this code addresses.

------

APAR: IY07132 COMPID: 576556402 REL: 310
ABSTRACT: EXTERNAL LOG FILE CREATED BY DSMULOG SHOWS A 3 DIGIT DATE

PROBLEM DESCRIPTION:
The activity log output produced from the dsmulog utility
displays dates in yyymmdd format for dates after December 31,
1999. For example the date displayed for December 31,1999 is
shown as '991231' and the date displayed for January 1,2000 is
shown as '1000101'. This display does not affect server
operations and the activity log displayed with the 'query
actlog' is displayed correctly.
This was reproduced on 3.1.2.50 and 3.7.1.0 server levels.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM v3.1.2 AIX servers and TSM v3.7 servers on
AIX platform only.
****************************************************************
* PROBLEM DESCRIPTION: *
The activity log output produced from dsmulog utility displays
dates after December 31, 1999 in incorrect format.
****************************************************************
* RECOMMENDATION: *
Apply a fixing PTF when available.
****************************************************************
The log output produced from the dsmulog utility
displays dates in incorrect yyymmdd format for dates
after December 1999.
 For example, the date displayed for December 31,1999 is
shown as '991231' and the date displayed for January 1,2000
is shown incorrectly as '1000101'.

PROBLEM CONCLUSION:
The code was fixed to display the date in correct yymmdd format.

------

APAR: IY07203 COMPID: 576556402 REL: 310
ABSTRACT: RETRIEVING FILES THAT SPAN SIDES OF OPTICAL MEDIA FAILS.

PROBLEM DESCRIPTION:
Some files that span sides of optical media fail on retrieve.
The failing file must have a mulitple segments with the first
segment being smaller than the last byte to retrieve from the
second segment.

LOCAL FIX:
Mark the optical volume containing the spanned file as
'unavailable'. This will cause retrieval of the file from
a backup copy if available.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM customers that use optical media in a storage pool.
****************************************************************
* PROBLEM DESCRIPTION: *
When a file that is stored on optical media and spans sides
media there is a possiblity that retrieving the file may
fail.
****************************************************************
* RECOMMENDATION: *
Apply the ptf when available.
****************************************************************
The failure occurs when the following are true:
1. file spans sides of optical media
2. first byte to retrieve is on one side and the last
   byte is on the second side.
3. the offset of the last byte into the second side
   is larger the the segment of the file on the first side.
Code changed to perform correct calculation of number of
bytes from each side to retrieve.

PROBLEM CONCLUSION:
Coded fix to improper file retrieval.

------

APAR: IY07226 COMPID: 576556402 REL: 310
ABSTRACT: ADSMSERV.MIB RETURNS INCORRECT ENTERPRISE ID

PROBLEM DESCRIPTION:
ADSM SNMP agent configured as per doc (GC35-0274-02, pp382-388)
allows ADSM to send SNMP traps to a netview box, but traps are
not "recognized" by netview.
Review of logs indicate that the ibmAdsm Enterprise ID:
1.3.6.1.4.1.2.6.135 which can be retrieved from the adsmserv.mib
is the same found in the mibbrowser after loading the mib.
However, traps sent by ADSM are not sent with the Enterprise ID

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM SNMP subagent users.
****************************************************************
* PROBLEM DESCRIPTION: *
Traps sent from ADSM to an SNMP manager are tagged
with the DPI subagent's enterprise id instead of the
ADSM enterprise id.
****************************************************************
* RECOMMENDATION: *
Apply the ADSM ptf that contains the fix.
It is also necessary on AIX to apply the AIX fix for APAR
IY08838.
****************************************************************
ADSM code was changed to supply the ADSM enterprise id
when an SNMP trap was sent. This change requires
the AIX fix for APAR IY08838 to be effective.

PROBLEM CONCLUSION:
Apply this fix and the fix for AIX APAR IY08838.

------

APAR: IY07233 COMPID: 576556402 REL: 310
ABSTRACT: WEB ADMIN SUGGESTS INCORRECT BEGINDATE WHEN SELECTING

PROBLEM DESCRIPTION:
This seems to be a Y2K bug ...
When selecting 'OBJECT VIEW' / 'SERVER' / 'ACTLOG' from Web
Admin, the suggested begin and end dates are for the current
month plus one.
Example: on 01/06/2000 the suggested date is 02/06/2000
This problem was reproduced on AIX 3.1.2.50 server. It is NOT
present on AIX V3.7 server, and also NOT on NT 3.1.2.50.
Customer support just informed me that they observed and
recreated the problem on OS/390 platform.
Update:
This problem will affect all suggestions made by the system
for date entries, e.g. also the defile schedule actions. If
customer does not overtype the suggested date, the schedule
will start one month later.
There is no indication, however, that the date will be
handled wrong once it is entered, i.e. if 02/06/2000 is not
modified, it will be handled as Feb. 06 - if the date is
changed to 01/06/2000 this will really be treated as Jan. 06.

LOCAL FIX:
Overtype suggested month or use command line.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM 3.1.2.50 servers and TSM V3.7 servers.
All platforms except WinNT.
****************************************************************
* PROBLEM DESCRIPTION: *
Web admin suggests incorrect begin date when selecting
'object view' / 'server' / 'activity log'.
SQL queries involving the current date return the current
date plus one month.
****************************************************************
* RECOMMENDATION: *
Apply the ptf when available.
****************************************************************
The underlying problem is the ID/SQL engine. If the following
SELECT statement is run from any admin client, the server
will return the date for the current month plus one:
select formatdatetime (current_date,'USA') from status
Please note that this is **NOT** a Y2K bug. A defect was
introduced into level 3.1.2.50 of the server which
causes the SQL engine or the Interface Driver to return
the current date plus one month. The 3.1.2.50 NT server is
not affected by this problem. The most probable reason for
this is that the PTF which was shipped to customers was
built using a 3.1.2.50 source tree with some downlevel code
in it.

PROBLEM CONCLUSION:
The current date returned by the SQL engine and the date
used by the rest of the server are entirely separate. This
problem is restricted to the Interface Driver and the SQL
engine. It will not affect expiration of files. This can
be verified by issuing a SHOW TIME command to the server.

TEMPORARY FIX:
The incorrect date shown in the activity log form of the Web
admin client can be circumvented by deleting the suggested
date and entering the correct date.
The underlying SQL query problem with current dates cannot be
circumvented.

------

APAR: IY07274 COMPID: 576556402 REL: 310
ABSTRACT: SNMP SUBAGENT ONLY WORKS WHEN TRACING IS ENABLED

PROBLEM DESCRIPTION:
In some instances, the adsm snmp agent will only function when
snmp (traceflags: snmp systime) tracing is enabled.

LOCAL FIX:
run with tracing enabled

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using the ADSM or TSM SNMP subagent,
dsmsnmp on AIX systems.
****************************************************************
* PROBLEM DESCRIPTION: *
The SNMP subagent may not complete initialization unless
the -trace flag is used when invoking dsmsnmp.
This applies only to the AIX version.
****************************************************************
* RECOMMENDATION: *
Apply the PTF which contains the fix.
Alternatively, use the -trace flag when invoking
dsmsnmp.
****************************************************************
On AIX systems, dsmsnmp may not initialize
unless the -trace flag is specified when invoking
dsmsnmp. dsmsnmp is not completely initialized unless
the message "TCP/IP Drive ready for connections" is
displayed.

PROBLEM CONCLUSION:
Defective logic was removed.

TEMPORARY FIX:
Use the -trace flag when invoking dsnsnmp as in
dsmsnmp -trace

------

APAR: IY07355 COMPID: 576556402 REL: 310
ABSTRACT: PARTIAL OBJECT RETRIEVE MAY SEND LESS BYTES THAN REQUESTED

PROBLEM DESCRIPTION:
Partial object retrieve may send less bytes than requested.
The problem seems to be that the number of bytes being sent
to the client is erroneously calculated in SmSendData()
depending on what the objectHeaderSize is set to.
In a server trace wou will see output similar to the following:
<33>sstrans.c(2886): Sink sending 3 bytes.
<33>smtrans.c(1224): Send Verb: Session 376349, Length=7, Code=
0052, Type=PartialObjData.
where the later trace line is missing in this failing case (it
just indicates what you could expect to see).
The problem occurs on server code levels 3.1.2.42, and 3.1.2.50,
but not on 3.1.2.20

LOCAL FIX:
Use a different offset for retrieve on your application.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All applications using the ADSM client api to perform
partial object retrieves.
****************************************************************
* PROBLEM DESCRIPTION: *
Partial object retrieves would fail given certain offsets.
****************************************************************
* RECOMMENDATION: *
Apply ptf when available.
****************************************************************
A fix to another apar caused the server to perform checks not
valid for partial object retrieves. These checks would skip
upto 4 bytes of client data before returning any data at all.

PROBLEM CONCLUSION:
Recoded so that the check is not performed when a partial
object retreive is performed on behalf of a client.

------

APAR: IY07356 COMPID: 576556402 REL: 310
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: IY07365 COMPID: 576556402 REL: 310
ABSTRACT: SCRIPT IS LIMITED TO 2000 BYTES WHEN UPDATING WITH TSM 3.7.1.0

PROBLEM DESCRIPTION:
When updating a script while using the TSM 3.7.1.0 web admin,
it errors with
Server Error / A internal error was encountered on the
server. / Please contact your server administrator.
In the actlog you get:
ANR9999D htpost.c(323): HT engine POST error: input line was
2073 bytes long.
IF make the script 2000 bytes or less, the web admin with update
with success.
Recreate:
after loading the sample scripts (DSMSERV RUNFILE SRCIPTS.SMP)
I've opened a WebAdmin session.
> Operation View > Automate Operations > Update a command script
Then I selected the first one,BKUP_STG_DB and copied the first
ntline (/* --- ... ---*/) three times into the script > Finish.
That gives : Server Error / A internal error was encountered on
server. / Please contact your server administrator.
and in the actlog:
ANR9999D htpost.c(323): HT engine POST error: input line was 20
73 bytes long.

LOCAL FIX:
Use the TSM command line to update the script.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This APAR effects users of ADSM 3.1.2.X and TSM 3.7.X.X on
NT, AIX, HP, SUN, and MVS server platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
Scripts entered via the TSM Web Administrator interface are
limited to 2000 characters.
****************************************************************
* RECOMMENDATION: *
Use the command line to update until PTF is available or keep
script sizes small. Apply PTF when available.
****************************************************************
The limit on the number of character that can be enter in a
script via the TSM web administrator interface has been raised
from 2000 Bytes to 1 MB.

------

APAR: IY07426 COMPID: 576556402 REL: 310
ABSTRACT: WHEN REMOVING A NODE NAME THAT WAS REGISTERED W/ USERID= PARM,

PROBLEM DESCRIPTION:
When removing a node name that was registered w/ the USERID=
parameter, there is no message indicating that the ADMIN userid
is not being removed.
adsm> reg node tttt tttt userid=qqqq
ANR2060I Node TTTT registered in policy domain STANDARD.
ANR2099I Administrative userid QQQQ defined for OWNER access to
node TTTT.
adsm> remove node tttt
ANR2061I Node TTTT removed from policy domain STANDARD.
Customer believes that there should be some type of
message indicating that the ADMIN userid that was defined
as OWNER access for that node is not being removed.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All Tivoli Storage Manager V3.7 and ADSM V3 Servers.
****************************************************************
* PROBLEM DESCRIPTION: *
When removing a node name that was registered with non default
administrator id no warning message is issued indicating
that the admin user id not removed.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF when available.
****************************************************************
No warning message is issued to indicate that the admin userid
is not removed when a node is removed which was registered
with the non-default admin user id. The default admin userid
is the same as the node name.

PROBLEM CONCLUSION:
The server code has been updated to display a warning
message.

------

APAR: IY07446 COMPID: 576556402 REL: 310
ABSTRACT: ANR9999D MMSSCSI.C ELEMENT ADDRESS MISMATCH ADIC VLS 4MM. THE LI

PROBLEM DESCRIPTION:
ANR9999D mmsscsi.c(4501): Element Address mismatch; slotInfo.ele
m =15, slotInv.addr = 0
ADSM will allow the user to define the drives and library. Howe
ver, other drive related commands will fail with the above error
The problem is when ADSM / TSM issues a READ ELEMENT STATUS (b8)
type 0 the data comes back correctly. However if ADSM issues th
e (b8) type 2(storage slots) the drives,autochanger and e/e slo
t are excluded and the number of slots returned is 11 and not 15
To verify that this is the problem you are encountering you can
use LBTEST manual test, set special file name, open, and library
 inventory(9). Also show slots and compare the info. A pvr mms
trace will show the following;
Element address mismatch; slotInfo.elem = XX, slotInv.addr = X

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADIC VLS4mm and ADIC 1200D tape libraries when using ADSM
3.1.2.50 or TSM 3.7.0 or above.
****************************************************************
* PROBLEM DESCRIPTION: *
ANR9999D MMSSCSI.C ELEMENT ADDRESS MISMATCH ADIC VLS 4MM.
ANR9999D mmsscsi.c(4501): Element Address mismatch; slotInfo.ele
m =15, slotInv.addr = 0
ADSM will allow the user to define the drives and library. Howe
ver, other drive related commands will fail with the above error
The problem is when ADSM / TSM issues a READ ELEMENT STATUS (b8)
type 0 the data comes back correctly. However if ADSM issues th
e (b8) type 2(storage slots) the drives,autochanger and e/e slo
t are excluded and the number of slots returned is 11 and not 15
****************************************************************
* RECOMMENDATION: *
To verify that this is the problem you are encountering you can
use LBTEST manual test, set special file name, open, and library
inventory(9). Also show slots and compare the info. A pvr mms
trace will show the following;
Element address mismatch; slotInfo.elem = XX, slotInv.addr = X
If this is the problem install APAR IY07446.
****************************************************************
A change was made to the ADSM/TSM device driver to "bypass"
the ADIC firmware problem.

PROBLEM CONCLUSION:
Install APAR IY07446.

------

APAR: IY07452 COMPID: 576556402 REL: 310
ABSTRACT: ANR8469E DISMOUNT OF VOLUME VOLUMENAME FROM DRIVE DRIVENAME

PROBLEM DESCRIPTION:
This problem only occurs on 3.1.2.50. It does not occur on
any other 312 level or 37 level.
This problem only affects 3494 library customers.
Description: If the customer halts the ADSM server while there
are tapes mounted in the drives. When the server restarts and
there are still tapes in the drives, ADSM will try to empty the
drives. That is when the problem occurs. Within a MMS PVR
Trace, you will see an attempt to open the drive will fail with
errno=11. ADSM server will not be able to use those drives.

LOCAL FIX:
The customer has to halt the server when the drives are empty.
Or, the customer can use mtlib to empty the drives before
restarting the ADSM server.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
AIX, NT, HP and SUN 3.1.2.50 users with 3494 libraries.
****************************************************************
* PROBLEM DESCRIPTION: *
If a customer restarts the server while there are tapes
mounted in the drives, the server is not able to empty the
drives.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The server empties any drives it finds with a tape still
mounted when it is initializing.

TEMPORARY FIX:
Either halt the server when the drives are empty, or empty
the drives via the mtlib utility before restarting the
ADSM server.

------

APAR: IY07501 COMPID: 576556402 REL: 310
ABSTRACT: ADSM HANGS DURING EXPIRATION.

PROBLEM DESCRIPTION:
Expiration processing can hang in cases where it has an error
resolving information for a domain that a file is bound to and
where information for a different domain is acquired while expir
ation is examining the same group of files. An indication of
this problem would be that any of the following messages are
issued and expiration is stalled. The messages that may be seen
are: ANR0830W, ANR0831W, ANR0832W, ANR0833W, ANR0886E, or
ANR0887E. The hang will only occur if one or more of the above
messages is seen and the expiration process has to lookup
different policy information within the transaction used to issu
the above mentioned message. The server transation deadlock
detection process in not able to detect this deadlock situation
because the nature of the lock acquisition and the semantics of
the expiration code.

LOCAL FIX:
3.1.2.50 can help alleviate the hang seen in older versions,
but does resolve the issue

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V312 Server users or TSM V37 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
The server may hang during expiration processing. This problem
occurs when any of the following messages are issued AND the
server has to evaluate different policy information for files
within the current selected group for expiration. The
messages that are seen than may indicate the hang are the
following: ANR0830W, ANR0831W, ANR0832W, ANR0833W, ANR0886E,
or ANR0887E.
****************************************************************
* RECOMMENDATION: *
Please apply the ptf containing this fix once it is available.
****************************************************************
The server expiration algorithm has changes the transaction
and locking model used that caused this hang.

PROBLEM CONCLUSION:
The server expiration process was getting into a hang situation
because of the way a transaction for looking up policy
attributes was being managed. This handling of this
transaction has been altered to prevent this problem
from occurring.

------

APAR: IY07513 COMPID: 576556402 REL: 310
ABSTRACT: MEMORY LEAK IN ADMNODES_CLOSE

PROBLEM DESCRIPTION:
There is a small memory leak in AdmNODES_Close. The memory is
allocated in AdmNODES_Open and is never freed

LOCAL FIX:
Apply PTF when available

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V3 Servers and TSM V3.7 Servers
****************************************************************
* PROBLEM DESCRIPTION: *
A SQL query of nodes will cause a small memory leak.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available
****************************************************************
When querying nodes through the SQL interface, a small amount
of memory is not freed when the query is closed.

PROBLEM CONCLUSION:
The memory leak has been corrected.

------

APAR: IY07515 COMPID: 576556402 REL: 310
ABSTRACT: THERE IS A MEMORY LEAK IN ADMQUERYNODE

PROBLEM DESCRIPTION:
Over an undetermined amount of time QUERY NODE can use memory
for building a domainlist, but is never freed. We free the mem
ory upon failure of the query, but we don't otherwise

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V3 Servers and all TSM V3.7 Servers
****************************************************************
* PROBLEM DESCRIPTION: *
QUERY NODE command can cause a small memory leak
****************************************************************
* RECOMMENDATION: *
Apply corrective service when available
****************************************************************
A QUERY NODE command with the DOMAIN option specified can cause
a memory leak.

PROBLEM CONCLUSION:
The QUERY NODE command was modified to free the storage
containing the domain list.

------

APAR: IY07631 COMPID: 576556402 REL: 310
ABSTRACT: DSMLABEL DOES NOT WORK ON ACSLS DRIVE IDS GREATER THAN 3

PROBLEM DESCRIPTION:
Dsmlabel does not work on acsls drive ids greater than 3.
To recreate try to label a tape in a drive which has an
acsls id 0,0,2,4, e.g.:
dsmlabel -drive=/dev/mt0,0,0,2,4 -library=acsls,0 -search
You will receive the following message:
ANR9757E ACS drive id 0.0.2.4 is not valid for drive '/dev/mt0'
The problem seems to be that MAX_DRIVE_ID is defined as 3 in
ltsacs.h.

LOCAL FIX:
Use the label libv command.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
         All ACSLS users who use dsmlabel utility and have
         more than 4 drives defined per LSM.
****************************************************************
* PROBLEM DESCRIPTION: *
         The maximum number of drive as specified in the
         developer tool kit was 3. However, as the STK
         library grow larger and more than 3 drive can be
         placed into the library, this value is no longer
         valid.
****************************************************************
* RECOMMENDATION: *
         The maximum drive has been modified to 19 in the
         header file for recompile.
****************************************************************
         Change the maximum drive number from 3 to 19
         for dsmlabel utility.

------

APAR: IY07663 COMPID: 576556402 REL: 310
ABSTRACT: SOME CLIENT SESSIONS BECOME "STUCK" OR "HUNG" - THEY CAN NOT

PROBLEM DESCRIPTION:
Some client sessions become stuck/hung on the server even after
the client is stopped and a CANCEL SESSION is issued. A restart
of the server is needed to clear these sessions from the server.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All TSM/ADSM Servers and backup/archive clients.
****************************************************************
* PROBLEM DESCRIPTION: *
Clients performing backup/archive operations can hang
if an error occurs during a read verb opertion on
the server.
****************************************************************
* RECOMMENDATION: *
Apply ptf when available.
****************************************************************
If an error occurs while the server is reading a verb
it is possilbe under certain conditions for the server
to take an error path that does not ensure that the
sink is in an idle state before asking it to terminate.
Ensure that the sink thread is idle at end of session before
waiting to terminate. Client
sessions can hang if they are in a waitBufFull state and do
not return to idle before we signal them to terminate.

PROBLEM CONCLUSION:
The server will now ensure that the sink thread is idle
before terminating the client session. The client session
should not hang.

------

APAR: IY07860 COMPID: 576556402 REL: 310
ABSTRACT: ANR9999D WHEN RUNNING AN AUDITDB

PROBLEM DESCRIPTION:
When running a AUDITDB, the audit fails with
ANR9999D bfaggrut.c(712):Unable to locate attributes for bitfile
ANR2184W bfaudit.c631: Transaction 0:110413 was aborted for
command AUDITDB.
ANR4142I AUDITDB: Database audit process terminated in error.
This apar has been opened on Internal defect# 23336.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem may affect customers who perform a database audit
of a Version 3 Tivoli Storage Manager (ADSM) server.
****************************************************************
* PROBLEM DESCRIPTION: *
Under certain circumstances, a database audit can fail and
produce messages such as the following.
ANR9999D bfaggrut.c(712):Unable to locate attributes for bitfile
ANR2184W bfaudit.c631: Transaction 0:110413 was aborted for
command AUDITDB.
ANR4142I AUDITDB: Database audit process terminated in error.
This problem occurs only when the audit is run with
FIX=YES and only when a specific combination of
referential-integrity errors is detected. The problem
is less likely to occur on Version 3.7 servers than on
earlier server levels.
****************************************************************
* RECOMMENDATION: *
This problem has been fixed in all Version 3 servers and can be
obtained in a future PTF.
****************************************************************
Customers who encounter this problem can apply the appropriate
PTF when it becomes available. It may also be possible to avoid
the problem by upgrading to Version 3.7 of the server.

PROBLEM CONCLUSION:
This problem occurs only under very unique circumstances, and
can be avoided by applying the appropriate PTF when it becomes
available.

------

APAR: IY07891 COMPID: 576556402 REL: 310
ABSTRACT: WEB BROWSER CONNECTS TO THE VM SERVER BUT THE SERVER IS SLOW TO

PROBLEM DESCRIPTION:
When a web admin session is open several sessions are started be
fore authentication occurs. The sessions open prior to authenti
cation remain in the start state and can not be caceled. It loo
ks like either the web browser is connecting to ADSM and not wri
ting things to the stream or the browser is timing out because V
M is slow to respond.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This apar effect all 3.1.2.X platforms and 3.7.X platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
HTTP session open but never close and are not canceled based
on commtimeout parameter in the server options. This happen
when an admin client connect to the http port instead of the
tcp port the session hangs. Another example of the problem
is a bunch of web sessions hang around and never seem to close.
****************************************************************
* RECOMMENDATION: *
Install PTF when available.
****************************************************************
HTTP session are now monitored when they recieve data from the
port. The problem is the server is waiting on the socket for
data to be read. This produces the appearence the session is
hung.

------

APAR: IY07930 COMPID: 576556402 REL: 310
ABSTRACT: CRASH AND CORE DUMP WHEN USING SERVER TO SERVER VIRTUAL

PROBLEM DESCRIPTION:
When using server to server virtual volumes, the source server
will crash and core dump when issueing the commands. This
happens when the passwords are syncronized.
Example of commands: delete volhist toddate=-90 type=all
backup db type=full devclass=serverclass
ANR2017I Administrator SEKKINO issued command:
DELETE VOLHISTORY type=all todate=-90
ANR2017I Administrator SEKKINO issued command:
DELETE VOLHISTORY type=all todate=-90
ANR4373E Session rejected by target server
WBADSM, reason: Authentication Failure.
This could also be related to apar IY01690.
This does happen is 3.1.2.40 and 3.1.2.50.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM Version 3.1.2.x server users and Tivoli Storage Manager
Version 3.7 server users.
****************************************************************
* PROBLEM DESCRIPTION: *
While using server-to-server virtual volumes, the source server
may crash. The crash only occurs if the passwords are not
synchronized between the source and target servers.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing the fix for this apar once it is
available.
****************************************************************
The server-to-server virtual volume algorithm has been modified
to correct the situation causing the crash.

PROBLEM CONCLUSION:
The server crash was caused by the source server accessing
an in-memory structure used to manage the communications
between the source and target servers. In this case, this
in-memory control structure had been released but the
server-to-server virtual volume algorithm attempted to
use it although it was no longer valid.
The algorithm has been modified to correct this situation.

------

APAR: IY08280 COMPID: 576556402 REL: 310
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: IY08334 COMPID: 576556402 REL: 310
ABSTRACT: LABEL FAILING ON SD3 (REDWOOD) DRIVES. LABEL LIBVOLUME FAILS ON

PROBLEM DESCRIPTION:
Label failing on SD3 (Redwood) drives. Label Libvolume fails on
every volume. DSMLabel fails after one volume is labeled.
Discovered on ADSM V3.1.2.40 server and Timberwolf 9740 Library
using Redwood (SD3C) drives.
MMS PVR Systime trace during Label Libv will show the following
sequence:
pvrgts.c(2742): Reading label from volume in drive DRIVE2
(/dev/mt1).
pvrtape.c(867): Setting mode for drive DRIVE2 (/dev/mt1);
format=57.
pvrgts.c(3641): Reading label blocks from drive DRIVE2
(/dev/mt1); blksize=0.
pvrgts.c(3681): Read VOL1 block from drive DRIVE2 (/dev/mt1);
sig= .
mmsscsi.c(11421): ObtainMediaType: devType=19 mediaType=0
wormMedia=0
mmsscsi.c(11565): Opening Drive DRIVE2 (/dev/mt1) in library
9740LIB with up to 120 second wait.
mmsscsi.c(3418): Waiting for drive DRIVE2 (/dev/mt1) to become
ready in library 9740LIB.
pvrgts.c(2535): Testing readiness of drive DRIVE2 (/dev/mt1).
pvrgts.c(2652): Writing Label to drive DRIVE2 (/dev/mt1)
pvrgts.c(3484): WriteLabelBlocks to drive DRIVE2 (/dev/mt1):
VOL1R00378
HDR1
HDR2U2621400000 0
pvrtape.c(867): Setting mode for drive DRIVE2 (/dev/mt1);
format=66.
pvrtape.c(1515): Error performing SETMODE operation on drive
DRIVE2 (/dev/mt1)
pvrtape.c(1591): Drive DRIVE2 (/dev/mt1): compcode=207,
status=22, sense data (0): .
Identification of problem:
format=57. Set Mode with correct format for SD3
format=66. Set Mode with incorrect format for SD3 failed on
the same volume.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM NT, HP, SUN and AIX servers attached to STK SD3 drives.
****************************************************************
* PROBLEM DESCRIPTION: *
The server does not configure the STK SD3 drives correctly to
write the internal tape label.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************
The server configures the STK SD3 drives correctly to write
the internal tape label.

TEMPORARY FIX:
Use the DSMLABEL utility to label volumes.

------

APAR: IY08736 COMPID: 576556402 REL: 310
ABSTRACT: WHEN DELETE DRIVE IS GENERATED WHILE A DRIVE IS IN POLLING,

PROBLEM DESCRIPTION:
When drives are in a shared situation, and are deleted while
the server is polling these drives, in some instances a core
dump may be produced.
RECREATE:
 1). started server
 2). shared drives were in use, so server started polling
 3). performed delete drive command
 4). server abended.
dbx shows:
IOT/Abort trap in signal.pthread_kill
0xd0236274 ($t2128)
0xd0236274 (pthread_kill+0x88) 80410014 lwz r2,0x14(r1)
(dbx) where
signal.pthread_kill(??, ??) at 0xd0236274
signal._p_raise(??) at 0xd023582c
raise.raise(??) at 0xd0013bec
abort() at 0xd000d350
AbortServer() at 0x1000bebc
TrapHandler(??, ??, ??) at 0x1000bbd0
DrivePollThread(??) at 0x1009013c
StartThread(??) at 0x1000bdc4
pthread._pthread_body(??) at 0xd0228d88
q actlog search="anr????E"
01/14/00 09:50:48 ANR8447E No drives are currently available in
                   library 3494lib

LOCAL FIX:
monitor activity log and do not delete drives while they are
being polled by the server.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM NT, AIX, SUN, HP servers
****************************************************************
* PROBLEM DESCRIPTION: *
The server may crash if a customer issues a DELETE DRIVE
command during the last iteration of the drive polling
algorithm.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The server does not crash when the DELETE DRIVE command is
issued against a drive the server is currently polling.

------

APAR: IY08819 COMPID: 576556402 REL: 310
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: IY08870 COMPID: 576556402 REL: 310
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.
ADDITIONAL KEYWORDS: ABEND0C4 ReadVolid

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: IY08917 COMPID: 576556402 REL: 310
ABSTRACT: ADSM SERVER IGNORES THE SEARCH=BULK PARAMETER ON THE

PROBLEM DESCRIPTION:
The ADSM or Tivoli Storage Manager server allows the
SEARCH=BULK parameter on the LABEL LIBVOLUME command for
a 3494 library but the SEARCH=BULK is ignored and instead
the server will behaves as if SEARCH=YES was specified.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM AIX, NT, SUN, HP servers
****************************************************************
* PROBLEM DESCRIPTION: *
The server does not correctly perform the following command
syntax checking for the CHECKIN LIBVOLUME command:
1) The SWAP parameter is only valid with the SEARCH=NO option.
2) The SEARCH=BULK option only applies to SCSI libraries.
The server performs the correct command syntax checking.
In addition, the reference manuals will be updated to state
that the SEARCH=BULK parameter in the CHECKIN LIBVOLUME
and LABEL LIBVOLUME commands only applies to SCSI libraries.

------

APAR: IY09061 COMPID: 576556402 REL: 310
ABSTRACT: ADSM AUDIT VOLUME DOES NOT CHECK THE IMBEDDED HEADER STORED WITH

PROBLEM DESCRIPTION:
The ADSM server stores imbedded header information with each
object backed up or archived on the server. The server audit
volume process does not check for the validity of this header.
The audit volume process needs to be enhanced to check this
header.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and Tivoli Storage Manager users
****************************************************************
* PROBLEM DESCRIPTION: *
"audit volume" did not check object headers.
****************************************************************
* RECOMMENDATION: *
Apply fixing ptf when available.
****************************************************************
"audit volume" mounted and read the volumes, but did not verify
the object headers.

PROBLEM CONCLUSION:
Processing has been changed. The headers are now validated.
If valid, all is fine. Otherwise, the file is marked "damaged"
when fix=NO, and deleted when fix=YES.

------

APAR: IY09067 COMPID: 576556402 REL: 310
ABSTRACT: ANR0104E ASTXN(1256): ERROR 2 DELETING ROW FROM TABLE "AS.VOLUME

PROBLEM DESCRIPTION:
During start up of ADSM server receive:
ANR0984I Process 1 for EXPIRATION started in the BACKGROUND at
08:46:3
ANR2855I Server is licensed to support space-managed clients.
ANR0811I Inventory client file expiration started as process 1.
ANR2860I Server is licensed to support disaster recovery
manager.
ADSM Server for MVS - Version 3, Release 1, Level 2.40
ANR0984I Process 2 for SPACE RECLAMATION started in the
BACKGROUND at 08:46:33.
 BACKUPVTS (process number 2).
adsm>
ANR0104E ASTXN(1256): Error 2 deleting row from table "AS.Volume
.Status"
ANR1181E ASTXN352: Data storage transaction 0:2792518 was aborte
Customer can not afford to have the ADSM server down to do an
audit DB.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM customers where expiration and reclamation
are running concurrently.
****************************************************************
* PROBLEM DESCRIPTION: *
If expiration is running and reclamation begins shortly
after, there is a small window of opportunity for
reclamation to delete the volume being reclaimed before
expiration can perform deallocation. Expiration fails
to find the row for the volume in the volume status
table and fails. The transaction rolls back leaving
entries in the inventory with no volume.
****************************************************************
* RECOMMENDATION: *
Apply ptf when available.
For customers that have volumes they can not delete
because of the missing volume status row, code has
been added to allow the volume deletion to succeed.
Perform the VOLUME DELETE command for each volume
in the described condition.
****************************************************************
During expiration deallocation if the row in the volume
status table is missing for the volume, then the volume
must have been deleted by another process (reclamation).
Since the volume no longer exist there is nothing to
deallocate and continue without indicating failure.
Code was also added to all the deletion of volumes
in the state where the volume status row is missing.
Issue the DELETE VOLUME command for volumes in the
state described.

PROBLEM CONCLUSION:
Expiration will no longer fail if reclamation has
deleted the volume that it is attempting to perform
deallocation on.
Volumes that could not previously be deleted can
now be deleted using the DELETE VOLUME command.

------

APAR: IY09073 COMPID: 576556402 REL: 310
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: IY09199 COMPID: 576556402 REL: 310
ABSTRACT: ANR9999D DBALLOC SMP PAGE ZERO BIT COUNT MISMATCH

PROBLEM DESCRIPTION:
A customer experienced the following error indicating SMP page
corruption in the Server database:
  ANR9999D DBALLOC(1247): Zero bit count mismatch for SMP page
  address .... Zero Bits = .., HeaderZeroBits = ...
The customer restored his database from the last BACKUP DB in
an attempt to correct the problem but ran into the same error
when attempting to restart the server after the restore. The
customer had to restore the database a second time from a
previous back before the server could be started.
The customer feels that the Server should check for this
condition during BACKUP DB processing. This would insure that
backup tapes were not corrupted by this condition and would
also lead to earlier detection of the condition and would
minimize loss of data.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and TSM users.
****************************************************************
* PROBLEM DESCRIPTION: *
When making a backup of the server's database, the server did
not perform sufficient consistency checks on the database in
order to help ensure that the backup would be usable.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************

PROBLEM CONCLUSION:
The TSM server is modified to perform more database consistency
checks when making a backup of the database.

------

APAR: IY09200 COMPID: 576556402 REL: 310
ABSTRACT: ABENDU0301 ON DEFINE LOGVOLUME WHEN TOTAL RECOVERY LOG CAPACITY

PROBLEM DESCRIPTION:
AbendU0301 on define logvolume. This happens only when the
total recovery log size is 5420MB, which is the maximum allowed.
Also msgANR9999d LVMCKPT. The log LP table exceeds the maximum
size. Internal error LVMCKPT227 detected.
It should also be documented that the maximum recovery log size
is 5420 MB.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM/TSM users.
****************************************************************
* PROBLEM DESCRIPTION: *
LVMCKPT227 assert occurs when defining a log volume that will
make the log size 5420M in size.
****************************************************************
* RECOMMENDATION: *
Apply the fix when available. Do not define recovery log
volumes that would make the log size greater than 5416M.
****************************************************************
Based on the use of internal structures. The actual limitation
for the recovery log is 5416M. This fix will correct the
calculations that check for the limit.

------

APAR: IY09203 COMPID: 576556402 REL: 310
ABSTRACT: WHEN CHECKIN LIBVOL COMMAND IS ISSUED USING A VOLRANGE OF ONLY

PROBLEM DESCRIPTION:
When the following command is issued:
checkin libvol <volumename> search=yes checklabel=yes
devtype=3590 status=scratch volrange=VN0005
Error generated
ANR8825E 'VN0005' is not a valid volume range.
However checkin completes with completion state SUCCESS.
All possible volumes starting with VN0005 are processed.

LOCAL FIX:
Use proper command syntax

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM/TSM servers on AIX, HP, SUN and NT.
****************************************************************
* PROBLEM DESCRIPTION: *
The server did not handle an error in the VOLRANGE parameter
for the CHECKIN LIBVOLUME command correctly.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
The server handles an error in the VOLRANGE parameter
for the CHECKIN LIBVOLUME command correctly.

------

APAR: IY09204 COMPID: 576556402 REL: 310
ABSTRACT: ANR0000E UNABLE TO OPEN LANGUAGE AMENG FOR MESSAGE FORMATTING IF

PROBLEM DESCRIPTION:
ANR0000E UNABLE TO OPEN LANGUAGE AMENG FOR MESSAGE FORMATTING IF
NO EN_US INSTALLED. To recreate:
1. Set up an aix box with only none en_US language environment
   installed (e.g. ja_JP).
2. Install TSM
3. If starting the server you get the ANR0000E message

LOCAL FIX:
Install the en_US part of the aix operating system

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V312 Servers and TSM V3.7 Servers.
****************************************************************
* PROBLEM DESCRIPTION: *
AIX Server initialization fails with unable to open language
AMENG when no 'en_US' installed.
****************************************************************
* RECOMMENDATION: *
Install fixing PTF when available.
****************************************************************
The ADSM/TSM AIX server needs to initialize with
a default message catalogue file( en_US ). In this case,
the ADSM/TSM AIX server was trying to initialize with the
wrong default message file. The server should use the
'en_US' message catalogue file, not, the AMENG message file.
The ADSM/TSM AIX server has been updated so that it will
use the correct message catalogue file to initialize with.
The 'TSM AIX Quick Start' publications will be updated to
clarify that the 'en_US' language environment on the AIX
system is a requirement for running the TSM server in 'en_US'
or in any other TSM server supported languages( ie.'ja_JP',
'de_DE', etc.. )

PROBLEM CONCLUSION:
The ADSM/TSM Server has been updated to correct the problem.

------

APAR: IY09210 COMPID: 576556402 REL: 310
ABSTRACT: WHEREPLATFORM OPTION FOR THE UPDATE NODE COMMAND DOES NOT WORK

PROBLEM DESCRIPTION:
The update node command with -WHEREPLATFORM= does
not work for the platforms that are mixed case as reported by
the QUERY NODE command. It doesn't matter what I put in
for the argument to the -WHEREPLATFORM option
if QUERY NODE shows the platform as mixed case.
These platforms work. AIX, HPUX, SUN SOLARIS, (?)
These platforms do not. WinNT, NetWare, Mac
Query Node reports the platform as AIX
This works
UPDATE NODE * CLOPTSET="" WHEREPLATFORM=AIX
UPDATE NODE * CLOPTSET="" WHEREPLATFORM=aIX
UPDATE NODE * CLOPTSET="" WHEREPLATFORM=aix
Query Node reports the platform as WinNT
This does not
UPDATE NODE * CLOPTSET="" WHEREPLATFORM=WinNT
UPDATE NODE * CLOPTSET="" WHEREPLATFORM=WINNT
UPDATE NODE * CLOPTSET="" WHEREPLATFORM=winnt
The information message that is displayed is.
ANR2019I UPDATE NODE: No nodes updated
I tried this from the server console as well as the 3.7.1 client
so I assume that the client code is not where the problem lies.

LOCAL FIX:
Do not use the whereplatform option. Update each node
individually.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All 3.1.2.x and 3.7.x servers.
****************************************************************
* PROBLEM DESCRIPTION: *
The WHEREPLATFORM option on the UPDATE NODE command did not
account for mixed case values (i.e. winNT).
****************************************************************
* RECOMMENDATION: *
Update the nodes individually instead of using the WHEREPLATFORM
option.
****************************************************************
The UPDATE NODE command was modified to handel mixed case values
for the WHEREPLATFORM option.

TEMPORARY FIX:
Update nodes individually instead of using the WHEREPLATFORM
option.

------

APAR: IY09212 COMPID: 576556402 REL: 310
ABSTRACT: MESSAGE IS VERY CRYPTIC WHEN ADSM CANNOT OBTAIN FILE FOR RESTORE

PROBLEM DESCRIPTION:
During a restore process if ADSM is unable to obtain a file
the message displayed does not indicate what file nor why it
cannot be located.
The following message is received:
ANR9999D SMNQR(1132): Bitfile 97014491 not found for retrieval.
ANR0540W Retrieve or restore failed for session 1 for node XYZ
data integrity error detected.
This error is often seen during a disaster recovery scenario.

LOCAL FIX:
Use the SHOW BFO command to determine what storage pool
the file is located in.
Use the SHOW INVO command to determine which file cannot
be restored and where the adsm server is looking for it.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Any ADSM V312 server user or any TSM V37 server user.
****************************************************************
* PROBLEM DESCRIPTION: *
If a file fails retrieval from the server during either a
retrieve or restore operation, an ANR9999D message may be
received indicating the following:
ANR9999D SMNQR.C(xxx): Bitfile xxxx not found for
retrieval.
The restore/retrieve operation fails at this point and
no other information is given on the server.
****************************************************************
* RECOMMENDATION: *
Please apply the ptf that resolves this situation once it is
available.
****************************************************************
The server ANR9999D message that was issued has been replace
with message ANR0548W. The message will indicate the
session number, client name, the client's platform, the
filespace that the file belongs to, the file name, and
the storage repository from the server (BACKUP, ARCHIVE,
or SPACEMANAGED). The recommended action is to
re-try the restore/retrieve operation if the file is backed
up to a copy storage pool.
An example of the new message is the following:
ANR0548W Retrieve or restore failed for session <session
number> for <client name> processing filespace <filespace
name> for file <file name> stored as <storage repository>
file - data integrity error detected.
Explanation: The server ends a file retrieval operation for
the specified session because an internal database integrity
error has been encountered on the server.
System Action: The server ends the specified session and
continues operation.
User Response: Re-try the restore or retrieve operation and if
the file is also backed up in a copy storage pool, the
operation will attempt to read the file from the
alternate location.

PROBLEM CONCLUSION:
The server was not providing enough information where a
restore/retrieve operation failed. The ANR9999D message that
was being issued has been replaced with ANR0548W so as to
provide more information.

------

APAR: IY09270 COMPID: 576556402 REL: 310
ABSTRACT: TIVOLI STORAGE MANAGER SERVER MAY GENERATE DEFUNCT

PROBLEM DESCRIPTION:
When using an external library manager (i.e. ACSLS) with the
Tivoli Storage Manager Server (3.7 or 3.1), the TSM Server may
generate defunct processes. This behavior has only been seen on
the AIX platform.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of ADSM V3 and later for AIX that use external
libraries.
****************************************************************
* PROBLEM DESCRIPTION: *
On a heavily loaded system, defunct proceses sometimes appear.
****************************************************************
* RECOMMENDATION: *
Apply the latest ADSM service which includes this fix.
****************************************************************
Apply the latest TSM service.

PROBLEM CONCLUSION:
This condition occurs on ADSM for AIX servers using external
libraries on heavily loaded systems.

------

APAR: IY09272 COMPID: 576556402 REL: 310
ABSTRACT: TRAP DURING DATABASE AUDIT WITH FIX=YES

PROBLEM DESCRIPTION:
During database audit of the TSM V3.7 Server, the server can
trap if it attempts to delete a file that is stored on
sequential access media.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem can affect customers who use the database audit
function on a Version 3 Tivoli Storage Manager server.
****************************************************************
* PROBLEM DESCRIPTION: *
In very rare situations, the server can trap during a database
audit with fix=yes. This problem can occur if the server
attempts to delete an object that is stored in a sequential-
access storage pool.
****************************************************************
* RECOMMENDATION: *
This problem is fixed in a future PTF of the Tivoli Storage
Manager V3.1.2 and V3.7 server.
****************************************************************
This problem occurs only in very rare situations involving
deletion of an object from a sequential-access storage pool
during a database audit.

PROBLEM CONCLUSION:
The problem can be avoided by applying a PTF with the fix.

------

APAR: IY09318 COMPID: 576556402 REL: 310
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: IY09418 COMPID: 576556402 REL: 310
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: IY09602 COMPID: 576556402 REL: 310
ABSTRACT: SERVER MAY CRASH IN TBPREFETCHTHREAD() IF A SECOND TBVAR STRUCTU

PROBLEM DESCRIPTION:
Server may crash in TbPrefetchThread() due to a NULL pointer
write which got returned from HashFindPrefetch().
The problem is caused by the initialization of the TBVars
structure. There is a timing window wherethis problem can
occur because it is possible for a second TBVars structure to be
created, in effect, losing the pointer to the previous hash
list.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM/TSM users
****************************************************************
* PROBLEM DESCRIPTION: *
Timing prblem on server start-up can cause core dump in
buffer prefetcher thread.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Fixed timing problem.

------

APAR: IY09654 COMPID: 576556402 REL: 310
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: IY09721 COMPID: 5697FRA00 REL: 361
ABSTRACT: WGETADMIN SHOWS OIDS OF OLD POLICY REGIONS.

PROBLEM DESCRIPTION:
wgetadmin shows the oids of old deleted policy regions.
this is erroneous and confusing to customers.

LOCAL FIX:
Solution: See the solution in TSD 1081-FRamework for
an explanation of this problem adn what causes it.
This problem is caused by removing a policy region without
removing it's associated roles from the administrator in questio
n. since the policy region is not longer in the name registry
the wgetadmin fails when trying "get_capabilities" method and
only reports the policy regions oid. Should be cleaned up
with a wchkdb enhancement.

PROBLEM SUMMARY:
The wgetadmin command does not show the
object ID of deleted policy regions.

PROBLEM CONCLUSION:
This is fixed in the 3.6.5 release. Fix
also made via CMVC defect 106074.

------

APAR: IY09850 COMPID: 576556402 REL: 310
ABSTRACT: EVENT SUMMARY DELETED AFTER ANY CHANGE TO THE MANAGED DOMAIN

PROBLEM DESCRIPTION:
'q event' output is deleted from managed servers when any change
is made to a managed domain on the config manager and the
configuration is refreshed. Initially thought to be caused by
copying a schedule, but actually any change to the domain
(including adding a policy set or mgmtclass) causes all objects
in the domain to be "updated" so the event history is lost.
Steps to recreate:
1. Setup Enterprise Administration on 2 servers, one manager &
    one managed.
2. Create a domain with a policy set and mgmtclass on the
    manager.
3. Define a schedule in that domain on the manager.
4. Add the domain to the config profile and notify subscribers.
5. Activiate policy set in the managed domain on the managed
    server.
6. Define a node in that domain and associate it with the
    schedule on the managed server.
7. Allow the schedule to miss or succeed so you have some
    'q event' output.
8. Copy the schedule to a new name in the same domain on the
    config manager or add a policy set or mgmtclass, then
    notify subscribers.
9. A 'q event' on the managed server will no longer show the
    missed or succeeded event from step 7, only a new future
    event, as if the schedule had been updated.
10. A 'q sched f=d' on the managed will show a last update date/
    time of the last notify subscribers, even though a 'q sched
    f=d' on the manager has an update date/time from before the
    schedule was copied.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem may affect administrators who use the enterprise
configuration function of Tivoli Storage Manager V3.1.2 or
V3.7.
****************************************************************
* PROBLEM DESCRIPTION: *
Enterprise configuration can be used for propagating domain
information, including definitions of related non-active
policy sets, management classes, copy groups, and client
schedules to one or more managed servers. Whenever any change
is made to a domain (or a policy set, management class, copy
group, or client schedule for that domain) on a configuration
manager, complete domain information is sent to any
managed servers which subscribe to profiles with associations
to the changed domain. When this occurs, the domain and all
related definitions on the managed server are updated with
the latest definitions from the configuration manager.
When client schedules are updated on a managed server, any
events for that schedule that occurred prior to the update will
no longer be visible. The event records themselves are not
deleted, but the QUERY EVENT command does not have sufficient
information to process events prior to the time at which the
schedule is updated. Refreshing of domains can therefore make
it impossible to view events that occurred prior to the
refresh, even if the schedules on the configuration manager
did not actually change.
****************************************************************
* RECOMMENDATION: *
The code which refreshes client schedules on the managed server
been modified to avoid the problem with QUERY EVENT. The
new code will not change the last modification date for
a client schedule unless that schedule was actually changed on
the configuration manager. This will allow the QUERY EVENT
command to display events prior to a configuration refresh,
provided that no changes were made to client schedule itself.
Customers who use enterprise configuration for propagating
domain information, including client schedules, should apply
this fix when it becomes available in a future PTF.
****************************************************************
Propagation of domain information to a managed server can make
it impossible for the QUERY EVENT command to display client
events that occurred before the refresh on the managed server.
A fix for this problem will appear in a future PTF.

PROBLEM CONCLUSION:
If domain information is updated during enterprise
configuration refresh processing, QUERY EVENT will not
be able to display events prior to the time at which
schedule updates were performed. Future PTFs for V3.1.2 and
V3.7 contain fixes for the managed server to avoid this
problem. No changes need be applied to the configuration
manager.

------

APAR: IY09972 COMPID: 576556402 REL: 310
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: IY10448 COMPID: 576556402 REL: 310
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: IY10633 COMPID: 576556402 REL: 310
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: IY10656 COMPID: 576556402 REL: 310
ABSTRACT: MIGRATION FAILS ON DISK STORAGE POOL WITH ANR9999D DFTXN.C(795)

PROBLEM DESCRIPTION:
When running migration on Disk Storage Pool receive error:
 ANR9999D dftxn.c (795): file count went negative for pool1,
   ck1=46 ck2=164
 ANR1181E dftxn.c 2000: data storage transaction 0:487686885
   was aborted

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM V3 server platforms.
All TSM V3 server platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
During processing that may delete files from disk storage
pools (expiration, migration, reclamation, etc.) it is
possible to receive the following error:
ANR9999D dftxn.c (795): file count went negative for poolX,
ck1=Y ck2=Z
As a result of the error, the db transaction in use will abort
and the server function will fail.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************
A similar problem with sequential media was documented by
APAR IX82403. Because of differences in the way disk storage
pools are implemented, the fix from IX82403 cannot be fitted
to disk storage pools. Instead, the fix for this APAR will be
to detect when the file count goes negative and reset the file
count to zero. A trace message under the trace class DFTXN
will be issued and processing will continue. This is possible
because the error condition in question is really non-fatal:
when additional processes (expiration, migration, etc) are
run on the disk storage pool, the file count in question will
return to an accurate value.

------

APAR: IY11007 COMPID: 576556402 REL: 310
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: IY11173 COMPID: 5697D1710 REL: 420
ABSTRACT: IN A DPL PROCESS THE FMH43 HEADER IS NOT HANDLED PROPERLY

PROBLEM DESCRIPTION:
MAS invokes a DPL call to communicate with CICS on OS/390.The
corresponding CICS transaction is started and receives the para-
meters correctly from the MAS.It returns some values but these
messages are not received at the MAS.
The cause is a bad formatted FMH43 header from the mainframe.
The actual cause of this problem was found to be a change m
made in the FMH43 header. A new field was added. When we
received this new header it showed that we had an error in
using the length field of the header to parse the data.
Encina defect 25022 corrects the use of the length field and
the FMH43 header is no longer having problems.

PROBLEM SUMMARY:
USERS AFFECTED: Encina users, Release 420 430
PPCGWY mishandling FMH43 header by appending bytes for
dynamically routing link requests.

PROBLEM CONCLUSION:
Code changes were made in cpic.c (by Mahesh Patil) to support
variable length FMH43 values. Changes were made to handle
requests in both directions.

------

APAR: IY11433 COMPID: 576556402 REL: 310
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: IY11485 COMPID: 576556402 REL: 310
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: IY12032 COMPID: 576556402 REL: 310
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: IY12033 COMPID: 576556402 REL: 310
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: IY12047 COMPID: 576556402 REL: 310
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: IY12111 COMPID: 576556402 REL: 310
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: IY12604 COMPID: 576556402 REL: 310
ABSTRACT: TCPIP REC/WAIT MEDIA/WAIT SOURCE SERVER TO SERVER

PROBLEM DESCRIPTION:
Problem: Target Server Hangs during virtual volume
server to server communication
ERROR DESCRIPTION:
OSs INVOLVED: ALL
COMPID: 576556402
APAR SEV: 3
RELESE: ALL
KEYWORD: IN/WAIT
ABSTRACT: SERVER to SERVER REC/WAIT MEDIAW RECW TCPIP
When a network interruption occurs during a server to server
Virtual Volume connection, the target server fails to recognize
the break in the connection and the thread hangs. Meanwhile,
the source server recognizes the break and terminates the
thread. This is caused by using a unique session_type (11) for
server to server connections that ignores the comm time
out.
Session_type (11) was modified for a server to server
connection to address the case where the source server may
wait for a volume to be mounted longer than the comm time out
period permits. To avoid unnecessary loss of connection, the
session_type (11) was modified to not time out.
When no administrators/operators are available to cancel the
hung thread, the target server eventually hangs due to a pinned
activity log.
RECREATE DIRECTIONS:
1) Establish a server to server connection (expiration/ backup)
2) Perform a "show sess" and a "q sess f=d" on both target and
   source servers
3) Interrupt the network
4) Perform another "show sess" and a "q sess f=d" on both
   target and source servers
The condition may be detected by doing a query session and/or
a show session on the source and target servers. The output
will show that only one of the servers has a active server to
server session with the other server. Show sessions is an
undocumented command and an example of the output follows.
Notice the SessType field contains an 11. A query session
would reveal the state and node name associated with the
associated session, number 1921 in the example below.
Sample show session:
Session 1921: Type=Node, Id=XXXXXXX
   Platform=AIX-RS/6000, NodeId=354, Owner=XXXXXXX
 * SessType=11, Index=3, TermReason=0
   RecvWaitTime=0.000 (samples=0)
   Backup Objects ( bytes ) Inserted: 0 ( 0.0 )
   Backup Objects ( bytes ) Restored: 0 ( 0.0 )
   Archive Objects ( bytes ) Inserted: 0 ( 0.0 )
   Archive Objects ( bytes ) Retrieved: 0 ( 0.0 )
ADDITIONAL KEYWORDS: HUNG LOOP TCP/IP COMMTIMEOUT
VVVirtual Volumes Target Source

LOCAL FIX:
Manually terminate the thread with a CANcel SESSion command

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of server to server virtual volumes.
****************************************************************
* PROBLEM DESCRIPTION: *
When there is a network interruption during server to server
connection the target server will not recognize the break in
the connection and the thread will hang. Meanwhile the source
server will recognize the break and will terminate the thread.
****************************************************************
* RECOMMENDATION: *
Install the fixing PTF.
****************************************************************

PROBLEM CONCLUSION:
The server has been modified to apply the standard time out
values to a target server.

------

APAR: IY12950 COMPID: 576556402 REL: 310
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: IY12988 COMPID: 576556402 REL: 310
ABSTRACT: ANR - EXPIRATION - ANR9999D IMARQRY OBJECT ALREADY EXPIRED

PROBLEM DESCRIPTION:
Expiration fails with:
ANR4391I Expiration processing node SIDCDEV01H, filespace
 \\sidcdev01\d$, domain HEBDOMADAIRE, and management class
 ARCHMC3600 - for ARCHIVE type files.
ANR9999D DSMSERV/QCSRC/IMARQRY(2004): Object 0.3ff4908 of
 type 1 is already expired
Expiration process remains active and doesn't complete.
Looks like the ANR9999D message is being issueddue
to an incomsistency when expiration is checking if
archive directories are referenced.

PROBLEM SUMMARY:
Expiration fails with:
ANR4391I Expiration processing node SIDCDEV01H, filespace
 \\sidcdev01\d$, domain HEBDOMADAIRE, and management class
 ARCHMC3600 - for ARCHIVE type files.
ANR9999D DSMSERV/QCSRC/IMARQRY(2004): Object 0.3ff4908 of
 type 1 is already expired
Expiration process remains active and doesn't complete.
Looks like the ANR9999D message is being issueddue
to an incomsistency when expiration is checking if
archive directories are referenced.

PROBLEM CONCLUSION:
The server expiration process and file deletion code has been
altered to prevent this error condition from happening. The
algorithm now evaluates if the file is explicitly marked for
deletion, if it is explicitly marked for deletion, it will no
exercise the code that issued the message and caused expiration
to terminate. This code was not supposed to be executed in
this case.
The server expiration and file deletion algorithms were
calling incorrectly evaluating a file to see if it should
be deleted. The algorithm already knows the file needs to be
deleted and did not need to make this additional evaluation.

------

APAR: IY13244 COMPID: 576556402 REL: 310
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: IY13289 COMPID: 576556402 REL: 310
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: IY13290 COMPID: 576556402 REL: 310
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: IY13291 COMPID: 576556402 REL: 310
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: IY13292 COMPID: 576556402 REL: 310
ABSTRACT: ABENDU301 MSGDM0001S LOGSEG014 ADSM MVS SERVER

PROBLEM DESCRIPTION:
This problem was discovered on a mvs 3.1.2.50 system.
The abend.info indicates that the call-stack was from the
DbCheckpointThread. So, it looks like the sequence of events
was the following:
1) DB Backup being performed. 2) DB Backup was to the point
that it opened the log scan and was processing the log records.
3) While the db backup process was running, the DbCheckpoint
thread met it's criteria to do a checkpoint. And in fact, the
db checkpoint thread looks as though it wrote the checkpoint
and was doing it's logTruncate action at the end of the
checkpoint processing.
It looks like there is a timing window between database backup
and the db checkpoint process (logTruncate more specifically)
where we truncate the log while the db backup has an open scan
of the log with a scanLsn below what the new truncation point
would be... The key is that the logTruncate called from the
checkpoint thread is indicating a new truncation point based on
the transactions and dirty pages that the DB
component/checkpointer views. However, this does not take into
account the log scan in use by the database backup. So, the
logTruncate called by the checkpoint thread tries to set the
truncLsn ahead of where the current open scan is...

LOCAL FIX:
Restart the ADSM/TSM server.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and TSM server users.
****************************************************************
* PROBLEM DESCRIPTION: *
Server crashes during database/log checkpoint when database
backup is happening concurrently.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************

PROBLEM CONCLUSION:
The server was corrected to take into account an active
database backup when the database/log checkpoint occurs.

------

APAR: IY13362 COMPID: 576556402 REL: 310
ABSTRACT: ABEND0C4 ANRQAMUT CANCEL SESSION

PROBLEM DESCRIPTION:
Running at 3.1.2.50; ABEND0C4 in ANRAQMUT on CS (Compare and
Swap) instruction because smSesionDesc.restCtlP = 0 when a
session is cancelled. Function CancelSessionNum() picks up
the restCtlP pointer and passes it to function imCancelRestore
without checking if pointer is null. This results in a program
check in ANRAQMUT.
ADDITIONAL KEYWORDS: ABEND0C4 PROTECTION EXCEPTION SEGMENT
VIOLATION

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
all ADSM and TSM server users
****************************************************************
* PROBLEM DESCRIPTION: *
server sometimes crashes for cancel session and NQR
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available
****************************************************************
A client was restoring files using no query restore. An
administrator issued "cancel session" for that client. Then
the server crashed.

PROBLEM CONCLUSION:
There was a window where, if a cancel session was issued
against a node that was doing a no query restore, and the
restore was terminating anyway, the server would crash. This
hole in the code has been fixed.

------

APAR: IY14248 COMPID: 576556402 REL: 310
ABSTRACT: TRACING ON SERVER USING TRACECLASS LOCKS (TM) BRINGS DOWN SERVER

PROBLEM DESCRIPTION:
Tracing on server using traceclass locks (which is part of tm
traceflag) brings adsm server down.

LOCAL FIX:
Disable traceclass locks by issuing the following command after
the trace enable tm command;
trace disable locks

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using the TM or LOCK trace parameters on
the TRACE ENABLE command. This applies to ADSM servers
at 3.1.0 and up as well as TSM 3.7.0 up to TSM 4.1.1.
****************************************************************
* PROBLEM DESCRIPTION: *
The server can crash if the
LOCK or DEADLOCK trace flag is in use and tracing has begun.
****************************************************************
* RECOMMENDATION: *
Apply the fixing PTF. Avoid the use of the LOCk
or DEADLOCK trace flags. If the TM trace flag is in use,
explicitly disable LOCK with the following command:
TRACE DISABLE LOCK.
****************************************************************
A check was missing for a null parameter on LOCK and
DEADLOCK trace. LOCK is included when TM is specified as
a TRACE keyword. Some locking calls use a null parameter.

PROBLEM CONCLUSION:
The code was updated to handle null parameters.

TEMPORARY FIX:
Avoid the use of the LOCK Trace parameter. If the TM
lock is specified, follow it with the TRACE DISABLE LOCK
command.

------

APAR: IY14255 COMPID: 576556402 REL: 310
ABSTRACT: DEADLOCK SITUATION CAUSING SERVER TO HANG DURING BACKUPS

PROBLEM DESCRIPTION:
A deadlock situation has been witnessed on AIX 4.3.1 server
running ADSM 3.1.2.57. Customer runs several scheduled client
backups along with an ADSM DB backup script. The script begins
with a 'delete volhist' command, and then continues with the DB
backup. Deadlock situation occurs when a client backup is
completing at the same time the 'delete volhist' command begins.
The 'delete volhist' needs a lock that the client backup is
holding and vice versa causing the deadlock situation.
The following output shows the deadlock:
From 'show threads'--
Thread 37: SessionThread
 tid=252d, ktid=88333, ptid=30, det=1, zomb=0,
join=0, result=0, sess=84
  Awaiting cond 30717750 (mutex 30717894) at
1019BBB0 (ssStore)
Thread 48: SessionThread
 tid=3036, ktid=27651, ptid=30, det=1, zomb=0,
join=0, result=0, sess=87
  Awaiting cond 308E6EE0 (mutex 3084E574) at
101954E0 (WaitBufEmpty)
Thread 84: SessionThread
 tid=5474, ktid=94973, ptid=30, det=1, zomb=0,
join=0, result=0, sess=109
  Awaiting cond 3071ECE8 (mutex 3011EB54) at
100119B4 (outGetNext)
From 'show locks'--
slot -> 33:
LockDesc: Type=77778, NameSpace=1,
SummMode=sLock, Key=''
  Holder: Tsn=0:54651214, Mode=sLock
  Holder: Tsn=0:54633103, Mode=sLock
  Holder: Tsn=0:54631420, Mode=sLock
slot -> 79:
LockDesc: Type=34000, NameSpace=0,
SummMode=sLock, Key=''
  Holder: Tsn=0:54631412, Mode=isLock
  Holder: Tsn=0:54631420, Mode=sLock
  Waiter: Tsn=0:54633118, Mode=ixLock
  Waiter: Tsn=0:54638509, Mode=sLock
  Waiter: Tsn=0:54644149, Mode=sLock
  Waiter: Tsn=0:54645273, Mode=ixLock
  Waiter: Tsn=0:54645335, Mode=sLock
  Waiter: Tsn=0:54645529, Mode=sLock
  Waiter: Tsn=0:54649350, Mode=sLock
  Waiter: Tsn=0:54650889, Mode=ixLock
  Waiter: Tsn=0:54651038, Mode=sLock
 slot -> 153:
 LockDesc: Type=77778, NameSpace=3,
 SummMode=sLock, Key=''
   Holder: Tsn=0:54651214, Mode=sLock
   Holder: Tsn=0:54633103, Mode=sLock
 slot -> 199:
LockDesc: Type=77778, NameSpace=8,
SummMode=xLock, Key=''
  Holder: Tsn=0:54631411, Mode=xLock
slot -> 274:
LockDesc: Type=77778, NameSpace=5,
SummMode=sLock, Key=''
  Holder: Tsn=0:54651214, Mode=sLock
  Holder: Tsn=0:54633103, Mode=sLock
slot -> 348:
LockDesc: Type=77778, NameSpace=2,
SummMode=sLock, Key=''
  Holder: Tsn=0:54651214, Mode=sLock
  Holder: Tsn=0:54633103, Mode=sLock
  Holder: Tsn=0:54631420, Mode=sLock
slot -> 394:
LockDesc: Type=77778, NameSpace=7,
SummMode=xLock, Key=''
  Holder: Tsn=0:54631411, Mode=xLock
  Waiter: Tsn=0:54631420, Mode=sLock
  Waiter: Tsn=0:54633103, Mode=sLock
  Waiter: Tsn=0:54638466, Mode=xLock
  Waiter: Tsn=0:54651214, Mode=sLock
slot -> 398:
LockDesc: Type=23000, NameSpace=0,
SummMode=xLock, Key=''
  Holder: Tsn=0:54631420, Mode=xLock
  Waiter: Tsn=0:54631422, Mode=xLock
  Waiter: Tsn=0:54631425, Mode=xLock
  Waiter: Tsn=0:54631618, Mode=sLock
  Waiter: Tsn=0:54632961, Mode=sLock
  Waiter: Tsn=0:54632968, Mode=sLock
  Waiter: Tsn=0:54632973, Mode=sLock
  Waiter: Tsn=0:54639865, Mode=sLock
  Waiter: Tsn=0:54643171, Mode=sLock
slot -> 422:
LockDesc: Type=77777, NameSpace=0,
SummMode=ixLock, Key=''
  Holder: Tsn=0:54651214, Mode=isLock
  Holder: Tsn=0:54638466, Mode=ixLock
  Holder: Tsn=0:54633103, Mode=isLock
  Holder: Tsn=0:54631420, Mode=isLock
  Holder: Tsn=0:54631411, Mode=ixLock
slot -> 468:
LockDesc: Type=77778, NameSpace=4,
SummMode=sLock, Key=''
  Holder: Tsn=0:54651214, Mode=sLock
  Holder: Tsn=0:54633103, Mode=sLock
Problem has been reported as intermittent.

LOCAL FIX:
Possible workaround is to spread out the scheduled backups.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All users of the ADSM and TSM server.
****************************************************************
* PROBLEM DESCRIPTION: *
Server deadlock situation may occur when performing normal
client backups and DELETE VOLHISTORY command.
****************************************************************
* RECOMMENDATION: *
Apply the applicable PTF when available.
****************************************************************

PROBLEM CONCLUSION:
The server is modified to prevent the deadlock situation.

TEMPORARY FIX:
Do not perform DELETE VOLHISTORY while normal client backups
are running.

------

APAR: IY14257 COMPID: 576556402 REL: 310
ABSTRACT: WHEN PERFORMING A BACKUP OF ON BKUPCPY STGPOOL, USING OPTIONS

PROBLEM DESCRIPTION:
The command BACKUP STG with the parameters MAXPR=2 and WAIT=YES
from the command line. The backup was not started and the server
the server terminates with "ANR7838S - Server operation
terminated.
..
The following is from the customer's dsmlog:
..
000908-093002: ANR0407I Session 4 started for administrator STG
000908-093002: ANR0407I 33(32823)).
000908-093002: ANR2017I Administrator STGADMIN issued command:
BACKUP S
000908-093002: ANR2017I tapecopy maxpr=2 wait=yes
ANR0984I Process 1 for BACKUP STORAGE POOL started in the
FOREGROUND at 09:30:03.
ANR2110I BACKUP STGPOOL started as process 1.
ANR1210I Backup of primary storage pool DISKPOOL to copy storage
pool TAPECOPY
ANR1210I started as process 1.
ANR0405I Session 4 ended for administrator STGADMIN (AIX).
ANR9999D Invalid condition object at 0 - magic number mismatch;
thread 37 (tid 0).
ANR7838S Server operation terminated.
0x00000000 *UNKNOWN*
..
The customer ran the followin trace: "TRACE ENABLE THREAD DFCOPY
AFCOPY ADMCMD". Trace file indicated the following information:
..
11:07:45.523 <26>pkthread.c(1004): Thread 26 (tid 1a55) awakened
after 60000 ms.
11:07:45.525 <26>pkthread.c(973): Thread 26 (tid 1a55) delaying
for 60000 ms.
This continues for about one minute. Then you see the following:
..
11:07:59.189 <27>admcmd.c(1566): Command: backup stg diskpool
tapecopy maxpr=2 wait=yes.
11:07:59.193 <27>admcmd.c(1567): admin=STGADMIN, txnStarted=
False, txnld=none, impliedCommit=True, type=0
11:07:59.195 <27>admcmd.c(1996): Local Command: backup stg
diskpool tapecopy maxpr=2 wait=yes
11:07:59.255 <27>dfbackup.c(1052): Process 0 reserving cluster
srvld=0, ck1=2 for backup of pool DISKPOOL(5).
11:07:59.299 <27>pkthread.c(636): Thread 27 (SmAdminCommandThrea
d) has created a new thread 28 (DfBackupPoolThread).
11:07:59.299 <28>dfbackup.c(572): Backup thread beginning for
disk pool DISKPOOL(5) to copy pool TAPECOPY(-1).
11:07:59.301 <27>pkthread.c(893): Thread 27 (tid 1b5e) has
detached thread 28 (tid 1c5f).
11:07:59.305 <27>dfbackup.c(438): Backup process not started for
pool DISKPOOL(5)-initial cluster not available.
11:07:59.318 <27>pkthread.c(2415): Thread 27 exiting; result=0
..
The problem is that when we serialize the threads for backup
stgpool wait=yes, if there was no data moved, we delete a data
structure that is used to serialize the threads.

LOCAL FIX:
Use backup stg <primary pool> <copy pool> maxpr=1 wait=no

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Users of the ADSM V312 server or TSM V37 or TSM V41 servers.
****************************************************************
* PROBLEM DESCRIPTION: *
During a "BACKUP STGPOOL WAIT=YES" the server may crash if
there was no data eligible to be backed up from fromStgpool
on the command.
****************************************************************
* RECOMMENDATION: *
Apply the ptf containing this fix once it is available.
****************************************************************
The server BACKUP STGPOOL algorithm has been modified to
correct the WAIT=YES behavior. Specifically, if no eligible
files are found to backup, the server will not crash and
will continue processing normally.

PROBLEM CONCLUSION:
The server BACKUP STGPOOL process encountered a timing
problem in cases where no data was eligible to be backed up.
In this case, this could cause a server crash depending upon
the timing of the situation. The fix addresses this timing
problem and correct for this.
The impact assessment for this apar is HIGH.

------

APAR: IY14258 COMPID: 576556402 REL: 310
ABSTRACT: WEB ADMIN SESSIONS HANG. APPEARS TO BE LOOP IN PAGE FETCH

PROBLEM DESCRIPTION:
WEB Admin session hang on TSM server. Sessions will not cancel.
Show thread output at the time the WEB Admin sessions are hung
show they are waiting on a condition in TbKillPrefetch. This
code is waiting for a fetch to complete. It appears that the
buffer prefetcher is in a loop which is keeping it from
completing.
Initial impact: Medium

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM/TSM users on all platforms.
****************************************************************
* PROBLEM DESCRIPTION: *
WEB ADMIN session hang and CPU utilization increases.
The problem is caused by a LOOP in the buffer prefetcher.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
Fixed the buffer prefetcher to prevent the LOOP from occuring.

TEMPORARY FIX:
Use the server option NOBUFPREFETCH in the server options file.
This will prevent the buffer prefetcher from running.

------

APAR: IY14294 COMPID: 576556402 REL: 310
ABSTRACT: FAILED STATUS IS INCORRECT FOR CLIENT SCHEDULE

PROBLEM DESCRIPTION:
Client schedule with action=command. The scheduler
started with Session 4453 (19:32::11) which then
triggers Session 4455 (13:35:54) to start
the api backup (SQL-BACKTRACK).
The backup does not complete until 5 hours later
(00:39:42). ADSM then attempts to udpate the event
status, which results in ANR2576W. However, 15
minutes into the backup the scheduler session ended
with idletimeout (19:47:59). Problem is with this
session not staying active.
If script completes within one hour (schedule duration)
it is not a problem; and if idletimeout was set to 5
hours, they might not see a problem. However, customer
has intentionally set duration to 1 hour and wants this
to fail if backup does not start within duration
window. Setting Idletimeout to 5 hours could cause
problems for other clients network problems.
ADSM should be able to handle the event update either
by keeping the session active or by allowing the session
to be reconnected. Customer should not have to circumvent
by increasing idletimeout or schedule duration.
The FAILED status just because the scheduler session
is no longer active is also incorrect. ADSM should
indicate something like INPROGRESS until backup completes
SUCCESSFUL or FAILED.
This could be addressed several ways
let client disconnect, but let daemon remain
busy (no other schedules can start) when event
complets client reconnects to server, updates
schedule; no extra session; and prevents
misinterpretation of which schedule completed
OR
server runs schedule forwards id string to identify the schedul
OR
spinoff threads; parallel schedule
OR
chg client; invoke script w/successful; doc in book
This problem is recreatable on all Server platforms.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All ADSM and TSM V3.x servers.
****************************************************************
* PROBLEM DESCRIPTION: *
If there is a client schedule with 'ACTION = COMMAND' and the
'IDLETIMEOUT' is smaller than the time that takes to do the job
ADSM reports that the job is failed at the end of IDLETIMEOUT
even though the job is not finished.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
If there is a client schedule with 'ACTION = COMMAND' and the
'IDLETIMEOUT' is smaller than the time that takes to do the job
ADSM reports that the job is failed at the end of IDLETIMEOUT
even though the job is not finished.

PROBLEM CONCLUSION:
ADSM/TSM Server code has been modified to handle this situation.

------

APAR: IY14296 COMPID: 576556402 REL: 310
ABSTRACT: THE DELETE FILESPACE PROCESSING SHOULD EXPLOIT THE TXNGROUPMAX

PROBLEM DESCRIPTION:
The file deletion processing being used is grouping transactions
as 16 files per batch. It should be using the txnGroupmax as
setin the server options file. It is using a hard coded
constant to set this value. With the current code, the
delete process is extremely slow.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Affected customers are those who use the ADSM Delete Filespace
administrative or client command.
****************************************************************
* PROBLEM DESCRIPTION: *
The performance of the Delete Filespace command can be much
slower than that of the Delect Volume command. The text of
this APAR suggests that transaction sizes for Delete Filespace
be controlled by the TXNGROUPMAX server option, assuming
that performance for this command could be improved by
adjusting transaction sizes.
****************************************************************
* RECOMMENDATION: *
****************************************************************
Server Development does not plan to allow control of Delete
Filespace transaction sizes using the TXNGROUPMAX option, since
this option is used for transactions involving client-server
sessions. The hard-coded transaction size for Delete Filespace
has been increased for ADSM V3 servers. This may provide some
performance improvement for this command. However, there are
still significant algorithmic differences between the Delete
Filespace and Delete Volume commands that probably
have a much greater effect on performance than the
transaction size.

PROBLEM CONCLUSION:
The performance difference between Delete Filespace and Delete
Volume is not caused by a bug in Delete Filespace, but by
differences in the nature of these commands and the algorithms
used. In particular, Delete Filespace should never be compared
with deletion of copy pool volumes, since the later operation
can be performed using a much shorter code path.
In the future, ADSM Development may enhance the algorithm for
Delete Filespace in an effort to achieve improved performance.

------

APAR: IY14299 COMPID: 576556402 REL: 310
ABSTRACT: VM SERVER ABEND ON CLIENT RESTORE WITH INCORRECT AUTHORITY

PROBLEM DESCRIPTION:
VM Server abends. The node is attempting to restore a file
owned by another node when proper authority has not been
granted to the node doing the restore.
Solaris client encounters ANE4007E (Session: xxxxx, NODE:xxxxx
error processing /export/home/sold615.pkg).

LOCAL FIX:
Correct authority for client node doing restore.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM 3.1.2 level servers on all platforms
****************************************************************
* PROBLEM DESCRIPTION: *
crash during no query restore
****************************************************************
* RECOMMENDATION: *
apply fixing ptf when available
****************************************************************
Customer issued a no query restore request. The server
crashed.

PROBLEM CONCLUSION:
After analyzing the dump, it was determined that server
execution had gone astray in a no query restore routine.
Exactly why that path was taken is undetermined ... the
reason should be related to processing for the transaction
group size determined by the client and server, and not
specifically to authorization checking mentioned in the pmr.
Breaches in the protocol that lead to the crash were repaired.

------

APAR: IY14300 COMPID: 576556402 REL: 310
ABSTRACT: CONVERT USSFILESPACE ANR2000E 3.1.2.50

PROBLEM DESCRIPTION:
The command CONVert USSFilespace was inadvertently deleted for
the administrator commands table in the ADSM Sever level
3.1.2.50 code level. Therefore, when an authorized
administrator issues this command on the 3.1.2.50 sever he or
she receives the following messages and no conversion is
performed.
  ANR2000E Unknown command - Convert.
  ANS8001I Return Code 2.
Users should convert their USS client file systems before
upgrading to level 3.1.2.50 or they should upgrade to the
Tivoli Storage Manager product which did not suffer this
problem.
ADDITIONAL KEYWORDS: MSGANR2000E MSGANR2000 ANR2000 MSGANS8001I
MSGANS8001 ANS8001 CMD/CONV SCMD/USSF

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
ADSM V3.1.2 server users that have OEMVS filespace data.
****************************************************************
* PROBLEM DESCRIPTION: *
Cannot issue CONVERT USSFILESPACE due to it is not available
on the server.
****************************************************************
* RECOMMENDATION: *
Apply fixing PTF when available.
****************************************************************
The CONVERT USSFILESPACE command was inadvertantly made not
available on the V3.1.2 ADSM server. Thus the user received
ANR2000E Unknown command ..... when issuing the command.

PROBLEM CONCLUSION:
The server code has been fixed to put back the
CONVERT USSFILESPACE command.

------

APAR: IY14564 COMPID: 576556402 REL: 310
ABSTRACT: ANR ANR9999D INVALID STREAM DESCRIPTION IN OUTCANCELSTREAM().

PROBLEM DESCRIPTION:
ANR8216W Error sending data on socket 2.
ANR9999D DSMSERV/QCSRC/OUTINIT(629): Invalid stream descriptor
 in outCancelStream().
Customer receives above message and then attempt has to
manually cancel sessions to avoid high cpu.
Customer has fix for PQ33234 applied on his system and is
still seeing this error message.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This APAR effects all users of ADSM 310 and 312 on VM and AS400
and TSM 37 and 41 on all supported platforms (MVS, AIX, NT, SUN
HP).
****************************************************************
* PROBLEM DESCRIPTION: *
When canceling a web session that appears to be hung and is in
the receive state, a ANR9999D error message appears stating
you can not close a NULL stream.
****************************************************************
* RECOMMENDATION: *
Install PTF when available. The message does no harm to
your server or data contained on the server.
****************************************************************
The problem with NULL stream in a session being reported
when a session is cancel is fixed. The error message stating
that a NULL stream is being canceled should no longer appear
when canceling a session.

------

APAR: IY14566 COMPID: 576556402 REL: 310
ABSTRACT: WHEN UPDATING NODE WITH A WILDCARD, IF A NODE FAILS THE COMMAND

PROBLEM DESCRIPTION:
From the admin command line, update node * will give ANR2063I
Node <nodename> updated. until encountering an active node, and
then gives the error message ANR2150E update node: node <node
name> is currently accessing the server. and processing of the
update node * command stops. There is no message explaining tha
t the nodes currently updated were rolled back prior to the
update node * command. When scheduling the update node * comman
d with an administrative command, you at least get a message
telling you that the scheduled event failed, but still can be
misleading in that it doesn't mention rolling back the nodes
that had been updated.

LOCAL FIX:
The workaround for updating nodes with wildcard so that you can
be sure that the nodes will be updated is to:
1) disable sessions
2) cancel session all
3) update node * (whatever you wanted to update)
4) enable sessions
This prevents an active node from preventing all the other nodes
from being updated.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
All platforms for ADSM 310, 312 and 370 servers
****************************************************************
* PROBLEM DESCRIPTION: *
Insufficient messages issued when an UPDATE NODE updating
multiple nodes fails because a node is in use.
****************************************************************
* RECOMMENDATION: *
Apply the PTF when available.
****************************************************************
Message has been added to help clarify that a rollback of
previously updated nodes will occur when an UPDATE NODE
command processing multiple nodes fails because a node
is in use.

------

APAR: IY14569 COMPID: 576556402 REL: 310
ABSTRACT: SHOW ARCHIVEDUMPS A SOLARIS SERVER IF ISSUED ON A MOUNTPOINT OF

PROBLEM DESCRIPTION:
Show archive dumps a solaris server if issued on a mountpoint of
a filesystem: To recreate:
1. Archive the root directory, 'dsmc ar /'
2. On an admin console issue 'show archive <nodename> /'
3. The server abends due to segmentation violation
The problem seems to be a NULL pointer read created
from the database page record which represents the '/'
directory. This pointer is created in imShowArchives()
by tbGetStrPtr( arRow, IMAR_LL ) which returns the
empty string red-colored below. The subseqent
outprintf() --> StdPutText() fails with segmentation
violation.
The according db entry looks like:
Partition Key ->(00000012)(0000001D)(01)<-
  Record 0 (KeyLen=9, DataLen=134):
    Key: ->(2F)(<empty string>)(00000001)(0000000000230295)<-
where <empty string> results in a null pointer.

LOCAL FIX:
Use select, or query archive.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
312 Sun Servers.
****************************************************************
* PROBLEM DESCRIPTION: *
Show archive dumps a solaris server if issued on a mountpoint of
a filesystem.
****************************************************************
* RECOMMENDATION: *
Avoid using the command until ptf provided.
****************************************************************

------

APAR: IY14577 COMPID: 576556402 REL: 310
ABSTRACT: ADSM/TSM DOC INDICATES ABBREVIATION FOR DEFINE MACHINE IS

PROBLEM DESCRIPTION:
Customer is reporting that the command DEFINE MACHINE
do not work as expected if he use the short syntax "DEF MA"
In this case he receive the MSG anr2000e

LOCAL FIX:
The statement "DEFINE MACHINE" is working OK.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Customers using Disaster Recovery Manager (DRM) on ADSM/TSM
312 and 370 servers.
****************************************************************
* PROBLEM DESCRIPTION: *
Server does not allow for using an abbreviation of MA for
the DEFINE MACHINE, UPDATE MACHINE, DELETE MACHINE or
QUERY MACHINE commands. MA is the abbreviation which is
documented in our command reference.
****************************************************************
* RECOMMENDATION: *
Apply PTF when available.
****************************************************************
Code has been modified to support an abbreviation of MA for the
DEFINE MACHINE, UPDATE MACHINE, DELETE MACHINE and QUERY MACHINE
commands.

TEMPORARY FIX:
When issuing the following commands use an abbreviation of
at least MACH:
  DEFINE MACHINE, UPDATE MACHINE, DELETE MACHINE, QUERY MACHINE

------

APAR: IY14579 COMPID: 576556402 REL: 310
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: IY14580 COMPID: 576556402 REL: 310
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: IY14582 COMPID: 576556402 REL: 310
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: IY14584 COMPID: 576556402 REL: 310
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: IY14716 COMPID: 576556402 REL: 310
ABSTRACT: DATABASE AUDIT FAILS ANR999D BFAGGRUT.C

PROBLEM DESCRIPTION:
The following output is generated when "dsmserv auditdb
fix=yes" is run:
ANR999D bfaggrut.c(754): Unexpected update for number of
files (1 >=1) in aggregated bitfile 0.2710540.
ANR2184W bfaudit.c631: Transaction 0:2583296 was aborted
for command AUDITDB.
ANR4142I AUDITDB: Database audit process terminated in
error
ADITIONAL KEYWORDS: 5698TSMAX 5698TSMHP 5698TSMNT 5698TSMSU
5697TSMVS 5697TSMAX 5697TSMHP 5697TSMNT
 5697TSMSU 565511901 5697TSM00 576556402
5639B2101 5639B2201 565511901 5769SV300
 NT AIX Solaris MVS AS/400
3.7.3 4.1
RECREATE DIRECTIONS: NONE

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
This problem may affect customers who perform a database audit
of a Tivoli Storage Manager or ADSM server. The problem can
occur for Version 3 or Version 4 servers.
****************************************************************
* PROBLEM DESCRIPTION: *
Under certain circumstances, a database audit can fail and
produce messages such as the following.
ANR999D bfaggrut.c(754): Unexpected update for number of
files (1 >=1) in aggregated bitfile 0.2710540.
ANR2184W bfaudit.c631: Transaction 0:2583296 was aborted
for command AUDITDB.
ANR4142I AUDITDB: Database audit process terminated in
error.
A message such as the following may also be observed.
Illegal update for logical size (0.1234567 > 0.123456)
of aggregated bitfile 0.123456.
****************************************************************
* RECOMMENDATION: *
The problem has been fixed in all Version 3 and Version 4
servers can be obtained in a future PTF.
****************************************************************
Customers who entounter this problem can apply the
PTF when it becomes available.

PROBLEM CONCLUSION:
This problem only occurs under very unique circumstances,
and can be avoided by applying the PTF when it becomes
available.

------

APAR: IY14717 COMPID: 576556402 REL: 310
ABSTRACT: ADSM SERVER NETWARE RESTORE ANR9999D SMNQR(235): INVALID OBJECT

PROBLEM DESCRIPTION:
Customer doing a RESTORE to an Netware client receives the
following error messages and the RESTORE is aborted.
Server: ANR9999D SMNQR(235): Invalid Object Header State in
         Retrieve operation for session ....
                    - or -
         ANR9999D SMTRANS(878): Invalid header size for Object
         Header.
Client: ANS1301E Server detected system error
         ANS1303E Client ended transaction
The ANS.... messages at the client may have many causes and
the user needs to verify that they received one to two ANR999D
messages at the server to verify if this APAR is related to
their problem.
There are two problems, first the RESTORE session is aborted
and, second, the ANR9999D message do not provide the required
information that IBM Service needs to assist the customer in
circumventing of fixing the problem.
The only circumvention know at this time is to do a directory
by directory RESTORE skipping those directories that fail. If
there are Netware Print queues on the volume being restored try
skipping the directories that contain the print queues.
ADDITIONAL KEYWORDS: MSGANS1301E MSGANS1303E

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: *
Users of ADSM servers which service no query restore request
from backup/archive clients.
****************************************************************
* PROBLEM DESCRIPTION: *
During no query restore operations, the restore may
fail with an ANR9999D SMNQR(235) Invalid Object Header
State in retrieve operation for session.....
A logic error occurred in the server did not reset
certain control information following a sink error.
As a result the above message was issued due to the
object header size being incorrect.
****************************************************************
* RECOMMENDATION: *
Apply ptf when available.
****************************************************************
The ADSM server was changed such that any sink error
will now cause the retrieve control information to
be reset.
In the event that the error does occur and the
ANR9999D message is issued, it was updated to include
the node name, object type (backup/archive/hsm),
filespace, file name and object ID. This will
provide additional information for diagnostics.

PROBLEM CONCLUSION:
Any sink error will now be recovered from and no
anr9999d message will be issued.

------

APAR: IY14785 COMPID: 576547875 REL: 710
ABSTRACT: SIGPIPE HANDLING INCORRECT FOR TEXT EXTENDER V7.1

PROBLEM DESCRIPTION:
sigpipe handling incorrect for text extender v7.1

------

APAR: IY15162 COMPID: 5697D1710 REL: 420
ABSTRACT: ENCONSOLE/ENCCP SHOULD NOT ALLOW AN OBJECT NAMED DEFAULT TO BE

PROBLEM DESCRIPTION:
Enconsole/enccp should not allow most operations on and object
with the name 'default'. Previously, you could create an
object named 'default' from enconsole or enccp, but when you
later tried to query/show the object, you ended up with the
default attributes for that attribute type. Other operations
on that object would either fatal, or have unexpected results
(because they too try to operate on the default object).

PROBLEM SUMMARY:
USERS AFFECTED: Encina users, Release 420
Enconsole/enccp should not allow most operations on and object
with the name 'default'. Previously, you could create an
object named 'default' from enconsole or enccp, but when you
later tried to query/show the object, you ended up with the
default attributes for that attribute type. Other operations
on that object would either fatal, or have unexpected results
(because they too try to operate on the default object).

PROBLEM CONCLUSION:
The solution to prevent the errors and confusion is to disallow
operations, excluding show/modify, on an object named
'default'. Show/modify on default is allowed, since those
commands operate on the default object. Users can no longer
create objects named 'default'.

TEMPORARY FIX:
enconsole default object

------

APAR: IY15163 COMPID: 5697D1710 REL: 420
ABSTRACT: HEURISTIC DAMAGE EVENT SHOULD BE WARNING

PROBLEM DESCRIPTION:
There is a heuristic damage trace point in the tmxa component
that is logged as an event. This message should be logged as a
warning.

PROBLEM SUMMARY:
USERS AFFECTED: Encina users, Release 420
There is a heuristic damage trace point in the tmxa component
that is logged as an event. This message should be logged as a
warning.

PROBLEM CONCLUSION:
Changed the tmxa trace event for 'Recording heuristic damage
for %s' to a warning.

TEMPORARY FIX:
tmxa heuristic

------

APAR: IY15164 COMPID: 5697D1710 REL: 420
ABSTRACT: DCE PRIN WITH $ IN THE NAME CANNOT COLD START MAS SERVERS.

PROBLEM DESCRIPTION:
Dce principals that have a "$" in the name could not cold start
any type of server. The same principals could warm start
servers once they had been cold started by another principal
that did not have this character in the uid.

PROBLEM SUMMARY:
USERS AFFECTED: Encina users, Release 420
Dce principals that have a "$" in the name could not cold start
any type of server. The same principals could warm start
servers once they had been cold started by another principal
that did not have this character in the uid.

PROBLEM CONCLUSION:
Encina looks for reference strings in the form of $string$. In
order to have a '$' in a direct value, it needs to be escaped
('$$'). Changes were made to scan direct value strings (-A for
cold starts, etc...) for '$' and insert a second '$' for each
occurrence.
Note: due to operating system restrictions this fix for Encina
4.2 is limited to supporting principal names with the $ sign at
the end of the string only. $'s in the middle or beginning will
result in startup failures.

TEMPORARY FIX:
enconsole dollar $$ principal

------

APAR: IY15165 COMPID: 5697D1710 REL: 420
ABSTRACT: TRPC_GETMANAGERFUNCTION NEEDS ENCINA_CALLING IN ITS PROTOYPE

PROBLEM DESCRIPTION:
A calling convention mismatch existed on the NT platform for
the trpc function - trpc_GetManagerInfo. Attempts to use this
function in NT applications resulted in the linker error -
"unresolved external symbol _trpc_GetManagerInfo" and required
user modification to the function prototype.

PROBLEM SUMMARY:
USERS AFFECTED: Encina users, Release 420
A calling convention mismatch existed on the NT platform for
the trpc function - trpc_GetManagerInfo. Attempts to use this
function in NT applications resulted in the linker error -
"unresolved external symbol _trpc_GetManagerInfo" and required
user modification to the function prototype.

PROBLEM CONCLUSION:
Changes were made to the prototype to correct this problem.

------

APAR: IY15166 COMPID: 5697D1710 REL: 420
ABSTRACT: TRANSLATETRACEID DISLIKES LANG=C

PROBLEM DESCRIPTION:
The translateTraceId tool did not work correctly on the HP_UX
platform with the environment variable LANG=C set. Certain
function calls used to retrieve data from catalog files
returned format strings instead of the actual data.

PROBLEM SUMMARY:
USERS AFFECTED: Encina users, Release 420
The translateTraceId tool did not work correctly on the HP_UX
platform with the environment variable LANG=C set. Certain
function calls used to retrieve data from catalog files
returned format strings instead of the actual data.

PROBLEM CONCLUSION:
Changes were made to use NLS safe function calls to retrieve
the message data. almasy-Thu, 30 Nov 2000 14:06:44

------

APAR: IY15211 COMPID: 5697D1710 REL: 420
ABSTRACT: TXSERIES 4.2 ENCINA ON AIX 4.2.1 AND AIX 4.3.1 PTF 15 REFERENCE

PROBLEM DESCRIPTION:
TXSERIES 4.2 ENCINA ON AIX 4.2.1 AND AIX 4.3.1 PATCH 15
REFERENCE APAR.
THIS APAR SHOULD BE USED WHEN ORDERING THE LATEST TXSERIES
ENCINA 4.2 MAINTENANCE ON THE AIX 4.2.1 AND AIX 4.3.1 OPERATING
SYSTEMS.
IY11173 IY15164 IY15162 IY15163 IY15166 IY15165

PROBLEM CONCLUSION:
IY11173 IY15164 IY15162 IY15163 IY15166 IY15165

------

APAR: IY15312 COMPID: 5765B8100 REL: 220
ABSTRACT: TSLOT SHUTS DOWN WITH "ALLOCATION FAILED" AT DT STARTUP

PROBLEM DESCRIPTION:
TSLOT shuts down with "allocation failed" at DT startup

PROBLEM SUMMARY:
TSLOT shuts down with "allocation failed" at DT
 startup

PROBLEM CONCLUSION:
Modified enable routine to correct
problem

------

APAR: IY15554 COMPID: 5765C3403 REL: 430
ABSTRACT: EXTRA SPACE IN FRENCH TRANSLATION OF TSM.MSG

PROBLEM DESCRIPTION:
Extra space in French translation causes customer
script to fail.

PROBLEM CONCLUSION:
Remove extra space from French translation of file tsm.msg

------

APAR: PQ44681 COMPID: 568819001 REL: 100
ABSTRACT: DUPLEX FORMDEF CREATES INCORRECT PGP STRUCTURED FIELD WHICH

PROBLEM DESCRIPTION:
Duplex formdef creates incorrect PGP structured field which
gives incorrout on AFP Viewer.

PROBLEM SUMMARY:
****************************************************************
* USERS AFFECTED: All users *
****************************************************************
* PROBLEM DESCRIPTION: PPFA generates bad PGP-2 structured *
* field for a duplex formdef. *
****************************************************************
* RECOMMENDATION: Apply the applicable PTF. *
****************************************************************
When a PPFA formdef is duplexed, an incorrect PGP-2 structured
field is generated. This causes the AFP Viewer to fail. With
this fix PPFA will generate the proper code.

------

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]