Conference azur::mcc

Bipin,

Regarding the second problem: fibre port characteristics coming back with 
the error 

   management window: unexpected information was returned in out_p:code 8

this error means that the attributes returned in outp included an attribute
with the code of 8, and that, from examining the dictionary and determining
the variant of this particular optical fibre port, that attribute should not
have been returned.  This error usually means that the Management Specification
for the entity class has not been set up quite correctly. 

The reason that this error is not seen using the FCL is that FCL simply decodes
outp and displays the results.  The Iconic Map checks if there are variants for
the particular entity class in the v,e,p and if so, sets up a form with the
correct attributes included according to the variant information.  Then it
decodes outp.  If values for attributes which should be returned according
to the variant information are NOT returned, the form displays --NOT RETURNED--
in the text widget.  If additionaly information is returned, the error message
you described is displayed with the name of the code returned.

Hope this helps.
Verna

Verna,

Thanks for the speedy reply. Does that imply, that the fibre port is returning
an attribute that MCC doesn't know about, ie fcl decodes everything and would
just declare that the attribute is unavailable for that entity class. Whereas,
because the iconic map does some pre-processing it fails to display any 
information (or am i barking up the wrong tree).

Looking in the dictionary, and going all the way down to attribute_list code 63
exists for the counters. However, does that only apply for the ethernet port of
the bridge and not the fibre port. If this is true then the iconic map may not
return any information.

Any ideas as to how i can track this down, and does it look like a bug in the
iconic map.

Bipin.

All ideas welcome.

p.s any thoughts about the hanging iconic help - could it be corrupt help files.
The customer has already rebuilt the help libraries once.

Bipin,

You should check in the dictionary to find out what attribute with code of 8 is,
and then check the entity being operated on to see what its variant information
describes as far as attributes to be returned, and go from there.  

FCL simply decodes what is in outp so it simply decodes the attribute with code 
8 just like any other attribute.

Could you describe further your problem about hanging iconic help - do you
ever get help, do you get any errors displayed, etc.

Verna

Verna,

Once in the dictionary the class used is bridge and the subclass used is line.
Now, do i look at the attributes below bridge which would make code 8 
updateswitch (and code 63 deviceframelost) or do i go further down to subclass
line. Sorry for being so vague but it is the first time i'm having to look at
the dictionary in earnest.

Regarding the help problem, as soon as he clicks on the iconic map help it
hangs and takes 95% of the cpu. There are no error messages the process just
sits there.

Bipin

From current (Bridge AM V1.3) MS file:

Line Characteristic code 8 = Collision Presence Test Switch
   DEPENDS ON = "Datalink Type IN SET (
	Ethernet CSMA/CD, IEEE802.3 CSMA/CD)".

Line Counter code 63       = Collision Presence Test Failed
   DEPENDS ON = "Datalink Type IN SET (
	Ethernet CSMA/CD, IEEE802.3 CSMA/CD)"

Why an fiber port would be returning CPT information is a mystery
to me...

I'll pass this on to the ELM guys.

						Chris

Verna,

Using the dictionary the attribute it should be returning :

DAP> show class bridge subclass line <cr>

attribute 8 is COLLISIONPRESENCETESTSWITCH and 
attribute 63 is COLLISIONPRESENCETESTFAILED.

This is correct, now these are returned for the ethernet device and not the
fibre. Are there differences in the way these behave.

Bipin.

p.s. If my understanding is correct, both ports should behave identically.

Any ideas.

re .5

I wrote 6 before reading 5, does this look like a bug then.

Bipin.

Since the LAN Bridge 100's Agent is apparently returning these, the
DEPENDS ON clause (for the CPT related attributes) should probably be
corrected.

The fix for DECmcc ELM V1.0 (Bridge AM V1.2) would be to modify the
mcc_bridge_am_svc_if.com file (or the dictionary directly, using DAP)
to mark the two attributes of interest as PREDICTABLE = FALSE.

Maybe the ELM people will generate a patch for this (hint, hint).

						Chris

P.S. This problem didn't exist in Bridge AM V1.1
     since the DEPENDS ON for that version was
     based on Bridge Type (not Datalink Type).
     It'll definitely be fixed for Bridge AM
     that layers on DECmcc V1.2 (and is part of
     the next DECmcc ELM AM kit)..
     

    Bipin,
    
    It is a bug in our Management Specification file.  Unfortunately we had
    no chance to test it on DEBET fiber medium.  The attributes of a line
    in a bridge are very complicated since we add DECbridge 5xx and 6xx.
    The line 1 of the DECbridge 5xx and 6xx is a FDDI line.  However, the
    line 1 of the rest of the LAN bridges are Ethernet line.  That makes
    our life difficult to write Management Specification file.
    
    Anyway, we will start EFT of the DECmcc ELM V1.1 in next couple of
    weeks and the Bridge AM in this kit will have this bug fix. 
    
    Jae

.1> If additionaly information is returned, the error message
.1> you described is displayed with the name of the code returned.

You *are*  going  to fix this for V1.2, aren't you? We have had the argument
before that this is unacceptable behaviour and I thought it was agreed.  The
DEPENDS  ON  clause  is  only  a hint -- only the entity itself *knows* what
attributes it currently has (did someone say "management knowledge"?!).

Graham