<!--Generated by stripref.xsl . Do not edit-->
<refentry id="zebraidx">
 <refentryinfo>
  <productname class="trade">zebra</productname>
  <productnumber>2.2.8</productnumber>
  <orgname>Index Data</orgname>
 </refentryinfo>

 <refmeta>
  <refentrytitle>zebraidx</refentrytitle>
  <manvolnum>1</manvolnum>
  <refmiscinfo class="manual">Commands</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>zebraidx</refname>
  <refpurpose><application moreinfo="none">Zebra</application> Administrative Tool</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
  <cmdsynopsis sepchar=" ">
   <command moreinfo="none">zebraidx</command>
   <arg choice="opt" rep="norepeat"><option>-c <replaceable>config</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-d <replaceable>database</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-f <replaceable>number</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-g <replaceable>group</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-l <replaceable>file</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-L</option></arg>
   <arg choice="opt" rep="norepeat"><option>-m <replaceable>mbytes</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-n</option></arg>
   <arg choice="opt" rep="norepeat"><option>-s</option></arg>
   <arg choice="opt" rep="norepeat"><option>-v <replaceable>level</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-t <replaceable>type</replaceable></option></arg>
   <arg choice="opt" rep="norepeat"><option>-v</option></arg>
   <arg choice="req" rep="norepeat"><replaceable>command</replaceable></arg>
   <arg choice="opt" rep="repeat"><replaceable>file</replaceable></arg>
  </cmdsynopsis>
 </refsynopsisdiv>

 <refsect1><title>DESCRIPTION</title>
  <para>
   <command moreinfo="none">zebraidx</command> allows you to insert, delete or updates
   records in <application moreinfo="none">Zebra</application>. <command moreinfo="none">zebraidx</command> accepts a set options
   (see below) and exactly one command (mandatory).
  </para>
 </refsect1>
 <refsect1>
  <title>COMMANDS</title>

  <variablelist>
   <varlistentry>
    <term>update <replaceable>directory</replaceable></term>
    <listitem>
     <para>
      Update the register with the files contained in
      <replaceable>directory</replaceable>.
      If no directory is provided, a list of files is read from
      <literal moreinfo="none">stdin</literal>.
      See <link linkend="administration">Administration</link> in the <application moreinfo="none">Zebra</application>
      Manual.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>delete <replaceable>directory</replaceable></term>
    <listitem>
     <para>
      Remove the records corresponding to the files found under
      <replaceable>directory</replaceable> from the register.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>adelete <replaceable>directory</replaceable></term>
    <listitem>
     <para>
      Remove the records corresponding to the files found under
      <replaceable>directory</replaceable> from the register.
      Unlike command <literal moreinfo="none">delete</literal> this command does not
      fail if a record does not exist (but which is attempted deleted).
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>commit</term>
    <listitem>
     <para>
      Write the changes resulting from the last <literal moreinfo="none">update</literal>
      commands to the register. This command is only available if the use of
      shadow register files is enabled
      (see <link linkend="shadow-registers">Shadow Registers</link> in the
      <application moreinfo="none">Zebra</application> Manual).
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>check <replaceable>options</replaceable></term>
    <listitem><para>
      Runs consistency check of register. May take a long time.
      Options may be one of <literal moreinfo="none">quick</literal>,
      <literal moreinfo="none">default</literal> or <literal moreinfo="none">full</literal>.
     </para></listitem>
   </varlistentry>
   <varlistentry>
    <term>clean</term>
    <listitem><para>
      Clean shadow files and "forget" changes.
     </para></listitem>
   </varlistentry>
   <varlistentry>
    <term>create <replaceable>database</replaceable></term>
    <listitem><para>
      Create database.
     </para></listitem>
   </varlistentry>
   <varlistentry>
    <term>drop <replaceable>database</replaceable></term>
    <listitem><para>
      Drop database (delete database).
     </para></listitem>
   </varlistentry>
   <varlistentry>
    <term>init</term>
    <listitem><para>
      Deletes an entire register (all files in shadow+register areas).
     </para></listitem>
   </varlistentry>
  </variablelist>
 </refsect1>
 <refsect1>
  <title>OPTIONS</title>
  <variablelist>

   <varlistentry>
    <term>-c <replaceable>config-file</replaceable></term>
    <listitem>
     <para>
      Read the configuration file
      <replaceable>config-file</replaceable> instead of
      <literal moreinfo="none">zebra.cfg</literal>.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-d <replaceable>database</replaceable></term>
    <listitem>
     <para>
      The records located should be associated with the database name
      <replaceable>database</replaceable> for access through the
      <acronym>Z39.50</acronym> server.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-f <replaceable>number</replaceable></term>
    <listitem>
     <para>
      Specify how many per-record log lines, zebraidx, should produce during
      indexing and during register check (check command). If this option
      is not given, a value of 1000 is used.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-g <replaceable>group</replaceable></term>
    <listitem>
     <para>
      Update the files according to the group
      settings for <replaceable>group</replaceable>
      (see <link linkend="zebra-cfg"><application moreinfo="none">Zebra</application> Configuration File</link> in
      the <application moreinfo="none">Zebra</application> manual).
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-l <replaceable>file</replaceable></term>
    <listitem>
     <para>
      Write log messages to <replaceable>file</replaceable> instead
      of <literal moreinfo="none">stderr</literal>.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-L</term>
    <listitem>
     <para>
      Makes zebraidx skip symbolic links. By default, zebraidx follows
      them.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-m <replaceable>mbytes</replaceable></term>
    <listitem>
     <para>
      Use <replaceable>mbytes</replaceable> of memory before flushing
      keys to background storage. This setting affects performance when
      updating large databases.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-n</term>
    <listitem>
     <para>
      Disable the use of shadow registers for this operation
      (see <link linkend="shadow-registers">Shadow Registers in
       the <application moreinfo="none">Zebra</application> manual</link>).
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-s</term>
    <listitem>
     <para>
      Show analysis of the indexing process. The maintenance
      program works in a read-only mode and doesn't change the state
      of the index. This options is very useful when you wish to test a
      new profile.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-t <replaceable>type</replaceable></term>
    <listitem>
     <para>
      Update all files as <replaceable>type</replaceable>. Currently, the
      types supported are <literal moreinfo="none">text</literal>, <literal moreinfo="none">alvis</literal>
      and <literal moreinfo="none">grs</literal><replaceable>.subtype</replaceable>.
      Generally, it is probably advisable to specify the record types
      in the <literal moreinfo="none">zebra.cfg</literal> file (see
      <link linkend="record-types">Record Types</link> in the <application moreinfo="none">Zebra</application> manual),
      to avoid confusion at subsequent updates.
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term>-V</term>
    <listitem>
     <para>
      Show <application moreinfo="none">Zebra</application> version.
     </para>
    </listitem>
   </varlistentry>
   <varlistentry>
    <term>-v <replaceable>level</replaceable></term>
    <listitem>
     <para>
      Set the log level to <replaceable>level</replaceable>.
      <replaceable>level</replaceable> should be one of
      <literal moreinfo="none">none</literal>, <literal moreinfo="none">debug</literal>, and
      <literal moreinfo="none">all</literal>.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>
 <refsect1><title>FILES</title>
  <para>
   <filename moreinfo="none">zebra.cfg</filename>
  </para>
 </refsect1>
 <refsect1><title>SEE ALSO</title>
  <para>
   <citerefentry>
    <refentrytitle>zebrasrv</refentrytitle>
    <manvolnum>8</manvolnum>
   </citerefentry>
  </para>
 </refsect1>
