Subject: JMP> Re: IPP> MOD JobState suggestion

From: Harry Lewis <[email-masked]>
Date: Mon, 2 Jun 1997 18:07:54 -0400

I am confused by the notation used in this discussion:

>The states are:

> pending
> pending-stopped
> processing
> processing-stopped
> done-aborted
> done-canceled
> done-completed

>I suggest changing the last three states to

>  completed
>  completed-canceled
>  completed-abort

I understand PENDING, PROCESSING and COMPLETED states. I thought I was
following a thread, somewhere, that PENDING-STOPPED was another way to say HELD
and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this what is
going on... just some renaming? Or do the "dashes" in these names indicate
separation between a state and a reason?

I agree with Bob's recommendations, above, to stick with Completed rather than
Done. Why change? And, for that matter, why not keep HELD and NEEDS ATTENTION?
What are we gaining. I find these discussions frequently go down the "generic
language" path until the labels we choose are so vague that, rather than risk
misinterpretation, the names end up meaning very little at all.

Harry Lewis

---

From: JK Martin <[email-masked]>
Date: Mon, 2 Jun 1997 18:13:34 -0400 (EDT)

We took a very simple 3-state queue mechanism (waiting,working,done),
then artificially elevated a few well-known substates to "full state"
values to make some folks happy.

This was done during the last IPP telecon, last Wednesday.

	...jay

----- Begin Included Message -----

>From [email-masked] Mon Jun  2 18:07 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: JMP> Re: IPP> MOD JobState suggestion
Date: Mon, 2 Jun 1997 18:07:54 -0400

Harry Lewis

----- End Included Message -----

---

From: [email-masked] (Robert Herriot)
Date: Mon, 2 Jun 1997 15:23:22 -0700

In one sense we have just renamed some states: held to pending-stopped
and needs-attention to processing-stopped.  But the renaming regularizes
the names to give the impression that there are 3 high level states
of pending, processing and completed and 4 additional variant of those
states.  These regularized states allow us to have other attributes
that draw from these names, e.g. time-since-pending time-since-processing
and time-since-completed. It also allows the addition of other states,
such as completed-with-errors.

Bob Herriot

> From [email-masked] Mon Jun  2 15:09:05 1997
>

---

From: JK Martin <[email-masked]>
Date: Mon, 2 Jun 1997 18:35:54 -0400 (EDT)

I guess I'm a bit disappointed that we elected to not do the "elegant"
thing and simply have 3 states (pending, processing, done), then use
a set defined of substates to describe refinements of those states.

A rare chance to do something that is both elegant *and* simple.
(Sigh...)

	...jay

----- Begin Included Message -----

>From [email-masked] Mon Jun  2 18:28 EDT 1997
Date: Mon, 2 Jun 1997 15:23:22 -0700
From: [email-masked] (Robert Herriot)
To: [email-masked], [email-masked]
Subject: Re: JMP> Re: IPP> MOD JobState suggestion
Cc: [email-masked]

Bob Herriot

----- End Included Message -----

---

From: Harry Lewis <[email-masked]>
Date: Tue, 3 Jun 1997 10:24:55 -0400

Thank you Jay! I agree!

Harry Lewis - IBM Printing Systems

------ Forwarded by Harry Lewis/Boulder/IBM on 06/03/97 08:18 AM ------

        [email-masked]
        06/02/97 06:39 PM
Please respond to [email-masked] @ internet

To: [email-masked] @ internet
cc: [email-masked] @ internet, [email-masked] @ internet
Subject: Re: JMP> Re: IPP> MOD JobState suggestion

 ...jay

----- Begin Included Message -----

Bob Herriot

> following a thread, somewhere, that PENDING-STOPPED was another way to say
HELD > and PROCESSING-STOPPED was another way to say NEEDS ATTENTION. Is this
what is > going on... just some renaming? Or do the "dashes" in these names
indicate > separation between a state and a reason? > > I agree with Bob's
recommendations, above, to stick with Completed rather than > Done. Why change?
And, for that matter, why not keep HELD and NEEDS ATTENTION? > What are we
gaining. I find these discussions frequently go down the "generic > language"
path until the labels we choose are so vague that, rather than risk >
misinterpretation, the names end up meaning very little at all. > > Harry Lewis

----- End Included Message -----

---

From: Tom Hastings <[email-masked]>
Date: Wed, 4 Jun 1997 05:53:35 PDT

At 15:07 06/02/97 PDT, Harry Lewis wrote:

snip...

>misinterpretation, the names end up meaning very little at all.

