Updated Definitions for the Job Monitor Project

Updated Definitions for the Job Monitor Project

Updated Definitions for the Job Monitor Project

rbergma at dpc.com rbergma at dpc.com
Tue Oct 1 21:38:28 EDT 1996


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



More information about the Pwg mailing list