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/ >>