XcmJMJobState

• Base type Enumeration

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.