IV13225: DISCOVERYUPDATEMODE IS 0 AND LINGERTIME DESCREASED DURING PARTIAL REDISCOVERY

ITNMIP_Patch_V3.8.0.89_Win32
3.8.0-TIV-ITNMIP-Solaris-REF-FP0007
3.8.0-TIV-ITNMIP-Linux-REF-FP0007
ITNMIP_Patch_V3.8.0.89_AIXPPC32
IBM Tivoli Network Manager IP 3.9.0 Fix Pack 3, 3.9.0-TIV-ITNMIP-FP0003
IBM Tivoli Network Manager IP 3.9.0 Fix Pack 4, 3.9.0-TIV-ITNMIP-FP0004
IBM Tivoli Network Manager IP Edition 3.9.0 Fix Pack 5, 3.9.0-TIV-ITNMIP-FP0005

APAR status

• Closed as program error.

Error description

• The threading timing issue.
  In SendTopologyToModel.stch, disco sends the request of update
  to model.config for DiscoveryUpdateMode first, and sends the
  request of Topology data update request to model at the end of
  stitcher.
  
  However in the model side, it randomly got the message of
  Topology Data update earlier than the message of
  DiscoveryUpdateMode update in model.config. It turned out to use
  the un-updated DiscoveryUpdateMode 0 and decided the Lingertime
  to be checked.
  

Local fix

• N/A
  

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users                                                    *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * During the partial rediscovery which was initiated after a   *
  * full discovery,                                              *
  * the non-target devices LingerTime decreased                  *
  * to 2. The problem only occurs randomly.                      *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * Modify SendTopologyToModel.stch as described in Problem      *
  * Conclusion..                                                 *
  *                                                              *
  * The following fixpacks will contain the fix:                 *
  * | fix pack | 3.8.0-ITNMIP-FP0007                             *
  * | fix pack | 3.9.0-ITNMIP-FP0002                             *
  ****************************************************************
  

Problem conclusion

• The root cause is the threading timing issue.
  In SendTopologyToModel.stch, disco first oql request to model
  service for updating DiscoveryUpdateMode in model.config base on
  whether the full (0) or partial discovery (1).
  At the end of the stitcher, it will then send the Topology data
  update request to model.
  
  However in the model processes, it randomly got the message of
  Topology Data update earlier than the message of
  DiscoveryUpdateMode update.
  So it mistakenly used the previous (un-updated)
  DiscoveryUpdateMode 0 and decided the Lingertime to be checked
  when initiating a partial discovery right after a full
  discovery.
  

Temporary fix

• Resolution:
  Added RetrieveOQLFromService query in SendTopologyToModel.stch
  to check for the DiscoveryUpdateMode before the process of
  SendTopoRecordListToModel. This would push the update of
  model.config
  
          RecordList modelData = RetrieveOQLFromService(
              "select DiscoveryUpdateMode from model.config;",
              "Model"
          );
  
  
          int updateMode = 0;
          foreach(modelData)
          {
              updateMode = eval(int,'&DiscoveryUpdateMode');
              if (updateMode != isRediscovery)
              {
                  Print("DiscoveryUpdateMode has not been updated
  in model.config. ");
                  Print("Please contact support.");
              }
          }
          delete(modelData);
  

Comments

APAR Information

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

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

Fix information

• Fixed component name

  NC/PREC DISCOVY

• Fixed component ID

  5724O52DS

Applicable component levels

• R380 PSY

     UP

• R390 PSY

     UP