I'm having a problem with requests for specific notes selected from
my INDEX shipments, namely, the request job exceeds the CPU limit half
the time (and I get just a failure report back).  The way I send the
requests is to reply to the INDEX mail, including the text of the INDEX,
and then deleting the entries for the messages I don't want to read.
The list in question (ROOTS-L on NDSUVM1) closes out a digest/index when
the total length of messages hits 1000 lines, so it isn't as if I were
getting any really huge files this way.  Besides, my fingers sometimes
slip and send in the request before deleting the unwanted entries, but
such a mistaken request has *never* run out of time!  The only failures
seem to be "short" requests for (typically) 7-10 messages out of
(typically) 20-30 available.
 
Questions:
 
1) Is there an unpredictable component in the CPU time due to system
   load, such that there is no "fix" for this problem?
2) Is there a less CPU-intensive method of requesting messages, such
   as the "/ship" command?
3) Does the fact that I habitually strip out the blank lines between
   entries add to the CPU burden in any way?
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?  Or does it just mean that LISTSERV truncates the
   output after the minimum information necessary to identify the
   job?
 
                                     John