Subject: PMP> Alert Alert

From: Harry Lewis <[email-masked]>
Date: Fri, 18 Apr 1997 13:15:56 -0400

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

In reading the definition of alertRemovalofBinaryChangeEntry, there doesn't
seem to be any information about WHICH alert was cleared. Is this intentional?
Is it obvious that the associated sub-unit should be 18 (Alert Group) and
sub-unit index should be the index of the alert that was removed?

Harry Lewis

---

From: JK Martin <[email-masked]>
Date: Fri, 18 Apr 1997 14:12:54 -0400 (EDT)

> sub-unit index should be the index of the alert that was removed?

In reviewing my copy of the draft (version 01) to get back up to speed
on alertRemovalofBinaryChangeEntry, I became even more confused.

Somehow it escaped me that we are now proposing to add yet another alert
to the table...and this this alert is designed to denote that an alert
has been removed!

Can someone quickly state why this is needed (or point me to a relevant
discussion or other posting)?  Having such an alert doesn't seem to
gain anything.  I fully understand the desire to have a related trap
for this kind of event, but do we really need an "Alert Alert"?

What I *do* recall is that we were going to add two new objects to the
MIB that functioned in a relatively indentical manner--both syntactically
and semantically--as the prtGeneralConfigChanges object.  One of the
new objects (prtGeneralAllEvents) would count all changes made to the
alert table, while the other (prtGeneralCriticalEvents) would only
count those changes made for critical alerts.

The philosophy was, as I recall, centered around the idiom whereby a mgmt
app would only have to watch for changes in one of these new objects in
order to know whether the app has to process the alert table.

Did I miss something along the way?  Can someone shed some light on this?
Perhaps a comment can be made by someone who is actually developing code
that uses this new objects.  I realize my memory must be failing me on
this, but I'd really appreciate some comments from someone on this topic.

I realize the draft claims that this new "alertRemovalOfBinaryChangeEntry"
alert is optional, but still--who is going to use it, and how, and why?
Could it be that the presence of this alert would result in an app not
having to parse the entire alert table in order to fully maintain its
internal working copy?

That seems conceivable, however, since this new alert is OPTIONAL, our
products certainly wouldn't use it.  Our customers expect our products
to work with ANY "RFC 1759" printer; the overhead and complexity of
having two algorithms just doesn't pan out, so we always opt for the
algorithm that is bullet-proof and works across the board.

By the way, the draft section "2.2.13.4  Alert Table Management" continues
to interchange the use of "simple" and "unary".  (Hadn't we resolved that
problem once and for all already?)  In that section, the term "simple" is
used a total of 5 times to denote a "unary" event type.  Randy, can you
make these changes, or would you prefer that I send you corrected text?

	...jay

----------------------------------------------------------------------
--  JK Martin               |  Email:   [email-masked]          --
--  Underscore, Inc.        |  Voice:   (603) 889-7000              --
--  41C Sagamore Park Road  |  Fax:     (603) 889-2699              --
--  Hudson, NH 03051-4915   |  Web:     http://www.underscore.com   --
----------------------------------------------------------------------

---

From: Harry Lewis <[email-masked]>
Date: Fri, 18 Apr 1997 17:13:51 -0400

Classification:
Prologue:

Wow, Jay, you don't ask for much... ;-).

>for this kind of event, but do we really need an "Alert Alert"?

Once upon a time...

If you'll recall back in the early MIF/MIB days, I had requested that both
START and END (or leading and trailing if you will) time (ticks) be associated
with EVERY alert ("unary" alerts would have equal start/stop times). There
was opposition - largely because my proposal came at a time when we had nearly
"locked" the printer MIB. Compromise resulted in the current (optional)
prtAlertTime.

Later... the desire to distinguish the temporal aspect of alerts took hold with
more PWG members. Several proposals were "batted" around, including
re-introduction of my Start/Stop tick idea. I think the main flaw in my
proposal was that that RFC1759 REQUIRES a trailing binary be removed, so how
can you "poll" to find out the end time. (I could be glossing over some other
condition of my or other proposals which made them undesirable).

Anyway... we agreed, en-mass, that we wanted to know WHEN the trap had been
removed and we needed a somewhat persistent entry to carry that information.
Enter the Alert Alert... a UNARY event that would indicate the END tick of a
vanishing binary (sounds almost astronomical!).

By the way... having gone through the recall on this... it might answer an
earlier question... "what made prtAlertTime go from optional to mandatory".
I do believe, it was just about at this point that we realized, if AlertAlert
was to be useful, prtAlertTime would have to become mandatory and there were
few (if any) objections.

>order to know whether the app has to process the alert table.

Yup.. all that too. But none of this addresses WHEN DID the alert EXPIRE.

>having to parse the entire alert table in order to fully maintain its

This is kinda why I asked the question about the "contents" of the AlertAlert.
Unless it points to a specific alert that was removed, what good is it?

Will we use it? I think so. But I think there are a few ramifications that
should be understood like:

 1. The use of AlertAlert will result in alert tables that "run full" rather
    than "empty" as I suspect is the case today. By this I mean there aren't
    many unary's around today and binarys come and go (by definition) so, if
    there's any "size" to the alert table it will tend to run sparse. But, if
    there is a Unary for every trailing binary, the table will tend to "fill up"
    with AlertAlert's. I don't know that it matters... it's just an
observation.

 2. Unary AlertAlerts should probably be the first to go among Unary's
    if and when room is needed in the table. They're most likely to be
    hanging in long after the information they represent is meaningful.

>algorithm that is bullet-proof and works across the board.

I hear ya. You're no different than any software in that sense (ooh... was that
a fopa ;-). But, remember, if AlertAlert's are supported, you can find out
about the end time if not, you basically can't. I think that's a bit different
than you code has to determine something one way for 90% and another for 10%.
Right? I don't really have a problem with making it mandatory, however.

Harry Lewis

---

From: JK Martin <[email-masked]>
Date: Fri, 18 Apr 1997 17:42:13 -0400 (EDT)

Harry,

Ah, now it's all coming back to me...  8-}

Ok, so the AlertAlert gives one the ability to have a timestamp
on exactly when the alert condition goes away.  (Assuming that
the AlertAlert is implemented, and assuming it is not removed
from the printer due to Alert Table space limitations.)

And you're right.  This will worsen the space management issues for
the Alert Tables.

I certainly hope more than one vendor implements this concept in
their products...and this implies both the client and the server
sides.  Should be interesting to watch in the future.

Thanks for the fine historical details, Harry.

	...jay