JMP Mail Archive: JMP> Re: Job MIB doesn't handle Uncollated Copies

JMP> Re: Job MIB doesn't handle Uncollated Copies

Ron Bergman (rbergma@mailgate.dpc.com)
Tue, 18 Nov 1997 08:22:00 -0800 (Pacific Standard Time)

Harry,

I do believe that Tom's proposed change solves the issue that you
presented. Since this looks like an easy change to incorporate, I
proposed that this be accepted.

Ron Bergman
Dataproducts Corp.

On Sat, 15 Nov 1997, Harry Lewis wrote:

> This message could be long - suffice it to say that I hope this news will be
> received in the spirit of an "early warning" interoperability issue.
>
> The issue lies with the following Job MIB attributes:
>
> |sheetsCompletedCurrentCopy(152)
> |impressionsCompletedCurrentCopy attributes(113)
> |documentCopiesCompleted(93)
> |jobCopiesCompleted(91)
>
> The problem is that these attributes can accurately reflect a "Mopy"
> or internal collation, but are inadequate if used to describe
> uncollated copies (or externally collated... such as use of
> sequential output bins).
>
> With "Internal Collation", one copy is "worked on" at a time. That copy
> is finished (jobCopiesCompleted) and the next is started, resetting
> "sheetsCompletedCurrentCopy"
>
> With "External Collation" (uncollated) multiple copies are "worked on"
> before any copy is completed. Thus, "sheetsCompletedCurrentCopy" has
> no meaning and "jobCopiesCompleted" jumps from initial to final value
> in one increment (not very useful).
>
> One possible reaction to the realization is to catagorize "External
> Collation" as uninteresting, or just a "larger" job. (I had this
> tendancy, initially). But, recall, IPP supports collated and
> uncollated copies. Also, as mentioned above, the uncollated case is
> the same (to the Job MIB agent) as sorting into multiple outputs.
>
> I have discussed this problem, at length, with my development team and
> also consulted with Tom Hastings (editor), briefly. Tom was receptive
> and helpful and contributed to the following proposal:
>
> Add the following attributes
> ---
> currentSheetNumber
> currentImpressionNumber
> currentCopyNumber
> currentDocumentNumber
>
> Replace these "completed" attributes with their new "current" counterparts
> -------
> sheetsCompletedCurrentCopy(152)
> impressionsCompletedCurrentCopy attributes(113)
>
> Decide whether or not to Keep these "completed" attributes
> ----
> documentCopiesCompleted(93)
> jobCopiesCompleted(91)
>
> for accounting purposes. Note, the "completed" values ONLY make
> sense for collated copies and/or FINAL values on uncollated jobs.
> For this reason, we recommend adding a final additional attribute
> ---
> copyType (ENUM - Internal Collation
> External Collation)
>
> The value of the currentXxx attributes is 0 while the job is
> PENDING. The values increment to 1 as the first impression is
> produced. An abbreviated example (sheets and jobs, only) should
> help visualize. For example, assume a 3 impression job with a
> request for 3 copies.
>
> Uncollated 3/3 (copyType = External Collation)
> --------------
>
> sheetsCompleted currentSheetNumber currentCopyNumber
> --------------- ------------------ -----------------
> 1 1 1
> 2 1 2
> 3 1 3
> 4 2 1
> 5 2 2
> 6 2 3
> 7 3 1
> 8 3 2
> 9 3 3
>
>
> Collated 3/3 (copyType = Internal Collation)
> ------------
>
> sheetsCompleted currentSheetNumber currentCopyNumber
> --------------- ------------------ -----------------
> 1 1 1
> 2 2 1
> 3 3 1
> 4 1 2
> 5 2 2
> 6 3 2
> 7 1 3
> 8 2 3
> 9 3 3
>
> The issue of whether or not to keep attributes
>
> documentCopiesCompleted(93)
> jobCopiesCompleted(91)
>
> could be resolved by specifying that the final value of
>
> currentCopyNumber
> currentDocumentNumber
>
> *is* the completed value and the attribute maintains this value
> for the remainig life of the entry.
>
> I did not show an example using currentDocumentNumber because this
> is for high end implementations that collate documents within jobs.
> Nonetheless, the same problem (solution) exists.
>
> Harry Lewis
>