</refentry>
<!--Generated by stripref.xsl . Do not edit-->
<refentry id="zebrasrv">
 <refentryinfo>
  <productname class="trade">zebra</productname>
  <productnumber>2.2.8</productnumber>
  <orgname>Index Data</orgname>
 </refentryinfo>

 <refmeta>
  <refentrytitle>zebrasrv</refentrytitle>
  <manvolnum>8</manvolnum>
  <refmiscinfo class="manual">Commands</refmiscinfo>
 </refmeta>

 <refnamediv>
  <refname>zebrasrv</refname>
  <refpurpose>Zebra Server</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
  <!-- 
   cmd description of &yaz; GFS application.
   Included in both manual and man page for yaz-ztest
-->

<cmdsynopsis sepchar=" ">
 <command moreinfo="none">zebrasrv</command>
 <arg choice="opt" rep="norepeat"><option>-install</option></arg>
 <arg choice="opt" rep="norepeat"><option>-installa</option></arg>
 <arg choice="opt" rep="norepeat"><option>-remove</option></arg>
 <arg choice="opt" rep="norepeat"><option>-a <replaceable>file</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-v <replaceable>level</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-l <replaceable>file</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-u <replaceable>uid</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-c <replaceable>config</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-f <replaceable>vconfig</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-C <replaceable>fname</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-t <replaceable>minutes</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-k <replaceable>kilobytes</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-d <replaceable>daemon</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-w <replaceable>dir</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-p <replaceable>pidfile</replaceable></option></arg>
 <arg choice="opt" rep="norepeat"><option>-ziDST1</option></arg>
 <arg choice="opt" rep="repeat">listener-spec</arg>
</cmdsynopsis>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document: "zebrasrv.xml"
sgml-local-catalogs: nil
sgml-namecase-general:t
End:
-->

 </refsynopsisdiv>
 <refsect1><title>DESCRIPTION</title>
  <para>Zebra is a high-performance, general-purpose structured text indexing
   and retrieval engine. It reads structured records in a variety of input
   formats (e.g. email, <acronym>XML</acronym>, <acronym>MARC</acronym>) and allows access to them through exact
   boolean search expressions and relevance-ranked free-text queries.
  </para>
  <para>
   <command moreinfo="none">zebrasrv</command> is the <acronym>Z39.50</acronym> and <acronym>SRU</acronym> frontend
   server for the <command moreinfo="none">Zebra</command> search engine and indexer.
  </para>
  <para>
   On Unix you can run the <command moreinfo="none">zebrasrv</command>
   server from the command line - and put it
   in the background. It may also operate under the inet daemon.
   On WIN32 you can run the server as a console application or
   as a WIN32 Service.
  </para>
 </refsect1>
 <refsect1>
  <title>OPTIONS</title>

  <para>
   The options for <command moreinfo="none">zebrasrv</command> are the same
   as those for <application moreinfo="none">YAZ</application>' <command moreinfo="none">yaz-ztest</command>.
   Option <literal moreinfo="none">-c</literal> specifies a Zebra configuration
   file - if omitted <filename moreinfo="none">zebra.cfg</filename> is read.
  </para>

  <!-- 
   Options for generic frontend server and yaz-ztest.
   Included in both manual and man page for yaz-ztest
   Note - these files have been altered for zebrasrv, and are not in
   sync any more!!
-->

<variablelist>
 
 <varlistentry><term><literal moreinfo="none">-a </literal>
   <replaceable>file</replaceable></term>
  <listitem><para>
    Specify a file for dumping PDUs (for diagnostic purposes).
    The special name <literal moreinfo="none">-</literal> (dash) sends output to
    <literal moreinfo="none">stderr</literal>.
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-S</literal></term>
  <listitem><para>
    Don't fork or make threads on connection requests. This is good for
    debugging, but not recommended for real operation: Although the
    server is asynchronous and non-blocking, it can be nice to keep
    a software malfunction (okay then, a crash) from affecting all
    current users. The server can only accept a single
       connection in this mode.
   </para></listitem></varlistentry>
<!-- The text for -S option is (in my opinion) the wrong way around. The main
argument for not using -S is that it can handle only one connection at a
time, whereas the forking and threading interfaces can handle multiple
connections. Also, the forking (but not threading) model can survive a
crash at a single server instance. Heikki -->

 
 <varlistentry><term><literal moreinfo="none">-1</literal></term>
  <listitem><para>
    Like <literal moreinfo="none">-S</literal> but after one session the server
    exits. This mode is for debugging <emphasis>only</emphasis>.
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-T</literal></term>
  <listitem><para>
    Operate the server in threaded mode. The server creates a thread
    for each connection rather than a fork a process. Only available
    on UNIX systems that offers POSIX threads.
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-s</literal></term>
  <listitem><para>
    Use the SR protocol (obsolete).
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-z</literal></term>
  <listitem><para>
    Use the <acronym>Z39.50</acronym> protocol (default). This option and <literal moreinfo="none">-s</literal>
    complement each other.
    You can use both multiple times on the same command
    line, between listener-specifications (see below). This way, you
    can set up the server to listen for connections in both protocols
    concurrently, on different local ports.
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-l </literal>
   <replaceable>file</replaceable></term>
  <listitem><para>
    Specify an output file for the diagnostic messages.
       The default is to write this information to
   <literal moreinfo="none">stderr</literal>
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-c </literal>
   <replaceable>config-file</replaceable></term>
  <listitem><para> Read configuration information from
       <replaceable>config-file</replaceable>.
       The default configuration is <literal moreinfo="none">./zebra.cfg</literal>
  </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-f </literal>
   <replaceable>vconfig</replaceable></term>
  <listitem><para>This specifies an <acronym>XML</acronym> file that describes
    one or more <application moreinfo="none">YAZ</application> frontend virtual servers. See section VIRTUAL
   HOSTS for details.
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-C </literal>
   <replaceable>fname</replaceable></term>
  <listitem><para>Sets SSL certificate file name for server (PEM).
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-v </literal>
   <replaceable>level</replaceable></term>
  <listitem><para>
    The log level. Use a comma-separated list of members of the set
    {fatal,debug,warn,log,malloc,all,none}.
   </para></listitem></varlistentry>
