Subject: Re: JMP> jmGeneralLeastActiveIndex

From: [email-masked]
Date: 10 Apr 97 16:08:19 EDT

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

---

From: Tom Hastings <[email-masked]>
Date: Fri, 11 Apr 1997 02:07:26 PDT

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