Jay,
Keep those cards and letters comming!!! I hope this is generating
interest by others for this project!!!
> 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.
These same thoughts have also crossed my mind. I was trying to better
understand the way this would be implemented before I objected. I
certainly agree that the degree of complexity should be controlled.
>> >> 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? ;-)
I am not sure what value "prtAlertPositionInTable" would contribute.
There is some value in knowing how many jobs preceed the target job on
a given device. How do we present this info? If the job index is a
easier to process in a management station, then that would be the
parameter to maintain.
---------------------------------------------------------------------
Ron Bergman
Dataproducts Corp
rbergma at dpc.com