At 18:38 10/01/96 PDT, rbergma at dpc.com wrote:
>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.
The problem is what state would you put a job, if it was using more than
one device and one device needed attention and the other was doing fine?
That is why in ISO DPA we added the multiple-valued
printer-state-of-printers-assigned. Then we didn't have to answer this
hard question; the job remains in the processing or printing state.
In a MIB, we simply put the device-state-of-devices-assigned in a
table, so that it can contain more than one row for those implementatations
that can have a job on more than one device. Most can't so their SNMP
agent implements a simple one-row table at NO EXTRA COST, except a single
extra byte in the OID for the object. Seems like a win-win situation
to me. It also uses a tried-and-true solution from ISO DPA that has had
lots of debate.
>>>>> >> 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.
NMS applications don't want the SNMP agent re-arranging the table just
because a new higher priority job arrived. Each job arrival should
be put into the table at the end, just like alerts are required to be
entered into the table. Then another object in the table indicates
the order. Or we could have a whole new table that just contains the
indices of the jobs. That table would be re-ordered as jobs arrive
and/or job priority changes as the jobs wait, but the main jobs table
remains fixed and growing at the end.
Comments?
Tom
>>---------------------------------------------------------------------
> Ron Bergman
> Dataproducts Corp
>rbergma at dpc.com>>>