| A job may be in any of the states defined by this textual-
convention.
The Xerox Job model is a refinement of the ISO DPA standard and
generalizes to non-printing devices. The textual definitions
given here are an abbreviation of the full specification of the
semantics of the job states given in the Xerox Job Model
specification. Agent implementers of this MIB need to refer to
the Xerox Job Model specification in addition to this textual
convention.
Traps shall be generated when a job performs a job
state transition. In order to reduce network traffic, it is
recommended, but not required, that an implementation suppress
traps for self-loops. The xcmJobPreviousState can be used to
detect self-loops and suppress self-loop traps by not sending
traps when the value of the xcmJobPreviousState is the same as
the value of the xcmJobCurrentState.
When a job is in the processing state,
the state of the assigned device(s) is needed to fully
represent the state of the job. In addition, the
job-state-reasons attributes provides additional, more abstract,
user feedback about what is happening to the job when the job
is in many of its states. See the Xerox Job Model
Specification, Phase 1 or later for the specification of which
job-state-reasons values may be used with which job states..
ISO DPA: Job-current-state
Standard values are defined for the current-job-state and
previous-job-state attributes of the DPA job object, as follows:
unknown The job state is not known, or is
indeterminate, or is not returned by the
operation. (id-val-job-state-unknown)
creating The job has been created on the server by
the create-job sub-operation of the Submit
request, but a Submit request with neither (1)
a TRUE value for the job-submission-complete
component of the SubmitArgument nor (2) a TRUE
value for the job-process-before-completely-
specified (long jobs) job attribute has not
yet been received and no document has started
processing. The job maybe in the process
of being checked by the server for
attributes, defaults being applied, a
device being selected, etc.
[Renamed from ISO DPA pre-processing state,
but kept the same enum code, since the
semantics are identical.] (id-val-job-
state-pre-processing)
NOTE: The Xerox Job Model transitory state: evaluate-hold shall not be
visible to requesters, and therefore is not in the Job Monitoring MIB.
held The job is waiting to be released for
scheduling for any number of reasons as
specified by the value of the job's job-
state-reasons attribute. (id-val-job-
state-held)
See the Xerox Job Model Specification, Phase 1
or later for the specification of which
job-state-reasons values may be used when the
job is in the held state.
pending The job is
waiting to start processing on a device and
has no shared system resources assigned to it
yet. (id-val-job-state-pending)
[The ISO DPA processing and printing states have been combined into a
single job state, called processing, which includes any device activity,
so that the job life cycle can be used for all kinds of jobs, not just
printing jobs, and have the same life cycle. The printing state is
DEPRECATED. In addition, the difference between the ISO DPA processing
state and printing state was one of user feed back only. The standard
specified no differences in job state transitions between the processing
and printing states. Therefore, ISO DPA should have used the device-
state-of-devices-assigned mechanism to provide the user feedback
distinction between the processing and printing states. In fact,
neither Novell's NDPS nor IBM's PSM DPA products implement the printing
state, only the processing state. Only Printxchange implements the
printing state (as well as the processing state). So we will propose to
ISO DPA that the DPA printing state be deprecated.
[For convenience in understanding the difference between ISO DPA and the
Job Monitoring MIB (and the Xerox Job Model), the ISO DPA processing and
printing specifications are given here first, followed by the new
(Xerox) definition of processing which incorporates the semantics of the
ISO DPA processing and printing states, and extends these semantics to
sub-jobs.]
[ISO DPA processing specification: The server is processing the job, or
has made the job ready for printing, but the output device is not yet
printing it, either because the job hasn't reached the output device or
because the job is queued in the output device or some other spooler,
awaiting the output device to print it.]
[ISO DPA printing state specification which is DEPRECATED by the Job
Monitoring MIB: The server has completed processing the job and the
output device is currently printing the job on at least one printer.
That is, a print engine is either printing pages of the job, or failing
in its attempt to print pages of the job because of some wait state,
such as, start-wait, end-wait, needs-attention, etc. The complete job
state includes the detailed status represented in the printers' printer-
state attribute(s).]
[The following Xerox definition of the 'processing' job state combines
the ISO DPA processing and printing states into a single state, called
'processing', which can be used with any kind of device:
processing The server is:
(1) processing the job, or
(2) has made the job ready for processing, but
the device is not yet processing it, either:
(a) because the job hasn't reached the
device or
(b) because the job is queued in the device
or some other spooler, awaiting the
device to process it
or
(3) has completed processing the job and the
device is currently processing (printing,
scanning, sending-fax, receiving-fax,
sending-e-mail, filing, or retrieving) the job
on at least one device. That is, a device is
either performing input-output of the job, or
failing in its attempt to perform input-output
of the job because of some wait state, such
as, start-wait, end-wait, needs-attention,
etc.
Additional information about the job's current
state is also given in the job's
job-state-reasons attribute for when the job
is in any of its states, including processing.
See the Xerox Job Model for which values of
the job's job-state-reasons attribute may be
used when the job is in the processing state.
NOTE: DPA does not yet have any
job-state-reasons defined for the
processing/printing states.
(id-val-job-state-processing)]
paused The job has been paused as a result of a
PauseJob request.
NOTE: The Xerox Job Model has renamed the
PauseJob and ResumeJob operations to HoldJob
and ReleaseJob and has changed the semantics
to put the job back into the held state,
with the job-hold attribute set to TRUE
and the job-hold-set value added to the
job-state-reasons attribute instead of putting
into the paused state. So the paused state
remains only for use with ISO DPA systems that
have implemented the paused state.
(id-val-job-state-paused)
interrupted The job was interrupted by the InterruptJob
request for an intervening job, and shall
resume processing automatically once the
intervening job has completed. The
interrupted job may relinquish shared
resources and devices to the interrupting job,
but not to other jobs.
(id-val-job-state-interrupted)
terminating The job has been cancelled by a CancelJob
request or aborted by the server and is in
the process of terminating. The job's job-
state-reasons attribute contains the
reasons that the job is being terminated.
(id-val-job-state-terminating)
retained The job is being retained at the server as
a result of the job's job-retention-period
being non-zero. The job has (1) completed
successfully or with warnings or errors,
(2) been aborted while [processing] printing
by the server, or (3) been cancelled by the
CancelJob request before or during
processing. The job's job-state-reasons
attribute contains the reasons that the job
has been retained.
While in the retained state, all of the
job's document data (and resources, if any)
shall be retained by the server; thus a job
in the retained state [could be resubmitted
using the Resubmit request in ISO DPA
Part 3.]. ResubmitJob shall create a new job
object instance and assign a new
job-identifier. See the Xerox Job Model spec.
(id-val-job-state-retained)
completed The job has either:
(1) completed successfully or with
warnings or errors,
(2) been aborted by the server while
processing, or
(3) been cancelled by the CancelJob
request,
AND the job's:
(1) job-retention-period was zero or
has expired, or
(2) job-discard-time has arrived.
OR a ResubmitJob operation has been issued
which forces the old job to the completed
state and makes a new job object instance
with a new job identifier. See the Xerox
Job Model specification.
The job's job-state-reasons attribute
contains the reason(s) that the job has
been completed.
While in the completed state, a job's
document data (and resources if any) need
not be retained by the server; thus a job
in the completed state could not be
resubmitted. The length of time that a job
may be in this state, before transitioning
to unknown, is implementation-dependent.
However, servers that implement the
completed job-state shall retain, as a
minimum, the following attributes for any
job in the completed state: job-identifier,
job-owner, job-name, current-job-state,
devices-assigned, and job-state-reasons, plus
as a Xerox extension, the accounting
attributes:
xcmJobAccountingUserName,
xcmJobAccountingInformation,
xcmJobStartedProcessingTime,
xcmJobImpressionsCompleted,
xcmJobMediaSheetsCompleted,
xcmJobCompletionTime, xcmJobWorkUnitType
XcmHrDevTrafficUnit,
and xcmJobUnitsOfWorkCompleted
so that an accounting management application
can copy the accounting data from the MIB
before the job is deleted from the MIB.
Jobs that have been moved to the OPTIONAL
'Job History' device SHALL be in the
'completed' state (or 'aborted' or 'canceled'
states with the PWG Job Mon MIB).
(id-val-job-state-completed)
This is a type 2 enum. |
