Subject: Re: JMP> serviceOffline

From: JK Martin <[email-masked]>
Date: Fri, 22 Aug 1997 12:21:29 -0400 (EDT)

Declaring serviceOffline as a mandatory reason is very appropriate, IMHO.

While I always despise the word "offline", there's just no getting away
from it.  :-(  So, we should probably be consistent (rather than accurate)
and continue this trend in nomenclature.

Let's go for it.  Thanks for discovering this situation, Harry.

	...jay

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

>From [email-masked] Fri Aug 22 12:15 EDT 1997
From: Harry Lewis <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: JMP> serviceOffline
Date: Fri, 22 Aug 1997 12:16:45 -0400

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

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

---

From: [email-masked]
Date: 25 Aug 97 11:51:49 EDT

Harry,

I personally think that deviceStopped is sufficient to cover all printer 
stoppage conditions including off-line.  So I don't think it is necessary to 
move serviceOffline.  Also, if serviceOffline means that the printer is 
off-line, it is well disguised in the DPA-ish description which I put for 
reference below.

serviceOffline
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.

Stuart

--------------------------------------------------------------------- 
Stuart Rowley                              Kyocera Electronics, Inc. 
Network Product Development Mgr.           3675 Mt. Diablo Blvd. #105 
[email-masked]        Lafayette, CA 94549
510 299-7206                               Fax: 510 299-2489 
---------------------------------------------------------------------

______________________________ Reply Separator _________________________________
Subject: JMP> serviceOffline
Author:  INTERNET:[email-masked] at CSERVE
Date:    8/22/97 12:15 PM

     

     
Thanks.

---

From: [email-masked]
Date: Mon, 25 Aug 1997 11:51:47 -0400

Harry,

serviceOffline

Stuart

     

     
     
Thanks.

---

From: [email-masked]
Date: Mon, 25 Aug 1997 11:51:47 -0400

Harry,

serviceOffline

Stuart

     

     
     
Thanks.

---

From: Tom Hastings <[email-masked]>
Date: Tue, 26 Aug 1997 13:18:24 PDT

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