Subject: Re: PMP> Alert table thoughts

From: [email-masked] (Bill Wagner)
Date: Tue, 1 Apr 1997 15:58:36 -0500

Matt brings up some good points. Since a Spring storm has closed the 
     airport here, I offer some comments on the wire.

When it was coverOpen(3) (Open, adj. describing state of cover), it made 
sense to put one alert in the alert table when it opened and remove it 
when it closed.  I never did understand why there was a coverClosed(4).
     
With coverOpened(3) (Opened, verb describing the leading edge action) it 
is implied that it will be followed by a coverClosed(4).
     
If this is the case is coverOpen(ed) a binary alert and coverClosed a 
unary one?  Is this waht we want?
     English is an imprecise language, and we cannot rely unpon subtileties 
     to define what we mean. 'Open' can also be a verb; and 'opened' can be 
     a gerundive (adjective derived from the past participle, as in an 
     opened can of worms). If we want binary and unary events to be 
     implemented consistently, we must explicitly state how each event is 
     to be treated. My own feeling is that an open cover  reflects a state 
     of the printer that should be handled as a binary consiiton. Cover 
     closed might be a optional unary event, but seems superfluous. But, if 
     we do  indeed need consistency (I am ambivalent on this), how the MIB 
     defines events is less important than that it defines them. 
     
2) In the internet-draft, the section that talks about the alert table 
has a paragraph that talks about unary alerts (included for reference). 
The paragraph gives an example of a unary alert then goes on to talk 
about not knowing when to remove unary alerts from the table.  The 
clarification I am adding talks about multiple unary alerts of the same 
type on the same subunit replacing each other.  This makes the example 
not demonstrate waht it was intended to do.  What do you guys think?
     
   I find the paragraph in the draft useful, if a bit chatty. I 
   am unsure about what is being clarified.
     
3) The title of section 2.2.13.3 is "Alert Tables".  The title of 
section 2.2.13.4 is "Alert Table Management".  Both sections talk about 
a single table.  Any idea why the plurality?
     I do not think there was any specific significance intended in Alert  
     Tables rather than Alert Table. If people find the plurality 
     confusing, it  should be changed to Alert Table.

     Bill Wagner

---

From: Matt King <[email-masked]>
Date: Wed, 02 Apr 1997 16:55:31 -0500

Bill, Jay, Harry:

It sounds like I did an ok job making my point on all questions except
for #2, where I apparently really blew it.  Let me take another hitch at
#2.

[Verbosity On]

I was asked to clarify (write up) a formal rule for removal of unary
alerts when redundant unary alerts are added to the alert table.  The
difference between this and what is currently in the internet-draft is
that this would be done even when the table is not full.  Below is a
draft of the clarification I will be proposing.  It would be added just
below the 4th paragraph of section 2.2.13.4, Alert Table Management.

    "Note that there should never be redundant unary alerts in 
    the alert table, where redundant is defined as two or more 
    alerts having the same prtAlertGroup, prtAlertGroupIndex, 
    prtAlertLocation, and prtAlertCode.  If a second unary change 
    event of the same type occurs on the same subunit and 
    location, as an existing alert, the existing alert should 
    be removed from the alert table and the new one added. For 
    example if a media size change occurs on input subunit 1, 
    then some time later a second media size change occurs on 
    the same subunit, the origional alert would be removed and 
    a new one added.  However, if the second media size change 
    occured on input subunit 2, both entries would appear in 
    the table unless the first had to be managed out due to 
    space constraints."

The only point I was trying to make was that the 4th paragraph of
section 2.2.13.4, seems to be trying to make the point that the problem
with unary alerts is that they will continue to be added to the alert
table until it is full at which point they will be managed out to make
room for new alerts.  It gives the following example:

    "[An] operator may change the paper that is in the
    primary input source from letter to legal. At some time
    in the future the paper may be changed back to letter, but
    it might be changed to executive instead."

It then goes on to explain:

    "This is where the problem occurs. It is not obvious how 
    long to keep simple change event entries in the Alert 
    Table. If they were never removed, the Alert Table would
    continue to grow indefinitely."

Applying my clarification for removal of redundant unary alerts would
cause the current example to leave only one entry in the alert table. 
Once again, It seemed to me that the point they were trying to make was
that if the example progressed, the table would eventually become full
of media change alerts.  That is why I felt "[this] makes the example
not demonstrate waht [sic] it was intended to do."

The question then is, once you apply the new rule, what is a good
example of what would fill up the alert table?

By the way, I don't think I just pulled this proposed clarification/rule
out of my ..., well ya'know.  I think this is what we came up with
during one of our discussions at the interop testing.  Do others recall
this?

[Verbosity Off]

--Matt

Bill Wagner wrote:
> [Text deleted]
> [Text Deleted]

-- 
Matt King                                     Opinions are my own and
Staff Engineer                                    are not necessarily
Lexmark International, Inc.                          those of Lexmark
[email-masked]