Conference azur::mcc

>	A table of 1000 data is defined in this MIB extension. 

	The problem is that you defined DTDRDATA as subclass which has a number
of instances (1000). After this you asked Exporter to export ALL instances of
this entity class and Exporter tries created an separate exporting request
for each entity instance.

	The only solution I can see is to move this table information from
    the identifier partition to another( may be characteristics?) and to
    have a single  DTDRDATA entity.


	Sam Shmuylovich
    

	Sam,
		DTRDATA is defined in the Sintrom POD mib as a table with
	upto 2400 rows in it. This table is indexed by dtdrTimeSlot. For
	that reason tables are modeled as subclasses with its index as
	an identifier attribute. Thus to get at the row corresponding to
	dtdrTimeSlot 200, one must specify

	MCC> show snmp blah sintromDataNet podMib dtdrData 200 all attr

	It is not possible to change the entity model and still have things
	work as above.

		TCPIP PA FM had a similar problem while trying to gather
	interface statistics. Chipcom has 272 interface instances, which
	would cause PA to create 272 threads and ultimately bring the
	system down to its knees. Finally the algorithm had to be changed
	to limit the total no. of threads created simultaneously. I don't
	know how the Exporter is going to handle this problem, but I guess
	something has to be done to prevent creating 1000 threads 
	at the same time.

	rahul.	

    
    
    
	RE: .2
    
	The difference between TCPIP PA and Exporter is that TCPIP PA handles
 directive (Show ... All Statistics) only for one global entity class so it
 can be customized to the particular class. Exporter FM allows to export 
 information for any entity class in a generic way.

 On the wish list for V1.3 Historian FM has such function as One Time Record
 which allows to make a snap shot of data. This function will be done in
 foreground process and will not create multiple threads. Later it's possible
 to use a "past time Export" operation to export desired historical data into 
 RDB (past time export is also done in foreground in one thread).

 Do you think it is a reasonable solution?

  Sam
    

	Sam,

	Sounds good. Any solution that limits the number of simultaneous
	threads created is a reasonable solution.

	Rahul.

Thanks for your help. Back to these 2400 values...

When we use the Iconic Map PM, we double click on dtdrdata and we see ONLY
999 values of the table (from 1 to 999).

Is there a known restriction (bug ?) preventing the iconic map PM to display
more than 999 subentities in the same window ???

If we use the FCL PM, no problem to access the other values: dtdrdata 1000,
dtdrdata 1001, .... dtdrdata 2400

I thank you in advance,
Regards,
Damien.

    re:.5
    
    Nope.  The iconic map will try to display them all.  Try issuing a 
    SHOW <class> <instance> dtdrdata *, to file tmp.dat
    
    Edit the file and see if all of the children are in the file.
    If they are there, send me mail {took::lemmon}.  If not, find out
    why your access module isn't returning all of them when a "*" is
    specified.
    
    /Jim

Jim,
	Sorry for the late answer (I was not present).
	You are right !
	This problem is not related to the Iconic Map at all. We find the same
	behavior when we do a:

MCC> sho snmp groumph sintromdatanet podmib dtdrdata * all char, to file tmp.dat


	The file tmp.dat contains ONLY the 999 first values of the DTDRDATA
	table ! (it should contain 2400 values)

	When we try to access individually with the FCL PM the other values
	of the tables, it works:

MCC> sho snmp groumph sintromdatanet podmib dtdrdata 1000 all char

SNMP groumph sintromDatanet podMIB dtdrData 1000
AT  9-JUL-1992 09:39:14 Characteristics

Examination of attributes shows:
                       dtdrVoltageLevel = 134

MCC> sho snmp groumph sintromdatanet podmib dtdrdata 2400 all char

SNMP groumph sintromDatanet podMIB dtdrData 2400
AT  9-JUL-1992 09:39:35 Characteristics

Examination of attributes shows:
                       dtdrVoltageLevel = 0




Therefore the problem seems to come from the wildcarding with the SNMP AM...

Is there a known restriction (bug ?) in the standard TCP/IP SNMP Access Module
preventing to handle more than 999 values in a MIB table ??

I thank you in advance,
Regards,
Damien.

	Damien,
		The SNMP AM has no restrictions at all regarding the number
	of table entries it can handle. It keeps doing an SNMP GetNext
	request on the table objects till it runs off the table. The AM
	decides whether it is still inside the table by looking at the
	objectid returned by the agent, (which should be for the lexinext 
	object). 

		The only explanation I can think of for the behaviour you 
	are encountering is that the agent is returning an objectid outside
	the table when a GetNext request is made to the 999th object. This
	would make the SNMP AM think that there no more rows left in the
	table, and consequently it will conclude its operations.

		You can verify this by walking through the mib using our
	mib query utility. On VMS define the symbol

		MQ :== $SYS$SYSTEM:MCC_TCPIP_MQ.EXE

	and use it as a foreign command. If you do not provide any options
	in the command invocation, the utility will provide you with a list
	of options and what they do.

	Rahul.

Rahul,
	Thank you very much for your (remote) help.
	I really do appreciate it.

	I have defined the MQ foreign command and the only help that I get
	from this tool is:

$ mq
Program usage:  MIB_Query   Identifier   Pdu   Mode

