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