PMP Mail Archive: Re: Re[2]: PMP> Should Alerts be replicated???

PMP Mail Archive: Re: Re[2]: PMP> Should Alerts be replicated???

Re: Re[2]: PMP> Should Alerts be replicated???

Gail Songer (Gail.Songer@eng.efi.com)
Mon, 3 Feb 1997 10:40:07 -0800

Folks,

Lets take a look at a potential, hypothetical implementation. Lets say that my
printer has at most 200 things that can go wrong with it, inclunding everything
from toner low, to paper out for all the trays, to printer on fire. I need all
of the information for the 6 prtAlert variables, and I decide to organize this
information into a table in ROM space. Now to actually construct the alert
table I need a linked list with 3 elements, the index id, the index to my table
in the ROM space, and a next pointer. Lets say that these 3 elements take up 4
bytes apeice. So for my implementation I have used, at most, 2400 bytes of RAM,
which is around 2.5k. I can reduce this number further since I know that there
are some alerts that mutually exclusive with other alerts; for example I know
that a tray can be low on paper or out of paper, but never both. In my opinion,
this is well with the noise range for any printer that wants to include 1759
support, including low memory devices.

Gail

On Feb 1, 3:10pm, Bill Wagner wrote:
> Subject: Re[2]: PMP> Should Alerts be replicated???
> Jay,
>
> I believe that RFC1759 does allow binary alerts (obviously
> non-critical) to be removed for table maintenance. I think it is
> unreasonable to require that the alert table be large enough to
> contain the maximum number of binary alerts possible within the
> printer implementation. It is my understanding that the definitive
> status of the device is in the rest of the MIB, with the Alert Table
> merely operating as an assist.
>
> Bill Wagner, DPI
>
>
> ______________________________ Reply Separator
_________________________________
> Subject: Re: PMP> Should Alerts be replicated???
> Author: JK Martin <jkm@underscore.com> at Internet
> Date: 2/1/97 1:49 AM
>
>
> Chris,
>
> > I would like a volunteer to draft some language for this that
> > would cover all the critical and non-critical alerts.
>
> Ok, I'll bite... ;-)
>
> Once a binary alert is placed into the Alert able, it shall remain
> in the Alert Table until the condition for which it was created has
> been cleared.
>
> If a unary alert must be removed due to Alert Table space constraints,
> then it shall not be reentered into the Alert Table should space become
> available at a later time. At no time shall any type of alert be
> replicated in the Alert Table.
>
> This will require the agent to ensure that it can maintain an Alert
> Table large enough to contain the maximum number of binary alerts
> possible within the printer implementation.
>
> ...jay
>
> ----------------------------------------------------------------------
> -- JK Martin | Email: jkm@underscore.com --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03015-4915 | Web: http://www.underscore.com --
> ----------------------------------------------------------------------
>
>
>-- End of excerpt from Bill Wagner

-- 

Gail Songer Electronics For Imaging gail.songer@eng.efi.com 2855 Campus Drive (415) 286-7235 San Mateo, CA 94403