Conference azur::mcc

    I am not certain I understand the question, but it sounds like you want
    the counters to automatically zero when they hit a specific threshold.
    To do this in MCC you should create a rule, using the alarms FM, and
    specify an action command procedure that goes out and zeros the
    counters whenever the counter hits your threshold.
    
    create domain foo rule bar -
    	expression = (node4 bar counter > #),
    	action = sys$login:zero_node4_bar_counters.com
    
    
    (^yes it is an example, and not a real FCL enterable command)

    
    Jill -
    
    I guess what I am looking for is a controlled reset of the counters.
    When one sets up NMCC/DECnet and tell NMCC that you wish to record
    counter data for reports, the program will automatically zero the
    counters (using appropriate access control information which is
    stored in the database) in such a way that it will not miss any
    of the counter information.  The programs then will have a continuous
    set of data that it can normalize over the recording intervals.
    
    Let's say we use an uncontrolled method of reset the counters,
    and we are recording a circuit counter every 30 minutes.
    
    Example Scenario -
    
    Set up NCP to zero the counters automatically.  Now we get a reading
    from the counters at the beginning of a half hour stretch.  25 minutes
    later, the counters happen to be automatically zeroed.  So now we have
    a start count of x number of bytes or data blocks (lets say 20000
    bytes) and at the end of the half hour, we now have (after the zeroing
    has occured) a count of 150 bytes.  Now I want to produce a circuit
    traffic analysis of that half hour ( or for a couple hours surrounding
    that time interval).  For starters, we now have a negative number of
    bytes transferred, ie. -19850.  Even if MCC use the absolute value
    of the number, this does not reflect the true traffic and misses the
    (again a made up case) mass file transfer that occurred during the
    interval in question.  Does MCC know that the counters were zeroed?
    Does it know how many bytes (or whatever) were transmitted or received
    during those 25 minutes?  In other words, I don;t believe there is any
    way for MCC to produce a valid analysis of the circuit traffic during
    that period. 
    
    Admittedly, I can force a controlled situation by using rules or
    batch procedures, however it seems that the MCC phase IV module
    should have a self policing mechanism built in to insure the integrity
    of the data.  Note that using either batch or alarm rules still requires
    one to record the counters just before zeroing, or the data that
    is recording in the historian will at best be skewed, at worst be
    unusable.  Additionally, anyone monitoring a relatively large number
    of circuits will have a good sized chore on their hands.

    Since this is exactly what is being done at my customer site, I
    am interested in more feedback.  One of the things we would like
    to do here is get away from NMCC/DECnet due to a relatively poor
    track record with database corruption, etc.
    
    Regards,
    
    Dave Comfort

I see what you are asking for, and in simple terms, to me, it means
you want the performance analyzer to handle detecting the facts that
the counters have latched, zero the counters, and continue evaluation
of the statistics (making use of the knowledge that the counters where
zeroed and taking that into consideration in the statistics algorythm).

PA as it stands today doesn't do any such thing. I will pass this along
and see if we can get any feedback from the PA team on this item.

jill
(thanks -- good input)

    Imagine, if you would, two different people using MCC (or NCP) from
    different systems, and perhaps unaware of each other.
    
    One decides to zero the counters that the other was looking at.
    
    That's why EMA, Phase V and all new stuff does not use latching
    counters, but instead wrapping counters. It enables multiple managers
    to sample counters at different times and not get in each other's way
    
    Colin

    
    I understand the problem as stated in .-1, however such a flat
    statement does not provide an answer to the problem.  If we expand
    the concept to include recording terminal server counters, the problem
    is there also (bridges are exempt, at least for the moment).  I
    strongly believe that our customer base will be managing Phase IV
    systems for a number of years yet (Phase V conversions will happen
    slowly) and the issue needs to be addressed.  I will assume based
    on the previous reply, that the performance analyzer section that
    applies to Phase V will have the knowledge "built-in" to deal with
    the wrap point of the new counter scheme.
    
    regards,
    
    Dave Comfort
    

re .2

>> ..Does MCC know that the counters were zeroed? Does it know how
>> many bytes (or whatever) were transmitted or received during those
>> 25 minutes? In other words, I don;t believe there is any way for
>> MCC to produce a valid analysis of the circuit traffic during that
>> period.

In DECmcc, the "Counters zeroed" event provides the values of the
counters just before they were zeroed. So Management modules have
access to these values. With these values and the counter values 
from the point they were zeroed to the time they were polled again, 
you know exactly how many bytes (or blocks) were transferred during 
the interval. 
Version 1.1 of the Performance Analyzer does not handle the problem
of zeroed counters very well. 

    I would like to add my vote to get MCC to handle this situation.  I
    have always recommended to my customers to use counter timers on their
    lines and circuits so that counter information for troubleshooting
    purposes would have at least some timeframe reference.  Do I now have
    to go back to those folks that are looking at using MCC (or are already
    using it) and say "By the way, go remove all the counter timers from 
    all your lines and circuits on all your nodes so that your data
    collection stats from MCC don't have gltiches!" ???
    
    I do realize that this may not be a problem for huge numbers of
    customers but fixing this "issue" does fit with consistency of good
    network management practice - at least in my opinion.
    
    Regards,
    
    Richard