[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference azur::mcc

Title:DECmcc user notes file. Does not replace IPMT.
Notice:Use IPMT for problems. Newsletter location in note 6187
Moderator:TAEC::BEROUD
Created:Mon Aug 21 1989
Last Modified:Wed Jun 04 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:6497
Total number of notes:27359

5078.0. "Child instance limitation & endless Get_Next loop" by VFOVAX::CARNELL (We're gonna need another Timmy!) Tue May 18 1993 12:08

Is there a limit to the number of child instances that can be defined using
the MIB extensions to the SNMP AM? 

We defined a child with 5000 instances and when we tried to show the whole 
thing mcc stoped at, and continued to ask for, instance 1000. A closer 
examination shows that when mcc reaches instance 1000 it issues the
"powerful" GET_NEXT to the object which returns 1001, but when mcc then 
issues a GET it uses 1000 instead of the returned value. Up to that point
everything works fine. We have let this run well beyond 5000 gets and mcc
shows no signs of terminating its endless loop.

VMS: V5.5-2
DECmcc: V1.3.0
TCPIP_AM: V1.3.0
System: VAXstation 4000/90 w/64mb
T.RTitleUserPersonal
Name		DateLines
5078.1RACER::daveAhh, but fortunately, I have the key to escape reality.Tue May 18 1993 13:541
Please file a QAR (See note #7)
5078.2QAR submittedVFOVAX::CARNELLWe're gonna need another Timmy!Wed May 19 1993 11:303
Submitted as QAR #00254.

Paul.
5078.3bug!MOLAR::PERRYWed May 19 1993 12:1511
    Paul,
    
    You're right. I looked at the SNMP AM code and found this nasty bug.
    The AM doesn't handle instances over 1000. If the SNMP AM receives an
    instance value greater than 1000, it will ignore it and continue issuing
    GetNext requests using an instance of 1000, forever.
     
    This bug will be fixed in the next release(hopefully the MUP).
    
    jim
5078.4Hum, Sorry...AEOENG::BOMMARTWaveWalker 887-4108Wed May 19 1993 13:1513
I had discovered this problem long time ago (see note 3256.7 & 3256.15).

After having read 3256.16, I thought that someone from the MCC SNMP AM team
worked on this problem...

I think it's my fault :-(

I would have QARed this earlier...

Sorry for that.

Regards,
Damien.
5078.5MOLAR::YAHEY::BOSEWed May 19 1993 19:3120
>>After having read 3256.16, I thought that someone from the MCC SNMP AM team
>>worked on this problem...

	Since I authored note 3256.16, I feel it is my responsibility to 
	clarify matters. Someone did work on the problem you had originally
	reported. Unfortunately, the fix that was put in did not cover all 
	the possible cases and the problem still partially exists.

>>I think it's my fault :-(

>>I would have QARed this earlier...

	Normally, it is good practice to file a QAR, but in this case it
	would have probably not made a difference.

>>Sorry for that.
	
	No need to be sorry. We are the ones who should apologise.

	Rahul.