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