VIII.a Debugging a Shell Search
-------------------------------
One of the most common problems reported to VMSGOPHER-L is that a shell search
(using Bruce Tanner's BUILD_INDEX/QUERY.EXE/SEARCH.SHELL indexed search) works
fine from DCL but doesn't return the expected results (usually no results)
when run by the Gopher Server.  Several assumptions need to be confirmed:

1)  Is the shell search is properly declared in a link tuple?  It should look
    something like this:

	Name=Shell Search
	Type=7
	Path=7gopher_root:[dir1]search.shell gopher_root:[dir2]document
	Port=+
	Host=+

Note that two filespecs must be supplied in the Path= string.  The first
locates the search shell file, the second locates the index files for the file
"document".

2)  If you create a link tuple like the following, can a client retrieve the
    shell file as a text file?  If not, perhaps the filespec for the
    search.shell file is incorrect, or read access to the file is not granted
    to the server.

	Name=Shell Search
	Type=0
	Path=0gopher_root:[dir1]search.shell
	Port=+
	Host=+

3)  Has the shell file been edited to properly reference the QUERY.EXE program
    *where it lives on your system*?

4)  Does the ID under which the Gopher Server runs have execute access to the
    shell file and the QUERY.EXE program?  Does it have write access to the
    ScratchDir: specified in the configuration?  Does it have execute access to
    the SpawnInit: file specified in the config- uration?  Does it have
    sufficient quotas to perform the spawned tasks asked of it?

5)  Do the files document.idx and document.sel, created by BUILD_INDEX, exist
    on the device and in the directory specified in the Path= specification of
    the link tuple?  Does the file specified in the "Rnnn-nnn-filespec" texts
    in the document.sel file actually exist as the filespec specifies?  If
    not, the document's index files .idx and .sel need to be moved there or
    rebuilt.

6)  A last recourse, of course, is to run the gopher_debug version of the
    server under the debugger, with SET VERIFY turned on before doing so.  Dummy
    up another configuration file for this, using port 71 or port 1070, so as
    not to conflict with the real server, and maybe a separate log file you can
    dispose of later.  Define a foreign command for the debug version of the
    server

	$ gd :== $dev:[dir]gopher_debug.exe

and invoke it:

	$ set verify		! to make spawned subprocesses display
	$ gd DEBUG port config	! where port is 71 or 1070 or whatever
				! and config is the dummy cfg file

Once in the debugger, SET MODE NOSCREEN and GO.

Then, invoke a client from a separate terminal or session, connecting it to
the selected debugging port.  Your main menu should be raised, and the debug
server (because of the DEBUG option on its command line) will log not just to
the log file but to the screen as well as it crunches along.  Go on down your
menus and select your search. Because of the SET VERIFY, you should see the
spawned seach.shell execute.  Take note of what's going on there and your
failure should appear fairly obviously.  If not, add some diagnostics (like
displaying effective filenames and parameters) to search.shell.

.