<!-- The -v option (for log level) is not enough. There are many more
log switches than the simple levels you mention, and more can (and will)
be defined in (loadable?) modules. You can get them all listed in the
log file with '-v loglevel'. Most users will at least have interest in 
'server', 'session', 'request', and 'requestdetail', and possibly
'searchhits', 'searchterms', 'resultsets', 'rpn'. And maybe many more...
I ought to write a script that greps the bits from the source code -
that is the only way to get to them, there is no longer any central
repository for them. No idea how to explain this neatly in the man
page...
Heikki -->


 <varlistentry><term><literal moreinfo="none">-u </literal>
   <replaceable>uid</replaceable></term>
  <listitem><para>
    Set user ID. Sets the real UID of the server process to that of the
    given user. It's useful if you aren't comfortable with having the
    server run as root, but you need to start it as such to bind a
    privileged port.
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-w </literal>
   <replaceable>working-directory</replaceable></term>
  <listitem><para>
    The server changes to this working directory during before listening 
    on incoming connections. This option is useful
    when the server is operating from the <application moreinfo="none">inetd</application>
    daemon (see <literal moreinfo="none">-i</literal>).
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-p </literal>
   <replaceable>pidfile</replaceable></term>
  <listitem><para>
    Specifies that the server should write its Process ID to
    file given by <replaceable>pidfile</replaceable>. 
    A typical location would be <filename moreinfo="none">/var/run/zebrasrv.pid</filename>.
   </para></listitem></varlistentry>

 <varlistentry><term><literal moreinfo="none">-i</literal></term>
  <listitem><para>
    Use this to make the the server run from the
    <application moreinfo="none">inetd</application> server (UNIX only).
     Make sure you use the logfile option <literal moreinfo="none">-l</literal> in
       conjunction with this mode and specify the <literal moreinfo="none">-l</literal>
       option before any other options.
   </para></listitem></varlistentry>
<!--
-i: Better say "use this when the server is run from inetd", than "use
this to make the server run from inetd", as the option itself will only
tell zebra that it should assume that inetd started it.
Heikki --> 


 <varlistentry><term><literal moreinfo="none">-D</literal></term>
  <listitem><para>
    Use this to make the server put itself in the background and
    run as a daemon. If neither <literal moreinfo="none">-i</literal> nor 
    <literal moreinfo="none">-D</literal> is given, the server starts in the foreground.
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-install</literal></term>
  <listitem><para>
    Use this to install the server as an NT service
    (Windows NT/2000/XP only). 
    Control the server by going to the Services in the Control Panel.
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-installa</literal></term>
  <listitem><para>
    Use this to install and activate the server as an NT service
    (Windows NT/2000/XP only). 
    Control the server by going to the Services in the Control Panel.
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-remove</literal></term>
  <listitem><para>
    Use this to remove the server from the NT services
    (Windows NT/2000/XP only). 
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-t </literal>
   <replaceable>minutes</replaceable></term>
  <listitem><para>
    Idle session timeout, in minutes. Default is 60 minutes.
   </para></listitem></varlistentry>
 
 <varlistentry><term><literal moreinfo="none">-k </literal>
   <replaceable>size</replaceable></term>
  <listitem><para>
    Maximum record size/message size, in kilobytes. Default is 1024 KB (1 MB).
   </para></listitem>
 </varlistentry>

 <varlistentry><term><literal moreinfo="none">-d </literal>
   <replaceable>daemon</replaceable></term>
  <listitem><para>
    Set name of daemon to be used in hosts access file.
    See
    <citerefentry>
     <refentrytitle>hosts_access</refentrytitle>
     <manvolnum>5</manvolnum>
    </citerefentry>
    and 
    <citerefentry>
     <refentrytitle>tcpd</refentrytitle>
     <manvolnum>8</manvolnum>
    </citerefentry>.
   </para></listitem>
 </varlistentry>
 
</variablelist>


  <para>
   A <replaceable>listener-address</replaceable> consists of an optional
   transport mode followed by a colon (:) followed by a listener address.
   The transport mode is either a file system socket
   <literal moreinfo="none">unix</literal>,
   a SSL TCP/IP socket <literal moreinfo="none">ssl</literal>, or a plain TCP/IP socket
   <literal moreinfo="none">tcp</literal> (default).
  </para>

  <para>
   For TCP, an address has the form
   <screen format="linespecific">
    hostname | IP-number [: portnumber]
   </screen>
   The port number defaults to 210 (standard <acronym>Z39.50</acronym> port) for
   privileged users (root), and 9999 for normal users.
   The special hostname "@" is mapped to
   the address INADDR_ANY, which causes the server to listen on any local
   interface.   </para>

  <para>
   The default behavior for <literal moreinfo="none">zebrasrv</literal> - if started
   as non-privileged user - is to establish
   a single TCP/IP listener, for the <acronym>Z39.50</acronym> protocol, on port 9999.
   <screen format="linespecific">
    zebrasrv @
    zebrasrv tcp:some.server.name.org:1234
    zebrasrv ssl:@:3000
   </screen>
  </para>

  <para>
   To start the server listening on the registered port for
   <acronym>Z39.50</acronym>, or on a filesystem socket, 
   and to drop root privileges once the ports are bound, execute
   the server like this from a root shell:
   <screen format="linespecific">
    zebrasrv -u daemon @
    zebrasrv -u daemon tcp:@:210
    zebrasrv -u daemon unix:/some/file/system/socket
   </screen>
   Here <literal moreinfo="none">daemon</literal> is an existing user account, and the
   unix socket <literal moreinfo="none">/some/file/system/socket</literal> is readable
   and writable for the <literal moreinfo="none">daemon</literal> account.
  </para>
<!--
The line before the examples "zebrasrv -u daemon @" would sound better
if it said something like "execute the server from a root shell with a
command like one of these:" - so that our users won't cut and paste all
three lines...
Heikki -->