I agree with Harry that we should reconsider the name change
from 'held' to 'pending-stopped' and go back to 'held'.

In looking at the complete spec for job-state and job-state-reasons in IPP
and the corresponding jmJobState and jmJobStateReason1 objects in JMP,
I discovered a problem with our renaming of 'held' to 'pending-stopped':

I've added the following joint IPP/JMP issue to the joint spec:

JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of
'pending-stopped'?

The IPP protocol has a "job-hold-until", so having the name of the state be
'held' aligns with that name better making it clearer to the user the
relationship between the attribute and the state.  Also some current systems
have a 'held' state, so that current practice for system that have such as
state is to call that state 'held'.  Also the ISO DPA has a 'held' state.
Finally, our sub-classing in the names doesn't work for 'completed', since
we have 'aborted' and 'canceled', not 'completed-aborted' and
'completed-canceled', so why have it for pending-stopped, which may prove
fairly startling to a user, while 'held' is readily understandable.

I think that 'processing-stopped' is fine and is clear that it is a 
sub-state of processing, so I'm not suggesting that we re-open the
'processing-stopped' name change.

Comments?

Tom

---

From: Tom Hastings <[email-masked]>
Date: Wed, 4 Jun 1997 05:53:28 PDT

Gee Jay,

You want to add another attribute to IPP: job-sub-state
and another object to the JMP jmJobTable: jmJobSubState?

This doesn't sound like simplicity and elegance to me.

Instead, we've shown the "refinement" of these substates, in the
names of the states and not added any more attributes or objects.

That seems like the best of both worlds, namely show the refinement
but keep the attributes and object simple.

Or did you mean to add the sub-states as job-state-reasons which
wouldn't add anymore attributes to IPP and objects to JMP?

Tom

---

From: Harry Lewis <[email-masked]>
Date: Wed, 4 Jun 1997 10:09:15 -0400

Tom, I support your proposal -

>JOINT IPP/JMP ISSUE - Should we go back to the name 'held', instead of

Not only for the many good reasons you listed but simply due to the reduced
brain-strain. HELD... I can relate to. But what exactly happens when pending
stops? It's obvious, by most of my notes, that I'm not much of a comedian, but
I can picture one having fun with some of these genericized brain teasers.

>'processing-stopped' name change.

I guess processing-stopped is about as clear as needs-attention (I think
this was the old name in JMP). No big problem with the name. I'm not sure
I really understand your use of the term "sub-state", however. Are you
referring to a JobStateReason or are you thinking of a job transition
diagram? I THINK you are talking about job transition flow and
processing-stopped is really a STATE, not a REASON. I don't think stopped is
a very good reason to be processing.

Harry

---

From: Tom Hastings <[email-masked]>
Date: Wed, 4 Jun 1997 09:34:42 PDT

>a very good reason to be processing.

I definitely meant that the 'processing-stopped' state is a separate state that
a job gets to from the 'processing' and returns to 'processing' state.

Here's the picture in the joint IPP/JMP jobstate.pdf file that I posted
for today's IPP telecon:

The following JMP figure shows the normal job state transitions:

                                                +--> canceled(7)
                                               /
    +---> pending(3) -------> processing(5) --+----> aborted(8)
    |        ^                    ^            \
--->+        |                    |             +--> completed(9)
    |        v                    v
    +---> pending-stopped(4)  processing-stopped(6)

           <------------- active ------------>|<-- in-active -->|

         Figure 3 - Normal job state transitions

Normally a job progresses only from left to right.  Other state transitions
are unlikely, but are not forbidden."

Changing the name from 'pending-stopped' to 'held' would yield:

The following figure shows the normal job state transitions:

                                                +--> canceled(7)
                                               /
    +---> pending(3) -------> processing(5) --+----> aborted(8)
    |        ^                    ^            \
--->+        |                    |             +--> completed(9)
    |        v                    v
    +---> held(4)        processing-stopped(6)

          <-------------- active ------------>|<-- in-active -->|

          Figure 3 - Normal job state transitions

Normally a job progresses only from left to right.  Other state transitions
are unlikely, but are not forbidden."

---

From: JK Martin <[email-masked]>
Date: Wed, 4 Jun 1997 14:13:30 -0400 (EDT)

