Harry,
If you've found it useful, we should move the reason
to the jmJobStateReason1 object.
The current spec is:
serviceOffLine 0x400000
The service/document transform is off-line and accepting no jobs. All
pending jobs are put into the pendingHeld state. This could be true if
its input is impaired or broken.
Is the description what you want? So the 'serviceOffLine' reason bit is set
for each job that has not yet completed in the service or device? So
the bit gets set for each job that is: 'pending', 'pendingHeld', 'processing',
or 'procesingStopped'. And the pending jobs are moved to pendingHeld?
Thanks,
Tom
At 09:16 08/22/97 PDT, Harry Lewis wrote:
>BACKGROUND -- In Redmond, we moved processingToStopPoint from job state reasons
>2 to job state reasons 1 as we agreed to use this reason to distinguish a
>CANCEL state where sheets might still be cleared from the paper path from a
>CANCEL operation that has completed.
>>PROBLEM -- In prototyping, we find one other job state reason which we feel is
>useful enough to be migrated into the (mandatory) job state reasons 1 category.
>This reason is serviceOffLine.
>>CLARIFICATION -- First, I am seeking agreement from the JMP that using job
>state reason serviceOffLine is valid when the printer is off-line. (I know...
>we usually get really tied up whenever the word off-line is used in
>conversation). If so, do you agree that Off-line is a common, likely or
>significant enough condition to warrant becoming part of the "reasons 1" group.
>>PROPOSAL -- I'd like to propose this simple change be added to Tom's pending
>draft, if possible, so I'm asking for discussion and straw poll (assuming the
>Chair deems this appropriate).
>>Thanks.
>>Harry Lewis - IBM Printing Systems
>>