<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document: "zebrasrv.xml"
sgml-local-catalogs: nil
sgml-namecase-general:t
End:
-->

 </refsect1>

 <refsect1 id="protocol-support">
  <title><acronym>Z39.50</acronym> Protocol Support and Behavior</title>

  <refsect2 id="zebrasrv-initialization">
   <title><acronym>Z39.50</acronym> Initialization</title>

   <para>
    During initialization, the server will negotiate to version 3 of the
    <acronym>Z39.50</acronym> protocol, and the option bits for Search, Present, Scan,
    NamedResultSets, and concurrentOperations will be set, if requested by
    the client. The maximum PDU size is negotiated down to a maximum of
    1 MB by default.
   </para>

  </refsect2>

  <refsect2 id="zebrasrv-search">
   <title><acronym>Z39.50</acronym> Search</title>

   <para>
    The supported query type are 1 and 101. All operators are currently
    supported with the restriction that only proximity units of type "word"
    are supported for the proximity operator.
    Queries can be arbitrarily complex.
    Named result sets are supported, and result sets can be used as operands
    without limitations.
    Searches may span multiple databases.
   </para>

   <para>
    The server has full support for piggy-backed retrieval (see
    also the following section).
   </para>

  </refsect2>

  <refsect2 id="zebrasrv-present">
   <title><acronym>Z39.50</acronym> Present</title>
   <para>
    The present facility is supported in a standard fashion. The requested
    record syntax is matched against the ones supported by the profile of
    each record retrieved. If no record syntax is given, <acronym>SUTRS</acronym> is the
    default. The requested element set name, again, is matched against any
    provided by the relevant record profiles.
   </para>
  </refsect2>
  <refsect2 id="zebrasrv-scan">
   <title><acronym>Z39.50</acronym> Scan</title>
   <para>
    The attribute combinations provided with the termListAndStartPoint are
    processed in the same way as operands in a query (see above).
    Currently, only the term and the globalOccurrences are returned with
    the termInfo structure.
   </para>
  </refsect2>
  <refsect2 id="zebrasrv-sort">
   <title><acronym>Z39.50</acronym> Sort</title>

   <para>
    <acronym>Z39.50</acronym> specifies three different types of sort criteria.
    Of these Zebra supports the attribute specification type in which
    case the use attribute specifies the "Sort register".
    Sort registers are created for those fields that are of type "sort" in
    the default.idx file.
    The corresponding character mapping file in default.idx specifies the
    ordinal of each character used in the actual sort.
   </para>

   <para>
    <acronym>Z39.50</acronym> allows the client to specify sorting on one or more input
    result sets and one output result set.
    Zebra supports sorting on one result set only which may or may not
    be the same as the output result set.
   </para>
  </refsect2>
  <refsect2 id="zebrasrv-close">
   <title><acronym>Z39.50</acronym> Close</title>
   <para>
    If a Close PDU is received, the server will respond with a Close PDU
    with reason=FINISHED, no matter which protocol version was negotiated
    during initialization. If the protocol version is 3 or more, the
    server will generate a Close PDU under certain circumstances,
    including a session timeout (60 minutes by default), and certain kinds of
    protocol errors. Once a Close PDU has been sent, the protocol
    association is considered broken, and the transport connection will be
    closed immediately upon receipt of further data, or following a short
    timeout.
   </para>
  </refsect2>

  <refsect2 id="zebrasrv-explain">
   <title><acronym>Z39.50</acronym> Explain</title>
   <para>
    Zebra maintains a "classic"
    <ulink url="https://www.loc.gov/z3950/agency/markup/07.html"><acronym>Z39.50</acronym> Explain</ulink> database
    on the side.
    This database is called <literal moreinfo="none">IR-Explain-1</literal> and can be
    searched using the attribute set <literal moreinfo="none">exp-1</literal>.
   </para>
   <para>
    The records in the explain database are of type
    <literal moreinfo="none">grs.sgml</literal>.
    The root element for the Explain grs.sgml records is
    <literal moreinfo="none">explain</literal>, thus
    <filename moreinfo="none">explain.abs</filename> is used for indexing.
   </para>
   <note>
    <para>
     Zebra <emphasis>must</emphasis> be able to locate
     <filename moreinfo="none">explain.abs</filename> in order to index the Explain
     records properly. Zebra will work without it but the information
     will not be searchable.
    </para>
   </note>
  </refsect2>
 </refsect1>
 <refsect1 id="zebrasrv-sru">
  <title>The <acronym>SRU</acronym> Server</title>
  <para>
   In addition to <acronym>Z39.50</acronym>, Zebra supports the more recent and
   web-friendly IR protocol <ulink url="https://www.loc.gov/standards/sru/"><acronym>SRU</acronym></ulink>.
   <acronym>SRU</acronym> can be carried over <acronym>SOAP</acronym> or a <acronym>REST</acronym>-like protocol
   that uses HTTP <acronym>GET</acronym> or <acronym>POST</acronym> to request search responses.  The request
   itself is made of parameters such as
   <literal moreinfo="none">query</literal>,
   <literal moreinfo="none">startRecord</literal>,
   <literal moreinfo="none">maximumRecords</literal>
   and
   <literal moreinfo="none">recordSchema</literal>;
   the response is an <acronym>XML</acronym> document containing hit-count, result-set
   records, diagnostics, etc.  <acronym>SRU</acronym> can be thought of as a re-casting
   of <acronym>Z39.50</acronym> semantics in web-friendly terms; or as a standardisation
   of the ad-hoc query parameters used by search engines such as Google
   and AltaVista; or as a superset of A9's OpenSearch (which it
   predates).
  </para>
  <para>
   Zebra supports <acronym>Z39.50</acronym>, <acronym>SRU</acronym> <acronym>GET</acronym>, SRU <acronym>POST</acronym>, SRU <acronym>SOAP</acronym> (<acronym>SRW</acronym>)
   - on the same port, recognising what protocol is used by each incoming
   requests and handling them accordingly.  This is a achieved through
   the use of Deep Magic; civilians are warned not to stand too close.
  </para>
  <refsect2 id="zebrasrv-sru-run">
   <title>Running zebrasrv as an <acronym>SRU</acronym> Server</title>
   <para>
    Because Zebra supports all protocols on one port, it would
    seem to follow that the <acronym>SRU</acronym> server is run in the same way as
    the <acronym>Z39.50</acronym> server, as described above.  This is true, but only in
    an uninterestingly vacuous way: a Zebra server run in this manner
    will indeed recognise and accept <acronym>SRU</acronym> requests; but since it
    doesn't know how to handle the <acronym>CQL</acronym> queries that these protocols
    use, all it can do is send failure responses.
   </para>
   <note>
    <para>
     It is possible to cheat, by having <acronym>SRU</acronym> search Zebra with
     a <acronym>PQF</acronym> query instead of <acronym>CQL</acronym>, using the
     <literal moreinfo="none">x-pquery</literal>
     parameter instead of
     <literal moreinfo="none">query</literal>.
     This is a
     <emphasis role="strong">non-standard extension</emphasis>
     of <acronym>CQL</acronym>, and a
     <emphasis role="strong">very naughty</emphasis>
     thing to do, but it does give you a way to see Zebra serving <acronym>SRU</acronym>
     ``right out of the box''.  If you start your favourite Zebra
     server in the usual way, on port 9999, then you can send your web
     browser to:
    </para>
    <screen format="linespecific">
     http://localhost:9999/Default?version=1.1
     &amp;operation=searchRetrieve
     &amp;x-pquery=mineral
     &amp;startRecord=1
     &amp;maximumRecords=1
    </screen>
    <para>
     This will display the <acronym>XML</acronym>-formatted <acronym>SRU</acronym> response that includes the
     first record in the result-set found by the query
     <literal moreinfo="none">mineral</literal>.  (For clarity, the <acronym>SRU</acronym> URL is shown
     here broken across lines, but the lines should be joined together
     to make single-line URL for the browser to submit.)
    </para>
   </note>
   <para>
    In order to turn on Zebra's support for <acronym>CQL</acronym> queries, it's necessary
    to have the <application moreinfo="none">YAZ</application> generic front-end (which Zebra uses) translate them
    into the <acronym>Z39.50</acronym> Type-1 query format that is used internally.  And
    to do this, the generic front-end's own configuration file must be
    used.  See <xref linkend="gfs-config"/>;
    the salient point for <acronym>SRU</acronym> support is that
    <command moreinfo="none">zebrasrv</command>
    must be started with the
    <literal moreinfo="none">-f frontendConfigFile</literal>
    option rather than the
    <literal moreinfo="none">-c zebraConfigFile</literal>
    option,
    and that the front-end configuration file must include both a
    reference to the Zebra configuration file and the <acronym>CQL</acronym>-to-<acronym>PQF</acronym>
    translator configuration file.
   </para>
   <para>
    A minimal front-end configuration file that does this would read as
    follows:
   </para>
   <screen format="linespecific">
    
    &lt;yazgfs&gt;
    &lt;server&gt;
    &lt;config&gt;zebra.cfg&lt;/config&gt;
    &lt;cql2rpn&gt;../../tab/pqf.properties&lt;/cql2rpn&gt;
   &lt;/server&gt;
   &lt;/yazgfs&gt;
    </screen>
   <para>
    The
    <literal moreinfo="none">&lt;config&gt;</literal>
    element contains the name of the Zebra configuration file that was
    previously specified by the
    <literal moreinfo="none">-c</literal>
    command-line argument, and the
    <literal moreinfo="none">&lt;cql2rpn&gt;</literal>
    element contains the name of the <acronym>CQL</acronym> properties file specifying how
    various <acronym>CQL</acronym> indexes, relations, etc. are translated into Type-1
    queries.
   </para>
   <para>
    A zebra server running with such a configuration can then be
    queried using proper, conformant <acronym>SRU</acronym> URLs with <acronym>CQL</acronym> queries:
   </para>
   <screen format="linespecific">
    http://localhost:9999/Default?version=1.1
    &amp;operation=searchRetrieve
    &amp;query=title=utah and description=epicent*
    &amp;startRecord=1
    &amp;maximumRecords=1
   </screen>
  </refsect2>
 </refsect1>
 <refsect1 id="zebrasrv-sru-support">
  <title><acronym>SRU</acronym> Protocol Support and Behavior</title>
  <para>
   Zebra running as an <acronym>SRU</acronym> server supports SRU version 1.1, including
   <acronym>CQL</acronym> version 1.1.  In particular, it provides support for the
   following elements of the protocol.
  </para>

  <refsect2 id="zebrasrvr-search-and-retrieval">
   <title><acronym>SRU</acronym> Search and Retrieval</title>
   <para>
    Zebra supports the searchRetrieve operation.
   </para>
   <para>
    One of the great strengths of <acronym>SRU</acronym> is that it mandates a standard
    query language, <acronym>CQL</acronym>, and that all conforming implementations can
    therefore be trusted to correctly interpret the same queries.  It
    is with some shame, then, that we admit that Zebra also supports
    an additional query language, our own Prefix Query Format
    (<ulink url="http://www.indexdata.com/yaz/doc/tools.html#PQF"><acronym>PQF</acronym></ulink>).
    A <acronym>PQF</acronym> query is submitted by using the extension parameter
    <literal moreinfo="none">x-pquery</literal>,
    in which case the
    <literal moreinfo="none">query</literal>
    parameter must be omitted, which makes the request not valid <acronym>SRU</acronym>.
    Please feel free to use this facility within your own
    applications; but be aware that it is not only non-standard <acronym>SRU</acronym>
    but not even syntactically valid, since it omits the mandatory
    <literal moreinfo="none">query</literal> parameter.
   </para>
  </refsect2>

  <refsect2 id="zebrasrv-sru-scan">
   <title><acronym>SRU</acronym> Scan</title>
   <para>
    Zebra supports scan operation.
    Scanning using <acronym>CQL</acronym> syntax is the default, where the
    standard <literal moreinfo="none">scanClause</literal> parameter is used.
   </para>
   <para>
    In addition, a
    mutant form of <acronym>SRU</acronym> scan is supported, using
    the non-standard <literal moreinfo="none">x-pScanClause</literal> parameter in
    place of the standard <literal moreinfo="none">scanClause</literal> to scan on a
    <acronym>PQF</acronym> query clause.
   </para>
  </refsect2>

  <refsect2 id="zebrasrv-sru-explain">
   <title><acronym>SRU</acronym> Explain</title>
   <para>
    Zebra supports explain.
   </para>
   <para>
    The ZeeRex record explaining a database may be requested either
    with a fully fledged <acronym>SRU</acronym> request (with
    <literal moreinfo="none">operation</literal>=<literal moreinfo="none">explain</literal>
    and version-number specified)
    or with a simple HTTP <acronym>GET</acronym> at the server's basename.
    The ZeeRex record returned in response is the one embedded
    in the <application moreinfo="none">YAZ</application> Frontend Server configuration file that is described in the
    <xref linkend="gfs-config"/>.
   </para>
   <para>
    Unfortunately, the data found in the
    <acronym>CQL</acronym>-to-<acronym>PQF</acronym> text file must be added by hand-craft into the explain
    section of the <application moreinfo="none">YAZ</application> Frontend Server configuration file to be able
    to provide a suitable explain record.
    Too bad, but this is all extreme
    new alpha stuff, and a lot of work has yet to be done ..
   </para>
   <para>
    There is no linkage whatsoever between the <acronym>Z39.50</acronym> explain model
    and the <acronym>SRU</acronym> explain response (well, at least not implemented
    in Zebra, that is ..).  Zebra does not provide a means using
    <acronym>Z39.50</acronym> to obtain the ZeeRex record.
   </para>
  </refsect2>

  <refsect2 id="zebrasrv-non-sru-ops">
   <title>Other <acronym>SRU</acronym> operations</title>
   <para>
    In the <acronym>Z39.50</acronym> protocol, Initialization, Present, Sort and Close
    are separate operations.  In <acronym>SRU</acronym>, however, these operations do not
    exist.
   </para>
   <itemizedlist>
    <listitem>
     <para>
      <acronym>SRU</acronym> has no explicit initialization handshake phase, but
      commences immediately with searching, scanning and explain
      operations.
     </para>
    </listitem>
    <listitem>
     <para>
      Neither does <acronym>SRU</acronym> have a close operation, since the protocol is
      stateless and each request is self-contained.  (It is true that
      multiple <acronym>SRU</acronym> request/response pairs may be implemented as
      multiple HTTP request/response pairs over a single persistent
      TCP/IP connection; but the closure of that connection is not a
      protocol-level operation.)
     </para>
    </listitem>
    <listitem>
     <para>
      Retrieval in <acronym>SRU</acronym> is part of the
      <literal moreinfo="none">searchRetrieve</literal> operation, in which a search
      is submitted and the response includes a subset of the records
      in the result set.  There is no direct analogue of <acronym>Z39.50</acronym>'s
      Present operation which requests records from an established
      result set.  In <acronym>SRU</acronym>, this is achieved by sending a subsequent
      <literal moreinfo="none">searchRetrieve</literal> request with the query
      <literal moreinfo="none">cql.resultSetId=</literal><emphasis>id</emphasis> where
      <emphasis>id</emphasis> is the identifier of the previously
      generated result-set.
     </para>
    </listitem>
    <listitem>
     <para>
      Sorting in <acronym>CQL</acronym> is done within the
      <literal moreinfo="none">searchRetrieve</literal> operation - in v1.1, by an
      explicit <literal moreinfo="none">sort</literal> parameter, but the forthcoming
      v1.2 or v2.0 will most likely use an extension of the query
      language, <ulink url="http://zing.z3950.org/cql/sorting.html"><acronym>CQL</acronym> sorting</ulink>.
     </para>
    </listitem>
   </itemizedlist>
   <para>
    It can be seen, then, that while Zebra operating as an <acronym>SRU</acronym> server
    does not provide the same set of operations as when operating as a
    <acronym>Z39.50</acronym> server, it does provide equivalent functionality.
   </para>
  </refsect2>
 </refsect1>

 <refsect1 id="zebrasrv-sru-examples">
  <title><acronym>SRU</acronym> Examples</title>
  <para>
   Surf into <literal moreinfo="none">http://localhost:9999</literal>
   to get an explain response, or use
   <screen format="linespecific">
    http://localhost:9999/?version=1.1&amp;operation=explain
    </screen>
  </para>
  <para>
   See number of hits for a query
   <screen format="linespecific">
    http://localhost:9999/?version=1.1&amp;operation=searchRetrieve
    &amp;query=text=(plant%20and%20soil)
    </screen>
  </para>
  <para>
   Fetch record 5-7 in Dublin Core format
   <screen format="linespecific">
    http://localhost:9999/?version=1.1&amp;operation=searchRetrieve
    &amp;query=text=(plant%20and%20soil)
    &amp;startRecord=5&amp;maximumRecords=2&amp;recordSchema=dc
    </screen>
  </para>
  <para>
   Even search using <acronym>PQF</acronym> queries using the <emphasis>extended naughty
    parameter</emphasis> <literal moreinfo="none">x-pquery</literal>
   <screen format="linespecific">
    http://localhost:9999/?version=1.1&amp;operation=searchRetrieve
    &amp;x-pquery=@attr%201=text%20@and%20plant%20soil
    </screen>
  </para>
  <para>
   Or scan indexes using the <emphasis>extended extremely naughty
    parameter</emphasis> <literal moreinfo="none">x-pScanClause</literal>
   <screen format="linespecific">
    http://localhost:9999/?version=1.1&amp;operation=scan
    &amp;x-pScanClause=@attr%201=text%20something
    </screen>
   <emphasis>Don't do this in production code!</emphasis>
   But it's a great fast debugging aid.
  </para>

 </refsect1>

 <refsect1 id="gfs-config"><title><application moreinfo="none">YAZ</application> server virtual hosts</title>
  <!-- 
   Description of the virtual host mechanism in &yaz; GFS
   Included in both manual and man page for yaz-ztest
