Douglas said:
 
> This is from one listowner's viewpoint (the one that started all this).
 
> Some listowners of larger lists sometimes, maybe not often, but definitely
> from time to time, need to change the sub options of a fairly significant
> portion of the subs while leaving the others untouched.
 
Yes.  The reason that I went to the trouble of cracking the code and
writing the perl script was that I needed to make mass changes for
subscribers depending on their topic settings.  We had been using
three topics on a list and we wanted to split the list into three
separate lists.  I wanted to make the switch fairly tranparent to the
subscribers.  The perl script enabled me to identify the subscribers
receiving each topic and to generate ADD commands for the new lists.
I also was careful to replicate their DIGEST/INDEX settings.  On
Sunday morning of Labor Day weekend, I submitted 4500 commands to our
LISTSERVer.
 
Here is Douglas's example:
 
>   For example, you decide you want to install Renewal, but
> you want it to apply only to those subs set nomail.  That means you need
> a list of the nomail subs.
 
We don't do thing like this very often.  But now that I have the
decoded lists, it is something that I use *every day*.  When I work on
the bounce messages, I like to check the subscriptions before I delete
them.  Scan and query are now much better than they used to be
(thanks, Erik) but they are still far to slow because I have to wait
for an email answer.  I GET our lists with (NOLOCK every week and then
do a local search when I need information.  This is *much* faster and
it gives the information in a single line format that much easier to
understand.  We have over 25 lists and if I query for all subscribers
on a system that is bouncing mail, I often have lists of over a
hundred subscriptions.  The standard output of query is really not
very helpful.
 
> What we, or at least I, want is sort of an amalgam of "query with"
> and scan.  I don't care whether scan is modified, or query is modified
> (and I'ld probably be satisfied if you kept the "with" option and
> just gave us back the option of the old style output when we want it)
> or an all new command is created.
 
I'd like to suggest a new option for GET:
 
    GET <listname> (DECODE
 
would return something like the output of my perl script--one line per
subscription with human-readable codes.  This would let you revise the
internal codes freely for new options and improved efficiency.  But it
would also support the list owners who need to work with their lists.
 
I hope somethink like this is possible in the next release.
 
                               Peace,  Dan
 
<<  Daniel D. Wheeler - Education & Psychology, Univ. of Cincinnati  >>
<<  KIDLINK Director of Educational Services & Subscription Manager  >>
<<  Email: [log in to unmask]      URL: http://www.uc.edu/~wheeler/  >>