Subject: Re: JMP> Max number of jobs [Second part of Issue 49]

From: Tom Hastings <[email-masked]>
Date: Tue, 1 Apr 1997 13:24:23 PST

Harry,

Convincing that we need to keep jmGeneralMaxNumberOfJobs as it is
independent of the wrap point.

So do we also need to add an object, say, jmGeneralMaxJobIndex,
for the wrap point as my second question in the issue asks?  
For example, BSD LPR/LPD wraps at 999 back to 0.

That question will be the only part of Issue 49 unresolved.

Thanks,
Tom

At 09:05 04/01/97 PST, Harry Lewis wrote:
>Classification:
>Prologue:
>Epilogue: Harry Lewis - IBM Printing Systems
>
>In my view, max number of jobs *cannot* be defined as the wrap point for
>jmJobIndex!
>
>>Issue 49 - Should we change the definition of the jmGeneralMaxNumberOfJobs
>>to jmGeneralMaxJobIndex meaning the maximum value that the jmJobIndex object
>>can have and the roll over to 1 happens for the next job received?  Or add
>>jmGeneralMaxJobIndex as another object in the General table?  Then the
>>monitoring application would know what the roll over limit would be.  For
>>agents that instrument servers or printers that use a job identifier of 0,
>>the actual maximum number would be one more than the actual job identifier
>>that the server or printer generates.  So for LPD, the value of
>>jmGeneralMaxJobIndex would by 1000, not 999.
>
>The jmJobIndex is a large integer specifically to prevent identical ID's from
>existing within any reasonable time window. If a printer can only hold
>information about (say) 20 jobs and it wraps at 21, then there is a chance that
>two different jobs may appear to have the same ID (1). A wrap at the max value
>of a vary large integer will prevent this from occurring.
>
>My opinion.
>
>

---

From: Harry Lewis <[email-masked]>
Date: Wed, 2 Apr 1997 01:05:10 -0500

Classification:
Prologue:

>For example, BSD LPR/LPD wraps at 999 back to 0.

What does the fact that BSD LPR/LPD wraps at 999 have to do with
the wrap point of jmJobIndex (that *is* what we're talking about,
isn't it?). I'm missing your point.

>From the best I can tell jmGeneralMaxNumberOfJobs actually has
little value, especially if we also have another object representing
how long a job entry will remain in the table (in seconds). I assume
some applications will use jmGeneralMaxNumberOfJobs for storage
allocation, but this assumes a rather static approach by this
application.

Can someone shed more light on who will use this object, how and
why?

Tom, maybe you can help me out with the BSD slant.

Harry Lewis