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