In this section, we will test the system by indexing a small set of sample GILS records that are included with the Zebra distribution, running a Zebra server against the newly created database, and searching the indexes with a client that connects to that server.
Go to the examples/gils
subdirectory of the
distribution archive. The 48 test records are located in the sub
directory records
. To index these, type:
zebraidx update records
In this command, the word update
is followed
by the name of a directory: zebraidx
updates all
files in the hierarchy rooted at that directory.
If your indexing command was successful, you are now ready to fire up a server. To start a server on port 2100, type:
zebrasrv @:2100
The Zebra index that you have just created has a single database
named Default
.
The database contains records structured according to
the GILS profile, and the server will
return records in USMARC, GRS-1, or SUTRS format depending
on what the client asks for.
To test the server, you can use any Z39.50 client. For instance, you can use the demo command-line client that comes with YAZ:
yaz-client localhost:2100
When the client has connected, you can type:
Z> find surficial Z> show 1
The default retrieval syntax for the client is USMARC, and the
default element set is F
(``full record''). To
try other formats and element sets for the same record, try:
Z>format sutrs Z>show 1 Z>format grs-1 Z>show 1 Z>format xml Z>show 1 Z>elements B Z>show 1
You may notice that more fields are returned when your client requests SUTRS, GRS-1 or XML records. This is normal - not all of the GILS data elements have mappings in the USMARC record format.
If you've made it this far, you know that your installation is
working, but there's a certain amount of voodoo going on - for
example, the mysterious incantations in the
zebra.cfg
file. In order to help us understand
these fully, the next chapter will work through a series of
increasingly complex example configurations.