Subject: JMP> JMP FAQ?

From: Harry Lewis <[email-masked]>
Date: Tue, 8 Jul 1997 16:38:19 -0400

The Job MIB is tending to be fairly "open" with respect to mandatory
attributes and jobStateReasons. We've struggled with how this may effect
interoperability.

Following is an example we've run into that illustrates the problem:

Consider a print job that gets canceled by the user (of course, with
our trusty camers - ONLY - we have no idea HOW the job got canceled;-).
Consider the two main applications monitoring via the Job MIB, 1) the
End User job monitor; and 2) the accounting application.

We feel the end user, in this situation, wants relatively instant feedback
that the job state has changed to CANCELED. But, cancel is a completion
state. We envision the accounting application waiting for jobs to be
complete then "harvesting" FINAL STATE attribute information.

Problem... there is some "intertia" in the print system. If the agent changes
state to CANCEL as soon as it becomes aware of the cancel command (to
satisfy the end user), there may still be a page or two in the pipeline
that the accounting application would miss if it noticed the state change
and performed it's data collection.

So, we suggest using jobStateReasons in this case.

CANCEL - processingToStopPoint

   which progresses to

CANCEL - jobCanceledByUser

The question is, since these jobStateReasons are not "mandatory", how do we
communicate and agree on this recommendation? In other words, how do we
achieve interoperability?

I am suggesting a FAQ. I would like your comments on how effective you feel
this might be. If a FAQ is not effective, then, should be we deciding on more
mandatory attributes? I don't really want to pursue this path unless it is
absolutely necessary, because I feel we've been there... and it's UGLY!

>>> Harry Lewis <<<

---

From: JK Martin <[email-masked]>
Date: Tue, 8 Jul 1997 19:11:26 -0400 (EDT)

You know what's needed here?  None other than an equivalent of the
Printer MIB's "Top 25 Conditions" summary table.

That is, the JMP folks get together and devise the top-most set of
job-related scenarios, then determine the values for the relevant
Job MIB objects.

What say ye?

	...jay

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

>From [email-masked] Tue Jul  8 16:37 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Subject: JMP> JMP FAQ?
Date: Tue, 8 Jul 1997 16:38:19 -0400

   which progresses to

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

---

From: Harry Lewis <[email-masked]>
Date: Tue, 8 Jul 1997 22:49:29 -0400

Agreed, as long as it doesn't open the MIB for re-design! But a top 25
list of uses, based on the current MIB, would be an excellent idea.

Harry Lewis - IBM Printing Systems

-------- Forwarded by Harry Lewis/Boulder/IBM on 07/08/97 08:46 PM ---------

        [email-masked]
        07/08/97 05:56 PM
Please respond to [email-masked] @ internet

To: Harry Lewis/Boulder/IBM@IBMUS
cc: [email-masked] @ internet
Subject: Re: JMP> JMP FAQ?

What say ye?

 ...jay

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

   which progresses to

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

---

From: [email-masked]
Date: Wed, 9 Jul 1997 07:27:39 -0400

I agree with Jay that I think a list of "Top 25 Job Conditions"
would be the best way of handling the ambiguity of how to
report various job states.
Lloyd Young