TH> My comments are prefixed with TH>
TH> If anyone cares to add more comments, I suggest that they
TH> also prefix their initials to their comments so we can tell
TH> from whom they came in this single document.
TH> Tom
Return-Path: <pwg-owner at pwg.org>
From: rbergma at dpc.com
Date: Mon, 30 Sep 1996 09:15:34 PDT
Illegal-Object: Syntax error in To: address found on alpha.xerox.com:
To: gate"pwg at pwg.org"@gate.dpc.com
^ ^-missing end of address
\-extraneous tokens in address
Apparently-To: pwg at pwg.org
To: <hastings at cp10.es.xerox.com>
Subject: RE[2]:Updated Definitions for the Job Monitor Project Sender:
owner-pwg at pwg.org
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.)
TH> The spec with the agreements from the July meeting was posted one
TH> week before the August meeting on 20-Aug in:
TH> ftp://ftp.pwg.org/ftp/pwg/snmpmib/jobs-mib/jmp-spec.doc .psr
> 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!!!
TH> Also remember that there are two roles of users that the MIB is
TH> trying to help: end-users and operators. The operator needs to
TH> know how many copies are requested.
>> 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.)
TH> Both DPA and FTP have separate concepts of job name versus
TH> document name. But in both protocols, neither is necessarily
TH> unique. Both supply the end-user with a convenient handle on
TH> the job and document in the job. In both protocols, there can
TH> be more than one document per job, so that it is important to
TH> have separate concepts. For implementations that don't support
TH> multiple documents per job, the document table will only have
TH> one entry, so no big overhead to have the document name in a
TH> separate table.
>> 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?
TH> These upstream and downstream ids become necessary if there
TH> are more than one entity in a given system that implements the
TH> Job Monitoring MIB. For example, a printer, a supervisor, and
TH> a spooler (or a Novell forwarding printer agent). Each entity
TH> assigns its own job id when it receives the job. If software
TH> and/or an operator needs to reconcile the information from two
TH> different agents in order to relate a job contained in one with
TH> the forwarded copy in another, there needs to be a way to understand
TH> how the job ids map.
> 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!
TH> I think that having a basic MIB and another that augments the
TH> basic MIB maybe a good idea. Then this more complicated stuff
TH> like these Ids can go into the second MIB, provided that the
TH> second MIB can augment the first.
TH> Could the basic MIB be for end-users and status/accounting
TH> and the second MIB be for operators with job parameters
TH> and the complicated upstream, downstream job id objects?
TH> A separate question is whether we do both MIBs in parallel
TH> or as separate projects one after the other?
TH> An alternative is to have the
TH> additional groups in the same MIB, but under conditional mandatory
TH> rather than required, provided that there is a clear specification
TH> as to when the conditional mandatory group becomes mandatory.
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.)
TH> We are getting confused as to which ids we are talking about.
TH> The agreements from Portland (reflected in the Aug spec which
TH> no one seems to be reading) are:
TH> 1. Job client id (on the original client)
TH> 2. Job upstream id (upstream from the server implementing this JM
MIB)
TH> 3. Job current id (on the server implementing this JM MIB)
TH> 4. Job downstream id (downstream from the server implementing this
JM MIB)
TH> Number 3: Job current id is very much required, since that is
TH> assigned by the server receiving the job. In DPA and BSD, the
TH> server assigns unique job ids, since they are under control of
TH> the server that is receiving the jobs. Without the server
TH> quarantee that the job ids are unique, the server is lost, since
TH> we can only encourage clients to generate unique ids, but we can't
TH> force them to.
TH> Perhaps the other ids could go into a second 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!)
TH> Yes, the updated Aug spec from the July Portland meeting
TH> has the enum bit encoded to show the following
TH>
Print(0): The job contains some document production instructions that
specify printing
Scan(1): The job contains some document production instructions that
specify scnning
Fax in(2): The job contains some document production instructions that
specify receive fax
Fax out(4): The job contains some document production instructions that
specify sending fax
Get file(8): The job contains some document production instructions
that specify accessing files or documents
Put file(16): The job contains some document production instructions
that specify storing files or documents
Mail list(32): The job contains some document production instructions
that specify distribution of documents using an electronic mail system.
>> 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!!!)
TH> Why does the name have to be network unique in the MIB?
TH> I would hope that job owner would be network unique within
TH> a particular job submission protocol, but a device might
TH> be supporting serveral job protocols at once. While it might
TH> be nice to require network uniqueness across the network and
TH> across all job submission protocols, I don't see how we can
TH> guarantee it, unless we require the SNMP agent to prefix the
TH> job owner within a job protocol with a prefix that identifies
TH> the job submission protocol, sort of
TH> like a URL. So maybe we could require uniqueness in this object.
>> 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.
TH> Can you give an example?
>> 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)
TH> It is important for those protocols that support multiple
TH> documents per job: DPA, LPD, PostScript and PCL, to name a few
TH> that more than one document name be permitted for a job when
TH> that job has more than one document.
TH> In the Aug spec from the July Portland agreements we have:
TH> 9. Job name (assigned by job owner)
TH> 10. Document name(s) (or file-names)
>> 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.
TH> Already agreed to in Portland and in the August spec as:
TH> Corresponds to the new object being added to the Printer MIB:
TH> prtGeneralDeviceName
>> 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!!!
TH> I disagree. We keep forgetting that either end-users or the
TH> operator may want to see what key job submission parameters are
TH> on the job, so that they can check what is going to happen.
TH> Especially, if the operator is involved in scheduling or
TH> changing devices to accommodate jobs that have been waiting a
TH> long time for, say, transparencies to be loaded, or, say B size
TH> paper, instead of transparencies, etc.
TH> See Goal U2 - The current states fo the user's job (user queries)
TH> See Goal OP3 - What resources does each job need.
TH> I've copied the agreed goals from the charter to the front of
TH> of the jmp-spec.doc, so we won't forget our agreed goals.
>> 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.
TH> The current spec (jmp-spec.doc) from July and August has a
TH> complete set of job states with descriptions and a state diagram.
>> 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.
TH> The current spec has a long list of job state reasons taken
TH> from ISO DPA, X/Open PSIS, and even lists which reasons go with
TH> which job states.
TH> I agree that a job-state-message object is needed, in addition to
TH> the bit map. Then an implementation can further refine the
TH> job state and job state reason. However, such a text string
TH> can only be for humans, not for programs to take action on,
TH> so we need the bits too.
TH> The jmp-spec.doc already has such an object:
TH> 4. Job State Reason Message
>> 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?
TH> The jmp-spec.doc has this object:
TH> 2. Physical device(s) being used
TH> and says that this object is a table that contains
TH> the hrDeviceIndex for each device that this job is using.
TH> So the NMS can go to each device MIB (printer MIB, etc) and
TH> get the status.
TH> On the other hand, if we don't want the Job Monitoring MIB to
TH> require implementation of other device MIBs, we could add
TH> a second object in this table that has the device state for
TH> the device. The first object could be left empty if there is
TH> no corresponding device MIB.
>> 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.
TH> Lets discuss. The reason that DPA defines the octet count
TH> the way it does, is so that the user can determine the progress
TH> of the job, no matter whether the implementation prints the
TH> the copies on one device or several, whether the printer
TH> prints an entire copy and then the next, or whether it prints
TH> all copies of each sheet and put it into a collater.
TH> So if the user knows the size of the job and the number of
TH> copies, the user (or the NMS) can put up a good thermometer for
TH> how far the job is completed, independent of the actual technique
TH> used to make multiple copies.
TH> It seems to me that its only network gurus that might want to
TH> know how many bytes have been transferrred over the network
TH> to the device. For devices that buffer and/or spool the job
TH> the octets received indicate nothing about how far along the
TH> job is as far as producing sheets.
TH> Remember goal OP5: Some idea of how long each job will take.
TH> octets-completed gives a running estimate of how the job is
TH> progressing, independent of technology.
TH> So it seems much more useful to have the DPA octets-completed
TH> than the number of octets transferred to the device.
>> 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?
TH> The warning count provides some feedback to users and operators
TH> as to whether the job is encountering recoverable conditions,
TH> such as font not found or image exceeding imageable area, etc.
TH> These two objects help with goal U2: "The current status of the
TH> user's job (user queries)" and goal U3: "Error and diagnostic
TH> information for jobs that did not successfully complete" since
TH> the warning and error count remains even if the job is aborted.
>> 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!
TH> Errors are more serious, than warnings.
TH> It is up to each system and PDL interpreter
TH> what is considered a warning and what
TH> is considered an error. There is no way that our MIB will
TH> specify. Its is just useful to have both errors and warnings
TH> in my experience for designers and implementors to count separately.
>> 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.
TH> Yes, there is no need for a agent to keep data up to date, just
TH> on the off chance that an SNMP Get might come. The agent can
TH> wait until it gets a Get request to compute the value of certain
TH> objects. The jobPositionInQueue is just such an object.
TH> The job table itself is probably ordered by submission time of the
TH> job, but that is not mandated. So the order of the jobs to
TH> print depends on the scheduling algorithm and is not always
TH> FCFS. So this object is the number of jobs likely to run before
TH> this job gets a chance.
TH> The jm-spec.doc has the object as:
TH> 13. Number of pending jobs currently scheduled to process before
TH> this job. (number-of-intervening-jobs)
TH> We probably want to not require a queue, since some implemenations
TH> don't have queues. So number-of-intervening-jobs
TH> (numberOfInterveningJobs) is probably a better name.
>> 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.
TH> The jm-spec.doc indicates that the data type is:
TH> PrtInterpreterLangFamilyTC from the Printer MIB
TH> and that it is a table for each job, since a job can use
TH> more than one PDL.
> 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.
TH> I think that we should also use our goals from our charter that
TH> I've copied to the front of jm-spec.doc. How about indicating
TH> for each object which goal or goals the object is addressing
TH> perhaps in priority order?
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"?
TH> Since accounting is one of our goals (see jm-spec.doc):
TH> "A1: A record of resources used and printer usage data for
TH> charging uses or groups for resources used."
TH> we have to record the media for a period after the job completes
TH> and for which the media could be changed for the next job.
TH> Also identifying media like any other resource makes media
TH> not special. See objects 15-18 in jm-spec.doc:
TH> "15. Consumables consumed. Presumably a type (enum) indicating the
TH> kind of resource, a name (text string) for each resource, and an
TH> amount (and maybe an enum to indicate what units the amount is in).
TH> Relates to Resources requested.
TH>
TH> 16. consumable name
TH>
TH> 17. consumable-unit
TH>
TH> 18. amount-consumed"
-----------------------------------------------------------------------
Ron Bergman
Dataproducts Corp
rbergma at dpc.com