Direct links to fixes
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 number
IV13225
Reported component name
NC/PREC DISCOVY
Reported component ID
5724O52DS
Reported release
380
Status
CLOSED PER
PE
NoPE
HIPER
NoHIPER
Special Attention
NoSpecatt
Submitted date
2012-01-16
Closed date
2012-01-27
Last modified date
2012-01-27
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
[{"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSSHRK","label":"Tivoli Network Manager IP Edition"},"Component":"","ARM Category":[],"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"380","Edition":"","Line of Business":{"code":"LOB45","label":"Automation"}}]
Document Information
Modified date:
27 January 2012