IBM Support



You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • The TSM Server will fail client backups as a result of the
    following error received in the TSM Server activity log:
    ANR0102E imbkins.c(1048): Error 1 inserting row in table
    ANR0530W Transaction failed for session XXXX for
     node XXXXXXX (XXXXX) - internal server error detected.
    NOTE: The error message above may come from a
    different module but the text of the message will be the
    same. The key here is the  "error 1 inserting row in table
    "Object.Ids"" message.
    This problem can be encountered if a customer used
    either the dumpdb or unloadb off-line utility followed by
    the loaddb. If the loaddb is followed by a full, or inventory,
    auditdb with fix-yes, the problem will not be encountered.
    The error is caused because the loaddb process is not
    properly updating an inventory table with the correct
    Object Id to use for all new objects being inserted into
    the TSM DB. The frequency of the failures is dependent
    on how many Object Ids being assigned to the new
    objects are already in use in the TSM DB.
    Platforms affected: All TSM 5.2 and 5.3 Servers utilizing the
    loaddb utility
    Customer/L2 Diagnostics
    If the error above is being received after an
    unloadb/dumpdb is performed without this fix applied, most
    likely it is this APAR. This would only be true if a full, or
    inventory, auditdb was also not performed with fix=yes after
    the loaddb is complete.
    Initial Impact: Medium
    Additional Keywords:  InsertRecordChain imvars imv hwm high
                          water mark initialize loadformat format

Local fix

  • 1) Apply the fix.
    2) Run either a full auditdb or an auditdb of the inventory.
       The decision of which should be used is dependent on
       the amount of time available for the off-line utility. The
       inventory auditdb will run quicker but will not correct
       possible invalid entries in other areas of the TSM DB
       unrelated to this problem. Also, the auditdb of the
       inventory can still take a substantial amount of time.
    dsmserv auditdb inventory fix=yes
    dsmserv auditdb fix=yes
    3) Manually correct the invalid entry in the TSM DB. This
       should be the last resort and should be performed under
       the guidance of L2 Support if an auditdb cannot be performed
       or the fix cannot be applied.

Problem summary

  • ****************************************************************
    * USERS AFFECTED: The TSM server APAR IC45034 changed the      *
    *                 behavior during LOADDB processing which      *
    *                 results in this error.  The APAR IC45034     *
    *                 was delivered in fix levels:,        *
    *                 5.2.5,, and 5.3.2.                   *
    *                                                              *
    *                 This problem affects those users that        *
    *                 performed either a database                  *
    *                 reorganization (UNLOADDB, LOADFORMAT,        *
    *                 LOADDB) or those that performed a            *
    *                 database salvage (DUMPDB,                    *
    *                 LOADFORMAT, LOADDB).                         *
    * RECOMMENDATION: Apply fixing level when available. This      *
    *                 problem is currently projected to be fixed   *
    *                 in level, 5.2.7,, and        *
    *                 5.3.3. Note that this is subject to          *
    *                 change at the discretion of IBM.             *
    This fix addressed two areas of processing:
    First, the LOADFORMAT processing has been
    modified to prevent this situation from occurring.
    If a database UNLOAD or DUMPDB was performed, use
    a server level containing this fix to perform
    the LOADFORMAT and subsequent LOADDB processing.
    Second, the server initialization and startup processing
    will evaluate the server's highest known identifiers and
    compare these to the database.  If these values are
    not correct, they will be corrected as part of
    the server startup processing.

Problem conclusion

  • An error was introduced into the server
    LOADFORMAT/LOADDB processing that causes
    internal highest known identifier information
    within the server to be incorrect.  This will likely
    result in operational failures for any of the following
    1) Backup, Archive, or Space management insertion of
    new data on the server.
    2) Import of new data on the server.
    3) Creation of new storage pools.
    4) Creation/assignment of new storage pool volumes.
    If an AUDITDB FIX=YES was performed after
    having done a LOADFORMAT/LOADDB, then these
    internal highest known identifier values
    would have been corrected.

Temporary fix


APAR Information

  • APAR number


  • Reported component name

    TSM SERVER 510

  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention


  • Submitted date


  • Closed date


  • Last modified date


  • APAR is sysrouted FROM one or more of the following:

  • APAR is sysrouted TO one or more of the following:

    PK13867 PK13869

Fix information

  • Fixed component name

    TSM SERVER 510

  • Fixed component ID


Applicable component levels

  • R52A PSY


  • R52H PSY


  • R52L PSY


  • R52P PSY


  • R52S PSY


  • R52W PSY


  • R53A PSY


  • R53H PSY


  • R53L PSY


  • R53S PSY


  • R53W PSY


[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\/TPS"},"Product":{"code":"SSGSG7","label":"Tivoli Storage Manager"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"52A","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
04 January 2006