-->

<para>
 The Virtual hosts mechanism allows a <application moreinfo="none">YAZ</application> frontend server to
 support multiple backends. A backend is selected on the basis of
 the TCP/IP binding (port+listening address) and/or the virtual host.
</para>
<para>
 A backend can be configured to execute in a particular working
 directory. Or the <application moreinfo="none">YAZ</application> frontend may perform <ulink url="http://www.loc.gov/standards/sru/cql/"><acronym>CQL</acronym></ulink> to <acronym>RPN</acronym> conversion, thus
 allowing traditional <acronym>Z39.50</acronym> backends to be offered as a  
<ulink url="https://www.loc.gov/standards/sru/"><acronym>SRU</acronym></ulink> service. 
 <acronym>SRU</acronym> Explain information for a particular backend may also be specified.
</para>
<para>
 For the HTTP protocol, the virtual host is specified in the Host header.
 For the <acronym>Z39.50</acronym> protocol, the virtual host is specified as in the
 Initialize Request in the OtherInfo, OID 1.2.840.10003.10.1000.81.1.
</para>
<note>
 <para>
  Not all <acronym>Z39.50</acronym> clients allows the VHOST information to be set.
  For those the selection of the backend must rely on the
  TCP/IP information alone (port and address).
 </para>
</note>
<para>
 The <application moreinfo="none">YAZ</application> frontend server uses <acronym>XML</acronym> to describe the backend
 configurations. Command-line option <literal moreinfo="none">-f</literal> 
 specifies filename of the <acronym>XML</acronym> configuration.
