Updated Definitions for The Job Monitor Project

Updated Definitions for The Job Monitor Project

Updated Definitions for The Job Monitor Project

Tom Hastings hastings at cp10.es.xerox.com
Tue Oct 1 02:33:43 EDT 1996


TH> I've annoted your updated definitions to tie back to the agreed spec
TH> to help us at the meeting.


TH> I've added the names and numbers of the agreed objects from the  
TH> Portland meeting as reflected in the jm-spec.doc and jm-spec.psr 
TH> that I posted a week before the August meeting in San Diego 
TH> that was cancelled at the last minute. 
 
TH> Then we can use these descriptions as we review the specification 
TH> posted in ftp://ftp.pwg.org/pub/pwg/snmpmib/jobs-mib/ 
TH> 
TH> -rw-r--r--   1 pwg      pwg       186368 Aug 22 23:30 jmp-spec.doc 
TH> -rw-r--r--   1 pwg      pwg       621572 Aug 22 23:37 jmp-spec.psr 
 
Return-Path: <pwg-owner at pwg.org> 
From: rbergma at dpc.com 
Date: Thu, 26 Sep 1996 18:42:43 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: Updated Definitions for The Job Monitor Project Sender: owner-
pwg at pwg.org 
 
This paper summarizes my understanding of the current status of the 
proposed objects for the Job Monitor project.  I believe that this 
document is necessary since the JMP minutes for the last two meeting 
were never published. 
 
TH> Not true, since the updated spec with the agreements from June 
TH> and July were each posted a week before the next meeting. 
TH> see jm-spec.doc and jm-spec.psr. 
 
I have also included a revised set of definitions for the objects to 
replace the DPA set originally provided by Tom Hastings.  My objective 
in writing these descriptions was to develop a minimal definition that 
could be expanded to a final form.  I feel that the DPA definitions are 
extremely restrictive and limiting in many areas.  We need a concise set 
of definitions that are applicable and useable with any job submission 
protocol and model. 
 
TH> I agree that our actual MIB wants to have concise definitions 
TH> along the lines that you propose.  But I want to first get agreement 
TH> on what objects we want and then we can refine, simplify, etc. 
TH> But if we attempt to worksmith the descriptions at the same time 
TH> as we are trying to decide what objects we need, we will have too 
TH> difficult time and progress will be too slow.   
 
TH> Also some of these definitions are actually different from the ISO  
TH> DPA semantics. 
 
TH> Also I don't want to debate names of the objects, until we have 
TH> the definitions agreed to.  Naming should come last.  Also we need 
TH> to understand what information a single job will have in a  
TH> (doubly indexed) table as opposed to a scaler (one column in the job 
TH> table) for the job.  Separate tables may want to have a different 
TH> significant word, such as "job" for the scalars and something else 
TH> for the tables, such as "doc", or "acc". or something.   
TH> So we need to wait to name our objects until after we agree on the 
TH> specification and the number of instances per job. 
TH> Also we may want to have a common prefix on each object, such as 
TH> "jm" for job monitoring, like so many other MIBs. 
 
TH> So the order for processing should be: 
TH> 1. What objects do we want using DPA definitions to indicate what  
TH> we mean using jm-spec.doc and jm-spec.psr. 
TH> 2. What objects are mandatory, what are conditionally mandatory, 
T>     what are in a second MIB. 
TH> 3. Which objects are one instance per job and which are multiple 
TH>    per job. 
TH> 4. What is the syntax for each object. 
TH> 5. What is the simplified description text for each object. 
TH> 6. What is the name for each object. 
 
Since I will not be able to attend the NYC meeting, I trust that Tom 
Hastings will make use of this document in the session devoted to the 
Job Monitor Project.  (Note that my absence is not due to a fear of the 
Big Apple, the expense of the meeting or the limited attendance by 
others.  I was not able to attend the San Diego meeting due to a similar 
situation.  And that meeting had none of the above problems!)  I hope to 
see everyone in New Orleans!!! 
 
TH> I've indicated the agreed descriptive name with the 
TH> number in the August agreed spec, followed by the ISO DPA name 
TH> in square brackets. 
------------------------------------------------------------------------ 
 
JOB IDENTIFICATION OBJECTS: 
 
TH> 1. Job client id (on the original client) [job-client-id] 
 
