I want to thank Jay Martin, Gail Songer, and Scott Isaacson for the
comments on my latest posting for the Job Monitor Project. We may
get more done outside of the meeting than will be accomplished in
NYC!!!!
Jay wrote in response to my proposed JMP agenda:
> Before making a couple of comments, I should mention that perhaps I am
> not quite up to speed on the latest draft for the MIB objects. Do you
> think you could post a pointer to the path of the file (on the ftp
> server) that contains the latest draft?
My draft was posted via email on 26-SEPT titled "Updated Definitions
for the Job Monitor MIB". The original document from Tom Hastings
was distributed at the July meeting (Portland) and should be on the
pwg-ftp site as jmp-spec.doc & .ps. (I am not able to verify this
since I can only access the ftp server from my home.)
> Some comments about your posting:
>> I propose that jobCopiesRequested" be change to
>> "jobCopiesCompleted" and moved into the accounting group. The
>> remaining items should be removed.
> Could it be that both kinds of objects are desirable? (Yeah, this
> coming from the person who says "No more than 20 objects!!"...)
> If we support both, then would we have reasonable measure of relative
> completion for the job? (Or is "job progress" better denoted from
> other proposed objects?)
My original thought was the user knows how many copies he requested
and only needs to know how many have been completed. But on second
thought, some users (myself included) have a short memory and also
someone other than the person who submitted the job may find this
a useful parameter. Sounds like a keeper. GOOD POINT!!!
>> 4. What value does "jobName" add to the identification group? Is
>> this value sufficient to warrant the inclusion of this object?
>> I propose that this object be removed.
> Just as in our recent discussions about the need for an "administrative
> name" for a printer (in the Printer MIB), it would seem both natural and
> useful to have an equivalent object for a job. Anyone else out there
> have a similar feeling? (Or counter-feeling?)
We presently have (using the names from my email) jobName and also
jobDocument, which is the name of the document. The proposal was
jobName would be unique and jobDocument would not, for the case where
the same file was submitted multiple times. My real question is:
Can this be supported by current job submission protocols and is it
of any value? The time stamp can be used to determine the order the
jobs were submitted and does provide some uniqueness. (I just do not
want to include too many objects that will never be used.)
>> 5. Are items #2 and #3 in the identification group needed? These
>> objects appear to provide only routing information. I do not
>> feel that routing information adds any value for job monitoring.
>> These objects do not add any significant information required
>> for job identification.
> Quite frankly, tackling the problem of "job routing" is pretty scary
> to me. My biggest fear along this line is that in order to maintain
> integrity of the MIB data for a job, several (relatively) independent
> processes--quite likely on different network hosts--will have to update
> certain job values at certain times. This could be a real killer, both
> in terms of implementation and access control.
> Anyone else share these feelings?
I believe it is obvious that I do!!! Any thirds?
> One last comment, of a general nature. Could it be that in order to
> satisfy DPA-related capabilities, we should define TWO Job MIBs, one
> for "basic" needs, and a second version that augments the "basic"
> version?
This is a good suggestion!!! I encourage Tom Hastings to comment!
Jay also wrote in response to my updated definitions:
> Some comments and questions on the object definitions:
>> 2. jobIdOnPktSrc: (String, max TBD) This object specifies .....
> What is the significance of the "Pkt" portion of the name? That is,
> what does it stand for? (Packet?)
I believe that it was to mean "Packet". To be honest, I did not put
a great deal of though into this name. Note that this is one of the
objects that I would like to remove. If we decide to keep, it
deserves a more descriptive name.
>> 4. jobIdOnDevice: (String, max TBD) This object identifies the job on
>> the device which is currently processing the job. The processing device
>> includes, but is not limited to, printers, faxes, scanners, spoolers,
>> and files servers. The value of this object may change for systems that
>> include intermediate devices such as file servers and spoolers.
> The last sentence in this paragraph is pretty scary IMHO. When it says
> "The value of this object may change...", what does this mean exactly?
> Does it mean the format will (may?) be different depending on the types
> of intermediate systems? Or does it mean the value (and possibly the format)
> may change during the life of the Job?
My intention here was to allow one object to be specified regardless of
the device that currently has the job. For example, in the model that
contains an external spooler; When the job is in the spooler waiting
for the printer, the spooler would provide its internal job identifier.
When the job is passed to the printer, the job id would change to that
of the printer. (A means of determining which device is currently
reporting may also be required. I originally thought that one of the
other proposed objects would provide this. But now that I look again,
a new object may have to be included.)
This object should not be required to identify the job. The combination
of jobIdOnClient and jobOwner must uniquely identify the job. This
object would allow identification of this job if another method of
interrogating the device was to be used. I don't feel that this object
is critical for this MIB.)
>> 5. jobType: (enum) This object specifies the type of service requested
>> to process the job.
> Can we get some examples here? Sounds like an interesting object, but only
> if a *single* parameter can reasonably denote the service required.
You reminded me that this issue was discussed in Portland. The agree-
ment was to make this a bit-mapped word. This would allow a job to be
print, fax, etc. (I should have read the minutes!)
>> 6. jobOwner: (String, max TBD) This object identifies the client that
>> submitted the job. The method of assigning this name will be system
>> and/or site specific but the method must insure that the name is unique
>> to the network visible to the client and target device.
> Warning, Will Robinson!! Ensuring network-wide uniqueness is virtually
> impossible without some stated rules. For example, this value could be
> relatively arbitrary, but MUST have (as a prefix, or suffix, or whatever)
> a valid, fully-qualified hostname, or something like that.
I agree 100%. This will be added to my action item list. (Assigned to
Will Robinson!!!)
>> 7. jobChannel: (enum) This object defines an equivalent to the print
>> job delivery channel as defined in the Printer MIB.
>May god forgive us all. ;-)
If jobMagicCookie works, this may not be needed!!!
>> 8. jobMagicCookie: (??) This object defines the protocol path from the
>> physical layer to the jobChannel. The format of this object will be
>> similar to the work in process for the Printer MIB.
> The use of the term "protocol path" to describe this kind of "wartly"
> object is interesting. Is this a reasonable term? Does it really express
> the concept? (Whatever that may be.) Note that the corresponding object
> in the Printer MIB does not attempt to define such a concept as "protocol
> path" Perhaps it should?
It seems to me that a "protocol path" is what we would like to define.
>> 10. jobDocument: (String, max TBD) This object defines a name for the
>> job. The name is typically expected to be the file or file/path name of
>> the source of the job. The name does not need to be globally unique.
>> (The name would typically be repeated if several jobs from the same file
>> are simultaneously in the job queue.)
> How is this different than "jobName"???
My point exactly. (See comments on jobName)
>> 13. jobDeviceName: (String, max TBD) This object specifies the
>> administratively defined name of the target device.
> I would strongly suggest that the value for this object be the same as
> the new "administrative name" object in the Printer MIB, iff the target
> device is Printer MIB-compliant, etc.
Although I did not explicitly state, this is my intention.
>> JOB PARAMETERS:
>>>> *** THE VALUE OF THESE PARAMETERS HAS BEEN QUESTIONED, ***
>> *** SINCE THIS IS NOT A JOB SUBMISSION PROTOCOL ***
>> *** PROPOSE THAT ONLY THE ITEMS THAT INDICATE STATUS OR ***
>> *** PROVIDE ACCOUNTING INFORMATION BE RETAINED !!! ***
> You're right, Ron. Drawing the line between "monitoring" and "submission"
> can be quite difficult. Perhaps these objects can be deferred to the very
> end of the project; that way if a project gets started for a standard
> network printing protocol, these two efforts can be combined to create
> commonly defined objects, etc.
Good point!!!
>> STATUS AND ACCOUNTING PARAMETERS:
>>>> 1. jobState (enum ?) This object defines the current state of the job.
>> (e.g. queued, printing, completed, etc.)
> Seems like a good object, but we won't know until someone posts a proposed
> list of states. Only then will we be able to know how applications will be
> able to use this object (if at all).
I do believe that this will be a difficult part of the project. But this
will be a very important parameter to have available.
>> 2. jobStateReason (bit map) This object provides additional information
>> regarding the the jobState.
> A bit map?? That would make it a finite set, right? If so, then someone
> should post some example values.
I expected this would require more work. A text string may also be
appropriate here.
>> 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?
>> 4. jobOctetsCompleted (Counter64) This object defines the number of
>> octetes currently processed by the device. For multiple copies
>> generated from a single data stream, the value shall be incremented as
>> if each copy was printed from a new data stream without resetting the
>> count between copies.
> What is the rationale for handling copies in this manner? Doesn't it
> seem useful to know how many data bytes actually flew across the network
> as part of the job? Yeah, you could use a "copies completed" object to
> derive the actual bytes transferred, but really, what value is having
> a total byte count calculated in the manner described above? Perhaps
> a real world application scenario description would help here?
Again, this is from the DPA set. I agree with your comment and propose
that this be changed to jobOctetsReceived.
>> 11. jobWarningCount (Counter32) This object contains a count of the
>> number of warning events that occurred during the processing of the job.
> Without being able to know what kinds of warnings occurred, what is the
> value of this object? That is, what are the semantics of the job entry
> if this value is non-zero? (That is, what can/should an application do
> if this value is non-zero?)
This object only provides an indication of a problem. Do we need to
include further details? Anyone care to comment?
>> 12. jobErrorCount (Counter32) This object contains a count of the
>> number of error events that occurred during the processing of the job.
> Same comments as #11.
Ditto!
>> 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.
>> 19. pdlUsed (enum) This object defines the PDL(s) used by the job.
> It would seem imperative to reconcile this object to the equivalent
> Printer MIB object, no?
Yes.
> All in all, things are coming along. This is good. However, we still
> seem to be floundering with respect to having solid, proven rationale
> for many of these objects. (What problem are we trying to solve? And
> how does this object solve that problem?)
> This may seem like a bit of a strange proposal, but do you think it would
> be useful to assign a "sponsor" for each of the proposed objects; that is,
> have a person responsible for the definition, qualification and rationale
> for each object? That way when a question arises, that person would be
> the one to respond and otherwise "defend" the object as necessary.
Good point!!! If Tom Hastings gets this email in time I would recommend
that we try to start obtaining "sponsors". Otherwise, I will make this
an issue in November.
Gail wrote:
>>5. jobMedia (?) This object indicates the media used for this table
>>entry. I propose that this be the prtInputIndex. Information regarding
>>the media can then be obtained from the Printer MIB.
> This is the same assumption that TIP/SI makes: the paper that is currently in
> the tray is the same as the paper that WAS in the tray when the job was
> printed.
> While most of the time this is true statement, it is not a guarantee. If this
> mib is to be used as an accounting tool, don't we want to provide accurate
> information?
Another good action item. Any "sponsors"?
-----------------------------------------------------------------------
Ron Bergman
Dataproducts Corp
rbergma at dpc.com