Subject: JMP> Job States and State Reasons

From: Harry Lewis <[email-masked]>
Date: Mon, 17 Mar 1997 19:18:07 -0500

Classification:
Prologue:
Epilogue: Harry Lewis - IBM Printing Systems

I've stated before, but perhaps not strongly enough, that I think job state and
job state reasons should be combined into one OID in the job MIB. It must be
that DPA defined it as two, I guess that's what is driving the spec today. But,
try and implement this in an embedded controller. There you are wasting 4 bytes
times every entry in your State table. If you are designing for persistent data
(across polling cycles, not with NVRAM) in the printer, you want as many
entries as possible in the table.

Is anyone else designing for embedded controller who shares my opinion strongly
enough to make a comment? Anyone who feels the job MIB, in general, is too
cumbersome for embedded controllers?

Harry Lewis - IBM Printing Systems

---

From: Tom Hastings <[email-masked]>
Date: Mon, 17 Mar 1997 18:14:05 PST

The reason for two separate objects, is that the job states can't be
added to without breaking application software.  If PWG registers
more states, such software will get some new state that it doesn't understand.
The idea is that the application software is likely to do something
based on a state, but is NOT likely to do anything based on a job-state-reason.
Only the human is interested in the job-state-reasons.

The job-state-reasons are extensible, since they aren't really new states, 
but are additional information or sub-states. If an application gets a
job-state-reason that it doesn't understand, it not a big problem.

For an embedded controller without much memory, why not leave out most
of the job-state-reasons?  Perhaps only the completion with errors or
success?

WE could make jmJobState a type 1 enum, instead of a type 2 enum,
to reflect this strategy?

This is the same strategy that we are taking in IPP as well where the
job and printer states are type 1 enums.

Tom

---

From: Harry Lewis <[email-masked]>
Date: Mon, 17 Mar 1997 23:43:39 -0500

Classification:
Prologue:

Doesn't seem like it would take too much of a filter to the existing
application to convert the enum values back into pairs, if that's what's needed
at that end.

Reducing the number of job states called out or changing them to type-2 enums
is not the issue. My concern is number of OIDs.
--- Forwarded by Harry Lewis/Boulder/IBM on 03/17/97 09:33 PM --

        [email-masked]
        03/17/97 07:17 PM

To: Harry Lewis/Boulder/IBM@IBMUS
cc: [email-masked]@internet
Subject: Re: JMP> Job States and State Reasons

Tom