On 1/21/2010 08:37, [log in to unmask] wrote:
> Patrick wrote on 01/21/2010 03:30:23 AM:
>
>> The business case is that we are in the process of ending the service,
>> and we are considering doing that in several phases. One of the phases
>> might be 'stop adding new lists' and another phase might be 'stop adding
>> new subscribers'.
>
> Instead of "Stop adding new subscribers" make the step "no changes will be
> allowed to the list."
>
> Then make a copy of the list files.  On a nightly basis, stop Listserv,
> replace the active list files with copies and restart Listserv.
>
> If changes must be made to a list, update the copy of the list file so it
> will overwrite the active file.
>

This introduces unnecessary overhead and creates a situation in which legitimate
and necessary changes might be overwritten.

Presumably, the decision to end the service, and the steps in the process toward
that end, have been (or will be) communicated to all list owners.  Given that
context, the presumed intent should be to prevent inadvertent changes to lists.
 If that is the case, use the "GET" command to lock each list.  This will
prevent anyone - site administrator or list owner - from making changes to any
list without first unlocking the list.  If a situation arises in which there is
a legitimate need to make a change to a list, the site administrator or list
owner can unlock the list, make the necessary change, then relock the list using
the "GET" command.  Intentional actions which disregard the organization's
stated direction are personnel issues, not technical problems.

--
Paul Russell, Senior Systems Administrator
OIT Messaging Services Team
University of Notre Dame