>As I understand it, in LISTSERV for VM the access-level specified as the
>fourth word in the value of the Notebook= keyword controls all of the
>following types of access:
>
>1. Who can retrieve the list archive notebooks with the "GET" command
>
>2. Who can retrieve specific messages from the list archive notebooks
>   with the "GETPOST" command
>
>3. Who can retrieve specific messages from the list archive notebooks
>   by sending an (edited) index back to the listname-SEARCH-REQUEST
>   address

#3 is just a front-end for #2. I cannot think of any reason to enable the one
but not the other - some INDEX users may use the -SEARCH-REQUEST
method while others will send a GETPOST command, as a matter of
personal preference.

From a security standpoint, there is no reason to allow one of the commands
in this group but not the others. From a resource standpoint, there does not
seem to be any reason either. None of these commands are resource
intensive, except GET if the file is really huge, which can be avoided by going
from yearly or monthly to weekly.

>4. Who can search/retrieve the list archive notebooks with CJLI database
>   search jobs
>
>5. Who can search the list archive notebooks with the new "SEARCH"
>   command

My advice (as I told Noel) would be to work on improving the performance of
#5, which is suboptimal by default on VM as a large increase in VMSIZE is
required, and then see what it would take to disable #4. While people do
complain about the lack of AFD/FUI for non-VM systems, there are essentially
no complaints about the lack of the more exotic database functions which are
not available on these systems yet. People generally prefer the new functions
and they are much faster (at least potentially, where VM is concerned). I never
use the old functions myself, except for searches in PEERS or the like, but
that is another story.

Anyway, while the missing functionality (index line redefinition, part exits, etc)
might be ported eventually, the old search engine code is definitely on
maintenance only. This means you will not get any significant enhancement
to #4 (which is easy to disable globally). The function you are asking for can
be implemented by modifying the REXX code, so you could develop it locally.
Personally I would try to talk my users into switching to the new functions, and
then I would disable the old functions completely for notebook searches.

#5 is a legitimate requirement, although on most systems it is not an issue. Of
course, on time-sharing systems there is always the issue of limited resources
at peak hours. Do other sites need this functionality?

>One way to accomplish this would be to continue to use the access-level
>currently specified as the fourth word in the value of the Notebook=
>keyword to control WHO has access and add a new facility for specifying
>WHICH of the access methods are available.

Note that this would not work because 'access-level' is any number of words.

   Eric