Job-Monitoring-MIB: View SNMP OID List / Download MIB

The MIB module for monitoring job in servers, printers, and other devices. Version: 1.0

The jmGeneralTable consists of information of a general nature that are per-job-set, but are not per-job. See Section 2 entitled 'Terminology and Job Model' for the definition of a job set. The MANDATORY-GROUP macro specifies that this group is MANDATORY.

Information about a job set (queue). An entry SHALL exist in this table for each job set.

A unique value for each job set in this MIB. The jmJobTable and jmAttributeTable tables have this same index as their primary index. The value(s) of the jmGeneralJobSetIndex SHALL be persistent across power cycles, so that clients that have retained jmGeneralJobSetIndex values will access the same job sets upon subsequent power-up. An implementation that has only one job set, such as a printer with a single queue, SHALL hard code this object with the value 1. See Section 2 entitled 'Terminology and Job Model' for the definition of a job set. Corresponds to the first index in jmJobTable and jmAttributeTable.

The current number of 'active' jobs in the jmJobIDTable, jmJobTable, and jmAttributeTable, i.e., the total number of jobs that are in the pending, processing, or processingStopped states. See the JmJobStateTC textual-convention for the exact specification of the semantics of the job states.

The jmJobIndex of the oldest job that is still in one of the 'active' states (pending, processing, or processingStopped). In other words, the index of the 'active' job that has been in the job tables the longest. If there are no active jobs, the agent SHALL set the value of this object to 0. See Section 3.2 entitled 'The Job Tables and the Oldest Active and Newest Active Indexes' for a description of the usage of this object.

The jmJobIndex of the newest job that is in one of the 'active' states (pending, processing, or processingStopped). In other words, the index of the 'active' job that has been most recently added to the job tables. When all jobs become 'inactive', i.e., enter the pendingHeld, completed, canceled, or aborted states, the agent SHALL set the value of this object to 0. See Section 3.2 entitled 'The Job Tables and the Oldest Active and Newest Active Indexes' for a description of the usage of this object.

The minimum time in seconds for this instance of the Job Set that an entry SHALL remain in the jmJobIDTable and jmJobTable after processing has completed, i.e., the minimum time in seconds starting when the job enters the completed, canceled, or aborted state. Configuring this object is implementation-dependent. This value SHALL be equal to or greater than the value of jmGeneralAttributePersistence. This value SHOULD be at least 60 which gives a monitoring or accounting application one minute in which to poll for job data.

The minimum time in seconds for this instance of the Job Set that an entry SHALL remain in the jmAttributeTable after processing has completed , i.e., the time in seconds starting when the job enters the completed, canceled, or aborted state. Configuring this object is implementation-dependent. This value SHOULD be at least 60 which gives a monitoring or accounting application one minute in which to poll for job data.

The human readable name of this job set assigned by the system administrator (by means outside of this MIB). Typically, this name SHOULD be the name of the job queue. If a server or device has only a single job set, this object can be the administratively assigned name of the server or device itself. This name does not need to be unique, though each job set in a single Job Monitoring MIB SHOULD have distinct names. NOTE - If the job set corresponds to a single printer and the Printer MIB is implemented, this value SHOULD be the same as the prtGeneralPrinterName object in the draft Printer MIB [print-mib-draft]. If the job set corresponds to an IPP Printer, this value SHOULD be the same as the IPP 'printer- name' Printer attribute. NOTE - The purpose of this object is to help the user of the job monitoring application distinguish between several job sets in implementations that support more than one job set. See the OBJECT compliance macro for the minimum maximum length required for conformance.

The jmJobIDTable provides a correspondence map (1) between the job submission ID that a client uses to refer to a job and (2) the jmGeneralJobSetIndex and jmJobIndex that the Job Monitoring MIB agent assigned to the job and that are used to access the job in all of the other tables in the MIB. If a monitoring application already knows the jmGeneralJobSetIndex and the jmJobIndex of the job it is querying, that application NEED NOT use the jmJobIDTable. The MANDATORY-GROUP macro specifies that this group is MANDATORY.