Parameters:
        Identifier - The host (domain) name
        Pdu        - The SNMP Pdu ( 0 for Get, 1 for GetNext )
        Mode       - 0 for stepwise, 1 for continuous

The "Pdu" and "mode" parameters are obvious but the first one (identifier) is
not very clear for me. I have tried a lot of commands and have always received
the following answer:

	"Cannot resolve host name."

For example I have tried:
$ mq "snmp groumph sintromdatanet podmib dtdrdata" 1 0

Where is my mistake ? What does this tool expect in the "identifier" parameter ?
I thank you in advance (once again...)
Regards,
Damien.

	Damien,
		The identifier that the mib query utility expects is just
	the host name. So, to walk through the mib starting at a certain
	point, you have to do the following.

	$ mq groumph 1 0
	OID>

		The utility will prompt you for an object id at which to
	start the GetNext operation. You will have to enter the oid for 
	the beginning of the table to start stepping through it.

	Rahul.

Hum...
I can't still use your tool. Did it work with DECmcc T1.2.7. (I haven't had the
time to install the SSB V1.2)
Here are exactly the commands that I execute: You can see that with the FCL PM
I can access without any problem the TCPIP node "groumph".
Any idea why I get the message "Cannot resolve host name" ???
By the way (to avoid a new note exchange :-), what is the format expected by
your tool for the Object ID: something like:
	OID> "1.3.6.1.4.1.131.2.5.1.2.4" ???
	OID> "{ 1 3 6 1 4 1 131 2 5 1 2 4 }" ???
	OID> another syntax ???

Sorry to disturb you once again...
Regards,
Damien.

$ mq :== $sys$system:MCC_TCPIP_MQ.EXE
$ mq groumph 1 0
Cannot resolve host name.

$ manage/enterprise
DECmcc (T1.2.7)

MCC> show snmp groumph all attributes

SNMP groumph
AT 10-JUL-1992 18:08:13 All Attributes

                                Address = 16.188.192.170
                                   Name = -- Attribute Not Gettable
                        Registered Name = DSP_NS:.groumph
                         ipReachability = up
                              sysUpTime = 131760443
                             sysContact = -- Attribute Not Available
                               Location = "salle telecom engineering"
                    Implementation Desc = -- Attribute Not Available
                     Responsible Person = -- Attribute Not Available
                           Phone Number = -- Attribute Not Available
                           MAIL Account = -- Attribute Not Available
                    Implementation Desc = -- Attribute Not Available
                     Responsible Person = -- Attribute Not Available
                           Phone Number = -- Attribute Not Available
                           MAIL Account = -- Attribute Not Available
                                Remarks = -- Attribute Not Available
                              Text File = -- Attribute Not Available
MCC>

>$ mq groumph 1 0
>Cannot resolve host name.


This symptom suggests that a call to UCX to translate the name
to address is failing.
Is "GROUMPH" in your UCX database?  UCX is case sensitive, and VMS
translates to upper case by default.  You can check with

$ UCX SHOW HOST GROUMPH
$ UCS SHOW HOST "groumph"

>$ mq groumph 1 0
>Cannot resolve host name.


This symptom suggests that a call to UCX to translate the name
to address is failing.
Is "GROUMPH" in your UCX database?  UCX is case sensitive, and VMS
translates to upper case by default.  You can check with

$ UCX SHOW HOST GROUMPH
$ UCX SHOW HOST "groumph"

	The format for specifying the oid is -

	OID> 1.3.6.1.4.1..........

First of all my apologies for this late reply...

Thank you Erik you were right, the "problem" came from the command line I gave
to the MQ tool. The correct one is the following:

	$ mq "GROUMPH" 1 1

Using MQ, I can easily scan the complete object tree and retrieve the 2400
values of the DTDRDATA table. Here is an extract of the MQ.LOG file that I
have copied in the DECnet account of our cluster ANNECY:: (you can copy this
file by issuing a $ COPY ANNECY""::MQ.LOG ...)

Object ID: 1.3.6.1.4.1.131.2.5.1.2.4.1.2.1.
Value = 134

/* A lot of lines skipped.... */

Object ID: 1.3.6.1.4.1.131.2.5.1.2.4.1.2.2400.
Value = 255

Object ID: 1.3.6.1.4.1.131.2.5.1.2.1.1.0.
Value = 0

Object ID: 1.3.6.1.4.1.131.2.5.1.2.2.1.0.
Value = 3

/* etc, etc... your tool continues to scan the object tree, but my interest
 * being only for the DTDRDATA table, I have done a CTRL/Y...
 */

In my opinion this test shows that the SNMP agent in the POD is working
correctly. Does this mean that the problem comes from the standard MCC TCPIP AM
(wildcarding) ? 

When I enter through the FCL PM the command:

MCC> show snmp groumph sintromdatanet podmib dtdrdata * all char, to file g.log

I ONLY GET THE 999 FIRST VALUES OF THE DTDRDATA TABLE !

I have also copied the G.LOG file in the DECnet account of the ANNECY cluster
and you can therefore retrieve it if you want.

Do you want me to do some more tests ? What is your opinion about this behavior
?

I thank you in advance for your help,
Damien.

	Damien,
		Please bear with us for a few more days. We have your problem
	in mind and we'll get to it as soon as we can free up some time.

	Thanks for your patience,

	Rahul.