IBM Support



You can track all active APARs for this component.


APAR status

  • Closed as program error.

Error description

  • With the introduction of client failover to a replicated server,
    consistency checking was added to compare the last
    backup/archive/migration time from the server with a last
    backup/archive/migration time now stored in the client side
    database (tsmnrtable.DB). One of the fields included in each of
    these client database entries is the filespace name. Currently
    the Tivoli Storage Manager/Spectrum Protect client will
    incorrectly store the VSS snapshot name as the filespace name in
     the client database  if the option SNAPSHOTPROVIDERFS VSS is
    being used. This will create one of two problems depending up
    whether or not a prior backup/archive was performed without the
    SNAPSHOTPROVIDERFS VSS option in place.
    Problem 1
    If a backup/archive of the client filespace in question was
    performed without the SNAPSHOTPROVIDERFS VSS option then the
    client database would have a valid entry for the filespace with
    that date and time. On subsequent backup/archives with the
    SNAPSHOTPROVIDERFS VSS option in place, this older date and time
    would not match with the value returned from the server. This
    results in the following messages during backup and restore
    09/30/2015 19:02:32 ANS2120W The last store operation date
    reported by the server REPLSERVERNAME of 09/29/2015 23:54:24 UTC
    does not match the last store operation date of 06/29/2015
    23:12:44 UTC stored by the client.
    09/30/2015 19:17:52 ANS2120W The last store operation date
    reported by the server REPLSERVERNAME of 09/29/2015 23:54:24 UTC
    does not match the last store operation date of 06/29/2015
    23:12:44 UTC stored by the client.
    A client service trace of a new backup and subsequent restore
    from a windows client processing an object on the D: drive shows
    the following:
    The entry put into database at backup:
       Key ServerName   : TSMSRV1
       Key NodeName     : NODE1
       Key Data Type    : 65536
       Key File Space   :
       Sequence         : 25
       Last Update Time : 10/02/2015 18:39:42
    (Note the filespace value is a VSS snapshot name)
    The entry found on restore:
       Key ServerName   : TSMSRV1
       Key NodeName     : NODE1
       Key Data Type    : 65536
       Key File Space   : \\ac2\d$
       Sequence         : 0
       Last Update Time : 06/29/2015 23:12:44
    (NOTE: the filespace value is now accurate)
    Comparison seen in trace that is triggering the ANS2120W:
      serverStoreDate : 10/02/2015 18:39:42
      localStoreDate  : 06/29/2015 23:12:44
    NOTE: the date and time stamp here is in UTC so that client and
    server times can be validly compared without concern for whether
    or not they are in the same timezone.
    Problem 2
    If backup/archives have always been run with SNAPSHOTPROVIDERFS
    VSS then all the entries in the client database will have the
    incorrect filespace values. When the client looks for an entry
    in this database a match will not be found because it is looking
    for a record with the valid filespace name. With no record found
    the client does not think a backup of this filespace has ever
    occurred so it will not check for a filespace date and time on
    the server. This means that if the date and time of the
    filespace on the server is not current no notification/warning
    will be issued and the user will not be aware if there is an
    actual difference between the client and server.
    A client service trace of a backup for this case shows the
    record not found and the ?not backed up? indication for the
    filespace (when the user knows and can vadidate via a schedule
    log or query filespace through an Admin client that the
    filespace has been backed up):
    10/21/2015 09:51:55.791 [004756] [3484] :
    NodeReplicationTableTable::getLastStoreDate searching for
    serverName "TORINO" nodeName "TORINO" fileSpace "\\torino\c$"
    with data type 65536 (Backup data)
    10/21/2015 09:51:55.791 [004756] [3484] :
    ..\..\common\ba\nrtable.cpp( 618):
    NodeReplicationTable::getRecord sKey
    10/21/2015 09:51:55.791 [004756] [3484] :
    ..\..\common\ba\nrtable.cpp( 640):
    NodeReplicationTable::getRecord cache entry for
    'TORINO:TORINO:65536:\\torino\c$' not found .
    10/21/2015 09:51:55.791 [004756] [3484] :
    ..\..\common\ba\nrtable.cpp( 653):
    NodeReplicationTable::getRecord returning 104
    10/21/2015 09:51:55.791 [004756] [3484] :
    ..\..\common\ba\nrtable.cpp( 532): NodeReplicationTable::Close()
    Record bHaveFileLock true bCacheDbOpen true
    10/21/2015 09:51:55.791 [004756] [3484] :
    ..\..\common\ba\nrtable.cpp( 542): NodeReplicationTable::Close()
    closing database file
    10/21/2015 09:51:55.791 [004756] [3484] :
    NodeReplicationTableTable::getLastStoreDate couldn't find
    nrtable record rc 0
    10/21/2015 09:51:55.791 [004756] [3484] :
    ..\..\common\fs\filespac.cpp(3379): cuCompareFSQryRespTimes file
    space >\\torino\c$< not backed up
    Tivoli Storage Manager Versions Affected:
    TSM Backup-Archive client version 7.1.x; Windows Platform
    Initial Impact:
    Additional Keywords:
    ANS2120W, client replication, replication, node replication,
    tsm, failover, backup, restore, last store operation date

Local fix

  • User can delete the tsmnrtable.DB file located in the
    "..\TSM\baclient" directory to resolve the ANS2120W messages.
    This should only be performed if the user is absolutely certain
    the entries are incorrect. Testing a restore of the object(s) is
     advised prior to deleting the tsmnrtable.DB file.

Problem summary

  • ****************************************************************
    * USERS AFFECTED:                                              *
    * Tivoli Storage Manager Client versions 7.1.1, 7.1.2, 7.1.3   *
    * and 7.1.4 running on all Microsoft Windows platforms.        *
    * PROBLEM DESCRIPTION:                                         *
    * See ERROR DESCRIPTION                                        *
    * RECOMMENDATION:                                              *
    * This issue is projected to be fixed in the Tivoli Storage    *
    * Manager Client on Windows in level 7.1.6                     *
    * Note 1: This is subject to change at the discretion of IBM.  *

Problem conclusion

  • Correct filespace name is saved in node replication table.

Temporary fix


APAR Information

  • APAR number


  • Reported component name


  • Reported component ID


  • Reported release


  • Status


  • PE




  • Special Attention

    NoSpecatt / Xsystem

  • 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:


  • dsmagent dsm

Fix information

  • Fixed component name


  • Fixed component ID


Applicable component levels

  • R71W 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":"71W","Edition":"","Line of Business":{"code":"LOB26","label":"Storage"}}]

Document Information

Modified date:
15 March 2016