On Fri, 16 Oct 1998, KEVIN  MCKENZIE wrote:

> If they are not allowed to have access to the information, why is there a
> concern that they have review commands available to them.  At least this
> way they could have the lists that they needed and it stays within policy
> demands without having to go through the trouble of super lists.

  The answer to that question is somewhat convoluted and refers to
comments in my initial request for assistance where I said that List
Owners had been using their class lists in ways unanticipated.  They used
the output of REVIEW to send specific and private mail to individual
students and viewed the changes as a loss of a right they previously had
as owners of their class mailing lists.  In addition, it was also viewed
as an insult in the sense that they could no longer "be in charge" of
their own class list.

  The alternative the system manager came up with last night (random
userids and fake names) will still allow faculty to own their list and be
able to REVIEW their list and construct private mail to students as they
did before.  In addition, with cooperation, the class roster will not
reveal these students in case it gets printed or distributed.  Most
importantly, I or someone else, doesn't have the task of writing something
to alter how Listserv processes certain commands, or alter the program
that feeds Listserv the students to be subscribed to one or more lists.
The catch is that this is a proposal we are submitting this am, so I may
be back if I run into trouble with the second alternative. :-)

  Thomas K., our Listserv server (1.8d Feb. 1998 build) runs under
Solaris.  Re: Private option in Listserv. Well, I don't think LSOFT would
do it for just a few of us because this is too specific a case and
probably wouldn't be worth the time and effort to code. :-)  We couldn't
do it without the source or if it can be done via an EXIT (I've never
written one for Listserv before), it wouldn't be efficient because we
already have a program that feeds an ADD JOB for each list, and it would
be more efficient to alter this job and have it parse the list of
subscribers putting those with the "Private" flag into a second appended
ADD JOB, using the same listname only with a "-P" and have this as the
sub-list.  Most of the work is already done in that program.  That is
probably the way we will go if the current proposal is not acceptable.
It would look like this, for example:

PSYC123-L              (Super List - owned by faculty member)
    |____PSYC123-P     (Sub-List   - not owned by faculty member)

I know that getting into super and sub lists is messy, and faculty don't
like it either because of the "secret list" and all it conjures up (you
can imagine the worst comments here) but with the task of having to comply
with Admin and reduce as much as possible the perceived insult (real or
imagined) to faculty, it is the best I think we could do if the solution
we present today isn't acceptable.

Thanks again for all comments and suggestions, at least if I could use
them, they helped clarify why I couldn't and made the task much easier
than relying on my own limited view of what I thought was possible.

--Trish