On 5/3/2007 12:31, Pete Weiss wrote: > At 12:03 5/3/2007 Thursday, Paul Russell wrote: > >> We made no attempt to retrofit this change to all existing lists. Instead, >> we update the lists one at a time, when Help Desk staff members notify us >> that they are unable to access a given list. > > Would it not make sense for those emulating this solution to slightly expand it so that it used the IMBED KEYWORD directive? > > .IK filename > > where the filename (in this case) contained > > .HH ON > OWNER= (hd_owners_list) > .HH OFF > > and possibly other keywords over time > > /Pete > As I see it, every list header has to be touched anyway, so it does not make much difference whether you add an Owner= statement or a .IK directive. Can the list owner remove a .IK directive? If not, then putting the Owner= statement in an embedded keyword file would prevent the list owner from removing that statement. Some sites may perceive this as A Good Thing; others might not. I like the concept of embedded keyword files, but the lack of a method to force LISTSERV to flush cached files tends to reduce its usefulness. If you update an embedded keyword file, the change will not be reflected in lists whose headers are cached until LISTSERV refreshes the cached copy of the header for every affected list. You can force LISTSERV to refresh the cached copy of the header for a single list by doing a PUT, however, I have a philosophical problem with doing a PUT when I am not actually making a change to the list header. The only way to force LISTSERV to refresh all cached list headers is to shutdown and restart the service. I have a major philosophical problem with unnecessary outages. L-Soft needs to provide a direct method to force LISTSERV to flush cached files. Ideally, this method should support the use of wildcards, so it could be used to flush a single cached file, or all cached files which match the specified pattern, up to and including, all cached files. -- Paul Russell, Senior Systems Administrator OIT Messaging Services Team University of Notre Dame [log in to unmask]