[I hope this cross-posting ends soon... :-{ ]

Tom,

> are unlikely, but are not forbidden."

Are you really sure this diagram is accurate?

Say, for example, a job is in the "held" state.  An operator or user then
cancels the job.  According to your diagram, the job transits would then
manner:

        held -> pending
     pending -> processing
  processing -> canceled

The same kind of mess occurs with the "processing-stopped" state, etc.

This certainly must not be what you intend, right?

	...jay

---

From: JK Martin <[email-masked]>
Date: Wed, 4 Jun 1997 15:12:40 -0400 (EDT)

Tom,

> but keep the attributes and object simple.

Someday, once the dust finally settles on the JMP and IPP projects,
I'd be really interested in hearing your definitions and metrics
relating to "simplicity" and "elegance".

Unfortunately, the combined JMP/IPP dust is now swirling around at
around 50,000 feet...and is unlikely to settle soon.   ;-)

> wouldn't add anymore attributes to IPP and objects to JMP?

Yes, Tom, this is the only natural conclusion here.

Better yet, no need to wait until the dust settles to do this.  ;-)

The really sad situation here is that some folks want to model the job
problem/solution to achieve an extremely teenie-weenie minor performance
boost.  That is, to only get a single MIB object instead of two (either
of which can be done by a single SNMP Get message).

Sorry, but perhaps the "puritan" nature of my engineering side has
surfaced on this topic, and hence my resistance to this kind of
bastardization of the IPP/JMP job model in general.

A job can be in many, many kinds of "states", depending on the features
(and attendant complexities) of the underlying printing system.  However,
no matter what printing system is involved, all jobs will be in exactly
one of the three top-level "meta" states of pending, processing, done.

Below these three states, the mgmt application in question will decide
on the exact semantics of the job based on some *consistent* refinement
of the top-level state.  Hence, the simple two-level model I have been
suggesting this past week or so.

	...jay

---

From: Harry Lewis <[email-masked]>
Date: Wed, 4 Jun 1997 15:49:20 -0400

I think there is a problem with the state diagram

                                                +--> canceled(7)
                                               /
    +---> pending(3) ----> processing(5) -----+----> aborted(8)
    |        ^                    ^            \
--->+        |                    |             +--> completed(9)
    |        v                    |
    +---> held(4)    processing-stopped(6)

In that it does not show the ability to cancel a job from Held or
Needs-Attention (processing-stopped) states. It is also quite possible
that a job in Needs-Attention state would ultimately abort.

I recommend the following changes to the diagram...

                                                +--> canceled(7)
                                               /
    +---> pending(3) ----> processing(5) ---+-+----> aborted(8)
    |        ^                    ^         |  \
--->+        |                    |         |   +--> completed(9)
    |        v                    v         |
    +---> held(4)    processing-stopped(6)  |
             |                    |         |
             +--------------------+---------+

---

From: Harry Lewis <[email-masked]>
Date: Wed, 4 Jun 1997 17:05:15 -0400

I also want a small set of meaningful job states.

> ...jay

I tend to get very confused by the 3 separate terminology's however,
those being JobState, JobSubState and JobStateReason.

I believe there are actually 7 job states that deserve to be called
STATES. We should be welcome to embellish any state with as many (or as
FEW) REASONS as seen fit. Listed in my preferred terminology along with
the current IPP/JMP name-for-a-day in parenthesis, the 7 are:

Pending
Held (Pending-Held)
Printing (Processing)
Needs_Attention (Processing-Stopped)
Completed
Canceled (Completed-Canceled)
Aborted (Completed-Aborted)

Yes, the STRAIGHT LINE PATH from submission to marks on paper is
Pending-Printing-Complete, but other significant states are Held,
Needs_Attention, Canceled and Aborted. There are all kinds of reasons
(my favorite being printer-partly-stopped). I would like to suggest, however,
that if we adopt these 7 as the "high level" states then we can eliminate the
idea of "sub-state".

---

From: Tom Hastings <[email-masked]>
Date: Thu, 5 Jun 1997 08:39:02 PDT

I agree completely with Harry that we should have seven job states
for IPP and JMP.

I also happen to like the simpler single word names for the 7 states:

pending
held
processing
stopped
canceled
aborted
completed

My understanding from the 6/4 telecon is that the JMP jmJobState object
will remain in the MANDATORY jmJobTable and that we will use Ron's suggestion
for the conformance of the enums as:

 "All possible enums for this object must be reported if implemented and 
  available to the agent."

And then I agree with Harry that JMP implementations can use as many or as
few job-state-reasons to embellish these states.  My understanding of our
agreement yesterday (6/4 telecon) is that JMP will keep jmJobStateReasons1 
object MANDATORY, but not say anything about which enums are MANDATORY, 
which are CONDITIONALLY MANDATORY and which are OPTIONAL.  Correct?

Or should we include Ron's statement for JMP jmJobStateReasons1 object
as well?

