On Thu, 2 Jun 1994 16:01:00 EDT "John F. Chandler" <[log in to unmask]>
said:
 
>1) Is there an unpredictable component in the CPU time due to system
>   load, such that there is no "fix" for this problem?
 
In theory, yes. New messages are indexed before the search starts. But in
practice, you  can't have  more than  a couple dozen  at most.  Unless of
course the list  owner routinely updates the archive  files, which resets
the index. But that would create problems for INDEX subscribers anyway.
 
>2) Is there a less CPU-intensive method of requesting messages, such
>   as the "/ship" command?
 
Hardly... These are just variants on submitting a database job.
 
>3) Does the fact that I habitually strip out the blank lines between
>   entries add to the CPU burden in any way?
 
The code  that converts your request  into a concrete series  of database
instructions is very  fast, and it isn't timed anyway  (the database code
starts its own timer when it begins).
 
>4) Does the fact that failure reports always break off after the
>   separator line for the first requested message mean that the
>   failure always occur while LISTSERV is extracting that first
>   message?
 
It suggests  that the  index was  reset, and  that this  left no  time to
retrieve the first message (indexing cannot be interrupted).
 
In principle the  only way you can burn  a lot of cycles is  if the index
was reset (and  the list is large),  or then if you request  a very large
amount of  items. The search  is more like a  selection - you  supply the
item numbers directly,  so the database is not really  searched. The code
that formats  the output  is in  REXX, but if  you're retrieving  a dozen
messages or so, it should complete in  a few seconds. The only thing that
can really eat up a lot of cycles is an index build from scratch.
 
But, in  principle, the index shouldn't  get reset unless the  list owner
does a DATABASE REFRESH or updates one of the archive files.
 
  Eric