In this section, we will test the system by indexing a small set of sample GILS records that are included with the software distribution. Go to the examples/gils subdirectory of the distribution archive. There you will find a configuration file named zebra.cfg with the following contents:
# Where the schema files, attribute files, etc are located. profilePath: ../../tab # Files that describe the attribute sets supported. attset: bib1.att attset: gils.att attset: explain.att recordtype: grs.sgml isam: c
The 48 test records are located in the sub directory records. To index these, type:
zebraidx update records
In the command above, the word update followed by a directory root updates all files below that directory node.
If your indexing command was successful, you are now ready to fire up a server. To start a server on port 2100, type:
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 either either USMARC, GRS-1, or SUTRS depending on what your client asks for.
To test the server, you can use any Z39.50 client. For instance, you can use the demo client that comes with YAZ:
When the client has connected, you can type:
Z> find surficial Z> show 1
The default retrieval syntax for the client is USMARC. To try other formats 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 or GRS-1 records. When retrieving GILS 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.