PMP Mail Archive: Re: PMP> Discussion items for 4/22 Conference call

PMP Mail Archive: Re: PMP> Discussion items for 4/22 Conference call

Re: PMP> Discussion items for 4/22 Conference call

Matt King (
Tue, 22 Apr 1997 11:59:26 -0400

JK Martin wrote:
> Matt,
> [ ... ]
> Further in your text you consistently use this phrase:
> "...that results in a change to..."
> I sincerely hope that a *real* change must be effected within the
> SNMP agent in these circumstances. Right?

Yes, as real as configuration change is. Setting a configuration
variable is a config change even though no physical change was made.

> That is, the Lexmark printers we test have the characteristic of
> adding quite a few "prtInputMedia" alerts when a tray is pulled out,
> and then quite a few more when the tray is put back in...even when
> no change in any media-related attributes has occurred.

That is a "feature" that we will be removing. It makes no sense to add
an alert for something that the printer connot detect. If the admin
cares what color paper he put in the printer, he should modify SNMP
variable himself. The act of modifying the variable should cause
prtGeneralConfigChanges to be incremented, however.

Regardless, the new wording says that prtGeneralConfigChanges is only
incremented on config changes (a variable, such as prtInputMediaColor
must be modified). Even though lexmark added an alert to the alert
table, we did not change any attribute variables.

> Does your new wording then imply that if the SNMP agent can not detect
> any changes in such media-related attributes, that the agent should NOT
> increment prtGeneralConfigChanges?

No. It says that any attribute change (not necessarily media related)
that either physically or logically (via an SNMP set) occurs will
trigger an increment of prtGeneralConfigChanges.

> In even simpler words, just because the tray is pulled, the SNMP agent
> should not announce "Media Size/Weight/Form/Name" has Changed!" in the
> Alert Table. Ditto for when the tray is restored. Right?

I agree that pulling a tray or putting it back should not add an alert
(as Lexmark currently does), however, that is really unrelated to the

> As we discussed at the interop testing last February, this particular
> issue has been a serious sore point as we try to deal with the various
> implementations of the Printer MIB in some vendors' network printers.
> Hopefully we can all come to a clean and consistent resolution here.
> Again, very nice work, Matt.
> ...jay
> ----------------------------------------------------------------------
> -- JK Martin | Email: --
> -- Underscore, Inc. | Voice: (603) 889-7000 --
> -- 41C Sagamore Park Road | Fax: (603) 889-2699 --
> -- Hudson, NH 03051-4915 | Web: --
> ----------------------------------------------------------------------

Matt King                                     Opinions are my own and
Staff Engineer                                    are not necessarily
Lexmark International, Inc.                          those of Lexmark