Well, I guess I can easily provide a new return code for FAV exits in the GET case, which means "save up the request until hh". Then I just add a procedure to the WAKEPARM FILE, which gets called every hours, and re-issues GET commands. Note that this would re-invoke the FAV exit (which might have other processing to perform on the file besides queueing it out), and it should therefore be consistent with itself and not keep postponing files for the next hour :-) That was one solution. Another less general one would be for the FAV to say "ok, postpone until hh but then you don't need to call me again. Just batch all the recipients together and send 'as is'". Then I can use DISTRIBUTE for the batch. But I don't like it, it's too specific I think. A last possibility is to postpone the requests, and then issue a special form of GET command (available only internally from LISTSERV) which specifies a list of recipients instead of just one. With that special call, the FAV gets control with a new request type (eg GETLIST0) and decides whether it can accept such calls or not. If it says "ok, go on", it will get called with the standard "GET1" and "GET2" request types being changed to "GETLIST1" and "GETLIST2" (so that it gets a chance to add info to the file), but the stuff will eventually be batched into a DISTRIBUTE job. This will work for all FAVs that don't perform any action that depends on the userid@node, or rather, that don't change the contents of the file being sent depending on the userid@node of the requestor. If this is not the case, the FAV simply rejects the "GETLIST0" call, and the GET processor merely converts the call into a series of individual GET for a single recipient which can be processed just as a regular GET command. Which solution do you prefer? Does the GETLIST stuff seem to complicated? I'd like to provide something general if at all possible -- Kermit is not our only application... Eric