1. jobIdOnClient: (String, max TBD)  This object identifies the job on 
the device that initiated the job.  The format and method of generating 
this object is expected to be defined by the Job Submission protocol and 
is beyond the scope of this document.  This object must include 
sufficient information to uniquely identify the job on the network 
visible to the client and target device. 
 
  *** THE FOLLOWING TWO OBJECTS ARE OF QUESTIONABLE VALUE ***  
 
 
TH> 4. Job downstream id (downstream from the server implementing this 
JM MIB) on device (printer [job-identifier-on-printer] 
 
2. jobDownsteamId: (String, max TBD)  This object identfies the job on 
the next downstream server. 
 
 
TH> 2. Job upstream id (on upstream from the server implementing thise 
JM MIB) [job-id-on-client] 
 
3. jobUpstreamId: (String, max TBD)  This object identfies the job on 
the next upstream server. 
 
  *** PROPOSED ALTERNATIVES TO THE ABOVE TWO OBJECTS *** 2. 
jobIdOnPktSrc: (String, max TBD)  This object specifies the identifier 
as assigned  by the entity that is currently sending the data set.  The 
value of this object will change as the data set moves from server to 
server. 
 
3. jobIdOnPktDest: (String, max TBD)  This object specifies the 
identifier as assigned by the entity that is currently receiving the 
data set.  The value of this object will change as the data set moves 
from server to server. 
  *** ARE EITHER OF THESE PROPOSALS REALLY NECESSARY ??? *** 
 
 
TH> 3. Job current id (on the downstream server implementing thise JM 
MIB) [job-identifier] 
 
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. 
 
 
TH> 5. Job types (print, fax, scan, etc.) - multi-valued [new] 
 
5. jobType: (enum)  This object specifies the type of service requested 
to process the job. 
 
 
TH> 6. Job owner (User name that originally submitting print job) [new] 
 
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. 
 
 
TH> 7. Source channel type (index of channel row in enum from Printer 
MIB) [new] 
 
7. jobChannel: (enum)  This object defines an equivalent to the print 
job delivery channel as defined in the Printer MIB. 
 
 
TH> ?. This is new but replaces the "source port" that we agreed to 
TH> delete in Portland. 
 
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. 
 
 
TH> 9. Job name (assigned by job owner) [job-name] 
 
9. jobName: (String, max TBD)  This object is an ASCII text string which 
identifies the job.  This is expected to be human readable form of 
jobIdOnClient. 
	*** IS THIS OBJECT SIGNIFICANTLY UNIQUE TO BE OF VALUE ??? *** 
 
TH> Its purpose isn't uniqueness, but helps a user distinguish between  
TH> his various jobs.  Its job-owner that distinguishes between jobs 
TH> belonging to different users. 
 
 
 
TH> 10. Document name(s) (or file-names) [document-name] 
 
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 jon queue.) 
 
 
TH> 11. Date/Time of job submission by job owner [submission-time] 
 
11. jobSubmissionTime: (DateAndTime)  This object indicates the time and 
date the job was submitted by the client. 
 
 
TH> 12. Job comment [job-comment] 
 
12. jobComment: (String, max TBD)  This object provides a user 
defineable, application specific field.  (Post-it note) 
 
 
TH> 13. Device name (Device-specific name of device) [printer-name-
requested] 
 
13. jobDeviceName: (String, max TBD)  This object specifies the 
administratively defined name of the target device. 
 
 
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 !!! *** 
 
 
TH> 1. Number of copies requested [job-copies] 
 
1. jobCopiesRequested (Integer32) 
 
 
TH> 2. Media path requested (one-sided, two-sided, LEF, SEF) [one value 
for each document] 
 
2. jobMediaPathRequested (enum) 
 
 
TH> 3. PDLs requested [one value for each document] [document-format] 
 
3. jobPDLRequested (enum) 
 
 
TH> 4. Job priority [job-priority] 
 
4. jobPriorityRequested (Integer) 
 
 
TH> 5. Resource types requested, including media, finishing, color ink.  
TH> Presumably a type (enum) indicating the kind of resource.   
TH> Relates to Consumables consumed.  TH> [new] 
 
5. jobResourceRequested (enum) 
 
 
TH> 6. Resource names requested [new] 
 
