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

From: Harry Lewis <[email-masked]>
Date: Thu, 20 Nov 1997 11:21:07 -0500

So much for working late to try and catch the early worm. My server crunched
this mail last night. Sorry... here it is.

Harry Lewis - IBM Printing Systems

---------------------- Forwarded by Harry Lewis/Boulder/IBM on 11/20/97 09:08 AM
 ---------------------------

Harry Lewis
11/19/97 10:23 PM
To: [email-masked] @ Internet
cc:
From: Harry Lewis/Boulder/IBM @ IBMUS
Subject: Re: JMP> Job MIB doesn't handle Uncollated Copies

There hasn't been a whole lot of discussion regarding my proposal (below) other
than Ron indicating he believes it should be accepted.

I would like to modify it slightly, in a manner which I believe better
accomplishes the goal of distinguishing between collated and uncollated copies
yet results in fewer changes to the Mib.

To put it as simply as I can, I propose to add

currentCopyNumber
currentDocumentNumber
copyType

and to keep

sheetsCompletedCurrentCopy
impressionsCompletedCurrentCopy
documentCopiesCompleted
jobCopiesCompleted

The example flows the same as before:

For a 3 impression job with a request for 3 copies.

Uncollated 3/3  (copyType = External Collation)
--------------

sheetsCompleted    sheetsCompletedCurrentCopy    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    sheetsCompletedCurrentCopy    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 reason for the change from currentSheetNumber and currentImpressonNumber is
that there may be several sheets in the paper path, (different) impressions may
be ripping and printing at the same time etc. It's very hard to say which is
the "currentImpression" or "currentSheet" but easier to say which is the
current copy. It is easy to say which sheet has just completed (stacked).

Note that, while drivers should protect from this, it is theoretically possible
to mix collated and uncollated copies (try it with your favorite printer...
it's fun!). At this point, attributes like current copy really break down. We
feel, rather then try and define even more attributes to handle this
pathological case we should just say behavior of the MIB, at this point, is
device specific.

Harry Lewis - IBM Printing Systems

[email-masked] on 11/14/97 11:31:38 PM
To: [email-masked]
cc: [email-masked], [email-masked], [email-masked],
[email-masked]
Subject: JMP> Job MIB doesn't handle Uncollated Copies

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