XEROX-JOB-MONITORING-MIB

This trap is sent whenever the state of a job changes. The
'state of a job' is comprised by the aggregate values of the
xcmJobCurrentState, xcmJobPriority, xcmJobStateReasons,
xcmJobXStateReasons, xcmJobX2StateReasons,
xcmDevicesAssigned and xcmDeviceStateOfDevicesAssigned
fields of the job's table entries: This notification is
sent whenever any of these values changes with the following
exceptions:

1. Changes in xcmDeviceStateOfDevicesAssigned shall only
generate traps when the job is in the processing state
(NOTE - xcmJMDevicesAssignedGroup is deprecated)

2. Changes in xcmJobStateReasons, xcmJobXStateReasons, and
xcmJobX2StateReasons shall only generate traps when the job is
in the processing state (rare). The normal polling cycle will
pick up any changes while the job is not in the processing
state. Since most changes in reasons also accompany a job state
change, the chances that a change in a reason will have to wait
for the normal polling cycle is very small. For example, a
requester further modifies a held job adding more reasons for it
to be held will have to wait for the polling cycle, since the
job does not change state (remaining in the held state).


NOTE - the hrDeviceIndex is included for convenience, even
though the Printer MIB (RFC 1759) doesn't include hrDeviceIndex
in its traps. Then the management station doesn't have to parse
the received varBind OIDs on a trap in order to discover which
device trapped.

NOTE - the addition of an entire row to the job tables
corresponds to the acceptance of another job by the server. The
state of the job changes from unknown to a specific value
(usually pending). Therefore, the agent shall generate a trap
when a job is accepted (so that the management station can
display the newly arrived job in a timely fashion).

Similarly when the server removes a job because the job has been
in the completed state for a sufficient time or the job has been
deleted by a Delete operation, the SNMP agent shall reflect
that removal by removing the row from the job tables, and shall
generate a trap (since the state of the job has changed to
non-existent).

The IETF Printer MIB maintains a table which serves as a sort
of 'audit-trail' of recent alerts. There is no need for such
a table here, since the job's tables will serve virtually the
same purpose.

As with all SNMP notifications, critical applications cannot
completely rely upon delivery: some amount of polling is
recommended.

The variable-bindings of this trap have been chosen to give the
minimum of information: the xcmJobIdentifierOnSystem
value and hrDeviceIndex are provided. With these an application
is able to obtain the full job table entry. An application has
to look at the job tables anyway. The time of the alert is
returned as part of any SNMP trap.

The hrDeviceIndex maps one-to-one with the PWG Job Mon
jmGeneralJobSetIndex. (The PWG Job Mon does not require the
Host Resources MIB, so the name of the primary index for all PWG
Job Mon tables is not hrDeviceIndex, but serves the same
purpose of allowing multiple instances in a single device or
server.

The Job Alert's special semantics is covered by U.S. patent
5778183.
This notification has the following special semantics:

o If the job's xcmJobClientId field is not empty,
its value will also be appended to trap object ID.

NOTE: If the format of the xcmJobClientId is dotted
decimal representation, then it will be encoded as a BER
binary OID appended to the trap object ID.


NOTE: The BER binary OID shall not include the ASN.1/BER
tag of 6 indicating an OID and shall not include the
ASN.1/BER length field in octets of the OID.

This trap OID qualifier allows job-submission and monitoring
applications to limit the alerts they receive to ones generated
by jobs which they have submitted.

NOTE: The sum of the trap var bind values must be less than can
fit into a PDU on any transport, roughly 540 octets on some
transports. Thus implementers are warned to minimize the length
of the xcmJobClientId and xcmJobIdentifierOnSystem objects.

This trap is sent whenever the state of one of the documents in
a job changes. The state of a single document is represented in
the xcmDocGenBasicTable column: xcmDocState.

The job's xcmJobIdentifierOnSystem and the document's
xcmDocSequenceNumber are included in the trap's variable
bindings; these can be used to reference the document's
xcmDocGenBasicTable entry.

NOTE - the addition of an entire row to the document tables
corresponds to the acceptance of another document (in a job) by
the server. The state of the document changes from unknown to a
specific value (usually transfer pending). Therefore, the agent
generates a trap when a document (within a job) is accepted (so
that the management station can display the newly arrived
document in a timely fashion).

This notification has the following special semantics:

1 The agent shall append the document's job's
xcmJobClientId to the trap object ID, if the document's
job's xcmJobClientId field is not empty.
NOTE: If the format of the xcmJobClientId is dotted


decimal representation, then it will be encoded as a BER
binary OID appended to the trap object ID.

NOTE: The BER binary OID shall not include the ASN.1/BER
tag of 6 indicating an OID and shall not include the
ASN.1/BER length field in octets of the OID.

2 The agent shall append the value of the document's
xcmDocSequenceNumber field to the trap object ID.

These trap OID qualifiers allow job-submission and monitoring
applications to specify exactly which alerts they are interested
in and to limit the alerts they receive to ones generated by
jobs or jobs and documents that they have submitted.

NOTE: The sum of the trap var bind values must be less than can
fit into a PDU on any transport, roughly 540 octets on some
transports. Thus implementers are warned to minimize the length
of the xcmJobClientId and xcmJobIdentifierOnSystem objects.