The idea in Austin, was that the jmGeneralLowestActiveIndex (or
jmGeneralSmallestActiveIndex for those whose memory grows upward),
pointed to the smallest job index that was active. When wrap occurs,
the agent sets that value back to 1, where the agent puts the newest
job arrival when a wrap occurs. In any case, the management app scans
the job table starting with this value looking for active jobs. When it
has found the number of active jobs indicated by jmGeneralNumberOfActiveJobs,
the management app knows it can stop looking. So during a wrap condition
where some active jobs are at the small end of the table and some are
at the large end of the table, our management app has to scan all the
intervening (completed) jobs in order to find all the active jobs.
With the new proposal, the management app always starts with the oldest
job, even during the wrap condition. The agents job is somewhat harder,
for the case of processing job out of order, in that when a job completes,
the agent has to scan backward (newer to older) down the table (and
possibly reverse wrap) to find the newest still active job. But that isn't
too difficult.
I still think that we should keep jmGeneralNumberOfActiveJobs, since it
provides a quick way to find out how busy a printer is.
I'll edit in this new proposal, unless I hear disagreement.
Ok?
Thanks,
Tom
At 13:08 04/10/97 PDT, STUART at kei-ca.ccmail.compuserve.com wrote:
>On 4/9/97 at 8:15 PM, Harry Lewis said ...
>>There was quite a bit of discussion upon adding this to the jmGeneral table
>last week in Austin. After reviewing back here, we still don't see how this
>value serves it's purpose. Does someone have a write-up of exactly what this
>object is supposed to do?
>>We feel another object is also required... basically something like
>jmGeneralHighestActiveIndex otherwise it is very difficult to avoid walking
the
>whole table.
>>We feel that these should be named
>> jmGeneralOldestActiveIndex
> jmGeneralNewestActiveIndex
>>this helps get around the wrap problem.
>>Using these two objects, an application should be about to determine where to
>start in the table (Oldest) and where to stop (Newest) and should also know
>there will be a wrap if Newest is a smaller number than oldest.
>>SWR>> I think you are right. jmGeneralLeastActiveIndex tells where to start
>scanning the table, but not where to stop. I am in favor of this change, and
>I think the names Oldest and Newest are an improvement.
>>Stuart
>>>>