Conference azur::mcc

5679.0. "DECnis and FRBS channel counters" by MUNICH::FERSTL () Thu Oct 21 1993 13:44

Hi,

I have a customer who searches for a simple method to collect information 
about the workload of the FRBS channels of his DECnis 500 (V2.2.4).

He tried to show the FRBS channel counters in graph modus. But he has 
problems with it, because MCC doesn't display fields like "Frames Sent",
"Octets Sent", "Frames received"... for the counters.
Instead you can find fields "Attribute Code 40", "Attribute Code 41"...
as you see it below.

                                                                               
DECmcc (V1.3.0)                                                                
                                                                               
Node COMBA_NS:.ramsf1 FRBS Channel W622-4-0                                    
AT 21-OCT-1993 17:34:01 Counters                                               
                                                                               
Examination of attributes shows:                                               
                          Creation Time =  8-OCT-1993 12:25:55.75              
                 Last State Change Time =  8-OCT-1993 12:26:04.20              
                          Time of Error =  8-OCT-1993 12:25:55.75              
                         Up Transitions = 1                                    
Connection Management Protocol Up Transitions = 1                              
      Connection Management Frames Sent = 112407                               
      Connection Management Octets Sent = 1461291                              
  Connection Management Frames Received = 112407                               
  Connection Management Octets Received = 1611171                              
                         Service Errors = 0                                    
                             CRC Errors = 0                                    
                       Discarded Frames = 0                                    
                      Attribute Code 40 = 5381101                              
                      Attribute Code 41 = 592890097                            
                      Attribute Code 42 = 8338102                              
                      Attribute Code 43 = 1810945658                           
                      Attribute Code 50 = 7993624                              
                      Attribute Code 51 = 0                                    
                      Attribute Code 52 = 0                                    
                      Attribute Code 53 = 0                                    
                      Attribute Code 54 = 0                                    
                      Attribute Code 56 = 0                                    
                      Attribute Code 55 = 0                                    
                      Attribute Code 57 = 0                                    
                      Attribute Code 58 = 4575                                 
                      Attribute Code 59 = 0                                    
                      Attribute Code 60 = 0                                    
                      Attribute Code 61 = 0                                    
                      Attribute Code 62 = 0                                    
                                                                               

Is there an explanation? 
How can the customer collect information about the workload of his lines?
He says there's nowhere the possibility to do a "SHOW STATISTICS".
                                                                         
I'm not able to reproduce the problem in my office, because we haven't set
up our DECnis to use PPP and FRBS connections.

    
Thanks for any help

Birgit Ferstl / Digital Service Center Munich      

>Instead you can find fields "Attribute Code 40", "Attribute Code 41"...

A quick look into the dictionary under 'class node subclass frbs
subclass channel' showed me that the attributes in question are simply
not defined. Please escalate the problem through the proper channels. If
it's just a matter of defining the attributes it shouldn't be too hard
to fix. A sample of the NCL output would surely help the engineer to 
figure out which is which, without having to install a DECnis.

*Robert

When 1.3 went out, the dictionary was current.

The problem is that the management specifications for the DECnis
is an ever moving target.  The development engineers keep changing/adding
to the definitions for the various objects.  They have good reasons to, 
I'm sure.

The problem is that they check in their changes in their source code, and
some time later, they update the DSSR, but that does not get anything
that is anywhere near current for the dictionary in MCC.

Think of MCC as a "C" compiler.  You went out and bought an application
from a third party written in "C", and when there is a bug in the 
application code, you now expect the compiler developer to provide the patch.

Frameworks (MCC) is not going to be providing updates for the dictionary
for quite some time.  So, I guess you should get the MSL updates for the 
current rev of the DECnis from the engineering group that is building it.  
Then you might just have a chance of being current.

 

DECNIS is no different from any other EMA-managed entity.

> The problem is that they check in their changes in their source code, and
> some time later, they update the DSSR, but that does not get anything
> that is anywhere near current for the dictionary in MCC.

I would dispute the order :-).  Suffice it to say that the DSSR registration
requests are completed before the changed DECNIS code submits to the SSB.

> Frameworks (MCC) is not going to be providing updates for the dictionary
> for quite some time.  So, I guess you should get the MSL updates for the 
> current rev of the DECnis from the engineering group that is building it.  
> Then you might just have a chance of being current.

But we  don't  have  the  *MCC* MSLs! We do ship (and install) the necessary
*NCL*  dictionary  updates but we rely on MCC releasing fairly frequently to
get  updates  into  the  MCC dictionary.  That was the process agreed a long
time ago between me, Bob Lynch and Wally Matthews.

If there  has been a change in policy which means that MCC won't be shipping
dictionary updates "for quite some time" then you need to work with DSSR and
all  the people shipping products (including DECNIS) to make sure that there
is  a mechanism for them to ship dictionary updates on their kits (including
a  supported  mechanism  for  getting  those  updates  into  the  customer's
dictionary).    The   DECNIS   development   manager   is   Ken  Chamberlain
(MARVIN::KCHAMBERLAIN).

Graham

Well, that's what I suspected. Anyway, I escalated the problem against 
MCC and hope that it will eventually flow into the right channel. In the 
meantime - do you know a name in the DECnis group whom I could contact?

*Robert

For all DECNIS help/questions/support-problems contact IRNBRU::IPEG_SUPPORT.
That mail address is the focal point for Engineering issues for DECNIS.

Graham