</para>
<para>
 The configuration uses the root element <literal moreinfo="none">yazgfs</literal>.
 This element includes a list of <literal moreinfo="none">listen</literal> elements,
 followed by one or more <literal moreinfo="none">server</literal> elements.
</para>
<para>
 The <literal moreinfo="none">listen</literal> describes listener (transport end point),
 such as TCP/IP, Unix file socket or SSL server. Content for 
 a listener:
 <variablelist>
  <varlistentry><term>CDATA (required)</term>
   <listitem>
    <para>
     The CDATA for the <literal moreinfo="none">listen</literal> element holds the
     listener string, such as <literal moreinfo="none">tcp:@:210</literal>, 
     <literal moreinfo="none">tcp:server1:2100</literal>,
     etc.
    </para>
   </listitem>
  </varlistentry>
  <varlistentry><term>attribute <literal moreinfo="none">id</literal> (optional)</term>
    <listitem>
     <para>
      identifier for this listener. This may be referred to from
      server sections.
     </para>
    </listitem>
   </varlistentry>
 </variablelist>
 <note>
  <para>
   We expect more information to be added for the listen section in
   a future version, such as CERT file for SSL servers.
  </para>
 </note>
</para>
<para>
 The <literal moreinfo="none">server</literal> describes a server and the parameters
 for this server type. Content for a server:
 <variablelist>
  <varlistentry><term>attribute <literal moreinfo="none">id</literal> (optional)</term>
   <listitem>
    <para>
     Identifier for this server. Currently not used for anything,
     but it might be for logging purposes.
   </para>
   </listitem>
  </varlistentry>

  <varlistentry><term>attribute <literal moreinfo="none">listenref</literal> (optional)</term>
   <listitem>
    <para>
     Specifies listener for this server. If this attribute is not
     given, the server is accessible from all listener. In order
     for the server to be used for real, however, the virtual host
     must match (if specified in the configuration).
    </para>
   </listitem>
  </varlistentry>

  <varlistentry><term>element <literal moreinfo="none">config</literal> (optional)</term>
   <listitem>
    <para>
     Specifies the server configuration. This is equivalent
     to the config specified using command line option
     <literal moreinfo="none">-c</literal>.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry><term>element <literal moreinfo="none">directory</literal> (optional)</term>
   <listitem>
    <para>
     Specifies a working directory for this backend server. If
     specified, the <application moreinfo="none">YAZ</application> frontend changes current working directory
     to this directory whenever a backend of this type is
     started (backend handler bend_start), stopped (backend handler hand_stop)
     and initialized (bend_init).
    </para>
   </listitem>
  </varlistentry>

  <varlistentry><term>element <literal moreinfo="none">host</literal> (optional)</term>
   <listitem>
    <para>
     Specifies the virtual host for this server. If this is specified
     a client <emphasis>must</emphasis> specify this host string in
     order to use this backend.
    </para>
   </listitem>
  </varlistentry>

  <varlistentry><term>element <literal moreinfo="none">cql2rpn</literal> (optional)</term>
   <listitem>
    <para>
     Specifies a filename that includes <ulink url="http://www.loc.gov/standards/sru/cql/"><acronym>CQL</acronym></ulink> to <acronym>RPN</acronym> conversion for this
     backend server. See <ulink url="http://www.loc.gov/standards/sru/cql/"><acronym>CQL</acronym></ulink> section in <application moreinfo="none">YAZ</application> manual.
     If given, the backend server will only "see" a Type-1/<acronym>RPN</acronym> query. 
    </para>
   </listitem>
  </varlistentry>
   
  <varlistentry><term>element <literal moreinfo="none">explain</literal> (optional)</term>
   <listitem>
    <para>
     Specifies <ulink url="https://www.loc.gov/standards/sru/"><acronym>SRU</acronym></ulink> ZeeRex content for this
     server - copied verbatim to the client.
     As things are now, some of the Explain content seems redundant
     because host information, etc. is also stored elsewhere.
    </para>
    <para>
     The format of the Explain record is described in detail, with
     examples, on the file at the
     <ulink url="http://zeerex.z3950.org/">ZeeRex</ulink> web-site.
    </para>
   </listitem>
  </varlistentry>
 </variablelist>