The map from (1) the jmJobSubmissionID to (2) the jmGeneralJobSetIndex and jmJobIndex. An entry SHALL exist in this table for each job currently known to the agent for all job sets and job states. There MAY be more than one jmJobIDEntry that maps to a single job. This many to one mapping can occur when more than one network entity along the job submission path supplies a job submission ID. See Section 3.5. However, each job SHALL appear once and in one and only one job set.

A quasi-unique 48-octet fixed-length string ID which identifies the job within a particular client-server environment. There are multiple formats for the jmJobSubmissionID. Each format SHALL be uniquely identified. See the JmJobSubmissionIDTypeTC textual convention. Each format SHALL be registered using the procedures of a type 2 enum. See section 3.7.3 entitled: 'PWG Registration of Job Submission Id Formats'. If the requester (client or server) does not supply a job submission ID in the job submission protocol, then the recipient (server or device) SHALL assign a job submission ID using any of the standard formats that have been reserved for agents and adding the final 8 octets to distinguish the ID from others submitted from the same requester. The monitoring application, whether in the client or running separately, MAY use the job submission ID to help identify which jmJobIndex was assigned by the agent, i.e., in which row the job information is in the other tables. NOTE - fixed-length is used so that a management application can use a shortened GetNext varbind (in SNMPv1 and SNMPv2) in order to get the next submission ID, disregarding the remainder of the ID in order to access jobs independent of the trailing identifier part, e.g., to get all jobs submitted by a particular jmJobOwner or submitted from a particular MAC address. See the JmJobSubmissionIDTypeTC textual convention. See APPENDIX B - Support of Job Submission Protocols.

This object contains the value of the jmGeneralJobSetIndex for the job with the jmJobSubmissionID value, i.e., the job set index of the job set in which the job was placed when that server or device accepted the job. This 16-bit value in combination with the jmJobIDJobIndex value permits the management application to access the other tables to obtain the job-specific objects for this job. See jmGeneralJobSetIndex in the jmGeneralTable.

This object contains the value of the jmJobIndex for the job with the jmJobSubmissionID value, i.e., the job index for the job when the server or device accepted the job. This value, in combination with the jmJobIDJobSetIndex value, permits the management application to access the other tables to obtain the job-specific objects for this job. See jmJobIndex in the jmJobTable.

The jmJobTable consists of basic job state and status information for each job in a job set that (1) monitoring applications need to be able to access in a single SNMP Get operation, (2) that have a single value per job, and (3) that SHALL always be implemented. The MANDATORY-GROUP macro specifies that this group is MANDATORY.

Basic per-job state and status information. An entry SHALL exist in this table for each job, no matter what the state of the job is. Each job SHALL appear in one and only one job set. See Section 3.2 entitled 'The Job Tables'.

The sequential, monatonically increasing identifier index for the job generated by the server or device when that server or device accepted the job. This index value permits the management application to access the other tables to obtain the job-specific row entries. See Section 3.2 entitled 'The Job Tables and the Oldest Active and Newest Active Indexes'. See Section 3.5 entitled 'Job Identification'. See also jmGeneralNewestActiveJobIndex for the largest value of jmJobIndex. See JmJobSubmissionIDTypeTC for a limit on the size of this index if the agent represents it as an 8-digit decimal number.

The current state of the job (pending, processing, completed, etc.). Agents SHALL implement only those states which are appropriate for the particular implementation. However, management applications SHALL be prepared to receive all the standard job states. The final value for this object SHALL be one of: completed, canceled, or aborted. The minimum length of time that the agent SHALL maintain MIB data for a job in the completed, canceled, or aborted state before removing the job data from the jmJobIDTable and jmJobTable is specified by the value of the jmGeneralJobPersistence object.

Additional information about the job's current state, i.e., information that augments the value of the job's jmJobState object. Implementation of any reason values is OPTIONAL, but an agent SHOULD return any reason information available. These values MAY be used with any job state or states for which the reason makes sense. Since the Job State Reasons will be more dynamic than the Job State, it is recommended that a job monitoring application read this object every time jmJobState is read. When the agent cannot provide a reason for the current state of the job, the value of the jmJobStateReasons1 object and jobStateReasonsN attributes SHALL be 0. The jobStateReasonsN (N=2..4) attributes provide further additional information about the job's current state.

