<chapter id="quick-start">
- <!-- $Id: quickstart.xml,v 1.1 2002-04-09 13:26:26 adam Exp $ -->
<title>Quick Start </title>
-
- <para>
- 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
- <literal>test/gils</literal> subdirectory of the distribution archive.
- There you will find a configuration
- file named <literal>zebra.cfg</literal> with the following contents:
-
- <screen>
- # Where are the YAZ tables located.
- profilePath: ../../../yaz/tab ../../tab
-
- # Files that describe the attribute sets supported.
- attset: bib1.att
- attset: gils.att
- </screen>
- </para>
-
+
<para>
- Now, edit the file and set <literal>profilePath</literal> to the path of the
- YAZ profile tables (sub directory <literal>tab</literal> of the YAZ
- distribution archive).
+ <!-- ### ulink to GILS profile: what's the URL? -->
+ 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.
</para>
-
<para>
- The 48 test records are located in the sub directory
- <literal>records</literal>. To index these, type:
-
+ Go to the <literal>examples/gils</literal> subdirectory of the
+ distribution archive. The 48 test records are located in the sub
+ directory <literal>records</literal>. To index these, type:
<screen>
- $ ../../index/zebraidx -t grs.sgml update records
+ zebraidx update records
</screen>
</para>
<para>
- In the command above the option <literal>-t</literal> specified the record
- type — in this case <literal>grs.sgml</literal>.
- The word <literal>update</literal> followed
- by a directory root updates all files below that directory node.
+ In this command, the word <literal>update</literal> is followed
+ by the name of a directory: <literal>zebraidx</literal> updates all
+ files in the hierarchy rooted at that directory.
</para>
<para>
fire up a server. To start a server on port 2100, type:
<screen>
- $ ../../index/zebrasrv tcp:@:2100
+ zebrasrv @:2100
</screen>
</para>
<para>
- The Zebra index that you have just created has a single database
+ The &zebra; index that you have just created has a single database
named <literal>Default</literal>.
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.
+ return records in &acro.usmarc;, &acro.grs1;, or &acro.sutrs; format depending
+ on what the client asks for.
</para>
<para>
- To test the server, you can use any Z39.50 client (1992 or later).
- For instance, you can use the demo client that comes with YAZ: Just
- cd to the <literal>client</literal> subdirectory of the YAZ distribution
- and type:
+ To test the server, you can use any &acro.z3950; client.
+ For instance, you can use the demo command-line client that comes
+ with &yaz;:
</para>
<para>
<screen>
- $ ./yaz-client tcp:localhost:2100
+ yaz-client localhost:2100
</screen>
</para>
When the client has connected, you can type:
</para>
-<para>
-
+ <para>
<screen>
Z> find surficial
Z> show 1
</para>
<para>
- The default retrieval syntax for the client is USMARC. To try other
- formats for the same record, try:
+ The default retrieval syntax for the client is &acro.usmarc;, and the
+ default element set is <literal>F</literal> (``full record''). To
+ try other formats and element sets for the same record, try:
</para>
<para>
<screen>
<note>
<para>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.
+ client requests &acro.sutrs;, &acro.grs1; or &acro.xml; records.
+ This is normal - not all of the GILS data elements have mappings in
+ the &acro.usmarc; record format.
</para>
</note>
<para>
- If you've made it this far, there's a good chance that
- you've got through the compilation OK.
+ 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
+ <literal>zebra.cfg</literal> file. In order to help us understand
+ these fully, the next chapter will work through a series of
+ increasingly complex example configurations.
</para>
</chapter>
projects / idzebra-moved-to-github.git / blobdiff