IPP has job-state-reasons attribute as MANDATORY and has the following
job-state-reason values MANDATORY, CONDITIONALLY MANDATORY, and OPTIONAL: 

MAN  none
MAN  job-incoming
OPT  outgoing
COND job-hold-until-specified
OPT  job-hold-until-resources-are-ready
OPT  printer-stopped-partly
MAN  printer-stopped
OPT  job-printing
MAN-L2 job-canceled-by-user
MAN-L2 job-canceled-by-operator
OPT  logfile-pending
OPT  logfile-transferring
MAN  job-completed-successfully
MAN  job-completed-with-warnings
MAN  job-completed-with-errors

Tom

---

From: Tom Hastings <[email-masked]>
Date: Thu, 5 Jun 1997 08:38:48 PDT

Yes, you are correct that the canceled state can be entered from any
of the active states and could do so in this picture which is intended
to be the "normal" implementation.  

The weasle words around the figure
are important, because some systems have transitions from processing
to held (system backs a job out of processing due to a resource problem
and DPA InterruptJob operation), and from completed to pending (DPA Resubmit).
So the picture isn't intended to show all possible transitions, ok?

The weasil words are:

"The following figure shows the normal job state transitions:

... the diagram...

I could go back to the transtion table that I had originally, but
this diagram that Bob drew was so much simpler and more understandable,
except for the canceled bug that you point out.

Harry also pointed out that some implementations might abort from
the stopped state.

Running arrows from every state to canceled and from stopped to
aborted would look like this:

>>              +--------->----------+------>------+--> canceled(7)
>>              |                    |             |
>>     +---> pending(3) -------> processing(5) -------> completed(9)
>>     |        ^                    ^  \          |
>> --->+        |                    |   +------------> aborted(8)
>>     |        v                    v  /          |
>>     +---> held(4)             stopped(6)        |
                |                    |             |
                +--------->----------+------>------+
>>           <-------------- active ------------>|<-- in-active -->|

Ok for IPP and JMP (IPP would be without the enum numbers and without
the "active/in-active" which is termiology in JMP only.

Thanks,
Tom

>[I hope this cross-posting ends soon... :-{ ]

Me too, but we're getting consistency between IPP and JMP this way.

---

From: Harry Lewis <[email-masked]>
Date: Thu, 5 Jun 1997 12:57:33 -0400

I don't want to begin making the diagram too complex.

                |                    |             |

I only want to assure that the state diagram does not give the impression that,
to cancel or abort a job, the flow has to be back through processing.

>    +---> held(4)    processing-stopped(6)

What was wrong with my proposal?

>>>  Harry  <<<

---

From: Tom Hastings <[email-masked]>
Date: Thu, 5 Jun 1997 15:02:32 PDT

>>>     +---> held(4)             stopped(6)        |

It shows state transitions that are very unlikely:

held -> aborted
held -> completed
processing-stopped -> completed

and it doesn't show pending -> canceled

---

From: "Caruso,Angelo" <[email-masked]>
Date: Fri, 6 Jun 1997 11:14:34 PDT

Given the recent argument that HELD is more intuitive to the average 
 user than PENDING-STOPPED, isn't the original name NEEDS-ATTENTION 
 also more intuitive than STOPPED or PROCESSING-STOPPED? It certainly is to me.

I propose we go back to the original name NEEDS-ATTENTION. So, the 
 seven states would be:

pending
held
processing
needs-attention
canceled
aborted
completed

Thanks,
Angelo

----------
From: [email-masked]
To: [email-masked];  [email-masked]; Harry Lewis
Subject: Re: JMP> Re: IPP> MOD JobState suggestion
Date: Thursday, June 05, 1997 12:00AM

pending
held
processing
stopped
canceled
aborted
completed

MAN  none
MAN  job-incoming
OPT  outgoing

Tom

---

From: Harry Lewis <[email-masked]>
Date: Fri, 6 Jun 1997 15:43:04 -0400

Taking your revised diagram:

>     +---> pending(3) --------> processing(5) -----+----> completed(9)
>     |        ^                      ^              \
> --->+        |                      |               +--> aborted(8)
>     |        v                      v              /
>     +---> pendingHeld(4)   processingStopped(6) --+
>
>         <--------------- active -----------------> <--- in-active --->
>                 Figure 4 - Normal Job State Transitions
>

*and* the associated wording:

> are unlikely, but are not forbidden.  The canceled state can be entered from
> the pending, pendingHeld, processing, or processingStopped states."

together, I think they tell the story we're looking for.

I agree.

>>> Harry Lewis <<<