Ron,
Good responses to those last comments. Just a couple more for
consideration:
> >> 3. jobDeviceUsed (hrDeviceIndex) This object identifies the physical
> >> device or devices used to complete the job.
> >> *** FURTHER WORK IS REQUIRED TO DEFINE THIS OBJECT AND ***
> >> *** ITS RELATION TO THE REMAINING OBJECTS !!! ***
> >> *** SHOULD A SEPARATE PACKET BE RETURNED FOR EACH DEVICE OR ***
> >> *** TRY TO COMBINE ALL INTO ONE ??? ***
> >> *** HOW IS ALL THIS INFORMATION TO BE COMBINED ??? ***
>> > Not sure what you mean about having a "separate packet be returned for
> > each device". Can you explain a bit more on this?
>> This object is derived from the DPA set to account for multiple devices
> used to complete a job. If the job MIB is resident on each of these
> devices, then a supervisor must either get the separate information from
> each device and combine or return each as received from the individual
> devices. If a combined pack is returned, do we need to identify the
> relationship between the other objects and the devices?
It is precisely this kind of complexity that should make all of us pause
and ask the question:
"Just because SNMP exists, must we use it to solve all possible problems?"
If DPA requires this complexity--and also developed supporting protocols
for other parts of the DPA system--then perhaps this kind of facility is
best served using a specially defined DPA protocol. Refrain from using
SNMP for this kind of complexity.
> >> 13. jobPositionInQueue (Counter32) This object indicates the number of
> >> jobs preceeding this job in the print queue.
>> > This sounds like an implementation problem. If it is expected that the
> > agent maintains all jobs as entries in a job table, then isn't the job
> > index a better qualifier for this kind of information? If this object
> > remains as described above, then every time a job is removed from the
> > table (due to completion of processing), then ALL OTHER job entries will
> > have to have this object updated. This is not a typical situation in
> > MIB-land, is it? (Sounds like a real implementation pain, both for the
> > agent and the mgmt application.)
>> I am not sure that I fully understand this comment. If the value of the
> object is generated upon request there should not be a problem. We can
> discuss further.
Let me put it this way: How come we don't have an object in the Printer MIB
called "prtAlertPositionInTable" as part of the Alert Table Entry definition?
See what I mean now? (Or am I being too obtuse here? ;-)
...jay