6. jobResourceNamesRequested (String) 
 
 
TH> 7. Destination (including phone numbers for FAX, logical printers 
for printing) [new] 
 
7. jobDestinationRequested (String) 
 
 
TH> 8. process-after-time [job-print-after] 
 
8. jobProcessAfterTime (TimeAndDate) 
 
 
TH> 9. job-message-to-operator from submitting user or device [job- 
TH> message-to-operator] 
 
9. jobMessageToOperator (String) 
 
 
 
STATUS AND ACCOUNTING PARAMETERS: 
 
TH> 1. Job state (held, pending, processing, completed, etc.) [current- 
TH> job-state] 
 
1. jobState (enum ?)  This object defines the current state of the job.   
(e.g. queued, printing, completed, etc.) 
 
 
TH> 3. Job state reasons [job-state-reasons] 
 
2. jobStateReason (bit map)  This object provides additional information 
regarding the the jobState. 
 
 
TH> 2. Physical device(s) being used [printers-assigned] 
 
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 ??? *** 
 
 
TH> 4. Job State Reason Message [new] 
 
not in Ron's list 
 
 
TH> 5. Octets completed [octets-completed] 
 
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. 
 
 
TH> Objects 5, 6, and 7 were merged into consumables consumed in  
TH> jm-spec. 
 
  *** OBJECTS 5, 6, AND 7 WILL BE A TABLE WITH AN ENTRY FOR EACH *** 
  *** MEDIA TYPE USED. *** 
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. 
 
 
TH> 6. Impressions (sides) complete [impressions-completed] 
 
6. jobImpressionsCompleted (Counter32)  This object defines the total 
number of sides that have been completed for this job.  Each physical 
sheet has two possible side.  (i.e. For a duplex printing job, the 
number of impressions will be 2 for each physical sheet printed on both 
sides.) 
 
 
TH> 7. Sheets completed [media-sheets-completed] 
 
7. jobMediaSheetsCompleted (Counter32)  This object defines the total 
number of physical sheets that have been completed for this job. 
 
 
TH> 8. Processing time completed [processing-time] 
 
8. jobProcessingTimeCompleted (Counter32)  This object defines the 
processing time, in seconds, consumed by the job. 
 
 
TH> 9. Date/Time of day job started processing on device [started- 
TH> printing-time] 
 
9. jobStartingTime (DateAndTime)  This object indicates the time the job 
started printing. 
 
 
TH> 10. Date/Time of day job finished using the device [completed-time] 
 
10. jobCompletionTime (DataAndTime) This object defines the time the job 
finished printing. 
 
 
TH> 11. Warning count [warning-count] 
 
11. jobWarningCount (Counter32)  This object contains a count of the 
number of warning events that occurred during the processing of the job. 
 
 
TH> 12. Error-count [error-count] 
 
12. jobErrorCount (Counter32)  This object contains a count of the 
number of error events that occurred during the processing of the job. 
 
 
TH> 13. Number of pending jobs currently scheduled to process before  
TH> this job [intervening-jobs] 
 
13. jobPositionInQueue (Counter32)  This object indicates the number of 
jobs preceeding this job in the print queue. 
 
 
TH> 14. Account Name [accounting-information] 
 
14. jobAccountName (String, max TBD)  This object contains information 
to be used by an accounting system to categorize charges. 
 
  *** OBJECTS 15, 16, 17 AND 18 WILL BE A TABLE WITH AN ENTRY *** 
  *** FOR EACH CONSUMABLE USED. *** 
 
TH> 15. Consumables consumed [new] 
 
15. jobConsumableId (enum)  This object defines the resource used. 
 
 
TH> 16. consumable name [new] 
 
16. jobConsumableName (String, max TBD)  This object provides an ASCII 
text string which describes the consumable. 
 
 
TH> 17. consumable-unit [new] 
 
17. jobConsumableUnit (enum)  This objects defines the units of measure 
for the consumable. 
 
 
TH> 18. amount-consumed [new] 
 
18. jobConsumableUsed (Integer32)  This object indicates the amount of 
the resource consumed. 
 
 
TH> 19. PDLs used [document-format] 
 
19. pdlUsed (enum)  This object defines the PDL(s) used by the job. 
 



More information about the Pwg mailing list