</para>
 
<para>
 The <acronym>XML</acronym> below configures a server that accepts connections from
 two ports, TCP/IP port 9900 and a local UNIX file socket.
 We name the TCP/IP server <literal moreinfo="none">public</literal> and the
 other server <literal moreinfo="none">internal</literal>.
 </para>
 <screen format="linespecific">
  
 &lt;yazgfs&gt;
  &lt;listen id="public"&gt;tcp:@:9900&lt;/listen&gt;
  &lt;listen id="internal"&gt;unix:/var/tmp/socket&lt;/listen&gt;
  &lt;server id="server1"&gt;
    &lt;host&gt;server1.mydomain&lt;/host&gt;
    &lt;directory&gt;/var/www/s1&lt;/directory&gt;
    &lt;config&gt;config.cfg&lt;/config&gt;
  &lt;/server&gt;
  &lt;server id="server2"&gt;
    &lt;host&gt;server2.mydomain&lt;/host&gt;
    &lt;directory&gt;/var/www/s2&lt;/directory&gt;
    &lt;config&gt;config.cfg&lt;/config&gt;
    &lt;cql2rpn&gt;../etc/pqf.properties&lt;/cql2rpn&gt;
    &lt;explain xmlns="http://explain.z3950.org/dtd/2.0/"&gt;
      &lt;serverInfo&gt;
        &lt;host&gt;server2.mydomain&lt;/host&gt;
        &lt;port&gt;9900&lt;/port&gt;
        &lt;database&gt;a&lt;/database&gt;
      &lt;/serverInfo&gt;
    &lt;/explain&gt;
  &lt;/server&gt;
  &lt;server id="server3" listenref="internal"&gt;
    &lt;directory&gt;/var/www/s3&lt;/directory&gt;
    &lt;config&gt;config.cfg&lt;/config&gt;
  &lt;/server&gt;
 &lt;/yazgfs&gt;

 </screen>
