SNMP MIB Search

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

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.

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'.

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.

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.

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 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 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 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.

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 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.

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. 

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

The general group.

The job ID group.

The job group.

The attribute group.