Updated Definitions for the Job Monitor Project

Updated Definitions for the Job Monitor Project

Updated Definitions for the Job Monitor Project

JK Martin jkm at underscore.com
Mon Sep 30 13:40:00 EDT 1996


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



More information about the Pwg mailing list