Conference azur::mcc

    Hi Mike,
    
    I'm not sure how it works either, but I'll take a look at it.
               
    Bob

    re: .1
    thanks for the reply...
    Any news yet?
    I have to to go back to this site on wednesday...
    thanks,
    Mike

    This has nothing to do with the descrepancy mentioned. I am simply
    taking this opportunity to tell you to be sure to get your customer to
    update firmware.
    
    You will save your customer future headaches by doing this.
    
    Have Field Service update FCOs on LB200s for your customer.
    
    -dan

RE: DECmcc vs ELMS - CPT switch.

I found the following description in an old mail folder. The mail was dated
12-JUL-1991, in response to SPR ICA-33243. The information was verified
with bridge engineering.

Not sure what the current state of this problem is...

					Chris

P.S. CPT is a software switch (it's SETABLE from MCC).

----extracted text begins here---

+---------------+
| The Problem : |
+---------------+

The original problem statement was that:
  (1) DECmcc and DECelms returned opposite values for the CPT switch.
  (2) DECelms was returning it "right" (based on the Bridge's behavior).
  (3) DECmcc and DECelms preserved this inverse relationship during the
      SET command (CPT Switch is software settable).

What we found was that:
  (1) DECmcc and DECelms returned opposite values for the CPT Switch
      ONLY IF THE BRIDGE WAS A LAN Bridge 200. DECmcc and DECelms agree
      on the value of CPT Switch if the bridge is a LAN Bridge 100,
      LAN Bridge 150, or DECbridge 500.
  (2) DECmcc is consistently handling the RBMS packet returned by all
      Bridges, returning TRUE when the protocol indicates TRUE, and
      FALSE when the protocol indicates FALSE.
  (3) LAN Bridge 200 has inverted the value of CPT Switch in the protocol
      packet, and the DECelms software is "compensating" by changing the 
      value for the USER to match extectations. In other words, this is
      a LAN Bridge 200 firmware bug that is being hidden by DECelms.
  (4) Word from the Bridge firmware maintainers (LAN BU) is that this
      firmware bug will be fixed in the next rev of LB200 ROMs.

So the question becomes: WHAT DO WE DO ABOUT THIS:
  (1) Collision Presence Test (CPT) Switch being set incorrectly results
      in a counter incrementing on the bridge. I know of no other side
      effects. 
  (2) TELLING users (that are concerned) that CPT Switch is "backwards" on
      LAN Bridge 200s does not seem like a big deal. Certainly not one that
      would justify the amount of special case code needed to PATCH around
      this behavior.
  (3) We will look at adding code (hiding this LB200 behavior) for DECmcc
      Bridge AM V1.2. The code would have to check the Bridge Hardware Type
      and also the Firmware Version to know whether to complement the
      value on SET and SHOW. If we don't get a chance to do this, and
      the Firmware Maintainers update the ROMs, we may just Release Note
      it (text like: "attribute complemented for LB200 before version x.y
      of LB200 ROMs...").

    Thanks for posting that Chris.   I did a packet dump and verfified that
    the Bridge AM is indeed showing the value returned by the LB 200
    RBMS agent.   This is a firmware bug.
    
    I will mail this string to Ken Rauhala.  He maintains the LANbridge 200
    product.
               
    -Bob

    
    
    From:   LEVERS::SASE::RAUHALA "21-Apr-1993 1014"
    To:     LEVERS::QUIVER::HAROKOPUS
    CC:
    Subj:   RE: LANbridge 200 CPT switch problem
    
    it's fixed in the latest code V2.5
    
    (actually it was fixed way back in 1.6)
    
    ken

    re: last few...
    thanks for the info... that should make my customer happy!
    Mike