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 Zebra a 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 |
Note: 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.