Conference azur::mcc

178.0. "BRIDGE "SPANNING CHARACTERISTICS" display problem" by BEAGLE::LORPHELIN (Chr Lorphelin TSCG/VBO) Tue Jul 10 1990 09:16

    "SHOW BRIDGE * LINE * ALL SPANNING CHARACTERISTIC" does not seem to 
    give awaited results:
    1/ it displays first spanning characteristics of line 1 for
       all bridges.
    2/ it displays spanning characteristics of line 2 
       of the FIRST bridge { 1rst in alphabetical order }.
    3/ it does not display spanning char of line 2 of 
       the other bridges.
    4/ it does not display spanning char of lines 3,4,..,8 of 
       VITALINK bridges.
     I tried MANY TIMES with same results.
    
    BUT "SHOW BRIDGE x LINE * ALL SPANNING CHARACTERISTIC"
    DISPLAYS SPANN CHAR for each line of bridge x, even for
    a VITALINK bridge.
    
    Follows an extract of display of 
    "SHOW BRIDGE * LINE * ALL SPANNING CHARACTERISTIC" command :
    
BRIDGE NESEVO_NS:.ALGO_1_2 LINE 1 
BRIDGE NESEVO_NS:.ALGO_1_3 LINE 1 
BRIDGE NESEVO_NS:.ALGO_3_2 LINE 1 
BRIDGE NESEVO_NS:.ALGO_4_3 LINE 1 
BRIDGE NESEVO_NS:.BACK_TRANSETC2 LINE 1 
BRIDGE NESEVO_NS:.comms LINE 1 
BRIDGE NESEVO_NS:.COMP_ROOM_ETC1 LINE 1 
BRIDGE NESEVO_NS:.ETC2_ETC1 LINE 1 
BRIDGE NESEVO_NS:.GRNDFLOOR_ETC1 LINE 1 
BRIDGE NESEVO_NS:.IDLE_A3 LINE 1 
BRIDGE NESEVO_NS:.ISCOMP_ETC2 LINE 1 
BRIDGE NESEVO_NS:.LAVC_ADG LINE 1 
BRIDGE NESEVO_NS:.LAVC_CASEE LINE 1 
BRIDGE NESEVO_NS:.LAVC_ETTS LINE 1 
BRIDGE NESEVO_NS:.LAVC_IED LINE 1 
BRIDGE NESEVO_NS:.LAVC_KESU LINE 1 
BRIDGE NESEVO_NS:.LAVC_PCI LINE 1 
BRIDGE NESEVO_NS:.LAVC_TIMA LINE 1 
BRIDGE NESEVO_NS:.LB200 LINE 1 
BRIDGE NESEVO_NS:.MFG1_A LINE 1 
BRIDGE NESEVO_NS:.MFG2_A LINE 1 
BRIDGE NESEVO_NS:.NETWLAB_ETC2 LINE 1 
BRIDGE NESEVO_NS:.PROD2_BENCH LINE 1 
BRIDGE NESEVO_NS:.RDC_AFSG LINE 1 
BRIDGE NESEVO_NS:.SER1A7_ETC2 LINE 1 
BRIDGE NESEVO_NS:.SER2A1_ETC2 LINE 1 
BRIDGE NESEVO_NS:.SER2A7_ETC2 LINE 1 
BRIDGE NESEVO_NS:.SER3A2_ETC2 LINE 1 
BRIDGE NESEVO_NS:.SER3A6_ETC2 LINE 1 
BRIDGE NESEVO_NS:.SER3A8_ETC2 LINE 1 
BRIDGE NESEVO_NS:.SERBENCHMARK LINE 1 
BRIDGE NESEVO_NS:.SERDEPARTE_ETC2 LINE 1 
BRIDGE NESEVO_NS:.TIMA32 LINE 1 
BRIDGE NESEVO_NS:.TIMA42 LINE 1 
BRIDGE NESEVO_NS:.TRANS1_PROD1 LINE 1 
BRIDGE NESEVO_NS:.TRANS1_TRANS2 LINE 1 
BRIDGE NESEVO_NS:.TRANS2_PROD2 LINE 1 
BRIDGE NESEVO_NS:.TRANS2_TRANS1 LINE 1 
BRIDGE NESEVO_NS:.VCS_ALGO LINE 1 
BRIDGE NESEVO_NS:.VCS_ETC1 LINE 1 
BRIDGE NESEVO_NS:.VCS_ETC2 LINE 1 
BRIDGE NESEVO_NS:.VIT_ALGO LINE 1 
BRIDGE NESEVO_NS:.VIT_ETC LINE 1 
BRIDGE NESEVO_NS:.VIT_MANUF LINE 1 
BRIDGE NESEVO_NS:.ALGO_1_2 LINE 2 
    
    Another issue :
    - it seems command intends to display spanning characteristics of
      all lines 1 for all bridges. Then all lines 2 for all bridges ,etc...
    - Couldn't we expect : display of spanning characteristics 
      for all lines of first bridge, spanning characteristics for all
      lines of 2nd bridge , etc...
    - This way it will be more compatible with RBMS or ELMS displays
      with which customers are more used.

    I forgot to precise I was using T1.0.1.
    
    I got same type of results with :
    "show bridge * line * all status"
    "show bridge * line * all characteristics"
    "show bridge * line * all counter"
    
    One "code correction" will fix probably all of these bugs.

    
    We had entered this item into the NACQAR system. It is located in the
    MCC_DEV data base QAR number 1031. The error, on initial quick review
    seems to be located in the FCL PM. It occurs for any entity class
    used, not just bridge.
    
    Thanks for your help
    

	QAR 1031 mentions handle processing errors.  Here's some more info.

	The command "$MCC> show snmp * interface * all char" yields:

	1.	AES lvl 1 = first SNMP entity in DNS
		AES lvl 2 = full instance wildcard

		the am sets the handle, and returns in Out_Entity lvl 2 the
		identifier of the first interface (in this case =  1)

	2.	AES lvl 1 = next SNMP entity in DNS
		AES lvl 2 = value = 1

	3.	AES lvl 1 = next SNMP entity in DNS
		AES lvl 2 = value 1

	...

	n.	AES lvl 1 = first SNMP entity in DNS
		    lvl 2 = full instance wildcard, but the value = 1

	It's clearly wrong to copy Out_Entity from the first response as
	In_Entity for the other requests.  They must all be wildcarded and
	handled separately (perhaps non-dynamic, registered subentities are
	an exception, but snmp interface is dynamic).

	Is it OK for an AES level indicate full instance wildcarding, but
	have a descriptor that fully specifies an instance?

	Mike

    Thanks Mike, this is what I was working on this morning. I am writing
    up my change proposal now. In the end it comes down to how we are
    doing the global expansion and NOT the handle. My first guess was
    incorrect. The handle was suspect because it was recently changed,
    I have a feeling this problem has been around a while though.