You are absolutely correct. As a matter of fact, we had one customer
who actually had Sun "enhance" LPD so that the 1000 job limit could be
overcome, as many of their Unix-based print queues were receiving jobs
faster than they could process them...and hence, rolled past the limit
of 1000 simultaneous jobs (ie, job IDs between 0 and 999).
Why exactly would a mgmt app need to know the roll-over point for the
job index, anyway? Can someone explain why this is necessary and/or
desirable?
...jay
----- Begin Included Message -----
From: Harry Lewis <harryl@us.ibm.com>
To: <jmp@pwg.org>
Cc: <LMORGAN@BLDVMB.vnet.ibm.com>
Subject: JMP> Max number of jobs
Date: Tue, 1 Apr 1997 12:05:39 -0500
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.
----- End Included Message -----