IV64996: MODEL GETS INTO ENDLESS LOOP WHILE LINGERING SUBNET OBJECTS IF THEY CONTAIN MANY MEMBERS

3.9.0-TIV-ITNMIP-Solaris-FP0005
3.9.0_INSTALL_NLS_FP0005
3.9.0_INSTALL_FP0005
3.9.0-TIV-ITNMIP-Windows-FP0005
3.9.0-TIV-ITNMIP-zLinux-FP0005
3.9.0-TIV-ITNMIP-Linux-FP0005
3.9.0-TIV-ITNMIP-AIX-FP0005
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

• v3.9-FP3 -linux (applicable for GA - fp4 builds and platform
  independent )
  
  ncp_model process enters in a endless loop while lingering
  SUBNET objects if they contain too many members resulting other
  issues such as :
  a) Not able to process subsequent discovery updates
  b) Not able to respond to ncp_oql queries etc.
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:                                              *
  * All users                                                    *
  ****************************************************************
  * PROBLEM DESCRIPTION:                                         *
  * ncp_model process enters in a endless loop while lingering   *
  * SUBNET objects if they contain too many members resulting    *
  * other issues such as :                                       *
  * a) Not able to process subsequent discovery updates          *
  * b) Not able to respond to ncp_oql queries etc.               *
  ****************************************************************
  * RECOMMENDATION:                                              *
  * The following fixpacks will contain the fix:                 *
  * | fix pack | 3.9.0-ITNMIP-FP0005                             *
  ****************************************************************
  

Problem conclusion

• From  stack trace, it shows -
  Model is attempting to "fix" the lingering connections from a
  device which was not discovered but is lingering. It loop over
  each entity (including subnet entities) in the
  ExtraInfo->RelatedTo field. One of the subnet has a huge list of
  RelatedTo.
  
  #35 0x08066b74 in CMdlStoreMgr::MSMPerformOQLQuery
  (this=0x8129f58, ^M
      queryString=0xea47b228 "update master.entityByName set
  RelatedTo(NEXT) = ..................... at CMdlStoreMgr.cc:817^M
  #36 0x080a7e84 in CMdlLingerTime::FixLingeringConnection
  (this=0x819fd14, nameAtom=..., lingeredRelationNameAtom=...)^M
      at CMdlLingerTime.cc:1225^M
  #37 0x080a8a97 in CMdlLingerTime::FixLingeringConnections
  (this=0x819fd14) at CMdlLingerTime.cc:1139^M
  #38 0x080ab7b9 in CMdlLingerTime::FinishedBatch (this=0x819fd14,
  mdlCore=...) at CMdlLingerTime.cc:312^
  
  In the CMdlLingerTime::FixLingeringConnections code, it should
  not be processing subnets. So the fix would be to change that
  code to first check if lingerRec is a subnet before embarking on
  the marathon loop.
  

Temporary fix

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/PRECISIONIP

• Fixed component ID

  5724O52RC

Applicable component levels

• R390 PSN

     UP

• R390 PSY

     UP