<para>
 There are three configured backend servers. The first two
 servers, <literal moreinfo="none">"server1"</literal> and <literal moreinfo="none">"server2"</literal>,
 can be reached by both listener addresses - since
 no <literal moreinfo="none">listenref</literal> attribute is specified.
 In order to distinguish between the two a virtual host has
 been specified for each of server in the <literal moreinfo="none">host</literal>
 elements.
</para>
<para>
 For <literal moreinfo="none">"server2"</literal> elements for 
<ulink url="http://www.loc.gov/standards/sru/cql/"><acronym>CQL</acronym></ulink> to <acronym>RPN</acronym> conversion
 is supported and explain information has been added (a short one here
 to keep the example small).
</para>
<para>
 The third server, <literal moreinfo="none">"server3"</literal> can only be reached
 via listener <literal moreinfo="none">"internal"</literal>.
</para>

<!-- Keep this comment at the end of the file
Local variables:
mode: sgml
sgml-omittag:t
sgml-shorttag:t
sgml-minimize-attributes:nil
sgml-always-quote-attributes:t
sgml-indent-step:1
sgml-indent-data:t
sgml-parent-document: "zebrasrv.xml"
sgml-local-catalogs: nil
sgml-namecase-general:t
End:
-->

 </refsect1>

 <refsect1><title>SEE ALSO</title>
  <para>
   <citerefentry>
    <refentrytitle>zebraidx</refentrytitle>
    <manvolnum>1</manvolnum>
   </citerefentry>
  </para>
 </refsect1>
</refentry>
<!--Generated by stripref.xsl . Do not edit-->
<refentry id="idzebra-config">
 <refentryinfo>
  <productname class="trade">zebra</productname>
  <productnumber>2.2.8</productnumber>
  <orgname>Index Data</orgname>
 </refentryinfo>
 
 <refmeta>
  <refentrytitle>idzebra-config</refentrytitle>
  <manvolnum>1</manvolnum>
  <refmiscinfo class="manual">Commands</refmiscinfo>
 </refmeta>
 
 <refnamediv>
  <refname>idzebra-config</refname>
  <refpurpose>Script to get information about idzebra</refpurpose>
 </refnamediv>
 
 <refsynopsisdiv>
  <cmdsynopsis sepchar=" ">
   <command moreinfo="none">idzebra-config</command>
   <arg choice="opt" rep="norepeat"><option>--prefix[=<replaceable>DIR</replaceable>]</option></arg>
   <arg choice="opt" rep="norepeat"><option>--version</option></arg>
   <arg choice="opt" rep="norepeat"><option>--libs</option></arg>
   <arg choice="opt" rep="norepeat"><option>--lalibs</option></arg>
   <arg choice="opt" rep="norepeat"><option>--cflags</option></arg>
   <arg choice="opt" rep="norepeat"><option>--tab</option></arg>
   <arg choice="opt" rep="norepeat"><option>--modules</option></arg>
   <arg choice="opt" rep="repeat">libraries</arg>
  </cmdsynopsis>
 </refsynopsisdiv>
 
 <refsect1><title>DESCRIPTION</title>
  <para>
   <command moreinfo="none">idzebra-config</command> is a script that returns information
   that your own software should use to build software that uses idzebra.
  </para>

  <para>
   The following libraries are supported:
  </para>

  <para>
   None
  </para>
  
 </refsect1>
 
 <refsect1><title>OPTIONS</title>
  
  <variablelist>
   <varlistentry>
    <term>--prefix[=<replaceable>DIR</replaceable>]</term>
    <listitem><para>
      Returns prefix of idzebra or assume a different one if DIR is
      specified.
     </para></listitem>
   </varlistentry>

   <varlistentry>
    <term>--version</term>
    <listitem><para>
      Returns version of idzebra.
     </para></listitem>
   </varlistentry>

   <varlistentry>
    <term>--libs</term>
    <listitem><para>
      Library specification be used when linking with idzebra.
     </para></listitem>
   </varlistentry>

   <varlistentry>
    <term>--lalibs</term>
    <listitem><para>
      Return library specification.
     </para></listitem>
   </varlistentry>

   <varlistentry>
    <term>--cflags</term>
    <listitem><para>
      Return C Compiler flags.
     </para></listitem>
   </varlistentry>

   <varlistentry>
    <term>--tab</term>
    <listitem><para>
      Return directory of idzebra tables.
     </para></listitem>
   </varlistentry>

   <varlistentry>
    <term>--modules</term>
    <listitem><para>
      Return directory for <application moreinfo="none">Zebra</application> modules.
     </para></listitem>
   </varlistentry>

  </variablelist>
 </refsect1>
 
 <refsect1><title>FILES</title>
  <para>
   <filename moreinfo="none">/usr/bin/idzebra-config-2.0</filename>
  </para>
  <para>
   <filename moreinfo="none">/usr/lib/libidzebra*2.0.a</filename>
  </para>
  <para>
   <filename moreinfo="none">/usr/include/idzebra-2.0/idzebra/*.h</filename>
  </para>
 </refsect1>

</refentry>
<!--Generated by stripref.xsl . Do not edit-->
<refentry id="idzebra-abs2dom">
 <refentryinfo>
  <productname class="trade">zebra</productname>
  <productnumber>2.2.8</productnumber>
  <orgname>Index Data</orgname>
 </refentryinfo>

 <refmeta>
  <refentrytitle>idzebra-abs2dom</refentrytitle>
  <manvolnum>1</manvolnum>
  <refmiscinfo class="manual">Commands</refmiscinfo>
 </refmeta>
 
 <refnamediv>
  <refname>idzebra-abs2dom</refname>
  <refpurpose>Converts .abs files to DOM XML configuration files</refpurpose>
 </refnamediv>
 
 <refsynopsisdiv>
  <cmdsynopsis sepchar=" ">
   <command moreinfo="none">idzebra-abs2dom</command>
   <arg choice="opt" rep="norepeat"><replaceable>file</replaceable></arg>
  </cmdsynopsis>
 </refsynopsisdiv>
 
 <refsect1><title>DESCRIPTION</title>
  <para>
   <command moreinfo="none">idzebra-abs2dom</command> converts grs filter .abs files
   to DOM XML filter index XSLT files.
   The melm and xelm directives are converted to XSLT rules. Conversion
   of elm directives are not supported.
  </para>
 </refsect1>
 <refsect1><title>SEE ALSO</title>
  <para>
   <citerefentry>
    <refentrytitle>zebraidx</refentrytitle>
    <manvolnum>1</manvolnum>
   </citerefentry>
  </para>
</refsect1>
</refentry>