The number of jobs that are expected to complete processing before this job has completed processing according to the implementation's queuing algorithm, if no other jobs were to be submitted. In other words, this value is the job's queue position. The agent SHALL return a value of 0 for this attribute when the job is the next job to complete processing (or has completed processing).

The total size in K (1024) octets of the document(s) being requested to be processed in the job. The agent SHALL round the actual number of octets up to the next highest K. Thus 0 octets is represented as '0', 1-1024 octets is represented as '1', 1025-2048 is represented as '2', etc. In computing this value, the server/device SHALL NOT include the multiplicative factors contributed by (1) the number of document copies, and (2) the number of job copies, independent of whether the device can process multiple copies of the job or document without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the server/device computation is independent of the implementation and indicates the size of the document(s) measured in K octets independent of the number of copies.

The total number of octets processed by the server or device measured in units of K (1024) octets so far. The agent SHALL round the actual number of octets processed up to the next higher K. Thus 0 octets is represented as '0', 1-1024 octets is represented as '1', 1025-2048 octets is '2', etc. For printing devices, this value is the number interpreted by the page description language interpreter rather than what has been marked on media. For implementations where multiple copies are produced by the interpreter with only a single pass over the data, the final value SHALL be equal to the value of the jmJobKOctetsPerCopyRequested object. For implementations where multiple copies are produced by the interpreter by processing the data for each copy, the final value SHALL be a multiple of the value of the jmJobKOctetsPerCopyRequested object. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobKOctetsProcessed object can be used with the jmJobKOctetsPerCopyRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies.

The total size in number of impressions of the document(s) submitted. In computing this value, the server/device SHALL NOT include the multiplicative factors contributed by (1) the number of document copies, and (2) the number of job copies, independent of whether the device can process multiple copies of the job or document without making multiple passes over the job or document data and independent of whether the output is collated or not. Thus the server/device computation is independent of the implementation and reflects the size of the document(s) measured in impressions independent of the number of copies. See the definition of the term 'impression' in Section 2.

The total number of impressions completed for this job so far. For printing devices, the impressions completed includes interpreting, marking, and stacking the output. For other types of job services, the number of impressions completed includes the number of impressions processed. NOTE - See the impressionsCompletedCurrentCopy and pagesCompletedCurrentCopy attributes for attributes that are reset on each document copy. NOTE - The jmJobImpressionsCompleted object can be used with the jmJobImpressionsPerCopyRequested object to provide an indication of the relative progress of the job, provided that the multiplicative factor is taken into account for some implementations of multiple copies. See the definition of the term 'impression' in Section 2 and the counting example in Section 3.4 entitled 'Monitoring Job Progress'.

The coded character set name of the user that submitted the job. The method of assigning this user name will be system and/or site specific but the method MUST ensure that the name is unique to the network that is visible to the client and target device. This value SHOULD be the most authenticated name of the user submitting the job. See the OBJECT compliance macro for the minimum maximum length required for conformance.

The jmAttributeTable SHALL contain attributes of the job and document(s) for each job in a job set. Instead of allocating distinct objects for each attribute, each attribute is represented as a separate row in the jmAttributeTable. The MANDATORY-GROUP macro specifies that this group is MANDATORY. An agent SHALL implement any attribute if (1) the server or device supports the functionality represented by the attribute and (2) the information is available to the agent.

Attributes representing information about the job and document(s) or resources required and/or consumed. Each entry in the jmAttributeTable is a per-job entry with an extra index for each type of attribute (jmAttributeTypeIndex) that a job can have and an additional index (jmAttributeInstanceIndex) for those attributes that can have multiple instances per job. The jmAttributeTypeIndex object SHALL contain an enum type that indicates the type of attribute (see the JmAttributeTypeTC textual-convention). The value of the attribute SHALL be represented in either the jmAttributeValueAsInteger or jmAttributeValueAsOctets objects, and/or both, as specified in the JmAttributeTypeTC textual- convention. The agent SHALL create rows in the jmAttributeTable as the server or device is able to discover the attributes either from the job submission protocol itself or from the document PDL. As the documents are interpreted, the interpreter MAY discover additional attributes and so the agent adds additional rows to this table. As the attributes that represent resources are actually consumed, the usage counter contained in the jmAttributeValueAsInteger object is incremented according to the units indicated in the description of the JmAttributeTypeTC enum. The agent SHALL maintain each row in the jmAttributeTable for at least the minimum time after a job completes as specified by the jmGeneralAttributePersistence object. Zero or more entries SHALL exist in this table for each job in a job set. See Section 3.3 entitled 'The Attribute Mechanism' for a description of the jmAttributeTable.

The type of attribute that this row entry represents. The type MAY identify information about the job or document(s) or MAY identify a resource required to process the job before the job start processing and/or consumed by the job as the job is processed. Examples of job attributes (i.e., apply to the job as a whole) that have only one instance per job include: jobCopiesRequested(90), documentCopiesRequested(92), jobCopiesCompleted(91), documentCopiesCompleted(93), while examples of job attributes that may have more than one instance per job include: documentFormatIndex(37), and documentFormat(38). Examples of document attributes (one instance per document) include: fileName(34), and documentName(35). Examples of required and consumed resource attributes include: pagesRequested(130), mediumRequested(170), pagesCompleted(131), and mediumConsumed(171), respectively.

A running 16-bit index of the attributes of the same type for each job. For those attributes with only a single instance per job, this index value SHALL be 1. For those attributes that are a single value per document, the index value SHALL be the document number, starting with 1 for the first document in the job. Jobs with only a single document SHALL use the index value of 1. For those attributes that can have multiple values per job or per document, such as documentFormatIndex(37) or documentFormat(38), the index SHALL be a running index for the job as a whole, starting at 1.

The integer value of the attribute. The value of the attribute SHALL be represented as an integer if the enum description in the JmAttributeTypeTC textual-convention definition has the tag: 'INTEGER:'. Depending on the enum definition, this object value MAY be an integer, a counter, an index, or an enum, depending on the jmAttributeTypeIndex value. The units of this value are specified in the enum description. For those attributes that are accumulating job consumption as the job is processed as specified in the JmAttributeTypeTC textual-convention, SHALL contain the final value after the job completes processing, i.e., this value SHALL indicate the total usage of this resource made by the job. A monitoring application is able to copy this value to a suitable longer term storage for later processing as part of an accounting system. Since the agent MAY add attributes representing resources to this table while the job is waiting to be processed or being processed, which can be a long time before any of the resources are actually used, the agent SHALL set the value of the jmAttributeValueAsInteger object to 0 for resources that the job has not yet consumed. Attributes for which the concept of an integer value is meaningless, such as fileName(34), jobName, and processingMessage, do not have the 'INTEGER:' tag in the JmAttributeTypeTC definition and so an agent SHALL always return a value of '-1' to indicate 'other' for the value of the jmAttributeValueAsInteger object for these attributes. For attributes which do have the 'INTEGER:' tag in the JmAttributeTypeTC definition, if the integer value is not (yet) known, the agent either (1) SHALL not materialize the row in the jmAttributeTable until the value is known or (2) SHALL return a '-2' to represent an 'unknown' counting integer value, a '0' to represent an 'unknown' index value, and a '2' to represent an 'unknown(2)' enum value.

The octet string value of the attribute. The value of the attribute SHALL be represented as an OCTET STRING if the enum description in the JmAttributeTypeTC textual-convention definition has the tag: 'OCTETS:'. Depending on the enum definition, this object value MAY be a coded character set string (text), such as 'JmUTF8StringTC', or a binary octet string, such as 'DateAndTime'. Attributes for which the concept of an octet string value is meaningless, such as pagesCompleted, do not have the tag 'OCTETS:' in the JmAttributeTypeTC definition and so the agent SHALL always return a zero length string for the value of the jmAttributeValueAsOctets object. For attributes which do have the 'OCTETS:' tag in the JmAttributeTypeTC definition, if the OCTET STRING value is not (yet) known, the agent either SHALL NOT materialize the row in the jmAttributeTable until the value is known or SHALL return a zero-length string.

The compliance statement for agents that implement the job monitoring MIB.

The general group.

The job ID group.

The job group.

The attribute group.